[netlabs #627] Parrot Debugger

2002-05-26 Thread via RT
# New Ticket Created by Daniel Grunblatt # Please include the string: [netlabs #627] # in the subject line of all future correspondence about this issue. # http://bugs6.perl.org/rt2/Ticket/Display.html?id=627 > While making the Parrot compiler I note that it's quite complicated to debug a Pa

Re: New Assembler for your perusal

2002-05-26 Thread Jeff
Steve Fink wrote: > > I thought the ultimate goal was to make this: > > set P0[S0], 1 > set P0[S1], 2 > set I0, P0[S0] > set I1, P0[S1] You're perfectly welcome to create a new version of 'set' and 'get' that accepts this parameter format. There's nothing special about the new notation.

Re: Hashtable+GC problems

2002-05-26 Thread Mike Lambert
> > Something about the whole setup just feels wrong. GC shouldn't be this > > intrusive. And it definitely shouldn't slow down the common case by > > making the compiler defensively reload a buffer pointer every few > > instructions (it'll be cached, but it fouls up reordering.) > > Alright. Toda

Re: Hashtable+GC problems

2002-05-26 Thread Mike Lambert
> Ok, I'll finish off the original conversion to indexed access that I > began once, before giving up in disgust. The problem is not just that > you have to use indices instead of pointers; it's also that you have > to constantly go back to the buffer header before you can get > anywhere. That nee

Re: Hashtable+GC problems

2002-05-26 Thread Steve Fink
On Mon, May 20, 2002 at 10:53:46PM +0200, Peter Gibbs wrote: > Steve Fink wrote: > > Is there some way to make the default be that things will not get > > moved around, and allow routines to volunteer to have their guts > > scrambled if they know how to handle it? > > A few random thoughts re buf

Re: REGEX structure and Regex implementation

2002-05-26 Thread Steve Fink
On Tue, May 21, 2002 at 03:57:33PM -0500, David M. Lloyd wrote: > Are the REGEX structure and the match vtable methods officially dead? The > POD inside of rx.ops does not mention them at all, and right now REGEX is > typedef'd to void and no-one uses the 'match' method for anything. > > Since r

Re: New Assembler for your perusal

2002-05-26 Thread Steve Fink
On Sun, May 26, 2002 at 01:52:58AM -0400, Jeff wrote: > 3) KEYED ACCESS > > Yes, you heard me. The new assembler accepts the following test program > (which is what I used to test the feature, so I know it works): > > set_keyed P0[S0],1 # HERE IT IS > set_keyed P0[S1],2 > get_keyed I0,P0[S0] > g

Re: [netlabs #626] [PATCH] reclaimed fix [APPLIED]

2002-05-26 Thread Daniel Grunblatt
On 26 May 2002, Mike Lambert wrote: > # New Ticket Created by Mike Lambert > # Please include the string: [netlabs #626] > # in the subject line of all future correspondence about this issue. > # http://bugs6.perl.org/rt2/Ticket/Display.html?id=626 > > > > Looksd like the logic for keeping trac

[netlabs #626] [PATCH] reclaimed fix

2002-05-26 Thread via RT
# New Ticket Created by Mike Lambert # Please include the string: [netlabs #626] # in the subject line of all future correspondence about this issue. # http://bugs6.perl.org/rt2/Ticket/Display.html?id=626 > Looksd like the logic for keeping track of unclaimed buffer data missed a few places.

RE: A big GC D'oh!

2002-05-26 Thread Brent Dax
Dan Sugalski: # On my part. Here's a way we can dodge the whole neonate, infant # mortality nonsense. # # Instead of marking everything dead at the beginning of a DOD run, # which'll get us the most aggressive cleanup, we mark things dead at # the *end* of the run. Then we also allocate all ou

Re: New Assembler for your perusal

2002-05-26 Thread Jeff
Clinton A Pierce wrote: > > At 09:17 AM 5/26/2002 +0200, Sebastian Bergmann wrote: > >Jeff wrote: > > > newasm has been completely rewritten. Three surprises lurk within. > > > >sb@wopr-mobile:/usr/src/parrot> newasm > >Can't locate auto/Parrot/PakFile2/autosplit.ix > > Go into lib/Parrot and p

Re: New Assembler for your perusal

2002-05-26 Thread Jeff
Sebastian Bergmann wrote: > > Jeff wrote: > > newasm has been completely rewritten. Three surprises lurk within. > > sb@wopr-mobile:/usr/src/parrot> newasm > Can't locate auto/Parrot/PakFile2/autosplit.ix in @INC (@INC contains: > ../lib/Par > rot/blib/arch/auto/Parrot/PakFile2 ./lib/Parrot/blib

Re: Parrot and Mono / .Net

2002-05-26 Thread Jerome Vouillon
On Fri, May 24, 2002 at 09:48:13AM -0400, Melvin Smith wrote: > I hate debugging stack operations. Its one of the hardest bug's to spot > in my limited experience. For this reason I'm glad that Parrot allows me > to think in registers, not stack locations. Given, everything I've said > relates

A big GC D'oh!

2002-05-26 Thread Dan Sugalski
On my part. Here's a way we can dodge the whole neonate, infant mortality nonsense. Instead of marking everything dead at the beginning of a DOD run, which'll get us the most aggressive cleanup, we mark things dead at the *end* of the run. Then we also allocate all our headers marked as live

Re: New Assembler for your perusal

2002-05-26 Thread Sebastian Bergmann
"Clinton A. Pierce" wrote: > Go into lib/Parrot and perl Makfile.pl && make and then try it > again. Works okay for me. I supposed this would be triggered automatically by 'make' in /parrot. Thanks, Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ http://

GC quick note

2002-05-26 Thread Dan Sugalski
One thing that might help the GC situation some. Since we've got mutable strings (yep, it's OK) perhaps we should thump the string functions a bit to not allocate new strings quite so often. That'll leave us fewer headers to worry about. -- Dan ---

Re: GC design

2002-05-26 Thread Sean O'Rourke
On Sun, 26 May 2002, Peter Gibbs wrote: > "Mike Lambert" wrote: > > > I know Dan's proposed solution has already been committed, but I'd > > like to add my support for this. In addition to providing a counter per > > opcode to ensure that we don't prematurely GC data, this field could also > > be

Re: New Assembler for your perusal

2002-05-26 Thread Clinton A. Pierce
At 09:17 AM 5/26/2002 +0200, Sebastian Bergmann wrote: >Jeff wrote: > > newasm has been completely rewritten. Three surprises lurk within. > >sb@wopr-mobile:/usr/src/parrot> newasm >Can't locate auto/Parrot/PakFile2/autosplit.ix Go into lib/Parrot and perl Makfile.pl && make and then try it aga

Re: Parrot and Mono / .Net

2002-05-26 Thread Ask Bjoern Hansen
[EMAIL PROTECTED] (Sebastian Bergmann) writes: > Leon Brocard wrote: > > Oh, this happens to be a FAQ. The main reason is: > > > > http://www.parrotcode.org/faq/ > > I know the technical reason for a new VM, but this could've been a new > VM for Perl 6 only. What I'd like to know is the moti

lib/Parrot/Types.pm deleted

2002-05-26 Thread Sebastian Bergmann
lib/Parrot/Types.pm is deleted upon 'make realclean' and needs to be retrieved anew from CVS. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

Tetris for Parrot

2002-05-26 Thread Jens Rieks
I've written a tetris clone in parrot asm. Its not finished yet, but playable. The game needs nonblocking input, there is a small tetris.pl that sets STDIN into nonblocking, then calls parrot an resets STDIN afterwards. Because it uses escape-sequences for cursor control it will probably not ru

Re: GC design

2002-05-26 Thread Peter Gibbs
"Mike Lambert" wrote: > I know Dan's proposed solution has already been committed, but I'd > like to add my support for this. In addition to providing a counter per > opcode to ensure that we don't prematurely GC data, this field could also > be reused to calculate the generation of a particular

Re: New Assembler for your perusal

2002-05-26 Thread Sebastian Bergmann
Jeff wrote: > newasm has been completely rewritten. Three surprises lurk within. sb@wopr-mobile:/usr/src/parrot> newasm Can't locate auto/Parrot/PakFile2/autosplit.ix in @INC (@INC contains: ../lib/Par rot/blib/arch/auto/Parrot/PakFile2 ./lib/Parrot/blib/lib ./lib /usr/lib/perl5/5. 6.1/i586-linux

Re: GC design

2002-05-26 Thread Mike Lambert
> Add a counter to the interpreter structure, which is incremented every > opcode (field size would not be particularly important) > Store this counter value in every new object created, and set the 'new > object' flag (by doing this on every object, we remove the requirement for > the creating fu