Re: Copy-on-write strings

2002-05-10 Thread Graham Barr
On Fri, May 10, 2002 at 12:12:41PM -0400, Dan Sugalski wrote: > At 5:38 PM +0200 5/10/02, Peter Gibbs wrote: > >The result is that the last header of a COWed string will still believe that > >the buffer is shared until a GC collection run occurs, and therefore could > >result in buffers being copi

Re: Copy-on-write strings

2002-05-10 Thread Dan Sugalski
At 5:38 PM +0200 5/10/02, Peter Gibbs wrote: >The result is that the last header of a COWed string will still believe that >the buffer is shared until a GC collection run occurs, and therefore could >result in buffers being copied unnecessarily. Your system eliminates this >problem; however, I bel

Tossing #lines from generated ops files

2002-05-10 Thread Dan Sugalski
Just set the PARROT_NO_LINE env variable to a true value. (After syncing up CVS, of course) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED]

Re: JIT for Win32

2002-05-10 Thread Dan Sugalski
At 12:29 PM -0300 5/10/02, Daniel Grunblatt wrote: >On Fri, 10 May 2002, Aldo Calpini wrote: > > also, to inspect core_ops.c in the debugger (instead of the not-so-helpful > > core.ops), I had to comment all the #line directives in core_ops.c. >I hate that too. If you want to throw in a patch t

Re: Copy-on-write strings

2002-05-10 Thread Peter Gibbs
Hi Nicholas The final design is now waiting on Dan, but it is always interesting to see other ideas. Like you, I rejected the parent/child technique. However, my proposed solution did not use any links at all, because it relies on the garbage collection system to determine when a shared buffer h

Re: JIT for Win32

2002-05-10 Thread Daniel Grunblatt
On Fri, 10 May 2002, Aldo Calpini wrote: > it was really nice to work on it anyway. I have learned alot of things, and > would like to suggest an 'enhancement' to Configure.pl. > > if the compiler is 'cl' (that is, Visual C++), and you invoke Configure.pl > with --debugging, it should add '-DDEBU

RE: JIT for Win32

2002-05-10 Thread Brent Dax
Aldo Calpini: # Daniel Grunblatt wrote: # > > is anybody working on JIT-enabling the Win32 platform? # > # > Yes, the new JIT will work (actually, it works) on Windows, # probably # > you didn't read the TODO, says '(currently on hold, waiting for JIT # > v2)', so, as soon as the the code is in

Re: JIT for Win32

2002-05-10 Thread Aldo Calpini
Daniel Grunblatt wrote: > > is anybody working on JIT-enabling the Win32 platform? > > Yes, the new JIT will work (actually, it works) on Windows, probably you > didn't read the TODO, says '(currently on hold, waiting for JIT v2)', so, > as soon as the the code is in you will be able to use the JI

Re: JIT for Win32

2002-05-10 Thread Daniel Grunblatt
On Fri, 10 May 2002, Aldo Calpini wrote: > > hello there (and especially the JIT team), > > is anybody working on JIT-enabling the Win32 platform? Yes, the new JIT will work (actually, it works) on Windows, probably you didn't read the TODO, says '(currently on hold, waiting for JIT v2)', so, a

JIT for Win32

2002-05-10 Thread Aldo Calpini
hello there (and especially the JIT team), is anybody working on JIT-enabling the Win32 platform? I've done some work on this (using MASM as an assembler and VisualC's DUMPBIN as a disassembler instead of the GNU as and objdump). I have a somewhat-working Parrot/Jit/MSWin32-x86.pm that generat

JIT for Win32

2002-05-10 Thread Aldo Calpini
hello there (and especially the JIT team), is anybody working on JIT-enabling the Win32 platform? I've done some work on this (using MASM as an assembler and VisualC's DUMPBIN as a disassembler instead of the GNU as and objdump). I have a somewhat-working Parrot/Jit/MSWin32-x86.pm that genera