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
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
Just out of curiosity, is the regex compiler going to be written in Parrot
or C?
- D
<[EMAIL PROTECTED]>
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
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
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
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
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
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
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
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
11 matches
Mail list logo