Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

> Somebody gimme a cookie. /me hands Steve a cookie. > If the rx info object is going away, then obviously those parts of the > patch need not be applied. But in the meantime, it's nice to have a > Parrot that doesn't crash. I agree. My disclaimer about the regex code in my original email was t

Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

> I have also come to the conclusion that tracking down these memory > bugs is way too difficult right now. I tracked the above problem back > from a seg fault, which was resulting from a garbage value in the byte > code stream, which was triggered by adding a PMC to the free list > until I added

Re: [PATCH] hash init (Version 5)

On 12 Aug 2002, Jason Greene wrote: > One more safety check (fixes another crash bug). Hopefully this is the > last patch patch. Applied, thanks. Daniel Grunblatt.

Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

This is a patch that clears up all of the GC_DEBUG-revealed bugs, at least on my machine. As I enumerated in my previous email, there are a lot of different ways to fix these sorts of problems, and this just kinda picks one for each problem encountered. This patch includes the stuff done by Jason

Re: debugger.pod

On Fri, 2 Aug 2002, Aldo Calpini wrote: > > hello everybody, > > here is my rough draft of the documentation for the > Parrot debugger. please review it (expecially the > boilerplate stuff like TITLE, HISTORY, etc. -- I don't > know if I have properly followed convention) (and if there > is one)

Re: Prototypes

On Tue, 13 Aug 2002, John Porter wrote: > Piers Cawley wrote: > > I'd also like to be able to generate parrot code from within parrot > > and immediately execute it... > > Something like that will be needed for eval() anyway, right? Yes, like PDB_eval() may be... Daniel Grunblatt.

Re: Prototypes

Piers Cawley wrote: > I'd also like to be able to generate parrot code from within parrot > and immediately execute it... Something like that will be needed for eval() anyway, right? -- John Douglas Porter

Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

In tracing down the next crash bug using GC_DEBUG, I found that the following code in new_stack is unsafe: stack->buffer = new_buffer_header(interpreter); Parrot_allocate(interpreter, stack->buffer, sizeof(Stack_Entry_t) * STACK_CHUNK_DEPTH); A GC can be triggered by

Re: [PATCH] new op in core.ops

Jerome Quelin wrote: > --snip-- > But, there is a tiny, little problem: I don't call srand(), and thus get > always the same value. I don't know *where* to call srand(). I don't even > know *if* I should call srand(). > Anyway, here's the patch and be kind since this is my first patch ;) (pod > c

Re: [PATCH] core.ops and pod

Jerome Quelin wrote: > > Btw, how do you prefer me to send patch (as if I were able to send more > patches... anyway...): plain text inside the mail or attached (such as this > one)? This is a great start, Jerome! A name for the patch might be a nice touch, but it applied just fine. -- Jeff <[EM

[PATCH] new op in core.ops

Well, I don't know if this is interesting, but here's a patch that implement: op rand(out NUM) op rand(out NUM, in INT) and does what you can guess. There's also a test file (I don't know wether the tests should go in an existant test file). But, there is a tiny, little problem: I don't c

Re: Prototypes

On 13 Aug 2002, Piers Cawley wrote: > Melvin Smith <[EMAIL PROTECTED]> writes: > > > At 06:56 PM 8/12/2002 +0100, Simon Cozens wrote: > > >Here's a more interesting question: which parts of Parrot are > > >enshrined, and which are prototypes, ready to be thrown away? For > > >instance, I'd say mu

Re: [PASM] PerlArray.length issue a warning

Jerome Quelin wrote: >Hi, it's me again with my questions on pasm... > >I just downloaded the latest version of Parrot (it's currently 17:00 GMT). >$ ./parrot -v >[...] >This is parrot version 0.0.7-devel built for i386-linux >[...] >$ cat test.pasm >new P0, .PerlArray >set P0[10], "foo" >set I

Re: Keyed access to PerlArray/PerlHash

On Tue, 13 Aug 2002, Tom Hughes wrote: > In message > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > Nobody's doing a get_integer on key PMCs--we're peeking directly. > > (Integer lookup can also be done via the keyed_int method of the > > vtable)

RE: [PASM] problem opening / reading file

At 02:27 AM 8/13/2002 -0400, Dan Sugalski wrote: >Anyone up to throwing a list of outstanding > problems with the I/O system together? From: Clinton A. Pierce [mailto:[EMAIL PROTECTED]] >I'd volunteer, except that I'm used to grunging > around at the assembler level of I/O (INT 21h!) > or with C'

Re: Keyed access to PerlArray/PerlHash

In message Dan Sugalski <[EMAIL PROTECTED]> wrote: > Nobody's doing a get_integer on key PMCs--we're peeking directly. > (Integer lookup can also be done via the keyed_int method of the > vtable) At the moment it is using get_integer as I decided

[PATCH] core.ops and pod

One should begin with slight updates.. :) So this patch is just about pod in core.ops (unbalanced =over / =back, and a missing blank line). Btw, how do you prefer me to send patch (as if I were able to send more patches... anyway...): plain text inside the mail or attached (such as this one)?

[PASM] PerlArray.length issue a warning

Hi, it's me again with my questions on pasm... I just downloaded the latest version of Parrot (it's currently 17:00 GMT). $ ./parrot -v [...] This is parrot version 0.0.7-devel built for i386-linux [...] $ cat test.pasm new P0, .PerlArray set P0[10], "foo" set I0, P0.length print I0 print "\n" $

Re: Keyed access to PerlArray/PerlHash

At 5:49 PM +0100 8/13/02, Tom Hughes wrote: >In message > Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> Hash should support integer lookup. PerlHash doesn't have to, and may >> throw an exception. > >I don't follow the logic behind this... Making

Re: Keyed access to PerlArray/PerlHash

At 5:50 PM +0100 8/13/02, Tom Hughes wrote: >In message > Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> Arrays don't have to support lookup by string keys. They also can >> throw an exception. > >How about numeric keys? Presumably they can also th

Re: Keyed access to PerlArray/PerlHash

In message Dan Sugalski <[EMAIL PROTECTED]> wrote: > Arrays don't have to support lookup by string keys. They also can > throw an exception. How about numeric keys? Presumably they can also throw an exception as it doesn't make much sense to acce

Re: Keyed access to PerlArray/PerlHash

In message Dan Sugalski <[EMAIL PROTECTED]> wrote: > Hash should support integer lookup. PerlHash doesn't have to, and may > throw an exception. I don't follow the logic behind this... Making it work for one but not another is tricky - either get

Re: [PASM] problem opening / reading file

At 02:27 AM 8/13/2002 -0400, Dan Sugalski wrote: >At 11:13 PM -0400 8/12/02, Clinton A. Pierce wrote: >>At 10:04 PM 8/12/2002 +0200, Jerome Quelin wrote: >> >>>I looked at parrot_assembly.pod and saw: >>>open px, sy >>>Open the file Y on filehandle X >>>read px, py, pz