sprog-users — This list is for both users and developers of Sprog.

Re: [sprog-users] Make Test and Apache LogRegex module

[Grant M. <gr...@mc...>]

On Sat, 2005-06-25 at 20:36 +0100, Gavin Henry wrote:
> Have you any thoughts about getting it into Fedora Extras?

That sounds like a great idea.  I'm a Debian user so I've sorted out a
Debian package and repository.  Gavin Brown helped me set up a process
for creating a generic RPM package on my Debian box, but I really need
someone knowledgeable about repositories for their distribution to act
as packaging maintainer.

Cheers
Grant

Re: [sprog-users] Re: Sprog::Gear::ReadExcel.pm Code Review

[Grant M. <gr...@mc...>]

On Sat, 2005-06-25 at 12:35 -0400, Marc Slagle wrote:
> Grant McLean wrote:
> >* The file_start and file_end events both send an argument of undef.
> >  It really ought to be the filename.
>
> Next version will do this.

Actually if you switch to not reading from a file then you can leave out
the file_start, file_end stuff altogether - it will be handled
automatically by the ReadFile gear.

> >* I'd also suggest that your gear shouldn't read from a file at all.
> >
> I will update the code to handle input this way.

I've just checked in to CVS a SlurpFile mixin module which handles the
details of file_start/end so all your gear needs to do is:

  use base qw(
    Sprog::Gear::SlurpFile
    Sprog::Gear
  );

  sub file_data {
    my($self, $data, $filename) = @_;

    # do stuff with $data and call $self->msg_out
  }

Expect a release in a day or two.

> I have one question about the XML dialogs.  It my be 
> documented, and if it is tell me to RTFM.  I would like to have the 
> system pop up the dialog box with a pulldown list of the sheets on the 
> excel file if they have not selected one.  

Hmm that's tricky from many angles.

* I haven't implemented drop downs in properties dialogs yet because 
  I haven't needed them (yet).

* You can't do it in a normal properties dialog anyway because the
  ParseExcel gear won't know the filename until run-time.

* When I implement the ReadFiles gear, someone could drag-n-drop
  multiple files onto a machine.

* In theory, you could pop-up a dialog at run-time, but you'd need to
  implement that in a custom gear view class.  None of the existing
  gears use dialogs at run time.

> After this excel 
> module is put to rest I plan on moving into an XSLT gear, since I 
> already have a need for that.

That one is on my list too.  Not that I'd discourage you from taking it
on.

> I'm also considering touching MySQL data 
> input/output gears, since being able to shuffle spreadsheets on my 
> desktop and either read or write records to my database would also make 
> life a lot easier.

Yes, DBI connectivity is a much needed feature.  See my other email for
a workaround you might be able to use now.

Cheers
Grant

[sprog-users] DBI Gear

[Grant M. <gr...@mc...>]

Hi All (and perhaps Tony in particular :-))

Obviously Sprog needs the ability to source data from a database via
DBI.  The tricky part of writing data source gears is the need for
non-blocking IO.  If someone submits a query that takes several minutes
to complete, then we obviously want the 'Stop' button to be functional
during that time.

Does anyone know if there are any hooks in DBI for using it
asynchronously?

Failing that, my short-term plan is to simply fork a process to handle
the database interaction and communicate with it over a pipe/socket
using the non-blocking framework I already have.

It's probably worth pointing out that one of the reasons I haven't done
the DBI gear yet is that I'm getting by with the following workaround:

I start my machine with a TextInput gear into which I type my SQL query.

I connect that to a CommandFilter gear and configure it to talk to my
Postgres database via psql like this:

  psql -f - -H dbname

The '-f -' tells psql to read the query from STDIN and the '-H' requests
HTML formatted output.

I then use a FindReplace gear to turn   (which psql uses for NULLs)
into a normal space.

A ParseHTMLTable gear turns the HTML into list output and a Strip
Whitespace gear removes the leading/trailing whitespace.

