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

Re: [sprog-users] Test Errors and final touches on Sprog RPM for Fedora Core 5 Extras

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

On Wed, 16 Nov 2005 08:59:37 +1300, Grant McLean wrote
> On Tue, 2005-11-15 at 11:41 +0000, Gavin Henry wrote:
> > On Tue, 15 Nov 2005 21:26:55 +1300, Grant McLean wrote
> >  
> > > It looks like there's something really basic gone wrong here.  I wonder
> > > if there might be some conflict between a version of Sprog that's
> > > already installed and the version being tested.
> >
> > That could be the case. Can I issue a make uninstall first?
> 
> I don't think make uninstall generally does anything useful.  I usually
> just do something like:
> 
>   rm -rf /usr/share/perl5/Sprog*
> 
> 'perldoc -l Sprog' will tell you where it's installed.

No build errors now!!!

> 
> Regards
> Grant
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> sprog-users mailing list
> spr...@li...
> https://lists.sourceforge.net/lists/listinfo/sprog-users


--
Kind Regards,

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

Re: [sprog-users] Test Errors and final touches on Sprog RPM for Fedora Core 5 Extras

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

On Tue, 2005-11-15 at 11:41 +0000, Gavin Henry wrote:
> On Tue, 15 Nov 2005 21:26:55 +1300, Grant McLean wrote
>  
> > It looks like there's something really basic gone wrong here.  I wonder
> > if there might be some conflict between a version of Sprog that's
> > already installed and the version being tested.
>
> That could be the case. Can I issue a make uninstall first?

I don't think make uninstall generally does anything useful.  I usually
just do something like:

  rm -rf /usr/share/perl5/Sprog*

'perldoc -l Sprog' will tell you where it's installed.

Regards
Grant

Re: [sprog-users] Test Errors and final touches on Sprog RPM for Fedora Core 5 Extras

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

On Tue, 15 Nov 2005 21:26:55 +1300, Grant McLean wrote
> On Tue, 2005-11-15 at 08:50 +0000, Gavin Henry wrote:
> > On Tue, 15 Nov 2005 12:28:58 +1300, Grant McLean wrote
> > > Hi Gavin
> > > 
> > > On Mon, 2005-11-14 at 23:59 +0000, Gavin Henry wrote:
> > > > Dear Guys,
> > > > 
> > > > This is the current specfile:
> > > > 
> > > > http://www.perl.me.uk/downloads/modules/Sprog.spec
> > > > 
> > > > It now has a desktop icon:
> > > > 
> > > > http://www.perl.me.uk/downloads/modules/sprog-logo.png
> > > > 
> > > > Is this icon ok?
> > > 
> > > Hmmmm, it's not really ideal.  I've had 'icon' on the todo list for some
> > > time, but in the absence of an official icon, I just use the standard
> > > gnome-run.png that ships with GNOME.
> > 
> > I thought so. Send us one over then ;-)
> 
> Attached.
> 
> > > > Lastly, it's all ready to go, but now we get Test Errors:
> > > > 
> > > > t/18_command_filter....dubious
> > > >         Test returned status 0 (wstat 13, 0xd)
> > > > DIED. FAILED tests 15-19
> > > >         Failed 5/19 tests, 73.68% okay
> > > 
> > > Try running this command to see if it gives any more clues:
> > > 
> > >   prove -v t/18_command_filter.t
> > > 
> > > It looks like it's dying in test number 15.  That test is really 
> > > just a placeholder while I consider how to get better diagnostics 
> > > from attempting to run a command that doesn't exist.  I'm not sure 
> > > why it's failing for you, but it's entirely non-critical so you 
> > > could skip it with the attached patch.
> > 
> > Fair enough. Me neither. Just happened lately. It has worked fine before on
> > this machine. Here's the verbose output:
> > 
> > t/18_command_filter....1..19
> > ok 1 - use TestApp;
> > ok 2 - use Sprog::Gear::CommandFilter;
> > not ok 3 - no alerts while creating machine
> > 
> > #     Failed test (t/18_command_filter.t at line 14)
> > #          got: 'Unable to create a LineSink object
> > # Base class package "Sprog::Mixin::InputByLine" is empty.
> > #     (Perhaps you need to 'use' the module which defines that package first.)
> > #  at t/lib/LineSink.pm line 13
> > # BEGIN failed--compilation aborted at t/lib/LineSink.pm line 16.
> > # Compilation failed in require at /usr/lib/perl5/site_perl/5.8.6/Sprog.pm
> > line 295.
> > #
> > # '
> > #     expected: ''
> > not ok 4 - filter gear isa Sprog::Gear::CommandFilter
> > 
> > #     Failed test (t/18_command_filter.t at line 16)
> > #     filter gear isn't defined
> > not ok 5 - filter gear also isa Sprog::Mixin::OutputToFH
> > 
> > #     Failed test (t/18_command_filter.t at line 17)
> > #     filter gear also isn't defined
> > not ok 6 - filter gear also isa Sprog::Mixin::InputFromFH
> > 
> > #     Failed test (t/18_command_filter.t at line 18)
> > #     filter gear also isn't defined
> > not ok 7 - filter gear also isa Sprog::Gear
> > 
> > #     Failed test (t/18_command_filter.t at line 19)
> > #     filter gear also isn't defined
> > Can't call method "has_input" on an undefined value at t/18_command_filter.t
> > line 21.
> > # Looks like you planned 19 tests but only ran 7.
> > # Looks like your test died just after 7.
> > dubious
> >         Test returned status 255 (wstat 65280, 0xff00)
> > DIED. FAILED tests 3-19
> >         Failed 17/19 tests, 10.53% okay
> > Failed Test           Stat Wstat Total Fail  Failed  List of Failed
> >
-------------------------------------------------------------------------------
> > t/18_command_filter.t  255 65280    19   29 152.63%  3-19
> > Failed 1/1 test scripts, 0.00% okay. 17/19 subtests failed, 10.53% okay.
> 
> So now it's failing tests 3-19 whereas originally it was failing 15-19.
> This time it's failing catastrophically because the InputByLine mixin
> hasn't been loaded even though its explicitly mentioned by the 'use
> base' in t/lib/LineSink.pm.
> 
> It looks like there's something really basic gone wrong here.  I wonder
> if there might be some conflict between a version of Sprog that's
> already installed and the version being tested.
> 
> Regards
> Grant

