From Peter at PSDT.com  Thu Sep  8 15:55:00 2005
From: Peter at PSDT.com (Peter Scott)
Date: Thu, 08 Sep 2005 15:55:00 -0700
Subject: [VPM] Reminder - no September meeting
Message-ID: <6.1.2.0.2.20050902155410.027242b8@mail.webquarry.com>

Just a reminder - there will be no September Victoria Perl Mongers meeting.

Look for a sparkling new October meeting full of promise and surprise :-)
-- 
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com/
http://www.perlmedic.com/


From darren at DarrenDuncan.net  Sat Sep 10 17:24:31 2005
From: darren at DarrenDuncan.net (Darren Duncan)
Date: Sat, 10 Sep 2005 17:24:31 -0700
Subject: [VPM] ANNOUNCE: Rosetta/SQL-Routine developer release #3
Message-ID: <p06230901bf491911f0f1@[192.168.1.101]>

2005-09-10   Darren Duncan <perl at DarrenDuncan.net>
--------------------------------------------------

I am now pleased to announce the third developer release of my 
Rosetta rigorous database portability library, currently featuring 
the SQL::Routine module.  (For reference, the second developer 
release was on 2005-04-03, and the first developer release was on 
2004-08-07.)

The module set that can be broadly referred to as the 'Rosetta 
Framework' is composed of the following 6+ distributions; all of them 
are in native Perl 5 versions, and native Perl 6 versions are being 
co-developed beside Pugs (see its /ext directory for the latter).

A terse, 5-minute introduction to the framework as a whole can be 
found at http://darrenduncan.net/OSCON/OSCON2005LightningTalk.txt .

These native Perl 5 distributions are on CPAN now, 
http://search.cpan.org/~duncand/ :

   1. Locale-KeyedText-1.6.0.tar.gz
   2. SQL-Routine-0.70.0.tar.gz (dep on 1)
   3. Rosetta-0.48.0.tar.gz (dep on 1, 2); also holds Rosetta::Validator
   4. SQL-Routine-SQLBuilder-0.21.0.tar.gz (dep on 1, 2)
   5. SQL-Routine-SQLBuilder-0.2.0.tar.gz (dep on 1, 2)
   6. Rosetta-Engine-Generic-0.21.0.tar.gz (dep on 1, 2, 3, 4, 5)

For the bleeding edge, check out my new public Subversion repository 
(donated by Sam Vilain / mugwump), at 
http://svn.utsl.gen.nz/trunk/Rosetta/ .

Now, keep in mind that the over-all Rosetta Framework is in pre-alpha 
development status and DOES NOT WORK yet (but that the 
Locale-KeyedText component is complete and DOES work right now).  The 
purpose of this developer release announcement is to remind 
interested people that they can look at my current development 
snapshot for reasons of study and feedback.

I welcome and encourage any and all feedback on these modules that 
you can give me.  It would be VERY helpful to me.  I am also grateful 
if you can find these modules useful in your own work.  Likewise, if 
you have any questions, I will do my best to answer them.  If you 
wish to help with their development in some way, I am also open to 
such offers.

----------

This list indicates some of the more significant changes to the 
framework since the second developer release, as I recall them from 
memory.  For more details of this delta period, see the 'Changes' 
files that come with each of the above distributions.

* Starting with the current release set (2005-09-08), all modules and 
distributions now have three-part version numbers, which are more 
expressive, rather than floating point version numbers.  Related to 
this, all modules also have gained dependencies on the 'version' and 
'only' modules, which are available on CPAN; their functionality is 
built-in to Perl 6.

* There is now a public Subversion repository for all of these modules.

* 'SQL::Routine' and 'Rosetta' have gained a dependency on 
Scalar::Util (bundled with Perl) and use its weaken() function; 
object trees for each module will now auto-destruct normally, despite 
having circular references between them, and users no longer have to 
explicitly destroy() them.

* SQL::Routine::SQLBuilder now has a test suite and is actually known to work.

* 'SQL::Routine' has been simplified greatly.  Nodes can no longer 
exist outside Containers, so there's no extra add/remove steps.  The 
multiplicity of attribute-type specific Node attribute accessors are 
gone, with only more generic accessors remaining.  The build_* 
methods now take a more terse input format, composed of mixed array 
and hash refs, rather than all hash refs.

* SQL::Routine has gained a number of security features, making it 
easier to share a model by reference between various program 
sections, without them stepping on each other.  For example, one 
program section can place a read-lock on sections of the model it is 
generating actions from, so other sections can't change those and 
invalidate it.

* All files are now indented with spaces rather than tabs.

* Various POD sections have been reorganized/renamed/added, now 
better resembling the recommendation given by Damian Conway's "Perl 
Best Practices".

* 'Rosetta' has had huge changes to its API, to make it easier to use 
and more secure.

----------

This list indicates some of the most significant TODO items, which I 
expect to produce over the next few weeks, to end up with the fourth 
developer release.