This workaround also has an advantage over a real DBI gear.  I can use
it to talk to database servers that sit behind firewalls.  I can't
connect directly to the Postgres server socket from my workstation, but
I can ssh in, so I use a command filter like this:

  ssh hostname psql -f - -H dbname

Of course if I had a real DBI gear I could use it with SSH's port
forwarding to achieve a similar effect.

Presumably other databases have command-line utilities that could be
exploited similarly.  Either HTML or CSV output should be easy to deal
with in Sprog.

Regards
Grant

Re: [sprog-users] Make Test and Apache LogRegex module

[Gavin H. <gh...@fe...>]

---------- Original Message -----------
From: Grant McLean <gr...@mc...>
To: Sprog Users <spr...@li...>
Sent: Sun, 26 Jun 2005 07:25:45 +1200
Subject: Re: [sprog-users] Make Test and Apache LogRegex module

> On Sat, 2005-06-25 at 19:22 +0100, Gavin Henry wrote:
> > Just wondering why perl MakeFile.PL doesnt mention this Apache module, when it
> > is needed for make test?
> 
> That was an oversight on my part.  The fix (which is in CVS) is to
> delete t/01_require_all.t from the distribution - it should only ever
> have existed in the development environment.

Ah, fine. Testing it now.

> 
> I don't want to force people to install half of CPAN just to get 
> Sprog installed.  The tests for the individual gears do fail 
> gracefully if their prerequisite modules aren't installed.
> 
> The bigger target here is enhancing Sprog to better handle missing
> dependencies.

Have you any thoughts about getting it into Fedora Extras?

I am a CVS maintainer for Extras, so I could clean up, if needed, the Sprog.spec?

P.S. If you haven't guessed it already, I'm ghenry on perlmonks

> 
> Cheers
> Grant
> 


--
Kind Regards,