That could be the case. Can I issue a make uninstall first?

--
Kind Regards,

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

Re: [sprog-users] Test Errors and final touches on Sprog RPM for Fedora Core 5 Extras

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

On Tue, 2005-11-15 at 08:50 +0000, Gavin Henry wrote:
> On Tue, 15 Nov 2005 12:28:58 +1300, Grant McLean wrote
> > Hi Gavin
> > 
> > On Mon, 2005-11-14 at 23:59 +0000, Gavin Henry wrote:
> > > Dear Guys,
> > > 
> > > This is the current specfile:
> > > 
> > > http://www.perl.me.uk/downloads/modules/Sprog.spec
> > > 
> > > It now has a desktop icon:
> > > 
> > > http://www.perl.me.uk/downloads/modules/sprog-logo.png
> > > 
> > > Is this icon ok?
> > 
> > Hmmmm, it's not really ideal.  I've had 'icon' on the todo list for some
> > time, but in the absence of an official icon, I just use the standard
> > gnome-run.png that ships with GNOME.
> 
> I thought so. Send us one over then ;-)

Attached.
 
> > > Lastly, it's all ready to go, but now we get Test Errors:
> > > 
> > > t/18_command_filter....dubious
> > >         Test returned status 0 (wstat 13, 0xd)
> > > DIED. FAILED tests 15-19
> > >         Failed 5/19 tests, 73.68% okay
> > 
> > Try running this command to see if it gives any more clues:
> > 
> >   prove -v t/18_command_filter.t
> > 
> > It looks like it's dying in test number 15.  That test is really 
> > just a placeholder while I consider how to get better diagnostics 
> > from attempting to run a command that doesn't exist.  I'm not sure 
> > why it's failing for you, but it's entirely non-critical so you 
> > could skip it with the attached patch.
> 
> Fair enough. Me neither. Just happened lately. It has worked fine before on
> this machine. Here's the verbose output:
> 
> t/18_command_filter....1..19
> ok 1 - use TestApp;
> ok 2 - use Sprog::Gear::CommandFilter;
> not ok 3 - no alerts while creating machine
> 
> #     Failed test (t/18_command_filter.t at line 14)
> #          got: 'Unable to create a LineSink object
> # Base class package "Sprog::Mixin::InputByLine" is empty.
> #     (Perhaps you need to 'use' the module which defines that package first.)
> #  at t/lib/LineSink.pm line 13
> # BEGIN failed--compilation aborted at t/lib/LineSink.pm line 16.
> # Compilation failed in require at /usr/lib/perl5/site_perl/5.8.6/Sprog.pm
> line 295.
> #
> # '
> #     expected: ''
> not ok 4 - filter gear isa Sprog::Gear::CommandFilter
> 
> #     Failed test (t/18_command_filter.t at line 16)
> #     filter gear isn't defined
> not ok 5 - filter gear also isa Sprog::Mixin::OutputToFH
> 
> #     Failed test (t/18_command_filter.t at line 17)
> #     filter gear also isn't defined
> not ok 6 - filter gear also isa Sprog::Mixin::InputFromFH
> 
> #     Failed test (t/18_command_filter.t at line 18)
> #     filter gear also isn't defined
> not ok 7 - filter gear also isa Sprog::Gear
> 
> #     Failed test (t/18_command_filter.t at line 19)
> #     filter gear also isn't defined
> Can't call method "has_input" on an undefined value at t/18_command_filter.t
> line 21.
> # Looks like you planned 19 tests but only ran 7.
> # Looks like your test died just after 7.
> dubious
>         Test returned status 255 (wstat 65280, 0xff00)
> DIED. FAILED tests 3-19
>         Failed 17/19 tests, 10.53% okay
> Failed Test           Stat Wstat Total Fail  Failed  List of Failed
> -------------------------------------------------------------------------------
> t/18_command_filter.t  255 65280    19   29 152.63%  3-19
> Failed 1/1 test scripts, 0.00% okay. 17/19 subtests failed, 10.53% okay.

