Re: TAP::Harness

[Michael G Schwern]

On 7/1/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:

As my flight is delayed I'll try to make a stab at posting up the basic design.


The whole point of replacing the Perl QA wiki was to have a public
place for the TAP::Harness design to live. :)

http://perl-qa.yi.org/index.php/TAP::Harness

The sources and runners work.  I started on the parser and then
stopped when I realized it would work better with a separate lexer.
The responsibilities of the parser vs the aggregator are still a bit
fuzzy as is exactly what goes into an event.  But hopefully there's
enough there to give a clearish idea of where I'm headed, what its
potentially capable of and to warn me alway from any horrible design
mistakes.

Re: Proposal Suggestion - Test::Run

[Shlomi Fish n]

On Thursday 06 July 2006 00:36, Jonathan T. Rockway wrote:
> Two comments, pretty much agreeing with chromatic and Ricardo:
>
> 1)  How would this proposed module benefit the perl community? Why 
> can't you fix things in Test::Harness and send the patch in?  If you fix
> deployed modules, everyone wins.  If you write your own module, it sits
> on CPAN unused.
>
> What exactly is wrong with Test::Harness, anyway?  The development team
> is pretty agreeable, the code is good, the module works, etc.  Is there
> some large problem I'm missing?  (A problem so large that TPF needs to
> *pay* someone to fix it!?)
>

I've answered some of these things in the following links:

http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/
http://use.perl.org/~Shlomi+Fish/journal/27467
http://use.perl.org/~Shlomi+Fish/journal/27887

Also see my other replies to this thread:

http://www.mail-archive.com/perl-qa%40perl.org/msg05987.html

And also the resource that Schwern pointed to:

http://www.mail-archive.com/perl-qa%40perl.org/msg06014.html

> 2) If you use GPL'd code in an MIT-licensed app, the entire app becomes
> GPL.  I don't think you can say, "this requires xyz GPL'd code, but if
> it didn't it would be MIT".  It's GPL by virtue of requiring GPL code.
> (Hence the accusation that the GPL is 'viral' or whatever.)  IANAL, but
> this is my understanding from reading the license, the FSF's site, etc.
> If the code isn't derived, though, feel free to MIT license it.  

There is a difference between derived code and inclusive code. The code that 
originated from other people's code was kept under the same licence 
(GPL+Artistic in this case). I also disclaimed any explicit ownership of it. 

OTOH, the code that was written from scratch and was my original code was 
licensed under the X11 licence, because it did not include anything else.

> (The 
> fact of the matter, though, is that Perl uses the Perl license.  I don't
> really love the Artistic license, but I release my perl code under the
> dual license because Everyone Else Does.  

I don't like doing everything only because everyone else does them. I like to 
think for myself what is the best course of action and long time strategy. 

> It makes everything work 
> nicely and builds community too  :)
>

I don't see using the X11 licence for my software as anti-social. Like I said, 
anyone can easily fork it as a software of a different licence. It's also 
more permissive than the GPL+Artistic licence (and much less problematic than 
the Artistic 1.0 licence, which some people don't even consider as 
free-as-in-speech.)

So far I've released all the software (Perl or otherwise) for which I had a 
choice under the Public Domain or X11 licence.

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.

Re: Test::Builder feature request...

[Michael G Schwern]

On 2/9/06, Geoffrey Young <[EMAIL PROTECTED]> wrote:

> This works:

yes, excellent randy.  thanks for that.  it still seems a little hackish but
that's ok - hackish works for me if it means I can do what I want and nobody
else needs to do extra work :)

I made some tweaks to your format and added a few minor notes here

  http://people.apache.org/~geoff/test-more-separately.tar.gz


A less hackish version of plan.t is...

 use Test::More;
 my $TB = Test::More->builder;
 $TB->no_ending(1);

 plan tests => 3;

 print qx!perl t/response.pl!;

Re: CPAN and META.yml: no_index dir vs directory

[Johan Vromans]

> > no_index/dir 13
> > no_index/directory 1397
> > private/directory40

> As for "dir", I'm three of the 13, 

I'm another three of the 13, and I'll switch to 'directory' as of the
next upload.

-- Johan

Re: Cage Cleaning for dummies? Re: Call for Parrot Janitors

[Nicholas Clark]

On Wed, Jul 05, 2006 at 09:10:47PM -0700, chromatic wrote:
> On Wednesday 05 July 2006 19:58, Bill Ricker wrote:

> > * Minimum GCC == whatever Perl5 was built with? or specific?
> 
> Probably at least 2.9x.

Why? IIRC gcc 2.7 was good and stable, and it's not like C89 has changed much
in the past 10 years. I guess it's really down to whether the C compiler
(gcc or otherwise) has awkward bugs on your platform.

> > (Alas, I do _not_ have the Tru64/DEC compiler for Alpha AXP on my
> > Debian/Alpha. There's someone I can talk to, I might be able to get
> > it, or get access to it. Hmm.)
> 
> Alpha would be very good.

Any vendor compiler is very good at picking up sloppy C code. As well as
Tru64, anyone with Irix, AIX, HP-UX, particularly if 64 bit, would be most
welcome.

Anyone got a Cray? sizeof(short) being 8 is always fun for surprising
unwary source code. And something (Amdahl mainframes?) aren't 2's complement.

Nicholas Clark

[svn:perl6-synopsis] r9815 - doc/trunk/design/syn

[audreyt]

Author: audreyt
Date: Wed Jul  5 22:28:06 2006
New Revision: 9815

Modified:
   doc/trunk/design/syn/S11.pod

Log:
* S11: TimToady++ changes this:

use v6-**;  # this caused warnings in perl5

  to this:

use v6-alpha;

  which has the good effect of denoting this is _not_ Perl 6.0.0
  and the syntax is subject to change.


Modified: doc/trunk/design/syn/S11.pod
==
--- doc/trunk/design/syn/S11.pod(original)
+++ doc/trunk/design/syn/S11.podWed Jul  5 22:28:06 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 27 Oct 2004
-  Last Modified: 4 Jul 2006
+  Last Modified: 6 Jul 2006
   Number: 11
-  Version: 13
+  Version: 14
 
 =head1 Overview
 
@@ -265,17 +265,19 @@
 
 to guarantee that you get the unembraced Perl.  C<:-)>
 
-Perl is the default module name, so
+Perl is the default module name, so this means the same thing:
 
 use v6-cpan:TPF;
 
-means the same thing.  As a variant of that, the current Perl 5
-incantation to switch to Perl 6 parsing is
-
-use v6-**;
-
-(though in Perl 5 this actually ends up calling the v6.pm module with a
-C<-**> argument for insane-but-useful reasons.)
+Before the full specification of Perl 6.0.0 is released, you can use C
+as the author slot to denote a program using syntax that is still subject
+to change:
+
+use v6-alpha;
+
+The C line also serves as the Perl 5 incantation to switch to
+Perl 6 parsing.  In Perl 5 this actually ends up calling the v6.pm module with 
a
+C<-alpha> argument, for insane-but-useful reasons.
 
 For wildcards any valid smartmatch selector works:
 

Re: CPAN and META.yml: no_index dir vs directory

[David Golden]

Andreas J. Koenig wrote:

The page is there, http://thepierianspring.org/perl/meta/, but does
not provide direct statistics so I made up my own.

no_index/dir 13
no_index/directory 1397
private/directory40

David's D/DA/DAGOLDEN/Perl-Dist-Vanilla-5 used both dir and directory:)

Those who used just "dir" were ignored up to now:

 B/BL/BLM/Win32API-Registry-0.27
 B/BW/BWARFIELD/NRGN/Test-AutoLoader-0.03
 D/DA/DAGOLDEN/Object-LocalVars-0.15
 D/DA/DAGOLDEN/Object-LocalVars-0.16
 D/DA/DAGOLDEN/Perl-Dist-Vanilla-4
 G/GU/GUIDO/Test-Unit-GTestRunner-0.03
 G/GU/GUIDO/Test-Unit-GTestRunner-0.04
 J/JV/JV/EekBoek-0.91
 J/JV/JV/EekBoek-0.60
 J/JV/JV/EekBoek-0.61
 R/RC/RCAPUTO/POE-0.3502
 R/RC/RCAPUTO/POE-Component-Client-Keepalive-0.0801


Well, I think that suggests pretty definitively that "directory" needs 
to be added to the spec, at least, to reflect de facto usage.


As for "dir", I'm three of the 13, so discount those.  I'm not sure 
that's worth adding to CPAN.  Maybe it calls for dropping "dir" from the 
spec unless anyone else knows who's using it.


Regards,
David