Gavin Henry,
Editorial Staff.
FedoraNEWS.ORG (http://FedoraNEWS.ORG)

Re: [sprog-users] Make Test and Apache LogRegex module

[Grant M. <gr...@mc...>]

On Sat, 2005-06-25 at 19:22 +0100, Gavin Henry wrote:
> Just wondering why perl MakeFile.PL doesnt mention this Apache module, when it
> is needed for make test?

That was an oversight on my part.  The fix (which is in CVS) is to
delete t/01_require_all.t from the distribution - it should only ever
have existed in the development environment.

I don't want to force people to install half of CPAN just to get Sprog
installed.  The tests for the individual gears do fail gracefully if
their prerequisite modules aren't installed.

The bigger target here is enhancing Sprog to better handle missing
dependencies.

Cheers
Grant

[sprog-users] Make Test and Apache LogRegex module

[Gavin H. <gh...@fe...>]

Hi all,

Just wondering why perl MakeFile.PL doesnt mention this Apache module, when it
is needed for make test?

Thanks.

--
Kind Regards,

Gavin Henry,
Editorial Staff.
FedoraNEWS.ORG (http://FedoraNEWS.ORG)

[sprog-users] Re: Sprog::Gear::ReadExcel.pm Code Review

[Marc S. <mar...@on...>]

Grant McLean wrote:

>I've also been working through your ReadExcel.pm code and coming up with
>some suggestions for making it both better and simpler.  I hope the
>suggestions don't come across as critical because they're not intended
>to be.  I really do appreciate the fact that you've slogged through my
>code enough to get something working.  Looking at your code has given me
>some ideas for how I can make things easier for gear-writers (including
>me).
>
>* I'd recommend moving the 'use strict' and related lines to after
>  the metadata block.  When Sprog is scanning @INC for gear classes
>  it 'parses' the start of each .pm file.  Any extraneous code
>  between the package name and the metadata section runs the risk of
>  confusing the simple parser.
>
>  
>
This was an oversight by me.  Normally I always use this, but since I 
was in "Play Mode" with the module I didn't go too far down the path of 
making it super-tight.  A rework of this code already going on in the 
background.

>* I'm guessing you based your code on the TextInput gear and some
>  bits of code are artifacts from that.  For example you declare a
>  property called 'text' which isn't really needed; an accessor
>  called gear_view that isn't used at all; and an accessor called
>  filename that really ought to be a property.  
>
>  
>
Yes, I did start that way.  Actually, the first thing I tried was to 
"use base qw(Sprog::Gear::ReadFile)" and override the _open_file 
subroutine.  I got that to work, but couldn't get the IO::Scalar fake 
filehandle to work.  After that I went with the TextInput gear since its 
straightforward.  There are probably several strange bits of code that 
don't belong there. I figure that as I get better with the framework 
I'll start writing code that is simpler.

>
>* The file_start and file_end events both send an argument of undef.
>  It really ought to be the filename.
>  
>
Next version will do this.

>* As Tony Bowden observed, your gear probably shouldn't be outputting
>  CSV data.  The 'List' output connector is probably a better choice.
>  People can always use the ListToCSV gear if that's what they want.
>  To use the list connector, just change the value for 'type_out' in
>  the metadata from 'P' to 'A', then instead of calling:
>  
>    $self->msg_out(data => $self->text);
>
>  to send all the CSV data, call:
>
>    $self->msg_out(row => \@cell_values);
>
>  once for each row in the spreadsheet - regardless of whether it's a
>  header or not.
>  
>
>* I'd also suggest that your gear shouldn't read from a file at all.
>  Instead, it should have a type 'P' input connector and simply
>  accumulate all 'data' events.  Then in the file_end event it can
>  call $XL->Parse(), passing it a reference to a scalar containing
>  all the accumulated data instead of a filename.  See ParseHTMLTable.pm
>  for example code.
>  
>
I thought of that as soon as I sent the link last night.  No problems, I 
will update the code to handle input this way.

>
>  Another advantage is that your gear would be simpler.  It wouldn't
>  need the Text::CSV_XS dependency, or the routine for accepting
>  drag-n-drop and it would even need a dialog box at all.  Unless you
>  decided to implement Tony's suggestion of allowing the user to select
>  which sheet to parse.  In which case, I'd suggest a dialog like the
>  ParseHTMLTable gear - one simple entry box where the user can type
>  either the sheet number or the name.
>
>  
>
I would love to implement this.  I'll probably be needing it soon 
anyway.  I have one question about the XML dialogs.  It my be 
documented, and if it is tell me to RTFM.  I would like to have the 
system pop up the dialog box with a pulldown list of the sheets on the 
excel file if they have not selected one.  I know how to make the 
dialog, but didn't know if there was an event I could call to pop up the 
dialog myself from the gear.  I'm not sure its even the best way to do it.

Perhaps even another way would be to put in a gear that splits the excel 
file into a list connector, one sheet for each record.  Any thoughts on 
the preferred methodology?

I don't take any of these things critically, I'm always looking to learn 
something new or improve something I'm working on.  After this excel 
module is put to rest I plan on moving into an XSLT gear, since I 
already have a need for that.  I'm also considering touching MySQL data 
input/output gears, since being able to shuffle spreadsheets on my 
desktop and either read or write records to my database would also make 
life a lot easier.

Thanks!
Marc

Re: [sprog-users] Gear Repository

[Marc S. <mar...@on...>]

>
>PS I'm curious as to why you didn't use
>Spreadsheet::ParseExcel::Simple for this - would simplify that code a
>lot ... :)
>
>
>  
>
I would have used that module, but I have run into trouble using it when 
there are calculated values in the columns.  Usually I get better 
results using this more nasty looking approach.

Marc

Re: [sprog-users] Abstracting the XML?

[Grant M. <gr...@mc...>]

On Sat, 2005-06-25 at 08:42 +0100, Tony Bowden wrote:
> Having a look at Sprog::Gear::ReadExcel posted recently, I'm wondering
> if there might be a way to separate out the mechanics of the
> translation modules from the glade XML? If there were a standard
> format for a Gear translation, then people could write modules to do
> the translations, even if they don't understand the widget format
> (like me!).

I'm not sure I fully understand what you're suggesting here.

The Glade XML section is only required for gears that have configurable
parameters.  So for example the 'CSV Split' gear doesn't need a
properties dialog and therefore doesn't have a dialog_xml method.
I'd recommend against having lots of configurable options.  It's
sometimes simpler just to have two separate gears with specific
hard-wired behaviours.

Also there's no need to understand the 'widget format'.  You just build
the dialog box in Glade, save it and paste the XML into the .pm file.

I initially planned to define dialogs using a simple YAML or XML format
but decided that re-inventing Glade was not going to help get the
project out the door :-)