So now it's failing tests 3-19 whereas originally it was failing 15-19.
This time it's failing catastrophically because the InputByLine mixin
hasn't been loaded even though its explicitly mentioned by the 'use
base' in t/lib/LineSink.pm.

It looks like there's something really basic gone wrong here.  I wonder
if there might be some conflict between a version of Sprog that's
already installed and the version being tested.

Regards
Grant

Re: [sprog-users] Test Errors and final touches on Sprog RPM for Fedora Core 5 Extras

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

On Tue, 15 Nov 2005 12:28:58 +1300, Grant McLean wrote
> Hi Gavin
> 
> On Mon, 2005-11-14 at 23:59 +0000, Gavin Henry wrote:
> > Dear Guys,
> > 
> > This is the current specfile:
> > 
> > http://www.perl.me.uk/downloads/modules/Sprog.spec
> > 
> > It now has a desktop icon:
> > 
> > http://www.perl.me.uk/downloads/modules/sprog-logo.png
> > 
> > Is this icon ok?
> 
> Hmmmm, it's not really ideal.  I've had 'icon' on the todo list for some
> time, but in the absence of an official icon, I just use the standard
> gnome-run.png that ships with GNOME.

I thought so. Send us one over then ;-)

> 
> > Lastly, it's all ready to go, but now we get Test Errors:
> > 
> > t/18_command_filter....dubious
> >         Test returned status 0 (wstat 13, 0xd)
> > DIED. FAILED tests 15-19
> >         Failed 5/19 tests, 73.68% okay
> 
> Try running this command to see if it gives any more clues:
> 
>   prove -v t/18_command_filter.t
> 
> It looks like it's dying in test number 15.  That test is really 
> just a placeholder while I consider how to get better diagnostics 
> from attempting to run a command that doesn't exist.  I'm not sure 
> why it's failing for you, but it's entirely non-critical so you 
> could skip it with the attached patch.

Fair enough. Me neither. Just happened lately. It has worked fine before on
this machine. Here's the verbose output:

t/18_command_filter....1..19
ok 1 - use TestApp;
ok 2 - use Sprog::Gear::CommandFilter;
not ok 3 - no alerts while creating machine

#     Failed test (t/18_command_filter.t at line 14)
#          got: 'Unable to create a LineSink object
# Base class package "Sprog::Mixin::InputByLine" is empty.
#     (Perhaps you need to 'use' the module which defines that package first.)
#  at t/lib/LineSink.pm line 13
# BEGIN failed--compilation aborted at t/lib/LineSink.pm line 16.
# Compilation failed in require at /usr/lib/perl5/site_perl/5.8.6/Sprog.pm
line 295.
#
# '
#     expected: ''
not ok 4 - filter gear isa Sprog::Gear::CommandFilter

#     Failed test (t/18_command_filter.t at line 16)
#     filter gear isn't defined
not ok 5 - filter gear also isa Sprog::Mixin::OutputToFH

#     Failed test (t/18_command_filter.t at line 17)
#     filter gear also isn't defined
not ok 6 - filter gear also isa Sprog::Mixin::InputFromFH

#     Failed test (t/18_command_filter.t at line 18)
#     filter gear also isn't defined
not ok 7 - filter gear also isa Sprog::Gear

#     Failed test (t/18_command_filter.t at line 19)
#     filter gear also isn't defined
Can't call method "has_input" on an undefined value at t/18_command_filter.t
line 21.
# Looks like you planned 19 tests but only ran 7.
# Looks like your test died just after 7.
dubious
        Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 3-19
        Failed 17/19 tests, 10.53% okay
