Re: parrot tests failing on Darwin

[Yuval Kogman]

On Sun, Oct 09, 2005 at 14:15:08 -0700, chromatic wrote:
> On Sun, 2005-10-09 at 17:25 +0200, Yuval Kogman wrote:
> 
> > Odd, I wonder why diagnosis are emitted on STDERR (or something else
> > maybe).
> 
> That's where Test::Builder emits them.  Test::Harness never collected
> them or parsed them until recently.
> 
> It's fairly difficult to decide whether a diagnostic is part of a
> specific test, so my guess is that writing them to a separate filehandle
> avoided that issue.

/me didn't realize that...

Pug's Test.pm emits to STDOUT, and since I saw the handles in Straps
I used them like that.

In TTH any diag after a test case is glued on to that test, and
any diag happening before any test has it's own little grey block.

I guess I thought that was Good Enough(tm)

> I think it would be useful in general, but it's not a guarantee that all
> of the information is useful or that any heuristic to identify the
> utility of any specific diagnostic would be correct.

Arguably it's a good idea if the test writers keep in mind that
emitting silly diags is not a good practice if they don't have to do
with why a test fails.

I'd like to request a feature for Test::Builder to make diag
optionally go to STDOUT, controlled via an environment variable as
well as a global var or method call to the builder singleton, since
it's the behavior I expect in all the tests I write. Right now you
can set the failure_output handle (right?) but there is no easy way
to say diag_to_stdout.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me dodges cabbages like macalypse log N: neeyah!



pgpZtKy70e7US.pgp
Description: PGP signature

Smoke not accepted from cygwin

[Nick Glencross]

Guys,

I have tried to submit a smoke from cygwin, but the server does not 
accept the smoke file (which I've attached).


Can someone in-the-know about what criteria the server uses shed any 
light on it? I note that the file is bzip'd whereas on Linux it is gzip'd.


For the record, after running Configure I replaced the Makefile in 
dynclasses with 'all:' to allow the build to complete. This does not 
affect the coverage of the tests.


Thanks,

Nick


/usr/bin/perl t/harness --html

# Failed test (t/op/trans.t at line 307)
#  got: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# ok 6
# ok 7
# ok 8
# ok 9
# ok 10
# ok 11
# ok 12
# ok 13
# ok 14
# ok 15
# ok 16
# not 0.00ok 17
# '
# expected: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# ok 6
# ok 7
# ok 8
# ok 9
# ok 10
# ok 11
# ok 12
# ok 13
# ok 14
# ok 15
# ok 16
# ok 17
# '
# Looks like you failed 1 test of 19.

# Failed test (t/pmc/signal.t at line 87)
#  got: 'start
# never
# '
# expected: 'start
# '
# './parrot.exe  "/tmp/parrot/t/pmc/signal_1.pasm"' failed with exit 
code 72057594037927935

# Looks like you failed 1 test of 3.

# Failed test (t/library/pcre.t at line 33)
#  got: 'ok 1
# Couldn't load 'libpcre': No such file or directory
# assertion 
"(interpreter->ctx.bp->pmc_reg.registers[cur_opcode[2]])->pmc_ext" 
failed: file "ops/core.ops", line 1195

# '
# expected: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# '
# Looks like you failed 1 test of 1.
smoke.html has been generated.
/usr/bin/perl util/smokeserv-client.pl smoke.html
* smokeserv-client v0.4 started.
* Bzip2 compression on
* Reading smoke "smoke.html" to upload... ok.
* Sending data to smokeserver "http://smoke.parrotcode.org/smoke/";... 
error: The submitted smoke does not look like a smoke!

make: *** [smoke] Error 1

Re: Smoke not accepted from cygwin

[Nick Glencross]

Strange, something has stripped the attachment (I didn't forget to 
attach it, honest!). I'll try again in a few hours using SMTP instead of 
NNTP.


Nick


Nick Glencross wrote:


Guys,

I have tried to submit a smoke from cygwin, but the server does not 
accept the smoke file (which I've attached).


Can someone in-the-know about what criteria the server uses shed any 
light on it? I note that the file is bzip'd whereas on Linux it is gzip'd.


For the record, after running Configure I replaced the Makefile in 
dynclasses with 'all:' to allow the build to complete. This does not 
affect the coverage of the tests.


Thanks,

Nick


/usr/bin/perl t/harness --html

# Failed test (t/op/trans.t at line 307)
#  got: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# ok 6
# ok 7
# ok 8
# ok 9
# ok 10
# ok 11
# ok 12
# ok 13
# ok 14
# ok 15
# ok 16
# not 0.00ok 17
# '
# expected: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# ok 6
# ok 7
# ok 8
# ok 9
# ok 10
# ok 11
# ok 12
# ok 13
# ok 14
# ok 15
# ok 16
# ok 17
# '
# Looks like you failed 1 test of 19.

# Failed test (t/pmc/signal.t at line 87)
#  got: 'start
# never
# '
# expected: 'start
# '
# './parrot.exe  "/tmp/parrot/t/pmc/signal_1.pasm"' failed with exit 
code 72057594037927935

# Looks like you failed 1 test of 3.

# Failed test (t/library/pcre.t at line 33)
#  got: 'ok 1
# Couldn't load 'libpcre': No such file or directory
# assertion 
"(interpreter->ctx.bp->pmc_reg.registers[cur_opcode[2]])->pmc_ext" 
failed: file "ops/core.ops", line 1195

# '
# expected: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# '
# Looks like you failed 1 test of 1.
smoke.html has been generated.
/usr/bin/perl util/smokeserv-client.pl smoke.html
* smokeserv-client v0.4 started.
* Bzip2 compression on
* Reading smoke "smoke.html" to upload... ok.
* Sending data to smokeserver "http://smoke.parrotcode.org/smoke/";... 
error: The submitted smoke does not look like a smoke!

make: *** [smoke] Error 1

Re: [perl #36452] Re: [BUG] PGE recursion, bus error

[Patrick R. Michaud]

On Sun, Oct 09, 2005 at 09:55:44AM -1000, Joshua Hoblitt wrote:
> > > What is the status of this bug?  Should this be a PGE todo item?
> > 
> > My opinion is that it's "not a bug" -- the normal behavior for
> > most programs with infinite recursive loops is that they
> > eventually explode.  
> 
> Sounds reasonable.  I'm sure it would be nearly impossible to catch all
> possible cases of infinite recursion when the grammar is compiled but
> how difficult would it be to trap at runtime?  A simple warning along
> the lines of "Warning: production foo has recursed 10,000 times without
> matching any terminal\n" would certainly be useful in figuring why it
> blew up...

We can enter "trap recursions without terminals" as a possible PGE
todo item, but unless someone knows an easy implementation or wants 
to take on the task of implementation it's not likely to be resolved
anytime soon.  :-)

Pm

Re: [perl #27003] bytecode (header?) problem in tru64/alpha

[Jarkko Hietaniemi]

Joshua Hoblitt via RT wrote:
>>[doughera - Thu Oct 06 07:21:15 2005]:
>>
>>I think this bug can be closed.  I just got those tests to pass on 
>>Sparc/Solaris 8 with gcc -m64 -mcpu=v9.  (Mind you lots of other tests 
>>fail, but that's a separate problem.)
>>
>>
>>
> 
> 
> Jarrko,
> 
> Are you OK with closing this bug now?
> 
> -J

Yeah.

> 
> 

[perl #37399] [PATCH] fix imcc tests with bison >= 1.75c

[via RT]

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


This transaction appears to have no contentAccording to the Bison Changlog, the error string "parse error" was
changed to "syntax error" in bison 1.75c.  I haven't tried that version
but can confirm that it has changed in 1.875.

This patch adds a note about this to the top of imcc/imcc.y and changes
the tests accordingly.  If this patch is applied, the rebuild version of
these files would also need to checked-in:

imcparser.c
imcparser.h
imclexer.c

Comments?

-J

--
Index: imcc/imcc.y
===
--- imcc/imcc.y (revision 9425)
+++ imcc/imcc.y (working copy)
@@ -8,6 +8,11 @@
  *
  * Grammar for the parser.
  *
+ * This file should be processed with bison 1.75c or later.  Version 1.75c
+ * changed the error message string "parse error" to "syntax error" to be more
+ * compatible with POSIX.  Earlier versions will work but the tests in
+ * t/syn/const.t will fail because of the difference in error strings.
+ *
  */
 
 #include 
Index: imcc/t/syn/const.t
===
--- imcc/t/syn/const.t  (revision 9425)
+++ imcc/t/syn/const.t  (working copy)
@@ -263,7 +263,7 @@
 print $S0
 .end
 CODE
-/^error:imcc:parse error, unexpected SHIFT_LEFT.*/
+/^error:imcc:syntax error, unexpected SHIFT_LEFT.*/
 OUT
 
 
@@ -278,7 +278,7 @@
 print $S0
 .end
 CODE
-/^error:imcc:parse error, unexpected SHIFT_LEFT.*/
+/^error:imcc:syntax error, unexpected SHIFT_LEFT.*/
 OUT
 
 
@@ -294,7 +294,7 @@
 print $S0
 .end
 CODE
-/^error:imcc:parse error, unexpected SHIFT_LEFT.*/
+/^error:imcc:syntax error, unexpected SHIFT_LEFT.*/
 OUT
 
 
@@ -309,7 +309,7 @@
 print $S0
 .end
 CODE
-/^error:imcc:parse error, unexpected SHIFT_LEFT.*/
+/^error:imcc:syntax error, unexpected SHIFT_LEFT.*/
 OUT
 
 
@@ -325,7 +325,7 @@
 print $S0
 .end
 CODE
-/^error:imcc:parse error, unexpected SHIFT_LEFT.*/
+/^error:imcc:syntax error, unexpected SHIFT_LEFT.*/
 OUT
 
 
@@ -386,7 +386,7 @@
 print $S0
 .end
 CODE
-/^error:imcc:parse error, unexpected SHIFT_LEFT.*/
+/^error:imcc:syntax error, unexpected SHIFT_LEFT.*/
 OUT
 
 


pgpHlBzBdRLw4.pgp
Description: PGP signature

Re: Smoke not accepted from cygwin

[Nick Glencross]

Here (hopefully) is the generated smoke file which might hold some clues...

Nick

Nick Glencross wrote:




Guys,

I have tried to submit a smoke from cygwin, but the server does not 
accept the smoke file (which I've attached).


Can someone in-the-know about what criteria the server uses shed any 
light on it? I note that the file is bzip'd whereas on Linux it is 
gzip'd.


For the record, after running Configure I replaced the Makefile in 
dynclasses with 'all:' to allow the build to complete. This does not 
affect the coverage of the tests.


Thanks,

Nick

Re: Sane (less insane) pair semantics

[Stuart Cook]

On 10/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> So to pass a hash that has one element requires using the hash
> keyword?

I don't see a hash in your example, so I'm not sure what you're
referring to here.

> Specifically, if I say:
>
>   @args = (a => 1, get_overrides());
>
> Then can I say
>
>   foo([EMAIL PROTECTED]);

Not if you want that a=>1 to be a named argument.

Under the proposal, the only ways to pass a named argument are:
1) By using a literal pair in the syntactic top-level of the arg list
2) By splatting a pair, hash, or arg-list-object

> Or will I, in the case of no overrides, get a positional pair instead of
> named a =>1 ?

The overrides have nothing to do with it.  That a=>1 will *always* be
a positional, because by the time it reaches the argument list, it's a
value (not a syntactic form).  The only way to use a pair-value as a
named argument is to splat it directly, or splat a hash or
arg-list-object containing it.  Splatting an array *never* introduces
named arguments, only positionals.


Stuart

[perl #37401] [PATCH] README.win32

[Joshua Hoblitt via RT]

> [EMAIL PROTECTED] - Sun Oct 09 23:46:41 2005]:
> 
> Hi,
> 
> Attached is a patch to change the spelling of librairies to libraries.
> 
> Michael Cartmell
> Network & Operating Systems Analyst
> Lawpoint
> Thomson Legal & Regulatory Limited  (ABN 64 058 914 668)
> Ph +61 2 9239 4958Fax   +612 9239 4900Toll Free: 1800 036 186
> E-mail [EMAIL PROTECTED]
> Web: www.thomson.com.au.
> 
>  
> 
> 

Applied as r9430.  Thanks.

Ps.  No need to compress patches in the future.

-J

Re: Sane (less insane) pair semantics

[Juerd]

Stuart Cook skribis 2005-10-10 22:58 (+1100):
> >   @args = (a => 1, get_overrides());
> >   foo([EMAIL PROTECTED]);
> Not if you want that a=>1 to be a named argument.
> Under the proposal, the only ways to pass a named argument are:
> 1) By using a literal pair in the syntactic top-level of the arg list
> 2) By splatting a pair, hash, or arg-list-object

I find this counterintuitive, and also want arrays to be included in
option 2.

It is consistent with the idea that * expands its RHS and evaluate it as
if it was written literally.

I'd like @_ or @?ARGS or something like that to be a *-able array that
will be guaranteed to be compatible with the current sub's signature.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: [perl #36452] Re: [BUG] PGE recursion, bus error

[Matt Fowles]

Patrick~

On 10/9/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 09, 2005 at 09:55:44AM -1000, Joshua Hoblitt wrote:
> > > > What is the status of this bug?  Should this be a PGE todo item?
> > >
> > > My opinion is that it's "not a bug" -- the normal behavior for
> > > most programs with infinite recursive loops is that they
> > > eventually explode.
> >
> > Sounds reasonable.  I'm sure it would be nearly impossible to catch all
> > possible cases of infinite recursion when the grammar is compiled but
> > how difficult would it be to trap at runtime?  A simple warning along
> > the lines of "Warning: production foo has recursed 10,000 times without
> > matching any terminal\n" would certainly be useful in figuring why it
> > blew up...
>
> We can enter "trap recursions without terminals" as a possible PGE
> todo item, but unless someone knows an easy implementation or wants
> to take on the task of implementation it's not likely to be resolved
> anytime soon.  :-)

The theoretical implementation of this is quite simple.  Keep a
counter. everytime a token is consumed from the input stream reset it.
 Every time a rule is followed increment the counter.  If the counter
is ever greater than the number of productions in the grammer, then
you have gone into infinite recursion.  The only place where this
technique will fail is where a rule that it is attempting to match
changes dynamically (i.e. mid match).  In such an event you have to
consider the number of productions infinite.

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

[perl #37402] [PATCH] parrot-config.imc documentation is missing ".imc" suffixes

[via RT]

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


The "SYNOPSIS" section within parrot-config.imc is missing the ".imc"
suffixes. This patch adds them to the three places where they are
required.

Index: parrot-config.imc
===
--- parrot-config.imc	(revision 9428)
+++ parrot-config.imc	(working copy)
@@ -8,9 +8,9 @@
 
 =head1 SYNOPSIS
 
-  ./parrot parrot-config VERSION
-  ./parrot parrot-config ccflags
-  ./parrot parrot-config --dump
+  ./parrot parrot-config.imc VERSION
+  ./parrot parrot-config.imc ccflags
+  ./parrot parrot-config.imc --dump
 
 =head1 AUTHOR
 

Re: Sane (less insane) pair semantics

[Juerd]

Juerd skribis 2005-10-10 15:20 (+0200):
> only pairs on the topmost level of arguments (not in any parens) are

s/not in any parens/not in any grouping parens/, to exclude .()


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Sane (less insane) pair semantics

[Miroslav Silovic]

[EMAIL PROTECTED] wrote:


Stuart Cook skribis 2005-10-10 22:58 (+1100):
 


 @args = (a => 1, get_overrides());
 foo([EMAIL PROTECTED]);
 


Not if you want that a=>1 to be a named argument.
Under the proposal, the only ways to pass a named argument are:
1) By using a literal pair in the syntactic top-level of the arg list
2) By splatting a pair, hash, or arg-list-object
   