I have considered supporting an alternative dialog definition for really
simple dialogs - eg: a single text entry with a label.  The problem is
that as simple as I tried to make it, people would always want to extend
it just that little bit further and in the end we'd re-invent GladeXML
and probably do it badly.  (I've learnt some lessons from XML::Simple).

> This isn't just a selfish thought though. If the XML could be
> abstracted further in some manner, it should theoretically be possible
> for someone to write a different front end - e.g. a web-based one.
> Drag and Drop is pretty well supported in browsers these days, so
> there's no theoretical reason I can think of why we couldn't have a
> web based front end. (Could also avoid all those nasty installation
> issues!)

Well I have tried to separate out the GUI code in the framework to allow
plugging in an alternative GUI layer.  I've even achieved that in a
perverse way with the --nogui option.

I'm certainly not discounting the idea.  If someone wants to come up
with an alternative way of defining the properties dialogs then I'm open
to ideas.  I have other priorities right now though.

Someone else suggested the web frontend notion to me recently.  It's an
interesting notion.

Cheers
Grant

[sprog-users] Abstracting the XML?

[Tony B. <ton...@gm...>]

Having a look at Sprog::Gear::ReadExcel posted recently, I'm wondering
if there might be a way to separate out the mechanics of the
translation modules from the glade XML? If there were a standard
format for a Gear translation, then people could write modules to do
the translations, even if they don't understand the widget format
(like me!).

This isn't just a selfish thought though. If the XML could be
abstracted further in some manner, it should theoretically be possible
for someone to write a different front end - e.g. a web-based one.
Drag and Drop is pretty well supported in browsers these days, so
there's no theoretical reason I can think of why we couldn't have a
web based front end. (Could also avoid all those nasty installation
issues!)

As I say, I don't know enough about the Gtk issues to know how one
might abstract this furthe, but, even if the web-interface idea is a
non-runner, anything that makes it easier for people to add their own
gears will only make this great project even better.

Tony

Re: [sprog-users] Gear Repository

[Tony B. <ton...@gm...>]

On 24/06/05, Marc Slagle <mar...@on...> wrote:
> I have written an Excel to CSV gear, but wanted to see if there was anoth=
er=20
> one floating around somewhere before trying to refine the one I'm working=
 on.

You might want to extend this to allow users to specify which
worksheet they wish to use. If I'm reading the code right it's
hardwired to use the first sheet? (Would also be useful to document
this).

I'm also wondering whether mapping this to CSV is the best approach.
It's obviously workable, as Sprog already has the ability to handle
CSV files, and users can therefore translate into whatever they want,
but I suspect that more often than not the next step will be to
translate back out of CSV. So perhaps it might be better to just have
it output a list of lists and have the ability to translate that into
whatever is required (including CSV). Thoughts?

Anyway nice work!

Tony

PS I'm curious as to why you didn't use
Spreadsheet::ParseExcel::Simple for this - would simplify that code a
lot ... :)

Re: [sprog-users] Gear Repository

[Marc S. <mar...@on...>]

>In the long term, I want to build repository support directly into Sprog
>so installing new gears is as easy as dragging a link from your browser
>and dropping it into your palette.  Or a Find Gear dialog that searches
>one or more repositories and lets you select gears for installation
>directly from the search results.
>  
>
There is probably a way to tie this in to the CPAN modules available, I 
can look into this if you haven't got the time to devote to it.