Failed Test           Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
t/18_command_filter.t  255 65280    19   29 152.63%  3-19
Failed 1/1 test scripts, 0.00% okay. 17/19 subtests failed, 10.53% okay.


> 
> Thanks for 'keeping the faith' Gavin.  Real life has been getting in 
> the way of Sprog development for a while now, but I haven't 
> abandoned it :-)

I'll apply this patch later today and get this thing released :-)

> 
> Cheers
> Grant


--
Kind Regards,

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

Re: [sprog-users] Test Errors and final touches on Sprog RPM for Fedora Core 5 Extras

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

Hi Gavin

On Mon, 2005-11-14 at 23:59 +0000, Gavin Henry wrote:
> Dear Guys,
> 
> This is the current specfile:
> 
> http://www.perl.me.uk/downloads/modules/Sprog.spec
> 
> It now has a desktop icon:
> 
> http://www.perl.me.uk/downloads/modules/sprog-logo.png
> 
> Is this icon ok?

Hmmmm, it's not really ideal.  I've had 'icon' on the todo list for some
time, but in the absence of an official icon, I just use the standard
gnome-run.png that ships with GNOME.

> Lastly, it's all ready to go, but now we get Test Errors:
> 
> t/18_command_filter....dubious
>         Test returned status 0 (wstat 13, 0xd)
> DIED. FAILED tests 15-19
>         Failed 5/19 tests, 73.68% okay

Try running this command to see if it gives any more clues:

  prove -v t/18_command_filter.t

It looks like it's dying in test number 15.  That test is really just a
placeholder while I consider how to get better diagnostics from
attempting to run a command that doesn't exist.  I'm not sure why it's
failing for you, but it's entirely non-critical so you could skip it
with the attached patch.


Thanks for 'keeping the faith' Gavin.  Real life has been getting in the
way of Sprog development for a while now, but I haven't abandoned it :-)

Cheers
Grant

[sprog-users] Test Errors and final touches on Sprog RPM for Fedora Core 5 Extras

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

Dear Guys,

This is the current specfile:

http://www.perl.me.uk/downloads/modules/Sprog.spec

It now has a desktop icon:

http://www.perl.me.uk/downloads/modules/sprog-logo.png

Is this icon ok?

Lastly, it's all ready to go, but now we get Test Errors:

t/18_command_filter....dubious
        Test returned status 0 (wstat 13, 0xd)
DIED. FAILED tests 15-19
        Failed 5/19 tests, 73.68% okay

Any ideas?

Gavin.

--
Kind Regards,

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

[sprog-users] Announce: Sprog-0.14

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

Hi Sproggers

I've just uploaded version 0.14 of Sprog to Sourceforge (although I'm
having difficulty updating the project web site).

This release has a few minor enhancements and a few minor bug fixes:

You can now rename gears and change the gear title font. The right click
menu no longer disappears unexpectedly. Enter now works in file
selection dialogs and Cancel now works in the preferences dialog. 

Other internal bugs fixes are listed in the change log below.

Warning for developers: the package names for the gear mixin classes
have changed.

If any of you are going to be at OSCON next week come and say hello:

  http://conferences.oreillynet.com/cs/os2005/view/e_spkr/2166

My talk is on the 'Emerging Topics' track rather than the Perl track.
Hope to see you there!

Change Log For 0.14:
====================
- fix bug: machine not stopping after syntax error in Perl gear
- fix bug: broken cancel button in tools/prefs dialog
- fix bug: extra file_end events from command_filter
- fix 'Enter' for default in file dialogs
- add ability to rename gears
- make gear title and text window fonts configurable
- make right click menu stay visible on click-release
- implement filename = '-' for STDIN in ReadFile.pm
- rename mixin classes from Sprog::Gear::* to Sprog::Mixin::*

Cheers
Grant

Re: [sprog-users] strange default behaviour in "preferences" dialog

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

On Thu, 2005-07-14 at 13:52 +0200, Zeno Gantner wrote:
> Hello,
> 
> when opening the preferences dialog for the first
> time, the "personal gear folder" field is empty.
> 
> If I click ok now, the program tells me that my
> gear folder does not exist yet, and asks me whether
> I want to create it.

Yes, that feature is obviously suffering from a complete 
lack of testing.  The code doesn't cope with leaving the
folder entry blank and the cancel button doesn't work at
all.  Both problems are fixed in CVS.

Unfortunately I've been rather busy with my day job and 
with getting my Sprog presentation ready for OSCON, so it
will be a while before the next release.

Cheers
Grant

Re: [sprog-users] Problems making a machine (snapping mechanism)

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

Hi Zeno

