At 02:42 PM 5/28/2002 -0700, George Rhoten wrote:
>Hello all,
>
>Hopefully I won't get too burned by flames by jumping into the middle of
>the conversation like this.
Fortunately this list is very low on flammable material. :)
Thanks for the helpful info. One of the concerns with using
an extern
I just uploaded the Parrot intermediate compiler to CPAN as
well as committing it to the Parrot CVS repository.
You can find it under parrot/languages/imcc if you update
your parrot tree, or get it from CPAN shortly under
http://cpan.org/authors/id/M/ME/MELVIN/imcc/
Please read the README. Hav
The common way is to define our own INLINE definition and have Configure
check for it, define it null if needed, and conditionally include it into a
file
as extern if so.
Sounds like a job for. BrentDax++!
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
> On Fri, May 31, 2002 at 06:18:55AM +0900, Dan Kogai wrote:
>actually adopted. Useful it may be I found raw ICM too Big and too
>Blue :)
Whats that mean, too Blue? :)
-Melvin
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 argumen
>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:25 PM 6/1/2002 -0400, Clinton A. Pierce wrote:
>Looks great. Converted over with little sweat, noted below.
Moving in the right direction. mandelbrot.cola -> mandel.pasm
Old assembler:
time assemble.pl mandel.pasm > mandel.pbc | grep real
real0m0.390s
New assembler:
time ./assembl
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 interpre
At 06:07 PM 6/1/2002 -0400, Kevin Falcone wrote:
> >>>>> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
>
>MS> FYI, Cola breaks with the new assembler. I think this is for 2
>MS> reasons, multiple labels and not allowing _ in label names. Ke
C++ automatically generates a typedef name when it sees struct Foo { .. }
We have a few places that name the typedef with the same name
as the tag (which I don't like as style anyway), and its causing problems
when trying to compile a C++ extension lib with parrot headers.
One example: interprete
At 11:13 PM 6/1/2002 -0400, Jeff wrote:
>shortly. I just didn't think that hand-written compilers would generate
>this code, but I suppose it's possible.
They shouldn't, only lazily written compilers do. :)
>Feel free to do that but I'll fix the actual bug soon.
I'll wait.
>Before we go down t
In order to make the extension library work with C++ I had
to rename Parrot_Interp typedef to Parrot_Interp_t
I know _t was a subject of discussion, but its a quick fix so
I can move ahead. Its only really used from embed.h in
test_main.c and the extension API layer.
If there are no complaints I
Native Extensions for Parrot:
Rather than talk about it at length and not get any code done, I decided,
concerning the native extension interface, to just take a simple
hello world approach with some outside library.
Qt is a great GUI lib, so I figured what the heck.
What resulted was a small A
At 10:23 PM 6/1/2002 -0700, Brent Dax wrote:
>Melvin Smith:
># Native Extensions for Parrot:
>#
># Rather than talk about it at length and not get any code
># done, I decided, concerning the native extension interface,
># to just take a simple hello world approach with some out
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 a
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
rvous though... maybe 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
Cross-posted to p6l and cardinal.
Parrot Intermediate Compiler (or Intermediate Representation)
See parrot/languages/imcc
Just another round of commits, supporting more directives and
instructions. Correctly handling indexed use of strings ala:
str[0] = "A"
ch = str[0]
Will have this working
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.
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 elem
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: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 parr
At 10:42 AM 6/7/2002 -0400, Josh Wilmes wrote:
> > PIO_push_payer(, &pio_sys_layer, ... )
> >
> > This means renaming all of io_unix/io_win32 to io_sys
> > since you would never have 2 OS dependant layers compiled at the
> > same time. I've just been too lazy to rework it.
>
>So something like
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 way
I just did a bunch of commits, people might need a fresh checkout.
Its a start for subroutines and co-routines. The keyword is 'start',
not final product. The ops are call/callco, but these will become
vtable entries for the 4 aforementioned sub types by Dan.
David has some pending patches for PM
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
>
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) 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 mist
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
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 us
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 doe
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 u
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 us
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 gener
At 10:21 PM 6/9/2002 +1000, Damian Conway wrote:
>Richard Nuttall wrote:
> > Grammar::Python, Grammar::Ruby, Grammar::PHP ?
>
>I should imagine that the first two at least would be very likely, given that
>we wish both of those languages to run on top of Parrot.
Given that by the time Parrot is b
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 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 the
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 ever
At 04:55 AM 6/12/2002 -0400, Dan Sugalski wrote:
> loadlib Sx, Sy
>
>Where Sx is the fully qualified name of the library we're loading, and Sy
>is the name of the routine that we're invoking once we load the library.
>This should be the *only* routine the library exports.
>
>The exported name
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.
> > # htt
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 02:10 PM 6/17/2002 -0600, Luke Palmer wrote:
>Java's hell if you know Perl. You're used to doing things in 200
>keystrokes, and suddenly it takes you 5000. "The easy things should be
>long, and the hard things should be longer... and slower." (i.e. I don't
>like Java)
If you don't have the b
At 06:55 PM 6/18/2002 +0200, Bart Schuller wrote:
>On Mon, Jun 17, 2002 at 03:43:48PM -0400, Melvin Smith wrote:
> > Ok, then we should start some nitty-gritty talk. I'm familiar with
> > implementing parsers for LR(1) grammars. I hope Larry, and other
> > people th
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 p
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&#
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 ma
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 stac
At 07:57 PM 6/21/2002 +0200, Jerome Vouillon wrote:
>On Fri, Jun 21, 2002 at 12:49:27PM -0400, Melvin Smith wrote:
> > >- Each co-routine should probably have its own interpreter.
> >
> > I'm not sure about this one. I think we can accomplish it without
> > the
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
> > cal
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 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 t
Heads up for internal hackers,
General stacks and control stacks are no longer circular. They are now
terminated at both ends with NULL pointers.
A "stack" now points to the top of the stack, not the base.
This simplified stack handling as well as the GC tracing, but
in one case, stack_entry()
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 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.
># http://bugs6.perl.org/rt2/Ticket/Display.html?id=769 >
>
>
>imcc currently only seems to suppor
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
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 upsho
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
At 04:24 PM 7/10/2002 +0100, [EMAIL PROTECTED] wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
> > >3. Is C<%MY> intended to reflect the PAD?
> >
> > Yes.
>
>Hey! How's this for a scary thought:
>
>$continuation.the_pad
>
>I'll get my
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
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.
># http://bugs6.perl.org/rt2/Ticket/Display.html?id=791 >
>
>
>This patch adds several ops that e
At 01:08 PM 7/11/2002 -0700, Ashley Winters wrote:
>On Thursday 11 July 2002 11:47 am, Chip Salzenberg wrote:
> > According to Dan Sugalski:
> > > At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote:
> > > >3a. If so, how can one distinguish among the e.g. many C
> > > >variables declared w
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 _a
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 (wee
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
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 in hopes
>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.
-Melv
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
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,
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 function
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 PARROT
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
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.
> > O
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.
> > Especi
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
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 pr
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
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 recogni
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 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
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
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 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 t
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 accept
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 f
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,
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 pla
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
At 11:04 AM 7/22/2002 -0600, Jonathan Sillito wrote:
>The attached patch makes the following changes:
>
>- adds invoke op to core.ops (patch does not remove call and callco)
>- adds vtable method 'invoke' to vtable.tbl
>- adds simple description (stolen from Dan's email) of the method to
>docs/pdd
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 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, bin
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 complai
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 wit
1 - 100 of 632 matches
Mail list logo