>In the immediate short term we need a way to share gear files manually.
>I can add a page to the Sprog web site to provide links to user
>contributed gears.  Do you have web space somewhere I could link to?  If
>not, I could put files directly on the project site but that would make
>it harder for you to upload new versions.
>  
>
http://osdn.whapps.com/files/Sprog-Gear-ReadExcel-0.03.tar.gz

I can probably place other versions there as I go until there is a 
decision on where to put the repository. 

>Right now, (as you know) Sprog only recognises gears in the
>Sprog::Gear::* namespace.  It might be an idea if I added support for
>the SprogEx::Gear::* namespace as well to distinguish contributed gears
>from ones in the core distribution.  If anyone has a better idea then
>speak up.
>  
>
This is fine with me, I'll be happy to post to whichever namespace makes 
the most sense to the community.  I would suggest that another directive 
for the author or homepage of the gear is added to the POD where the 
name is set. 

I can see tons of uses for this utility, and plan on releasing back to 
the community anything that seems like it will be of  use.  Let me know 
if I can be of more assistance.  Thanks for the app!

Marc Slagle
Online-Rewards

Re: [sprog-users] Gear Repository

[Grant M. <gr...@mc...>]

Hi Marc

On Fri, 2005-06-24 at 14:52 -0400, Marc Slagle wrote:
> Is there a place where I can post or download additional gears?  If not 
> I would assume that CPAN is the place to go.  I have written an Excel to 
> CSV gear, but wanted to see if there was another one floating around 
> somewhere before trying to refine the one I'm working on.

Welcome to the bleeding edge.  To my knowledge, you are the first person
in the world apart from myself to successfully build a Sprog gear :-)
Congratulations!

Obviously my master plan for Sprog includes lots of different gears
written and maintained by lots of different people.  I have vaguely
considered the need for a gear repository (GearPAN?) but haven't given
much thought yet to how that would work.

In the long term, I want to build repository support directly into Sprog
so installing new gears is as easy as dragging a link from your browser
and dropping it into your palette.  Or a Find Gear dialog that searches
one or more repositories and lets you select gears for installation
directly from the search results.

In the immediate short term we need a way to share gear files manually.
I can add a page to the Sprog web site to provide links to user
contributed gears.  Do you have web space somewhere I could link to?  If
not, I could put files directly on the project site but that would make
it harder for you to upload new versions.

Right now, (as you know) Sprog only recognises gears in the
Sprog::Gear::* namespace.  It might be an idea if I added support for
the SprogEx::Gear::* namespace as well to distinguish contributed gears
from ones in the core distribution.  If anyone has a better idea then
speak up.

Probably best to hold off on uploading to CPAN until the namespace thing
is sorted.

Regards
Grant

[sprog-users] Gear Repository

[Marc S. <mar...@on...>]

Is there a place where I can post or download additional gears?  If not 
I would assume that CPAN is the place to go.  I have written an Excel to 
CSV gear, but wanted to see if there was another one floating around 
somewhere before trying to refine the one I'm working on.

Thanks

Marc Slagle
Online-Rewards
2900 Jefferson Ave.
Cincinnati, OH 45219

[sprog-users] Announce: Sprog-0.11

[Grant M. <gr...@mc...>]

Hi All

This release of Sprog is a very minor update.  It's just to replace the
'proof of concept' CSV Split gear with a more capable version.  The new
one understands quoted fields, escaped quotes and embedded newlines.

You can now also use the escape key to hide the Text Window.

Regards
Grant

[sprog-users] Announce: Sprog 0.10

[Grant M. <gr...@mc...>]

Hi All

This release has some bug fixes, some new gears and one crazy new
feature: You can now use the --nogui option to run Sprog without a GUI.
So those snazzy machines you've been building to automate repetitive
tasks can now be scheduled via cron, or kicked off daily from your login
script. Also new in this release:

* Drag-and-drop: drag filenames or links from your file manager 
  or web browser into your machine.

