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.
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 just operations
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
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
# '
Does OS
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
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
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
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
'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 present it only
