Re: Something wrong with str.reverse
On 22/06/2010 09:07, Richard Hainsworth wrote: I was going to suggest this too after reading PM's post. I would suggest that for whatever reason a list operator was used on a scalar, including a hold over form another language (Ruby and perl5), a warning should be issued. Most likely to be an error. For a nop? Ouch. Could this not be pushed off onto a lint-like/PBP analysis? If you want the compiler to moan about every construct that may not be doing what you think it's doing... you don't want to do that every time the program is run. David On 06/21/2010 11:05 PM, yary wrote: Warning on using any list-y op on a scalar seems like a good idea, and the fact that the idea arose after a perl5 misunderstanding now looks like a "red herring". That is, while warning on "only" reverse-on-a-scalar may be a bad idea and perl5 specific, I'd vote for warning on all apparent mis-uses of list ops on scalars as a generally helpful. -- There's bum trash in my hall and my place is ripped I've totaled another amp, I'm calling in sick
Re: [perl #39742] [BUG] installed parrot conflicts with dev parrot.
chromatic via RT did write:
garaud and I hope to have fixed this as of r16139, though he still has
some dynext and dynpmc failures on his FreeBSD 6.2-tobe box.
Can anyone still confirm?
I just synched to 16207, but the test suite produces the following:
Failed Test Stat Wstat Total Fail List of Failed
---
t/codingstd/c_code_coda.t 1 256 21 1
t/codingstd/tabs.t 1 256 11 1
t/codingstd/trailing_space.t1 256 11 1
t/src/basic.t 1 256 31 3
t/src/compiler.t6 1536 66 1-6
t/src/exit.t1 256 11 1
t/src/extend.t 15 384015 15 1-15
t/src/hash.t 11 281611 11 1-11
t/src/intlist.t 1 256 41 1
t/src/io.t 20 512020 20 1-20
t/src/list.t2 512 22 1-2
t/src/sprintf.t 2 512 32 1-2
t/src/string.t 2 512 32 2-3
(1 subtest UNEXPECTEDLY SUCCEEDED), 8 tests and 591 subtests skipped.
Failed 13/266 test scripts. 64/6808 subtests failed.
Files=266, Tests=6808, 2280 wallclock secs (867.71 cusr + 264.75 csys =
1132.46 CPU)
Failed 13/266 test programs. 64/6808 subtests failed.
Can't install it, either.
[EMAIL PROTECTED]:/home/perl/src/parrot% sudo make reallyinstall
Password:
make installable
Compiling with:
xx.c
cc -I./include -DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.8/BSDPAN
-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -pipe
-Wdeclaration-after-statement -I/usr/local/include -g -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow
-Wpointer-arith -Wcast-qual -Wwrite-strings -Waggregate-return -Winline
-Wno-unused -Wsign-compare -falign-functions=16 -Wformat-nonliteral
-Wformat-security -Wpacked -Wdisabled-optimization
-mno-accumulate-outgoing-args -Wno-shadow -DHAS_JIT -DI386
-DHAVE_COMPUTED_GOTO -DPIC -fPIC -I. -o xx.o -c xx.c
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;' docs
perl -MExtUtils::Command -e mkpath ops
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;' src/dynpmc
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;'
src/dynoplibs
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;'
compilers/past
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;'
compilers/pge
cd PGE/pmc && perl /home/perl/src/parrot/tools/build/dynpmc.pl generate
codestring
cd PGE/pmc && perl /home/perl/src/parrot/tools/build/dynpmc.pl compile
codestring
cd PGE/pmc && perl /home/perl/src/parrot/tools/build/dynpmc.pl linklibs
codestring
cd PGE/pmc && perl /home/perl/src/parrot/tools/build/dynpmc.pl copy
--destination=/home/perl/src/parrot/runtime/parrot/dynext codestring
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;'
compilers/tge
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;'
compilers/past-pm
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;'
compilers/json
Invoking Parrot to generate install_config.fpmc
./parrot config_lib.pasm --install > install_config.fpmc
perl tools/build/parrot_config_c.pl --install > src/install_config.c
src/install_config.c
g++ -o ./installable_parrot compilers/imcc/main.o
-L/home/perl/src/parrot/blib/lib -lparrot -lm -lcrypt -lutil -pthread
-lgmp -lreadline -Wl,-E -L/usr/local/lib src/install_config.o
src/pdump.c
src/packdump.c
g++ -o ./installable_pdump src/pdump.o src/packdump.o
-L/home/perl/src/parrot/blib/lib -lparrot -lm -lcrypt -lutil -pthread
-lgmp -lreadline -Wl,-E -L/usr/local/lib
src/disassemble.c
g++ -o ./installable_disassemble src/disassemble.o
-L/home/perl/src/parrot/blib/lib -lparrot -lm -lcrypt -lutil -pthread
-lgmp -lreadline -Wl,-E -L/usr/local/lib
src/pbc_info.c
g++ -o ./installable_pbc_info src/pbc_info.o
-L/home/perl/src/parrot/blib/lib -lparrot -lm -lcrypt -lutil -pthread
-lgmp -lreadline -Wl,-E -L/usr/local/lib
src/pdb.c
src/pdb.c: In function `main':
src/pdb.c:153: warning: implicit declaration of function `IMCC_ast_init'
g++ -o ./installable_pdb src/pdb.o -L/home/perl/src/parrot/blib/lib
-lparrot -lm -lcrypt -lutil -pthread -lgmp -lreadline -Wl,-E
-L/usr/local/lib
src/pdb.o(.text+0xaa): In function `main':
src/pdb.c:153: undefined reference to `IMCC_ast_init'
*** Error code 1
Stop in /home/perl/src/parrot.
*** Error code 1
Stop in /home/perl/src/parrot.
All of the above was preceded by a 'make distclean' followed by a 'perl
Configure.pl'.
Feel free to holler if you want some more info.
Thanks,
David
--
"It's overkill of course, but you can never have too much overkill."
Re: [perl #39742] [BUG] installed parrot conflicts with dev parrot.
chromatic via RT did write: garaud and I hope to have fixed this as of r16139, though he still has some dynext and dynpmc failures on his FreeBSD 6.2-tobe box. Can anyone still confirm? Let me have a look and I'll get back to you. David -- "It's overkill of course, but you can never have too much overkill."
Re: 6-on-5 and read only aliasing
Nicholas Clark wrote: [...] Suggestions for a better name for BIND welcome. 4 letters or fewer. An alias, eh? That's like a nickname, isn't it? Well, since you're asking, I propose NICK Nicholas Clark PS blead source is at rsync://public.activestate.com/perl-current/ -- 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: [perl #39552] Segfault on FreeBSD during make
Chip Salzenberg via RT wrote:
Is this bug still reproducible this even after removing everything
Parrot-related from /usr/local? (Also /usr/bin and /usr/lib if you
happen to have installed e.g. Debian's parrot packages.)
I deleted /usr/local/{bin,doc,include,lib}/parrot (or something very
close to that), rsynced from the repo and rebuilt. This time the install
went perfectly, although the test suite issued a certain amount of smoke.
Failed Test Stat Wstat Total Fail List of Failed
---
t/dynoplibs/dan.t 6 1536 66 1-6
t/dynoplibs/myops.t7 1792 77 1-7
t/dynpmc/dynlexpad.t 6 1536 66 1-6
t/dynpmc/foo.t 9 2304 99 1-9
t/dynpmc/gdbmhash.t 13 332813 13 1-13
t/dynpmc/perlarray.t 32 819232 32 1-32
t/dynpmc/perlenv.t 1 256 11 1
t/dynpmc/perlhash.t 37 947238 37 1-31 33-38
t/dynpmc/perlint.t75 1920076 75 1-60 62-76
t/dynpmc/perlnum.t53 1356860 53 1-47 54 56-60
t/dynpmc/perlscalar.t 2 512 32 2-3
t/dynpmc/perlstring.t 69 1766469 69 1-69
t/dynpmc/perlundef.t 13 332813 13 1-13
t/dynpmc/sparse_perlarray.t4 1024 44 1-4
t/dynpmc/sub.t 2 512 22 1-2
t/examples/past.t 1 256 11 1
t/pmc/eval.t 1 256191 19
t/pmc/mmd.t9 2304399 1 14-20 23
t/pmc/sub.t3 768553 44-46
8 tests and 387 subtests skipped.
Failed 19/242 test scripts. 343/6028 subtests failed.
Files=242, Tests=6028, 2249 wallclock secs (521.95 cusr + 201.22 csys =
723.16 CPU)
Failed 19/242 test programs. 343/6028 subtests failed.
Thus the bug may be closed. I see that the install process now says
WARNING:
Installing Parrot may interfere with developing Parrot
on the same machine. This is a temporary flaw in the
Parrot build system. If you are not sure this is OK,
press ^C (or your interrupt key) in the next ten seconds.
It might be worth pointing out here what the work-around is:
if the install dumps core, remove the installed version (and what files
in question are).
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: [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:
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
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
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
Re: Fwd: Re: Pugs 6.2.0 released.
Jonathan Worthington wrote: "Juerd" <[EMAIL PROTECTED]> wrote: You both use "iff". What does that mean? I believe it's to be read "if and only if". Yes, but that doesn't explain what it means. Rather than me try to explain it (poorly)... http://en.wikipedia.org/wiki/If_and_only_if David
Re: = vs <== [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
Aaron Sherman wrote: So hold on to your socks... what about: @x @y; This reminds me of AWK's string concatenation behaviour: print "this " $1 " that " $2 This was nice feature at the time, but caused problems down the track when they wanted to add functions to the language in a subsequent revision. See section 8.1 of The AWK Programming Language for more details. For that reason alone (future-proofing the grammar), I would be leery of going down this route. David
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
Uri Guttman wrote: [...] i think so but i can't read larry's mind (nor would i want to! :) XP = extreme programming DBC = design by contract (or even designed by conway :) MP = ?? Modular Programming David
Re: Periodic Table of the Operators
Mark Lentczner wrote: All - Awhile back, I saw Larry Wall give a short talk about the current design of Perl 6. At some point he put up a list of all the operators - well over a hundred of them! I had a sudden inspiration, but it took a few months to get around to drawing it... http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html Nice. Now to find a large enough printer to be able to pin it up on the wall. One minor quibble, in the "Quasi Operators" section there's a typo: s/Anonamizer/Anonymizer/ David - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl (at) glyphic (dot) com -- Commercial OS breeds commerce, whereas free OS breeds freedom, the only thing more dangerous and confusing than commerce. -- Michael R. Jinks, redhat-list, circa 1997
Re: is static?
Damian Conway wrote:
[...]
Hence, I would argue, one ought to simply mark it with a trait:
sub foo() {
my $s is retained = 0;
$s++;
}
Other possible trait names:
is kept
is preserved
is permanent
is reused
is saved
is stored
is restored
is irrepressible
I expected to see 'is persistent' as a possible name. Or does that
denote serialisation too much? Would people read
sub foo() {
my $s is persistent = 0;
$s++;
}
as meaning that the value of $s is saved across program invocations?
David