[perl #39732] [TODO] Tcl - Add namespace support for variables

[via RT]

# New Ticket Created by  Matt Diephouse 
# Please include the string:  [perl #39732]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39732 >


Variables like $foo::bar don't work currently. These should take  
advantage of the new namespace support. Tests are needed in addition  
to an implementation. Tests should also test that [namespace delete]  
deletes any variables in a namespace.

--
Matt Diephouse

Re: Perl 6 compiler docs released - graffle questions, compiler questions

[Audrey Tang]

在 2006/7/5 上午 1:26 時，George Wood 寫到：


Here are some probably for Audrey...
1. Page on  Perl 6 on Haskell - Is runtime Specific AST actually  
the file Language.TH.Sytnax?


Well, no, it's probably best to call it Pugs.AST, and link to src/ 
Pugs/AST.hs.



2. I am still trying to distinguish these
Perl 6 on Perl 6
Perl 6 on Parrot
Do they both emit pmc files?


Perl 6 on Parrot will emit .pir files.

Perl 6 on Perl 6 will emit .p6 files, but currently no such  
implementations exist, as it's still a few milestones away from now. :-)


Thanks!
Audrey



PGP.sig
Description: This is a digitally signed message part

Re: CPAN and META.yml: no_index dir vs directory

[Andreas J. Koenig]

> On Wed, 5 Jul 2006 21:39:06 -0500, Ken Williams <[EMAIL PROTECTED]> said:

  > On Jul 5, 2006, at 7:47 PM, David Golden wrote:

 >> Some potential options:
 >> 
 >> (a) Add "directory" as a synonym to the spec and add "dir" as
 >> something that CPAN sites recognize.
 >> 
 >> (b) Change the spec to "directory" -- if CPAN sites are the only
 >> real user of META.yml no_index, then the pain should be minimal.
 >> 
 >> (c) Change CPAN sites to follow the spec, despite breaking many
 >> distributions' current indexing.


  > Randy Sims keeps some statistics on the META.yml files that exist on
  > CPAN, perhaps he could tell us the relative frequencies of 'dir' vs.
  > 'directory' in the wild?

The page is there, http://thepierianspring.org/perl/meta/, but does
not provide direct statistics so I made up my own.

no_index/dir 13
no_index/directory 1397
private/directory40

David's D/DA/DAGOLDEN/Perl-Dist-Vanilla-5 used both dir and directory:)

Those who used just "dir" were ignored up to now:

 B/BL/BLM/Win32API-Registry-0.27
 B/BW/BWARFIELD/NRGN/Test-AutoLoader-0.03
 D/DA/DAGOLDEN/Object-LocalVars-0.15
 D/DA/DAGOLDEN/Object-LocalVars-0.16
 D/DA/DAGOLDEN/Perl-Dist-Vanilla-4
 G/GU/GUIDO/Test-Unit-GTestRunner-0.03
 G/GU/GUIDO/Test-Unit-GTestRunner-0.04
 J/JV/JV/EekBoek-0.91
 J/JV/JV/EekBoek-0.60
 J/JV/JV/EekBoek-0.61
 R/RC/RCAPUTO/POE-0.3502
 R/RC/RCAPUTO/POE-Component-Client-Keepalive-0.0801

-- 
andreas

v6.pm now runs Test.pm!

[Audrey Tang]

(Cross-posted from http://pugs.blogs.com/pugs/2006/07/ 
v6pm_now_runs_t.html)


Due to clkao++ and fglock++'s work, the CPAN version of v6.pm now  
passes all Pugs sanity tests, up and including the Perl 6 Test.pm:


# http://search.cpan.org/dist/v6-pugs/
# http://search.cpan.org/dist/v6-pugs/t/

That makes it the second implementation (after Pugs) and the fourth  
runtime (after Pugs's Haskell/JavaScript/PIR backends) that has  
access to the 11,000+ subtests in the test suite. Once the Parrot/ 
Perl6 implementation support for subroutines, arrays, hashes and use  
statements, it will join as the third implementation that can run the  
test suite.


Development of v6.pm, the new AST, a concrete definition of multiple  
dispatch, etc. continues apace in #perl6; we are seeing nearly more  
than 50 commits per day in the past few days. (gaal++ describes it's  
just like the good old days of early Pugs development, but it's  
actually faster. now :-)) For example, v6.pm can now parse regex/ 
token/rule declarations natively.


I'm very excited about this new cleanly-partitioned task space of  
Perl 6 implementation:


(Non-Perl 5 Specific)

* Descriptions of semantics in the test space;
* Analytical summaries and stories in the spec space;
* Algorithmic expression of effects and structures in the new  
AST space;


(Perl 5 Specific)

* Implementation APIs to embed them as Perl 5 modules;
* Idiomatic, pure-perl5 sugar that makes Perl 6 semantics  
accessible;
* Translation from Perl 6 surface syntax into those new perl 5  
idioms;


And the best thing is that, instead of a cyclic dependency as we had  
before, each layer are independent from the ones after it. It means  
that CPAN people can use Class::MOP and Data::Bind to improve their  
own frameworks; or to use the new idioms enabled by Moose.pm et all;  
all without necessarily switching to the Perl 6 surface syntax. And  
it also makes v6.pm's output idiomatic -- we just need to  
incrementally build a new Perl 5 idiom, which, as Bjorn Freeman- 
Benson noted, is a Very Good Thing.




PGP.sig
Description: This is a digitally signed message part

Re: Cage Cleaning for dummies? Re: Call for Parrot Janitors

[chromatic]

On Wednesday 05 July 2006 19:58, Bill Ricker wrote:

> * How many free GB should I expect to need on my filesystem(s) to copy
> and build?

My source tree is 70 Mb with Svk, so 150 - 250 Mb should suffice.

> * Is there a minimum version  of SVN required to access this repository?

At least 1.0, I expect.

> * Is a FQDN with RDNS required for access or posting of bugs?

I believe you can post through the web interface.

> * Minimum GCC == whatever Perl5 was built with? or specific?

Probably at least 2.9x.

> * Is > parrot/cage/todo.pod in the source tree or elsewhere?

It's in the tree.

> * Is  building on Debian 3.0 ("Woody") of any use or practicality?

Sure, why not?  Alternate arches would be good too.

> (Alas, I do _not_ have the Tru64/DEC compiler for Alpha AXP on my
> Debian/Alpha. There's someone I can talk to, I might be able to get
> it, or get access to it. Hmm.)

Alpha would be very good.

-- c

Cage Cleaning for dummies? Re: Call for Parrot Janitors

[Bill Ricker]

For those of us drawn in by the postings elsewhere, not long-time
denizens of either P6 or Porters lists, a pointer to the basic HOWTO
for setting up a build-and-smoke environment that's a bit longer than
   >>> svn co https://svn.perl.org/parrot/trunk parrot
would be useful.

E.g.,
* How many free GB should I expect to need on my filesystem(s) to copy
and build?
* Is there a minimum version  of SVN required to access this repository?
* Is a FQDN with RDNS required for access or posting of bugs?
* Minimum GCC == whatever Perl5 was built with? or specific?
* Is > parrot/cage/todo.pod in the source tree or elsewhere?
* Is  building on Debian 3.0 ("Woody") of any use or practicality?

(Alas, I do _not_ have the Tru64/DEC compiler for Alpha AXP on my
Debian/Alpha. There's someone I can talk to, I might be able to get
it, or get access to it. Hmm.)

--
Bill
[EMAIL PROTECTED] [EMAIL PROTECTED]

Re: CPAN and META.yml: no_index dir vs directory

[Ken Williams]

On Jul 5, 2006, at 7:47 PM, David Golden wrote:


Some potential options:

(a) Add "directory" as a synonym to the spec and add "dir" as  
something that CPAN sites recognize.


(b) Change the spec to "directory" -- if CPAN sites are the only  
real user of META.yml no_index, then the pain should be minimal.


(c) Change CPAN sites to follow the spec, despite breaking many  
distributions' current indexing.



Randy Sims keeps some statistics on the META.yml files that exist on  
CPAN, perhaps he could tell us the relative frequencies of 'dir' vs.  
'directory' in the wild?


 -Ken

Re: Proposal Suggestion - Test::Run

[Michael G Schwern]

On 7/5/06, Jonathan T. Rockway <[EMAIL PROTECTED]> wrote:

1)  How would this proposed module benefit the perl community?  Why
can't you fix things in Test::Harness and send the patch in?  If you fix
deployed modules, everyone wins.  If you write your own module, it sits
on CPAN unused.

What exactly is wrong with Test::Harness, anyway?


At least this much I can answer.
http://perl-qa.yi.org/index.php/Test::Harness

IMHO multiple, competing TAP parsers is healthy.  Whether or not TPF
should pay for it is another thing entirely.

Re: a smarter form of whitespace

[Patrick R. Michaud]

On Tue, Jul 04, 2006 at 12:57:16PM -0700, Allison Randal wrote:
> --
> 
> token start { ^*$ }
> 
> regex emptyline { ^^ $$ \n }
> 
> token ws { [ | \t]* }
> 
> --

The above grammar doesn't have a "grammar" statement; as a result
the regexes are being installed into the '' namespace.

> If I match this against a string of 7 newlines, it returns 7 
> matches, and each match is a single newline. This is the behavior I want
> for newlines.

I tried it with a grammar statement and it seems to work:



$ cat ar.pg
grammar XYZ;

token start { ^*$ }

rule emptyline { ^^ $$ \n }

token ws { [ | \t]* }

$ ./parrot compilers/pge/pgc.pir ar.pg >ar.pir
$ cat xyz.pir
.sub main :main
load_bytecode 'PGE.pbc'
load_bytecode 'ar.pir'
load_bytecode 'dumper.pbc'
load_bytecode 'PGE/Dumper.pbc'

$P0 = find_global 'XYZ', 'start'
$P1 = $P0("\n\n\n\n\n\n\n", 'grammar' => 'XYZ')

'_dumper'($P1)
.end
$ ./parrot xyz.pir
"VAR1" => PMC 'XYZ' => "\n\n\n\n\n\n\n" @ 0 {
 => ResizablePMCArray (size:7) [
PMC 'XYZ' => "\n" @ 0,
PMC 'XYZ' => "\n" @ 1,
PMC 'XYZ' => "\n" @ 2,
PMC 'XYZ' => "\n" @ 3,
PMC 'XYZ' => "\n" @ 4,
PMC 'XYZ' => "\n" @ 5,
PMC 'XYZ' => "\n" @ 6
]
}
$ 

-

Pm

Re: The new wiki

[Tyler MacDonald]

Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Thanks to Tyler MacDonald and yi.org we now have a brand spanking new
> wiki!  http://perl-qa.yi.org/ is its location, we'll worry about
> getting more official domains later.

Since I set up my own server for (then nx, now yi).org 8 years ago
and started doing the dynamic DNS thing, my hope was to be able to give
something back to the hackers in the open source community that have already
given me more than a lifetime's worth of value. Perl/CPAN in particular has
made my life both more enjoyable and profitable. I'm glad that the server is
fulfilling it's use; thanks to you guys for doing what you're doing! :)

- Tyler

HLL root globals and empty keys (was Re: test of get_namespace opcode)

[Chip Salzenberg]

On Sat, Jul 01, 2006 at 03:04:05PM -0700, Matt Diephouse wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> >   .namespace   # no key
> >means the HLL root.
> 
> That resolves the other ticket I opened yesterday (good). But I'd
> prefer to have C< .namespace [] > so that we could also have the
> matching C< find_global [], 'foo' >.  Otherwise find_global becomes a
> two step operation for finding globals in the root HLL namespace.

Well, that's a bit problematic.  The [] syntax is inherited from the key
syntax, and keys currently can't be empty.  The use of keys is a hack, but
it's a very convenient hack at the source code level, and unlikely to
change.

  --- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --

