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