Re: [bug] parrot doesn't compile

This is the same problem I reported. The vtable.ops is not being generated so all the pmc tests will fail (i.e., the ops don't exist). David - Original Message - From: "Boris Tschirschwitz" <[EMAIL PROTECTED]> To: "Dan Sugalski" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday,

vtable.ops not being generated

I recently did a build from scratch and noticed that vtable.ops, vtable_ops.c etc are not being generated. Is there something new I need to do in the config or is it broken. I'm on a cygwin platform. David

Re: TODOs for STRINGs

From: "Peter Gibbs" <[EMAIL PROTECTED]> > > * Add size of string termination to encodings (i.e., how many 0 bytes) > > Should string termination be required? If strings are assumed to be > terminated, it seems to me that precludes buffer re-use (copy-on-write) for > substrings. On the other hand,

[PATCH] - small string patch

This is just a small simplification. David Index: string.c === RCS file: /cvs/public/parrot/string.c,v retrieving revision 1.35 diff -c -r1.35 string.c *** string.c 1 Jan 2002 17:53:50 - 1.35 --- string.c 2 Jan 2002 05:09:45 -00

TODOs for STRINGs

Here is a short list of TODOs that I came up with for STRINGs. First, do these look good to people? And second, what is the preferred method for keeping track of these (patch to the TODO file, entries in bug tracking system, mailing list, etc. * Add set ops that are encoding aware (e.g., set S0

Re: interp failures in the new IO system

I just did a cvs up and it seems to be testing ok on my cygwin system... David - Original Message - From: "Dan Sugalski" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 01, 2002 5:09 PM Subject: interp failures in the new IO system > Dunno if this is affecting anyone

[PATCH] - more encodings cleanup

Got rid of unneeded tmp var and eliminated const from encode prototype since it does make changes to the string. David Index: encodings/singlebyte.c === RCS file: /cvs/public/parrot/encodings/singlebyte.c,v retrieving revision 1.9 d

[PATCH] - Fixes make clean to eliminate pdump.o

Index: Makefile.in === RCS file: /cvs/public/parrot/Makefile.in,v retrieving revision 1.95 diff -c -r1.95 Makefile.in *** Makefile.in 31 Dec 2001 22:37:26 - 1.95 --- Makefile.in 1 Jan 2002 19:46:26 - *** *** 350,35

Re: [patch] Signed correctness, plus other warnings fixes [1/?]

Actually, I started down this road as well, but thought it would make more sense to make the opcode_t unsigned. This would allow us to keep it a consistent size across platforms if we want. Thoughts? David - Original Message - From: "Chip Turner" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTE

[Patch] - Eliminate extraneous < 0 tests

This patch eliminates extraneous < 0 tests (because they are unsigned). David Index: encodings/singlebyte.c === RCS file: /cvs/public/parrot/encodings/singlebyte.c,v retrieving revision 1.8 diff -c -r1.8 singlebyte.c *** encodings/s

[PATCH] - migrate encodings to UINTVAL

I have a LOT of changes I want to make with respect to unsigned ints. The net result will be fewer warnings along with lower chance of errors. To keep from getting out of sync with everyone I'm going to break it into as small pieces as I can. Unfortunately, this made lead to a few extra warning

[PATCH] - Addition of UINTVAL

Index: config_h.in === RCS file: /cvs/public/parrot/config_h.in,v retrieving revision 1.13 diff -c -r1.13 config_h.in *** config_h.in 30 Dec 2001 17:26:55 - 1.13 --- config_h.in 1 Jan 2002 03:41:43 - *** *** 8,13 *

Clean up warnings in global_setup.c

Index: global_setup.c === RCS file: /cvs/public/parrot/global_setup.c,v retrieving revision 1.11 diff -c -r1.11 global_setup.c *** global_setup.c 18 Dec 2001 07:05:00 - 1.11 --- global_setup.c 1 Jan 2002 03:32:01 - ***

Re: Large string patch

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/

Re: Correction to string patch

Ooops :-). Yes I did. David - Original Message - From: "Peter Gibbs" <[EMAIL PROTECTED]> > In your last change (splitting buffer allocation from string) I assume you > also intended to shorten the initial allocation. > > Index: string.c >

Re: Large string patch

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

[PATCH] - removes unused tmp

Index: core.ops === RCS file: /cvs/public/parrot/core.ops,v retrieving revision 1.64 diff -c -r1.64 core.ops *** core.ops30 Dec 2001 20:45:32 - 1.64 --- core.ops31 Dec 2001 04:20:57 - *** *** 354,360 *

Re: Large string patch

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

Re: [Patch] - Changes iton and ntoi to set operators

gt; Mailer mangling prevents me from applying this. If you send again > as an attachment, I can do it. > > I would like to see the implementations of the new set ops be > marked 'inline', and I'd like to see them avoid using local > variables, too. > > > Regards, &

[Patch] - Changes iton and ntoi to set operators

This patch moves the conversion routines iton and ntoi into set. Index: core.ops === RCS file: /cvs/public/parrot/core.ops,v retrieving revision 1.61 diff -c -r1.61 core.ops *** core.ops 30 Dec 2001 12:04:56 - 1.61 --- core.ops 3

Re: Large string patch

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 thin

Re: Large string patch

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

Making conversion operators consistently named

I noticed that for converting numbers to integers and back there are the named operators "iton" and "ntoi", but for conversions to and from PMCs the "set" operator is used. Should we make all conversions have their own ops (e.g., pton, ptoi, ...) or should we push all conversions into the set ope

Re: Large string patch

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

Large string patch

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.

[Patch] Mismatch warnings

Assuming these mismatches weren't intentional, here is a patch that fixes the mismatches between the pointer prototypes in the _vtable definition and the function definition in the perlint, perlnum and perlstring pmc files. David RCS file: /cvs/public/parrot/classes/perlint.pmc,v retrieving revi

Why does mul have fewer combos than div?

I noticed that div has Parrot_div_i_i_i, /*170 */ Parrot_div_i_ic_i, /*171 */ Parrot_div_i_i_ic, /*172 */ Parrot_div_i_ic_ic,/*173 */ Parrot_d

[Patch] More tests for bitwise functions

This patch adds tests for all the bitwise opcodes. David *** bitwise.t 26 Sep 2001 05:55:32 - 1.2 --- bitwise.t 15 Dec 2001 21:53:18 - *** *** 1,6 #! perl -w ! use Parrot::Test tests => 4; output_is(<<'CODE', <<'OUTPUT', "shr_i_ic (>>)"); set I0, 0b001100 --

Re: [Patch] - for memory.c

Ack! never mind, I see the problem, I'll submit a new patch if an elegant solution comes to me. Thanks for your time. David - Original Message - From: "David & Lisa Jacobs" <[EMAIL PROTECTED]> To: "Sam Tregar" <[EMAIL PROTECTED]> Cc: <

Re: [Patch] - for memory.c

Thanks for the catch! How about just adding the limit check back in. for (i=1; (size>i) && (i<0xff); i<<=1); Do you like the rest of the changes I made to the algorithm? David Jacobs - Original Message - From: "Sam Tregar" <[EMAIL PROTECTED]> > > +for (i = 1; size > i; i <<=