From Peter at PSDT.com Fri Nov 1 09:52:23 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:10 2004 Subject: Perl interacting with C++ In-Reply-To: <3DC219F4@wm2.uvic.ca> Message-ID: <4.3.2.7.2.20021101075005.00aafc60@shell2.webquarry.com> At 06:06 PM 10/31/2002 -0800, nkuipers wrote: >Hello all, > >A friend of mine is very interested in Perl but does the bulk of his >programming in C++. He's currently writing a game, and he wants to be >able to >extract information from a (for example) QuakeII config file. He knows >enough >of Perl to realize that it is ideal for that sort of thing. Is there a >way to >have C++ sit on (talk to?) Perl or vice versa? Could he shunt out from his >C++ to a perl script that does it's thing and returns findings for use in the >C++ program? If so, where should I tell him to look for information? Abram told you what to do for C. If your friend is hell bent on using the extensional features of C++ (and has a good reason for it), then he might drop a line to Chip Salzenberg. Whatever there is to know about combining Perl and C++, Chip knows it (at one time he was working on what was going to be Perl 6, codenamed Topaz, written in C++). Peter Scott peter@psdt.com http://www.perldebugged.com From darren at DarrenDuncan.net Sat Nov 2 01:37:39 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:10 2004 Subject: Peter Scott on Perl 6 development lists Message-ID: I have recently gone back and started reading the Perl 6 Porters Digest, from the beginning where it appeared on perl.com (http://www.perl.com/pub/at/16), 2002.02.14. I also read Larry's one-and-a-half hour long speech transcript which was dated from mid-2000, linked to from the first message, so I have an easier time seeing when this v6 design stuff was moving forward in an organized fashion. On the fourth message, for 2002.05.21 (http://www.perl.com/pub/a/2001/05/p6pdigest/THISWEEK-20010501.html), I noticed that Peter Scott was quoted for discussions on "Perl 6 Meta", postulating the apropriateness of changing the name of the language to something else to signify how new and fresh it is. So I found it interesting that some local faces were actively involved in this planning, rather than just people "far away". Peter, can you tell me if you know, around how many people would you say are involved with designing Perl 6 and/or implementing or documenting it or Parrot? I have seen many names in the summaries, but often the same dozen or so keep appearing. Also, not having read all the archives yet, was I just seeing a one-off, or are you still involved with those planning lists. Anyway, I'm thinking I may get involved in contributing at some point, if I had the time. Good day. -- Darren Duncan From Peter at PSDT.com Sat Nov 2 08:43:36 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:10 2004 Subject: Peter Scott on Perl 6 development lists In-Reply-To: Message-ID: <4.3.2.7.2.20021102062907.00b54790@shell2.webquarry.com> At 11:37 PM 11/1/02 -0800, Duncan Darren wrote: >I have recently gone back and started reading the Perl 6 Porters >Digest, from the beginning where it appeared on perl.com >(http://www.perl.com/pub/at/16), 2002.02.14. > >I also read Larry's one-and-a-half hour long speech transcript which >was dated from mid-2000, linked to from the first message, so I have >an easier time seeing when this v6 design stuff was moving forward in >an organized fashion. > >On the fourth message, for 2002.05.21 >(http://www.perl.com/pub/a/2001/05/p6pdigest/THISWEEK-20010501.html), >I noticed that Peter Scott was quoted for discussions on "Perl 6 >Meta", postulating the apropriateness of changing the name of the >language to something else to signify how new and fresh it is. > >So I found it interesting that some local faces were actively involved >in this planning, rather than just people "far away". Well, I made a few better contributions than just name change speculations, at least until the other people on perl6-language evolved into a new species :-) Take a look at http://dev.perl.org/rfc/by-group.html. I abandoned my exception RFC to co-author the mammoth RFC 88, parts of which Larry accepted... although no one ever expected him to make so many changes to the language. The one I'm most proud of is RFC 151, which appears to have been accepted as is. >Peter, can you tell me if you know, around how many people would you >say are involved with designing Perl 6 and/or implementing or >documenting it or Parrot? I have seen many names in the summaries, >but often the same dozen or so keep appearing. It's not what you would call a step function, more like the usual Poisson distribution. So the question is how far out do you want to go into the tail? But I think you're right about the serious work being done by a dozen or so people. >Also, not having read all the archives yet, was I just seeing a >one-off, or are you still involved with those planning lists. I follow them, but right now they're over my head in discussions of bizarre new operators, superpositions, and the like. I recently gave up mailing lists for the NNTP interface via nntp.perl.org and I can follow a lot more now. Eventually they'll get on to some topic where I can make some contribution or other. >Anyway, I'm thinking I may get involved in contributing at some point, >if I had the time. Have at it! Lots of room there. Just look for perl.perl6.* groups. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From nkuipers at uvic.ca Wed Nov 6 22:05:52 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:10 2004 Subject: linked lists in perl? Message-ID: <3DCA2D3F@wm2.uvic.ca> Hello everyone, I recently acquired one of those "Essentials" pocket books; this one is called Data Structures I. The chapter I am on right now deals with linked lists. I admit that the extent of my search for link-list-like structs in Perl has been limited to scanning the index of the Camel 3rd (zilch), but does anyone know how linked lists could be emulated in Perl, if at all (since as far as I know Perl doesn't have anything like pointers...)? Just curious. Thanks, Nathanael From darren at DarrenDuncan.net Wed Nov 6 22:20:43 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:10 2004 Subject: linked lists in perl? In-Reply-To: <3DCA2D3F@wm2.uvic.ca> References: <3DCA2D3F@wm2.uvic.ca> Message-ID: Nathaniel said: >Hello everyone, >I recently acquired one of those "Essentials" pocket books; this one is called >Data Structures I. The chapter I am on right now deals with linked lists. I >admit that the extent of my search for link-list-like structs in Perl has been >limited to scanning the index of the Camel 3rd (zilch), but does anyone know >how linked lists could be emulated in Perl, if at all (since as far as I know >Perl doesn't have anything like pointers...)? >Just curious. >Thanks, >Nathanael While Perl 5 doesn't have "pointers" per se, it does have "references" for variables of any data type, which are more or less the same thing. You can either take references to existing variables and pass them around like plain scalars, or you can create new anonymous variables, where the only way to hold them is with a reference. Perl's built-in data structures are rather unique to the language in their implementation or properties, so they are flexible enough to emulate several other things you are used to. For example, Perl's arrays and hashes are both "sparse", part of which means they grow as needed when you stuff more values into them. Also, with arrays you can add or remove elements to either the front or the back end easily. I expect that some of Perl's variables make use of some linked lists in the background so that the whole array or hash don't have to be re-copied every time they grow in size. By using Perl's references, can effectively create a multi-dimensional structure with any properties you want, which can be linked like a list or a tree, including circular references like a doubly-linked list. I suggest that you examine what kind of behaviour you want and re-ask the list on how might be a way to get the behaviour you want. -- Darren Duncan From abez at abez.ca Thu Nov 7 00:16:19 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:10 2004 Subject: linked lists in perl? In-Reply-To: <3DCA2D3F@wm2.uvic.ca> Message-ID: Ok If I really had to do it this way I would use a structure like this: $node = [$val,$arref] $val would be a scalar, it could point or be anything $arref would undefined or a listref. Then to iterate you'd go $node = $node->[1]; To add a new node you'd go $node->[1] = [$val,undef]; Well that's how I'd do it. On Wed, 6 Nov 2002, nkuipers wrote: > Hello everyone, > > I recently acquired one of those "Essentials" pocket books; this one is called > Data Structures I. The chapter I am on right now deals with linked lists. I > admit that the extent of my search for link-list-like structs in Perl has been > limited to scanning the index of the Camel 3rd (zilch), but does anyone know > how linked lists could be emulated in Perl, if at all (since as far as I know > Perl doesn't have anything like pointers...)? > > Just curious. > > Thanks, > > Nathanael > -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From nkuipers at uvic.ca Thu Nov 7 11:21:04 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:10 2004 Subject: linked lists in perl? Message-ID: <3DCAC8A3@wm2.uvic.ca> >I suggest that you examine what kind of behaviour you want and re-ask the list >on how might be a way to get the behaviour you want. >-- Darren Duncan Actually I don't need a particular behavior at the moment anyway...I'm just learning about things like linked lists and stacks and queues in my spare time and am naturally curious as to their Perl homologues. Thanks to Darren and Abram for their feedback, both were informative and interesting. Cheers, Nathanael From peter at PSDT.com Thu Nov 7 18:43:03 2002 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:10 2004 Subject: linked lists in perl? In-Reply-To: <3DCA2D3F@wm2.uvic.ca> Message-ID: <4.3.2.7.2.20021107162028.00b98bd0@shell2.webquarry.com> At 08:05 PM 11/6/02 -0800, nkuipers wrote: >Hello everyone, > >I recently acquired one of those "Essentials" pocket books; this one >is called >Data Structures I. The chapter I am on right now deals with linked lists. I >admit that the extent of my search for link-list-like structs in Perl >has been >limited to scanning the index of the Camel 3rd (zilch), but does anyone know >how linked lists could be emulated in Perl, if at all When I program in C, I have to create linked lists all the time. Everyone raise your hand if you're sick of writing the same kind of code all the time for doing that and figuring out whether you've made a fencepost error in the code to find an element and insert a new one. In Perl, I've never needed a linked list. A linked list is not a "natural" structure, it's something computer programmers invented to solve certain kinds of problems because the language didn't natively support the kinds of data structures the problems called for. Well, Perl does. Most of the need for linked lists is for dynamically resizable lists. But Perl's arrays are just that. Next, there's the benefit of keeping things in sorted order with minimal disturbance when inserting a new element. AFAIK splice() results in equally minimal disturbance, although I usually just sort the whole thing when I need it and seldom have to worry about performance. Hmmm... any other reason to use a linked list instead of an array? Now, when you're talking about non-linear structures, e.g. trees, things are different; you can just use some anonymous array or hash to hold each node and make references to them for pointers. Not surprising that you didn't think Perl had pointers. For reasons unknown to me, Randal goes out of his way to avoid all mention of references in Llama III. It's a remarkable trick, actually, considering that he even discusses objects. Some time I must ask him why he did that. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From Peter at PSDT.com Mon Nov 11 14:17:23 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:10 2004 Subject: Meeting next week? Message-ID: <4.3.2.7.2.20021111121641.00b19100@shell2.webquarry.com> Okay, so next week looks prime territory for a meeting... suggestions for the day? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From Peter at PSDT.com Tue Nov 12 12:00:18 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:10 2004 Subject: Meeting next week? Message-ID: <4.3.2.7.2.20021112100016.00b20d10@shell2.webquarry.com> Okay, so next week looks prime territory for a meeting... suggestions for the day? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From nkuipers at uvic.ca Tue Nov 12 12:20:11 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:10 2004 Subject: Meeting next week? Message-ID: <3DD12034@wm2.uvic.ca> M-W evenings would work for me. I'll go out on a limb and say Tuesday. nathanael From darren at DarrenDuncan.net Tue Nov 12 14:32:21 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:10 2004 Subject: Meeting next week? In-Reply-To: <3DD12034@wm2.uvic.ca> Message-ID: On Tue, 12 Nov 2002, nkuipers wrote: > M-W evenings would work for me. I'll go out on a limb and say Tuesday. > nathanael Tuesday should probably work for me too. I have a ride that is usually at UVIC on tuesday, so I can avoid taking the bus home to the Sidney area afterwards. This said, at the last meeting I was fortunate to have a ride from someone (Rockie) to the bus stop down town, so other week days would probably also work. Regarding discussion material, if someone else doesn't have plans then I could probably give the talk this month. Currently my favorite tasks are either talking to databases or making complex web applications. That said, due to my busy work schedule, I may not have any written material to bring and would have to do it all out of my head or on the white-board (which is how I did the amateur Perl tutorials to 1st year Camosun students). Hopefully as well I can get around to drafting that new database-access module that I mentioned on the list about a month ago, so I can get feedback for it on the list-serv or at the meeting. Or, perhaps those ideas could be combined, and part of the meeting could serve the purpose of giving people practice at designing and implementing a new module which would then be cleaned up and posted on CPAN. You know, a practical team project meeting or JAD, where we could practice our Perl skills on something that would actually get used, rather than just being a throw-away example. If this idea is acceptible, then I could write a requirements document to post on the list-serv or bring to the meeting, and we could do some design stuff at the meeting. And part of that design would be coming up with a *name* for the module. Of course, having thought about this for a few months already, I already have a good idea for what I would want to do as far as design and implementation goes, so this would serve as my input into the design process. But I haven't thought out all the details yet, and so we may have a good opportunity here to consider the needs of people in the community other than myself from the beginning of implementation. I look forward to your comments. -- Darren Duncan From darren at DarrenDuncan.net Tue Nov 12 14:35:07 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:10 2004 Subject: Meeting next week? Message-ID: One more thing: thursday would probably be a conflict for me as I usually meet with some other people on thursdays. -- Darren Duncan From Peter at PSDT.com Tue Nov 12 14:38:37 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:10 2004 Subject: Meeting next week? In-Reply-To: References: <3DD12034@wm2.uvic.ca> Message-ID: <4.3.2.7.2.20021112123639.00b24100@shell2.webquarry.com> At 12:32 PM 11/12/02 -0800, Darren Duncan wrote: > > M-W evenings would work for me. I'll go out on a limb and say Tuesday. > > nathanael > >Tuesday should probably work for me too. Okay, looking like Tuesday... going, going... We could also discuss the recent Perl QOTWs (quizzes of the week). The one just finishing has been a fascinating discursion into anagrams. I know I've spent entirely too much time writing anagram code over the years. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From sm at uvic.ca Tue Nov 12 14:54:03 2002 From: sm at uvic.ca (S. Mackey) Date: Wed Aug 4 00:11:10 2004 Subject: Meeting next week? References: Message-ID: <3DD16A6B.000001.00057@bec-165-01.sfg.uvic> On Tue, 12 Nov 2002, nkuipers wrote: >> M-W evenings would work for me. I'll go out on a limb and say Tuesday. >> nathanael >Tuesday should probably work for me too. I have a ride that is usually >at UVIC on tuesday, I'm out next week. No one to turn my dogs out for me. Having said that, pick the night that works and I'll do what I can to make it :-) Susan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/archives/victoria-pm/attachments/20021112/1432e417/attachment.htm From rockie at innocent.com Tue Nov 12 21:47:33 2002 From: rockie at innocent.com (Liz or Rockie Lowe) Date: Wed Aug 4 00:11:10 2004 Subject: Fw: [discuss] Fw: [linops] 12 days of Linux Message-ID: <00a201c28ac7$663e2930$e9954218@bullwinkle2000> This is for Linux hackers only. :-) enjoy > Subject: [linops] 12 days of Linux > > > In light of the impending holiday season, I have created a song(with > some help from bronaugh) entitled the 12 days of Linux. The tune is > available here: http://www.night.net/christmas/midi/12-Days-Xmas2.mid > No groans please!! > > The 12 days of Linux > by Clint Byrum > *Sing to the tune of "The twelve days of Christmas"* > > On the 1st day of Linux > my Linus gave to me > an inode in a b-tree > > > On the 2nd day of Linux > my Linus gave to me > two posix threads > and an inode in a b-tree > > On the 3rd day of Linux > my Linus gave to me > three new vms > two posix threads > and an inode in a b-tree > > On the 4th day of Linux > my Linus gave to me > four 0wn3d b0x3n > three new vms > two posix threads > and an inode in a b-tree > > On the 5th day of Linux > my Linus gave to me > five latent pings > four 0wn3d b0x3n > three new vms > two posix threads > and an inode in a b-tree > > On the 6th day of Linux > my Linus gave to me > six super symlinks > five latent pings > four 0wn3d b0x3n > three new vms > two posix threads > and an inode in a b-tree > > On the 7th day of Linux > my Linus gave to me > seven swapped out zombies > six super symlinks > five latent pings > four 0wn3d b0x3n > three new vms > two posix threads > and an inode in a b-tree > > On the 8th day of Linux > my Linus gave to me > eight kernel panics > seven swapped out zombies > six super symlinks > five latent pings > four 0wn3d b0x3n > three new vms > two posix threads > and an inode in a b-tree > > On the 9th day of Linux > my Linus gave to me > nine newbie HOWTOs > eight kernel panics > seven swapped out zombies > six super symlinks > five latent pings > four 0wn3d b0x3n > three new vms > two posix threads > and an inode in a b-tree > > On the 10th day of Linux > my Linus gave to me > ten hackers hacking > nine newbie HOWTOs > eight kernel panics > seven swapped out zombies > six super symlinks > five latent pings > four 0wn3d b0x3n > three new vms > two posix threads > and an inode in a b-tree > > On the 11th day of Linux > my Linus gave to me > eleven file systems > ten hackers hacking > nine newbie HOWTOs > eight kernel panics > seven swapped out zombies > six super symlinks > five latent pings > four 0wn3d b0x3n > three new vms > two posix threads > and an inode in a b-tree > > On the 12th day of Linux > my Linus gave to me > twelve years of coding > eleven file systems > ten hackers hacking > nine newbie HOWTOs > eight kernel panics > seven swapped out zombies > six super symlinks > five latent pings > four 0wn3d b0x3n > three new vms > two posix threads > and an inode in a b-tree > > _______________________________________________ > Discuss mailing list > Discuss@vlug.org > http://vlug.org/mailman/listinfo/discuss From nkuipers at uvic.ca Wed Nov 13 10:36:28 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:10 2004 Subject: next meeting's topics Message-ID: <3DD241EE@wm2.uvic.ca> I may have a short blurb to contribute if you are all interested. This Thursday evening I am attending a 2-hour lecture by Lincoln Stein. Lincoln is one of the bigwigs in the bioperl project so you can bet Perl will be a point of discussion in this lecture. If I come away with anything interesting, I'd be happy to share it. Cheerio, Nathanael From darren at DarrenDuncan.net Wed Nov 13 10:48:20 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:10 2004 Subject: next meeting's topics In-Reply-To: <3DD241EE@wm2.uvic.ca> Message-ID: On Wed, 13 Nov 2002, nkuipers wrote: > I may have a short blurb to contribute if you are all interested. This > Thursday evening I am attending a 2-hour lecture by Lincoln Stein. Lincoln is > one of the bigwigs in the bioperl project so you can bet Perl will be a point > of discussion in this lecture. If I come away with anything interesting, I'd > be happy to share it. > Cheerio, > Nathanael I know who Lincoln Stein is (originally because he wrote CGI.pm), but does he live around the Victoria area or are you travelling? While I'm not a biologist myself, I do have a friend who teaches biology at UVIC or something (Ben Koop, if any of you know him). He told me that he had met Lincoln on one or several occasions through his biology connections. I might even be interested in meeting him if it is practical. -- Darren Duncan From nkuipers at uvic.ca Wed Nov 13 14:08:56 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:10 2004 Subject: Stein talk details, was RE: next meeting's topics Message-ID: <3DD2C34C@wm2.uvic.ca> Small world. Ben Koop is the bio professor I work for. The lecture in the Chan Auditorium at the BC Research Institute for Children's and Women's Health ( 950 West 28 Avenue, Vancouver) from 6-8PM on November 14th. For more information see http://vanbug.org Nathanael >===== Original Message From Darren Duncan ===== >On Wed, 13 Nov 2002, nkuipers wrote: >> I may have a short blurb to contribute if you are all interested. This >> Thursday evening I am attending a 2-hour lecture by Lincoln Stein. Lincoln is >> one of the bigwigs in the bioperl project so you can bet Perl will be a point >> of discussion in this lecture. If I come away with anything interesting, I'd >> be happy to share it. >> Cheerio, >> Nathanael > >I know who Lincoln Stein is (originally because he wrote CGI.pm), but does >he live around the Victoria area or are you travelling? While I'm not a >biologist myself, I do have a friend who teaches biology at UVIC or >something (Ben Koop, if any of you know him). He told me that he had met >Lincoln on one or several occasions through his biology connections. I >might even be interested in meeting him if it is practical. -- Darren >Duncan From Peter at PSDT.com Wed Nov 13 14:28:10 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:10 2004 Subject: Stein talk details, was RE: next meeting's topics In-Reply-To: <3DD2C34C@wm2.uvic.ca> Message-ID: <4.3.2.7.2.20021113122547.00b2fe20@shell2.webquarry.com> At 12:08 PM 11/13/02 -0800, nkuipers wrote: >Small world. Ben Koop is the bio professor I work for. > >The lecture in the Chan Auditorium at the BC Research Institute for >Children's >and Women's Health ( 950 West 28 Avenue, Vancouver) from 6-8PM on November >14th. For more information see http://vanbug.org Ah. I think I'll pass on the trip over (you're staying the night? Last ferry leaves 9pm IIRC). Might have stretched to it if it was Perl-centered. But if you get the chance, tell Lincoln I said Hi. (No, he doesn't live around here. He lives in New York.) -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From darren at DarrenDuncan.net Wed Nov 13 14:36:57 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:10 2004 Subject: Stein talk details, was RE: next meeting's topics In-Reply-To: <3DD2C34C@wm2.uvic.ca> Message-ID: On Wed, 13 Nov 2002, nkuipers wrote: > Small world. Ben Koop is the bio professor I work for. > Nathanael How nice. You can tell him I said hi. -- Darren Duncan From Peter at PSDT.com Thu Nov 14 17:31:54 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:10 2004 Subject: Meeting - Tuesday Nov 19 Message-ID: <4.3.2.7.2.20021114152908.00b43660@shell2.webquarry.com> Hearing no suggestion to the contrary, I declare next Tuesday, November 19, to be the next Victoria.pm meeting at the usual place and time (reminder details to be emailed the day before). Topic? Duncan, you want to speak? The QOTW is now discussing numbering crossword puzzles and ASCII drawings of tree structures. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From darren at DarrenDuncan.net Thu Nov 14 19:26:47 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:11 2004 Subject: Meeting - Tuesday Nov 19 In-Reply-To: <4.3.2.7.2.20021114152908.00b43660@shell2.webquarry.com> Message-ID: On Thu, 14 Nov 2002, Peter Scott wrote: > Topic? Duncan, you want to speak? Sure. There are several things that I could talk about, depending on the interests of who is there. I will try to email some preparatory materials to the list at least a day before the meeting (such as on the weekend). It probably won't be the same format as that nice lesson on object-orientedness we had last time, but I expect something should work out. I was going to talk about one or more of the following: 1. effective web applications; 2. how to talk to databases with DBI and/or general relational database theory; 3. how to design a relational database; 4. a workshop where we do some design work on a real module that provides a high-level database interface (to program code, not direct to users). Regardless of what happens at the meeting, I plan to send some specs or initial design work on the module set for #4 to the list on the weekend. Basically, aside from generic Perl fundamentals like data structures and control structures or reading/writing text files, it is the web and database stuff that I know the best and have greatest interest in. As a fore-warning, I use objects in all but the simplest of my Perl code, especially anything meant to be reusable. If any of you want to do something else at the meeting, or have specific questions you want answered then, please email them to the list in advance so there is the best chance that I can do any needed preparation (although I may not need any preparation); of course, it could be the type of question that anyone could answer on the list anyway. -- Darren Duncan From rockie at innocent.com Fri Nov 15 00:55:27 2002 From: rockie at innocent.com (Liz or Rockie Lowe) Date: Wed Aug 4 00:11:11 2004 Subject: Meeting next week? References: <3DD12034@wm2.uvic.ca> <4.3.2.7.2.20021112123639.00b24100@shell2.webquarry.com> Message-ID: <011e01c28c73$fae478c0$e9954218@bullwinkle2000> Monday is best but Tuesday is good, so lets go with Tue. From rockie at innocent.com Fri Nov 15 01:15:15 2002 From: rockie at innocent.com (Liz or Rockie Lowe) Date: Wed Aug 4 00:11:11 2004 Subject: Meeting - Tuesday Nov 19 References: Message-ID: <017101c28c76$bf0ac9a0$e9954218@bullwinkle2000> I would be interested in comparisons between the use of XML and relational database models. I don't have a specific questions, just a general interest. ----- Original Message ----- From: "Darren Duncan" To: ; "Peter Scott" Sent: Thursday, November 14, 2002 5:26 PM Subject: Re: Meeting - Tuesday Nov 19 > On Thu, 14 Nov 2002, Peter Scott wrote: > > Topic? Duncan, you want to speak? > > Sure. There are several things that I could talk about, depending on the > interests of who is there. I will try to email some preparatory materials > to the list at least a day before the meeting (such as on the weekend). > It probably won't be the same format as that nice lesson on > object-orientedness we had last time, but I expect something should work > out. I was going to talk about one or more of the following: 1. effective > web applications; 2. how to talk to databases with DBI and/or general > relational database theory; 3. how to design a relational database; 4. a > workshop where we do some design work on a real module that provides a > high-level database interface (to program code, not direct to users). > Regardless of what happens at the meeting, I plan to send some specs or > initial design work on the module set for #4 to the list on the weekend. > Basically, aside from generic Perl fundamentals like data structures and > control structures or reading/writing text files, it is the web and > database stuff that I know the best and have greatest interest in. As a > fore-warning, I use objects in all but the simplest of my Perl code, > especially anything meant to be reusable. If any of you want to do > something else at the meeting, or have specific questions you want > answered then, please email them to the list in advance so there is the > best chance that I can do any needed preparation (although I may not > need any preparation); of course, it could be the type of question that > anyone could answer on the list anyway. -- Darren Duncan > From darren at DarrenDuncan.net Fri Nov 15 11:09:52 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:11 2004 Subject: Meeting - Tuesday Nov 19 In-Reply-To: <017101c28c76$bf0ac9a0$e9954218@bullwinkle2000> Message-ID: On Thu, 14 Nov 2002, Liz or Rockie Lowe wrote: > I would be interested in comparisons between the use of XML and relational > database models. I don't have a specific questions, just a general interest. Sure, I can do that, since I have at least a year's experience in both. The short answer is that an XML document or an XML DOM is a tree structure with one root and many branches; while a relational database can emulate this, a relational database is more like a web where you can have multiple roots as well. As far as implementation goes, XML is stored on disk as text files, sort of like html but more generic, while relational databases are more like a set of hashes and trees. XML is better suited for small amounts of data when you want to read all the XML data into memory at once; you have to parse the whole document in order to know how to find any data in it. Relational databases are better suited for when you have a huge amount of data and you can't or don't want to read it all into memory every time. This said, once the XML is parsed in memory as a DOM, you can use XPATH expressions to fetch any data in it just as easily as an SQL expression can fetch anything in a relational database. So, I know all about theory for both XML and relationals, but I haven't actually used the Perl libraries to deal with XML before (I have read about them) so I don't know which are best for particular tasks (my coding for XML was in a different language). I have actually used DBI.pm to talk to MySQL though, so I know specific Perl code for doing that. -- Darren Duncan From Peter at PSDT.com Mon Nov 18 05:38:00 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:11 2004 Subject: Meeting reminder Message-ID: <4.3.2.7.2.20021114153156.00b43bd0@shell2.webquarry.com> Monthly Victoria.pm (Perl Mongers) meeting notice: Victoria.pm will meet tomorrow, Tuesday November 19, at UVic's McPherson Library. Meet inside in the art gallery area immediately to the right upon entering between 6:45 and 7:00. A camel will be in evidence. At 7:00 we will relocate to a suitable area. We will leave a note with the location in the art gallery area. We may be in a conference room up the stairs (which we did every time but last time) if you don't find the notice, ask the librarian where the conference rooms are and look through their doors which sport handy windows for this purpose until you find some people having way too much fun. For those unfamiliar with UVic, see http://www.uvic.ca/maps/index.html grid C3. Parking can be found at the top centre of B3. If you don't know how to get to UVic - welcome to Victoria - see http://www.uvic.ca/maps/directions.html. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From peter at PSDT.com Mon Nov 18 15:43:36 2002 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:11 2004 Subject: Meeting topic Message-ID: <4.3.2.7.2.20021118134146.00aaca80@shell2.webquarry.com> I've had an inquiry as to tomorrow night's topic. So we might as well settle on one or two. There was discussion about Darren Duncan talking on XML/database modules, or the Perl Quiz-of-the-Week (currently working on printing crossword puzzles and laying out trees in ASCII art). Comments, please. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From abez at abez.ca Mon Nov 18 15:47:11 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:11 2004 Subject: Meeting topic In-Reply-To: <4.3.2.7.2.20021118134146.00aaca80@shell2.webquarry.com> Message-ID: Maybe we should do both. On Mon, 18 Nov 2002, Peter Scott wrote: > I've had an inquiry as to tomorrow night's topic. So we might as well > settle on one or two. There was discussion about Darren Duncan talking > on XML/database modules, or the Perl Quiz-of-the-Week (currently > working on printing crossword puzzles and laying out trees in ASCII > art). Comments, please. > -- > Peter Scott > Pacific Systems Design Technologies > http://www.perldebugged.com/ > -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From darren at DarrenDuncan.net Mon Nov 18 16:07:16 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:11 2004 Subject: Meeting topic In-Reply-To: Message-ID: On Mon, 18 Nov 2002, abez wrote: > Maybe we should do both. > > On Mon, 18 Nov 2002, Peter Scott wrote: > > I've had an inquiry as to tomorrow night's topic. So we might as well > > settle on one or two. There was discussion about Darren Duncan talking > > on XML/database modules, or the Perl Quiz-of-the-Week (currently > > working on printing crossword puzzles and laying out trees in ASCII > > art). Comments, please. I agree about doing both. I should also warn you all that, regarding my talk, I wasn't able to do any preparation on the weekend due to other commitments, and probably wouldn't have more than an hour before the meeting to do so. Therefore, please do not count on being provided any written materials, and be prepared to write your own if you don't want to remember important details in your head. I apologize for this lack. So what I will probably end up doing is an overview of DBI and XML stuff with some examples, and answering your questions, verbally or on the white-board. I could probably follow up with some details on the mailing list later. -- Darren Duncan From nkuipers at uvic.ca Mon Nov 18 16:35:50 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:11 2004 Subject: Meeting topic Message-ID: <3DD9A2AA@wm2.uvic.ca> I for one am somewhat keen on XML/DBI stuff since I am approaching a stage in my work where I will want to commit my results to a searchable database. However the qotw would be a good warm-up to the session? I agree with doing both, with emphasis perhaps on the XML/DBI portion. From darren at DarrenDuncan.net Wed Nov 20 12:44:32 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:11 2004 Subject: suggest DBIx::Concept for module name? Message-ID: This comment is largely for those of you at last night's meeting who heard or participated in the end of my discussion, which involved a new Perl module I wanted to make and release on CPAN, which can be construed as a thin and fast layer on top of DBI. That is the context of the next paragraph... Perhaps something like DBIx::Concept might be a good module name. Besides being shortish and somewhat unique, it describes one of the main purposes of the module. Part of the module purpose is to let one communicate with the database using terminology or database feature concepts that more closely mirror what they actually 'mean' to ask or do. The module abstracts away the specific sql syntax for doing what they mean, usually in the more efficient manner, and sometimes implementing said features where the underlying dbms doesn't support them directly. A driving purpose is to allow application code to be easier to understand, document, change, as well as smaller or more concise. A related objective is that the program can do anything with the database by just calling functions named after what they want to do (generic with arguments) and it is so applications never have to write sql themselves (although there is allowance for this). Other module suggestions, probably not as good, include likes of 'DBIx::Portable' or 'DBIx::Abstract' or 'DBIx::Functional', but I like the sound of 'DBIx::Concept' better. I did a search on CPAN and there doesn't seem to be any existing module named 'DBIx::Concept' or similar. What do you think of my suggested module name, given what you know from discussion? -- Darren Duncan From nkuipers at uvic.ca Wed Nov 20 14:18:32 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:11 2004 Subject: suggest DBIx::Concept for module name? Message-ID: <3DDBF92A@wm2.uvic.ca> DBIx::ConceptI You're not really defining a database concept, you're just defining an interface for more intuitive (conceptual) syntax and some light, on-the-fly, no-op recovery; "Do What I Mean". You could maybe go out on a limb and call it DBIx::Intuitive(I). ;p Nathanael >===== Original Message From Darren Duncan ===== >This comment is largely for those of you at last night's meeting who heard >or participated in the end of my discussion, which involved a new Perl >module I wanted to make and release on CPAN, which can be construed as a >thin and fast layer on top of DBI. That is the context of the next >paragraph... > >Perhaps something like DBIx::Concept might be a good module name. Besides >being shortish and somewhat unique, it describes one of the main purposes >of the module. Part of the module purpose is to let one communicate with >the database using terminology or database feature concepts that more >closely mirror what they actually 'mean' to ask or do. The module >abstracts away the specific sql syntax for doing what they mean, usually >in the more efficient manner, and sometimes implementing said features >where the underlying dbms doesn't support them directly. A driving >purpose is to allow application code to be easier to understand, document, >change, as well as smaller or more concise. A related objective is that >the program can do anything with the database by just calling functions >named after what they want to do (generic with arguments) and it is so >applications never have to write sql themselves (although there is >allowance for this). Other module suggestions, >probably not as good, include likes of 'DBIx::Portable' or >'DBIx::Abstract' or 'DBIx::Functional', but I like the sound of >'DBIx::Concept' better. > >I did a search on CPAN and there doesn't seem to be any existing module >named 'DBIx::Concept' or similar. What do you think of my suggested >module name, given what you know from discussion? > >-- Darren Dunc From Peter at PSDT.com Wed Nov 20 14:20:29 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:11 2004 Subject: suggest DBIx::Concept for module name? In-Reply-To: Message-ID: <4.3.2.7.2.20021120121948.00b6ca50@shell2.webquarry.com> At 10:44 AM 11/20/02 -0800, Darren Duncan wrote: >This comment is largely for those of you at last night's meeting who heard >or participated in the end of my discussion, which involved a new Perl >module I wanted to make and release on CPAN, which can be construed as a >thin and fast layer on top of DBI. That is the context of the next >paragraph... > >Perhaps something like DBIx::Concept might be a good module name. Can you tell me what your module will do that http://search.cpan.org/dist/DBIx-Abstract/Abstract.pm doesn't? That would help me. > Besides >being shortish and somewhat unique, it describes one of the main purposes >of the module. Part of the module purpose is to let one communicate with >the database using terminology or database feature concepts that more >closely mirror what they actually 'mean' to ask or do. The module >abstracts away the specific sql syntax for doing what they mean, usually >in the more efficient manner, and sometimes implementing said features >where the underlying dbms doesn't support them directly. A driving >purpose is to allow application code to be easier to understand, document, >change, as well as smaller or more concise. A related objective is that >the program can do anything with the database by just calling functions >named after what they want to do (generic with arguments) and it is so >applications never have to write sql themselves (although there is >allowance for this). Other module suggestions, >probably not as good, include likes of 'DBIx::Portable' or >'DBIx::Abstract' or 'DBIx::Functional', but I like the sound of >'DBIx::Concept' better. > >I did a search on CPAN and there doesn't seem to be any existing module >named 'DBIx::Concept' or similar. What do you think of my suggested >module name, given what you know from discussion? > >-- Darren Duncan -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From darren at DarrenDuncan.net Wed Nov 20 14:27:14 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:11 2004 Subject: suggest DBIx::Concept for module name? In-Reply-To: <3DDBF92A@wm2.uvic.ca> Message-ID: On Wed, 20 Nov 2002, nkuipers wrote: > DBIx::ConceptI > You're not really defining a database concept, you're just defining an > interface > for more intuitive (conceptual) syntax and some light, on-the-fly, no-op > recovery; "Do What I Mean". You could maybe go out on a limb and call it > DBIx::Intuitive(I). ;p > Nathanael Thanks for the quick feedback, Nathaneal. And while short, this is a good enough argument to make me rethink this. Here's a question: I actually thought of 'DBIx::Conceptual' first, with 'Concept' for short; would the longer name make any difference? I do agree with the idea behind having 'I' or 'Interface' in the name as far as making it descriptive goes, although I'm not sure if it is practical. Technically, the 'DBI' part already implies that this is an interface, so what is another 'I' good for? Also, I should clarify that I didn't intend for my module to be an artificial intelligence. It is still meant to take precise and unambiguous input as to what the user wants to happen. It is more just being creative as to the precise implementation, because the precise implementation for the same task varies by the DBMS. While someone could extend it so, I didn't want to get into AI since this would make it fat (lots of calculations to make an educated guess) and more error prone (guessing wrong). Thank you. -- Darren Duncan From darren at DarrenDuncan.net Wed Nov 20 16:07:22 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:11 2004 Subject: suggest DBIx::Concept for module name? In-Reply-To: <4.3.2.7.2.20021120121948.00b6ca50@shell2.webquarry.com> Message-ID: On Wed, 20 Nov 2002, Peter Scott wrote: > Can you tell me what your module will do that > http://search.cpan.org/dist/DBIx-Abstract/Abstract.pm doesn't? That > would help me. Yes I can. However, given that both modules are meaning to solve similar problems, and would look similar on the surface, I would have to go a bit more into detail with my answers. (Note: I downloaded the module and looked at its source code, not just its documentation.) For the moment, here is an unordered list of things that I noticed: 1. DBIx::Abstract does all of its work in a single module, which has to be updated to add support for new database vendors or improve existing ones; as that happens, the module gets larger and more complex. My approach has a separate module for each database that contains its details; this separation makes it easier to understand and extend; new databases can be added as new files without requiring changes to existing files (of course, similar database-specific files can still be made to subclass each other). This is like the approach that DBI itself uses. 2. DBIx::Abstract saves log files of its activity or errors, and makes use of a global filehandle 'LOG'. My approach does not talk to the file system at all, thereby keeping more focused; it returns errors or debugging info as output to the calling code; users of my modules can use something else more focused on log-keeping instead. 3. DBIx::Abstract contains at least 1 of what it calls a 'hack' to make Oracle look like other dbs (in the connection string); the module defaults to wanting to deal with ODBC style. Although this in itself may not be an issue, my approach wouldn't have such 'hacks'. 4. DBIx::Abstract closely ties itself to the existing (although stable) DBI interface. A greater part of its functions just pass through to the DBI function with the same name. Also, several DBIx::Abstract functions take DBI objects as input or return them as output. My approach will have a fully independent interface which may resemble that of DBI only where it seems like common sense. My approach will never expose a DBI object to the caller, since this breaks my control over the calling interface, and because I may not always use DBI internally for all databases (although that is unlikely, I want to be flexible), so it wouldn't be reliable. 5. My approach would provide more functionality than DBIx::Abstract, such as inserting a whole 'recordset' at once (possibly in multiple related tables) rather than a single record at once, or such as implementing table creation and removal, or such as including generically defined subselects or unions or hierarchical joins or such in select statements, or implementing 'paging' in select statements like 'return rows 11-20 of this' or 'resort the list but keep this record in the selected page'. 6. DBIx::Abstract sometimes requires the caller to provide fragments of literal sql to embed in statements, where I wouldn't. DBIx::Abstract lets the caller run any arbitrary sql statement passed in as a string, where I would require there to be a separately defined 'stored callback function' that contains the sql instead. 7. I would make it easier to use the 'stored procedure' functionality built into many databases, as well as to imitate the behaviour that stored procedures would do in Perl for databases that don't do stored procedures (the main application wouldn't have to know the difference). The application can just do something like '$result = $dbi->my_proc( "arg" )' rather than '$dbi->query( "CALL my_proc( :OUT_VAR, :IN_VAR )", {} )'; syntax for stored procedures varies by the DBMS. 8. Join conditions don't have to be passed in as a sql fragment with my approach; rather I would take a list (or an object having a list) of table fields to match up as well as whether it is equal or outer join etcetera; this would (especially outer joins) turn into different sql depending on the database. DBIx::Abstract doesn't seem to deal with building join conditions. 9. Technically, my approach will be 'less thin' than DBIx::Abstract, but it would also be 'more abstract'. In summary, while I could make change requests to the author of 'DBIx::Abstract' (the likes of which CPAN encourages), I don't think he will be able to approach what I am offering without rewriting it from scratch. There actually are a lot of differences. So if that's necessary, why don't I just 'rewrite it'? And if so, better to have a different module name so people don't expect it to be native-backwards-compatible. Note: My approach is designed to be low-level enough and flexible enough that most of the existing database abstraction modules could be simulated or emulated with a separate compatability layer module sitting on top of mine. This would help migration, if the move would help anyone. Scott, If this doesn't answer your question, then please ask me more detailed questions to flesh it out. -- Darren Duncan From nkuipers at uvic.ca Wed Nov 20 20:07:31 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:11 2004 Subject: inlining a method return Message-ID: <4.3.2.7.2.20021120180534.00b6e240@shell2.webquarry.com> [This is being redirected by Peter since it bounced because it matches /^sub\b/m, which is an administrative request. I've changed the lidst options to ignore things like this from now on. This should look to you like it came from Nathanael.] At least, I think inlining is the appropriate term. Here's the situation. I have a sequence object which has a get/set method for most of its properties. For example: sub seq { my $caller = shift; die "No object.\n" unless ref $caller; @_ ? $caller->{SEQUENCE} = $_[0] : $caller->{SEQUENCE}; } This allows something like print "This is the sequence: ",$obj->seq,"\n"; Moreover, $obj->seq can be inlined with something like length, as in my len method: sub len { my $caller = shift; die "No object.\n" unless ref $caller; $caller->bare; length( $caller->seq ); } Finally, I can use msy/// on the sequence key directly, as in: sub bare { my $caller = shift; die "No object.\n" unless ref $caller; $caller->{SEQUENCE} =~ s/[^rndeqhilkmfpswyvacgtux*-]//gi; } However, I cannot say something like this: sub residues { my $caller = shift; die "No object.\n" unless ref $caller; my %args = ( GC => '', @_ ); $caller->bare; $caller->uppercase; my $p = $caller->profile; #begin problem line $p->{$1}++ while $caller->seq =~ m/([ARNDCQEGHILKMFPSTWYVU])/g; #end problem line if ( $args{GC} ) { die "%GC on a protein.\n" unless ( $caller->is_dna || $caller->is_rna ); no warnings; my $gc = ( $p->{G} + $p->{C} ) / $caller->len * 100; } } How would I inline a get/set method so that I could use it in a msy/// statement directly rather than first setting a $tmp variable and using the $tmp (which is my current workaround)? Many thanks, Nathanael From Peter at PSDT.com Wed Nov 20 20:15:21 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:11 2004 Subject: inlining a method return In-Reply-To: <200211210247.gAL2lG705733@mail.pm.org> Message-ID: <4.3.2.7.2.20021120180929.00b754d0@shell2.webquarry.com> >At least, I think inlining is the appropriate term. No, "lvalue" is what you mean. >Here's the situation. I have a sequence object which has a get/set >method for >most of its properties. For example: > >sub seq { > my $caller = shift; > die "No object.\n" unless ref $caller; > @_ ? $caller->{SEQUENCE} = $_[0] : $caller->{SEQUENCE}; >} > >This allows something like > >print "This is the sequence: ",$obj->seq,"\n"; > >Moreover, $obj->seq can be inlined with something like length, as in my len >method: > >sub len { > my $caller = shift; > die "No object.\n" unless ref $caller; > $caller->bare; > length( $caller->seq ); >} > >Finally, I can use msy/// on the sequence key directly, as in: > >sub bare { > my $caller = shift; > die "No object.\n" unless ref $caller; > $caller->{SEQUENCE} =~ s/[^rndeqhilkmfpswyvacgtux*-]//gi; >} > >However, I cannot say something like this: > >sub residues { > my $caller = shift; > die "No object.\n" unless ref $caller; > my %args = ( GC => '', @_ ); > $caller->bare; > $caller->uppercase; > my $p = $caller->profile; > #begin problem line > $p->{$1}++ while $caller->seq =~ m/([ARNDCQEGHILKMFPSTWYVU])/g; > #end problem line > if ( $args{GC} ) { > die "%GC on a protein.\n" > unless ( $caller->is_dna || $caller->is_rna ); > no warnings; > my $gc = ( $p->{G} + $p->{C} ) / $caller->len * 100; > } >} > >How would I inline a get/set method so that I could use it in a msy/// >statement directly rather than first setting a $tmp variable and using the >$tmp (which is my current workaround)? You could make an lvaluable method: % cat foo #!/bin/perl -l use strict; use warnings; use lib qw(/tmp); use Foo; my $obj = Foo->new; $obj->seq += 42; print $obj->seq; $obj->seq =~ s/4/17/; print $obj->seq; % cat Foo.pm package Foo; use strict; use warnings; sub new { bless { }, shift } sub seq :lvalue { my $self = shift; $self->{SEQUENCE}; } 1; % ./foo 42 172 I haven't done this before now, but it seems ok. As to maintainability, that's for you to decide. perldoc perlsub for more info. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From darren at DarrenDuncan.net Fri Nov 22 01:34:01 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:11 2004 Subject: your DBIx::Abstract perl module In-Reply-To: <20021122030958.GE6553@mikomi.org> References: <20021122030958.GE6553@mikomi.org> Message-ID: Hello Andy, thank you for your quick reply. (And this letter is CCd to my local victoria.pm for a backup reference copy.) You said: >I do. You can take a look at it here: >http://turner.mikomi.org/DBIx-Abstract-1.100.tar.gz Thanks for the preview. I had a look, but I went through quickly due to it being late here. At first glance it looks much like the old version, but that probably makes sense since it is an incremental upgrade. When I get the chance I will look closer. >As for DBIx::Abstract, it needs to be revised in light of the more recent >versions of DBI. Many of the old convenience methods are now (kind of) in >core DBI. For instance DBIx::Abstract's select_all_to_hashref is very >similar to DBI's selectall_hashref. True. I also noticed that, despite continuing to provide select_all_to_hashref() in your module, you are still implementing it the hard way (using a loop to transform a fetched array to a hash) rather than just wrapping it around a call like '$rowset = $sth->fetchall_arrayref({});', which is what I do in my own module. Is this an oversight, or did you want different output than my suggestion provides? >I do need help in figuring out how to represent complex joins in Perl-land. >And the field list could use some help. Right now its fine for a list of >fields but kind of falls down when more complex expressions are needed. I can help you with this, since I had already thought of a way to solve more complex cases in preparation to making my own module. I will outline the idea here (and please credit me if you use it): 1. To my knowledge, joins are always for relating records in two tables, so they don't need to be very complex like where/filter conditions are. Also, join conditions are always anded/intersected and not ored, are they not? So all you have to do is take a list of join conditions, where each join condition is a structure like this: ... join => [ { lhs_table => 'business', rhs_table => 'product', join_type => 'left', rel_fields => { fk_pt_one => 'pk_pt_one', fk_pt_two => 'pk_pt_two', }, }, ], ... The above example should handle any join type, equal, inner, left, etc, and handle any case from 1 to N fields needed as a unique identifier of a table record. As you can see, it is a hash ref per two tables being joined, and there is nothing in there at all that suggests what sql syntax looks like, which is quite different between Oracle and MySQL; this can even be used with databases who don't use sql as their interface language (but still support relational theory). 2. To deal with the common case where multiple records from the same table are joined together, directly or indirectly, here is a suggestion for making that work: ... table => { myself => 'person', father => 'person', mother => 'person', }, ... If you take this suggestion, then the keys in the hash are table aliases and the values in the hash are table names (the aliases are always unique, the names aren't always). The caller and you would then use the table aliases declared here instead of the usual table names in all of the other parameters: join, fields, where, group, order... 3. I will note that the above example didn't say anything about dealing with sub-selects. But if you decide (as I have) to use a new object to store the details of a select, such as what I mentioned above, then you can have these objects contain other objects when a sub-select or perhaps a union is meant to be used somewhere. 4. I won't give any details on 'fields' or 'where' suggestions right now, since they can be inordinately complex when one has to deal with functions and such, so another time. But you're already further ahead in those areas, abstraction-wise, than you were with 'table' or 'join'. >As for dialect differences. I do have a rewrite that was built with that >intention. What I plan to do (and suggest to you) is to go further. Make your 'public' module just an interface and/or input validator. Let your dialect modules not only create sql but actually call the DBI methods themselves (and instantiate the DBI object for that matter). On the other hand, if this sounds like a lot of duplication, you can have a different new 'private' module that contains functionality removed from your 'public' module, and from which your 'dialect' modules subclass. Of course, this may be further than you want to go, but it's what I'm going to do. >Other then inner joins I don't think you need any SQL now. But yeah, that's >the goal. (Field lists can be passed as arrayrefs, but when they're >constant it usually seems cleaner to just pass them as scalars.) There is a lot more I want to do, such as call 'stored procedures' from my main application without knowing the database particulars for doing so (and even have it work magically for databases that don't even support stored procedures, but use the real stored procedures for those that do). I also want to be able to verify/create/modify/delete database schema. All without the application who calls the Abstract module knowing about sql. And store metadata from which both selects and modifying sql can be generated. But that's talk for another day... ... and now it's almost an hour later. Time for rest. Have a good night to you. -- Darren Duncan From peter at PSDT.com Fri Nov 22 12:50:41 2002 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:11 2004 Subject: your DBIx::Abstract perl module In-Reply-To: References: <20021122030958.GE6553@mikomi.org> <20021122030958.GE6553@mikomi.org> Message-ID: <4.3.2.7.2.20021122104917.00b1db10@shell2.webquarry.com> At 11:34 PM 11/21/02 -0800, Darren Duncan wrote: >1. To my knowledge, joins are always for relating records in two >tables, so they don't need to be very complex like where/filter >conditions are. Also, join conditions are always anded/intersected >and not ored, are they not? There are admittedly rare conditions where they are not. I encountered these in Oracle classes. I would have to look up the notebooks for examples, but there are legitimate reasons for joins which do not use exact equality conditions. But all you need to do is add an optional extra parameter which is the operation. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From peter at PSDT.com Fri Nov 22 12:55:54 2002 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:11 2004 Subject: suggest DBIx::Concept for module name? In-Reply-To: References: <4.3.2.7.2.20021120121948.00b6ca50@shell2.webquarry.com> Message-ID: <4.3.2.7.2.20021122105044.00b1d100@shell2.webquarry.com> At 02:07 PM 11/20/02 -0800, Darren Duncan wrote: >On Wed, 20 Nov 2002, Peter Scott wrote: > > Can you tell me what your module will do that > > http://search.cpan.org/dist/DBIx-Abstract/Abstract.pm doesn't? That > > would help me. > >Yes I can. [snip] Thanks. Try these: DBIx::Transparent DBIx::NoSQL DBIx::SQLless DBIx::Portable -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From darren at DarrenDuncan.net Fri Nov 22 13:11:25 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:11 2004 Subject: suggest DBIx::Concept for module name? In-Reply-To: <4.3.2.7.2.20021122105044.00b1d100@shell2.webquarry.com> Message-ID: On Fri, 22 Nov 2002, Peter Scott wrote: > Thanks. Try these: > DBIx::Transparent > DBIx::NoSQL > DBIx::SQLless > DBIx::Portable Thank you, Peter; they look like good suggestions. Perhaps one of my larger goals is to avoid the caller doing any sql (except in stored procedures), so it might be good to mention it. The 'Portable' angle was also appealing and one of the first things I thought of; it would also provide a bit of parity with my previous largeish abstraction project, 'CGI::Portable' (where rather than DBMSs, it is web server protocols or their extension interfaces that are abstracted away). 'Portable' is also short, which is good. However, the main reason I was seeking other names is because portability seemed to be on the verge of being over-used as jargon, kind of like 'thinking outside the box'; using it doesn't have as powerful an affect as it used to. Of course, in the end it may turn out to be exactly the right name to use. But I'm still exploring other options like the 'NoSQL' suggestion you made. Thank you. -- Darren Duncan From darren at DarrenDuncan.net Fri Nov 22 16:46:38 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:11 2004 Subject: unsubscribe In-Reply-To: <001801c29277$3824e220$a3718e8b@vestappp> Message-ID: If you want to unsubscribe from this list then I think you do it by sending an email to 'majordomo@hfb.pm.org' with 'unsubscribe victoria-pm' in the body. Sending messages to the discussion list itself won't do anything. That said, does your unsubscribing have anything to do with my having sent an email to the list, which you quoted, or is there some other reason? -- Darren Duncan From abez at abez.ca Fri Nov 22 19:12:04 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:11 2004 Subject: suggest DBIx::Concept for module name? In-Reply-To: References: Message-ID: Have you guys looked at Tangram or Taboo? These are OOP wrappers for a RDBMS persistence layer. It's pretty spiffy. -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez On Fri, 22 Nov 2002, Darren Duncan wrote: > On Fri, 22 Nov 2002, Peter Scott wrote: > > Thanks. Try these: > > DBIx::Transparent > > DBIx::NoSQL > > DBIx::SQLless > > DBIx::Portable > > Thank you, Peter; they look like good suggestions. Perhaps one of my > larger goals is to avoid the caller doing any sql (except in stored > procedures), so it might be good to mention it. The 'Portable' angle was > also appealing and one of the first things I thought of; it would also > provide a bit of parity with my previous largeish abstraction project, > 'CGI::Portable' (where rather than DBMSs, it is web server protocols or > their extension interfaces that are abstracted away). 'Portable' is also > short, which is good. However, the main reason I was seeking other names > is because portability seemed to be on the verge of being over-used as > jargon, kind of like 'thinking outside the box'; using it doesn't have as > powerful an affect as it used to. Of course, in the end it may turn out > to be exactly the right name to use. But I'm still exploring other > options like the 'NoSQL' suggestion you made. Thank you. -- Darren Duncan > > From darren at DarrenDuncan.net Mon Nov 25 21:56:39 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:11 2004 Subject: using name 'DBIx::Portable' for now Message-ID: Hello. I have decided to use 'DBIx::Portable' as the name for my new module during its initial public availability. I have to call it something. And so this is good enough for referring to in my original documentation, on this list, and on any RFCs that I post to modules@perl.org or dbi-users@perl.org; they can also suggest alternate names. Alternately, if there is concern that I would pollute the CPAN namespace if I posted one module and then changed its name, I could just keep it on my server until it is approved, perhaps? -- Darren Duncan