Re: Possible module for 'safer' signal handling....

2004-01-12 Thread Martyn J. Pearce
On Sun, Jan 11, 2004 at 10:15:20PM -0500, Lincoln A. Baxter wrote: On dbi-users... I responded to Tim Bunce's most helpful suggestions as follows... He suggested Sys::SigAction as name. Since the module is all about wrapping up system (POSIX) sigaction() calls, I like it! Lincoln, A slow

Re: Possible module for 'safer' signal handling....

2004-01-12 Thread A. Pagaltzis
* Lincoln A. Baxter [EMAIL PROTECTED] [2004-01-12 10:02]: On Sun, 2004-01-11 at 15:50, Tim Bunce wrote: It might also be worth adding some mechanism to integrate with Sys::Signal http://search.cpan.org/src/DOUGM/Sys-Signal/Signal.pm I took a look that this. It is little bit of perlxs glue

Re: Possible module for 'safer' signal handling....

2004-01-12 Thread Tim Bunce
On Sun, Jan 11, 2004 at 10:15:20PM -0500, Lincoln A. Baxter wrote: On dbi-users... I responded to Tim Bunce's most helpful suggestions as follows... He suggested Sys::SigAction as name. Since the module is all about wrapping up system (POSIX) sigaction() calls, I like it! On Sun, 2004-01-11

Re: Possible module for 'safer' signal handling....

2004-01-12 Thread Elizabeth Mattijsen
At 10:09 + 1/12/04, Tim Bunce wrote: On Sun, Jan 11, 2004 at 10:15:20PM -0500, Lincoln A. Baxter wrote: eval { local $SIG{ALRM} = sub { ... }; } Either way your Sys::SigAction is sufficient. The only thing it's lacking that Sys::Signal has is the automatic restoration of the

New User

2004-01-12 Thread khemir nadim
Hi All, this seems to be the group I have been looking for (and missed for few years). The module I am working on lately is a Spreadsheet (Spreadsheet::Perl), There is also a Data::TreeDumper that can be of interrest wich is very good at filtering data, it looks good and is easier to follow

Re: New version of Roman available

2004-01-12 Thread Flavio S. Glock
khemir nadim wrote: Why not call you module Roman::Extended (or whatever name you fancy) and upload it to CPAN? You can then forget about Roman.pm altogether and go on with your module. In this case, a better option would be to change your focus and contribute to one of: Text::Roman -

RFC: CGI::UploadDB

2004-01-12 Thread Mark Stosberg
Hello, I'm interested in feedback on a module

Re: RFC: CGI::UploadDB

2004-01-12 Thread A. Pagaltzis
* Mark Stosberg [EMAIL PROTECTED] [2004-01-12 23:22]: OK Name? Sounds good to me. Useful idea? Most certainly. (This question being the sole reason for me to pipe up, really.) It would've been cool to have this back when I was trying to write a script for such duties. Clear documentation?

Re: Possible module for 'safer' signal handling....

2004-01-12 Thread Lincoln A. Baxter
On Mon, 2004-01-12 at 05:46, Elizabeth Mattijsen wrote: At 10:09 + 1/12/04, Tim Bunce wrote: On Sun, Jan 11, 2004 at 10:15:20PM -0500, Lincoln A. Baxter wrote: eval { local $SIG{ALRM} = sub { ... }; } Either way your Sys::SigAction is sufficient. The only thing it's

would you$please shut the door?

2004-01-12 Thread david nicol
Is this an appropriate post to module-authors or would it be better taken to fun-with-perl? It's a module announcement... Acme::please is for randomly inserting please into your output via a tied scalar. The string and printing percentage are both configurable (see the documentation.)

Re: Possible module for 'safer' signal handling....

2004-01-12 Thread Lincoln A. Baxter
On Mon, 2004-01-12 at 04:18, A. Pagaltzis wrote: IMO it would be much neater not to have to separately localize $SIG{ALRM} but to have restoration optionally done by your module on request. I believe the clearest way to handle the syntax would be a check for context in sig_set_handler() and

Re: New User

2004-01-12 Thread David Manura
Nadim, This module looks neat. The way speadsheets automatically update data on dependencies, like a continually running makefile, seem to be their main benefit, but they do have some limitations since the data in a problem must be flattened onto a two-dimensional grid. Being a programmer,