RE: [COMMIT] miniperl has been somewhat busy...

2001-12-19 Thread Dave Mitchell
Dan Sugalski [EMAIL PROTECTED] wrote: Ah, the joys of Supreme Executive Power! Look 'ere - Supreme Executive Power resides in a mandate from the masses, not some farcical aquatic ceremony... :-) We really have three separate but related needs: *) Shallow register copy. (set) This just

Re: Request for comments

2001-12-19 Thread Melvin Smith
Burp, more spam from me... As I see it there are several immediate questions to be answered for Parrot IO. Feel free to answer with Y/N or Maybe. 1) Nick Ing-Simmons' Perl IO for Perl5 c) Is there a copyright issue? Nick's intent all along has been that his work be useful and used

parrot_assembly.pod

2001-12-19 Thread Alex Gough
Much of parrot_assembly.pod seems out of date, or raises interesting questions: Are we going to bother with NAMESPACEs and SUBs in assembler? (from parrot_assembly.pod: Namespaces are noted with the NAMESPACE directive. It takes a single parameter, the name of the namespace. Multilevel

Re: How to add new ops?

2001-12-19 Thread Marcus Petersson
Oops, three replies. Is it ok if I only reply to one? :-) On Tue, 18 Dec 2001, Dan Sugalski wrote: Hmmm. For the moment throw them into core.ops in a local copy. I'll work up a protocol for adding ops files over the next day or so and document it. Yeah, that'd be good. Putting them in

Re: How to add new ops?

2001-12-19 Thread Marcus Petersson
On Tue, 18 Dec 2001, Simon Cozens wrote: I anticipated this question so well that you'll find the answer in the middle of docs/intro.pod :) Ah, now I see. Good stuff. I'll have to take a deeper look at this. Maybe some of my other questions will find their answers there. Marcus

Re: parrot_assembly.pod

2001-12-19 Thread Dan Sugalski
On Wed, 19 Dec 2001, Alex Gough wrote: Much of parrot_assembly.pod seems out of date, or raises interesting questions: Are we going to bother with NAMESPACEs and SUBs in assembler? Yup. We just haven't gotten there yet. Is it worth keeping documentation for (implemented) opcodes in this

Re: setline

2001-12-19 Thread Simon Cozens
On Wed, Dec 19, 2001 at 11:38:39PM +, Alex Gough wrote: We're clearly doing this wrong, is it really worth calling setline every time we *run* the line in question We call setline whenever the code generated by the compiler tells us to. If it's so dumb that it calls setline in the middle

attempts to clean up a few warnings

2001-12-19 Thread Josh Wilmes
I'm no sure if i've submitted some of these before, but here goes. Diffs against current cvs: Index: Configure.pl === RCS file: /home/perlcvs/parrot/Configure.pl,v retrieving revision 1.39 diff -u -r1.39 Configure.pl ---

JIT me some speed!

2001-12-19 Thread Dan Sugalski
Thanks to the work of Daniel Grunblatt, we now have JIT capabilities in parrot. It's in the latest CVS, ready for your use and abuse. To run a program with the JIT, pass test_parrot the -j flag and watch it scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on mops.pbc of

Re: setline

2001-12-19 Thread Dan Sugalski
At 12:36 AM 12/20/2001 +, Simon Cozens wrote: On Wed, Dec 19, 2001 at 11:38:39PM +, Alex Gough wrote: We're clearly doing this wrong, is it really worth calling setline every time we *run* the line in question We call setline whenever the code generated by the compiler tells us to.

POD cleanups for core.ops

2001-12-19 Thread Josh Wilmes
This makes it pass podchecker and look more aesthetically pleasing. Index: core.ops === RCS file: /home/perlcvs/parrot/core.ops,v retrieving revision 1.53 diff -u -r1.53 core.ops --- core.ops20 Dec 2001 01:53:14 - 1.53

struct Parrot_Interpreter argument

2001-12-19 Thread mrjoltcola
Since so many functions pass around the interpreter, can we add a standard, short interpreter arg macro so I don't have to clutter the argument list of every function I write. theINTERP or something? -Melvin