|
IO::Tty::Constant is automatically generated when you install IO::Tty. Oops. IO-Tty's Makefile.PL has some doc. You would need to include some sort of install step after all, unless all of these systems are identical and you can just include the autogenerated IO::Tty::Constant. That Bundle::Expect module doesn't actually contain anything. Bundle:: modules just list the names of other modules. An example of a useful Bundle (unlike Bundle::Expect) is Bundle::CPAN, which lists of bunch of modules that cpan can use to be generally better.
|
# ? Mar 4, 2009 00:56 |
|
|
# ? Apr 26, 2024 15:49 |
|
Probably a hyper-dumb question, but anyway. I'm converting a really old Perl app to PHP. I know next to nothing about Perl, but nevertheless everything was coming along smoothly until this line:code:
Edit: here's the whole sub, for context: code:
Tad Naff fucked around with this message at 08:15 on Mar 4, 2009 |
# ? Mar 4, 2009 05:30 |
|
Kind of a guess but $a holds a hash ref and whatever is in $lea will be put into $a with the key of '01'code:
|
# ? Mar 4, 2009 07:31 |
|
FeloniousDrunk posted:
Read the perlvar(1) documentation under $;.
|
# ? Mar 4, 2009 17:27 |
|
My boss is asking me to present on the most modernest poo poo, as suggestions for a new project. Given a fresh start, I'm thinking at bare minimum Moose (I know this makes Sartak happy) and Catalyst. I guess we're missing an ORM. DBIx::Class, maybe? Thoughts?
Triple Tech fucked around with this message at 20:25 on Mar 4, 2009 |
# ? Mar 4, 2009 17:30 |
|
Yeah, use DBIx::Class. There are other options (Fey::ORM, KiokuDB) but I don't think they're ready for general use yet.
|
# ? Mar 4, 2009 19:41 |
|
I've come to love Rose::DB over the past few months.
|
# ? Mar 4, 2009 20:01 |
|
There Will Be Penalty posted:Read the perlvar(1) documentation under $;. Got it. code:
is php:<? $a['000'][1]=$lea; ?>
|
# ? Mar 4, 2009 22:12 |
|
The wheels have been set in motion. I recommended DBIx::Class, Moose, Catalyst, and HTML::Mason.
|
# ? Mar 5, 2009 20:50 |
|
Building Rakudo (Perl 6 on Parrot) from scratch is now four steps:code:
Try it out!
|
# ? Mar 7, 2009 23:51 |
|
I'm starting a new project at work and I am looking for a web framework with a more lightweight install than Catalyst. I have a lot of experience with Catalyst, and it would actually work really well for this, but I'm afraid the massive list of CPAN dependencies will scare away the higher-ups. I'm looking at CGI::Application right now. I have a rather large DBIx::Class schema, so it is nice that it can be used as a mod_perl handler (presumably not reloading the schema on each request.) Any other suggestions? The trend around here has been to roll their own frameworks, but hopefully I can steer them in the direction of Catalyst eventually. edit: on second thought, gently caress it, all the Catalyst modules I need are in Debian already so the install is not going to be painful. leedo fucked around with this message at 02:09 on Apr 21, 2009 |
# ? Mar 13, 2009 15:14 |
|
YAPC tickets are on sale at a big discount this week. I picked some up, though I'm not 100% sure I can make it. At the very least it is a decent donation. http://yapc10.org/yn2009/
|
# ? Mar 16, 2009 01:47 |
|
First off, I'll admit for not searching, cuz, well, search is just temporarily down. I am not much of a perl person, I'm just starting out. I am trying to write a routine in a perl script to parse an XML file. The XML is basically like this: code:
What I need to be able to do, in "psuedocode": for each <LoadProfileEventType> where <Status> = YES print <NAME> And I have no idea how to go about doing this. I'm using XML::Simple to read the xml data.
|
# ? Mar 17, 2009 03:48 |
|
nitrogen posted:And I have no idea how to go about doing this. code:
|
# ? Mar 17, 2009 05:11 |
|
That's exactly it. Thanks. I was doing the bits for nested tags in XML::Simple incorrectly.
|
# ? Mar 17, 2009 05:45 |
|
Speaking of XML, I can't figure out how to retrieve the correct data of the original reference from another reference. XML: code:
code:
code:
code:
wolffenstein fucked around with this message at 23:59 on Mar 17, 2009 |
# ? Mar 17, 2009 19:34 |
|
Use Data:: Dumper to dump out the contents of $xml->{localLogDirectory} to see why it's coming up as a Hash.
|
# ? Mar 17, 2009 20:37 |
|
Beardless Woman posted:Use Data:: Dumper to dump out the contents of $xml->{localLogDirectory} to see why it's coming up as a Hash. I don't think localLogDirectory is coming up as a hash. It looks like that's getting expanded to "/srv/stats/log". It's the next variable in the string, $server, that seems to be the hash reference. wolffenstein, are you sure that the corrected code that you posted still produces the wrong output? It looks like the incorrect version that you first posted would be exactly the sort of mistake that would produce the bad output in question. If your corrected version's still causing problems, Data::Dumper's the way to go as Beardless Woman suggested. I'd recommend doing the dump on $serverRef to get the full picture. Erasmus Darwin fucked around with this message at 21:18 on Mar 17, 2009 |
# ? Mar 17, 2009 21:05 |
|
I didn't make clear the second perl snippet works as intended. Thanks for your help.
|
# ? Mar 18, 2009 00:01 |
|
Moose question for Sartak. Let's say I have a DESTROY that's paired with a side effect during the object's construction. In traditional Perl, if the side effect fails, the object doesn't have to be constructed, and DESTROY isn't called later. But in Moose, if I delegate the side effect to the BUILDer, it's possible that the object is constructed in Perl space but BUILD can still fail. When Perl tears everything down, it calls on a mismatched DESTROY. Is this what DEMOLISH is for? I just tested it and die'ing from BUILD still triggers DEMOLISH. I would have thought DEMOLISH would be paired with a successful BUILD. use Please::Advise; Edit: Hrmm... I'm reading the Moose source and I guess since DESTROY is used BY Moose, I need to make a destructor in Moose-space, they're asking me to use DEMOLISH instead, which is fine. But I don't think you're taking into account this mismatched BUILD-DEMOLISH scenario. Thoughts? Triple Tech fucked around with this message at 22:54 on Mar 19, 2009 |
# ? Mar 19, 2009 22:46 |
|
DEMOLISH is like BUILD in that it is called for each class in your hierarchy. You don't need to worry about calling the right "next" method (which can be weird under multiple inheritance). Moose takes control of the DESTROY method. Moose's DESTROY calls DEMOLISH on every class in your hierarchy, just like Moose's new calls BUILD on every class in your hierarchy. These two special methods result in shorter (and more correct!) code. There are two ways to fix your design issue. You can add an attribute to indicate whether you successfully initialized, or you can do your initialization before new. code:
The other option is: code:
The former kind of sucks in that it adds an attribute to your class, but oh well. Filburt Shellbach fucked around with this message at 23:50 on Mar 19, 2009 |
# ? Mar 19, 2009 23:47 |
|
Hrm, I was more expecting you to say that Moose was designed wrong! I mean, philosophically, is an object considered complete only after BUILD? Or is it kinda superfluous and a Perl-object is good enough for a Moose object? Why wouldn't you check that BUILD was successful before deciding to DEMOLISH? I guess if something was partially built you'd still want a thorough destructor... Ehh, I dunno.
|
# ? Mar 19, 2009 23:56 |
|
We try to avoid making those kinds of assumptions about what you are doing. When there are multiple valid options, it's sometimes nice to let the user decide. I guess part of it is also that exceptions in BUILD are weird to begin with.
|
# ? Mar 19, 2009 23:58 |
|
I'm having trouble with get and post data in perl. Previously I was extracting arguments using the CGI module, as in $cgi->param($key). That was working fine with just get arguments, but I found out that if I had both post and get arguments it would only find the post args. So I did some research and made a function that did it manually, but I ran into a problem with getting post data. All the information I found said to use read(STDIN, $request, $ENV{'CONTENT_LENGTH'}), but it fails every time. So I guess I have three questions. Is there any way to get the CGI module to fetch both get and post arguments? And if not, what's wrong the method I'm using to extract post data manually? Lastly, will I even be able to grab both get and post data this way? I was assuming I'd be able to concatenate the post and get data and then process them normally.
|
# ? Mar 20, 2009 21:38 |
|
mit_senf posted:I'm having trouble with get and post data in perl. Previously I was extracting arguments using the CGI module, as in $cgi->param($key). That was working fine with just get arguments, but I found out that if I had both post and get arguments it would only find the post args. http://perldoc.perl.org/CGI.html#MIXING-POST-AND-URL-PARAMETERS
|
# ? Mar 20, 2009 23:39 |
|
Land Mime posted:http://perldoc.perl.org/CGI.html#MIXING-POST-AND-URL-PARAMETERS Thanks
|
# ? Mar 21, 2009 00:17 |
|
edit: am moron accidentally pressed tab + space, still writing this now.. far out. I wrote a module based on JSON::RPC to publish some json encoded data. It originally had a layout like this: code:
I don't quite understand what the problem is because I don't fully get the interactions between apache and mod_perl, but how I should deal with this? adante fucked around with this message at 18:58 on Mar 22, 2009 |
# ? Mar 22, 2009 18:26 |
|
code:
code:
|
# ? Mar 22, 2009 18:47 |
|
I didn't see an actual question there, but you REALLY want to learn how to use push and pop. Your use of stuff like $i and $j is just atrocious.
|
# ? Mar 22, 2009 18:49 |
|
So if I wanted to add a new virtual host to the server, I would push a hash with the host's information into the the hash reference at the {server}{host} level? And yes, I admit using incremental counters in a foreach loop is dumb as hell.
|
# ? Mar 22, 2009 18:53 |
|
adante posted:Unfortunately it starts throwing (not in any particularly systematic manner, sometimes it does and sometimes it doesn't) this sort of error. At the moment you're creating your $dbh at compile time, since the instantiation takes place when the package is pulled in by mod_perl. If you create it at run-time closer to when it's needed, as opposed to at startup, the errors should stop occurring. You may still cache the handle between requests, however you need to make sure you connect after the thread itself is created (otherwise it will be shared between threads, and blow up when you use it). The easiest way would be to make a get_dbh() function that connects the first time it's called, and just returns the existing handle every subsequent time. Mario Incandenza fucked around with this message at 21:32 on Mar 22, 2009 |
# ? Mar 22, 2009 21:30 |
|
Sometimes, because perl tries to be so flexible, I'll get a horrible idea and just see if it works. I have a nested datastructure, and wanted to know if a list -- which would always exist and have at least one element -- would have more than one element in it. The "sane" expression that I settled on is: code:
code:
|
# ? Mar 22, 2009 23:51 |
|
Just because you can doesn't mean you should. Why not:code:
|
# ? Mar 23, 2009 07:24 |
|
atomicstack posted:http://search.cpan.org/~timb/DBI/DBI.pm#Threads_and_Thread_Safety What's best practice? I have now changed it to something like: package MyPackage; my $dbh = null; sub getdbh { $dbh = DBI->connect(...) unless $dbh; return $dbh; } sub foo : Public { my ($s, $x) = @_; my $dbh = getdbh(); $dbh->do(...); } This seems clunky and somewhat annoying to have to getdbh() in every call. I was reading the mod_perl manual and it suggests using the PerlRequire directive to use a file to startup - the next page uses Apache:BI. But I've been told by others that Apache:BI is evil. I have no idea about this, can someone give me pointers on what, if anything, is best practice?
|
# ? Mar 24, 2009 22:30 |
|
I'm not sure if this is the right place to ask, but can anyone help me with a problem buttbot is giving me? Buttbot is goon made apparently http://code.google.com/p/buttbot/ Buttbot throws and error when it attempts to buttify something. The error is code:
|
# ? Mar 27, 2009 01:47 |
|
What revision of Buttbot do you have? And do you have TeX::Hyphen installed?
|
# ? Mar 27, 2009 01:51 |
|
I have r93 and TeX::Hypen is in my lib folder. e: doing "perl -e "use TeX::Hyphen"" works fine e2: i overwrote my TeX folder with the same files and now the bot works hitze fucked around with this message at 02:27 on Mar 27, 2009 |
# ? Mar 27, 2009 01:55 |
|
hitze posted:I have r93 and TeX::Hypen is in my lib folder. Kind of pointless to mention it now, but you can use a module from the command line with perl -MTex::Hyphen
|
# ? Mar 27, 2009 13:52 |
|
Fenderbender posted:Kind of pointless to mention it now, but you can use a module from the command line with perl -MTex::Hyphen Well, he would have to have a shallow execute, like perl -MTeX::Hyphen -e 1.
|
# ? Mar 27, 2009 14:36 |
|
|
# ? Apr 26, 2024 15:49 |
|
Just started using Perl this week, so excuse any blatant stupidity please. I was wondering how I could read from a SQL db to an array. This is my code so far: code:
Also: will the last line of code effectively fill the array $rawstats with all data from the query? It's important here that the data remain in the order as read by the SQL statement.
|
# ? Mar 27, 2009 17:16 |