[PATCH] rx.t passes all tests on Solaris builds

This patch fixes a warning and also changes an 'int' to an 'INTVAL'. All tests should pass on Solaris. Index: rx.ops === RCS file: /home/perlcvs/parrot/rx.ops,v retrieving revision 1.4 diff -a -u -r1.4 rx.ops --- rx.ops 11 Jan

tinderbox in flames...

With current cvs, I get the following running Configure.pl-- Building ./testparrotsizes.cfrom testparrotsizes_c.in... In file included from include/parrot/parrot.h:75, from testparrotsizes.c:9: include/parrot/string.h:40: parse error before `;' include/parrot/string

Another regex question

Just out of curiosity, is the regex compiler going to be written in Parrot or C? - D <[EMAIL PROTECTED]>

[PATCH] Fix warning, fix wrong int type on Solaris

Try #2, my first was lost in the mail or something. Index: rx.ops === RCS file: /home/perlcvs/parrot/rx.ops,v retrieving revision 1.4 diff -a -u -r1.4 rx.ops --- rx.ops 11 Jan 2002 05:34:00 - 1.4 +++ rx.ops 11 Jan

Re: [PATCH] jumps with pbc2c.pl

On Fri, Jan 11, 2002 at 12:54:08PM -0500, Dan Sugalski wrote: > At 06:01 PM 1/10/2002 -0500, Jason Gloudon wrote: > >Here is a patch that makes pbc2c generated code work with the bsr opcode. It > >creates a new opcode 'enternative', and uses this to support a mixed model of > >interpretation and

Re: Proposal: Naming conventions

On Fri, Jan 11, 2002 at 11:45:03AM -0800, Jonathan Leffler wrote: > On Thu, 10 Jan 2002, Steve Fink wrote: > > >[...] I'd like to propose a convention [...] By example: > > > >struct somename_t { ... }; > >typedef struct somename_t { ... }* Somename; > > > >The non-typedef'd name of a struct ty

Re: Proposal: Naming conventions

On Thu, 10 Jan 2002, Steve Fink wrote: >[...] I'd like to propose a convention [...] By example: > >struct somename_t { ... }; >typedef struct somename_t { ... }* Somename; > >The non-typedef'd name of a struct type ends in _t. Is this a good idea? The _t suffix is reserved by POSIX for use b

New memory allocator starting

I've got the first bits of our private memory allocator in. It's a bit wasteful (allocation regions are multiples of 16 bytes) but it passes all the tests. cvsup and abuse heavily, please. As a side-effect, it close to doubles the speed of life.pbc when running in the interpreter. (But it's ra

Re: [PATCH] Make save work for sizeof(opcode_t) != sizeof(INTVAL) (caveat) [APPLIED]

At 06:49 PM 1/10/2002 -0600, David M. Lloyd wrote: > > The problem is that when you save an int constant on the stack in a > > mixed 32/64-bit system, the int type is 8 bytes but the pointer points > > to four bytes of int constant and four bytes of... something else. So > > it has to be copied o

Re: [PATCH] jumps with pbc2c.pl

At 06:01 PM 1/10/2002 -0500, Jason Gloudon wrote: >Here is a patch that makes pbc2c generated code work with the bsr opcode. It >creates a new opcode 'enternative', and uses this to support a mixed model of >interpretation and execution of compiled C code. Applied, thanks. Seems to give life abo

Re: New benchmark

At 08:44 AM 1/11/2002 +0100, Sebastian Bergmann wrote: >Dan Sugalski wrote: > > Okay, I've abused examples/assembly/life.pasm to be a benchmark > > program. It now will time generations/sec, and does rather more than > > mops.pasm does. > > Where can I find implementations of this algorithm in o