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
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?
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
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
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
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:
> # >
- 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 )
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
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,
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
>
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
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 @@
12 matches
Mail list logo
