From perl-pm at joshheumann.com Mon Jan 3 19:13:46 2005 From: perl-pm at joshheumann.com (Josh Heumann) Date: Mon Jan 3 19:13:48 2005 Subject: [Pdx-pm] January Meeting Message-ID: <33151.130.94.161.146.1104801226.squirrel@joshheumann.com> The January Meeting will be Lightning Talks, Wednesday, January 12th at 6:30pm at Free Geek, 1741 SE 10th Please sign up for a slot on the kiwki: http://pdx.pm.org/kwiki ALSO: New Books Available from O'Reilly: ---------------------------------------------------------------- -Windows XP Pro: The Missing Manual, 2nd Edition -Photo Retouching with Photoshop: A Designer's Notebook -Linux Cookbook -Revolution in The Valley -Silence on the Wire -Jakarta Commons Cookbook -Dr. Tom Shinder's Configuring ISA Server 2004 -Oracle SQL*Plus: The Definitive Guide, 2nd Edition -Windows XP Annoyances for Geeks, 2nd Edition -Home Theater Hacks -Hacking a Terror Network -Word Hacks -High Performance Linux Clusters ---------------------------------------------------------------- From nick2canz at yahoo.com Fri Jan 7 21:15:03 2005 From: nick2canz at yahoo.com (Nick Wehr) Date: Fri Jan 7 21:15:16 2005 Subject: [Pdx-pm] perl and vim - for cool guys Message-ID: <20050108051503.10677.qmail@web50902.mail.yahoo.com> Ovid, Thanks for plugging the perl and vim blog page. Anyone here use perl-support vim plugin? I just discovered it about 3 days ago, and just using it forces my code to look better, er at least the comments. I keep so busy I really didn't realize how bad my commenting had been. Once I found an easy way to do it, I was all over it. I also like to install gvim for windows if I'm forced to edit code on those dreaded machines. Anyhow, stay cool. -nick wehr __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From jamarks at jamarks.com Mon Jan 10 22:55:56 2005 From: jamarks at jamarks.com (James marks) Date: Mon Jan 10 22:56:12 2005 Subject: [Pdx-pm] Readable code Message-ID: Greetings all, I'm new to Perl and fairly new to programming as well and I'd like to pose a question for all of you experienced and knowledgeable Perl programmers: Recently, a number of books I've read about, or referring to, writing code - Steve McConnell's "Code Complete" and Paul Graham's "Hackers and Painters," are two examples - emphasize writing readable code. An excerpt from "Hackers and Painters" illustrates my point: "Source code, too, should explain itself. If I could get people to remember just one quote about programming, it would be the one at the beginning of Structure and Interpretation of Computer Programs. " 'Programs should be written for people to read, and only incidentally for machines to execute.' " You need to have empathy not just for your users, but for your readers. It's in your interest, because you'll be one of them. Many a hacker has written a program only to find on returning to it six months later that he has no idea how it works. I know several people who've sworn off Perl after such experiences." I've gotten in the habit of breaking my code out into lots of subroutines because I've found that makes it much easier for me to read and troubleshoot, a practice that seemed to be reinforced in Code Complete. Now, however, as I read books on Perl and talk to Perl coders I'm finding that placing an emphasis on writing readable code, and breaking code out into lots of subroutines doesn't seem to be considered "the Perl way" of doing things. The emphasis seems to be tighter and tighter code, sometimes - it seems to me - at the expense of readability (especially for those new to Perl). I'd be very interested in your thoughts and suggestions regarding terse code, readable code, verbose code, etc... Thanks, James From ewilhelm at sbcglobal.net Mon Jan 10 23:18:21 2005 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Mon Jan 10 23:15:46 2005 Subject: [Pdx-pm] Readable code In-Reply-To: References: Message-ID: <200501110118.21904.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # James marks # on Tuesday 11 January 2005 12:55 am: >Now, however, as I read books on Perl and talk to Perl coders >I'm finding that placing an emphasis on writing readable code, and >breaking code out into lots of subroutines doesn't seem to be >considered "the Perl way" of doing things. Yes, but golfing isn't "the Perl way" for me. I thought "the Perl way" was TMTOWTDI >The emphasis seems to be >tighter and tighter code, sometimes - it seems to me - at the > expense of readability (especially for those new to Perl). I don't know. I'm using Math::Vec here, so does adding array references inside of a map qualify as more readable or less? It's a lot more transparent than a foreach loop or a subroutine call, and takes up as much space. # totally out-of-context code my @vecs = ($self->{edge_vec}, $prev->{edge_vec} * -1); # get the framework lines (aimed away from corner) my @fwsegs = map({[$pt, $pt + $_]} @vecs); I do a lot of CAD/CAM and geometry code, so almost everything is an array. IMO, this is exactly the perl way to do it, since we have garbage collection, etc. The C/C++ way to do it seems to be to deal with things named x,y, and z, and then write all of the code 3 times. Sure, you can define classes, etc. but perl lets you do that too. From my experience, SPOT is easier to achieve with perl, which helps readability because there is less to read and it is less scattered. I guess the short answer is that good software practices are good. I would say readability is one of them, and yes perl allows you to write unreadable code. I don't think it encourages it. English doesn't force readability on you either. --Eric From kyle at cepaso.com Mon Jan 10 23:22:55 2005 From: kyle at cepaso.com (Kyle Dawkins) Date: Mon Jan 10 23:23:45 2005 Subject: [Pdx-pm] Readable code In-Reply-To: References: Message-ID: <9C7D4FF7-63A1-11D9-B11E-000393635E16@cepaso.com> James You bring up a really good point and one that definitely touches a nerve. > I've gotten in the habit of breaking my code out into lots of > subroutines because I've found that makes it much easier for me to > read and troubleshoot, a practice that seemed to be reinforced in Code > Complete. Now, however, as I read books on Perl and talk to Perl > coders I'm finding that placing an emphasis on writing readable code, > and breaking code out into lots of subroutines doesn't seem to be > considered "the Perl way" of doing things. The emphasis seems to be > tighter and tighter code, sometimes - it seems to me - at the expense > of readability (especially for those new to Perl). Yes, you're right. Many things that are considered "The Perl Way" are often totally contrary to many of the points found in Code Complete (and other well-respected engineering books). There is definitely a culture in The Perl World that elevates obfuscation and "one-liners", creating a myth in the rest of the IT world that Perl looks like this: #!$ugh%%^#!@&^#; Of course, we know better, but the perception from Java or C# programmers is "You program in Perl? Ewwwwww... I've seen Perl, it looks impossible to read." > I'd be very interested in your thoughts and suggestions regarding > terse code, readable code, verbose code, etc... Well, you can write shitty -or great- code in any language. I've seen some code in Java that makes my skin crawl, and code in Lisp that is a thing of beauty and readability. It comes down to the simple principles that McConnell et al extoll in their various books. You shouldn't care what The Perl World thinks, you should do what's right for you. There is a lot of great, readable code being written in Perl every day, and just because it doesn't do strong-typing of your variables or method-signature checking or ... etc ... doesn't mean that code you write in Perl is going to be disorganised. In fact, there are constructs in Perl that make writing readable, clear code *easier* than other languages. E.g. Using "return unless condition;" to short-circuit methods is a tight, concise code construct, and is much easier to read than the "if (!condition) { return };" of many other languages. There are many other examples. One of the great strengths -and weaknesses- of Perl is that you can make it look pretty much however you want. Kyle Kyle-at-cepaso.com From almeria at earthlink.net Mon Jan 10 23:24:08 2005 From: almeria at earthlink.net (Rafael Almeria) Date: Mon Jan 10 23:24:20 2005 Subject: [Pdx-pm] Readable code In-Reply-To: References: Message-ID: > I've gotten in the habit of breaking my code out into lots of > subroutines because I've found that makes it much easier for me to > read and troubleshoot, a practice that seemed to be reinforced in Code > Complete. Now, however, as I read books on Perl and talk to Perl > coders I'm finding that placing an emphasis on writing readable code, > and breaking code out into lots of subroutines doesn't seem to be > considered "the Perl way" of doing things. The emphasis seems to be > tighter and tighter code, sometimes - it seems to me - at the expense > of readability (especially for those new to Perl). > > I'd be very interested in your thoughts and suggestions regarding > terse code, readable code, verbose code, etc... Writing obfuscatory code certainly shouldn't be the way to do things; however, Perl does give you certain constructs which are very useful (as mental shortcuts) but perhaps difficult for the beginner. Make sure your code is well thought out, commented and use good variable names. Cheers, Rafael From randall at sonofhans.net Mon Jan 10 23:35:39 2005 From: randall at sonofhans.net (Randall Hansen) Date: Mon Jan 10 23:35:54 2005 Subject: [Pdx-pm] Readable code In-Reply-To: References: Message-ID: <642D9B24-63A3-11D9-B212-000A95D9E32C@sonofhans.net> On Jan 10, 2005, at 10:55 PM, James marks wrote: > I'd be very interested in your thoughts and suggestions regarding > terse code, readable code, verbose code, etc... josh is fond of damian conway's saying, "any ten lines of perl can be reduced to one line." you can write some pretty terse code in perl, and it's easy to see the attraction. like any tool, when you get to know it better you can use it more efficiently. expressing a relatively complex thought in 30 characters of seeming line noise can feel pretty powerful. and, as you say, be impossible to read. i suggest writing perl the same way you'd write anything else: for your audience. sometimes your code will be more verbose, but that isn't always bad. you don't read hegel to your toddler. if you're writing a system maintenance script on contract, write it cleanly and simply, since you don't know who will have to modify it (a) under pressure, and (b) with limited perl knowledge. if you're writing for a more specialized audience or where your own time optimization is of the utmost importance, pull out the stops and be idiomatic. $.02 r From tex at off.org Tue Jan 11 00:29:14 2005 From: tex at off.org (Austin Schutz) Date: Tue Jan 11 00:29:30 2005 Subject: [Pdx-pm] Readable code In-Reply-To: References: Message-ID: <20050111082914.GH30155@gblx.net> > I've gotten in the habit of breaking my code out into lots of > subroutines because I've found that makes it much easier for me to read > and troubleshoot, a practice that seemed to be reinforced in Code > Complete. Now, however, as I read books on Perl and talk to Perl coders > I'm finding that placing an emphasis on writing readable code, and > breaking code out into lots of subroutines doesn't seem to be > considered "the Perl way" of doing things. The emphasis seems to be > tighter and tighter code, sometimes - it seems to me - at the expense > of readability (especially for those new to Perl). > Actually, I'd have to say by and large the documentation in the published code, except for the Tolkien peppered C, has improved quite a bit over the last few years. Either that or I'm having an easier time slogging through it. > I'd be very interested in your thoughts and suggestions regarding terse > code, readable code, verbose code, etc... > I tend to be one of those annoying long sub people, though I do my best to document what a sub is supposed to accomplish and how each section works toward accomplishing that goal. Deciding how long to make subs is pretty subjective. There's a readability tradeoff either way - either you have long subs which run on and are more difficult to debug, or you chop it into smaller blocks which may be harder to comprehend and lead to more complex code paths. Here's an example of what I mean. Take a lexer, for example. You tend to have sections like: if (/a/) { ... } elsif (/b/) { ... } elsif (/c/) { ... ... } elsif (/z/) { ... Which could be shortened to: if(/[a-l]/) { lex_a_l(); } elsif( /[m-z]/) { lex_m_z(); } else { ... } but you've added complexity, and it may be harder to follow the code in the end, especially as you get more and more levels deep. I dunno. Use common sense, try to imagine what the poor slob who gets to maintain your code will want to know when reading it. Chances are you will end up being the poor slob as soon as you've forgotten how the code works and something breaks. Use pod to doc functionality. pod rocks. Austin From bruce at gridpoint.com Tue Jan 11 08:09:23 2005 From: bruce at gridpoint.com (Bruce J Keeler) Date: Tue Jan 11 08:09:35 2005 Subject: [Pdx-pm] Readable code In-Reply-To: <642D9B24-63A3-11D9-B212-000A95D9E32C@sonofhans.net> References: <642D9B24-63A3-11D9-B212-000A95D9E32C@sonofhans.net> Message-ID: <1105459763.1141.51.camel@bjk-machine> On Mon, 2005-01-10 at 23:35 -0800, Randall Hansen wrote: > On Jan 10, 2005, at 10:55 PM, James marks wrote: > > > I'd be very interested in your thoughts and suggestions regarding > > terse code, readable code, verbose code, etc... > > josh is fond of damian conway's saying, "any ten lines of perl can be > reduced to one line." you can write some pretty terse code in perl, > and it's easy to see the attraction. like any tool, when you get to > know it better you can use it more efficiently. expressing a > relatively complex thought in 30 characters of seeming line noise can > feel pretty powerful. I think the whole line-noise criticism is due to regular expressions more than anything else. Old UNIX hands know regexes, but people coming from Windows programming see them and then dismiss Perl as unreadable line-noise, which is simply not fair. It would be like me dismissing Dostoyevsky as writing unreadable prose, when I don't even know the Cyrillic alphabet, much less the Russian language. For example: s/^([^ ]*) *([^ ]*)/$2 $1/; As a Perl programmer, I can look at that one line of code, parse it, understand what it's doing and convince myself whether it's correct or not for the job at hand, all in about 3-5 seconds. Compare that to the equivalent page or so of C (or even Java) that it would take to the same job, and it's easy to see that Perl is both more readable and more likely to be bug-free. Concision is good. -- Bruce J Keeler From jonlevitre at yahoo.com Tue Jan 11 08:34:54 2005 From: jonlevitre at yahoo.com (Jon LeVitre) Date: Tue Jan 11 08:36:29 2005 Subject: [Pdx-pm] Readable code In-Reply-To: Message-ID: <20050111163454.14256.qmail@web52709.mail.yahoo.com> > I'm finding that placing an emphasis on writing readable > code, and breaking code out into lots of subroutines > doesn't seem to be considered "the Perl way" of doing > things. I think that the main reason for this is that parameter passing is one of Perl's weaknesses. In other languages it's easier to write a short function that takes a couple of complex parameters. In Perl it's often easier to just in-line the same function. Jon __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From jkeroes at eli.net Tue Jan 11 11:39:20 2005 From: jkeroes at eli.net (Joshua Keroes) Date: Tue Jan 11 11:39:31 2005 Subject: [Pdx-pm] RIP: Lucky the lab Message-ID: <7D5933C4-6408-11D9-B2A3-000A95C466EC@eli.net> > Lucky > > 1995 - Jan 8, 2005 > > Lucky was well known for his friendly nose-in-the-crotch greeting, sly > antics, and boundless joy. He was a photogenic part-time television > star, > appearing on such shows as A.M. Northwest among others. > > His hobbies were barking, running, and watching cat-food commercials > and > Animal Planet on television. > > He apparently suffered a fatal stroke in his sleep on the night of > Jan. 7. > > Lucky is survived by his family and constant companion Miss Dibs. > > Lucky's four-legged and two-legged friends are invited to come say a > toast: > > Wed., Jan. 12 > Lucky Lab Brewpub > 915 SE Hawthorne Blvd. > 6.30 - 8.00 p.m. That's tomorrow, same day as the PDX.pm meeting. It'll be a good drinking night there! -J From perl-pm at joshheumann.com Tue Jan 11 12:16:30 2005 From: perl-pm at joshheumann.com (Josh Heumann) Date: Tue Jan 11 12:16:43 2005 Subject: [Pdx-pm] January Meeting tomorrow night Message-ID: <33748.130.94.161.146.1105474590.squirrel@joshheumann.com> January Meeting January 12th, 2005 6:30pm at Free Geek, 1741 SE 10th Ave Lightning Talks The list of lightning talks is slim at this point. There are only three people signed up, and if we don't get more, we're looking at a very short meeting. Persuant to a couple of recent emails, it would be cool if someone would do a little talk on perl styles that they like, and maybe an intro to pod for people who have never used it. Sign up for a slot on the kwiki: http://pdx.pm.org/kwiki The list: - MarvinHumphrey: Kinosearch, a Perl search engine library - GabrielleRoth: How I Integrated & Automated a Network Management System with Perl - Keith Lofstrom: Dirvish - disk-to-disk based on perl and rsync A projector and an internet connection will be provided. Afterwards, as always, beer at the Lucky Lab. From rlucas at tercent.com Wed Jan 12 11:14:00 2005 From: rlucas at tercent.com (Randall Lucas) Date: Wed Jan 12 11:14:16 2005 Subject: [Pdx-pm] Mac OS X 10.2, Perl and mod_perl upgrades Message-ID: <41E576F8.2070103@tercent.com> Hi mongers, I'm looking for some assistance, paid in cash or in kind, with some upgrades to my Mac. My Powerbook runs OS X 10.2. My latest work relies upon Perl >> 5.6.0, and I need to be able to test things under an Apache/mod_perl environment as well. Another issue is that I've got Fink installed, and have installed a bunch of stuff through Fink. I installed Perl 5.8 from source and Apache with Apachetoolbox. It took much, much finagling to get both Perl and Apache+mod_ssl to compile, including much guessing with config options, trial-and-error with -L flags, and unspeakable things done to Makefiles. However, 1. I don't trust my Apache since I basically made it do a "shut up and compile" rather than addressing the underlying complaints, and 2. more importantly, my Perl is only marginally usable, with all of the old 5.6.0 XS libraries barfing. At this point, I have concluded that I am Not Smart Enough for this task. I am looking for an OS X geek who has upgraded Perl and Apache + mod_perl + mod_ssl successfully on OS X 10.2, and can repeat the process on my machine so I have some notion that it was done "the right way." I will buy dinner, or beer, or both, or we can work out a cash price. I'll be at the meeting tonight (wearing a black sweater; don't just say "Randall" aloud or you'll receive a deafening chorus in reply). Randall -- Randall Lucas DF93EAD1 Tercent, Inc / SuperSurvey Online Surveys http://www.supersurvey.com From mikeraz at patch.com Wed Jan 12 12:04:44 2005 From: mikeraz at patch.com (Michael Rasmussen) Date: Wed Jan 12 12:04:55 2005 Subject: [Pdx-pm] anonymous (?) regex use Message-ID: <20050112200444.GA13036@patch.com> I'm trying to build a regex on the fly and then search an array: #!/usr/bin/perl -Tw @group = qw ( foo bar baz fuz mlr ); $regex = "/fu/"; @found = grep {$regex} @group; foreach (@found) { print "$_\n"; } but this populates @found with all members of @group. When I change the grep line to: @found = grep {/fu/} @group; then @found is populated with one element, fuz. Cluestick anyone? -- Michael Rasmussen, Portland Oregon Be appropriate && Follow your curiosity http://meme.patch.com/memes/BicycleRiding Get Fixed: http://www.dampfixie.org The fortune cookie says: Is it NOUVELLE CUISINE when 3 olives are struggling with a scallop in a plate of SAUCE MORNAY? From mikeraz at patch.com Wed Jan 12 12:11:28 2005 From: mikeraz at patch.com (Michael Rasmussen) Date: Wed Jan 12 12:11:37 2005 Subject: [Pdx-pm] anonymous (?) regex use - nevermind, solved In-Reply-To: <20050112200444.GA13036@patch.com> References: <20050112200444.GA13036@patch.com> Message-ID: <20050112201128.GA13167@patch.com> Michael Rasmussen wrote: > $regex = "/fu/"; > > @found = grep {$regex} @group; changed to $regex = "fu"; @found = grep {/$regex/} @group; is the way to do it. -- Michael Rasmussen, Portland Oregon Be appropriate && Follow your curiosity http://meme.patch.com/memes/BicycleRiding Get Fixed: http://www.dampfixie.org The fortune cookie says: Rome was not built in one day. -- John Heywood From merlyn at stonehenge.com Wed Jan 12 13:26:48 2005 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Wed Jan 12 13:26:59 2005 Subject: [Pdx-pm] anonymous (?) regex use - nevermind, solved In-Reply-To: <20050112201128.GA13167@patch.com> References: <20050112200444.GA13036@patch.com> <20050112201128.GA13167@patch.com> Message-ID: <861xcqqqxz.fsf@blue.stonehenge.com> >>>>> "Michael" == Michael Rasmussen writes: Michael> @found = grep {/$regex/} @group; or @found = grep $_ =~ $regex, @group; -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! From perl-pm at joshheumann.com Wed Jan 12 16:22:08 2005 From: perl-pm at joshheumann.com (Josh Heumann) Date: Wed Jan 12 16:22:20 2005 Subject: [Pdx-pm] January Meeting tonight Message-ID: <32787.130.94.161.146.1105575728.squirrel@joshheumann.com> January Meeting January 12th, 2005 6:30pm at Free Geek, 1741 SE 10th Ave Lightning Talks - MarvinHumphrey: Kinosearch, a Perl search engine library - GabrielleRoth: How I Integrated & Automated a Network Management System with Perl - Keith Lofstrom: Dirvish - disk-to-disk based on perl and rsync - Anyone else who wants to play! A projector and an internet connection will be provided. Afterwards, as always, beer at the Lucky Lab. From david at kineticode.com Thu Jan 13 10:04:37 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 10:04:41 2005 Subject: [Pdx-pm] Links Message-ID: <96BCE176-658D-11D9-A874-000A95B9602E@kineticode.com> PDX.pmers, I mentioned at the Lucky Lab last night that I'll be speaking at a new conference in April the Open Source Business Conference. Josh asked me to send a link, so here it is: http://www.osbc2004.com/ I also mentioned to Frank that I recalled reading an article by Mark Jason Dominus in which he took a badly written Perl program and converted it to idiomatic Perl. Here's the article, "Program Repair Shop and Red Flags," published on Perl.com: http://www.perl.com/pub/a/2000/04/raceinfo.html Enjoy, David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/220693e9/smime-0001.bin From publiustemp-pdxpm at yahoo.com Thu Jan 13 10:15:46 2005 From: publiustemp-pdxpm at yahoo.com (publiustemp-pdxpm@yahoo.com) Date: Thu Jan 13 10:15:59 2005 Subject: [Pdx-pm] Great Talks Message-ID: <20050113181547.30762.qmail@web60806.mail.yahoo.com> I just wanted to drop a note and say that last night's lightning talks were great. Sometimes those can be a hit or miss affair, but those were three of the most interesting talks I've seen in a while. Thanks! Cheers, Ovid PS: Josh, post those program notes :) ===== Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ From ben.prew at gmail.com Thu Jan 13 10:26:04 2005 From: ben.prew at gmail.com (Ben Prew) Date: Thu Jan 13 10:26:13 2005 Subject: [Pdx-pm] anonymous (?) regex use In-Reply-To: <20050112200444.GA13036@patch.com> References: <20050112200444.GA13036@patch.com> Message-ID: <24f4b2e80501131026415a7aa1@mail.gmail.com> m// is an operator. By putting "/fu/" in a string, it no longer sees // as an operator. Rather it sees it as part of a string. You want to do this: my $re = 'fu'; grep { /$re/ } @group or, more explicitely, grep { m/$re/ } @group Where m// is an operator, similar to + or *. It works for the same reason you can't do this: my $sum = "3 + 4"; print $sum; and expect to get 7. (Of course, you could print eval $sum, and get 7, but that's not the point) Hope that helps On Wed, 12 Jan 2005 12:04:44 -0800, Michael Rasmussen wrote: > I'm trying to build a regex on the fly and then search an array: > > #!/usr/bin/perl -Tw > > @group = qw ( foo bar baz fuz mlr ); > $regex = "/fu/"; > > @found = grep {$regex} @group; > > foreach (@found) { > print "$_\n"; > } > > but this populates @found with all members of @group. > When I change the grep line to: > @found = grep {/fu/} @group; > then @found is populated with one element, fuz. > > Cluestick anyone? > > -- > Michael Rasmussen, Portland Oregon > Be appropriate && Follow your curiosity > http://meme.patch.com/memes/BicycleRiding > Get Fixed: http://www.dampfixie.org > The fortune cookie says: > Is it NOUVELLE CUISINE when 3 olives are struggling with a scallop in a > plate of SAUCE MORNAY? > > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list@pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list > -- Ben Prew ben.prew@gmail.com From publiustemp-pdxpm at yahoo.com Thu Jan 13 14:02:06 2005 From: publiustemp-pdxpm at yahoo.com (Ovid) Date: Thu Jan 13 14:02:17 2005 Subject: [Pdx-pm] (OT) SQL style question Message-ID: <20050113220206.59649.qmail@web60802.mail.yahoo.com> Hi all, Sorry for the OT question (well, it's not completely OT as this impacts how Bricolage 2.0 will be implemented.) We have views that reference more than one table. Our views have a primary table they are based upon and fields from "non-primary tables." To make it very clear which fields are which, there's been a bit of discussion regarding how to make it visually distinct that a particular field is from a table that is not the primary table of the view. Which of the following is clearer? Using double underscores to separate the other table name from its field name: SELECT id, first_name, last_name, other_table__id, other_table__name FROM some_view Quoting column names and using periods as separators: SELECT "id", "first_name", "last_name", "other_table.id", "other_table.name" FROM some_view Is the latter portable? Is the former too confusing? Which is easier to read? Are there reasonable alternatives? Cheers, Ovid ===== Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ From tex at off.org Thu Jan 13 14:15:07 2005 From: tex at off.org (Austin Schutz) Date: Thu Jan 13 14:15:16 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <20050113220206.59649.qmail@web60802.mail.yahoo.com> References: <20050113220206.59649.qmail@web60802.mail.yahoo.com> Message-ID: <20050113221507.GH5945@gblx.net> On Thu, Jan 13, 2005 at 02:02:06PM -0800, Ovid wrote: > Hi all, > > Sorry for the OT question (well, it's not completely OT as this impacts > how Bricolage 2.0 will be implemented.) > > We have views that reference more than one table. Our views have a > primary table they are based upon and fields from "non-primary tables." > To make it very clear which fields are which, there's been a bit of > discussion regarding how to make it visually distinct that a particular > field is from a table that is not the primary table of the view. Which > of the following is clearer? > > Using double underscores to separate the other table name from its > field name: > > SELECT id, > first_name, > last_name, > other_table__id, > other_table__name > FROM some_view > Seems quite clear to me. > Quoting column names and using periods as separators: > > SELECT "id", > "first_name", > "last_name", > "other_table.id", > "other_table.name" > FROM some_view > This scares me. I'm not sure if it's portable, but it will _definitely_ bite you when someone forgets the "s. I've never even seen this done before.. what happens when you join something with the view and need to specify a column? SELECT some_view."other_table.id" ? Scary. > Is the latter portable? Is the former too confusing? Which is easier > to read? Are there reasonable alternatives? I don't know of any alternatives, but I'd be interested to know if there were. Austin From kyle at cepaso.com Thu Jan 13 14:26:25 2005 From: kyle at cepaso.com (Kyle Dawkins) Date: Thu Jan 13 14:27:00 2005 Subject: [Pdx-pm] (OT) SQL style question Message-ID: <37425476-65B2-11D9-82BC-000393635E16@cepaso.com> > We have views that reference more than one table. Our views have a > primary table they are based upon and fields from "non-primary tables." > To make it very clear which fields are which, there's been a bit of > discussion regarding how to make it visually distinct that a particular > field is from a table that is not the primary table of the view. Which > of the following is clearer? Just out of curiosity, why do you need to know this at all? If I were an app developer, I wouldn't want to know -- or have to care -- which table it came from. The whole point of views (surely?) is to have the DB do the muscle work of presenting to you, in a format that looks like a unified table, data aggregated from different places. If you require your app layer to know that information, what's the point of doing it in the first place? Just my 2 cents... and I'm probably missing something... Kyle Central Park Software From david at kineticode.com Thu Jan 13 14:29:39 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 14:29:44 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <20050113221507.GH5945@gblx.net> References: <20050113220206.59649.qmail@web60802.mail.yahoo.com> <20050113221507.GH5945@gblx.net> Message-ID: <9CF8E1D6-65B2-11D9-A874-000A95B9602E@kineticode.com> On Jan 13, 2005, at 2:15 PM, Austin Schutz wrote: > This scares me. I'm not sure if it's portable, but it will > _definitely_ bite you when someone forgets the "s. I believe that double-quotes are the SQL-standard way of using non-standard character in entity names in a database. So it should be portable. > I've never even > seen this done before.. what happens when you join something with the > view and need to specify a column? SELECT some_view."other_table.id" ? > Scary. Yes, that's exactly what you do. > I don't know of any alternatives, but I'd be interested to know > if there were. Me, too! I know that there are other characters you can use, but your options are limited. Allowed characters generally only allow a-zA-Z_ (I'd kill to be able to use "-", but it's not to be). But there is variation. PostgreSQL, for example, allows you to use "$". But this would be confusing to me: SELECT id, first_name, last_name, other_table$id, other_table$name FROM some_view ...especially since $ means something in both Perl and PostgreSQL functions. PostgreSQL also allows the use of Unicode characters over a certain number. So, for example, I could do: SELECT id, first_name, last_name, other_table?id, other_table?name FROM some_view But the trouble with these solutions is that neither of them is very portable. :-( I kind of like the dot notation, as it means exactly what it represents: A reference to another column in another table. Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/b236eb8b/smime.bin From jeff at vpservices.com Thu Jan 13 14:42:57 2005 From: jeff at vpservices.com (Jeff Zucker) Date: Thu Jan 13 14:42:13 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <9CF8E1D6-65B2-11D9-A874-000A95B9602E@kineticode.com> References: <20050113220206.59649.qmail@web60802.mail.yahoo.com> <20050113221507.GH5945@gblx.net> <9CF8E1D6-65B2-11D9-A874-000A95B9602E@kineticode.com> Message-ID: <41E6F971.1000002@vpservices.com> David Wheeler wrote: > I believe that double-quotes are the SQL-standard way of using > non-standard character in entity names in a database. True. > So it should be portable. Not true :-(. For example, MySQL uses backticks (ugh) as the default delimiter for identifiers. It will accept the standard double-quote character only if the database server was started with the ANSI_Quotes flag. MS Access uses square brackets as identifier delimiters, although I think it also accepts double-quote. -- Jeff From david at kineticode.com Thu Jan 13 14:45:13 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 14:45:18 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <41E6F971.1000002@vpservices.com> References: <20050113220206.59649.qmail@web60802.mail.yahoo.com> <20050113221507.GH5945@gblx.net> <9CF8E1D6-65B2-11D9-A874-000A95B9602E@kineticode.com> <41E6F971.1000002@vpservices.com> Message-ID: On Jan 13, 2005, at 2:42 PM, Jeff Zucker wrote: >> So it should be portable. > > Not true :-(. > > For example, MySQL uses backticks (ugh) as the default delimiter for > identifiers. It will accept the standard double-quote character only > if the database server was started with the ANSI_Quotes flag. MS > Access uses square brackets as identifier delimiters, although I think > it also accepts double-quote. Yet another reason not to use MySQL. Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/1e3b459c/smime-0001.bin From kyle at cepaso.com Thu Jan 13 15:16:13 2005 From: kyle at cepaso.com (Kyle Dawkins) Date: Thu Jan 13 15:16:29 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <04547AFD-65B4-11D9-A874-000A95B9602E@kineticode.com> References: <37425476-65B2-11D9-82BC-000393635E16@cepaso.com> <04547AFD-65B4-11D9-A874-000A95B9602E@kineticode.com> Message-ID: <1E406A9A-65B9-11D9-82BC-000393635E16@cepaso.com> But why does that have anything to do with column or table names? That information should all be in your O-R model, not in the DB schema. The whole point of passing objects into (and receiving them out of) an O-R model is to *abstract* the workings of the underlying datastore. If you're finding yourself wondering about this kind of thing, maybe the O-R abstraction is the problem (and in this case, not abstract enough it seems), not the underscores or periods or backticks or quotation marks in the column names... But... there are always good reasons to have a thin abstraction layer, and since I don't know all the details, it's definitely not my place to make any more statements about what you should or shouldn't do. How do you model classes? And relationships? And how do you fetch and save objects? Maybe there's a way to get in there at the right point and map the columns in question to the objects in question without your app-level code ever needing to know about it. Cheers Kyle Central Park Software On 13/01/2005, at 14:39, David Wheeler wrote: > On Jan 13, 2005, at 2:26 PM, Kyle Dawkins wrote: > >> Just out of curiosity, why do you need to know this at all? If I >> were an app developer, I wouldn't want to know -- or have to care -- >> which table it came from. The whole point of views (surely?) is to >> have the DB do the muscle work of presenting to you, in a format that >> looks like a unified table, data aggregated from different places. >> If you require your app layer to know that information, what's the >> point of doing it in the first place? > > Because the related columns actually represent separate (contained) > *objects*. So we need a class name as well as the attribute name. > > Regards, > > David From david at kineticode.com Thu Jan 13 15:19:24 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 15:19:29 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <1E406A9A-65B9-11D9-82BC-000393635E16@cepaso.com> References: <37425476-65B2-11D9-82BC-000393635E16@cepaso.com> <04547AFD-65B4-11D9-A874-000A95B9602E@kineticode.com> <1E406A9A-65B9-11D9-82BC-000393635E16@cepaso.com> Message-ID: <904BB2D1-65B9-11D9-A874-000A95B9602E@kineticode.com> On Jan 13, 2005, at 3:16 PM, Kyle Dawkins wrote: > But why does that have anything to do with column or table names? > That information should all be in your O-R model, not in the DB > schema. The whole point of passing objects into (and receiving them > out of) an O-R model is to *abstract* the workings of the underlying > datastore. If you're finding yourself wondering about this kind of > thing, maybe the O-R abstraction is the problem (and in this case, not > abstract enough it seems), not the underscores or periods or backticks > or quotation marks in the column names... It's the O-R abstraction that we're creating. We want to take advantage of the features of each database to the fullest extent, so we're using views to represent compound objects. In sort, we're using the database as the O-R layer itself. But there need to be some conventions when naming things. > But... there are always good reasons to have a thin abstraction layer, > and since I don't know all the details, it's definitely not my place > to make any more statements about what you should or shouldn't do. > How do you model classes? And relationships? And how do you fetch > and save objects? Maybe there's a way to get in there at the right > point and map the columns in question to the objects in question > without your app-level code ever needing to know about it. The app-level code won't need to know, but the abstraction layer will, and that's what we're working on. Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/7f5f292f/smime.bin From jeff at vpservices.com Thu Jan 13 15:20:13 2005 From: jeff at vpservices.com (Jeff Zucker) Date: Thu Jan 13 15:19:31 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: References: <20050113220206.59649.qmail@web60802.mail.yahoo.com> <20050113221507.GH5945@gblx.net> <9CF8E1D6-65B2-11D9-A874-000A95B9602E@kineticode.com> <41E6F971.1000002@vpservices.com> Message-ID: <41E7022D.6040403@vpservices.com> David Wheeler wrote: > On Jan 13, 2005, at 2:42 PM, Jeff Zucker wrote: > >>> So it should be portable. >> >> >> Not true :-(. >> >> For example, MySQL uses backticks (ugh) as the default delimiter for >> identifiers. It will accept the standard double-quote character only >> if the database server was started with the ANSI_Quotes flag. MS >> Access uses square brackets as identifier delimiters, although I >> think it also accepts double-quote. > > > Yet another reason not to use MySQL. True, but "portable" does not mean "portable to all reasonable systems", otherwise, there would be no need for things like ActivePerl :-). -- Jeff From rlucas at tercent.com Thu Jan 13 15:19:53 2005 From: rlucas at tercent.com (Randall Lucas) Date: Thu Jan 13 15:20:19 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <20050113224528.660E417774@x6.develooper.com> References: <20050113224528.660E417774@x6.develooper.com> Message-ID: <41E70219.5030300@tercent.com> > Quoting column names and using periods as separators: I recommend against this, even if all your target database platforms support escaped identifier names with periods in them. For one thing, Class::DBI (and/or at least some of its related modules) doesn't play nice with quoted names. I got a good ways into an implementation that worked with all of my own software, using odd but escaped names on Postgres, but found myself in a world of hurt when trying to use a number of automation tools for SQL. If you have the luxury, ban leading, trailing, and double underscores in all db identifiers except for the prefixed names. That should preserve uniqueness of __ so that you can do a s/__/\./g to change names back. Having names that m/^\w+$/ will be a lot easier for you in the end, I think. Best, Randall -- Randall Lucas DF93EAD1 Tercent, Inc / SuperSurvey Online Surveys http://www.supersurvey.com From david at kineticode.com Thu Jan 13 15:21:34 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 15:21:37 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <200501131443.42023.josh@agliodbs.com> References: <20050113220206.59649.qmail@web60802.mail.yahoo.com> <20050113221507.GH5945@gblx.net> <9CF8E1D6-65B2-11D9-A874-000A95B9602E@kineticode.com> <200501131443.42023.josh@agliodbs.com> Message-ID: On Jan 13, 2005, at 2:43 PM, Josh Berkus wrote: > The problem with using "." is that, if you join a view to something > else, it > can become really messed up: > > SELECT payroll_view."payroll.id", more_people.name > FROM payroll_view JOIN more_people .... > > Frankly, if I saw payroll_view."payroll.id" in code somewhere, I'd > assume it > was a typo and change it to: > payroll_view.payroll.id > > ... which would get me a "no such schema payroll_view" error for my > troubles. Oh, right, I quite forgot that double-dot notation is legitimate SQL (schema.table.column). Ick. Okay, double-underscores it is, I guess. At least that frees us from having to use double-quotes. Thanks for your feedback, Josh. Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/e0af9e9a/smime.bin From david at kineticode.com Thu Jan 13 15:25:37 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 15:25:51 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <41E7022D.6040403@vpservices.com> References: <20050113220206.59649.qmail@web60802.mail.yahoo.com> <20050113221507.GH5945@gblx.net> <9CF8E1D6-65B2-11D9-A874-000A95B9602E@kineticode.com> <41E6F971.1000002@vpservices.com> <41E7022D.6040403@vpservices.com> Message-ID: <6E6E7B9C-65BA-11D9-A874-000A95B9602E@kineticode.com> On Jan 13, 2005, at 3:20 PM, Jeff Zucker wrote: >> Yet another reason not to use MySQL. > > True, but "portable" does not mean "portable to all reasonable > systems", otherwise, there would be no need for things like ActivePerl > :-). It depends on your definition of "reasonable," I suppose. ;-) Regards, David (who hopes that MySQL 5.0 is more, um, standard) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/004b7bde/smime-0001.bin From david at kineticode.com Thu Jan 13 15:27:38 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 15:27:41 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <41E70219.5030300@tercent.com> References: <20050113224528.660E417774@x6.develooper.com> <41E70219.5030300@tercent.com> Message-ID: On Jan 13, 2005, at 3:19 PM, Randall Lucas wrote: > I recommend against this, even if all your target database platforms > support escaped identifier names with periods in them. For one thing, > Class::DBI (and/or at least some of its related modules) doesn't play > nice with quoted names. I got a good ways into an implementation that > worked with all of my own software, using odd but escaped names on > Postgres, but found myself in a world of hurt when trying to use a > number of automation tools for SQL. Only an issue if you're using Class::DBI. > If you have the luxury, ban leading, trailing, and double underscores > in all db identifiers except for the prefixed names. That should > preserve uniqueness of __ so that you can do a s/__/\./g to change > names back. Yes, that's where I'm leaning now. Then we just have to deal with the overhead of that conversion for each column name. > Having names that m/^\w+$/ will be a lot easier for you in the end, I > think. Fair enough. Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/bc0f8004/smime.bin From tex at off.org Thu Jan 13 15:33:10 2005 From: tex at off.org (Austin Schutz) Date: Thu Jan 13 15:33:18 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <41E70219.5030300@tercent.com> References: <20050113224528.660E417774@x6.develooper.com> <41E70219.5030300@tercent.com> Message-ID: <20050113233310.GI5945@gblx.net> On Thu, Jan 13, 2005 at 03:19:53PM -0800, Randall Lucas wrote: > > Quoting column names and using periods as separators: > > I recommend against this, even if all your target database platforms > support escaped identifier names with periods in them. For one thing, > Class::DBI (and/or at least some of its related modules) doesn't play > nice with quoted names. I got a good ways into an implementation that > worked with all of my own software, using odd but escaped names on > Postgres, but found myself in a world of hurt when trying to use a > number of automation tools for SQL. > > If you have the luxury, ban leading, trailing, and double underscores in > all db identifiers except for the prefixed names. That should preserve > uniqueness of __ so that you can do a s/__/\./g to change names back. > This is pretty unrelated, but it reminded me of something truly obvious I "discovered" recently. Perl let's you use qq{}; as a double quoting mechanism. That's really handy for code like: $statement = qq{ SELECT $table."bar.baz" FROM $table where "bar.baz" LIKE 'STUFF%' }; where you have both single and double quotes in the mix. Also makes it easy to maintain indentation without too much ugliness, as opposed to constructs like $statement = <<' EOF' SELECT ... EOF ; One of those features in perl that I always knew about but never considered using until fairly recently. Well, I did say it was obvious. :-) Austin From kyle at cepaso.com Thu Jan 13 16:01:36 2005 From: kyle at cepaso.com (Kyle Dawkins) Date: Thu Jan 13 16:01:53 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <904BB2D1-65B9-11D9-A874-000A95B9602E@kineticode.com> References: <37425476-65B2-11D9-82BC-000393635E16@cepaso.com> <04547AFD-65B4-11D9-A874-000A95B9602E@kineticode.com> <1E406A9A-65B9-11D9-82BC-000393635E16@cepaso.com> <904BB2D1-65B9-11D9-A874-000A95B9602E@kineticode.com> Message-ID: <74FD4EAA-65BF-11D9-82BC-000393635E16@cepaso.com> > It's the O-R abstraction that we're creating. We want to take > advantage of the features of each database to the fullest extent, so > we're using views to represent compound objects. In sort, we're using > the database as the O-R layer itself. But there need to be some > conventions when naming things. Well, here's where I am still not quite getting you... if you are creating an abstraction, then store the meta-information in your O-R model, not in the DB column names... if your abstraction needs to know that columns A, B and C come from table X and columns D and E come from table Y, then why wouldn't you store that in your model? I don't quite understand why you need to derive that information from the DB schema... especially since you want to support different DBs, which will almost certainly have different naming conventions. You should move it up into a mapping system, and perform all reads through that mapping system. >> But... there are always good reasons to have a thin abstraction >> layer, and since I don't know all the details, it's definitely not my >> place to make any more statements about what you should or shouldn't >> do. How do you model classes? And relationships? And how do you >> fetch and save objects? Maybe there's a way to get in there at the >> right point and map the columns in question to the objects in >> question without your app-level code ever needing to know about it. > > The app-level code won't need to know, but the abstraction layer will, > and that's what we're working on. Good good... definitely the right idea. But if you haven't already started a higher-level model of your underlying DB schema, now is the time. It will save you tons of grief and prevent you needing to answer the question you posed to this list because the whole issue becomes moot; all column names become irrelevant (which doesn't mean you shouldn't name them consistently, just that the format you use is not relevant to your code). Cheers 2 all! Kyle Central Park Software From kevin.long at iovation.com Thu Jan 13 16:12:29 2005 From: kevin.long at iovation.com (Kevin Long) Date: Thu Jan 13 16:11:27 2005 Subject: [Pdx-pm] (OT) SQL style question Message-ID: I have use _DOT_ in the past. I would also consider other human readable alternatives like _CONTAINS_ which conveys more meaning and avoids the difficulty of seeing a difference between A_VERY_LONG__THING and A_VERY_LONG_THING Kevin Ernest Long | Creator of Cool Office: +1 503 224 6010 x 248 | Fax: +1 503 224 1581 | Home Office & Mobile: +1 503 888 6879 -----Original Message----- From: pdx-pm-list-bounces@pm.org [mailto:pdx-pm-list-bounces@pm.org] On Behalf Of Austin Schutz Sent: Thursday, January 13, 2005 3:33 PM To: Randall Lucas Cc: pdx-pm-list@pm.org Subject: Re: [Pdx-pm] (OT) SQL style question On Thu, Jan 13, 2005 at 03:19:53PM -0800, Randall Lucas wrote: > > Quoting column names and using periods as separators: > > I recommend against this, even if all your target database platforms > support escaped identifier names with periods in them. For one thing, > Class::DBI (and/or at least some of its related modules) doesn't play > nice with quoted names. I got a good ways into an implementation that > worked with all of my own software, using odd but escaped names on > Postgres, but found myself in a world of hurt when trying to use a > number of automation tools for SQL. > > If you have the luxury, ban leading, trailing, and double underscores in > all db identifiers except for the prefixed names. That should preserve > uniqueness of __ so that you can do a s/__/\./g to change names back. > This is pretty unrelated, but it reminded me of something truly obvious I "discovered" recently. Perl let's you use qq{}; as a double quoting mechanism. That's really handy for code like: $statement = qq{ SELECT $table."bar.baz" FROM $table where "bar.baz" LIKE 'STUFF%' }; where you have both single and double quotes in the mix. Also makes it easy to maintain indentation without too much ugliness, as opposed to constructs like $statement = <<' EOF' SELECT ... EOF ; One of those features in perl that I always knew about but never considered using until fairly recently. Well, I did say it was obvious. :-) Austin _______________________________________________ Pdx-pm-list mailing list Pdx-pm-list@pm.org http://mail.pm.org/mailman/listinfo/pdx-pm-list The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please notify the sender by reply email and delete the message and any attachments. From david at kineticode.com Thu Jan 13 16:32:49 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 16:32:53 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: <74FD4EAA-65BF-11D9-82BC-000393635E16@cepaso.com> References: <37425476-65B2-11D9-82BC-000393635E16@cepaso.com> <04547AFD-65B4-11D9-A874-000A95B9602E@kineticode.com> <1E406A9A-65B9-11D9-82BC-000393635E16@cepaso.com> <904BB2D1-65B9-11D9-A874-000A95B9602E@kineticode.com> <74FD4EAA-65BF-11D9-82BC-000393635E16@cepaso.com> Message-ID: On Jan 13, 2005, at 4:01 PM, Kyle Dawkins wrote: > Well, here's where I am still not quite getting you... if you are > creating an abstraction, then store the meta-information in your O-R > model, not in the DB column names... if your abstraction needs to know > that columns A, B and C come from table X and columns D and E come > from table Y, then why wouldn't you store that in your model? I don't > quite understand why you need to derive that information from the DB > schema... especially since you want to support different DBs, which > will almost certainly have different naming conventions. You should > move it up into a mapping system, and perform all reads through that > mapping system. It's more to be self-documenting, but as I said, the O-R mapper needs to know where to look, and the more opaque things are, the better. > Good good... definitely the right idea. But if you haven't already > started a higher-level model of your underlying DB schema, now is the > time. It will save you tons of grief and prevent you needing to > answer the question you posed to this list because the whole issue > becomes moot; all column names become irrelevant (which doesn't mean > you shouldn't name them consistently, just that the format you use is > not relevant to your code). It's not relevant, it just makes it easier or more difficult to write the O-R mapper or to diagnose issues when you look at the database schema directly. Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/b34d6b6c/smime.bin From david at kineticode.com Thu Jan 13 16:34:16 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 16:34:21 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: References: Message-ID: <056FA23A-65C4-11D9-A874-000A95B9602E@kineticode.com> On Jan 13, 2005, at 4:12 PM, Kevin Long wrote: > I have use _DOT_ in the past. I would also consider other human > readable > alternatives like _CONTAINS_ which conveys more meaning and avoids the > difficulty of seeing a difference between A_VERY_LONG__THING and > A_VERY_LONG_THING What if you have a column named "contains"? Recall that SQL entity names are case-insensitive unless you use quotation marks. And if you're going to use quotation marks, you might as well use a punctuation character to do the work (. or - or * or or + or something--or even -> :-)). Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/96d98d00/smime-0001.bin From kevin.long at iovation.com Thu Jan 13 16:50:09 2005 From: kevin.long at iovation.com (Kevin Long) Date: Thu Jan 13 16:49:09 2005 Subject: [Pdx-pm] (OT) SQL style question Message-ID: I had the luxury of creating a system for a large but known set of databases and tables. Additionally addition of new databases and tables that users were not interested in reporting on were not needed. You must admit that _CONTAINS_ is an unlikely name-part for a table =-) Kevin Ernest Long | Creator of Cool Office: +1 503 224 6010 x 248 | Fax: +1 503 224 1581 | Home Office & Mobile: +1 503 888 6879 -----Original Message----- From: David Wheeler [mailto:david@kineticode.com] Sent: Thursday, January 13, 2005 4:34 PM To: Kevin Long Cc: pdx-pm-list@pm.org Subject: Re: [Pdx-pm] (OT) SQL style question On Jan 13, 2005, at 4:12 PM, Kevin Long wrote: > I have use _DOT_ in the past. I would also consider other human > readable > alternatives like _CONTAINS_ which conveys more meaning and avoids the > difficulty of seeing a difference between A_VERY_LONG__THING and > A_VERY_LONG_THING What if you have a column named "contains"? Recall that SQL entity names are case-insensitive unless you use quotation marks. And if you're going to use quotation marks, you might as well use a punctuation character to do the work (. or - or * or or + or something--or even -> :-)). Regards, David The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please notify the sender by reply email and delete the message and any attachments. From perl-pm at joshheumann.com Thu Jan 13 16:57:57 2005 From: perl-pm at joshheumann.com (Josh Heumann) Date: Thu Jan 13 16:58:09 2005 Subject: [Pdx-pm] Great Talks In-Reply-To: <20050113181547.30762.qmail@web60806.mail.yahoo.com> References: <20050113181547.30762.qmail@web60806.mail.yahoo.com> Message-ID: <33633.130.94.161.146.1105664277.squirrel@joshheumann.com> > I just wanted to drop a note and say that last night's lightning talks > were great. Sometimes those can be a hit or miss affair, but those were > three of the most interesting talks I've seen in a while. Thanks! > > Cheers, > Ovid > > PS: Josh, post those program notes :) At Ovid's prompting, I have finally uploaded his code from the testing talk to the web site. They are located thusly: http://pdx.pm.org/RPG-Dice.tar.gz I will also place a link to them on the page in the kwiki about his talk. Josh From perl-pm at joshheumann.com Thu Jan 13 16:58:46 2005 From: perl-pm at joshheumann.com (Josh Heumann) Date: Thu Jan 13 16:58:57 2005 Subject: [Pdx-pm] what the cpan? Message-ID: <33441.130.94.161.146.1105664326.squirrel@joshheumann.com> Can anyone else get to http://search.cpan.org/ right now? J From david at kineticode.com Thu Jan 13 17:07:30 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 17:07:34 2005 Subject: [Pdx-pm] (OT) SQL style question In-Reply-To: References: Message-ID: On Jan 13, 2005, at 4:50 PM, Kevin Long wrote: > I had the luxury of creating a system for a large but known set of > databases and tables. Additionally addition of new databases and tables > that users were not interested in reporting on were not needed. > > You must admit that _CONTAINS_ is an unlikely name-part for a table =-) Yes, but it's not very distinctive, visually. And in a view where you might have a bunch of them, it can get to be pretty ridiculous: select * from foo; id | name | bar_contains_id | bar_contains_name | bar_contains_description | bar_contains_status | bar_contains_long_name ----+------+-----------------+------------------- +--------------------------+--------------------- +------------------------ Ick. Note that the case sensitivity wasn't retained because I didn't use double-quotes to create this table. Note that you can also run into problems when the maximum number of characters you can use in column names is limited to a low number (as it was in PostgreSQL 7.2 or 7.3, when it was 32 characters!). I much prefer __: select * from foo; id | name | bar__id | bar__name | bar_description | bar__status | bar__long_name ----+------+---------+-----------+-----------------+------------- +---------------- And me being a Perler, I don't mind using punctuation characters to add meaning. This is what we're going to do; thanks to everyone for the feedback! Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/60494cab/smime.bin From david at kineticode.com Thu Jan 13 17:08:53 2005 From: david at kineticode.com (David Wheeler) Date: Thu Jan 13 17:09:03 2005 Subject: [Pdx-pm] what the cpan? In-Reply-To: <33441.130.94.161.146.1105664326.squirrel@joshheumann.com> References: <33441.130.94.161.146.1105664326.squirrel@joshheumann.com> Message-ID: On Jan 13, 2005, at 4:58 PM, Josh Heumann wrote: > Can anyone else get to http://search.cpan.org/ right now? No. Use http://cpan.uwinnipeg.ca/htdocs/faqs/cpan-search.html while it's down. Regards, David PS: It occurred to me that it'd be awesome to get Graham interested in Kinosearch and get the dreadful search engine on search.cpan.org replaced. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2369 bytes Desc: not available Url : http://mail.pm.org/pipermail/pdx-pm-list/attachments/20050113/d09415ef/smime.bin From jkeroes at eli.net Thu Jan 13 17:32:55 2005 From: jkeroes at eli.net (Joshua Keroes) Date: Thu Jan 13 17:33:06 2005 Subject: [Pdx-pm] what the cpan? In-Reply-To: <33441.130.94.161.146.1105664326.squirrel@joshheumann.com> References: <33441.130.94.161.146.1105664326.squirrel@joshheumann.com> Message-ID: <37070C09-65CC-11D9-BDD1-000A95C466EC@eli.net> On Jan 13, 2005, at 4:58 PM, Josh Heumann wrote: > Can anyone else get to http://search.cpan.org/ right now? Nope. kobesearch.cpan.org is faster anyway. -J From nick2canz at yahoo.com Fri Jan 14 13:39:38 2005 From: nick2canz at yahoo.com (Nick Wehr) Date: Fri Jan 14 13:39:50 2005 Subject: [Pdx-pm] Re: (OT) SQL style question Message-ID: <20050114213938.37048.qmail@web50910.mail.yahoo.com> Ovid, I find the underscores to be more readable and intuitive. -nick __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From keithl at kl-ic.com Wed Jan 19 20:56:03 2005 From: keithl at kl-ic.com (Keith Lofstrom) Date: Wed Jan 19 20:56:15 2005 Subject: [Pdx-pm] Library Title sort ordering Message-ID: <20050120045603.GA24572@gate.kl-ic.com> Public libraries sort titles with various stop words ignored. For example, here are three video titles in library order: Das Boot The Castle Return of the King, The I would like to find a string comparison module that incorporates all the funny rules that librarians use to do this ordering. I am not very good at hunting through CPAN yet; a half-hour of searching through a lot of irrelevant stuff came up with Tie::Hash::Abbrev::BibRefs which does a few of the right things for different reasons. While the name of a module would be nice, some clues as to how to look through CPAN for something like this would be more useful. Of course, such clues would be based on a successful search. Keith -- Keith Lofstrom keithl@keithl.com Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs From andy at petdance.com Wed Jan 19 21:10:20 2005 From: andy at petdance.com (Andy Lester) Date: Wed Jan 19 21:10:30 2005 Subject: [Pdx-pm] Library Title sort ordering In-Reply-To: <20050120045603.GA24572@gate.kl-ic.com> References: <20050120045603.GA24572@gate.kl-ic.com> Message-ID: <95108CC0-6AA1-11D9-9ADC-000393DC3588@petdance.com> > Public libraries sort titles with various stop words ignored. All libraries do. > Das Boot > The Castle > Return of the King, The > > I would like to find a string comparison module that incorporates > all the funny rules that librarians use to do this ordering. We don't do it with rules. We use non-filing character counts, entered by humans. In a MARC record, fields that can have non-filing characters will have an indicator that tells how many there are. For example, from http://search.cpan.org/dist/MARC-Record/lib/MARC/Doc/Tutorial.pod, LDR 00903pam 2200265 a 4500 100 1 _aLogan, Robert K. _d1939- 245 14 _aThe alphabet effect / _cRobert K. Logan. The "14" in the 245 tag are the indicators, and the "4" means "skip the first 4 characters when filing this." In this case, it means to ignore "The " and just file as "alphabet effect". The lack of rules is because there's just no reliable way for the computer to figure it out. Take the Spanish article "La". If you have a book called "La Luna", you have an NFC of 3, but what if it's the movie "LA Confidential"? Or say you have the book "A Bell For Adano", and clearly it should be NFC of 2 because of the obvious "A ", but what about the book "A B C Play With Me"? Yes, there are times we'll take shortcuts when mangling data and do a simple $titlesort = $title; $title =~ s/^(A|An|The) //; but that's not really accurate, but can be close enough for prototyping. Library software guy for 14+ years now, xoxo, Andy -- Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance From perl-pm at joshheumann.com Thu Jan 20 11:44:43 2005 From: perl-pm at joshheumann.com (Josh Heumann) Date: Thu Jan 20 11:44:53 2005 Subject: [Pdx-pm] [Fwd: OSCON Call For Proposals Now Open] Message-ID: <33367.130.94.161.146.1106250283.squirrel@joshheumann.com> -------- Original Message -------- Subject: OSCON Call For Proposals Now Open From: "O'Reilly Conferences" Date: Thu, January 20, 2005 11:30 am The Call for Proposals has just opened for the 7th Annual O'Reilly Open Source Convention http://conferences.oreillynet.com/os2005/ OSCON is headed back to friendly, economical Portland, Oregon during the week of August 1-5, 2005. If you've ever wanted to join the OSCON speaker firmament, now's your chance to submit a proposal (or two) by February 13, 2005. Complete details are available on the OSCON web site, but we're particularly interested in exploring how software development is moving to another level, and how developers and businesses are adjusting to new business models and architectures. We're looking for sessions, tutorials, and workshops proposals that appeal to developers, systems and network administrators, and their managers in the following areas: - All aspects of building applications, services, and systems that use the new capabilities of the open source platform - Burning issues for Java, Mozilla, web apps, and beyond - The commoditization of software: who and/or what can show us the money? - Network-enabled collaboration - Software customizability, including software as a service - Law, licensing, politics, and how best to navigate other troubled waters Specific topics and tracks at OSCON 2005 include: Linux and other open source operating systems, Java, PHP, Python, Perl, Databases (including MySQL and PostgreSQL), Apache, XML, Applications, Ruby, and Security. Attendees have a wide range of experience, so be sure to target a particular level of experience: beginner, intermediate, advanced. Talks and tutorials should be technical; strictly no marketing presentations. Session presentations are 45 or 90 minutes long, and tutorials are either a half-day (3 hours) or a full day (6 hours). Feel free to spread the word about the Call for Proposals to your friends, family, colleagues, and compatriots. We want everyone to submit, from American women hacking artificial life into the Linux kernel to Belgian men building a better mousetrap from PHP and recycled military hardware. We mean everyone! Even if you don't want to participate as a speaker, send us your suggestions--topics you'd like to see covered, groups we should bring into the OSCON fold, extra-curricular activities we should organize--to oscon-idea@oreilly.com . This year, we're moving to the wide open spaces of the Oregon Convention Center. We've arranged for the nearby Doubletree Hotel to be our headquarters hotel--it's a short, free Max light rail ride (or a lovely walk) from the Convention Center. Registration opens in April 2005; hotel information will be available shortly. Deadline to submit a proposal is Midnight (PST), February 13. For all the conference details, go to: http://conferences.oreillynet.com/os2005/ Press coverage, blogs, photos, and news from the 2004 O'Reilly Open Source Convention can be found at: http://www.oreillynet.com/oscon2004/ Would your company like to make a big impression on the open source community? If so, consider exhibiting or becoming a sponsor. Contact Andrew Calvo at (707) 827-7176, or andrewc@oreilly.com for more info. See you Portland next summer, The O'Reilly OSCON Team ******************************************************* To change your newsletter subscription options, please visit https://epoch.oreilly.com/account/default.orm and click the "Manage My Newsletters" link. For assistance, email help@oreillynet.com O'Reilly Media, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472 ******************************************************* From allison at perl.org Thu Jan 20 19:23:30 2005 From: allison at perl.org (Allison Randal) Date: Thu Jan 20 19:23:34 2005 Subject: [Pdx-pm] Hotels for OSCON Message-ID: With the announcement going out, I'm starting to get requests for "local" information on hotels around the Convention Center. Any suggestions, or suggestions on hotels people should avoid? Allison From glim at mycybernet.net Mon Jan 24 19:45:00 2005 From: glim at mycybernet.net (glim@mycybernet.net) Date: Mon Jan 24 19:43:54 2005 Subject: [Pdx-pm] Yet Another Perl Conference North America 2005 announces call-for-papers Message-ID: YAPC::NA 2005 (Yet Another Perl Conference, North America) has just released its call-for-papers; potential and aspiring speakers can submit a presentation proposal via: http://yapc.org/America/cfp-2005.shtml The dates of the conference are Monday - Wednesday 27-29 June 2005. The location will be in downtown Toronto, Ontario, Canada. (Note that a different date block was previously announced, but has been moved to accomodate venue availability.) The close of the call-for-papers is April 18, 2005 at 11:59 pm. If you have any questions regarding the call-for-papers or speaking at YAPC::NA 2005 please email na-author@yapc.org We would love to hear from potential sponsors. Please contact the organizers at na-sponsor@yapc.org to learn about the benefits of sponsorship. Other information regarding the conference (e.g. venue, registration specifics) will be announced soon. We look forward to your submissions and a great conference! From randall at sonofhans.net Mon Jan 24 20:33:03 2005 From: randall at sonofhans.net (Randall Hansen) Date: Mon Jan 24 20:33:16 2005 Subject: [Pdx-pm] Devel::Cover, a lighting email Message-ID: <3395C374-6E8A-11D9-A17E-000A95D9E32C@sonofhans.net> Devel::Cover, or, "why I can give up crack." i ran across Devel::Cover[1] today, and wanted to share. this would have been a lightning talk if i'd found it a couple weeks ago. like some of you, i suppose, i've often wondered if i'm *really* testing all my code. i try hard for best practice: always write failing tests first; test every condition; make each line of code justify its existence with a test. Devel::Cover takes a lot of the guesswork out of this. i installed it this evening from CPAN and ran it on one of my projects, a smallish one; 12 modules, ~2k LOC including POD, ~2k tests. Devel::Cover creates a database directory of test results which it then parses into nicely readable output. you get plain text but also an HTML tree, with pages for each file and a line-by-line breakdown. i'm so tickled that i've posted the whole suite of results; take a look[2]. i started off at 98.1%, and a couple tweaks got me to 98.5%. one of the tweaks was something non-obvious (to me) that i'd missed. i wrote a new test and it passed, and i've made a mental note to watch out for similar situations. another tweak allowed me to delete a couple old lines of code that were never used or tested. running it is simple. my dev directory is pretty standard: ./lib for code and ./t for tests: just what ExtUtils::ModuleMaker would give you. i ran this: cover -delete HARNESS_PERL_SWITCHES=-MDevel::Cover make test cover as i said, it's addicting. "i'll eat dinner as soon as i get to 99%," i've been thinking. it has limitations. it says it likes some versions of perl better than others; it's pretty slow; it declares itself "alpha." for all that, it's really useful. highly recommended. r ---- 1. http://search.cpan.org/dist/Devel-Cover/lib/Devel/Cover.pm 2. http://sonofhans.net/validop/cover_db/coverage.html From schwern at pobox.com Tue Jan 25 02:51:52 2005 From: schwern at pobox.com (Michael G Schwern) Date: Tue Jan 25 02:52:02 2005 Subject: [Pdx-pm] Hotels for OSCON In-Reply-To: References: Message-ID: <20050125105152.GC14281@windhund.schwern.org> On Thu, Jan 20, 2005 at 07:23:30PM -0800, Allison Randal wrote: > With the announcement going out, I'm starting to get requests for > "local" information on hotels around the Convention Center. Any > suggestions, or suggestions on hotels people should avoid? At the low end, Hawthorne Hostel. Clean, friendly, about $20/night for dorm, $45/night for a private room. Short, direct bus ride to the conference. Free wireless. Powell's annex nearby. http://www.portlandhostel.org/ The NW Hostel. Similar attributes to the above. Bigger Powell's. :) http://www.2oregonhostels.com/nw_home.htm From allison at perl.org Tue Jan 25 13:18:32 2005 From: allison at perl.org (Allison Randal) Date: Tue Jan 25 13:18:38 2005 Subject: [Pdx-pm] Hotels for OSCON In-Reply-To: <20050125105152.GC14281@windhund.schwern.org> References: <20050125105152.GC14281@windhund.schwern.org> Message-ID: On Jan 25, 2005, at 2:51 AM, Michael G Schwern wrote: > > At the low end, Hawthorne Hostel. [...] The NW Hostel. Neat! Added: http://pdx.pm.org/kwiki/index.cgi?OSCON2005Hotels (Feel free to add and comment.) Allison From merlyn at stonehenge.com Tue Jan 25 13:41:55 2005 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Tue Jan 25 13:42:10 2005 Subject: [Pdx-pm] Yet Another Perl Conference North America 2005 announces call-for-papers In-Reply-To: References: Message-ID: <86psztnq3g.fsf@blue.stonehenge.com> >>>>> "glim" == glim writes: glim> The dates of the conference are Monday - Wednesday 27-29 June 2005. glim> The location will be in downtown Toronto, Ontario, Canada. (Note that glim> a different date block was previously announced, but has been moved to glim> accomodate venue availability.) yeah, too bad the canada location means I won't be going. I'll try to send some of the other senior Stonehenge people though. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! From perl-pm at joshheumann.com Tue Jan 25 13:55:30 2005 From: perl-pm at joshheumann.com (Josh Heumann) Date: Tue Jan 25 13:55:38 2005 Subject: [Pdx-pm] February's Meeting Message-ID: <33053.130.94.161.146.1106690130.squirrel@joshheumann.com> Mongers, As of yet, we have no topic for February's meeting (the 9th). If anyone has a topic they'd like to propose, please let me know. Josh From raa at mailporter.net Wed Jan 26 12:16:55 2005 From: raa at mailporter.net (Roderick A. Anderson) Date: Wed Jan 26 12:15:15 2005 Subject: [Pdx-pm] Simple Expert ( or Decision Support ) System Message-ID: <41F7FAB7.4090006@mailporter.net> A question to both sides of the world ( united by perl :-). I looked on CPAN and found quite a few modules but since I'm more a user than a coder and have no _real_ expert system experience I couldn't use these easily. Anyone have a pointer , or more , to some perl AI ( example ) applications. Preferably FOSS. TIA, Rod -- --- [This E-mail scanned for viruses by Declude Virus] From publiustemp-pdxpm at yahoo.com Wed Jan 26 12:26:40 2005 From: publiustemp-pdxpm at yahoo.com (Ovid) Date: Wed Jan 26 12:27:03 2005 Subject: [Pdx-pm] Simple Expert ( or Decision Support ) System In-Reply-To: <41F7FAB7.4090006@mailporter.net> Message-ID: <20050126202641.56360.qmail@web60810.mail.yahoo.com> --- "Roderick A. Anderson" wrote: > Anyone know of web based , (preferrably perl coded ) , expert or > decision support system software? Cross-replied from PLUG because I thought Perl folks might find this interesting: Ah, crud. If you ask again in a few months, I'll have AI::Prolog (http://search.cpan.org/~ovid/AI-Prolog-0.03/) stable and you'd be able to whip it out with that. Unfortunately, I have a job and only work on it in my spare time, so it's only alpha and still requires that you know Prolog :/ However, depending upon your needs, you could quite possibly use FSA::Rules (http://search.cpan.org/~dwheeler/FSA-Rules-0.21/) for something like this. Plus, if you have a GraphViz installed, it can print a graph of the underlying state machine so you can see if you've modeled it correctly. An example is at http://users.easystreet.com/ovid/images/pg_rules.png. Those are the rules we are using at work to control how PostgreSQL gets installed. I wrote a lot of that module, so you have questions, you could shoot them to me. Yet another option, though it takes some work since the docs are awful: Language::Prolog::Yaswi (http://cpan.uwinnipeg.ca/htdocs/Language-Prolog-Yaswi/Language/Prolog/Yaswi.html). It's an interface to SWI-Prolog. There are some caveats to using it and I've written a bit about it at http://use.perl.org/~Ovid/journal/22708. It's the fastest of the bunch, but it's unmaintained and requires an older version of SWI-Prolog :( Cheers, Ovid ===== If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/ From jouke at pvoice.org Thu Jan 27 04:50:12 2005 From: jouke at pvoice.org (Jouke Visser) Date: Thu Jan 27 04:50:42 2005 Subject: [Pdx-pm] Hotels for OSCON In-Reply-To: References: Message-ID: <41F8E384.2060006@pvoice.org> Allison Randal wrote: > With the announcement going out, I'm starting to get requests for > "local" information on hotels around the Convention Center. Any > suggestions, or suggestions on hotels people should avoid? Last year I stayed at La Quinta Inn at the Convention Center the week before OSCON. It was a decent, rather cheap place with friendly people over there. I can recommend it. -- /Jouke Visser/ pVoice website Personal website Mail me Skype me! -------------- next part -------------- Skipped content of type multipart/related From mikeraz at patch.com Thu Jan 27 10:08:15 2005 From: mikeraz at patch.com (Michael Rasmussen) Date: Thu Jan 27 10:08:28 2005 Subject: [Pdx-pm] regex regex Message-ID: <20050127180815.GC12300@patch.com> I have a number of scripts that filter directory contents checking for particular file names. Today I was asked "will a file named PDX200501270800KEYW.msg be processed by one of your scripts?" In reality the search is easy because I'll look for the program that handles the work for this particular business group. However, let's say I had to go through a large (i.e., bigger than I want to vgrep) number of source files. I'd want a program to look for regexes and then see if this filename would match. So I need a regex to find regexes. Or do I? Perhaps search for m|(/.*?/)| and then strip the /s and eval the remainder. Comments? -- Michael Rasmussen, Portland Oregon Be appropriate && Follow your curiosity http://meme.patch.com/memes/BicycleRiding Get Fixed: http://www.dampfixie.org The fortune cookie says: Emerson's Law of Contrariness: Our chief want in life is somebody who shall make us do what we can. Having found them, we shall then hate them for it. From jeff at zeroclue.com Thu Jan 27 10:22:17 2005 From: jeff at zeroclue.com (Jeff Lavallee) Date: Sun Jan 30 18:43:12 2005 Subject: [Pdx-pm] regex regex In-Reply-To: <20050127180815.GC12300@patch.com> References: <20050127180815.GC12300@patch.com> Message-ID: On Thu, 27 Jan 2005, Michael Rasmussen wrote: > So I need a regex to find regexes. Or do I? Perhaps search for m|(/.*?/)| and then > strip the /s and eval the remainder. This would take a little more work, as regexes may not be denoted with "m" and may not use "/" as a delimiter. i.e. /regex/ m;regex; s'regex'replace' I bet there's a CPAN module to help out with this.... jeff From publiustemp-pdxpm at yahoo.com Thu Jan 27 10:17:13 2005 From: publiustemp-pdxpm at yahoo.com (Ovid) Date: Sun Jan 30 18:43:15 2005 Subject: [Pdx-pm] regex regex In-Reply-To: <20050127180815.GC12300@patch.com> Message-ID: <20050127181713.55975.qmail@web60807.mail.yahoo.com> --- Michael Rasmussen wrote: > I'd want a program to look for regexes and then see if > this filename would > match. > > So I need a regex to find regexes. Or do I? Perhaps search for > m|(/.*?/)| and then > strip the /s and eval the remainder. > > Comments? Comments? Hmm ... let's see. You want to grab Perl code at random, eval it, and see if it does what you want. What could possibly go wrong? :) See if you can figure out PPI (http://search.cpan.org/~adamk/PPI-0.900/) This is a pure Perl parser for Perl. Out of over 38,000 files on the CPAN, it only chokes on 28. It's very robust. You could use that to much more reliably pull out regexen. However, be sure to be careful with that. if ($oops -~ /.*(?{system("rm -fr /")})/) { collect_pinkslip(); } Cheers, Ovid ===== If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/ From tex at off.org Thu Jan 27 10:41:40 2005 From: tex at off.org (Austin Schutz) Date: Sun Jan 30 18:43:18 2005 Subject: [Pdx-pm] regex regex In-Reply-To: <20050127180815.GC12300@patch.com> References: <20050127180815.GC12300@patch.com> Message-ID: <20050127184140.GB15109@gblx.net> On Thu, Jan 27, 2005 at 10:08:15AM -0800, Michael Rasmussen wrote: > I have a number of scripts that filter directory contents checking for particular file names. > > Today I was asked "will a file named PDX200501270800KEYW.msg be processed by one of your scripts?" > > In reality the search is easy because I'll look for the program that handles the work for this particular business group. > > However, let's say I had to go through a large (i.e., bigger than I want to vgrep) number of > source files. I'd want a program to look for regexes and then see if this filename would > match. > > So I need a regex to find regexes. Or do I? Perhaps search for m|(/.*?/)| and then > strip the /s and eval the remainder. > > Comments? well it's a good start, but it's not guaranteed to hit everything. You have a few problems to cover, such as: if( /foo/ or /bar/ ) { m{foo} && .... s(foo)(bar) and the multiline /x regexes, like m/ foo /x ..but it's a good start. If you have a specific directory of scripts to look at you can probably test for the existence of all these. But make sure you cover everything in `perldoc perlre`. Austin From schwern at pobox.com Thu Jan 27 12:44:51 2005 From: schwern at pobox.com (Michael G Schwern) Date: Sun Jan 30 18:43:28 2005 Subject: [Pdx-pm] regex regex In-Reply-To: <20050127180815.GC12300@patch.com> References: <20050127180815.GC12300@patch.com> Message-ID: <20050127204450.GC8513@windhund.schwern.org> On Thu, Jan 27, 2005 at 10:08:15AM -0800, Michael Rasmussen wrote: > So I need a regex to find regexes. Or do I? Perhaps search for m|(/.*?/)| and then > strip the /s and eval the remainder. > > Comments? Some hand waving in the general direction of PPI perhaps? From ben.prew at gmail.com Thu Jan 27 22:58:01 2005 From: ben.prew at gmail.com (Ben Prew) Date: Sun Jan 30 18:43:44 2005 Subject: [Pdx-pm] regex regex In-Reply-To: <20050127180815.GC12300@patch.com> References: <20050127180815.GC12300@patch.com> Message-ID: <24f4b2e8050127225874cd2846@mail.gmail.com> Yikes, if you can't vgrep the source, or don't know where the program entry point is, I would just toss the file in your dev/test site to see what it does. Otherwise, write a test... or grep -ri '=[!~].*/.*/' *.pm while not perfect, will get you pretty close, and it eliminates things like qw// and q// and qq// and others. On Thu, 27 Jan 2005 10:08:15 -0800, Michael Rasmussen wrote: > I have a number of scripts that filter directory contents checking for particular file names. > > Today I was asked "will a file named PDX200501270800KEYW.msg be processed by one of your scripts?" > > In reality the search is easy because I'll look for the program that handles the work for this particular business group. > > However, let's say I had to go through a large (i.e., bigger than I want to vgrep) number of > source files. I'd want a program to look for regexes and then see if this filename would > match. > > So I need a regex to find regexes. Or do I? Perhaps search for m|(/.*?/)| and then > strip the /s and eval the remainder. > > Comments? > > -- > Michael Rasmussen, Portland Oregon > Be appropriate && Follow your curiosity > http://meme.patch.com/memes/BicycleRiding > Get Fixed: http://www.dampfixie.org > The fortune cookie says: > Emerson's Law of Contrariness: > Our chief want in life is somebody who shall make us do what we > can. Having found them, we shall then hate them for it. > > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list@pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list > -- Ben Prew ben.prew@gmail.com From nick2canz at yahoo.com Fri Jan 28 06:31:42 2005 From: nick2canz at yahoo.com (Nick Wehr) Date: Sun Jan 30 18:44:05 2005 Subject: [Pdx-pm] I'm lost! Message-ID: <20050128143142.14485.qmail@web50901.mail.yahoo.com> I'm writing an Inline::C module...and I'm getting seg faults when I use it. When I run it through valgrind, it tells me that there are memory leaks. It says it's from the memory I allocated using Newz from the perl API. So my question is this: am I supposed to be using the API functions New, Newz, and Safefree? or should I stick with the standard malloc and free? Here's some output from valgrind: ==13668== 144672 bytes in 14 blocks are possibly lost in loss record 13 of 14 ==13668== at 0x34149540: malloc (vg_replace_malloc.c:131) ==13668== by 0x341BD23A: Perl_safesysmalloc (util.c:69) ==13668== by 0x341C9392: Perl_reentrant_init (reentr.c:143) ==13668== by 0x3416DC24: perl_construct (perl.c:295) ==13668== ==13668== LEAK SUMMARY: ==13668== definitely lost: 21290 bytes in 20 blocks. ==13668== possibly lost: 144672 bytes in 14 blocks. ==13668== still reachable: 1439929 bytes in 28708 blocks. ==13668== suppressed: 0 bytes in 0 blocks. Thanks! __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 From rootbeer at redcat.com Sun Jan 30 07:51:30 2005 From: rootbeer at redcat.com (Tom Phoenix) Date: Sun Jan 30 18:44:30 2005 Subject: [Pdx-pm] regex regex In-Reply-To: <20050127180815.GC12300@patch.com> References: <20050127180815.GC12300@patch.com> Message-ID: On Thu, 27 Jan 2005, Michael Rasmussen wrote: > So I need a regex to find regexes. Or do I? Perhaps search for > m|(/.*?/)| and then strip the /s and eval the remainder. Rather than parsing the source code, why not use the decompiler to pull out the patterns? Start with B::Concise, maybe, or one of the other B::* modules. Good luck with it! --Tom Phoenix From ewilhelm at sbcglobal.net Mon Jan 31 09:40:00 2005 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Mon Jan 31 09:36:16 2005 Subject: [Pdx-pm] I'm lost! In-Reply-To: <20050128143142.14485.qmail@web50901.mail.yahoo.com> References: <20050128143142.14485.qmail@web50901.mail.yahoo.com> Message-ID: <200501311140.00238.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Nick Wehr # on Friday 28 January 2005 08:31 am: >I'm writing an Inline::C module...and I'm getting seg faults when I > use it. When I run it through valgrind, it tells me that there are > memory leaks. ?It says it's from the memory I allocated using Newz > from the perl API. ?So my question is this: am I supposed to be > using the API functions New, Newz, and Safefree? ?or should I stick > with the standard malloc and free? Maybe a question for the Inline list (inline@perl.org). Though, I would probably want to see your code there too. Are you using objects with destructors or a functional interface where you rely on Perl's gc? You should be able to use malloc and free, as long as they don't break on your platform/compiler (I believe that's the whole reason for having the API functions: they have all the #ifdef mess builtin.) As long as you're not mixing the malloc with the Safefree, you should be okay. Your segfaults are probably coming from destroying something that is still referenced, or not destroying it before the end of the program. --Eric -- "Matter will be damaged in direct proportion to its value." --Murphy's Constant