> > '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
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
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
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
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
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
>
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
> "JW" == John Williams <[EMAIL PROTECTED]> writes:
JW> On Fri, 23 Jan 2004, Larry Wall wrote:
>> Sorry, I was just copying the designers of supercomputers in my
>> terminology. So you can really blame Seymour Cray for misappropriating
>> the term. On a Cray, "vector processing" is j
On Fri, 23 Jan 2004, Larry Wall wrote:
> Sorry, I was just copying the designers of supercomputers in my
> terminology. So you can really blame Seymour Cray for misappropriating
> the term. On a Cray, "vector processing" is just operations applied
> in parallel to two one-dimensional lists. Unfo
