Re: OT: lists.cpan.org
Gabor Szabo a écrit : I know there are people who will complain about the fact I did it or the way I did it, I am getting really used to it. So I took the liberty to copy all the data from lists.cpan.org (aka lists.perl.org) to the Perlfoundation wiki. As the data was too big to fit on one page I split it up into 6 pages. Now people should go and manually clean up and reorganize the data. I'll ask the webmaster @ perl.org if they agree to replace the current database with a link to the wiki. Forwarded. (Excellent initiative :) Thanks, David
Re: CPAN Testers - Author Notification System
Barbie wrote, some time around 11/09/2008 16:19: Today I'm pleased to announce the launch of the CPAN Testers' "Collated Email Notification of Tester Reports for Authors Service" [1], a [...] [1] If you can think of a suitable word beginning with 'L' to replace 'Service' let me know ;) Hmm, L is always a bit of a bastard to backronymise link log letterbox David -- stubborn tiny lights vs. clustering darkness forever ok?
Re: [RFC] Dual-lifing test.pl
Nicholas Clark a écrit : On Tue, Jul 01, 2008 at 09:31:22AM -0400, Jerry D. Hedden wrote: If the functionality in test.pl (that does not currently exist in other module) could be duplicated elsewhere using a Test::Builder-based module, would there be a reason then to maintain test.pl? Would it be better then to eliminate test.pl entirely? No, it should stay. It intentionally doesn't use packages internally, and (at least) some other constructions. (specifically ++. I played with this a bit a couple of years ago. What I wanted to do at the time was to see how far one could push the envelope using an absolute minimal syntax, such as replacing unless () by negated if, && and || by 'and' and 'or' (or at least settling on one or the other), eschewing statement modifiers, ternaries and so on. I also wanted to prove that t/base/* and t/cmd/* provided tests for all constructs seen in test.pl, but after playing around with B::Concise for a while I realised it was a non-trivial undertaking. David Although a quick skim suggests that some use of -> for method calls has slipped in, with File::Spec and Config, in which_perl(), fresh_perl* and the isa/can tests) Oh the decadence. Nicholas Clark
Re: Diagnostics
Ovid wrote: --- "Philippe Bruhat (BooK)" <[EMAIL PROTECTED]> wrote: The biggest trouble I had was for diagnostics. I ended up considering that diagnostics output after a test result belong to the test result (as a comment to it), and that diagnostics appearing before the first test result are "global" to the whole test script. Which means that "# Looks like you failed 3 tests of 22." is always attached to the last test. What were you trying to do with the diagnostics? Simply store them, or something more elaborate? Right now, Test::More::Diagnostic can somewhat help: [...] # Failed test 'fails' # at t/fail.t line 11. # got: '3' # expected: '4' # Failed test 'fails structure' # at t/fail.t line 12. # ++--+--+ # | Elt|Got |Expected | # ++--+--+ # | 0|this |this | # * 1|that |other * # ++--+--+ # Looks like you failed 2 tests of 3. I wish you'd s/Got/Actual/ or Received. Got must die. David
Re: BackPAN mirror owners: please delete Finance::FuturesQuote
Shawn Boyette ☠ wrote: On Nov 27, 2007 12:25 PM, chromatic <[EMAIL PROTECTED]> wrote: On Tuesday 27 November 2007 08:53:52 Jonathan Rockway wrote: What legal precedent is there here? Violating the ToS is the responsibility of the user of the module, not people distributing the module. Would you also distribute a module which effectively performed a DoS against search.cpan.org and *.perl.org? There must be some story missing here. Those of us who are only on perl-qa and not whatever list this got started on know nothing except what was stated in David Landgren's message, which, free of context, comes across as somewhere between reactionary and panicky. Barring any revelations (which I now hope are forthcoming), I tend to agree with jrockway. Yes, please accept my apologies for that. There is no list that I am aware of that would have been better. If you know how to get in touch with people who are not obliged to tell you who they are (and even if they did there is no formal channel for doing so) then I'm all ears. Admins running backpan are free to ignore my request and do nothing, that's fine by me, it's not like I'm paid for it. I've done my part by getting the word out, and if we ever hear back from the company (which I doubt) we'll say we did what we could. We now return you to your regularly scheduled Perl-QA. Thanks, David
Re: BackPAN mirror owners: please delete Finance::FuturesQuote
Jonathan Rockway wrote: On Tue, 2007-11-27 at 17:42 +0100, David Landgren wrote: Let's not kill the free software movement by deleting anything that anyone with a lawyer requests to be deleted. I don't think it's anything so serious. It's more like "you played, you lost". The web site owners have to show that they care about protecting their information, which might supported by a click-through ad banner revenue stream or something like that. I am well aware of the futility of the quest, what with Goggle's cache in the short term, and things like the Internet Archive and the Wayback machine in the long term. Nevertheless we have to appear to respond actively to something like this. David PS: I kept a copy of Time::Cubic if you're interested :)
Re: Combatting attempt to censor Finance::FuturesQuote
Jonathan Rockway a écrit : On Tue, 2007-11-27 at 17:55 +0100, Dominique Quatravaux wrote: All publicly accessible BackPAN mirrors must pull this distribution manually, given that rsync-without-delete won't do it for you. Shucks! Too late. http://kilimandjaro.dyndns.org/~dom/FuturesQuote-0.01.pm Come on now. I have no idea whether that thing is any good, but these scare tactics from The Man are just silly. Agree here. One thing to think about: is this going to get the *author* in trouble? It would be nice to change the contact information there to avoid the author being sucked into a legal battle he can't afford. He I'm not particularly worried about the author. It's the backpan admin I'm more concerned for. In this day and age, it's too easy to say: it's your machine, it's your fault. The admin is an easier target than the author. doesn't deserve legal trouble simply because he wrote a useful CPAN module that someone doesn't like... but I can't afford to defend him against a $LARGE_COMPANY. I recommend we delete the AUTHOR information and distribute this module on thepiratebay. I will definitely seed the torrent. I really don't think it's worth the trouble. For all I know they have a sanctioned API that lets you do the same thing anyway. I dunno, I didn't care to look. DAvid
BackPAN mirror owners: please delete Finance::FuturesQuote
Hello and apologies for the cross-posting. PLEASE TRIM FOLLOW-UPS TO PERL-QA ONLY. All other non-discussion queries regarding this matter may be directed to [EMAIL PROTECTED] Finance::FuturesQuote scrapes information from a web site that offers (I would imagine) futures quotes. The author of this module has received a cease-and-desist letter from the owner of the web site, since the module is in violation of the Terms of Use. The module is currently not available on CPAN, but it still lurks on the BackPAN (which is where the site owner tracked it down). I don't know off-hand the exact list of who is currently mirroring, I think there are two or three people only. All publicly accessible BackPAN mirrors must pull this distribution manually, given that rsync-without-delete won't do it for you. I don't know of any better way of reaching potential backpan admins, if anyone has a good suggestion I'm all ears. (I'll post to c.l.p.m from home tonight). Thanks, David
Re: New proposed CPANTS metric: prereq_matches_use
Thomas Klausner wrote: The metric will be called prereq_matches_use and shall check if all the modules used in a dist are also listed as a prereq. (prereq is either gatherd directly from Meta.YMLs 'requires', by parsing Build.PL or Makefile.PL) As you might know this is quite tricky, because some modules live in strange dists (e.g. HTTP::Request -> libwww-perl) and some modules are in Core (I'll check this with Module::CoreList). The first implementation 'simply' selects all distinct dists from all modules (of which CPANTS know which dist they are in..) used in a dist, and compares this with the distinct dists from all listed prereqs. I have just looked at the latest CPANTS results. I see that all my modules fail this metric... but I am unsure as to why. Consider: http://cpants.perl.org/dist/prereq/Integer-Partition I agree, it's probably best to list Carp, but do I really declare pragmas like 'strict' and 'vars'? How many ISPs remove *them*? Does the metric include modules used in the test suite? I write my test suites to deal gracefully with missing Test modules. David
Re: Ownership rot in the Phalanx 100 page
Andy Lester a écrit : On Nov 15, 2007, at 4:52 AM, David Landgren wrote: Andy Lester wrote: I imagine that there are other modules in the same boat. Perhaps a better solution is to avoid the ego points, drop the author link, and just point to http://search.cpan.org/dist/Crypt-SSLeay/ instead. You wanna take care of that maintenance task? My plate is plenty full. Sure. Send me the details off-list. Would you take care of the other cleanup tasks needed at qa.perl.org? You don't want to bother learning Combust if all you'll be doing is changing one page. Is there much that needs doing? I am reasonably familiar with Combust. David
Re: Ownership rot in the Phalanx 100 page
Andy Lester wrote: I imagine that there are other modules in the same boat. Perhaps a better solution is to avoid the ego points, drop the author link, and just point to http://search.cpan.org/dist/Crypt-SSLeay/ instead. You wanna take care of that maintenance task? My plate is plenty full. Sure. Send me the details off-list. DAvid
Ownership rot in the Phalanx 100 page
I just fielded a question addressed to [EMAIL PROTECTED] asking about "10 essential Perl modules every programmer should know about". In the reply, I mentioned in passing the Phalanx 100 http://qa.perl.org/phalanx/100/ I took another look at it, and noticed that in the time since it was published, I have since become the maintainer of Crypt-SSLeay. The page links to the current-at-the-time author directory (CHAMAS). My version is 0.57, but the version in Joshua's directory is 0.51 (which cannot even be built with current OpenSSL libraries). I imagine that there are other modules in the same boat. Perhaps a better solution is to avoid the ego points, drop the author link, and just point to http://search.cpan.org/dist/Crypt-SSLeay/ instead. David
Re: TAPx::Parser 0.50_06 -- Now on Windows!
David Landgren wrote: Try perldoc vmsperl for more details. *snort* Try perldoc perlvms for any details :)
Re: TAPx::Parser 0.50_06 -- Now on Windows!
Andy Armstrong wrote: On 21 Jan 2007, at 13:28, Abe Timmerman wrote: I see now that on OpenVMS you also use IPC::Open3, that in turn uses fork(). fork() is not implemented on OpenVMS, so this will not work. Although I'm not a VMS expert, I do have a testdrive account, and can test some stuff if that helps. Does anyone know the idiom for launching a process and capturing its output on VMS? If we can get that I'll plug it into TAPx::Parser. It's been over 10 years since I played with it, but I'm pretty sure it Just Works: vmsperl does the redirection itself. You can system( "perl test.t 2>&1 >test.out" ); and the startup code within the perl interpreter strips out and performs the redirection. By the time you start running test.t, @ARGV is empty, but stdout and stderr are redirected. Try perldoc vmsperl for more details. David
Re: Comment about BAIL_OUT
Ovid did write: --- Michael G Schwern <[EMAIL PROTECTED]> wrote: Adam Kennedy wrote: Personally, I've always wanted a per-file bail_out as well, that can just abort the current test script, rather than the entire testing process. Schwern? :) die. Definitely the way to go. Up until I started moving the loading of Oh, for a moment I thought Michael was talking about Adam :)
Re: Comment about BAIL_OUT
Greg Sabino Mullane wrote: [...] [1] I've never had a need for random tests myself. The only reason I break mine apart is to isolate testing various sub-systems, but I almost always end up having some dependencies put into an early "00" file. I also tend to a have a final "99" cleanup file. While I could in theory have each file be independent, in practice it's a lot of duplicated code and a lot of time overhead, so it's either the 00-99 or (as I sometimes have done) one giant testing file. Ah, then I suppose you have never considered the need to run a huge test suite in parallel on a multi-CPU box, where tests really are run at random (in relation to each other). 99 may complete before 00 has finished. This is a big problem for the test suite of Perl itself. David
Re: Modules dealing with data files
Sébastien Aperghis-Tramoni did write: Sébastien Aperghis-Tramoni wrote: [...] Er, sorry for mixing things up; my previous mail should have been sent to module-authors@perl.org, not to [EMAIL PROTECTED] That's ok, everyone's on both lists :) -- "It's overkill of course, but you can never have too much overkill."
Re: CPANTS and META.yml
Thomas Klausner wrote: Hi! I had some time recently and added some first META.yml checking to CPANTS (with the help of Gabor Szabo): Aha, since I have your attention... I've been meaning to suggest the following changes, on the best and worst reports pages: This distributions got the most Kwalitee: --> These distributions have the most Kwalitee This distributions got the least Kwalitee: --> These distributions have the least Kwalitee Question: how are the dists sorted on the /author/CPANID page? David -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: Bioperl
Nathan Haigh wrote: I have just discovered the cpants and was wondering why only version 1.2.3 of bioperl has made it in and not the latest version 1.4? Does anyone have any ideas about this? I noticed the same thing. A module I released over a week ago is still stuck at version n-1. I think domm's CPAN mirror is not receiving updates from somewhere upstream. DAvid Cheers Nathan -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: Suggestions for cpantesters
A. Pagaltzis wrote: * David Golden <[EMAIL PROTECTED]> [2006-10-02 12:55]: This creates an interesting quandary: subscribe to the list and be deluged with thousands of emails or don't subscribe to the list and accept that your test reports won't show up immediately. Good mailing list software gives you the option of receiving no mail to a subscribed address (primarily for the benefit of people who use multiple addresses and want to be able to post with several of them). I suppose the listserv at perl.org does not have such an option? Nope. ezmlm is specifically designed to not allow this, apparently for performance reasons. If you don't want the messages, unsubscribe. http://www.ezmlm.org/ezman/ezman1.html#ss1.10 Yeah, I think it sucks too. David -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: CPANTS quality brainstorming
Thomas Klausner wrote: Hi! On Tue, Sep 12, 2006 at 11:07:28PM -0500, Chris Dolan wrote: I posted all of my thoughts on the Perl-QA wiki here: http://perl-qa.yi.org/index.php/CPANTS_Quality_Goals Cool! I added a few things, most notably the new has_license metric (thanks again to Gabor Szabo for implementing it). (BTW, there was quite a drop in the CPANTS game highscore lists, as lots of dists don't come with a license (9064 to be exact) Oww, that includes all of mine, even though they state clearly in the docs that they are distributed under the perl license. I assume this looks at the META.yml license key? I guess it's time to take ExtUtils-MakeMaker-6.30_04 for a spin, I guess. Thanks, David -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: $parser->unexpectedly_succeeded;
Ovid wrote:
Hi all,
For the TAPx::Parser, I need a better way of tracking all tests which
unexpectedly succeed. The simple way is to have the user accumulate them while
the tests are running:
while ( my $result = $parser->results ) {
if ( $result->is_test && $result->has_todo && $result->actual_passed ) {
# test unexpectedly succeeded
}
}
That's ugly. Really ugly. However, it reads clearly (once you know the
methods). It seems better if I can have individual tests report this status:
if ( $result->unexpectedly_succeeded ) { ... }
Unexpectedly succeeding is a consequence of upstream code change. The
thing *you're* interested in is the todo aspect.
todo_done
todo_succeeded
todo_passed
todo_ok
Something along those lines?
David
--
Much of the propaganda that passes for news in our own society is given
to immobilising and pacifying people and diverting them from the idea
that they can confront power. -- John Pilger
Re: some CPANTS news
Thomas Klausner wrote:
Hi!
I've found some tuits to spend on CPANTS, so I changed the whole author
rating thing (aka the CPANTS game).
I've split the metrics into core metircs and optional ones. At the
moment, the only optional metric is 'is_prereq'.
I've also changed the kwalitee rating from absolut to relative (i.e.
percentages).
If a dist satisfies all core metrics, it gets 100% kwalitee. If it
satisfies all core and optional metrics, it gets more then 100%
kwalitee.
For the author rankigns, I'm not counting the optional metrics. So now
you won't loose rank if you publish a new ('perfect') dist because
nobody is using it...
As much as I enjoy the heady rush of being ranked number one among a
select group of leet Perl hackers, I must say that I have to cast a vote
in favour of the previous method of scoring. Somehow the new way seems
less fun. Or put the old scores in a third column.
I think the enjoyment of getting that last extra point for 18 Kwalitee
far outweighs the anguish due to the decline in mean Kwalitee when
releasing a new module. After all, this decrease tends towards zero as
the number of your released modules increases towards infinity!
And thanks for all the hard work you've put into this,
David
--
Much of the propaganda that passes for news in our own society is given
to immobilising and pacifying people and diverting them from the idea
that they can confront power. -- John Pilger
Re: Real Kwalitee, or please stop spending time thinking about CPANTS
Adam Kennedy wrote: [...] I'd actually love to see some statistics, if we are collecting any, of the "good vs bad" scores for the various kwalitee elements over time. That might give us a better idea of how big an impact there is. Of course, we wouldn't have any stats from before CPANTS existed... The truth is out there, if you care to ferret it out. You just have to pull down the previous versions of modules from one of the backpan. David -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: [Slightly OT] Understanding Software Licences [was Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]]
Shlomi Fish wrote: On Friday 07 July 2006 18:39, Andy Lester wrote: Those who disagree with Shlomi on licenses are small-headed and ignorant. Got it. Keep digging that hole, Mr. Fish! That's not what I said or meant. What I meant was that someone here said and I quote: http://www.mail-archive.com/perl-qa%40perl.org/msg06038.html <<< Personally, I'm happy enough to sign my modules as "licenced under the same terms as Perl itself", thereby letting other people deal with a matter for which I have next to no interest in. Hey! That was me! I recognise my hand-writing. My own take on this is that even if your code was better, I wouldn't use it, since I couldn't be sure that my use of it may in some way violate its terms. At least I know where I stand with the GPL and AL. Life is short, and the less I have to think about licensing issues, the better. From my interpretation, what he said was "I don't care to understand licenses enough so I don't want to be bothere with it." Now I think this is a rather small-minded approach to this issue, which I think is very bad. Perhaps, the response to Ovid about it instead of this message was not appropriate, or I may have misunderstood what Ovid said. Ah, that would explain why my hat keeps falling down onto my nose. It was a rational decision that makes perfect economic sense (or is that an oxymoron). If I may reformulate my position, it would be more "I have expended a certain effort to understand licenses, but they are nearly completely opaque to me, since they are written for a legal audience. I therefore choose to defer to the judgment of others who have spent considerable effort on this issue, thereby freeing me to devote my attention to other matters". Rather than choose to spend my insufficient spare time learning more about law, I choose to spend it writing the occasional module that is released onto CPAN under the same terms as Perl itself. Thanks to the efforts of others, I can stand on their shoulders, knowing that they have thought about and taken care of licensing issues for me. I thank you for alerting me to the MIT/X11 license. I now know it exists. That doesn't mean I'm going to start hunting down information about it, but if I come across a Great Computer Language Licensing Shoot-out, I will pay more attention to it than I might have otherwise. And my small mind believes that this is about as much as you can hope for from most people. David -- hope still, a little resistance always maybe stubborn tiny lights vs. clustering darkness forever ok?
Re: TAP diagnostic syntax proposal
demerphq wrote: On 7/13/06, David Landgren <[EMAIL PROTECTED]> wrote: [...] >> They strike me as the teams most intuitively recognizable and least open >> to misinterpretation. I choose to disagree. If so i think you might be disagreing with yourself. :-) That was a quote of Smylers agreeing with _your_ proposal. Gah. ENOCONTEXT. I thought that was you talking about Have and Want :) David -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: TAP diagnostic syntax proposal
demerphq wrote:
On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
David Landgren writes:
> Expected and actual has a long tradition in scientific endeavour,
And are still sucky as they are different lengths meaning the two
outputs are offset on the screen making it harder to see the failure.
Yves, that is absolute nonsense. The current output already has it that way:
% perl -MTest::More -e 'plan(tests => 1); is("slothrop", "porpentine")'
1..1
not ok 1
# Failed test in -e at line 1.
# got: 'slothrop'
# expected: 'porpentine'
# Looks like you failed 1 test of 1.
They look lined up to me.
They strike me as the teams most intuitively recognizable and least open
to misinterpretation.
I choose to disagree.
I think its more important to instantly see the difference between two
simple outputs than it is to use the most absolutely appropriate
terms.
But you cannot instantly see with what you suggest, since the two words
are *exactly the same length*!
With 'expected' and 'actual', the lengths are different, that's the
whole point. And of course, they would be appropriately right-justified
to line up their values.
Also how can people misinterpret:
Want: X
Have: Y
They are not very typographically distant.
David
--
Much of the propaganda that passes for news in our own society is given
to immobilising and pacifying people and diverting them from the idea
that they can confront power. -- John Pilger
Re: TAP diagnostic syntax proposal
Jonathan T. Rockway wrote: I agree that "got" is generally a good word to avoid in formal writing, but in a testing protocol I think that it's an acceptable abbreviation No! Do not accept inferior substitutes, strive for perfection. for "the actual result". Especially since "received" doesn't quite convey the right meaning here. Maybe "expected data" and "actual data" Expected and actual has a long tradition in scientific endeavour, and is what I put forward last year, the last time this subject came up. (or "expected" and "actually") are better? Or maybe "got" is fine; HTTP still works even though "Referer" is misspelled. So we should use Recieved? :) Has got/expected ever caused any confusion to anyone (including non-speakers of English)? If so, why? Yes me, and I am a native speaker (well, Australian... so... whatever...) I ranted about this on -qa some time back, and Schwern said that it was too late to do anything about it now. But this new format allows me to roll out my rant again! My confusion regarding "got" is that I never know whether it's what I got initially, and then I want to see what the test brings back, or whether I have something, and it's what I got back from the test. On a number of occasions I have stared at a failing test, wondering why when I run it manually or stick in printf statements I appear to be getting the right thing. Or the wrong thing, whatever. It gets me confused. Compounded by the fact that, as others point out elsewhere in this thread, the order of appearance is backwards. A primary school teacher taught me that "got" was a word of the weak, that can nearly always be replaced by something better. This is the only lesson that still stands out vivdly for me from that time. Here, let me dig up that rant: http://www.mail-archive.com/perl-qa@perl.org/msg03999.html Thanks, David -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: Proposal Suggestion - Test::Run
Shlomi Fish n wrote: I don't see using the X11 licence for my software as anti-social. Like I said, But it is. You are forcing people to spend some of their precious time to understand the ramifications of this different license, and consider the differences between it and the GPL and AL. anyone can easily fork it as a software of a different licence. It's also Again, you are forcing people to expend effort for what could otherwise be a non-issue. more permissive than the GPL+Artistic licence (and much less problematic than the Artistic 1.0 licence, which some people don't even consider as free-as-in-speech.) That's their problem. So far I've released all the software (Perl or otherwise) for which I had a choice under the Public Domain or X11 licence. Personally, I'm happy enough to sign my modules as "licenced under the same terms as Perl itself", thereby letting other people deal with a matter for which I have next to no interest in. My own take on this is that even if your code was better, I wouldn't use it, since I couldn't be sure that my use of it may in some way violate its terms. At least I know where I stand with the GPL and AL. Life is short, and the less I have to think about licensing issues, the better. David Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%. Indeed. -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: Module requirements
Smylers wrote: David Cantrell writes: rsnapshot (for example) has its own code for traversing a directory tree, its own cut-down Memoize, and probably a few others that I've not found yet. That said, I don't want to see those things go into the core, because I'm in the "the core is too big already" camp. Um, surely File::Find and Memoize are already in the core? perl -MModule::CoreList -le 'print Module::CoreList->first_release($_) for @ARGV' File::Find Memoize 5 5.007003 (um, that can no doubt be golfed, but you get the picture). Executive summary: File::Find has always been there, Memoize, since 5.8. David -- "It's overkill of course, but you can never have too much overkill."
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
demerphq wrote: On 4/4/06, Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote: (*) Yes, I know that the core Perl distribution includes many modules, but ask any P5Porter and he'll answer you that the core is over-crowed and that all core modules that can be made dual-life should be released on the CPAN. I dont agree with this. Or rather, I dont agree that the core is over-crowded. I do agree that as many modules should be dual-lifed as possible however, but that is just so you can upgrade without upgrading perl. There are some crappy modules in the core, though. I mean, look at C. I'm never likely to use that in a million years. (partly because the documentation doesn't help me understand what it buys me). Or C. I know what it does, but its purpose is so specialised (and in this international age, woefully parochial) that it hardly deserves core status. It's just that it's been in there forever. In another universe it would be on CPAN only. Possibly with some sort of plug-in architecture to let you switch in Metaphone and other algorithms. Then it might be a bit more useful. There are also some mistakes, like Switch, but once a module goes in, it can never be removed. That's the main reason why people are so leery these days of adding new stuff to the core, in case they get it wrong. Personally i think the "core is too big" argument is a red-herring given that bandwidth is as cheap as it is these days. Adding a couple I don't think bandwidth is the argument. of modules to core would increase the rsynch time by what a second or two? It would suck up a couple of extra K, something like 1% of what most of use for our web-browser cache. So the size argument IMO doesnt hold water. There is the multiplier effect of having that new K stored on all the mirrors to keep in mind. Also, there is a tension in the community relating to this issue that i dont think we will see any resolution of soon. Many module authors set a design objective of making their modules "dependent only on core modules". This is a comment that I see on a regular basis. As long as the core modules are there on the basis that they serve as building blocks to build other modules, I don't see any problem with that. The trouble is that all the cool tools are evolving so rapidly that putting them into core would really cramp their style. IMO this objecitve is in direct contradiction of the purported P5P objective of not adding stuff to the core and just makes omissions from the core even more critical. I'm curious, what's critically lacking? Anyway, i just wanted to add this because I dont think that you can take it for granted that all perl5porters believe the core module set should be as restricted as possible. I dont. I believe that the core should contain out of the box enough support for the various platforms that perl runs on that when people write code based only on core modules they can do a good job without reinventing wheels or code duplication. What wheels are being reinvented, or what code is being duplicated? I think the core problem-space isn't too bad. I'm not sure that there are many intermediate level modules left out there that can be applied to generic module development. I'm not sure that I want to drink the Class::* kool-aid. Long term i think the community needs to sort out this problem because I dont think there is consensus on it, and I think that a lot of people only look at the issue from their own individual point of view. If somebody is concerned about the overall quality of perl and CPAN I think a more holisitic point of view is required. Who was it who was working on the global CPAN dependency graph, to figure out what module was dependent on what? Whatever became of that? I think hard numbers that stand on their own merits are about the only way to get new stuff into core. Let the early adopters try out non-CPAN low-level modules. Then after a while, see what floats to the top. David -- "It's overkill of course, but you can never have too much overkill."
Re: New kwalitee metric - eg/ directory
Tels wrote: Moin, My modules are usually so feature crammed that they need a few examples for showing what you can all do with it or to enable the user oto use the modul without having to write/use perl code first. Plus, the code cut and pasted from Synopses winds up with 8 space leading indents or whatever, that you have to strip out and/or you forget to turn off vi's auto indenting so you have this massive staircase effect and the last line starts at around column 160. Hate hate hate. David Best wishes, Tels -- "It's overkill of course, but you can never have too much overkill."
Re: New kwalitee metric - eg/ directory
Steve Peters wrote:
On Tue, Mar 14, 2006 at 04:52:18PM +0100, David Landgren wrote:
[...]
/eg scripts are a nice "hands-on" way of finding out how a module works
in real life.
No distribution should be without one!
Unless, of course, it has an examples/ directory, which would cause the
kwalitee test to fail. ;) I do think its a good idea, especially with
large, all-encompassing type modules to provide some examples, but
testing for (in effect, regulating) the name of the directory that will
be difficult to do.
Man, you wanna start a religious war or something?
I wasn't proposing to regulate anything, merely document existing
practices. After haved grepped through a fair portion of my local
mirror, at a bare minimum the pattern to match an eg directory looks like
m{/(?:e(?:xamples?|[gx])|(?:Ex|s)amples?|contrib|demo)/$}
If an obvious name is overlooked, I'm sure people will draw attention to
it after the first iteration :)
David
Steve Peters
[EMAIL PROTECTED]
--
"It's overkill of course, but you can never have too much overkill."
New kwalitee metric - eg/ directory
Hey! It's been over two months since we last had one of these suggestions! I did battle with a module that shall remain nameless the other day. I had a difficult time figuring out how to use it. In times like these, I like being about to go to the build directory and p(aw|ore) through the eg/ directory and take a script and bend it into a suitable shape. The package in question didn't have an eg/ directory, so I had to spend far more time studying the source and running it through the debugger than I really cared to. For instance, I know that when I have something tricky to do with HTML::Parser, I know there's always going to be something close to what I need to do in the eg/ directory. I think its a good adjunct to POD, which tends to be more (or should be) more theoretical. /eg scripts are a nice "hands-on" way of finding out how a module works in real life. No distribution should be without one! David -- "It's overkill of course, but you can never have too much overkill."
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
David Cantrell wrote: brian d foy wrote: <[EMAIL PROTECTED]> wrote: Hopefully it will be something like: $I::don't::bother::to::write::portable::code=1; ;-) Seriously though, I would expect things in Win32::* to only work on Windows, things in Linux::* only to work on linux, and so on for many other sections (including Mac::* where I have some modules). Portable code isn't always the goal. I want my code to be more like File::Spec, which provides a common interface to a load of platform-specific modules. That has very good coverage of bizarro OSes, and I think we'd all agree that it's an excellent example of a nice portable module. It doesn't work on RISC OS though. I suppose that this is less that RISC OS is so truly bizzare that it defies anyone to come up with platform-specific File::Spec code for it, and more a gentle nudge on your part for someone to find the tuits to do so? David -- "It's overkill of course, but you can never have too much overkill."
Re: YAML and Makefile.PL (was various topics)
Tels did write: Moin, [...] So, MakeMaker should be fixed to generate proper META.ymls without the kludges nec that I needed. Of course, Schwern wills say "patches welcome" and I am not up to patch MakeMaker :-( (The other way would be the META.yml file for CPAN to be generated, but that just shifts the problem and is not really a solution. The author knows best what goes in META.yml) The current development code in Schwern's repository does indeed generate the license field in META.yaml, as of version 6.30_01. http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker/trunk/ David Best wishes, Tels -- "It's overkill of course, but you can never have too much overkill."
Re: CPANTS: released_while_burning_midnight_oil
David Cantrell wrote: A. Pagaltzis wrote: * Ian Langworth <[EMAIL PROTECTED]> [2005-11-14 18:15]: PS. If you feel that sarcasm and satire are not best reflected in email, I cordially suggest that you eat a helicopter. What wine is more appropriate with helicopters, though, white or red? If they're UN Stormtrooper Black Helicopters, it has to be a Pinot Noir. Of course, if the module is under the Text:: hierarchy, then a glass of Chardonnay is recommended. David -- "It's overkill of course, but you can never have too much overkill."
Re: Sometimes MakeMaker won't make.
James E Keenan wrote: Rob Bloodgood wrote: Adam Kennedy wrote: Doesn't makemaker only like you if you have a single .pm file just in the root directory? And otherwise you have to have your lib files actually under lib? lib/Tree/Splay.pm lib/Tree/Splay/Node.pm lib/Tree/Splay/IntRange.pm t/01_basics.t t/02_compat.t Makefile.PL MANIFEST [snip] Well... I don't know if your conjecture is true, but your suggestion worked like a charm. Thanks! (and now I'm on my way to reorganize my other distribution...) To get the directory and file framework which MakeMaker (and its young cousin, Module::Build) likes to play with, you can use any of a number of Perl extensions on CPAN. I'm now maintaining ExtUtils::ModuleMaker; Ricardo Signes maintains Module::Starter. They'll each save you from these kinds of problems in the future. The trouble is... I *like* having the files in the root directory. Having them in lib/foo is a real hassle (from a filename tab-completion point of view). Of course, I don't have any multi-module files, so it seems I've been lucky. David -- "It's overkill of course, but you can never have too much overkill."
Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license
Chris Dolan wrote: On Nov 2, 2005, at 10:19 AM, David Landgren wrote: Chris Dolan wrote: In the last year as a Fink maintainer (Mac OS X debian-like package manager), I've come across a couple CPAN modules that have no license information at all. It's very frustrating. I've submitted RT bugs, but one of them has been fixed (thanks Ken Williams). To encourage authors to correct this oversight, I propose a new pair of Kwalitee tests. Both would be nice, but if either of them were implemented, I'd be thrilled. I'd prefer that someone else implement the test (lack of tuits), but if there is approval for the idea without a motivated implementer I will take a hack at it. 1) has_license -- check for the presence of a file named something like LICENSE or COPYING or COPYLEFT or GPL or ... (each test case insensitive, with or without .txt extensions). Alternatively, the test can be more liberal by looking for the string "copyright" in README, *pm and *.pod. 2) has_meta_yml_license -- check for a META.yml field named "license". Module::Build supports this. That would suck, you may as well propose a Kwalitee bit for modules that use Module::Build. I know that the current alpha of ExtUtils::MakeMaker supports this, but until it is released as stable *and* module authors have the time to upgrade EU::MM *and* release a new version of their module (s), those authors will be penalised through no fault of their own. David What penalty? The whole point of Kwalitee is not to reward authors who jump through hoops, but to encourage authors to live up to community I don't know how to distinguish between someone who likes to jumps through hoops and someone who cares about their modules. I choose to achieve the highest possible Kwalitee for my modules because it's a way of showing people that I care. expectations. That includes good packaging, good POD and, I say emphatically, clear licensing. Anything we can do to encourage authors to more clearly state their license is a good thing. If that in turn means encouraging them to 1) use Module::Build, 2) upgrade EU::MM or 3) hand-edit META.yml, then I think that's a burden worth bearing. My licensing terms are clearly stated in the POD, using the more-or-less canonical "licensed under the same terms as Perl itself" term. I am not going to use Module::Build. I've tried it but I prefer EU::MM, at least for the time being. I'm all for the concept, but I wanted to do something really basic with it for a new module a while ago. I forget the details, but after futzing around for a while I just found it easier to go back to EU::MM. Hand-editing META.yml doesn't work. It gets overwritten when I make tardist or something. If there's a way around that, I'm all ears. You're complaining that its too big a burden to clearly state your module's license? To me that's just crazy. To some people, the license is actually more important than the module (e.g. if I can only redistribute Artistically license code). No. I'm complaining that there's no need for two different Kwalitee points for this, that's all. I think one is sufficient (and a very worthy one I should add, in case I wasn't being clear, which I probably wasn't). David -- "It's overkill of course, but you can never have too much overkill."
Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license
Chris Dolan wrote: In the last year as a Fink maintainer (Mac OS X debian-like package manager), I've come across a couple CPAN modules that have no license information at all. It's very frustrating. I've submitted RT bugs, but one of them has been fixed (thanks Ken Williams). To encourage authors to correct this oversight, I propose a new pair of Kwalitee tests. Both would be nice, but if either of them were implemented, I'd be thrilled. I'd prefer that someone else implement the test (lack of tuits), but if there is approval for the idea without a motivated implementer I will take a hack at it. 1) has_license -- check for the presence of a file named something like LICENSE or COPYING or COPYLEFT or GPL or ... (each test case insensitive, with or without .txt extensions). Alternatively, the test can be more liberal by looking for the string "copyright" in README, *pm and *.pod. 2) has_meta_yml_license -- check for a META.yml field named "license". Module::Build supports this. That would suck, you may as well propose a Kwalitee bit for modules that use Module::Build. I know that the current alpha of ExtUtils::MakeMaker supports this, but until it is released as stable *and* module authors have the time to upgrade EU::MM *and* release a new version of their module(s), those authors will be penalised through no fault of their own. David These tests should not care which license is claimed, just that there is a license present. Chris -- "It's overkill of course, but you can never have too much overkill."
Re: cpan testers and dependencies
Fergal Daly wrote: http://www.nntp.perl.org/group/perl.cpan.testers/257538 shows a fail for Test-Benchmark but the fail seems to be caused by CPANPLUS not installing dependencies: Apparently it's a bug in CPANPLUS that stops it from keeping track of grand children dependencies. @INC winds up only containing the first level of prerequisites. That is, if A prereqs B, and B prereqs C, then after having built C and then B, when testing A, only B appears in @INC. There's a bug report on this on RT. In the meantime, I've given up smoking :( DAvid -- "It's overkill of course, but you can never have too much overkill."
Re: Test::Kwalitee - Where is it hosted?
Dave Cross wrote:
David Landgren wrote:
Gavin Henry wrote:
Dear List,
In "Perl Testing - A Developers Notebook" it has a section on
Test::Kwalitee.
I can't find this module anywhere, nothing on the CPAN or on Google.
It would only be POD, I imagine.
Anyone know where it's hosted?
Kwalitee, as in cpants.perl.org, is run by Thomas "domm" Klausner.
What is Kwalitee
http://cpants.perl.org/kwalitee.html
Y::E 2005 Braga slides by Thomas Klausner
http://domm.zsi.at/talks/2005_braga_cpants/s2.html
Actually the book strongly suggests that it's a real module which runs
the Kwalitee checks on your code
Download and install Test::Kwalitee. Then add the following code to
your t/ directory as kwalitee.t:
#!perl
eval { require Test::Kwalitee };
exit if $@;
Test::Kwalitee->import( );
That's from section 4.9 Validating Kwalitee.
Perhaps this has been subsumed into what is now Module::CPANTS::Generator?
DAvid
Dave...
--
"It's overkill of course, but you can never have too much overkill."
Re: Test::Kwalitee - Where is it hosted?
Gavin Henry wrote: Dear List, In "Perl Testing - A Developers Notebook" it has a section on Test::Kwalitee. I can't find this module anywhere, nothing on the CPAN or on Google. It would only be POD, I imagine. Anyone know where it's hosted? Kwalitee, as in cpants.perl.org, is run by Thomas "domm" Klausner. What is Kwalitee http://cpants.perl.org/kwalitee.html Y::E 2005 Braga slides by Thomas Klausner http://domm.zsi.at/talks/2005_braga_cpants/s2.html David -- "It's overkill of course, but you can never have too much overkill."
Re: Apologies for my last post.
Thomas Klausner wrote: Hi! On Wed, Sep 28, 2005 at 12:41:31PM +0100, Gavin Henry wrote: I have just re-read the summary of this list; "A list for discussing and planning CPANTS, the quality assurance effort for CPAN modules." and realised this is the wrong list for my last post. No it's not. module-authors is perhaps a better fit. David -- "It's overkill of course, but you can never have too much overkill."
Re: New kwalitee test, has_changes
Adam Kennedy wrote:
Michael Graham wrote:
[...]
But I think a more useful measure of kwalitee would be a 20%-30%
coverage test.
Something like that sounds much more reasonable than a high number.
Of course, if you've seen the first third of the PPI talk you realise we
still have all the problems of having to use perl itself...
#!/usr/bin/perl
use Test::More 'no_plan';
use Suitcase::Nuke trigger_in_seconds => 1;
pass("Looks good");
oops, there goes the neighbourhood.
Collecting any sort of coverage data is a complete bitch. Let me just
say right now that doing it across _all_ of CPAN is flat out impossible.
It's impossible.
Quite. I believe the only way is for the author to do the Devel::Cover
dance and forward the results. It also distributes the workload out to
where it should be done.
Since it's an optional step that has no direct bearing on the
functionality of the module, it's a sign that the author takes care. In
fact, uploading any coverage statistics would already be a sign of quality.
David
--
"It's overkill of course, but you can never have too much overkill."
Re: New kwalitee test, has_changes
demerphq wrote: On 9/21/05, David Landgren <[EMAIL PROTECTED]> wrote: I know I had my eyes opened by Devel::Cover. I thought I had pretty good coverage in Regexp::Assemble. In fact I had about 60%. I lifted it up to 100% statement coverage (some branching and conditional paths are never taken, but they are "normal", for example C<$foo or return 0>). This toook about 15 hours of work over a week or so. I caught a couple of minor bugs and one rather big one in the process. Well, I dont think it would be possible for me to get 100% coverage in a module like Data::Dump::Streamer. Im pretty happy that I managed to get about 80% actually. The problem for me is that i have a fair amount of code that is specifically for one version of perl, or another, or to handle "never happen" cases (like Scalar::Util::reftype() returning a unknown type). Likewise all kinds of things that are supported in 5.8 are totally meaningless in 5.6.x (locked hashes anyone?). You miss my point. Whether the code be cross-platform or cross-version, you need to aggregate the coverage results from all the environments your code is designed to run on. "can't happen" is another kettle of fish, of course. I wouldn't advocate stripping out defensive coding in order to improve coverage. But then again, in large system failures it's the never-visted code, executed in failure modes, that are regularly singled out as a source of failure amplification. Just read computer.risks for a while. David OTOH, i was happy that DC illustrated some "dead" codepaths that probably could be removed. But im resigned to never getting 100%. And, it doesnt help that something about DC breaks the defined operator when dealing with overloaded objects. (yeah, he did say the code was alpha quality :-) cheers, yves -- "It's overkill of course, but you can never have too much overkill."
Re: New kwalitee test, has_changes
David Cantrell wrote:
demerphq wrote:
On 9/15/05, David Landgren <[EMAIL PROTECTED]> wrote:
As I was downloading the newest version of Devel::Cover this morning, I
pondered on the concept of 1 Kwalitee point for coverage >= 80% ...
I have to wonder about how you handle modules that have code that is
Perl version dependent or OS dependent. Many non-trivial modules end
up having to work around one such incompatibility or another, and
therefore can't get full coverage on a single perl/OS combination.
You could argue that such modules should have their platform/version
specific bits in seperate modules, like what File::Spec does. I'd not
support that argument though - it would make stuff like ...
warn("Windows isn't supported\n") if($^O =~ /win32/i);
impractical.
If a module has extensive platform-dependent codepaths, it is impossible
to achieve full coverage in a single run. One would have to aggregate
the coverage databases from separate D::C runs from, for example, Unix,
VMS and Win32.
This is probably something only the author can do, with perhaps a
willing person who can forward the results from platforms the author
does not have access to. If an author went to such troubles, she would
be deserving of a 48pt bold, orange Kwalitee point.
I know I had my eyes opened by Devel::Cover. I thought I had pretty good
coverage in Regexp::Assemble. In fact I had about 60%. I lifted it up to
100% statement coverage (some branching and conditional paths are never
taken, but they are "normal", for example C<$foo or return 0>). This
toook about 15 hours of work over a week or so. I caught a couple of
minor bugs and one rather big one in the process.
To me, this is a mark of Quality. It would be good to have it as a
Kwalitee metric, but I see no easy way. The simplest way I can see would
be to have a META.yml key that contains a URI to the HTML D::C report. I
would rule out adding a cover/ subdirectory to the distribution due to
the impact it would have on CPAN repositories.
David
--
"It's overkill of course, but you can never have too much overkill."
Re: CPANTS: has_license ?
Gábor Szabó wrote: What do you think about adding a has_license kwalitee to CPANTS ? Checking if the META.yml has that entry ? This will penalise all the modules that use ExtUtils::MakeMaker, which, last time I looked, does not generate the license metadata, even though the module may clearly state the license used in the documentation. I made a half-hearted attempt at patching EU::MM to provide a LICENSE key to WriteMakefile but then Real Life intervened. It did help me get an appreciation of what a thankless job the maintenance of EU::MM is, though. DAvid
Re: CPANTS new
Thomas Klausner wrote:
[...]
The cpants analysis fails to recognise this as valid. What is it looking
for and/or could it be taught to look for this? I thought that it was
only looking for a string eval of "use Test::Pod".
It does, but the qq{} you're using isn't recognised by the regex. I'll try
to improve it a bit. In the long run I'd like to use PPI to parse the code
properly (or at least some magnitudes more proper than I do).
Oh, well don't fret about trying to improve it, PPI is the way to go.
Something the scope of CPANTS is bound to shake out bugs in PPI, which
will make Adam Kennedy happy. (FSDO happy).
David
Re: CPANTS new
Thomas Klausner wrote:
Hi!
On Sun, Sep 18, 2005 at 09:30:03PM +0200, David Landgren wrote:
Yeah, but I'm loathe to dedicate two separate test files merely to score
two points of Kwalitee. As it is, I'd just much rather bundle both tests
in a 00_basic.t file along with all the other standard no-brainer tests.
I'm not sure if Test::Pod and Test::Pod::Coverage can be run from the same
test script. AFAIK all_pod_files_ok sets the plan, and all_pod_coverage_ok
does so too.
use Test::More tests => 3;
SKIP: {
skip( 'Test::Pod not installed on this system', 2 )
unless do {
eval qq{ use Test::Pod };
$@ ? 0 : 1;
};
pod_file_ok( 'foobar.pm' );
pod_file_ok( 'quux.pm' );
}
SKIP: {
skip( 'Test::Pod::Coverage not installed on this system', 1 )
unless do {
eval qq{ use Test::Pod::Coverage };
$@ ? 0 : 1;
};
pod_coverage_ok( "FOO::BAR", "POD coverage is go!" );
}
__END__
TMTOWTDIlly yours,
David
Re: CPANTS new
Andrew Savige wrote: I based mine on the Test::Pod::Coverage docs: use Test::More; eval "use Test::Pod::Coverage 1.00"; plan skip_all => "Test::Pod::Coverage 1.00 required for testing POD coverage" if $@; all_pod_coverage_ok(); and scored the coverage kwalitee point... Yeah, but I'm loathe to dedicate two separate test files merely to score two points of Kwalitee. As it is, I'd just much rather bundle both tests in a 00_basic.t file along with all the other standard no-brainer tests. David
Re: CPANTS new
Thomas Klausner wrote:
Hi!
Data using the new metric 'has_changelog' is now available from
http://cpants.perl.org
Ooh! my kwalitee improved :) except other people's kwalitee improved
more than mine :(
Thanks again to Adam Kennedy, H.Merijn Brand and Smylers for various
suggestions/help with 'has_changelog'.
I've also added suggestions to improve ones kwalitee. For each metric I
wrote up a short 'remedy'. You can view all here:
http://cpants.perl.org/kwalitee.html
Seriously though, I have a module whose test suite includes Test::Pod
and Test::Pod::Coverage, except that I use the following construct:
SKIP: {
skip( 'Test::Pod not installed on this system', 1 )
unless do {
eval qq{ use Test::Pod };
$@ ? 0 : 1;
};
pod_file_ok( 'foobar.pm' );
}
The cpants analysis fails to recognise this as valid. What is it looking
for and/or could it be taught to look for this? I thought that it was
only looking for a string eval of "use Test::Pod".
Congratulations on a job well done!
Later,
David
Re: New kwalitee test, has_changes
Ricardo SIGNES wrote: * "Christopher H. Laco" <[EMAIL PROTECTED]> [2005-09-15T08:23:57] Would this look for Change OR ChangeLog? Both seem to be popular on CPAN. ...and some modules have a HISTORY or CHANGES section of POD, and DBI has DBI::Changes. As long as you use a recent ExtUtils::MakeMaker or Module::Build it's very hard to get *below* about 2 off the maximum. Kwalitee tests for things that are easy to test, rather than testing for things that are worth going after. As I was downloading the newest version of Devel::Cover this morning, I pondered on the concept of 1 Kwalitee point for coverage >= 80%, and another for 100%, and how absolutely impossible it would be to set out to establish these points for all the modules on CPAN. But it would be Good. DAvid
Re: HTTP::Recorder
Michael G Schwern wrote: On Tue, Jul 12, 2005 at 07:35:40PM -0400, Ian Langworth wrote: I'd like to improve HTTP::Recorder. I've contacted Linda Julien (http://search.cpan.org/~leira/) via her CPAN email address, but I've received no response. The module hasn't been touched in over a year and every RT ticket seems to have gone unanswered (http://rt.cpan.org/NoAuth/Bugs.html?Dist=HTTP-Recorder). Suggestions? Roll a new release of the module, upload it to CPAN, announce this on modules@perl.org and module-authors@perl.org and request PAUSE to transfer ownership. There is a 'leira' on perlmonks who hasn't logged in in 20 weeks. One more reason to assume she has fallen off the net. On IRC someone just told me that she's in New Mexico, looking for a job. David
Re: 5.004_xx in the wild?
Michael G Schwern wrote: [...] That said, here's the main differences: * No qr//. Even if you target 5.5.4 qr// still has lots of bugs. [...] Once you go through the initial pain of backporting its not too big a deal to keep things working as long as you're not doing XS. qr// is the only thing I really miss. I like to use constant when I can, but the further you go back in time the more brain-damaged it becomes. I think in 5.005 it only knows about scalars. No hashrefs or arrayrefs allowed. I find this is a bit of a bugger to work around. There are the following documents perl5004delta perl5005delta perl56delta perl561delta etc. that can give clues as to when what language features were added or changed. I thought history.perl.org covered this in more detail but apparently not. David
Re: 5.004_xx in the wild?
Ben Evans wrote: On Mon, Jul 04, 2005 at 02:00:57PM +1000, Adam Kennedy wrote: Michael G Schwern wrote: I'm going through some work to restore Test::More and Test::Harness to work on 5.4.5, minor stuff really, and I'm wondering if its worth the trouble. Has anyone seen 5.004_xx in the wild? And if so, were people actively developing using it or was it just there to run some old code and they were actually developing on a newer perl? I've seen it on occasion, and it's general on large old IRIX servers, and similar aged things. CVS repositories and other boxes that have provided the same services pretty much forever and have never had a compelling reason to upgrade. Some large financial companies are still using this version. At my last place of work, I suspect they're still running 5.002gamma on an aging Vax. They still were in 2002, in any event. That said, from what I can recall, no CPAN modules were hurt in the making of the application. David
Re: what slow could be in Compress::Zlib? (was RE: 5.004_xx in the wi ld?)
Konovalov, Vadim wrote: I've just been through the should-I-shouldn't-I-support-5.4 with my (painfully slow) rewrite of Compress::Zlib. In the end I ... I always thought that Compress::Zlib is just a wrapper around zlib which in turn is C and developed elsewhere (and in stable state for a long time now). What is "(painfully slow) rewrite"? I think Paul means that it is taking him a long time to write the code, not that the code itself is slow. David
Re: [EMAIL PROTECTED]: Re: fixing is_deeply]
demerphq wrote: On 6/30/05, Michael G Schwern <[EMAIL PROTECTED]> wrote: Yves has some controversial ideas about what is and is not data structure equivalence. I'd like comments on it. Well while im disappointed that its considered to be a controversial position (why is accuracy and correctness controversial?) i do beleive Accuracy and correctness are Good. Breaking backwards compatibility is Bad. it is important that this is debated outside of just the perl-qa list (its not that high traffic or visibility IMO) so I have taken the liberty of starting a thread on Perlmonks about this. It is at http://perlmonks.org/index.pl?node_id=471639. Ohh, that'll make schwern happy :) I also beleive that as Test::More is core it has certain obligations that mean that this issue should probably also be discussed on p5p. But for now lets see what happens. The motivation of all of us Im sure is the best interests fo the Perl community who consider Test::More to be a critical module whose quality and standards are vital to the ongoing success of the Perl world. After all this is the perl quality assuarace list right? Of course it should be possible to test for referential equality, if you need it, you need it bad, and nothing else will do. I don't think anyone questions you on this. I don't, however, think it is feasible to make is_deeply() do this, for historical reasons. I would add this new functionality via a new looks_like() or is_deeply_ref() routine. No debate there: if people don't need it they won't (have to) use it. David
Re: Test::More diagnostic change... again
Michael G Schwern wrote: I just went to go patch in the code ref stuff to is_deeply() and found that I had unfinished changes to the diagnostic output. Remember, it was about including the description in the failure diagnostics. So instead of this: /Users/schwern/tmp/test...NOK 1 # Failed test (/Users/schwern/tmp/test at line 5) # got: '42' # expected: '23' You get this: /Users/schwern/tmp/test...NOK 1 # Failed test "this is the test description" # in /Users/schwern/tmp/test at line 5 # got: '42' # expected: '23' There was some debate about the details, I don't remember how it all turned out but I like this new format. Any objections before I chuck it in? I ranted a while back about s/got/received/ David
Re: is_deeply() and code refs
Tels wrote :
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Sunday 26 June 2005 07:18, Collin Winter wrote:
[...]
After tinkering with B::Deparse for a bit, I think this particular
"oddity" may just be a result of poorly-written docs (or, more
probably, poorly-read on my part). The module seems to do the right
thing in all cases I could come up with (i.e., it only optimises out
truly-useless constants), so it should be safe to use for this
particular purpose. With this matter sorted, I've started on the code
and requisite tests to make the new stuff work.
Just for clarification: this means that:
is_deeply( sub { 1 + 2; }, sub { 3; } );
should/will pass because the subs compile to the same code?
is_deeply( sub {cos(0) + sqrt(4)}, sub {3} );
does as well, fwiw. So do looping constructs that map to the same thing:
is_deeply(
sub { my $x=0; $x += $_ for 1..10;$x },
sub { my $x=0; for( 1..10 ) { $x += $_ }; $x },
);
Michael Schwern wrote at the beginning of this thread:
> What it *shouldn't* do is what Test.pm does, namely execute the
> code ref and compare the values returned. It would just compare
> the refernces.
Why should it not do that? Is this because of subs with side effects?
Isn't that more an issue of "Doctor, it hurts when I hit my knee with a
hammer"?
David
Re: Phalanx 100 list
Kevin Scaldeferri wrote: My understanding is that inclusion on the Phalanx 100 doesn't constitute any sort of endorsement of the modules. It's hopefully a statement that the module is widely used, but not a judgment on whether it ought to be. They are not endorsed, but they are considered "important". And it's human nature to pay attention to top ten (or top 100) lists. Some people will take it as an endorsement, no matter how much you tell them not to. People drowning in seas of modules will clutch at anything if it looks like it floats. I would suggest that you make these reservations you expressed above clear in the perldoc of the module. (Maybe it already it; I didn't check.) Beyond that, though, the Phalanx project has always stated that they want to work with authors, not against them, so if you want to remove your module from the project it's absolutely your prerogative. However, perhaps I and others can convince you that there is value in participating. (I.e., even if the module is slow and cryptographically weak, it seems to be widely used so there is an argument for ensuring it works as well as it can within the bounds of what it tries to do.) Yes, but which is the cause, and which is the effect? I can't think of any reason for using a slow and cryptographically weak cypher. Unless I had to write some interopable glue to legacy software that used DES -- but by then I would know what to start searching for. But what if I wanted to create a system from scratch? Reducing the visibility of Crypto::DES will give the other symmetric cyphers a better chance gaining mindshare. David
Re: Displaying the description in diagnostic output
Ian Langworth wrote: On 5/13/05, David Landgren <[EMAIL PROTECTED]> wrote: So what I *really* think about Perl's test reporting is that the results are shown in the wrong order, and that it would also be better to use a less ambiguous word than 'got'. 'actual' would be nice. I like the word "actual" much better than "got," but I agree that swapping the order would create inconsistency. Indeed, it's a human interface issue. Like I said, I don't think that the order can be changed now at this point in time. Nor do I make the mistake all that often, perhaps 0.05% of the time, but the potential is there. It has happened, I've been tired, and at those times I wasted more effort than I care to admit simply because I misinterpreted what the results were telling me. Which lead me to conclude that there is an Edward Tufte-type problem in the way the information is presented. Anything other than 'got' would go some of the way in disambiguating things. I'd write a patch if I thought it had a chance of being applied, that would let the developer choose what was desired. Something like use Test::Simple display => traditional # implicit, by default or use Test::Simple display => modern David
Re: Displaying the description in diagnostic output
Michael G Schwern wrote: [...] This is what I morphed it into. /Users/schwern/tmp/duringNOK 1 # Failed test (/Users/schwern/tmp/during.t at line 5) # got: '23' # expected: '42' /Users/schwern/tmp/duringNOK 2 # Failed test "this is a really long name and its pretty long you see" # (/Users/schwern/tmp/during.t at line 6) # got: '42' # expected: '23' I'm pretty happy with that but I'd like feedback. I've attached the patch so folks can play around with it. Let me know what you think. This is just a general comment on visual design that's been on my mind a long time, so make of it what you will. More than once I have been tripped up by the testinterface. I interpret the output the first line being what I've _got_ to test, and the second line being the result. After all, the test was written first, and the code was run afterwards. So I parse the first line' as 'what I've _got_ in the test', and by then it's game over. The second line my brain skips past the first eight letters and interprets the rest as 'what came back'. Needless to say, the more tired I am, the more likely I am to make this mistake. So what I *really* think about Perl's test reporting is that the results are shown in the wrong order, and that it would also be better to use a less ambiguous word than 'got'. 'actual' would be nice. # Failed test "this is a really long name and its pretty long you see" # (/Users/schwern/tmp/during.t at line 6) # expected: '23' # actual: '42' Or received. Or anything. My grade three teacher drummed into my head that there is always an alternative to 'got'. I also understand that I'm no doubt in a minority of one on this issue, and that everyone else's brain is wired the other way, and that in any event, even if my argument has some merit, it is far too late in the game to do anything about it. Maybe in Perl 6, I dunno. Thank-you for listening to my rant, David
