At 11:47 AM 1/1/2002 +, Tim Bunce wrote:
>On Mon, Dec 31, 2001 at 06:53:29AM -1000, David & Lisa Jacobs wrote:
> > From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > > >Agreed. I'll probably have the encoding structure provide the
> > terminating
> > > >bytes. As a side note don't we also have to
At 09:30 AM 1/1/2002 -0800, Benjamin Stuhl wrote:
>--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 07:30 AM 12/30/2001 -1000, David & Lisa Jacobs wrote:
> >
> > >From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > > > At 08:33 PM 12/29/2001 -1000, David & Lisa Jacobs
> > wrote:
> > > > GC will manage
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 07:30 AM 12/30/2001 -1000, David & Lisa Jacobs wrote:
>
> >From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > > At 08:33 PM 12/29/2001 -1000, David & Lisa Jacobs
> wrote:
> > > GC will manage all the memory. Everything managed
> should either be hung
> >
On Mon, Dec 31, 2001 at 06:53:29AM -1000, David & Lisa Jacobs wrote:
> From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > >Agreed. I'll probably have the encoding structure provide the
> terminating
> > >bytes. As a side note don't we also have to split UTF-16 into UTF-16BE
> and
> > >UTF-16LE (big en
At 06:53 AM 12/31/2001 -1000, David & Lisa Jacobs wrote:
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > >Agreed. I'll probably have the encoding structure provide the
>terminating
> > >bytes. As a side note don't we also have to split UTF-16 into UTF-16BE
>and
> > >UTF-16LE (big endian and little
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> >Agreed. I'll probably have the encoding structure provide the
terminating
> >bytes. As a side note don't we also have to split UTF-16 into UTF-16BE
and
> >UTF-16LE (big endian and little endian)?
>
> I think UTF-16 can be a single encoding. The little/
At 09:55 PM 12/30/2001 -1000, David & Lisa Jacobs wrote:
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > We do still need to address the byte-orientation of the strings. Throwing
>a
> > single null byte on the end's not enough for buffers that have 16 or 32
>bit
> > characters.
>
>Agreed. I'll prob
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> We do still need to address the byte-orientation of the strings. Throwing
a
> single null byte on the end's not enough for buffers that have 16 or 32
bit
> characters.
Agreed. I'll probably have the encoding structure provide the terminating
bytes. As
At 08:33 AM 12/30/2001 -1000, David & Lisa Jacobs wrote:
>Here is the patch to make the string buffer separate from the structure
>again. I also snuck in a patch to the mops.pasm file in examples/assembly
>that changes an iton op to a set op.
Applied, thanks.
We do still need to address the byt
Here is the patch to make the string buffer separate from the structure
again. I also snuck in a patch to the mops.pasm file in examples/assembly
that changes an iton op to a set op.
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> So you still need the interpreter pointer, you just don't have to pass
At 07:30 AM 12/30/2001 -1000, David & Lisa Jacobs wrote:
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > At 08:33 PM 12/29/2001 -1000, David & Lisa Jacobs wrote:
> > GC will manage all the memory. Everything managed should either be hung
>off
> > a PMC or an internal structure. (There are GC hooks
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> At 08:33 PM 12/29/2001 -1000, David & Lisa Jacobs wrote:
> GC will manage all the memory. Everything managed should either be hung
off
> a PMC or an internal structure. (There are GC hooks in the vtable for
> complex things)
So does that mean I can get
At 08:33 PM 12/29/2001 -1000, David & Lisa Jacobs wrote:
> >From what I could tell, it looks like Dan put it in there as a potential GC
>hook when allocating the header of a string or PMC (see resources.c). My
>guess is that he is planning to fire off the GC from the interpreter.
>
>If that is th
On Sun, Dec 30, 2001 at 12:01:05PM +, Simon Cozens wrote:
> On Sat, Dec 29, 2001 at 10:46:48PM -1000, David & Lisa Jacobs wrote:
> > Here is the string patch with the interpreter left in. Take your pick :-)
>
> I'll apply this, on the basis of only changing as little as possible
> at a time.
On Sat, Dec 29, 2001 at 10:46:48PM -1000, David & Lisa Jacobs wrote:
> Here is the string patch with the interpreter left in. Take your pick :-)
I'll apply this, on the basis of only changing as little as possible
at a time. :) Thanks.
--
Simon: `hello kitty' douche. If you are getting some a
Here is the string patch with the interpreter left in. Take your pick :-)
David
Index: Makefile.in
===
RCS file: /cvs/public/parrot/Makefile.in,v
retrieving revision 1.85
diff -c -r1.85 Makefile.in
*** Makefile.in 27 Dec 2001 23:57
"David & Lisa Jacobs" <[EMAIL PROTECTED]> writes:
> From what I could tell, it looks like Dan put it in there as a
> potential GC hook when allocating the header of a string or PMC (see
> resources.c). My guess is that he is planning to fire off the GC
> from the interpreter.
>
> If that is the c
Saturday, December 29, 2001 7:53 PM
Subject: Re: Large string patch
> On Sat, Dec 29, 2001 at 06:25:33PM -1000, David & Lisa Jacobs wrote:
> > First, I want to apologize for the size of this patch. I normally try
to
> > make bite size changes but this one just touched too man
On Sat, Dec 29, 2001 at 06:25:33PM -1000, David & Lisa Jacobs wrote:
> First, I want to apologize for the size of this patch. I normally try to
> make bite size changes but this one just touched too many things. I still
> have a few enhancements to make but wanted to get this in before anyone el
First, I want to apologize for the size of this patch. I normally try to
make bite size changes but this one just touched too many things. I still
have a few enhancements to make but wanted to get this in before anyone else
started hacking on the same pieces.
This patch had a number of goals.
20 matches
Mail list logo