On the other hand, we could extend the key PMC to represent emptiness,
i.e. zero dimensions.  This seems useful for namespaces and could even prove
useful for real keys.  And this makes keys even more compatible with the
Array interface, which I think they might need to implement someday anyway.

Allison, what do you think of zero-length keys, i.e. having [] construct a
Key PMC describing no dimensions of lookup?  If we use those we can get rid
of the current null-string hack.

If zero-length keys are not OK, then...

  --- PART 3, IN WHICH AN UGLY BUT WORKING HACK IS DESCRIBED --

I introduced a hack in my recent namespace cleanups.  I was planning to
ask/warn users about it, but then forgot I'd done it, so it's in the svn
repo now.  The hack is:

When find_global or store_global expects a string or PMC to designate (name)
a namespace, Parrot takes a null value to name the HLL root namespace.
Thus:

.sub main :main
$P0 = find_global 'Foo', 'bar'
$P0()
.end

.sub bar
.end

.namespace ['Foo']
.sub bar
$P0 = find_global 'bar'   # ['parrot';'Foo';'bar']
null $S0
$P1 = find_global $S0, 'bar'  # ['parrot';'bar']
.end

I don't recommend anyone coding anything to use this feature, because the
more I look at it the less I like it: It's still a two-step process, and
with kludge factor to boot.  Zero-length keys are better, IMO.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

The new wiki

[Michael G Schwern]

Thanks to Tyler MacDonald and yi.org we now have a brand spanking new
wiki!  http://perl-qa.yi.org/ is its location, we'll worry about
getting more official domains later.

Its a wiki.  Go nuts.  Err on the side of editing rather than doing
nothing.  Not sure if something should go on the wiki?  Put it there,
it can be deleted.

This is MediaWiki, the wiki which Wikipedia runs.  Its got some
features and differences from other wikis, so please read
http://perl-qa.yi.org/index.php/MediaWiki_Editing_Tips to learn how to
use it most effectively.

I've put together a short list of things you can do for the Wiki.
http://perl-qa.yi.org/index.php/What_can_I_do%3F

Those of you who have proposed TAP extensions, kindly scrape the
details off the mailing list, write them up on the wiki and list them
here:
http://perl-qa.yi.org/index.php/TAP_Proposals

Those writing TAP parsers, kindly write them up on the wiki and list them here:
http://perl-qa.yi.org/index.php/TAP_Parsers

Those writing TAP producers (things which can produce TAP output.  ie.
Test::Builder, libtap, Test.pm, Selenium?...), write them up on the
Wiki and list them here:
http://perl-qa.yi.org/index.php/TAP_Producers

Module Signatures [was Re: On "Gaming" CPANTS...]

[Jonathan Rockway]

> It adds a dependency on a binary application (gpg) that users have to
> install by hand, doesn't check for the presence of it properly, and if
> you don't have it, installs an enormous chain of dependencies, with said
> deps having some major issues of their own.
>
> It's become bad enough that Module::Signature is being pulled from
> Bundle::CPAN and being disabled by default in CPAN.pm, until
> Module::Signature gets a maintainer capable that can make it somewhat
> saner.

I think the solution (to dependency hell) is to dictate that CPAN
modules be signed with a standard algorithm.  OpenPGP allows too many
different algorithms, hence the 22 modules Crypt::OpenPGP is dependent
on.  The only strong reason to stick with OpenPGP is that it has the
whole web-of-trust and keyserver infrastructure.

If we can live without that, then I could write a small "cpansign"
script that just uses Crypt::DSA to sign the distribution, and then have
Module::Signature just verify that DSA signature.  There's still a
dependency issue, but 21 fewer of 'em.  DSA can be made to be portable
if it isn't already.  (RSA is fine too, then I could sign my modules
with my OpenPGP smartcard ;)

If we adopted this scheme, maybe we could just have authors upload their
keys to PAUSE (or some other "Trusted Source"), and have people that
want to verify distributions pull the keys down from there.

The disadvantage of this is that the PAUSE master could forge
distributions, as could someone performing a MITM attack on your key
download.

However, this could all happen anyway.  I have a few keys of CPAN
authors in my keyring, but I've never verified the fingerprints in real
life... so for all I know, someone could be tampering with my
distributions as we speak.  This message might not really be from Jon
Rockway :)

On a related note, I sent some patches in to the Crypt::OpenPGP author a
while ago but never heard anything back.  Is that module still being
maintained?

Regards,
Jonathan Rockway



signature.asc
Description: OpenPGP digital signature

Re: Volunteer wanted: We need a new wiki.

[David Golden]

Randy W. Sims wrote:
I don't know much about SocialText. Is there a converter, so that if you 
put something up temporarily in MediaWiki, it can later be converted and 
moved to SocialText?


I know there are a whole series of HTML::WikiConverter dialects on CPAN. 
 I haven't used it, but it seems like it has the right idea.  If there 
isn't a SocialText dialect plugin already, I'm sure someone could whip 
one up.


Regards,
David

CPAN and META.yml: no_index dir vs directory

[David Golden]

To the Illuminated Masters of CPAN and META.yml:

Apparently, my upload of Perl::Dist::Vanilla spuriously indexed 
directories that I thought I had listed as "no_index".


On examination, it appears that the META.yml spec says to use a "dir" 
entry under "no_index" whereas PAUSE/CPAN/search.cpan.org appears to 
honor "directory" (based on the META.yml I see for perl-5.8.8).  Compare 
to the spec:


http://module-build.sourceforge.net/META-spec-v1.2.html#no_index

I hereby appeal to the Powers That Be (tm) to resolve this inconsistency 
for the clarity and benefit of us all.  :-)


Some potential options:

(a) Add "directory" as a synonym to the spec and add "dir" as something 
that CPAN sites recognize.


(b) Change the spec to "directory" -- if CPAN sites are the only real 
user of META.yml no_index, then the pain should be minimal.


(c) Change CPAN sites to follow the spec, despite breaking many 
distributions' current indexing.


Of these three, I'd suggest (a) or (b).  (a) seems crufty but breaks 
nothing.  (b) is conceptually cleaner but might break a few things.  (c) 
seems like a nightmare.


Regardless, I encourage PAUSE admins to better document how CPAN uses 
no_index (as it currently points to a missing spec file, no less).


Thank you all very much,

Regards,
David Golden

[svn:parrot-pdd] r13170 - in trunk: docs/pdds include/parrot src src/ops src/pmc t/op t/pmc t/src

[chip]

Author: chip
Date: Wed Jul  5 17:31:15 2006
New Revision: 13170

Modified:
   trunk/docs/pdds/pdd21_namespaces.pod

Changes in other areas also in this revision:
Modified:
   trunk/include/parrot/global.h
   trunk/include/parrot/hll.h
   trunk/src/builtin.c
   trunk/src/global.c
   trunk/src/global_setup.c
   trunk/src/hll.c
   trunk/src/mmd.c
   trunk/src/objects.c
   trunk/src/ops/var.ops
   trunk/src/pmc/boolean.pmc
   trunk/src/pmc/default.pmc
   trunk/src/pmc/parrotinterpreter.pmc
   trunk/t/op/globals.t
   trunk/t/pmc/globals.t
   trunk/t/pmc/namespace.t
   trunk/t/src/compiler.t
   trunk/t/src/extend.t

Log:
* No longer support a namespace PMC as the second parameter to find_global
  and store_global.  These opcodes require namespaces to be designated
  (named) with a string, a key, or an array of strings.

  User code that already has a namespace PMC, should use the pdd21 namespace
  interface.

* Revamp the Parrot_{find,store}_global functions, each of which now has
  several variations for convenience in various circumstances:

   PMC *Parrot_find_namespace* - find an existing namespace PMC
   PMC *Parrot_make_namespace* - find an existing namespace PMC,
   or if not found, create it
   PMC *Parrot_find_global*- fetch a global from an existing namespace
   PMC *Parrot_store_global*   - store a possibly new global into a possibly
 new namespace

  and helper functions for opcodes:

   PMC *Parrot_find_global_op  - find a global, optionally throwing an
  exception on failure
   PMC *Parrot_find_name_op- find a variable which could be a lexical or
  a global in one of a few namespaces,
  optionally throwing an exception on failure


Modified: trunk/docs/pdds/pdd21_namespaces.pod
==
--- trunk/docs/pdds/pdd21_namespaces.pod(original)
+++ trunk/docs/pdds/pdd21_namespaces.podWed Jul  5 17:31:15 2006
@@ -343,19 +343,29 @@
   $P1 = split "::", "Foo::Bar"
   $P0 = get_namespace $P1
 
-=item $P0 = find_global $P1, $S0
-
 =item $P0 = find_global $S0
 
-Find $P0 as the variable $S0 in the current namespace. or in $P1 (an array of
-names or a multidimensional hash index), relative to the HLL root namespace.
+Find $P0 as the variable named $S0 in the current namespace.
 
-=item store_global $P1, $S0, $P0
+=item $P0 = find_global $S1, $S0
+
+=item $P0 = find_global $P1, $S0
+
+Find $P0 as the variable named $S0 in $S1 (a first-level namespace) or $P1 (an
+array of names or a multidimensional hash index), relative to the HLL root
+namespace.
 
 =item store_global $S0, $P0
 
-Store $P0 as the variable $S0 in the current namespace, or in $P1 (an array of
-names or a multidimensional hash index), relative to the HLL root namespace.
+Store $P0 as the variable $S0 in the current namespace.
+
+=item store_global $S1, $S0, $P0
+
+=item store_global $P1, $S0, $P0
+
+Store $P0 as the variable $S0 in $S1 (a first-level namespace) or $P1 (an
+array of names or a multidimensional hash index), relative to the HLL root
+namespace.  If the given namespace does not exist it is created.
 
 =back
 

Re: Volunteer wanted: We need a new wiki.

[Randy W. Sims]

Michael G Schwern wrote:

On 7/5/06, Jonathan T. Rockway <[EMAIL PROTECTED]> wrote:

The thing about using MediaWiki is that it's not written in Perl.  Not
that PHP is bad (ok, yes it is bad...), but doesn't it send some sort of
negative message when Perl QA doesn't use a Perl-based Wiki?


