Heya,
After seeing all the bruhaha on the list about keyed-ness, I thought I'd
try my hand at it, to see if I could get any farther before running up
into the wall. :)
Here's my own list of questions...first, the main problem with keys, as I
see it, is that there is no guiding PDD or spec that
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] Recursive
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
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
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
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 directory
TG cvs
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
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
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
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 contents, the hash
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 you
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
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
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 restored
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 access
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_stack
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 performance
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.
Couldn't I
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 something I
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 suspect not.
* 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
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
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
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
===
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 were
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 extensions to
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
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 for
28 matches
Mail list logo
