Re: What hurts you the most in Perl?
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. 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? Chris
Re: What hurts you the most in Perl?
On Nov 26, 2010, at 5:24 AM, Paul LeoNerd Evans wrote: On Wed, Nov 24, 2010 at 04:54:31PM +0100, Sébastien Aperghis-Tramoni wrote: In terms of Perl itself, apart from the reference syntax, the thing that really annoyed me recently was the lack of advanced debug tools, for example to find memory leaks. None of the tools I found or was pointed to worked in my case. Have you tried either Test::Refcount Test::MemoryGrowth I like this one for finding design flaws in complicated data structures: Test::Memory::Cycle Chris
Re: Why are you releasing modules to CPAN?
On May 27, 2010, at 6:33 AM, Gabor Szabo wrote: So why do *you* contribute to CPAN? Cynical reason: Because otherwise code I write stays locked up in my employer's intellectual property. Convincing them to release it as open source is easier than convincing them to let me continue to use it in my next job. Especially if said employer goes out of business. ROI reason: For the bug reports and patches -- the free labor nearly balances my additional support workload, and makes the code better. Karma reason: Payback for other people's open source code that I use. Chris
Re: how to set $VERSION throughout distribution
On Sep 13, 2009, at 7:36 AM, Shawn H Corey wrote: Jonas Brømsø Nielsen wrote: dist_name = 'Workflow', dist_version_from = 'lib/Workflow.pm', I would be tempted to: dist_version_from = 'lib/Workflow/VERSION.pm', Comments? I thought about that too and rejected it as unnecessary complexity. You still need a $VERSION in Workflow.pm anyway or else Workflow- VERSION() doesn't work right, so why not just put the version in Workflow.pm in the first place. Chris
Re: how to set $VERSION throughout distribution
On Sep 11, 2009, at 8:08 PM, Jonathan Swartz wrote:
What's a good policy for setting $VERSION in the non-main modules
of a distribution?
e.g. I've got Server-Control-0.08, and Server::Control contains
our $VERSION = '0.08';
but none of the other modules in the distribution (e.g.
Server::Control::Apache) contain a $VERSION. I can see at least
three possibilities:
1) Don't bother putting $VERSION anywhere except the main module
2) Put a different $VERSION in each module, depending on when that
module itself changes
3) Put the same $VERSION in each module, matching the distribution
and the main module
1 clearly wins for laziness - is there a reason to do more? If so,
pros/cons to 2 vs 3?
Thanks
Jon
I always choose #3.
If you don't put a $VERSION in a sub-module, then it's hard for an
arbitrary user to tell if he has a corrupt installation with mixed
versions. Consider the case where you rename Server::Control::Apache
to Server::Control::Plugin::Apache between version 0.08 and 0.09.
Then a user who sees Server/Control/Apache.pm with $VERSION = 0.08
knows that that is an obsolete file in contrast to Server/Control.pm
with $VERSION = 0.09.
With automated build tools (e.g. perl -i -pe's/\$VERSION = 0.08/\
$VERSION = 0.09/' lib/{,*/,*/*/}*.pm) it's trivial to update the
version number of the whole group of modules at once. The biggest con
is churn -- even if you don't change any of the code Server/Control/
Apache.pm, you still must commit another SVN/Git/etc version of it
just because the version number changed. That makes it harder to read
the version control logs. The best practice to mitigate this is make
the version number change be a single commit with no other changes.
That way, the version change doesn't bury small code changes. This
churn also adds a little noise to the diff tool on search.cpan.org.
Chris
Re: question concerning module architecture
On Aug 9, 2009, at 3:03 PM, Geoffrey Leach wrote: Is here any way for a module to discover the package that requires it? You can invoke caller() within Getopts::Auto::import Chris
Re: Structured Changelog?
Josh, I participated in a previous thread on this topic, but I couldn't find it (maybe it was blog comments?) From memory, I think we concluded that, no, there was no formal spec and that it would be too painful to build one broad enough for everyone's taste. So, we dropped the idea. My own ad-hoc syntax looks like this example: http://cpansearch.perl.org/src/CDOLAN/Fuse-PDF-0.09/Changes In retrospect, I may have gotten a little carried away with too much detail... For my own syntax, I wrote an author unit test that checks that all versions have a summary and a release date. I never got around to writing the test that ensured the .pm's current version number had an entry in the changelog. Chris On Jun 27, 2009, at 10:42 AM, Joshua ben Jore wrote: Last year I started seeing change logs in perl modules that looked more YAMLish. Is there any spec out there on this? I'm currently just copying input from `git log --pretty=oneline' into my Changes file and as of this moment, including the git repo URL. Is there any external standard or pattern I can conform to? Revision history for Perl extension App::Perldoc::Search at http://github.com/jbenjore/App-Perldoc-Search/commits/master. 0.02 Sat Jun 27 08:33:00 2009 304a4464b38b71f10f34c8866da7e3bab1369d3e Clean up dependency list 0.01 Fri Jun 26 01:10:54 2009 9e60c318ebd5543bb342725f7f4834b2502e65f5 Add META.yml c69869d09c07115b04120ce0d294011940d76321 0.01 Josh
Re: Module::Build + documenation woes
I believe you missed the point of Paul's joke. He was quoting advice from ExtUtils::MakeMaker that many of us consider antiquated: http://www.perl.com/doc/manual/html/lib/ExtUtils/MakeMaker.html#DESCRIPTION Chris On Jun 12, 2009, at 9:41 AM, Jonathan Yu wrote: I have *never* used h2xs to start a module, though I have copied the basic scripts/structure/etc that other packages have (which likely began with h2xs at one point or another)... I prefer doing it on my own by hand, though I guess that's not an option for people new to Perl packaging On Fri, Jun 12, 2009 at 6:36 AM, Paul Johnsonp...@pjcj.net wrote: On Thu, Jun 11, 2009 at 04:12:32PM -0700, Bill Ward wrote: 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?) Always begin with h2xs. Always begin with h2xs! ALWAYS BEGIN WITH H2XS! -- Paul Johnson - p...@pjcj.net http://www.pjcj.net
Re: Help needed testing security of login module
On May 20, 2009, at 4:24 PM, Bill Ward wrote: 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? I highly, highly recommend reading this article in detail: http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ Some good takeaway lines are: No, really. Use someone else’s password system. Don’t build your own. The problem is that MD5 is fast. The post is in response to a security hole article on the popular Coding Horror blog (by Jeff Atwood of StackOverflow fame). Rainbow Hash Cracking http://www.codinghorror.com/blog/archives/000949.html You're Probably Storing Passwords Incorrectly http://www.codinghorror.com/blog/archives/000953.html I Just Logged In As You: How It Happened http://www.codinghorror.com/blog/archives/001263.html Chris
Re: New Module
On May 3, 2009, at 6:54 AM, Aristotle Pagaltzis wrote: * Jonathan Rockway j...@jrock.us [2009-05-03 08:00]: This is why Perl people should blog more. Agreed, that helps up to a point. But you can’t natter on about *every* module at the same level of noise. I vehemently agree. At the risk of derailing this thread, I'll digress to say the Iron Man blogging competition has actually made me read fewer posts -- my initial impression was that the quality of a post was lower if it mentioned Iron Man in the first sentence. If you blog because you are inspired to say something important to the community, then I want to read it. If you blog every time you release a module, or just because mst told you to, then you are just lowering the signal-to-noise ratio. High S/N means optimizing quality/quantity. Jonathan's simply-stated opinion pushes to increase the denominator, which may help increase the visibility of the community but hurts inside the community. Chris
Re: Module for detecting is a method is overridden
On Mar 8, 2009, at 11:48 AM, Ovid wrote:
I want to write a module which allows me to quickly detect if a
method is overriding a parent class method (I already know about the
method cache invalidation problem).
Potential uses would be for something like this:
use Attribute::Override;
use parent 'Some::Class';
sub foo :override{...} # fails if it doesn't override
sub bar {...} # fails if it does override
Or:
# needs to
use Method::Override;
Method::Override::overriden(qw/foo/); # must be done after
compilation
That can solve nasty problems where the developer accidentally
overrides a parent method but doesn't realize it. Still trying to
figure out a good interface, otherwise it will never get used
(unless it's built in to the language, I suspect it will never get
used anyway, but what the heck :)
Suggestions?
In Java, it's
@Override
public void foo() { ... }
which is very close to what you've suggested with :override. It is
indeed quite useful because it checks both method name and signature.
But for backward compatibility, it does not fail if it doesn't
override, so there are third-party static analyzers (e.g. FindBugs)
which take on that chore if you mark a superclass method as
@MustOverride or something like that. That's sometimes done for
clone() or the like.
Chris
Re: ARGH!
On Feb 21, 2009, at 2:10 AM, Eric Wilhelm wrote: Is there a critic metric for that? There are several designed to protect internals. Here are the ones among the Perl::Critic core policies: Subroutines::ProtectPrivateSubs ValuesAndExpressions::ProhibitLongChainsOfMethodCalls Variables::ProtectPrivateVars Variables::ProhibitPackageVars Chris
RE: ARGH! (was FW: Perl Critic and (honest) hash references)
Honestly I just left the default perlcritic test script in my package as generated by Module::Starter. This was the first time I had done so, and I really had no idea about Perl::Critic until last night when my module failed smoke testing after upload to CPAN. From the test script I am guessing that I cannot alter the verbosity setting (running on someone else's automated server). Score one for the good guys: annoying our users into writing better code. ;-) Chris
Readonly::XS failure under 5.10
Eric, There's an utterly trivial error in Readonly::XS that prevents it from compiling under 5.10. There have been three RT reports about this problem since Oct 2007. The fix is incredibly simple: just put parentheses around the argument to Cart::croak. Will you please fix this bug, or will you grant someone else co- maintainership? Readonly::XS is much too important to let it stagnate. http://rt.cpan.org/Public/Bug/Display.html?id=33711 http://rt.cpan.org/Public/Bug/Display.html?id=29778 http://rt.cpan.org/Public/Bug/Display.html?id=35201 Chris
Re: Module for base 85 encoding
On Mon, Nov 24, 2008 at 10:42:07AM -0600, Chris Dolan wrote: I don't have a good name recommendation, but I do know there is a PDF-specific implementation within this CPAN module: http://search.cpan.org/src/MHOSKEN/Text-PDF-0.29a/lib/Text/PDF/Filter.pm I use that filter within my own CAM::PDF module. I infer that you only use it for input, because as best I can tell, the output filter does not work: http://rt.cpan.org/Public/Bug/Display.html?id=41085 Nicholas Clark Hah, thanks for pointing that out, I hadn't noticed. You're right, I think I've only used it for reading. It's not a commonly used feature in PDF anyway since gzip is an obviously better filter. Chris
Re: Module for base 85 encoding
Yes. RFC 1924 specifies a way to convert an IPv6 address to ASCII, by treating it as 128 bit integer, writing the number in base 85, then expressing each base 85 digit as an ASCII character btoa and PDFs break up a stream of bytes into ASCII by treating it as 32 bit integers (4 bytes become 5 ASCII characters), and (in the case of PDFs) then representing last odd 1 to 3 bytes as 2 to 4 ASCII characters. They also use a different subset of printable ASCII from RFC 1924 Nicholas Clark Given that, I second RJBS' suggestion of String::Base85 (or perhaps String::Ascii85 for better searchability) Chris
Re: The value of threads
On Nov 1, 2008, at 7:31 PM, Dr.Ruud wrote: Cuse forks; :) Wow, I was unaware of that module. My primary problem with forking in applications is the programming overhead of joining and sharing. This implementation seems to hide a lot of that complexity. The reuse of the threads API is an added bonus. Chris
The value of threads (was Re: META.yml how to declare the need for threaded perl?)
On Nov 1, 2008, at 10:39 AM, Dr.Ruud wrote: Gabor Szabo schreef: I guess we can implement everything with fork but I think - maybe because of my lack of experience in threads - that it will be better to use them than to fork. I think it was Randal Schwartz who said something like: If the answer involves threads, then the question was wrong. Most likely that quote comes from a year when multi-processor systems were not ubiquitous. Every UI framework I've ever used was indeed written with a single- threaded event loop, but even in an editor it sure is handy to have background threads to do asynchronous work (syntax checking, rebuilding call graphs, Perl::Critic, etc) without having to explicitly chunk the work or coordinate multiple processes. Chris
Re: META.yml how to declare the need for threaded perl?
Just add a dependency on thread::shared or one of the other threading
libraries. Push your problem up the chain!
Chris
On Oct 31, 2008, at 7:31 AM, Gabor Szabo wrote:
Hi,
currently I have this code in Build.PL to check if the perl where
Padre
is being installed is threaded.
use Config;
if (not $Config{usethreads}) {
warn Padre requires a perl built using threads\n;
exit 0;
}
Is there any way to add this requirement to META.yml?
Gabor
Re: Integrating license related things of CPAN
On Oct 26, 2008, at 10:24 PM, Bill Ward wrote: The problem is people may add it to META.yml but not remove it from the POD. For one thing, it would be nice to be able to see what the license is when viewing the POD. Once the module is installed META.yml is no longer present, and there's no way for someone using the module to determine the license from perldoc/man. Also, some modules may include a separate LICENSE or COPYRIGHT file in the tarball. (joining this discussion late...) Isn't that just an authoring problem that already exists today? The LICENSE file is not kept after installation either. This is a human problem, so I think a human solution is appropriate, like a Perl::Critic policy or a Kwalitee rule or a distcheck action to ensure the META.yml matches the POD copyright. The definition of matches is the hard part...
Getting co-maint for new modules in a package
The Perl::Critic team has a small but persistent problem with PAUSE. We frequently add new policy modules to the distro. When we do so, the person who does the release gets ownership of that namespace. We have three co-maintainers who do releases, so reminding each other to grant co-maint on the new modules is becoming an unwelcome ritual before handing off the release baton. Is there an easy solution to getting co-maint on all modules in a distro? Is it just something we need to remember to do, or is there an automatic solution somewhere? Chris
Re: Module::Install is a time bomb
On Sep 30, 2008, at 5:04 PM, Gabor Szabo wrote: Excuse me? and you kept this information to yourself all those years? BTW Could I somehow install all the dependencies of a module but not the module itself? Yes, that's what the earlier test . recommendation meant. Personally, to get deps of darkpan code I usually do cpan . and then Ctrl-C when I hit the tests in ./t. Sloppy, but effective. Chris
Re: Must exist, right?
On Jun 18, 2008, at 6:35 PM, Andy Armstrong wrote:
I assume there's a module that works like this?
[snip]
It's got to exist, right? I had a look but there are so many ^
(?:Object|Data)::.* modules that it's a bit hard to see the wood
for the trees :)
--
Andy Armstrong, Hexten
Implemented! See the attached .pm file and the test.pl file that
verifies the four snipped use cases. It could certainly be made more
readable, but my interest is waning quickly. :-) I hereby grant
anyone permission to use/extend this crappy code under the same
license terms as Perl itself.
Chris
package MyFoo;
use Data::Auto::Objectify::Thing qw( my_data_field );
sub new {
bless {
my_data_field = {
foo = [ 1, 2, 3 ],
bar = { eat = 'drink', sleep = 'wake' },
grid = [
[1,2,3,4,5,6], [7,8,9,10,11,12],
[13,14,15,16,17,18], [19,20,21,22,23,24],
],
}
},
shift;
}
package main;
use Test::More tests = 4;
my $my_foo = MyFoo-new;
is($my_foo-foo( 1 ), 2);
is($my_foo-bar-eat, 'drink');
is($my_foo-bar('eat'), 'drink');
is($my_foo-grid(3, 5), 24);
package Data::Auto::Objectify::Thing;
use warnings;
use strict;
use Carp;
use Data::Dumper;
sub import {
my ($pkg, $fieldname) = @_;
my $caller_pkg = caller(0);
no strict 'refs';
*{$caller_pkg . '::AUTOLOAD'} = sub {
my ($self, @args) = @_;
my $autoload = do {
no strict 'vars';
$AUTOLOAD;
};
return if $autoload =~ /::DESTROY$/;
my ($fn) = $autoload =~ m/([^:]+)\z/xms;
if (defined $fieldname) {
$self = $self-{$fieldname};
}
if (!exists $self-{$fn}) {
croak 'No such field ' . $fn;
}
my $field = $self-{$fn};
if (!ref $field) {
return $field;
}
if ('ARRAY' eq ref $field) {
$field = $field-[$_] for @args;
return $field;
}
my $obj = bless {xyzzy = $field}, 'Data::Auto::Objectify::Thing::anon';
$obj = $obj-$_() for @args;
return $obj;
};
return;
}
package Data::Auto::Objectify::Thing::anon;
Data::Auto::Objectify::Thing-import('xyzzy');
1;
Re: Naming help - XML plist (Apple/Mac/iTunes)
On Jun 13, 2008, at 6:48 PM, Bill Ward wrote: On Fri, Jun 13, 2008 at 4:35 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: Note that plists can also be stored in a binary format; would you want to support that also? If so, how about Parse::ApplePlist? I don't know anything about the binary format but its existence does argue against the XML prefix for sure. On a Mac, you can use plutil -convert xml1 -o out.xml in.xml and plutil -convert binary1 -o out.xml in.xml to switch back and forth. You can also use the -lint option to validate your data files. I *think* the binary format was introduced in 10.4, but maybe it was 10.3. Chris
Re: Licenses of CPAN modules
On Jun 6, 2008, at 4:58 AM, Aristotle Pagaltzis wrote:
* Barbie [EMAIL PROTECTED] [2008-06-06 11:35]:
(Spec 1.4) [required] {map} The license(s) under which this
distribution may be used and redistributed, using a YAML
mapping to describe the version and the file or url containing
the full text of the license. For a full list of acknowledged
licenses please see the Software::License distribution -
http://search.cpan.org/dist/Software-License.
version
(Spec 1.4) [required] Explicit version number of the license
under which the distribution is being distributed.
I disagree with this. Version numbers on licences are just a
naming sleight of hand. GPLv3 differs drastically from GPLv2,
and while Artistic 2.0 is the spiritual successor to the Artistic
Licence, in legal terms at least it is a completely new beast.
The “version number” is part of the name. There is no GPL; there
are GPL1, GPL2 and GPL3, and you must specify which you mean. In
case of the Artistic Licence, there is no 1.0 version as it was
never called Artistic 1.0 prior to the work on Artistic 2.0.
Using a version number in the name is purely a marketing device.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Agreed. GPLv2 or later is a common license which is not
represented by the version number. We really don't want the full
Module::Build version syntax:
license:
- GPL:
version: '=2, !=3'
:-)
Seriously, though, I like the idea of pointing at a file and an URL.
I would switch the URL to opensource.org, though, since it's easier
to imagine that staying up-to-date (no offense, RJBS). And I would
use the file as the key since it's more definitive than the human-
readable name. Or perhaps the URL should be the key?
license:
- 'Artistic.txt':
title: 'Artistic License v1'
url: 'http://www.opensource.org/licenses/artistic-license-1.0.php'
- 'COPYING':
title: 'GPL v3'
url: 'http://www.opensource.org/licenses/gpl-3.0.html'
Chris
Re: How to challenge a cpan-testers test result?
On May 26, 2008, at 6:43 PM, Eric Roode wrote:
On Mon, May 26, 2008 at 4:15 PM, Burak Gürsoy [EMAIL PROTECTED]
wrote:
Hi,
It looks like you're suffering from a feature of MakeMaker. Add
this to your
Makefile.PL options (WriteMakefile):
PL_FILES = {},
so that your Build.PL will not be identified as some executable
code...
Hey, that's a great tip. Thanks, Burak.
-- Eric
I highly recommend that you consider using the create_makefile_pl =
'traditional' option which takes care of these annoying little
details for you automatically.
If you had done a web search for the error Too early to specify a
build action 'Build' you would have seen that others have made this
same error in their Makefile.PL files. The first Google result, for
example, has the solution: http://www.cpanforum.com/threads/373
Perhaps someone should file a bug against MakeMaker and/or
Module::Build to emit a more useful error in this case? Or make
Build.PL be an explicit exception to MakeMaker's rules? That won't
help older installations, but it will make the future a happier place.
Chris
Re: Reporting CPAN Index Problem
On Apr 16, 2008, at 3:50 PM, imacat wrote: On Wed, 16 Apr 2008 22:00:05 +0200 [EMAIL PROTECTED] (Andreas J. Koenig) wrote: It is a little known fact how decimal numbers convert to version strings in perl. Frankly, I do not even know where it is documented. % perl -le 'use version;print version-new(0.3) = version-new (0.3.1);' 1 This means that 0.3 is higher than 0.3.1. To beat 0.3 with a versions I see. I have filed an RT request (#35130) to Lingua-Features to suggest a better version text naming. But I think that it would be great if 0.3.1 can be higher than 0.3, since that is natural to human reading, and is the current practice of many open source projects. I agree with that request in principle, but in reality it's too late. Reversing the ordering would break hundreds of other CPAN modules, not to mention perl itself. The easy way to remember it is that a second dot in a number triggers the elements of the version number to be split specially 0.3 == 0.30 0.3.1 == 0.003001 0.3.0 == 0.003000 And of course: perl 5.5.0 == 5.005 perl 5.6.0 == 5.006 perl 5.6.1 == 5.006001 perl 5.10.0 == 5.010 Looking at the right hand side, the ordering becomes obvious. So, the common recommendation is to be 100% consistent with your version numbers. Either always use two dots or always use one dot or always use strings. Chris P.S. What does Perl 6 do?
Re: publish/subcribe model via network
On Apr 11, 2008, at 9:23 PM, Eric Wilhelm wrote:
...
I would like the publish clients to connect to a server, then
publish
their message and disconnect. (Optionally, they can stay connected
and
publish more messages.)
The subscribe clients would hold persistent connections to the
server
(there are only 2 subscribers, though there could be more) and receive
the messages immediately after publication.
...
http://scratchcomputing.com/svn/misc/pubsubserver
To put that in some rough but short code:
my $fh;
while(my $client = $socket-accept()) {
my $pid = open($fh, '|-') and next;
if(pub) {
while($client) { print $fh $_ }
}
else {
while() { relay_to_subscriber($client) }
}
exit;
}
...
I implemented something vaguely like this in a single threaded manner
a couple of years back. My implementation looked something like this:
while (1) {
my $msg;
my $client = $socket-accept;
if (!$client) { # time out, send a keepalive to listeners
$msg = $self-make_keepalive_msg();
} else {
my $response = $self-handle($c);
if ($response-is_new_listener) {
$self-add_listener($client);
$socket-timeout($LISTENER_TIMEOUT);
} elsif ($response-should_send_to_listeners) {
$msg = $response-make_msg();
}
}
if ($msg) {
for my $client ($self-get_listeners) {
if (!$client-connected) {
$self-remove_listener($client);
$socket-timeout(undef) if ! @listeners;
} else {
print {$client} $msg;
}
}
}
}
My real implementation did a lot more error handling, of course, and
spoke SOAP but still netted under 200 lines. Perhaps a difference
between your problem and mine is that my messages were always short
and my accepting server was allowed to be single threaded (very low
traffic), so looping over the listeners in the main accept loop was
fine.
Mine had to work on Windows, so I did as little forking as possible.
Chris
Re: Date::Piece -- Happy New Year
On Jan 3, 2008, at 4:48 PM, Johan Vromans wrote: Eric Wilhelm [EMAIL PROTECTED] writes: The caveat may apply if today is any day = 28 -- if we run out of days in the destination month, we stop at the end. I'd say that January 30 + 1 month should be March 1, not February 29. -- Johan The Java world is considering the same question. The current release has java.util.Calendar which does as you suggest, and it's a horrible, widely-despised solution. The proposed change for Java 7 is based on the joda-time.sf.net library which takes an interesting approach: distinguish between adding a Duration and a Period. What you describe would be adding Period.month(1). Joda considers the difference between two DateTime instances to be a Duration. Chris
[Request] File::Wordlist
Dear really-really-lazyweb,
Would someone please create a CPAN module that finds a wordlist on
the local computer in a cross-platform friendly manner, a la
File::HomeDir? For typical unix systems, that would be:
sub find_wordlist {
return '/usr/share/dict/words';
}
But it could be smarter and look for, say, /usr/share/dict/scrabble-
english first. For Windows, maybe it would look for MS Office or
OpenOffice files first.
For extra points, it could even parse those files if their not just
word + newline. For double extra points, it could download
additional dictionaries from the web (ispell, etc).
TIA,
Chris ;-)
References:
http://www.nntp.perl.org/group/perl.fwp/2007/12/msg4038.html
http://en.wikipedia.org/wiki/Words_(Unix)
http://packages.debian.org/sarge/all/scrabble/filelist
http://packages.ubuntu.com/dapper/virtual/wordlist
http://fmg-www.cs.ucla.edu/geoff/ispell-dictionaries.html
http://www.gutenberg.org/etext/3201
Paths:
/usr/dict/words
/usr/share/dict/*
/Applications/Firefox.app/Contents/MacOS/dictionaries/en-US.dic
/Library/Dictionaries/New\ Oxford\ American\ Dictionary.dict/
Contents/dict_body
/sw/share/aspell/*
Re: RFC: relative.pm
On Oct 6, 2007, at 1:27 PM, Sébastien Aperghis-Tramoni wrote: Paul Hoffman wrote: use relative to = Enterprise::Framework = qw(Base Factory); # loads Enterprise::Framework:Base, Enterprise::Framework::Factory Hmm, the last example is equivalent to this: use relative qw(to Enterprise::Framework Base Factory); Which might conceivably cause a problem for someone at some point. You might consider requiring the string ':to' instead of 'to'. I agree that this syntax prevents from loading a module named to.pm, but I think this is a good trade-off given than adding any other character will require quoting the word, and I'd like to keep the syntax as simple as possible. An acceptable compromise it to write it as C -to = Root As a side note, using find(1) on a mini-CPAN and Google CodeSearch, I only found 3 modules named tp.pm : - CGI::FormMagick::L10N::to (in MITEL/CGI-FormMagick-0.89.tar.gz) - DateTime::Locale::to (in DROLSKY/DateTime-Locale-0.35.tar.gz) - Number::Tolerant::Type::to (in RJBS/Number-Tolerant-1.550.tar.gz) If you really wanted a ::to you could just rearrange the order and say: use relative qw(Enterprise::Framework Base Factory to); The only thing it couldn't support is a single pkg called ::to. Chris
Moving a module to another distribution
We're thinking about promoting one of the Perl::Critic::More policies to the core Perl::Critic distribution. As long as the version number increases and PAUSE permissions are OK that should be fine, right? http://search.cpan.org/perldoc? Perl::Critic::Policy::ValuesAndExpressions::ProhibitMagicNumbers Chris
Re: Should I include second-order dependencies in Makefile.PL?
On Jun 5, 2007, at 8:00 PM, Andy Lester wrote: On Jun 5, 2007, at 7:42 PM, James E Keenan wrote: Is there any reason *not* to do so? Yes. Second-order dependencies are beyond your control. You will have false dependencies when an underlying module changes. Say that Mech has dependency on HTML::Wango, which in turn has a dependency on Test::Tango. So my dependencies are listed as HTML::Wango = 1.00, Test::Tango = 1.00, SCENARIO 1: The maintainer of Foo::Wango decides that Test::Tango is unnecessary, and does without it. He released HTML::Wango 1.02. Someone installing Mech must now install HTML::Wango and Test::Tango, although NOTHING in the chain requires Test::Tango. SCENARIO 2: HTML::Wango uses some new feature of Test::Tango 2.00, and thus requires it. Your helpful list of dependencies is out of date, because although you say that you are requiring 1.00, HTML::Wango requires 2.00. I think scenario 2 is quite harmless. If the user has... ... no Test::Tango version installed, then they will be properly upgraded to the latest CPAN Test::Tango 2.00+ at the first level ... Test::Tango 1.00, then they will be properly upgraded to the latest CPAN Test::Tango 2.00+ at the first level ... 2.00 Test::Tango = 1.00 then they will pass the first-level dependency but get prompted and then properly upgraded at the second level ... Test::Tango = 2.00 then they're already all set at both levels So, at worst Jim's dependency flattening doesn't hurt in scenario 2 and would help most users. Still, scenario 1 is the killer. SCENARIO 3: Combine 1 2. The real solution is either: 1) for the CPAN shell to use the META.yml files to determine the chain of dependencies ahead of time. Also, you don't always have to have the ask option on prereqs. I think most people DON'T have it set to ask. xoxo, Andy I suspect this last point is wrong. The CPAN.pm default is ask and we know that most of the time most people just take defaults. But, beside that point, I think Andy is on the right track with his real solution. Chris
Re: (Create a new ?) namespace for applications on CPAN
On May 18, 2007, at 10:01 AM, John M. Gamble wrote: Yeah, there's no tree-browsing capability on CPAN. I wish there was. Take a look at Laurent Dami's Pod::POM::Web application. it's for locally-installed modules rather than all of CPAN, but it does do a nice tree layout. Screenshot: http://www.chrisdolan.net/images/Pod-POM-Web.png CPAN: http://search.cpan.org/dist/Pod-POM-Web/ Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: bin:: namespace for utilities on CPAN
On May 18, 2007, at 3:15 AM, Dominique Quatravaux wrote: Chris Dolan wrote: Don't forget Mail::SpamAssassin. That's a popular example of a CPAN-hosted, end-user application. I think it would not be an improvement to rename it Application::Mail::SpamAssassin or bin::Mail::SpamAssassin. Does this mean you are advising Crypt::NutsPKI in my situation over App::NutsPKI? Maybe, maybe not. I advocate for the name that would get the most hits in a search by a user looking for a module like yours. Given my limited understanding of what you app will do, I *think* I prefer App::NutsPKI over Crypt:: because the latter sounds more like a library than an app. That said, the Nuts part of the name means nothing to me... Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: bin:: namespace for utilities on CPAN
On May 17, 2007, at 10:26 PM, Andy Lester wrote: On May 17, 2007, at 9:49 PM, Eric Wilhelm wrote: I'm actually having a difficult time getting you all to agree to *recommend* that things which will be installed in a directory named bin/ should have a namespace named bin::? Wow. LWP::UserAgent has stuff that installs into bin. WWW::Mechanize has stuff that installs into bin. etc etc etc Don't forget Mail::SpamAssassin. That's a popular example of a CPAN- hosted, end-user application. I think it would not be an improvement to rename it Application::Mail::SpamAssassin or bin::Mail::SpamAssassin. I'm with Andy on this. In the CPAN world, the stuff that gets installed in bin/ is usually thin wrappers around the real code which gets installed in lib/perl5/. Should the rest of CPAN all go in the lib:: namespace? And maybe .pod files belong under share::man3:: :-) Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: OO filename abstraction module?
On Apr 27, 2007, at 11:14 PM, Eric Wilhelm wrote: I'm thinking of using a filename as a unique identifier and I'm wondering if there is a module on CPAN (in those 1483 search results) that I can't seem to find which provides some kind of OO filename abstraction. Try this: http://search.cpan.org/dist/Path-Class/ It has a very intuitive API and is based on File::Spec. And it's written by Ken Williams, so it must be good. :-) Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: echo die Makefile.PL
On Apr 17, 2007, at 12:16 PM, Eric Wilhelm wrote: The suggestion people made was to have M::B produce a 'traditional'-style makefile as well. So at least M::B-deprived systems might have a good go. My problem with the create_makefile_pl = 'traditional' is that it doesn't install Module::Build, so we're not making any progress. If you have a custom build subclass, you might as well put a die in Makefile.PL. The passthrough seems much more sane because it actually installs Module::Build, yet nobody seems to encourage its use. Why? I am a long-time supporter of M::B, but I consistently choose create_makefile_pl = 'traditional'. I believe that successful install for the largest number of users is the most important goal, not progress. Progress is what 5.10 is for, where M::B will be bundled. I like 'traditional' because it's the easiest on the end user for packages that don't really need M::B's extra goodness (that is: the majority of CPAN modules). It's easier because EU::MM is pre- installed and older pre-installed CPAN.pm versions interact better with EU::MM than M::B. Echoing die into Makefile.PL is like putting the following in your modules: die 'Time to upgrade' if $] 5.008008; Amusing, but ultimately counter-productive and disrespectful of users whose needs you may not understand. Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: Locally installed modules
Bill,
This is kind of a wild guess, but perhaps your make install is using
sudo? Recent versions of sudo are more restrictive in which envvars
get propagated. One difference between your CPAN config and mine is
the following:
'make_install_make_command' = q[/usr/bin/make],
Chris
On Apr 9, 2007, at 11:27 AM, Bill Moseley wrote:
This may be a CPAN or MakeMaker question -- please point me to a
different list if so.
I just when through the exercise of installing Catalyst on a clean
Debian Stable machine into a local Perl library. (Testing what
non-root user would need to do). I first updated ExtUtils::MakeMaker
to the current version.
The only problem was Template Toolkit installation (which has the .xs
stash) tried to get installed here:
ERROR: Can't create '/usr/local/lib/perl/5.8.4'
Do not have write permissions on '/usr/local/lib/perl/5.8.4'
My setup is this in .bashrc:
export PATH=$LOCAL_LIB/bin:$LOCAL_LIB/script:$PATH
perlversion=`perl -v | grep 'built for' | awk '{print $4}' |
sed -e 's/v//;'`
PERL5LIB=$LOCAL_LIB/share/perl/$perlversion:$PERL5LIB
PERL5LIB=$LOCAL_LIB/lib/perl/$perlversion:$PERL5LIB
PERL5LIB=$LOCAL_LIB/lib:$PERL5LIB
PERL5LIB=$LOCAL_LIB/lib/perl5:$PERL5LIB
export PERL5LIB
And then customize .cpan/CPAN/MyConfig.pm with:
'make_install_arg' = qq[SITEPREFIX=$ENV{LOCAL_LIB}],
'makepl_arg' = qq[INSTALLDIRS=site install_base=$ENV{LOCAL_LIB}],
So, does this need to be resolved with TT's Makefile.PL? Or would I
need an additional config setting in MyConfig.pm? Or something else?
$CPAN::Config = {
'auto_commit' = q[0],
'build_cache' = q[100],
'build_dir' = q[/home/moseley/.cpan/build],
'cache_metadata' = q[1],
'commandnumber_in_prompt' = q[1],
'cpan_home' = q[/home/moseley/.cpan],
'ftp_passive' = q[1],
'ftp_proxy' = q[],
'http_proxy' = q[],
'index_expire' = q[1],
'inhibit_startup_message' = q[0],
'keep_source_where' = q[/home/moseley/.cpan/sources],
'make_arg' = q[],
'make_install_make_command' = q[],
'mbuild_arg' = q[],
'mbuild_install_arg' = q[],
'mbuild_install_build_command' = q[./Build],
'mbuildpl_arg' = q[],
'no_proxy' = q[],
'prerequisites_policy' = q[ask],
'scan_cache' = q[atstart],
'term_ornaments' = q[1],
'urllist' = [q[http://www.perl.com/CPAN/]],
'use_sqlite' = q[0],
'make_install_arg' = qq[SITEPREFIX=$ENV{LOCAL_LIB}],
'makepl_arg' = qq[INSTALLDIRS=site install_base=$ENV{LOCAL_LIB}],
};
1;
__END__
--
Bill Moseley
[EMAIL PROTECTED]
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: CPAN testers machines that lack Module::Build
On Mar 15, 2007, at 8:54 PM, Adam Kennedy wrote: Chris Dolan wrote: M::B does not require make nor a C compiler to install or run, once you have all of its dependencies installed. That means that in theory it can be installed on a Mac that lacks the Developer Tools or on Windows with just Perl, for example. Again, neither does M:I or EU:MM (at least for the C compiler). The one difference here is make. Agreed. My mention of the C compiler was a red herring. Sorry about that. :-) What I really should have pointed out was that M::B can build XS and C modules even without make thanks largely to ExtUtils::CBuilder and ExtUtils::ParseXS. The other point I failed to make was that M::B builds itself without resorting to a Makefile, which I've always found satisfying. If you want to install modules from a source repository, you need the ability to work with source. I'd be quite (and pleasantly) surprised if the entire dependency chain of a typical catalyst application didn't involve needing a C compiler at some point. catalyst_digression It's actually not THAT bad. My Catalyst app currently needs Perl 5.8.6+ and the following non-portable/non-PARable dependencies: install PAR install Params::Validate install Date::Calc install DateTime install Encode (= 2.10) install Template::Stash::XS install DBD::mysql install Test::Exception install Config::Any install HTML::Parser install Time::Piece I know this because I develop on my Mac and deploy on Mac, FreeBSD and Linux via a single .par file. The list above are what I install by hand on each server and omit from the PAR bundle. /catalyst_digression In any case, this isn't an attack on Module::Build, just a suggestion to refer correctly to the deficiencies in other things. The known deficiencies in Module::Install should be plenty to flame about, without resorting to adding more. :) I certainly did not mean to dismiss M::I. My goal was to reinforce the uniqueness of the M::B approach among the various CPAN toolchain elements. M::I is a clever evolutionary step from EU::MM intermingled with a self-bootstrapping solution to the agony of installing prereqs. Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: CPAN testers machines that lack Module::Build
On Mar 13, 2007, at 7:41 PM, Jonathan Rockway wrote: Why don't y'all just use Module::Install? It handles build_requires, AND you can bundle modules with your dist, in case dependencies worry you. Problems solved. Regards, Jonathan Rockway Because M::I still uses make, thereby failing at one of Module::Build's primary goals: to minimize non-Perl dependencies and achieve greater portability. Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: CPAN testers machines that lack Module::Build
On Mar 11, 2007, at 7:43 AM, David Golden wrote: That said, i agree in the meantime that providing a traditional Makefile.PL along with a Build.PL is usually a wise approach, as Chris suggested. Just to expand these thoughts, every one of the modules I maintain is Module::Build-based and I've never had a smoke report that failed due to a Module::Build problem. And, yes, I'm a CPANPLUS user. If your Build.PL is fairly simple, create_makefile_pl = 'traditional' is a very reliable fallback. Both CPANPLUS and Module::Build are great ideas which have been bitten by compatibility problems. They are both trying to remove external dependencies (make, primarily) from the CPAN build process to help make that more portable and programmable. CPANPLUS handles Makefile.PL well and CPAN.pm handles Build.PL well, but the intersection of the two newer technologies, CPANPLUS and Build.PL has been more tumultuous. Please, please don't give up on either CPANPLUS and M::B! Despite some hiccups, these are important technologies that have driven the CPAN infrastructure forward. Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: CPAN testers machines that lack Module::Build
On Mar 10, 2007, at 10:04 PM, David Golden wrote: On 3/10/07, Paul LeoNerd Evans [EMAIL PROTECTED] wrote: I am getting lots of test reports from machines that don't have Module::Build installed, and so they all ultimately do something like Is there anything I as the module's author, can do about these? Short of (a) Use only Makefile.PL (b) Include Module::Build explicitly as a prerequisite of your module (c) Ignore test reports from CPANPLUS (d) create_makefile_pl = 'traditional' Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: Custom extensions to META.yml
On Mar 2, 2007, at 4:45 PM, David Golden wrote: For the META.yml spec, should anything not expressly allowed be forbidden? No. Be liberal in what you accept and conservative in what you emit. Everything is hell for back/forward compatibility. Personally, The best solution is to have an official policy for adding non-standard additions. X- is bad for reasons that many people have shared. I like the idea of a per-module special prefs area. To insure that collisions are impossible, how about a URI for the prefs wrapper like below (sorry, not sure if this is valid YAML) extensions: 'http://search.cpan.org/dist/CPAN-Reporter/': cc_author: 0 That will enable the extension mechanism to work for non-Perl code too. To me, that feels a little like the -moz-* CSS extensions that Mozilla and others use. === That said, the biggest drawback of this whole thing is that it's just one more piece of information that module authors need to think about when writing code. Writing a good CPAN module is already a fairly hefty task. I'm not saying there's an alternative, but really what we need is the module creator's equivalent of Perl Best Practices. Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: Another non-free license - PerlBuildSystem
On Feb 21, 2007, at 4:56 AM, Adam Kennedy wrote: Personally, I've always liked the idea we limit CPAN to at least something like OSI-compatible licenses. This would at least remove some ambiguity... Adam K I strongly disagree. I like the current non-policy to let anything in, but retroactively to kick out the really nasty junk. The CPAN FAQ says: CPAN and PAUSE are not responsible for any licenses or lack thereof contained in the contents of the archive. We do recommend that authors license their modules to avoid legal ambiguity and so that people may use the code in good conscience. If you require help with a license, we urge you to consult legal counsel who can give you sound advice. -- http://www.cpan.org/misc/cpan-faq.html#How_is_Perl_licensed With that statement, CPAN is absolving itself of any claim to represent only open source code. If we have an open-source-only policy, then someone needs to enforce it. Who do you think should go through all of the CPAN modules to look for non-OSI-licensed packages? Well, it looks like RT users are doing that a module at a time, but slowly: http://rt.cpan.org/Search/Results.html?Query=Subject+LIKE +'license'Order=DESCOrderBy=Status For a while Path-Class, Archive-Any and even Encode all lacked license statements. Happily these are now fixed, but if a policy like what you propose had been in place they would have not been allowed in CPAN, much to everyone's loss. http://rt.cpan.org/Ticket/Display.html?id=9203 http://rt.cpan.org/Ticket/Display.html?id=14896 http://rt.cpan.org/Ticket/Display.html?id=19056 Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: Another non-free license - PerlBuildSystem
On Feb 21, 2007, at 5:37 PM, A. Pagaltzis wrote: * Chris Dolan [EMAIL PROTECTED] [2007-02-21 16:00]: For a while Path-Class, Archive-Any and even Encode all lacked license statements. Happily these are now fixed, but if a policy like what you propose had been in place they would have not been allowed in CPAN, much to everyone's loss. You mean the authors of these modules would have taken their ball and gone home, instead of just fixing their lack of licence and reuploading? :-) True enough. You've poked a gaping hole in my argument. Although I've declared I'm in favor of the ad hoc system that is in place now, I would not be opposed to a PAUSE rule that required every upload to contain a LICENSE or COPYING file. That would certainly have made my Module::License::Report package easier to write! Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: Delete hate speech module
On Feb 8, 2007, at 11:48 AM, Tim Maher wrote: On Thu, Feb 08, 2007 at 08:58:01AM -0800, alan wrote: On a more serious side, getting rid of it [Time::Cubic] should be pretty open and shut. CPAN is a public resource managed by private entities. I'm generally against the idea of censorship in all its forms, and /definitely/ against the idea of removing a Perl module from CPAN just because something *within the code* offended somebody--or even lots of somebodies! I support the idea that a CPAN author has the right to write his (her, etc.) code *any way he wants*/--which includes the use of comments that might appear scurrilous to some (which appears to be the complaint against Time::Cubic). Yes, the author may have the right to write that code, but does CPAN have the obligation to host it? What's the alternative? That we have every CPAN Module scanned for offensive components, including comments (# shit happens!), variable names ($KKK), variable names (my $ugly_female_boss), and statement labels? (NUKE_OJ_BUSH_AND_OSAMA: for $ever) The alternative is that the powers-that-be respond to the community's requests on a case-by-case basis using their own judgment. Proactive scanning/moderation would clearly be impractical and has been rejected on previous occasions on this list. Wouldn't we be better off investing our collective JAPHly energies in the expanding our market share and completion of Perl 6 and rather than the creation of Regexp::Common::Enforce_Code_Nazi_Policies? Personally, I think fighting hatred is a more worthwhile use of energy than finishing Perl 6. offtopicYour choice of the word Nazi is conspicuous given the ASCII art in the Time::Cubic comments./offtopic If we /were/ to become Code Nazis, the slippery-slope that we'd be embarking on would unavoidably affect many eccentric modules which people value (Regexp::Common::profanity_us, Tie:Hash::Cannabinol, etc.). Is the slope really that slippery? I doubt that anyone here finds any value in the Time::Cubic module. Furthermore, I have not heard anyone complain about those other modules you mention. I don't think anybody has proposed a blanket policy against offensive modules. Instead, the requests I've seen so far are simply to remove Time::Cubic from CPAN. I think your invocation of the slippery slope argument is fallacious, and I have confidence in the CPAN community's collective wisdom to call for the removal of only truly inappropriate modules. I realize that some CPAN users live in countries where people have strict limits on their freedom of expression, and I empathize with those who have taken offense at someone else's indulgences of their unbridled liberties. But remember, Perl is the language that has a poetry mode! It's designed for those who value unfettered self expression. Sure, but how does that translate into CPAN must host all crap thrown at it? Chris
Re: Delete hate speech module
On Feb 8, 2007, at 11:48 AM, Tim Maher wrote: On Thu, Feb 08, 2007 at 08:58:01AM -0800, alan wrote: On a more serious side, getting rid of it [Time::Cubic] should be pretty open and shut. CPAN is a public resource managed by private entities. I'm generally against the idea of censorship in all its forms, and /definitely/ against the idea of removing a Perl module from CPAN just because something *within the code* offended somebody--or even lots of somebodies! I support the idea that a CPAN author has the right to write his (her, etc.) code *any way he wants*/--which includes the use of comments that might appear scurrilous to some (which appears to be the complaint against Time::Cubic). Yes, the author may have the right to write that code, but does CPAN have the obligation to host it? What's the alternative? That we have every CPAN Module scanned for offensive components, including comments (# shit happens!), variable names ($KKK), variable names (my $ugly_female_boss), and statement labels? (NUKE_OJ_BUSH_AND_OSAMA: for $ever) The alternative is that the powers-that-be respond to the community's requests on a case-by-case basis using their own judgment. Proactive scanning/moderation would clearly be impractical and has been rejected on previous occasions on this list. Wouldn't we be better off investing our collective JAPHly energies in the expanding our market share and completion of Perl 6 and rather than the creation of Regexp::Common::Enforce_Code_Nazi_Policies? Personally, I think fighting hatred is a more worthwhile use of energy than finishing Perl 6. offtopicYour choice of the word Nazi is conspicuous given the ASCII art in the Time::Cubic comments./offtopic If we /were/ to become Code Nazis, the slippery-slope that we'd be embarking on would unavoidably affect many eccentric modules which people value (Regexp::Common::profanity_us, Tie:Hash::Cannabinol, etc.). Is the slope really that slippery? I doubt that anyone here finds any value in the Time::Cubic module. Furthermore, I have not heard anyone complain about those other modules you mention. I don't think anybody has proposed a blanket policy against offensive modules. Instead, the requests I've seen so far are simply to remove Time::Cubic from CPAN. I think your invocation of the slippery slope argument is fallacious, and I have confidence in the CPAN community's collective wisdom to call for the removal of only truly inappropriate modules. I realize that some CPAN users live in countries where people have strict limits on their freedom of expression, and I empathize with those who have taken offense at someone else's indulgences of their unbridled liberties. But remember, Perl is the language that has a poetry mode! It's designed for those who value unfettered self expression. Sure, but how does that translate into CPAN must host all crap thrown at it? Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: Delete hate speech module
On Feb 8, 2007, at 9:24 AM, IvorW wrote: Ahah, now I see the correct module name, I can browse the source and see what the issue is. The only difficulty is that the module could be somebody's incredibly poor taste sick joke, and people could raise the old chestnut argument about free speech. Free speech varies by country, but generally only applies to public venues. While CPAN may seem like a public resource because it generously hosts content for so many module authors, it is not a public venue and free speech laws certainly do not apply. Chris -- Chris Dolan, Equilibrious LLC, http://equilibrious.net/ Public key: http://chrisdolan.net/public.key vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: Dependency trees
On Jul 20, 2006, at 10:24 PM, Andy Lester wrote: Is there anything out there that will generate a tree of dependencies, probably based on META.yml? I figure I can pass in Mason, Test::WWW::Mechanize and Catalyst and get back a list of dependencies that those require. It would be the entire tree, so like so: Test::WWW::Mechanize Test::Builder WWW::Mechanize LWP::UserAgent HTTP::Response HTML::Form HTML::Tree Blah::Blah Test::LongString Test::Builder Blah::Blah If it doesn't exist, I'll write it. I just don't want to reinvent the wheel. Others have mentioned good candidates, but I thought I'd mention my own... I've done something not-exactly-like-that in Module::License::Report: % license-report -a Module::License::Report perl CPANPLUS unrestricted File-Slurp perl Module-License-Report perl YAML % license-report -a Test::WWW::Mechanize Can't find a license for Test::LongString perl Carp-Assert perl Carp-Assert-More perl HTML-Parser perl HTML-Tagset perl HTTP-Server-Simple perl Test-Exception perl Test-WWW-Mechanize perl URI perl WWW-Mechanize perl libwww-perl Something like that could be adapted to your purpose, maybe. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: GraphViz , Leon Brocard (acme)
On Jul 1, 2006, at 7:21 PM, Jogi Kuenstner wrote: Hi, I recently submitted a patch to the author of Graphviz : Leon Brocard (acme) via the given email-adress in the module. Unfortunately he didn't respond. Does anyone have another way to contact him? I assume my mails got lost in his spam-filter. Regards Jogi Leon is sometimes slow to respond (aren't we all?), but in my experience he does always respond eventually. He has a lot going on. For example, I've worked with Leon on Net::VNC and Image::Imlib2 quite a bit in the last 3 months. As others have said, rt.cpan.org is the best place to submit patches. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Preserving Supplementary Documentation for Modules
On May 12, 2006, at 9:03 AM, David Golden wrote: John M. Gamble wrote: CPAN, of course, is eternal, but putting the pdf in a module that is only a tenth its size would be an undue burden on downloaders, not to mention the lack of a clear policy on this. How big is the PDF? If it could be optimized down to the 100K range or less, I wouldn't really think twice about undue burden. So. Is there, or could there be, a separate spot on CPAN for supplemental documentation like PDF files and graphics files? Has this ever been discussed before? My immediate thought it to just bundle it in another distribution, e.g. Math-Polynomial-Solve-Docs. Give that a regular distribution skeleton with a Pod file that describes what it is and where it is in the distribution. I think that if you create a pdf/ directory and put the file in there, it will get picked up as part of other files by search.cpan.org. Then just reference Math::Polynomial::Solve::Docs in your main Pod file. If you want to get really fancy, you could also configure a CPAN install tool to install the PDF in the perl library path for local browsing. (See the Module::Build::Cookbook for some examples). Regards, David Golden I agree with David in terms of size, but license may be a bigger problem. Unless the author of the PDF explicitly gave you permission to release under the same terms as Perl itself (or whatever license you have chosen for your code) you may need to follow the advice above and bundle it as a separate upload with a different license. In that case, you might consider making it a real Bundle so installing Math-Polynomial-Solve-Docs automatically installs Math- Polynomial-Solve too. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: maintainer for PGP::Mail
On Apr 20, 2006, at 8:02 AM, Patrik Wallstrom wrote: On Thu, 20 Apr 2006, Nicholas Clark wrote: On Thu, Apr 20, 2006 at 02:49:51PM +0200, Patrik Wallstrom wrote: Does anybody here know how to reach [EMAIL PROTECTED] How have you tried contacting him, and how has it failed? Yes, through that address three weeks ago. No response or bounce. If that author is anything like me, he probably put the message in his TODO email box and then forgot about it. Try sending it again. Or perhaps a spam filter caught it. In any case, three weeks isn't that long a time in volunteer land. Another good option is to post to to rt.cpan.org. Sometime RT email gets more attention because it's publicly visible. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Naming advice: parse info out of Build.PL/Makefile.PL
On Mar 10, 2006, at 2:45 PM, brian d foy wrote:
I haven't been following the Module::Build stuff closely, but I've
always wondered about these sorts of intricate solutions. Shouldn't it
be enough to temporarily replace ExtUtils::Makemaker with something
that has the same interface and spits out a Build.PL and a META.yml? I
do something similar with Test::Prereq to see what's in PREREQ_PM.
No, because when you run Makefile.PL you only get the *output* of
that program. If it has any non-trivial code, then EU::MM is only
seeing the reduction of that content. For example, this cruddy code
exists in one my own older Makefile.PL files:
open my $fh, 'MANIFEST' || die;
my @exefiles = grep {s/\s.*$//; /^scripts\/.*\.pl)$/} $fh;
close $fh;
...
'EXE_FILES' = [EMAIL PROTECTED],
EU::MM only sees
'EXE_FILES' = ['foo.pl', 'bar.pl', ...],
My proposed module would flag that Makefile.PL as non-trivial and
recommend that the author convert it by hand. I've tried doing this
via regexps in the past, but it's too messy. So this time I'm going
to try with PPI. The idea is to make it NOT intricate if possible.
We'll see. I haven't written the code yet...
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Naming advice: parse info out of Build.PL/Makefile.PL
I'm going to write a module that uses PPI to parse Build.PL and Makefile.PL files without executing them. The goal of the project is to deduce information like version, dist name, author, abstract, prereqs, etc. from (possibly untrusted) packages that have incomplete or absent META.yml files. Clearly, only a subset of Build.PL and Makefile.PL files will be easily digestable, but that's expected. My expectations for the use cases for this module will be: * Simply automatic translation of legacy Makefile.PL files into Build.PL files * Extract info from modules that lack META.yml files * Further indexing of CPAN and for my own Module::License::Report project * Exposing license information for CPAN modules to simply redistribution My current ideas for names: PPIx::Buildfile PPIx::BuildPL/PPIx::MakefilePL Package::Buildfile Module::Info::Buildfile Module::Info::BuildPL/Module::Info::MakefilePL Module::Info::PPI::Buildfile Module::Info::PPI::BuildPL/Module::Info::MakefilePL Really this project analyzes packages, not modules, but the Module:: namespace seems to be preferred over Package:: on CPAN. (or am I mistaken?) Thanks, Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [RFC] ASNMTAP
Alex, I think what Frank is saying is that your license forbids CPAN from distributing or mirroring your package without your explicit permission. That means that CPAN can't let anybody download it without violating your license. If that's so, what's the point? I personally suggest you consider one of the more well-known licenses: http://search.cpan.org/~kwilliams/Module-Build/lib/Module/Build/ Authoring.pod#license In that classification, yours clearly falls in the category of restrictive But, of course, I respect whatever choice you make. Chris On Jan 31, 2006, at 3:16 PM, Alex Peeters wrote: Hi Frank, This is the licence that i did use for the Application Monitor. For the ASNMTAP and Nagios compatible CPAN modules you may suggest a good licence and i will use it. - Alex -Original Message- From: Frank Wiles [mailto:[EMAIL PROTECTED] Sent: dinsdag 31 januari 2006 20:14 To: ZXR750 Cc: module-authors@perl.org; [EMAIL PROTECTED] Subject: Re: [RFC] ASNMTAP On 31 Jan 2006 01:39:44 -0800 ZXR750 [EMAIL PROTECTED] wrote: =head1 LICENSE ASNMTAP may be used and modified free of charge by anyone so long as this copyright notice and the comments above remain intact. By using this code you agree to indemnify Alex Peeters from any liability that might arise from it's use. Selling the code for this program without prior written consent is expressly forbidden. In other words, please ask first before you try and make money off of my program. Obtain permission before redistributing this software over the Internet or in any other medium. In all cases copyright and header must remain intact. It is entirely up to you as the author, but this license is going to drasticly limit the number of people who can and/or will use this module. - Frank Wiles [EMAIL PROTECTED] http://www.wiles.org - -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [RFC] Samba::LDAP namespace?
On Jan 16, 2006, at 3:13 PM, David Landgren wrote: Gavin Henry a écrit : Dear List, I would like your opinion on the namespace: Samba::LDAP then Samba::LDAP::Group Samba::LDAP::Password Samba::LDAP::User I want to do this as I am halfway through writing an application called SOSA - Samba and Open-xchange Simple Administrator using Catalyst (which is to be released GPL) and I don't want to have to rely on the command line smbldap tools from idealx being installed, so I want to CPAN- ize them and have the modules installable from there. Smb seems to be more common on CPAN, as well as most package systems I am familiar with. I would be inclined to go with Net::Smb::LDAP, which leaves open the possibility that someone could do something useful with Net::Smb. To elaborate on what I think David is saying, you should be careful about the distinction between SMB (a network filesystem specification) and Samba (an open source implementation of SMB). If your package works ONLY with Samba, then that name is OK. If you intend that it will work with other SMB implementations, use Smb. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: New module: FLV file parsing
On Dec 2, 2005, at 4:20 PM, Austin Schutz wrote: On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: The FF:: namespace is a terrible idea, in my opinion. I expect that it will be meaningless to the majority of module searchers. The argument that search makes names irrelevant is just silly. ..because? Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? No. I concur that the module name is effectively meaningless, but I don't see that it makes any difference to the searcher. Nitpick: FLV is not Flash. FLV is a video format that is often used by Flash movies, but it is not Flash and does not work standalone without a Flash movie to control it. SWF is the file format for Flash movies. It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, but beyond that, what tangible and practical difference does it make? You assume that all authors discover modules solely through search.cpan.org? I often discover modules by reading other people's code and seeing what modules they use. If I see use FF::FOOBAR at the top of someone's module, I will have no idea what they are trying to do. But if I see, say FileFormat::Video::FOOBAR then at least I will know the author is trying to interact with a stream of video data. To me, it's as much about readable code as it is about findable modules. If that were true, the practice of bouncing name ideas off this email list would cease, and I'd just name it FLV.pm. As I understand it there's some rationale for keeping the top level namespace small, so that would probably not be a good choice. Beyond that, name it what you will. I submit these long threads about which module name is better than some other similar name are a waste of time, and I do indeed suggest we take them off list as a general rule. Austin I strongly disagree. I think good naming is important for readability and maintainability. Like good variable and method names, module names should be self-documenting whenever feasible. Since module names are harder to change than variable or method names, I say a little forethought and discussion is justified. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: When CPAN shell cannot find a module
On Nov 21, 2005, at 10:51 AM, Christopher Hicks wrote: On Sun, 20 Nov 2005, Andreas J. Koenig wrote: I don't think many people would appreciate getting something installed they didn't explicitly ask for. Hmmm. I can have extra pain every time I'm installing something to avoid occassionally getting something I don't want or I can have pain every thousandth time I install something because oopsie I got something extra. It doesn't seem like a hard choice to me. Let's just say your many people aren't the same folks as my any people. ;-) The lack of distname support due to anal retentive accident avoidance in CPAN is utterly odd considering the culture of DWIMery that is so much a part of Perl. I'm not surprised that one person would think this was good, but the whole Perl community acquiescing to it is quite a shock. Chris, If CPAN made it easy to install unintended software by mistake, that would be a huge security hole. Some people run cpan as root. Defensive programming is absolutely the right thing here. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Name advice: check license of dependencies
Thanks for the feedback Mark and Sam. I chose Module::License::Report and posted my implementation to CPAN this afternoon. Further feedback would be VERY welcome, as the module uses a few sketchy heuristics to guess at the license. To mitigate the uncertainty, I made it report a confidence number so the user can set a sketchiness threshold. The confidence is just a guess, but it's better than nothing. I'm thinking the next version should use multiple algorithms to guess the license and report higher confidence if they all agree. On a side note, I discovered that using Data::Dumper on my output object causes memory use to go through the roof. I think Data::Dumper is chasing into the CPANPLUS data structures and thrashing my machine. Is anyone familiar enough with CPANPLUS internals to know whether Data::Dumper problems are well known, or if I've stumbled on some new bug? Thanks all, Chris On Oct 31, 2005, at 2:51 PM, Sam Vilain wrote: On Mon, 2005-10-31 at 11:20 -0500, Mark Stosberg wrote: I don't like any of the names I've come up with so far. It seems clear that it should be in the Module:: namespace, but beyond that I'm unsure. Possibilities: Module::GuessLicense Module::License Module::LicenseChain Module::DistributionRights From your description, this is much as about a module's dependencies as it as a about a specific module. So I'll suggest: Module::Depends::LicenseReport Including Report signifies that the module has a read-only purpose. On the other hand, a license might be seen to implicitly imply dependency on all of the things that it depends on (esp. if any are GPL). I think your point is very valid, and perhaps the logic for figuring a module's dependencies recursively should be available independently from the logic to show the license for an individual module. So, perhaps Module::Depends and Module::License Module::License::(Report|Chain|...) Sam. -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Name advice: check license of dependencies
I'm toying with starting a new module and would like some naming advice. My module will accept the name of another module and, using CPAN metadata and/or package contents, determine the license of that module's package and the license of all non-core packages that it in turn depends on. This module would be useful for determining redistribution rights for aggregations of code, like PAR files. It will probably employ CPANPLUS, YAML, Module::Depends, Module::Corelist and a bunch of heuristics to make its determination. For example, my module CAM::PDF is Artistic/GPL but it depends on Text::PDF which is just Artistic. This new module would help me to discover that fact. I don't like any of the names I've come up with so far. It seems clear that it should be in the Module:: namespace, but beyond that I'm unsure. Possibilities: Module::GuessLicense Module::License Module::LicenseChain Module::DistributionRights Thanks, Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Releasing slower pure-perl module and faster Inline::C version
Hi Scott,
Here's how I would try implementing it as one module instead of two.
I'm not sure if this is the best approach -- I'd be interested to
hear if other authors have done anything like this. Use
Module::Build, and have a block like:
recommends = { Inline::C = 0 },
Then in the module do this:
eval {
require Inline;
import Inline C = DATA;
};
if ($@) {
*great_circle = sub { ... pure perl implementation ... };
} else {
*great_circle = sub { ... wrapper for C function ... };
}
__DATA___
... C implementation ...
That way, anyone who installs Inline::C either before or after
installing your module gets the speed boost. The biggest risk, as I
see it, is if the two implementations are not quite identical. But
some good regression tests could ameliorate that. To help with that,
there's a new CPAN module called Devel::Hide that can make your test
code think that Inline::C is not installed.
Chris
On Oct 16, 2005, at 12:30 AM, Scott W Gifford wrote:
Hello,
Some quick background: I've got some code I use that does a lot of
distance calculations. I found that a limiting factor for me was the
time it took to do a great circle calculation, a trigonometric
calculation of the distance along the surface of a sphere (see
Math::Trig::great_circle_distance). I rewrote that function in C
using Inline::C, and achieved a substantial speedup (a 300% speedup
for the great circle calculation, resulting in about 30% overall
speedup). So I actually do have an application that cares about the
speed of this function, and I have benchmarked and the Inline::C
version is substantially faster.
I'm interested in releasing the Inline::C version of this code.
Because it's often called from within modules, I'd like to make it
easy for module authors to use the accelerated version if it's
available, but without limiting their support to platforms that have a
compiler and Inline::C.
I think the easiest way to do this would be to release the Inline::C
version as Math::GreatCircle::Fast and a pure-perl version as
Math::GreatCircle. Math::GreatCircle would check for an installation
of Math::GreatCircle::Fast, and if it found it would override all of
its own functions with the C equivalents from the accelerated module.
That would allow module authors to simply say use Math::GreatCircle
in their module and PREREQ_PM = {Math::GreatCircle=0} in their
Makefile.PL, and they'd get the fast version if it was available,
without having any dependencies on Inline::C or a compiler. If a user
needed the faster distance calculations, they could install
Math::GreatCircle::Fast; otherwise things would still work OK, but a
little slower.
The functionality of Math::GreatCircle would be pretty much the same
as Math::Trig's great circle functions; primarily it's a wrapper for
Math::GreatCircle::Fast.
Does anybody see any problems with, or have any objections to, this
approach?
Thanks for any thoughts,
---ScottG.
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Checking for boilerplate
On Aug 24, 2005, at 7:46 AM, Ken Williams wrote: On Aug 22, 2005, at 2:07 PM, Andy Lester wrote: RJBS and I are going to put some tests into Module::Starter to check for boilerplate. Watch for it tomorrow, maybe tonight. Personally I still don't think that's the best place for it. Why make all the people who *download* your module check something that should be checked at make dist time? Did people not like the idea of putting these checks as plugins into Module::Release? I strongly suspect that the people who use Module::Release are not the ones uploading modules with boilerplate. Putting the test in Module::Release is a good idea, but it would not abate the primary problem under discussion. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Checking for boilerplate
On Aug 24, 2005, at 10:56 AM, Andy Lester wrote: Remember, CPAN thrives BECAUSE we allow unfettered uploading of shit, not in spite of it. Now there's a quote that needs to be added to the use.perl.org footer rotation. :-) Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Help with naming: ASDoc to POD conversion
On Aug 10, 2005, at 12:28 AM, A. Pagaltzis wrote: * Chris Dolan [EMAIL PROTECTED] [2005-08-09 17:05]: I like to Pod:: namespace, but that's mostly for modules that convert from POD, not to POD. One exception is Pod::HTML2Pod, which leads me to one option: Pod::ASDoc2Pod [snip] I do think the Pod:: namespace is appropriate for this. The primary purpose of the module has to do with POD, so that’s where it should be filed. I don’t like the 2Pod bit – both for the (common and established; unfortunately) abuse of “2” just to save a character as well as because the “to POD” part really is redundant. What you want is a simple “From.” I also think the “AS” acronym is way too opaque for this. I’m not sure it needs to mention “Doc,” though “Javadoc” would be too much. So I’d say this module’s name is Pod::FromActionScriptDoc or if you think it’s unambiguous enough, maybe Pod::FromActionScript both of which are plain, descriptive and memorable. Thanks much, Aristotle! I like your latter suggestion and will go with that. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Help with naming: ASDoc to POD conversion
I am working on a module that converts Flash Actionscript documentation (an informal variant of Javadoc) to POD. What would be a good name for this? I like to Pod:: namespace, but that's mostly for modules that convert from POD, not to POD. One exception is Pod::HTML2Pod, which leads me to one option: Pod::ASDoc2Pod Any other ideas? Good words to pick from: Actionscript, ASDoc, JavaDoc, Pod, Text. Since this is just a text = text conversion, names that include Flash or SWF are not appropriate, I think. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Regexp code feature
On Jul 25, 2005, at 10:59 AM, David Landren wrote:
Note that $^R is broken. It won't be set correctly in cases like
'ab' =~ /^a(?{1})(?:b(?{2}))?$/
In this case $^R will be set to 1 instead of 2. I have filed a bug
report on this, but I doubt it will ever get fixed unless Dave
Mitchell find a pile of tuits. That said, looking at your problem
domain, I'm not sure you'll encounter optional tails.
Plugging my own module here, you might find that Regexp::Assemble, in
its tracked pattern mode, will do all that you need, and works
around this bug. This should help save you a certain amount of
development time.
Thanks for the info, David. No, it should not affect my code,
fortunately. My regexps are designed so that at most one code block is
hit, right at the end of the match (they are all at the end of a series
of literals).
This is exactly the sort of feedback I was hoping to see, however. May
I recommend that you add a note about that $^R problem to the docs at
annocpan.org?
http://annocpan.org/~NWCLARK/perl-5.8.7/pod/perlre.pod
I did look at Regexp::Assemble at Sébastien's suggestion. It looks
very powerful. My problem space is much simpler than that module is
trying to address, however, so constructing a binary tree to represent
the IP ranges and building my regexps from that tree was
straightforward (and performant) in about 30 lines of code.
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Regexp code feature
On Jul 21, 2005, at 3:17 PM, A. Pagaltzis wrote:
* Chris Dolan [EMAIL PROTECTED] [2005-07-21 22:05]:
What's the minimum version of Perl needed to reliably exploit the (?{
code }) feature in regexps?
You can check at http://search.cpan.org/dist/perl/. The first
version where pelre documents this feature is 5.005.
Though as far as “reliably” is concerned: it has never lost its
“experimental” status. Even if I doubt that it would be removed
from Perl5 at this point.
Thanks, Aristotle.
After checking that URL, I've confirmed that 5.005 probably *could*
work, but I've successfully tested my module on 5.6.0 and called that
good enough (since I use our, etc). I've uploaded
Net::IP::Match::Regexp to CPAN.
Yes, I see your point about the experimental status. Well, it's the
only way I could think of to implement varying return values via the
regexp. I'm using only the most basic aspect of the (?{code}) feature,
so I'm safe unless someone takes $^R away from me. :-)
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Namespace Advice
On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote: I would suggest now to name the module Win32::Storage::ReadSummaryInfo. I like this better than before, but why not Win32::Document::SummaryInfo? Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Re: How to force tests to issue NA reports?
On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote: Is there a way tests to determine that a module cannot be installed on a platform so that CPANPLUS or CPAN::YACSmoke can issue an NA (Not Applicable) report? CPANPLUS relies on module names (e.g. Solaris:: or Win32::) but that is not always appropriate in cases where a module runs on many platforms except some that do not have the capability. There's also a separate issue of whether NA reports should be issued if a library is missing. (Usually these come out as failures.) Regards, Rob (Co-author of CPAN::YACSmoke) It won't help you *today* but there is a proposed META.yml field called excludes_os which fits your request perfectly. http://module-build.sourceforge.net/META-spec-new.html#excludes_os See also optional_features.foo.excludes_os http://module-build.sourceforge.net/META-spec-new.html#recommends Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Re: Namespace Advice
On Apr 7, 2005, at 8:28 AM, Reinhard Pagitsch wrote: Hello Chris, Chris Dolan wrote: On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote: I would suggest now to name the module Win32::Storage::ReadSummaryInfo. I like this better than before, but why not Win32::Document::SummaryInfo? Because not only MS documents can be read? There is also the possibility to read the summary informations from text and and other files, if there is a summary information available. Reinhard Hmm, I think it must be my Mac experience showing through. I'll defer in this case, but permit me to further detail my thoughts anyway... When I think Document I mentally include any non-active file, including MS Office files, text files, PDF files, etc. but excluding executables. To me Win32::Storage and Win32::File suggest the manifestation of the file in the filesystem, not the the contents of that file. But perhaps my vocabulary of simply off base. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Re: Namespace Advice
On Apr 5, 2005, at 2:44 AM, Reinhard Pagitsch wrote: Win32::File::Prop - Perl extension read property informations from MS compound files and normal files, if the properties are set. Question: Is this really Win32 specific? Are you using Windows-only functionality, or would this module work fine on non-Windows computers (like the Excel and OLE modules do)? I think Document may be better than File in this case. My first impression was that Win32::File::Prop is would interact with Windows filesystem properties, like permissions, hidden flags, ownership, etc. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Re: lib::http - Using virtually a Perl library from the Internet with the HTTP protocol.
Check out PAR. I believe it can do exactly what you are describing. It resembles Java's JAR concept, and it supports the ability specify remote archives of packages. Chris On Feb 20, 2005, at 7:14 PM, Graciliano M. P. wrote: Felow PM Authors, Recently I was developing a new module, called lib::http, where is possible to use a Perl library installed in other server over the internet. Also with this release is distributed a modified Perl interpreter, actually a modified TinyPerl, that doesn't have any lib, but with it is possible to use a full perl installation over the internet. The main idea is to use Perl without need to install anything, and to have a central point to load modules, where is possible to update a full grid of servers changing only a single place. So, we can update all the services writed in Perl that works in our grid changing a single Perl installation, what is much more faster, and as a plus we can hide some modules, since we can tell to load this modules only in the memory, without need to store them fisically in the server. lib::http was created only in the last week and still need tests, of course, but it's working very well, and already have support for gzip compression, index of a perl library in the server side, and works in any simple HTTP server. You can find it at: http://search.cpan.org/~gmpassos/lib-http-0.01/lib/lib/http.pm Enjoy! ;-P Regards, Graciliano M. P. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 18/2/2005 -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Re: MySQL::Backup?
Assuming it is based on DBI at its core, your module would fit better in the DBI extension area. I think DBIx::Backup::MySQL would be good, as it would leave room for expansions to databases other than ::MySQL. Chris On Oct 25, 2004, at 3:00 PM, Sean Quinlan wrote: Good afternoon, I've been working on a tool for automating log rotations and database dumps for MySQL. This started during system administration discussions in a development group I was in at MGH quite a while ago, and a few people were involved in writing the first versions. I've just recently gotten back to working on it again. I now have a working version that is being tested at a couple of sites. I would be happy to send it to anyone (or the list) on request. It has three components, a module, a conf file and a tiny script for initiating backups, generally to be run by daily cron job. The documentation is scattered about a bit still, but should be functionally correct. I would welcome any feedback on the module name. I've got it as MySQL::Backup at the moment, and don't see anything currently on CPAN in that name space. Does anyone have any other recommendations or concerns before I upload it to PAUSE? Thanks! -- Sean Quinlan [EMAIL PROTECTED] -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, 313 W Beltline Hwy Suite 41, Madison WI 53713 PGP.sig Description: This is a digitally signed message part
Re: Application mechanizing
Thanks for the feedback. I will use Win32::Automate::app and I encourage others to use the same pattern in the future. Chris On Thursday, April 22, 2004, at 06:56 PM, Gabor Szabo wrote: The Win32:: namspace is also quite established to applications specific to that platform so if the underlying application is Windows specific I think using Win32:: would be a good idea. I'd understand more something like Win32::Automate::app or Win32::Drive::app. less than 2c. Gabor -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, 211 S Paterson Suite 260, Madison WI 53703 PGP.sig Description: This is a digitally signed message part
Application mechanizing
Authors, Using the handy Win32::GuiTest module, I'm automating control of a particular Windows application which lacks a specific command line or scriptable interface. (We're still unclear on licensing issues, so forgive for simply calling it app instead of it's real name) What sort of name would be good? I'm thinking about something like category::app::behavior or category::behavior::app, where category = Win32, GUI, UI, App, ... behavior = Mechanize, Automate, Truss, Script, ... E.g.: Win32::app::Mechanize App::Automate::app Alternatively, it could simply be app::Mechanize, but that creates a new top-level space for every application, which I'd like to avoid. Surely there's a module which has already explored this conceptual space, but I can't find a similar example yet which doesn't just create a new top-level name for the application. Win32::IE::Mechanize is the closest I've seen with a good name, but it definitely has a different goal (it's not really an application truss). Thanks! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, 211 S Paterson Suite 260, Madison WI 53703 PGP.sig Description: This is a digitally signed message part
Debugging unfamiliar platforms
I'm maintaining a module, CGI::Compress::Gzip, which does auto-compressed output at for CGI scripts. The module works very well for me under Linux, BSD and MacOSX, but I keep getting automated reports from CPANPLUS that the module fails under Solaris and/or Windows. I've tried replying to the bug report emails asking questions about the environment but, not surprisingly, I haven't gotten an answer. I don't have easy access to a Solaris or Windows environment for testing Perl modules, so I have not been able to reproduce the bug reports. How do others out there deal with module maintenance for platforms you don't support locally? Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. [EMAIL PROTECTED], 294-7900, 211 S Paterson, Madison WI 53703