Do I worry that qa.perl.org is running Apache?  That's not written in Perl.
I'm sending mail via GMail, you're using Thunderbird.  Not Perl.
This mailing list is run with ezmlm on qmail.  They're not written in Perl.

What message are we sending using all this non-Perl software?  That we
use the best tool for the job, not the one with the best political
connections.  That we're focused on QA and not in the business of
maintaining MTAs, MUAs, web servers, mailing lists or wikis.

If it bothers you that we're not using a Perl-based wiki, improve the
Perl wikis.  Or think less provincially, its ok to use more than one
language.  Or don't let it bother you.

Honestly, it could be written in COBOL for all I care.  Its well
written, it works well and, thanks to Tyler MacDonald, it works now.



Thank you for those sensible words. This type discussion happens way too 
often.


There have been several threads lately on wikis. The perl6-user group 
had a long one; and someone has even offered a bounty for a perl 6 based 
wiki. Meanwhile they have set up on . 
The maintainers of that site, Australia and New Zealand PM, have made it 
available to other perl projects as well.


A request for a decent central perl wiki was also requested on the 
advocacy list where perl.net.au was again mentioned and made available, 
and Ask mentioned setting a SocialText based wiki for perl:



When Socialtext releases their beta I'm planning to play with it and likely 
setup an instance for the perl community (FWIW).


I don't know much about SocialText. Is there a converter, so that if you 
put something up temporarily in MediaWiki, it can later be converted and 
moved to SocialText?


Randy.

Re: On "Gaming" CPANTS, and a Kwalitee Suggestion

[Adam Kennedy]

Define "some" please :)


Ricardo has said he is, for example.


And, "improve compatibility" - with broken systems? OMG. :)

You mean we now don't sign packages anymore just because someone isn't 
able to check the signature? 

The right way is to tell the user to fix their borken system, not to  
remove features.


The concept of user being capable of doing ANYTHING is invalid in 
toolchainland. The user isn't able to, and shouldn't have to, do anything.


Module::Signature is broken, in several ways, on many platforms.

It adds a dependency on a binary application (gpg) that users have to 
install by hand, doesn't check for the presence of it properly, and if 
you don't have it, installs an enormous chain of dependencies, with said 
deps having some major issues of their own.


It's become bad enough that Module::Signature is being pulled from 
Bundle::CPAN and being disabled by default in CPAN.pm, until 
Module::Signature gets a maintainer capable that can make it somewhat saner.


CPAN.pm has to work everywhere, and currently Module::Signature is 
breaking that. So it's getting shelved until it works.


Adam K

[svn:perl6-synopsis] r9814 - doc/trunk/design/syn

[larry]

Author: larry
Date: Wed Jul  5 16:27:04 2006
New Revision: 9814

Modified:
   doc/trunk/design/syn/S04.pod

Log:
bracket mismatch spotted by TreyHarris++


Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podWed Jul  5 16:27:04 2006
@@ -763,8 +763,8 @@
 the start of a statement.  To embed a statement in an expression you
 must use something like C or C.
 
-$x =  do { given $foo { when 1 {2} when 3 {4} } + $bar;
-$x = try { given $foo { when 1 {2} when 3 {4} } + $bar;
+$x =  do { given $foo { when 1 {2} when 3 {4} }} + $bar;
+$x = try { given $foo { when 1 {2} when 3 {4} }} + $bar;
 
 Just because there's a C<< statement_control: >> does not preclude us 
from
 also defining a C<< prefix: >> that I be used within an expression:

Re: Volunteer wanted: We need a new wiki.

[Michael G Schwern]

On 7/5/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:

Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On 7/5/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> >I'd be happy to. yi.org is already running a few mediawikis, as well as
> >cpants.perl.org. Let me know and I'll get it set up.
>
> You win!  Set it up.  Let us know when its online.  We'll worry about
> getting a proper domain/uri for it later.

Done! http://qa.yi.org/


Thanks!

Could you switch that to perl-qa.yi.org?  Just to make it clear this
isn't yi.org's QA department.

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Andy Lester]

On Jul 5, 2006, at 5:26 PM, chromatic wrote:


If you
cannot or will not work with the community, don't be surprised when  
the

community has little interest in working with you.


Please also LISTEN to what we're saying.  A thread w/Shlomi typically  
has responses from Shlomi that rebut the concerns of others, rather  
than assimilating them.


The other thing to remember, Shlomi, is that Test::Run is entirely  
for Shlomi.  Nobody is asking for it.  The market for Test::Run does  
not exist.


It's fine to write software to scratch an itch.  Just don't be  
surprised when your itch is unique to you.


xoa

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Shlomi Fish]

On Wednesday 05 July 2006 23:55, chromatic wrote:
> On Wednesday 05 July 2006 12:28, Shlomi Fish wrote:
> > I'd like to suggest a generic proposal for the Perl Foundation Grants.
> > Note that I'm not going to take it myself, because I just started a new
> > job and would like to commit to it. However, I can be the mentor for this
> > grant. I'm posting it here to get some reactions before I put it in my
> > use.perl.org journal, etc.
>
> You want TPF to pay some unspecifed and unidentified other person 

Not exactly. I suggested that if anyone is interested in working on Test::Run, 
he can file a proposal for a grant saying he'd like to work on it with me as  
a mentor. I still don't have anyone who can work on it. This is similar to 
Adam Kennedy's "Strawberry Perl" developer wanted:

http://use.perl.org/~Alias/journal/29174

Albeit mine was possibly too badly phrased.

> to 
> continue a fork of a core module that can't ever replace the core module
> because of its licensing?
>

Test::Run has no licensing problems. Some parts of it are under the Perl 
dual-license. The other parts are under the MIT X11 license. One can easily 
re-license MIT X11-licensed code under any other licence.

Sheez...

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.

Re: Volunteer wanted: We need a new wiki.

[Tyler MacDonald]

Michael G Schwern <[EMAIL PROTECTED]> wrote:
> >> You win!  Set it up.  Let us know when its online.  We'll worry about
> >> getting a proper domain/uri for it later.
> >
> >Done! http://qa.yi.org/
> 
> Thanks!
> 
> Could you switch that to perl-qa.yi.org?  Just to make it clear this
> isn't yi.org's QA department.

yi.org's QA department... I almost snorted me tea out of my nose when I read
that. ;-)

OK, I've set perl-qa.yi.org to point there. I figured once it was ready for
production you'd point a more official perly URL at it. (If/when you
want to do that, please let me know so I can update apache etc...)

Cheers,
Tyler

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[chromatic]

On Wednesday 05 July 2006 15:02, Shlomi Fish wrote:

> Test::Run is licence-compatible with the core.

I do not think those words mean what you think they mean.

> Some of Test::Run is 
> licensed under the GPL and Artistic (version 1.0) licence which is the
> licence of the perl 5 core. The other part is licensed under the MIT X11
> license which can be freely linked against each one and can also be
> converted to the Perl dual-license by anyone who re-distributes the code.

Hypothetically speaking, if Test::Run gets in the core as a dual-lived module 
and maintains its current licensing, if I were to write a patch against it 
and submit it to p5p, would I have to license the patch as 
Artistic/GPL/BSD/MIT to match all of the licenses on the code?  (Is it even 
*possible* to link all of those licenses together without the GPL trumping at 
least the latter two?)  What if I use the standard Perl license?  That part 
can go in the core, but it's more restrictive than your preferred license, so 
you can't use it.

You're a smart guy and you have a lot to contribute, but there's a reason 
people complain when you wander so far away from the community and start 
doing things on your own: it's a real hassle for the rest of us.  If you 
cannot or will not work with the community, don't be surprised when the 
community has little interest in working with you.

(Please don't argue about how this is not a problem in theory.  We're not 
working in theory here.  We're working in practice, and in practice I have a 
Really Big Problem here that no amount of theoretical handwaving can 
dismiss.)

-- c

Re: Volunteer wanted: We need a new wiki.

[Michael G Schwern]

On 7/5/06, Jonathan T. Rockway <[EMAIL PROTECTED]> wrote:

The thing about using MediaWiki is that it's not written in Perl.  Not
that PHP is bad (ok, yes it is bad...), but doesn't it send some sort of
negative message when Perl QA doesn't use a Perl-based Wiki?


Do I worry that qa.perl.org is running Apache?  That's not written in Perl.
I'm sending mail via GMail, you're using Thunderbird.  Not Perl.
This mailing list is run with ezmlm on qmail.  They're not written in Perl.

What message are we sending using all this non-Perl software?  That we
use the best tool for the job, not the one with the best political
connections.  That we're focused on QA and not in the business of
maintaining MTAs, MUAs, web servers, mailing lists or wikis.

If it bothers you that we're not using a Perl-based wiki, improve the
Perl wikis.  Or think less provincially, its ok to use more than one
language.  Or don't let it bother you.

Honestly, it could be written in COBOL for all I care.  Its well
written, it works well and, thanks to Tyler MacDonald, it works now.

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Shlomi Fish]

On Wednesday 05 July 2006 23:51, Ricardo SIGNES wrote:
> * Shlomi Fish <[EMAIL PROTECTED]> [2006-07-05T15:28:28]
>
> > The grant is about Test::Run, which is a fork of Test::Harness that aims
> > to greatly refactor and modularise it. I've already revamped and
> > re-written a lot of code for it, but there's still a lot that needs to be
> > done.
>
> [...]
>
> > Some of the code in Test::Run is derived from the code of Test::Harness,
> > which is GPL+[Artistic 1.0]. Thus, it should be kept this way. However,
> > some code was written from scratch and due to my personal preferences, it
> > was licensed under the MIT X11 Licence[1]. I prefer that all new code
> > will be also MIT X11 licence, and that existing code will retain its
> > original licensing terms.
>
> [...]
>
> > TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and
> > others.
>
> So, you want to have someone (other than you) work on a project that
> largely seems to duplicate the functionality of existing code.  Among the
> existing code whose functionality is being duplicate is code still under
> development.

Let me try and understand what you mean and explain what I want. Test::Run was 
started before TAP::Harness in the aim to transform Test::Harness into 
something more modular. A large part of this goal was already acheived, see 
what exists now at:

http://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/

Among the tasks that were achieved so far in Test::Run are:

1. More tests were added.

2. An almost complete Object-Oriented interface instead of a procedural 
interface.

3. Many long functions were broken into smaller one.

