From darren at DarrenDuncan.net Thu Aug 7 11:08:56 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] OT: About Linux' mascot Message-ID: I just saw this again today, and thought you might like it. http://joyoftech.com/joyoftech/joyimages/001_300/046.gif -- Darren Duncan From darren at DarrenDuncan.net Thu Aug 7 11:52:13 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] APSL v2.0 now qualifies as "free software" according to FSF Message-ID: As you know, some parts of Mac OS X (darwin) and other Apple technologies have been made available under an open-source license for the last few years. The original Apple Public Source License v1.x had issues with it such that the Free Software Foundation said it did not qualify as "free"; APSL 1.0 had 3 conditions preventing that; APSL 1.2 changed two but 1 was left. And now APSL 2.0 removes the third. And so the Free Software Foundation now considers APSL 2.0 licensed works to be actually "free". Considering their weight in the developer communities, this change should give a significant boost to the number or quality of people working to improve Apple's open source software projects, which should be beneficial for us all. For a couple references (in the order I discovered them): http://maccentral.macworld.com/news/2003/08/06/apsl/ http://www.gnu.org/philosophy/apsl.html http://apple.slashdot.org/apple/03/08/06/1729213.shtml?tid=107&tid=117&tid=187&tid=99 -- Darren Duncan From darren at DarrenDuncan.net Mon Aug 11 16:58:59 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related Message-ID: Hello, this request for comment is in particular aimed at those of you who use databases and/or DBI with Perl. Thanks to a topic covered in Piers Cawley's most recent Perl 6 Summary (generic Parrot code generators), I think I have finally figured out what is the standard industry terminology to describe and/or use to name a new module I am making: "AST" or "Abstract Syntax Tree". P.S. Please CC your reply directly to my address (darren@DarrenDuncan.net) in addition to sending it to the discussion list. I am writing you today to get second opinions for proposed names on my new module, which I would like to register as soon as possible. The current working title I have, which came out of a productive RFC I did on May 29th, is "SQL::ObjectModel". I did submit that name on June 2nd to get registered; it never got registered, but on the bright side it gave me time to come up with the possibly better title. I propose something like "SQL::AST" or "SQL::AbstractSyntax" or "SQL::AbstractSyntaxTree". I like the first one best, because it is short. Or maybe "SQL::AS". SQL::ObjectModel is currently on CPAN in alpha development status, and I plan to upload a major code/design revision in the next few days. But if possible I would like to know if the new module name is workable, in which case I will upload under that name. So my question for you is, does "SQL::AST" sound good, and is the term "AST" well known enough that people who would likely use this module would know its meaning? Or would I attract more users by expanding the title. Or should I stick with ObjectModel? In my mind, AST seems to be a lot more descriptive to what the module actually does, or rather "is". On a related question, after I have finished the PurePerl implementation of this module, I plan to make a C library implementation, and so what would be a good name for that? In my experience, C libraries often have names like "libABC" (such as libXML); might I be best to have a name like that, such as "libSQLAST". Or would it sound better without that, such as "SQLAST"? Thank you very much in advance for any feedback. -- Darren Duncan P.S. For your convenience, below is a copy of some pod from SQL::ObjectModel v0.03, which describes it. It will be updated/rewritten after the rename. --------------------------------- This Perl 5 object class is intended to be a powerful but easy to use replacement for SQL strings (including support for placeholders), which you can use to make queries against a database. Each SQL::ObjectModel object can represent a non-ambiguous structured command for a database to execute, or one can be a non-ambiguous structured description of a database schema object. This class supports all types of database operations, including both data manipulation and schema manipulation, as well as managing database instances and users. You typically construct a database query by setting appropriate attributes of these objects, and you execute a database query by evaluating the same attributes. SQL::ObjectModel objects are designed to be equivalent to SQL in both the type of information they carry and in their conceptual structure. This is analagous to how XML DOMs are objects that are equivalent to XML strings, and they can be converted back and forth at will. If you know SQL, or even just relational database theory in general, then this module should be easy to learn. SQL::ObjectModels are intended to represent all kinds of SQL, both DML and DDL, both ANSI standard and RDBMS vendor extensions. Unlike basically all of the other SQL generating/parsing modules I know about, which are limited to basic DML and only support table definition DDL, this class supports arbitrarily complex select statements, with composite keys and unions, and calls to stored functions; this class can also define views and stored procedures and triggers. Some of the existing modules, even though they construct complete SQL, will take/require fragments of SQL as input (such as "where" clauses) By contrast, SQL::ObjectModel takes no SQL fragments. All of its inputs are atomic, which means it is also easier to analyse the objects for implementing a wider range of functionality than previously expected; for example, it is much easier to analyse any select statement and generate update/insert/delete statements for the virtual rows fetched with it (a process known as updateable views). Considering that each database product has its own dialect of SQL which it implements, you would have to code SQL differently depending on which database you are using. One common difference is the syntax for specifying an outer join in a select query. Another common difference is how to specify that a table column is an integer or a boolean or a character string. Moreover, each database has a distinct feature set, so you may be able to do tasks with one database that you can't do with another. In fact, some databases don't support SQL at all, but have similar features that are accessible thorough alternate interfaces. SQL::ObjectModel is designed to represent a normalized superset of all database features that one may reasonably want to use. "Superset" means that if even one database supports a feature, you will be able to invoke it with this class. You can also reference some features which no database currently implements, but it would be reasonable for one to do so later. "Normalized" means that if multiple databases support the same feature but have different syntax for referencing it, there will be exactly one way of referring to it with SQL::ObjectModel. So by using this class, you will never have to change your database-using code when moving between databases, as long as both of them support the features you are using (or they are emulated). That said, it is generally expected that if a database is missing a specific feature that is easy to emulate, then code which evaluates SQL::ObjectModels will emulate it (for example, emulating "left()" with "substr()"); in such cases, it is expected that when you use such features they will work with any database. For example, if you want a model-specified boolean data type, you will always get it, whether it is implemented on a per-database-basis as a "boolean" or an "int(1)" or a "number(1,0)". Or a model-specified "str" data type you will always get it, whether it is called "text" or "varchar2" or "sql_varchar". SQL::ObjectModel is intended to be just a stateless container for database query or schema information. It does not talk to any databases by itself and it does not generate or parse any SQL; rather, it is intended that other third party modules or code of your choice will handle this task. In fact, SQL::ObjectModel is designed so that many existing database related modules could be updated to use it internally for storing state information, including SQL generating or translating modules, and schema management modules, and modules which implement object persistence in a database. Conceptually speaking, the DBI module itself could be updated to take SQL::ObjectModel objects as arguments to its "prepare" method, as an alternative (optional) to the SQL strings it currently takes. Code which implements the things that SQL::ObjectModel describes can do this in any way that they want, which can mean either generating and executing SQL, or generating Perl code that does the same task and evaling it, should they want to (the latter can be a means of emulation). This class should make all of that easy. SQL::ObjectModel is especially suited for use with applications or modules that make use of data dictionaries to control what they do. It is common in applications that they interpret their data dictionaries and generate SQL to accomplish some of their work, which means making sure generated SQL is in the right dialect or syntax, and making sure literal values are escaped correctly. By using this module, applications can simply copy appropriate individual elements in their data dictionaries to SQL::ObjectModel properties, including column names, table names, function names, literal values, bind variable names, and they don't have to do any string parsing or assembling. Now, I can only imagine why all of the other SQL generating/parsing modules that I know about have excluded privileged support for more advanced database features like stored procedures. Either the authors didn't have a need for it, or they figured that any other prospective users wouldn't need it, or they found it too difficult to implement so far and maybe planned to do it later. As for me, I can see tremendous value in various advanced features, and so I have included privileged support for them in SQL::ObjectModel. You simply have to work on projects of a significant size to get an idea that these features would provide a large speed, reliability, and security savings for you. Look at many large corporate or government systems, such as those which have hundreds of tables or millions of records, and that may have complicated business logic which governs whether data is consistent/valid or not. Within reasonable limits, the more work you can get the database to do internally, the better. I believe that if these features can also be represented in a database-neutral format, such as what SQL::ObjectModel attempts to do, then users can get the full power of a database without being locked into a single vendor due to all their investment in vendor-specific SQL stored procedure code. If customers can move a lot more easily, it will help encourage database vendors to keep improving their products or lower prices to keep their customers, and users in general would benefit. So I do have reasons for trying to tackle the advanced database features in SQL::ObjectModel. From yf110 at victoria.tc.ca Mon Aug 11 18:04:19 2003 From: yf110 at victoria.tc.ca (Malcolm Dew-Jones) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related In-Reply-To: References: Message-ID: Personally when I see AST I think of VMS and A-Synchronous Traps. I notice that a google search shows the achronym AST is used for many computer related things besides abstract syntax trees. The CPAN rules suggest avoiding achronyms. On the other hand I find the name SQL::AbstractSyntaxTree to be pretty much self explanatory, unlike the shorter variations, and the only issue is that is a little bit long. I'm not sure that shortening the name of the module is a sensible "optimization" of anything. The code a programmer needs to write could still be be pleasantly terse $ast = new SQL::AbstractSyntaxTree(); $ast->Method()... etc. $0.02 From darren at DarrenDuncan.net Mon Aug 11 19:54:14 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related In-Reply-To: <3F384DCD@wm2.uvic.ca> References: <3F384DCD@wm2.uvic.ca> Message-ID: At 4:01 PM -0700 8/11/03, Nathanael Kuipers wrote: >I prefer SQL::AbstractSyntaxTree myself, favoring the descriptive name over >yet another acronym, particularly in the area of databasing. > >Users familiar with the Perl implementation who wish to switch to the C >implementation would not have any trouble using libsqlAST or what have you. > >Cheers, > >Nathanael At 4:04 PM -0700 8/11/03, Malcolm Dew-Jones wrote: >Personally when I see AST I think of VMS and A-Synchronous Traps. > >I notice that a google search shows the achronym AST is used for many >computer related things besides abstract syntax trees. > >The CPAN rules suggest avoiding achronyms. > >On the other hand I find the name SQL::AbstractSyntaxTree to be pretty >much self explanatory, unlike the shorter variations, and the only issue >is that is a little bit long. I'm not sure that shortening the name of >the module is a sensible "optimization" of anything. > >The code a programmer needs to write could still be be pleasantly terse > > $ast = new SQL::AbstractSyntaxTree(); > > $ast->Method()... etc. > >$0.02 Thank you both for your feedback. It was greatly appreciated, along with the reasoning that went with it. It's also a good sign when two people independantly suggest the same name. It also sounds good to me, I think I will go with SQL::AbstractSyntaxTree for a name. (Of course, I am still open to hearing other opinions or additions.) Have a good day. -- Darren Duncan From darren at DarrenDuncan.net Tue Aug 12 13:06:12 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Re: [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related In-Reply-To: <20030812143004.GC13812@dansat.data-plan.com> References: <20030812143004.GC13812@dansat.data-plan.com> Message-ID: Thank you very much to all of you who replied (6 people at least), even though only some of them are quoted below. At 10:41 AM +0100 8/12/03, Ed Avis wrote: > How about just SQL::Tree? > > Since it is a Perl module nobody should think this is a package of SQL > routines for tree handling. > > Before you use 'abstract syntax tree' make doubly sure you know what > an AST is and how it differs from a concrete syntax tree. I don't! > > Ed Avis I know that 'abstract' is more correct because my module is an abstracted representation of SQL which can be converted to or from any concrete SQL version, either ANSI or an RDBMS vendor variant. I can not use 'concrete' because that would mean the class is identical to a SQL variant. Regarding 'SQL::Tree', that name is nice and short, but it almost sounds too generic. At 3:30 PM +0100 8/12/03, Tim Bunce wrote: >Short names are generally not good names. SQL::AbstractSyntaxTree >sounds okay, as does SQL::ObjectModel. I think SQL::ObjectModel is >a more "friendly" name. Not that I'm surprised, since you suggested it last time. :) But two words does seem much easier to say than three ... >As a counter example I offer Data::Dumper and DBI. Both come with >C and pure-perl implementations that are selected automatically. >Much simpler for the user. > >Tim. Part of my reasoning for asking about a separate C module name is that I intend for the C module to be useable with any programming language, through a binding layer (XS in Perl 5's case, ? in Parrot's case), much as GD or libXML are. So, are there any pure C modules that have ':' in their names? Or that could be a non-issue. For that matter, are C library names usually the same as their compiled file names? If I used SQL::ObjectModel for the Perl name, then SQLObjModel perhaps might work for a C name? At 12:56 PM -0400 8/12/03, Matthew Simon Cavalletto wrote: >My two cents: SQL::AST is too short and cryptic, forcing me to guess which AST you're referring to, while SQL::AbstractSyntaxTree strikes me as workable but maybe a bit long (the module compatibility guideline is a maximum of 11 characters per name component). > >Of the three words Abstract Syntax Tree, the one that seems to me least valuable is Abstract, so you might also consider SQL::SyntaxTree as a candidate -- it's short enough, and pretty much self-explanatory. > >-Simon Well, 'AST' is definately not going to be used; everyone agrees with that. Maybe 'Abstract' is less important, though I consider it meaningful, though maybe that isn't actually a problem. Thanks for pointing out the 11 character dealy though. So, I have an idea. What if I were to keep the previous name (not yet registered) of 'SQL::ObjectModel' for the module itself, and use 'Abstract Syntax Tree' in the description? For example: SQL:: ::ObjectModel adhOg An abstract syntax tree for SQL DUNCAND So who likes that for a registration? Or should I keep SyntaxTree in the module name instead (and object model in the desc)? Or are there other suggestions? -- Darren Duncan From Peter at PSDT.com Tue Aug 12 14:50:28 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Next meeting Message-ID: <5.2.1.1.2.20030812124923.00b40be0@shell2.webquarry.com> So who's up for meeting next week? Are there many folks out of town? Tentative topic: presentation on the Template Toolkit by moi. Any other suggestions welcome. When shall we meet? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From darren at DarrenDuncan.net Tue Aug 12 15:47:04 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Next meeting In-Reply-To: <5.2.1.1.2.20030812124923.00b40be0@shell2.webquarry.com> References: <5.2.1.1.2.20030812124923.00b40be0@shell2.webquarry.com> Message-ID: Peter Scott said: >So who's up for meeting next week? Are there many folks out of town? > >Tentative topic: presentation on the Template Toolkit by moi. > >Any other suggestions welcome. > >When shall we meet? I should be fine with next week. I suggest Wednesday but am fairly open. As far as a topic, what you suggest could be good, since I know little to nothing about Template Toolkit. Something else I also wanted to know more about is SAX. Both of them sound like something that I might use if I knew what they were good for, but I have had trouble finding a good introduction. Also, never mind on my request for how to compile Perl from source; I figured it out and did 5.8.1rc4 successfully last week, under Mac OS X 10.2.6. (I also timed the process, but forget where I wrote the numbers; it was fast, though.) On the other hand, I still haven't tried to compile optional Perl extensions like DBI or GD yet. -- Darren Duncan From Peter at PSDT.com Tue Aug 12 16:06:38 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Next meeting In-Reply-To: References: <5.2.1.1.2.20030812124923.00b40be0@shell2.webquarry.com> <5.2.1.1.2.20030812124923.00b40be0@shell2.webquarry.com> Message-ID: <5.2.1.1.2.20030812140618.00b40be0@shell2.webquarry.com> At 01:47 PM 8/12/2003 -0700, Darren Duncan wrote: >As far as a topic, what you suggest could be good, since I know little >to nothing about Template Toolkit. Something else I also wanted to >know more about is SAX. Both of them sound like something that I >might use if I knew what they were good for, but I have had trouble >finding a good introduction. We should have an XML person among us who knows that... anyone? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From darren at DarrenDuncan.net Tue Aug 12 16:18:32 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Next meeting In-Reply-To: <5.2.1.1.2.20030812140618.00b40be0@shell2.webquarry.com> References: <5.2.1.1.2.20030812124923.00b40be0@shell2.webquarry.com> <5.2.1.1.2.20030812124923.00b40be0@shell2.webquarry.com> <5.2.1.1.2.20030812140618.00b40be0@shell2.webquarry.com> Message-ID: Peter Scott said: >At 01:47 PM 8/12/2003 -0700, Darren Duncan wrote: >>As far as a topic, what you suggest could be good, since I know little to nothing about Template Toolkit. Something else I also wanted to know more about is SAX. Both of them sound like something that I might use if I knew what they were good for, but I have had trouble finding a good introduction. > >We should have an XML person among us who knows that... anyone? Not necessarily. While I will be using it for XML, one of the reasons I had trouble understanding SAX is that it doesn't seem to be specific to XML, and can be used for a wide variety of other things (all of the examples I found did). Or I was misreading the examples. -- Darren Duncan From nkuipers at uvic.ca Tue Aug 12 18:08:43 2003 From: nkuipers at uvic.ca (Nathanael Kuipers) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Next meeting Message-ID: <3F398DB6@wm2.uvic.ca> Wednesday is good for me too. Monday is the only other option for me. Prefer wednesday. As for XML SAX, I don't know much about it but I have that Perl&XML book (that I forgot to bring for Darren last meeting) and I will remember it this time. Cheers, Nathanael From Peter at PSDT.com Tue Aug 12 21:03:58 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Next meeting In-Reply-To: <3F398DB6@wm2.uvic.ca> Message-ID: <5.2.1.1.2.20030812190134.00b43e00@shell2.webquarry.com> At 04:08 PM 8/12/2003 -0700, Nathanael Kuipers wrote: >Wednesday is good for me too. Monday is the only other option for >me. Prefer >wednesday. As for XML SAX, I don't know much about it but I have that >Perl&XML book (that I forgot to bring for Darren last meeting) and I will >remember it this time. > >Cheers, > >Nathanael Okay, Wednesday August 20... do I hear any objections? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From abez at abez.ca Wed Aug 13 10:10:51 2003 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:26 2004 Subject: [VPM] Next meeting In-Reply-To: <5.2.1.1.2.20030812190134.00b43e00@shell2.webquarry.com> References: <5.2.1.1.2.20030812190134.00b43e00@shell2.webquarry.com> Message-ID: I have no problem with Aug 20. If no one objects by the end of the day I will book it. abram On Tue, 12 Aug 2003, Peter Scott wrote: > At 04:08 PM 8/12/2003 -0700, Nathanael Kuipers wrote: > >Wednesday is good for me too. Monday is the only other option for > >me. Prefer > >wednesday. As for XML SAX, I don't know much about it but I have that > >Perl&XML book (that I forgot to bring for Darren last meeting) and I will > >remember it this time. > > > >Cheers, > > > >Nathanael > > Okay, Wednesday August 20... do I hear any objections? > > -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From darren at DarrenDuncan.net Wed Aug 13 21:45:00 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:26 2004 Subject: [VPM] Re: [RFC] SQL::AST (SQL Abstract Syntax Tree) - DBI related In-Reply-To: References: Message-ID: At 3:03 PM -0400 8/12/03, Matthew Simon Cavalletto wrote: >I believe the convention is for the portable C library to be named something short like libSQLOM, with the Perl code either in SQL::ObjectModel or a related namespace like SQL::ObjectModelXS or SQL::ObjectModel::libSQLOM. Thank you Matthew. I think I will name the C library either "SQLOM" or "libSQLOM", unless someone else has used the name already (unlikely). But the public face of the Perl module will still be "SQL::ObjectModel". >Consider this guidance from perlmodlib: "Generally the name should reflect what is special about what the module does rather than how it does it." > >The name you pick should focus on the distinct purpose of the module -- ie, providing a static representation of various kinds of SQL statements. > >The fact that your module is implemented as a tree of objects, rather than as functions which operate on nested hash-refs or whatever, is an implementation detail. Actually, the reason I use "Object" in the name is to describe what the module *is* conceptually. I am not using it to refer to the implementation. In fact, the C implementation will be very definately not a set of objects (but rather a set of structs that reference each other). The fact that the Perl interface is object oriented is a convention that I like to use, and it goes with the conceptual idea of what the module is. >In practice, many of the modules on CPAN are based on some kind of "object model," but don't use it in their class names -- for example, think of the many distributions that could have been named "XML::ObjectModel." > >-Simon XML is different. There is an official W3C standard called "Document Object Model" (DOM) which is a conceptual object holding an XML syntax tree. My use of "Object Model" was inspired by the XML, since my module does with SQL what a DOM does with XML. So, based on what I have seen and heard from the feedback (thank you all), including that 11-character thing, I think that this is what I will try to register: SQL:: ::ObjectModel adhOg An abstract syntax tree for SQL DUNCAND Have a good day. -- Darren Duncan From Peter at PSDT.com Thu Aug 14 17:35:41 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:26 2004 Subject: [VPM] Victoria Perl Mongers meeting Message-ID: <5.2.1.1.2.20030814152902.00b2c698@shell2.webquarry.com> Victoria.pm will meet next week on Wednesday, August 20, 7pm, at UVic. Abram is reserving the room and I shall announce it by email the day before the meeting. I will present on Andy Wardley's Template Toolkit. Other topics may be raised ad hoc in the remaining time. Other topics to be covered as time permits; make requests for anything particular. I shall give away an Open Source Convention tote bag by the usual method. (Okay, so you can tell what the source of the giveaways is... hey, it beats a slap in the face with a wet fish.) (Courtesy copy to VLUG members by permission of the list manager. Victoria.pm's home page is .) -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From Peter at PSDT.com Tue Aug 19 12:00:00 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:26 2004 Subject: [VPM] Victoria Perl Mongers meeting tomorrow Message-ID: <5.2.1.1.2.20030818114737.01b662f0@shell2.webquarry.com> Victoria.pm will meet tomorrow, Wednesday, August 20, 7pm, at UVic CIT120 as on the last few occasions. Thanks to Abram for getting the room. I will present on Andy Wardley's Template Toolkit. Other topics may be raised ad hoc in the remaining time. I shall give away an Open Source Convention tote bag by the usual method. (Courtesy copy to VLUG members by permission of the list manager. Victoria.pm's home page is .) -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From darren at DarrenDuncan.net Tue Aug 19 12:24:26 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:26 2004 Subject: [VPM] Victoria Perl Mongers meeting tomorrow In-Reply-To: <5.2.1.1.2.20030818114737.01b662f0@shell2.webquarry.com> References: <5.2.1.1.2.20030818114737.01b662f0@shell2.webquarry.com> Message-ID: Sounds good. And hopefully Nathaniel will bring his Perl and XML book too, as I look forward to browsing it. -- Darren Duncan From Peter at PSDT.com Wed Aug 20 14:42:20 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:26 2004 Subject: [VPM] Video connection Message-ID: <5.2.1.1.2.20030820124043.00b2d0c8@shell2.webquarry.com> My Compaq is in for repair and I will only have the iBook tonight. I am not using it for my presentation (will use whiteboard), but if anyone wants to see something on a computer and project it, either bring another machine or the cable that will go from my iBook to the wall (I believe that needs to be male-male). -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From abez at abez.ca Wed Aug 20 16:09:37 2003 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:26 2004 Subject: [VPM] Video connection In-Reply-To: <5.2.1.1.2.20030820124043.00b2d0c8@shell2.webquarry.com> References: <5.2.1.1.2.20030820124043.00b2d0c8@shell2.webquarry.com> Message-ID: the room doesn't have a whiteboard I don't think, we can check the other rooms in the building. I think I'll bring my laptop just in case. abram On Wed, 20 Aug 2003, Peter Scott wrote: > My Compaq is in for repair and I will only have the iBook tonight. I > am not using it for my presentation (will use whiteboard), but if > anyone wants to see something on a computer and project it, either > bring another machine or the cable that will go from my iBook to the > wall (I believe that needs to be male-male). > -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From peter at PSDT.com Wed Aug 20 16:17:32 2003 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:26 2004 Subject: [VPM] Video connection In-Reply-To: References: <5.2.1.1.2.20030820124043.00b2d0c8@shell2.webquarry.com> <5.2.1.1.2.20030820124043.00b2d0c8@shell2.webquarry.com> Message-ID: <5.2.1.1.2.20030820141707.00b2d0c8@shell2.webquarry.com> At 02:09 PM 8/20/2003 -0700, abez wrote: >the room doesn't have a whiteboard I don't think, we can check the other rooms >in the building. > >I think I'll bring my laptop just in case. It's got an overhead projector? I can bring transparencies and pens. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From abez at abez.ca Wed Aug 20 16:16:17 2003 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:26 2004 Subject: [VPM] Video connection In-Reply-To: <5.2.1.1.2.20030820141707.00b2d0c8@shell2.webquarry.com> References: <5.2.1.1.2.20030820124043.00b2d0c8@shell2.webquarry.com> <5.2.1.1.2.20030820124043.00b2d0c8@shell2.webquarry.com> <5.2.1.1.2.20030820141707.00b2d0c8@shell2.webquarry.com> Message-ID: Do that. If the room lacks on there are other rooms to swipe one from. abram On Wed, 20 Aug 2003, Peter Scott wrote: > At 02:09 PM 8/20/2003 -0700, abez wrote: > > >the room doesn't have a whiteboard I don't think, we can check the other rooms > >in the building. > > > >I think I'll bring my laptop just in case. > > It's got an overhead projector? I can bring transparencies and pens. > > > -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From peter at PSDT.com Wed Aug 20 17:12:38 2003 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:26 2004 Subject: [VPM] pavel@md5.ca Message-ID: <5.2.1.1.2.20030820151205.00b2d0c8@shell2.webquarry.com> If anyone knows another address to contact pavel@md5.ca at, please advise him that his Victoria.pm mail is bouncing with a gnarly error. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/