Re: [PATCH] Help catching gc errors in HLL

2008-08-20 Thread NotFound
On Mon, Jun 2, 2008 at 7:18 PM, chromatic <[EMAIL PROTECTED]> wrote: > I like the general idea, but I wonder if there's something cleaner than an > environment variable. Nothing really comes to mind at the moment besides > making argument processing even uglier in IMCC's main.c. > > Let's think a

Re: [PATCH] Help catching gc errors in HLL

2008-06-02 Thread chromatic
On Monday 02 June 2008 07:58:57 NotFound wrote: > Previous version generates a warning when building with C, fixed now. I like the general idea, but I wonder if there's something cleaner than an environment variable. Nothing really comes to mind at the moment besides making argument processing

Re: [PATCH] Help catching gc errors in HLL

2008-06-02 Thread NotFound
Previous version generates a warning when building with C, fixed now. -- Salu2 Index: src/runops_cores.c === --- src/runops_cores.c (revisión: 28033) +++ src/runops_cores.c (copia de trabajo) @@ -242,13 +242,28 @@ opcode_t * runo

[PATCH] Help catching gc errors in HLL

2008-06-01 Thread NotFound
After some discussion on #parrot about the slowness of the gcdebug core with HLL programs, I've done this proof of concept patch: it skips the gc run the first n opcodes, with n defined by setting an environment variable. Example of usage: PARROT_GCDEBUG_SKIP=85000 ../../parrot --runcore=gcdebug