4. All the command line and %ENV handling was moved into a separate module.

5. A plugin interface was defined and several plugins were written.

But like I said there is still a lot of work to be done.

Now TAP::Harness was started several months after the first release of 
Test::Run. Its aim is to provide another implementation for processing TAP, 
which from what I understood will share much of the goals.

>
> The other project is being done with no TPF funding and will be capable of
> becoming part of the core in future Perls, largely superseding the existing
> test framework.

So hopefully will Test::Run. Except that now that I have a full-time job, it 
would be nice if someone can work on it as well as me.

>
> You want funding for a parallel project that will be not be
> license-compatible with the core.

Test::Run is licence-compatible with the core. Some of Test::Run is licensed 
under the GPL and Artistic (version 1.0) licence which is the licence of the 
perl 5 core. The other part is licensed under the MIT X11 license which can 
be freely linked against each one and can also be converted to the Perl 
dual-license by anyone who re-distributes the code.

And like I said, I don't want the funding for me - I want it for someone who 
volunteers to work on the project.

>
> I don't see how this would be worth TPF's money.  It might be a very useful
> project for people who use the code or for people who want to steal ideas,
> but I don't see how it fills a really critical void in the language or its
> toolset.

Please read my answers above and also re-read my original draft of the 
proposal.

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.

Re: Volunteer wanted: We need a new wiki.

[Tyler MacDonald]

Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On 7/5/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> >I'd be happy to. yi.org is already running a few mediawikis, as well as
> >cpants.perl.org. Let me know and I'll get it set up.
> 
> You win!  Set it up.  Let us know when its online.  We'll worry about
> getting a proper domain/uri for it later.

Done! http://qa.yi.org/

- Tyler

Re: TAP Grammar

[Chris Dolan]

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:



-- 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: a smarter form of whitespace

[Allison Randal]

Nathan Gray wrote:
> 
> Overloading  and other builtins was fixed in parrot and pugs
> approaching midnight (hackathon time) on 2006-06-29.  If your parrot
> and pugs are both more recent than that, I'm not sure where the bug
> is.

I have the latest checkout of Parrot (I'm not using Pugs).

It may not be a bug. The design question is: should  match a newline
even when it's been overloaded to match only spaces and tabs? (I'm
thinking "No", but could be wrong.)

Allison

Re: Volunteer wanted: We need a new wiki.

[Jonathan T. Rockway]

I'd prefer MediaWiki (that which
Wikipedia uses).


I'm working on making Socialtext open source right now.  I plan to  
put up a wiki based on it very soon.


This sounds like the best idea.

The thing about using MediaWiki is that it's not written in Perl.  Not 
that PHP is bad (ok, yes it is bad...), but doesn't it send some sort of 
negative message when Perl QA doesn't use a Perl-based Wiki?  I know 
Rails gets criticized for running their site on PHP... you'd think 
they'd just rename it to index.rhtml or whatever :)


Regards,
Jonathan Rockway

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Andy Lester]

On Jul 5, 2006, at 3:55 PM, chromatic wrote:

You want TPF to pay some unspecifed and unidentified other person  
to continue
a fork of a core module that can't ever replace the core module  
because of

its licensing?


But at least he'll act as mentor.

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Proposal Suggestion - Test::Run

[Jonathan T. Rockway]

Two comments, pretty much agreeing with chromatic and Ricardo:

1)  How would this proposed module benefit the perl community?  Why 
can't you fix things in Test::Harness and send the patch in?  If you fix 
deployed modules, everyone wins.  If you write your own module, it sits 
on CPAN unused.


What exactly is wrong with Test::Harness, anyway?  The development team 
is pretty agreeable, the code is good, the module works, etc.  Is there 
some large problem I'm missing?  (A problem so large that TPF needs to 
*pay* someone to fix it!?)


2) If you use GPL'd code in an MIT-licensed app, the entire app becomes 
GPL.  I don't think you can say, "this requires xyz GPL'd code, but if 
it didn't it would be MIT".  It's GPL by virtue of requiring GPL code.  
(Hence the accusation that the GPL is 'viral' or whatever.)  IANAL, but 
this is my understanding from reading the license, the FSF's site, etc.  
If the code isn't derived, though, feel free to MIT license it.  (The 
fact of the matter, though, is that Perl uses the Perl license.  I don't 
really love the Artistic license, but I release my perl code under the 
dual license because Everyone Else Does.  It makes everything work 
nicely and builds community too  :)


Just my two cents :)

Regards,
Jonathan Rockway

Shlomi Fish wrote:


Hi all!

I'd like to suggest a generic proposal for the Perl Foundation Grants. Note 
that I'm not going to take it myself, because I just started a new job and 
would like to commit to it. However, I can be the mentor for this grant. I'm 
posting it here to get some reactions before I put it in my use.perl.org 
journal, etc.


The grant is about Test::Run, which is a fork of Test::Harness that aims to 
greatly refactor and modularise it. I've already revamped and re-written a 
lot of code for it, but there's still a lot that needs to be done.


Here are some Test::Run links:

1. Lightning Talk about Test::Run - 
http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/


2. use.perl.org journal entries:
http://use.perl.org/~Shlomi+Fish/journal/27467
http://use.perl.org/~Shlomi+Fish/journal/27887

(they contain a lot of links).

---

Licencing Issues:
=

Some of the code in Test::Run is derived from the code of Test::Harness, which 
is GPL+[Artistic 1.0]. Thus, it should be kept this way. However, some code 
was written from scratch and due to my personal preferences, it was licensed 
under the MIT X11 Licence[1]. I prefer that all new code will be also MIT X11 
licence, and that existing code will retain its original licensing terms.


Comparison with Similar Efforts:


* Test::Harness is the old harness module of Perl 5, from which Test::Run was 
derived. It is not very Object Oriented, suffers from some modularity issues, 
and is generally hard to properly adapt. Often, customisations to it need to 
be kept and maintained in house.


Test::Run is no longer backwards compatible with Test::Harness. The internal 
and external interface was changed.


* TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and others. 
It has similar goals to Test::Run, but has a different methodology of trying 
to achieve it. 

* TAP::Parser by Ovid is a work-in-progress module that aims to be a modular 
event-based parser for TAP output. Test::Run may eventually convert to use it 
instead of its current ad-hoc TAP handling routine (that was inherited from 
Test::Harness).


Orthogonal to all of these are the various Perl and non-Perl TAP generators 
such as Test::Builder, Test::Simple, Test::More, Test::Base, and the 
http://search.cpan.org/~petdance/Test-Harness-2.62/lib/Test/Harness/TAP.pod#Non-Perl_TAP
. Test::Run and friends are not concerned by them as long as the script that 
performs the tests' generates correct TAP.


Scope of the Project:
=

This project aims to do the following:

1. Finish refactoring Test::Run::Obj, Test::Run::Straps and the other modules 
derived from Test::Harness. One should probably have read "Refactoring" by 
Martin Fowler, for some indication on which "bad smells" exist in bad code, 
and how bad code should be methologicaly refactored if it has them. "Perl 
Best Practices" is also possibly a good read. (albeit I only began reading 
it).


2. Move some of the functionality of Test::Harness that's currently in the 
Test::Run::Obj core into plugins.


3. Update the POD documentation for the new version.

4. Extend (using plugins, etc.) for:
- Formatting the messages using templates or callbacks.
- Colours in the output. (Already exist to some extent).
- HTML, XML and YAML (and others) Output.
- Persistent Running.
- Interrupted GUI running.

Michael G. Schwern also suggested the following: (in the context of 
TAP::Harness)


<<<
Right now the use cases I have in mind include things such as
parallelized test runs, fancy GUI and HTML outputs (for example,
TAP::Model::HTMLMatrix), multiple,

Re: Volunteer wanted: We need a new wiki.

[Michael G Schwern]

On 7/5/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:

I'd be happy to. yi.org is already running a few mediawikis, as well as
cpants.perl.org. Let me know and I'll get it set up.


You win!  Set it up.  Let us know when its online.  We'll worry about
getting a proper domain/uri for it later.

Re: Volunteer wanted: We need a new wiki.

[Andy Lester]

On Jul 5, 2006, at 4:17 PM, Michael G Schwern wrote:


We need a new wiki.  schwern.org is too anemic to run anything serious
(64 megs of RAM, woo!).  We need a volunteer with server space to
setup and maintain the Perl QA Wiki.  I'd prefer MediaWiki (that which
Wikipedia uses).  It seems the best known, best of breed with the
least fuss.


I'm working on making Socialtext open source right now.  I plan to  
put up a wiki based on it very soon.


If you can wait a few days, I'll have something up at rakudo.org.

xoxo,
Andy

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Volunteer wanted: We need a new wiki.

[Tyler MacDonald]

Michael G Schwern <[EMAIL PROTECTED]> wrote:
> These TAP extension proposals and designs for parsers and questions
> for details about the TAP grammar... they should all go into the Wiki.
> But the Perl QA Wiki sucks.  Its slow.  Its spammed.  UseModWiki
> sucks.  And I don't have the time to maintain it.
> 
> We need a new wiki.  schwern.org is too anemic to run anything serious
> (64 megs of RAM, woo!).  We need a volunteer with server space to
> setup and maintain the Perl QA Wiki.  I'd prefer MediaWiki (that which
> Wikipedia uses).  It seems the best known, best of breed with the
> least fuss.
> 
> Please contact me if you would like to do this.

I'd be happy to. yi.org is already running a few mediawikis, as well as
cpants.perl.org. Let me know and I'll get it set up.

Cheers,
Tyler

Volunteer wanted: We need a new wiki.

[Michael G Schwern]

These TAP extension proposals and designs for parsers and questions
for details about the TAP grammar... they should all go into the Wiki.
But the Perl QA Wiki sucks.  Its slow.  Its spammed.  UseModWiki
sucks.  And I don't have the time to maintain it.

We need a new wiki.  schwern.org is too anemic to run anything serious
(64 megs of RAM, woo!).  We need a volunteer with server space to
setup and maintain the Perl QA Wiki.  I'd prefer MediaWiki (that which
Wikipedia uses).  It seems the best known, best of breed with the
least fuss.

Please contact me if you would like to do this.

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[chromatic]

On Wednesday 05 July 2006 14:04, Andy Lester wrote:

