Re: [Boston.pm] getting perl interpreter object inside perl
On Wed, 2006-05-24 at 03:23 -0400, BORIS REITMAN wrote:
Hi,
Is some module like Devel::Peek that will give me
the address of the C-space perl interpreter object
that executing my perl script ?
I mean, I want to find out the perl intepreter address, inside the perl
script.
What part of it? You could use:
use Inline C = q{
void * get_thx_loc () {
dTHX;
return (void*)aTHX;
}
};
my $loc = get_thx_loc();
But I cannot imagine any sane world in which you want to do that!
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] LARGE MySQL Database
Steve Revilak wrote: Basically I am dealing with using, storing, and sorting a LOT of data in a mysql database. With all the data in the table it makes for 404.8 Million rows. In a backup sql file that makes just under 80GB. OK, so you're dealing with a tiny database. mysql select count(*) from the_log; +---+ | count(*) | +---+ | 449349136 | +---+ 1 row in set (0.00 sec) Real table name changed to protect the innocent. The row size is around 128 bytes. I have so few rows right now because I just purged 2005 data. I an using the InnoDB engine. Could be good, but probably a mistake. MyISAM is much more suited to large amounts of data. Unless you need transactional integrity on this particular data, I would dump InnoDB ASAP and go with MyISAM. If you *think* you need transactional integrity, consider the possibility that you might not, and that what you might actually need is transactional integrity on the smaller quantity of data that you have in other tables. Often such a large table represents some sort of external data such as a log file or a list of users which is either updated from an external source (logs) or is only inserted to most of the time (users). For both situations, there are better solutions than the overkill of InnoDB. If you haven't normalized the pants out of the table, that's probably a good place to start. Anything you can do to trim a few bytes off the row size will make a big difference in the size of the overall table. (Is this table part of a data warehouse?). Smaller data will always be faster than bigger data. I don't mean any offense, but I could not disagree more with ... well, every sentence. First off, normalization is the antithesis of performance, as it almost always results in more joins. It's the right thing to do in many cases, but think twice before normalizing the pants out of the table for performance. It won't be a win. The row size is ignorable, unless you've constructed your data and your indexes poorly. If you need to fetch every record, then of course, you want to have as little data as possible, but if you just need to fetch key records or compute summary information, then row size is not your most important concern by far. Smaller data vs. bigger data is orders of magnitude less important than less data vs. more data, and the way you reduce the AMOUNT of data is to use indexes wisely. This reduces the amount of data that any given query must interact with, rather than trying to reduce the data in the table. You can also, as one other person pointed out, use merge tables (a MyISAM feature) to break the data up, but with only 80GB of data, I would not worry about that just yet. Other things to look at: The tuning parameters for the database. Ideally, you want to be able to suck all of the indexes for your giant table into RAM. That means you need lots of RAM, and it also means that you need to hack the MySQL configs. There's a great book on MySQL tuning from O'Reilly that I suggest you check out. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] perl 5.8.3, perl/Tk 804.027, and 64 bit Redhat Enterprise 3 Update 5
On Fri, 2006-04-21 at 14:16 -0400, Greg London wrote: So, perl 5.8.8 is the latest version available. available from your vendor, or from CPAN? and we're having some problems. Such as? the first fix might be to try version 5.8.3 of perl, rather than the latest. Where the heck can you get older versions of perl off of CPAN? If you're running RHEL, you should not have to touch CPAN except to acquire modules that Red Hat hasn't packaged up. If you're going to compile from source, you'll want to get Red Hat's SRPM, install it and peruse the patch sets that they include to see which of them you will want to apply to the CPAN version yourself. I don't recommend this, as the folks at Red Hat, python-lovers though they be, tend to do a decent job on the integration front. Silly question: have you considered the GTK or KDE toolkit interfaces? They tend to be maintained a bit better. Of course, you may be maintaining a legacy application, in which case that advice won't help. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith We had some good machines, but they don't work no more. -Shriekback ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] may be OT: Heard of chkinstall, a utility to build RPMs ?
On Tue, 2005-12-06 at 15:10 -0800, Ranga Nathan wrote: I believe there is a utility to build RPMs from normal tar.gz distro. In order to keep things consistent, I would like to build an RPM of Nagios 2x beta for SuSE9 (intel). Of course, creating an RPM from a tar ball is a fairly simple operation even without such a tool. Spec files are easy to write, and once you do that, you place your tar ball into /usr/src/X/SOURCES (X=redhat on my system, but I'm sure SuSE puts it somewhere else). Then run rpmbuild -ba /usr/src/X/SPECS/yourpackage.spec and you get an SRPM and RPM(s). If you need guidance on what a spec file should contain, just grab the SRPM for any random package in your distribution, install it and look at its spec file. They're like a Makefile, but with a bit more regular structure. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith We had some good machines, but they don't work no more. -Shriekback ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Combinatorics (Permutations)
Ronald J Kimball wrote:
my @indices = (0) x $maxlen;
I have no idea why, because it's not more efficent or anything, but I
always find myself writing:
my @indices = map { 0 } 1..$maxlen;
The nice thing about it is that I tend to think of map even when I want
something very slightly different from a simple list on n items, and
that keeps me from writing wasteful foreach loops.
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] damian topic
On Tue, 2005-10-25 at 06:54 -0400, Tom Metro wrote: Combining the official, unofficial, and my votes, we have: 4 Small Miracles 3 Perl 6: The Sky Isn't Falling 1 Time::Space::Continuum 1 Perl 6 Update I'd vote for either of the p6 topics, which given the voting so far would seem to favor The Sky Isn't Falling. I'd really like to hear from him on his feelings about the Perl 6 state of the world. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] perl5.8.1 on Red Hat
On Fri, 2005-05-20 at 10:27, Ronald J Kimball wrote: I seem to recall that the perl5.8.1 that comes with Red Hat is not the same as the official release of perl5.8.1. Anyone know where I can find out more information about this? Well, for starters, you might want to narrow down what you mean by Red Hat (RHL, RHEL, Fedora, etc.); but no matter what you're running, you can always use the magic of RPM to find out what you want: [acquire SRPM for your version from ftp/apt/whatever you use] rpm -ivh perl[...]src.rpm less /usr/src/redhat/SPECS/perl.spec This will list the official perl tar-ball that comes from CPAN, and all of the individual patch files (which are now located in /usr/src/redhat/SOURCES) that would be applied if you were to build from this spec file. Red Hat never modifies the base source for a package, they just add patches to the SRPM which are applied when the RPM is built. There is also a changelog at the end of the file that details what was done to this package. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] perl5.8.1 on Red Hat
On Fri, 2005-05-20 at 14:10, Larry Underhill wrote: Worth noting that my perl version on RHEL 3.0 is 5.8.0 (with a pile o' patches -- makes sense). Haven't checked out RHEL 4 yet, but I would assume that they are running a more recent version since the Fedora Core 3 box I am typing this from uses perl 5.8.5. Oh, and the real way to answer your question is, what Aaron said. Well thanks ;-) Getting access to the RHEL SRPMs can be a bit tricky if you don't have a RHN account, so would recommend you pull the SRPM from a site like CentOS www.centos.org (RHEL clone less RH trademarks, etc.). Yep, the CentOS SRPM should at least be the same base. They do try to avoid changing things so that RHEN updates still work cleanly. Dunno for sure, but I think they have a special naming convention if they do change something. Red Hat never modifies the base source for a package, they just add patches to the SRPM which are applied when the RPM is built. There is also a changelog at the end of the file that details what was done to this package. What I seem to remember hearing is that the perl5.8.1 that Red Hat distributes is actually different from the official perl5.8.1. My understanding is that because 5.8.1 was not ready when Red Hat needed it, they took 5.8.0, added a bunch of the available patches, and packaged it as perl5.8.1. p5p subsequently released the real 5.8.1 with additional patches. That would be mildly shocking to me (they've done it, but only for something that they had major input on (gcc), which they don't with perl). What would be much more likely is that their distribution was based on an RC, but the only truly definitive resource is the SRPM, and I would literally fall out of my chair in shock if they so much as breathed on the tarball inside of it. They'll heap on patches for anything they fix until / unless it's accepted up-stream, but I've never seen them package a tar-ball that wasn't virgin. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Can you better this?
On Wed, 2005-05-11 at 15:24, Aaron Sherman wrote:
This smells like homework, but *shrug*
Then my mailer decided to play the role of the proverbial dog and eat
said homework ;-) If it does so again, I'll just leave well-enough
alone.
On Wed, 2005-05-11 at 14:59, John Tsangaris wrote:
I was asked to provide the 73 occurrence of a sequence of numbers,
with the numbers 12345. Each number can be used only once, and there
are a possible 120 combinations.
perl -le '$n=0;sub x{my($s,@l)[EMAIL PROTECTED];if (@l){for my
$l(@l){x($s.$l,grep{$_ ne [EMAIL PROTECTED])}}else{print ++$n,
,$s}}x(,1,2,3,4,5)'
That can be golfed if you feel like it, but I've stripped it down to the
essentials.
Oh, and a correction. There is only ONE combination. There are 120
PERMUTATIONS. Different.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: Serial Cables RE: [Boston.pm] OT(very):VT-100 Project
On Thu, 2005-04-21 at 10:55, Ricker, William wrote: A real working VT-100, that's a blast from the past. I hope it's actually a VT-102, that's the sweet spot iirc. I assume you've already found http://vt100.net/ . With a real VT-100, you can watch all the old Christmas Card animations [ http://artscene.textfiles.com/vt100/ ] -- I've seen Perl scripts that help some of these work again, but not all of 'em do. All you really need is something to slow them down (as most of them depend on baud rate at which you could move data to a vt). Some of them rely on other features that, for example, gnome-terminal does not support, but most of them work fine for me. Use the green-on-black pre-setting for best results in gnome-terminal. This tiny bit of Perl will slow them down for you: http://pleac.sourceforge.net/include/perl/ch01/slowcat That said, I'm not sure if the vt100 uses normal 25 or 9 pin serial ports, it's that old. It *is* that old. The VT100 used DB25 with proper DTE gender according to the original standard. (Modems are DCEs, computers and terminals are DTEs, by definition.) In fact, it was the VT100 which cemented the standard. Every 2-bit PC card maker wanted to embrace the standard with their own proprietary add-ons, but would discover that everyone was buying the other guy's serial cards because they had to work with VT100s and serial printers. This was in the days before time when IBM was still a big name in PCs, before they were again. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] sending a user to the middle of a page from a form post
On Tue, 2005-03-08 at 15:08, Tal Cohen wrote: I am not sure if this will work, but...Try embedding an anchor tag name into the path of the Perl CGI URL called in your FORM tag. Then, have the Perl-CGI script embed that same anchor tag into the resulting HTML document. What should happen is now when you call the CGI script, the browser will know to seek out that anchor tag. Yep, that's the way to go. Problem with POSTs, is *technically* it's illegal to re-direct from them, so you are not supposed to issue a new URL to go to. Thus, any anchor referenced must be in the original URL. Of course, you can violate the HTTP standard, but that's another barrel of apple juice. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl Popularity and Interview Questions
On Mon, 2005-03-07 at 01:51 -0500, James Freeman wrote: So this leads me to this scenario and a question, your manager has asked you to be part of the interview process for a new programmer position that involves Perl and he wants you to make sure this person knows their Perl. I use a technique that's very controversial at my company. Most people think I'm quizzing people for useless trivia, and they're 1/2 right. I fire a bunch of questions at you that look for the kinds of trivia that you pick up while writing Perl. Just as two examples, I like to use what is $_ as my first question. If you don't know that, then clearly you have only glanced off of Perl at best. We can move on. The last question is, What is 'A'|'B' (I got this from a Boston.pm member long ago). The correct answer depends on your knowing a bit of Perl trivia: how bit-vector ops work. If you know it, it's easy (65|66=67='C'). If you don't know it, that doesn't say anything about you as a Perl programmer, only provides one data-point. I look for someone who knows lots of little bits of trivia, indicating that they have spent lots of time with Perl. If you know more trivia than I do (I've yet to see that), then I would hire you on the spot. Side note: We recently hired someone who didn't know Perl very well, but on the above 'A'|'B' he worked out the correct answer purely by deducing how a language might treat that construct. THAT was far more impressive to me than KNOWING the answer. Let me also note that if someone KNOWS Perl, that doesn't mean they know how to WORK in Perl. Get code samples of real, working code! Other concerns: * Come up with questions that have simple answers, and can thus be asked by others who don't know Perl as well as you do. * Don't ask style questions (e.g. should you use $_ ?) You will find that people who disagree with you are often still very helpful * DO ask at least one inflammatory question (e.g. would you prefer to work in Python?) You don't care about the answer... you care about the TONE of the answer. Make sure you're not hiring a hot-head Perl fanatic (or any other flavor of fanatic for that matter). * Ask at least one probing question to determine how much they enjoy coding. Something like, what's your favorite personal project, works well. Good luck, but keep in mind I'm not giving away all my best tricks! ;-) ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl popularity and interview questions
On Mon, 2005-03-07 at 08:17 -0500, Greg London wrote:
3: What is printed when this script executes?
my %hash;
if($hash-{key1}-{key2})
{print Exists!;} else {print Doesnt exist}
print Dumper \%hash;
5: What is printed when this script executes?
package Dog;
sub Speak { print Dumper [EMAIL PROTECTED]; }
Dog-Speak('woof');
Bot answers are the same, nothing. I'd ask a followup question: What
if I used perl -MData::Dumper; to run it?
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl popularity and interview questions
On Mon, 2005-03-07 at 10:24, Palit, Nilanjan wrote: (b) nothing to do with Perl - just assess the person's attitude vs. your own team's dynamic. To me, this is much more important then the exact technical skill. Also nothing to do with the questions as posted. The answers were wrong, and I was trying to warn people who might try to use them of that. Can you imagine the outrage of someone who didn't get a job because they gave the RIGHT answer to a question?! That Greg seems to have revised his answers into a personality test does not change the fact that the original answers are wrong. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] Perl popularity and interview questions
On Mon, 2005-03-07 at 11:22, Palit, Nilanjan wrote: -Original Message- From: Greg London [mailto:[EMAIL PROTECTED] Sent: Monday, March 07, 2005 11:17 AM As for the triple-plus operator ;) I'd think perl would take x, do a ++ on it, get 2, and then do the +1 on it to get three. But oh well. just won't use that in my code. No. In Perl (or C), $x++ = use then increment, whereas ++$x = increment then use. Thus the expression will use the existing value of x (1) to compute the value of y then increment x itself. Correct. If you wanted obscure, you probably wanted: $y=$x+++-+1 Which is arguably not a useful feature, but still quite legal. Deparse is enlightening here, as you will notice that the last + is not represented (it's considered part of the number, and lost after tokenization), where the - is an actual operator (unary:-). This is why you can't reverse it: $y=$x+++ +-1 yields a very different deparse (you can't string all four + without whitespace because it will be read as ($x++)++, which is invalid. None of this addresses the value of obscurity in an interview (I think it has its place, but needs to be moderated). ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl popularity and interview questions
On Mon, 2005-03-07 at 11:36, Ronald J Kimball wrote:
$y = $x++ + 1;
is quite readable, and very clear in its intent if you know know what
postfix:++ and infix:+ do (and you'd better). You don't even have to
know precedence, as it is implied by the (now correct) use of
whitespace.
It's fairly readable (which is subjective anyway), but I don't think it is
clear in its intent. Since it is equivalent to C $y = ++$x when $x is
a number, I would be unsure why the programmer wrote it in the more
complicated way. Did they really mean to do that, or were they trying to
do something different and erred?
I would assume that there's a reason that they're not equivalent in this
specific context, but yes you're right in the general case they are the
same. Some people would not realize that right off the bat, though and
might just use this version as it's the first that comes to mind for
them.
As for not being the same... here's one example:
$ perl -le '$x=1/3;{use int; $y=$x+++1}print $y'
1
$ perl -le '$x=1/3;{use int; $y=++$x}print $y'
1.33
Enjoy.
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl Popularity and Interview Questions
On Mon, 2005-03-07 at 15:33 -0500, Uri Guttman wrote: AS == Aaron Sherman [EMAIL PROTECTED] writes: see what i do in File::Slurp. i wanted a single error handling sub but also to have the croak in there report back from the original call (say read_file). Tried that. Problem is File::Copy is the kind of thing that's going to be called often and fast, and there's nothing short of an eval that stops performance dead more than an subroutine call in Perl. Ah, Perl 6, where are you? Of course, now (many years later) XS support is much better, and I'm sure I could do an XS File::Copy that would eliminate the need for that goto ;-) it had was gotos and even then i structured my code as much as possible. i have never done spaghetti coding at any point in my career. maybe i have more innate understanding of logic than some but i always wonder how spaghetti coders think (or rather don't think! :). Well, that's the point. The language is the tool, not the programmer. You use the tool to perform the task at hand. If that means bending it in funny ways, then that's what you do. Gotos are the programming equivalent of duct tape. If you see duct tape, you know that there was a limitation in the tool or the tool-user that made the duct tape necessary. In this case, it was the tool, and in all these years, no one has ever re-written that chunk of code without gotos and without a performance or readability hit. Like I say, it'll be a (not so) fond memory once P6 takes over the world. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl Popularity and Interview Questions
On Tue, 2005-03-08 at 00:04 -0500, Uri Guttman wrote: AS == Aaron Sherman [EMAIL PROTECTED] writes: AS On Mon, 2005-03-07 at 15:33 -0500, Uri Guttman wrote: AS == Aaron Sherman [EMAIL PROTECTED] writes: see what i do in File::Slurp. i wanted a single error handling sub but also to have the croak in there report back from the original call (say read_file). AS Tried that. Problem is File::Copy is the kind of thing that's going to AS be called often and fast, and there's nothing short of an eval that AS stops performance dead more than an subroutine call in Perl. Ah, Perl 6, AS where are you? did you do magic goto? it shouldn't be slow at it doesn't touch the stack nor mung @_. I've tried that. It helps, but sub overhead is still deadly all on its own, even without stack manipulation. Annoyingly, now that I go try to test it to see if it's still the same, I find that goto foo breaks Benchmark :-( i haven't benchmarked that aspect but file::slurp is pretty fast. you could do worse than writing file::copy as write_file( $to, read_file( $from ) ) ; Check out File::Copy. It does basically that. With tons of special cases, of course, but still. It has a buffer (user-sizable), which it reads into in a single sysread, and then writes out to the new file, repeat until done. If you set the buffer size to = the input file size, you have a slurp. AS Like I say, it'll be a (not so) fond memory once P6 takes over the AS world. i am waiting patiently (really!). I see that nail biting! Of course, people are starting to make library-writing noises now that PUGS exists, so P6 can't be THAT far off ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Re: Perl Products
On Sat, 2005-03-05 at 01:16 -0500, Tom Metro wrote: I'd be willing to bet that Jesse has encountered, with some regularity, resistance to commercial adoption of RT due to its use of Perl. Ah... hey, I'm a fan of RT overall, but lack of commercial adoption would be a result of the fact that it's slow and it has significant human factors issues. We use RT at work as a NOC ticketing system, and the combination of really weak searching, using POST for everything, and rendering pages about as fast as my grandmother builds houses (actually, my grandmother is pretty spry for her age) makes the word-of-mouth value low. Focusing on the small job market for Perl is a red herring. ... It isn't. And for the same reason that a glib comment posted to the list saying that most jobs in *any* field are entry level, in response to my comment that most available Perl jobs are entry level. Agreed, but I find that a language that worries about its users and their work doesn't need to worry about its users getting work. There are those who will never be happy with the popularity of Perl until no other language is used, but personally, I'm happy if Perl continues to evolve and adapt to my needs, and enough people use it that CPAN continues to be one of the most useful resources on the planet. That requires a HUGE user-base, but there's plenty of room for the Javas and the Rubys and the Pythons and the C#s of the world. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] CPANPLUS
On Sat, 2005-03-05 at 02:08 -0500, Tom Metro wrote: Aaron Sherman wrote: * Help make CPANPLUS work well with all extant package managers * CPANPLUS - Better integration (platform bias removal) Could you expand upon CPANPLUS? I played around with it a while ago. I tried out the Tk UI, but with a 50 MB memory footprint I found it a bit sluggish, and haven't bothered to reinstall it since upgrading Perl. I'm not directly involved, but as I understand it, the project aims to resolve many of the platform integration, testing, and usability issues that cropped up around CPAN. CPAN was an amazingly cool step forward, and a first ever in terms of a language's support for its primary code repository (AFAIK), but it has been showing its age, and platform management issues have evolved. Enter the new guy: CPANPLUS. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] why popularity matters
On Fri, 2005-03-04 at 07:54, Kate Wood wrote: [...] the barriers to learning and using Perl [...] Managers, [...] expect you to have [available certification] You do realize that those are orthoganal, right? What's more, I GUARANTEE you that I could go learn Java (for which there is a strong certification program), not get certified and get a job within 5 weeks. This is because I have a significant amount of relevant job experience, regardless of the language I'm programming in. What you're describing is a situation where it would become costly to break into the _professional_ Perl programming world as a _novice_ programmer. This is true, and that's just the way mature languages are... more and more people start looking for employees with some indication that they've been using the language for a long time. Try being a novice programmer breaking into the world of C++! Wow, there's a hard thing to do! And yet, C++ continues to thrive. Side note: If you're looking to break into programming, start contributing to open source projects. There's nothing more valuable than saying, well, I might not be certified, but I did write the software that runs your company. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] why popularity matters
On Fri, 2005-03-04 at 14:02, Greg London wrote: andrew burke said: I never excluded people. I was asking them to play a different game. And I asked those who didn't want to play, to find a different game. This is said without realizing the irony? Hey, where were you as Irony-Identifier when Aaron called me exclusionary in the same email that he me to take the converation off the list? Let's review what I did say: You are free to ask the question, but not to expect others to constrain themselves to your arbitrary lines of response. It's not that people don't like you personally, it's just that we all feel kind of put upon to be told, don't say what you think, just let me noodle around on this list. It's exclusionary. [...] I don't like being given a list of what is impossible when I'm trying to play. Then form the play with Perl advocacy list, don't ask an existing list to re-form around your idea of what a valid discussion of certification and its value is. Aaron called me exclusionary No, he did not. He said that a specific act was exclusionary and it was. he [told?] me to take the converation [sic] off the list No, he did not. He told you that if you wanted a list with different ground-rules, you should create your own. You can have this conversation here, you just can't control the types of responses. For that, you need your own list. Can we stop tilting at straw men now and talk about Perl? Oh, and while I'm thinking about dinner (don't ask), I want to mention that there is an AWESOME new Chinese restaurant in Allston called Shanghai Gate. If we can arrange an off-peak time to go (they get packed around 7-9PM) that would be a very nice hang-out for the next informal Food.pm ;-) http://www.boston.com/dining/globe_review/1101 ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] why popularity matters
On Thu, 2005-03-03 at 16:15 -0500, Greg London wrote: Ben Tilly said: I think responses are more along the lines of, certification introduces a lot of problems, and we don't see how you'll make a certification become accepted. I don't know how it can be done, so it must not be possible. I don't see the so it must be possible, but rather a simple statement that there's something lacking here. That's a fair observation. I think responses are more along the lines of, we don't think that the business world pays as much attention as you think. If you think that it does, then please explain the success, past and present, of C, C++, PHP and Perl. I don't know how it can be done, so it must not be possible. You're repeating yourself, and in this case you're way off base. In fact, there's 4 good examples presented for SUCCESS, just not down the path that you suggest. It's a valid concern: why execute plan a, when plan b (already being executed) has many observed successful outcomes? It's a question you might answer many ways, but it's a valid question. I think that several have mentioned the cheap (used to be free) web-based certification at http://www.brainbench.com/. You have not explained why we should expect another one to have significantly better uptake than that one. I don't know how it can be done, so it must not be possible. Now you're getting quasi-religious with this mantra, and it's WAY off base. Re-read the statement. This has been tried. It's still out there. What's DIFFERENT about your model? If you say nothing, an obvious response is: why not throw your lot in with those already doing this? But you don't seem to be trying to understand why, you're just frustrated that we are not acting on it. No, see, that exactly is were you are wrong. I'm not frustrated that you aren't acting on it. It's like a walkie talkie with a bunch of people on the same frequency. Every time I say Anyone out there want to talk about certification/advocacy/insert idea here? a bunch of people hit the push-to-talk button with an air-horn by their microphone. You see, it's like you sent mail to a mailing list saying, hey, want to talk about certification? and lots of people did. You, as it turns out, didn't actually want to talk about certification. You wanted to talk about how to make Perl more popular via certification and you interpreted any other discussion of certification (especially if it contradicted any assumption you held), as -- and I use this grotesque tool of cheap rhetoric only because you insisted on over using it -- HOOONNNKKK! This is an OLD conversation, and to jump in with no plan, and only a hey we could do this and it would be cool, is like posting to a physics list, hey we could invent time travel, and it would be cool. If you are likely to be upset when someone says, time travel almost certainly is not possible, unless you're talking about moving very discrete, possibly highly restricted packets of information, then you might as well just skip the post because that's just a standard reply. Either cope and continue with your thought or don't bother. Check google, you'll see that there's even been a Perl Certification Wiki which was created solely to divert certification-related arguments. It's a hot-button topic, and to say that someone doesn't have a right to reply to it the way they feel is reasonable seems just as unfair as your airhorn metaphor. HOOKKK!!! The words you were looking for were cogent reply. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] why popularity matters
On Thu, 2005-03-03 at 23:52 -0500, Greg London wrote: Did you ever get a cool idea for a problem and just dive into it, explore it, learn about it, try out different things, and play? Yes. When I do that, I don't post to a public list saying, what if I just take this line of code, and move it over here... and then... well, perhaps I'll... I dunno ... it could... maybe it would run faster. If DID, however, I would certainly respect those who said, Joe over here tried exactly that on that section of code, and here are his benchmarks. Your level of respect for those comments was summed up best in one word, HOOONNNKK! But that's not what I'm talking about, I'm talking about the way JFK was a damned fool for saying he wanted to put a man on the moon before the decade was out. completely impossible at the time he said it. His speechwriters didn't want him to go public wiht it because they figured there was a good chance it wouldn't happen, and then he'd look bad for saying something so foolish and not having it come true. Ah, but you're not talking about solving a problem, no matter how hard. If you were, then you would have left certification out of it (at least at first) and asked if people wanted to beat around the idea of how to improve Perl popularity. You wanted to talk about a PARTICULAR MEANS. JFK didn't deliver a spec for the rocket and say THIS will make it to the moon, now let's talk about that. He stated a goal. These are VERY different things. If you want to talk about making Perl more popular, here are some ideas ranked in order of how likely I think they are to succeed in terms of large scale adoption. * Help make CPANPLUS work well with all extant package managers * Work on Perl 6 / Parrot / Pugs * Write documentation * Review / suggest edits to existing documentation * Lobby more large companies to formally support local user groups So, my message has always been along the line of can I just play around with this idea foolishly, without all the reasons why it will never work? Not on a public list, no. You are free to ask the question, but not to expect others to constrain themselves to your arbitrary lines of response. It's not that people don't like you personally, it's just that we all feel kind of put upon to be told, don't say what you think, just let me noodle around on this list. It's exclusionary. You have as much a right to talk about certification's potential as someone else does to say it's a lose. What if you had a way to do certification that was no cost to the programmer, but considered valuable by the corporate world? What if? not How? The next, obvious, burning question is: how? I'm sorry, but we're programmers. It's painful to see such a statement and not respond with a request for well defined parameters. And yet, I'll answer: such ways have existed for years, and they seem to have little effect, so no, not really. There, that's an answer to a what if / would it be, not a how. The question also begs the question (in the rhetorical sense) of why it would be considered of value to the programmer, and that too was discussed. So, no, neither you nor anyone on this list ever listened along the lines of my message, Yeah, we did. I failed this time, that is clear. But I learned something about how I relate to people who relate to teh world as a list of what is impossible. You're mis-characterizing the people on this list. No one is thinking in those terms, as far as I've seen. We're just being very mildly pragmatic. I don't like being given a list of what is impossible when I'm trying to play. Then form the play with Perl advocacy list, don't ask an existing list to re-form around your idea of what a valid discussion of certification and its value is. I didn't know that until this discussion. And I learned it because I got pulled into it and only at the end figured out what was going on. Hopefully, if nothing else good comes of all this, it will teach me not to get sucked into the what is impossible debate when I'm trying to come from what is possible, trying to come from play. I think if you had avoided interpreting responses as a what is impossible debate, then that would have worked out well too. No one ever heard the What if? they only heard Why not? No, they (we) heard the what if. You didn't hear the in that case, you get the following observed results. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] perl6/pugs
On Mon, 2005-02-28 at 12:51, Benjamin Kram wrote: Has anyone had a chance to play with pugs? I just svned down a copy and was going to toy with it a bit. Only a little bit. I am, however, sure that the correct way to boost the popularity of your favorite niche language is to write a compiler / interpreter in it for a popular language. Pugs will certainly boost Haskell in this way ;-) -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] certification
On Mon, 2005-02-28 at 15:39, Tom Metro wrote: As others have argued on the list, as programmers we know certifications are pointless as a technical qualification, but we're not the audience that needs to be convinced otherwise. I disagree. A certification says that you have a certain baseline of knowledge about a subject. The fact that people routinely mis-use certifications as a means to judge _applicable skill_ with some toolset whose knowledge is tested in the certification process is NOT the certification's fault. If you came to me and said, I have a certification in X, but have no other exposure to it, I would place your resume in the pile above the people who have not encountered X and below those who have used it for real work (assuming that the certification is one that I know and at least superficially trust). If, on the other hand, two experienced people applied and only one was certified in X, I would consider them to be equal and let in-interview factors decide. I would never let certification trump experience. Treated this way, certifications are a useful measure of how much ramp-up someone is going to have on a given technology, but NOT how good they are at using it. -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] short-listing languages for applications software development
On Tue, 2005-02-22 at 17:38, Ranga Nathan wrote:
Here is an email I received internally regarding the shortlist of
languages for future software development. I must add that this is a
corporate environment. I responded saying that Perl has one of the richest
data structures that I know of. Strong typing is actually a bad thing as
far as I am concerned. How can I rebut this arguement in a better way?
Actually, there is a hidden agenda to standardize on C# here!
On Type Safety and Perl
First, let's start with a definition. This one comes from answers.com:
http://www.answers.com/type-safetyr=67
In computer science, a programming language is type safe when
the language does not permit the programmer to treat a value as
a type to which it does not belong.
In Perl, there is one data type and two containers. The data type is
called scalar. In so far as the definition goes, Perl is a type safe
language, since you can never treat a scalar as a not scalar in Perl.
Of course, what type safety is SUPPOSED to mean is that you have a
semantic hierarchy of types, and each one has some particular definition
which prevents abuse of that type. In Perl, we fundamentally deny
abuse of data. There is no such concept. If you wish to add the number
10 to the string five, then you may do so because Perl brings to the
table a set of tools that allow the free conversion of string and
numeric data.
The type safe programming languages instead force you to pre-declare
that a variable is a string or integer, and then to invoke a
function or method which explicitly converts one to the other, and thus
adding five to 10 would result in a compile-time error in most cases.
While Perl 6 will add features that allow for such type-safety,
ultimately Perl will always provide this facility. Why? Ease of use, and
rapid development. It is possible, for example, to read the raw text of
an HTTP response like so:
$response = http_request($details);
($proto,$status,$text) = split(/\s+/, $response, 3);
if ($status = 200 $status 300) {
print Success: $status $text\n;
} else {
print Failure: $status $text\n;
}
Notice that $status moves from string to number and back to string
without any explicit conversion being required. The savvy programmer
would point out that we run the risk of $response containing some
strange error message from the server. What would happen, for example,
if $status contained the word violation? Let's find out by running
this code:
$status = violation;
if ($status 200) {
print that's strange\n;
} else {
print Good news, violation isn't 200\n;
}
I run this by placing the text in a file, and typing perl -w filename.
I then get:
Argument violation isn't numeric in numeric gt () at - line
3.
Good news, violation isn't 200
As you can see, Perl knows that I'm doing something that doesn't match
its understanding of valid string-to-numeric conversions, but it
proceeds anyway, after producing a warning message. This warning is
enabled by the -w flag, which is a critical flag to know about,
regardless of your preference for typing.
So, what else does dynamic typing give us? One useful feature is
free-form data structures. For example, take:
@employees = (
{
name = 'Bob',
id = 1,
title = 'Muckety Muck',
subordinates = [ 2, 3 ],
}, {
name = 'Alice',
id = 2,
title = 'Coffee Drinker',
subordinates = undef
}, {
name = 'Charlie',
id = 3,
title = 'Trouble Maker',
subordinates = undef
}
);
this is a complex data structure which contains 3 records for employees
of a company. There need be no forward declaration of how this data
structure behaves, however, since it is just a collection of arrays and
hashes of scalar values. Notice that subordinates is an anonymous
array of ids in the first case, but in the other two cases, it is the
special value undef. This is possible because references to arrays and
the undef value are both scalars, and hash values and array elements are
always scalar values.
This free-form data management is tremendously powerful, and while it
sacrifices the assurances of strongly typed languages, it is far easier
for modules and extensions to provide such safety where needed than it
is for a strictly typed language to provide dynamic typing.
Conclusions
Type safety is a powerful tool, but to confirm that high quality code
can be written and maintained without type safety, one need only look at
the CPAN repository where Perl modules and add-ons
Re: [Boston.pm] short-listing languages for applications software development
On Tue, 2005-02-22 at 19:32 -0500, Bob Rogers wrote: The type safe programming languages instead force you to pre-declare that a variable is a string or integer, and then to invoke a function or method which explicitly converts one to the other, and thus adding five to 10 would result in a compile-time error in most cases. This conflates type safety with static typing; type checks can also be done at run-time Yes they can, but I'm speaking to a Java guy here, so I simplified and abbreviated. Anything else would have taken far too long to explain. Unfortunately, someone who doesn't like Perl is probably going to really hate Common Lisp . . . Not so. I work at a company that uses Common LISP heavily, and I'm strongly looked down on as just a Perl programmer. Someone who doesn't like Perl, and DOES like statically typed languages, will probably hate Common LISP, but never underestimate the power of a Common LISP programmer to look down on other languages ;-) CPAN would be helped by dynamic type safety. It probably owes its large size to the lack of static typing. Not really. The size is mostly due to the thousands of packages, and many versions of each. That's not to say that run-time type checking would not be a win. I'm psyched about PUGS, as I'm finally looking forward to a foreseeable future that has Perl 6 in it! ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] control-c occurs during system() command
On Tue, 2005-01-25 at 11:34, Uri Guttman wrote:
GL == Greg London [EMAIL PROTECTED] writes:
GL After the system call, how do I test for a control-c
GL as the cause for the command ending?
look at $@ and check for why the process died. you can extract a signal
number from it (shift 8 bits and mask IIRC, rtfm for details. i think
perlvar covers it).
This is incorrect. $@ is for eval, $? is for system.
GL Oh, and I can't simply say
GL system('cp -r longtree dest')==0 or die $@;
GL because some system commands will fail because the
GL directory doesn't exist or something, and in those
GL cases, I want the script to keep going.
just check for SIGINT and handle that.
You're correct, but that's not clear to the uninitiated. Here's the
explanation:
$? contains the exit status of the program. On POSIX-compliant systems
this is a number which is:
($exit 8) | $signal
Where $exit is the parameter that the program passed to exit(2), and
$signal is the signal that interrupted the process, if any.
You can check to see if the process was killed by:
if ($? 0xff) {
die Process killed by signal .($? 0xff);
} elsif ($? 8) {
die Process exited with status .($? 8);
} else {
# Worked fine
}
Make sense?
This is also a faq, so you can type:
perldoc -q control-c
to see what the lord of the FAQ says ;-)
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] mind share
On Tue, 2005-01-18 at 12:07, Uri Guttman wrote:
DB == Dan Boger [EMAIL PROTECTED] writes:
DB I've been trying to be good, and seperate content from presentation.
DB But since starting using Mason, I find that's much harder to do? Yes
in the templating world, there are two camps, code embedded in the text
and code separated from the text. i have always been in the code outside
the text camp and i have rolled my own tiny templaters in that way for
years.
Template Toolkit makes this trivial. The code that you put in the
template is a pseudo-code that has only the tools you need in order to
integrate your variables with the page. The code all goes elsewhere. For
example, here's some CGI:
use CGI qw(:standard);
use Template;
my $stuff=param('stuff');
my $ttk = Template-new()
or die Failed to instantiate TTK engine;
print header();
$|=1;
$ttk-process('mytemplate.tt',
{ stuff = $stuff, nums = [1,2,3] })
or die Cannot process template 'stuff';
exit 0;
And a template:
htmlheadtitle[% stuff %]/title/head
body
[% FOREACH n = nums; %]
pSay hello to the number [% n %]/p
[% END %]
/body
/html
Notice that while there's a loop in the template, it's nothing but a
simple iteration, and there's no complex flow control here. Thus, an
HTML editing tool could display this with a reasonable degree of
non-intrusiveness and allow you to change that to a table:
table
[% FOREACH n = nums; %]
trtdSay hello to the number/td
td[% n %]/td/tr
[% END %]
/table
This is the way content and code should be combined... anything more
complex than the above should be used to construct the variables. The
only exception is conditional includes, which are a nice way to
conditionally insert an entire section of a page, based on the setting
of a variable without having to put HTML in your variables (e.g. are
you loogged in? Ok, you get the 'log out/manage my account' sidebar.)
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] mind share
On Tue, 2005-01-18 at 16:08, Uri Guttman wrote: templating is not rocket science. that is why there are so many template modules on cpan. they are trivial to do basic versions. whether they mature into large systems like tt2 is another matter. True, but the advantage of having a baseline way of templating (and this is the BIG advantage of PHP) is that you can then abstract away from that and develop second-derivative toolsets. This is what TTK has done (look at the number of Template::* modules in CPAN that aren't part of the core Template-Toolkit). When you roll your own, you have to stop and think about how and if to integrate each of these new tools, and I always find myself limiting the scope of a project instead of tackling that kind of battle. Some examples for TTK: Template::Plugin::Translit::RU Template::Plugin::Tooltip Template::Plugin::Textile Template::Plugin::TextToHtml Template::Plugin::TagRescue Template::Plugin::Table Template::Plugin::StringTree Template::Plugin::StickyQuery Template::Plugin::Stash Template::Plugin::Siesta Template::Plugin::Shuffle Template::Plugin::ShellQuote Template::Plugin::Session Those are just the Ss and Ts! Mason too has a fair number of extensions (though fewer, I think, than TTK). AS This is the way content and code should be combined... anything more AS complex than the above should be used to construct the variables. please restate that last sentence in english. i think we are agreeing but i can't be for sure! :) This is the way content and code should be combined (that is, by using variables in simple HTML, with as little flow control as possible)... anything (that is, code) more complex than the above (simple example) should be used to construct the variables (in, say, Perl which are then used by the templating system to search/replace the template). Or another way of saying that is: Your templates should never have a complex boundary between code and content. Is that better? And, yes, I think we're agreeing on that point from the gate. -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] mind share
On Fri, 2005-01-14 at 10:33, Sean Quinlan wrote: On Thu, 2005-01-13 at 21:58, Tom Metro wrote: This reminded me of something I've wondered about for a long time. Why did PHP become as successful and popular as it is, even though it mostly offers a subset of what Perl can do. (I'm aware of some of the historical reasons for PHP being created. What's less clear is why a Perl equivalent didn't address the need.) I certainly wouldn't mind this as a discussion topic for part of the meeting. I'd also be particularly interested in hearing from people who are working with PHP and other languages. What are the pro's and cons'? Since I can't be there, I'd just like to explain why I think this happened. mod_perl is an amazing tool, and correctly combined with other tools such as HTML::Mason, TTK, etc. it makes for a very usable content system. However, PHP's arrival on the scene was important as it was the first open source language (to my knowledge) which required exactly no integration work between it and the HTML-based Web page. Inline PHP is simple and easy to use. PHP's inlinability makes lots of things easier when you're getting started, and so the language gained quick popularity. It's also deadly as many PHP developers discover all too late (see the various *Nuke projects and other PHP projects which have done well to a point and then had to pour tons of engineering time into separating presentation and code in order to move to a level of abstraction that allowed the project to scale). Currently working in TTK, I can see the echos of that. There's a strong insistence in the docs that you not use the inline perl features (turned off by default), for example. Having first experienced content generation under StoryServer (a proprietary system using embedded TCL in HTML, but with a simply awesome caching system that beats anything else even today), I came into TTK already wary of this pitfall, but it's good to see the reflective paint on the guard-rails -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
[Boston.pm] Re: [Boston.pm-announce] [ADMIN] Mailing list / Web site news
On Wed, 2005-01-05 at 10:14, Ronald J Kimball wrote: The [EMAIL PROTECTED] address is currently invalid. I do not know whether this is a permanent change or just a temporary side effect of the move. LIST POSTS MUST BE SENT TO boston-pm@mail.pm.org instead. Our lovely new Kwiki is now inaccessible. In order to restore it, we will most likely need to find a new host for our website. Suggestions welcome. I will make inquiries at work, and see if we can allocate a machine here in the home office (we have decent bandwidth for a low-impact site like boston.pm.org), with appropriate software installed. No promises. -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Max hash key length
On Thu, 2004-12-30 at 20:45, Ben Tilly wrote: On Thu, 30 Dec 2004 18:02:07 -0500, Aaron Sherman [EMAIL PROTECTED] wrote: I understand risk assessment and the idea that nothing is 100% safe, but when you have a situation where you KNOW from day one that some keys will collide, and your data will be corrupted, you don't build that into your system if you have an easy out. Then I recommend that you never use rsync. As for me, I'm sometimes willing to accept the possibility of algorithm failures which are less than the odds of my program going wrong because of cosmic radiation. Take a look at rsync. It relies, by default, on four pieces of information exactly because trusting a single checksum is far too risky for a general-purpose tool. That information is: file size, timestamp, large-scale checksum, block-level checksum. Moreover, rsync allows the interpretation of each and every one of those to be tuned from the command-line. And yes, while I usually just trust to the law of probability (which is a very strange feature of our universe, if you stop to think about it), when I'm doing something that requires certainty I do not rely on rsync's block-for-block checksum strategy. Instead, I do one of two things: 1. I force a full copy of files based on timestamp (costly, of course) 2. I add one byte to the end of all files, rsync normally, remove the byte and rsync again. This results in odds of correct identification of changes that is an order of magnitude better, but still not perfect. Again, this is a matter risk assessment. This is hashing 101. You hash, you bucket based on the hashes, and then you store a list at each bucket with key and value tuple for a linear search. There are other ways to do it, but this is the classic. Yes, I'm familiar with this, and outlined it in a previous email in this thread. So, why were we discussing a module that would tie a hash to a lossy checksumming operation, when standard practice in computer science provides a simple solution? Of course, Perl does this for you. That extra time that I measured is almost certainly the time spent comparing the two strings, which your tie interface will also have to do because of collisions. Want to bet whether Perl spends more time in computing hash values or comparing strings? I think you missed the point. I was not discussing a trade-off, but rather suggesting why my example played out the way it did. If you're suggesting pre-computing hashes, not just as a front-end to fetch/store, but on a persistent basis, then you will get a very noticeable performance win, but at the cost of having to perform some kind of copy-on-write or other tainting check for modified keys (slowing all other operations)... which of course, it turns out that Perl already does for you, see sv.[hc] and hv.c in the standard Perl 5.8.x distribution ;-) -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Max hash key length
On Wed, 2004-12-29 at 18:10, Ben Tilly wrote: Under normal circumstances, to get non-miniscule odds of having a collision somewhere between MD5 keys, you'd need about 2**64 keys. If you have less than, say, a billion keys then you can ignore that possibility for all practical intents and purposes. I understand risk assessment and the idea that nothing is 100% safe, but when you have a situation where you KNOW from day one that some keys will collide, and your data will be corrupted, you don't build that into your system if you have an easy out. This is hashing 101. You hash, you bucket based on the hashes, and then you store a list at each bucket with key and value tuple for a linear search. There are other ways to do it, but this is the classic. Of course, Perl does this for you. That extra time that I measured is almost certainly the time spent comparing the two strings, which your tie interface will also have to do because of collisions. -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Max hash key length
On Tue, 2004-12-28 at 13:46, Ian Langworth wrote:
On 28.Dec.2004 01:14AM -0500, Tom Metro wrote:
If you are concerned about the performance impact of long
keys, and your application fits a write-once, read-many
model, then you could always hash the hash keys. Say generate
an MD5 digest of the key string, and then use the digest as
the hash key.
This might make a nice Tie:: module, if there already isn't
one. But then again, tie itself is allegedly slow...
No, that would defeat the point
Or at least that's what I was going to say... I had a whole rationale
typed up, but then I went to benchmark my hypothesis and I get this:
$ perl -MBenchmark -e 'my $long=ax10_000;my %x;timethis(100_000,sub
{$x{$long}++});print Final: $x{$long}\n'
timethis 10: 7 wallclock secs ( 6.54 usr + 0.00 sys = 6.54 CPU)
@ 15290.52/s (n=10)
Final: 10
$ perl -MBenchmark -e 'my $long=ax10_000;my %x;timethis(100_000,sub
{my $tmp=unpack(%32C*,$long) % 65535;$x{$tmp}++});my
$tmp=unpack(%32C*,$long) % 65535;print Final: $x{$tmp}\n'
timethis 10: 2 wallclock secs ( 2.16 usr + 0.00 sys = 2.16 CPU)
@ 46296.30/s (n=10)
Final: 10
Is there a bug in my code, or is there really that substantial a
savings?
Of course, there's a substantial problem with the above: hashes DO
conflict. Your module would have to do the same conflict resolution that
perl's built-in hashing would do, and that's probably where the extra
overhead comes in (though I admit I'm not seeing it... perhaps in
comparing the long value to the original?)
In a case where collisions wouldn't be a real problem, I guess that's a
non-issue, but those are rare cases.
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] transposing rows and columns in a CSV file
On Fri, 2004-11-12 at 13:22 -0800, Ben Tilly wrote: On Fri, 12 Nov 2004 10:05:27 -0500, Uri Guttman [EMAIL PROTECTED] wrote: GS == Gyepi SAM [EMAIL PROTECTED] writes: [...] this talk about mmap makes little sense to me. it may save some i/o and even some buffering but you still need the ram and mmap still causes disk accesses. Just to throw in my own two cents before I critique the reply: some disk buffering can mean a factor of 10-1000 performance improvement in real world applications. This is my personal experience with real-world programs. Of course, if all you want is linear access to a file once, then mmap doesn't help. But, if you want random access to a file, nothing beats mmap because people spend their LIVES tuning paging strategies, and such code has knowlege of the hardware that you cannot otherwise take advantage of in a general purpose IO layer. Um, mmap does not (well should not - Windows may vary) use any RAM You are confusing two issues. using RAM is not the same as allocating process address space. Allocating process address space is, of course, required for mmap (same way you allocate address space when you load a shared library, which is also mmap-based under Unix and Unix-like systems). All systems have to limit address space at some point. Linux does this at 3GB up to 2.6.x where it becomes more configurable and can be as large as 3.5, I think. To be clear, though, if you had 10MB of RAM, you could still mmap a 3GB file, assuming you allowed for over-committed allocation in the kernel (assuming Linux... filthy habit, I know). mmap should not cause any more or less disk accesses than reading from the file in the same pattern should have. It just lets you do things like use Perl's RE engine directly on the file contents. Actually, no it doesn't as far as I know (unless the copy-on-write code got MUCH better recently). Like I said, you probably won't get the win out of mmap in Perl that you would expect. In Parrot you would, but that's another story. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] emergency social meeting
On Fri, 2004-11-12 at 10:26 -0500, Uri Guttman wrote: bdf == brian d foy [EMAIL PROTECTED] writes: bdf I'm in Boston from Nov 15-18. for those of you who don't know, bdf teaches for stonehenge (randal's biz) and is the founder of perl mongers (which you are a member of!) so let's give him his due props with a nice emergency social meeting. Yeah, yeah... whatever. How cool is his camera?! ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] transposing rows and columns in a CSV file
On Wed, 2004-11-10 at 23:13 -0500, Uri Guttman wrote:
sorry i missed the meeting but i have a nasty cold i am fighting off.
I just got over that one :-(
As for transposing a matrix that won't fit in ram... that's easy. Mail
it to someone who has more ram.
Aaron Gordian Knot Sherman, at your service ;-)
Seriously, while mmap is ideal in C, in Perl I would just build an array
of tell()s for each line in the file and then walk through the lines,
storing the offset of the last delimiter that I'd seen. That way, every
read looks like this:
# XXX WARNING, untested pseudo-code
next if $offsets[$thisline] == -1;
seek(INPUT,$tells[$thisline]+$offsets[$thisline],0);
$bigbuf = '';
for($i=0;$i;$i++) {
sysread(INPUT,$buf,$blocksz);
# Proper CSV parsing left as an exercise...
if ($buf =~ /[,\n]/) {
$pos = length($`)+1;
$sep = $;
if ($sep eq \n) {
$offsets[$thisline] = -1; # Done here
} else {
$offsets[$thisline] += $i*$blocksz+$pos;
}
last;
} else {
$bigbuf .= $buf;
}
}
handle_one_field($bigbuf);
Let the kernel file buffer do your heavy lifting for you.
--
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Inheriting documentation for inherited command-line options
On Wed, 2004-09-08 at 00:17, Uri Guttman wrote: use warnings should be here too. [...] i like _$method better. [...] i don't like using = like that. Uri, you're ripping the guy's code to shreds over minor points of syntactic sugar... I seem to remember that Perl's moto isn't There's only one way to do it. i can't get into the actual design or debugging but i hope my comments are useful. He did ask for help specifically in two areas of the design, not a style lecture. Usually I'm not this harsh, but man, that's gotta make a guy feel like sending his code to this list is about the same as pulling his pants down in public! -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Tech Meeting Followup
On Thu, 2004-08-05 at 11:16, Ronald J Kimball wrote: We had about 20 people at Tuesday's tech meeting. We started with a review of notable happenings at OSCON, including Dan Sugalski being hit in the face with a pie, and Jon Orwant receiving a White Camel award. That former topic also showed up on Slashdot thanks to yours truly, but it never showed up on the home page. Still, here it is: http://developers.slashdot.org/article.pl?sid=04/08/04/0018226tid=145tid=133tid=218 I'm constantly amazed by the progress Parrot has made, and while I was sad that we didn't make the deadline, I think the fact that Parrot was able to run 6 out of 7 of the benchmarks and 5 of them faster than CPython was well worth a hearty slap on the back for the Parrot devs, Dan included! I look forward to the day that my Python-happy co-workers can use my in-house Perl module library as well as all of CPAN! What a day that will be! -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