I find this counterintuitive, and also want arrays to be included in
option 2.
 


How would you splat an array of pairs if you want to preserve the pairs?


It is consistent with the idea that * expands its RHS and evaluate it as
if it was written literally.

I'd like @_ or @?ARGS or something like that to be a *-able array that
will be guaranteed to be compatible with the current sub's signature.

 

This sounds nice, though. Maybe it suggests that the 'named splat' 
should be something other than *?


   Miro

Re: Sane (less insane) pair semantics

[Juerd]

Miroslav Silovic skribis 2005-10-10 15:04 (+0200):
> >>Under the proposal, the only ways to pass a named argument are:
> >>1) By using a literal pair in the syntactic top-level of the arg list
> >>2) By splatting a pair, hash, or arg-list-object
> >I find this counterintuitive, and also want arrays to be included in
> How would you splat an array of pairs if you want to preserve the pairs?

By adding parens, because by this proposal (if I read it correctly),
only pairs on the topmost level of arguments (not in any parens) are
parsed as named arguments.

foo(([EMAIL PROTECTED]));
foo ([EMAIL PROTECTED]);

This doesn't allow for combining named and positional pairs. I do not
think that is necessary at all, for arrays. I think that combining
the two on the same level is a recipe for disaster anyway, and should
perhaps even emit a warning.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