> On Jul 5, 2006, at 3:55 PM, chromatic wrote:

> > You want TPF to pay some unspecifed and unidentified other person
> > to continue a fork of a core module that can't ever replace the core
> > module because of its licensing?

> But at least he'll act as mentor.

I have no involvement with TPF leadership, but I'm not sure TPF is in the 
business of funding examples of how not to do F/LOSS development.

-- c

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Ricardo SIGNES]

* Shlomi Fish <[EMAIL PROTECTED]> [2006-07-05T15:28:28]
> The grant is about Test::Run, which is a fork of Test::Harness that aims to 
> greatly refactor and modularise it. I've already revamped and re-written a 
> lot of code for it, but there's still a lot that needs to be done.

[...]
 
> Some of the code in Test::Run is derived from the code of Test::Harness,
> which is GPL+[Artistic 1.0]. Thus, it should be kept this way. However, some
> code was written from scratch and due to my personal preferences, it was
> licensed under the MIT X11 Licence[1]. I prefer that all new code will be
> also MIT X11 licence, and that existing code will retain its original
> licensing terms.

[...]

> TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and others. 

So, you want to have someone (other than you) work on a project that largely
seems to duplicate the functionality of existing code.  Among the existing code
whose functionality is being duplicate is code still under development.

The other project is being done with no TPF funding and will be capable of
becoming part of the core in future Perls, largely superseding the existing
test framework.

You want funding for a parallel project that will be not be license-compatible
with the core.

I don't see how this would be worth TPF's money.  It might be a very useful
project for people who use the code or for people who want to steal ideas, but
I don't see how it fills a really critical void in the language or its toolset.

-- 
rjbs


signature.asc
Description: Digital signature

Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[chromatic]

On Wednesday 05 July 2006 12:28, Shlomi Fish wrote:

> I'd like to suggest a generic proposal for the Perl Foundation Grants. Note
> that I'm not going to take it myself, because I just started a new job and
> would like to commit to it. However, I can be the mentor for this grant.
> I'm posting it here to get some reactions before I put it in my
> use.perl.org journal, etc.

You want TPF to pay some unspecifed and unidentified other person to continue 
a fork of a core module that can't ever replace the core module because of 
its licensing?

-- c

Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]

[Shlomi Fish]

Hi all!

I'd like to suggest a generic proposal for the Perl Foundation Grants. Note 
that I'm not going to take it myself, because I just started a new job and 
would like to commit to it. However, I can be the mentor for this grant. I'm 
posting it here to get some reactions before I put it in my use.perl.org 
journal, etc.

The grant is about Test::Run, which is a fork of Test::Harness that aims to 
greatly refactor and modularise it. I've already revamped and re-written a 
lot of code for it, but there's still a lot that needs to be done.

Here are some Test::Run links:

1. Lightning Talk about Test::Run - 
http://www.shlomifish.org/lecture/Perl/Lightning/Test-Run/

2. use.perl.org journal entries:
http://use.perl.org/~Shlomi+Fish/journal/27467
http://use.perl.org/~Shlomi+Fish/journal/27887

(they contain a lot of links).

---

Licencing Issues:
=

Some of the code in Test::Run is derived from the code of Test::Harness, which 
is GPL+[Artistic 1.0]. Thus, it should be kept this way. However, some code 
was written from scratch and due to my personal preferences, it was licensed 
under the MIT X11 Licence[1]. I prefer that all new code will be also MIT X11 
licence, and that existing code will retain its original licensing terms.

Comparison with Similar Efforts:


* Test::Harness is the old harness module of Perl 5, from which Test::Run was 
derived. It is not very Object Oriented, suffers from some modularity issues, 
and is generally hard to properly adapt. Often, customisations to it need to 
be kept and maintained in house.

Test::Run is no longer backwards compatible with Test::Harness. The internal 
and external interface was changed.

* TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and others. 
It has similar goals to Test::Run, but has a different methodology of trying 
to achieve it. 

* TAP::Parser by Ovid is a work-in-progress module that aims to be a modular 
event-based parser for TAP output. Test::Run may eventually convert to use it 
instead of its current ad-hoc TAP handling routine (that was inherited from 
Test::Harness).

Orthogonal to all of these are the various Perl and non-Perl TAP generators 
such as Test::Builder, Test::Simple, Test::More, Test::Base, and the 
http://search.cpan.org/~petdance/Test-Harness-2.62/lib/Test/Harness/TAP.pod#Non-Perl_TAP
. Test::Run and friends are not concerned by them as long as the script that 
performs the tests' generates correct TAP.

Scope of the Project:
=

This project aims to do the following:

1. Finish refactoring Test::Run::Obj, Test::Run::Straps and the other modules 
derived from Test::Harness. One should probably have read "Refactoring" by 
Martin Fowler, for some indication on which "bad smells" exist in bad code, 
and how bad code should be methologicaly refactored if it has them. "Perl 
Best Practices" is also possibly a good read. (albeit I only began reading 
it).

2. Move some of the functionality of Test::Harness that's currently in the 
Test::Run::Obj core into plugins.

3. Update the POD documentation for the new version.

4. Extend (using plugins, etc.) for:
- Formatting the messages using templates or callbacks.
- Colours in the output. (Already exist to some extent).
- HTML, XML and YAML (and others) Output.
- Persistent Running.
- Interrupted GUI running.

Michael G. Schwern also suggested the following: (in the context of 
TAP::Harness)

<<<
Right now the use cases I have in mind include things such as
parallelized test runs, fancy GUI and HTML outputs (for example,
TAP::Model::HTMLMatrix), multiple, non-Perl TAP sources (ex. contact a
URL and get the TAP from that; run HTML through a validator which
produces TAP; run a C program which spits out TAP), "enhanced" TAP
output (ex. colors; levels of verbosity), and the ability to smoothly
handle TAP extensions.
>>>

Roles in the Project:
=

Like I said I'm going to be the mentor for the project, not the one who 
actually performs it. The one who takes it will receive most (or all) of the 
money of the grant while doing most of the work on Test::Run.

I will aid the project proposer by giving him a Berlios.de developer status 
for the Test-Run project (with Subversion commit access) and also eventually 
make him a CPAN co-maintainer for the appropriate namespaces, so he can 
upload modules there.

One note is that so far I did most of the work on Test::Run, and so no-one 
else has much first-hand experience with it. However, I believe any prior 
experience with the Test::Harness code or even with Perl 5 testing in general 
will do, and I'll be glad to help any newcomer feel comfortable with the 
code.

I can be reached in the following means:

http://www.shlomifish.org/me/contact-me/

Regards,

Shlomi Fish

[1] - The MIT X11 Licence ( http://en.wikipedia.org/wiki/MIT_License )  a 
BSD-style licence that is almost ent

Re: S29 proposed revision

[Aaron Sherman]

On Wed, 2006-07-05 at 16:09 -0400, Aaron Sherman wrote:

> The fourth of July weekend was fairly slow for me, so I started with
> Larry's S29 and went forward.
> 
> My first pass at a revised S29 is attached.

I already see one problem. "as" slipped in, which is an operator, not a
function.

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback

S29 proposed revision

[Aaron Sherman]

Larry (bless his wire-photographing heart) took the time to re-vamp S29.
Of course, this threw off all of my collating of S29, but that's fine
since he's actually answered more of my questions than I could have
hoped.

The fourth of July weekend was fairly slow for me, so I started with
Larry's S29 and went forward.

My first pass at a revised S29 is attached. This is a combination of
some of what was left from my original work, some suggested changes to
Larry's version, and some newly incorporated bits. Where possible I'm
footnoting the summary or mailing list and message ID that my changes
are based on. There's a lot more of the mailing-list based work to go,
but before someone overhauls S29 again, I thought I should make some of
my work public. My diff is against pugs/docs/Perl6/Spec circa revision
11216.

A quick summary for discussion:

Operators vs. Functions

Before Larry's update, I had decided that simple functions and term:'s
were the only things that made sense for S29, even though EVERYTHING is
really a function. I've codified this as part of the intro. Thoughts?

Removing code

I've begun the process of removing some of the code from S29. It's not
that code is bad, it's just that it's not actually documentation. To
that end, I'm writing real documentation for functions like sign and
sqrt instead of example implementations.

Constants as functions

Since this is S29, I think it makes sense to unify every entry with a
leading subroutine/function signature, not to use the otherwise very
nice and convenient C notation. To this end,
I've re-written constants as C ()>
which I assert means the exact same thing (please correct me if that
assertion fails). Of course the implementation might use C,
but the documentation doesn't have to agree with the implementation
details as long as it agrees with the implementation interface.

TODO

Two major TODO sections were in there: defined/undefine/want/caller and
fork/lock/wait/waitpid. I moved all of these into the body of the
Summary and defined defined, undefine, fork and wait. I left the body of
want and caller as TODO, and put lock and waitpid in the Obsolete
section (per S17 Draft and the simple fact that waitpid is no longer
required).

For wait I've defined a new object called Conc::Proc::Status (no more
bit shifting, yay!) and some behavior of S17's Conc::Proc which is
probably fine, but others should look it over. If this is OK, some notes
should probably be added back into S17 as well.

There are some notes on waitpid in Perl 5's perlfunc, which probably
need to be moved into S29, but some analysis of parrot's wait facilities
will be required to be sure how they play in.

word to your macro

Larry proposed word as an operator a while back. This is one of the
(many) things that was in my note bin for transcription. Let me know if
this is still relevant.

word probably violates my intro on the scope of the document, but it's a
pretty strange one, so I don't think anyone's going to complain too
much.

Index: Functions.pod
===
--- Functions.pod	(revision 11216)
+++ Functions.pod	(working copy)
@@ -39,7 +39,15 @@
 Where code is given here, it is intended to define semantics, not to
 dictate implementation.
 
+=head2 Operators vs. Functions
 
+There is no particular difference between an operator and a function,
+but for the sake of documentation, only functions declared without
+specifying a grammatical category or with a category of C
+(see L) will be described as "functions",
+and everything else as "operators" which are outside of the scope
+of this document.
+
 =head1 Type Declarations
 
 The following type declarations are assumed:
@@ -155,6 +163,7 @@
 
  &log10 := &log.assuming:base(10);
 
