Re: New User
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, I feel that the structure, size, and type of the data gets lost. For example, if cell C5 contains the average of cells B5:B10, and then you append a new value to cell B11, you have to correct the formula in C5 to cover the new range B5:B11. Software like Mathcad offers the best of both worlds by preserving the concept of data structures while also having the spreadsheet-like data-update dependencies. That makes me wonder whether something similar could be done in Perl, and if so how useful it would be. -davidm khemir nadim wrote: 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 relationship. I have an unreleased build system written in perl (+/- 350 Kb) that is quite fun to use. I'll try to be a bit active. Nice to be here Nadim. (NKH)
Re: Possible module for 'safer' signal handling....
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 returning an
> object that auto-restores the signal in question on destruction
> only if the context is not void.
>
> That way people could write
>
> my $restore = sig_set_handler( ... );
>
> when they want it undone and simply
>
> sig_set_handler( ... );
>
> when they do want the change to persist until explicit change.
>
>
I have come to the same conclusion. It has an additional benefit that
you can explicitly reset things by just undeffing the reference to the
returned object if thats what one wanted to do.
If sig_set_action could handle such an object, I would kill two birds
with one stone. I think I'll head in that direction.
Today I got the code working with perl 5.005 through 5.008. and I am
building 5.8.2 now so I can test with that. Interestingly, with
versions of perl earlier than 5.8, could not get the POSIX::sigaction
routine to behave, so I implemented it "under the covers", but just
setting $SIG{name}. Which got me identical behavior across all three
versions.
This discussion has been most helpful.
"would you$please shut the door?"
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.) #!/usr/local/bin/perl -l use Acme::please; print "would you$please shut the door?"; print "would you$please shut the door?"; print "would you$please shut the door?"; print "would you$please shut the door?"; print "would you$please shut the door?"; __END__ Enjoy.
Re: Possible module for 'safer' signal handling....
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
> >lacking that Sys::Signal has is the automatic restoration of the old
> >value when the object is destroyed. It would be trivial to add a
> >variant of sig_set_action() to do that for those that want it.
> >Something along the lines of:
> >
> > sub sig_set_action_auto_restore {
> > my $class = shift;
> > return bless sig_set_action(@_), $class;
> > }
> > sub DESTROY {
> > shify->sig_set_action();
> > }
>
> I'm not sure whether this is relevant here, but I seem to recall a
> bug reported sometime in the past 3 weeks about signals not being
> restored at the right time when using eval. You might want to p5p
> archives for that.
Thanks Liz for the note. I have found the discussion, and have down
loaded the fellows test script. Unfortunately it does NOT reproduce the
bug on my system (current gentoo) with perl 5.8.0 I am building a 5.8.2
perl now to see what that does.
I think I will see if I come up with an object implementation the resets
the handler in on object destruction. I will then modify his script to
see if the problem persists with Sys::SigHandler, using scope based
resets.
Re: RFC: CGI::UploadDB
Hi Mark,
Taking a scan though this. The first issue concerns how the
documentation is is put forth. It's not quickly clear to me what the
module does. At first glance I thought "CGI::UploadDB - Manage CGI
uploads using SQL database" meant is was a module for automatically
uploading/replicating database tables from one database to a remote
database on your web site via CGI (probably because I recently wrote
that). The word "manage" itself in imprecise, especially when "using
SQL database" could modify either "CGI uploads" or the "management of
CGI uploads."
On reading the description, it seems to be a module for a web-accessible
file system, where file data is stored in a real file system and file
meta data is stored in a database for easy searching. This seems
widely useful as an alternative to FTP, kind-of like a much trimmed down
version of Zope for Perl (i.e. Pope). However, the module does only the
data processing and CGI request handling parts this and does not create
the UI/HTML--this context in which it is used can be stated as well.
So, the next question concerns how to upload a file. One apparently
uses the install_uploads method, passing it a
Data::FormValidator::Results object, but what CGI request parameters
must be sent? What would the HTML form look like? I'm expecting
something like
...
possibly even in the SYNOPSIS and expecting some code like
$fh = $query->upload('something');
while (<$fh>) { ... }
in the module itself. However from the code, there seems to be a
temporary file that must be created:
copy($q->tmpFileName($q->param($i)),
$self->{updir_path}."/$id".$info->{extension})
In fact, I've never seen this CGI::tmpFileName method before. I first
thought this was requiring a temporary file upload via FTP or something.
tmpFileName is partly documented in CGI::Simple but is also
undocumented but existant in CGI.pm. So, the fact that the module uses
some directory to store temporary files should be stated as well.
At first I was confused about the deal with the thumbnails. How are
thumbnails used and accessed? Are they displayed (no) or merely stored
(yes)? Are thumbnails like buttons or icons (associated with file
types) or snapshots associates with individual images? The latter seems
the case now, but it unclear until I got to the METHODS section where it
says "thumbnails that will be created for these files (if they are
images)" since I was thinking about non-image types of files (text
files, Perl files, *.gz.bz2.tar.gpg.md5 files, etc...). Can there be
multiple thumbnails per file? Can a single thumbnail be associated with
multiple files? Is a thumbnail deleted when a file associated with it
is deleted? The first part of the DESCRIPTION section is good in that
it starts defining what the data model is and what the database and file
system requirements are, but nowhere is this done fully. You could say
somewhere something like, "You must have available a web-accessible
directory ona POSIX-compatible file system with such-and-such file
permissions and sufficient free space to hold file uploads. Changes to
that directory will be managed entirely via CGI::UploadDB. There must
also be a temporary directory with such and such permissions capable of
holding at least one concurrent file upload Uploaded files can be
binary or ASCII handled as such and such, and each file can have
user-supplied/inferred metadata associated with it: (if applicable) zero
or more image thumbnails rendered automatically by CGI::UploadDB based
on mime-type/file-extension, a file ID, File names are not stored.
Custom metadata attributes are/are-not supported via such and such.
Your code own must generate HTML forms with ...such and such...
parameters that will form the requests handled by CGI::UploadDB...etc.
etc. etc.."
OK, so once you upload a file, and you know the filename, how do you
find it? The uploads table has "id" and "[file]extension" fields but no
file name field. On further look, it seems that files are referenced
purely by numeric ID as clarified near the end of the document where it says
{
file_1_id => 523,
file_1_url=> 'http://localhost/images/uploads/523.pdf',
}
Some other terminology like "installs all the files on the file system"
can be misleading. When I hear "install," I think "make install" as in
"upload a *.tar.gz file and install it" or "Add it to the system PATH,"
which some users may enjoy doing :)
So, that was my first impression, hopefully useful.
-davidm
Mark Stosberg wrote:
Hello,
I'm interested in feedback on a module I've developed
Re: RFC: CGI::UploadDB
* 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? Casual glance says it's fine. Would have to try to implement something using the module to tell you how clear it really is. Can't really comment more, as I didn't actually ever get anywhere with that script.. -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
RFC: CGI::UploadDB
Hello, I'm interested in feedback on a module I've developed to manage file uploads, which I'm calling CGI::UploadDB for now. CGI::UploadDB manages file uploads with a SQL database. It handles generating thumbnails, file installation, deletion, and display. Files are stored on the file system with meta-data in the database. MySQL and Postgres are supported. I'm interested to know: OK Name? Useful idea? Useful interface? Clear documentation? Other suggestions? Full documentation [1] and source code [2] are available. It currently depends on the brand new Data::FormValidator 3.50 release. 1. http://mark.stosberg.com/dfv/doc/CGI/UploadDB.html 2. http://mark.stosberg.com/perl/CGI-UploadDB-0.10_03.tar.gz 3. http://search.cpan.org/perldoc?Data::FormValidator Thanks! Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: New version of Roman available
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 - Allows conversion between Roman and Arabic algarisms. Text-Roman-3.3 - 15 Jan 2003 - Erick Calder Math::Roman - Arbitrary sized Roman numbers and conversion from and to Arabic. Math-Roman-1.05 - 08 Nov 2001 - Tels Convert::Number::Roman - Convert Between Western and Roman Numeral Systems. Convert-Number-Roman-0.01 - 22 Jun 2003 - Dyacob - Flavio S. Glock
Re: New version of Roman available
Hi Michel, I think your way of going with your module release is wrong. Having the modules on your home page isn't good enough, you should be able to have it on CPAN (you deserve that). 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. Roman.pm is a very little package, copy what you need and give credits to Mr OZAWA then you are done. Cheers, Nadim. "Michel Rodriguez" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi, > > A while back I asked if it was possible for me to take over the > maintenance of Roman.pm. > > I got no answer...
New User
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 relationship. I have an unreleased build system written in perl (+/- 350 Kb) that is quite fun to use. I'll try to be a bit active. Nice to be here Nadim. (NKH)
Re: Possible module for 'safer' signal handling....
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 old
value when the object is destroyed. It would be trivial to add a
variant of sig_set_action() to do that for those that want it.
Something along the lines of:
sub sig_set_action_auto_restore {
my $class = shift;
return bless sig_set_action(@_), $class;
}
sub DESTROY {
shify->sig_set_action();
}
I'm not sure whether this is relevant here, but I seem to recall a
bug reported sometime in the past 3 weeks about signals not being
restored at the right time when using eval. You might want to p5p
archives for that.
Liz
Re: Possible module for 'safer' signal handling....
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 at 15:50, Tim Bunce wrote:
> [snip]
> > 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 which uses
> perl's internals to set signal handlers, and have them restored when the
> object returned gets destroyed as it goes out of scope. It does not
> help us with our problem however, as it just does what perl does. I see
> no real benefit to this over:
>
>eval {
> local $SIG{ALRM} = sub { ... };
>}
>
> Perhaps there was a time when the above trick was not well known, and
> Sys::Signal was implemented to do that. After looking at the truss and
> strace outputs for the way the above code works, I would say that
> Sys::Signal is pretty unnecessary.
The Sys::Signal docs suggest the key feature is "with the added
functionality of restoring the underlying signal handler to the
previous C function, rather than Perl's". Perhaps perl didn't do
that before.
Um, or perhaps the only way to do that from perl is to use local()
but there are times where local() doesn't provide the right lifespan.
Either way your Sys::SigAction is sufficient. The only thing it's
lacking that Sys::Signal has is the automatic restoration of the old
value when the object is destroyed. It would be trivial to add a
variant of sig_set_action() to do that for those that want it.
Something along the lines of:
sub sig_set_action_auto_restore {
my $class = shift;
return bless sig_set_action(@_), $class;
}
sub DESTROY {
shify->sig_set_action();
}
Tim.
Re: Possible module for 'safer' signal handling....
* 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 which
> uses perl's internals to set signal handlers, and have them
> restored when the object returned gets destroyed as it goes out
> of scope. It does not help us with our problem however, as it
> just does what perl does. I see no real benefit to this over:
>
>eval {
> local $SIG{ALRM} = sub { ... };
>}
>
> Perhaps there was a time when the above trick was not well
> known, and Sys::Signal was implemented to do that. After
> looking at the truss and strace outputs for the way the above
> code works, I would say that Sys::Signal is pretty unnecessary.
Actually, I think it is much worth pursuing, given this:
* Lincoln A. Baxter <[EMAIL PROTECTED]> [2004-01-11 15:19]:
> This module is almost as convenient to use as the above:
>#timeout a system call:
>use POSIX ':signal_h' ;
>use SignalHandler qw( set_handler );
>
>eval {
> local $SIG{ALRM};
> set_handler( 'mypackage::mysubname' ,SIGALRM );
> alarm(2)
> #... do something you want to timeout for instance:
> $dbh = DBI->connect( "dbi:Oracle:$dbn", $usr, $pwd
> ,{ AutoCommit=>$self->auto_commit()
> ,RaiseError=>1
> ,PrintError=>$self->print_err()
> } );
> alarm(0);
>};
>#perl clears the handler here... because of the local dec above
>alarm(0);
>if ( $@ ) ...
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 returning an
object that auto-restores the signal in question on destruction
only if the context is not void.
That way people could write
my $restore = sig_set_handler( ... );
when they want it undone and simply
sig_set_handler( ... );
when they do want the change to persist until explicit change.
--
Regards,
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
Re: Possible module for 'safer' signal handling....
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 reply to the thread in general: yes please. This module would be very handy, coding up an esoteric distinction between 5.8 & 5.6 that would take me at least the nine months you took to find, and probably more. This module wpould be a splendid thing. All power to your coding elbow. Mx.
