On Friday 07 September 2001 12:56 am, Ken Fox wrote:
> "Bryan C. Warnock" wrote:
> > Generically speaking, modules aren't going to be running amok and making
> > a mess of your current lexical scope - they'll be introducing, possibily
> > repointing, and then possibly deleting specific symbols
>
>
At 12:13 AM 9/7/2001 -0400, Ken Fox wrote:
>Damian Conway wrote:
> > "3, 1, 3" is the correct answer.
>
>That's what I thought. Dan's not going to be happy. ;)
Well, it means a fetch by pad entry rather than use of a cached PMC
pointer, but that's OK by me.
I have a solution for this that I'm p
On Fri 11 May 2001 16:31, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Fri, May 11, 2001 at 01:55:42AM +0100, Graham Barr wrote:
> > On Thu, May 10, 2001 at 07:40:04PM -0500, Jarkko Hietaniemi wrote:
> > > By far most of my use of typeglobs is making aliases, and then mostly
> > > for code:
>
will the iterator variable be available in map, grep, join...etc...
I was also wondering if the join syntax be extended in a way that it can
support preffix and suffix... what i have in mind ... not necesary but :
#pair
join ($prefix => $suffix), @ary;
so :
my $select = join (qq{} => '
On Friday 07 September 2001 03:22 pm, raptor wrote:
> will the iterator variable be available in map, grep, join...etc...
Iterators haven't been defined yet, so it's hard to tell.
For map and grep, it's certainly feasible, depending on their implementation
- although neither are truly iterators.
On Fri, Sep 07, 2001 at 10:22:49PM +0300, raptor wrote:
> I was also wondering if the join syntax be extended in a way that it can
> support preffix and suffix... what i have in mind ... not necesary but :
> #pair
> join ($prefix => $suffix), @ary;
>
> so :
> my $select = join (qq{} =>
At 10:47 PM 9/6/2001 +0200, Paolo Molaro wrote:
>On 09/06/01 Dan Sugalski wrote:
> > Then I'm impressed. I expect you've done some things that I haven't yet.
>
>The only optimizations that interpreter had, were computed goto and
>allocating the eval stack with alloca() instead of malloc().
Doesn'
While waiting for Parrot (dammit, I took the wrong week off), I've been
scanning the various documents and samples which have been floating
around on the list. Is there a document describing Parrot syntax yet?
Or is that a "will be released on monday" thing as well?
Brian Wheeler
[EMAIL PROTECT
At 03:10 PM 9/7/2001 -0500, Brian Wheeler wrote:
>While waiting for Parrot (dammit, I took the wrong week off), I've been
>scanning the various documents and samples which have been floating
>around on the list. Is there a document describing Parrot syntax yet?
>Or is that a "will be released on
On Thu, Sep 06, 2001 at 04:55:49PM -0700, Benjamin Stuhl wrote:
> I had a thought this morning on funtion/struct/global
> prefixes for Parrot. If we really plan to also run
> Python/Ruby/whatever on it, it does not look good for the
> entire API to be prefixed with "perl_". We really (IMHO)
> ough
Here's the assembly PDD. Changes to it to come, of course.
---Cut Here--
=head1 TITLE
Parrot assembly language
=head1 VERSION
=head2 CURRENT
Maintainer: Dan Sugalski
Class: Internals
PDD Number: 6
Version: 1.2
Status: Developin
A thought I had: if variable-width encodings are so difficult because
it's hard to index into them by character, why don't we break them up
ourselves?
+PV---+ +strchunk-+-+
+strchunk-+-+
|string |-->|the quick brown fox jumped ov|>+-
hi,
I see that it was mentioned that Perl5 is fast than Java, Python etc... and
was wondering is there any comparison how-much, if ? and if why ? and if we
know the reason can we exploit it further ... and similar...
And does really Perl6 will be faster. how much u expect ?
Thanx
=
iVAN
At 10:30 PM 9/7/2001 +0300, raptor wrote:
>I see that it was mentioned that Perl5 is fast than Java, Python etc... and
>was wondering is there any comparison how-much, if ? and if why ? and if we
>know the reason can we exploit it further ... and similar...
>And does really Perl6 will be faster..
On Friday 07 September 2001 05:38 pm, Dan Sugalski wrote:
>
> As for perl 6 vs perl 5, that's reasonably easy. We benchmark things on
> perl 5.004_04 and 6.x, and see who wins. If 6 doesn't, we find out why and
> speed it up. :)
5.004? (Is that where the big drop-off begins?)
You are going to t
>>How about something a little more explicit than XXX, like TODO or FIXME?
> Some syntax-highlighting editors highlight "XXX". Let's use that feature.
Which ones? emacs doesn't seem to do it by default.
> And how can you get more explicit than XXX, anyway?
Funny, but I still think TODO or
At 05:41 PM 9/7/2001 -0400, Bryan C. Warnock wrote:
>On Friday 07 September 2001 05:38 pm, Dan Sugalski wrote:
> >
> > As for perl 6 vs perl 5, that's reasonably easy. We benchmark things on
> > perl 5.004_04 and 6.x, and see who wins. If 6 doesn't, we find out why and
> > speed it up. :)
>
>5.004
On Friday 07 September 2001 05:51 pm, Dan Sugalski wrote:
> >(Like
> >Unicode Everywhere).
>
> Who's doing that? We're keeping things in native format as much as we can.
If one of our stated goals is Unicode support (even for the source itself -
that's what I meant by "everywhere": source, input
At 05:54 PM 9/7/2001 -0400, Bryan C. Warnock wrote:
>On Friday 07 September 2001 05:51 pm, Dan Sugalski wrote:
> > >(Like
> > >Unicode Everywhere).
> >
> > Who's doing that? We're keeping things in native format as much as we can.
>
>If one of our stated goals is Unicode support (even for the sour
On Friday 07 September 2001 01:30 pm, Dan Sugalski wrote:
> In all cases, the letters x, y, and z refer to register numbers. The
> letter t refers to a generic register (P, S, I, or N). A lowercase p,
> s, i, or n means either a register or constant of the appropriate type
> (PMC, string, integer
On Friday 07 September 2001 07:21 pm, Matthew Cline wrote:
> On Friday 07 September 2001 01:30 pm, Dan Sugalski wrote:
> > In all cases, the letters x, y, and z refer to register numbers. The
> > letter t refers to a generic register (P, S, I, or N). A lowercase p,
> > s, i, or n means either a re
On Fri, Sep 07, 2001 at 10:32:42AM -0400, Dan Sugalski wrote:
> Simon's going there already. We should fix the docs up, though. (I have a
> bunch of PDDs to update and submit. I think they're going to go into the
> CVS repository too, once it's fully operational, so I don't lose track of
> thin
At 04:55 PM 9/6/2001 -0700, Benjamin Stuhl wrote:
>I had a thought this morning on funtion/struct/global
>prefixes for Parrot. If we really plan to also run
>Python/Ruby/whatever on it, it does not look good for the
>entire API to be prefixed with "perl_". We really (IMHO)
>ought to pick something
Actually there were some tests done, can't recall where now, though by a
trusted source. I will be digging it up in my email and emailing it to the
list. There were a few languages tested including Perl, C, C++, Java (can't
remember if Python was there). Perl came in in second place after C. Ye
On Friday 07 September 2001 11:08 pm, Sterin, Ilya wrote:
> Actually there were some tests done, can't recall where now, though by a
> trusted source. I will be digging it up in my email and emailing it to the
> list. There were a few languages tested including Perl, C, C++, Java
> (can't remembe
Hey, folks.
I'm going to be giving the world's second public parrot demo at this
month's Boston.pm meeting. It's Tuesday the 11th at 7 PM, give or take, at
the Boston.com building in (who'd've thought) Boston. :) If you're
interested in coming, make sure to RSVP to Ronald Kimball,
<[EMAIL PRO
26 matches
Mail list logo
