|
Sartak posted:It'll be my first YAPC, so I can't say for sure. But I am very excited about it. There are so many talks I want to see and people I want to meet. You should definitely come by. It's only $100. I think you'll get your money's worth. i noticed that they still have a few Perl6 sessions in the program. i mean, for christs sake, who the gently caress still cares about it? its been 8 years now!
|
#
?
May 25, 2008 18:44
|
|
|
|
| # ? May 17, 2024 17:11 |
|
|
YAPC looks freaking amazing I wish I could attend it.German Joey posted:i noticed that they still have a few Perl6 sessions in the program. i mean, for christs sake, who the gently caress still cares about it? its been 8 years now!  One day it'll be out. Actually, it seems perl 6 is really picking up these days. They've gotten a nice donation that should help get things done faster, and apparently theres more people interested in sinking some money into it. I'm also considering helping develop perl6 (if I even can), I'm just having trouble wrapping my head around it. I guess that happens when you try to join a gigantic half-finished project.
|
|
#
?
May 29, 2008 04:42
|
|
|
TiMBuS posted:One day it'll be out. /me lights a candle at his alter of Larry and chants the sacred runes $@%* $@&* $@%* ...
|
|
#
?
Jun 3, 2008 14:09
|
|
|
German Joey posted:i noticed that they still have a few Perl6 sessions in the program. i mean, for christs sake, who the gently caress still cares about it? its been 8 years now! One of my coworkers was on the original Topaz Perl 6 project and said that development changed a lot since then - they were making good progress and had a team that fit well together, but other influences changed things and I guess they scrapped a lot of work. I unfortunately don't know any specifics.
|
|
#
?
Jun 3, 2008 19:47
|
|
|
I'm using perl 5.8.8 and want to pull data from the capture buffer using variable variables. Like this:code:code:code:Am I missing something fundamental?
|
|
#
?
Jun 3, 2008 23:01
|
|
|
Cheesus posted:Am I missing something fundamental? If you can find a way to do what you're trying to do without turning off strict refs for that block, then it's a bug and you should file a report. This is exactly what strict refs is supposed to prevent. You are aware that if you do @foo = $bar =~ m/(abc)def(ghi)/ then you get @foo = ('abc', 'ghi'), right? That would let you do this with array indexes instead of soft references.
|
|
#
?
Jun 3, 2008 23:09
|
|
|
Jesus, that's just what I wanted. Thanks. Even looking at the perlre page again I can't see where they say this works.
|
|
#
?
Jun 3, 2008 23:48
|
|
|
Look for something like the regexp operator that starts with an m returns the captured matches in list context. Also, what is it that you're trying to do? Your regexp smells funny. http://perldoc.perl.org/perlop.html#Regexp-Quote-Like-Operators "If the /g option is not used, m// in list context returns a list consisting of the subexpressions matched by the parentheses in the pattern" Triple Tech fucked around with this message at 02:54 on Jun 4, 2008 |
|
#
?
Jun 4, 2008 02:48
|
|
|
ashgromnies posted:One of my coworkers was on the original Topaz Perl 6 project and said that development changed a lot since then - they were making good progress and had a team that fit well together, but other influences changed things and I guess they scrapped a lot of work. Topaz perl was around before Larry began the perl 6 spec, so it didn't have much going for it.
|
|
#
?
Jun 4, 2008 04:24
|
|
|
ashgromnies posted:One of my coworkers was on the original Topaz Perl 6 project and said that development changed a lot since then - they were making good progress and had a team that fit well together, but other influences changed things and I guess they scrapped a lot of work. oh man, topaz, i remember that. that was chip salzenburg's thing, wasn't it? last i heard he was locked up in jail or somesuch. i guess the bigshots in perl community have never had much luck with the law. if i remember right, topaz was just a rewrite of the perl 5 core in C++. the motivation was that new language features were too hard to implement due to the immense complexity of the perl 5 core. i just looked it up and that was NINE years ago. yeesh! i was just talking about the rewrite done with parrot. topaz was scrapped for parrot because larry and the community wanted a language rewrite in addition to an implementation rewrite. i remember working quite a bit on the first implementation of perl 6 on parrot for a few years - the one written in perl 5 that started after a half a dozen apocalypses or so had come out. it, unfortunately, collapsed due to its immense weight and the lack of developers holding it together. oh well. i also remember this book: Perl 6 and Parrot Essentials. i tech-reviewed both editions. i remember being so excited when it first came out! i thought that the book would drum up enough excitement and momentum in the community to finish the project within two years! the second edition came out four years ago.
|
|
#
?
Jun 4, 2008 09:22
|
|
|
ShoulderDaemon posted:You are aware that if you do @foo = $bar =~ m/(abc)def(ghi)/ then you get @foo = ('abc', 'ghi'), right? That would let you do this with array indexes instead of soft references. This is a good solution. You could define constants and access your resulting array with them similar to how POE works (eg, $blah=$matched[MATCHED_NAME]). You can also do ( $match1, $match2 ) = $bar =~ m/(abc)def(ghi)/ to directly set the variables (just like anything else that returns an array), or even ( $hash{blah}, $hash{blah2} ) = $bar =~ m/(abc)def(ghi)/ if you really want to use a hash.
|
|
#
?
Jun 4, 2008 12:36
|
|
|
I have a question about mod_perl persistence. I'm working with some (horrible but readable) legacy code and at the core we have this main module that handles database connection and templating, etc. So we have this "core.pm" and inside there is a subroutine called "get_logo_data" which checks the (shared) file server for the existence of a logo and if so, returns the filename. The way this has been made effecient is to have this a variable the top of the Core package: our %logo_data; and then inside the subroutine to fetch logo data store the result of the request into %logo_data. The idea being that for the duration of the process this variable will act as a cache between page requests. The senior guy here just ran me through a simple test to show that it definitely remembers the contents of the variable through multiple page requests and explained on our high traffic environment this could be saving anything from 10 to 20% of file server hits. The idea of this "our" variable having that kind of benefit seems retarded to me. Not only that, I'm trying to move this code in a more OOP direction, and I need to at least try and replicate this idea of cache. I'm not allowed to modify the publishing system to just set a database value of "has_logo" or anything sensible like that so for now I need to deal with hitting the file server and trying to cache this somehow. I hope I explained that right, because frankly the entire thing just seems retarded to me. Can anyone who's had to deal with this in the past point me in the direction of a better way to cache those file server hits?
|
|
#
?
Jun 6, 2008 12:06
|
|
|
Div posted:I hope I explained that right, because frankly the entire thing just seems retarded to me. Can anyone who's had to deal with this in the past point me in the direction of a better way to cache those file server hits? While it's not the greatest, I'm not sure what your problem is with the scheme beyond it being "retarded". Are you having problems with logo updates not propagating quickly enough since cache persistence is arbitrarily tied to the life of the mod_perl process? Is there so much logo data being cached that it's causing problems with the size of the mod_perl and/or the system memory? Edit: One more proper way would be to use Memoize to memoize the logo look-up function. However, at its core, Memoize would be doing the same thing that your code already does with just a lot of extra packaging and unnecessary flexibility. Erasmus Darwin fucked around with this message at 16:16 on Jun 6, 2008 |
|
#
?
Jun 6, 2008 15:00
|
|
|
TiMBuS posted:YAPC looks freaking amazing I wish I could attend it. Slight derail. The one thing I'm looking forward to the most is the complete revamp of the Regular Expression syntax, which is radically different in a lot of ways than the current Perl 5 Regular Expression syntax: http://dev.perl.org/perl6/doc/design/apo/A05.html. For example, '(...)' still denotes a capturing group, however, '[...]' is for non-capturing instead of the ungainly '(?:...)'. This change means that character classes are a completely different beast altogether. 
|
|
#
?
Jun 7, 2008 06:57
|
|
|
KillerTwinkie posted:Slight derail. the new regular expressions were definitely one of my favorite planned features of Perl 6 too. but minor syntactical changes aren't even the half of it! the best feature by far were "rules", which allow the programmer to build up complicated expressions in an object oriented way (inspired by Parse::RecDescent of course). i wrote up an article about em a few weeks after Apocalypse 5 came out (i.e. 6 years ago, LOL) that compares perl5 to perl6 in an example of parsing javascript code, if you're interested in learning more. http://www.perlmonks.org/?node_id=179555
|
|
#
?
Jun 7, 2008 08:34
|
|
|
So I inherited this Perl program where the designer has done everything possible wrong, including obscure syntax rules and complicated global data structures that all sub-functions modify directly. I'm rewriting it to make things sane for me, but I can't decipher some of it. For instance, can someone help me unwind these kinds of variables into english or less code noise? ${$$g_mapTransform{$frame}}[0] ${$$xaPlate[$iRow][$iCol]}{'gt'} Also, what. return (@g_errors == 0);
|
|
#
?
Jun 9, 2008 22:51
|
|
|
NotShadowStar posted:So I inherited this Perl program where the designer has done everything possible wrong, including obscure syntax rules and complicated global data structures that all sub-functions modify directly. I'm rewriting it to make things sane for me, but I can't decipher some of it. For instance, can someone help me unwind these kinds of variables into english or less code noise? perl -MO=Deparse let's you input a phrase (or use a script as an argument) and it will give you back a rough (not 100% perfect) mechanical equivalent to what you typed out, with more parenthesis and what not, making the underlying intentions more clear. The first part I'm not sure of but the second part is "return true if the number of errors (given by the length of the stack) is zero" or "return good if no errors".
|
|
#
?
Jun 9, 2008 22:55
|
|
|
Interesting idea butcode:
|
|
#
?
Jun 9, 2008 23:02
|
|
|
NotShadowStar posted:${$$g_mapTransform{$frame}}[0] $$g_mapTransform{$frame} is an array ref. $g_mapTransform is a hash ref. $$xaPlate[$iRow][$iCol] is a hash ref. $xaPlate[$iRow] is an array ref. $xaPlate is an array ref (an abstracted two dimensional array). You can also use print Data::Dumper $structure.
|
|
#
?
Jun 9, 2008 23:02
|
|
|
You basically have to look at this like an onion. The first sigils have braces and a lookup, which is nice, so you know that first structure, so you can drop them. The next outer sigil is attached to the next outer lookup. It helps if you put braces between that sigil and the lookup. So... $$apple[lookup] becomes ${$apple}[lookup] where the first sigil denotes context, the middle part denotes complex scalar name, and the last part is the lookup paired with the first sigil. So from this, we can infer that $apple is being treated like an index lookup of an array which is written in scalar context. So, removing the context sigil and the lookup, the natural state of the variable is @$apple making it an array ref. Blah.
|
|
#
?
Jun 9, 2008 23:07
|
|
|
NotShadowStar posted:So I inherited this Perl program where the designer has done everything possible wrong, including obscure syntax rules and complicated global data structures that all sub-functions modify directly. I'm rewriting it to make things sane for me, but I can't decipher some of it. For instance, can someone help me unwind these kinds of variables into english or less code noise? As for how to rewrite those to be more "clear", I would rewrite this: "${$$g_mapTransform{$frame}}[0]" as this: "$g_mapTransform->{$frame}->[0]" and "${$$xaPlate[$iRow][$iCol]}{'gt'}" as "$xaPlate->[$iRow]->[$iCol]->{'gt'}".
|
|
#
?
Jun 10, 2008 00:31
|
|
|
After the first deref, you don't need subsequent derefers. $a->{lookup}->[lookup] == $a->{lookup}[lookup]
|
|
#
?
Jun 10, 2008 00:55
|
|
|
Triple Tech posted:You can also use print Data::Dumper $structure. Triple Tech nailed it on the head: Data::Dumper is your super number 1 friend: code:
|
|
#
?
Jun 10, 2008 01:30
|
|
|
Thanks for the advice, but the app is old-school CGI based, another circle of hell. Since the thing is so incredibly monolithic, I did hack in some debugging and logging support to files when changing minor things, but the whole app is references to references to references to GLOBAL data structures called upon by different subroutines at different times, depending on the CGI entry point. I know what goes in and what's supposed to come out so I don't really care about how it's doing most of it, I'm redoing it all in my own way, but there are a few instances where I need to see how some variables are referenced or where they may possibly be coming from so I can figure out the math behind it.
|
|
#
?
Jun 10, 2008 02:01
|
|
|
Triple Tech posted:After the first deref, you don't need subsequent derefers. Sure, they might not be necessary, but I like keeping them, stylistically. I try to keep everything consistent, so if I use -> for dereferencing in one place I should use it everywhere in a particular file or project. Also, I remember old versions of ActivePerl didn't like hash references more than two or three levels deep, unless you used arrows, so that's how I got in the habit. Still, you're right, it's just a matter of preference.
|
|
#
?
Jun 10, 2008 07:20
|
|
|
Triple Tech posted:After the first deref, you don't need subsequent derefers. That's just a syntactic nicety. Same with how you usually don't need to include the quotes around a literal hash-key (e.g. $test->{'key'} vs $test->{key}). However, I've always preferred to keep dereferences 'explicit' by using '->'. I like the arrows  Edit: How the gently caress did I not spot I'd been 100%, thoroughly beaten?! Ninja Rope 
|
|
#
?
Jun 10, 2008 08:28
|
|
|
magimix posted:That's just a syntactic nicety. Same with how you usually don't need to include the quotes around a literal hash-key (e.g. $test->{'key'} vs $test->{key}). However, I've always preferred to keep dereferences 'explicit' by using '->'. I like the arrows syntactic niceties go a long way to keep your code from looking like line noise, especially when you're working with a structure thats more than a few levels deep.
|
|
#
?
Jun 10, 2008 08:45
|
|
|
German Joey posted:syntactic niceties go a long way to keep your code from looking like line noise, especially when you're working with a structure thats more than a few levels deep. Sounds like we've got a new doctrinal conflict on our hands! I was getting bored of tabs-vs-spaces, braces-on-same-line-vs-on-new-line, and suchlike anyway.  
|
|
#
?
Jun 10, 2008 09:01
|
|
|
I think I grossly misunderstood one of MJD's slides where he said "less punctuation". I've been a diehard fan of that mantra ever since, you know, I misunderstood it. =) Where possible, at the sacrifice of possibly performance but never clarity (does the reader know all of the operator precedence without looking?), nearly all my code aims for less punctuation. Put succinctly, as previously mentioned, less punctuationi helps fight against that "line noise" stigma that Perl has. I'm thoroughly happy at how my new code has turned out with this mantra.
|
|
#
?
Jun 10, 2008 12:13
|
|
|
I'm having a problem with Perl. I've got a script using Archive::Zip. RedHat Issued a patch today for RHEL 4 (yes it is old, but it is what I've got to work with). http://rhn.redhat.com/errata/RHSA-2008-0522.html After the upgrade a script that worked now fails. code:So within CPAN I first upgraded CPAN, then did "test Archive::Zip" and all the related packages I could find (Scalar::Util, IO::Compress::Base, Compress::Raw::Zlib). CPAN now says all the things tested successfully, but the script is still not working. Anyone got any ideas on what to try/look for?
|
|
#
?
Jun 12, 2008 01:02
|
|
|
How about a straight up use? perl -MArchive::Zip -e 1
|
|
#
?
Jun 12, 2008 01:08
|
|
|
6174 posted:Scalar::Util is somehow screwed up and the answer is to reinstall the module in CPAN I'll expand on this, because it's a lovely problem that's worth knowing about. Some vendors (notably, RedHat, though maybe they've since fixed this) ship a broken Scalar::Util. In particular, weaken just does not work. This sucks because weaken is absolutely necessary for working with circular data structures. Module authors: depend on Task::Weaken. It will test weaken support explicitly and do whatever it can to help the situation, including letting the user that his Scalar::Util is broken. Thankfully it's not as big a deal nowadays as Scalar::Util is in the core distribution as of 5.8. Filburt Shellbach fucked around with this message at 01:22 on Jun 12, 2008 |
|
#
?
Jun 12, 2008 01:20
|
|
|
Triple Tech posted:How about a straight up use? perl -MArchive::Zip -e 1 code:Sartak posted:More reasons why I'm frustrated with RHEL I do have 5.8.5 on the box. Is the answer then to not let RedHat manage Perl? (ie remove the rpm and grab Perl and do a standard make; make install; )
|
|
#
?
Jun 12, 2008 01:52
|
|
|
I'm working on a project to break logfile data into various archival formats. My co-worker is convinced that regular expressions are too slow and is convinced there's a way to break such entries down using a BNF-like syntax into either an array or hash. Without using regular expressions. Is there such a CPAN module to do this? I've tried searching for "BNF" and also things like Yacc/Lex but I'm pretty ignorant about how those actually work. The few modules I've come across talk about generating C++ code which isn't what I want. Or is there something else I should be looking for?
|
|
#
?
Jun 12, 2008 03:27
|
|
|
Look at Parse::RecDescent on CPAN.
|
|
#
?
Jun 12, 2008 03:37
|
|
|
6174 posted:I do have 5.8.5 on the box. Is the answer then to not let RedHat manage Perl? (ie remove the rpm and grab Perl and do a standard make; make install; ) I just finished manually compiling and installing 5.8.8 and everything works again. Stupid RedHat.
|
|
#
?
Jun 12, 2008 18:58
|
|
|
Cheesus posted:My co-worker is convinced that regular expressions are too slow Are they really? Are you sure you aren't wasting development time by looking this up? Are regexps really the bottleneck in your process? If you've said Yes to any of these questions, Also, if the data is fixed width, consider unpack?
|
|
#
?
Jun 12, 2008 19:17
|
|
|
6174 posted:I just finished manually compiling and installing 5.8.8 and everything works again. Stupid RedHat. This... on a production server that SOMEHOW had up2date running with Perl not excluded.  Plus ~20 minutes of frantic perl -cw / CPAN sessions.
|
|
#
?
Jun 13, 2008 02:19
|
|
|
Triple Tech posted:Are they really? Are you sure you aren't wasting development time by looking this up? Are regexps really the bottleneck in your process? In fact, I'm suspicious and will be evalating the performance against some of these modules. The module that Ninja Rope mentions itself mentions performance concerns in the reviews (however one of them mentioned modifying another package to act nearly the same and possibly with better performance).
|
|
#
?
Jun 13, 2008 13:45
|
|
|
|
| # ? May 17, 2024 17:11 |
|
|
Cheesus posted:I don't share his sentiment. i've used Parse::RecDescent for a few projects in the past and it certainly is true that it is has significant performance drawbacks. as a good example: the grammar we used for the perl6 prototype involved a 1000-line BNF grammar that needed plenty of embedded code. when using it to compile a program there was a 30 second startup delay penalty during which Parse::RecDescent converted the BNF into an executable format (that internally used regexes to tokenize the input). that was reasonable for us since our prototype was not aimed at performance but at greatly simplifying the process of parsing a phenomally complex input files. for simple files, such as a logfile, you should be fine using more ordinary methods. BNF parsing will be, in general, much slower than a regular expression (which will be in turn much slower than unpack). the more complicated a parsing method can handle, the slower it'll be. the main question i have for your coworker then is: why do you need something more powerful than a regex for parsing a loving log file? and why do you need something more efficient? how big is this file, in the gigabytes?
|
|
#
?
Jun 14, 2008 00:53
|
|