Re: Jperl is bad name -;
What does it do that is different from the existing JavaScript modules? Maybe you can build on top of one of those? On Tue, Oct 29, 2013 at 4:58 PM, Jean-Damien Durand jeandamiendur...@free.fr wrote: Big thanks for all the suggestions! Let me reply to the original mail directly. I liked - JavaScript::Transpile for its explicit namespace and play on words translate/compile (that's my interpretation, Aristotle) - Robusta is cool and breaks a little bit the $animals naming tendency - Puffin - Luwak Let me adopt Puffin... I like the fact that is starts with 'P' -; Many thanks again to everybody / JD. -- Check out my LEGO blog at brickpile.com http://www.brickpile.com/ Follow/friend me: Facebook http://facebook.com/billward • Flickrhttp://flickr.com/photos/billward/• Twitter http://twitter.com/williamward • LinkedInhttp://www.linkedin.com/pub/william-ward/63/393/985/
Re: please help me name a module
I'd suggest Vehicle instead of Car since future instances might be trucks, vans, motorcycles, etc. Sent from my phone (sorry if my reply is brief, ask me again when I'm at a real keyboard) On Sep 12, 2013 1:47 AM, Aaron Trevena aaron.trev...@gmail.com wrote: On 12 September 2013 07:58, Aristotle Pagaltzis pagalt...@gmx.de wrote: * Greg Lindahl lind...@pbm.com [2013-09-11 22:45]: I have a module that talks to my car, a Tesla Model S. You can get speed and position, remotely turn on the AC, all that good stuff. Cool!! +1 serious envy! These sorts of things are sometimes called the Internet of Things, or IOT. Looking in CPAN I don't see any existing modules for cars or mentioning the Internet of Things. There is a top-level group named Device that might be useful ... Device::Tesla? Device::Auto::Tesla ? That was the TLNS I immediately thought of. Device::Car::Tesla? Yes, much better. Auto is ambiguous and rarely used to refer to cars except by merkins. A.
Re: please help me name a module
On Thu, Sep 12, 2013 at 9:38 AM, Smylers smyl...@stripey.com wrote: David Precious writes: On Thu, 12 Sep 2013 12:15:22 +0100 David Cantrell da...@cantrell.org.uk wrote: I'd go for Device::Car::Tesla(::ModelS)?. Car, not Auto, because in most of the English-speaking world auto means automatic, not automobile. Also, I would suggest including the ::ModelS, as it's entirely possible that Tesla will release budget modules in future which won't support all the cool stuff. Bill Ward writes: I'd suggest Vehicle instead of Car since future instances might be trucks, vans, motorcycles, etc. How about Vehicle::Tesla::ModelS then? Does putting Device:: in front of that lot actually add anything, other than to the unwieldiness of the name? I like that -- Check out my LEGO blog at brickpile.com http://www.brickpile.com/ Follow/friend me: Facebook http://facebook.com/billward • Flickrhttp://flickr.com/photos/billward/• Twitter http://twitter.com/williamward • LinkedInhttp://www.linkedin.com/pub/william-ward/63/393/985/
Re: please help me name a module
On Thu, Sep 12, 2013 at 8:56 PM, Greg Lindahl lind...@pbm.com wrote: On Thu, Sep 12, 2013 at 05:38:00PM +0100, Smylers wrote: How about Vehicle::Tesla::ModelS then? Does putting Device:: in front of that lot actually add anything, other than to the unwieldiness of the name? Vehicle:: doesn't generalize very well to toasters, refrigerators, etc. If a new top-level name is a good idea, I'd suggest an Internet-of-Things top-level, Thing:: or IoT:: or IOT:: This particular module, btw, will probably be good for future Tesla vehicles; it's anyone's guess how the API will evolve. In fact, at the moment it's just the reverse-engineered API used by the Tesla iOS and Android apps; nothing officially supported. I'll have to have a big fat dislciamer at the top of the POD... Thing::Vehicle::Tesla::ModelS? -- Check out my LEGO blog at brickpile.com http://www.brickpile.com/ Follow/friend me: Facebook http://facebook.com/billward • Flickrhttp://flickr.com/photos/billward/• Twitter http://twitter.com/williamward • LinkedInhttp://www.linkedin.com/pub/william-ward/63/393/985/
Re: What to call a module that rewrites Perl code
Is it truly only ever going to work on Perl code? Mightn't it also be pluginnable to rewrite other kinds of files? On Friday, August 30, 2013, Shlomi Fish wrote: On Sat, 31 Aug 2013 06:11:03 +0100 Robert Rothenberg r...@cpan.org javascript:; wrote: At $work, I've been writing scripts that use PPI to munge massive amounts of legacy code. So far simple things like changing die/warn to croak/carp, ensuring all modules specify a minimum version number, or changing print foo\n so say foo, etc. It seems worthy enough to turn this code into a CPAN module. My thoughts are that it would use a plugin system for specific tasks, and a command-line script that takes plugin names as arguments, so basically you'd run the script to apply various tasks to a set of modules or scripts in a directory, perhaps using a configuration file for each of the plugins. The early version would have simple plugins, but there's no reason why more complex plugins couldn't be written (e.g. to translate a non-Moose class into something Moose-like), or other things like optimize certain kinds of expressions. I'm well aware of the limitations of doing this automatically. But the idea is to get a script that can do the bulk of the tedious rewriting, so that a human can clean up the mistakes. It's meant to be run by intelligent people who use things like version control and tests. So what should it be called? I'm thinking Perl::Rewrite is the best name. Alternatives are: - Perl::Refactor - except refactoring has a technical meaning that I don't think applies - Perl::Modernize - except that one might want a plugin that translates newer-style code into older code - Perl::Munge - except that it connotes sloppiness - Perl::Snorft - no, just kidding I have no idea what that means. - ? Perl::Modify? Perl::Transform? Perl::Revise? I don't like Perl::Rewrite too much because it may (but not necessarily) imply rewriting from scratch. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Stop Using MSIE - http://www.shlomifish.org/no-ie/ “My only boss is God. And Chuck Norris who is his boss.” — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ Please reply to list if it's a mailing list post - http://shlom.in/reply . -- Check out my LEGO blog at brickpile.com http://www.brickpile.com/ Follow/friend me: Facebook http://facebook.com/billward • Flickrhttp://flickr.com/photos/billward/• Twitter http://twitter.com/williamward • LinkedInhttp://www.linkedin.com/pub/william-ward/63/393/985/
Re: Namespace for Module Wrapping iTunes' Store Executable
On Tue, Jun 25, 2013 at 1:07 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote: Net::iTMS No, for the well-known reasons. What well-known reasons? -- Check out my LEGO blog at brickpile.com http://www.brickpile.com/ Follow/friend me: Facebook http://facebook.com/billward • Flickrhttp://flickr.com/photos/billward/• Twitter http://twitter.com/williamward • LinkedInhttp://www.linkedin.com/pub/william-ward/63/393/985/
Re: Namespace for Module Wrapping iTunes' Store Executable
Thanks On Tue, Jun 25, 2013 at 1:31 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote: http://pause.perl.org/pause/query?ACTION=pause_namingmodules#Net -- Check out my LEGO blog at brickpile.com http://www.brickpile.com/ Follow/friend me: Facebook http://facebook.com/billward • Flickrhttp://flickr.com/photos/billward/• Twitter http://twitter.com/williamward • LinkedInhttp://www.linkedin.com/pub/william-ward/63/393/985/
Re: removal request - Sys::UniqueID
On Wed, May 2, 2012 at 6:25 AM, Daniel Lukasiak est...@estrai.com wrote: On 02/05/12 00:49, Todd Rinaldo wrote: On May 1, 2012, at 1:09 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote: If removal isn't possible is there any other mechanism (forced depreciation?) that can be used? You could take it over and fix it… I'd be more than happy to contribute but only if that would provide any value. In this case I think there's more value in removing this broken module, there are much better alternatives. I understand this is a problem with CPAN's nature, but there must be a line somewhere. Taking it over only to deprecate it might be a solution. -- Check out my LEGO blog at http://www.brickpile.com Follow/friend me: facebook.com/billward • flickr.com/photos/billward • twitter.com/williamward
Re: Changing module name
I think the easiest solution is to create a new module with the new name, and refactor the old one to use it... so Plack::Middleware::Auth::Form would still exist as a consumer of the new module, and perhaps there are some Plack-specific things that it might add to the inherited object, especially if what you're creating is truly a webprototype, and the existing module is truly middleware... 2012/4/9 Zbigniew Łukasiak zzb...@gmail.com I am thinking about changing Plack::Middleware::Auth::Form to WebPrototypes::LoginForm - the idea is to provide more such 'widgets' (there are already two published: http://search.cpan.org/search?query=webprototypesmode=all - still experimental) with the same basic approach for reusabillity of web elements. Is there a common procedure for such a migration? -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ -- Check out my LEGO blog at http://www.brickpile.com Follow/friend me: facebook.com/billward • flickr.com/photos/billward • twitter.com/williamward
Re: Seeking advice on module name: Config::CPP?
Consider CPP::Config? On Fri, Mar 23, 2012 at 2:49 PM, David Oswald daosw...@gmail.com wrote: I maintain Inline::CPP. Currently that module's Makefile.PL jumps through a bunch of hoops to detect the C++ compiler most compatible with the C compiler that built perl, and to detect what default C++ libraries should be linked in when building Inline::CPP client code. A lot of work has gone into tweaking to obtain better success rates with as wide a variety of platforms as possible. This work could be applicable to other modules that wish to build XS code based on C++. Additionally, I would like the ability to continue development (there's a lot of work still to do) on this task independently of Inline::CPP (I don't like uploading a new Inline::CPP for smoke testing every time I want to smoke test a change to Makefile.PL while leaving the core modules virtually unchanged). So I intend to split this functionality out of Inline::CPP's Makefile.PL by creating a new module to handle the detection/guessing logic. That begs the question of what to call it. Config already reveals information about how Perl was built (C compiler, etc.). This is essentially an extension of that functionality. Therefore, it makes sense to me to call it something like Config::CPP. But unfortunately, Config shares its top-level namespace with modules that are used to deal with configuration files (Config::Auto, Config::General, Config::JSON, etc.). My question is what would be an appropriate name for this module? Dave Oswald dav...@cpan.org -- Check out my LEGO blog at http://www.brickpile.com Follow/friend me: facebook.com/billward • flickr.com/photos/billward • twitter.com/williamward
Re: Naming of Perl module
On Wed, Dec 14, 2011 at 3:46 AM, Smylers smyl...@stripey.com wrote: Bill Ward writes: File::RegexMatch? I think having ::Find:: in there would be better, so that it's immediately obvious that this module performs a similar task to the other modules already named like that. File::Find::Regexp, perhaps? I like that, but that implies that its interface is similar to File::Find. Is it? (Note that 'Regexp' with a 'p' appears to be the canonical Perl way of spelling it: % perl -E say ref qr// It's also a superset of the spelling 'Regex', so searching for 'Regex' should still find it, whereas searching for 'Regexp' wouldn't match 'Regex'. On the downside, 'Regexp' is considerably harder to say than 'Regex'.) You're right, but I'm much more accustomed to Regex for some reason, despite the fact that Emacs too uses regexp -- Check out my LEGO blog at http://www.brickpile.com Follow/friend me: facebook.com/billward • flickr.com/photos/billward • twitter.com/williamward
Re: Naming of Perl module
On Wed, Dec 14, 2011 at 7:24 AM, Smylers smyl...@stripey.com wrote: Bill Ward writes: On Wed, Dec 14, 2011 at 3:46 AM, Smylers smyl...@stripey.com wrote: Bill Ward writes: File::RegexMatch? I think having ::Find:: in there would be better, so that it's immediately obvious that this module performs a similar task to the other modules already named like that. File::Find::Regexp, perhaps? I like that, but that implies that its interface is similar to File::Find. Not really. File::Find::Rule doesn't have a similar interface to File::Find, for instance. Maybe so, but I think that will be a potential user's first assumption. -- Check out my LEGO blog at http://www.brickpile.com Follow/friend me: facebook.com/billward • flickr.com/photos/billward • twitter.com/williamward
Re: Naming of Perl module
File::RegexMatch? On Tue, Dec 13, 2011 at 8:21 AM, ll...@singletasker.co.uk wrote: Hi there, I'm close to completing a module, but I'm pretty clueless on what to call it. The purpose of the module is to find files which match a regular expression. The module currently only has one subroutine which takes two parameters, base_directory and expression. The subroutine traverses all subdirectories of the base directory and returns a hash when it's completed. Each key of the returned hash is the absolute path of the directory, and the value(s) associated with the key are the files which were found matching the regular expression within that directory, the hash only returns a directory if there are files which matched the given regex found within that directory. I've had a couple of ideas such as File::Snap (based on a card game I used to play as a child), but I'm not sure if it's very suitable. Any guidance would be appreciated. Many thanks, Lloyd. -- Check out my LEGO blog at http://www.brickpile.com Follow/friend me: facebook.com/billward • flickr.com/photos/billward • twitter.com/williamward
Re: Module naming: postifx/dovecot/MySQL configuration
Mail::Postfixadmin seems fine to me On Tue, Dec 13, 2011 at 5:06 AM, Avi Greenbury li...@avi.co wrote: Hi, I've been working on a module which basically makes it easy to write command-line tools for interacting with a postfixadmin[0] installation, that is a Postfix/Dovecot mail server with virtual domains/users stored in MySQL. I'd like to upload it to the CPAN, and I'm after some advice on what to call it first. The closest I can find on the CPAN is VUser::Email::Postfix which is part of VUser. There's also Mail::Vpopmail which is exactly the same in purpose, but for Vpopmail rather than postfixadmin. To me, this obviously belongs somewhere in the Mail namespace, but I'm not really sure where it should go in that. I'm tempted to rename it to Mail::Postfixadmin, but I don't want to give the impression that it's somehow endorsed by that project. It's currently called Mail::Vpostmail (since originally it was to be a postfix clone of the Vpopmail utilities and it must have seemed like a reasonable pun at the time). I've got a bunch of work to do on it over Christmas, and I figure that that's also as good a time as any to rename it in preparation for making it more public and check everything still works. Thanks! -- Avi [0] http://sourceforge.net/projects/postfixadmin/ -- Check out my LEGO blog at http://www.brickpile.com Follow/friend me: facebook.com/billward • flickr.com/photos/billward • twitter.com/williamward
Re: The module authors pledge
On Fri, Nov 11, 2011 at 2:43 PM, yan...@babyl.dyndns.org wrote: On Thu, Nov 10, 2011 at 11:27:04PM +, Neil Bowers wrote: Interesting thought. How about: - if a distribution author appears to be inactive, then the author would receive an email to their registered CPAN email address saying this distro appears to be inactive, just reply to this email to let me know otherwise. That's the tricky part where the the system has not to be too spammy. For peeps with one or two dists, it's not an issue. For the CPAN titans who are owning hundreds of distributions, we... probably don't want to send an email for every module. We should have at most an aggregated reminder every X weeks, and allow for the author to see/select her distros in a single, easy way. How about just do it by author - if any of the author's distros are idle for 6 months, send them an email?
Re: The module authors pledge
I think the Should I die (though I think in the event of my death would be better) can only really work if a family member replies to the email saying that the maintainer has passed away, which isn't too likely but could happen. Since those time limits would expire eventually anyway, it's probably not necessary except that it speeds up the process---*if* you get confirmation of death. On Thu, Nov 10, 2011 at 6:58 AM, David Cantrell da...@cantrell.org.ukwrote: On Tue, Nov 08, 2011 at 04:22:02PM +, Neil Bowers wrote: I hereby give modu...@perl.org permission to grant co-maintainership to any of my modules, if the following conditions are met: (1) I haven't released the module for a year or more (2) There are outstanding issues on RT which need addressing (3) Email to my CPAN email address hasn't been answered after a month (4) The requester wants to make worthwhile changes that will benefit CPAN Should I die, then the time-limits in (1) and (3) do not apply. So, what do y'all think? I think that this isn't really different from what happens now anyway. -- David Cantrell | Reality Engineer, Ministry of Information -- Check out my LEGO blog at http://www.brickpile.com Follow/friend me: facebook.com/billward • flickr.com/photos/billward • twitter.com/williamward
Re: Math::BigInt inheritance problems
On Sun, Oct 9, 2011 at 7:44 AM, Paul Bennett paul.w.benn...@gmail.comwrote: On Sun, 09 Oct 2011 10:34:46 -0400, Leon Timmermans faw...@gmail.com wrote: I think the obvious mistake you're making is using inheritance in the first place. Why are you doing that? Your interface is not «an IP address is really a number», so why would you make it one? Ah, but an IP address *is* really a number. An unsigned 128-bit integer, in fact, with some additional properties that are specific to the semantics of IP addresses themselves. An unsigned base 256 4-digit number, perhaps True, certain operations (multiplication and division spring to mind) are -- probably -- bad ideas, but addition, subtraction, bitwise operations, bitshifting, comparison (including range comparison and sorting), and many other good numbery things definitely apply. -- Paul Bennett (PWBENNETT) -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Math::BigInt inheritance problems
On Mon, Oct 10, 2011 at 10:42 AM, Paul Bennett paul.w.benn...@gmail.comwrote: On Mon, 10 Oct 2011 13:30:22 -0400, Bill Ward b...@wards.net wrote: On Sun, Oct 9, 2011 at 7:44 AM, Paul Bennett paul.w.benn...@gmail.com** wrote: Ah, but an IP address *is* really a number. An unsigned 128-bit integer, in fact, with some additional properties that are specific to the semantics of IP addresses themselves. An unsigned base 256 4-digit number, perhaps No. IPv4 can be represented that way, though at heart they're a 32-bit unsigned integer (in Network order). That's what I was talking about IPv6 is an unsigned 128-bit number (in Network order), and has a space for compatibility with IPv4 at 0x. Therefore it is safe, sane, and consensual to store them all as IPv6 addresses (using the compatibility area for IPv4 addresses). I don't use IPv6 personally... at least not directly
Re: PDF in Marpa::XS distribution?
On Mon, Jul 18, 2011 at 2:07 PM, Andreas J. Koenig andreas.koenig.7os6v...@franz.ak.mind.de wrote: On Sun, 17 Jul 2011 09:43:01 -0700, Jeffrey Kegler jeffreykeg...@mac.com said: I'd like feedback on a question. My feeling is that internals documentation is important, that disk is relatively cheap, and that I should include the PDF file that contains Marpa's internal documentation with the CPAN distribution. But I'd like to know if others agree. I have read three opinions for separating documentation and code. I myself am pretty indifferent, but I'd point out that potentially code and docs would not need the same update frequency. That would mean that a separate way of distributing could be taken. Why is the documentation in PDF form? If it's documentation for a Perl module, it should be in POD format so that it can be viewed the way all other Perl modules are. If the PDF is not closely linked to the Perl module, then a link in the POD to a Web URL where it can be found for more information seems like the way to go.
Re: Need suggestions for a module name
It's not really that high level or specialized. It's just a matter of updating how the file name is generated. I could easily see it going either way. If you do go with a separate module, the interface should be the same (with whatever added options needed to add the new features) as File::Temp, for reduced confusion. On Sat, Jun 18, 2011 at 5:36 PM, Robert Rothenberg r...@cpan.org wrote: The module makes use of File::Temp, but the interface is different, and I don't think it makes sense to add specialised high-level functionality to a low-level module. On Sat, Jun 18, 2011 at 4:42 PM, Bob Parker b...@perldevgeek.com wrote: -Original Message- From: Robert Rothenberg r...@fastmail.net Reply-To: Robert Rothenberg at CPAN r...@cpan.org Date: Thu, 16 Jun 2011 21:23:50 +0100 To: Perl Module Authors List module-authors@perl.org Subject: Need suggestions for a module name While debugging a project that generated a lot of temporary files, I came upon a nifty idea: rather than name the temporary files the usual random strings, why not have the files named by the method/function that created them, e.g. instead of something like /tmp/Hf6254d85.txt, why not call it /tmp/Some_Package_Name/text_analysing_function-Hf6254d85.txt. Anyhow, I think this might be something worth uploading to CPAN. So what should it be called? I was thinking of something like File::Temp::Smart, for lack of a better name. But I am open to better ideas. Suggestions? Rob Rob, rather than creating a brand new module for this, perhaps you could work with Tim Jenness to add this functionality to the existing File::Temp module as a non-default exported function and/or OO interface method? It seems like it would be useful enough that it would be fairly common for folks to use, once they realize what it is, so why make them install yet another module (assuming he agrees, of course). Obviously it could be done using the existing template functions, but to do it automatically with an option to use directories or just the file name would certainly save a lot of time code rewriting, at least IMHO. I know I've done it at least 3 or 4 times, as recently as 3 weeks ago. Just a thought, Bob -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Need suggestions for a module name
Oh, I thought it was just about generating the filename using the module/subroutine name. *that* should be in File::Temp, and maybe the other features you describe should be in a new module? On Sat, Jun 18, 2011 at 6:44 PM, Robert Rothenberg r...@cpan.org wrote: It has a different interface, necessarily. File::Temp only manages single temp files or directories in isolation, whereas my module manages a set of them with logs about how they were created. On 18 Jun 2011 23:44, Bill Ward b...@wards.net wrote: It's not really that high level or specialized. It's just a matter of updating how the file name is generated. I could easily see it going either way. If you do go with a separate module, the interface should be the same (with whatever added options needed to add the new features) as File::Temp, for reduced confusion. On Sat, Jun 18, 2011 at 5:36 PM, Robert Rothenberg r...@cpan.org wrote: The module makes use of File::Temp, but the interface is different, and I don't think it makes sense to add specialised high-level functionality to a low-level module. On Sat, Jun 18, 2011 at 4:42 PM, Bob Parker b...@perldevgeek.com wrote: -Original Message- From: Robert Rothenberg r...@fastmail.net Reply-To: Robert Rothenberg at CPAN r...@cpan.org Date: Thu, 16 Jun 2011 21:23:50 +0100 To: Perl Module Authors List module-authors@perl.org Subject: Need suggestions for a module name While debugging a project that generated a lot of temporary files, I came upon a nifty idea: rather than name the temporary files the usual random strings, why not have the files named by the method/function that created them, e.g. instead of something like /tmp/Hf6254d85.txt, why not call it /tmp/Some_Package_Name/text_analysing_function-Hf6254d85.txt. Anyhow, I think this might be something worth uploading to CPAN. So what should it be called? I was thinking of something like File::Temp::Smart, for lack of a better name. But I am open to better ideas. Suggestions? Rob Rob, rather than creating a brand new module for this, perhaps you could work with Tim Jenness to add this functionality to the existing File::Temp module as a non-default exported function and/or OO interface method? It seems like it would be useful enough that it would be fairly common for folks to use, once they realize what it is, so why make them install yet another module (assuming he agrees, of course). Obviously it could be done using the existing template functions, but to do it automatically with an option to use directories or just the file name would certainly save a lot of time code rewriting, at least IMHO. I know I've done it at least 3 or 4 times, as recently as 3 weeks ago. Just a thought, Bob -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Interesting licensing requires written permission of the author to modify it
On Mon, Mar 14, 2011 at 11:53 AM, David Nicol davidni...@gmail.com wrote: On Mon, Mar 14, 2011 at 10:22 AM, Gabor Szabo szab...@gmail.com wrote: Hi I found a module on CPAN http://search.cpan.org/~goyali/google_talk_bot_v_01/ with the following comment regarding licensing: You are not allowed to modify the script unless having the written permission of abhishek jain What do you think? Gabor I think abishek jain's domain of control does not extend to you, and as long as you aren't *distributing a derived work* copyright law does not apply. If the script in question is a trade secret, he's done a really crappy job of protecting it, posting it on CPAN and all. I think that copyright still applies for copying the original. You don't have to make a derived work of an MP3 file for it to be an illegal copy for example. But it does seem like posting it on CPAN would give de facto permission to copy the file. Also, just to be nice, you could write him for permission. He must be awfully lonely, to use that for his license. Poor fellow.
Re: Module Naming Suggestion - Carp from somewhere else
Have you talked to the maintainer of Carp about this? It might be best to
just suggest it as a new feature in Carp itself.
Otherwise, Carp::Whence or something might seem reasonable to me.
On Sat, Mar 5, 2011 at 4:11 AM, Paul LeoNerd Evans
leon...@leonerd.org.ukwrote:
(To copypaste
http://leonerds-code.blogspot.com/2011/03/carp-from-somewhere-else.html ):
Carp provides two main functions, carp and croak, as replacements for
core Perl's warn and die. The functions from Carp report the file and
line number slightly differently from core Perl; walking up the
callstack looking for a different package name. The idea being these are
used to report errors in values passed in to the function, typically bad
arguments from the caller.
These functions use the dynamic callstack (as provided by caller()) at
the time the message is warned (or thrown) to create their context. One
scenario where this does not lead to sensible results is when the called
function is internally implemented using a closure via some other
package again.
Having thought about this one a bit, it seems what's required is to
split collecting the callstack information, from creating the message.
Collect the information in one function call, and pass it into the
other.
This would be useful in CPS for example. Because the closures used in
CPS::kseq or kpar aren't necessarily invoked during the dynamic scope of
the function that lexically contains the code, a call to croak may not
be able to infer the calling context. Even if they are, the presence of
stack frames in the CPS package would confuse croak's scanning of the
callstack. Instead, it would be better to capture the calling context
using whence, and pass it into whoops if required for generating a
message.
For example, this from IO::Async::Connector:
sub connect
{
my ( %params ) = @_;
...
my $where = whence;
kpar(
sub {
my ( $k ) = @_;
if( exists $params{host} and exists $params{service} ) {
my $on_resolve_error = $params{on_resolve_error} or whoops
$where, Expected 'on_resolve_error' callback;
...
}
These functions would be a fairly simple replacement of carp and croak;
capture the callsite information at entry to a function, and pass it to
the message warning function.
It does occur to me though, the code will be small and self-contained,
and not specific to CPS. I think it ought to live in its own module
somewhere - any ideas on a name?
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iD8DBQFNcihqvLS2TC8cBo0RAuSrAJ9omaYwINWa31kEAh3jQtgjI03sMACePZzP
VbxfM0a4TuhPoJijNBwu2eg=
=Fg2o
-END PGP SIGNATURE-
--
Check out my LEGO blog at http://www.brickpile.com/
View my photos at http://flickr.com/photos/billward/
Follow me at http://twitter.com/williamward
Re: best practices for module renaming
On Mon, Feb 7, 2011 at 12:48 PM, Dave Rolsky auta...@urth.org wrote: On Mon, 7 Feb 2011, Xavier Noria wrote: Hi, I am the author of Net::FluidDB, which let's you talk to FluidDB. FluidDB has been renamed to Fluidinfo, and I should rename the module in accordance. Is there a recommended way to do this? Or should I just upload a different distribution and document the rename? Yes to your last question. You could also upload one last version of Net::FluidDB and update its docs to point to the new name. You probably also want to keep Net::FluidDB around as a wrapper module so that you don't break backward compatibility. # # ##
Re: Setting an environment variable for tests
But the question is having the command be interpreted by make, not by the shell, right? On Fri, Dec 17, 2010 at 11:59 AM, Andrew Savige ajsav...@yahoo.com.auwrote: I don't know Module::Install, but a more portable Unix way to write: export MATH_ROUND_FAIR_DEBUG=1 is: MATH_ROUND_FAIR_DEBUG=1;export MATH_ROUND_FAIR_DEBUG The former abbreviated syntax was introduced in the Korn shell, while the latter works with both the Korn shell and the original Bourne shell (bash is Korn-shell derived). Of course this is Unix-shell specific and may not work on non-Unix platforms. HTH, /-\ - Original Message From: Marc Mims m...@questright.com To: module-authors@perl.org Sent: Thu, 16 December, 2010 12:16:14 PM Subject: Setting an environment variable for tests I recently released a new version of Math::Round::Fair. Anders Johnson provided several in situ tests that we optimized out at compile time using Devel::Assert. They can be turned on by setting an environment variable: MATH_ROUND_FAIR_DEBUG=1 I wanted the assertions enabled when make test runs without having to explicitly set the variable in each test. And I found a way to do that, using Module::Install's preamble: ぴreamble export MATH_ROUND_FAIR_DEBUG=1\n; That works for Linux systems, but seems to be failing on other platforms: http://www.cpantesters.org/cpan/report/28e28ab0-0825-11e0-bb29-ad544afd17af http://www.cpantesters.org/cpan/report/68705c5e-086e-11e0-bb29-ad544afd17af So, how *should* I be doing this? -Marc -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Discussion question: what is the best syntax for documenting a coderef parameter?
I would have just said $retry and then gone on to document each of the parameters including what type they should be... and of course a croak XXX unless ref($retry) eq 'CODE' before doing any real work. On Tue, Dec 7, 2010 at 2:12 PM, David Nicol davidni...@gmail.com wrote: The pod for AnyEvent::Handle contains SNIP on_connect = $cb-($handle, $host, $port, $retry-()) This callback is called when a connection has been successfully established. The peer's numeric host and port (the socket peername) are passed as parameters, together with a retry callback. SNIP Is C$retry-() the best way to represent that a coderef is required there? It's clear, but I would have written it C\retry. And I would have written something confusing. I think Marc Lehmann has done it the right way. -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: What hurts you the most in Perl?
On Wed, Dec 1, 2010 at 1:11 PM, Gabor Szabo szab...@gmail.com wrote: On Wed, Dec 1, 2010 at 6:21 PM, Lyle webmas...@cosmicperl.com wrote: I wasn't *shitting* as you put it, on other peoples work. At least no more so than Bill's original comment about Perl 6. I expressed my opinion only and should be free to do so. I already asked Bill in my response to refrain from such comments. I don't think that having freedom of speech means we should not care about the feelings of our fellow Perl mongers and we should not respect their work. I wasn't shitting on Perl 6. I just don't think it stands a snowball's chance in hell of being adopted in place of Perl 5, unless some serious marketing energy is thrown behind it (like getting rid of the Perl name which is more of a liability these days). People will hear Perl 6 and assume it's just a new version of an obsolete language, when really it's almost a whole new language. But I'm not shitting on Perl 6 itself. I think it's got some beautiful ideas in it. But it's been in design/development for so long that it seems like it will always be vaporware, and in the meantime Perl 5 has been neglected. What's called Perl 6 should be a whole new language with a new name, and the things about Perl 5 that are so out of date should have been fixed in that codeline. As for Moose, I have similar concerns. I think it changes the nature of the language too much to be considered Perl, but not enough to be considered a new language. Maybe if Moose was more like a repackaging of Perl with the Moose stuff more tightly integrated, and presented as a new language that's based on and backward-compatible with Perl 5, then maybe it would make more sense. But as it is, it's just Perl with some weird changes to the OO practices that are incompatible with the majority of Perl5 code out there. The technology is fine. But we (collectively, the Perl community) suck at marketing. The perception I hear everywhere I go is that Perl is a dead-end language, and will soon go the way of Fortran or COBOL. It's too late to change that. But maybe if Perl 6 were released under a totally new name it could gain traction the way Ruby has done.
Re: What hurts you the most in Perl?
On Tue, Nov 30, 2010 at 5:36 PM, Chris Dolan ch...@chrisdolan.net wrote: On Nov 29, 2010, at 6:52 PM, Bill Ward wrote: What hurts me is that Perl has fallen out of favor so much ... I'm contemplating jumping ship myself, and moving to Ruby or Python, not because of anything intrinsic to the language but just because Perl is going the way of Cobol or Fortran. In the early stages of my last big Perl project, a sysadmin happened to mention to the non-technical project lead that Perl is a dead language. While that clearly was (and is) a falsehood, it nearly killed the project. To me, the mere *perception* that Perl is a troubled platform hurts the most. Yeah, whenever I tell people I write Perl I often get the response people still use that? The funny thing, though, is that I've never worked in a language that hasn't been maligned by my peers or customers at some point. Perl, C, C++, csh, Java, Actionscript, Python, Lisp, PHP, VB, Javascript, etc -- it always seems like there's someone in a position of authority who wants to trash-talk the technology. Why is that? Programming languages are like religions. People invest so much time in a language they feel that it is inherently superior to the alternatives. The reality is, any of us can pick up a new language in a few weeks if we work full-time at it.
Re: What hurts you the most in Perl?
What hurts me is that Perl has fallen out of favor so much ... I'm contemplating jumping ship myself, and moving to Ruby or Python, not because of anything intrinsic to the language but just because Perl is going the way of Cobol or Fortran. On Wed, Nov 24, 2010 at 4:01 AM, Gabor Szabo szab...@gmail.com 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/ -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Naming a module: Non bioperl related Taxonomy modules
I think if you put it under Bio:: then people will naturally assume that your modules are bioperl-related. Probably a different top level name is appropriate, maybe something starting with Bio. 2010/11/4 Miguel Pignatelli pignatelli_...@gva.es Dear all, I have written a small set of modules that have in common certain goals with the bioperl modules Bio::DB::Taxonomy(::flatfile) and Bio::Taxon. The main differences are: + No dependencies of non-standard Perl modules (VS tons of dependencies of bioperl modules) -- This is important in certain (and convenient) environments (like GRID or cloud systems) where you can't rely on automatic installation of big bundles. + NCBI and RDP taxonomies support (VS only NCBI support of bioperl modules) -- I plan to add support for additional taxonomies. + Very fast and low memory footprint (VS general poor performance of the bioperl bundle). Orders of magnitude even for the simplest lookups. + Fast mapping of different identifiers (VS lack of this feature in bioperl) Of course, these modules doesn't compete with Bio::DB::Taxonomy and Bio::Taxon in completeness of methods or integration with other tools (e.g. the rest of the bioperl bundle) but they are very handy (and actually being used by several bioinformatics groups) for fast mapping and large datasets analysis (frequent in bioinformatic analysis). The current (local) name of these modules are Taxonomy, Taxonomy::RDP, Taxonomy::NCBI, Taxonomy::NCBI::Gi2taxid I have been told to put them in CPAN. Their natural location would be under the Bio:: namespace. The bioperl developers don't have any problem with this as long as i) the documentation clearly states that these modules are not bioperl related and ii) the naming is sufficiently distinguishable from existing (bioperl) Taxonomy modules. Bioperl already have a Bio::Taxonomy::* (obsolete) and Bio::DB::Taxonomy::* which makes difficult the naming decision. I have in mind some alternatives like: Bio::Taxonomy::Lite::* Bio::DB::Taxonomy::Lite::* Bio::TaxDB::* Bio::TaxonomyDB::* Bio::TaxLite::* Bio::FastTaxonomy::* I don't know what is your feel about this. Any suggestion would be welcome. Best regards, M; -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Naming a module: Non bioperl related Taxonomy modules
How about putting everything under Bio::Lite::Taxonomy? There are several modules with Lite in the name which are generally meant to be simpler alternatives to other modules, and it sounds like your module is a simplified alternative to bioperl taxonomy modules? On Thu, Nov 4, 2010 at 10:46 AM, Bill Ward b...@wards.net wrote: I think if you put it under Bio:: then people will naturally assume that your modules are bioperl-related. Probably a different top level name is appropriate, maybe something starting with Bio. 2010/11/4 Miguel Pignatelli pignatelli_...@gva.es Dear all, I have written a small set of modules that have in common certain goals with the bioperl modules Bio::DB::Taxonomy(::flatfile) and Bio::Taxon. The main differences are: + No dependencies of non-standard Perl modules (VS tons of dependencies of bioperl modules) -- This is important in certain (and convenient) environments (like GRID or cloud systems) where you can't rely on automatic installation of big bundles. + NCBI and RDP taxonomies support (VS only NCBI support of bioperl modules) -- I plan to add support for additional taxonomies. + Very fast and low memory footprint (VS general poor performance of the bioperl bundle). Orders of magnitude even for the simplest lookups. + Fast mapping of different identifiers (VS lack of this feature in bioperl) Of course, these modules doesn't compete with Bio::DB::Taxonomy and Bio::Taxon in completeness of methods or integration with other tools (e.g. the rest of the bioperl bundle) but they are very handy (and actually being used by several bioinformatics groups) for fast mapping and large datasets analysis (frequent in bioinformatic analysis). The current (local) name of these modules are Taxonomy, Taxonomy::RDP, Taxonomy::NCBI, Taxonomy::NCBI::Gi2taxid I have been told to put them in CPAN. Their natural location would be under the Bio:: namespace. The bioperl developers don't have any problem with this as long as i) the documentation clearly states that these modules are not bioperl related and ii) the naming is sufficiently distinguishable from existing (bioperl) Taxonomy modules. Bioperl already have a Bio::Taxonomy::* (obsolete) and Bio::DB::Taxonomy::* which makes difficult the naming decision. I have in mind some alternatives like: Bio::Taxonomy::Lite::* Bio::DB::Taxonomy::Lite::* Bio::TaxDB::* Bio::TaxonomyDB::* Bio::TaxLite::* Bio::FastTaxonomy::* I don't know what is your feel about this. Any suggestion would be welcome. Best regards, M; -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Module naming - Test::Import::DontRun
On Thu, Oct 7, 2010 at 4:13 PM, Paul Johnson p...@pjcj.net wrote: On Thu, Oct 07, 2010 at 12:36:41PM +0100, Charles Colbourn wrote: Test::Include::DontRun I'll just point out that any name which includes DontRun rather than Don't::Run has sold its soul and should probably start with Com::ReallyBigCorporation::Enterprise:: Then I'll duck (low) and I will run. Yeah, but in Perl 5 the ' has been superseded with :: so you need to use Test::Include::Don::tRun ;-)
Re: my $self = shift
On Sun, Sep 12, 2010 at 2:10 PM, Shawn H Corey shawnhco...@gmail.comwrote:
On 10-09-12 04:58 PM, Aristotle Pagaltzis wrote:
* Shawn H Coreyshawnhco...@gmail.com [2010-09-10 14:30]:
On 10-09-10 03:02 AM, Eric Wilhelm wrote:
sub foo {
my $self = shift;
my $self = shift @_;
Always put the array in the shift.
Why?
Regards,
So you will never have experienced Perl programmers come up to you and ask,
What does this shift do? It doesn't do anything; @_ is not set yet.
Things that behave differently should look different.
If that's your attitude, Perl is probably not the best language for you...
context is everything in Perl.
Re: Please advise before I submit to CPAN
On Fri, Sep 10, 2010 at 1:13 PM, Paul LeoNerd Evans leon...@leonerd.org.ukwrote: On Thu, Sep 09, 2010 at 12:37:43PM -0700, Bill Ward wrote: Yes, but doing so is naughty. Really? Howso? I ask because I do it in a module of mine. http://cpansearch.perl.org/src/PEVANS/IO-Async-0.29/lib/IO/Async/Listener.pm Namely: - # This is a bit naughty but hopefully nobody will mind... bless $handle, IO::Socket if ref( $handle ) eq GLOB; - Even in the comment you admit it's naughty :) but what I meant was taking an object of one type and reblessing it to another. GLOB isn't really an object (well that's debatable, but it's not from GLOB.pm!) so that's kind of a different thing.
Re: Storable Stream - Module namespace help
Does it actually use the Storable format/algorithm or are you using storable in a more generic sense of the word? If the latter, I'd avoid using it in the name of your module to avoid confusion. On Sun, Aug 8, 2010 at 2:58 AM, Marco Neves [ModAuthors] perl-module-auth...@knowhunter.cjb.net wrote: Hello, In need for a way to transfer a large amount of small datastructures I created a module that stores and retrieves a stream of storables in a file. I created it in a private Namespace using in the company I worked for but, with they permission, and because I think this may be useful for someone else, I want to publish it on cpan. I'm finishing documentation and tests, before uploading it to CPAN, but I don't know exactly which namespace to use. For me, the obvious namespace would be Storable::Stream (and eventually Storable::Stream::GZip), but as Storable is part of core, I think we are not expected to publish modules in that namespace. So, which name should I use for this small module? Thanks, mpneves -- Magick Source http://www.magick-source.net -- Magick Source http://www.magick-source.net -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: The CPAN Definitive Tags Spec
On Fri, Aug 6, 2010 at 1:37 PM, Geoffrey Leach ge...@hughes.net wrote: On 08/06/2010 10:58:02 AM, Shlomi Fish wrote: Hi all! Today I converted the Definitive Tags list to a POD-based spec. One can find it inside a Mercurial repository here: http://bitbucket.org/shlomif/rethinking-cpan/src/tip/CPAN-Definitive- Tags/cpan-definitive-tags.pod (Short URL: http://xrl.us/bhvcyb ). Any comments would be welcome. Regards, Shlomi Fish H color me anal, but shouldn't this be an actual POD file, rather than a web page that shows a POD file? I agree. The URL probably should have a .html suffix. -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: pause.perl.org: cert expired
Maybe a few days ago was before the new certificate was installed, and you had told your browser to save the exception for the old one, so you didn't see it before. 2010/5/15 p...@0ne.us p...@0ne.us I swear that a few days ago I got on pause to upload a dist and didn't see that warning then today all of a sudden I see it... Maybe it's just some weirdness on my side :( Burak Gürsoy wrote: -Original Message- From: p...@0ne.us [mailto:p...@0ne.us] Sent: Saturday, May 15, 2010 9:33 PM To: jkee...@cpan.org Cc: module-authors@perl.org Subject: Re: pause.perl.org: cert expired Also, I didn't realize the 2012 apocalypse is upon us already! I thought I had another 2 years to prepare :( However, firefox popped up a notification about untrusted issuer - I assume that was what you saw? It was always like this IIRC. /me wonders how the heck I didn't have the CAcert root cert on my computer... ohwell James E Keenan wrote: pause.perl.org Issued by: CAcert Class 3 Root Expires: May 10, 2012 6:18:36 PM EDT Who should be notified? Thank you very much. Jim Keenan -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Goodbye Perl6::Say
On Thu, Apr 15, 2010 at 1:32 PM, Daniel Staal dst...@usa.net wrote: On Thu, April 15, 2010 4:09 pm, Eric Wilhelm wrote: Honestly, if you're setting up a blank machine next week with less than 5.10, not finding Perl6::Say in the index is going to be the least of your problems anyway. But you should be able to purchase some complaint tokens if you really need them. I believe RedHat still ships with 5.8.8... (Not that I'd run RedHat by choice if Perl were a consideration at all.) I don't know about others. In general the larger and more commercial the vendor the further behind I'd expect them to be. In general I'm for putting in a depreciated warning for some period before final removal of any public API. If run under 5.10 or newer does it actually conflict with the builtin say? I'd say (pun intended) that it should fall through to the builtin if run in a Perl version that has it, and give a warning.
Re: Trimming the CPAN
Also, see if the list of big files correlates to old versions when there are newer versions available -- one large distro with a huge archive of back versions could easily tip the scales. On Thu, Mar 25, 2010 at 11:47 PM, Gabor Szabo szab...@gmail.com wrote: Some people are more space conscious than others. Shlomi, I'd say, prepare a report of 1) the 20 biggest files on CPAN 2) the 20 biggest files on CPAN excluding perl-* releases 3) the 20 packages that take the most space cumulative (all the version on CPAN) 4) Some other report that can measure space usage along with the actual sizes. That might help understanding if there is an issue and what that would be. Gabor -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Module uploaded - whats next?
On Fri, Dec 4, 2009 at 10:41 AM, Arthur Corliss corl...@digitalmages.com wrote: On Fri, 4 Dec 2009, Dave Rolsky wrote: The idea that you couldn't learn the basics of Catalyst and get things running in the same time seems unlikely. Also, you haven't factored in all the time it's going to take you to add features and fix bugs already present/fixed in an existing tool. I have no interest in any possible outcome of this discussion, but I have to throw out a small tangential comment: as someone who has to support a Catalyst deployment I'd like to know if anyone here has unrolled the ridiculously long list of dependencies necessary for Catalyst?! As a fellow dev I struggle often with trying to achieve the balance between not reinventing the wheel and not including the wheel that has its own tractor trailer attached towing a mobile factory. And as a fellow admin as well I may have to err towards a framework that provides the core functionality I need with the least number of moving parts. Yep, that's why I didn't use Catalyst and would never suggest it to anyone... it's an IT nightmare. Let the guy introduce another framework. None of the existing frameworks are void of any sizeable Cons. Amen. -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Problems with Date::Manip
I haven't taken a look any deeper than reading this email but the first thing that jumps to mind would be something to do with list vs. scalar context... perhaps the new Date::Manip is returning a list, and you're assigning it to a scalar? On Tue, Nov 24, 2009 at 10:49 AM, Rene Schickbauer rene.schickba...@gmail.com wrote: Hi! Installed another linux box today and installed my usual set of modules. There was a problem with Date::Manip (installed a 6.xx version) The function UnixDate now returns 1 instead of the correct date. When i copied an older 5.xx version to that box, everything worked again. Date::Manip::Migration5to6 doesn't mention anything related to UnixDate(), and the function description didn't change either as far as i can tell. The code i use is something like this: use Date::Manip qw(Date_Init UnixDate); Date_Init(TZ=CET); my $datestring = UnixDate(last friday in june 2009, %Y-%m-%d); The whole kaboodle is a bit more complex, but im fairly certain that are the offending lines. LG Rene P.S.: If you need the complete code that fails, it's in Maplat::Helpers::DateStrings -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Weekend entertainment
On Tue, Nov 17, 2009 at 5:09 AM, Robin Berjon ro...@berjon.com wrote: On Nov 15, 2009, at 18:45 , David Golden wrote: E.g. from his site today: You might be a redneck if your Christmas ornaments are made out of spent shot-gun shells. (And maybe I'm guilty of stereotyping, but I suspect that Jörg Walter is not a Nigerian spammer.) Since I was in the same (chat) room when this module was birthed many years ago, I can vouch for Jörg that he certainly didn't mean to offend. I'll note that the module is called NIGERIAN, not Nigerian; I would have thought PERL programmers might pick up on that. I don't think the complainer is a Perl programmer. And I think there are plenty of Perl programmers out there who might overlook that subtlety of the humor. It would be better if the name mentioned spam or 419 or something, I guess?
Re: Term::Info - takeover
Oh, sorry. On Thu, Sep 24, 2009 at 9:18 PM, Fayland Lam fayl...@gmail.com wrote: I think you forget to CC the list. :) -- Forwarded message -- From: Bill Ward b...@wards.net Date: Fri, Sep 25, 2009 at 11:58 AM Subject: Re: Term::Info - takeover To: Fayland Lam fayl...@gmail.com I think if you're going to extend the existing module (radically improving it, it sounds like, but keeping backward compatibility) then I'd say follow those instructions to take over the module. But if you're doing something new that doesn't just extend what's already there, it would be better to use a new name. Term::Terminfo might be good, since terminfo is the name of the database you're supporting. On Thu, Sep 24, 2009 at 7:33 PM, Fayland Lam fayl...@gmail.com wrote: I suggest that you should use another package name, that's the easiest way to do. or else, you need follow the instruction of http://www.cpan.org/misc/cpan-faq.html#How_adopt_module that would take a month or two. Thanks Jonathan Yu wrote: On Thu, Sep 24, 2009 at 4:43 PM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: I notice that Term::Info was released in 1999, has no documentation, no testing, only wraps Tput, and is generally not all that useful. I'm planning to write a proper terminfo wrapping module anyway, and this seems an ideal name to give it. CPANTS claims nothing is using it: http://cpants.perl.org/dist/used_by/Term-Info If I were to create another one which is more useful, providing more access to terminfo information, how might I go about creating a release of it? I trust you know that releasing under the same name would be marked as an unauthorized release by the indexer, unless you manage to convince the original author or the PAUSE Admins to grant you that namespace. I suggest you first name the module something like, Term::Info::More to indicate that it is Term::Info with some additional features. Then you can petition for the Term::Info namespace if you so choose, at a later date, though that probably won't be necessary or desired. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ -- Fayland Lam // http://www.fayland.org/ -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward -- Fayland Lam // http://www.fayland.org/ -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: how to set $VERSION throughout distribution
Subversion is more like mercurial/git in that sense - versions go by changesets rather than individual files. On Sun, Sep 13, 2009 at 6:48 PM, Dana Hudes dhu...@hudes.org wrote: Quite simply you are stuck in the concept of tracking files a la sccs/rcs/cvs/svn. 3rd generation VCS doesn't track files but rather change sets. This is what you are attempting to do manually by setting $VERSION There are rcs/cvs/svn migration tools for mercurial and git. Mercurial additionally has git to mercurial migration support. --Original Message-- From: David Golden To: Jonas Brømsø Nielsen Cc: dhu...@hudes.org Cc: module-authors@perl.org Sent: Sep 13, 2009 8:19 AM Subject: Re: how to set $VERSION throughout distribution On Sun, Sep 13, 2009 at 7:50 AM, Jonas Brømsø Nielsen jona...@gmail.com wrote: I learned one lesson based on feedback from a user and that was that the distribution number should be reflected in the main package identified by the build file an example from Workflow: dist_name = 'Workflow', dist_version_from = 'lib/Workflow.pm', That's a great point. I wrote a short article defining what I call a well-formed distribution -- where the distribution name is the same as a module name (with appropriate :: mangling) and the distribution version is the same as the $VERSION of the package of the same name. http://www.dagolden.com/index.php/308/packages-modules-and-distributions/ Personally, I'm of the school of setting all $VERSION the same so that they clearly indicate which *distribution* they came from. While I don't use it personally (I have my own tools/workflow), the perl-reversion script in Perl-Version makes this easy. Unfortunately, it's in the examples folder, so it isn't installed by default. http://cpansearch.perl.org/src/ANDYA/Perl-Version-1.009/examples/perl-reversion -- David Sent from my BlackBerry® smartphone with Nextel Direct Connect -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: gentle nudgings about upgrading your tools
On Fri, Aug 28, 2009 at 9:02 AM, Eric Wilhelmenoba...@gmail.com wrote: # from David Cantrell # on Friday 28 August 2009 04:10: I guess maybe. It still seems arbitrary, and my point was that it is a workaround to the fact that it's currently difficult for a module to do the right thing to even compare its version against the index. I'd restrict it to only those modules that are needed to install stuff: CPAN.pm ExtUtils::MakeMaker Module::Build CPANPLUS We've already solved the 'install-side' need with configure_requires. I was talking about the `./Build dist` (author) side of things (from the observation that the OP had run into a bug which would have been avoided by upgrading M::B before rolling a dist.) Authors using an old Module::Build won't be releasing dists with M::B in configure_requires until they upgrade. That might happen automatically if they install some new code from the CPAN which has M::B in its configure_requires, but that's a combination of happy accidents. And, if we were to pretend that M::B author tools were split off into a separate distribution, having CPAN.pm warn you about a new M::B wouldn't do any good, plus people would be confused when their `./Build dist` suddenly started complaining about needing to install something extra (which brings me back to the bit about users setting a preference about which CPAN client to use.) Can PAUSE detect the version of M::B or EU::MM that the author used, and warn accordingly or even reject it?
Re: XML::Rules new versions not seen by CPAN shell
Do I understand this right? If a tar file contains a directory with permissions 777 - as would be likely to happen if it was made on Windows - then PAUSE rejects it? Why doesn't PAUSE just modify the permissions in the tarfile and publish the resulting file?
Re: Suggested module name
That name works for me. I trust you have sub-classes for each OS and/or window manager you support? On Fri, Jul 10, 2009 at 12:18 AM, Ivan Wills ivan.wi...@gmail.com wrote: Hi, I have a new module that provides a simple way to run functions when the screen saver starts/stops (X11 or Gnome Screen saver only currently). I'm not sure what to call it currently it is tentatively call Event::ScreenSaverhttp://github.com/ivanwills/Event-ScreenSaver/tree/masterbut I'm not sure if this is the best name. Thanks, Ivan Wills PS If you are wondering what this may be used for one example is pausing your music player when the screen saver starts then resuming it when the screen saver stops. Another example is running perl smoke tests while the screen save is running and stopping it again when the screen saver stops -- email/jabber: ivan.wi...@gmail.com / / _ _ / \ / | | | | /\/ \_| | | -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: module/script to clean up old files and prune empty directories
File::Find can be used to write such a script, but doesn't by itself address this issue. On Tue, Jun 30, 2009 at 6:15 PM, Dana Hudes dhu...@hudes.org wrote: File::Find::Perl --Original Message-- From: Jonathan Swartz To: module-authors@perl.org Sent: Jun 30, 2009 7:59 PM Subject: module/script to clean up old files and prune empty directories At various places around our system we want to clean up files older than x, and sometimes prune empty directories. Naturally we have to be careful doing this lest we accidentally blow away far too many of the wrong files. I'm thinking about a Perl module and accompanying script with this interface: cleanup_files.pl --age=age --dir=dir --name=name [--dry-run] [-- prune-empty-dirs] where age can be specified as 1h, 2day, etc., and name is a required glob pattern, and dir is checked to make sure it is sufficiently deep (e.g. can't use /). --dry-run tells you what would be deleted. --prune-empty-dirs also causes empty dirs to be pruned. The script would report at its end how many files and directories were removed. The idea is to have a convenient, but safe, one-liner to put in a cron for each directory that needs periodic cleaning. In the past we've done the old find ... | xargs rm -f, but it doesn't have the safety checks, directory pruning, or reporting. Does anyone else think this is (mildly) valuable? Am I reinventing the wheel, in terms of Perl libraries or other Unix utilities besides basic find? Thanks Jon Sent from my BlackBerry® smartphone with Nextel Direct Connect -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: module/script to clean up old files and prune empty directories
I want it, whether it is already extant or you write it... On Tue, Jun 30, 2009 at 4:59 PM, Jonathan Swartz swa...@pobox.com wrote: At various places around our system we want to clean up files older than x, and sometimes prune empty directories. Naturally we have to be careful doing this lest we accidentally blow away far too many of the wrong files. I'm thinking about a Perl module and accompanying script with this interface: cleanup_files.pl --age=age --dir=dir --name=name [--dry-run] [--prune-empty-dirs] where age can be specified as 1h, 2day, etc., and name is a required glob pattern, and dir is checked to make sure it is sufficiently deep (e.g. can't use /). --dry-run tells you what would be deleted. --prune-empty-dirs also causes empty dirs to be pruned. The script would report at its end how many files and directories were removed. The idea is to have a convenient, but safe, one-liner to put in a cron for each directory that needs periodic cleaning. In the past we've done the old find ... | xargs rm -f, but it doesn't have the safety checks, directory pruning, or reporting. Does anyone else think this is (mildly) valuable? Am I reinventing the wheel, in terms of Perl libraries or other Unix utilities besides basic find? Thanks Jon -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
lexical warnings question
In the perllexwarn man page, it states that the scope of the warning
pragma is limited to the enclosing block. It also means that the
pragma setting will not leak across files (via use, require or do).
This allows authors to independently define the degree of warning
checks that will be applied to their module.
I'm more interested (at $JOB) in global warnings, actually. Of course
one can enable those with $^W or perl -w and I do, but developers
ignore the warnings all too often. Many of our core modules were
written without warnings enabled, and people are slow to fix those
warnings. So, we want to make warnings fatal in the development
environment to force developers to fix those niggling uninitialized
value warnings that are all over the place in our log files.
We can do this in a lexical way with the FATAL option to warnings.pm,
but that would only affect one file, and we don't want to have to
modify every file in our code base to do this. And since we want it
to be enabled only in the development environment, it would have to be
some kind of ternary operator conditional testing an environment
variable and only setting fatal if that indicates debug mode.
So, do I need to monkey with $SIG{__DIE__} or something? I haven't
yet tried peeling back the covers of warnings.pm to see if there's
some way I can enable FATAL globally... before I did that I thought
I'd ask if anyone here has done it.
--
Check out my LEGO blog at http://www.brickpile.com/
View my photos at http://flickr.com/photos/billward/
Follow me at http://twitter.com/williamward
Re: lexical warnings question
On Tue, Jun 16, 2009 at 2:43 PM, Hans Dieter
Pearceyhdp.perl.module-auth...@weftsoar.net wrote:
On Tue, Jun 16, 2009 at 02:39:21PM -0700, Bill Ward wrote:
So, do I need to monkey with $SIG{__DIE__} or something?
$SIG{__WARN__} = sub { die @_ };
Apply more advanced filtering to @_ as desired.
Arg, I meant to say $SIG{__WARN__} when I wrote the original
message... sorry. I was hoping to avoid that, since I think we are
already messing around with %SIG in our applications too much as it
is.
Re: lexical warnings question
On Tue, Jun 16, 2009 at 3:01 PM, Hans Dieter
Pearceyhdp.perl.module-auth...@weftsoar.net wrote:
On Tue, Jun 16, 2009 at 02:49:36PM -0700, Bill Ward wrote:
Arg, I meant to say $SIG{__WARN__} when I wrote the original
message... sorry. I was hoping to avoid that, since I think we are
already messing around with %SIG in our applications too much as it
is.
What would doing *anything* with other keys of %SIG have to do with it? Or
did
you mean that you're already using $SIG{__WARN__}, and overriding or wrapping
it again would be painful?
I know we're doing all kinds of crazy stuff to __DIE__ and I'm not
sure about __WARN__ but I suspect we may be.
__WARN__ and __DIE__ are not my favorite tools ever, but a situation like this
(where you aren't going to be trying to pick up after the handler's done)
isn't
egregious.
Also, I don't think you're going to find anything better without requiring
that
all your packages import warnings FATAL = 'all', either directly or through
some intermediary module (see e.g. Modern::Perl for how to do this).
I'll look into Modern::Perl, thanks
--
Check out my LEGO blog at http://www.brickpile.com/
View my photos at http://flickr.com/photos/billward/
Follow me at http://twitter.com/williamward
Re: lexical warnings question
On Tue, Jun 16, 2009 at 4:14 PM,
Ovidpubliustemp-moduleautho...@yahoo.com wrote:
- Original Message
From: Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net
On Tue, Jun 16, 2009 at 02:39:21PM -0700, Bill Ward wrote:
So, do I need to monkey with $SIG{__DIE__} or something?
$SIG{__WARN__} = sub { die @_ };
Apply more advanced filtering to @_ as desired.
Just a quick ack through most of my CPAN modules shows that messing with
__WARN__ is very hit-and-miss.
ack __WARN__ /opt/local/lib/perl5/site_perl/5.8.8/
Yeah, I am leery of it.
I like the Modern::Perl idea. I'm going to see if there's some way I
can do what it does.
Re: Module::Build + documenation woes
On Thu, Jun 11, 2009 at 3:46 AM, Ovid publiustemp-moduleautho...@yahoo.comwrote: What would be nice if if the main documentation ( http://search.cpan.org/dist/Module-Build/lib/Module/Build.pm) had, right at the top, sample Build.PL code in the synopsis. After that, maybe a few optional configurations or recommended Build.PL files. For example, here's a sample Build.PL that I'm using and the various features are ones that I learned from mailing lists because I get lost in the docs :) [...] I suspect, but can't prove, that many potential Module::Build users have the same issues. They just want to know how to write a useful Build.PL. Maybe after that a quick example of how to extend it to, say, set up a test database or some other build action. Then and only then go into the mind-numbing detail about every single bell and whistle that Module::Build provides :) +1. If you really want people to adopt Module::Build, change the h2xs script so it generates something like the above... (kidding - does anyone still use h2xs to start a non-xs module?)
Re: Process for Removing Qt Module from CPAN
It also makes it easier to inherit the constructor when subclassing the module. I would suggest that Perl modules should be done the Perl way, rather than by importing ideas from other languages. On Tue, May 26, 2009 at 11:22 AM, Jonathan Yu jonathan.i...@gmail.comwrote: Chris: I'm not sure if that's the most desirable behaviour, as it differs from the rest of the Perl world... Also, one useful thing is that if you want to create an object of something in Perl you could do: my $foo = Foo::Bar-new(); my $bar = $foo-new(); Which would create a $bar of the same type as $foo. You lose this by dropping the -new part. I'm sure there's other very good reasons as to why those sorts of constructors are a bad idea. Jonathan On Tue, May 26, 2009 at 2:20 PM, Chris Burel chrisbu...@gmail.com wrote: No, Check out this document from Germain Garand wrote for PerlQt3: http://web.mit.edu/perlqt_v3.009/www/index.html#anatomy_of_perlqt Syntax elements summary : 1. All Qt classes are accessed through the prefix Qt::, which replaces the initial Q of Qt classes. When browsing the Qt documentation, you simply need to change the name of classes so that QFoo reads Qt::Foo. 2. An object is created by calling the constructor of the class. It has the same name as the class itself. You don't need to say new Qt::Foo or Qt::Foo-new() as most Perl programmers would have expected. Instead, you just say : my $object = Qt::classname(arg_1, ..., arg_n); If you don't need to pass any argument to the constructor, simply say : my $object = Qt::classname; On Tue, May 26, 2009 at 11:13 AM, Jonathan Yu jonathan.i...@gmail.com wrote: On Tue, May 26, 2009 at 2:08 PM, Chris Burel chrisbu...@gmail.com wrote: It's currently neither. Right now it looks like this: use Qt; my $app = Qt::Application(\...@argv); my $hello = Qt::PushButton(Hello world!); I'm guessing you meant to say Qt::PushButton-new(...) :-) $hello-show(); etc. Which I realize is a problem. On Tue, May 26, 2009 at 11:00 AM, Jonathan Yu jonathan.i...@gmail.com wrote: Chris: Is it Qt4::Application or QApplication (as it was in Qt - ie version 1?) On Tue, May 26, 2009 at 1:59 PM, Chris Burel chrisbu...@gmail.com wrote: And really, what's wrong with Qt4::Application-new()? I've been modeling the Qt4 bindings off the Qt3 ones that Ashley and Germain wrote. And that's how it works in 3, so I kept it. -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Process for Removing Qt Module from CPAN
On Tue, May 26, 2009 at 2:59 PM, Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net wrote: On Tue, May 26, 2009 at 05:56:10PM -0400, Daniel Staal wrote: --As of May 26, 2009 12:33:08 PM -0700, Bill Ward is alleged to have said: How would you feel about ref($foo)-new(); --As for the rest, it is mine. As a clone? Off the top of my head, I can't see what's that doing. A bit of thinking (and reading) about ref() makes it understandable, if not clean. No, as a way of creating a new object in the same class as an existing object. The suggestion for a method that clones was $obj-clone. $foo-new() makes a new object of the same type as $foo. I suggested ref($foo) as a more explicit alternative, rather like saying $count = scalar(@array) instead of just $count = @array to get the number of elements explicitly rather than implicitly. Kind of like a (cast) in C.
Help needed testing security of login module
Over the years I've developed my own private Perl web login module. It takes a username or email address and password, checks it against the database, and creates the cookies. It has a 'forgot my password' option which is reasonably secure (of course it assumes that the email address of record is secure, but that's unavoidable). It uses MD5 to store passwords so there's no plaintext option, and I think it's secure enough for most Web apps. I wrote the initial code many years ago and have been tweaking it and adapting it but never released it as its own module, which I'd like to finally get around to doing. But I'm afraid I may have missed a spot security-wise and would like someone who's a little more of an expert in that area to see if they can find any holes in its design or implementation that would be unacceptable. Any takers?
Re: Help needed testing security of login module
On Wed, May 20, 2009 at 2:55 PM, Jonathan Yu jonathan.i...@gmail.comwrote: Bill: To clarify why a salt is necessary, consider the classic time-space tradeoff. Let's say I know that your password is exactly 8 characters long and I know all of the possible characters it could be. So let's say it's alphanumeric (a-z, A-Z, 0-9, hyphen, period, underscore) - that's 26+26+10+3 = 65 possible combinations per character. Then you'd only have to generate a hash 65^8 = 318644812890625 times, which for faster computers these days shouldn't take too long. Still, it takes a lot of time, so you can store it all in a database (ie, Rainbow Table). So if you map a bunch of arbitrary plaintexts and calculate their hash, you can look up the hash and figure out what text was used to generate that hash. Thus, you've either figured out the password or an MD5 collision thereof; in either case, you'll be able to log in. There are web sites that specialize in that sort of thing. So having a 2-byte salt can really help stop those attacks, or at least make the amount of space needed infeasible (since every different 2 character salt will require you to generate an entirely different rainbow table). For most uses it's probably unnecessary, however, if you can harden security with just a few extra lines of code, why not? Yeah, but how would you get the MD5 hash without already having access to the database behind the web site, in which case the farm has already been given away? Still, it's not hard to add.
Re: Help needed testing security of login module
The passwords are stored in a database table, not a file, so that exact scenario won't work. But one could easily imagine some SQL injection attack or something like that making the passwords visible - which is a big reason I store them as MD5 hash values rather than plaintext. It certainly wouldn't be much work to add a salt, so no reason not to. On Wed, May 20, 2009 at 3:07 PM, Jonathan Yu jonathan.i...@gmail.comwrote: Bill: Perhaps there is a vulnerability in something else, like a PHP script you use to show source code, that allows attackers to get the file. You want to make sure the file is useless to people, even if they have it, which I think is the worst-case scenario. They might not be able to download all files this way, as the program might be restricted to showing ASCII files; so they will be able to view your password file but not, say, the binary files stored on your server in the passworded area that they want to get to. Never hurts to fix those things, really. It doesn't negatively impact performance in a noticeable way, and the security benefits dramatically outweigh the costs. Cheers, Jonathan On Wed, May 20, 2009 at 6:05 PM, Bill Ward b...@wards.net wrote: On Wed, May 20, 2009 at 2:55 PM, Jonathan Yu jonathan.i...@gmail.com wrote: Bill: To clarify why a salt is necessary, consider the classic time-space tradeoff. Let's say I know that your password is exactly 8 characters long and I know all of the possible characters it could be. So let's say it's alphanumeric (a-z, A-Z, 0-9, hyphen, period, underscore) - that's 26+26+10+3 = 65 possible combinations per character. Then you'd only have to generate a hash 65^8 = 318644812890625 times, which for faster computers these days shouldn't take too long. Still, it takes a lot of time, so you can store it all in a database (ie, Rainbow Table). So if you map a bunch of arbitrary plaintexts and calculate their hash, you can look up the hash and figure out what text was used to generate that hash. Thus, you've either figured out the password or an MD5 collision thereof; in either case, you'll be able to log in. There are web sites that specialize in that sort of thing. So having a 2-byte salt can really help stop those attacks, or at least make the amount of space needed infeasible (since every different 2 character salt will require you to generate an entirely different rainbow table). For most uses it's probably unnecessary, however, if you can harden security with just a few extra lines of code, why not? Yeah, but how would you get the MD5 hash without already having access to the database behind the web site, in which case the farm has already been given away? Still, it's not hard to add. -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Help Needed in Sorting and Updating the List of Perl Mailing Lists
On Mon, May 11, 2009 at 3:47 PM, Elaine Ashton eash...@mac.com wrote: On May 11, 2009, at 6:37 PM, David Golden wrote: I don't object to you being busy -- it happens to all of us -- but blaming others for not trying hard enough is absurd. You probably aren't in the middle of a trans-con move, starting a new job, etc in addition to the baby. I mean, sure, why shouldn't I have spent what precious little time I had to myself scanning all the perl mailing lists for people suddenly taking an interest in stuff I did years ago? That's what my husband is for. I'm getting old and in a community as generally thankless as this one is, you'll have to try a little harder at guilting me over really being too busy at the time to have noticed. My name was mentioned and my husband is also pretty easy to find. Again, people just tend to complain as it's easier than focusing on the solution. If someone wants the data, I've offered the tables. If you have a better site, it can be hosted where the old one is or I'm sure we reassign the DNS. It's really not worth looking at my date book for how I spent my time in early 2007. I think the blame game is silly here - we should be looking for solutions moving forward, not who's fault things are. The best thing to do now, IMHO, would be to either change the hosting or keep it where it is but grant access to let others help maintain it. Is that an option you'd consider?
Re: Arguments checker module
Do you mean Parse::Method::Signatures ? On Tue, May 5, 2009 at 10:54 PM, breno oainikus...@gmail.com wrote: On Wed, May 6, 2009 at 12:04 AM, Bill Ward b...@wards.net wrote: Params::Validate has the right features, but I really don't like the verbosity of its configuration. I was hoping for something more like the Perl prototyping or Getopt::Long syntax. Maybe I'll write a wrapper around Params::Validate? Have you looked at Method::Signatures? -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Arguments checker module
On Tue, May 5, 2009 at 11:48 PM, breno oainikus...@gmail.com wrote: On Wed, May 6, 2009 at 2:59 AM, Bill Ward b...@wards.net wrote: Do you mean Parse::Method::Signatures ? No, I mean http://search.cpan.org/perldoc?Method::Signatures http://www.slideshare.net/schwern/methodsignatures-presentation I haven't looked at it much, but it seems to fill most of your needs (not tied to Moose, usable from within methods with a prototype-like interface). Although it doesn't seem to perform much of a validation (except for types and traits, I guess), you probably could extend it with callbacks and regexp the same way Params::Validate does (although, since you complained about its verbosity, it appears to not be the case). It has two deal-breakers for me: 1. Same problem as Moose - it changes the language too much for my taste. I don't see what all the fuss is about declaring $self. 2. Not robust enough - big alpha software warnings are a huge turn-off to me.
Re: Arguments checker module
On Wed, May 6, 2009 at 6:38 AM, Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net wrote: On Wed, May 06, 2009 at 07:10:49AM -0400, David Golden wrote: I don't think he deserves public scorn in response to a reasonable question and reasonable objections to suggestions. I agree about the public scorn, but I disagree that Perl 5's OO is fine is reasonable. It's horrible; we just all forget that because we're used to it and know it inside and out. Thanks guys for sticking up for me. I am just old-fashioned, I guess; for better or for worse, I'm not interested in changing/fixing Perl itself, just in finding writing reusable code that meets my needs without adding stuff that doesn't.
Re: Arguments checker module
On Wed, May 6, 2009 at 10:42 AM, Jonathan Leto jal...@gmail.com wrote: Howdy, Thanks guys for sticking up for me. I am just old-fashioned, I guess; for better or for worse, I'm not interested in changing/fixing Perl itself, just in finding writing reusable code that meets my needs without adding stuff that doesn't. Wow, I was taken aback when I read not interested in changing/fixing Perl itself. Ever heard of technical debt? You can feel it every time you type my ($self) = @_. Also, Perl 5 doesn't have OO, it has blessed scalars. Just sayin' ;). If you want to maximize your code reuse, I suggest drinking the Moose Koolaid and learning about roles [1]. Chromatic has a pretty nice description [2] and hdp gave a nice description of them at a recent PDX.pm [3]. There are a couple of big problems with adopting Moose or one of the similar redesigns of Perl OO. 1. Not every module you're using will be Moose-based, so if you're working on one of those, you'll need to remember to switch back and forth. It's bad enough having both (Perl's approximation of) OO and procedural calls. 2. If we bring someone new onto the team we'd have to train them not just in Perl, but in Moose as well. There are tons of books and online resources for Perl, but only Moose's own documentation for that. All the examples, code snippets, books, and howtos that people might want to use would have to be adapted to fit into a Moose framework. 3. If I am going to change languages, I'd rather switch to Ruby or Python.
Re: Arguments checker module
On Wed, May 6, 2009 at 3:54 PM, Paul LeoNerd Evans leon...@leonerd.org.ukwrote: On Wed, 6 May 2009 11:27:05 -0700 Bill Ward b...@wards.net wrote: (Perl's approximation of) OO I've often seen this one bandied about, and I can't say I agree with it. Neither do I, but I threw the parenthetical in to placate the person to whom I was replying. Perl's the only language I've done OO programming in for about 16 years so I'm quite happy with it the way it is.
Re: Puzzling error from cpan testers
On Tue, May 5, 2009 at 6:02 AM, David Cantrell da...@cantrell.org.ukwrote: On Sun, May 03, 2009 at 12:23:27PM -0700, Bill Ward wrote: On Sun, May 3, 2009 at 12:18 PM, Andy Armstrong a...@hexten.net wrote: On 3 May 2009, at 20:07, Bill Ward wrote: For my module Number::Format I am getting a strange result from cpan testers that I can't replicate. See this error report... http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3560533.html [...]Since it's using '==' it shouldn't be possible to get those errors, right? Anyone have any thoughts? Yeah, that's floating point. There can be a difference between the two values that's too small to display but big enough to make them non-equal. '==' is /always/ risky with FP values. You should instead check for the value being within an acceptable range. Do you think I should change it to use eq in the test? It may work, or it may not. If it works - in the sense of making the test failure go away - then I would expect it to bite someone later when they just happen to hit upon a number where the floating point rounding error goes the other way. Check that it's in an acceptable range. Perhaps I should stringify and then re-numberify the value inside round() instead?
Re: Puzzling error from cpan testers
Thanks David. This is a nice module, but overkill for my needs and I'd rather not make people install more CPAN modules than they have to. Looks like the key thing is this line: $ok = abs($p - $q) $epsilon; I'll incorporate that bit into my test suite for Number::Format. On Tue, May 5, 2009 at 12:05 PM, David Golden xda...@gmail.com wrote: On Tue, May 5, 2009 at 2:58 PM, Jonathan Leto jal...@gmail.com wrote: I very much recommend that you look at is_similar() in Math::GSL::Test, it has implemented at least a few wheels that you are destined to want: Yikes. You must have missed Test::Number::Delta when you were writing that. On CPAN since 2005. I originally called it Test::Float and got argued into a proper hierarchical name, which is probably why no one seems to know it exists. Synopsis: # Import test functions use Test::Number::Delta; # Equality test with default tolerance delta_ok( 1e-5, 2e-5, 'values within 1e-6'); # Inequality test with default tolerance delta_not_ok( 1e-5, 2e-5, 'values not within 1e-6'); # Provide specific tolerance delta_within( 1e-3, 2e-3, 1e-4, 'values within 1e-4'); delta_not_within( 1e-3, 2e-3, 1e-4, 'values not within 1e-4'); # Compare arrays or matrices @a = ( 3.14, 1.41 ); @b = ( 3.15, 1.41 ); delta_ok( \...@a, \...@b, 'compare @a and @b' ); # Set a different default tolerance use Test::Number::Delta within = 1e-5; delta_ok( 1.1e-5, 2e-5, 'values within 1e-5'); # ok # Set a relative tolerance use Test::Number::Delta relative = 1e-3; delta_ok( 1.01, 1.0099, 'values within 1.01e-3'); -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Dual-Build Modules (What to do if both Makefile.PL and Build.PL exist)
The way I've interpreted that in my own auto-build scripting is that if Build.PL exists, the module author is probably a Module::Build user who is only providing a Makefile.PL grudgingly for the sake of those who haven't installed Module::Build, and thus I figure that if there's any difference between the two .PL files, probably Build.PL is the one the author is more invested in. On Tue, May 5, 2009 at 7:06 PM, Jonathan Yu jonathan.i...@gmail.com wrote: Hi wise Perl authors: I've been building some Perl packages for Debian. I've noticed in the course of this that dh-make-perl (our preferred script for transforming Perl distributions into Debian packages) prefers Makefile.PL over Build.PL. One problem this has caused is that a Makefile is created which is not removed when 'perl Build clean' is run. Now, Makefile.PL via Module::Build::Compat actually runs Build.PL the first time, so the Makefile expects 'Build' to already exist. The next time the module is built, 'make' is run, which in turn triggers 'perl Build', but this no longer works since Build.PL has not been run yet (so there is no Build). The real question at hand here is: for modules that provide both a Makefile.PL and Build.PL, which should be preferred? More than that, from the perspective of CPAN authors, is it even useful to provide both? Now that Module::Build is a core module, maybe only a Build.PL should be included. Add to this some complication from Module::Install, which also uses Makefile.PL. So in that case maybe Makefile.PL is preferred (for Module::Install to do its thing) rather than Build.PL. (On the other hand, I don't think I've seen modules that mix both M::I and M::B, so in the wild this will probably not be a problem) What does everyone else think? I look forward to reading what other authors have to say about this. Cheers, Jonathan -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Arguments checker module
Is anyone aware of any modules that will check subroutine arguments? I can think of two similar features of Perl, but neither is quite right: 1. Prototypes (perlsyn) - put something like ($$@) after your subroutine declaration - but doesn't work for object methods and a few other cases. Plus, doesn't give you the ability to name the arguments and doesn't support argument-based overloading. 2. Getopt::Long - check for argument value types, illegal arguments, etc. - but doesn't allow for mandatory options (sounds like an oxymoron, but very common when passing arguments in a hash form to a subroutine) or validating nested data structures. I'm often having to add a half dozen lines of code to every subroutine to perform argument validation and I'd like to offload it once and for all into a CPAN module. Has anyone written or seen such a beast? I haven't, so I've started writing it... but then, what to call it? My working title is ArgsChecker.pm but it should be put into a hierarchy - Data:: perhaps? -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Arguments checker module
On Tue, May 5, 2009 at 7:55 PM, Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net wrote: On Tue, May 05, 2009 at 07:51:09PM -0700, Bill Ward wrote: I'm often having to add a half dozen lines of code to every subroutine to perform argument validation and I'd like to offload it once and for all into a CPAN module. Has anyone written or seen such a beast? I haven't, so I've started writing it... but then, what to call it? My working title is ArgsChecker.pm but it should be put into a hierarchy - Data:: perhaps? Params::Validate does everything but nested data structures. Declare::Constraints::Simple does everything. Data::FormValidator does everything. MooseX::Types does everything and does it best. There are a lot more of these. I'm surprised you haven't seen them on CPAN. Thanks for the recommendations. I didn't think to look under any of those names.
Re: Arguments checker module
On Tue, May 5, 2009 at 7:55 PM, Dave Rolsky auta...@urth.org wrote: On Tue, 5 May 2009, Bill Ward wrote: I'm often having to add a half dozen lines of code to every subroutine to perform argument validation and I'd like to offload it once and for all into a CPAN module. Has anyone written or seen such a beast? I haven't, so I've started writing it... but then, what to call it? My working title is ArgsChecker.pm but it should be put into a hierarchy - Data:: perhaps? Please don't write yet another one. I will if none of them meet my needs. Params::Validate Params::Util (sort of a validator) Moose + MooseX::Params::Validate MooseX::Method::Signatures Perl6::Signature and probably five dozen more. Thanks for the suggestions. I'm not interested in being locked-in to a framework like Moose, so I won't even consider those. Params::Validate has the right features, but I really don't like the verbosity of its configuration. I was hoping for something more like the Perl prototyping or Getopt::Long syntax. Maybe I'll write a wrapper around Params::Validate?
Re: Arguments checker module
On Tue, May 5, 2009 at 8:27 PM, Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net wrote: On Tue, May 05, 2009 at 08:04:35PM -0700, Bill Ward wrote: I'm not interested in being locked-in to a framework like Moose, so I won't even consider those. http://search.cpan.org/~drolsky/Moose-0.77/lib/Moose/Util/TypeConstraints.pm#Use_with_Other_Constraint_Moduleshttp://search.cpan.org/%7Edrolsky/Moose-0.77/lib/Moose/Util/TypeConstraints.pm#Use_with_Other_Constraint_Modules Moose's type constraints subsume pretty much anything else. What's the lock-in you're worried about? Just a philosophical objection to frameworks. I like Perl's OO the way it is, thanks. Params::Validate has the right features, but I really don't like the verbosity of its configuration. I was hoping for something more like the Perl prototyping or Getopt::Long syntax. Maybe I'll write a wrapper around Params::Validate? I did that once, if it helps. http://search.cpan.org/~hdp/Params-Validate-Micro-0.032/lib/Params/Validate/Micro.pmhttp://search.cpan.org/%7Ehdp/Params-Validate-Micro-0.032/lib/Params/Validate/Micro.pm I'll take a look at that. -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Puzzling error from cpan testers
For my module Number::Format I am getting a strange result from cpan testers that I can't replicate. See this error report... http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3560533.html # Failed test 'pi with precision=6' # at t/round.t line 18. # got: 3.141593 # expected: 3.141593 # Failed test 'precision=-2' # at t/round.t line 24. # got: 123500 # expected: 123500 # Looks like you failed 2 tests of 16. t/round.t Here are the test cases in question: cmp_ok(round(PI,6), '==', 3.141593, 'pi with precision=6'); cmp_ok(round(123456.78951, -2), '==', 123500, 'precision=-2' ); Since it's using '==' it shouldn't be possible to get those errors, right? Anyone have any thoughts?
Re: Puzzling error from cpan testers
On Sun, May 3, 2009 at 12:18 PM, Andy Armstrong a...@hexten.net wrote: On 3 May 2009, at 20:07, Bill Ward wrote: For my module Number::Format I am getting a strange result from cpan testers that I can't replicate. See this error report... http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3560533.html [...]Since it's using '==' it shouldn't be possible to get those errors, right? Anyone have any thoughts? Yeah, that's floating point. There can be a difference between the two values that's too small to display but big enough to make them non-equal. '==' is /always/ risky with FP values. You should instead check for the value being within an acceptable range. Do you think I should change it to use eq in the test?
Re: Configuration files and ExtUtils::MakeMaker
For this kind of thing I usually copy the Config.pm generated by Perl or the CPAN::Config module -- create a MyModule::Config file that defines a hash %MyModule::Config with all my stuff in it. The script can then just use MyModule::Config and off you go. On Tue, Apr 28, 2009 at 3:52 PM, Bill Moseley mose...@hank.org wrote: I have a package that includes a few scripts that I want installed. These scripts need to be able to find configuration files at run time and the config files are part of the distribution package. What's the best way to setup my package and Makefile.PL to place the config files in a package-specific directory? And then what's the best way in the script to find the installed location of these files when the script runs? Thanks, -- Bill Moseley mose...@hank.org Sent from my iMutt -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Naming advice for retry manager module
On Tue, Apr 21, 2009 at 3:12 PM, David Nicol davidni...@gmail.com wrote:
On Tue, Apr 21, 2009 at 3:11 PM, Bill Ward b...@wards.net wrote:
Something like Object::Retry maybe? Then things can inherit from it?
The proposed module sounds more like a has-a than an is-a. Or maybe
just a new method that would get included in the caller's namespace.
Set the defaults at import time, then call it with a single coderef:
use retry MIN_SLEEP = 3, MAX_SLEEP = 10, TIMEOUT = 120
my $asdf_server_connection;
retry sub { $asdf_server_connection = connect ( (new socket), ...)
or die } # whatever
the retry::retry routine would be something like
sub retry::retry($) {
my $start_time = time;
my $result;
for(;;){
eval { $result = $_[0]; 1 } and return $result;
my $E = $@;
$LOGGER and $LOGGER-( $E invoked from @{[caller]});
time - $start_time $TIMEOUT and die $E\n;
sleep ($MIN_SLEEP + rand ( $MAX_SLEEP - $MIN_SLEEP ))
}
}
Everything in all-caps would be retry:: package variables, or scalars
tied to a per-caller(1)[0] hash to mitigate AAAD surprises. Or
incorporated into the particular Retry::Object, as you are wisely
suggesting.
I've written stuff like that often enough that it would be cool to be
able to have a standard name and API for it, too.
Well, there could be multiple things that have retry functionality, so
I would want to use object attributes rather than globals ... but
you're right, it's more has-a than is-a.
Re: a lot of controversy about Module::Build
On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockway j...@jrock.us wrote: Most people I know compile one perl for each of their applications. The OS perl is for the OS, not for you. (OK, and packages the OS installs. Basically, if you plan on modifying anything perl touches in any way, you want your own perl install for that. Otherwise, yeah, you will break your OS. Why would this surprise anyone?) You'd be surprised...
Re: a lot of controversy about Module::Build
On Thu, Apr 9, 2009 at 12:10 PM, Jonathan Rockway j...@jrock.us wrote: * On Thu, Apr 09 2009, Bill Ward wrote: On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockway j...@jrock.us wrote: Most people I know compile one perl for each of their applications. The OS perl is for the OS, not for you. (OK, and packages the OS installs. Basically, if you plan on modifying anything perl touches in any way, you want your own perl install for that. Otherwise, yeah, you will break your OS. Why would this surprise anyone?) You'd be surprised... So maybe we should try educating users, instead of holding back the ENTIRE COMMUNITY for their sake. How about you write a how to manage Perl on your system doc and get it into the core as a new perlxyz perldoc file then.
Re: a lot of controversy about Module::Build
On Wed, Apr 8, 2009 at 1:05 PM, Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net wrote: On Wed, Apr 08, 2009 at 10:55:44PM +0300, Burak Gürsoy wrote: I think M::B has a clean and understandable interface while EU::MM is archaic (yes I know I didn't say something new). Any current argument about Perl installation tools is, as far as I can tell, primarily a battle between Module::Build and Module::Install, with EUMM on a stretcher by the sidelines. Pitting M::B against EUMM makes your argument neither fair nor compelling. For the average simple module that's just a pm file or two, EUMM is the least painful solution. It comes with every version of Perl that a user might possibly have, and it works the same in each of those Perl versions. It may be clunky and lack many desirable fetures, but it works just fine in most cases.
Re: RFC: Yet Another Excel Writer..
On Wed, Apr 1, 2009 at 1:36 AM, sawyer x xsawy...@gmail.com wrote: Sounds like a good module to me. I know I could have used it a few weeks ago. If so, is this set of modules aptly named? - Does it use a standard CPAN module for email sending? - What does it use for formating to web? If it's a subset of Spreadsheet::WriteExcel, maybe it would be better off to note it as Spreadsheet::WriteExcel::Easy or whatever. Basically a name that says oh wait, it's a subset of Spreadsheet::WriteExcel that will make it easier/faster (to write)/use better defaults for me than the basic Spreadsheet::WriteExcel. I think ::Simple is probably the most standard way of doing that. I'm not aware of any ::Easy modules.
Re: Net::Vimeo::API - namespace question
On Tue, Mar 10, 2009 at 6:23 AM, David Golden da...@hyperbolic.net wrote: On Tue, Mar 10, 2009 at 10:05 AM, Jonathan Yu jonathan.i...@gmail.com wrote: WWW::Vimeo. That would be my choice. Adding API seems redundant. I agree about dropping API, but prefer Net. WWW to me suggests web browsers and HTML.
Re: Perl Critic and (honest) hash references
On Mon, Mar 2, 2009 at 10:09 AM, Eric Wilhelm enoba...@gmail.com wrote: # from Joshua ben Jore # on Monday 02 March 2009 08:20: If you redesigned, replacing your hash with an array would be harder to typo, faster, smaller, not as nice to dump with Dumper, and harder for 3rd parties to extend. Is harder to extend a design goal? You also make it harder to use. I don't see how harder to extend could be considered a benefit - I think he meant that to show that there is a trade-off involved. And if everybody did it, you would have name clashes with all of those constants. That's why Perl has packages. Client code should be using accessor methods so the constants are only needed in the object class package. Using methods for typo protection doesn't get you compile-time checking, but you have tests, right? You get runtime checking, though. At least it doesn't just give a surprise undef for misspelling something. Personally I always use hashes for objects. Hashes are pretty fast in Perl, especially when there aren't many keys, so I don't think the benefits of using arrays are worth it. The risk of typos is pretty small, and the ability to easily extend it is a big plus. I provide accessor methods and don't like users prying around in the internal hash keys but if they are willing to take the risk I don't see that it's my place to stop them, either.
Re: Perl Critic and (honest) hash references
On Mon, Mar 2, 2009 at 12:22 PM, Nicholas Clark n...@ccl4.org wrote: On Mon, Mar 02, 2009 at 10:23:38AM -0800, Bill Ward wrote: Personally I always use hashes for objects. Hashes are pretty fast in Perl, especially when there aren't many keys, so I don't think the benefits of using arrays are worth it. The risk of typos is pretty small, and the Hash lookup should be O(1), independent of number of keys. Of course, a hash with more keys uses more memory, but so does an array with more elements. Yes, hashes are fast... but they do use memory and string operations are inherently slower than integer ones... O(n) by length of the keys if nothing else :)
Re: ARGH! (was FW: Perl Critic and (honest) hash references)
Still, that's bogus for ordinary hashes... it should only care about that
for objects. Though I wonder how it could possibly know the difference.
On Wed, Feb 18, 2009 at 12:17 PM, Roger Hall raha...@ualr.edu wrote:
I had to dig around in the policy modules because it isn't actually listed
in the other document I linked.
Specifically: ProhibitAccessOfPrivateData
I'm only sure this is it because the error message that came out of the
report ...
Private Member Data shouldn't be accessed directly at line X, column Y.
Accessing an objects data directly breaks encapsulation and should be
avoided.
... is prominently displayed in the module.
Thanks!
Roger
-Original Message-
From: Bill Ward [mailto:b...@wards.net]
Sent: Wednesday, February 18, 2009 11:11 AM
To: raha...@ualr.edu
Subject: Re: ARGH! (was FW: Perl Critic and (honest) hash references)
What was the solution?
On Wed, Feb 18, 2009 at 8:53 AM, Roger Hall raha...@ualr.edu wrote:
RTFM is always pretty good advice, eh? :}
-Original Message-
From: Roger Hall [mailto:raha...@ualr.edu]
Sent: Wednesday, February 18, 2009 10:05 AM
To: module-authors@perl.org
Subject: Perl Critic and (honest) hash references
$config-{query}
Perlcritic complains that Private Member Data shouldn't be accessed
directly because Accessing an objects data directly breaks
encapsulation
and should be avoided. I get that. Only problem: it's not an object.
It's
just a hashref.
Re: ARGH! (was FW: Perl Critic and (honest) hash references)
On Wed, Feb 18, 2009 at 12:22 PM, Jonas Brømsø Nielsen jona...@gmail.comwrote: Hi Roger, How do you perform your perlcritic runs? I can recommend the verbosity setting 8 perlcritic --verbose 8 This gives you quite friendly policy identifiers [ValuesAndExpressions::ProhibitConstantPragma] Pragma constant used at line 22, column 1. (Severity: 4) What's wrong with 'use constant'?
Re: ARGH! (was FW: Perl Critic and (honest) hash references)
On Wed, Feb 18, 2009 at 3:35 PM, Curtis Jewell perl.module-auth...@csjewell.fastmail.us wrote: On Wed, 18 Feb 2009 22:03 +, Ezra Cooper e...@ezrakilty.net wrote: On Feb 18, 2009, at 9:08 PM, Bill Ward wrote: Still, that's bogus for ordinary hashes... it should only care about that for objects. Though I wonder how it could possibly know the difference. Only by executing the program, I think. It couldn't be a static test. Yeah, I agree. I can see it as a warning, but not as a hard error. I've never used Perl::Critic actually, but we're looking into using it to supplement our existing (homemade) standards compliance checker at work.
Re: Delivery Status Notification (Failure)
Has anyone here worked with HTML::StripScripts? It seems to do what we want. On Sat, Feb 14, 2009 at 6:06 PM, Jonathan Yu jonathan.i...@gmail.com wrote: Hi: What about the other modules in See Also of that module? HTML::Sanitizer, HTML::Scrubber, HTML::StripScripts, HTML::Parser Cheers, Jonathan On Fri, Feb 13, 2009 at 5:53 PM, Bill Ward b...@wards.net wrote: I sent mail to the author of HTML::Detoxifier but it bounced. Does anyone here have any suggestions for XSS-killers in Perl? -- Forwarded message -- From: Mail Delivery Subsystem mailer-dae...@googlemail.com Date: Fri, Feb 13, 2009 at 2:13 PM Subject: Delivery Status Notification (Failure) To: william.w...@gmail.com This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: pwal...@metajournal.net Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 pwal...@metajournal.net: Relay access denied (state 14). - Original message - MIME-Version: 1.0 Sender: william.w...@gmail.com Received: by 10.223.105.208 with SMTP id u16mr423166fao.14.1234563201184; Fri, 13 Feb 2009 14:13:21 -0800 (PST) Date: Fri, 13 Feb 2009 14:13:20 -0800 X-Google-Sender-Auth: 64c746ed7ffc96c9 Message-ID: 3d2fe1780902131413s2d0c1a62y1f43df84c4d3e...@mail.gmail.com Subject: HTML::Detoxifier From: Bill Ward b...@wards.net To: Patrick Walton pwal...@metajournal.net Content-Type: multipart/alternative; boundary=001636c599f30f35870462d42521 --001636c599f30f35870462d42521 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I noticed you have posted HTML::Detoxifier on CPAN, but it's version 0.01 only, and hasn't been updated since 2004. What's the current status? I have need of something that does what this purports to do, but I'm dubious about the fact that it hasn't been updated. --001636c599f30f35870462d42521 - Message truncated -
Re: Name for barcode-reading module?
On Tue, Feb 17, 2009 at 10:04 AM, Keith Ivey ke...@iveys.org wrote: Okay, it seems like Barcode is the best namespace for it. As Bill says, the module is essentially OCR for barcodes, so if there were a good space for OCR-related modules it might fit there, but there doesn't seem to be one. I've thought about Barcode::Reader, but that could give people the idea that it's for use with barcode readers, when the whole point is that it allows you to use images of barcodes created by a camera or scanner *without* having a barcode reader. Right now, I'm leaning toward Barcode::Finder, or maybe Barcode::Recognizer. Anyone have any better ideas? How about Barcode::Parser? There's an article in the latest Linux Journal about a library and command-line tool for parsing 2D barcodes (I use quotes because it's pixels, not bars). I don't remember offhand what it's called, but as I was reading the article I was thinking of you and how someone ought to write a Perl interface to it if there isn't one already
Re: autoabbrev algorithm from Getopt::Long
On Fri, Feb 13, 2009 at 6:22 AM, Darren Chamberlain d...@sevenroot.orgwrote: On Fri, Feb 13, 2009 at 09:05, Johan Vromans jvrom...@squirrel.nl wrote: I could just extract the code from Getopt::Long but I think it would be a useful thing to have as a CPAN module... No problem with that, but since this is only supposed to assist typing, would't looking at readline completions be a better idea? What's wrong with Text::Abbrev? It's been part of the core for a long time. That might be the thing I'm looking for, thanks.
Module::Build equivalent to MakeMaker's LIB= argument?
I'm building a tech stack - that is, downloading CPAN modules and installing them in a new directory, not the one that Perl lives in. Until now, all the modules I build are MakeMaker-based, but I've just started adding a new Module::Build-based module (Net::OAuth, in case you're curious) and am now stuck. With MakeMaker, I run Makefile.PL with the PREFIX= and LIB= arguments. PREFIX tells Perl where the files will be installed, and LIB tells Perl where to find the modules that have been installed thus far. Adding Module::Build to the tech stack is easy, but when I try to compile Net::OAuth, I run into problems because it can't find Module::Build! I suppose I could use perl -I or PERL5LIB to specify the path, but I was looking for something analagous to the LIB= argument that I could give to Build.PL, and have that be propagated into the Build script that it generates. However, a perusal of the Module::Build man page didn't reveal any obvious answers. Is there such a feature?
Re: Module::Build equivalent to MakeMaker's LIB= argument?
On Fri, Feb 13, 2009 at 12:40 PM, Eric Wilhelm scratchcomput...@gmail.comwrote: # from Bill Ward # on Friday 13 February 2009 12:22: it can't find Module::Build! I suppose I could use perl -I or PERL5LIB to specify the path, but I was looking for something analagous to the LIB= argument that I could give to Build.PL, and have that be propagated into the Build script that it generates. However, a perusal of the Module::Build man page didn't reveal any obvious answers. Is there such a feature? If there were, it would have to be a compile-time feature of the Build.PL -- because you can't find M::B until you can find it ;-) Anything in your @INC in Build.PL will be added to ./Build, so perl -I is probably your best bet. So, if I used perl -I on Build.PL, it would remember that when doing Build itself? I'm passing perl -I to Build.PL as well as the Build script that it generates, which is working fine. I was just hoping for something a little more like how LIB= works with EU::MM
Fwd: Delivery Status Notification (Failure)
I sent mail to the author of HTML::Detoxifier but it bounced. Does anyone here have any suggestions for XSS-killers in Perl? -- Forwarded message -- From: Mail Delivery Subsystem mailer-dae...@googlemail.com Date: Fri, Feb 13, 2009 at 2:13 PM Subject: Delivery Status Notification (Failure) To: william.w...@gmail.com This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: pwal...@metajournal.net Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 pwal...@metajournal.net: Relay access denied (state 14). - Original message - MIME-Version: 1.0 Sender: william.w...@gmail.com Received: by 10.223.105.208 with SMTP id u16mr423166fao.14.1234563201184; Fri, 13 Feb 2009 14:13:21 -0800 (PST) Date: Fri, 13 Feb 2009 14:13:20 -0800 X-Google-Sender-Auth: 64c746ed7ffc96c9 Message-ID: 3d2fe1780902131413s2d0c1a62y1f43df84c4d3e...@mail.gmail.com Subject: HTML::Detoxifier From: Bill Ward b...@wards.net To: Patrick Walton pwal...@metajournal.net Content-Type: multipart/alternative; boundary=001636c599f30f35870462d42521 --001636c599f30f35870462d42521 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I noticed you have posted HTML::Detoxifier on CPAN, but it's version 0.01 only, and hasn't been updated since 2004. What's the current status? I have need of something that does what this purports to do, but I'm dubious about the fact that it hasn't been updated. --001636c599f30f35870462d42521 - Message truncated -
Re: Name for barcode-reading module?
As the author of Barcode::Code128 (though I haven't done anything with barcodes in many years) I don't see anything wrong with the Barcode namespace. I think it predates the others, but I'm too lazy to dig up the dates on each. Anyway, I think filing it under Business is silly, since there are plenty of non-business uses of barcodes, and unless your barcode is nothing but an extension of GD I wouldn't put it there. If I understand, your code is something like OCR for barcodes? On Wed, Feb 11, 2009 at 12:10 PM, Keith Ivey ke...@iveys.org wrote: I've written some code to recognize and read barcodes in images that I want to clean up and release as a module. I haven't found any module that duplicates the functionality. The idea is that you give it an image (JPEG, PNG, or anything else handled by GD) that contains a barcode and it returns the string that the barcode decodes to. Currently I handle only EAN-13 (including UPC) barcodes, but I may eventually extend it. There are modules for generating barcodes under GD::Barcode, modules for validating the check digit in barcodes under Business::Barcode, and a top-level Barcode namespace that may or may not be a good idea. Any suggestions for the right namespace? -- Keith C. Ivey ke...@iveys.org Washington, DC
Re: RFC: String::Tagged
On Fri, Jan 30, 2009 at 2:32 AM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: On Thu, 29 Jan 2009 16:57:42 -0800 Bill Ward b...@wards.net wrote: Why just strings? Why not scalars? Because only strings have character positions. Perhaps the description isn't clear enough - the string is the thing that has tags. Tags are name/value pairs that apply to some substring range of positions of that string. The type of the tag values is not restricted - any scalar will do. Could even be a CODE ref, for what to do if someone clicks here. Perhaps I should explain that clearer in the docs... I must confess I didn't read your docs at all, just going by the name and the basic description I assumed you meant tagging in the sense that is used on blogs, Flickr, etc. as a means of organizing or labeling data.
Re: RFC: String::Tagged
On Fri, Jan 30, 2009 at 10:07 AM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: On Fri, Jan 30, 2009 at 09:15:35AM -0600, Jonathan Rockway wrote: * On Fri, Jan 30 2009, Bill Ward wrote: I agree here. There is prior art for calling these overlays: http://www.gnu.org/software/emacs/elisp/html_node/Overlays.html Ah; would this suggest something like these? String::Overlay String::Overlaid String::Overlays I think Overlain may be more grammatical than Overlaid but I think I prefer MarkUp personally.
Re: RFC: String::Tagged
On Fri, Jan 30, 2009 at 12:45 PM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: On Fri, Jan 30, 2009 at 10:11:33AM -0800, Bill Ward wrote: String::Overlay String::Overlaid String::Overlays I think Overlain may be more grammatical than Overlaid Overlaid, Overlain... One of those annoying centuries-old legacies of languages. Seems Perl isn't the only language to suffer those ;) but I think I prefer MarkUp personally. Hrm. Well, MarkUp would tend to suggest issues of formatting or rendering attributes. That was mostly the use-case I had in mind, but only indirectly. Nothing in the implementation directly requires that to be the case. True. What we really have here is attributes of substrings but that's kinda long.
Re: RFC: String::Tagged
On Fri, Jan 30, 2009 at 2:04 PM, David Nicol davidni...@gmail.com wrote: On Fri, Jan 30, 2009 at 2:46 PM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: On Fri, Jan 30, 2009 at 02:00:13PM -0600, David Nicol wrote: there is also intersection with the concept of ropes rather than strings as I understand the term, A rope is a data structure designed to make string concat an O(1) operation, where you store a tree, or a linked list of substrings. That isn't the case here - in fact, the string data itself is just stored in here as a single perl string. The tags are stored in as a list of [start, length, name, value] objects beside it. The other advantage is that the substrings can have attributes. That would be a good way to define this but it still doesn't lend itself well to a name. String::SubStrAttr ?
Re: RFC: String::Tagged
On Fri, Jan 30, 2009 at 2:07 PM, Bill Ward b...@wards.net wrote: On Fri, Jan 30, 2009 at 2:04 PM, David Nicol davidni...@gmail.com wrote: On Fri, Jan 30, 2009 at 2:46 PM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: On Fri, Jan 30, 2009 at 02:00:13PM -0600, David Nicol wrote: there is also intersection with the concept of ropes rather than strings as I understand the term, A rope is a data structure designed to make string concat an O(1) operation, where you store a tree, or a linked list of substrings. That isn't the case here - in fact, the string data itself is just stored in here as a single perl string. The tags are stored in as a list of [start, length, name, value] objects beside it. The other advantage is that the substrings can have attributes. That would be a good way to define this but it still doesn't lend itself well to a name. String::SubStrAttr ? Or String::Substrate? The meaning of substrate doesn't really fit here but it's so close to SubStrAttr that I bet you could get away with it, with a suitable comment explaining the name :)
Re: RFC: String::Tagged
Why just strings? Why not scalars?
On Thu, Jan 29, 2009 at 4:52 PM, Paul LeoNerd Evans
leon...@leonerd.org.uk wrote:
I find myself requiring an object to store a text string, with ways to
throw markup or presentation attributes around it, but in such a way
that they're easy to edit and change separately from the string data.
I.e. the usual embedded HTML / ANSI escapes / etc... are not really
suitable.
With this in mind, I have come up with String::Tagged.
I'd appreciate any thoughts or comments people might have on the API and
design before I upload it.
-
String::Tagged(3pm) User Contributed Perl Documentation String::Tagged(3pm)
NAME
String::Tagged - string buffers with value tags on ranges
SYNOPSIS
use String::Tagged;
my $st = String::Tagged-new( An important message );
$st-apply_tag( 3, 9, bold = 1 );
$st-iter_substr_nooverlap(
sub {
my ( $substring, %tags ) = @_;
print $tags{bold} ? b$substring/b
: $substring;
}
);
DESCRIPTION
This module implements an object class, instances of which store a
(mutable) string buffer that supports tags. A tag is a name/value pair
that applies to some non-empty range of the underlying string.
Tags may be arbitrarily overlapped. Any given offset within the string
has in effect, a set of uniquely named tags. Tags of different names
are independent. For tags of the same name, only the the latest,
shortest tag takes effect.
For example, consider a string with two tags represented here:
Here is my string with tags
|-|foo = 1
|---| foo = 2
|---| bar = 3
Every character in this string has a tag named foo. The value of this
tag is 2 for the words my and string and the space inbetween, and 1
elsewhere. Additionally, the words is and my and the space between
them also have the tag bar with a value 3.
CONSTRUCTOR
$st = String::Tagged-new( $str )
Returns a new instance of a String::Tagged object. It will contain no
tags. If the optional $str argument is supplied, the string buffer
will be initialised from this value.
METHODS
$str = $st-str
Returns the plain string contained within the object.
$str = $st-substr( $start, $len )
Returns a substring of the plain string contained within the object.
$st-apply_tag( $start, $len, $name, $value )
Apply the named tag value to the given range.
$st-unapply_tag( $start, $len, $name )
Unapply the named tag value from the given range. If the tag extends
beyond this range, then any partial fragment of the tag will be left in
the string.
$st-delete_tag( $start, $len, $name )
Delete the named tag within the given range. Entire tags are removed,
even if they extend beyond this range.
$st-iter_tags( $callback )
Iterate the tags stored in the string. For each tag, the CODE reference
in $callback is invoked once.
$callback-( $start, $length, $tagname, $tagvalue )
$st-iter_tags_nooverlap( $callback )
Iterate non-overlapping ranges of tags stored in the string. The CODE
reference in $callback is invoked for each range in the string where no
tags change. The entire set of tags active in that range is given to
the callback.
$callback-( $start, $length, %tags )
The callback will be invoked over the entire length of the string,
including any ranges with no tags applied.
$st-iter_substr_nooverlap( $callback )
Iterate ranges of the substring in the same way as
iter_tags_nooverlap(), but passing the substring of data instead of
the start position and length.
$callback-( $substr, %tags )
@names = $st-tagnames
Returns the set of tag names used in the string, in no particular
order.
$tags = $st-get_tags_at( $pos )
Returns a HASH reference of all the tag values active at the given
position.
$value = $st-get_tag_at( $pos, $name )
Returns the value of the named tag at the given position, or undef if
the tag is not applied there.
$st-set_substr( $start, $len, $newstr )
Modifies a range of the underlying plain string to that given.
NOTE: - Because of the way that this method modifies the underlying
string, its use would disturb the tags applied in its range, or after
if the length changes. There is no clear behaviour for what should be
done to tags applied in the affected range, or after it.
Therefore, this method will throw an exception if any tags apply after
the $start index.
This is unlikely to be useful in a general application; I am well aware
of this fact. I welcome
Number::Format and locale woes
WHEREAS, Number::Format uses POSIX for locale stuff, and WHEREAS, locale is b0rked on so many systems out there, and WHEREAS, Number::Format is constantly getting barraged by bug complaints and CPAN build failure emails, and WHEREAS, I'm getting tired of the above and can't do much about it, BE IT THEREFORE RESOLVED, that I'm seriously considering to take out Locale support from Number::Format and make it configured manually. Perhaps there may be a little locale support left in to set defaults, but only if locale isn't b0rked on that system. Any thoughts opinions? --Your exasperated Number::Format maintainer.
