Re: [perl #25266] [PATCH] Unify PMC accessor macros

2004-01-26 Thread Leopold Toetsch
Gordon Henriksen (via RT) wrote: PMC accessor macros come in a bewildering variety of forms, depend upon one another, are scattered throughout pobj.h, are generally difficult to decipher. [ snip ] This patch defines yet another set of accessor macros, but these have a consistent naming strat

Re: t/src/io failure

2004-01-26 Thread Leopold Toetsch
Michael Scott <[EMAIL PROTECTED]> wrote: > I see that t/src/io is now failing on OS X 10.3.2. Is anyone else > seeing this on another system? > t/src/iook 12/19# Failed test (t/src/io.t at line > 395) > # got: '0 > # 0 > # 0 > # ' > # expected: '0 > # 6 > # 6 >

Re: [perl #25260] [PATCH] Parrot m4 0.0.2

2004-01-26 Thread Leopold Toetsch
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > I have prepared a new revision of Parrot m4. There is some code cleanup and > a revamping of the internal data structures. So the next step can be > implementation of some > builtin functions. Thanks, applied. leo

Re: [perl #25248] gettingstarted.pod missing

2004-01-26 Thread Leopold Toetsch
Dave Pippenger <[EMAIL PROTECTED]> wrote: > gettingstarted.pod seems to be missing from docs/*.pod I've committed that pod now, hope that's still accurate leo

Re: [perl #25253] [PATCH] Remove Parrot_INTERP

2004-01-26 Thread Gordon Henriksen
Seiler Thomas wrote: Gordon Henriksen wrote: The Parrot_INTERP type from embed.c and embed.h serves no purpose. [linking failures...] mem_alloc_executable mem_free_executable mem_realloc_executable [...] Re-ran Configure.pl and these went away, in case anyone else has this. inet_pton Is a IPv6

Re: IMCC - PerlArray getting trounced

2004-01-26 Thread Leopold Toetsch
Will Coleda <[EMAIL PROTECTED]> wrote: > I'm trying to track down a problem with a PerlArray that is getting > modified on me. > I have a snippet of code like: Could you please provide a complete program, that imposes the bug? leo

Re: [perl #25265] [PATCH] peek opcode

2004-01-26 Thread Cory Spencer
> > 'peek' implements an opcode which can look ahead at an arbitrary number of > > bytes in a IO stream, but does not remove the bytes from the stream in the > > process. > > > [...] > > I have some question though: > > - what if peek wants to look beyond current buffered limits Yes - at presen