* Help system: access a gear's help page directly from the palette 
  via right click menu or Shift-F1.

* New gears: NameFields, SelectFields, PerlCodePA, PerlCodePH,
  ReplaceFile, ImageBorder (experimental).

* UI tweaks: view preferences are now saved, help browser remembers
  scroll position when moving back/forward, highlighting of gear 
  that raised an alert.

* A few bug fixes, including a scheduler race condition which could
  cause machine hangs.

The Sourceforge site has links to the source download as well as Debian
and RPM packages:

  http://sprog.sourceforge.net/

Regards
Grant

Re: [sprog-users] Documentation

[Grant M. <gr...@mc...>]

On Fri, 2005-06-10 at 09:58 +0100, Gavin Brown wrote:
> > If you have feature requests, I'm all ears.  I've got plenty of ideas 
> > to work on, but if you have something in mind that you'd find useful
> > then I definitely want to hear about it.
> 
> Is there a "gear-writing guide"? I have some ideas but don't know where
> to start.

The file lib/Sprog/help/gear_internals.pod contains the information
required to understand gears.  Towards the end of the document it gets
into the specifics of what you need to do to write your own.  If your
gear would need a properties dialog, there's some information about that
in lib/Sprog/help/prop_auto_dialog.pod.

To read those POD files, in addition to the familiar 'perldoc' tool, you
can run Sprog, press F1 for help and then click on the links under the
"Help for Developers" heading.

There are bound to be typos and unclear bits, so let me know if there's
anything you don't understand.

Regards
Grant

Re: [sprog-users] Sorry

[Gavin B. <gav...@uk...>]

> If you have feature requests, I'm all ears.  I've got plenty of ideas 
> to work on, but if you have something in mind that you'd find useful
> then I definitely want to hear about it.

Is there a "gear-writing guide"? I have some ideas but don't know where
to start.

Cheers,

Gavin.

-- 
Gavin Brown
e: gav...@uk...
w: http://jodrell.net/

Re: [sprog-users] Sorry

[Grant M. <gr...@mc...>]

On Fri, 2005-06-10 at 06:06 +0100, Neateye wrote:
> Call out Gouranga be happy!!!
> Gouranga Gouranga Gouranga ....

Hmm.  Sorry sprog-users, I though the mailing list had been configured
for subscriber posting only - it is now.

The next release of Sprog should be happening early next week.  

If you have feature requests, I'm all ears.  I've got plenty of ideas 
to work on, but if you have something in mind that you'd find useful
then I definitely want to hear about it.

Cheers
Grant

[sprog-users] Gouranga hey

[Neateye <nit...@ao...>]

Call out Gouranga be happy!!!
Gouranga Gouranga Gouranga ....
That which brings the highest happiness!!

Re: [sprog-users] debian problems with 0.0.9

[Grant M. <gr...@ca...>]

On Mon, 2005-05-30 at 22:26 +0200, Bo=C5=A1tjan =C5=A0peti=C4=8D wrote:=20
> hi
>=20
> Selecting previously deselected package libpod-escapes-perl.
> (Reading database ... 118885 files and directories currently installed.)
> Unpacking libpod-escapes-perl (from .../libpod-escapes-perl_1.04-1_all.de=
b) ...
> Selecting previously deselected package libpod-simple-perl.
> Unpacking libpod-simple-perl (from .../libpod-simple-perl_3.02-2_all.deb)=
 ...
> Selecting previously deselected package libsprog-perl.
> Unpacking libsprog-perl (from .../libsprog-perl_0.09-1_all.deb) ...
> Setting up libpod-escapes-perl (1.04-1) ...
> Setting up libpod-simple-perl (3.02-2) ...
> Setting up libsprog-perl (0.09-1) ...
> misko:/home/guru# exit
> exit
> guru@misko:~$ sprog
> Can't call method "run" on an undefined value at /usr/local/share/perl/5.=
8.4/Sprog.pm line 39.
> guru@misko:~$
>=20
> any ideas?
>=20
> regards, bostjan