You seem to be posting from a different email address than you used to
subscribe to the list - this leads to a delay until I manually approve
the posts.

On Thu, 2005-07-14 at 13:34 +0200, Zeno Gantner wrote:
> Hello,
> 
> first of all, I have to say that I really like your program's concept.
> It is the most interesting piece of software that I saw this year.

Thanks.

> Today I played a little bit with it, but I had some problems.
> 
> I had a hard time to find out how the snapping mechanism
> works. For me, it works only if I approach the gear I want
> to connect to from the right hand side.

Unfortunately, this has become an FAQ, so I've just added it to 
the web site:

  http://sprog.sourceforge.net/faq/index.html#connect_gears

Obviously, the real answer is to fix the code.  I look forward 
to the day when I can remove that entry from the FAQ.

Regards
Grant

[sprog-users] strange default behaviour in "preferences" dialog

[Zeno G. <zen...@we...>]

Hello,

when opening the preferences dialog for the first
time, the "personal gear folder" field is empty.

If I click ok now, the program tells me that my
gear folder does not exist yet, and asks me whether
I want to create it.

Sure I want, but that does not work, because
(my guess) it tries to call mkdir with an empty
string as argument.

So I get an error message (which is ok).
But the problem is that I cannot leave the
preferences dialog until I successfully created
the gear folder, because (at least for me) the
"cancel" button does not work.

I had to find out that I have to select a folder
name to make it work.

It would be better to put a default folder name
(like ~/gears) into that field.

Hm, I hope I explained that well enough.
If not, just tell me, and I'll try again ;-)

Best regards,
  Zeno

[sprog-users] Problems making a machine (snapping mechanism)

[Zeno G. <zen...@we...>]

Hello,

first of all, I have to say that I really like your program's concept.
It is the most interesting piece of software that I saw this year.

Today I played a little bit with it, but I had some problems.

I had a hard time to find out how the snapping mechanism
works. For me, it works only if I approach the gear I want
to connect to from the right hand side.
It does not snap if I try it from the left side, and it does
not snap if I try to put the two connectors together as
close as possible.

I needed like 10 minutes to figure out how this works,
I first thought it did not work at all.

I found some other minor issues that I will report the
next days.

Keep up the good work!

Best regards,
         Zeno

Re: [sprog-users] Standard Error Question

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

On Fri, 2005-07-08 at 09:56 -0700, Paul Hamingson wrote:
> Turns out that was correct for what
> we had on the test site at the time, but it raised the
> question of where should standard error go?

Yes, there are a couple of known problems here.  The first is 
that the Retrieve URL gear is not exactly robust.  Improved
functionality and error handling are on the todo list.  I'd 
envisage that in the case you encountered, a pop-up alert
would be displayed and the machine would stop.

The second problem is as you've seen STDERR isn't visible to 
the user.  I plan to allow the framework to capture STDERR and 
display it in a separate window - similar to the Javascript
console in Firefox.  The user will be able to choose to have 
that window pop up when necessary or stay hidden unless 
specifically turned on.

> Sometimes a Sprog user might want that as part of the
> stream they are processing, and sometimes not. 

In the case of a machine that uses an external command, you 
can always append 2>&1 to the command if you do want the error 
messages mixed in with the data.

> Any plans to add a Tee, in addition to the gears? 

Yes eventually, but there are a number of higher priorities on
the list.

Thanks for you feedback.

Cheers
Grant

[sprog-users] Standard Error Question

[Paul H. <pha...@ya...>]

Grant,
First - thanks for all the great work on Sprog. I've
started to see a number of uses for this tool. I was
playing around last night on our test site at work,
using ReadURL and TextWindow, when I ran into a page
that appeared not to produce anything as output.

I run Fedora Core 3, and had added a launcher on my
panel (counts as a Sprog endorsement, BTW) and that
was how I started it up. So, I then popped open a
shell and ran it from the command line. When I set up
the same gears, and ran it, there was a 403 message in
the shell window. Turns out that was correct for what
we had on the test site at the time, but it raised the
question of where should standard error go?

Sometimes a Sprog user might want that as part of the
stream they are processing, and sometimes not. Any
plans to add a Tee, in addition to the gears? I am
sure that is no small feat, but I curious if this is
something considered in your design roadmap?

Thanks,
Paul Hamingson

Re: [sprog-users] Parse HTML Table Error - Debian

[Ryan M. <mcc...@gm...>]

On 7/7/05, Grant McLean <gr...@mc...> wrote:
> On Thu, 2005-07-07 at 13:24 -0600, Ryan McCahan wrote:
> > ...
> > > One thing I am finding is that they cogs are not snapping together
> > > easily for me.
> >
> > The trick is to make sure that the top-right hand corner of the cog
> > you want to drop onto your machine is inside the boundaries of the cog
> > before it.
>=20
> Top left actually :-)

