At 05:44 PM 8/21/2002 -0400, John Porter wrote:
The outstanding question is, Is imcc a part of the parrot system?
When compiler writers target parrot, do we really want them to target imcc?
I have a feeling some of you would answer yes to that question all too
My answer is yes, not because I
At 07:00 PM 8/21/2002 -0400, 'John Porter' wrote:
No; but statements like imcc MUST provide access to ALL of parrot's
(still very dynamic) feature set and discussions of imcc syntax
naturally lead to questions of imcc's role in the parrot project.
E.g. will the perl6 compiler target imcc?
Good
At 11:15 PM 8/21/2002 +0200, Leopold Toetsch wrote:
So please, first, let's consider the status quo, not the future.
Agree.
_SV_s1 = clone $P1
I've considered changing '=' to mean clone, and add ':=' to imply set.
What do you think?
-Melvin
At 10:59 PM 8/21/2002 -0400, 'John Porter' wrote:
Sean O'Rourke wrote:
However, if we already have a working register
allocator and peephole optimizer, I see little reason to write another.
Maybe you're taking a very perl6-centric view. (I don't know.)
But as someone who's writing an
Jeff wins the Who took all the inodes? prize for 2002.
-Melvin
At 01:10 PM 8/12/2002 -0600, Jonathan Sillito wrote:
1) The Parrot_Sub struct in sub.h has its own user_stack and
control_stack. Why is this necessary?
Probably an artifact of my failed experiments. :)
Originally Dan said subs would need their own stacks. Either way,
they should be part of
At 06:56 PM 8/12/2002 +0100, Simon Cozens wrote:
Here's a more interesting question: which parts of Parrot are enshrined,
and which are prototypes, ready to be thrown away? For instance, I'd
say much of languages/* is all proof-of-concept prototype stuff; imcc
may not be. The assembler I'd call a
At 08:14 PM 8/12/2002 -0700, Sean O'Rourke wrote:
On Mon, 12 Aug 2002, Melvin Smith wrote:
4) Parrot_Coroutine's 'init' is not longer used and can go away, I guess
I could remove it in a future patch ... ok so that's not a question
I wish this wouldn't go away. I think passing
At 06:14 PM 8/1/2002 +0200, Jerome Vouillon wrote:
Melvin, I think it would really help if you could explain us how you
would compile this code. Also, you should describe precisely what
invoke and new_pad (and maybe the other scratchpad-related
opcodes) do as far as scratchpads are concerned.
At 08:50 AM 8/2/2002 -0700, Sean O'Rourke wrote:
Without performance numbers, this is hard to test, but it can potentially
turn a single a = b + c, which is just add P0, P1, P2 if a, b, and c
have been referenced, into a hideous five instructions:
fetch_lex P0, 'a' # Because how we store
At 06:14 PM 8/1/2002 +0200, Jerome Vouillon wrote:
On Wed, Jul 31, 2002 at 11:40:39AM -0600, Jonathan Sillito wrote:
So here is my take on a slightly simpler example:
sub foo {
my $x = 13;
return sub { print $x\n; };
}
$foo()
Melvin, I think it would really help if
Jerome Vouillon writes:
On Wed, Jul 31, 2002 at 11:22:56PM -0400, Melvin Smith wrote:
At 06:25 PM 7/31/2002 +0200, Jerome Vouillon wrote:
Closures
A subroutine must have access to the scratchpads of all the
englobing blocks. As the scratchpads are linked, it is sufficient
to add
At 06:41 PM 7/30/2002 -0400, John Porter wrote:
Sean O'Rourke wrote:
I read that as expressions are evaluated once, not PMC's are accessed
once. So something like
2 $i++ 23
will do the expected -- increment $i once, keeping the result in a PMC
temporary.
I don't see that.
At 03:18 PM 7/31/2002 -0700, Stephen Rawls wrote:
I'm sure this has been thought out before, but I'll
press on anyway. Assuming parrot shouldn't always
create intermediate files (.pbc), then shouldn't
parrot be able to take an input stream as an argument
instead of a filename? That way, one
At 06:25 PM 7/31/2002 +0200, Jerome Vouillon wrote:
Scratchpads
We need to allocate an area in the heap for each lexical variable.
Instead of allocating this area one variable at a time, we can
allocate a single scratchpad value for all variables of a block:
this is more efficient.
Dan wrote:
At 10:43 AM -0400 7/29/02, Melvin Smith wrote:
At 10:45 AM 7/29/2002 +0100, Nicholas Clark wrote:
The VM and assembler does not need to provide every operator as
an new 'op'. Eventually, languages with funky operators need to start
thinking
about implementing them as methods
At 06:56 PM 7/30/2002 +, via RT wrote:
# New Ticket Created by Jonathan Sillito
# Please include the string: [perl #15846]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15846
This patch supersedes my previous
At 02:48 PM 7/22/2002 +, Stéphane Payrard wrote:
On Sun, Jul 21, 2002 at 02:05:42PM +, s. payrard @ wanadoo. fr wrote:
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #15267]
# in the subject line of all future correspondence about this issue.
# URL:
At 05:21 AM 7/31/2002 +, via RT wrote:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #15879]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15879
Using ld for ld does not work.
At 05:24 AM 7/31/2002 +, via RT wrote:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #15880]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15880
I think the generic platform.c
At 05:26 AM 7/31/2002 +, via RT wrote:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #15882]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15882
I thought exit code 0.01171875 was
At 05:28 AM 7/31/2002 +, via RT wrote:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #15883]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15883
SGI cc gets upset by enum bit
At 10:45 AM 7/29/2002 +0100, Nicholas Clark wrote:
[Maybe we should have a competition to suggest the most crazy three character
operator - ie state your sequence of three characters (not necessarily ASCII,
but it helps), state their name, and state their purpose (including whether
listop, binop,
At 07:57 PM 7/29/2002 -0700, Sean O'Rourke wrote:
On Mon, 29 Jul 2002, Dan Sugalski wrote:
Just out of curiosity, I presume the (rather abysmal) perl 6 numbers
include time to generate the assembly and assemble it--have you tried
running the generated code by itself as a test? (At the
At 04:08 PM 7/27/2002 +, via RT wrote:
# New Ticket Created by Nicholas Clark
# Please include the string: [perl #15676]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15676
Thanks Nicholas. Applied.
-Melvin
Array currently is broken. I'm not sure about _how_ broken,
but I know it doesn't work as well as PerlArray.
I think Steve Fink worked out some bugs in PerlArray that may
have been left in Array.
I can't remember who wrote what (I know it wasn't me, Jeff maybe?), but if
there
aren't any
Since not all languages targetting Parrot need or want neato things
like aggregate keys, I propose that they be left to the Perl* stuff and we
make the default Array/Hash very simple, but fast primitive versions.
That means a plain Array will be able to use Ix registers directly
as subscripts
With the mass of discussion revolving around PMCs lately, I
just want to put my 2 cents in.
It is not clear to me yet that there needs to be a 1-to-1 correlation
from PMC's to upper level classes. I can't see Parrot ever
providing enough vtable methods for every language that will
ever target
At 02:19 PM 7/24/2002 +, [EMAIL PROTECTED] wrote:
cvsuser 02/07/24 07:19:27
Modified:languages/imcc imcc.l imcc.y
Log:
Set IF_r0_read for set Px, Ay.
On IMCC's aggressive behaviour :)
I finally sat down and looked at this. This fix will only make the symptom
go away for
At 12:14 PM 7/23/2002 -0600, Jonathan Sillito wrote:
Is now a good time to start a discussion on lexical scopes? Is anyone
currently working on an implementation of scratchpads? I have sketched
I started on a simple implementation. I decided to just use the
PerlHash that we already have.
I
At 12:00 PM 7/22/2002 +0100, Nicholas Clark wrote:
On Mon, Jul 22, 2002 at 11:21:09AM +0100, Graham Barr wrote:
On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote:
Sean O'Rourke [EMAIL PROTECTED] wrote:
languages/perl6/README sort of hides it, but it does say that If
you
At 05:47 PM 7/22/2002 +0100, Nicholas Clark wrote:
Opefully, this can be accepted ;)
Do pmc files get turned pretty directly into C code?
Yep.
And if pmc files get turned pretty directly into C code, do the C++ style
comments stay in there? If yes and yes, then the patch won't be acceptable
At 09:58 PM 7/22/2002 +0100, Nicholas Clark wrote:
On Sun, Jul 21, 2002 at 11:46:34AM -0700, Scott Walters wrote:
Perl 5 runs *awesome* on a 486/25. Java (Kaffe) is completely unusable.
AWT windows come up in a matter of *days*, whereas a Tk window comes up
in about 45 seconds. On a fast
At 07:45 PM 7/22/2002 -0400, Melvin Smith wrote:
At 05:47 PM 7/22/2002 +0100, Nicholas Clark wrote:
I think boolean is a language dependant thing and probably shouldn't
be implemented as a PMC. For some languages, boolean can be optimized
all the way down to the JIT level, and I'm not sure which
At 02:16 PM 7/18/2002 -0600, Jonathan Sillito wrote:
On Wed, 2002-07-17 at 22:01, Melvin Smith wrote:
Subs, co-routines and continuations are at a very limited, but functional
state.
Basically you can create a PMC with a bytecode address or label
and use the call/callco/callcc ops
At 05:00 PM 7/18/2002 -0600, Jonathan Sillito wrote:
On Thu, 2002-07-18 at 14:27, Melvin Smith wrote:
The temporary fix is to do:
Attached are three small patches, two of them change example files
(examples/assembly/coroutine.pasm and examples/assembly/sub.pasm)
to use this fix that Melvin
At 06:35 PM 7/18/2002 -0400, Tanton Gibbs wrote:
This is the .dev file for dod.c
Applied, thanks.
They are all in docs/dev now.
-Melvin
At 11:54 PM 7/18/2002 -0400, Josh Wilmes wrote:
I really dislike this.
It wasn't my choice, I just asked for a consensus on IRC
since I didn't see a final decision on p6i.
Feel free to move them wherever.
-Melvin
At 06:14 PM 7/16/2002 -0700, John Porter wrote:
Melvin Smith wrote:
I put it temporarily in the root dir, which I know is wrong.
Where should .dev files go, anyway?
Actually, I think that's right.
..dev files live alongside their .c/.h siblings, no?
Hmm, looking at the source directory
At 04:50 PM 7/17/2002 -0400, Dan Sugalski wrote:
I'm putting together my presentations for TPC (one of the reasons I've
been missing the past few days). There's going to be a good round of
acknowledgements in the State of the Parrot talk. If you've contributed
and *don't* want to be
At 09:16 PM 7/17/2002 -0400, Dan Sugalski wrote:
Melvin (and the rest of you... :)
Are subroutine PMCs at a point where we can use them? If not, that's fine,
but if so, they can go on the list 'o things. (And we can add global
variables, if they didn't make it in the 0.0.6 release notes)
At 09:42 AM 7/16/2002 -0700, Damien Neil wrote:
On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote:
True async IO implementations allow other things besides just notifying
the process when data is available. Things like predictive seeks, or
bundling up multiple read/writes, etc
At 05:08 PM 7/15/2002 -0700, Stephen Rawls wrote:
Ok, I cleaned up the file a little bit, and added pod
declarations. Should be finalized or close to it at
least. If anyone likes it, I'll start working on
making a .dev file for some other files, and start
asking questions while I'm at it
At 05:25 AM 7/16/2002 +0200, Angel Faus wrote:
Hi Melvin,
This patch does the following things:
- It includes patch #813 from Sean O'Rourke
- It fixes another bug in spill(), who was generating bad code
- It adds a bunch of work using the control-flow graph, analyzing the
exact places
At 11:18 AM 7/15/2002 -0700, Damien Neil wrote:
On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote:
1) Async support. The IO system needs to be asynchronous and re-entrant
at the core, whether by threads or by use of the platform's async support.
Other things like callbacks assume
At 11:08 AM 7/15/2002 -0700, Damien Neil wrote:
On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote:
The last four are reserved by various C and C++ standards.
I always hear this, but in real life it is never much of a problem.
Especially
with a namespace like [Parrot
At 03:54 PM 7/14/2002 +0100, Tom Hughes wrote:
I've been trying to make sense of the current status of keyed access
at all levels, from the assembler through the ops to the vtables and
it has to be said that the harder I look the more confused I seem to
become...
I think we all have...
FWIW, I
At 09:55 PM 7/14/2002 -0400, Josh Wilmes wrote:
IMHO, there's no way to find out quite like trying to use it :)
In my experiences with it thus far, it all seems to work fine. Melvin has
indicated that its API and internal structure may need some changes at
some point, but the basic
At 09:27 PM 7/14/2002 -0700, Brent Dax wrote:
Wow, Brent lives! :)
Here's the rules, roughly as they stand right now:
-Functions start with Parrot_[a-z] or just [a-z].
-Typedefed names start with Parrot_[A-Z] or just [A-Z].
-Macros and constants start with
At 11:13 AM 7/12/2002 -0400, Mike Litherland wrote:
I've been lurking for a bit until I'm up to speed enough to help out. I'm
glad to see a glossary is forming of some of the terms newbies need, but
there are some things I think are missing.
First is that COW was discussed a few days (weeks?)
At 01:37 AM 7/12/2002 -0700, John Porter wrote:
I have to say that I am extremely disappointed at the
paucity of internal documentation.
push melvins_list_of_disappointments, $johns_disappointment;
I know this is going to be extremely painful for some of you
hackers... consider it a chance to
flame on
I've seen several comments go across with valid concerns,
and a few that perplex me.
Guys, look at the facts. We have a very small number of
internals hackers here, and only one who actually gets
paid for it. Most of us have jobs and families, and we slip in this stuff
in little slices
Which IRC network, which channel?
I use irc.pobox.com, you can also try irc.rhizomatic.net
Channel is #parrot
Sorry for past, present, and future newbie questions. Doubly so for having
As always, newbie questions are welcome, and I think the Parrot list
is usually nicely on-topic.
At 01:16 PM 7/12/2002 -0700, John Porter wrote:
Melvin Smith wrote:
Guys, look at the facts. We have a very small number of
internals hackers here, and only one who actually gets
paid for it. . . . We are not an army.
I'm so busy building this tower single-handedly,
I don't have time
It appears that not all of the keyed versions for aggregates
are supported by the assembler and/or in the ops file.
If someone has time, I think it would be very useful to catalogue:
1) Which keyed versions are we missing (if any)
2) Which are working (by working I mean they exist in core.ops
At 02:13 PM 7/10/2002 -0700, John Porter wrote:
Dan Sugalski wrote:
John Porter wrote:
but what about non-PMC variables?
Generally speaking, there aren't any. Everything else (in this case
the buffer/string things) is for internal use only. Languages aren't
supposed to expose
At 04:34 PM 7/10/2002 -0600, Luke Palmer wrote:
On Wed, 10 Jul 2002, Melvin Smith wrote:
At 02:13 PM 7/10/2002 -0700, John Porter wrote:
Dan Sugalski wrote:
John Porter wrote:
but what about non-PMC variables?
Generally speaking, there aren't any. Everything else
At 10:38 PM 7/10/2002 -0500, via RT wrote:
# New Ticket Created by Sean O'Rourke
# Please include the string: [netlabs #791]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=791
This patch adds several ops that exist
At 05:01 PM 7/7/2002 -0400, via RT wrote:
# New Ticket Created by Sean O'Rourke
# Please include the string: [netlabs #769]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=769
imcc currently only seems to support
At 08:55 AM 7/5/2002 -0500, David M. Lloyd wrote:
On Wed, 3 Jul 2002, Melvin Smith wrote:
At 09:51 PM 7/3/2002 -0400, Josh Wilmes wrote:
I know there was some talk about this extra address parameter recently,
but i'm not sure what the upshot of it is. Right now, tcc is complaining
At 12:48 PM 7/5/2002 -0400, Dan Sugalski wrote:
At 10:39 PM -0400 7/3/02, Melvin Smith wrote:
At 09:51 PM 7/3/2002 -0400, Josh Wilmes wrote:
I know there was some talk about this extra address parameter recently,
but i'm not sure what the upshot of it is. Right now, tcc is complaining
loudly
FYI,
PMCs ParrotPointer, ParrotSub and ParrotCoroutine have been
renamed to Pointer, Sub and Coroutine.
Parrot PMCs reserve the basic names, and language specific (Perl*, Ruby*)
should prepend their PMCs with the language name.
-Melvin
At 09:51 PM 7/3/2002 -0400, Josh Wilmes wrote:
I know there was some talk about this extra address parameter recently,
but i'm not sure what the upshot of it is. Right now, tcc is complaining
loudly because the init functions for parrotsub and parrotcoroutine don't
match the init_method_t type
At 06:59 PM 6/30/2002 +0100, Tom Hughes wrote:
of the ARM procedure call standard. The solution there is to always
keep one chunk in reserve - when you move back out of a chunk you don't
free it. Instead you wait until you move back another chunk and then
free the chunk after the one that has
At 06:34 PM 6/21/2002 +0200, Jerome Vouillon wrote:
On Thu, Jun 20, 2002 at 12:26:11AM -0400, Melvin Smith wrote:
Given that it seems capturing and restoring a context is the most
expensive part, should we make default routines lightweight (execute
on caller stack rather than getting
At 10:22 PM 6/21/2002 +0200, Jerome Vouillon wrote:
On Fri, Jun 21, 2002 at 02:33:33PM -0400, Melvin Smith wrote:
Now, if you look at it and say we can do a lightweight
interpreter, I think that is what I'm trying to accomplish, but I'm
calling it Parrot_Context.
Ok. Then, you should do
At 12:47 AM 6/18/2002 -0400, David J. Goehrig wrote:
Melvin's quip regarding macros, while harmless in itself, is, I fear, a
symptom
of a real problem. One of the muses for parrot and perl 6 has always been
I have no fear of macros; I contributed quite a few to Parrot myself. :)
Perl 5's
At 11:49 AM 6/18/2002 -0700, Larry Wall wrote:
On Tue, 18 Jun 2002, Melvin Smith wrote:
: 2) In fact, there are MANY funny named macros in Perl5.
That is precisely *why* they had to have funny names. Perl 5's
macro naming schemes were a vast improvement over Perl 4's. In
Perl 4
At 09:29 PM 6/18/2002 +0200, Jerome Vouillon wrote:
On Mon, Jun 17, 2002 at 04:59:05PM -0400, Melvin Smith wrote:
I have started writing a Perl 6 grammar:
http://www.pps.jussieu.fr/~vouillon/parrot/parser.y
It is far from complete, and certainly not very accurate, but it may
be a good start
I'll put this into RT tracker.
I noticed this while integrating some code from Angel Faus for
the IMCC compiler. The assembler currently does not check
if your register is in the correct range. So it allows:
set I11, -1
At least I don't think we've implemented unlimited register file size.
I've just committed the 3rd revision of the Parrot intermediate compiler.
Angel Faus has added register spilling to work with the graph-coloring
allocator. Currently we spill regs to an array in P31. Given that we don't
have random access stacks, this is the only fast way to do this.
Much thanks
At 09:03 PM 6/12/2002 -0400, Jason Gloudon wrote:
On Tue, Jun 11, 2002 at 12:04:19PM -, Clinton A. Pierce wrote:
# New Ticket Created by Clinton A. Pierce
# Please include the string: [netlabs #702]
# in the subject line of all future correspondence about this issue.
# URL:
At 05:07 PM 6/11/2002 +0100, Dave Mitchell wrote:
On Tue, Jun 11, 2002 at 11:31:37AM -0400, Dan Sugalski wrote:
We'll find out with A6 whether we do coroutines and continuations as
part of the core perl. If not, well, python does the first and ruby
the second, so it's all good in there.
At 12:29 PM 6/11/2002 -0400, Melvin Smith wrote:
You can think of continuations as an execution context. This context
incudes everything, not just stack. It is a snapshot in time. You may think
Let me rephrase. The context doesn't include everything, rather everything
that is local to that call
At 04:34 PM 6/9/2002 +, [EMAIL PROTECTED] wrote:
cvsuser 02/06/09 09:34:43
This needs rethinking. PIOHANDLE may not be an integer, so this
implementation is probably incorrect. For now, i'm just disabling it
unless
the UNIX io module is used, so that warnings aren't
At 03:49 PM 6/9/2002 +0200, Jerome Vouillon wrote:
Thanks for the links and references, Jerome. I'll have a go
at digesting these. As soon as the new neural pathways
have formed I'll try to comment on where I can see us
improving our implementation. :)
-Melvin
At 09:50 AM 6/8/2002 +0200, Jerome Vouillon wrote:
Alternatively, I think you can just replace the definition of yield
by:
inline op yield (in INT) {
struct Parrot_Sub * sub =
(struct Parrot_Sub*)interpreter-pmc_reg.registers[0]-data;
sub-init = OFFSET($1);
At 09:50 AM 6/8/2002 +0200, Jerome Vouillon wrote:
On Sat, Jun 08, 2002 at 01:15:48AM -0400, Dan Sugalski wrote:
First, we need to beef up ret, but that's a problem of definition. It
Why does ret need to be so smart? We can have an opcode that pop
exception handlers (we need it anyway) and a
At 08:15 PM 6/8/2002 +0200, Jerome Vouillon wrote:
I think this is a design mistake of the Java VM. It would have been
more efficient to keep the local variables on the stack.
Define efficient. I assume they made their choices for more than one
reason, and I'd hesitate to call it a design
At 08:27 PM 6/8/2002 +0200, Jerome Vouillon wrote:
On Sat, Jun 08, 2002 at 12:20:55PM -0400, Melvin Smith wrote:
What would that accomplish?
If yield is to suspend the current coroutine and return back to the
controlling context, you don't need an argument to yield, unless you
wish
At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote:
On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
The support isn't complete, for example, co-routines, etc. need to
swap in their own context, which right now they don't do.
Instead of using some space on the stack, co-routines
At 03:48 PM 6/8/2002 -0400, Dan Sugalski wrote:
At 3:35 PM -0400 6/8/02, Melvin Smith wrote:
At more risk of admitting more of my ignorance...
We have to store the closure's variables somewhere, if not on a stack, where?
In scratchpads. The way perl 5 does it is that every subroutine has
At 02:36 PM 6/8/2002 -0400, Dan Sugalski wrote:
At 8:15 PM +0200 6/8/02, Jerome Vouillon wrote:
On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote:
The Java VM does this by popping values off of the local stack, and
onto the callee's stack upon return.
I think this is a design
At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote:
On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
The support isn't complete, for example, co-routines, etc. need to
swap in their own context, which right now they don't do.
Instead of using some space on the stack, co-routines
At 01:50 AM 6/7/2002 -0400, Dan Sugalski wrote:
So, we're adding an invoke vtable method, and we'll have four sub PMC
types: ParrotSub, ParrotClosure, ParrotCoroutine, and
ParrotContinuation. We ought to be able to create them with limited
trouble, and it's OK if they've got evil knowledge of
At 03:28 AM 6/7/2002 -0400, Josh Wilmes wrote:
It appears that the mechanism for choosing an os layer for PIO could use
some work, and it also appears that io_stdio is incomplete.
Yes to both.
The mechanism:
#ifndef WIN32
PIO_push_layer(interpreter, PIO_base_new_layer(pio_unix_layer),
At 03:38 PM 6/7/2002 +0100, Nicholas Clark wrote:
Is the goal to eliminate all the stdio code, so that by release parrot
can't run on stdio? (ie all OSes must have some sort of direct layer, and
porting parrot involves creating such a layer if none exists)
As far as I know, yes.
Or that parrot
Rather than naming all the basic Parrot types (I mean classes
that are exposed at the PASM level) Parrot*
(ParrotPointer, ParrotSub, ...) I propse we name them by their
simple names and require all new languages to prefix their
types ala PerlString, etc. We already have Array and Intqueue
that
At 05:16 PM 6/7/2002 -0700, Brent Dax wrote:
Subject says it all. Updates conventions to be consistent with much of
the core. Unfortunately, that doesn't include 'struct Parrot_Interp'.
I'll work on bringing the source up to date as soon as pending patches are in.
-Melvin
At 07:40 PM 6/7/2002 -0400, Melvin Smith wrote:
# Sample sub-routines in Parrot
#
# Create 2 subroutines
#
set_addr I0, SUB
new P0, .ParrotSub, I0
save P0
new P0, .ParrotSub, I0
# Calling convention says P0 will contain the sub
call
restore P0
# Call second one
call
end
# A subroutine address
Warning, if this message is too long, please skim to the bottom and read
the part marked IDEA, lest it get lost in the rant.
rant
Why make keyed access of arrays any more complicated than it
needs to be?
The Ix regs are for optimization, so it seems natural
for Ix or ICx simply return the i-th
At 04:48 PM 6/5/2002 +0200, Jerome Vouillon wrote:
My feeling is that the current implementations of stacks are not
adequate:
- the control stacks store too many registers at once;
They are register windows, so I think they work fine for that purpose.
It doesn't mean the control stack must be
At 01:29 AM 6/3/2002 -0700, Brent Dax wrote:
Leon Brocard:
# This little patchette lets the new shiny assembler cope with
# using an I register as a PMC key, eg P14[I3]. Obviously
# brainf*ck needs to be in the testsuite ;-)
See my comment on a previous, similar patch by Simon Glover.
If you
it
introduces warnings on other platforms?
I would cast the opposite way. dlopen/dlsym can take a const char *
so just declare s as const char * s instead.
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
At 10:06 PM 6/1/2002 -0700, Brent Dax wrote:
Melvin Smith:
# If there are no complaints I'm going to commit this when I
# commit the initial patch for extensions.
I think that's renaming it the wrong way. The struct should probably
become parrot_interp_t and the typedef Parrot_Interp
I'm working on an experimental extension API, which is going
well, but I'm pondering how the GC should cooperate with
native calls.
Currently I have some code like:
# t.pasm
loadlib P0, libpqt.so
print Loaded\n
callnative P1, P0, PQt_init
end
/* libpqt.c */
int PQt_init(Interp * interp) {
At 02:17 PM 6/1/2002 -0400, Melvin Smith wrote:
# t.pasm
loadlib P0, libpqt.so
print Loaded\n
callnative P1, P0, PQt_init
end
The correct code is actually:
loadlib P0, libpqt.so
print Loaded\n
# Save an argument for native method
save Testing...
# callnative calls a native method and caches
Now there are a dozen ways to handle this. Using flags, keeping args on the
stack until return, yada yada yada...
One option is we don't pass args to native on the normal stack, rather
create a scratchpad Array PMC and pass it instead, so the routine
can access it randomly. However, I'm unsure
At 12:39 AM 6/1/2002 -0400, Jeff wrote:
As noted, the new assembler is now in place. There isn't much
Yay!
FYI, Cola breaks with the new assembler. I think this is for 2 reasons,
multiple labels and not allowing _ in label names. Kevin posted
a couple of patches which fix the breakage, but I'm
At 02:50 PM 6/1/2002 -0400, Dan Sugalski wrote:
At 2:17 PM -0400 6/1/02, Melvin Smith wrote:
Now there are a dozen ways to handle this. Using flags, keeping args on the
stack until return, yada yada yada...
Since extensions are supposed to be isolated from the interpreter
internals, I'm just
201 - 300 of 511 matches
Mail list logo
