> Design Edict #3: All destinations *must* be marked as such in the
> bytecode metadata segment. (I am officially nervous about this, as I
> can see a number of ways to subvert this for evil)
[...]
> Design Edict #4: Dan is officially iffy on jumps, but can see them as
> useful for lower-level s
> But then sometimes you'd *want* hashing to be based on the
> content.
OK, I'll bite -- when would you want this behavior? This behavior means
that once you change the contents, the hash value would become irretrievable
unless you restored the contents of the key. (Is this useful in functional
As the last person to change the key hash algorithm, I'd like to chime in
here with a request that each PMC provide a string that the key hashing
algorithm can operate on. To some degree this is just selfish on my part --
I've got plans for upgrading the key hash algorithm in Perl 5 and Perl 6
wh
> I've no strong opinions on how it's done, but I do believe that
> it's *very* important that subroutine calls be as fast as possible
> (and significantly faster than perl5). This must be a priority.
>
> To my mind that means that a subroutine should be responsible for
> setting up whatever _it_
> Should strings in parrot be mutable or immutable? Right now we've a
> mix, and that's untenable.
I've improved (read: got working) 2 C++ string libraries in the past, both
with mutable strings. As performance was a primary consideration on both
systems that used these libraries, I chose to co
If it's not too late, I'd like to also add:
Code Complete : A Practical Handbook of Software Construction
Steve C. McConnell
No matter what else we do, we know we're going to be writing code for this
puppy. IMHO I was writing pretty solid code already, but I'm seeing ways to
impro
Chain Frenkel writes:
>DS> For the internals, though...
>
>DS> This would be very useful, and it's a feature I'd really like to
implement.
>DS> Basically you're asking for pre-computed, indirect, shared hash keys.
This
>DS> sounds like a Good Plan to me.
>
>Why precomputed? Any 'interned' string
> One C++ problem I just found out is memory management. It seems
> that it's impossible to 'new' an object from an specified memory block.
> So it's impossible to put free'd objects in memory pool and re-allocate
> them next time.
It can't be done by the default new operator, but you can do it
Bradley M. Kuhn wrote:
> For the world of the JVM port, it's imperative that hooks be
> provided so
> that the front-end can be run independently, and a different
> back-end can be
> run (to emit bytecode of some sort).
All this also dovetails nicely with the mass-market world of embedded
devic
Although Perl interpretation is divided into several passes (parser/lexer,
optimizer, tree/bytecode runner), all these passes are grouped together in
one binary. Under some memory-constrained conditions, it could be better if
each pass ran as its own program, passing the transformed data onto the
>>BTW, I have access to Rational Software's Quantify (and PureCoverage and
>>Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests.
>
>If you want to get "in the mood" it would be good to fire it up on
>(say) perl5.6.0 and see where the hot-spots are.
Planning on it as part of
>Leaping to conculusions based on no tests at all is even worse...
>
>Will anyone bite the bullet and write the "Internals Decisions should
>be based on actual tests on multiple platforms" RFC ?
BTW, I have access to Rational Software's Quantify (and PureCoverage and
Purify) on WinNT and HP-UX 10
> For instance, if I'm running Perl on my Palm, I'd just as soon that
> index() were implemented in Perl using repeated substr() comparisons.
How small do we really need to go? Are we looking at implementing Perl for
microcontrollers, or are we only worrying about Perl for PDAs? The
difference
13 matches
Mail list logo