Whoops...  not so good with directions after I wake up.

Ryan McCahan

>=20
> Cheers
> Grant
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> sprog-users mailing list
> spr...@li...
> https://lists.sourceforge.net/lists/listinfo/sprog-users
>

Re: [sprog-users] Parse HTML Table Error - Debian

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

On Thu, 2005-07-07 at 13:24 -0600, Ryan McCahan wrote:
> ...
> > One thing I am finding is that they cogs are not snapping together
> > easily for me.  
> 
> The trick is to make sure that the top-right hand corner of the cog
> you want to drop onto your machine is inside the boundaries of the cog
> before it.

Top left actually :-)

Cheers
Grant

Re: [sprog-users] Parse HTML Table Error - Debian

[Ryan M. <mcc...@gm...>]

...
> One thing I am finding is that they cogs are not snapping together
> easily for me.  Sometimes I just can't get them to pop together, and as
> earlier mentioned on the list, if I take a machine apart it does not go
> back together very easily (well, at all actually).  I'll keep fiddling
> with it and report anything repeatable.
>=20

The trick is to make sure that the top-right hand corner of the cog
you want to drop onto your machine is inside the boundaries of the cog
before it.

> I definitely think that sprog is extremely neat, and hopefully I'll be
> able to meaningfully contribute.
> --
>=20
> yours,
>=20
> William
>=20


Ryan McCahan

Re: [sprog-users] Parse HTML Table Error - Debian

[William O'H. <wil...@ut...>]

On Thu, Jul 07, 2005 at 07:20:27AM +1200, Grant McLean wrote:
>
>On Wed, 2005-07-06 at 11:43 -0400, William O'Higgins wrote:=20
>> I've been meaning to poke around on sprog since I read the article on
>> O'Reilly, and the first thing I tried threw an error.
>
>To put it slightly differently, you had no problem installing Sprog or
>getting it to run and display the main application Window.  But when you
>tried to add a specific gear to the workspace you got an error message.=20

Just like you said :-)

>I (perhaps optimistically) envisage that there will eventually be Sprog
>components for half the modules on CPAN.  But, having to install half of
>CPAN just to get Sprog running would present quite a barrier to entry.

Good point, but perhaps the cogs supplied by default should be
supported.

>So instead, my plan is to allow gear classes to declare dependencies.
>Then in the circumstance you described, Sprog would recognise which CPAN
>module was missing and would determine the corresponding package for
>your OS distribution through some mapping process.  Instead of the
>current Perl compilation error, Sprog would pop up an alert dialog
>advising you that you needed to install the libxml-libxml-perl package.

I'll take a look at the error codes and see if I can contribute a
user-friendly "You appear to be missing $module_x" routine.  Once
there's a way to tell the user which module they need, than we can see
about system-specific mappings to resolve those dependencies.

One thing I am finding is that they cogs are not snapping together
easily for me.  Sometimes I just can't get them to pop together, and as
earlier mentioned on the list, if I take a machine apart it does not go
back together very easily (well, at all actually).  I'll keep fiddling=20
with it and report anything repeatable.

I definitely think that sprog is extremely neat, and hopefully I'll be
able to meaningfully contribute.
--=20

yours,

William

Re: [sprog-users] Parse HTML Table Error - Debian

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

Hi William

Welcome to the list.

On Wed, 2005-07-06 at 11:43 -0400, William O'Higgins wrote: 
> I've been meaning to poke around on sprog since I read the article on
> O'Reilly, and the first thing I tried threw an error.

To put it slightly differently, you had no problem installing Sprog or
getting it to run and display the main application Window.  But when you
tried to add a specific gear to the workspace you got an error message. 

> I wanted to parse an HTML table, and I got an error that, at the root of
> the problem, was based on not having XML::LibXML installed.

Good diagnosis.  

> I am on Debian, and I did some poking, and installed these additional
> components: xml2 libxml-libxml-perl libxml2-dev

Actually, the libxml-libxml-perl was the only one that Sprog needed.

> Now that cog no longer throws the error.  I think though, that the
> dependencies for the libsprog-perl should include libxml-libxml-perl,
> and maybe xml2.  What does anyone else think?

I (perhaps optimistically) envisage that there will eventually be Sprog
components for half the modules on CPAN.  But, having to install half of
CPAN just to get Sprog running would present quite a barrier to entry.

