Bill Coffman <[EMAIL PROTECTED]> wrote:
> Hello,
> * I have the below failed tests.
> t/library/dumper.t 13 332813 13 100.00% 1-13
These are fixed (assignment collisions in pcc.c)
> t/op/gc.t 1 256181 5.56% 13
Is very similar to the case below - gc_14 (you mi
First, thanx so very much for responding so quickly...
Paul Johnson wrote:
On Sat, Nov 13, 2004 at 12:46:16AM +1100, Leif Eriksen wrote:
Even though Test::More is reporting (via make test) that every test
Could you try putting the use_ok inside a BEGIN block, as Test::More
recommends?
OK, will
> Segfault in the lexer. Bad.
>
> 349 sprintf(label, "%s%d", yytext,
> frames->label);
> (gdb) p frames
> $1 = (struct macro_frame_t *) 0x0
I didn't know how or why or what a frame is in this
context which is why this isn't a patch :)
__
Larry Wall writes:
> On Wed, Nov 10, 2004 at 01:12:46PM -0600, Rod Adams wrote:
>
> : /usr/bin/perl6forces perl6
> : /usr/bin/ponieforces ponie
> : /usr/bin/perl5p alias for ponie, as some sites might find the term
> : "ponie" too removed from "perl"
> : /usr/bin/perluses other rul
As the analysis of test errors of the new reigster allocator has shown,
we have a problem WRT register allocation. This problem isn't new, but
as the allocator is more efficiently reusing registers (or reusing them
in a different way) it's exposed again.
0) The register allocator isn't to blame
On Nov 13, 2004, at 8:53 AM, Leopold Toetsch wrote:
2) Continuations (t/op/gc_13.imc [Hi Piers])
Again we have a hidden branch done by a Continuation, or better a
loop. The control flow of the main program is basically represented by
this conventional code fragment:
arr1=[...]; arr2=[.
All~
On Sat, 13 Nov 2004 10:52:38 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 13, 2004, at 8:53 AM, Leopold Toetsch wrote:
> > We'd have just to force using lexicals for all vars
>
> Having variable-size register sets would solve this, since you could
> have fixed assignments of variab
Matt Fowles <[EMAIL PROTECTED]> wrote:
> I like the idea of mandating lexicals vars. This would also eliminate
> the need for spilling (I think), as the register allocator would only
> need to refetch the lexical rather than save it off somewhere to be
> restored later.
There are two issues: yes
On Nov 13, 2004, at 11:16 AM, Matt Fowles wrote:
All~
On Sat, 13 Nov 2004 10:52:38 -0800, Jeff Clites <[EMAIL PROTECTED]>
wrote:
On Nov 13, 2004, at 8:53 AM, Leopold Toetsch wrote:
We'd have just to force using lexicals for all vars
Having variable-size register sets would solve this, since you co
Jeff~
On Sat, 13 Nov 2004 14:08:12 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
> That's oversimplifying a bit, but I feel like those are the core issues
> (stemming from the observation of Leo's that continuations in effect
> give all variables a lifetime that extends to their entire block, in
While there was a lot of talk in this thread about how we were not going to
provide extra
checks to prevent segfaults... both the original case and the simple one below
no longer
generate segfaults, but instead throw an exception of some kind.
Closing ticket.
> [EMAIL PROTECTED] - Tue Jul 29
On Nov 13, 2004, at 2:46 PM, Matt Fowles wrote:
On Sat, 13 Nov 2004 14:08:12 -0800, Jeff Clites <[EMAIL PROTECTED]>
wrote:
That's oversimplifying a bit, but I feel like those are the core
issues
(stemming from the observation of Leo's that continuations in effect
give all variables a lifetime tha
Jeff~
On Sat, 13 Nov 2004 17:35:02 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
> Not all variables, but due to Leo's case (2), it should be all
> variables which are referenced after the first function call out of a
> subroutine, if there's a later function call; for instance, consider:
>
> ..
13 matches
Mail list logo
