Re: Perl 6 and Parrot VM presentation slides
I have power point slides I did use for a course on parrot machine and
assembly language for my students. With many examples.
They are in french. I can send you the file if you want.
--
__
\|||/
(o o)
+--ooO-( )-Ooo--+
| Christian Aperghis-Tramoni |
| |
| Case Postale 901 Tel : (33) 04 91 82 92 49 |
| 163 Avenue de Luminy SFR : (33) 06 18 93 10 70 |
| 13288 Marseille Cedex 09 Fax : (33) 04 91 82 92 75 |
| FranceMel : [EMAIL PROTECTED] |
/) [EMAIL PROTECTED](Ä
/ ) WEB : http://www.dil.univ-mrs.fr/~chris ( Ä
( (+---+) )
((\ \) / ) / ) (/ //)
(\\\ \_/ /\ \_/ ///)
\ /\ /
___\___/__\___/
print join('',map({$i=1-$i;$a=$i?10*$_."\b\b":pack"c",$a+$_+0x16}split
(//,"5110789279758710838810587992861093898779948387799310")),"...\n");
___
Re: How to get started with Test::TAP::HTMLMatrix
On 7/7/05, Yuval Kogman <[EMAIL PROTECTED]> wrote: > On Tue, Jul 05, 2005 at 23:57:10 +0000, Chris Hutchinson wrote: > > > For what it's worth, I wrote a trivial wrapper for TAP::HTMLMatrix to run > > tests > > in a chosen directory and write the html. It requires File::Find::Rule as > > well > > as the Test::TAP modules. You can grab it from > > http://www.hutchinsonsoftware.com/misc/run_tap > > In this script you probably want to set $v->has_inline_css(1), so > that you can have the proper CSS stuff without mucking with another > file. > Updated, with some POD usage docs as well. - Chris
Just an anouncement
In our university, teaching parrot assembly is effective.
For 3 weeks now, our students (2nd year) are trying to realize programs
in parrot assembly and, for most of them, they really apreciate it.
The general opinion is that it is very powerfull and easy to learn.
In the nest french perl workshop, I will explain why such a language is
able to help us in our pedagogy.
Regards.
--
__
\|||/
(o o)
+--ooO-( )-Ooo--+
| Christian Aperghis-Tramoni |
| |
| Case Postale 901 Tel : (33) 04 91 82 92 49 |
| 163 Avenue de Luminy SFR : (33) 06 18 93 10 70 |
| 13288 Marseille Cedex 09 Fax : (33) 04 91 82 92 75 |
| FranceMel : [EMAIL PROTECTED] |
/) [EMAIL PROTECTED](Ä
/ ) WEB : http://www.dil.univ-mrs.fr/~chris ( Ä
( (+---+) )
((\ \) / ) / ) (/ //)
(\\\ \_/ /\ \_/ ///)
\ /\ /
___\___/__\___/
print join('',map({$i=1-$i;$a=$i?10*$_."\b\b":pack"c",$a+$_+0x16}split
(//,"5110789279758710838810587992861093898779948387799310")),"...\n");
___
RE: "new" method
How about some variation on "create"? --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/2004
RE: backticks
Perhaps this is naive, but couldn't something like this be achieved in a
manner similar to how I just implemented it in Ruby? Surely Perl will have
similar capabilities to handle unknown methods.
class Hash
def method_missing(method_name)
str = method.id2name
if str =~ /^\w+$/ then self[str] else super(method_name) end
end
end
h = {"foo" => "bar"}
h.foo# "bar"
h.baz# nil
h.length # 1
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/2004
RE: hyper op - proof of concept
On Tue, 2004-04-20 at 1:26PM, Aaron Sherman wrote: > > Another of those darned "I don't get it" posts, but I'll keep > this one short. > > Why does Parrot need this? What's so special about hyper > operations that makes Parrot want to take them on? I'm not sure I entirely get it myself, but perhaps it's a good thing if it can take some work off the shoulders of the Perl6 compiler writers. After all, if a lot of Perl6 can be mapped fairly directly to Parrot, without hurting the efforts of other compiler writers, it'll mean an even quicker working Perl6 once the language design is (more or less) finished. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 15/04/2004
"hyper variables/references?
I may have missed an obvious answer to this question, but has any thought been given to allowing for variables which behave as though ever operation on them is the hyper version of that operation? Sort of an automagical way of redefining a LOT of operators. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.686 / Virus Database: 447 - Release Date: 14/05/2004
Severe error
This is the message I get while compiling parrot on linux :
./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
real_exception (severity:2 error:30): Complex: malformed string
likely reason: argument count mismatch in main (more than 1 param)
make: *** [runtime/parrot/include/config.fpmc] Erreur 30
--
__
\|||/
(o o)
+--ooO-( )-Ooo--+
| Christian Aperghis-Tramoni |
| |
| Case Postale 901 Tel : (33) 04 91 82 92 49 |
| 163 Avenue de Luminy SFR : (33) 06 18 93 10 70 |
| 13288 Marseille Cedex 09 Fax : (33) 04 91 82 92 75 |
| FranceMel : [EMAIL PROTECTED] |
/) [EMAIL PROTECTED](Ä
/ ) WEB : http://www.dil.univ-mrs.fr/~chris ( Ä
( (+---+) )
((\ \) / ) / ) (/ //)
(\\\ \_/ /\ \_/ ///)
\ /\ /
___\___/__\___/
print join('',map({$i=1-$i;$a=$i?10*$_."\b\b":pack"c",$a+$_+0x16}split
(//,"5110789279758710838810587992861093898779948387799310")),"...\n");
___
Error on Debian distrib
I am installing Parrot both on Mandriva ans Debian.
This error only occurs on Debian distrib.
./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
real_exception (severity:2 error:30): Complex: malformed string
likely reason: argument count mismatch in main (more than 1 param)
make: *** [runtime/parrot/include/config.fpmc] Erreur 30
--
__
\|||/
(o o)
+--ooO-( )-Ooo--+
| Christian Aperghis-Tramoni |
| |
| Case Postale 901 Tel : (33) 04 91 82 92 49 |
| 163 Avenue de Luminy SFR : (33) 06 18 93 10 70 |
| 13288 Marseille Cedex 09 Fax : (33) 04 91 82 92 75 |
| FranceMel : [EMAIL PROTECTED] |
/) [EMAIL PROTECTED](Ä
/ ) WEB : http://www.dil.univ-mrs.fr/~chris ( Ä
( (+---+) )
((\ \) / ) / ) (/ //)
(\\\ \_/ /\ \_/ ///)
\ /\ /
___\___/__\___/
print join('',map({$i=1-$i;$a=$i?10*$_."\b\b":pack"c",$a+$_+0x16}split
(//,"5110789279758710838810587992861093898779948387799310")),"...\n");
___
Re: Why {{}} for regexp closures instead of just {}?
> On Sun, Oct 26, 2008 at 10:45 PM, Chris Dolan <[EMAIL PROTECTED]> wrote:
>> S05 always uses single curlies for closures, but throughout Parrot, code
>> seems to use double curlies in PGE regexps. Why is that?
>>
>> That is, why this:
>> m/ foo {{ say "found foo" }} /
>> and not this:
>> m/ foo { say "found foo" } /
>>
>> The latter complains about "Statement not terminated properly".
>>
> this is old PGE syntax that hasn't yet been updated to match S05. it's a
> bug.
>
> or maybe, you can say that closures inside regexes aren't supported
> yet, but rakudo has a feature that allows {{PIR}}} to work.
> ~jerry
Thanks for the info. I'll try to learn enough to write a PGE patch to
support {PIR} notation. Given the ubiquity of the {{PIR}} notation I will
probably try to see if I can make it backward compatible, with an eye
toward deprecating it.
Chris
Error on Leopard
Compiling the last version 0.6.1 on Mac OsX leopard, I get the folowing
error message :
{standard input}:111888:no such instruction: `trap'
lipo: can't open input file:
/var/folders/QC/QCZT0Y5F2RWKy++1YvjO0TI/-Tmp-//ccJ5JQmO.out (No such
file or directory)
make: *** [src/ops/core_ops.o] Error 1
Can you tell me what to do ?
--
__
\|||/
(o o)
+--ooO-( )-Ooo--+
| Christian Aperghis-Tramoni |
| |
| Case Postale 901 Tel : (33) 04 91 82 92 49 |
| 163 Avenue de Luminy SFR : (33) 06 18 93 10 70 |
| 13288 Marseille Cedex 09 Fax : (33) 04 91 82 92 75 |
| FranceMel : [EMAIL PROTECTED] |
/) [EMAIL PROTECTED](ƒ
/ ) WEB : http://www.dil.univ-mrs.fr/~chris ( ƒ
( (+---+) )
((\ \) / ) / ) (/ //)
(\\\ \_/ /\ \_/ ///)
\ /\ /
___\___/__\___/
print join('',map({$i=1-$i;$a=$i?10*$_."\b\b":pack"c",$a+$_+0x16}split
(//,"5110789279758710838810587992861093898779948387799310")),"...\n");
___
A problem on regex.
Hello everybody.
Lets explain my problem.
Lets see the folowing perl 5 program :
#!/usr/bin/perl
my $c = "AABBCC";
my $m = "B";
$c =~ s/($m+)/XX/;
print "Chain : $1.\n";
print "Final chain : $c.\n";
Le résultat est bien celui que j'attendais :
Chain : BB.
Final chain : AAXXCC.
Lets see now Perl 6.
with a simple mach.
use v6;
my $c = "AABBCC";
my $m = "B";
$c ~~ m:c/($m+)/;
say "Chain : $0. Place : ", $/.from;
Ici aussi, le résultat est bien celui attendu :
Chain : BB. Place : 2
and the perl 5 program translated in Perl 6.
use v6;
my $c = "AABBCC";
my $m = "B";
$c ~~ s/($m+)/XX/;
say "Chain : $0.";
say "Final chain : $c.";
Oups, result is not really what I was waiting :
Chain : Any().
Final chain : AAXXCC.
The $0 var is set on a mach operation but not in a substitute.
So that its value is "Undef"
The problem can be solved using firts a m then a s
use v6;
my $c = "AABBCC";
my $m = "B";
$c ~~ m:c/($m+)/;
$c ~~ s/($m+)/XX/;
say "Chain : $0.";
say "Final chain : $c.";
The rseult is what I was waiting :
Chain : BB.
Final chain : AAXXCC.
Where is the problem ?
Is there any solution to set the $0 var in a s operation ?
Thanks
--
__
\|||/
(o o)
+--ooO-( )-Ooo--+
| Christian Aperghis-Tramoni |
| |
| Case Postale 901 Tel : (33) 04 91 82 92 49 |
| 163 Avenue de Luminy SFR : (33) 06 18 93 10 70 |
| 13288 Marseille Cedex 09 Fax : (33) 04 91 82 92 75 |
| France Mel : ch...@dil.univ-mrs.fr |
/) ch...@aperghis.net(\
/ ) WEB : http://www.dil.univ-mrs.fr/~chris ( \
( (+---+) )
((\ \) / ) / ) (/ //)
(\\\ \_/ /\ \_/ ///)
\ /\ /
___\___/__\___/
print join('',map({$i=1-$i;$a=$i?10*$_."\b\b":pack"c",$a+$_+0x16}split
(//,"5110789279758710838810587992861093898779948387799310")),"...\n");
___
Re: [perl #63408] [PATCH] use PCT::HLLCompiler.addstage()
Yes, closeable. Thanks. Chris "Tadeusz Sośnierz via RT" wrote: On Sun Feb 22 18:53:32 2009, ch...@chrisdolan.net wrote: > This trivial patch to perl6.pir changes Perl6::Compiler to use its > superclass' addstage() mutator instead of directly editing the > @stages attribute. This should make for better forward > compatibility, as it avoids repeating the list of stages. > https://github.com/rakudo/rakudo/blob/master/src/Perl6/Compiler.pir#L162 The current implementation seems to use addstage, is the ticket closable?
RE: RFC 343 (v1) New Perl Mascot
At 14:01 -0500 2000.09.29, Garrett Goebel wrote: >From: Tim Conrow [mailto:[EMAIL PROTECTED]] >> >> I don't know trademark law, but it seems unlikely that >> O'Reilly can trademark the concept of the camel, or all >> representations of the camel. > >No. They can't trademark the "concept" of the camel. But they _have_ >trademarked their camel logo and its association with Perl. No, they have trademarked the O'REILLY logo, and the association of a camel with Perl. >"The relationship between a (animal image: must be specified) and >(specific technology) is a trademark of O'Reilly & Associates, Inc. Used >with permission." Any camel associated with Perl falls under that trademark (according to O'Reilly). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: licensing issues
At 15:32 -0500 2001.01.05, Dan Sugalski wrote: >Honestly, the license we choose will only restrict those people who will >respect it, either for moral or legal reasons. That's one reason to choose >a license that places the fewest restrictions on those people, and the GPL >is not that license. True, unless we stick to the same licensing scheme we have today for perl, which, like it or not, has served Perl very, very well. But yes, I see no way to put perl solely under the GPL. That's just about the worst thing we could do, aside from making perl non-"free." -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: licensing issues
At 0:59 -0500 2001.01.09, Bradley M. Kuhn wrote: >Chris Nandor <[EMAIL PROTECTED]> wrote: > >> True, unless we stick to the same licensing scheme we have today for perl, >> which, like it or not, has served Perl very, very well. > >As it turns out, this isn't an RFC under consideration by Larry, AFAIK. >The only RFC about licensing that went in was (Artistic-2.0|GPL). Right. Not many RFCs said "don't change anything." That doesn't mean anything, though. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: licensing issues
At 12:05 AM -0800 1/13/01, Russ Allbery wrote: >Perl, by the *explicit* intention of Larry, sits at a very nice crossroads >between three active communities; those who use the GPL and agree with the >general goals of the FSF, those who prefer software to be as free as >possible and usually use the BSD or X license, and those who write >proprietary software. All three of those groups meet and work and help >each other with Perl, which I think is a wonderful and important thing. I >think it should be the first goal of this working group to preserve that >balance regardless of the license chosen, so that all these people who are >currently working together can continue to do so. Absolutely. And this "status quo" argument is why I think that it is reasonable to keep the current licensing scheme; it has served Perl very, very well. If the AL can be changed to satsify some lawyers, while at the same time not becoming less readable (becoming more readable would be better) and certainly not imposing any more of a burden on the people who use it, then I am not opposed to it. While I do not appreciate much of what the GPL has to offer, we are still _essentially_ working toward the same goal -- free software -- and as you said, having the GPL on perl has helped perl and its community tremendously. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: licensing issues
At 09.19 -0500 01.14.2001, Ben Tilly wrote: >That situation definitely had ActiveState violating the >spirit of the Artistic License, whether or not they were >violating the letter. They violated neither the spirit nor the letter. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: licensing issues
At 15.27 + 01.14.2001, Simon Cozens wrote: >On Sun, Jan 14, 2001 at 09:27:28AM -0500, Chris Nandor wrote: >> At 09.19 -0500 01.14.2001, Ben Tilly wrote: >> >That situation definitely had ActiveState violating the >> >spirit of the Artistic License, whether or not they were >> >violating the letter. >> >> They violated neither the spirit nor the letter. > >Incorrect. Indeed, the entire point of the OnePerl thingy was to >resolve the violation! No. It was to have Windows support built-in to the standard distribution. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Why modifing the Artistic license is a good idea (was Re:licensing issues)
At 17.00 -0500 01.14.2001, Bradley M. Kuhn wrote: >I think, in some cases, it has not served Perl as well as it might have. Yes, but it has still served it very well. Perhaps better than any other "free" program out there. I concede it could be better, but simply assert it has been served very, very well. >Namely, because the Artistic license is unclear. The OSI and the Debian >group only reluctantly and with many reservations accepted the Artistic >license as an open source license. The FSF has been unable to accept it >as a free software license, and some of these reasons are brought up in >the various RFCs I wrote. This is all for political reason, and I am not inclined to care about that. >> If the AL can be changed to satsify some lawyers, > >It's not just lawyers. The changes I have proposed can help satisfy >businesses, because it makes it more clear that they can charge money >for redistributing perl. The current Artistic license is somewhat >unclear on this issue. I disagree entirely, as you may already know. It is very clear on this point. The only significant business complaints I have _ever_ heard (from actual businesses) about the AL comes from said businesses' lawyers. >> while at the same time not becoming less readable (becoming more readable >> would be better) and certainly not imposing any more of a burden on the >> people who use it, then I am not opposed to it. > >Why do you feel the AL-2.0 that I proposed is less readable than the >current one? I did not say it was. I was speaking generally, not specifically. I apologize for any confusion on the matter. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: no one is asking for Perl to be GPL-only (was Re: licensingissues)
At 17.19 -0500 01.14.2001, Bradley M. Kuhn wrote: >The FSF surely wants Perl to be under a GPL compatible license (and, >(GPL|SOMETHING) is always GPL-compatible, by default). I don't think >the FSF has ever expressed a desire that Perl be GPL-only. In fact, the >FSF has a policy of encouraging everyone to always dual-licensing >(GPL|Artistic) for Perl modules, to encourage uniformity, and avoid >licensing confusion for those who use lots of Perl modules. I think it is for compatiblity, not uniformity (perhaps you are using them somewhat synonymously). >(Indeed, it is quite unfortunate that there are so many modules on CPAN >that have chosen Artistic-only or GPL-only.) I think it is unfortunate that anyone would think someone else's choice of license is unfortunate. :) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: no one is asking for Perl to be GPL-only (was Re: licensing issues)
At 15.32 -0700 01.14.2001, Nathan Torkington wrote: >Chris Nandor writes: >> >(Indeed, it is quite unfortunate that there are so many modules on CPAN >> >that have chosen Artistic-only or GPL-only.) >> >> I think it is unfortunate that anyone would think someone else's choice of >> license is unfortunate. :) > >I can't even remember the topic we're supposed to be discussing, but >I'm pretty sure that this would begin a tangent :-) > >Brad, are we trying to come to a conclusion or is this just babble? Seeing as how the RFC process is done, I don't think there is a conclusion to be had in this forum, at this point. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: no one is asking for Perl to be GPL-only (was Re: licensingissues)
At 19.55 -0800 01.14.2001, Russ Allbery wrote: >Chris Nandor <[EMAIL PROTECTED]> writes: > >> I think it is unfortunate that anyone would think someone else's choice >> of license is unfortunate. :) > >While I'm with Linus on this (those who write the code get to choose the >license), I think it's incumbent on us, as the licensing working group, to >be aware that choices of licenses have consequences and sometimes those >consequences can be obscure or unintended. I'd like it if everyone >choosing a license did so with full knowledge of the possible consequences >(and then, once they are, they should feel free to chose whatever license >they want). Agreed. >For some purposes, it would be >nice to be able to distribute CPAN or a subset of it under a single clear >license (although there's enough diversity now that this would require a >lot of work to do). I don't know what has come of it, but there was a big discussion about changes to CPAN, including metadata about the modules, and if that ever happens/catches on, you just have a place in the metadata for what license(s) are used. >Sure, if people are aware of all of those issues and have decided that >their goals are more important to them than those drawbacks, more power to >them and they should be able to use whatever license they want. Yes; it is this situation with every licensing scheme that we've ever seen. There are goals, there are drawbacks, and there are decisions. Informed decisions are always best. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: licensing issues
At 22.39 -0500 01.14.2001, David Grove wrote: >I think that "charter" would be more palatable than "manifesto", although >I won't lose the sentiment in semantics. I've been thinking the same >thing, and agree entirely. Whereas the license could use some tightening >up to allow legal enforcement of rights and restrictions, such a charter >could allow for public censure to serve the same purpose as seeking legal >remedy when Larry's hands are otherwise tied. I think the purpose of such a "charter" should be to inform rather than punish supposed offenders. To have suchg a wrong-headed motivation seems to me to be asking for failure. >However, there's a fly in the ointment. In current circumstances, Larry's >hands may well be tied to so much as consider an "official" charter of >this nature, much less bless it. If this turns out to be so, what do we >do? Not have one. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: no one is asking for Perl to be GPL-only (was Re: licensingissues)
At 16:42 -0500 01.15.2001, Bradley M. Kuhn wrote: >For example, I'd like to see CPAN.pm warn you if you are about to >install a module which will, licensing-wise, force you down a GPL-only >or AL-only fork when you use it in your programs. As long as it is an option, sure, some people would probably dig it. But it would annoy me greatly if it were that way on my system and I couldn't turn it off with a flag in CPAN::Config. It would probably annoy me if it was on by default, too. Remember, most of the problems with these licenses have to do not with use, but distribution, and the vast majority of users of modules just use them, they don't distribute them. Most people don't care what the license is unless that are going to distribute. >Also, someone might have to use a completely different license for other >reasons. For example, some modules are MPL-only because they are XS >interfaces to MPL-only systems. We should flag people about that. > >(In fact, I don't even know that the MPL is compatible with the AL, so it >may not be feasible to install such a module at all...we'll need to >find that out.) I don't think we should flag that. I think we should stay away from any specific recommendations as far as the software is concerned. Just inform people what the licenses are, perhaps with links to the licenses. I dunno, it strikes me as overly "interested" to actually make recommendations to users about what is compatible with what at this level. Does that make sense? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: feedback and the license of Perl (was Re: licensing issues)
At 20:04 -0500 01.16.2001, Bradley M. Kuhn wrote: >Related to this, though, I have a procedural question: > > Does anyone know if Larry is considering "leave it as it is" for all > options on RFCs? Chris noted that there wasn't a point in writing an RFC > that said: "perl's license stays the same", because it was implicit. I > wasn't clear that it was implicit. Have I misunderstood? Larry can do anything at all, regardless of the RFCs. He can choose to leave something as it is, accept an RFC, modify an RFC, or come up with something new on his own. I think this is the case with _everything_ related to this phase of things. Rule #1 still applies. At least, this is my understanding. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: no one is asking for Perl to be GPL-only (was Re: licensingissues)
At 18:38 + 01.24.2001, John van V wrote: >> >For example, I'd like to see CPAN.pm warn you if you are about to >> >install a module which will, licensing-wise, force you down a GPL-only >> >or AL-only fork when you use it in your programs. > >Personally I'd be thrilled to know that the module works at all, and returns >useful data sometime this year... It does, and has for some time, so feel free to be thrilled. HTH. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: ANNOUNCE: smokers@perl.org Discussion of perl's daily buildand smoke test
At 15:45 + 2001.02.19, Tim Bunce wrote: >On Mon, Feb 19, 2001 at 09:03:00AM -0600, Jarkko Hietaniemi wrote: >> On Mon, Feb 19, 2001 at 04:01:25PM +0100, H.Merijn Brand wrote: >> > On Mon, 19 Feb 2001 08:49:04 -0600, Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote: >> > > On Mon, Feb 19, 2001 at 03:47:12PM +0100, Johan Vromans wrote: >> > > > As an active non-smoker, I'd appreciate a different name. >> > > >> > > Likewise. What's wrong with builders? >> > >> > Same here. Testers? >> >> perl-builders? > >Or to be more whimsical: > > perl-night-shift > perl-night-build > >It probably needs a name that'll both indicate its role and avoid confusion >with 'porters' (who do most of the 'building' to the untrained eye). I dunno; I dislike smoking, but I like the idea of "smoking-camels" or something. :) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: licensing issues
At 10:10 -0500 01.15.2001, David Grove wrote: >> I think the purpose of such a "charter" should be to inform rather than >> punish supposed offenders. To have suchg a wrong-headed motivation seems >> to me to be asking for failure. > >Then there is no point in working with licenses at all. If licenses will >not be enforced through litigation and our desires for the Perl language >cannot be enforced through public censure, we might as well have a license >that simply says, "Do whatever you want with this, we don't care >(especially if you're in bed with ORA)." All discussion is moot, working >with the wordings of the licenses is in vain unless it is sufficient to do >so only to please a small group of fanatics (lawyers don't count, because >we won't use them), and we simply have to tolerate the abuses currently in >place and likely those to come in the future. I can't imagine that you'd >find that situation acceptable, Chris, unless you have better ideas about >how to remedy them. (Continuing to sweep them under the rug doesn't >count.) I say that this charter thing should not be designed to be punitive, and you say that this means all discussion about licensing, charters, and the rest is pointless in light of that idea. Please make sense if you are going to address me in the future, or simply don't bother addressing me at all. Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
suggested properties of operator results
Currently, this expression:
VALUE1 < VALUE2
is functionally equivalent to this:
$v2 = VALUE2;
$v1 = VALUE1;
return ($v2-$v1 == abs($v2-$v1));
After reading the Apocalypse & Exegesis articles, and seeing some examples
of properties and the "is" operator, I'd like to suggest that the
less-then operator be changed, so it is functionally equivalent to:
$v2 = VALUE2;
$v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
which (assuming the operator's association was changed to "left") would
cause the following code to mean what beginning programmers always think it
should mean:
if ($foo < $bar < $baz) { ... }
It should be obvious how "> <= >= lt gt le ge" can similarly
be modified. Then even this would make sense...
if ($foo <= $bar > $yak lt $wak) { ... }
"== != eq ne" could be similarly modified (with the addition of a valueL
property to deal with precedence) but I haven't convinced myself it's a
good idea -- too many people like using == in place of xor...
if (($foo < $bar) == ($yak < wak)) { ... }
(I haven't even begun to consider <=> and cmp, but I'm sure there's
someone smarter then me out there with an idea on how/why they could
be modified as well (if for no other reason then to make obfuscated perl
contests even more interesting))
--
-------
"Oh, you're a tricky one."Chris M Hostetter
-- Trisha Weir[EMAIL PROTECTED]
Re: suggested properties of operator results
For the record, bwarnock pointed out to me that damian allready proposed
this behavior in RFC 25...
http://dev.perl.org/rfc/25.html
That RFC doesn't suggest having the comparison operators set properties
on their result -- instead it recomends that "multiple chained comparisons
should be automagically expanded to the equivalent binary conjunction."
... I think I like his way better. Mainly because I didn't consider the
ramifications of scenerios like this...
$input = 4;
$bool = $input < 22;# $bool = 1 is valueR(22)
print "ok!" if $bool == 1; # whoops, '==' is looking at $bool.valueR
But as long as we're on the subject, dstorrs raises some good issues on
"should we do it at all"...
: someone (was it tchrist?) pointed out, beginners don't stay beginners for
: long, so writing a language for beginners may cost you people when they
: "grow out of" your language. I don't this we should do this just because
I agree with that sentiment, but I don't think it applies in this case.
We're not talking about a feature that will be usefull for beginers, and
a hinderence to experienced users who move on to to another language
because being able to write "1 < $val <10" is making more work for them.
: 2) This feature would be very prone to abuse (makes it easier to
: obfuscate code), but that isn't a reason to disqualify something either.
I disagree, I think that this...
if (1 <= $x <= 10 and 1 <= $y <= 10) { # inside grid?
is much less obfuscated then this...
if (1 <= $x and $x <= 10 and 1 <= $y and $y <= 10) { # inside grid?
--
---
"Oh, you're a tricky one."Chris M Hostetter
-- Trisha Weir[EMAIL PROTECTED]
(proto)typing, return types, polymorphism, ... ?
A few questions regarding typing. (first some assumptions/axioms)
Axiom #1: perl6 will enable programs to be more explicit about the typing
of variables -- even allowing them to specify dynamic-ish properties about
the values in those variables.
Damian's Attribute::Types has examples like this...
my %handler : CODE; # Entries can only store sub refs
my $arr : ARRAY; # Can only store array ref
my $score : NUMBER(0.1..9.9); # Can only store a num between 0.1..9.9
my $guarded : Type(&odd);# Can only store values for which
# odd($value) returns true
while Exegesis 2 has examples whose syntax is probably a little closer to
what will finally be in perl6...
my int ($pre, $in, $post) is constant = (0..2);
Axiom #2: perl6 will allow more more robust subroutine prototyping for
compile time / run time type checking.
>From Exegesis 2...
sub insert (HASH $tree is rw, int $val) { ... }
sub search (HASH $tree is rw, *@_) { ...; return $tree }
(which will presumably cause a fatal error if called as insert(1,"foo")
Quandary #1: How "deep" of type specifications should / will perl6 allow?
For example, could something like this work?
my ARRAY(int(0..9)) $ref # $ref can only store an array ref
# ...and that array can only hold ints
# ...and those ints must be between 0 & 9
Quandary #2: Should / will subroutine prototyping provide any support
for specifying the return type? perhaps...
sub search (HASH $tree is rw, *@_) HASH { ...; return $tree }
If so, this opens up all sorts of questions ... the influence of
calling context (ie: "wantarray") comes to mind.
Quandary #3: Should / will perl6 support polymorphic typing? In the past,
it really hasn't mattered -- but as perl begins to support stricter typing
(if you want it) people may find themselves having to choose between
strongly typing their subroutines to make their code more explicit to
callers, or excluding typing info to make them useful in more situations.
All of these quandary's occurred to me as I started to wonder how you could
write a reusable Tree class whose insert/search/delete methods could be
prototyped to require an argument of the type specified when the Tree
was constructed. (without requiring the class to do it's own type
checking)
--
---
"Oh, you're a tricky one."Chris M Hostetter
-- Trisha Weir[EMAIL PROTECTED]
Private tests
Hello all, I've just published an article about public vs. private regression tests. I've defined private tests as t/*.t files that are for the author only and don't go in MANIFEST. Naturally, those don't get as much publicity as tests included in CPAN distributions. In the article I advocate that some tests should be private. In particular, 1) those that test non-critical aspects of a module (like documentation and coding style) 2) those that are too expensive to run often 3) those that require special software or customization In my conclusion I describe a possible system where authors publish the results of private tests with their distributions as a trust- based kwalitee system. That is, authors assert kwalitee rather than be judged for it. http://www.chrisdolan.net/talk/index.php/2005/11/14/private- regression-tests/ Both positive and negative feedback is very welcome! Chris -- Chris Dolan, Software Developer, www.chrisdolan.net Public key: http://www.chrisdolan.net/public.key
Private tests
Hello all, I've just published an article about public vs. private regression tests. Private ones are t/*.t files that are for the author only and don't go in MANIFEST. Naturally, those don't get as much publicity as tests included in CPAN distributions. In the article I advocate that some tests should be private. In particular, 1) those that test non-critical aspects of a module (like documentation and coding style) 2) those that are too expensive to run often 3) those that require special software or customization In my conclusion I describe a possible system where authors publish the results of private tests with their distributions as a trust- based kwalitee system. http://www.chrisdolan.net/talk/index.php/2005/11/14/private- regression-tests/ Both positive and negative feedback is very welcome! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Private tests
Tels, I believe you have misunderstood my intentions. I was not advocating that any algorithmic tests be non-public. The only tests that should be private are ones that satisfy one or more of the following restrictions: 1. require special additional software that’s difficult or expensive to acquire, 2. require special configuration to run properly, 3. don’t affect the quality of the final software, or 4. take too long to run. That is, tests like spell-checking, pod-checking, Perl::Critic and ones that take tens of minutes to run. Naturally, any test whose results may vary from machine to machine should be public wherever feasible. After reading some of the insightful comments posted on my blog, I've been convinced that the private tests should be included in the CPAN distribution, but disabled in some way (perhaps via a file extension other than .t?). That way, resourceful or interested users can run the tests but average users don't need to. The example I included at the end of the article stating a failed test under Windows was only tangentially related and perhaps was a distraction. I was saying that perhaps it would be useful if authors could assert things about their personal testing experience that would be machine readable and useful to others. In that example I was suggesting that the author could announce that the hypothetical module was known to fail under Windows and, as a TODO test, was an implicit request for help from other developers. Chris On Nov 15, 2005, at 4:12 AM, Tels wrote: -BEGIN PGP SIGNED MESSAGE- Moin, On Monday 14 November 2005 18:21, Chris Dolan wrote: Hello all, I've just published an article about public vs. private regression tests. I've defined private tests as t/*.t files that are for the author only and don't go in MANIFEST. Naturally, those don't get as much publicity as tests included in CPAN distributions. In the article I advocate that some tests should be private. In particular, 1) those that test non-critical aspects of a module (like documentation and coding style) 2) those that are too expensive to run often 3) those that require special software or customization In my conclusion I describe a possible system where authors publish the results of private tests with their distributions as a trust- based kwalitee system. That is, authors assert kwalitee rather than be judged for it. http://www.chrisdolan.net/talk/index.php/2005/11/14/private- regression-tests/ Both positive and negative feedback is very welcome! Private tests will only be run by the author, meaning they will be only run on a very small subset of all systems the modules can be used on. This limits their usefullness quite a bit. Case ein point: I can test my modules on linux, 32 bit, unthreaded, under unicode, and under perl 5.8.x. Thats about it, everything else gets really really complicated for me to set up and maintain/test. So, no win32, no mac, now solaris, no irix, no perl 5.6.x, no iso-something, no EBDIC (or however it is spelled), no threading, no 64 bit, no SMP system. As for 1), these things should matter (the "broken window analogy") and you would be surprised to know how these tests can pass on your system, and still fail on other systesm (forget to include the .pod file in MANIFEST is the most obvious one). As for 2), random testing should be employed (Math::BigInt does this, it runs 256 or so tests with random number patterns (and thus known results like "2 * A - A == A"). The tests are quite fast, but they cover only a small subset of potential values. However, since each system and user runs a new, different random set, you end up with a really huge testing number being run. (Yes, this has found some bugs) And for 3), this might be the only point I can think that private tests are usefull (I have a private testset for Graph::Easy that I use from time to time, it is not public mainly because it fails/hangs/takes forever and is work-in-progress). However, I have to actually read your article to find out what your proposal solves (compared to me just running thetest once in a while :) Hope that was usefull :) Best wishes, Tels - -- Signed on Tue Nov 15 11:04:21 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "Now, _you_ behave!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQ3m0pHcLPEOTuEwVAQF6lQf8CtubDMQjLdCBcEGNczxZj2Y1kTVhOU7Z bvweeJe4RWFfmd2JMw7dwiu3Sjb57hNlVkl4LwN+7vx3tm3DsnhRUoMHvkDtCddC 8bfxpLcOi8WMlySAud+unKnpZVwlwn2rZ/enu2Dd01QKOgOQkBr1HWTJUguPv4No eWT3UiEZhV4hU764gtF7a8raHjbvxpTJcNk22KHnRmyTKX+SugCyI0qkmIQrFntl cQWXyA9GV7V+5bK5/Sp2eWv2MXX3fhNDxtZywkmqun+6/YhPgSDJQp3FcKThZFYy WxPXsrXVIXFJbbtkSs+PGe18VdXqEFCHOI29H1+9gyiC3FW3N6AARw== =GA3y -END PGP SIGNATURE
Re: Private tests
On Nov 15, 2005, at 3:38 PM, chromatic wrote: I posted a small Module::Build subclass that shows one way to do this to Perl Monks: http://perlmonks.org/?node_id=508160 Yeah, I saw that one. Perhaps a better approach is to store these tests in a subdirectory of t/. Beware that M::B has a recursive mode for finding tests. It's set by the author, so you should be safe in this case, but it's a point worth remembering. *light bulb* And in fact, that could be the run-time trigger. Hmmm.... Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: How to use Devel::Cover?
On Dec 25, 2005, at 3:46 PM, Scott Wang wrote: I am new to use Devel::Cover. We have lots of product Perl modules in our product "lib" folder and we have lots of Perl test scripts to cover those modules, right now, we are trying to get the code coverage metrics for our tests on those modules. I find we might get help by using Devel::Cover, would you please give me some idea on how I should use the Devel::Cover to generate our tests coverage metrics on our Perl modules? Thanks in advance, Scott If you use Module::Build, then simply type "./Build testcover" and then open cover_db/coverage.html in your browser. If you are using a version of M::B older than 0.27_02, you may wish to manually delete the whole cover_db directory between runs. Later M::B versions auto- detect when cover_db files are out of date. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
punie.g observation
Allison et al.,
I was looking at languages/punie/lib/punie.g in the current SVN head
and got confused. I see:
rule gprint { (print) \s* }
and
rule expr{ | }
Doesn't that imply that "print print print print 1;" is a valid Punie
program? Is that intentional? It seems to me that the gprint rule
should instead contain "cexpr":
rule gprint { (print) \s* }
Sorry if these are dumb questions. I've been following Parrot for a
while, but I'm new to the code...
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Jan 27, 2006, at 12:01 PM, Tels wrote: On Friday 27 January 2006 18:48, Chris Dolan wrote: On Jan 27, 2006, at 11:23 AM, Tels wrote: Basically something like CPAN, but with much less network traffic and much less hassle for a user. Bonus points if it gives you stuff pre- compiled for windows (all those ppl w/o a compiler). I think you just described ActiveState's Perl Package Manager (PPM). http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/ I lived under the expression that it is: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Jan 27, 2006, at 11:23 AM, Tels wrote: Basically something like CPAN, but with much less network traffic and much less hassle for a user. Bonus points if it gives you stuff pre- compiled for windows (all those ppl w/o a compiler). I think you just described ActiveState's Perl Package Manager (PPM). http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/ Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Jan 27, 2006, at 12:30 PM, Tyler MacDonald wrote: Chris Dolan <[EMAIL PROTECTED]> wrote: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? Um, no it isn't! http://ppm.activestate.com/ PPMs are built for a variety of platforms, windows, OSX, and various unixes. You can download ActivePerl for these platforms here: http://www.activestate.com/Products/Download/Download.plex? id=ActivePerl - Tyler Sweet! I didn't know that. Yay ActiveState! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
Tels,
Please forgive me for being blunt, but I think it's your fault for
writing fragile META.yml creation code. YAML.pm is not even at 1.00
yet, so an API change is allowed by convention, and lack of backward
compatibility is to be expected. If you were to have wrapped your
whole custom META.yml creation code in a big eval, there would not
have been a problem. Furthermore, it seems to me that you are
reinventing the wheel by adding custom META.yml code to the
Makefile.PL of every package you write instead of, say, using
Module::Build or just omitting the non-essential META.yml customization.
The ultimate solution, of course, is that there will be a standard
way to generate proper META.yml. In the meantime, however, it is my
opinion that we're better off lacking META.yml than having a
proliferation of different solutions to the META.yml issues.
Chris
On Jan 28, 2006, at 4:26 AM, Tels wrote:
Moin,
On Saturday 28 January 2006 11:08, Adam Kennedy wrote:
Graph::Easy installation failing here with YAML 0.50 (newer
versions of
YAML seem to be uninstallable at the moment due to Class::Spiffy +
Spiffy + Test::Base install failures...
Just what I said about dependecies etc. My Makefile.PL uses YAML
for me
(e.g. the author) to create a META.yml file with a license field,
something that MakeMaker (could?) can't do.
I used "require YAML;" to avoid that the user has to has it installed.
Unfortunately, YAML got changed, and now you also need "require
YAML::Node;" for my Makefile.PL working properly. :-(
So you can either:
* patch my Makefile.PL
* patch YAML to work like the previous version, then update it on
CPAN,
then install it
The latter is way more work, and needs time and due to what you wrote
above, might even not work.
I'd say keep the dependencies out of YAML ("KISS"!). Whether YAML
should
also load YAML::Node when you do "require YAML;" is a point for
discussion, but it certainly tripped up a *lot* of existing
Makefiles and
I don't have the time to patch them all because that requires me to
release a dozend or so modules.
Sorry for the problem, but it is only partly my fautl :)
Best wishes,
Tels
--
Signed on Sat Jan 28 11:22:01 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
This email violates EU patent EP0394160:
[ ## 66% ]
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
On Jan 30, 2006, at 10:04 AM, David Cantrell wrote: [...] for example, on OS X, HFS+ is case-preserving but case- insensitive. UFS is case-sensitive. And FAT16 smashes case. And to make matters even worse (better?) Apple added a case-sensitive mode to HFS+ in 10.4. It's not widely used. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: YAML and Makefile.PL (was various topics)
On Jan 31, 2006, at 2:30 AM, Adam Kennedy wrote: Solutions that can be implement without either betting incredibly aggressive to users, putting MB or CPANPLUS into the core, or going down the bundled route, would be interesting to hear though. If I've read the perl5-porter summaries correctly, M::B just entered core in 5.9.3. There has long been hope that M::B and CPANPLUS will be in core for 5.10. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: YAML and Makefile.PL (was various topics)
On Jan 31, 2006, at 2:32 AM, Adam Kennedy wrote: But then how are you going to make Bundle::CPAN trigger when there's a critical failure, without requiring the user to be smart? CPAN.pm and CPANPLUS.pm already check their own version against CPAN on every run. All we'd need to do is have Andreas or Jos increment the CPAN.pm/CPANPLUS.pm version and just about everyone would be prompted to upgrade the next time they tried to install something. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: TODO test paradox: better TODO test management?
On Jan 31, 2006, at 10:40 AM, demerphq wrote: While only indirectly related. Lately when ive built blead I see stuff like "10 TODO tests unexpectedly passed!" So far ive not found a way to make harness tell me which they are... So i too would like a report of TODO tests, both those passing and those failing. You could try: make test verbose=1 > out and then search the output for "TODO" Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [Module::Build] [RFC] author tests
On Feb 1, 2006, at 10:35 PM, Tyler MacDonald wrote: Chris Dolan <[EMAIL PROTECTED]> wrote: There is a class of tests that module authors perform that end users are not expected to run. For example code coverage tests, spelling tests, coding style tests, etc. These tests are either prohibitively expensive or complicated or unpredictable for end users to run. I call these "private tests" or author tests. I really like this idea. But as you pointed out, it's not just authors that need to worry about running these tests, it's packagers (ppm/deb/etc), automated testers (cpants/testers.cpan.org/etc), and hackers. I'd suggest we call these "exhaustive" tests. No, I disagree. I'm specifically talking about author tests, NOT packager tests. Things like Test::Spelling are pointless and difficult for packagers to execute because Test::Spelling relies on an external aspell or ispell program *and* performs differently in the presence of an author's custom dictionary (mine has "Dolan"; does yours?) These specifically are not exhaustive tests but spit-and-polish tests. To make this less abstract, let me list the specific author tests that I employ for most of my CPAN modules, along with an explanation of why it wouldn't work for a packager * copyright.t - Ensures that there is a "Copyright ".([localtime]-> [5]+1900) somewhere in every .pm file. Will break 11 months from now. * distribution.t - Relies on Test::Distribution, which is not in my prereq list * perlcritic.t - Runs Test::Perl::Critic on all .pm files. Will fail without my specific $HOME/.perlcriticrc and will fail with future, more exhaustive versions of P::C * spelling.t - Runs Test::Spelling. Will fail without my custom dictionary * versionsync.t - Checks that the $VERSION is the same in all bin/* and *.pm files. This test is pointless after release, since it's already been tested before release * pod.t - Checks POD validity. This test is pointless after release, since it's already been tested before release * pod-coverage.t - Checks POD completeness. This test is pointless after release, since it's already been tested before release and one I have not yet employed: * coverage.t - Ensures that Devel::Cover totals are higher than some threshold Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [Module::Build] [RFC] author tests
On Feb 2, 2006, at 9:19 PM, Yitzchak Scott-Thoennes wrote: Chris, how are you currently set up to run these tests only when preparing a release? I make no such distinction. Instead, I see these tests as part of my day-to-day development and run all of them with every "./Build test". Presently, I simply include them all in my MANIFEST.SKIP so they are not included in my uploaded package. That's why I call these "author tests" and not "release tests" or "exhaustive tests". Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Default tests, beta testing, etc.
On Feb 5, 2006, at 2:36 PM, Bryce Harrington wrote: [snip] It would seem to be useful if CPAN were to have a couple really basic tests like this to run for perl modules that haven't created any tests themselves. Obviously, this only benefits immature modules, but this might be a good way to motivate new authors to put more attention into testing. I recommend Test::Distribution for this type of "default" tests. It looks for .pm files in blib and performs a bunch of tests on them -- POD, compile, version, etc. [snip] Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Default tests, beta testing, etc.
On Feb 6, 2006, at 1:37 AM, Adam Kennedy wrote: In fact, what you just asked is already listed in the PITA documentation as within it's scope. For lack of a better name, I've called it Fallout Testing. As opposed to Rot Testing, which is when your module doesn't change, but makes sure it still works as Perl is upgraded and your dependencies evolve. Since I've got a terribly bad habit of inventing things that have existing names, I'm sure someone will correct my on the two above namings. I think those are great names. Very clear. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: OS.pmc patch to add 'ls'
On Feb 12, 2006, at 6:52 PM, Joshua Hoblitt wrote: It would also be 'really nice' have a glob(3) like method that is implemented as a wrapper around *dir methods so the semantics are portable. My outsider opinion is that parrot should focus on exposing basic OS functions (opendir, readdir, closedir) and leave the high-level functions (ls, glob) to the languages or libraries. My justification for that opinion is security lockdown. If there are more op-level ways of accessing the system, then there are more features that sandboxes like Safe.pm have to disable. Even more critical is the potential for creep. If sandboxes have to follow a moving target, then it could make it challenging to make security promises. Certainly, it would aid performance to have parrot-level support for commonly used idioms like directory slurping, but the price is more work for the languages. It's kind of a CISC vs. RISC argument. Again, this is an outsider opinion. Apologies in advance if I'm off- base or misunderstood the proposal. Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: OS.pmc patch to add 'ls'
On Feb 13, 2006, at 1:20 PM, Joshua Hoblitt wrote: On Mon, Feb 13, 2006 at 09:28:40AM -0600, Chris Dolan wrote: On Feb 12, 2006, at 6:52 PM, Joshua Hoblitt wrote: It would also be 'really nice' have a glob(3) like method that is implemented as a wrapper around *dir methods so the semantics are portable. My outsider opinion is that parrot should focus on exposing basic OS functions (opendir, readdir, closedir) and leave the high-level functions (ls, glob) to the languages or libraries. My justification for that opinion is security lockdown. If there are more op-level ways of accessing the system, then there are more features that sandboxes like Safe.pm have to disable. Even more critical is the potential for creep. If sandboxes have to follow a moving target, then it could make it challenging to make security promises. I think your slightly confusing OPs and PMCs. Presumably the *dir functionality would be implemented as OP codes while glob(3) would be implemented in the OS.pmc. For all intents and purposes PMCs can fill the role of what you referred to as libraries. Thanks for the clarification. Apologies for the spam! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #38604] m4.pm vs. M4.pm causes problems in case-insensitive filesystems
On Feb 21, 2006, at 1:30 PM, Bernhard Schmalhofer wrote: Chris Dolan (via RT) schrieb: # New Ticket Created by Chris Dolan # Please include the string: [perl #38604] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38604 > While doing an "svn update" from a Mac OS X box today, I got this error: svn: Failed to add file 'languages/m4/lib/Parrot/Test/M4.pm': object of the same name already exists This is funny. I think that I have renamed m4.pm to M4.pm around revision 11350. So it should be OK for fresh checkouts. The funny thing is that I can do a 'svn mv' under Unix, which causes troubles on case-insensitive filesystems. Aha. Indeed, the last time I updated was prior to 11350, I believe. I agree that fresh checkouts should be OK. In this case, my successful workaround was simply "rm languages/m4/lib/Parrot/Test/ m4.pm ; svn update" IIRC, "svn mv" is really just "svn cp" followed by "svn rm" behind the scenes. So, there is a moment during update when both files need to exist. A possible (untested) workaround for committers might be: svn mv m4.pm m4-temp.pm svn commit svn mv m4-temp.pm M4.pm svn commit To prevent a repeat of this problem in the future, one solution is to use the check-case-insensitive.pl pre-commit hook script that is in the contrib directory of the subversion source. This FAQ has more info: http://subversion.tigris.org/faq.html#case-change Somebody who can administrate the SVN server could take a look at this script. The FAQ does not really tell what it does. Mandating all lower case filenames is no solution. The script looks at the incoming files and compares to existing files to see if any names differ only in case. If there are such files, the commit fails. Chris
Surprising use_ok false positive
I encountered a real-world case where Test::More's use_ok() passed
when the specified package had a fatal syntax error. I'm looking for
advice about whether I should file a bug, or fix my code that
triggered the false positive. Read on for details...
Consider two packages Foo.pm and Bar.pm:
--- Foo.pm ---
package Foo;
my $has_Bar = eval {require Bar; 1;};
sub print_msg {
$has_Bar ? Bar->print("Hello") : print "Hello";
}
1;
--- Bar.pm ---
package Bar;
sub print { # egregious syntax error
1;
--- t/use.t ---
use Test::More tests => 2;
use_ok('Foo');
use_ok('Bar');
Then if I run "perl t/use.t" I get the surprising result:
1..2
ok 1 - use Foo;
ok 2 - use Bar;
The problem is that Foo trapped Bar's syntax error in the eval, so %
INC{Bar} is defined and use_ok() sees it as a success.
Advice? While this example is contrived, the "eval { require ... }"
idiom is used often in the wild, so this is not a wholly unrealistic
scenario.
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Surprising use_ok false positive
On Mar 5, 2006, at 3:55 PM, David Wheeler wrote:
On Mar 5, 2006, at 13:52, Chris Dolan wrote:
Advice? While this example is contrived, the "eval
{ require ... }" idiom is used often in the wild, so this is not a
wholly unrealistic scenario.
Of course it should be
eval { require Bar; 1; } or die $@;
But I agree that it seems like if the load failed in your eval, it
should fail for Test::More, too. But maybe even a failed require
sets the record in %INC?
In this case, Bar.pm is intended to represent optional functionality
that Foo.pm conditionally loads. So, adding a die would be
counterproductive. The problem is that I don't know how to
distinguish between a load failure or a compile failure. There must
be a way to do that right?
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: early draft of I/O PDD
On Mar 6, 2006, at 6:08 AM, Leopold Toetsch wrote:
Using opcodes for all the IO has some disadvantages:
a) namespace pollution: all opcodes are reserved words in Parrot
b) opcodes aren't overridable, that is you can't provide your own
'print' opcode for e.g. debugging
c) all such IO opcodes have to verify that the given PMC is
actually a ParrotIO PMC.
E.g.
new P0, .Undef # or .Integer, ...
print P0, "foo"
I'm in favor of using methods for almost all IO functionality:
P0.'print'("sample data\n")
I agree. Additionally, I speculate that the latter would make it
easier to write the Parrot equivalent of Safe.pm's sandbox later. It
would likely be easier to disable a PMC class than a diverse
collection of opcodes.
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: Best Practice for testing compilation of scripts
On Mar 15, 2006, at 2:47 PM, Geoffrey Young wrote: chromatic wrote: On Wednesday 15 March 2006 12:25, Jeffrey Thalhammer wrote: I'm sure I could clean this up by opening a pipe instead of using backticks and output redirection. But even that doesn't smell very good. I've looked around on CPAN, but I have not yet found a Test:: module that seems appropriate. I also wondered if fiddling with $^C would do the trick somehow. Any suggestions? Thanks. I've long intended to take t/test.pl from the Perl core distribution and wrap up at least its runperl() in a Test:: module. Perhaps that would work for you? compile_ok() ? --Geoff It is unclear from Geoff's message above whether he is asserting that function exists, or if he is merely proposing it, so I googled. It doesn't appear to exist in any Test:: package (corrections VERY welcome). However, Adam Kennedy wrote one: http://search.cpan.org/src/ADAMK/ThreatNet-Bot-AmmoBot-0.10/t/ 01_compile.t That function should probably be changed to use FindBin instead of updir() calls. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Upgrading core modules on Windows
On Mar 16, 2006, at 8:51 AM, David Golden wrote: ... So why not bundle a snapshot of all the module dependencies for PPM/ cpan.pm into a separate directory and put that at the start of @INC when running PPM/cpan.pm? ... Makes sense to me. PAR would be a very valuable tool to implement this, although that would be a huge addition to the dependency list. With PAR, you could employ a whole separate .exe and probably even do the core updates. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [PATCH] Forking tests with Test::More
On Mar 28, 2006, at 4:55 AM, Tassilo von Parseval wrote:
Do you think this might work better, or could be implemented as, a
seperate Test::Fork type module?
It certainly could be done. But it would essentially share 90% of its
code with Test::Builder.
Umm, subclassing? :-)
It's simple really: Either my proposed method
is robust in which case it can go into Test-Simple. Or it isn't. Then
there's no need to implement it as a separate module. :-)
I don't think it is that simple. *IF* there are any bugs in this
niche feature, then it could break the most popular test module on
CPAN. Clearly from your proposed patch, any code that needs the fork
feature of Test::More says so explicitly via the $self->{Forked}
property. So specifying a subclass instead, like a hypothetical
Test::More::Forked, should be trivial. I have not yet seen any
justification for adding this feature to Test::More itself.
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Module requirements
On Apr 5, 2006, at 9:06 AM, David Landgren wrote: 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). Yes, it can: % corelist File::Find Memoize File::Find was first released with perl 5 Memoize was first released with perl 5.007003 Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Where can I find a Perl 6 langauge reference?
Hi Mr. Mathews,
PXPerl (http://pxperl.com/) has a version of Perl6 compiled into
the build. That should get you started.
Regards,
Chris
On 5/18/06, Michael Mathews <[EMAIL PROTECTED]> wrote:
Like Thomas, I'm interested in having a go, in my case I'd like to
install something I can play with. The link is appreciated but what I
was hoping for was a simple set of instructions for just installing
Perl6 (maybe I missed it--sorry) . Does such a thing exist?
Regards,
Michael Mathews
On 18/05/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> Hallo Thomas :-),
>
> * Thomas Wittek <[EMAIL PROTECTED]> [2006-05-18 20:30]:
> > Would you recommend reading the synopses[1]?
> > Or should I take a look at pugs-doc?
>
> the synopses are the canonical design documentation of the Perl 6
> language, to my understanding. Pugs-doc would probably be a good
> place to look if you actually want to tinker in the language (at
> least, in its Pugs incarnation). There's a `getting_started`[1]
> in pugs-doc that should provide the sort of pointers you're after.
>
> [1]: http://svn.openfoundry.org/pugs/docs/getting_started
>
> Regards,
> --
> #Aristotle
> *AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
> &Just->another->Perl->hacker;
>
Windows Binaries for Pugs
Hi All, I just wanted to let you know that there are some Windows binaries of Pugs avaliable from Jonathan Worthington (http://www.jwcs.net/~jonathan/perl6/). They seem to be a bit out of date (last update was at Monday, 10-Apr-2006 05:29:30 CDT) but should get you started. Regards, Chris
Re: Windows Binaries for Pugs
True. Although, I would say that for those who only want to tinker with the language, this might be the most convenient way to do so. I have already started to work with it and I am liking what I am seeing. On 5/19/06, James Peregrino <[EMAIL PROTECTED]> wrote: At this stage, are binaries even worth it? Judging from my lurking on #perl6, things are moving so fast that anything but a regular nightly-built binary would be too out of date. Seems like svn is the way to go. -James At 11:58 AM -0400 5/19/06, Chris Yocum wrote: >Hi All, > I just wanted to let you know that there are some Windows >binaries of Pugs avaliable from Jonathan Worthington >(<http://www.jwcs.net/~jonathan/perl6/>http://www.jwcs.net/~jonathan/perl6/). > They seem to be a bit out of >date (last update was at Monday, 10-Apr-2006 05:29:30 CDT) but should >get you started. > >Regards, >Chris -- -- James Peregrino - http://people.dce.harvard.edu/~peregrin/business-card.html
Re: CPANTS is not a game.
On May 23, 2006, at 8:39 AM, David Golden wrote: How does "is_prereq" improve quality? Or, put differently, how does measuring something that an author can't control create an incentive to improve? is_prereq is usually a proxy metric for software maturity: if someone thinks your module is good enough that he would rather depend on it than reinvent it, then it's probably a better-than-average module on CPAN. is_prereq is usually a vote of confidence, so it is likely a good proxy for quality. In fact I believe that because the author (usually) can't control it directly, is_prereq is one of the best proxies for quality among the current kwalitee metrics. CPANTS by itself does nothing to improve quality. However, by drawing attention to kwalitee metrics, I argue that CPANTS draws attention to quality too. Even if many authors don't understand that, the ones that do makes CPANTS worthwhile. If making it a game helps to further raise awareness, then I think that should be tolerated until CPANTS matures. IMHO, the best way to improve CPANTS and move away from the game mentality is to continually add more tests. Each added test diminishes the weight of previous tests. This will annoy the "gamers" because their modules keep dropping in kwalitee, while those that genuinely care about quality will appreciate the additional measurements. If some gamers get annoyed enough to quit the game, that's not a big deal because they didn't really understand the point of CPANTS anyway. If some keep playing the game by cleaving to the standards the community sets for them, then all the better for the rest of us. As an example, consider pod_coverage. It's a rather annoying metric, most of us agree. Test::Pod::Coverage really only needs to be run on the author's machine, not on every user's machine. However, by adding pod_coverage to kwalitee we got LOTS of authors to improve their POD with the cost of wasting cycles on users' machines. I think that's a price worth paying -- at least until we rewrite the metric to actually test POD coverage (which is a decent proxy for POD quality) instead of just checking for the presence of a t/ pod_coverage.t file (which is a weak proxy for POD quality, but dramatically easier to measure). Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: CPANTS is not a game.
On May 23, 2006, at 10:34 AM, David Golden wrote: Chris Dolan wrote: ... just checking for the presence of a t/pod_coverage.t file (which is a weak proxy for POD quality, but dramatically easier to measure). It doesn't check for the existence of a t/pod_coverage.t file. It checks that a string like "use Test::Pod::Coverage" appears properly formatted. E.g. I believe this is sufficient to get the Kwalitee point: # t/pod_coverage.t __END__ use Test::Pod::Coverage; And, unfortunately, it also misses actual perl that doesn't meet its regex expectations. (E.g. see the bug I recently filed for Module::ExtractUse.) Point taken, apologies for the inaccuracy. However, that supports my argument that pod_coverage is a weak proxy. I say it's much better than nothing, but still weak and the brittleness documented above makes it weaker. Actually, I'd rather see a robust pod_coverage that just checks for the existence of t/.*pod_coverage.t than a slightly brittle that parses that file. That is, I'd rather see false positives than false negatives. To put it another way, I'll tolerate cheaters to avoid annoying the well-intentioned authors. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: CPANTS is not a game.
On May 23, 2006, at 10:15 AM, H.Merijn Brand wrote: is_prereq is usually a vote of confidence, I respectfully disagree completely. It's been more than once that I did *not* install a module because it required a module that I did not trust, either because of (the programming style of) the author of that module, or because that module required yet another zillion things I do not want installed (think YAML). I believe we are largely in agreement, but I think your example demonstrates that you missed my point. As you well know, CPANTS is not making recommendations whether a module is a good solution for your problem, or whether you should trust a given module. Instead, it is currently measuring maturity of a module and the author's attention to detail. is_prereq just measures whether *any* other humans trust the module in question. In that way, is_prereq is like a simplistic binary version of Google's page rank. Just because Google rates a page highly doesn't mean it's a good page. Similarly just because CPANTS ranks a module highly doesn't mean it's a good module. However, both is_prereq and page rank are among the current best automatable proxies we have for approximating human judgment of quality. Yes, there are great modules with is_prereq of 0 and there are great web sites with low page ranks. But in both cases they're harder to find than their highly-linked counterparts, except via word of mouth (perlmonks, cpanratings, etc). I keep advocating for is_prereq because currently it's the only non- author-controlled input to CPANTS. That's it's primary value, and it will continue to be important until some better proxy for human confidence comes along, like incorporating cpanratings into CPANTS (I do NOT advocate that!) or getting download stats from CPAN (never gonna happen) or adding voluntary "Someone installed module X" pings from CPAN.pm. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: perl 6 hosting?
That is an interesting idea but, as you say, fraught with security problems. Maybe we can find a team of people to create binaries on a regular basis for most of the major platforms? That would mitigate the security concerns and allow people to run up-to-date stuff. This is just a thought, however. Chris On 5/23/06, Michael Mathews <[EMAIL PROTECTED]> wrote: I realise its still very, very early days, but considering the growing number of people who would enjoy just dabbling a little in perl6, it seems unreasonable to expect that the "average person" would install the many megabytes of beta (alpha?) software required, and keep it all updated with the latest releases. However, if someone had already done that, why not let folks log in remotely via shell accounts and try out the latest version on that computer? Okay, okay, I know there are a million security issues with that, but maybe if the server were highly locked down and isolated, maybe wiped clean regularly, and restricted in the necessary ways... Is this even possible? I'm not a sys. admin, but I thought I'd throw that out there. Any one think that would be useful and possible, and want to suggest a way to proceed with that? --michael
Simple Print/Say Question
Hi all, I was converting a program that I wrote a while back from Perl5 to Perl6 and I got stuck on something really easy. In Perl5, when I want to print something out, in this case an array with lines between the columns, like this: 1|2|3 I would say something like: print $array[0] . "|" . $array[1] . "|" . $array[2] . "\n"; not the best way but it works. In Perl6 if say something like this: print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] . "\n"; I get 1 2 3 | | | My question is: why is it doing that or, more to the point, what am I doing wrong? Thanks, Chris PS This is what I am running currently: This is Perl6 User's Golfing System, version 6.2.11, February 1, 2006 built for MSWin32-x86-multi-thread Summary of pugs configuration: archlib: C:\Perl6\lib archname: MSWin32-x86-multi-thread bin: C:\Perl\bin exe_ext: .exe file_sep: \ installarchlib: C:\Perl6\lib installbin: C:\Perl\bin installman1dir: C:\Perl\man\man1 installman3dir: C:\Perl\man\man3 installprivlib: C:\Perl6\lib installscript: C:\Perl\bin installsitearch: C:\Perl6\site\lib installsitebin: C:\Perl\bin installsitelib: C:\Perl6\site\lib installsiteman1dir: C:\Perl\man\man1 installsiteman3dir: C:\Perl\man\man3 osname: MSWin32 pager: more /e path_sep: ; perl5path: C:\Perl\bin\perl.exe perl_revision: 6 perl_subversion: 0 perl_version: 0 prefix: C:\Perl privlib: C:\Perl6\lib pugs_revision: 0 pugs_version: Perl6 User's Golfing System, version 6.2.11, February 1, 2 006 pugs_versnum: 6.2.11 pugspath: C:\Perl\bin\pugs.exe scriptdir: C:\Perl\bin sitearch: C:\Perl6\site\lib sitebin: C:\Perl\site\bin sitelib: C:\Perl6\site\lib siteprefix: C:\Perl\site sitescript: C:\Perl\bin sourcedir: F:/Hacking/Pugs-Build @*INC: C:\Perl6\lib C:\Perl6\lib C:\Perl6\site\lib C:\Perl6\site\lib C:\Perl6\lib\auto\pugs\perl6\lib C:\Perl6\site\lib\auto\pugs\perl6\lib .
Re: Simple Print/Say Question
Oops. That last . is a typo on my part. Sorry about that! It should read, which it does in my code: print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] ~ "\n"; However, your say join technique does not work. I will keep on it but for now I am off to dinner! Thanks!, Chris On 5/23/06, Gabor Szabo <[EMAIL PROTECTED]> wrote: On 5/23/06, Chris Yocum <[EMAIL PROTECTED]> wrote: > > 1|2|3 > > I would say something like: > > print $array[0] . "|" . $array[1] . "|" . $array[2] . "\n"; > > not the best way but it works. > > In Perl6 if say something like this: > > print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] . "\n"; > > I get > > 1 2 3 | | | > > My question is: why is it doing that or, more to the point, what am I > doing wrong? > I am not sure, maybe the . before "\n" cause the problem but why not try this one: my @array = (1, 2, 3); say join "|", @array; Gabor
Re: Simple Print/Say Question
Dear Fagyal, Huh. Strange. I tried the code on its own without the rest of the script and it did just fine as well. There must be something wrong in my script somewhere. Chris On 5/23/06, Fagyal Csongor <[EMAIL PROTECTED]> wrote: Chris, Strange. I have just tried this using an old version (6.2.3) of Pugs: my (@array) = 1,2,3; print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] ~ "\n"; It prints 1|2|3 on my terminal. Gabor's join-ed version also works. - Fagzal > Oops. That last . is a typo on my part. Sorry about that! It should > read, which it does in my code: > > print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] ~ "\n"; > > However, your say join technique does not work. I will keep on it but > for now I am off to dinner! > > Thanks!, > Chris > > On 5/23/06, Gabor Szabo <[EMAIL PROTECTED]> wrote: >> On 5/23/06, Chris Yocum <[EMAIL PROTECTED]> wrote: >> > >> > 1|2|3 >> > >> > I would say something like: >> > >> > print $array[0] . "|" . $array[1] . "|" . $array[2] . "\n"; >> > >> > not the best way but it works. >> > >> > In Perl6 if say something like this: >> > >> > print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] . "\n"; >> > >> > I get >> > >> > 1 2 3 | | | >> > >> > My question is: why is it doing that or, more to the point, what am >> I doing wrong? >> > >> >> I am not sure, maybe the . before "\n" cause the problem but why not >> try this one: >> >> my @array = (1, 2, 3); >> say join "|", @array; >> >> Gabor
Re: Simple Print/Say Question
Huh. The script is not too long so I will post it here for people to
see since I cannot see anything wrong with it. It is just
embarrassing to give out bad code.
All it does is solves a bucket problem, which I have been working on
for something else.
my @wArray;
my @xArray;
my @yArray;
my @zArray;
for 0..4 -> my $i {
@wArray[$i] = $i * 10.5;
}
for 0..6 -> my $j {
@xArray[$j] = $j * 7;
}
for 0..12 -> my $k {
@yArray[$k] = $k * 3;
}
for 0..18 -> my $l {
@zArray[$l] = $l * 2;
}
my %hash;
my $key = 0;
for 0..4 -> my $i {
my $w = @wArray[$i];
for 0..6 -> my $j {
my $x = @xArray[$j];
for 0..12 -> my $k {
my $y = @yArray[$k];
for 0..18 -> my $l {
my $z = @zArray[$l];
if(($w + $x + $y + $z) == 35) {
my @total = ($i, $j, $k, $l);
%hash{$key} = [EMAIL PROTECTED];
$key++;
}
}
}
}
}
for %hash.sort.keys -> my $key {
my @total = %hash{$key};
print "$key: " ~ @total[0] ~ "|" ~ @total[1] ~ "|" ~ @total[2] ~ "|"
~ @total[3] ~ "\n";
}
On 5/23/06, Ovid <[EMAIL PROTECTED]> wrote:
This seems to work for me:
pugs -e 'say (1,2,3).join("|")'
1|2|3
Or even:
pugs -e '(1,2,3).join("|").say'
1|2|3
Cheers,
Ovid
-- If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
- Original Message
From: Fagyal Csongor <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: perl6-users@perl.org
Sent: Tuesday, May 23, 2006 12:11:07 PM
Subject: Re: Simple Print/Say Question
Chris,
Strange. I have just tried this using an old version (6.2.3) of Pugs:
my (@array) = 1,2,3;
print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] ~ "\n";
It prints
1|2|3
on my terminal.
Gabor's join-ed version also works.
- Fagzal
> Oops. That last . is a typo on my part. Sorry about that! It should
> read, which it does in my code:
>
> print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] ~ "\n";
>
> However, your say join technique does not work. I will keep on it but
> for now I am off to dinner!
>
> Thanks!,
> Chris
>
> On 5/23/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
>> On 5/23/06, Chris Yocum <[EMAIL PROTECTED]> wrote:
>> >
>> > 1|2|3
>> >
>> > I would say something like:
>> >
>> > print $array[0] . "|" . $array[1] . "|" . $array[2] . "\n";
>> >
>> > not the best way but it works.
>> >
>> > In Perl6 if say something like this:
>> >
>> > print @array[0] ~ "|" ~ @array[1] ~ "|" ~ @array[2] . "\n";
>> >
>> > I get
>> >
>> > 1 2 3 | | |
>> >
>> > My question is: why is it doing that or, more to the point, what am
>> I doing wrong?
>> >
>>
>> I am not sure, maybe the . before "\n" cause the problem but why not
>> try this one:
>>
>> my @array = (1, 2, 3);
>> say join "|", @array;
>>
>> Gabor
Re: Simple Print/Say Question
Dear Mr. Bach,
You were indeed correct so I wrapped the %hash like this
"@{%hash}" like you would to de-refrence an array and it worked
perfectly. It was indeed just me.
Thanks to everyone that responded!
Chris
On 5/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Oh, I just saw some discussion about the flatten op and:
for %hash.sort.keys -> my $key {
my @total = [,] %hash{$key};
maybe, would be the unroll or:
for %hash.sort.keys -> my $key {
my @total = ( %hash{$key} );
or
for %hash.sort.keys -> my $key {
my (@total) = %hash{$key};
perhaps?
a
Andy Bach, Sys. Mangler
Internet: [EMAIL PROTECTED]
VOICE: (608) 261-5738 FAX 264-5932
"It's a summons."
"What's a summons?"
"It means summon's in trouble."
-- Rocky and Bullwinkle
Re: Simple Print/Say Question
Hi Everyone,
I never thought that my little script would get such loving
attention least of all from such distinguished members of the
community. It took me a little while to understand exactly what was
going on but now that I do, it looks very good.
Thank you again! It has been very instructive.
Chris
On 5/24/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
my %buckets = (
w => {
count => 4,
scale => 10.5,
},
x => {
count => 6,
scale => 7,
},
y => {
count => 12,
scale => 3,
},
z => {
count => 18,
scale => 2,
},
);
for %buckets.values -> $arg_for {
$arg_for = [ ( 0 .. $arg_for ) »*« $arg_for ];
}
my int @results;
my int $target = 35;
for %buckets.kv -> $i, $w {
say "To 4: $i";
last if $w > $target;
for %buckets.kv -> $j, $x {
say " To 6: $j";
last if ($w, $x).sum > $target;
for %buckets.kv -> $k, $y {
last if ($w, $x, $y).sum > $target;
for %buckets.kv -> $l, $z {
if( $target == ($w, $x, $y, $z).sum ) {
@results.push( [$i, $j, $k, $l] );
}
}
}
}
}
for @results.kv -> $idx, $result {
say "$idx: $result.join(' | ')";
}
I assume all those temporaries that I cleaned out were there for
speed, in which case this will run slower, but they were too
unsightly to keep around.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
Re: 3 Good Reasons...
On May 26, 2006, at 6:37 AM, Michael Mathews wrote: I use the expat and libxslt libraries (both in C) regularly via perl, so I guess I must agree that there is a distinction -- thank you for clarifying that. But I can't think of any examples where I was stuck because I couldn't use a "library" only available in, say Python, or JavaScript in my Perl. But then I'm seeking to learn here so can you give a nice juicy example of a non-C library that would be a big plus to be able to include in Perl? I have a real-world example from my work. Perl lacked a library for parsing and editing Macromedia FLV files. There was one in Ruby[1], but the rest of my code was written in Perl. So, I created the FLV- Info library[2]. It's pretty nice for reading FLVs IMHO, but has no edit features due to my time constraints. If I were working in the magic future where Perl and Ruby are bytecode compatible, perhaps I would have just interfaced with the Ruby library directly instead of having to reinvent it, saving a couple of days of coding and debugging. [1] http://inlet-media.de/flvtool2 [2] http://search.cpan.org/dist/FLV-Info/ Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Relationship between pugs and parrot/language/perl6
On May 29, 2006, at 6:34 PM, Audrey Tang wrote: Personally, I think a canonical acceptance test suite is more important than a canonical implementation, but if the Parrot/Perl6 official-perl6 plan works out, that's wonderful too. :-) That's so cool. :-) This positive attitude toward testing is what has kept me so excited about the Perl community over the last few years, even after the initial love for the language wore off. So instead of "Only Perl can parse Perl" we get "Only Perl regression tests can specify Perl". I can be happy with that. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Continuous testing tools
On Jun 8, 2006, at 10:39 AM, Tels wrote: On my todo (well, wish list) is still a project that works rouhgly like a server/client model. You upload a snapshot to the server, it notifies the clients, they download the package, run the tests and report the result back. Reports are viewed on the server. Is there any interest in such a package? Best wishes, Tels That sounds very similar to Adam Kennedy's PITA project. Yes, there is great interest! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Mutil Method Questions
Hi All, At the risk of sounding a bit thick, I have a couple of questions about Perl6's multi keyword and mutilmethod in general. This seems like overloaded functions from C++ so why do we need a key word to declare them rather than using something like C++'s name mangling? Is there something that I am just missing here? From the wikipedia article (http://en.wikipedia.org/wiki/Multimethods), it seems that this is a way to write generic (or lambda (I think, please correct me if I am wrong)) functions. If that is the case, can we now write generic/overloaded functions in Perl6 without OO or have I conflated OO with overloading incorrectly? Thanks, Chris
Re: Mutil Method Questions
Hi All, I would like to thank everyone for their illuminating examples and prose. This has cleared up understanding for me. Thanks again, Chris On 6/23/06, Markus Laire <[EMAIL PROTECTED]> wrote: On 6/23/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: > An alternate interpretation would be that the last one is actually a compile- > time error because none of the sigs match (Int,Int) and for a call to > work with 2 Int parameters, you'd need to be explicit: > > talk(~123,3); > > But I'm not sure which way perl6 actually leans. > > Though it seems to me that automatic type conversion by the compiler is > a way to get yourself in trouble. Not that perl shouldn't let the > programmer get himself in trouble, but this seems like one of those > things that should require asking to turn on rather than asking to > turn off. Synopsis 12 at http://dev.perl.org/perl6/doc/design/syn/S12.html says When you call a subroutine with a particular short name, if there are multiple visible long names, they are all considered candidates. They are sorted into an order according to how close the actual types of the arguments match up with the declared types of the parameters of each candidate. The best candidate is called, unless there's a tie, in which case the tied candidates are redispatched using any additional tiebreaker long names (see below). IMHO that seems to mean that in my example the (String, Int) version would be called because it's "the best candidate". And that would also mean that first Int is automatically converted to String. -- Markus Laire
Re: TAP Grammar
On Jul 3, 2006, at 6:33 PM, chromatic wrote: On Monday 03 July 2006 09:01, Jonathan T. Rockway wrote: That said, I would be interested. I'm still trying to page all the perl6/parrot grammars (PGE, TGE, etc.) into my brain, so any additional examples would helpful, interesting, and fun. For me, anyway :) Jerry Gay just wrote a PGE TAP grammar: <http://svn.perl.org/parrot/trunk/examples/pge/grammars/TAP.pg> -- c I hacked a rudimentary test case for that grammar, borrowing heavily from Punie: https://svn.clotho.com/public/parrot-experiments/TAP/ To run it, edit the first line of the Makefile to specify the path to PARROT_DIR and run "make". My tests found a few bugs in Jerry's grammar. My fixed version of that grammar is here: https://svn.clotho.com/public/parrot-experiments/TAP/grammars/TAP.pg Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Old and broken versions of Module::Install
On Jul 6, 2006, at 9:18 AM, A. Pagaltzis wrote: * Steffen Mueller <[EMAIL PROTECTED]> [2006-07-06 15:20]: What does Module::Build count as? ;) I use M::B with `create_makefile_pl => 'traditional'`. What does that count as? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> IMHO it likely counts as a CPANTS pass for now, but it may be a fail in the future unless you update the Makefile.PL with a newer M::B as bugs are discovered. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Old and broken versions of Module::Install
On Jul 6, 2006, at 8:10 AM, Steffen Mueller wrote: David Golden schrieb: What about adding NO_BROKEN_INSTALLER as a Kwalitee point for CPANTS? Maybe tongue-in-cheek, but it's actually a good idea. Module::Install pre-0.61 is certainly "broken". What does Module::Build count as? ;) Steffen I agree, this is a really good idea. I would call it "UP_TO_DATE_INSTALLER". For the present, it could simply test for old Module::Install. In the future, it could be expanded to look for compatibility problems in Build.PL or Makefile.PL (e.g. a Makefile.PL using out-of-date Module::Build::Compat boilerplate). If the CPANTS "game" gets any M::I-using authors to upgrade, then it has served its purpose. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Cage Cleaning for dummies? Re: Call for Parrot Janitors
On Jul 5, 2006, at 11:10 PM, chromatic wrote: * Is a FQDN with RDNS required for access or posting of bugs? I believe you can post through the web interface. Not as of yesterday. RT appears broken and searches return no bugs... The official bug submission recommendations are listed here: http://bugs6.perl.org/ Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Old and broken versions of Module::Install
On Jul 6, 2006, at 10:18 AM, A. Pagaltzis wrote: * Chris Dolan <[EMAIL PROTECTED]> [2006-07-06 16:30]: IMHO it likely counts as a CPANTS pass for now, but it may be a fail in the future unless you update the Makefile.PL with a newer M::B as bugs are discovered. To make sure we’re on the same page: that would be bugs in M::B::Compat, not M::B itself, right? If that isn’t accepted, then I will revert to EU::MM (with apologies to Schwern) until you all figure out the damn installers among yourselves. Yes indeed, that's what I meant. I'm not saying there are M::B::Compat bugs, just *if* any were discovered someday, they could be flagged by CPANTS. Anywhere you have boilerplate code, you have the possibility of bugs that need to be fixed via the good intentions of authors deploying that boilerplate. M::B- and EU::MM-using authors generally create minimal boilerplate and thus have a central point of upgrade. M::B::Compat is the only exception I could think of, so it became my example in my effort *not* to incite an M::I vs. M::B flamefest. Apologies for any confusion. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #39743] [PATCH] change perl6-internals to parrot-porters in docs
Oops, I missed a couple of instances of perl6-internals in the previous patch (notably, in parrotbug). This updated patch obsoletes the previous one. % diffstat parrot-porters2.patch README |4 ++-- README.win32.pod |2 +- RELEASE_INSTRUCTIONS |8 compilers/imcc/README|2 +- docs/debug.pod |2 +- docs/dev/dod.pod |6 +++--- docs/faq.pod |6 +++--- docs/gettingstarted.pod | 15 --- docs/glossary.pod|2 +- docs/intro.pod |8 docs/parrot.pod |2 +- docs/pdds/pdd00_pdd.pod |4 ++-- docs/submissions.pod |4 ++-- editor/pir-mode.el |4 ++-- languages/regex/README |4 ++-- languages/tcl/README.pod |2 +- parrotbug|2 +- src/exceptions.c |2 +- 18 files changed, 40 insertions(+), 39 deletions(-) parrot-porters2.patch Description: Binary data
Re: [Slightly OT] Understanding Software Licences [was Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]]
On Jul 7, 2006, at 8:13 AM, Shlomi Fish wrote: This kind of attitude was also said by another responder to this mailing list. It's sort of a "small headed" (see http://www.joelonsoftware.com/items/2004/12/06.html ) "I just want to write code and am not interested in any legal details" attitude. May I suggest a compromise? As the author of the MIT-licensed code in Test::Run, Shlomi has the option of releasing the code under any license he prefers. Shlomi can releases *two* versions of Test::Run with every update -- a mixed license version and an Artistic/GPL version. With that solution, Shlomi himself shoulders the burden of resolving license compatibility and tracking which line of code is under which license. I do believe that the quest for license simplicity in the Perl core is not "small headed" or rooted in ignorance, but is instead inspired. While many developers or TPF itself could easily delve deep enough to decide whether MIT/BSD licensed code in the core is a threat, I think that would be a wasted effort. The increased complexity of licensing (whether real or perceived) could easily turn off third parties with less dedication to Perl, thereby decreasing the attractiveness of the language. After all, software engineering is largely about reducing the exposed complexity of a project. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Java Script in Parrot
On Jul 10, 2006, at 4:31 PM, Vishal Soni wrote:
This is is a good starting point. I have been writing the
JavaScript grammar
in PGE fromECMA-262 spec. They lay out the operator precedence
using Grammar
rules. Instead of using rules for operator precedence I would like
to use
your optok approach. Is there some help I can get? I did look at
your YAPC
2006 presentation. Are there any code examples?
Take a look at parrot/languages/punie/lib/{punie.pg,PunieGrammar.pir}
which has both bottom up and top down parsing. I found it very
educational.
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #39809] PGE crash on parrot;PGE::Exp::Quant;reduce
On Jul 12, 2006, at 10:53 PM, Patrick R. Michaud wrote:
On Wed, Jul 12, 2006 at 08:04:01PM -0700, Chris Dolan wrote:
As simple token containing ":i" causes PGE to crash with an attempted
method call on Undef.
Steps to reproduce:
1) Create a grammar file called "foo.pg" that has one line:
token foo { :i a }
As I read S05, a modifier has to occur at the *very* beginning
of a regex (or group) in order to work. In other words, no whitespace
before modifiers in a regex (because whitespace may have some
other meta-syntactic meaning with :sigspace). Thus
token foo {:i a }
works, while
token foo { :i a }
is an error, since the ':' acts as a cut operator that doesn't
have anything to cut.
But I admit that since we've gone to regex/token/rule, then perhaps
leading whitespace prior to a modifier should be ignored. That
probably needs a ruling from p6l or @Larry.
Pm
Ahh, that makes sense. So it's possibly just an uncaught syntax
error, and definitely a syntax error under :sigspace. I propose that
P6Regex.pir gets something like:
parse_error(mob, pos, "Too late for modifier")
but I have not yet figured out where it belongs in P6Regex.pir.
On a related note, I don't see any regression tests for syntactically
incorrect regexps. I'm good at writing invalid regexps :-) so if
someone starts a stub .t file for syntax errors, I'd be happy to
populate it with TODO tests like the above.
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #39829] [PATCH] accept() always fails
On Jul 14, 2006, at 4:56 AM, Leopold Toetsch wrote: Am Donnerstag, 13. Juli 2006 23:41 schrieb Kay-Uwe Huell: Hi parrot, unfortunatly you fail when I call your accept() op. I have fixed this issue with attached patch. The Parrot documentation can now be accessed at http:// localhost:1234 . accept: errno=22unknown method:'' I don't get that error and I can't see, why changing the (not-reached) diagnostic might fix accept. The httpd.pir has different problems, though, which seem to be protocol-related. leo Kiwi, I also don't experience this error but instead for me httpd.pir fails at bind() [see RT #39738] on Darwin and FreeBSD. On which platform does accept() fail for you? Which C compiler are you using? I agree with Leo that your patch looks suspicious. If you are right that just adding that diagnostic really does fix it, then it sounds like a compiler bug that needs to be reported, or at least documented. Chris P.S. I've been working on some small improvements to httpd.pir, including better failure diagnostics. Please contact me off-list for a patch if you are interested. -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: Time for a Revolution
On Jul 14, 2006, at 8:03 PM, chromatic wrote: On Friday 14 July 2006 17:59, Andrew Savige wrote: I thought Chromatic might be the name of chromatic's father or older brother. No, that's Mixolydian and Ionian, respectively. -- c (Yes, of course my mother is Dorian. What were you thinking?) Whoa, this is becoming an unexpectedly educational thread... Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
ICU advantages? was Re: Problems Installing Parrot
On Jul 21, 2006, at 9:48 AM, Jonathan Rockway wrote: I have downloaded the icu4j_3_4_4.jar but have no idea what to do with it. Could someone please help? You'll want to get icu4c (icu for C), not icu4j (for java). If you get the tgz C version, just tar xzvf it, cd source; ./configure; make; make install. Note that most Linux distros have packages for icu. apt-get install libicu.* will get everything you need on Debian. (On other distros, be sure to install the -dev or -devel pacakages). Anyway, here's where I got it from: ftp://ftp.software.ibm.com/software/globalization/icu/3.4.1/ icu-3.4.1.tgz On a related note, I understand that ICU is recommended but not required for Parrot (right?). After searching in the Parrot docs subdir a couple weeks ago, I couldn't find more than that. Questions: 1) Is there documentation on how ICU relates to Parrot somewhere that I missed? 2) How important is ICU? 3) If I build Parrot without ICU, what repercussions should I expect? This would be a good entry for the FAQs for a cage cleaner. Thanks, Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: FAQ Questions (WAS: ICU advantages? was Re: Problems Installing Parrot)
On Jul 21, 2006, at 1:12 PM, Mr. Shawn H. Corey wrote: Chris Dolan wrote: This would be a good entry for the FAQs for a cage cleaner. If you're collect questions for the FAQ, here are some Andy Lester answered for me: I'm not, actually. :-( Could you do one of the following, in order of preference: 1) Write these up as a patch to the FAQ 2) Write these up as a patch for cage/TODO.pod 3) Submit an RT bug to add these to the FAQ Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Questions
On Aug 1, 2006, at 2:45 PM, Joshua Hoblitt wrote:
While I'd been hoping that M::B had a public method for changing
'blib'
this appears not to be the case (just looking at the pod). If this
functionality were added we could have the root makefile invoke each
module as `perl Build.PL --blib [buildroot/somedir]`, use that path
for
runtime testing, and still let M::B handle the packages own
installation. I admit this scheme is a little hackish but it avoids
having to do a custom setup for each bundled package. Thoughts?
That syntax works:
% perl Build.PL --blib=foobar
Checking whether your kit is complete...
Looks good
Checking prerequisites...
Looks good
Creating new 'Build' script for 'FLV-Info' version '0.11'
% ./Build
lib/FLV/File.pm -> foobar/lib/FLV/File.pm
...
% perl -MModule::Build -le'print Module::Build->VERSION'
0.2801
This also works:
my $mb = Module::Build->new(
...
);
$mb->blib('foobar');
$mb->create_build_script;
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: Perl6 "style-guide"
On Sep 20, 2006, at 6:16 PM, Darren Duncan wrote: At 4:56 PM +0200 9/20/06, Fagyal Csongor wrote: I was wondering if there is (or there should be) a documentation on how to elegantly write Perl6 code. I have found that Damian's "Perl Best Practices" still works very well for Perl 6 code, so I still apply that where reasonably possible. And in fact, I expect that PBP was written to be forward compatible to Perl 6, as it could describe styles that should be natural in Perl 6, even if less so in Perl 5. Does anyone want to start a port of Perl::Critic to Perl6? :-) Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [CAGE] perl coding standards...
On Sep 26, 2006, at 10:21 PM, Will Coleda wrote: I took a first pass at a perlcritic test: t/codingstd/ perlcritic.t ; this test isn't run by default. [snip] Cool! Attached is a patch to simplify this test code a little bit by leveraging Test::Perl::Critic. I also reworked CodeLayout::UseParrotCoda to use current P::C conventions. lib/Perl/Critic/Policy/CodeLayout/UseParrotCoda.pm | 41 +++-- t/codingstd/perlcritic.t | 88 +++ +- 2 files changed, 51 insertions(+), 78 deletions(-) Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf perlcritic.patch Description: Binary data
Re: Emacs/vim code coda placement
On Oct 3, 2006, at 1:29 AM, Paul Cochrane wrote: Hi all, In the process of trying to finish off the perl coda cage task, I notice that the Perl::Critic policy for the emacs/vim coda skips __END__ and __DATA__ sections at the end of perl files, however vim (I don't know about emacs) requires the coda to be within either the first or last 5 lines of the file (by default) for which the editor settings are to be applied, and so if one has a large __END__ or __DATA__ section (not exactly difficult) the coda will be missed by vim. A lot of the time __END__ sections are used for pod, so there is an easy fix for these situations such that the coda can be added without affecting perldoc output namely: put a C<=cut> at the end of the pod, before the coda. However, this doesn't work in all situations, and I believe the coda will add itself to the data in the __DATA__ block, am I correct? In short, the coda needs to be at the end of each of the files, however, not to be included in any present __END__ or __DATA__ blocks; how do we get around this in nice, general way? Thanks heaps in advance, Paul Paul, Good point, I meant to bring this up myself when I was fiddling with lib/Perl/Critic/Policy/CodeLayout/UseParrotCoda.pm I agree that using =cut in __END__ is the right solution. I have no idea how to handle __DATA__ since you can't put an __END__ embedded in a __DATA__ section. If Will Coleda (or someone else) approves the coda-after-__END__ spec change, I'll be happy to code that up in CodeLayout::UseParrotCoda. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
On Oct 9, 2006, at 4:51 AM, Paul Cochrane (via RT) wrote:
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40482]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40482 >
Hi,
This patch adds a new policy for the Parrot Perl::Critic tests, namely
to check that the shebang line doesn't use 'perl -w', rather 'use
warnings;' and that the shebang line doesn't use something unix
specific such as '#!/usr/bin/perl' and rather '#! perl'. Would it be
a good idea to group all of the code standards-related stuff into a
directory CodeStandards? As such, should I then make a patch for
CodeLayout::UseParrotCoda to go under CodeStandards::UseParrotCoda
instead? I'm also wondering what the policy is on svn Id keywords in
files, and whether or not the svn:keywords property is set to a
particular value. I don't think there's a standard or anything
defined for this yet. Should there be? If so, should I put a request
into RT?
Paul,
A few comments:
* No, this shouldn't go into UseParrotCoda. Separately enabled
policies are more flexible.
* In fact, yours should probably be broken into two policies. Perhaps
CodeStandards::ProhibitShebangWarningsArg
and
CodeStandards::RequirePortableShebang
* This would be a nice addition to core Perl::Critic!
* The -w catcher fails on "#!perl -T -w" or other variations on
argument lists. Perhaps forbid any arguments at all?
* The shebang line is always a PPI::Token::Comment and is always on
the first line. Take a look at this utility function from
Perl::Critic::Utils:
sub is_script {
my $doc = shift;
my $first_comment = $doc->find_first('PPI::Token::Comment');
return if !$first_comment;
return if $first_comment->location()->[0] != 1;
return $first_comment =~ m{ \A \#\! }mx;
}
Now that I'm talking about it, I should write a
Perl::Critic::Utils::get_shebang() function...
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
On Oct 9, 2006, at 11:50 AM, Paul Cochrane wrote: Will, They're all coding standards. I say leave the Coda where it is, and put this in the same grouping as 'use warnings' (i.e. 'TestingAndDebugging'). Ok, see attached patch. This one is still a false negative on "#!perl -Tw" and is a false positive on "package main; #!!! my co-worker provided this non-Perl- licensed code to Parrot!!!". Yes, that's a highly contrived example. :-) But the false positive would be avoidable by checking the line and column number of the element. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
On Oct 10, 2006, at 3:12 AM, Paul Cochrane wrote: * This would be a nice addition to core Perl::Critic! Do you want me to supply a patch for Perl::Critic too, or will the file added to Parrot suffice? That's completely up to you. You seem to have a knack for writing policies, so we'd love to have the help with Perl::Critic. But Parrot is a worthy cause too! :-) If you don't provide a P::C patch, I'll probably do it myself eventually. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
On Oct 10, 2006, at 11:03 AM, Paul Cochrane wrote: I've been playing around for a while with the shebang line tests, and it struck me that the is_script() function will return true on your contrived example. Yeah, I saw that and fixed it in SVN yesterday. :-) It now checks that column == 1 too. Also, the fact that you mention that the shebang should be the first line lead me to think that maybe we could look for misplaced shebang lines, and report an error there as well. I've got a patch for that and can send this in too if you want. Interesting idea. You'll have to ensure it's a PPI::Token::Comment and not a PPI::Token::Quote, for example. Perhaps further discussion should move to the perlcritic.tigris.org dev mailing list or to http://rt.cpan.org/Dist/Display.html?Queue=perl-critic Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [perl #40564] [TODO] fix perlcritic Subroutines::RequireFinalReturn policy
On Oct 18, 2006, at 4:27 PM, Jerry Gay (via RT) wrote: currently, this policy does not ignore subs which exit or die... it forces the addition of a return statement in these subs. yuck. this policy will be disabled until this is fixed. ~jerry Fixed in Perl::Critic svn r737. This will appear in the next release of Perl::Critic. Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