So instead, my plan is to allow gear classes to declare dependencies.
Then in the circumstance you described, Sprog would recognise which CPAN
module was missing and would determine the corresponding package for
your OS distribution through some mapping process.  Instead of the
current Perl compilation error, Sprog would pop up an alert dialog
advising you that you needed to install the libxml-libxml-perl package.

> I'm no Debian guru but I have learnt a bit about how to get myself out
> of (and into, can't forget to mention into) trouble, and this was my first
> experiment with sprog.

And you passed the test with flying colours :-)

Future versions of Sprog will be more supportive of adventurers such as
yourself.  We're still in the early stages of development.

Thanks for your feedback.

Grant

[sprog-users] Parse HTML Table Error - Debian

[William O'H. <wil...@ut...>]

I've been meaning to poke around on sprog since I read the article on
O'Reilly, and the first thing I tried threw an error.

I wanted to parse an HTML table, and I got an error that, at the root of
the problem, was based on not having XML::LibXML installed.

I am on Debian, and I did some poking, and installed these additional
components: xml2 libxml-libxml-perl libxml2-dev

Now that cog no longer throws the error.  I think though, that the
dependencies for the libsprog-perl should include libxml-libxml-perl,
and maybe xml2.  What does anyone else think?

I'm no Debian guru but I have learnt a bit about how to get myself out
of (and into, can't forget to mention into) trouble, and this was my first
experiment with sprog.
--=20

yours,

William

Re: [sprog-users] win32 sprog

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

Hi Matija

Sorry, I didn't respond to your message immediately and then forgot it
entirely.

On Mon, 2005-07-04 at 12:19 -0700, Matija Papec wrote:
> Hi,
> I've read Sprog intro on perl.com and wander if someone can compile exe
> version for win32. With PAR, that would be something like
> pp sprog.pl

The immediate obstacle to running Sprog on Win32 is that there is no
binary PPM for the Gnome2::Canvas module which in turn needs the
libgnomecanvas library.  I don't run Windows so I'm not really in a
position to do anything about that.  If you were to download Microsoft's
free compiler then the folks on gtk...@gn... could no doubt
offer advice.

I seem to recall reading that PAR doesn't support Gtk2.  It could work
if the user had the Gtk libraries installed, but they can't be bundled
with PAR.

Regards
Grant

[sprog-users] win32 sprog

[Matija P. <mp...@ya...>]

Hi,
I've read Sprog intro on perl.com and wander if someone can compile exe
version for win32. With PAR, that would be something like
pp sprog.pl


tnx!



Matija


		
__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html

Re: [sprog-users] Announce: Sprog-0.13

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

---------- Original Message -----------
From: Grant McLean <gr...@mc...>
To: Sprog Users <spr...@li...>
Sent: Mon, 04 Jul 2005 00:03:53 +1200
Subject: [sprog-users] Announce: Sprog-0.13

> Hi Sproggers
> 
> I've just uploaded version 0.13 of Sprog to Sourceforge.

Give us a chance to package the darn thing ;-)
 
> The major new feature is this release is the 'Make Command Gear' 
> menu option.  If you've been using the 'Run Command' gears to 
> wrap up cryptic command lines, you can now add your creations to 
> the palette with the click of a button and then reuse them in 
> other machines.  One advantage of creating custom command gears
> is that you can change the gear title.
> 
> The only new gear in this release is a variant of 'Run Command' 
> which can be used as the final (output) gear in a machine.
> 
> The distribution now includes guidelines for packaging Sprog.
> 
> UI Tweaks
> - Tools|Preferences can now create the personal gear folder if
>   it doesn't exist
> - over-long gear titles are now truncated
> 
> Bug Fixes:
> - exporter fix for 5.8.1 (reported by Christian Renz)
> - fix for help viewer not finding POD in personal gear folder
> - fix missing palette icons
> 
> API Updates:
> - new mixin: InputByPara (originally contributed by Chris Benson)
> - allow derived gears to 'uninherit' properties
> 
> Regards
> Grant
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration 
> Strategies from IBM. Find simple to follow Roadmaps, straightforward 
> articles, informative Webcasts and more! Get everything you need to 
> get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> sprog-users mailing list
> spr...@li...
> https://lists.sourceforge.net/lists/listinfo/sprog-users
------- End of Original Message -------

Re: [sprog-users] Re: DBI Gear

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

On Sat, 2005-07-02 at 13:22 +1000, Matthew Keene wrote:
> --- Grant McLean <gr...@mc...> wrote:
> > And likewise, I'd appreciate comments from people
> > who are building gears and have questions about how
> > things are meant to work (or why) or comments about
> > how things could be better.
> 
> The obvious thing is more complete documentation.  

Ahh the perennial bugbear.  As it happens though I quite
enjoy writing documentation so stay tuned.

> A 'How To' guide for gear developers would be excellent

Yes, I'll put something up on the web site.  A few pictures
could make some of the concepts clearer.

> - the gear internals guide that you've got is a good
> start, but I found it a little lacking in detail (and
> I've just read the scheduler internals document and
> found some more stuff in there which now starts to
> make a bit more sense).

I'll probably end up turning those documents into 
reference pages and have the more descriptive stuff with
background details on the web site.

> I was planning on making a
> start on a step by step guide when I finished writing
> the DBI gear, sort of like a 'Gear Development for
> Dummies'.  (We're not all rocket scientists, you know
> ;-)).  Obviously I could only put in the little I know
> so far and you have to fill in the rest....

