Some final 5000 life results from my system, and a few improvements
I believe are still possible:
Before COW: 172 seconds
After COW: 121 seconds
A 30% improvement in performance is not too bad, I suppose.
Well done Mike!
Thanks!
CVS/COW with stack pointer alignment = four: 93 seconds
[EMAIL PROTECTED] (Jeff) writes:
The subject pretty much says it all. The format pretty much corresponds
to the upcoming Exegesis. Major changes were to the modifiers, and a few
syntax changes in the depths.
I've started rewriting my Shishi P6 RE module since it was becoming
way too
Jeff Goff:
# The mass of ICU code that's been added to Parrot. It's taking
Have we determined that there are no programming language and
portablility issues yet?
Are all the bits we need written in C? If not, we can't use it.
Does ICU handle Unix, Windows, VMS and Palm OS? If not, we can't
Mike Lambert wrote:
Should this be a configure.pl-determined constant? Should we hardcode it
to sizeof(void*)? Is this behavior guaranteed by the C spec? Can we
assume it across all platforms even if it is not guaranteed?
I would be in favour of making it configuration-determined, just in
On Wed, 21 Aug 2002, Mark Koopman wrote:
I wonder how many interested observers of this list there are like
myself. I only wish I had the time experience/skill/knowledge to
contribute.
Keep up the good work.
Lurker honk, agreement. :)
R.
On Wed, Aug 21, 2002 at 02:11:29PM +, Daniel Grunblatt wrote:
Apart from that, does anyone know why test doesn't run on OpenBSD?
I get:
ar: illegal option -- s
Gnu-ism? What ar does OpenBSD use?
A number of modifiers (mod) may immediately follow the p
keyletter, to
'John Porter' wrote:
Brent Dax wrote:
No; but statements like imcc MUST provide access to ALL of parrot's
(still very dynamic) feature set and discussions of imcc syntax
naturally lead to questions of imcc's role in the parrot project.
E.g. will the perl6 compiler target imcc?
The perl6
Sean O'Rourke wrote:
On Wed, 21 Aug 2002, Leopold Toetsch wrote:
Well, Sean's not quite sure about that. I agree with Melvin that using
PASM syntax for IMCC could make it harder to target other platforms.
I don't know Melvin's plan for other targets - but - as parrot is very
special - I
Melvin Smith wrote:
At 11:15 PM 8/21/2002 +0200, Leopold Toetsch wrote:
So please, first, let's consider the status quo, not the future.
Agree.
_SV_s1 = clone $P1
I've considered changing '=' to mean clone, and add ':=' to imply set.
What do you think?
No changes in
On Wed, Aug 21, 2002 at 07:17:22AM -0700, Michael G Schwern wrote:
On Wed, Aug 21, 2002 at 02:11:29PM +, Daniel Grunblatt wrote:
Apart from that, does anyone know why test doesn't run on OpenBSD?
I get:
ar: illegal option -- s
Gnu-ism? What ar does OpenBSD use?
Obviously and
Dan Sugalski wrote:
The intent ultimately
is that you hand an AST, and potentially some rules, to IMCC and it
creates bytecode for you from it.
That's different, then. Then the whole issue of syntax goes away.
Unless the data interchange format is textual; but even then, you'd
want a
I've just got a cvaazy idea. Why not have a multihash.pmc, multdimensional
hashes. I've been going through perlhash code and my multiarray code and,
as i see it, its doable. Why would we want something like that one
could ask? One idea is for translation from different languages ex:
new P0,
It's a fact that we have a problem with pmc's that has custom functions
which dosent fit into the vtable. Therefore i suggest we add a pointer in
pmc struct that points to a function list, Also adding 3
functions to vtable struct that manipulates this list.
register_function( PMC *p, void
Josef Hook wrote:
It's a fact that we have a problem with pmc's that has custom
functions which dosent fit into the vtable. Therefore i suggest
we add a pointer in pmc struct that points to a function list,
we already have find_method and invoke, they just need to be
implemented :-)
I was
14 matches
Mail list logo
