|
Copying Sartak's #cobol contribution for posterity...code:
|
#
?
Jan 13, 2009 21:46
|
|
|
|
| # ? Apr 24, 2024 16:32 |
|
|
Okay, now my real question. We've covered what. Now why. Why is this superior than traditional return's? I've not yet seen anything you couldn't do with just return. It's even worse in the above example. If there's no subroutine flow to complicate things, how is it any different then assigning one value, then assigning another right after. How does rewinding help the workflow of two assignments? PS, thanks to Sartak for being so patient. You trooper.
|
|
#
?
Jan 13, 2009 21:48
|
|
|
biznatchio posted:What's it do that this doesn't do? Continuation::Escape doesn't trigger an exception to jump back up the stack. This is useful because if your code inside the call_cc catches exceptions then it has to know to rethrow the escape-continuation exception. If you get a stack trace (immeasurably useful for debugging) then it'll look like the exception occurred at the rethrow statement instead of the original expression, which really sucks. $SIG{__DIE__} adds more fun to the mix. In short, I don't want to reuse exceptions as a flow control mechanism.
|
|
#
?
Jan 14, 2009 02:06
|
|
|
Any suggestions on an ORM package? Any favorites?
|
|
#
?
Jan 14, 2009 17:15
|
|
|
DBIx::Class seems to be the latest and greatest. It's the most actively developed and maintained. Dave Rolsky (author of HTML::Mason, DateTime, Params::Vaidate, Log:  ispatch..) has been writing Fey for a while but I haven't looked at it. Might be worth playing with if this is for a hobby project.
|
|
#
?
Jan 14, 2009 17:33
|
|
|
http://pastie.textmate.org/private/0gmfj9j1aafa0royekgiyg It's output: php:<?
$VAR1 = {
'server' => [
{
'awstats' => '/var/lib/awstats',
'name' => 'Buttjumper',
'address' => 'buttjumper.yourmom.com',
'logs' => '/var/log/awstats',
'username' => 'asdfasdf',
'os' => 'Linux'
},
{
'awstats' => '/var/lib/awstats',
'name' => 'LWBP01',
'address' => 'LWBP01.yourmom.com',
'logs' => '/var/log/awstats',
'username' => 'rfreiburger',
'os' => 'Linux'
}
]
};
Buttjumper
Reference found where even-sized list expected at xmlTest.pl line 12.
Use of uninitialized value $d{"HASH(0x876b1a4)"} in concatenation (.) or string at xmlTest.pl line 14.?>
|
|
#
?
Jan 14, 2009 20:46
|
|
|
Did you dereference the hash before consuming it? Each server has multiple hash-objects, but then each of those objects need to be referred to as real hashes and not just elements of the collection.
|
|
#
?
Jan 14, 2009 20:49
|
|
|
Sartak posted:DBIx::Class seems to be the latest and greatest. It's the most actively developed and maintained. Seconded. It's got very comprehensive documentation too. I've also heard good things about Rose::DB
|
|
#
?
Jan 15, 2009 00:28
|
|
|
Triple Tech posted:Okay, now my real question. We've covered what. Now why. Why is this superior than traditional return's? I've not yet seen anything you couldn't do with just return. Tree-search. If you have to search through some tree recursively and are only looking for one single result, i'd gather you can do something like this: 1. Mark the point where you start searching. 2. Dive into tree. 3. Once you've got the result, jump back to the marked point with the result. Compared with bubbling the result back up with returns, this could probably be faster. More importantly though it should be easier to implement with less code, since you don't need to return ANYTHING at all, and can thus also completely skip any sorts of checks on returns. Mithaldu fucked around with this message at 07:27 on Jan 15, 2009 |
|
#
?
Jan 15, 2009 07:23
|
|
|
I'm very new to perl and I've got like the simplest problem in the world that I can't seem to fix it. I've got an if statement that by all signs should be evaluating to true and executing its code block some of the time, but instead is never evaluating to true. The statement is so friggin simple:code:
|
|
#
?
Jan 15, 2009 23:37
|
|
|
String comparison is done with eq or ne. Stuff like != only works on numbers.  http://perldoc.perl.org/perlop.html
|
|
#
?
Jan 15, 2009 23:48
|
|
|
Mithaldu posted:String comparison is done with eq or ne. Stuff like != only works on numbers. Thanks! So far, coming from Python, my impression of Perl is that it cares way too goddamn much about data types.
|
|
#
?
Jan 15, 2009 23:55
|
|
|
Wow, I've never heard anyone say anything like that considering Perl is so lazy and does everything so automagically... What do the more experienced Perl guys have to say about this, from a philosophical perspective?
|
|
#
?
Jan 16, 2009 00:07
|
|
|
Triple Tech posted:What do the more experienced Perl guys have to say about this, from a philosophical perspective? Perl has significantly weaker typing than Python. Because its typing is so weak, a running Perl program can't infer if you intended, for example, a string comparison or a numeric comparison. It requires the programmer to explicitly annotate the code with which comparison is the correct one. This comes out of an older programming mentality - the programmer presumably knows what he wants, so it's "not any harder" to make it explicit. And given that the programmer can make it explicit, there's no reason to have the programming language "second guess" the programmer and force strong typing on them - computers should just do as they're told. Fortunately, this attitude has been going away for a long time. Almost all the newer generation of languages are at least strongly typed enough to differentiate between numbers and strings, and most of the dynamic languages have very strong type systems.
|
|
#
?
Jan 16, 2009 00:22
|
|
|
I am retrieving a path from an external source and now have a string: C:\Program Files\Foo Bar Baz\bin I need to shorten it like so: C:\Progra~1\Foo Ba~1\bin Any idea how I can do this with the least amount of packages?
|
|
#
?
Jan 16, 2009 02:08
|
|
|
GetShortPathName from Win32
|
|
#
?
Jan 16, 2009 02:19
|
|
|
Triple Tech posted:GetShortPathName from Win32 Works great, thanks!
|
|
#
?
Jan 16, 2009 02:39
|
|
|
s/\\(.{8}).+(\\)/\\\1~1\2/g would work too I would think. Untested and off the top of my head.
|
|
#
?
Jan 16, 2009 04:55
|
|
|
Fenderbender posted:s/\\(.{8}).+(\\)/\\\1~1\2/g would work too I would think. Untested and off the top of my head. I think your regexp is still broken. Regardless, you need to check the file system to reliably determine a short name due to the possibility of naming collisions. If I make a root-level folder on C: called "Program Stuff", it'll wind up being Progra~2 due to Progra~1 being taken by "Program Files".
|
|
#
?
Jan 16, 2009 05:09
|
|
|
Erasmus Darwin posted:I think your regexp is still broken. Regardless, you need to check the file system to reliably determine a short name due to the possibility of naming collisions. If I make a root-level folder on C: called "Program Stuff", it'll wind up being Progra~2 due to Progra~1 being taken by "Program Files". Ah, yes, completely forgot about that.
|
|
#
?
Jan 16, 2009 05:13
|
|
|
ShoulderDaemon posted:Perl has significantly weaker typing than Python. Perl's typing isn't that weak. Perl has a hierarchy of several types of scalars (integer, double, string, reference, etc) and can freely change a scalar from one type to another as needed. code:The == operator tests literal C equality of its operands as integers. The scalar operands are downgraded to IV type scalars if they are a more complex type, which is why " 43 " == 43 works without warning. This operator is faster than eq. The eq operator does string comparison via an API function called sv_eq. This op is utf8-aware, and converts its operands to "PV scalars" before evaluation. It is more expensive than using the == operator, however, Perl has absolutely no problems comparing two integer scalars via eq.
|
|
#
?
Jan 19, 2009 21:25
|
|
|
satest4 posted:Perl's typing isn't that weak. Perl[...] can freely change a scalar from one type to another as needed. That is the definition of weak typing. If there was only one scalar type, like Tcl, it would be an untyped language. satest4 posted:The == and eq are two different operators because they do different things, not because Perl is too stupid to discern type. Well, programmers normally elect to encode semantic differences like which equality matters in the type of the values involved, but because Perl allows essentially any type conversion this is very hard to do, so instead the programmer manually selects which comparator to call. I think it's all just an evolution in mindset. Many of the older-generation programming languages have weak typing: Perl, C, C++ (to a lesser extent), BASIC, PASCAL. Programmers were more willing to annotate individual statements and less willing to trust compilers to infer information from types. Programming with weak types is much more similar to how the program will actually be executed, and the early high-level languages strongly reflect this. Nowadays most programmers don't care about the compile-time or runtime overhead of strong typing systems, and are willing to admit more and more clever compilers. In C++ we got signature-based dispatch, stronger restrictions on enums and pointers and such, and the class system. Then, in Java, we lost a wide variety of automatic conversions and got even stronger restrictions on array types and primitives. Newer dynamic languages like Ruby and Python make conversions explicit and use a significant amount of type information at runtime.
|
|
#
?
Jan 19, 2009 22:06
|
|
|
You are throwing around a lot of different ideas in your rush to declare progress. There is no accepted meaning for "weak typing", and everyone who says it means a different thing; in particular, I have no idea what you mean it to be. There is an accepted notion of "untyped" as meaning "having no static type system," which is a somewhat vague notion but certainly includes Ruby and Python. And even C "infers information from types" quite a lot.
|
|
#
?
Jan 20, 2009 00:03
|
|
|
Quote is not edit.
|
|
#
?
Jan 20, 2009 00:04
|
|
|
rjmccall posted:You are throwing around a lot of different ideas in your rush to declare progress. There is no accepted meaning for "weak typing", and everyone who says it means a different thing; in particular, I have no idea what you mean it to be. There is an accepted notion of "untyped" as meaning "having no static type system," which is a somewhat vague notion but certainly includes Ruby and Python. And even C "infers information from types" quite a lot. That's a fair complaint. I was using what wikipedia indicates as the most common usage; that the language performs many implicit type conversions and consequently cannot make many promises about type safety. I've never heard untyped specifically exclude dynamic typing. Certainly Ruby's typechecking is capable of providing more type safety than Perl or C; it just happens at runtime and is not subject to static analysis. Tcl, on the other hand, genuinely makes no distinctions at all between different kinds of scalar values. And yes, C does have enough type information that the compiler can make some use if it, but much of the work is left to the programmer. For example, if we have a function which we would like to vary the implementation of depending on if its parameter is an int or a long, we would have to give the implementations different names and explicitly call one or the other at appropriate times. In C++, we've allowed the language some additional room to infer which implementation of the function is the most appropriate to call, and we can assign them both the same name.
|
|
#
?
Jan 20, 2009 00:55
|
|
|
ShoulderDaemon posted:That's a fair complaint. I was using what wikipedia indicates as the most common usage; that the language performs many implicit type conversions and consequently cannot make many promises about type safety. This is all very difficult to interpret. We usually use "implicit type conversions" to mean things that the compiler/runtime intentionally does; it's not obvious how that affects "type safety". Clearly it doesn't change the basic soundness of the language — I can only think of one (common) language that makes any implicit unsound conversions at all (C's treatment of void*). If you mean "type safety" as in "the system forbids meaningless operations", well, I don't see how the implicit conversions in most statically-typed languages affect that — typically they're just casts to supertypes, and any "meaningless" operation defined for a supertype is necessarily defined for the subtype. So I think you're arguing that dynamically-typed languages should fail when they encounter unexpected types of values instead of trying to infer or convert to something sensible — and I agree that that's a good design principle for dynamically-typed languages. That said, I'm not sure how compatible this is with your praise for overloading. I mean, the multiplication operator in Ruby is overloaded to work on some curious combinations of types — surely that impacts type safety just as much as implicit type conversions do. ShoulderDaemon posted:I've never heard untyped specifically exclude dynamic typing. Certainly Ruby's typechecking is capable of providing more type safety than Perl or C; it just happens at runtime and is not subject to static analysis. Tcl, on the other hand, genuinely makes no distinctions at all between different kinds of scalar values. So, first off, that's not really true of Tcl; the value of an expression is always a string, yes, but those strings can be the names of variables that hold real objects that behave exactly like you would expect an object to behave. And, of course, if you're programming for efficiency you have to bear in mind that the major Tcl implementations basically store values using a sum-type just like every other dynamically-typed language. But anyway, we could substitute sh and get back to the major point. The use of "untyped" to mean "the syntax doesn't carry type information" dates back to Church and the lambda-calculus; whatever. PL researchers usually wouldn't call dynamic typing a type system at all: of course the language has different kinds of values, that goes without saying. Even our idealized Tcl has multiple kinds of values; it just chooses to represent them all using strings. If you wanted to, you could build a real static type system on top of Tcl, tracking booleans and numbers and variable references and true-strings, and you'd gain some safety and lose a great deal of expressiveness.
|
|
#
?
Jan 20, 2009 03:50
|
|
|
I've got a step in a script at which I need to see if two times are equal to one another. They come in as a UTC string, and I'm not sure which is quicker -- convert the string to an integer with str2time and compare the integers, or just use a string comparison on the twenty-odd character string. I can't just use time to test the two methods, since my data gets pulled from an external source that varies wildly in the amount of time it takes to return a query result. Anyone know which is quicker?
|
|
#
?
Jan 20, 2009 20:08
|
|
|
Sock on a Fish posted:I've got a step in a script at which I need to see if two times are equal to one another. They come in as a UTC string, and I'm not sure which is quicker -- convert the string to an integer with str2time and compare the integers, or just use a string comparison on the twenty-odd character string. I can't just use time to test the two methods, since my data gets pulled from an external source that varies wildly in the amount of time it takes to return a query result. If you're not worried about compile-time overhead, Date::Manip is good for such a thing.
|
|
#
?
Jan 20, 2009 20:21
|
|
|
Why care about speed at all? Just use string equality. Given no context, I would assume this is just premature optimization.
|
|
#
?
Jan 20, 2009 20:35
|
|
|
Oh, I completely missed that it's coming in UTC format. I need to readed better.
|
|
#
?
Jan 20, 2009 21:08
|
|
|
Sock on a Fish posted:I've got a step in a script at which I need to see if two times are equal to one another. They come in as a UTC string, and I'm not sure which is quicker -- convert the string to an integer with str2time and compare the integers, or just use a string comparison on the twenty-odd character string. I can't just use time to test the two methods, since my data gets pulled from an external source that varies wildly in the amount of time it takes to return a query result. Let me give you a hint: str2time does not magically turn the string into an integer without looking at every character in the string.
|
|
#
?
Jan 20, 2009 21:47
|
|
|
Sure, I guess that should have been fairly obvious. Maybe, just maybe numeric comparisons are faster than string comparisons. But you're also spending cycles on conversion, which sort of defeats your quest for speed. Again, why not go for the one with the least inertia. Less logic, less dependencies.
|
|
#
?
Jan 20, 2009 22:06
|
|
|
I'm not sure if you're basing your question off of what satest4 said, but 'eq' is not so slow as to make it unwise to use. Use eq and == where appropriate, ie, eq for strings and == for integers, and don't worry about the performance implications of either.
|
|
#
?
Jan 20, 2009 23:23
|
|
|
Here's a few (hopefully) quick question. For a bit of background, I've got a pretty large app that does a lot of background processing, with a bit of user interaction (status messages, question & answer bits etc). The cli "interface" is done via Term::UI The first problem i've got is that some new (external to my package) routines that need to run take quite a long time to processes (like a few minutes), so i'd like to essentially background them and keep the main body running, until i need the results... From experimenting (use Thread qw(async)) it seems the external modules are not very thread safe. I know i can fork() and leave the child running until it finishes or waitpid() it out, if there anyway to return the modified variables from the parent back to main? Second one up, it'd benefit quite a bit if the interface could have a status bar (similar to screen's hardstatus). Does anyone know of a nice way of doing this? It wouldn't be the end of the world if the Term::UI stuff had to go
|
|
#
?
Jan 21, 2009 04:57
|
|
|
If you want concurrency without using actual threads, you could try Coro.
|
|
#
?
Jan 21, 2009 09:58
|
|
|
bbatter posted:Second one up, it'd benefit quite a bit if the interface could have a status bar (similar to screen's hardstatus). Does anyone know of a nice way of doing this? It wouldn't be the end of the world if the Term::UI stuff had to go code:
|
|
#
?
Jan 21, 2009 14:28
|
|
|
Have you guys looked at Fey? This Dave Rolsky character seems pretty involved. And, it seems to address what I think I want, an object-oriented way of modeling SQL.
|
|
#
?
Jan 26, 2009 19:23
|
|
|
Dave Rolsky writes practically bug-free code, so I'm sure Fey is very well done. It's also built on top of Moose. I haven't looked at it yet though. I find myself generally moving away from relational databases and am likely to try KiokuDB (an object database) for my next project that would've required an ORM.
|
|
#
?
Jan 27, 2009 00:01
|
|
|
One of my coworkers wrote something like this:code:Specifically, this: @{$hash_ref}{"donkey"} = "rear end"; What the hell is going on there? It will set the "donkey" key in $hash_ref to be "rear end" but... how? I didn't know you could use the {} notation on an array.
|
|
#
?
Jan 28, 2009 04:15
|
|
|
|
| # ? Apr 24, 2024 16:32 |
|
|
It's called a hash slice and is occasionally quite useful. It's clearer if you have a plain hash and not a complicated expression that evaluates to a hashref, like your coworker's code.code:
|
|
#
?
Jan 28, 2009 05:07
|
|