On Fri, Oct 12, 2001 at 12:01:00AM -0400, Bryan C. Warnock wrote:
The attached patch addresses the non-printf related casting problems between
opcodes (which are currently doubling as PBC chunks in addition to just
being an opcode number) and INTVALs. Handles sizeof(opcode_t) =
On Sat, Oct 13, 2001 at 01:24:59AM -0400, James Mastros wrote:
I know it's a little (OK, a lot) early for this, but has anybody
considered writing support for parrot bytecode and the parrot object
format into GNU binutils?
A nice idea, but I don't think it's going to happen; we'll really
opcheck.pl: Found 39 errors.
Is opcheck.pl wrong, or is the optable wrong? Would like a volunteer
to fix up which it is.
--
The UNIX system is harder to use than a toaster. -Kaare Christian
In message [EMAIL PROTECTED]
Simon Cozens [EMAIL PROTECTED] wrote:
opcheck.pl: Found 39 errors.
Is opcheck.pl wrong, or is the optable wrong? Would like a volunteer
to fix up which it is.
I''ll take a look...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
On Sat, Oct 13, 2001 at 10:40:06AM +0100, Jonathan Stowe wrote:
Did I just pick a bad moment to checkout ?
No. Unfortunately, someone's done something pretty stupid.
Brent? The testparrotsizes isn't going to work, since various
.pl stuff needs to be run before all the headers are generated.
--
On Sat, Oct 13, 2001 at 11:08:28AM +0100, Simon Cozens wrote:
No. Unfortunately, someone's done something pretty stupid.
Brent? The testparrotsizes isn't going to work, since various
.pl stuff needs to be run before all the headers are generated.
I've fixed this with a bad hack for now, and
In message [EMAIL PROTECTED]
Simon Cozens [EMAIL PROTECTED] wrote:
opcheck.pl: Found 39 errors.
Is opcheck.pl wrong, or is the optable wrong? Would like a volunteer
to fix up which it is.
Well as far as I can tell the rules it enforces are essentially
arbitrary and not documented
cvs.perl.org is in the office at ValueClick. We are getting a
diesel generator plugged in there, so power might be out for some
hours here early Saturday morning PST. (I'm not sure if they'll
shut stuff down or just let it run off the UPSes).
any questions - send mail to cvs at perl.org.
-
Simon
opcheck.pl: Found 39 errors.
Is opcheck.pl wrong, or is the optable wrong? Would like a volunteer
to fix up which it is.
opcheck.pl assumes there is a naming standard for ops, makes an assumption
about what it should be, and then tests the ops against that standard.
Moby.patch gets
On Sat, Oct 13, 2001 at 11:08:28AM +0100, Simon Cozens wrote:
On Sat, Oct 13, 2001 at 10:40:06AM +0100, Jonathan Stowe wrote:
Did I just pick a bad moment to checkout ?
No. Unfortunately, someone's done something pretty stupid.
Brent? The testparrotsizes isn't going to work, since various
On Sat, 13 Oct 2001, Jason Gloudon wrote:
On Sat, Oct 13, 2001 at 11:08:28AM +0100, Simon Cozens wrote:
On Sat, Oct 13, 2001 at 10:40:06AM +0100, Jonathan Stowe wrote:
Did I just pick a bad moment to checkout ?
No. Unfortunately, someone's done something pretty stupid.
Brent? The
Thus spake Dan Sugalski [EMAIL PROTECTED]:
I'm not 100% sure I want random number generation to be a fundamental
part of the interpreter. (Though it *is* really appealing...) This sort
of thing might be better put in the standard library rather than built
in as a core opcode.
Nifty,
All --
It looks like moby.patch is going to go in, but I *really* need help
from people on various platforms looking at the floating point
problems. I'm hoping that someone else's compiler will complain about
whatever it is I've done that flakes it out. Barring that, I'm hoping
that among a
Ryan --
Speaking of the standard library, I cannot find any discussions regarding
it. It's certainly easy enough to create new opcode .so libraries with the
opcode processing script. Has there been any thought as to how these
might be properly loaded?
I've thought about it a bit, but I
On Sat, 13 Oct 2001, Simon Cozens wrote:
A nice idea, but I don't think it's going to happen; we'll really need
PMCs and string registers for anything sensible (which is why I'm
being really quiet this weekend and trying to get PMCs implemented)
I wasn't thinking so much of gas being the
Tom --
I think I've solved it. You're going to kick yourself...
Ouch! That hurt!
The answer is that you're not include math.h in core_ops.c which
means that floor() is not prototyped which means the compiler assumes
it returns an int hence the screwed up results.
Thanks so much. That did
I get the following trying to do a cvs checkout or update:
.
.
.
cvs server: Updating include
cvs server: Updating include/parrot
cvs server: [17:11:59] waiting for cvsanon's lock in
/home/perlcvs/parrot/include/parrot
cvs server: [17:13:33] waiting for cvsanon's lock in
All --
I just committed (the now functioning; thanks to Tom Hughs for spotting
my missing #include sin) moby.patch.
It works great here, but its a big change. Feedback appreciated.
* basic_opcodes.ops and opcode_table replaced by core.ops
* process_opfunc.pl replaced by Parrot/OpsFile.pm,
Here's a small change to push* which copies the last context
automatically. I was thinking about Dan's clone opcode, when I
realized that most of the time you're going to want the values, and if
you don't, you can always issue a clear. It passes all of the make
tests, and it allows recursive
On 13 Oct 2001, Brian Wheeler wrote:
Here's a small change to push* which copies the last context
automatically. I was thinking about Dan's clone opcode, when I
realized that most of the time you're going to want the values, and if
you don't, you can always issue a clear. It passes all of
On Saturday 13 October 2001 08:50 pm, Dan Sugalski wrote:
On 13 Oct 2001, Brian Wheeler wrote:
Here's a small change to push* which copies the last context
automatically. I was thinking about Dan's clone opcode, when I
realized that most of the time you're going to want the values, and if
21 matches
Mail list logo
