|
checkeredshawn posted:Ah, thanks for the ampersand tip, I was unsure about that also. The undefined value error message confuses me because I definitely declare it in the first block of code with An "undefined" variable does not mean it was not created with "my", it means it contains the value "undef" (similar to NULL value in a database). If you didn't declare the variable with "my" you would get a "Global symbol "$asdf" requires explicit package name" error.
|
# ? Aug 5, 2008 21:59 |
|
|
# ? May 21, 2024 16:04 |
|
Double check that whatever is setting alias is actually working. For fun, set the alias to a simple value like "apple" and see if that works. Your config parsing code looks okay, I'm starting to wonder what the actual lines look like. Again, using lots of Data::Dumper would help a lot.
|
# ? Aug 5, 2008 22:26 |
|
I figured it out, I had one block of text that didn't match either /^field/ or /^alias/ so it was coming out undef I guess. I altered the code to skip over that block of text and now it works. Thanks for all your help guys.
|
# ? Aug 5, 2008 22:48 |
|
Anyone know of a Perl module that will gather command line arguments:code:
-option => ('one', 'two', 'three') -other => 'four' Or how I might start thinking about writing this myself? Thanks.
|
# ? Aug 6, 2008 18:21 |
|
The Getopt series. I recommend Getopt::Long, having used it many times at work.
|
# ? Aug 6, 2008 18:23 |
|
Triple Tech posted:The Getopt series. I recommend Getopt::Long, having used it many times at work. Yeah, I've used Getopt::Long before, but the only problem is this time around there are 26 different options that can be passed to the command line. Is there any way to have Getopt just gather all of the options for me instead of having to type them all out manually?
|
# ? Aug 6, 2008 18:38 |
|
A naive implementation for your example:code:
|
# ? Aug 6, 2008 18:48 |
|
Again I'm wont to question your initial design before proceeding. What one thing really has 26 dimensions?
|
# ? Aug 6, 2008 18:52 |
|
Triple Tech posted:Again I'm wont to question your initial design before proceeding. What one thing really has 26 dimensions? It's a really long flat text file containing 26 fields of information for each object.
|
# ? Aug 6, 2008 19:17 |
|
checkeredshawn posted:It's a really long flat text file containing 26 fields of information for each object. Why dont you open the file and read the contents instead of accepting them on the command line?
|
# ? Aug 6, 2008 19:20 |
|
Erm, why don't you slurp each line and construct a full model out of it, and then just selectively act on which fields you want? I don't see how this directly relates to command line options.
|
# ? Aug 6, 2008 19:30 |
|
Subotai posted:Why dont you open the file and read the contents instead of accepting them on the command line? I forgot to mention the purpose of the script is to be able to filter the contents of the text file by field, and then to be able to print out specific attributes. Say I have 3 objects in the file with 3 attributes: code:
code:
code:
checkeredshawn fucked around with this message at 19:34 on Aug 6, 2008 |
# ? Aug 6, 2008 19:31 |
|
drat, ain't that some poo poo. Well, if your arguments are really that dynamic, might as well parse @ARGV yourself, or look into the Getopt documentation. I've never had to deal with a moving target.
|
# ? Aug 6, 2008 19:50 |
|
Triple Tech posted:drat, ain't that some poo poo. Well, if your arguments are really that dynamic, might as well parse @ARGV yourself, or look into the Getopt documentation. I've never had to deal with a moving target. I think I'm just gonna read all of the Getopt documentation I can find.
|
# ? Aug 6, 2008 20:11 |
|
checkeredshawn posted:I forgot to mention the purpose of the script is to be able to filter the contents of the text file by field, and then to be able to print out specific attributes. Say I have 3 objects in the file with 3 attributes: So you are creating a way to query data. Would it not be simpler to import the data into a database? Have your script define which fields may be used for matching and which can be displayed, and generate SQL to pull what was requested. Maybe use a syntax such as this: code:
|
# ? Aug 6, 2008 22:14 |
|
Have a look at Getopt::Whatever and Getopt::Casual, I bet one of those will do what you need.
|
# ? Aug 6, 2008 22:50 |
|
I also like Getopt::Euclid, since it basically takes your documentation and generates command line arguments out of it. For this poster's needs though, I would probably parse @ARGV myself.
|
# ? Aug 6, 2008 23:11 |
|
What's a compelling reason to use an INIT block versions just some code in main:: when making a module? My coworker says it's easier to tell how code in a module breaks if it's inside an INIT, versus main where it just says module use failed. I told him, you could see the error if you just ran the module as a script. Thoughts?
|
# ? Aug 14, 2008 16:33 |
|
Triple Tech posted:What's a compelling reason to use an INIT block versions just some code in main:: when making a module? My coworker says it's easier to tell how code in a module breaks if it's inside an INIT, versus main where it just says module use failed. I told him, you could see the error if you just ran the module as a script. Thoughts? INIT is the first thing to get called after compilation (except BEGIN blocks or 'use' statements, etc). The main reason to use it is to make sure you have certain code executed before anything else. You can think of it as a constructor I guess. I have never heard of it being used to find errors. Maybe he is thinking of eval? *edit* typos Subotai fucked around with this message at 17:34 on Aug 14, 2008 |
# ? Aug 14, 2008 17:12 |
|
I've never heard of it being used for anything ever. What's a really good, typical example of someone using an INIT that can't just be in main before the subroutines?
|
# ? Aug 14, 2008 17:13 |
|
Triple Tech posted:I've never heard of it being used for anything ever. What's a really good, typical example of someone using an INIT that can't just be in main before the subroutines? It could be considered cleaner I suppose. I dunno, ask your co-worker to explain himself.
|
# ? Aug 14, 2008 17:44 |
|
Triple Tech posted:What's a compelling reason to use an INIT block versions just some code in main:: when making a module? My coworker says it's easier to tell how code in a module breaks if it's inside an INIT, versus main where it just says module use failed. I told him, you could see the error if you just ran the module as a script. Thoughts? You put initializaton and unloading code into INIT, BEGIN and END blocks when you're writing scripts that get compiled once and then used precompiled, like FastCGI and PersistentPerl edit: Irssi scripts, too. edit: not necessarily irssi scripts, but I think I had a case once when I used it. heeen fucked around with this message at 19:55 on Aug 14, 2008 |
# ? Aug 14, 2008 19:27 |
|
Triple Tech posted:What's a compelling reason to use an INIT block versions just some code in main:: when making a module? My coworker says it's easier to tell how code in a module breaks if it's inside an INIT, versus main where it just says module use failed. I told him, you could see the error if you just ran the module as a script. Thoughts? If you're writing a module, why would you have related code in main::? BEGIN blocks are eval'd as soon as they are defined, and then the block is undefined. An INIT block is executed before normal runtime, but like normal code (it is not eval'd). I think there is also CHECK and another type that happen even before INIT. Remember use implies BEGIN around the code it loads.
|
# ? Aug 15, 2008 16:45 |
|
I'm talking about the main:: section of the pm file itself. My understanding of a module is that 99% of it is subs. And there's some code outside of those subs sometimes, right? Things that need to be computed once, like lookup tables? Or are you implying that there should pretty much never be that type of code and it should all be inside of some sort of block?
|
# ? Aug 15, 2008 16:50 |
|
heeen posted:You put initializaton and unloading code into INIT, BEGIN and END blocks when you're writing scripts that get compiled once and then used precompiled, like FastCGI and PersistentPerl Sort of. For FastCGI, you usually run a script that enters a loop to process requests. Any code run outside of the loop performs initialization that affects all requests regardless of BEGIN/INIT (ie, it is not run again within the loop). There's similar implications for forking, of course.
|
# ? Aug 15, 2008 17:01 |
|
Triple Tech posted:I'm talking about the main:: section of the pm file itself. My understanding of a module is that 99% of it is subs. And there's some code outside of those subs sometimes, right? Things that need to be computed once, like lookup tables? A pm file is just a perl script. What really defines the scope is the package declaration, not the file. If you have this code: code:
code:
code:
(edit: also I would point out that it is probably bad form to have code in a pm file outside of a package declaration, since that code would execute in the caller's namespace) s139252 fucked around with this message at 17:28 on Aug 15, 2008 |
# ? Aug 15, 2008 17:21 |
|
Okay, right, wow, totally my fault. Every single time I said main:: I just meant in the package but not tucked in a subroutine or block.
|
# ? Aug 15, 2008 18:41 |
|
Triple Tech posted:Okay, right, wow, totally my fault. Every single time I said main:: I just meant in the package but not tucked in a subroutine or block. Oh I see - package scope. The easiest way to view the whole thing is that the compiler inlines all the code it uses into one big contiguous block of perl. The package statement really means "change current symbol table". That is what allows non-contiguous weirdness like this (which is actually useful in unit tests sometimes): code:
Neat topic though. As an aside, aren't END blocks LIFO? I think they at least were at some point... I never use them so I forget.
|
# ? Aug 15, 2008 21:04 |
|
Yeah, they're LIFO:code:
code:
|
# ? Aug 16, 2008 09:54 |
|
I need some assistance from a SOAP::Lite expert. I am using SOAP::Lite to run a SOAP service. I have a very simple sanity check method and am querying it in soapUI to view its adherence to the WSDL. I have two servers. One is running SOAP::Lite version 0.69, the other is running 0.60. The server running 0.60 returns the correct data and it validates against the WSDL fine. The server running 0.69, however, leaves out the xmlns attribute on elements even when I try forcing it which results in it not being able to find their xsi:type in the namespace(from what I understand, SOAP is kind of weird). I cannot change the version of SOAP::Lite installed, it is out of the question. Here is the output from version 0.60: code:
code:
|
# ? Aug 19, 2008 20:24 |
|
This is going to be a little abstract, forgive me... So I have an object that encapsulates a process, which would be seperated into steps.code:
The thing that's bothering me is that I'm exposing interfaces (of course not technically since this is Perl) and building all this test code and it's making my class look ugly. Then an idea dawned on me. What if I just put all of the test methods and checks and what not into another module, a module that will have access to all the innards of this process class and can poke and prod at it freely. I figure that way the main class can have the appearance of looking clean while I'm still able test its insides in an encapsulated way. Thoughts? It's just that it's difficult and annoying to test this module because it's heavily data driven and there's a lot of data (20min, 4M rows). Edit: I was thinking about this more, and what about code:
|
# ? Aug 20, 2008 22:23 |
|
Triple Tech posted:
I would write separate tests to cover those individual methods (boom/blam/kerplow), including edge cases. Compare object state before/after running the method as part of the test if that's required. Devel::Cover helps and makes writing mundane tests rewarding for some reason. If I need a method that only is useful for running unit tests, I put it with the tests and never in the module, but that's just personal preference of course. quote:Edit: I was thinking about this more, and what about It sounds like maybe you want mock objects? Check out Test::MockObject.
|
# ? Aug 20, 2008 23:42 |
|
What's the syntax for POSTing a multiple SELECT input via LWP::UserAgent? Say I have a form like: code:
code:
|
# ? Aug 22, 2008 22:18 |
|
SubG posted:What's the syntax for POSTing a multiple SELECT input via LWP::UserAgent? If I remember correctly you have to submit foozle=>foo and foozle=>bar together. wait, that doesn't work here... try using an array instead of a hash: $ua->post('http://some_url',[foozle=>'foo', foozle=>'bar']); heeen fucked around with this message at 23:51 on Aug 22, 2008 |
# ? Aug 22, 2008 23:43 |
|
heeen posted:If I remember correctly you have to submit foozle=>foo and foozle=>bar together. I think this works. I tried it on the problem I'm actually working on and it didn't work, but then I tried it on my toy test page and it appears to work. So I think that's the correct answer and I just have to figure out what else is going on in the real world page. Thanks. SubG fucked around with this message at 00:25 on Aug 23, 2008 |
# ? Aug 23, 2008 00:09 |
|
Is there any way to have a method detect the context it is being called in (list or scalar)? Right now I am returning a ton of arrayrefs in a module I am working on, but would like to return a list in list context. DBIx::Class seems to do this with it's ResultSets but I can't seem to see how. Ideally it could do this: code:
code:
leedo fucked around with this message at 01:20 on Aug 27, 2008 |
# ? Aug 27, 2008 01:18 |
|
leedo posted:edit: annnnd I quickly answered my own question with Just an obscure word of warning (since this somewhat unlikely to crop up for most people) but man did it ruin my day once: "list context" can crop up when you aren't always thinking about it, and due to perl flattening lists when you're not looking this can have interesting results. For example: code:
code:
|
# ? Aug 27, 2008 01:49 |
|
I've never been much of a Perl expert, but what's the philosophical reason behind Perl flattening lists?
|
# ? Aug 27, 2008 03:12 |
|
more falafel please posted:I've never been much of a Perl expert, but what's the philosophical reason behind Perl flattening lists? I think it was just a mistake. I am sure you can find Larry Wall talking about it somewhere on the net.
|
# ? Aug 27, 2008 03:40 |
|
|
# ? May 21, 2024 16:04 |
|
It's a bit late so maybe I'm misunderstanding the discussion or the way it works, but to comment on the above code, => is just an alias for a comma. So when you declare a a hash, if you have (), it's essentially not putting an item in there. In the above example:code:
my %hash = ('foo', 1, 'bar', 'baz', 2); You're placing an empty array as a value, so it's compiled as essentially just nothing, and so it offsets all the key/value pairs in the hash.
|
# ? Aug 27, 2008 06:53 |