At 02:19 PM 7/24/2002 +, [EMAIL PROTECTED] wrote:
>cvsuser 02/07/24 07:19:27
>
> Modified:languages/imcc imcc.l imcc.y
> Log:
> Set IF_r0_read for "set Px, Ay".
On IMCC's aggressive behaviour :)
I finally sat down and looked at this. This fix will only make the symptom
go away
With the mass of discussion revolving around PMCs lately, I
just want to put my 2 cents in.
It is not clear to me yet that there needs to be a 1-to-1 correlation
from PMC's to upper level "classes". I can't see Parrot ever
providing enough "vtable" methods for every language that will
ever target
> > If performance has to halve in order to implement such features, I hope
> > somebody plans to write Parrot::Lite!
>
> I'm not sure if I understand the problem properly, but is the problem with
> using exceptions (or using longjmp) and the like to unwind that we can't
> trust external extension
> With the call to trace_system_stack commented out in dod.c, I get 48.5
> generations per second. The full stats are:
> 5000 generations in 103.185356 seconds. 48.456488 generations/sec
> A total of 36608 bytes were allocated
> A total of 42386 DOD runs were made
> A total of 6005 collection runs
> This patch is rather questionable, and thus I did not commit it
> directly. However, it illustrates a point I wanted to make.
Doh! Hopefully my previous post will make a bit more sense now. :)
Mike Lambert
Index: array.pmc
===
This patch is rather questionable, and thus I did not commit it
directly. However, it illustrates a point I wanted to make.
As mentioned in my recent PARROT QUESTIONS email, a lot of the clutter in
the PMC aggregates can be removed with the use of redirecting functions.
The below patch reduces t
> This would only automate the generation of large amounts of code, not get rid
> of the large amount of code being generated. Once again, my complaint here is that
> the L2 cache would buckle under the weight of a dozen PMCs each defining a few dozen
> recursive accessors. The performance gain of
> * win32 can flush it's file buffers (FlushFileBuffers())
> * SetFilePointer knows about whence, win32 constants (values, not names) are the
>same as in linux.
Applied, thanks.
Mike Lambert
On Tue, Jul 23, 2002 at 03:10:50PM +, Ashley Winters wrote:
> On Tuesday 23 July 2002 08:44 am, Alberto Manuel Brandão Simões wrote:
> > On Tue, 2002-07-23 at 09:27, Ashley Winters wrote:
> > > @foo = ();
> > > %hash{@foo} = 10;
> > > push @foo, 'This would change the hash key for @foo?';
> >
On Wed, Jul 24, 2002 at 10:38:09PM +0200, Peter Gibbs wrote:
> "Mike Lambert" wrote:
> > I know that there are faster solutions to the problem of child collection,
> > but Dan doesn't want to use them due to the problems that occur when we
> > start using exceptions (and longjmp, etc).
>
> If pe
"Mike Lambert" wrote:
> - addition of stack-walk code to avoid child collection
> - the GC refactoring I commited
> I suspect the former is what is causing your speed hit, although I'm not
> ruling out the possibility that my changes caused a problem as well. Can
> you disable the trace_system_st
On Wed, Jul 24, 2002 at 08:44:20AM -0700, Stephen Rawls wrote:
> The last two (well, the only two :) patches I sent
> were counted as spam. Some of the points were becuase
> I'm using Yahoo. Should I send patches from another
> e-mail address? I have a NASA e-mail account, but I
> can only acce
I had assumed Perl6 will have copy-on-write references, so that
$x = [1,2,3];
@y = *$x;
would not require a copy. However, on thinking about it further, I
realized that that would get you in trouble here:
$x = [1,2,3];
%h{$x} = 1;
@y = *x;
$x[0]++;
print %h{$x};
Thi
Hey Peter,
Sorry about not replying to your ealier message...I completely forgot
until I saw this message. :)
> Thanks Mike, those changes do indeed help. Current numbers on my system for
> 5000 generations of life with various versions of Parrot (using CVS tags)
> are:
> 0.0.5 47.99 genera
> TG> Does anyone know why I keep getting this:
> TG> $ cvs diff > diff.out
> TG> cvs server: failed to create lock directory for
`/cvs/public/parrot/Parrot'
> TG> (/cvs/public/parrot/Parrot/#cvs.lock): No such file or directory
> TG> cvs server: failed to obtain dir lock in repository
> TG> `/cvs
On Wednesday 24 July 2002 05:42 am, Jeff 'japhy' Pinyan wrote:
> On Jul 24, [EMAIL PROTECTED] said:
> >Nicholas Clark <[EMAIL PROTECTED]> wrote:
> >:Is there an easy way any regexp internals guru can suggest to patch
> >: perl5's regexp code to disable the optimiser?
> >
> >At the moment, I suspec
"Jeff 'japhy' Pinyan" <[EMAIL PROTECTED]> wrote:
:On Jul 24, [EMAIL PROTECTED] said:
:>Nicholas Clark <[EMAIL PROTECTED]> wrote:
:>:Is there an easy way any regexp internals guru can suggest to patch perl5's
:>:regexp code to disable the optimiser?
:>
:>At the moment, I suspect not.
:>
:>This is s
Thanks for the response.
On Tue, 2002-07-23 at 13:23, Melvin Smith wrote:
[reordered]
> If you want to take a whack at it before I get to it, take a look at the
> global variable ops, although they aren't perfect. I just stacked them
> on top of the Hash PMC that we already had.
If you think yo
On Wed, 2002-07-24 at 18:15, Aaron Sherman wrote:
> On Wed, 2002-07-24 at 12:34, Fisher Mark wrote:
> > > 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 content
On Wed, 2002-07-24 at 12:34, Fisher Mark wrote:
> > 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 rest
> 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
The last two (well, the only two :) patches I sent
were counted as spam. Some of the points were becuase
I'm using Yahoo. Should I send patches from another
e-mail address? I have a NASA e-mail account, but I
can only access it at work (they have external
accounts, but they don't give them to a
On Jul 24, [EMAIL PROTECTED] said:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
>:Is there an easy way any regexp internals guru can suggest to patch perl5's
>:regexp code to disable the optimiser?
>
>At the moment, I suspect not.
>
>This is something I hope we can make easier in the 5.9 track.
Co
Nicholas Clark:
> It tells you how good the parrot regexp opcode dispatch is relative to the
> perl regexp opcode dispatch.
Is the current Parrot regex engine worth comparing against? Is it sufficiently
extensibly-designed to allow it to do all that's required of it by A5 and
more?
--
There is
"Mike Lambert" wrote:
> I've just committed some changes tonight that improved performance
> on the GC-heavy tests in examples/benchmarks/ by about 8%.
Thanks Mike, those changes do indeed help. Current numbers on my system for
5000 generations of life with various versions of Parrot (using CVS
> On Wed, 24 Jul 2002 10:55:22 -0400, "Tanton Gibbs" <[EMAIL PROTECTED]> said:
TG> Does anyone know why I keep getting this:
TG> $ cvs diff > diff.out
TG> cvs server: failed to create lock directory for `/cvs/public/parrot/Parrot'
TG> (/cvs/public/parrot/Parrot/#cvs.lock): No such file or dir
Does anyone know why I keep getting this:
$ cvs diff > diff.out
cvs server: failed to create lock directory for `/cvs/public/parrot/Parrot'
(/cvs/public/parrot/Parrot/#cvs.lock): No such file or directory
cvs server: failed to obtain dir lock in repository
`/cvs/public/parrot/Parrot'
cvs [server
Sean O'Rourke wrote:
> The compiler should work with 5.005_03 now (you may need to get a newer
> version of Class::Struct -- I'm waiting to hear back on this).
Patches are on the way.
It works(tm) here, modulo imcc quirks, meaning same test results as with
5.6.1.
> /s
leo
On Wed, 24 Jul 2002, Mike Lambert wrote:
Mike,
I submit some patches a few days back, one with updates to the documentation
from my reverse engineering and probing efforts. I also implemented a patch
to make Array.PMC handle keys recursively. I'm kind of testing the waters
here. If they are ac
Applied, thanks.
If someone wants to mark this ticket as resolved, I'd appreciate it.
Mike Lambert
Scott Walters wrote:
> Date: Mon, 22 Jul 2002 08:49:33 GMT
> From: Scott Walters <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [perl #15317] [PATCH] Recurs
31 matches
Mail list logo
