From darren at DarrenDuncan.net Mon Dec 2 13:08:30 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:12 2004 Subject: RFC: suggest DBIx::Layer or similar for module name Message-ID: Hello. I thought I would bounce this off of the omnimind to see if it has some merit. But first... When it comes to naming a module, what kind of descriptive emphasis might be better in a module name, between what kind of problem the module is to solve and what kind of method is being used in the solution? I ask because, while DBIx::Portable may be a good name regarding what the module is to do, I am wondering if is too generic where people could say "I've already seen that sort of thing before", given that a handful of other modules are working on the same problem. Instead, perhaps, I was thinking that a name which incorporates my solution (which is unlikely to be implemented differently over time) would be a better attention grabber. Peter's suggestion of 'NoSQL' or the like is indeed less generic, but for my purposes it is too descriptive, or not always correct. My idea for a name like DBIx::Layer (or DBIx::Layered, or DBIx::ByLayer, etc) came out this weekend and today when I was thinking more of what kind of implementation and/or feature set I wanted to have. My current idea is that my module is supposed to facilitate a multi-layer abstraction of databases, with the layers ranging between code that knows nothing about specific database engines (high abstraction) and code that is highly optimized for a specific database engine (low/no abstraction). There would probably be a middle layer that does some of each. The idea here is that my module should help manage and interoperate code in these layers with the database and the main application. High abstraction layers would use zero sql, and low/no probably would use all sql. The point here is to have your cake and eat it too. In other words, to have an application that is completely portable but at the same time very fast and efficient. Existing 'portability' solutions seem to take one tack or the other, but not both. Some implement a lot of features as pure Perl code and talk to all databases using the lowest common denominator; what MySQL supports. That approach is highly portable but it also has a tendency to be very slow as well, with the Perl code doing a lot of work that the much faster database engine itself should be doing. Other solutions are thin and fast, but they don't interface to a large number of database features; to use those features they provide a 'bypass routine' where the app developer essentially works at DBI directly as if the abstraction module wasn't there, putting sql in their app which must be changed or put in 'if' blocks depending on the database in use. I could say more if needed, but that will be in a separate email. So, based on what I have said, does a name involving 'Layer' or a synonym thereof sound better than 'Portable' for what I have in mind. Thank you in advance. -- Darren Duncan From Peter at PSDT.com Mon Dec 2 16:54:07 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: RFC: suggest DBIx::Layer or similar for module name In-Reply-To: Message-ID: <4.3.2.7.2.20021202145032.00aa6f00@shell2.webquarry.com> At 11:08 AM 12/2/2002 -0800, Darren Duncan wrote: >Hello. I thought I would bounce this off of the omnimind to see if it has >some merit. But first... > >When it comes to naming a module, what kind of descriptive emphasis might >be better in a module name, between what kind of problem the module is to >solve and what kind of method is being used in the solution? Apples, meet oranges. >I ask because, while DBIx::Portable may be a good name regarding what the >module is to do, I am wondering if is too generic where people could say >"I've already seen that sort of thing before", given that a handful of >other modules are working on the same problem. Instead, perhaps, I was >thinking that a name which incorporates my solution (which is unlikely to >be implemented differently over time) would be a better attention grabber. > >Peter's suggestion of 'NoSQL' or the like is indeed less generic, but for >my purposes it is too descriptive, or not always correct. > >My idea for a name like DBIx::Layer (or DBIx::Layered, or DBIx::ByLayer, >etc) came out this weekend and today when I was thinking more of what kind >of implementation and/or feature set I wanted to have. If this differs semantically from "Abstract" then the distinction is too subtle for me, if not everyone else. >My current idea is that my module is supposed to facilitate a multi-layer >abstraction of databases, with the layers ranging between code that knows >nothing about specific database engines (high abstraction) and code that >is highly optimized for a specific database engine (low/no abstraction). >There would probably be a middle layer that does some of each. The idea >here is that my module should help manage and interoperate code in these >layers with the database and the main application. High abstraction >layers would use zero sql, and low/no probably would use all sql. > >The point here is to have your cake and eat it too. In other words, to >have an application that is completely portable but at the same time very >fast and efficient. > >Existing 'portability' solutions seem to take one tack or the other, but >not both. Some implement a lot of features as pure Perl code and talk to >all databases using the lowest common denominator; what MySQL supports. >That approach is highly portable but it also has a tendency to be very >slow as well, with the Perl code doing a lot of work that the much faster >database engine itself should be doing. Other solutions are thin and >fast, but they don't interface to a large number of database features; to >use those features they provide a 'bypass routine' where the app developer >essentially works at DBI directly as if the abstraction module wasn't >there, putting sql in their app which must be changed or put in 'if' >blocks depending on the database in use. > >I could say more if needed, but that will be in a separate email. > >So, based on what I have said, does a name involving 'Layer' or a synonym >thereof sound better than 'Portable' for what I have in mind. This is all too reminiscent of angels-on-pinheads discussions. If any clear answer stood out for me, I would have given it, but at this point, the possibilities all look pretty much the same to me. I think you could make any of them stick. That may not be helpful, unless it just encourages you to pick one and live with it instead of worrying further. Peter Scott peter@psdt.com http://www.perldebugged.com From darren at DarrenDuncan.net Mon Dec 2 17:20:12 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:12 2004 Subject: RFC: suggest DBIx::Layer or similar for module name In-Reply-To: <4.3.2.7.2.20021202145032.00aa6f00@shell2.webquarry.com> Message-ID: On Mon, 2 Dec 2002, Peter Scott wrote: > Apples, meet oranges. > If this differs semantically from "Abstract" then the distinction is too > subtle for me, if not everyone else. > This is all too reminiscent of angels-on-pinheads discussions. If any > clear answer stood out for me, I would have given it, but at this point, > the possibilities all look pretty much the same to me. I think you could > make any of them stick. > That may not be helpful, unless it just encourages you to pick one and live > with it instead of worrying further. Thanks for the reply. The fact that you couldn't tell any difference between the meaning of these name options is still quite helpful. If that is typical of the Perl/DBI community at large then it probably doesn't matter so much what name I use. So I will just pick one that works for now. Have a good day. -- Darren Duncan From nkuipers at uvic.ca Mon Dec 2 18:44:02 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:12 2004 Subject: RFC: suggest DBIx::Layer or similar for module name Message-ID: <3DEBFFE2@wm2.uvic.ca> I agree with Peter's assessment. And just to be a loser, I'll throw out some more name ideas: DBIx::Accomodate DBIx::LessSQL Nathanael Kuipers >===== Original Message From Darren Duncan ===== >On Mon, 2 Dec 2002, Peter Scott wrote: >> Apples, meet oranges. >> If this differs semantically from "Abstract" then the distinction is too >> subtle for me, if not everyone else. >> This is all too reminiscent of angels-on-pinheads discussions. If any >> clear answer stood out for me, I would have given it, but at this point, >> the possibilities all look pretty much the same to me. I think you could >> make any of them stick. >> That may not be helpful, unless it just encourages you to pick one and live >> with it instead of worrying further. > >Thanks for the reply. The fact that you couldn't tell any difference >between the meaning of these name options is still quite helpful. If that >is typical of the Perl/DBI community at large then it probably doesn't >matter so much what name I use. So I will just pick one that works for >now. Have a good day. -- Darren Duncan From abez at abez.ca Mon Dec 2 19:17:21 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:12 2004 Subject: RFC: suggest DBIx::Layer or similar for module name In-Reply-To: <3DEBFFE2@wm2.uvic.ca> References: <3DEBFFE2@wm2.uvic.ca> Message-ID: On a side not the The Perl Journal this month contains an article called: "Perl & Rapid Database Prototyping" by Tim Kientzle . It's similar to the DB abstraction techniques discussed here. http://www.tpj.com/issues/index.html On Mon, 2 Dec 2002, nkuipers wrote: > I agree with Peter's assessment. And just to be a loser, I'll throw out some > more name ideas: > > DBIx::Accomodate > DBIx::LessSQL -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From darren at DarrenDuncan.net Tue Dec 3 00:29:18 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:12 2004 Subject: RFC: suggest DBIx::Layer or similar for module name In-Reply-To: <3DEBFFE2@wm2.uvic.ca> References: <3DEBFFE2@wm2.uvic.ca> Message-ID: >I agree with Peter's assessment. And just to be a loser, I'll throw out some >more name ideas: > >DBIx::Accomodate >DBIx::LessSQL > >Nathanael Kuipers Thanks for your input. I hadn't even thought of something like 'Accomodate' yet, so that's new. Also interesting, but a tad long. Now, what do you mean by "and just to be a loser"? On a different note, I will probably continue with 'DBIx::Portable' for the time being, but I thought I could include some of the other concepts in the one-liner description that goes with the 'Name' of a module's POD, and in the module list. I will probably start with a variant of this description for the first release, with this DSLIP (the size limit for description is 44 chars): Name-------------- DSLIP 12345678901234567890123456789012345678901234 Author- DBIx:: ::Portable adpOp Multilevel, fast, flexible RDBMS abstraction DUNCAND When I write an actual "Description" section in my POD and other documentation / implementation, I should have a lot more inspiration for how to amend the above description to be more accurate. One target application type is large data-dictionary driven apps. For a possible reference of how that would stand out, I have included at the end of this letter the same type of information that is published for a number of related modules (incomplete; most are from the registered module list, and not all grouped together there either, a few I didn't see there but on the search site). So I need something that says how it is unique from them, for the most part. Have a good day. -- Darren Duncan ---------------------------------------- Class:: ::DBI adpOp Simple SQL-based object persistance TMTM DBFramework adpO? is a collection of classes for manipulating DBI databases PSHARPE DBI MmcOp Generic Database Interface (see DBD modules) DBIML DBI:: ::Format bmpO? Defined display formats for data from DBI TLOWERY ::Shell ????? Interactive command shell for the DBI TIMB DBIx:: ::Abstract RmpO? Wrapper for DBI that generates SQL TURNERA ::AnyDBD bdpO? Module to make cross db applications easier MSERGEANT ::Browse bdpOg A class to browse related tables via CGI/Web EJDRS ::DataSource ????? Database-independant create and drop functions IVAN ::CGITables adpO? Easy DB access from a CGI TOBIX ::Chart adpOa extends DBI & SQL w/ charting capabilities DARNOLD ::Copy adpO? Copying databases TOBIX ::dbMan bmpOp Tk/cmdline database manipulating tool MILSO ::DBSchema bmpOp Database-independent schema objects IVAN ::FetchLoop RdpOg Fetch with change detection and aggregates BITS ::FullTextSearch bmpOp Index documents with MySQL as storage TJMATHER ::glueHTML bdpO? CGI interface to DBI databases JFURNESS ::HTMLView cdpO? Creating web userinterfaces to DBI dbs HAKANARDO ::OracleSequence adpOp OO access to Oracle sequences via DBD-Oracle BLABES ::Password MdpO? Abstration layer for database passwords KROW ::Recordset bmpO? DB-Abtractionlayer / Access via Arrays/Hashs GRICHTER ::SchemaView adpf? Retrieving and drawing of DB schema (Tk) MILSO ::SearchBuilder ????? Perl extension for easy SQL SELECT Statement generation JESSE ::Sequence MdpOp Database independent ID generation BBEAUSEJ ::SystemCatalog RdpO? Accessing system catalog in common databases MILSO ::Table bdpO? OO access to DBI database tables DLOWE ::TableAdapter adpOa A object-relational table adapter class GED ::TextIndex bdpOp Creates fulltext indexes of SQL text columns DKOCH ::Tree adpO? Expand self-referential table into a tree BJEPS ::XHTML_Table RdpOp SQL query result set to XHTML table JEFFA ::XMLMEssage bdpOp Exchange of XML messages between DBI sources ANDREIN ::XML_RDB ????? Creates XML from DBI datasources MSERGEANT DBIx::Lookup:: ::Field Rdpfp Create a lookup hash from a database table MARCEL Persistent:: ::DBI bdpO? Persistent abstract class for DBI databases DWINTERS Relations adphp Database, CGI, and Graph Interfunctionality GAFFER SQL:: ::Abstract ????? Generate SQL from Perl data structures NWIGER ::Builder adpO? OO interface for creating SQL statements ZENIN ::Generator adpOg Generate SQL-queries via OO perl MUENALAN ::Schema bdpO? Convert a data dictionary to SQL statements TODD ::Snippet bdpOp Constraint-based OO Interface to RDBMS PRL ::Statement adcO? Small SQL parser and engine JWIED SQL::QueryBuilder:: ::Simple ????? Generates simple SQL SELECT queries RRWO From peter at PSDT.com Tue Dec 10 17:37:18 2002 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: December Victoria.pm meeting? Message-ID: <4.3.2.7.2.20021210153558.00b07160@shell2.webquarry.com> So, does the group mind lean towards a December meeting, or is there enough to do with the holidays? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From abez at abez.ca Tue Dec 10 17:28:20 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:12 2004 Subject: Canoe uses perl? Message-ID: http://cnews.canoe.ca/CNEWS/Canada/2002/12/03/6247-cp.html 1/4 down the page: > But a Martin spokesman said Tuesday that his boss is committed to implementing > Kyoto and would not backtrack. > > - > > ARRAY(0x85295dc) > > Q: What is the Kyoto protocol? So I assume then that at least this page uses perl :) -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From nkuipers at uvic.ca Tue Dec 10 22:04:48 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:12 2004 Subject: December Victoria.pm meeting? Message-ID: <3DF6CB85@wm2.uvic.ca> I have my last exam on the evening of the 19th, and thus naturally am unavailable until the 21st, needing time to recover. ;) I'll be leaving for the mainland on the 22nd. As long as the meeting is before the 19th, I should be able to make it, and in any case would like to, since I just started reading the Perl6 Apocalypse articles which both intrigue and cosmically frighten me. Hope everyone is doing well, Nathanael >===== Original Message From Peter Scott ===== >So, does the group mind lean towards a December meeting, or is there >enough to do with the holidays? >-- >Peter Scott >Pacific Systems Design Technologies >http://www.perldebugged.com/ From darren at DarrenDuncan.net Wed Dec 11 00:47:36 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:12 2004 Subject: Canoe uses perl? Message-ID: abez said: >http://cnews.canoe.ca/CNEWS/Canada/2002/12/03/6247-cp.html > >1/4 down the page: >> But a Martin spokesman said Tuesday that his boss is committed to implementing >> Kyoto and would not backtrack. >> >> - >> >> ARRAY(0x85295dc) >> >> Q: What is the Kyoto protocol? > >So I assume then that at least this page uses perl :) I didn't find that error when I looked, so they must have fixed it, or I wasn't looking right. In any event, I haven't seen any other language that produces language like this, so I'm inclined to agree with you. It looks like Perl. It does not look like PHP, which would simply say 'Array' (that case). It doesn't look like javascript or asp, which I think would say '[Object]' or something. -- Darren Duncan From darren at DarrenDuncan.net Wed Dec 11 00:50:16 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:12 2004 Subject: December Victoria.pm meeting? In-Reply-To: <4.3.2.7.2.20021210153558.00b07160@shell2.webquarry.com> References: <4.3.2.7.2.20021210153558.00b07160@shell2.webquarry.com> Message-ID: >So, does the group mind lean towards a December meeting, or is there enough to do with the holidays? >-- >Peter Scott >Pacific Systems Design Technologies >http://www.perldebugged.com/ I don't anticipate having problems with a meeting on any day in December, except that thursdays are usually a conflict so I would avoid them. On another note, I talked to Darrell Wick recently, whom I've mentioned before. While I haven't received confirmation to the effect, he might join this list or come to meetings, or send students this way come January classes. -- Darren Duncan From abez at abez.ca Wed Dec 11 22:36:49 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:12 2004 Subject: Presentation? Message-ID: Does anyone want to do a presentation for next week? Even a mini presentation is fine (less than 1/2 hour). It's nice to have a focus. -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From darren at DarrenDuncan.net Thu Dec 12 00:05:56 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:12 2004 Subject: Presentation? In-Reply-To: Message-ID: On Wed, 11 Dec 2002, abez wrote: > Does anyone want to do a presentation for next week? Even a mini presentation > is fine (less than 1/2 hour). It's nice to have a focus. If there is a lack of alternatives I am willing to talk again. But what about? Of course, since I did it last time it would probably be better if someone else led this time. If there is no better idea, maybe we could discuss what is coming up in Perl 6 as we know it, such as what has changed or new features, and perhaps how that might affect us. Not that this is too practical within the next year or so, since it is not ready to actually use for real work yet. -- Darren Duncan From Peter at PSDT.com Thu Dec 12 11:41:07 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: Presentation? In-Reply-To: References: Message-ID: <4.3.2.7.2.20021212084807.00ab0dd0@shell2.webquarry.com> At 10:05 PM 12/11/2002 -0800, Darren Duncan wrote: >On Wed, 11 Dec 2002, abez wrote: > > Does anyone want to do a presentation for next week? Even a mini > presentation > > is fine (less than 1/2 hour). It's nice to have a focus. > >If there is a lack of alternatives I am willing to talk again. I could talk about Test:: modules if necessary. But I'd sooner see someone else step up to the plate this month. Peter Scott peter@psdt.com http://www.perldebugged.com From darren at DarrenDuncan.net Thu Dec 12 12:22:00 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:12 2004 Subject: Presentation? In-Reply-To: <4.3.2.7.2.20021212084807.00ab0dd0@shell2.webquarry.com> Message-ID: On Thu, 12 Dec 2002, Peter Scott wrote: > I could talk about Test:: modules if necessary. But I'd sooner see someone > else step up to the plate this month. Actually, module testing is something that I could use a little more help with. There are some questions here, but a discussion might be in order. I understand that providing a test suite with any modules released to the public / CPAN (or even used internally) is generally a must so that it is easier for potential users of a module to be confident that it is working correctly. Also, it helps the developer be confident that when they change some internals they can know that the outward behaviour is still the same and/or changed to the way they expect. For many modules one doesn't have to spend much time retesting after even small changes, because a quick run of a test script will just say yay or nay. However, I find that to get this kind of robustness it is taking me a lot of time and effort to make my test suites in the first place. The easiest kinds of modules to write tests for are those which are self-contained (sit on top of bare perl and don't use other modules) and particularly which are of the data structure or data conversion variety, which only take input through their methods and only send output through their methods. Those 4 of my modules that are this type have a full test suite at the moment, and the test count for each is about 229, 64, 45, 90, or somewhere between those ranges; each test suite took me several full days to write. By contrast, it is modules that serve as interfaces to something external, such as files or networks or user interfaces or databases or other programs or hardware, which are a lot more difficult to write tests for, because how do you exhaustively test things where a large part of which is out of your control. For example, how would I test certain kinds of errors that can happen with a file, as another of my modules (with an incomplete test suite) is supposed to do? It is easier to show that it works when it should than that it catches errors when there are external problems. For a related question, if a module is supposed to interface to a file, such as perhaps create one or write to one, where should this file go such that it doesn't step on other things in the filesystem? Or, how does one simulate a failure to do a read or a write or an flock; it is easy enough to simulate an open failure (such as asking for a wrong name) by contrast. Also, is it normal for test suites to come with other files for them to manipulate other than what is in the test.pl code itself? I will note that my 10+ modules which are not in the 'easier' category mentioned above have been released with a test suite that usually does nothing more than test that the module compiles. Besides that, I don't know for sure that it works except that I have observed the applications running on top of them to behave correctly. But those don't use every single option that the modules provide for their completeness. For the most part, it is the presence of a complete test suite that makes the difference for my modules being in status 'R'eleased (with) or 'b'eta/'a'lpha (without). I would really like to get my modules into 'R', but I don't want to be deceptive by just putting them there anyway. I also don't want to take a lot of time to make the tests. These are some issues I struggle with. It is easy to make module updates and updates to their documentation by contrast, as often module methods are smaller than the test code for them. And trying to have proper tests is really slowing me down when I want to put something out quickly, taking a lot of my time and delaying results. Perhaps a more general question is, of all the CPAN modules, about what fraction have an exhaustive test suite and what fraction have an incomplete suite. Is it acceptible to have modules in status 'R' that are not fully tested. Are in any modules in status 'a' or 'b' that have comprehensive test suites and pass all the tests? Any feedback or suggestions? -- Darren Duncan From Peter at PSDT.com Thu Dec 12 12:26:52 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: Presentation? In-Reply-To: References: <4.3.2.7.2.20021212084807.00ab0dd0@shell2.webquarry.com> Message-ID: <4.3.2.7.2.20021212102545.00b1f6d0@shell2.webquarry.com> At 10:22 AM 12/12/02 -0800, Darren Duncan wrote: >On Thu, 12 Dec 2002, Peter Scott wrote: > > I could talk about Test:: modules if necessary. But I'd sooner see someone > > else step up to the plate this month. > >Actually, module testing is something that I could use a little more help >with. There are some questions here, but a discussion might be in order. Everything you say is true. I am a convert to the fold. I can talk about it; I'll shamelessly use a tutorial of Schwern's as the material though. Now, what night? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From nkuipers at uvic.ca Thu Dec 12 12:29:49 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:12 2004 Subject: Presentation? Message-ID: <3DF8EF46@wm2.uvic.ca> >Now, what night? How about Monday the 16th. From peter at PSDT.com Thu Dec 12 12:51:18 2002 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: Presentation? In-Reply-To: <3DF8EF46@wm2.uvic.ca> Message-ID: <4.3.2.7.2.20021212105108.00b22c90@shell2.webquarry.com> At 10:29 AM 12/12/02 -0800, nkuipers wrote: > >Now, what night? > >How about Monday the 16th. Do I hear a second? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From abez at abez.ca Thu Dec 12 12:53:58 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:12 2004 Subject: Presentation? In-Reply-To: <3DF8EF46@wm2.uvic.ca> References: <3DF8EF46@wm2.uvic.ca> Message-ID: I'm ok with monday or tuesday. Wednesday and beyond are a pain for me. On Thu, 12 Dec 2002, nkuipers wrote: > >Now, what night? > > How about Monday the 16th. > -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From abez at abez.ca Thu Dec 12 13:01:05 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:12 2004 Subject: Presentation? In-Reply-To: <4.3.2.7.2.20021212105108.00b22c90@shell2.webquarry.com> References: <4.3.2.7.2.20021212105108.00b22c90@shell2.webquarry.com> Message-ID: Second On Thu, 12 Dec 2002, Peter Scott wrote: > At 10:29 AM 12/12/02 -0800, nkuipers wrote: > > >Now, what night? > > > >How about Monday the 16th. > > Do I hear a second? > > > -- > Peter Scott > Pacific Systems Design Technologies > http://www.perldebugged.com/ > -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From Peter at PSDT.com Thu Dec 12 13:24:52 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: Meeting In-Reply-To: References: <3DF8EF46@wm2.uvic.ca> <3DF8EF46@wm2.uvic.ca> Message-ID: <4.3.2.7.2.20021212112227.00b16d20@shell2.webquarry.com> Okay, Monday the 16th it is. I'll send out another notice closer to the time. I'll talk about using Test:: modules to follow the eXtreme Programming (XP) dogma^Wmantra^Wprinciple of writing tests before code. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From abez at abez.ca Thu Dec 12 14:07:19 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:12 2004 Subject: Meeting In-Reply-To: <4.3.2.7.2.20021212112227.00b16d20@shell2.webquarry.com> References: <3DF8EF46@wm2.uvic.ca> <3DF8EF46@wm2.uvic.ca> <4.3.2.7.2.20021212112227.00b16d20@shell2.webquarry.com> Message-ID: Outright I have an anti-XP bias. I have used it before, even done the pair programming but I feel it's not appropriate for many tasks, especially programs of 30KLOC or more. C3, the Program that Kent Beck and Cronies worked on at Chrysler, failed after 4 years of development. This was the program which was used as an example in the XP books. Chrysler refuses to use XP for any future projects. I'm not saying all of XP is bad but when it's based on Refactoring, which already classified as an antipattern one has to be a little skeptical. Test first is great if you don't know what your interfaces look like. It helps designing interfaces on a code level. Tests are usually always good. Although Djisktra has said something to the effect that testing shows the presence of the bugs, not their absence. A contrived case #returns half a number sub half { return int($_[0]/2); } and your test is half(4) you get 2, but if you put in 5 you get 2.5. Obviously you're supposed to test with greater coverage but this was a simple example. Of course Donald Knuth has said, "Beware of bugs in the above code; I have only proved it correct, not tried it." Have a good day everyone :) abram On Thu, 12 Dec 2002, Peter Scott wrote: > Okay, Monday the 16th it is. I'll send out another notice closer to > the time. I'll talk about using Test:: modules to follow the eXtreme > Programming (XP) dogma^Wmantra^Wprinciple of writing tests before code. > -- > 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 Thu Dec 12 14:10:13 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:12 2004 Subject: Meeting In-Reply-To: <4.3.2.7.2.20021212112227.00b16d20@shell2.webquarry.com> Message-ID: On Thu, 12 Dec 2002, Peter Scott wrote: > Okay, Monday the 16th it is. I'll send out another notice closer to > the time. I wasn't fast enough to get my vote in. However, I don't forsee any schedule conflicts at this time, so monday should work for me as well. > I'll talk about using Test:: modules to follow the eXtreme > Programming (XP) dogma^Wmantra^Wprinciple of writing tests before code. Funny that you should bring this up. While not exactly the same thing, I was planning to write the *documentation*/specification for my new RDBMS module before writing the code, since it is new enough that I don't know entirely what it should do yet. Writing documentation first would help to solidify this, and allow people to comment on the spec prior to committing anything to code. In fact, I would probably make my first upload to CPAN in that form, perhaps as version zero; the next release, version 0.01 would have some code, which is enough to do something useful (what my app is currently using). Or should the docs-only first release be 0.01? I wasn't going to start writing tests immediately for this module, but if our meeting shows me how to do it quickly/easily then I just might do it from the start after all. -- Darren Duncan P.S. This is my current idea for a DSLIP. The 'a'lpha status recognizes the early release that, while the code works, it may be subject to heavy changes so one shoudn't count on the interface staying unchanged. Name-------------- DSLIP 12345678901234567890123456789012345678901234 Author- DBIx:: ::Portable adpOp Framework for RDBMS-generic apps and schemas DUNCAND From Peter at PSDT.com Thu Dec 12 14:13:49 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: Meeting In-Reply-To: References: <4.3.2.7.2.20021212112227.00b16d20@shell2.webquarry.com> <3DF8EF46@wm2.uvic.ca> <3DF8EF46@wm2.uvic.ca> <4.3.2.7.2.20021212112227.00b16d20@shell2.webquarry.com> Message-ID: <4.3.2.7.2.20021212121321.00b1a220@shell2.webquarry.com> At 12:07 PM 12/12/02 -0800, abez wrote: >Outright I have an anti-XP bias. Good, it should be a lively discussion :-) I also have an anti-XP bias. But there are parts of it I like. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From abez at abez.ca Thu Dec 12 14:16:18 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:12 2004 Subject: Meeting In-Reply-To: References: Message-ID: I find this strategy works well. Write docs for your code before hand. Specify how you want it used. Don't spend too much time on it. Write it. Reverse Engineer your new code and see what has changed, update your docs or make new ones. I think doxygen works for perl now.. Before you release anything in the wild you should provide some docs otherwise people won't use it and if people won't use it why release it? On Thu, 12 Dec 2002, Darren Duncan wrote: > Funny that you should bring this up. While not exactly the same thing, I > was planning to write the *documentation*/specification for my new RDBMS > module before writing the code, since it is new enough that I don't know > entirely what it should do yet. Writing documentation first would help to > solidify this, and allow people to comment on the spec prior to committing > anything to code. In fact, I would probably make my first upload to CPAN > in that form, perhaps as version zero; the next release, version 0.01 > would have some code, which is enough to do something useful (what my app > is currently using). Or should the docs-only first release be 0.01? I > wasn't going to start writing tests immediately for this module, but if > our meeting shows me how to do it quickly/easily then I just might do it > from the start after all. > > -- Darren Duncan > > P.S. This is my current idea for a DSLIP. The 'a'lpha status recognizes > the early release that, while the code works, it may be subject to heavy > changes so one shoudn't count on the interface staying unchanged. > > Name-------------- DSLIP 12345678901234567890123456789012345678901234 Author- > DBIx:: > ::Portable adpOp Framework for RDBMS-generic apps and schemas DUNCAND > -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From pavel at md5.ca Thu Dec 12 14:14:07 2002 From: pavel at md5.ca (Pavel Zaitsev) Date: Wed Aug 4 00:11:12 2004 Subject: Meeting In-Reply-To: References: Message-ID: <20021212201407.GA29931@md5.ca> abez(abez@abez.ca)@Thu, Dec 12, 2002 at 12:16:18PM -0800: > I think doxygen works for perl now.. Nooo way! :-) I wish it was. p. -- Create like god, rule like a king, work like a slave. From darren at DarrenDuncan.net Thu Dec 12 14:30:51 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:12 2004 Subject: Meeting In-Reply-To: Message-ID: On Thu, 12 Dec 2002, abez wrote: > I find this strategy works well. Write docs for your code before hand. Specify > how you want it used. Don't spend too much time on it. This is similar to how I learned structured programming in college. Essentially write the interface first and/or the user documentation, and then afterwards implement it. If you find that you can't adequately explain how to use the module to someone else, it probably isn't designed properly. > Before you release anything in the wild you should provide some docs otherwise > people won't use it and if people won't use it why release it? I will take this comment as a general suggestion. But in case anyone misinterpreted this as referring to the state of my older released modules, I will briefly clarify... It is true that about 2/3 of my released modules do not have any or a complete test suite (but they all come with a test.pl that confirms they compile). However, every single one of my modules does have complete user documentation, examples of using the module, and interface documentation for all the methods, etc; in other words, complete POD. Only the lack of complete test.pl is keeping 2/3 of my older modules from being finished. Regarding Xtreme Programming, while I have heard about this, I have never read books on it or knowingly practiced it myself. Maybe some of my 'structured programming' practices are compatible with XP, but I have never tried to be an XP programmer. I can't comment on how good or bad it is from experience. -- Darren Duncan From abez at abez.ca Thu Dec 12 14:36:18 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:12 2004 Subject: Meeting In-Reply-To: <20021212201407.GA29931@md5.ca> References: <20021212201407.GA29931@md5.ca> Message-ID: It doesn't! Goddamn. It's strange it works for PHP and not for PERL, since PHP has multiple wacky syntaxes and perl is pretty predantic about curly braces. Still placing block comments above your subroutines and package names isn't hard. It wouldn't be too hard to parse.. That's pretty lame. Does anyone know of a good code reverse engineering program for perl? I know perlpod exists but it doesn't seem to be for a subroutine level documentation like javadoc. On Thu, 12 Dec 2002, Pavel Zaitsev wrote: > abez(abez@abez.ca)@Thu, Dec 12, 2002 at 12:16:18PM -0800: > > I think doxygen works for perl now.. > > Nooo way! :-) > I wish it was. > p. > > -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From abez at abez.ca Thu Dec 12 14:53:04 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:12 2004 Subject: Meeting In-Reply-To: <20021212201407.GA29931@md5.ca> References: <20021212201407.GA29931@md5.ca> Message-ID: It's so funny there is all these perl transformation tools on the Doxygen helper page and using perl as a intermediate format but never anything to document perl. Strange. On Thu, 12 Dec 2002, Pavel Zaitsev wrote: > abez(abez@abez.ca)@Thu, Dec 12, 2002 at 12:16:18PM -0800: > > I think doxygen works for perl now.. > > Nooo way! :-) > I wish it was. > p. > > -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From peter at PSDT.com Thu Dec 12 15:10:21 2002 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: Auto-autosplit Message-ID: <4.3.2.7.2.20021212130737.00aadcc0@shell2.webquarry.com> This code has been rather useful. I'm wondering whether I've reinvented a wheel, and if so, which one. Otherwise, this could be improved a bit with use of File::Spec, and maybe I can find a way to modularise it. # Autosplitting because we expect to have a number of large methods # which we won't use many of at a time. # Because it's a nuisance to remember to do the split, we do it # if necessary and if we can. If it's needed but we can't do it, # we croak. use Carp; use AutoLoader 'AUTOLOAD'; BEGIN { my $pack = __PACKAGE__; my $dir = __FILE__; $dir =~ s#[^/]+$##; $dir ||= '.'; $pack =~ s#::#/#g; if (-M __FILE__ < -M "$dir/auto/$pack/autosplit.ix") { open TEST, ">>$dir/auto/$pack/autosplit.ix" or croak "Module has not been autosplit since last change\n"; close TEST; require AutoSplit; AutoSplit->import; autosplit(__FILE__, "$dir/auto", 0, 1, 0); } } -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From rockielowe at shaw.ca Fri Dec 13 00:27:07 2002 From: rockielowe at shaw.ca (Liz or Rockie Lowe) Date: Wed Aug 4 00:11:12 2004 Subject: Presentation? References: <4.3.2.7.2.20021212105108.00b22c90@shell2.webquarry.com> Message-ID: <01ec01c2a270$a9096fc0$e9954218@gv.shawcable.net> I vote yea for Mon. > > Second > > On Thu, 12 Dec 2002, Peter Scott wrote: > > > At 10:29 AM 12/12/02 -0800, nkuipers wrote: > > > >Now, what night? > > > > > >How about Monday the 16th. > > > > Do I hear a second? > > From peter at PSDT.com Sun Dec 15 03:31:00 2002 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: Meeting tomorrow Message-ID: <4.3.2.7.2.20021212112907.00b16cc0@shell2.webquarry.com> Victoria.pm will meet for December tomorrow: Monday December 16 at UVic's McPherson Library. Meet inside in the art gallery area immediately to the right upon entering between 6:45 and 7:00. At 7:00 we will relocate to one of the small conference rooms on the next floor up. If one is not available (rare) we will find somewhere else; either way we will leave a note with the room number in the art gallery area; if you don't find it, 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. I'll talk about using Test:: modules to follow the eXtreme Programming (XP) dogma^Wmantra^Wprinciple of writing tests before code. 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 abez at abez.ca Tue Dec 17 11:39:49 2002 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:12 2004 Subject: Perl & Binary Data (fwd) Message-ID: -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez ---------- Forwarded message ---------- Date: Mon, 16 Dec 2002 22:52:51 -0800 (PST) From: abez To: owner-victoria-pm@pm.org Subject: Perl & Binary Data I want to filter short integers in perl. I know I could do this in C or C++ easily but I want to do it in perl effectively. I think I'm taking a big hit converting to and from binary to perl numbers and back again. E.g. in C while (len = read(fd,(char*)buffer,size)) { for (i = 0; i < size/sizeof(short); i++) { buffer[i] = buffer[i]/2; } write(fd,(char*)buffer,size); } so far in perl I'm guessing while ($len = sysread($fd,$buffer,$size)) { my @o = unpack("s*",$buffer); foreach (@o) { $_/=2; } syswrite($fd,pack("s*",$buffer,$size); } This seems really slow for datarates of 178kb/s -- abez----- ----- ------ - ------ -- ------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) --- --- ------ --------- - - ------ --------abez From Peter at PSDT.com Tue Dec 17 13:31:43 2002 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: Perl & Binary Data In-Reply-To: References: <4.3.2.7.2.20021217095913.00aae260@shell2.webquarry.com> <4.3.2.7.2.20021217081747.00ab5010@shell2.webquarry.com> <4.3.2.7.2.20021217081747.00ab5010@shell2.webquarry.com> <4.3.2.7.2.20021217095913.00aae260@shell2.webquarry.com> Message-ID: <4.3.2.7.2.20021217103317.00ab1a90@shell2.webquarry.com> abez@abez.ca wrote: > > > >while ($len = sysread($fd,$buffer,$size)) { > > > > my @o = unpack("s*",$buffer); > > > > foreach (@o) { > > > > $_/=2; > > > > } > > > > syswrite($fd,pack("s*",$buffer,$size); > > > >} > > > > > > > >This seems really slow for datarates of 178kb/s This seems to work: my $data = "\x10\x02\x80\xff"; # Test data for (my $i = 0; $i < length($data); $i += 2) { my $x = vec($data, $i >> 1, 16); vec($data, $i >> 1, 16) = ($x >> 1) | ($x & 0b10000000); } Assuming twos complement and that the top bit being set indicates it's negative... I'm rusty there. May be endian issues. It would be a lot easier if << and >> worked on bit strings. I don't know why they don't. I've asked on comp.lang.perl.moderated. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From peter at PSDT.com Tue Dec 17 13:40:22 2002 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: Perl & Binary Data In-Reply-To: <4.3.2.7.2.20021217103317.00ab1a90@shell2.webquarry.com> References: <4.3.2.7.2.20021217095913.00aae260@shell2.webquarry.com> <4.3.2.7.2.20021217081747.00ab5010@shell2.webquarry.com> <4.3.2.7.2.20021217081747.00ab5010@shell2.webquarry.com> <4.3.2.7.2.20021217095913.00aae260@shell2.webquarry.com> Message-ID: <4.3.2.7.2.20021217113920.00b62ae0@shell2.webquarry.com> At 11:31 AM 12/17/02 -0800, I wrote: >abez@abez.ca wrote: > > > > >while ($len = sysread($fd,$buffer,$size)) { > > > > > my @o = unpack("s*",$buffer); > > > > > foreach (@o) { > > > > > $_/=2; > > > > > } > > > > > syswrite($fd,pack("s*",$buffer,$size); > > > > >} > > > > > > > > > >This seems really slow for datarates of 178kb/s > >This seems to work: > >my $data = "\x10\x02\x80\xff"; # Test data > >for (my $i = 0; $i < length($data); $i += 2) { > my $x = vec($data, $i >> 1, 16); > vec($data, $i >> 1, 16) = ($x >> 1) | ($x & 0b10000000); >} I forgot to say, please let me know if it's faster. It avoids a pack/unpack cycle, which has to be worth something. Although maybe vec() is no faster. Perhaps you could benchmark, I don't have the time. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From nkuipers at uvic.ca Tue Dec 17 15:03:26 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:12 2004 Subject: 2002 Perl Advent Calendar Message-ID: <3DFF9504@wm2.uvic.ca> Hello all, Just thought I'd pass along the following link in case you're not aware of it, since it's cute yet informative. http://www.perladvent.org/2002/ Enjoy, ;) Nathanael Kuipers From nkuipers at uvic.ca Fri Dec 20 17:12:49 2002 From: nkuipers at uvic.ca (nkuipers) Date: Wed Aug 4 00:11:12 2004 Subject: well... Message-ID: <3E03D806@wm2.uvic.ca> ...I have just today fninshed my semester, having handed in my directed studies paper that represents 8 months of Perl and biology intertwined, and will be leaving for my parents' place soon. I just wanted to give my best wishes for a restful and (dare I say it) blessed holiday season to everyone. Oh the humour. Thanks for all the wonderful meetings and correspondences, I have learned much and look forward to continuing with the PM in the new year. Hey Peter, special thanks to you for kickstarting the whole thing in the first place. Take care all, Nathanael From darren at DarrenDuncan.net Fri Dec 20 17:25:12 2002 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:12 2004 Subject: well... In-Reply-To: <3E03D806@wm2.uvic.ca> Message-ID: On Fri, 20 Dec 2002, nkuipers wrote: > ...I have just today fninshed my semester, having handed in my directed > studies paper that represents 8 months of Perl and biology intertwined, and > will be leaving for my parents' place soon. I just wanted to give my best > wishes for a restful and (dare I say it) blessed holiday season to everyone. > Oh the humour. Thanks for all the wonderful meetings and correspondences, I > have learned much and look forward to continuing with the PM in the new year. > Hey Peter, special thanks to you for kickstarting the whole thing in the first > place. > Take care all, > Nathanael What he said. -- Darren Duncan From peter at PSDT.com Fri Dec 20 17:28:58 2002 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:12 2004 Subject: well... In-Reply-To: <3E03D806@wm2.uvic.ca> Message-ID: <4.3.2.7.2.20021220152827.00b23340@shell2.webquarry.com> At 03:12 PM 12/20/02 -0800, nkuipers wrote: >...I have just today fninshed my semester, having handed in my directed >studies paper that represents 8 months of Perl and biology intertwined, and >will be leaving for my parents' place soon. I just wanted to give my best >wishes for a restful and (dare I say it) blessed holiday season to everyone. >Oh the humour. Thanks for all the wonderful meetings and correspondences, I >have learned much and look forward to continuing with the PM in the >new year. >Hey Peter, special thanks to you for kickstarting the whole thing in >the first >place. There are many things I've started that never went anywhere. That this one has succeeded in any measure is due to you guys, not me. Thanks! -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/