Re: What hurts you the most in Perl?
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 Didn't see these. But one of my problems is that the programs I wanted to debug are daemons or code running in an embedded Perl (within Nagios in my case). Many of the existing tools rely on eval'ing the code or rely on an END block being executed, making them a bit hard to use in the case of embedded code.. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: What hurts you the most in Perl?
Gabor Szabo wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. When in need to execute things in parallels, I use fork() or POE. 2) Using signals and signal handlers regularly crashes perl. I don't remember seeing regular crash because of signals. I even wrote some badly designed daemons which relied on a heavy use of signals. They had bugs, but not because of the signals per se. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. I still have not been bitten yet by this. Probably because I don't have heavy OO needs. And if I did, I would now use Moose. So I wonder what hurts *you* the most in Perl? 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. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: CPAN Index Version Problem with Sys-Syslog-0.26.tar.gz
Andreas J. Koenig wrote: On Mon, 16 Jun 2008 13:13:05 +0800, imacat [EMAIL PROTECTED] said: Dear all, This is imacat from Taiwan. I wonder who should I report this problem to. The CPAN index seems to have a problem indexing Sys-Syslog-0.26.tar.gz. The Sys::Syslog in Sys-Syslog-0.26.tar.gz should be of version 0.26, but not 0.25. [EMAIL PROTECTED] CPAN/modules % gunzip -c 02packages.details.txt.gz| grep Sys-Syslog Sys::Syslog0.25 S/SA/SAPER/Sys- Syslog-0.26.tar.gz Sys::Syslog::Win32undef S/SA/SAPER/Sys- Syslog-0.24.tar.gz Sys::SyslogMessages0.02 J/JU/JUDITH/Sys- SyslogMessages-0.02.tar.gz [EMAIL PROTECTED] CPAN/modules % This time the problem does not look like the previous ones. I tried to look into the Syslog.pm. It is indeed 0.26, with a clean version text that is parsable with ExtUtils::MakeMaker: [EMAIL PROTECTED] /tmp/Sys-Syslog-0.26 % perl -MExtUtils::MakeMaker -le 'print MM-parse_version(shift)' Syslog.pm 0.26 [EMAIL PROTECTED] /tmp/Sys-Syslog-0.26 % The result is that the CPAN shell r and upgrade commands fails to recognize this update. Does anyone know where should I address this problem to? Thank you. The bug is in the META.yml. The 0.25 comes from there. Yes, sorry for uploading with a buggy META.yml. I saw it only once I sent the patch to P5P and began working on ExtUtils::Constant, for which I was copying things from Sys::Syslog's makefile.PL Given PAUSE didn't give any errors, I thought nobody would see it, allowing me to carpet it during the next release. I guess I was wrong. Thanks Imacat for noticing this. Andreas, are you able to fix it or do you prefer me to upload a fixed release, with a new version? -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: CPAN Index Version Problem with Sys-Syslog-0.26.tar.gz
Andreas J. Koenig wrote: On Tue, 17 Jun 2008 00:42:36 +0200, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] said: Andreas, are you able to fix it or do you prefer me to upload a fixed release, with a new version? Fixing this manually was a breeze, so I did it. The new index file is already on its way through CPAN. Thank you. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: shipping extra files in a dist?
Jerome Quelin wrote:
hi there,
i'm writing a tk app that i'm shipping as a cpan dist. this app needs
some extra resource files (icons, etc) i'd like to know what's the best
method to ship extra data files in a dist.
where to put them in the dist tar file:
- create a data subdir under lib/Foo/Bar (assuming it's dist Foo::Bar).
in that case, do they get installed automatically, even if not pm
files?
- create a data subdir at the top level, and use sthg like this in
Makefile.PL:
PM = {
'data/foo.data' = '$(INST_LIB)/Foo/Bar/foo.data',
...
},
- anything else?
You can also define a MY::postamble() for this task:
» http://use.perl.org/~Maddingue/journal/34682
Of course, Michael Schwern doesn't like such extensions for obvious
reasons ;-)
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.
Re: Changing the focus of the chronic CPAN problem
Jonathan Rockway wrote: * On Sat, Apr 05 2008, Eric Wilhelm wrote: It appears that our current strategy is this: * rely on a proprietary web application for search (search.cpan.org) I like kobesearch better. I hear the code for that is available, which is the main reason I like it better :) I haven't actually looked at the code yet though (or talked to Mr Kobes). It is available on the CPAN: » http://cpan.uwinnipeg.ca/dist/CPAN-Search-Lite -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
Andreas J. Koenig wrote: On Thu, 31 Jan 2008 23:44:37 +0100, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] said: While checking the reports of my modules, I see from time to time FAIL reports that weren't sent to me by mail. Some of these reports were even useful to me. You could try if MARCEL/App-sync_cpantesters-0.04.tar.gz fits your needs. Just installed it. It seems to DTRT. Thanks for pointing. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
David Cantrell a écrit : There is one crucial difference between the CPAN testers and real spammers though - we actually care what authors think. Upgrading to a version of CPAN::Reporter that supports the skip file is on my to-do list, and you can rest assured that PETDANCE will be the second author in there, along with MLEHMANN, as they obviously don't want reports. Just to be annoying, could the reverse be also available? While checking the reports of my modules, I see from time to time FAIL reports that weren't sent to me by mail. Some of these reports were even useful to me. Ok, I should setup a Plagger thingy to read the feeds from cpantesters, filter my modules, find and send the new FAIL reports, but being pushed the reports by mail is just so much easier.. And aren't we using a language that promote laziness ;-) -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Naming convention for thin wrappers around C libfoo.so ?
brian d foy wrote: In article [EMAIL PROTECTED], Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: IMHO, Lib doesn't carry as much information as Raw or even API, given the already existing modules. Raw and API don't mean anything. Everything is an API :) Yes, everything is an API, but in a sense, everything is a library as well, depending on how you define that term. :-) I was proposing a name ending with API to follow the Win32 / Win23API scheme, the same way many modules now follow the name ending with X scheme for extension modules. It's not meaningful, but it seems to be the current convention. Lib denotes the external dependency, which says much more about the either two, which can refer to anything. There is (currently) no Lib:: module, while there are 78 distributions with API in their name. And if you check, most actually define low-level API to external things, for things ranging from system stuff (Win32 stuff, GSSAPI, card terminal stuff) to documents (PDF::API2), protocols (LDAP), and of course web sites (EVDB, Flickr, Facebook, Google). What I'm saying is just that there seems to be a pattern. Tim may or may not want to follow it. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Naming convention for thin wrappers around C libfoo.so ?
Tim Bunce wrote: I'm looking to build a very thin wrapper around libmemcached (http://tangent.org/552/libmemcached.html) a high-performance feature-rich interface to memcached. [...] I was thinking in terms of a low-level 'thin' extension called Lib::libmemcached with separate pure-perl modules implementing the Cache and Cache::Cache interfaces. So, here's the point: does anyone have any good objections to my establishing a new precident by using the Lib:: namespace for this? (Or perhaps CLib:: or SysLib:: or ...) I was wondering why you wanted to build yet another Memcached module given there is already Cache::Memcached::XS, but now I understand: you want to do something similar to what Paul Marquess did with Compress::Zlib when he splitted it between a high-level Perl frontend (Compress::Zlib) and a low-level driver (Compress::Raw::Zlib), which allowed him to provide bzip2 support (Compress::Raw::Bzip2). It's also similar to the Win32 situation: Win32API::* modules provide low-level API, while Win32::* provide high-level API. IMHO, Lib doesn't carry as much information as Raw or even API, given the already existing modules. So possible namespaces are: Cache::Raw::Memcached or CacheAPI::Memcached. Or, if you don't want to be related to the Cache:: namespace, Memcached::Raw or Memcached::API. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: relative.pm vs import.pm
A. Pagaltzis wrote: * Sébastien Aperghis-Tramoni [EMAIL PROTECTED] [2007-10-11 12:10]: But this will load *all* the modules below the current one, which is not the same thing as loading a set of selected modules. Imagine doing this with Plagger ;) Imagine trying to load all of Plagger's modules by hand. ;--) Right, except I chose Plagger because this is typically a framework where you only load a couple of modules from the gazillions available. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)
Eric Wilhelm wrote: # from Sébastien Aperghis-Tramoni # on Monday 08 October 2007 16:02: use relative; my $Customer = import relative qw(Report Customer); This changes the require() on Foo::Report and Foo::Customer to run- time though, right? Right, but I'd say that for writing object-oriented code, there isn't such a need to do things at compile time, is it? -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
Eric Wilhelm wrote:
Anyway, this is an unchecked eval, and always-on.
# import the symbols from the loaded module into the caller module
eval qq{ package $caller; $module-import };
Indeed. Thanks for spotting this.
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.
Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)
Ovid wrote:
--- Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
Eric Wilhelm wrote:
use relative;
my $Customer = import relative qw(Report Customer);
This changes the require() on Foo::Report and Foo::Customer to run-
time though, right?
Right, but I'd say that for writing object-oriented code, there isn't
such a need to do things at compile time, is it?
You know, I hadn't considered the runtime/compile-time issue when I
first saw this. Eric's right that this does change the semantics. I
suppose one could wrap it in a BEGIN block, but that makes it worse:
use relative;
my ( $Report, $Customer );
BEGIN {
( $Report, $Customer ) = import relative qw(Report Customer);
}
I do get tired of writing code like that (it happens a lot in test
suites when I have use_ok $CLASS in a BEGIN block).
I do agree that with OO modules that compile-time should be less of an
issue, but it's not universally the case. Still, I think the import
relative is probably enough for me.
To be honest, I'm not really convinced because I don't see why so much
things should happen at compile-time, but I'll add the -aliased option
in the next release.
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.
Re: RFC: relative.pm
A. Pagaltzis wrote: * Bill Ward [EMAIL PROTECTED] [2007-10-07 04:55]: Would lib::relative be too weird? There is already a `lib` pragma; `lib::relative` to me sounds like does something like `lib`, only relatively, which more naturally suggests something to do with relative paths and [EMAIL PROTECTED] I proposed pkg::relative which Eric Wilhelm liked; no word from Sébastien yet though. Sorry, I forgot to answer this mail. AIUI, lib::relative already exists: it's called FindBin (and the derivates). pkg::relative would seem like an incorrect name because it carries a semantic you can't achieve: in Perl, you don't load packages but modules, which happen to define (or not) a package of the same name. So, IMO, there's no other semantic to differentiate from when used as a Cuse argument, hence the plain relative name. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)
Ovid wrote: I like the idea of this module. Lots of people like the idea of 'aliased'. Would it be worth combining the two? use My::Enterprise::Framework; use relative -aliased = qw(Customer Report); # instead of: # my $customer = My::Enterprise::Framework::Customer-new($id); # use: my $customer = Customer-new($id); Hmm.. As is, relative.pm already allows you to do that (thanks to Ken Williams' suggestion): package My::Enterprise::Framework; use relative; my $Customer = import relative qw(Report Customer); my $customer = $Customer-new($id); That is, import returns the full names of the successfully loaded modules in list context, or the last one in scalar context. Is this sufficient or did I misunderstand you? -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Fwd: CPAN Upload: S/SA/SAPER/relative-0.02.tar.gz
Hello, The version 0.02 of relative.pm is now available on the CPAN. Thanks to everybody who suggested improvements. (And it still works on Perl 5.004 :-) Forwarded message: From: PAUSE [EMAIL PROTECTED] Date: 7 octobre 2007 19:58:44 HAEC To: Sebastien Aperghis-Tramoni [EMAIL PROTECTED] Subject: CPAN Upload: S/SA/SAPER/relative-0.02.tar.gz The uploaded file relative-0.02.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SA/SAPER/relative-0.02.tar.gz size: 4459 bytes md5: 9deb938f018c86e8ab4b48b4225b6978 No action is required on your part Request entered by: SAPER (Sébastien Aperghis-Tramoni) Request entered on: Sun, 07 Oct 2007 17:57:27 GMT Request completed: Sun, 07 Oct 2007 17:58:44 GMT -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
Hello Aristotle, A. Pagaltzis wrote: Hi Sébastien, * Sébastien Aperghis-Tramoni [EMAIL PROTECTED] [2007-10-06 03:05]: package BigApp::Report; use relative to_parent = qw(Utils); # loads BigApp::Utils use relative to_self = qw(Create Publish); # loads BigApp::Report::Create, BigApp::Report::Publish I like the idea. Catalyst privately invents something like that, so obviously there are other people who feel the same need. Yes, POE also provide a similar mechanism, that's why I was thinking to provide a generic module to do that. But I like neither the name nor the interface. How about this: package BigApp::Report; use subclass qw(..::Utils Create Publish); # loads BigApp::Utils, BigApp::Report::Create, BigApp::Report::Publish subclass would imply more OO semantic than I'd like, as the module just loads others modules, but I agree it's a better name than relative and I can't find a better one. Also agreeing for the API change. I know I was pondering about using .. but can't remember why I didn't. Thanks -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
Andy Armstrong wrote: But I like neither the name nor the interface. How about this: package BigApp::Report; use subclass qw(..::Utils Create Publish); # loads BigApp::Utils, BigApp::Report::Create, BigApp::Report::Publish subclass would imply more OO semantic than I'd like, as the module just loads others modules, but I agree it's a better name than relative and I can't find a better one. Also agreeing for the API change. I know I was pondering about using .. but can't remember why I didn't. Would it also do use relative [to = 'My::Big::Namespace'] = qw( This That Munger::Fast Munger::Precise ); It can easily do that. The problem is more the name. In this case, use relative to ... works well. But in y original example, use subclass works better. Maybe I should provide both modules then. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
Andy Armstrong wrote: Would it also do use relative [to = 'My::Big::Namespace'] = qw( This That Munger::Fast Munger::Precise ); It can easily do that. The problem is more the name. In this case, use relative to ... works well. But in y original example, use subclass works better. Maybe I should provide both modules then. I always hesitate to suggest Aristotle is mistaken - it's not a common occurrence - but I really think 'subclass' is wrong. As you said this is an extension to the semantics of use that has (I presume) nothing to do with any inheritance relationship the modules may have with each other. Mixing both your and Aristotle's suggestions, here is the new synopsis: package BigApp::Report; use relative qw(Create Publish); # loads BigApp::Report::Create, BigApp::Report::Publish use relative qw(..::Utils); # loads BigApp::Utils use relative to = Enterprise::Framework = qw(Base Factory); # loads Enterprise::Framework:Base, Enterprise::Framework::Factory I quite like 'relative' to be honest. And I like the idea of the module. I'll use it immediately when you release it, thanks. Heh, thanks. I'll announce here when the module is available. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Fwd: CPAN Upload: S/SA/SAPER/relative-0.01.tar.gz
Hello, relative.pm is now available on the CPAN. Thanks to Aristotle and Andy for their suggestions. For people who care about this, it even works on Perl 5.004 Forwarded message: From: PAUSE [EMAIL PROTECTED] Date: 6 octobre 2007 18:39:45 HAEC To: Sebastien Aperghis-Tramoni [EMAIL PROTECTED] Subject: CPAN Upload: S/SA/SAPER/relative-0.01.tar.gz The uploaded file relative-0.01.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SA/SAPER/relative-0.01.tar.gz size: 3962 bytes md5: 1127c3c21734e2ffd12bff036b944581 No action is required on your part Request entered by: SAPER (Sébastien Aperghis-Tramoni) Request entered on: Sat, 06 Oct 2007 16:38:50 GMT Request completed: Sat, 06 Oct 2007 16:39:45 GMT Thanks, -- paused, v929 -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
Ken Williams wrote: If there were a return value from import(), they could do something like this instead: package BigApp::Report; use relative; my $Pub = import relative to_self = qw(Create Publish); my $p = $Pub-new; Except that, 1), the API has changed a bit, 2) I think import should return a list in this case because it's importing several modules at once. So would write it like this: package BigApp::Report; use relative; my ($Create, $Publish) = import qw(Create Publish); my publisher = $Publish-new; Looks a good idea. It should also DTRT so my $Publish = import qw(Publish); works as one expects. The only case left is: my $What = import qw(One Two Three); It could return the last one in order to mimic the comma operator. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
David Cantrell wrote: Also agreeing for the API change. I know I was pondering about using .. but can't remember why I didn't. '..' is only meaningful in the Unix/Win32 world. VMS, RISC OS and others call it something else. On the other hand, I think it's safe to assume that anyone using those platforms and perl will know what .. means and if they don't I'm sure you'll document it. For best or worse, Unix semantics are pretty common and have contaminated many other things not related to filesystems. Think of URL or XPath[1] for example. [1] http://www.w3.org/TR/xpath#path-abbrev -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
A. Pagaltzis wrote: * Sébastien Aperghis-Tramoni [EMAIL PROTECTED] [2007-10-06 20:30]: As a side note, using find(1) on a mini-CPAN and Google CodeSearch, I only found 3 modules named tp.pm: Don’t forget the darkPAN though. On a side note, if some people here know Perl modules outside CPAN but available on the internet, I'll gladly accept patches to list them in Module::ThirdParty. An acceptable compromise it to write it as C -to = Root That’s what I’d suggest. FWIW, even with the current interface, it’s possible to load a to.pm if you do it this way: use relative to = __PACKAGE __, qw(to from before after boo); But that’s a) noisy b) less than self-suggesting. I’d stick the hyphen on there to avoid that sort of irregularity. It’s a really tiny change anyway. Ok, ok, you've convinced me :-) Will change this, along with your patch and Ken's idea. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: relative.pm
Dr.Ruud wrote: Sébastien Aperghis-Tramoni schreef: package BigApp::Report; These would also be nice: package BigApp::__FROMFILE__; package BigApp::__FROMFILE__($RCSfile); Not sure how this is supposed to work, but I think this is beyond the aim of relative.pm -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
RFC: relative.pm
Hello, Following a suggestion by a coworker, I wrote the following module: NAME relative - Load modules with relative names DESCRIPTION This module allows you to load modules using only parts of their name, relatively to the caller module. SYNOPSIS package BigApp::Report; use relative to_parent = qw(Utils); # loads BigApp::Utils use relative to_self = qw(Create Publish); # loads BigApp::Report::Create, BigApp::Report::Publish __END__ The interest of such a module would be to ease writing modules using a big set of sibling modules (in the same hierarchy), and would also simplify refactoring and renaming. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: How to recognize modules that needs compilation?
Gabor Szabo wrote: Hi, I would like to create a list of modules that need compilations as opposed to those that are pure perl Is checking for a file with .xs .c or .h extension in the distribution the correct thing to do? Is there a better way to collect this information or is it alrady available somewhere? This looks like an heuristic.. which leads us to Klortho #11953 ;-) It would work for most modules, but would miss those that generates the C and XS files on the fly, like Perl::API » http://search.cpan.org/dist/Perl-API/ But I guess there aren't that much modules like this one. In addition I would located modules that have dependecies that are not available on CPAN. (e.g. most of the DBD::* modules are such but DBD::SQLite is not such a module as it includes all the C code of SQLite) I keep track of external Perl modules in Module::ThirdParty » http://search.cpan.org/dist/Module-ThirdParty/ But you would still need something for tracking modules that needs external C libraries, but I think this should simply be included in the module which tracks modules that need compilation, as a field need_external_libs, and why not also a field with the names of required libs. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: In which linux distribution is my module available
Gabor Szabo wrote: On 5/4/07, Johan Vromans [EMAIL PROTECTED] wrote: For example, according to the report, Getopt::Long is only available in FreeBSD but I'm pretty sure it is installed in all other distros as well. In addition, after I generated and announced the initial report I stated to look into how the data is fetched (which is done by Module::Packaged::Generate from Leon) and found out that the data collector of Mandriva is dead and Fedora actually means FC2. I guess that Getopt::Long, as well as other dual-life modules, are very often not packaged by editors because they have to specifically remove it from the main Perl package. And even though several modules from 5.8 have been dual-lifed and have more recent versions on the CPAN, they prefer to keep the versions included with the Perl distribution. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: recent search.cpan changes?
Andy Armstrong wrote: On 5 May 2007, at 09:29, Jonathan Rockway wrote: Also, I can't seem to find the search.cpan source. Could someone provide a pointer to it? I've been wondering if that was available too. AFAIK, the sources of search.cpan.org, nicknamed TUCS, have never been made available. OTOH, you can get the sources of cpan.uwinnipeg.ca from http:// cpan.uwinnipeg.ca/dist/CPAN-Search-Lite -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Module Proposal: Parse::Reversible
Paul LeoNerd Evans wrote: No, I think at this point we have to appeal to the core reason for creating this module in the first place; namely, that it is bidirectional. Parsing a string into variables, or interpolating the variables back into a string. Both can be done within one object, symmetrically. To introduce something that breaks that symmetry effectively removes the requirement that it be done within one object, at which point one might as well use two separate objects for each individual operation. If the main objects your module will manipulate still are URIs, maybe it should be in the URI:: namespace. And couldn't the bidirectional relation you want to create be seen like a mapping? Hence URI::Mapper or something similar? -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: echo die Makefile.PL
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? If you really want Module::Build to be installed, why not simply create a traditional Makefile.PL and add Module::Build as a prerequisite? That way your module can be installed with ExtUtils::MakeMaker yet Module::Build also gets installed for the next time. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Best practices for dual-lifing a core module?
David Landgren wrote:
List,
Hello David,
I've recently taken over File::Path, to bring some modern goodness
to this venerable module (and therefore allow such goodness to be
backported to older perls). As it stands in the core, it consists
of the files ./lib/File/Path.{pm,t}.
Nice. Let me know if you want some beta tests on old Perls.
To turn it into a standalone CPAN distribution, it needs a
manifest, a README, pod tests (*snort*), a Makefile.PL, test files
in t/ and so forth. Which is fair enough, but I wonder how I sync
it back with blead.
Do I just make sure that I can pull the .t file and the .pm file,
wherever they may wind up in the distribution layout, and diff them
against those two files in blead? I can't see the point of stuffing
all the ancillary distribution files into the blead tarball when
the .pm and .t will be enough. What do other people do/have other
people done?
That's what I do for the two dual-life modules I maintain. I usually
create a patch by diff'ing the new release with the previous one if
there wasn't any patch applied in blead (that's generally the case),
then edit it in order to remove the parts that aren't needed for
core, then send it to P5P.
That is, unless Steve Peters plays Road-Runner and updates blead with
the new files before I even have the chance to send the patch ;-)
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.
Re: CPAN testers machines that lack Module::Build
Ken Williams wrote: On Mar 13, 2007, at 8:38 PM, Sébastien Aperghis-Tramoni wrote: 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. OTOH, Module::Install (and Module::Build as well to be honest) doesn't work on old Perl. Some people may care about this and thus not use M::I, others may not. Module::Build works as far back as perl 5.005_03 - before that and we'd be pulling our hair out more than we already are. That said, testing on old perls doesn't always happen as often as we'd like, so sometimes it breaks and nobody notices. But generally it should work. I now remember that part of the problem were some modules Module::Build use, which are now compatible with Perl 5.004, so I'll test again Module::Build with the old Perl I have. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: CPAN testers machines that lack Module::Build
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. OTOH, Module::Install (and Module::Build as well to be honest) doesn't work on old Perl. Some people may care about this and thus not use M::I, others may not. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: supporting older perls
Greg Matheson wrote:
I got one failure with 5.6.2 and passes with 5.8. The problem
appears to be the constant pragma, which doesn't seem to have an
independent contemporary existence on CPAN.
[...]
Because it is not failing on 5.8, I suspect that in 5.6.2 the
constants pragma
didn't have:
Defining multiple constants at once
Indeed, the constant pragma began supporting this feature with Perl 5.8
Line 16 of my module is:
use constant {
C1= 'C1',
C2= 'C2',
and it continues on this way to line 40.
PREV = PREV,
COLORS= COLORS,
};
What do I do now? constants doesn't seem to have a contemporary
existence on CPAN distinct from perl.
If you want your module to be compatible with Perl 5.6, you can
rewrite your statement using multiple use constant calls.
Otherwise, you can simply add a require 5.008 in your Makefile.PL
in order to indicate that your module needs Perl 5.8.
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.
Re: Delete hate speech module
Dave Rolsky wrote: On Wed, 7 Feb 2007, Joshua ben Jore wrote: I'd just read of Time::Cube, a disjointed rant full of hate speech. This is the kind of content that is most deserving of deletion from CPAN. Would the responsible parties please go nuke this, please? Just to clarify for the curious, to see the bile you have to take a look at the module's source. It's not in the docs. I would just consider this distribution as spam, and treat it as is. (Usually, I simply punch the delete key.) -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: James Freeman's other modules
David Landgren wrote: One thing that makes it difficult to play along at home is that there's no easy way to obtain a dump of the cpan.org RT tickets, short of violently scraping a web server that's already slow enough as it is. If one could obtain a tarball of a tab-delimited file containing o RT id o status o last update o distribution o subject of all tickets, or all non-resolved tickets, well there's a language that's good at munging such data and producing all kinds of interesting reports. Is Jesse Vincent the person to ask for this? AFAICT, he is. But asking your question at cpan- [EMAIL PROTECTED] is probably the best thing :-) -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Module::Build and the Test Harness Report in the CPAN Testers
Shlomi Fish wrote: Hi all! Hello Shlomi, Yuval Kogman claimed that Module::Build generates CPAN testers reports with no output from the test harness. Now, I released Math::GrahamFunction, which is based on Module::Build, a few days ago and today received this failure error report: http://nntp.x.perl.org/group/perl.cpan.testers/397523 And indeed it does not contain the output of the test harness. Is this a known problem with Module::Build? Is it intentional, or are people otherwise working on resolving it? Is there anything I can do about it? This is a known issue. See ticket CPAN-RT#9793 » http://rt.cpan.org/Public/Bug/Display.html?id=9793 -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Benefits of Test::Exception
Paul LeoNerd Evans wrote: That said, I know Test::More isn't core, yet all my tests use that without declaring it, so maybe it would work. Test::More is core, but only since Perl 5.8 (to speak with stable Perl releases). Just remember that, contrary to an unfortunate but popular belief, the set of core Perl modules is a moving target. Use Module::CoreList and its command corelist(1) to know which module is core and since when. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Question: How can one get a module's rt.cpan.org traffic?
Shlomi Fish wrote: I'd like to inquire how can one subscribe to a module's rt.cpan.org traffic. I recently started contributing to XML::RSS, but I'm not a maintainer (yet), and would like to receive all the messages that are sent to its queue by email or RSS. But I couldn't find a way to do that. I know it's possible in bugzilla, but rt.cpan.org uses Request Tracker. Just log in your RT account, then you have an RSS feed for each and every queue in its bugs list. The canonical URL being: http:// rt.cpan.org/Search/Results.rdf?Query=Queue%20%3D%20'DISTNAME'%20AND%20 (%20Status%20%3D%20'new'%20OR%20Status%20%3D%20'open'%20OR%20Status% 20%3D%20'stalled'%20) (replace DISTNAME with the distribution name) -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Give up your modules!
Quoting Ovid: Nothing wrong with a good-old-fashion hostile fork now and again :) But hopefully we can avoid that. I'd almost be inclined to have takeovers than forks, but I suspect I'll be universally shouted down over that one. If module authors are unwilling to fix bugs in critical proojects and not allow comaintainers, the poor end-user is stuck. Looking at the recent and past history of the CPAN, I'd say that forks usually happen for young modules with very active development (see the Class::DBI / DBIx::Class case). Mature modules look unsexy to most people's eyes, even to the author's, and he or she is usually quite eager to let someone else deal with the bugfixes. Said in another way, if you feel that there is a number of modules that need a new maintainer while bug are piling up, it's usually not because the author doesn't want to give the co-maintenance, but because nobody wants to deal with such unfun work. Creating a web site which shows the modules in dire need of maintenance is a good thing, but the next question is: how many people here will then accept to maintain such modules? (History has shown that this number is very low.) -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Fwd: Indexing for AI-Prolog-0.735_01?
Adriano Ferreira wrote: On 8/4/06, Ovid [EMAIL PROTECTED] wrote: Maybe it's just me not understanding how things work (no big surprise there, eh?), but I've also noticed that http://search.cpan.org/dist/AI-Prolog/ points to your release but searching for AI::Prolog only shows mine (http://search.cpan.org/search?query=AI%3A%3APrologmode=all). I don't know exactly why it happens, but it always happens with development versions (the ones that got underscores in version numbers like the AI-Prolog-0.735_01 Joshua used). There is someplace where it is told that development versions are not indexed. search.cpan finds it and bundles together with other AI-Prolog distributions, but the search does not work smoothly. This is because PAUSE and Search CPAN do not work the same way. PAUSE only indexes modules that follow some precise rules, one of them being that the version number mustn't indicate a development version. Search CPAN however indexes nearly every uploaded distribution. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: This Week on perl5-porters - (12-18 June 2006)
Selon David Nicol [EMAIL PROTECTED]: On 6/22/06, David Landgren [EMAIL PROTECTED] wrote: Could Perl get Reversible Debugging? [...] We need a come from instruction http://xrl.us/nnuw I don't recall reading a demand for a come from instruction in that thread, but I had an idea last night that I was going to dismiss as trivial, until reading that assertion in the week in p5p summary. It's a real simply come from instruction that forks at the labels instead of branching. Not suitable at all as a replacement for goto -- if you want to branch, use goto. But may be useful for setting checkpoints/breakpoints with a minimum of surgical insult. [...] So.. shall I put this on CPAN? OTOH, there's already Audrey Tang's Acme::ComeFrom http://search.cpan.org/dist/Acme-ComeFrom/ -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Naming advice for a templating module
A. Pagaltzis wrote: Hi all, Hello Aristotle, yes, yes, a templating module. Shush. This one differs because it’s a pure-XML approach. The templates must be well-formed XML, and the design of the template language is built to ensure, as best as possible, that the output is well-formed at all times as well. Maybe I miss something, but did you look at AxKit? http://www.axkit.org/ I've never used it but I've always heard about it as *the* Perl-XML web framework. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: Linking to a POD document in POD
A. Pagaltzis [EMAIL PROTECTED] wrote: * Randy Kobes [EMAIL PROTECTED] [2005-11-18 17:10]: Perhaps inserting such a section would help - what seems to happen is that, within a distribution, direct links to docs will be formed for modules within that distribution; otherwise, http://search.cpan.org/perdoc? will be used. Hmm, isnât the search.cpan.org code available somewhere? I seem to remember so, but canât find if and where saw mention of that. AFAIK, the source code of search.cpan.org is not available, although it uses many CPAN modules itself. As noted by Graham Barr on the Perl NOC blog, the site may migrate its full text search engine from WAIT to Swish-e: http://log.perl.org/cpansearch/ -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Linking to a POD document in POD
Randy Kobes [EMAIL PROTECTED] wrote: It is puzzling ... One difference between the example of Catalyst::Manual::Intro and Rose::DB::Object::Tutorial is that Catalyst::Manual::Intro has a =head1 NAME Catalyst::Manual::Intro - Introduction to Catalyst section, whereas Rose::DB::Object::Tutorial doesn't. Perhaps inserting such a section would help - what seems to happen is that, within a distribution, direct links to docs will be formed for modules within that distribution; otherwise, http://search.cpan.org/perdoc? will be used. Although a NAME section alone isn't enough to register a module in the CPAN/PAUSE indices (a package declaration would also be needed, for example), perhaps such a section is enough for search.cpan.org in the context of forming links. Andreas Koenig and Graham Barr confirmed me that this is the way the indexer works: the .pm files must contain a corresponding =head1 NAME, otherwise it is added in the documentation section. You can find more information about this in this thread: http://xrl.us/ihei [groups.google.com] -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Name advice for a new module
Greetings all, I'm planning to create a module that provides access to specific flags of the Perl interpreter; currently, I really only have the PERL_SIGNAL unsafe flag in mind[1,2] but other could be added as well. What could be the name of such a module? Maybe Perl:API::Flags to follow Gisle Aas hidden module Perl::API? It it clear enough or does anybody have another suggestion? [1] http://perldoc.perl.org/perlrun.html#ENVIRONMENT [2] http://perldoc.perl.org/perlipc.html#Deferred-Signals-(Safe-Signals) Thanks in advance -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC - Test::Stupid module
Selon David Landgren [EMAIL PROTECTED]: Or have Module::Starter know how to include site-local boilerplate. I like addnig a fixed blurb on how to report bugs (and no doubt other stuff but that's what I can think of without looking). If M::S knew how to fetch that during a run it would save me from having to set up a local template such as brian d foy outlined earlier. Module::Starter already allows you to create your own templates, see http://search.cpan.org/dist/Module-Starter/lib/Module/Starter/Plugin/Template.pm Then you can create distributions your way using the module-starter --plugin option. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Regexp code feature
Chris Dolan wrote:
I'm working on a module that I call Net::IP::Match::Regexp which
builds and runs regexps that contain simple code blocks. It works
great under 5.8.1 on my Mac, but I haven't tested older Perl versions
yet.
My code turns these IP ranges (randomly generated)
109.27.190.54/28= 1
109.61.26.198/24= 2
180.203.154.195/28 = 3
5.98.198.68/19 = 4
68.238.145.35/29= 5
into regexps look like this:
my $re =
^(?:0(?:10101100010110(?{'2'})|1(?:000100111011101001000100100(?{'
3'})|10110100(?:01101110100011(?{'5'})|0100011010(?{'4'}|10
11010011001011100110101100(?{'1'}));
I may be wrong, but this looks similar to what Regexp::Assemble does,
or that you could use it to ease your task.
http://search.cpan.org/dist/Regexp-Assemble/
Sébastien Aperghis-Tramoni
-- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO
Re: How to force tests to issue NA reports?
David Cantrell wrote: Let's take my module File::Find::Rule::Permissions as an example. I know it doesn't work on Windows, but not having access to a Windows machine, I have *no idea* what $^O should be on that platform, especially for any odd Windows environments like Cygwin or WinCE. I also know it doesn't work on VMS. perlport to the rescue: http://search.cpan.org/dist/perl/pod/perlport.pod#PLATFORMS Oh, and to the list of fields at http://module-build.sourceforge.net/META-spec-new.html how about adding 'requires_application'. Mac::iTunes::Applescript has an obvious prerequisite. The module Net::P0fq that I am slowly working on requires a running copy of p0f. http://search.cpan.org/dist/Net-P0f/ Maybe we should join our forces here :) On a side note, the tests would just check for the availability of p0f. If it's not present, just skip the tests that require it. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Should I keep META.yml under Version Control?
José Castro wrote: Well, Makefile is obviously being generated from Makefile.PL. However, MANIFEST is not. I just tried deleting the MANIFEST, and running perl Makefile.PL; make dist. I got an empty distribution. One should maintain MANIFEST manually. make manifest Of course, `make manifest` *assumes* a bunch of not be accurate.. I a bunch of stuff that might not This is what MANIFEST.SKIP is for. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: CPAN::Forum
Selon Gabor Szabo [EMAIL PROTECTED]: [...] So if you are a module author but your module does not have its own mailing list or web forum yet, you can make use of CPAN::Forum Let your users know that your module can be discussed at http://www.cpanforum.com/dist/Distro-Name and they will be directed to the sub forum of your distribution. You can also subscribe to get e-mail notification whenever someone posts to this distribution without visiting the site. Sounds very good. Thank you Gabor! I'd appreciate your feedback either here or better yet on http://www.cpanforum.com/dist/CPAN-Forum I've already posted a small feature request :) -- Maddingue Close the world, txEn eht nepO.
Re: Taking over maintenance of PDF.pm
Selon David Landgren [EMAIL PROTECTED]: Hello, I want to take over PDF.pm (I have a few patches for it). I've been talking back and forth with a guy who used to work with the author, and I quote: David, before spending time patching PDF.pmd, did you take a look at PDF::API2? It is more recent and still actively maintained. http://search.cpan.org/dist/PDF-API2/ -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: CPAN Testers and PREREQ_PM doesn't work very well!!!!!!
Selon David Coppit [EMAIL PROTECTED]: I had a similar rant about cpan-testers on module-authors in September. It seems like the automated reporting is so easy, the testers don't stop to determine whether *they* are the source of the problem. (I thought it was fully automated by a testing farm somewhere, based on the brain-dead submissions I was getting.) Perhaps we need a Testing HOWTO that the testers have to read before we let them submit reports. In fact, there are already such documents: http://search.cpan.org/~autrijus/CPANPLUS-0.049/lib/CPANPLUS/TesterGuide.pod http://search.cpan.org/~autrijus/CPANPLUS-0.049/lib/CPANPLUS/FAQ.pod The frustrating thing is that the failure reports on CPAN indicate that a module is buggy when it's not. As a result, modules that depend on external modules, libraries, or programs tend to get unfairly graded. It hurts the reputation of the author. (In my case, such as it is. :) Personnally, I run CPANPLUS by hand and only send reports when I think the author should know, but not in case of bad Perl version or missing external library. Jos Boumans is currently working on CPANPLUS 0.050 which is correcting several issues that 0.049 had (like not understanding no to some questions). Also, the default is set to no in case of FAIL to avoid sending false reports. cpansmoke is being re-added for 0.050_04. What is missing now is people using/testing CPANPLUS 0.50_xx to help Jos find and crush bugs. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
