Re: Devel::Size broken
On Tue, Jun 17, 2014 at 04:29:02PM +0100, David Cantrell wrote: On Mon, Jun 16, 2014 at 04:57:49PM -0700, Mark Hedges wrote: Devel::Size module seems to be broken in 5.20.0. No response from developers. No work for a year or so. What's the process to address a broken module that the developers won't fix? http://www.cpan.org/misc/cpan-faq.html#How_adopt_module The current maintainer is Nick Clark, who is active in the community. I don't know how long ago you tried to contact him, but perhaps he's just busy on other stuff. Work is currently stupidly busy*, and home is differently busy. :-( I'm aware that there are now some test failures, which I had hoped to have time to get to and haven't yet. I wasn't aware that it was actually in a dependency chain. Sorry about that. The problem is that historically there have multiple occasions with the module where patches have been submitted (and in several cases accepted) that were wrong. Sometimes blatantly, sometimes subtly. In particular, it's easy to write tests that produce a number. It's much harder to write tests that actually test what they think that they are testing, and testing the wrong number isn't useful. IIRC one recent patch sent by a third party ended up being totally wrong in its assumptions, and fixing the problem properly took somewhat over 5 hours of serious concentration. The problem is finding a block of 5 hours.** Nicholas Clark * This will not be tolerated indefinitely. ** Work currently has pseudo-timesheets submitted daily. Borrowing 5 hours in a day is hard to hide. Borrowing 5 hours in a week would not be impossible.
Re: COMAINT on https://metacpan.org/release/String-Random
On Fri, Dec 13, 2013 at 10:11:09AM +, Nicholas Clark wrote: balls it up). And as long as you don't throw away the terminal output, push anything or run `git gc`, there's always about 30 days to recover from any mess* from the various internal reflogs. * Other than git reset --hard Bother, or git clean -dxf (Backups have to be good for something But even CVS has a command to screw up the same way as `git reset --hard`, so there is tradition to uphold) I am confident that fanatical loyalty to the Pope will not be featuring in an e-mail in the near future. Although arguments might be :-) But hopefully they will be resolved using the rules from the Bruces sketch. Nicholas Clark
Re: A call to action for CPAN authors: make sure your modules work on perl 5.18
On Thu, May 23, 2013 at 09:06:33AM +0300, Gabor Szabo wrote: Hi, with the release of 5.18 some modules might stop working 100%. Please take a look at the call of David Oswald and, please update your module to make it work on 5.18 as well: In particular, please look at rt.cpan.org to see if someone has already submitted a patch that fixes it. In quite a few cases, there is a patch just waiting for the module's owner to apply it at make a release. Nicholas Clark
Re: DB_File is not installed?
On Thu, Nov 22, 2012 at 01:49:29PM +0100, Leon Timmermans wrote: On Thu, Nov 22, 2012 at 1:43 PM, Shmuel Fomberg shmuelfomb...@gmail.com wrote: Interestingly, most of the fails come from Solaris. but a few from Linux too. Any idea why the module is missing? The *DB_File modules aren't build when their library (in this case, libdb aka Berkeley DB) isn't present on the system. Only SDBM_File is guaranteed to be present because it's bundled with perl. I think all of them are prime targets for dual-living, which might alleviate some of these issues (though external dependencies are always tricky). DB_File is dual life already (upstream CPAN) Certainly the other 3 (not SDBM_File) are obvious victims to dual life. SDBM_File still has a parallel makefile issue that it would be nice to nail first. Someone previously seemed interested in having this happen, but inexplicably vanished when we said go for it! Nicholas Clark
Re: The CPAN Morass
On Mon, Dec 05, 2011 at 04:55:23PM -0800, Linda W wrote: I have tried to get a hold of icc, you had to be a famous developer or pay money -- I wanted to try it because it was said to do a much better job of optimizing than the gnu compiler... I was meaning this Non-Commercial Software Development, which still seems to be available: http://software.intel.com/en-us/articles/non-commercial-software-development/ It's limited to My use of software products is for personal non-commercial purposes. which I think actually excludes me, based on my current situation. Nicholas Clark
Re: The CPAN Morass
On Mon, Dec 05, 2011 at 09:42:30AM -0800, Linda W wrote: The assertion was that such a thing does not. It is is incumbent upon you, who want to refute that assertion to provide at least 1 example to disprove the general assertion. Claiming it is a research opportunity (because you don't know of any), is what i would expect of the average person cannot refute my stated position. Is that your final answer? ;-) Or would you like to get serious? Intel's icc is available for Linux (for x86 and x86_64, I assume) Sun's compiler is available for Linux (just for x86 and x86_64, I think) I've used lcc on Linux I've not tried clang on Linux That's 4 without trying, all of which I believe can be used in some cases without payment. Nicholas Clark
Re: The CPAN Morass
On Fri, Dec 02, 2011 at 10:21:32PM -0800, Linda W wrote: Dana Hudes wrote: BTW not everyone uses gcc. What compiler on linux -- where perl was born, would you suggest? Perl 5 was developed on SunOS. I don't know what platform Perl 1 was developed on. Perl 1 was released in December 1987, and predates Linux and ANSI C. Curiously, gcc was first released in May 1987. If it doesn't work on freely available and unencumbered tools (i.e. nothing more restrictive than the license on perl), then wouldn't it violate the implied site license? No. Because there is no implied site licence. I don't know where that idea came from. And you're also incorrect in implying that gcc is not more restrictive than Perl. It is. gcc is GPL only. Perl is under a dual licence, GPL or Artistic. The Artistic License permits one to make a binary only release using the Perl source code providing one doesn't pass it off as Perl. You seem to be basing a chunk of your reasoning on a lot of false assumptions. Nicholas Clark
Re: Spam to CPAN Developers? (Fwd: Betonmarkets CTO position)
On Wed, Feb 10, 2010 at 11:23:03AM -0600, Andy Lester wrote: On Feb 10, 2010, at 11:20 AM, Jonathan Yu wrote: Has anyone else got a message like this to their CPAN Developer e-mail address? I'm curious if this is the beginning of a really bad trend toward CPAN author spamming :/ Yes. Maybe, but I doubt it. I'm praying that we can chalk it up to some guy in Malaysia sending us all mail, and this doesn't turn into a huge metadiscussion. It didn't turn into a metadiscussion. But it does seem that the *only* firm that is* spamming CPAN authors is Betonmarkets, as they've done it *again*. Life would be quieter if they kindly ceased trading. (Because that seems a more reliable way for them to stop, than issuing an apology then repeating the offence every 18 months) Nicholas Clark * or fails to stop agents acting on their behalf.
Re: Spam to CPAN Developers? (Fwd: Betonmarkets CTO position)
On Tue, Sep 06, 2011 at 10:44:47AM -0400, David Golden wrote: Since aut...@cpan.org generally forwards somewhere useful, it's not the whois file that matters. I've gotten similar spam (from another company) that got my email off github. I think recruiter spam is just one of those things to ignore. At least it's *topical* unlike the email about winning a million pounds in a British lottery. But this is somewhat more like pissing in the pool that most of it. One is supposed to ignore spam, so as not to encourage the spammers. Topical spam is troubling, because it's *still spam*, but there's now a contradiction between ignoring it, and wanting to follow it up. I believe (but can't find it) that they apologised for this last time.* In which case they're proving not to be effective at sticking to their word. Also, Claes attempted to reply to it and met a challenge-response system. Not sure what else they can do to make themselves look more stupid. Hence why I'd like them to kindly cease trading. Nicholas Clark * Actually, it seems that Uri was also working to help them recruit, and so was going to tell their CEO that this was a foolish move as it breaks the rules: http://london.pm.org/pipermail/london.pm/Week-of-Mon-20100208/019134.html
Re: Re: Making sure your module works on other OS-es as well
On Sun, Jul 03, 2011 at 12:56:56AM -0700, Serguei Trouchelle wrote: Shmuel Fomberg wrote: I'm not advocating of throwing everything before 5.12, but I think that version 5.8.9 if the earliest we should accept. I know one Fortune 50 company who runs Perl 5.8.5 in production. Happy Birthday 5.8.5 - 7 years old today! Nicholas Clark
Re: Making sure your module works on other OS-es as well
On Sat, Jul 02, 2011 at 10:24:33AM +0300, Gabor Szabo wrote: On Fri, Jul 1, 2011 at 4:23 PM, David Cantrell da...@cantrell.org.uk wrote: I went through a period of trying to make sure my code worked on Windows, but I've given up. Not because it's hard to do - it generally isn't - but the complete lack of a reasonable set of tools* on Windows, which just makes me angry whenever I have to touch the blasted thing, made me stop. Indeed the issues I encountered were all quite simple: Thank you for you consideration of the other 80% of people who are still using Windows. Gabor, Dave is volunteering his code. That's such a nice way of you to treat volunteers. Would you prefer it that he didn't even upload it to CPAN? Would you prefer it if he remove the important offer [*that you edited out*] that he's happy to accept competent patches from anyone who makes his code woke on Windows? Because you're going the right way about it to get either of those two results. I appreciate what you want. I'd also want what you ultimately want. But you're going the *wrong way* about getting it. Nicholas Clark
Re: MakeMaker 6.57_08 (RC1)
On Tue, Mar 29, 2011 at 01:27:36PM +1100, Michael G Schwern wrote: After 6.58 MakeMaker will seriously consider shooting 5.6 in the head... I mean ending long term support. That will make shipping Scalar::Util unnecessary. Excellent. (release the hounds) Nicholas Clark
Re: Reducing rsync cost
On Tue, Nov 23, 2010 at 10:24:18PM +0100, David Landgren wrote: On 22/11/2010 15:18, David Nicol wrote: On Mon, Nov 22, 2010 at 4:37 AM, David Landgrenda...@landgren.net wrote: Yeah, this is the killer. In an ideal world, we would kill the symlinks such as authors/id/*, modules/by-category/*, modules/by-module/* and so on. These could be recreated via shell scripts locally on mirrors for people who wish to maintain these legacies. Cutting that out would diminish the rsync burden considerably. David or re-engineer CPAN as a sqlite+FTSE database, and re-engineer the mirroring process as a database mirror via a TBD compact database diff protocol (I have no intention of doing any of this myself; good morning) Well... I guess that's not going to happen then, is it? I shouldn't even bother replying, but I wouldn't want the archives to think that silence indicates tacit agreement. The symlink tree is built by scripts, isn't it? Are they available? Because the nice thing about your suggestion is that it doesn't involve changing any of the server infrastructure, and it's an incremental change which can be done by each mirror in turn. Instead of running rsync over the whole tree, it can change to run a top level script that runs rsync over the parts that have to be copied, and then run the symlink generation on the parts that can be recreated locally. Nicholas Clark
Re: What hurts you the most in Perl?
On Wed, Nov 24, 2010 at 07:26:27AM -0500, David Golden wrote: On Wed, Nov 24, 2010 at 7:01 AM, Gabor Szabo szab...@gmail.com wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. Out of curiosity, do you know what version of Perl they were running? Because #2 sounds like it's pre 5.8.1 Nicholas Clark
Re: Trimming the CPAN - Automatic Purging
On Tue, Mar 30, 2010 at 10:08:57PM +0200, Rene Schickbauer wrote: Now, if we where to put all files into mercurial, git or the like, renaming the files so they don't have version numbers in their names but storing them sequentially as commits so new versions update old ones. Sort of like Schwern already did? http://github.com/gitpan Nicholas Clark
Re: Trimming the CPAN - Automatic Purging
On Wed, Mar 31, 2010 at 01:03:51PM +1100, Adam Kennedy wrote: I've said nothing till now, because I figured more noise wouldn't help much. But I quite like the rsync daemon/proxy idea, and as it so happens I'm attending the OzLabs Unconference in 3 weeks time to hang out with Tridge, Rusty and the other Australia C/Kernel/Samba/RSync elites. So I'd be happy to raise any issues or ideas in this area with them in person over beers. I can see two possibly useful things (and I have no idea if either is yet possible, or a great understanding of how the protocol works) 1: stateful rsync daemon which doesn't scan all the time, either by a: Actually having a means to update b: Simply telling fibs, and pretending that the file system it scanned $n minutes ago is still current. (Which I think would work, at least for a mirror where files aren't edited (much) - if the server discovers that the client's view of that file *is* out of date, then scan that file for real, and give the up to date truth) 2: federated (or federate-able) server (or proxy) - so that you can say hand this subtree off to that other server This would allow the (fast, existing, C) rsync server to serve most of (say) funet.fi, handing off to a stateful server for the CPAN subtree. Nicholas Clark
Re: Trimming the CPAN - Automatic Purging
On Sat, Mar 27, 2010 at 08:52:22PM -0800, Arthur Corliss wrote: On Sat, 27 Mar 2010, Elaine Ashton wrote: Actually, I thought I was merely offering my opinion both as the sysadmin for the canonical CPAN mothership and as an end-user. If that makes me a prick, well, I suppose I should go out and buy one :) :-) You'll have to pardon my indiscriminate epithets. The barbs are coming from multiple directions. My point still stands, however. Your experience, however worthy, has zero bearing on whether or not my experience is just as worthy. Even moreso when you guys have zero clue who you're talking Are you running a large public mirror site, where you don't even have knowledge of who is mirroring from you? (Not even knowledge, let alone channels of communication with, let alone control over) Because (as I see it, not having done any of this) the logistics of that is going to have as much bearing on trying to change protocols as the actual technical merits of the protocol itself. Most of the cost of rsync is an externality to the clients. If one has an existing mirror, one is using rsync to keep it up to date, what's the incentive to change? Sounds like you may be hamstrung by your own bureacracy, but that's rarely the case in most the places I've worked. Not to mention that between passive mode FTP or even using an HTTP proxy (most of which support FTP requests) what I'm proposing is relatively painless, simple, and easy to secure. This concern I suspect is a non-issue for most mirror operators. Even if it was, allow them to pull it via HTTP for all I care. Either one is significantly more efficient than rsync. I'm missing something here, I suspect. How can HTTP be more efficient than rsync? The only obvious method to me of mirroring a CPAN site by HTTP is to instruct a client (such as wget) to get it all. In which case, in the course of doing this the client is going to recurse over the entire directory tree of the server, which, I thought, was functionally equivalent to the behaviour of the rsync server. Nicholas Clark
Re: Trimming the CPAN - Automatic Purging
On Sat, Mar 27, 2010 at 10:52:05AM -0800, Arthur Corliss wrote: I think I was quite explicit in saying that efficiencies should be pursued in multiple areas, but the predominant bitch I took away from your thread dealt with the burden of synchronizing mirrors. What's the easiest way to address that pain? I don't believe it's your method. I'd look into the size issue *after* you address the incredible inefficiencies of a simple rsync. I You? Or someone else? I am quite happy to agree that your understanding and experience of storage management is better than mine. But that's not the key question, in a volunteer organisation. The questions I ask, repeating Jan's comments in another message, are. Nicholas Clark
Re: Spam to CPAN Developers? (Fwd: Betonmarkets CTO position)
On Wed, Feb 10, 2010 at 12:20:51PM -0500, Jonathan Yu wrote: Hi, Has anyone else got a message like this to their CPAN Developer e-mail address? I'm curious if this is the beginning of a really bad trend toward CPAN author spamming :/ Yes. I replied to him with a polite but sarky note about it, finishing by suggesting that he used http://jobs.perl.org/ Nicholas Clark
Re: Process for Removing a Module from CPAN
On Wed, May 27, 2009 at 02:54:11PM -0700, Bill Ward wrote: 2009/5/27 Steffen Schwigon s...@renormalist.net Burak Gürsoy burakgur...@gmx.net writes: -Original Message- From: Steffen Schwigon [mailto:s...@renormalist.net] Sent: Tuesday, May 26, 2009 1:25 AM To: Jonathan Yu Cc: module-authors@perl.org Subject: Re: Process for Removing a Module from CPAN The best and easiest thing is to contact the author of the original namespace to give you co-maintainer rights. Maybe this way you even get him involved and relight his fire. Come on, do you really believe what you're saying? The author will pick it up after 12 years? A module stayed at version 0.03? Nonsense IMHO. You might be right, but even so I think it shows some respect to at least consider it, in contrast to speculatively assume that he will not be interested anyway, especially if someone wants to takeover his namespace... Certainly that's true. Have attempts been made to contact the author? I would have assumed that had already been tried and failed prior to even posting here. The original message ends : So, what's the process for having a module removed from CPAN or at : least having the namespace transferred to someone else, so that we can : create a new package and have that one installed via the CPAN shell? (it's one level of quoting above the innermost message above) Given that the original correspondent did not say I've tried contacting the author, and stated that he wanted to know the general procedure, I strongly assume not. Nearly everyone who has contacted the author before mailing here has said so. Nicholas Clark
Re: Perl Critic and (honest) hash references
On Mon, Mar 02, 2009 at 11:15:53PM -0800, Joshua ben Jore wrote:
On Mon, Mar 2, 2009 at 12:22 PM, Nicholas Clark n...@ccl4.org wrote:
On Mon, Mar 02, 2009 at 10:23:38AM -0800, Bill Ward wrote:
Personally I always use hashes for objects. Hashes are pretty fast in
Perl,
especially when there aren't many keys, so I don't think the benefits of
using arrays are worth it. The risk of typos is pretty small, and the
Hash lookup should be O(1), independent of number of keys. Of course, a hash
with more keys uses more memory, but so does an array with more elements.
I once found some very fast code varying in something I'm guessing was
O(n) on the length of the keys. I've occasionally wished I could get
static lookups to compile with the hashed I32 already stashed.
There is code to do this in the peephole optimiser. For those who don't know,
shared hash key scalars store the precomputed U32 hash value. For
illustration, I'm going to use pre 5.10, as 5.8.x and earlier store them in
PVIVs, which makes them visibly distinct from regular PVs in dump output.
The code (in blead) to convert constant method names to shared hash keys is
in Perl_ck_method: http://perl5.git.perl.org/perl.git/blob/HEAD:/op.c#l7455
The code to convert hash lookups (or at least some of them) is
in Perl_peep: http://perl5.git.perl.org/perl.git/blob/HEAD:/op.c#l8568
However, something in ithreads, I know not what, undoes this one. So, for
an unthreaded 5.8.8, notice that rules is a PVIV, so shared:
$ ./perl -Ilib -MO=Concise -e '$perl-{rules}'
8 @ leave[1 ref] vKP/REFC -(end)
1 0 enter -2
2 ; nextstate(main 1 -e:1) v -3
7 2 helem vK/2 -8
51 rv2hv[t1] sKR/1 -6
4 1 rv2sv sKM/DREFHV,1 -5
3 $ gv(*perl) s -4
6$ const(PVIV rules) s/BARE -7
-e syntax OK
Whereas the threaded 5.8.8 loses this optimisation at some point later:
$ perl -MO=Concise -e '$perl-{rules}'
8 @ leave[1 ref] vKP/REFC -(end)
1 0 enter -2
2 ; nextstate(main 1 -e:1) v -3
7 2 helem vK/2 -8
51 rv2hv[t2] sKR/1 -6
4 1 rv2sv sKM/DREFHV,1 -5
3 # gv[*perl] s -4
6$ const[PV rules] s/BARE -7
-e syntax OK
If you have time to identify and fix that, that would be great. Method names
don't seem to suffer from this:
$ ./perl -Ilib -MO=Concise -e '$perl-rules()'
7 @ leave[1 ref] vKP/REFC -(end)
1 0 enter -2
2 ; nextstate(main 1 -e:1) v -3
6 1 entersub[t1] vKS/TARG -7
30 pushmark s -4
-1 ex-rv2sv sKM/1 -5
4 $ gvsv(*perl) s -5
5$ method_named(PVIV rules) -6
-e syntax OK
$ perl -MO=Concise -e '$perl-rules()'
7 @ leave[1 ref] vKP/REFC -(end)
1 0 enter -2
2 ; nextstate(main 1 -e:1) v -3
6 1 entersub[t2] vKS/TARG -7
30 pushmark s -4
-1 ex-rv2sv sKM/1 -5
4 # gvsv[*perl] s -5
5$ method_named[PVIV rules] -6
-e syntax OK
However, longer term, I'm wondering why we even do this in the peephole
optimiser, given that, worst case, we could allocate *all* bare words are
shared, straight out. (And possibly even allocate all strings from the
tokeniser as shared, given that they can now be copied as COW, and my hunch
is that strings in the tokeniser more likely than not occur more than once).
Nicholas Clark
Re: Perl Critic and (honest) hash references
On Mon, Mar 02, 2009 at 10:23:38AM -0800, Bill Ward wrote: Personally I always use hashes for objects. Hashes are pretty fast in Perl, especially when there aren't many keys, so I don't think the benefits of using arrays are worth it. The risk of typos is pretty small, and the Hash lookup should be O(1), independent of number of keys. Of course, a hash with more keys uses more memory, but so does an array with more elements. Nicholas Clark
Re: Specifying different bug trackers?
On Tue, Jan 27, 2009 at 03:42:23PM -0600, Andy Lester wrote: It would be nice if rt.cpan.org allowed authors to shut down queues, but hey, I'm not arguing with a free service. When I requested it, a queue was shut. I believe the correct address for requests is rt-cpan-ad...@bestpractical.com Nicholas Clark
Re: Module for base 85 encoding
On Mon, Nov 24, 2008 at 11:49:04AM -0500, Darian Anthony Patrick wrote: Darian Anthony Patrick wrote: Nicholas Clark wrote: I've written a module that implements the base 85 encoding used by the old btoa program, and by PDFs as their Ascii85 encoding* I'm not sure what to call it. It's functionally equivalent interface to MIME::Base64, but this isn't a MIME standard, so that's not the correct top level to live under. It is, arguably, an encoding module, but it isn't the interface of Encode, which is what modules under the Encode top level provide. So I'm not sure what to call it. Nicholas Clark * http://en.wikipedia.org/wiki/Ascii85 Maybe Math::Base85, following the placement of Math::Base36? Hmm. Looks like there already is a Math::Base85. Is your implementation different from the existing Math::Base85? 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
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
Re: META.yml how to declare the need for threaded perl?
On Fri, Oct 31, 2008 at 06:16:01PM -0500, Chris Dolan wrote: Just add a dependency on thread::shared or one of the other threading libraries. Push your problem up the chain! No, not threads::shared $ /home/nclark/Sandpit/588ish/bin/perl -Mthreads::shared -e0 $ threads looks a better idea: $ /home/nclark/Sandpit/588ish/bin/perl -Mthreads -e0 This Perl not built to support threads Compilation failed in require. BEGIN failed--compilation aborted. $ Nicholas Clark
Re: Integrating license related things of CPAN
On Fri, Oct 31, 2008 at 08:03:10PM +, David Cantrell wrote: What if my version of GPL2.txt has an extra CRLF at the end because of how I cut n pasted it from the GNU website? Or has the address changed, as they are wont to do. Nicholas Clark
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
On Sat, Oct 04, 2008 at 01:55:50PM +1000, Adam Kennedy wrote: The magic ponies will be introduced in 5.8.9 and 5.10.1. You indeed will never have to upgrade. 5.8.9 will ship, ponies ready or not. I don't see stable ponies in blead to merge. I'm not the only person who can commit to blead, so someone else can deal with that part. Nicholas Clark
Re: Proposal: Test::Refcount
On Mon, Jul 14, 2008 at 08:32:52PM +0100, Paul LeoNerd Evans wrote:
sub is_1ref
{
my ( undef, $name ) = @_;
my $count = refcount($_[0]);
...
}
The $object in the first code creates a second reference, so you have to
subtract 1, whereas the @_ array seems special and doesn't have that
side-effect.
Until you take a reference to it, or various other things (I cant' remember the
canonical list, but push is in it, whereas shift doesn't seem to be (at least
a simple shift)):
$ perl -MDevel::Peek -e 'sub f {Dump $_[0]; warn [EMAIL PROTECTED]; Dump $_[0];
} f(\$v)'
SV = RV(0x817e18) at 0x800168
REFCNT = 1
FLAGS = (ROK)
RV = 0x800f18
SV = NULL(0x0) at 0x800f18
REFCNT = 2
FLAGS = ()
ARRAY(0x800f00) at -e line 1.
SV = RV(0x817e18) at 0x800168
REFCNT = 2
FLAGS = (ROK)
RV = 0x800f18
SV = NULL(0x0) at 0x800f18
REFCNT = 2
FLAGS = ()
It would be dangerous to rely on this reference counting behaviour remaining
the same.
Nicholas Clark
Re: Is there even a C compiler?
On Mon, Feb 25, 2008 at 03:59:14PM +, Andy Armstrong wrote:
Is there a generally approved way for an XS module to test for the
existence of a C compiler before attempting to build?
Personally I'd like such a test to be standard in MakeMaker, because I am
of the (old fashioned) opinion that if %Config says that there is a C
compiler and there isn't one, then it's lying (and the instalation is broken,
for a small value of broken)
Oh, and I don't want wheels re-invented.
I guess I could just try running whatever $Config{cc} suggests. Are
there any edge cases that that misses? Does $(CC) -o foo.o foo.c work
just about everywhere?
Not sure. Certainly don't test that there is a file of that name in $PATH,
as it's acceptable for it to be a series of shell commands.
Also, you're already making assumptions about object file extension.
You can get that from $Config:
$ perl -V:obj_ext
obj_ext='.o';
Nicholas Clark
Re: Maintenance of IO::Socket::INET6 - http://search.cpan.org/dist/IO-Socket-INET6/
On Fri, Feb 01, 2008 at 08:18:21PM +0200, Shlomi Fish wrote: Due to the fact I did not hear from the original author for 2 weeks, I'd like to ask the CPAN admins to give me (SHLOMIF on the CPAN) a co-maintainer status so I can upload my modifications (and future ones) as a new distribution. Some people go on holiday for more than 2 weeks. Nicholas Clark
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
On Tue, Jan 29, 2008 at 11:47:48AM -0500, David Golden wrote: You mean rather than a skipfile, have an opt-in file? I think that's a good suggestion. I could add that to CPAN::Reporter fairly quickly, but someone will have to go upgrade CPANPLUS or CPAN::YACSmoke and then we have to get all the automated test smokers to upgrade. You mean there isn't a backdoor in the smokers code to allow it to upgrade itself when it detects that it is smoking a newer version of itself? :-) Nicholas Clark
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, Dec 07, 2007 at 03:45:26PM -0500, Guy Hulbert wrote: On Fri, 2007-12-07 at 14:28 -0600, Jonathan Rockway wrote: On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. Hi. Nobody cares about your opinion on this matter. Many perl5 I do. I do, so that's at least 3 people. experiments have been quite successful; for example, Moose. macros? Don't use 'em. Don't like people using macros in CPAN modules? Don't use 'em. Trying to control what other people think and do will get you nothing except flames. I think you could be a bit more charitable in your interpretation of Bill's opinions. He certainly didn't manage to control you very well. Because perl modules can install their own dependencies, his concern is other people affecting *his* choices. One particular problem can be that if something you use adds a dependency on something else you weren't previously using, so you can reach the situation where upgrading to fix a bug will also bring in something new that you didn't want (for valid local policy reasons). Nicholas Clark
Re: Tk / Nick Ing-Simmons
On Thu, Nov 22, 2007 at 04:54:31PM +, Andy Armstrong wrote: I notice that since Nick Img-Simmons' sad passing Tk seems unmaintained. It certainly doesn't build on 5.10. I wonder if anyone knows the status of it and whether anyone is considering maintaining it? Thoughts? I think you're missing what Slaven has been up to: http://search.cpan.org/~srezic/Tk-804.027_501/ Nicholas Clark
Re: Incompatible change in blead perl for Safe.pm?
On Thu, Aug 16, 2007 at 02:11:38PM -0700, Joshua ben Jore wrote: On 8/16/07, Dominique Quatravaux [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joshua ben Jore wrote: caller() is a less-safe kind of operation because it now returns a hash ref of the current lexical pragmas. I don't recall why this new behavior warranted its removal from the default list of safe opcodes. Maybe because if it returns *refs*, the evil guy could then alter what they point to? It isn't clear that modifying the reference does anything. The reference is constructed in the moment that it is asked for. It can contain only strings. I wouldn't swear that it is impossible to have a change be reflected in the data stored in the optree but I suspect it is unlikely. The optree is read only. So the caller implementation has to respect this. However, for efficiency it is constructing a scalar which points to the bytes in the optree. So if anything ignores the readonly flag on the SV it will be changing the bytes in the optree. How Safe this is, I'm not sure. Nicholas Clark
Re: James Freeman's other modules
On Fri, Jan 12, 2007 at 03:09:00PM +0100, Philippe Bruhat (BooK) wrote: Maybe a yearly email from PAUSE asking them to click a I'm still active form would be enough? I get enough spam already. On Fri, Jan 12, 2007 at 08:07:57AM -0600, Andy Lester wrote: How in the world could you determine either unloved or unused? And unupdated certainly doesn't mean that they're not valuable. It can just mean that they have no known bugs. IIRC MJD cites Text::Template as an example of something that people wrongly assume is abandoned simply because the most recent release is some time ago. Nicholas Clark
Re: Modules dealing with data files
On Fri, Nov 10, 2006 at 03:05:53PM +0100, David Landgren wrote: Does that sound sane? Does anyone have some pointers on how to deal with the placement of datafiles on the local system with one module, and having the other module know where to find them? Seems pretty sane to me. No, I don't have a great idea on the other part, aside from sticking the data into a .pm file you generate at build time, after __DATA__, and reading it in from there. (don't forget to close the DATA file handle to avoid wasting resources) Nicholas Clark
Re: Give up your modules!
On Thu, Aug 24, 2006 at 03:16:22PM +0800, imacat wrote: On Wed, 23 Aug 2006 14:28:13 +0100 Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Aug 23, 2006 at 06:52:26PM +0800, imacat wrote: But this ain't right. Crypt-Cracklib is critical to security and user management, Crypt-Rijndael is the current US governmental standard encryption algorithm, and x86_64 is the contemporary architech. It's just not right that they don't work. What would you consider to be the right that should be happening here? Answering that will make answering your next question easier: Working. Sorry, but I don't get the point of your question. Thanks. See below: On Wed, Aug 23, 2006 at 06:52:26PM +0800, imacat wrote: I'm not a skilled C/XS programmer, or I would consider taking over them. Can anybody have advice on this issue? The author made these modules available to you for free. So any support you get is a bonus. In addition, the author has made the source code available to you for free. This means that you are not reliant on him/her for support - you have more options: * Fix the modules yourself * Employ someone to fix the modules for you Given that you have said that you do not currently have the skills to fix these modules, your choices seem to be learn the skills, or employ someone. You seem to be assuming that someone owes you a fix for these modules. For free. I'm not sure why you are assuming this. This is why I asked you what was not right. From your answer what seems to be not right is the modules do not continue to be maintained for free in perpetuity. Nicholas Clark
Re: Give up your modules!
On Wed, Aug 23, 2006 at 06:52:26PM +0800, imacat wrote: But this ain't right. Crypt-Cracklib is critical to security and user management, Crypt-Rijndael is the current US governmental standard encryption algorithm, and x86_64 is the contemporary architech. It's just not right that they don't work. What would you consider to be the right that should be happening here? Answering that will make answering your next question easier: I'm not a skilled C/XS programmer, or I would consider taking over them. Can anybody have advice on this issue? Nicholas Clark
Re: Test-time dependencies.
On Sat, Aug 05, 2006 at 11:27:09AM +0200, Johan Vromans wrote: A. Pagaltzis [EMAIL PROTECTED] writes: That seems wrong. Every module you install contains lists of dependencies, one list for runtime, one for build-time. The CPAN shell won?t ask questions about missing dependencies, that is true. But why does that matter? You have the dependency lists anyway. Let's try to work out an example. You have a build system, and a series of production systems. The production systems need module Foo::Simple. Module Foo::Simple requires Foo::Heavy at run-time, and Test::Ridiculous at build time. A mere build (not install, just build) of Foo::Simple causes Foo::Heavy and Test::Ridiculous to be installed on the build system[1]. After install of Foo::Simple, three new modules got added to the build system. If Test::Ridiculous were not installed, I could chase down the perl installation to find out what files were added[2], and distribute these to the production systems. Now I have to manually weed out the files that are not needed for production. As I said, it increases the maintenance load. This is true if you're installing all modules required in one block. Whereas I believe that the counter arguments come from people who are considering the case of packaging up each module in turn, and marking that package as only depending on the packages (modules) that it stated as run-time requirements, basing that dependency information on the metadata from the modules (instead of what got installed) Nicholas Clark
Re: maintainer for PGP::Mail
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? Nicholas Clark
Re: Testing an FTP module
On Mon, Apr 03, 2006 at 12:56:07AM -0400, Randy W. Sims wrote: Scott W Gifford wrote: I just uploaded to CPAN some FTP-related modules (Net::FTP::AutoReconnect and Net::FTP::RetrHandle). In one of the unit tests, I connect to ftp.cpan.org and retreive MIRRORED.BY to make sure everything works OK. Just in the last little bit, though, I've noticed that a connection to ftp.cpan.org is timing out. So my questions are: * Is ftp.cpan.org a reliable way to access CPAN? Is there a more reliable way, besides looking and MIRRORED.BY? * Is testing by connecting to CPAN an appropriate thing to do? I would guess not. Certainly not without asking permission. In the general case, having module tests make external network connections is a bad idea 1: You are assuming that people will be building your module on a network connected computer. This is never 100% true. 2: Your module's tests can fail due to external factors beyond your control, such as people screwing up DNS, or having other outages. Random test failures tends to annoy your users, and will lead to bug reports. The annoyance is particularly great within organisations running full build tests overnight, because sooner rather than later the tests will fail. Nicholas Clark
Re: Regexp code feature
On Mon, Jul 25, 2005 at 12:07:27PM -0500, Chris Dolan wrote: 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 Annotations are designed for real users. *This* is a bug in the implementation that needs to be documented (preferably fixed) annocpan is not the *master* copy of the documentation of anything. As ever, please report the bug to the maintainer of the module (via the correct mechanism for that module), so that the master can be updated. Otherwise the bug will never be fixed, and the incorrect documentation will continue to propagate elsewhere. Nicholas Clark
Re: Switching Maintenance of a CPAN Distribution
On Sat, Jul 02, 2005 at 10:44:15AM -0400, James E Keenan wrote: Apologies in advance for asking a question which has probably been asked here before. Googling didn't give fruitful results. The author of a CPAN distribution has discussed turning over maintenance of that distribution to me. What is the official way of doing so? I recall being told that there was a form for this purpose at pause.perl.org. However, none of the sub-pages at that site seemed to answer the question. I want the switch to go in such a way that the various indexers don't get confused. The existing maintainer needs to log into PAUSE, then select Change Permissions from the menu on the left. He/she is then presented with a series of select buttons, and wants 2.1 Pass primary maintainership status to somebody else Which gets to a form to select which modules to transfer. Nicholas Clark
Re: Problem while installing optimizer module
On Tue, May 31, 2005 at 03:14:19PM +0530, Sapna Jain wrote: Hello Sir, I m trying to install optimizer module of Perl, but it make test fails, giving following errors. I have red hat Linux as operating system and Perl 5.8.6 installed. I cannot figure out where the actual problem is. To: cpan-discuss@perl.org, cpan-testers@perl.org, module- [EMAIL PROTECTED], [EMAIL PROTECTED], modules@perl.org, [EMAIL PROTECTED] Spamming multiple inappropriate lists *isn't* the correct way to encourage people to help you. Have you read the fine documentation? The Author section gives the current maintainer as Arthur Bergman. Have you tried contacting him? (Also, I don't know the answer to the original problem, so mailing me privately isn't going to help) Nicholas Clark
Re: Removal of old versions of modules can break FreeBSD ports
On Fri, Apr 08, 2005 at 09:08:51AM -0400, Philip M. Gollucci wrote: Ken Williams wrote: Agreed - for providing a stable download link of a CPAN package, backpan is better than CPAN itself. If this could be integrated into the BSD system itself that would be great. -Ken Hi, as a FreeBSD user, I'm interested in possibly implementing this.. Where can I read some documentation about backpan ? I'm not sure if there is that much. Basically backpan is this host running a CPAN mirror: http://backpan.cpan.org/ except that this CPAN mirror doesn't delete things. Nicholas Clark
Re: Seeking Namespace Advice (MVS OS/390 Mainframe Util.)
On Thu, Mar 24, 2005 at 04:52:51PM -0500, Paul Boin wrote: I'm just about to finish up a module that someone might find useful. It emulates two utilities found on IBM Mainframes, IEBUPDTE and IEBPTPCH. For a general discussion, lets just say that these two utilities are similar to tar/untar. I wrote them so that I can bundle local files to upload, and so that I can un-bundle files downloaded from the mainframe. If I were to start fresh, I'd like OS390::IEBUtils. A bit of history: IBM's OS has gone through many names, the three most recent are 'MVS', 'OS/390', and 'z/OS', so it's a little tricky using the OS name as an identifier. The two most closely related existing modules are MVS::VBFile and Convert::OS390. What's a little bit unusual is that this code would only be of interest to a mainframer, but it's designed to run on a PC. Your thoughts are appreciated. I've got a good bit of work in the modules, and don't want to gum up the works with an ineffective or misleading name. If the utilities are archivers, would it work to put them in the Archive:: top level namespace, alongside Archive::Tar and Archive::Zip ? Nicholas Clark
Re: CPAN::Forum
On Fri, Feb 04, 2005 at 02:40:09AM +0200, Gabor Szabo wrote: On Wed, 2 Feb 2005, Nicholas Clark wrote: The same hack as rt.cpan.org uses - attempt a login on pause.cpan.org using the ID and password provided. If PAUSE accepts it, then you know it's the real thing. That would mean my server if cracked could be used to collect PAUSE passwords. I am not sure I'd like to have that responsibility. No, because you don't keep passwords. You do the auth back to PAUSE as you need it, and then merely record in your site's state that you did it. Nicholas Clark
Re: CPAN::Forum
On Wed, Feb 02, 2005 at 08:58:23PM +0200, Gabor Szabo wrote: How would you implement it and if someone comes along and claims he is DCONWAY how can I make sure he really is DCONWAY from PAUSE ? The same hack as rt.cpan.org uses - attempt a login on pause.cpan.org using the ID and password provided. If PAUSE accepts it, then you know it's the real thing. I can't think of a future-proof way of avoiding IDs you allocate conflicting with PAUSE, unless you and Andreas collaborate Nicholas Clark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 11:02:31PM -0600, David Nicol wrote: instead of having to haul around the code to figure this out, why not create a handy documentary web service somewhere where you fill out the blanks and get an appropriate connection string? Loading a module every time you start the program just to create something that is a permanent per-installation configuration constant strikes me has if not ugly, at least hideously post-modern. I'll even donate a spot of server space to the cause if you don't have it already. It's a kind offer, but does your server reach me when I'm working offline? Doubtful. But I have a local CPAN mirror, and run local database servers for development. Nicholas Clark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote:
I don't get it. Can someone give me some small but real examples
of the problem that's being solved here?
The one that I've hit - specifying port and host, Pg vs Mysql (and SQlite):
if ($dbspec-{driver} eq 'DBI:Pg') {
# Aaargh. Why aren't these things standarised?
$dsn = DBI:Pg:host=$dbspec-{domain};
# Aargh. W.T.F. is this case sensitivity here? It fails to connect unless
# the name is all lowercase (as is stored within the non-case preserving
# pg DB)
$dsn .= lc ;dbname=$dbspec-{db_name} if length $dbspec-{db_name};
$dsn .= ;port=$dbspec-{port} if defined $dbspec-{port};
} else {
$dsn .= :port=$dbspec-{port} if defined $dbspec-{port};
}
Nicholas Clark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 10:32:12PM +, Tim Bunce wrote:
On Tue, Nov 30, 2004 at 09:38:47PM +, Nicholas Clark wrote:
On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote:
The one that I've hit - specifying port and host, Pg vs Mysql (and SQlite):
if ($dbspec-{driver} eq 'DBI:Pg') {
# Aaargh. Why aren't these things standarised?
$dsn = DBI:Pg:host=$dbspec-{domain};
# Aargh. W.T.F. is this case sensitivity here? It fails to connect
unless
# the name is all lowercase (as is stored within the non-case preserving
# pg DB)
$dsn .= lc ;dbname=$dbspec-{db_name} if length $dbspec-{db_name};
$dsn .= ;port=$dbspec-{port} if defined $dbspec-{port};
} else {
$dsn .= :port=$dbspec-{port} if defined $dbspec-{port};
}
It seems to me that the problem is of your own making.
Why have separate hash elements for all these things in the first place?
Oops. 1 more line would have helped. This precedes my previous code:
my $dsn = $dbspec-{driver}:$dbspec-{db_name}:$dbspec-{domain};
Even if I keep the DSN in a flat string, I have to remember that MySQL
wants driver:DBname:hostname:port=# while Pg wants
driver:dbname:host=name;port=#
and to me needing to remember all this trivia seems wasteful.
It doesn't actually matter if its in a hash or flat string, there's too much
driver specific already even in the simple bits I would like flexibility in.
In general I find that a hash ref is useful as an argument to a function as
it provides named parameters, which avoids needing to remember a list order
for parameters, and also to have to fill in defaults to make the list up to
the position of the parameter you wish to change.
I guess I don't find it natural thinking about parameters as a single string.
Nicholas Clark
Re: Best Practice for renaming modules?
On Mon, Sep 06, 2004 at 03:42:56AM +0200, A. Pagaltzis wrote: * Mark Stosberg [EMAIL PROTECTED] [2004-08-28 14:12]: 2. Make another release under the old name, leaving the functionality intact, but with a clear disclaimer near the top: This is the last release under this name. Future development will happen under the name New::Name. Please use it when you write or update code. You could have the last release of the old module merely contain a stub that transparently loads the new-name module, possibly with a deprecation warning. The old distribution would then depend on whatever the latest version of the new one is. CPAN.pm will then detect a dependency and automatically install the new module for anyone who requests the latest version under the previous name. Doing this stub with clear descriptive text above seems to me to be the best way to do it. Nicholas Clark
Re: name for singlethreaded web server framework module (chatty)
On Sat, Aug 21, 2004 at 06:52:27PM -0500, david nicol wrote: Better to be a team player and release HTTP::Server::Singlethreaded which would invoke the correct class of considerations for those whose initial referent for Selecting is not the Berkeley socket library. Seems sensible enough (and I read that you've uploaded under that name) Does Perl have non-blocking file IO yet? I know Uri Guttman requested non-blocking file IO some time ago. I've thought about serving larger static files with open my $OutBound, cat $filename|; and incorporating these pipes into the multiplexion, but this approach (1) is not portable to places where cat(1) is not installed and (2) requires more complex multiplexion than is needed for The Task At Hand and is therefore deferred according to the best practices of Extreme Programming. Presumably generating pipes to helper tasks can be done with a module on CPAN? And is it really going to achieve faster non-blocking file IO on anything other than Unix (or Unix-a-likes) where there will be cat? Nicholas Clark
Re: Let's eliminate the Module List
On Mon, Aug 23, 2004 at 04:11:33PM -0400, Robert Rothenberg wrote: It would be a lot of work to implement a workflow system (I wish I had the time), but once it's implemented, the approval work could be Your honesty with I wish I had the time illustrates the problem here. [and the following isn't personal, but for the list as a whole:] Talk is cheap. Sadly none of this will get done unless someone with sufficient desire to do this creates themselves the time and does it. There is nothing stopping anyone on this list prototyping their own improved substitute for search.cpan.org. (although it helps if you have a public facing webserver if you want to show it to others). Yet no-one does. Until someone does, nothing will change. No-one on this list is preventing anyone from trying this. Nicholas Clark
Re: name for singlethreaded web server framework module
On Fri, Aug 20, 2004 at 08:50:16PM -0500, david nicol wrote: I am writing a module that provides HTTP interface using select, for simple web applications without a web-server, and without POE or other modules. Configuration will be by mapping paths to coderefs. I infer from the description that it's going to serve files representing parallel requests by multiplexing using select(). Will it just serve static content, or also dynamic generated content from user code? If so, how do you feed that out via select? - non-blocking API, or just buffer the generated DATA in memory and then feed it out at the pace dictated by select() and non-blocking IO? Planning to call this cute beastie HTTP::Server::Selecting. because I'm not convinced that this name would give much insight into the implications of the implementation, and the trade offs they give. Nicholas Clark
Re: CPAN Rating
On Wed, Jun 16, 2004 at 12:02:17PM +0200, khemir nadim wrote: Now, I'm asking for someone else to do the job (I don't even know who he is) but I'd gladely help if I can, I'd definitively rate more. Which means that it won't get done. All volunteer organisations work in roughly the same way - if you want to get a job done, you have to *start* it yourself. Others may well join in and help once they see that it's a good idea, but things don't get started because someone would like it. [This is an oversimplification. You may be able to persuade someone else that they also care about it enough to do it. But this is as if that person starts on his/her own as above. Likewise someone may be able to get others to start a new project for them, but generally they have earned this by visibly contributing their own blood sweat and tears to something else already.] No-one is stopping you setting up a ratings system. Nicholas Clark
Re: CPAN Rating
On Wed, Jun 16, 2004 at 11:41:12AM -0400, darren chamberlain wrote: I didn't read that as concern about permission. I've also contemplated duplicating or extending some of the functionality of search.cpan.org for internal CPAN mirrors, but I don't want to reimplement *everything*, just add on top of what's already there. So, what do I have to patch to change search.cpan.org? Well, I guess to run a patched version of search.cpan.org on your local system you need to start by running an unpatched version of search.cpan.org. I'm not sure whether the source to it is available, and if so, where to get it. But resolving that seems to be the first step. Nicholas Clark
Re: ExtUtils::Embed and C++
On Sat, May 29, 2004 at 06:23:30PM -0300, SilvioCVdeAlmeida wrote: The error is as follows: In file included from /usr/include/math.h:109, from /usr/local/lib/perl5/5.8.3/i686-linux-thread-multi-64int-ld/CORE/perl.h:2839, from persistent.c:3: /usr/local/lib/perl5/5.8.3/i686-linux-thread-multi-64int-ld/CORE/perl.h:1330: previous declaration of `long double modfl(long double, long double*)' with C++ linkage /usr/include/bits/mathcalls.h:116: conflicts with new declaration with C linkage /usr/include/bits/mathcalls.h:116: declaration of `long double modfl(long double, long double*) throw ()' throws different exceptions /usr/local/lib/perl5/5.8.3/i686-linux-thread-multi-64int-ld/CORE/perl.h:1330: than previous declaration `long double modfl(long double, long double*)' I have a vague idea of what it stands for, but nothing about how to fix it. Could you report this with the perlbug program? (Presumably it's installed as /usr/local/bin/perlbug. The important bit is to make sure that it reports the configuration for your perl you're having problems with). The bug report will get to the perl5-porters list, who ought to see it as I think it's almost a bug in perl (and how perl does things). That list is also more likely to suggest a good way to fix it. Nicholas Clark
Re: [RFC] Text-Balanced 1.96 proposed interface changes: return failure in list context
On Mon, Feb 16, 2004 at 11:50:42AM +, Simon Cozens wrote: This is why I tend to do something like this in Makefile.PL: print WARNING: This new major release is incompatible with previous\n; print releases. Please check any code which uses this module.\n; print Press enter to continue.\n; ; Something that struck me is that your specific text doesn't name the module. Hence if this shows up somewhere in the auto-building of dependencies by the CPAN module the user is going to have to skim back somewhat to work out which module will need its README reading. It would seem that the quick change of rephrasing to add the name the module would save users' time. With this approach, how many subsequent releases of the module do you make before you drop this text? Nicholas Clark
pure perl Zlib
Ton Hospel has written a pure perl implementation of gunzip. (no mean feat) Autrijus sent to the PAR list and asked if anyone could refactor it to emulate Compress::Zlib's interface sufficiently to allow Archive::Zip (and therefore PAR) to work with it (to unpack zip files). It seems that the only 2 functions from Compress::Zlib's API actually need implementing - inflateInit and inflate. I'm partway through this, and I'm wondering what the name should be. Autrijus suggested Compress::Zlib::PurePerl, which I think is reasonable. Are there further suggestions? Nicholas Clark
Re: pure perl Zlib
On Mon, Feb 16, 2004 at 10:43:27AM +1300, Sam Vilain wrote: On Mon, 16 Feb 2004 10:19, Nicholas Clark wrote; Autrijus suggested Compress::Zlib::PurePerl, which I think is reasonable. ...but it doesn't use Zlib! :) Compress::Gzip? But it doesn't compress. Compress:Gunzip? Uncompress::Gzip (Neither really meant as serious suggestions) Problem is that it's an emulation of bits of Compress::Zlib's interface, so I feel that a clue should be in the name. As should the bit that it's pure perl, as otherwise it's like huh, why another front end to some C code? Nicholas Clark
Re: How about class Foo {...} definition for Perl?
On Sun, Jan 18, 2004 at 12:02:43PM +, Simon Cozens wrote: [EMAIL PROTECTED] (David Manura) writes: Since Text::Balanced is a core module, distributed with Perl, I'm not sure what the best way to report these are. E-mail the author? rt.cpan.org? http://rt.perl.org (perlbug)? perlbug. Modules in core should be maintained by perl5-porters, and so bug reports should be submitted there. perlbug takes care of making a new ticket in the main perl queue, and posting it to p5p. But modules in core with a dual life are maintained by their CPAN authors and the current stable CPAN version is merged into the core. The module's documentation should say where to report bugs. However, I'd not expect everyone out there to know precisely which module is maintained by whom, so reporting bugs with perlbug for modules distrubuted with the core is reasonable. [Whereas using perlbug to attempt to report bugs in non-core modules is not, but you all know this] I'm not sure what the specific position is at present with the maintenance of Damian's modules in the core. An example I do know about is CGI.pm - we're passing all bug reports over to its author Lincoln Stein, who is actively maintaining it on CPAN. Nicholas Clark
Re: Version Numbers
On Fri, Jan 09, 2004 at 08:49:59AM +, Andy Wardley wrote: I think it's a good idea for every module to have a version number, even if they are very rarely used. If possible, don't change version numbers of sub-modules between distributions unless they have changed. That way it is easy to tell at a glance that versions 2.10 and 2.11 of the Foo::Bar distribution, both use the same version 3.14 of the Foo::Bar::Magic::Helper module, for example, without having to mess around with diff. I think it's a good idea too, because it makes life easier trying to keep track of files in dual-life modules. The other important bit is to actually change the version number if anything in the file changes. But I'm biased. :-) Nicholas Clark
Re: SQL::Interpolate and *::Interpolate proposals
On Mon, Jan 05, 2004 at 10:04:01PM -0500, David Manura wrote: So, there seems like three main ways out there to implement string interpolation: - use tied hashes - use source filtering (e.g. Filter::Simple) - use a function call on a list (e.g. as done with SQL::Interpolate with source filtering disabled: dbi_interp SELECT * FROM mytable WHERE X =, \$x); I think it's also possible to overload parsing using the overload module. But my brain is hazy on this one. Certainly you should be able to parse a string and decide what to return (string, or object ref) Nicholas Clark
Re: BTRIEVE::*
On Wed, Dec 03, 2003 at 05:12:07PM +0100, Steffen Goeldner wrote: Hi, I'm about to release two modules: BTRIEVE::XS BTRIEVE::API The first, BTRIEVE::XS, is a simple XS wrapper module for Btrieve's single function API. I.e., you can call Btrieve's C function BTRCALL() in perl as BTRIEVE::XS::Call(). Are these namespaces ok? IT STRIKE ME THAT ALL UPPER CASE DOESN'T SEEM VERY perl LIKE. Also, does it need to be at the top level? What is Btrieve? Could your module sensibly live one level down, even if it means creating a new top level for it? Nicholas Clark
Re: Ivy.pm: name change? to upload on CPAN
On Wed, Nov 26, 2003 at 03:31:21PM +0100, Christophe MERTZ wrote: [Changing Ivy to Net::Ivy] BTW: I do not know if this discussion is still appropriate in the mailing list, as I am new on it. Let me know... I don't have an answer to your question about how to do it, but I do think that the discussion is appropriate to this list, as getting this list to work out the the best way making this change will help future authors. This won't be the last time someone asks the list this question for an existing module, and the recommendation is to make this sort of rename. Nicholas Clark
Re: [Module::Build] Re: How to indicate a dependency in my module
On Wed, Nov 12, 2003 at 04:11:45PM +, Sam Vilain wrote: On Tue, 11 Nov 2003 02:29, Michael G Schwern wrote; YAML was chosen because its human readable and writable, its data ^ ^ So long as you're a FREAK who likes INDENTING and WHITESPACE to signify STRUCTURE. Is it any surprise that YAML is supported by PYTHON?! no, not at ALL but GIVEN that XS also treats INDENTING and WHITESPACE significantly, it is STRANGE that there are no YAML modules for perl written in XS. [although I believe that Ingy is working on something] Nicholas Clark
Re: what to do with dead camels ?
On Tue, Aug 05, 2003 at 01:27:47AM -0400, Christopher Hicks wrote: Maybe the e-mail should do something informative like list how many years, months and days it's been since a given module has been updated. Some weak souls might be guilted into pushing out bug fixes sooner. If there are no bugs, there is no need for bug fixes. MJD gets very irritated with people asking whether certain of his modules are abandoned, simply because the most recent version is old. Why are you assuming that all stable code has known but unfixed bugs? If anything, have rt.perl.org send out ping messages about new (but unresponded to) bugs, or maybe open but serious bugs, because these do have content But *do not* send out an all's well message, which will get filtered with the spam to /dev/null, because crying wolf like this will cause people to miss subsequent real, serious, messages. Nicholas Clark
Re: what to do with dead camels ?
On Mon, Aug 04, 2003 at 10:24:29PM +0200, Elizabeth Mattijsen wrote: This could be as simple as sending an email once a month to the CPAN id's mail address and set a flag when it has bounced. Maybe once a year you would like the author to actually reply to make sure the mail isn't going into some bitbucket. Maybe something that Siesta can do as soon as it knows how to VERP... ;-) Yes, but... How much do you hate mailman for all those here is a reminder of your mailing list memberships messages? Happy mailman day? Or curse mailman day? I can see this as a really good way to piss people off. Anyway, it's moot point as you already know that the person assigned to VERP takes an awfully long time to getting a round tuit, so it's unlikely to be finished soon ( http://siesta.unixbeard.net/svn/trunk/siesta/TODO ) Nicholas Clark
Re: Binary File Modules
On Wed, Jun 18, 2003 at 04:52:16PM +, Matt Seddon wrote: It's not yet completly functional, but is aimed at extracting everything you never wanted to know about a binary (probably including resource icons for humour factor). Does anyone else actually even have a use for this package? :) Possibly. IIRC Autrijus Tang was looking for a pure perl way to replace the resource icon on an exe file generated by PAR. I may have some of this wrong, but not the pure perl and replace icon bits. Nicholas Clark
Re: req4comments Reuters::SSL
On Thu, Jul 18, 2002 at 03:42:09PM +0200, Barkey, Christian LUX wrote: Hello, thank you for your comment. You are right, SSL is on the internet most likely confused with the SSL - encryption algorithm/protocol. Even if its a usual Reuters expression to speak of SSL - Infrastructure the meaning is the same as realtime - Infrastructure. Even the expression realtime could also lead to misunderstandings concerning the realtime - operation - systems which garantuee a secified response time to some actions. What shall I do now? I would like to leave the SSL - expression untouched because it's under the toplevel of Reuters and not an own toplevel. Clearly, a search for SSL would also bring up the Reuters::SSL - module, but as well as a search for Realtime would also bring up the Reuters::Realtime - module. Anyway, I will go the democratic way. I wait some time to more responses and if more people would have the name changed to Realtime I will do so, if not the name will be left as SSL. I believe I wouldn't find modules in the Reuters::SSL namespace confusing. I would be confused the other way round - if I found (say) SSL::Reuters was a module that dealt with Reuters' SSL infrastructure and had nothing to do with Secure Socket Layers. So I don't see any problem with calling your modules Reuters::SSL or Reuters::Realtime - people searching for something else at the top level should be smart enough to figure out that it's not what they are looking for. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: howto mirror subset of CPAN?
On Sun, May 26, 2002 at 10:06:06AM -0400, Jay Lawrence wrote: On May 25, 2002 03:24 pm, you wrote: On Sat, May 25, 2002 at 10:13:20AM -0400, Jay Lawrence wrote: Using Rsync and a bit o' Perl I have developed a latest version only mirror of CPAN. Its very crude but if people are interested I could clean it up a bit and let you have it. For a mere $20, with profits going to YAS? That's a good idea. I'll be at YAPC ... maybe there will be some takers there. It's not an original idea, in that Amsterdam.pm got a firm (Nedstat, it says on it) to sponsor a CPAN CD which they gave out for free at YAPC::Europe::2001 Before burning lots you might want to check whether the YAPC::NA guys have borrowed the idea. If whatever OS you're usually using is happy with bzip2 compressed files, then you may be able to cram another 5 to 10% on the CD by turning all the tar.gz files to tar.bz2. You may also make some savings by re-packing zips as tar.gz files, and even more as tar.bz2 Another good idea. I keep running out of disk space. It's less painful than deleting files. But a lot slower, as bzip2 is somewhat slower than gzip. But putting lots of CPU once into compressing more seems to be the correct trade for any write-once, read-many archive. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: howto mirror subset of CPAN?
On Sat, May 25, 2002 at 10:13:20AM -0400, Jay Lawrence wrote: Using Rsync and a bit o' Perl I have developed a latest version only mirror of CPAN. Its very crude but if people are interested I could clean it up a bit and let you have it. For a mere $20, with profits going to YAS? I still find that its hard to strip CPAN down to fit on a CD ... but I am certain that there is some stuff in there that is so specialized that it could be safely excluded. If whatever OS you're usually using is happy with bzip2 compressed files, then you may be able to cram another 5 to 10% on the CD by turning all the tar.gz files to tar.bz2. You may also make some savings by re-packing zips as tar.gz files, and even more as tar.bz2 Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Env::Reject
At 11:00 -0500 01.31.2001, David Boyce wrote: On UNIX it's straightforward: "exec $^X ,$0, @ARGV" out of a BEGIN clause. Linux isn't UNIX: $ cat argv.pl #!/usr/bin/perl -w print "$^X\n"; print "$0\n"; $ ./argv.pl perl ./argv.pl where's perl? :-( [and anyone who assumes that perl is the first perl in my $PATH (eg http://jarl.sourceforge.net/) does not please me] I think that's going to be "interesting" for the rare case where the script comes in on stdin. Nicholas Clark