+A base C<10> logarithm.
 
 =item rand
 
@@ -168,19 +177,10 @@
 
  our Int multi Num::sign ( Num  $x )
  our Int multi Math::Basic::sign ( Num $x )
-   if !defined($x) { return undef };
-   if $x < 0   { return -1};
-   if $x > 0   { return  1};
-   if $x == 0  { return  0};
-   fail;
- }
 
-or more succinctly:
+Returns 1 when C<$x> is greater than 0, -1 when it is less than 0, 0 when it
+is equal to 0, or undefined when the value passed is undefined.
 
- our Int multi Math::Basic::sign ( Num $x )
-   $x <=> 0;
- }
-
 =item srand
 
  multi Math::Basic::srand ( Num $seed = default_seed_algorithm())
@@ -199,26 +199,38 @@
  our Complex multi Complex::sqrt ( Complex  $x )
  our Num multi Math::Basic::sqrt ( Num $x )
 
-C<$x ** 0.5>
+Returns the square root of the parameter.
 
 =item e
 
- constant Num Num::e = exp(1);
+ our Num multi term:Num:: ()
 
+The constant I, roughly equal to C<2.71828182845905>.
 
 =item pi
 
- constant Num Num::pi = atan(1,1) * 4;
- constant Int Int::pi = 3;
+ our Num multi term:Num:: ()
 
+The constant I, roughtly equal to C<3.14159265358979>.
+
 =item i
 
- constant Complex Complex::i = Complex::sqrt(-1);
+ our Num multi term:Num:: ()
 
+The constant

Re: Call for Parrot Janitors

[Andy Lester]

On Jul 5, 2006, at 2:30 PM, jerry gay wrote:


The following message from Andy Lester has been posted to perlmonks,
use.perl, and other sites, yet somehow never made it to the p6i
mailing list.


Probably because I didn't post it here. :-)

parrot/cage/todo.pod has some high-level plans and ideas that I'd  
like to attack.  Discussion here is more than welcome.


Thansk,
xoa

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Fwd: Call for Parrot Janitors

[jerry gay]

The following message from Andy Lester has been posted to perlmonks,
use.perl, and other sites, yet somehow never made it to the p6i
mailing list. I'm making sure the regular (and irregular) list readers
don't miss out on this exciting news.
~jerry

=

I've put on my overalls and rubber gloves to help Perl 6. I'm the
chief Parrot Cage Cleaner, and I'd like you to join me in helping to
keep this crucial bird healthy.