[perl #37401] [PATCH] README.win32

[via RT]

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


Hi,

Attached is a patch to change the spelling of librairies to libraries.

Michael Cartmell
Network & Operating Systems Analyst
Lawpoint
Thomson Legal & Regulatory Limited  (ABN 64 058 914 668)
Ph +61 2 9239 4958  Fax   +612 9239 4900Toll Free: 1800 036 186
E-mail [EMAIL PROTECTED]
Web: www.thomson.com.au

 


README.win32.diff.gz
Description: GNU Zip compressed data

Re: [perl #34669] [TODO] IMCC - make imcc.l compatible with modern flex

[Chip Salzenberg]

On Sun, Oct 09, 2005 at 08:41:32PM -0700, Joshua Hoblitt via RT wrote:
> It works with flex version 2.5.4 - is that new enough? ;)

Sorry, that's the old one.  The new one is 2.5.31 or so.

Yes, the maintainers of flex made an incompatible change in the middle
of the 2.5.* version series.  Grr.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #36452] Re: [BUG] PGE recursion, bus error

[Matt Fowles]

Patrick~

On 10/10/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 10, 2005 at 09:11:02AM -0400, Matt Fowles wrote:
> > Patrick~
> >
> > The theoretical implementation of this is quite simple.  Keep a
> > counter. everytime a token is consumed from the input stream reset it.
> >  Every time a rule is followed increment the counter.  If the counter
> > is ever greater than the number of productions in the grammer, then
> > you have gone into infinite recursion.
>
> What happens with something like:
>
> rule atom { A }
> rule binary { .  |  \*  }
> rule expr {  }
>
> "AB" ~~ /  /
>
> Here, the '.' in  keeps "consuming" the initial "A" (thus
> resetting the counter), but the  rule fails, so we take
> the alternation which recurses back to  and does the whole
> thing all over again (with the counter having been reset to zero).
> So I guess we'd need to backtrack the counter as well...?
>
> Perhaps what we want to be watching is "positions", so that we detect
> when the depth of nested subrules activated from a common input position
> is greater than the total number of defined rules?
>
> And, of course, in the case of rules containing closures, all bets
> should be off for detecting infinite recursion, since the closure
> could be handling the termination of the recursion based on some
> criteria other than tokens consumed from the input stream.  (But it's
> also probably easy to know when we've executed a closure and thus
> disable the check for infinite recursion when that happens.)

You are right about backtracking, rather than a simple counter we need
to keep track of the current recursion depth from a particular
position.  I agree that we would have to disable this for rules
containing code.  Perhaps a better approach would be to perform a bit
of static analysis on the grammar and look for left recursions at
creation time (I believe that is a known problem).  Then we can just
warn once up front and go on our merry way recursing at matchtime.

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

Re: Sane (less insane) pair semantics

[Larry Wall]

Interestingly, I had already written almost exactly the same thing
into my version of S06, but I've been holding off on checking it in
while I mull over Luke's theory theory.  Regardless of the actual
syntax we end up with, I think everyone can assume that the compiler
will be able to determine at compile time which pairs are intended
to be named arguments and which ones positional parameters, and pass
them as separate entities through whatever structure supplies all the
arguments to a call so that the caller doesn't have to worry about
making the distinction based on type.

It still has to figure out how to reconcile the named arguments
with the positional parameters, of course, unless someone has
made sufficient representation to the compiler that all calls to
a particular short name have particular named parameters that are
guaranteed to be in the same position everywhere, in which case the
compiler is allowed to simply translate them to positionals on the
call end.

Perhaps it would be useful to allow a stubbed multi to declare the
required names of positional parameters in some scope or other.  This
might be generalized to a translation service for calls outside the
scope, where the current scope could even be the current language
as a whole.  That might alleviate cultural differences if one language
always uses $left and $right where another uses x and y, for instance.

Of course, I haven't eaten breakfast yet, so maybe that's impossible.

Larry

Re: Sane (less insane) pair semantics

[Austin Hastings]

Stuart Cook wrote:

>On 10/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
>  
>
>The overrides have nothing to do with it.  That a=>1 will *always* be a 
>positional, because by the time it reaches the argument list, it's a value 
>(not a syntactic form).  The only way to use a pair-value as a named argument 
>is to splat it directly, or splat a hash or arg-list-object containing it.  
>Splatting an array *never* introduces named arguments, only positionals.
>  
>

That seems like a huge error. Arrays are the only thing (that I know of)
that can store the positional part of an arglist as well as storing the
pairs. If there's not some mechanism for getting the entire arglist, and
if there's not some simple inversion of that simple mechanism for
passing the args along to some other victim, then ... well ... I don't
know. But it's bad!

So since you keep saying "arg-list-object" as though it was something
not an array, I'll bite:

What's an arg-list-object, and how is it different from an array?


=Austin

Re: [perl #36452] Re: [BUG] PGE recursion, bus error

[Matt Fowles]

Patrick~

On 10/10/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 10, 2005 at 10:45:54AM -0400, Matt Fowles wrote:
> > Perhaps a better approach would be to perform a bit
> > of static analysis on the grammar and look for left recursions at
> > creation time (I believe that is a known problem).  Then we can just
> > warn once up front and go on our merry way recursing at matchtime.
>
> I think this approach falls back into my category of
> "unless someone wants to take on the task of implementation it's not
> likely to be resolved anytime soon..."  :-) :-)
>
> In a dynamic environment like the one we have (parrot/perl) I find it's
> really hard to say what constitutes "creation time", especially since
> we can refer to subrules dynamically ( <$foo>, <::$foo>, etc. ) and
> our grammars have inheritance in which a rule defined by a parent
> grammar can invoke a rule defined later in a child grammar.  As with
> closures, we could probably punt on performing any analysis of
> rules with dynamic references or that refer to rules outside of
> the current grammar.  But given that we can't really know until
> matchtime what subrule will be invoked by an expression like ,
> it's hard for me to imagine a whole lot we can do in the way of
> static analysis beforehand.  However, that could easily just be a
> limit of my imagination.

I completely forgot about inheritance.  That basically throws static
analysis out the window.

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

Re: Type annotations

[TSa]

HaloO,

I fear I'm addicted...

Luke Palmer wrote:

On 10/7/05, chromatic <[EMAIL PROTECTED]> wrote:


On Fri, 2005-10-07 at 17:43 -0600, Luke Palmer wrote:



No, you can't overload assignment at runtime because you can't
overload assigment at any time, so says the language spec (well, not
any formal spec; so says Larry as far as I remember).


Again, I don't care *how* I accomplish it, as long as I don't have to
root around in the source code of Perl 6 itself to make it work.



That's easy.  Define coerce: (Int --> Array) {...}.  Don't define
it after CHECK is run.


But that makes MMD at most a second class concept.
Worse is that this hinders the concrete formulation
of abstract concepts into which designers can hook their
stuff. Assignment to me is a non-commutative, or if you
like that better, asymmetric binary operator. The asymmetry
beeing that the LHS takes the burden to keep the connection
to the value of the RHS at that time.

I call the thing that Larry wants to preserve a slot call.
That is

  $x = $y;

actually means

  $x.STORE( $y.FETCH );

where I would write the .STORE and .FETCH methods with
adverbial pair syntax :STORE and :FETCH because they
are looked up from the things that $x and $y contain or
refer to at runtime while the dot forms are dispatched
on the type. In other words the generated code is different
in both cases. But usually the net result is the same because
the .STORE method has the same targets for the usual types
of $x as the vtbls that different types of $x carry around.

BUT you can break that symmetry *either* by changing the entries
in the method *or* some vtbls! And if you want to base your
decision which route to take on *both* the participants you
write a *multi* method for infix:{'='}.

And only if none of the above is satisfactory messing with the
parser/grammar should be considered. I have the impression that
Perl 6 pulls out this rather heavy-weight tool too early in many
cases.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: [perl #37399] [PATCH] fix imcc tests with bison >= 1.75c

[Leopold Toetsch]

Joshua Hoblitt (via RT) wrote:


According to the Bison Changlog, the error string "parse error" was
changed to "syntax error" in bison 1.75c.  I haven't tried that version
but can confirm that it has changed in 1.875.


Or: unify the printed message in IMCC_fataly

Or: as these are regexen anyway ...


-/^error:imcc:parse error, unexpected SHIFT_LEFT.*/
+/^error:imcc:syntax error, unexpected SHIFT_LEFT.*/


... just test for (parse|syntax)

leo

Re: Sane (less insane) pair semantics

[Austin Hastings]

Miroslav Silovic wrote:

> [EMAIL PROTECTED] wrote:
>
>> * expands its RHS and evaluate it as if it was written literally.
>>
>> I'd like @_ or @?ARGS or something like that to be a *-able array that
>> will be guaranteed to be compatible with the current sub's signature.
>>
> This sounds nice, though. Maybe it suggests that the 'named splat'
> should be something other than *?


How about "perl should DWIM"? In this case, I'm with Juerd: splat should
pretend that my array is a series of args.

So if I say:

foo [EMAIL PROTECTED];

or if I say:

foo([EMAIL PROTECTED]);

I still mean the same thing: shuck the array and get those args out
here, even the pairs.

It's worth pointing out that perl does know the list of declared named
args, though that may not be enough. If the pair.key matches an expected
arg, then splat should collapse it for sure. If it doesn't match...I dunno.

Is there a list() operator for converting hashes into lists of pairs?
That might make parsing foo([EMAIL PROTECTED], *%_) more palatable, but I'd 
still
prefer to get pairs in @_ if I don't explicitly ask for *%_...

=Austin

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Austin Hastings wrote:
> How about "perl should DWIM"? In this case, I'm with Juerd: splat
> should pretend that my array is a series of args.

Yep.

> So if I say:
> 
> foo [EMAIL PROTECTED];
> 
> or if I say:
> 
> foo([EMAIL PROTECTED]);
> 
> I still mean the same thing: shuck the array and get those args out
> here, even the pairs.

Right, you name it: you get *pairs* out of the array, not named
parameters. Under the proposal, a Pair object doesn't have any special
magic -- it's simply

class Pair { has $.key; has $.value is rw }

Thus:

my @array = (42, "hi", (a => 23));
foo [EMAIL PROTECTED];  # same as

foo 42, "hi", (a => 23);  # three positional params (Int, Str, Pair)

> It's worth pointing out that perl does know the list of declared named
> args, though that may not be enough. If the pair.key matches an
> expected arg, then splat should collapse it for sure. If it doesn't
> match...I dunno.

But that's exactly the problem. You shouldn't have to worry about any
special magic when dealing with [EMAIL PROTECTED] Consider:

sub foo ($a, $b, $c, ?$d) {...}

my @array = (1, 2, (key => "value"));
foo [EMAIL PROTECTED];  # fine, no problem, $c will receive (key => "value")

my @array = (1, 2, (d => "value"));
foo [EMAIL PROTECTED];  # oops! $a = 1, $d = "value"
  # "Required argument 'c' not given!"

> Is there a list() operator for converting hashes into lists of pairs?

my @array_of_pairs = %hash;  # short for
my @array_of_pairs = list %hash;


--Ingo

Re: Sane (less insane) pair semantics

[Dave Whipp]

Austin Hastings wrote:


How about "perl should DWIM"? In this case, I'm with Juerd: splat should
pretend that my array is a series of args.

So if I say:

foo [EMAIL PROTECTED];

or if I say:

foo([EMAIL PROTECTED]);

I still mean the same thing: shuck the array and get those args out
here, even the pairs.


The trouble is, an array doesn't contain enough information:

Compare:
  foo( (a=>1), b=>2 );

With
  @args = ( (a=>1), b=>2 );
  foo( [EMAIL PROTECTED] );

If we have an arglist ctor, then we could have

  @args = arglist( (a=>1), b=>2 );
  foo( [EMAIL PROTECTED]);

  say @args.perl
## (
##   (a=>1) but is_positional,
##   (b=>2) but is_named,
## )


but without such a constructor, it would be difficult to DWIM correctly.

Of course, for the case of $?ARGS, constructing the array with 
appropriate properties wouldn't be a problem.

Re: Sane (less insane) pair semantics

[Mark Reed]

On 2005-10-10 13:36, "Ingo Blechschmidt" <[EMAIL PROTECTED]> wrote:
> Under the proposal, a Pair object doesn't have any special
> magic 

Right.  So under this proposal, the "key => value" syntax is overloaded: in
some contexts it creates a Pair object, and in others it assigns a value to
a named parameter, and parentheses are the disambiguating mechanism to get
the former behavior in the latter context.  Meanwhile, a reference to a Pair
object occurring in an argument list does not interact with the
named-parameter mechanism at all.

At least, not by default.  It would be desirable to have a way to flatten a
hash/list of Pairs/whatever in such a way that it *does* map key names to
named parameters.

Re: Sane (less insane) pair semantics

[Juerd]

Ingo Blechschmidt skribis 2005-10-10 19:36 (+0200):
> my @array = (42, "hi", (a => 23));

It is worth pointing out that the inner parens here are merely for
grouping: this information is lost afterwards, hence this:

> foo [EMAIL PROTECTED];  # same as

shouldn't be

> foo 42, "hi", (a => 23);  # three positional params (Int, Str, Pair)

but instead

foo 42, "hi", a => 23  # two positional args, one named.

OR pairs need to remember whether they were originally in parens. This
is very doable, but whether we want or need it is very arguable.

(Very little sidenote: parameters are expected, arguments are passed. In
the signature, you have parameters, in the call, you have arguments.
However, in the case of a named argument, it does make some sense to
call the name parameter and the value argument, resulting in having both
in the call.)


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Mark Reed wrote:
> On 2005-10-10 13:36, "Ingo Blechschmidt" <[EMAIL PROTECTED]> wrote:
>> Under the proposal, a Pair object doesn't have any special
>> magic
> 
> Right.  So under this proposal, the "key => value" syntax is
> overloaded: in some contexts it creates a Pair object, and in others
> it assigns a value to a named parameter, and parentheses are the
> disambiguating mechanism to get
> the former behavior in the latter context.  Meanwhile, a reference to
> a Pair object occurring in an argument list does not interact with the
> named-parameter mechanism at all.

Exactly.

> At least, not by default.  It would be desirable to have a way to
> flatten a hash/list of Pairs/whatever in such a way that it *does* map
> key names to named parameters.

Yep:

foo *%hash;  # keys of %hash taken as named parameters
foo *hash(@array_of_pairs);
 # @array_of_pairs's pairs taken as named parameters


--Ingo

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Dave Whipp wrote:
> Austin Hastings wrote:
>> How about "perl should DWIM"? In this case, I'm with Juerd: splat
>> should pretend that my array is a series of args.
>> 
>> So if I say:
>> 
>> foo [EMAIL PROTECTED];
>> 
>> or if I say:
>> 
>> foo([EMAIL PROTECTED]);
>> 
>> I still mean the same thing: shuck the array and get those args out
>> here, even the pairs.
> 
> The trouble is, an array doesn't contain enough information:
> 
> Compare:
>foo( (a=>1), b=>2 );
> 
> With
>@args = ( (a=>1), b=>2 );
>foo( [EMAIL PROTECTED] );

my @args = ( (a => 1), b => 2 );  # is sugar for
my @args = ( (a => 1), (b => 2) );
# We can't stuff named arguments into an array, only pairs.
# Named arguments are neither objects nor some other data type,
# they're purely syntactical.

> If we have an arglist ctor, then we could have
> 
>@args = arglist( (a=>1), b=>2 );
>foo( [EMAIL PROTECTED]);
> 
>say @args.perl
> ## (
> ##   (a=>1) but is_positional,
> ##   (b=>2) but is_named,
> ## )
> 
> 
> but without such a constructor, it would be difficult to DWIM
> correctly.

Yep, see Luke's tuple proposal [1]:

my $tuple = ( (a => 1), b => 2 );
foo *$tuple;  # same as
foo( (a => 1), b => 2 );  # one positional argument (a Pair) and
  # the named parameter "b"


--Ingo

[1] http://svn.openfoundry.org/pugs/docs/notes/theory.pod
/Tuples

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Juerd wrote:
> Ingo Blechschmidt skribis 2005-10-10 19:36 (+0200):
>> my @array = (42, "hi", (a => 23));
> 
> It is worth pointing out that the inner parens here are merely for
> grouping: this information is lost afterwards, hence this:
> 
>> foo [EMAIL PROTECTED];  # same as
> 
> shouldn't be
> 
>> foo 42, "hi", (a => 23);  # three positional params (Int, Str,
>> Pair)
> 
> but instead
> 
> foo 42, "hi", a => 23  # two positional args, one named.
> 
> OR pairs need to remember whether they were originally in parens. This
> is very doable, but whether we want or need it is very arguable.

Luckily, this is not needed, see my response to Dave [1]:

Because named arguments are purely syntactic (i.e., they are not objects
or some other kind of data type), you can't stuff them into an array
(or a scalar, for that matter).

# (assuming => binds thighter than =)
my $scalar = a => 1;  # sugar for
my $scalar = (a => 1);

my @array = (42, a => 1);  # sugar for
my @array = (42, (a => 1));

Named arguments can -- under the proposal -- only ever exist in calls.


--Ingo

[1] http://www.nntp.perl.org/group/perl.perl6.language/23438

Re: Sane (less insane) pair semantics

[Juerd]

Ingo Blechschmidt skribis 2005-10-10 20:08 (+0200):
> Named arguments can -- under the proposal -- only ever exist in calls.

Which leaves us with no basic datastructure that can hold both
positional and named arguments. This is a problem because in a call,
they can be combined.

An array could hold both, but with only one small and minor
inconvenience: pairs are either all positional, or all named. I
sincerely believe that this is a feature, not a problem, because arrays
are singledimensional, and having pairs mean two different things on the
same level is, as this new proposal also indicates, confusing at best.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Sane (less insane) pair semantics

[Juerd]

Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200):
> my @args = ( (a => 1), b => 2 );  # is sugar for
> my @args = ( (a => 1), (b => 2) );

Please, no. Please let the pair constructor be =>, not (=>). There is
really no need for this operator to consist of both infix and circumfix
parts. Please leave the parens for grouping (and in calls: breaking
recognition).


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: [perl #36119] [PATCH] Reapply execute permissions on dynclasses for HP-UX

[Nick Glencross]

Joshua Hoblitt via RT wrote:


-copy("$_$LOAD_EXT", $dest) or die "Copy $_$LOAD_EXT failed ($?)\n";
+File::Copy::syscopy("$_$LOAD_EXT", $dest) or die "Copy $_$LOAD_EXT failed 
($?)\n";

Certainly on cygwin File::Copy::syscopy also seems to lose execute 
permissions, despite what the manual page might imply. I recall trying 
it before going down the chmod route.


I'll submit a patch this evening which just checks for HP-UX & cygwin.

Nick

Re: [perl #37308] Parrot gobbles up all the memory

[Andy Dougherty]

On Fri, 7 Oct 2005, Leopold Toetsch wrote:

> 
> On Oct 7, 2005, at 20:52, Andy Dougherty wrote:
> 
> > perl Configure.pl --optimize=-O3 --debugging=0 --cc=gcc --ld=gcc
> > --link=gcc
> 
> ...
> Andy slowly please. No --optimize tests yet. Let's first look at plain default
> build.

Why?  --optimize does at least two different things:  First, obviously, it 
allows the compiler to optimize.  This is often a good strategy for 
exposing faulty assumptions in code.  Second, it enables the 
DISABLE_GC_DEBUG define, which changes the sizes of several 
structures, including PMCs and Stack_Chunks.  Changing the sizes of 
those structures can expose alignment and size assumptions.

> > One thing I really don't understand is why the CONTEXT macro has to play
> > the "-1" trick to access memory to the "left".
> 
> There is currently just one base pointer (praise x86 jit). Parrot registers
> are to the right of it, context is at the left side (src/inter_create.c has a
> picture describing this).

I know about the picture.  I don't know why you chose to use a pointer 
pointing to the middle of the structure instead of the beginning.  I'm
afraid "praise x86 jit" doesn't mean anything to me.

> > Similarly, I don't
> > understand why the ALIGNED_CTX_SIZE macro has a NUMVAL_SIZE buried in it,
> > and how that fits in with attempting to do things like p[-1].
> 
> Context + registers are allocated as one chunk. Registers especially the
> FLOATVAL ones have to be aligned at FLOATVAL alignment needs. Therefore there
> can be a gap between the context and the registers. Above macro takes care
> about this fact by increasing the allocation size.

But you don't include the gap in your picture, and the code actually 
assumes that the gap is at the beginning of the chunk, not in the middle 
as you indicate here.  Placing the gap at the beginning allows p[-1] to 
work, but then runs into the problem that the context structures might, in 
principle, be incorrectly aligned.  I also don't know if there are 
any garbage collection issues, since we don't actually carry around a 
pointer to the beginning of the allocated chunk -- but that may 
simply be my ignorance of garbage collection.  

(This isn't an issue now because, at least for the default configuration 
on common architectures, ALIGNED_CTX_SIZE == sizeof(struct 
Parrot_Context), so there actually isn't any padding at all.  Further, 
since the Parrot_Context structure consists of integers and pointers, its 
alignment constraints are easily satisfied.)

If, instead, you allocated a single structure containing both the Context 
plus the registers, then the compiler would correctly ensure all the 
correct padding and compute all the offsets for you.

> I don't think that current failures are related to this at all - see
> explanation for above errors. It's of course true that optimized build will
> cause more troubles, but we'll have a look at these later.

You may well be right, since there is actually 0 padding at present.  
However, the tests in question worked in the trunk before the merge, and 
fail after it, so this was a natural place to look.  Also, alignment 
issues have been at the root of a number of problems in the past, gcc 
warned about aliasing problems with the code in this area, and it was just 
plain puzzling to me.

None of which is terribly urgent to me, however, as I don't expect to have 
time to follow up on this for quite a while.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Juerd wrote:
> Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200):
>> my @args = ( (a => 1), b => 2 );  # is sugar for
>> my @args = ( (a => 1), (b => 2) );
> 
> Please, no. Please let the pair constructor be =>, not (=>). There is
> really no need for this operator to consist of both infix and
> circumfix parts. Please leave the parens for grouping (and in calls:
> breaking recognition).

Err, of course! The parens around "b => 2" should make clear that "b =>
2" is not a named argument, but a pair. Outside of calls, the parens
are only for grouping:

my @args = (b => 2);# same as
my @args = ((b => 2));  # same as
my @args = b => 2;


--Ingo

Re: Sane (less insane) pair semantics

[Uri Guttman]

> "J" == Juerd  <[EMAIL PROTECTED]> writes:

  J> Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200):
  >> my @args = ( (a => 1), b => 2 );  # is sugar for
  >> my @args = ( (a => 1), (b => 2) );

  J> Please, no. Please let the pair constructor be =>, not (=>). There is
  J> really no need for this operator to consist of both infix and circumfix
  J> parts. Please leave the parens for grouping (and in calls: breaking
  J> recognition).

he isn't saying that. the example shows the b => 2 is fine and will be
parsed as if it were ( b => 2 ). the point is how pairs in an array are
splatted or not to names args. and if i get it right, *hash( @args ) is
what is needed to convert an array of pairs to be used as named params.

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Juerd wrote:
> Ingo Blechschmidt skribis 2005-10-10 20:08 (+0200):
>> Named arguments can -- under the proposal -- only ever exist in
>> calls.
> 
> Which leaves us with no basic datastructure that can hold both
> positional and named arguments. This is a problem because in a call,
> they can be combined.

Very true. This is why we need Luke's Tuple proposal [1]. Basically:

my $tuple = (a => 1, (b => 2)):{ ...block... };  # $tuple.isa(Tuple)
# Tuples are ordinary objects -- they can be stored
# in scalars, arrays, etc.

# But splatting tuples unfolds their magic:
foo(*$tuple);  # same as
foo(a => 1, (b => 2)):{ ...block...};
   # named arg "a", positional pair (b => 2),
   # adverbial block { ...block... }

# (Yep, under the current proposal, tuple construction conflicts
# with list/array construction. FWIW, I'd be fine with
# using Tuple.new(...) as the tuple constructor.)


--Ingo

[1] http://svn.openfoundry.org/pugs/docs/notes/theory.pod

Re: [perl #36119] [PATCH] Reapply execute permissions on dynclasses for HP-UX

[Nick Glencross]

Joshua Hoblitt via RT wrote:


As a general comment, 36119 makes me a little nervous as 'chmod' isn't
something you can count on unless your on a POSIX like system and osname
ne 'MSWin32' certainly would encompass non-POSIX systems.  Are you
planning on retool this patch to be more pedantic about platforms?
 

The easiest thing to do is resubmit the patch, as suggested, with 
specific platforms listed. We can then tweak them should more come along.


Thanks,

Nick

Index: config/gen/makefiles/dynclasses_pl.in
===
--- config/gen/makefiles/dynclasses_pl.in   (revision 9438)
+++ config/gen/makefiles/dynclasses_pl.in   (working copy)
@@ -153,6 +153,13 @@
 
 foreach (@ungrouped_pmcs, keys %$group_files) {
 copy("$_$LOAD_EXT", $dest) or die "Copy $_$LOAD_EXT failed ($?)\n";
+
+# Execute permissions on libraries is especially important on
+# some platforms
+if ($^O eq 'hpux' or $^O eq 'cygwin') {
+   chmod 0755, "$dest${slash}$_$LOAD_EXT";
+}
+
 }
 }
 else {

Re: [perl #37399] [PATCH] fix imcc tests with bison >= 1.75c

[Joshua Hoblitt]

On Mon, Oct 10, 2005 at 06:19:12PM +0200, Leopold Toetsch wrote:
> Joshua Hoblitt (via RT) wrote:
> 
> >-/^error:imcc:parse error, unexpected SHIFT_LEFT.*/
> >+/^error:imcc:syntax error, unexpected SHIFT_LEFT.*/
> 
> ... just test for (parse|syntax)

I considered that but "syntax error" is specified by POSIX.  Doesn't
really matter as longer as it will work with newer versions of Bison.

-J

--


pgptFDLI2uzWw.pgp
Description: PGP signature

Re: Roles and Trust

[Piers Cawley]

Ovid <[EMAIL PROTECTED]> writes:

> Apocalypse 12 has the following to say about roles and trust
> (http://www.perl.com/pub/a/2004/04/16/a12.html?page=10)
>
>   It's not clear whether roles should be allowed to grant
>   trust. In the absence of evidence to the contrary, I'm 
>   inclined to say not.
>
> In Perl 5, I recently found myself in the annoying position of having a
> method which could accept scalar, array, or hash references.  My
> primary code looked similar to this (simplified for clarity):
>
>   sub _attributes {
> my ($self, $attrs) = @_;
> return $$attrs if UNIVERSAL::isa( $attrs, 'SCALAR' );
>
> my @attributes = UNIVERSAL::isa( $attrs, 'HASH' ) 
>   ? %$attrs : @$attrs;
> return unless @attributes;
> # more code here
>   }
>
> This was a private method, but $attrs is an argument that is passed in
> by the person using my class.  It would be nice if I could just assign
> an "attributes" role to the SCALAR, ARRAY, and HASH classes and say
> that only my class could see the method(s) it provides.  Thus, my
> caller would be blissfully unaware that I am doing this:
>
>   $attrs->attributes; # even if it's an array reference

How about:

  my method SCALAR::attributes($self:) { $$self }
  my method HASH::attributes(%self:) { %self.kv }
  my method ARRAY::attributes(@self:) { [EMAIL PROTECTED] }

  method _attributes($attrs) {
my @attributes = $attrs.attributes
return @attributes[0] if @attributes == 1;
...
  }

Assuming it's legal.

-- 
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/

Re: [perl #37308] Parrot gobbles up all the memory

[Leopold Toetsch]

On Oct 10, 2005, at 20:24, Andy Dougherty wrote:

Why?  --optimize does at least two different things:  First, 
obviously, it

allows the compiler to optimize.  This is often a good strategy for
exposing faulty assumptions in code.  Second, it enables the
DISABLE_GC_DEBUG define, which changes the sizes of several
structures, including PMCs and Stack_Chunks.  Changing the sizes of
those structures can expose alignment and size assumptions.


Sure, all ACK. And actually I'm compiling --optimized quite often to 
check perfomance. But I currently don't care about failing tests due to 
opimizations, the more that the involved structures are only 
intermittend steps towards variable sized register frames.



I know about the picture.  I don't know why you chose to use a pointer
pointing to the middle of the structure instead of the beginning.  I'm
afraid "praise x86 jit" doesn't mean anything to me.


This structure will also change soon again.

If, instead, you allocated a single structure containing both the 
Context

plus the registers, then the compiler would correctly ensure all the
correct padding and compute all the offsets for you.


This will not work for variable sized register frame, as there is no 
real register structure. We will have to fake it enough that the 
compiler thinks there is a structure, but actually there is none.


I'm currently working on an outline of the final thingy. Given that, 
I'm very glad about hints WRT the sanest way to convince compilers to 
DTRT.


None of which is terribly urgent to me, however, as I don't expect to 
have

time to follow up on this for quite a while.


I need some time too, to convert to the 'final' design. I'll appreciate 
comments, tests, ... very much.


leo

Re: [perl #36452] Re: [BUG] PGE recursion, bus error

[Patrick R. Michaud]

On Mon, Oct 10, 2005 at 09:11:02AM -0400, Matt Fowles wrote:
> Patrick~
> 
> The theoretical implementation of this is quite simple.  Keep a
> counter. everytime a token is consumed from the input stream reset it.
>  Every time a rule is followed increment the counter.  If the counter
> is ever greater than the number of productions in the grammer, then
> you have gone into infinite recursion.  

What happens with something like:

rule atom { A }
rule binary { .  |  \*  }
rule expr {  }

"AB" ~~ /  /

Here, the '.' in  keeps "consuming" the initial "A" (thus 
resetting the counter), but the  rule fails, so we take
the alternation which recurses back to  and does the whole
thing all over again (with the counter having been reset to zero).
So I guess we'd need to backtrack the counter as well...?

Perhaps what we want to be watching is "positions", so that we detect
when the depth of nested subrules activated from a common input position 
is greater than the total number of defined rules?  

And, of course, in the case of rules containing closures, all bets
should be off for detecting infinite recursion, since the closure 
could be handling the termination of the recursion based on some
criteria other than tokens consumed from the input stream.  (But it's 
also probably easy to know when we've executed a closure and thus 
disable the check for infinite recursion when that happens.)

Pm

[perl #37405] [RFE] void function return in PIR

[via RT]

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


Currently when invoking a .Sub in PIR with no return values, you must  
write:

function()

It would be nice for laziness (for compiler writers who then can  
always generate the ()'s) and symmetry (with the arguments) if we  
could write:

() = function()

Regards.

Re: [perl #36452] Re: [BUG] PGE recursion, bus error

[Patrick R. Michaud]

On Mon, Oct 10, 2005 at 10:45:54AM -0400, Matt Fowles wrote:
> Perhaps a better approach would be to perform a bit
> of static analysis on the grammar and look for left recursions at
> creation time (I believe that is a known problem).  Then we can just
> warn once up front and go on our merry way recursing at matchtime.

I think this approach falls back into my category of 
"unless someone wants to take on the task of implementation it's not
likely to be resolved anytime soon..."  :-) :-)

In a dynamic environment like the one we have (parrot/perl) I find it's
really hard to say what constitutes "creation time", especially since
we can refer to subrules dynamically ( <$foo>, <::$foo>, etc. ) and
our grammars have inheritance in which a rule defined by a parent
grammar can invoke a rule defined later in a child grammar.  As with 
closures, we could probably punt on performing any analysis of
rules with dynamic references or that refer to rules outside of
the current grammar.  But given that we can't really know until
matchtime what subrule will be invoked by an expression like , 
it's hard for me to imagine a whole lot we can do in the way of
static analysis beforehand.  However, that could easily just be a 
limit of my imagination.  

Pm

Re: [perl #37399] [PATCH] fix imcc tests with bison >= 1.75c

[Leopold Toetsch]

On Oct 10, 2005, at 21:45, Joshua Hoblitt wrote:


On Mon, Oct 10, 2005 at 06:19:12PM +0200, Leopold Toetsch wrote:

Joshua Hoblitt (via RT) wrote:


-/^error:imcc:parse error, unexpected SHIFT_LEFT.*/
+/^error:imcc:syntax error, unexpected SHIFT_LEFT.*/


... just test for (parse|syntax)


I considered that but "syntax error" is specified by POSIX.  Doesn't
really matter as longer as it will work with newer versions of Bison.


I have no problem updating to a never bison version. Just OS/X is a bit 
confusing:


$ bison --version
GNU Bison version 1.28

So if more folks can confirm that we want/need >= 1.75c, let's do it.


-J


leo

First (developers) Release of Test::Shlomif::Harness

[Shlomi Fish]

Hi all!

In a previous thread, I promised that I'm going to spin-off Test::Harness and 
heavily refactor and revamp it for extensibility. I did just that, and I'm 
proud to announce the first developers release of Test::Shlomif::Harness:

http://download.berlios.de/web-cpan/Test-Shlomif-Harness-0.0100_01.tar.gz

Being a developers' release, it is still subject to change. Here are a few 
notes:

1. The code is derived from the original code of Test::Harness. However, it is 
heavily refactored and the interface has completely changed. There's now an 
object instance (Test::Shlomif::Harness::Obj->new()), and many methods were 
extracted. Hopefully, it will allow for greater flexibility and 
extensibility.

2. The latest version of the code is available on the Berlios' repository for 
the web-cpan project:

svn://svn.berlios.de/web-cpan/Test-Harness-NG/trunk/

3. The name was chosen because "Shlomif" is my common username and handle. I 
didn't want to populate yet another Top-level CPAN namespace, so I placed it 
under Test::. And naturally, there's the Harness. This is just a *temporary* 
name. Possible names for the permanent module (I'm open for more 
suggestions):

* Test::HarnessPlus
* Test::RunTests
* Anything else?

4. It seems the tests coverage of Test::Harness is incomplete so some bugs may 
have escaped.

5. Documentation is somewhat out-of-date at the moment, and a lot of the 
interface has changed.

Let me know what you think.

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: [perl #37399] [PATCH] fix imcc tests with bison >= 1.75c

[Joshua Hoblitt]

On Mon, Oct 10, 2005 at 01:51:54PM -0700, Leopold Toetsch via RT wrote:
> 
> On Oct 10, 2005, at 21:45, Joshua Hoblitt wrote:
> 
> > On Mon, Oct 10, 2005 at 06:19:12PM +0200, Leopold Toetsch wrote:
> >> Joshua Hoblitt (via RT) wrote:
> >>
> >>> -/^error:imcc:parse error, unexpected SHIFT_LEFT.*/
> >>> +/^error:imcc:syntax error, unexpected SHIFT_LEFT.*/
> >>
> >> ... just test for (parse|syntax)
> >
> > I considered that but "syntax error" is specified by POSIX.  Doesn't
> > really matter as longer as it will work with newer versions of Bison.
> 
> I have no problem updating to a never bison version. Just OS/X is a bit 
> confusing:
> 
> $ bison --version
> GNU Bison version 1.28
> 
> So if more folks can confirm that we want/need >= 1.75c, let's do it.

I wouldn't really classify it as a 'need' but last release in the Bison
1.x series was 3 years ago.  It would be 'nice' to work with
reasonably modern tools.

I've decided that I don't like accepting '(parse|syntax)' in the error
string as that could end up forcing end-user tests to accept both as
well.  Lets either require Bison >= 1.75c or explicitly declare the
error messages.

Cheers,

-J

--


pgp0J3BRCFcb5.pgp
Description: PGP signature

Re: First (developers) Release of Test::Shlomif::Harness

[Michael G Schwern]

On Mon, Oct 10, 2005 at 10:53:34PM +0200, Shlomi Fish wrote:
> Let me know what you think.

$ perl -Ilib -wle 'use Test::Shlomif::Harness::Obj;  
Test::Shlomif::Harness::Obj->new->runtests(test_files => [EMAIL PROTECTED])' 
t/*.t
Can't use an undefined value as an ARRAY reference at 
lib/Test/Shlomif/Harness/Obj.pm line 715.

runtests() is not doing anything with its arguments and neither is
_run_all_tests() so $self->test_files is undefined.  In fact, there's a 
few places where you code waffles between getting information from the
object and from its arguments.  _leader_width, for example, gets its 
test_files from its arguments even though it should be available on the
object.

Moving along, here's what happens on a simple test failure.

$ perl -Ilib -wle 'use Test::Shlomif::Harness::Obj;  $t = 
Test::Shlomif::Harness::Obj->new;  $t->test_files([EMAIL PROTECTED]);  
$t->runtests()' t/fail.t 
t/failNOK 1  
#   Failed test in t/fail.t at line 4.
# Looks like you failed 1 test of 1.
t/faildubious
Test returned status 1 (wstat 256, 0x100)
DIED. 
Undefined format "STDOUT" called at lib/Test/Shlomif/Harness/Obj.pm line 842.

It appears all that nasty format code that we hate in Test::Harness has 
gone missing yet _fail_other() still tries to use it.


The way you've broken down the nattier bits of Test::Harness, such as
_show_results(), into digestable functions has value.  I'd like to see
that sort of thing as patches to Test::Harness rather than in a fork.
Also using an object *internally* makes sense.  Cleans up having to pass
%tot and %test around all over.  An external object interface will require
a lot more thought.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Ahh email, my old friend.  Do you know that revenge is a dish that is best 
served cold?  And it is very cold on the Internet!

Re: First (developers) Release of Test::Shlomif::Harness

[Andy Lester]

On Mon, Oct 10, 2005 at 02:27:03PM -0700, Michael G Schwern ([EMAIL PROTECTED]) 
wrote:
> The way you've broken down the nattier bits of Test::Harness, such as
> _show_results(), into digestable functions has value.  I'd like to see
> that sort of thing as patches to Test::Harness rather than in a fork.

I do NOT want to see that sort of thing as patches to Test::Harness.

I would like anyone who presumes that he's going to change the internals
of a module I maintain to talk to me about a general overview of the
changes first, rather than a sweep of the hand that says "What you have
here must be eradicated and replaced by my method that is clearly
better."  That way we can talk about what direction things can go,
rather than having a pile of patches that won't be used.

But it's bigger than that.

Frankly, Shlomi, I continue to be insulted by your sweeping changes:

  my @projects = (
  "language, Perl," => "Rindolf",
  "learn.perl.org"  => "perlmeme.org",
  "Test::Harness"   => "Test::Shlomif::Harness",
  );
  while ( @projects ) {
  printf "Your %s sucks, and you should all use my new %s instead!\n",
  splice( @projects, 0, 2 );
  print "[oh, and fuck you]\n" if @projects;
  # (Have to print the subtext between the lines)
  }

Your attitude is inappropriate and counteractive for a community-based
open source project like Perl and Perl testing.  The first mention of
this harness was a few weeks ago, when we were notified that you were
going to fork Test::Harness.  Forking a project should be the path of
LAST RESORT, not the first.  See also 
http://geeketiquette.infotrope.net/archives/2005/04/19/patches-forks-and-takeovers/

I would be glad to talk to you one-on-one on specific plans and features
for Test::Harness.  Nik Clayton and I, for example, have worked out some
changes to the straps mechanism that fits his needs.  My email address
and AIM account are in every email.  Until then, I'm not interested.

xoxo,
Andy

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

Re: First (developers) Release of Test::Shlomif::Harness

[chromatic]

On Mon, 2005-10-10 at 16:41 -0500, Andy Lester wrote:

> I do NOT want to see that sort of thing as patches to Test::Harness.
> 
> I would like anyone who presumes that he's going to change the internals
> of a module I maintain to talk to me about a general overview of the
> changes first, rather than a sweep of the hand that says "What you have
> here must be eradicated and replaced by my method that is clearly
> better."  That way we can talk about what direction things can go,
> rather than having a pile of patches that won't be used.

I don't think that's fair, Andy.

I have a few ideas myself on how to make T::H a little more clean and
useful, but I'd have to do some refactorings myself on a private fork to
see how well they look in practice.  Perhaps Shlomi's approach to
announcing his intent was less tactful than you might prefer and perhaps
distributing his module on the CPAN as a replacement rather than an
experiment would be a mistake, but backing up big ideas with working
code is worth some respect, not outright dismissal.

-- c

Re: First (developers) Release of Test::Shlomif::Harness

[Andy Lester]

On Mon, Oct 10, 2005 at 02:52:49PM -0700, chromatic ([EMAIL PROTECTED]) wrote:
> > I do NOT want to see that sort of thing as patches to Test::Harness.

> I have a few ideas myself on how to make T::H a little more clean and
> useful, but I'd have to do some refactorings myself on a private fork to
> see how well they look in practice. 

And I'm OK with that.  I just want, and I suspect 99% of any authors
want, to have people work WITH me.  "Hey, Andy, I've got some ideas on
X, are you interested?  Is this something you're looking at exploring?"

Sure, working code is good, but the author also runs the risk of sending
stuff that is less likely of being accepted.  That's not much of a risk,
though, and the time lost would likely be small.

The real issue is that, if Shlomi had come to me and discussed the
issues rather than "I want to fork Test::Harness", we could have worked
together.  Instead, it's "I want color-coding of tests, and T::H doesn't
do what I want, so I'm gonna go fork it, OK?"

http://www.nntp.perl.org/group/perl.qa/4799

xoa

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

Class Methods, Eigenclasses and $?CLASS

[Stevan Little]

Evening all,

So I am in the process of adding class-methods into the meta-model  
using eigenclasses. Eigenclasses are a ruby thing (and also a CLOS  
thing IIRC), in which an anon-class is inserted between an instance  
and it's class, essentially replacing the instance's class. The anon- 
class then adds the original class to it's superclass list. This is  
best shown visually I think:


 ::Class
^
:  <-- eFoo is a subclass of Class
:
 ::eFoo   # eFoo is also an instance of Class
|
|  <-- eFoo is the class of Foo
V
  ::Foo

The dispatching of instance methods is still the same, and everything  
"just works". Well... almost everything.


There is a slight issue/inconsitency with how $?CLASS works.

class Foo {
method bar (Class $c:)  { $?CLASS }
method baz (Foo $self:) { $?CLASS }
}

Within the &bar class-method, the natural inclination is to think  
that $?CLASS will refer to ::Foo. However, in order to be consistent  
it actually refers to the eigenclass between ::Foo and ::Class, lets  
call it ::eFoo. This is because methods are associated with the class  
which contains them. In the &baz instance-method, $?CLASS does refer  
to ::Foo, since ::Foo is the class which contains &baz.


It seems to me that this inconsistency could be very problematic,  
especially since eigenclasses should really be an invisible  
implementation detail.


I am not 100% sure of what is the correct approach here, so I thought  
I would ask the group. Any thoughts guys/gals?


Thanks,

Stevan

Re: First (developers) Release of Test::Shlomif::Harness

[chromatic]

On Mon, 2005-10-10 at 17:22 -0500, Andy Lester wrote:

> The real issue is that, if Shlomi had come to me and discussed the
> issues rather than "I want to fork Test::Harness", we could have worked
> together.  Instead, it's "I want color-coding of tests, and T::H doesn't
> do what I want, so I'm gonna go fork it, OK?"

I agree that his approach was inappropriate.  Still, he has working code
and that's significant.

http://petdance.com/perl/geek-culture/

-- c

This week's summary

[The Perl 6 Summarizer]

The Perl 6 Summary for the week ending 2005-10-09
Hello, and welcome to the first Perl 6 Summary to be published on my
website rather than its former home at 

This week in perl6-compiler
  PGE error on failing subrules
Allison broke the resounding silence of the last two weeks by posting
about some PGE errors she was seeing. No reply yet.



  Tests converted from pugs' rules.t to Parrot::Test::PGE
Yuval Kogman announced that he'd written a script to convert pugs's
rules tests into Parrot tests. The resulting test suite still needs some
attention, and he outlined what was needed. No response so far on the
list.



Meanwhile, in perl6-internals
  Variable registers
Klaas-Jan Stol wondered about how the new lexical scheme was going to
work. In particular, he wanted to know what was happening to
scratchpads. Leo gave a very brief overview of the new scheme, which
uses register frames for static lexicals and more conventional
scratchpads for dynamic lexicals. As I understand it, they'll look
pretty much the same from the PIR writer's point of view. Leo promised a
PDD from Chip in the nearish future which would thrash out the details.



  Exception handlers and calling conventions
Roger Browne wanted to know if exception handling had changed at the
same time as the calling conventions. He presented some code that
behaved differently depending on the Parrot version. Leo replied that
exceptions still wind up in P5 and Roger had found a bug. So Leo fixed
it.



  Parrot 0.3.0 TODO
Having successfully got Parrot building on his Cygwin installation,
Robert Eaglestone was casting around for something to do and listed a
few possibilities. Will Coleda replied that he'd quite like to see a
working Parrot equivalent to Perl 5's $0.



  Parrot 0.3.0 and Tru64
Jarkko Hietaniemi posted a bunch of issues with Parrot on the Tru64
architecture. Leo addressed them. I'm not sure they're all fixed yet
though.

  TCL - Compiling
Will Coleda announced that ParTcl is now a compiler. Some tests are
failing but Will claimed that this is because Jerry Gay was getting
bored with all the tests passing. Jerry was delighted. As Will said
later in the thread, the current iteration is doing the bare minimum
needed to be called a compiler, but of course that will change over
time. Good work Will.



  BROKEN.pod
Hey, now he's no longer my editor, I don't have to worry about making
sure I don't put his name at the beginning of a sentence! Anyhow,
chromatic posted a first cut at BROKEN.pod, the big list of broken
stuff. There followed some discussion of how this should be organised in
the future, particularly on the RT side. After discussion, it was
decided to keep it as a single file for now, but to aim for generating
it from multiple RT tickets in the future.



  Stack call directives are deprecated
Using ".param", ".arg", ".return", ".result" and "call" to do stack
based calling conventions is now deprecated. Use "save", "restore",
"bsr" and "ret" instead. Or, ideally, use the standard Parrot calling
conventions.



  Deprecation of rx ops
Brent Royal-Gordon confirmed that he was happy enough to see his
experimental regular expression specific ops removed from Parrot.

They've not been removed yet, but they're certainly deprecated.



  Software Architecture of Parrot
Klaas-Jan Stol informed us that his Software Architecture professor had
approved his proposal to write a paper on the architecture of Parrot. He
outlined his plans for the paper and hoped that he would be able to
count on people for proof-reading when the time came. Leo thought it was
a marvellous idea (so do I come to that, but I didn't say anything on
the list.)



  ParTcl command line options, etc
Will Coleda kept us abreast of his progress with ParTcl in this thread,
initially announcing the new "-e" flag which allowed for writing one
liners. After a certain amount of havering before a final interface
arrived, ParTcl also acquired a --pir flag, which dumps the results of
compilation to a PIR file.



  BASIC compiler
Will Coleda (does the man never sleep?) announced that the BASIC
compiler is (sort of) working again with Parrot 0.3.0. There are still
problems with the windows display code (the offending code is simply
commented out), but code that doesn't need that appears to be working
now. He noted that BASIC could really use a decent test suite, right now
he was simply working to get programs like eliza2.bas and wumpus.bas
working

Re: First (developers) Release of Test::Shlomif::Harness

[Andy Lester]

On Mon, Oct 10, 2005 at 03:38:20PM -0700, chromatic ([EMAIL PROTECTED]) wrote:
> I agree that his approach was inappropriate.  Still, he has working code
> and that's significant.
> 
> http://petdance.com/perl/geek-culture/

I don't think Shlomi's a fuckhead, nor do I have the bozo bit flipped
against him.  If I thought the situation was hopeless, I wouldn't bother
responding.

I'm glad to work with anyone on changes to Test::Harness.  The code that
has been uploaded is a fork of, not changes to, Test::Harness.

And Shlomi, I apologize for referring to you in the 3rd person in this
thread. :-)

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

Re: Class Methods, Eigenclasses and $?CLASS

[Luke Palmer]

On 10/10/05, Stevan Little <[EMAIL PROTECTED]> wrote:
>   ::Class
>  ^
>  :  <-- eFoo is a subclass of Class
>  :
>   ::eFoo   # eFoo is also an instance of Class
>  |
>  |  <-- eFoo is the class of Foo
>  V
>::Foo
>
> The dispatching of instance methods is still the same, and everything
> "just works". Well... almost everything.

How do you explain this:

class Foo {
method bar (Class $class:) { "class method" }
}
say Foo.bar;# class method
my $foo = Foo.new;
say $foo.bar;   # class method

Assuming that that is valid Perl.

Luke

Re: Class Methods, Eigenclasses and $?CLASS

[Stevan Little]

Luke,

On Oct 10, 2005, at 7:47 PM, Luke Palmer wrote:

How do you explain this:

class Foo {
method bar (Class $class:) { "class method" }
}
say Foo.bar;# class method
my $foo = Foo.new;
say $foo.bar;   # class method

Assuming that that is valid Perl.


It is "valid" Perl 5, however (IMHO) it is *not* valid Perl 6.

To start with, the type of the invocant is Class, which $foo is not  
derived from (it is an instance of something which itself is an  
instance of Class).


I think that

  $foo.class.bar()

should work. And changing the method defintion to be

  method bar (Class|Foo $class:) { ... }

should work, but the code as you wrote it should not. Which means  
that when we deal with Perl 5 classes within Perl 6, we should likely  
give them an implied signature of (Class|Foo $self:) or some other  
weirdness (I haven't thought that far down the line yet).


Class methods are strange creatures, in Perl 5 they were nothing  
different than instance methods. In Java (static methods), they are  
really just odd functions which need to be qualified by a class name.  
Python doesn't even really have them (you have to jump through odd  
hoops to make the method "callable"). Ruby uses Eigenclasses, and  
CLOS uses something akin to eigenclasses. I am not sure how Smalltalk  
handles things, but my guess is that class methods on Foo are  
instance methods of classFoo, or some such.


They are ugly beasties no matter what, but eigenclasses (so far) seem  
to be the prettiest of the uglies.


Stevan

Re: First (developers) Release of Test::Shlomif::Harness

[Shlomi Fish]

On Monday 10 October 2005 23:41, Andy Lester wrote:
> On Mon, Oct 10, 2005 at 02:27:03PM -0700, Michael G Schwern 
([EMAIL PROTECTED]) wrote:
> > The way you've broken down the nattier bits of Test::Harness, such as
> > _show_results(), into digestable functions has value.  I'd like to see
> > that sort of thing as patches to Test::Harness rather than in a fork.
>
> I do NOT want to see that sort of thing as patches to Test::Harness.
>
> I would like anyone who presumes that he's going to change the internals
> of a module I maintain to talk to me about a general overview of the
> changes first, rather than a sweep of the hand that says "What you have
> here must be eradicated and replaced by my method that is clearly
> better."  That way we can talk about what direction things can go,
> rather than having a pile of patches that won't be used.
>

You are right. Thing is that I noticed Test::Harness had monlithic functions, 
and wasn't an object (and thus did not have over-ridable methods), etc. I 
wanted to heavily revamp it and change the entire code, in a non-compatible 
way, but did not know exactly what I was going to do, because I had no 
intimate knowledge of the code. 

Converting T::S::H to have an object instance that will be pass around from 
function to function was the first thing I did. Later it facilitated adding 
more refactorings.

> But it's bigger than that.
>
> Frankly, Shlomi, I continue to be insulted by your sweeping changes:
>
>   my @projects = (
>   "language, Perl," => "Rindolf",

Actually, Rindolf was supposed an alternative to _Perl 6_, due to me being 
unhappy with it. Originally, it was not supposed to be backwards compatible 
with Perl 5, but later was compatible.

>   "learn.perl.org"  => "perlmeme.org",

Actually it's more accurately "learn.perl.org" => "perl-begin.berlios.de". 
"perlmeme.org" is orthoganal to both. Perlmeme was started without my 
involvement, and I found myself contributing to it only further. Perl-Begin, 
OTOH is my baby. 

My history with learn.perl.org is this:

1. I began writing perl-begin out of frustration from learn.perl.org.

2. A news item I wrote about it, was re-routed to the learn.perl.org guys, 
where it was decided that I will do a redesign and extension of l.p.o.

3. After Perl-Begin was in a more complete state, I tried to recommend the 
l.p.o guys to integrate its changes in the site. No-one responded. I tried to 
subscribe to [EMAIL PROTECTED], but I couldn't because it's not open 
for subscribers. I also wasn't added manually.

4. Without too much choice, I set up perl-begin.berlios.de and hosted my 
version of the site there. 

5. Eventually, I contacted the perl.org admins about linking to perl-begin, 
and they decided that instead of learn.perl.org, which was heavily 
unmaintained, they should instead have a http://www.perl.org/learn/ section. 
I designed such a page, and submitted a patch against the perl.org sources to 
the Perl.org admins. They had their share of trouble from then, and as a 
result, it wasn't integrated.


>   "Test::Harness"   => "Test::Shlomif::Harness",

I plan Test::Shlomif::Harness (whatever it will be permananetly named) to be 
an alternative to Test::Harness. One would be able to use it instead, and 
exploit its better modularity and extensibility. There is still a lot of code 
that uses Test::Harness around, and so Test::Harness still needs to be 
maintained. I also plan to implement a Test::Harness-compatible module 
eventually that makes use of Test::Shlomif::Harness. (but did not get to it 
yet.)

Think of T::S::H vs. Test::Harness as Module::Build to ExtUtils::MakeMaker, or 
CPANPLUS to CPAN, or PONIE to perl 5. 

> Your attitude is inappropriate and counteractive for a community-based
> open source project like Perl and Perl testing.  The first mention of
> this harness was a few weeks ago, when we were notified that you were
> going to fork Test::Harness.  Forking a project should be the path of
> LAST RESORT, not the first.  See also
> http://geeketiquette.infotrope.net/archives/2005/04/19/patches-forks-and-ta
>keovers/

I realize the problem with forking. However, I span-off the codebase, in order 
to convert it to something much better. I asked for your permission to do 
that, and outlined my plans, and you gave me your permission. So I went on to 
"show you the code", and back my words with code.

>
> I would be glad to talk to you one-on-one on specific plans and features
> for Test::Harness.  Nik Clayton and I, for example, have worked out some
> changes to the straps mechanism that fits his needs.  My email address
> and AIM account are in every email.  Until then, I'm not interested.
>

OK, we'll talk on AIM.

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%.