I have a design question here. Why did we take the approach of having a
match method on every single vtable, instead of having a vtable for
regular expressions, and have regex be an object (like Perl 5)?
>From a Perl (6) perspective, it makes more sense to me:
# This:
$a =~ /$regex/;
# wo
> cvsuser 02/01/08 14:55:59
>
> Modified:docs vtables.pod
> Log:
> Clarify what get_string should do.
>
> Revision ChangesPath
> 1.7 +4 -1 parrot/docs/vtables.pod
>
> --- vtables.pod 4 Jan 2002 00:51:00 - 1.6
> +++ vtables.pod 8 Jan 2002
Just out of curiosity, is the regex compiler going to be written in Parrot
or C?
- D
<[EMAIL PROTECTED]>
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, 11 Jan 2002, 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 type ends in _t.
>
> Is
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
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
12 matches
Mail list logo
