# 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
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.
> > 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
> 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
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
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
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
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
# 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.
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
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
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
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
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
"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://
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
---
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
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
[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 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/
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
"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
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
> 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
24 matches
Mail list logo