Re: Dpchrist::FileType
Dear Mark Jason Dominus: Please reconsider changing the name of the Dpchrist::FileType Perl module/ distribution: http://search.cpan.org/~mjd/Dpchrist-FileType-0.10/lib/Dpchrist/FileType.pm I have scheduled the modules for deletion.
Re: What hurts you the most in Perl?
To add my five cents, the thing that hurts me the most is that Perl is not an accepted language when it comes to the differnet new platforms. Our work has adopted Drupal as a CMS and it's written in PHP. It would be awesome if it was written in Perl, but as someone else posted in this thread, we can pick up languages pretty easily (better than foreign languages, no? ;)) and be productive in a few weeks. I'm also attracted to the new Android and iPad platforms, but there's no Perl there, either. There's no Perl when it comes to creating client-side web applications (using JavaScript). IMHO, Perl is getting relegated to server-side/backend applications and when more power is getting brought to the front, it's losing mindshare/focus. - Jason http://use.perl.org/~Purdy/journal/31280 On 11/24/2010 07:01 AM, Gabor Szabo wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. So I wonder what hurts *you* the most in Perl? Gabor -- Gabor Szabo http://szabgab.com/ Perl Ecosystem Group http://perl-ecosystem.org/
Re: Begging for money - too tacky?
This might be a cool thing to add to CPAN in the form of a Tip Jar. People/Companies could donate money through there and CPAN could also keep track of donations as a form of popularity. Authors could also tithe or mark some percentage to donate to the Perl Foundation. I had looked at doing this a few months ago as a Perl Grant, but the hang up is the payment technology. Some of the bigger players (Amazon, PayPal, Google Checkout) restrict who can sign up to receive money, nationality-wise. Since the CPAN authorhood is a diverse group, we couldn't get complete coverage. - Jason Dave Rolsky wrote: On Tue, 15 Jul 2008, David Cantrell wrote: IIRC Amazon have a donation thing. If you have an Amazon wishlist, point people at that too. About half the donations I get for CPANdeps are in the form of books and DVDs. In my case, I mostly don't want stuff, so I'd really prefer people to send cash or nothing. For the stuff I do want, I generally either buy local, used, or both, so cash works well for that ;) -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Naming advice: Smart Card Interface module
Greetings and salutations, I am seeking advice for namespace selection for a smart card interface module, as I have read through all of the faqs on cpan.org, as well as Life With CPAN and perl*mod*, and have thus far been unable to come up with a consistent and current answer. I am currently working on a high-level interface for a particular brand of MCU smart card (the ACOS2). This module will initially rely heavily upon the Chipcard::PCSC and Chipcard::PCSC::Card modules, and thus I would naturally assume it belongs under that hierarchy. I am planning on testing and working on modules for various other manufacturers, and potentially basing them upon the same underlying support modules, assuming that the PC/SC interface is flexible enough to meet my needs. My question, therefore, is this: Should this module be called: Chipcard::ACOS2 Chipcard::PCSC::ACOS2 Chipcard::PCSC::Card::ACOS2 - or - Something::Else::ACOS2 ? Since Chipcard::PCSC and C::P::Card are both by the same author, I am not sure about polluting his namespace with an inappropriate module, but there are also drawbacks to placing it so far down the hierarchy, as previously mentioned in the old Master Modules List (that is no longer being maintained). It is also possible that at some point in the future, it may be beneficial to move this out from under the PC/SC tree and into a more generic hierarchy, as I may end up relying upon another driver and/or module to perform the backend communication (OpenSC/CT, pkcs11, etc), and thus I would to like to do future-proofing as early as possible. (However, moving modules around might be just worth a separate submission later, as it would likely entail a fairly substantial rewrite..) Any advice would be appreciated. Thank you kindly, Jason McManus
Re: detecting the invoking perl
Quoting Ovid [EMAIL PROTECTED]: http://search.cpan.org/~mschwern/ExtUtils-MakeMaker-6.25/lib/ExtUtils/MakeMaker.pm The bug you are referring to appears to be: http://rt.cpan.org/NoAuth/Bug.html?id=6588 bryar-newblog is referenced in the EXE_FILES of the Makefile.PL. and it's shebang line is #!/usr/bin/perl. According to the ExtUtils::MakeMaker docs: If your executables start with something like #!perl or #!/usr/bin/perl MakeMaker will change this to the path of the perl 'Makefile.PL' was invoked with so the programs will be sure to run properly even if perl is not in /usr/bin/perl. So, if the bug author is still finding the shebang line is wrong, I would suggest either they ran Makefile.PL with the wrong Perl or there is a bug in their ExtUtils::MakeMaker setup. Does this answer the question? Yes it does. Cool. I was always concerned about this, but haven't had an impetus to find out what the deal was/fix it until i wanted to close out that bug. Thanks Randall and Ovid for the pointers. /me ducks now for not reading the make maker documentation. It never occurred to me that this was install magic. -jason gessner [EMAIL PROTECTED]
new module, Data::Form::Elements
Hi All.
Thanks to Mark Stosberg for helping me name this a while ago. I have
released Data::Form::Elements to the CPAN (it should show up in a
while. not sure how long it takes. This is my first public module.
The module is downloadable here, though:
http://www.multiply.org/notebook/archives/000588.html
).
Basically, Data::Form::Elements is an OO wrapper around
Data::FormValidator that gives you a form object with paramaters and
validation. The docs in the POD are pretty clear, but here is a short
example:
use Data::Form::Elements;
my $form = Data::Form::Elements-new();
# add a couple elements
$form-add_element( username, {
required = 1, errmsg = Please provide your username.
} );
$form-add_element( password, {
required = 1, errmsg = Please provide your password.
} );
...
$form-validate( %ARGS );
if ( $form-is_valid() ) {
# continue logging on ...
}
I would appreciate any feedback, bug reports ,etc.
Thanks!
-jason scott gessner
[EMAIL PROTECTED]
Re: [RFC] - New module proposal: JavaScript::DebugConsole
HTTP::Recorder has a console feature that you may want to check out as well. I know that Linda hasn't made it a separate module, but the two of you may have an interesting possibility to combine features. -jason scott gessner [EMAIL PROTECTED] On May 5, 2004, at 9:23 AM, Enrico Sorcinelli wrote: Hi all, I packaged some my old and simple functions inside a Perl module (I was tired to do cutpaste each time :-) ) to generate the necessary JavaScript code in order to open a popup window with custom text and typical web development useful infos (like form params, env vars, HTTP headers and so on). For example: my $jdc = new JavaScript::DebugConsole( %args ); $js_code_to_put_in_html_page = $jdc-debugConsole( content = $content, title = $title', auto_open = 1 ); $link_to_open_popup = $jdc-link; (There are also other methods and properties). Of course before coding, I've searched similar modules over CPAN with no significant results. So, I'm considering to put it on CPAN. It will be useful? It is a good name? Maybe CGI::JavaScript::DebugConsole, JavaScript::Popup*, JavaScript::*, [...] sounds better? Any suggestions and/or criticisms are welcome. Thanks in advance. by - Enrico
New Wrapper API for Data::FormValidator
I have written a wrapper API around Data::FormValidator and it is
getting close to being sharable.
The module basically provides an object oriented API to add form
elements dynamically, and wraps the output of a validator object from
your module.
A sample of the code to make a form looks like this:
$form-add_element( category_id, { required = 1 } );
$form-add_element( name, { required = 1, errmsg = 'Please fill
in a name for this category' } );
$form-add_element( description, {} );
$form-add_element( help_text, {} );
$form-add_element( sort_position, { required = 1, constraints
= qr/^\d+$/, invmsg = The sort position has to be a number. } );
$form-add_element( visible, { required = 0, value = 0,
constraints = qr/^\d+$/, invmsg = The sort position has to be a
number. } );
then, each element can be accessed like this:
$form-param(category_id); # the current value
$form-message(category_id); # the error message or invalid message,
depending on if
# something is missing or invalid.
Basically, this will construct a profile for D::FV to use, but still
allow easy access to the objects in the form in another part of an
application.
I am looking for naming ideas. I had initially thought of
Data::FormValidator::API, but it lacks a certain pizazz. ;)
Any thoughts? Any interest?
And hello! This is my first post to the group.
Thanks!
-jason scott gessner
[EMAIL PROTECTED]
Detecting updates to installed modules?
Has anyone created a tool to determine what modules are installed locally, and check CPAN for updates to any of those modules? I don't want to reinvent the wheel here, but I can't find anything that does this. CPAN.pm does a fine job of download-and-install, but there's no inventory function or query-for-update. Thanks, -Jason
