On Sunday, January 25, 2004, at 07:08 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
Speaking of cleaning and uniting, what is with this?
#define bufstart obj.u.b.bufstart
#define buflen obj.u.b.buflen
These are *currently* necessary macros, until the PMC/PObj layout is
On Friday, January 23, 2004, at 10:57 , Larry Wall wrote:
Anyway, if we do use _ for that, the people who want to warp Perl into
Prolog will have to use something else for unnamed bindings. :-)
Use ¬! Then the AppleScripters will feel right at home when they upgrade
to Perl 6. :/
—
Gordon Hen
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Would be nice if there were a convenient way to run the lot of them
> collect the timing information, though.
Yep. That would be really great. That is: have per platform numbers over
time (correlated to patches) about performance of current and a lot
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Speaking of cleaning and uniting, what is with this?
> #define bufstart obj.u.b.bufstart
> #define buflen obj.u.b.buflen
These are *currently* necessary macros, until the PMC/PObj layout is
really carved in stones. You had in your proposal a differ
On Sunday, January 25, 2004, at 06:42 , Michael Scott wrote:
I see that t/src/io is now failing on OS X 10.3.2. Is anyone else
seeing this on another system?
Also on 10.1.5.
—
Gordon Henriksen
[EMAIL PROTECTED]
Cory Spencer <[EMAIL PROTECTED]> wrote:
> '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.
> The proposed format is:
> peek(out STR, in INT)
> where $1 contains up to $2 peek'ed by
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
# '
t/src/iook 18/19# Looks like you failed 1
On Sunday, January 25, 2004, at 06:01 , Matt Fowles wrote:
Of late it seems that everybody has been throwing around their own
little homegrown benchmarks to support their points. But many people
frequently point out that these benchmarks are flawed on one way or
another.
I suggest that we add
A few notes on the benchmarks can be found/added here
http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/
ParrotDistributionExamples#benchmarking
Mike
On 26 Jan 2004, at 00:14, Luke Palmer wrote:
Matt Fowles writes:
All~
Of late it seems that everybody has been throwing around their own
lit
Matt Fowles writes:
> All~
>
> Of late it seems that everybody has been throwing around their own
> little homegrown benchmarks to support their points. But many people
> frequently point out that these benchmarks are flawed on one way or another.
>
> I suggest that we add a benchmark/ subdire
All~
Of late it seems that everybody has been throwing around their own
little homegrown benchmarks to support their points. But many people
frequently point out that these benchmarks are flawed on one way or another.
I suggest that we add a benchmark/ subdirectory and create a canonical
suit
On Sunday, January 25, 2004, at 03:44 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
All embedders see is this:
typedef struct Parrot_Interp *Parrot_Interp;
I don't do decisions on embedding or extending interfaces. But it seems
to be the time to decide (and clean/unite)
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Increasing the union size, so that each pointer is distinct is not an
>> option. This imposes considerable overhead on a non-threaded program
>> too, due its bigger PMC size.
> That was the brute-force approach, separating ou
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> All embedders see is this:
> typedef struct Parrot_Interp *Parrot_Interp;
I don't do decisions on embedding or extending interfaces. But it seems
to be the time to decide (and clean/unite) the current names:
struct Interp* / struct Parrot_Inte
# New Ticket Created by Cory Spencer
# Please include the string: [perl #25265]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25265 >
'peek' implements an opcode which can look ahead at an arbitrary number of
bytes in a I
Michael Scott <[EMAIL PROTECTED]> wrote:
> So, to go back to Dan's original list, does that give us:
> (FixedMixedArray - fixed-size, mixed-type array)
> MixedArray - variable-sized, mixed-type array
> FixedPMCArray - fixed-size, PMC array
> PMCArray - variable-sized, PMC array
> FixedStringArr
On Saturday, January 24, 2004, at 02:28 , Leopold Toetsch wrote:
Mattia Barbon <[EMAIL PROTECTED]> wrote:
I feel I'm becoming annoying, but: the embedding and extending
interfaces are still using different names for
Parrot_Interp/Parrot_INTERP. Which one is correct?
AFAIK both. Embedding and ex
Leopold Toetsch wrote:
Gordon Henriksen wrote:
I overstated when I said that morph must die. morph could live IF:
[ long proposal ]
Increasing the union size, so that each pointer is distinct is not an
option. This imposes considerable overhead on a non-threaded program
too, due its bigger PMC
Nope. If I turn on -G and leave off explicit savetop/restoretop, the
perlArray is still stomped.
Regards.
On Sunday, January 25, 2004, at 09:29 AM, Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
If there's magic, it was an unintentional invocation. =-) If I was
managing my own
On Sunday, January 25, 2004, at 06:10 , Michael Scott wrote:
On 25 Jan 2004, at 00:50, Gordon Henriksen wrote:
[...]
Is there something so terribly wrong with English? How about a general
scheme of * ? So, respectively,
MixedArray
Array
FixedArray
StringArray
FixedStringArray
Array is what Per
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #25260]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25260 >
Hi,
I have prepared a new revision of Parrot m4. There is some code cleanup and
Will Coleda <[EMAIL PROTECTED]> wrote:
> If there's magic, it was an unintentional invocation. =-) If I was
> managing my own registers, I'd expect to have to save things - but
> since I'm always (I think) using .locals or the $I syntax, I'd
> expect IMCC to do the saving,
IMCC does provide the n
If there's magic, it was an unintentional invocation. =-) If I was
managing my own registers, I'd expect to have to save things - but
since I'm always (I think) using .locals or the $I syntax, I'd
expect IMCC to do the saving, since I have no way of knowing /which/
registers it's using for me.
On 25 Jan 2004, at 00:50, Gordon Henriksen wrote:
[...]
Is there something so terribly wrong with English? How about a general
scheme of * ? So, respectively,
MixedArray
Array
FixedArray
StringArray
FixedStringArray
Array is what Perl familiars will usually want.
Did I miss something? What is A
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> I overstated when I said that morph must die. morph could live IF:
[ long proposal ]
Increasing the union size, so that each pointer is distinct is not an
option. This imposes considerable overhead on a non-threaded program
too, due its bigger PMC si
Chromatic <[EMAIL PROTECTED]> wrote:
> On Sat, 2004-01-24 at 06:18, Leopold Toetsch wrote:
>> Either:
>> new $P2, .HashlikeStruct, $P1
>> or
>> assign $P2, $P1
> That gave me "Illegal initializer for struct", which may be related to
> your next comment.
The UnManagedStruct initializ
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> On Thursday, January 22, 2004, at 09:58 , Leopold Toetsch wrote:
>> cvsuser 04/01/22 06:58:48
>>
>> Modified:src res_lea.c
>> Log:
>> * PANIC on allocation errors
> Er? Shouldn't this try to turn into an exception somehow?
Finally
Jeffrey Dik <[EMAIL PROTECTED]> wrote:
> Oh yeah, the patch is probably The Wrong Way To Do It because I have no idea
> what I'm doing ;-)
The patch is fine, thanks - applied.
leo
Arvindh Rajesh Tamilmani <[EMAIL PROTECTED]> wrote:
> The attached patch
> a) fixes bugs in reading a larger chunk when the read buffer is not empty
> (io/io_buf.c).
> b) corresponding test cases (t/src/io.t).
> c) minor comment fix (io/io.c).
Thanks, applied.
leo
Il Sat, 24 Jan 2004 19:42:20 -0500 Gordon Henriksen <[EMAIL PROTECTED]> ha scritto:
> On Saturday, January 24, 2004, at 11:28 , Mattia Barbon wrote:
>
> > I feel I'm becoming annoying, but: the embedding and extending
> > interfaces are still using different names for
> > Parrot_Interp/Parrot_I
# New Ticket Created by Will Coleda
# Please include the string: [perl #25255]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25255 >
It would be helpful if IMCC complained about duplicate ".local" labels,
so that the atta
# New Ticket Created by Gordon Henriksen
# Please include the string: [perl #25253]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25253 >
The Parrot_INTERP type from embed.c and embed.h serves no purpose.
Parrot_Interp
Mattia Barbon <[EMAIL PROTECTED]> wrote:
> Hello,
> I feel I'm becoming annoying, but: the embedding and extending
> interfaces are still using different names for Parrot_Interp/Parrot_INTERP.
> Which one is correct?
AFAIK both. Embedding and extending are to different APIs. The former
has acc
Will Coleda writes:
> I'm trying to track down a problem with a PerlArray that is getting
> modified on me.
>
> I have a snippet of code like:
>
> typeof $S12, tcl_words
> $I12 = tcl_words
> print "TYPEOF: "
> print $S12
> print "\n"
> print "SIZEOF: "
> print $I12
> print "\n"
>
On Sat, 2004-01-24 at 19:51, Jeffrey Dik wrote:
> glibc-2.3.1-51a according to rpm -q
Interesting. I'm using 2.3.2. Do you have the opportunity to try out
NPTL with a newer glibc and kernel? It may involve some pain, so that's
fine if you'd rather not. (I'm in the same boat.)
I'm just about
35 matches
Mail list logo