It looks like there's some version conflict between an old Sprog release
installed manually under /usr/local/share/perl/5.8.4 and the new release
installed by the package under /usr/share/perl5.

I suspect the new script is being picked up from /usr/bin/sprog but your
PERL5LIB settings cause it to find the old library modules
under /usr/local/share/perl/5.8.4.

This should do the trick:

  rm -r /usr/local/share/perl/5.8.4/Sprog*

Cheers
Grant

[sprog-users] debian problems with 0.0.9

[<igz...@au...>]

hi

Selecting previously deselected package libpod-escapes-perl.
(Reading database ... 118885 files and directories currently installed.)
Unpacking libpod-escapes-perl (from .../libpod-escapes-perl_1.04-1_all.deb) ...
Selecting previously deselected package libpod-simple-perl.
Unpacking libpod-simple-perl (from .../libpod-simple-perl_3.02-2_all.deb) ...
Selecting previously deselected package libsprog-perl.
Unpacking libsprog-perl (from .../libsprog-perl_0.09-1_all.deb) ...
Setting up libpod-escapes-perl (1.04-1) ...
Setting up libpod-simple-perl (3.02-2) ...
Setting up libsprog-perl (0.09-1) ...
misko:/home/guru# exit
exit
guru@misko:~$ sprog
Can't call method "run" on an undefined value at /usr/local/share/perl/5.8.4/Sprog.pm line 39.
guru@misko:~$




any ideas?

regards, bostjan

-- 
igzebedze - he who speaks loud and say nothing

[sprog-users] Announce: Sprog-0.09

[Grant M. <gr...@mc...>]

Hi All

Well it's been a while since the last release of Sprog, but once you try
it, I hope you'll agree it was worth the wait:

 * A help viewer is now bundled, help text has been added for all 
   gears and developer notes have been added too.

 * A bunch of new gears are included in the distribution: 
   WriteFile, CommandFilter, CSVSplit, ParseHTMLTable, SelectColumns,
   StripWhitespace, ListToCSV, ListToRecord, TemplateTT2, PerlCodeAP,
   RetrieveURL

 * The API for the PerlCode gears have been changed to use an 
   overridden 'print' - much simpler.

 * For developers: auto-discovery of gears has been implemented, so 
   if you implement your gear class according to the documented 
   rules, it should appear in the palette.

 * The scheduler logic has been reworked to be more robust, 
   functional and better documented.

The tarball is available for download from here:

http://prdownloads.sourceforge.net/sprog/Sprog-0.09.tar.gz?download

Debian users will get the updated package in their next update if
they've set up the repository as per these instructions:

http://sprog.sourceforge.net/install/index.html#debian

Let me know if you have any problems.

Regards
Grant

[sprog-users] Announce: Sprog-0.08

[Grant M. <gr...@mc...>]

Release 0.08 of Sprog has just been uploaded to SourceForge.

The main user-visible changes in this release are some major speed
improvements, a new 'Text Input' gear and the removal of the vapourware
gears.

There have been many infrastructural changes too. Sprog now sports a
regression test suite with over 400 tests. Numerous bugs were found and
fixed during the development of these tests. Much refactoring and code
cleanup has been completed too.

You can download this release from:

  http://prdownloads.sourceforge.net/sprog/Sprog-0.08.tar.gz?download

or Debian users can use the 'apt' repository detailed here:

  http://sprog.sourceforge.net/install/index.html#debian

Regards
Grant

[sprog-users] Current state of CVS

[Grant M. <gr...@mc...>]

Just a quick heads up to anyone who might be trying to use Sprog from
CVS right now - it's broken.

I've got quite a few commits in the pipeline, but time constraints in
real life mean it's not going to happen today.

I've sorted out a few architectural issues which will clean up the code
base and I'm starting to whip the regression test suite into shape.
There are also some much needed performance enhancements on the way, so
once I get the CVS sorted out a new release should follow within a
couple of days.

Thanks for your patience
Grant