I don't mind writing it and if you ask questions about 
things that aren't clear, then I'll have a better idea what
to write about.

> My other main complaint is not related to developing
> gears, but a tool usability issue.  When you right
> click on a gear on the palette the current behaviour
> is that the selected item is executed when you release
> the right mouse button.  

I'd never noticed that, since I am in the habit of holding 
down the mouse button and releasing it once I've highlighted
the required option.  I certainly haven't done anything to
make it disappear as soon as you release the button, so it
looks like I'll have to do something to allow it to stay.

On my systems though the delete option isn't selected unless
I move the mouse after the initial click.  If I just right
click and release, nothing gets selected.  Admittedly though
the mouse only needs to move one or two pixels to make a 
selection.


> One thing that I'm still a little confused by when
> writing the non-blocking version of this gear is how
> to give control back to the framework so that other
> events can be processed.  

'return' :-)

Seriously though, it's a cooperative multitasking 
environment so a long as your method doesn't return, no 
other method (or GUI update) will get a chance.

> The difficulty here is that
> I'm going to basically have a single event (executing
> the query) which will potentially consume a large
> amount of time before any data becomes available.  

Yes, this is the bit that needs to be in the other process.

> I'm
> planning to call can_read (or some equivalent) on the
> IPC file handle to determine whether there the worker
> has produced any data to be processed, 

Glib/Gtk support a callback interface which allows you to
register a handler routine which should be called when a
filehandle becomes readable/writable or when a timeout 
expires.

The ReadFile and CommandIn gears both only read from a 
filehandle from within IO event handlers.  They both use
the InputFromFH mixin class to manage that.

> should I just
> return from send_data without sending any messages and
> let the scheduler handle the looping, 

Yes, that's exactly what you should do.

> How often will the scheduler call the input gear's
> send_data method if it hasn't yet started producing
> any data ?

The scheduler only calls send_data when it has no messages
queued for delivery.  Immediately after calling send_data,
the scheduler goes to sleep, so it won't call send_data 
again unless something wakes it up.  The most likely thing
to wake it up is if your gear sends a message - which it 
would most likely do from inside an IO event handler.

It is possible that some other gear in the machine has an
IO or timeout event setup too.  If it fired and sent some
messages, the scheduler would wake, deliver the messages 
and then call send_data again on all gears that had a 
send_data method, before going back to sleep.  So it is 
possible that your gear could be asked to send data more 
than once.  It ought not to be hammered with requests 
though.

>   I'm a little conscious of consuming CPU
> needlessly cycling around waiting for data if it's
> going to take some time to arrive, and I had been
> planning on putting a second or two's sleep time in
> the loop just to make sure that it doesn't put a hard
> head lock on the CPU.

It shouldn't be necessary to use sleeps.  Indeed if your 
code is sleeping, no other code is running.  If your code runs
in response to a filehandle becoming readable then other code
can run until that happens.

Regards
Grant

[sprog-users] Announce: Sprog-0.13

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

Hi Sproggers

I've just uploaded version 0.13 of Sprog to Sourceforge.

The major new feature is this release is the 'Make Command Gear' 
menu option.  If you've been using the 'Run Command' gears to 
wrap up cryptic command lines, you can now add your creations to 
the palette with the click of a button and then reuse them in 
other machines.  One advantage of creating custom command gears
is that you can change the gear title.

The only new gear in this release is a variant of 'Run Command' 
which can be used as the final (output) gear in a machine.

The distribution now includes guidelines for packaging Sprog.

UI Tweaks
- Tools|Preferences can now create the personal gear folder if
  it doesn't exist
- over-long gear titles are now truncated

Bug Fixes:
- exporter fix for 5.8.1 (reported by Christian Renz)
- fix for help viewer not finding POD in personal gear folder
- fix missing palette icons

API Updates:
- new mixin: InputByPara (originally contributed by Chris Benson)
- allow derived gears to 'uninherit' properties

Regards
Grant