* Make another large change set to the Rosetta API, which includes 
adding more Interface object types, making it more secure, and 
splitting 'compile' and 'prepare' apart from each other.

* Add functionality to Rosetta::Engine::Generic so that the framework 
as a whole can actually be used for something.

* Add a small demo app that demonstrates its being useful.

* Convert all objects to the inside-out format described in Best 
Practices, so to make it impossible for users to circumvent the API 
and mess with an object's properties directly; such users are the 
bane of many maintainers.

* Change the SQL routine meta model to more resemble Pascal rather 
than C, where you set a function's return value by assignment to a 
named psudo-argument, rather than invoking 'return' with a parameter; 
this makes a function's return values look the same as 'OUT' or 
'INOUT' arguments to statements inside the function.

* Add explicit support for LOBs to the framework, such that large 
scalar values can be processed in chunks, rather than being entirely 
put in a scalar variable.

* Complete the read lock, mutex, and model-transaction feature of SQL::Routine.

* Add Module::Build support to the distros.

* Make a Bundle::Rosetta distribution.

* Whatever else needs doing.

----------

Have a good day. -- Darren Duncan

From abez at abez.ca  Sat Sep 24 13:19:07 2005
From: abez at abez.ca (abez)
Date: Sat, 24 Sep 2005 16:19:07 -0400 (EDT)
Subject: [VPM] Perl Reviewed in 1 line
Message-ID: <Pine.LNX.4.44.0509241617490.1843-100000@tsunami.abez.ca>

my 1 line review of perl
perl -e 'print map {(split(//))[0]} (q study abs, q chomp getc, q die bind, q lstat eval, q g u lag, q die bind, q lstat eval, q y u may, q wantarray qw, q y han may, q crypt ungetc, q next warn, q eval time, q die bind, q keys break, q qw uniq)'

-- 
abez ------------------------------------------
http://www.abez.ca/ Abram Hindle (abez at abez.ca)
------------------------------------------ abez


From crimson at uvic.ca  Mon Sep 26 09:13:55 2005
From: crimson at uvic.ca (Clarke Brunsdon)
Date: Mon, 26 Sep 2005 09:13:55 -0700
Subject: [VPM] Requesting a time-chunk
In-Reply-To: <Pine.LNX.4.44.0509241617490.1843-100000@tsunami.abez.ca>
References: <Pine.LNX.4.44.0509241617490.1843-100000@tsunami.abez.ca>
Message-ID: <1127751235.933.4.camel@localhost>

Ahoy hoy

If possible, could I get a chunk of time at the next meeting to talk
about my in-progress POE IRC bot?

I think its pretty neat and solves a couple of the problems we saw in
the last IRC talk (namely smooth reloading), while introducing a host of
new ones (natrually).

Thanks
~Clarke


From darren at DarrenDuncan.net  Mon Sep 26 12:04:11 2005
From: darren at DarrenDuncan.net (Darren Duncan)
Date: Mon, 26 Sep 2005 12:04:11 -0700
Subject: [VPM] Requesting a time-chunk
In-Reply-To: <1127751235.933.4.camel@localhost>
References: <Pine.LNX.4.44.0509241617490.1843-100000@tsunami.abez.ca>
	<1127751235.933.4.camel@localhost>
Message-ID: <p06230900bf5df68e0ac1@[192.168.1.101]>

At 9:13 AM -0700 9/26/05, Clarke Brunsdon wrote:
>Ahoy hoy
>
>If possible, could I get a chunk of time at the next meeting to talk
>about my in-progress POE IRC bot?
>
>I think its pretty neat and solves a couple of the problems we saw in
>the last IRC talk (namely smooth reloading), while introducing a host of
>new ones (natrually).
>
>Thanks
>~Clarke

Sounds good to me.  Go for it! -- Darren Duncan

From sergiolcrezende at gmail.com  Mon Sep 26 18:52:37 2005
From: sergiolcrezende at gmail.com (sergio rezende)
Date: Mon, 26 Sep 2005 22:52:37 -0300
Subject: [VPM] How to find the processing of a server windows?
Message-ID: <28cdcb9e05092618521e284ae8@mail.gmail.com>

It has some module in *perl* what does it show the processing or available
memory of a *server* windows?

 Thanks


--
-:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/victoria-pm/attachments/20050927/2a78276e/attachment.html

From darren at DarrenDuncan.net  Fri Sep 30 22:12:49 2005
From: darren at DarrenDuncan.net (Darren Duncan)
Date: Fri, 30 Sep 2005 22:12:49 -0700
Subject: [VPM] ANNOUNCE: reboot of Rosetta/SQL-Routine development, in Perl 6
Message-ID: <p06230900bf63ac69f542@[192.168.1.101]>

2005-09-30   Darren Duncan <perl at DarrenDuncan.net>
--------------------------------------------------

I would like to acknowledge that, despite all the good things that 
have come out of it, I have had some significant problems in regards 
to the past development of my Rosetta rigorous database portability 
framework.

