[PATCH] Does jit.c warning reveal a bug ?

2002-02-24 Thread Jonathan Stowe
I've sent this before, unless I am missing something this looks like it would give rise to a coredump at some point, unfortunately it doesn't stop the coredumps when running 'make testj' :( --- jit.c~ Sun Feb 24 13:05:14 2002 +++ jit.c Sun Feb 24 13:07:11 2002 @@ -214,7 +214,7 @@

i386 jit print_s

2002-02-24 Thread Jonathan Stowe
Well I found out the reason for 13 out of the 15 core dumping tests for 'testj' but I'm not sure why this was done: RCS file: /home/perlcvs/parrot/jit/i386/core.jit,v retrieving revision 1.14 retrieving revision 1.15 diff -u -p -r1.14 -r1.15 --- parrot/jit/i386/core.jit2002/01/31 02:22:00

Re: Initial bignum pdd

2002-02-24 Thread Bryan C. Warnock
Comments inline. Some snippage. On Thursday 21 February 2002 22:08, Alex Gough wrote: > > It is therefore the current I which determines which numeric > type is being considered during a particular operation, this makes it > easy to upgrade from one numeric form to another, and also allows for >

Re: Initial bignum pdd

2002-02-24 Thread Alex Gough
On Sun, 24 Feb 2002, Bryan C. Warnock wrote: > On Thursday 21 February 2002 22:08, Alex Gough wrote: > > > > It is therefore the current I which determines which numeric > > type is being considered during a particular operation, this makes it > > easy to upgrade from one numeric form to another,

[PATCH] typo in jit/i386/string.jit

2002-02-24 Thread Jonathan Stowe
I assume this is a typo anyway :) --- jit/i386/string.jit~Sun Feb 24 15:45:19 2002 +++ jit/i386/string.jit Sun Feb 24 15:46:20 2002 @@ -33,7 +33,7 @@ mov (%eax),%eax } -get_enconding { +get_encoding { movl &ARG[0],%eax addl $0x14,%eax mov (%eax),%eax /J\ -- Jonath

Re: [PATCH] Bowing to necessity (was Re: [PATCH]Macro bulletproofing )

2002-02-24 Thread Brian Lee Ray
- Original Message - From: "Josh Wilmes" <[EMAIL PROTECTED]> To: "Brian Lee Ray" <[EMAIL PROTECTED]> Cc: "Nicholas Clark" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, February 23, 2002 12:08 PM Subject: Re: [PATCH] Bowing to necessity (was Re: [PATCH]Macro bulletproofing )

Re: #defined types

2002-02-24 Thread Martien Verbruggen
On Sat, 23 Feb 2002 20:10:53 -0800, Brent Dax <[EMAIL PROTECTED]> wrote: > Dan Sugalski: > # At 10:43 PM -0500 2/23/02, Josh Wilmes wrote: > # >So indent needs to be told about non-standard type > # (typedefs) to work best. > # >The problem is that some of the parrot code does this: > # >

Re: The Big switch() in the (Blue) Sky [was: Re: Parrot is evil]

2002-02-24 Thread Gregor N. Purdy
Nicholas -- On Fri, 2002-02-22 at 19:23, Nicholas Clark wrote: > On Fri, Feb 22, 2002 at 09:00:29AM -0500, Gregor N. Purdy wrote: > > > I'm not surprised that find_op() is causing some distress. The "best > > way" is subject to interpretation, of course. TMTOWTDI all over again. > > I chose this

[PATCH] PDD 0 - The PDD PDD

2002-02-24 Thread Bryan C. Warnock
The pod version of PDD 0 in CVS seems to have several chunks missing out of it, too. This patch is simply an administrative patch, with the differences between my last version, and the one currently in there. There will be a forthcoming patch for some minor tweaking to the PDD, but I wanted a

P(erl|arrot) Design Docs

2002-02-24 Thread Bryan C. Warnock
And other things P(erl|arrot) internals related. When and where do we draw a line between the two? Should the PDDs be Parrot Design Docs? How about versioning and the ilk? What other circular dependencies and interrelationships do the two have (besides the people involved)? Discuss. -- B

Regular expression compiler

2002-02-24 Thread Steve Fink
I've written a more or less working regular expression compiler and optimizer. Where should I put it? It's not really part of Parrot, at least no more than perl's eval"" would be. Would languages/regex be ok for now?

RE: Regular expression compiler

2002-02-24 Thread Brent Dax
Steve Fink: # I've written a more or less working regular expression compiler and # optimizer. Excellent work! #Where should I put it? It's not really part of Parrot, at # least no more than perl's eval"" would be. Would languages/regex be ok # for now? We have an opcode, rx_compile