Re: [perl #19334] [PATCH] PARROT_GC_DEBUG=1 failures

At 8:06 PM + 12/21/02, Jason Gloudon (via RT) wrote: Trying to run parrot with the PARROT_GC_DEBUG environment variable set to 1 causes parrot to fail during initialization. The GC_DEBUG flag is set early based on the environment variable, but the marker for the top of the C stack is not set

Re: [perl #19334] [PATCH] PARROT_GC_DEBUG=1 failures

This patch should also be applied, or initialize_core_pmcs will fault with PARROT_GC_DEBUG set. diff -u -r1.52 embed.c --- embed.c 21 Dec 2002 10:07:34 - 1.52 +++ embed.c 21 Dec 2002 21:34:32 - @@ -32,6 +32,8 @@ we set up our own in embed.c:Parrot_runcode()? */ { +

[perl #19334] [PATCH] PARROT_GC_DEBUG=1 failures

# New Ticket Created by Jason Gloudon # Please include the string: [perl #19334] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19334 > Trying to run parrot with the PARROT_GC_DEBUG environment variable set to 1 causes par

Re: [perl #19332] [PATCH] mark PMCs w/o next_for_GC

Dan Sugalski wrote: At 6:02 PM +0100 12/21/02, Leopold Toetsch wrote: And the memory get directly malloced from system. Which argues against having it in one piece, unfortunately, as then we have the occasional need for one huge-ish chunk of memory. Damn. I see. ... I wanted chunks

Re: [perl #19332] [PATCH] mark PMCs w/o next_for_GC

At 6:02 PM +0100 12/21/02, Leopold Toetsch wrote: Dan Sugalski wrote: From a reading of the code, this allocates memory within a function that's called during garbage collection. We can't do that. This buffer could also be allocated, when more PMCs are alloced. The size if fix, i.e. the tot

Re: [perl #19332] [PATCH] mark PMCs w/o next_for_GC

Dan Sugalski wrote: From a reading of the code, this allocates memory within a function that's called during garbage collection. We can't do that. This buffer could also be allocated, when more PMCs are alloced. The size if fix, i.e. the total amount of PMCs. And the memory get directly mal

Re: [perl #19331] [PATCH]befunge 0.1.0 released

At 2:27 PM + 12/21/02, Jerome Quelin (via RT) wrote: Thanks to Leo who fixed the bug when setting a list of lists element, the befunge interpreter now uses a list of lists (perlarray of perlarrays to be more precise) instead of a list of strings. I thought this big evolution needed a gap in m

Re: [perl #19332] [PATCH] mark PMCs w/o next_for_GC

At 3:47 PM + 12/21/02, Leopold Toetsch (via RT) wrote: # New Ticket Created by Leopold Toetsch # Please include the string: [perl #19332] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19332 > I'll send this first to the

[perl #19332] [PATCH] mark PMCs w/o next_for_GC

# New Ticket Created by Leopold Toetsch # Please include the string: [perl #19332] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19332 > I'll send this first to the list for review. This patch changes mark_used(PMC *) so

[perl #19331] [PATCH]befunge 0.1.0 released

# New Ticket Created by Jerome Quelin # Please include the string: [perl #19331] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19331 > Thanks to Leo who fixed the bug when setting a list of lists element, the befunge inte

Re: [perl #19179] [PATCH] creating string_max_bytes()

[EMAIL PROTECTED] (via RT) wrote: # New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #19179] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19179 > This patch (1) Creates a string_max_bytes() fu

Re: [perl #19328] bug/feature (?) in perlarray of perlarrays

Jerome Quelin (via RT) wrote: # New Ticket Created by Jerome Quelin # Please include the string: [perl #19328] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19328 > Thanks for reporting, fixed (modulo the autovivify thin

Re: [perl #19191] [PATCH] creation of string_nprintf()

[EMAIL PROTECTED] (via RT) wrote: # New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #19191] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19191 > This patch creates a string_nprintf(), as descr

Re: [perl #19328] bug/feature (?) in perlarray of perlarrays

Jerome Quelin (via RT) wrote: # New Ticket Created by Jerome Quelin # Please include the string: [perl #19328] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19328 > Is it a bug or a feature? For me, it looks like a bug,

Re: cvs.perl.org?

Jerome Quelin wrote: > Is it me or cvs.perl.org isn't in the dns anymore? Never mind, my ISP dns should've been down for a moment. Everything is ok by now... Jerome -- [EMAIL PROTECTED]

cvs.perl.org?

Hey, Is it me or cvs.perl.org isn't in the dns anymore? $ cvs diff | tee lol.patch Unknown host cvs.perl.org. No comment, Jerome -- [EMAIL PROTECTED]

[perl #19328] bug/feature (?) in perlarray of perlarrays

# New Ticket Created by Jerome Quelin # Please include the string: [perl #19328] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19328 > Hi there, While trying to use a PerlArray of PerlArrays (guess why? :-) ), I ran into

Buffer/PMC unification #8

Next (small) step towards $subject is in: - classes may have a class_init code: this is used in array.pmc and perlhash.pmc to setup sized header pools for bufferlike objects - sized_pool access functions are in headers.c - the duplicates in smallobject.c are gone. The plan is to use get_buffe