(As a reminder of what this is, a terse, 5-minute introduction can be 
found at http://darrenduncan.net/OSCON/OSCON2005LightningTalk.txt ).

The main problem being that it is taking an order of magnitude too 
long to come out with a product that is actually useable for 
practical work.  I see one root cause of this being my packrat nature 
of not wanting to throw out portions of the project (a lot of that 
being documentation) that I already invested time in, since they 
could still be useful.  Another main problem was a persuit of 
perfectionism that left me spending too long on little details that 
could better have been put off until later, and this multiplied by 
the size of of a system that has a semblence of being 
over-engineered.  Also, in hind-sight it was a mistake to limit 
certain implementation decisions in the core due to a desire to make 
a C version later, which is a less expressive tool.

I have decided that now is an excellent time to start over and remake 
the system from the ground up.  But while this is an opportunity to 
change many things, I see the larger scale design of the previous 
version to still be sound, as well as its planned feature set, and so 
therefore the new version will look like the old one at a distance. 
The main difference will be in the details of the API and in the 
internals, plus the new documentation won't be so verbose.  Many 
valuable lessons were still learned in the first attempt to make this 
project, and will be applied in the new version.  In some respects, 
the new version will actually be akin to a large refactor of the old, 
and not so much a rewrite where the fundamental design and feature 
plan sees change.  However, all of the code and documentation is in 
fact being re-typed, so many things can be changed, even with the old 
version being a rough guideline to follow.

In this process, I also draw a lot of inspiration from Autrijus Tang 
and his Pugs project, which demonstrates ways to come up with 
something amazing in a short period of time, and spark strong 
interest and participation from the wider community, a killer app of 
development models perhaps.

So what are the practical benefits and effects of this reboot, then? 
Here are the most pertinent:

1. Development speed will be several orders of magnitude faster than 
before, measured by the rate at which actual useable features are 
made available to users, even when I'm the sole developer (as I was 
before).  You will actually be able to see progress being made, and I 
will have more personal satisfaction in my output.

2. Development will now proceed vertically first and horizontally 
second, rather than the reverse which was true before.  This means 
that at any given period of time, we will have a small number of 
features that are 100% complete and useable *now* vs a large number 
of features that are 80% complete and wholly unuseable, which is the 
case in the older system.

3. Since people will be able to actually use the system for 
something, whether work or play, it will be a lot easier for them to 
get excited about it, then turn around and participate in its further 
development.

4. Perl 6 is now the primary native platform of the Rosetta 
framework, and Rosetta's design and implementation will be driven by 
what is considered the most natural and best practices in Perl 6. 
This action both helps the development of Pugs itself through the 
extra integration testing it provides, but it also helps anyone that 
wants to make database using applications in Perl 6 to migrate there 
faster.  The Perl 6 version will not be a port of the Perl 5 version 
after the latter is done.

5. But because Perl 6 is still very much a moving target, and its 
implementations unstable, a native Perl 5 version will be developed 
simultaneously and be kept in full parity with it; this task is made 
a lot easier by the multiple modules on CPAN or bundled with Perl 5 
that give it functionality and syntax like Perl 6 has natively, such 
as 'version' and 'List::MoreUtils' and 'Class::Std'; but the Perl 5 
version should still be very stable and efficient, a good Perl 5 
citizen.

6. If you have ideas you want to contribute towards improving 
Rosetta, it will be a lot easier for me to adopt them now that the 
pot has been emptied.  And don't worry if you think that your ideas 
were already in my un-stated plans; its always nice to have 
confirmation of an idea's validity.

7. The code will be visibly smaller and more nimble.

8. Certain classes of features will be available sooner than otherwise.

9. Lastly, I can finally start to build other products of my own that 
employ Rosetta (providing useful benefits to others, and income to 
me), even if at a fraction of functionality, rather than putting off 
the start of their development until Rosetta is done.

So where is this all happening, you may ask?  In 2 main places:

1. The native Perl 6 version is being co-developed with Pugs, like a 
variety of other Perl 6 native modules and applications; you can see 
the newest version in Pugs' own public Subversion repository (see 
http://pugscode.org/ for links) and in its distributions on CPAN; see 
the sub-directory "/modules/Rosetta-Incubator" for now.

2. The native Perl 5 version has a public Subversion repository 
(donated by Sam Vilain / mugwump), at 
"http://svn.utsl.gen.nz/trunk/Rosetta-Incubator/", the same server 
but different directory as the previous project attempt.

Note that the module names and versions will continue directly from 
the series in the previous project attempt, and will show up on CPAN 
as successors later.

Once this rewrite of Rosetta gets to the point of being useable for 
something, I will announce "Rosetta/SQL-Routine developer release 
#4"; this is actually in line with my announced plans that came with 
the September 10th "developer release #3".  Given the acceleration 
resulting from this re-write, I expect that to happen any week now.

Thank you and have a good day.

-- Darren Duncan