Parrot (http://parrotcode.org/) is the virtual machine designed to
efficiently compile and execute bytecode for interpreted languages.
Parrot will be the target for the final Perl 6
(http://dev.perl.org/perl6/) compiler, and is already usable as a
backend for Pugs (http://www.pugscode.org/), as well as variety of
other languages.

The Parrot project was re-energized by a week-long hackathon at
YAPC::NA 2006 (http://yapcchicago.org/), with Parrot wizards from
around the world converging on Chicago to create more magic. However,
when wizards create magic, they spend less time fighting entropy. The
Parrot project is starting to accumulate technical debt
(http://c2.com/cgi/wiki?TechnicalDebt), and that helps diminish the
potential velocity of the project. It often turns out that without
janitors, the wizards get stuck.

That's where I come in -- and where you can join me, even if you're
new to Perl or Parrot. I don't know Perl 6 or Parrot yet, but I don't
need to, and neither do you. The beauty of a janitorial job on a
project is that it doesn't require wizard-level skills on the main
project, but a competence on the lower-level parts of maintenance.
Parrot Cage Cleaners just need to be comfortable with building C
programs, and with large projects, and an eye to watching the corners.

Cage cleaning will be a learning experience for everyone. This is a
great way to get familiar with Parrot, and get your feet wet working
on a next-generation virtual machine. It's also a way to help out on
an important open source project without having to devote lots of
time. There are always smaller tasks to be done.

I've worked with Chip Salzenberg, the new Parrot pumpking
(http://use.perl.org/~chip/journal/30136), to come up with a list of
high-level goals:

   * Enforcing coding standards, naming conventions, etc
   * Smoke testing on many platforms
   * Decreasing the amount of repeated code
   * Automated generation of C headers
   * Improve low-level code quality
   * Creating automated code checking tools
   * Documenting function behavior and structure members
   * Developing coverage tools where they don't exist

This is a great opportunity for those of you out there (and I know
you're out there!) who have always wanted to help out Perl, but don't
know where to start. If you're interested, please contact me at andy
at perl.org, or visit the #parrot IRC channel on irc.perl.org. You
should also subscribe to the parrot-porters mailing list at
lists.perl.org, currently transitioning from the name perl6-internals
(http://lists.cpan.org/showlist.cgi?name=perl6-internals). For the
latest information on the Cage Cleaners, visit
http://parrotcode.org/cage-cleaners/.

I hope to see you soon!

xoxo,
Andy

Re: On "Gaming" CPANTS, and a Kwalitee Suggestion

[Tels]

Moin,

On Wednesday 05 July 2006 17:56, David Golden wrote:
> Randy J. Ray wrote:
> > I'm a fairly-recent addition to the list. I've read a good part of
> > the
>
> Welcome!
>
> > Secondly, having recently added digital-signing to a few of my
> > modules, perhaps the presence of a SIGNATURE file might be a Kwalitee
> > marker (with the caveat that it should be an actual
> > Module::Signature-generate artifact, not just a zero-length file
> > named "SIGNATURE"). I found the steps needed to add this to be pretty
> > simple, not much more work than adding POD and POD-coverage tests to
> > those same modules.
>
> Module::Signature has caused a problem at various points for people who
> have it installed, but not configured properly.  Given that, some
> developers have started removing SIGNATURE to improve compatibility.

Define "some" please :)

And, "improve compatibility" - with broken systems? OMG. :)

You mean we now don't sign packages anymore just because someone isn't 
able to check the signature? 

The right way is to tell the user to fix their borken system, not to  
remove features.

> Given that Mod::Sig checks are just that the signature is valid, not
> that the signature matches a known/registered developer, the security
> aspect is already minimal.

This is a security bug and should then be fixed ASAP.

But AFAIK, PAUSE checks the key upon upload, and I am *think* it would 
also check that the maintainer who uploads the package is the one who 
signed it. Anything else would be a stupid lapse and I can't imagine 
Andreas would be that stupid :)

Best wishes,

Tels

-- 
 Signed on Wed Jul  5 19:53:45 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Most of the screen on a blog is blank for an imaginary populace of
 readers still using 640x480 resolution. I didn't buy a 19" monitor to
 have 50% of its screen realestate pissed away on firing white pixels,
 you assholes." -- maddox from xmission



pgp9SYA1FRsXE.pgp
Description: PGP signature

Re: Using Rules Today

[Joshua Gatcomb]

On 7/3/06, Paul Seamons <[EMAIL PROTECTED]> wrote:



It isn't specifically a parser designed for general language parsing, but
CGI::Ex::Template does have a mathematical expression parser.



Thanks, but this falls into the realm of existing wheels which is a
different part of this project.



perl -e 'use CGI::Ex::Template; $s=CGI::Ex::Template::dump_parse("3 * 4 **
2 +
5"); $s =~ s/\s+/ /g; print "$s\n"'


$VAR1 = [ \[ '+', [ \[ '*', '3', [ \[ '**', '4', '2' ], 0 ] ], 0 ], '5' ],

0 ];



Ok, but where is the evaluation?  I know it wouldn't be too hard to write
something that could evaluate this data structure to produce the correct
results but that is what this project is all about.  Some parsers make this
easier than others.  Some allow the expression to be evaluated as it is
parsed while some require additional homegrown code to parse the resulting
parse tree (data structure).

I have not had a chance to look at Flavio's links yet.  Since no one who
actually knows rules seemed to be inspired to write an example for me - I
will *eventually* figure it out on my own and post back to the list as an
FYI.

Paul Seamons


Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region

Re: On "Gaming" CPANTS, and a Kwalitee Suggestion

[David Golden]

Randy J. Ray wrote:

I'm a fairly-recent addition to the list. I've read a good part of the


Welcome!


Secondly, having recently added digital-signing to a few of my modules,
perhaps the presence of a SIGNATURE file might be a Kwalitee marker (with
the caveat that it should be an actual Module::Signature-generate artifact,
not just a zero-length file named "SIGNATURE"). I found the steps needed to
add this to be pretty simple, not much more work than adding POD and
POD-coverage tests to those same modules.


Module::Signature has caused a problem at various points for people who 
have it installed, but not configured properly.  Given that, some 
developers have started removing SIGNATURE to improve compatibility.


Given that Mod::Sig checks are just that the signature is valid, not 
that the signature matches a known/registered developer, the security 
aspect is already minimal.


Regards,
David Golden

Re: TAP::Harness

[Geoffrey Young]

Geoffrey Young wrote:
> I've mentioned the idea of making it simple to use
> plan() and Test::More functions before

blarg... insert "separately" ^ here.  all the rest is pretty simple
already :)

--Geoff

Re: TAP::Harness

[Geoffrey Young]

sorry for dropping in on this late, but it was a holiday weekend :)

> * How can I help?
> 
> Provide use cases, what would you want to do with Test::Harness if you
> could?  What are you doing with Straps?  What features do other
> testing systems (JUnit, for example) have that you'd like to see in
> Perl?

the current threads are a bit to wade through, but in case nobody else
has brought it up, I've mentioned the idea of making it simple to use
plan() and Test::More functions before[1], because it's what we do over
in httpd land (plan in perl from the shell, emit TAP in perl from the
server).  you can do it now[2] but ideally it should be a bit more
seamless I'd think.

since you're asking :)

--Geoff

[1] http://www.nntp.perl.org/group/perl.qa/5445
[2] http://www.nntp.perl.org/group/perl.qa/5455

[perl #39714] [TODO] Refactor IMCC to remove static globals

[via RT]

# New Ticket Created by  Audrey Tang 
# Please include the string:  [perl #39714]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39714 >


IMCC currently relies on a lot of static globals to carry state, and
cannot reliably restore them when an error occurs. (grep for
"static" and "FIXME global" in the IMCC tree.)

Allison had ruled that reentrancy should be possible for IMCC, and
this would be a good refactoring project.


PGP.sig
Description: PGP signature

[perl #39716] [TODO] Document IMCC's :immediate feature

[via RT]

# New Ticket Created by  Audrey Tang 
# Please include the string:  [perl #39716]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39716 >


The IMCC operating in .pir->.pbc mode has a special feature of  
running arbitrary Parrot code
inside the PBC emitter, via an :immediate annotation on subroutines.   
It is currently the
idiom for loading dynamic lexical pads, but its semantics is  
undocumented.  Takers?


PGP.sig
Description: PGP signature

Perl 6 compiler docs released - graffle questions, compiler questions

[George Wood]

Audrey, Allison, and Patrick:

I am writing to enlist your help with the most recent documents that I have had 
the good fortune to have Audrey review this evening.  

I have released the latest version back to the 
pugs/docs/perl6_compilation/perl6_compilation.pdf file to complement the 
pugs/docs/perl6_compilation.graffle file.  The jpg and html linked files are a 
few hours older but were somewhat obsoleted when Audrey did the updates in the 
current file on the last page - so see the PDF for that.

If anyone, Audrey?, knows of a way to automate the export of the JPG and HTML 
files that set up the image maps I would be grateful - I could then put the 
export in a script/makefile of some kind to split the graffle file into user 
readable docs.  It takes me about 20 minutes to release the docs by hand now.

Here are some probably for Audrey...

1. Page on  Perl 6 on Haskell - Is runtime Specific AST actually the file 
Language.TH.Sytnax?

2. I am still trying to distinguish these 
Perl 6 on Perl 6  
Perl 6 on Parrot 

Do they both emit pmc files?

For everyone:

3. Do all of the emitted files on all of the diagrams match their intended 
types?

4. Do you like the over all presentation? 

Does it need more organization structure up front - I was thinking of a 
graphical table of contents that was linked into each page - do you have some 
project logos that I could use?

5. Should the documents be cross listed/linked in parrot tree?

Please feel free to edit/correct at will, and send me a note as to what needed 
work. I can work off a jpg or png emailed just as well as a set of comments.

George

[perl #39715] [TODO] IMCC errors should throw Parrot exceptions

[via RT]

# New Ticket Created by  Audrey Tang 
# Please include the string:  [perl #39715]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39715 >


Currently, if you use IMCC inside embedded parrot (eg. when compiling
via PGE), when a syntax error occurs, imcc calls Parrot_exit (or
downright exit() -- see imclexer.c)), and it terminates the
interpreter right there without any chance of recover.

It should throw an exception using the standard Parrot exception  
mechanism.
Note that doing this may depend on removing the global states, as to  
make IMCC
reentrant.


PGP.sig
Description: PGP signature

Re: [perl #39711] [TODO] Make PIR->PBC reentrant

[Allison Randal]

Audrey Tang wrote:
> 
> I already filed that as #39716 a few hours ago; also #39715 and #39714, 
> as per your suggestion:

Excellent.

> As I cannot modify links on rt.perl.org, can you do that for me?

Done, and I also added Vishal as a requestor on the relevant tickets.

Thanks!
Allison

Re: "Dynamic"

[Allison Randal]

chromatic wrote:
> 
> That doesn't quite seem fair; dynamic is a lot broader than just typing.  
> Certainly any statically typed language with decent support for generic 
> operations (or at least type-safe polymorphism) and a non-static loading 
> scheme would be sufficiently dynamic.
> 
> I can't point to an example of such a language, but there you go.

Well, it could be rather painful to use those features with static
typing. Dynamic typing is more of a side-effect of dynamic
language features than it is the defining characteristic.

Here are a few concepts often associated with dynamic languages
(though, many are creeping into static languages now too):

reflection, dynamic modification of behavior, garbage
collection, portability/mobility, dynamic first-class namespaces,
explicit meta-models, optional/pluggable type systems, incremental
compilation of running software systems...

Here's a tiny, semi-random collection of snippets for further reading,
there are plenty more out there:
 
 
 

I particularly like this quote:

"The notion of custom-built "little languages" goes all the way back to
Lisp and Smalltalk, as ultimately everything related to dynamic
languages does. It's one of those deeply elegant principles that can
take decades to unfold."

 

Ride the wave, change the universe,
Allison

Re: [perl #39711] [TODO] Make PIR->PBC reentrant

[Audrey Tang]

在 2006/7/5 上午 3:06 時，Allison Randal 寫到：


Audrey Tang wrote:


But I guess this bug ticket is not an appropriate place...


Indeed. We need a "Document :immediate" ticket.


I already filed that as #39716 a few hours ago; also #39715 and  
#39714, as per your suggestion:


[TODO] Document IMCC's :immediate feature
[TODO] IMCC errors should throw Parrot exceptions
[TODO] Refactor IMCC to remove static globals

As I cannot modify links on rt.perl.org, can you do that for me?

Thanks,
Audey

PGP.sig
Description: This is a digitally signed message part

[perl #39711] [TODO] Make PIR->PBC reentrant

[via RT]

# New Ticket Created by  Audrey Tang 
# Please include the string:  [perl #39711]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39711 >


Currently, if you use IMCC inside embedded parrot (eg. when compiling  
via PGE), when a syntax error occurs, imcc calls Parrot_exit (or  
downright exit() -- see imclexer.c)), and it terminates the  
interpreter right there without any chance of recover.

However, we can't easily make that throwing an exception, because  
IMCC currently relies on a lot of static globals to carry state, and  
cannot reliably restore them when an error occurs.  (grep for  
"static" and "FIXME global" in the IMCC tree.)

Moreover, the :immediate feature, currently unused (except to load  
dynamic lex pad, as a backdoor workaround for the design) and  
undocumented, allows running arbitrary code inside the .pir->.pbc  
emitter; that means each .pir compilation can potentially affect the  
state of the environment.

In short, a .pir file can compile to drastically different .pbc file,  
depending on the phase of the moon, etc.

Currently in all Parrot-targetting languages, only Perl 6 has that  
kind of evaluation-during-compilation feature, via its BEGIN block;  
however, due to Perl 6's doctrine of separate compilation, the BEGIN  
block has be compiled separately as another .pbc anyway; that means  
nobody has a legitimate use of :immediate at this point.

I argue that :immediate should be retired, and static globals should  
be removed from IMCC.  There is no drawback (as currently there are  
no real uses and it's undocumented), and the benefits are:

- External non-parrot tools can manipulate .pir without exposing  
themselves to the security risks of carrying a full Parrot interpreter.
- IMCC can regain the ability to compile .pir to .pasm.
- It will be safe to recover from a .pir parsefail for Parrot embedders.
- .pir->.pbc is made into a deterministic process, which makes .pir  
fingerprinting possible.

Thanks,
Audrey










PGP.sig
Description: PGP signature

Re: [perl #39711] [TODO] Make PIR->PBC reentrant

[Allison Randal]

Audrey Tang wrote:
> 
> But I guess this bug ticket is not an appropriate place...

Indeed. We need a "Document :immediate" ticket.

Vishal is doing a fantastic job putting the IMCC bugs into RT. And that
pretty much wraps up this ticket (except as a parent for the others).

Thanks,
Allison

Re: [svn:parrot-pdd] r13151 - in trunk: . docs/pdds

[Allison Randal]

Bob Rogers wrote:

   If, as seems likely, exception bookkeeping is moved to a separate
stack in the interpreter (with or without dynamic-wind actions), then
C/C addresses can stay in the Parrot_Context, and all of
pdd23_exceptions.pod that is quoted below ceases to be problematic.
Does that seem reasonable?


Yeah, that's the current best solution (the last time Chip and I talked 
on Saturday). I'd like avoid a stack entirely, but this is a 
straightforward first attack on the problem. If we implement a separate 
exception stack now and run into problems, we can refine and refactor later.


It's an encouraging sign that we've got hold of a good idea when the 
same solution occurs to others independently. :)


Thanks,
Allison

Re: More on the TAP::Grammar

[Michael G Schwern]

On 7/4/06, Ovid <[EMAIL PROTECTED]> wrote:

Because we're discarding anything which does not look like a plan or a test line


Don't discard them, just pass them through unaltered.  Don't want to
lose any information.  The /^#/ lines should be marked as comments.
Anything else is marked as junk but still passed through.



Currently there are some assumptions I'm making, some of which I think are 
wrong.

1.  The lexer croaks() if the planned tests and the actual tests don't match.  
I assume this behavior should be handled elsewhere?


Doesn't sound like a lexer's job.  Sounds more like the parser's.



2.  Croaks if numbered and non-numbered tests are mixed:

   ok 1 - This is a test.
  ok  This is only a test
  not ok 3 - Had this been an actual emergency ...
  ok still don't have a number


This is perfectly ok.  A virtual number is assigned.

This would be bad:

ok 1
ok
ok
ok 3

But again, parser's job.



3.  Croaks if the tests are numbered but the numbers are out of sequence.


Also sounds like the parser's job.



4.  Croaks if planned tests are a test number are less than one.


1..0 is a skip all.

Also, parser's job.



Questions:

1.  Are non-integers allowed for test numbers?  I know this has been proposed 
for groups of tests.


It may have been proposed, but it is not currently allowed.



2.  Is there a plan at some point to allow for test failure output to be 
officially incorporated in TAP?


Yes.  It will not be in the form of comments.



I know we discard that *now*, but in the future, people with a GUI are going to 
want to click on a failure and see:

  not ok 3 - Had this been an actual emergency ...
   #   Failed test 'Had this been an actual emergency ...'
  #   in foo.t at line 5.
  #  got: '42'
 # expected: 'answer'

Instead of:

  not ok 3 - No more info, sucks to be you.


They can still see that if you pass the comments through the
lexer/parser unaltered and allow the GUI to do whatever they like with
it.



Next, what interface do you want?  I'm thinking something like this:

  my $parser = TAP::Parser->new({
newlines => 1, # add newlines to output


I don't understand what this option would do. What does a parser output?



version => $optional_version_number
  });
  $parser->parse($tap); # croaks if it can't


What is $tap?  A string?  Then it can't parse a stream like we do now.



  print $parser->plan;
  foreach my $line ( $parser->test_lines ) {
print $line;
  }


What work is the parser doing here if all you get is the original line
spat back?