On Wed, Nov 24, 2004 at 04:25:14PM -0500, John Siracusa wrote:
> On 11/24/04 3:42 PM, Felix Gallo wrote:
> > Well, it's the first time *I've* seen it.
> >
> > http://otierney.net/images/perl6.gif
> >
> > I find it difficult to disagree, at the perl6
Well, it's the first time *I've* seen it.
http://otierney.net/images/perl6.gif
I find it difficult to disagree, at the perl6 language
level. Here's to hoping something sensible emerges from
Parrot, at least. :)
F.
Leo writes:
> Wed 6.10. 18:00 GMT - feature freeze
> Sat 9.10. 8:00 GMT - code freeze - no checkins please
>
> - Parrot 0.1.1 will go out on Saturday.
> - nice release name wanted
'fireparrot'
Leo writes:
> Felix Gallo <[EMAIL PROTECTED]> wrote:
>
> > 6. It's a little alarming that if you look for struct
> > ParrotIOData in src/ and include/, you won't find it. I found
> > it, but couldn't figure out why it was there. Leo?
>
> B
(suggested reading: PDD 18)
I am starting work on the implementation of privileges. There are
a couple of open issues I'd like to bounce before I start typing
in earnest.
1. Privs take several forms. Privs can be per-interpreter
(no computed goto), per set-of-ops (e.g., "deny everything",
"a
Dan writes:
> True enough. Oh, don't get me wrong, I think we can go faster than
> the perl 5 regex engine. I just don't think we can do in 2 seconds
> what takes perl 5 10 seconds... :-P
Yeah, I meant the other way around. Lacking any kind of formal
specification for it, my general thought is
Dan writes:
> I don't think we're going to be able to manage doing our matches in
> 20% of the time of the current regex engine. That's a bit ambitious,
> even for me. :)
I dunno, there are a number of extant cases of languages that
manage to run regexes just as fast as the current regex engine.
Dan writes:
> [...]
> Yes, and some of the initial list already has ops to do those bits,
> though I fully plan on evil cheating versions for some extra speed.
If I recall correctly, someone with the best intentions attempted
to write a clear, object-oriented (but still C/C++ based) regex
engine
Nicholas writes:
> I can't really see how you can rotate a bignum that doesn't have a width
> already associated with it.
Maybe that's the answer: unless a bignum has a limit set on it,
rotate is shift ('we're just rotating a really, really large number...')
F.
Dan writes:
> >The "some multiple" being the next largest power of 256 that contains the
> >value, or the width that the value happens to be stored in at that time?
> >(Based on previous values assigned to that PMC which may have widened it)
>
> Good question. The size of the bignum, if it's been
Nick writes:
> 2 * 3 give a bignum. That feels evil.
> Except that the way that $a = 2 * 3 will work is that the assignment of
> the bignum temporary to $a will cause $a to drop it back to an int
> (for most languages' choice of target PMC) ?
Dan, any feeling about RISC vs. CISC? Because to me, t
Aaron writes:
> COME FROM is very different, and (as with much of Intercal) was created
> specifically to be obtuse. Discussing it as if it's a useful feature
> tends to creep me out because I get the feeling someone might actually
> put it in a language I care about.
I feel the same way about
Aaron writes:
> Ok, this is starting to look like people speaking seriously about using
> Intercal's COME FROM (http://c2.com/cgi/wiki?ComeFrom)... can we just
> step back and take a deep breath of AIR please? Seriously, this is
> starting to creep me out.
In case anyone reading this is getting co
Dan writes:
> sub foo :come_from('+', int, int) {}
One problem with MMD in general, and return specifically, is
'what happens if multiple M match the same D requirements?
i.e.,
sub foo :come_from('+', int, int) { shift; shift builtin::+ shift };
sub bar :come_from('+', int, int) { shift; shi
On Tue, Aug 17, 2004 at 04:08:34PM -0400, Dan Sugalski wrote:
> 1) We're going to have MMD for functions soon
> 2) Function invocation and return continuation invocation's
> essentially identical
> 3) Therefore returning from a sub/method can do MMD return based on
> the return values
>
> Someon
Dan writes:
> Anyway, there *is* a threefold plan, involving quotas,
> privileges/capabilities, and restricted embedding environments.
If there's a link out there, I must've missed it. Is there one?
> >clock time (ulimit style)
>
> This'd be a per-interpreter, per-user quota.
Depending on
The summary: request for architectural analysis.
The motivation: there are certain languages, possibly including perl 6,
that will benefit from the ability to flow from one parrot interpreter
to another. For example:
#!//googlestorage/programs/perl7.08032005
use remote qw( :googlecompute-shared
17 matches
Mail list logo
