Poor guy, I just told him the same thing off-list. Well I come to think of
it,
I guess that makes me an old fogey too.
-Melvin
Dan Sugalski <[EMAIL PROTECTED]>
09/15/2003 11:39 AM
To: Brent Dax <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], <[EMAIL PROTECTED]>,
<[EMAI
ad version that is
non-commercial usable? I'll check.
-Melvin
Dan Sugalski <[EMAIL PROTECTED]>
09/11/2003 03:08 PM
To: Melvin Smith/ATLANTA/Contr/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:Re: Need Win32 Tinder suggestions
On Thu
Eep, I was too busy poking fun at Dan about the book I forgot to say:
1) I do not represent IBM nor IBM's preferences for development
environment, I was just guessing.
You are welcome to add IBM Visual Age stuff in there, let me know if
you need a license. :)
2) The P6E book was well done,
Based on current customers I would guess the following in priority:
VC/C++ (latest non-.NET version, most people I know are still building
their stuff with Pre-.NET versions)
Visual Studio .NET
Cygwin
Borland C++ Builder
I love Borland but I have to put it last because I think the 1st 3 covers
At 12:04 PM 8/28/2003 +0200, Juergen Boemmels wrote:
Hello,
last week I send in a patch which creates io/io_private.h, but nobody
replied to it. The classical Warnock's Dilemma. I have the strange
feeling that its because nobody read my mail, because sometimes the
p6i mailinglist does not like mai
Hi,
Computed goto is a feature supported by GCC (not sure which others) that
allows using dynamic
addresses as jump targets from C. This allows the opcode tables to be
loaded and jumps to
the op can be much faster than a subroutine call. On the other hand, good
compilers can sometimes
optimize
Piers,
Regarding your Perl6 Essentials summary:
>Or, he can write code for IMCC using Parrot Intermediate Language (known
as PIR for reasons that aren't entirely clear even to one who has been
watching the mailing list since the Parrot project started)
I suppose noone has much read the README
At 11:37 PM 8/4/2003 -0400, Brent Dax wrote:
Jonathan Worthington:
> work something out. :-) However, Brent said "If you mean precompiled
> binaries, not yet. Parrot is still under development, so we aren't
shipping
> binaries.", so I'm guessing maybe I shouldn't do a ZIP with the
executables
>
At 11:02 PM 7/31/2003 +0200, Jerome Quelin wrote:
Anyway, whatever the reason, I'm playing with imcc and have some
questions about it:
I think its officially time to put together a nice set of documentation
for IMCC (like web based). I'll try to start, right after I catch up with the
year of progre
At 01:51 PM 7/31/2003 -0600, Luke Palmer wrote:
You mind submitting a patch to put this in the languages/pirate
directory of the parrot distro? I'd like to stay up to date, and
probably do some work (as, I imagine, would others).
I'd like to officially complain that "pirate" is a cooler name than
At 02:54 PM 7/31/2003 -0400, Michal Wallace wrote:
Actually, between imcc and the python compiler
module, it's not nearly as hard as I thought it
would be. So far, I think the parrot version is
actually a lot simpler than the python compiler,
just because imcc is doing so much of the work.
Leo and
Disclaimer: This reply comes from a badly configured client at work. Hence
the ugly format.
Sounds correct. There is already a seperate layer as you said, the "buf"
layer which should
keep track of correct semantics for seeking, etc. Also, IO should work the
same whether the
buffered layer is i
At 11:50 PM 7/8/2003 +0200, Leopold Toetsch wrote:
Gregor N. Purdy wrote:
All --
I just checked in a small patch that allows Jako to start
grokking PMCs. For example:
During feature freeze -
I think languages/ (besides imcc) should probably be
exempt of freezes unless Parrot depends on said l
At 05:44 PM 7/8/2003 -0400, Gregor N. Purdy wrote:
I just checked in a small patch that allows Jako to start
grokking PMCs. For example:
use sys;
var pmc foo;
foo = new PerlUndef;
foo = "Hello, world!\n";
sys::print(foo);
Neato, by the way.
-Melvin
At 10:46 AM 6/28/2003 -0400, Clinton Pierce wrote:
> If you want true variables around compilations units, please use globals
> or lexicals if they are in the same lexical pad.
>
> [1] This "feature" is IMHO at the boarders of imcc as the namespace
> instructions is. Should the HL handle these or
At 02:34 AM 6/19/2003 +0200, Leopold Toetsch wrote:
Jonathan Sillito wrote:
(3) One other efficiency thought: I wonder if the interpreter's context
could be changed to a pointer to struct Parrot_Context? This would make
accessing the stacks slightly slower but would of course make restoring the
con
At 06:05 PM 6/12/2003 -0400, Dan Sugalski wrote:
Second, I see that the registers themselves are in the context structure.
I think this may be a good part of our speed problem with taking
continuations. Now, continuations should *not* restore the registers, so
this strikes me as an incorrect thi
At 05:04 PM 2/17/2003 -0800, Tupshin Harper wrote:
So I'm gonna take a look at the native calling functionality of parrot to
see about access to an XML parser.
Taking a look at the pxs example (is this the right place to be looking?),
and I'm having problems compiling PQt.C per it's own instruc
At 02:14 AM 2/18/2003 -0800, Tupshin Harper wrote:
A number of the language examples in parrot seem to not work as well as
they once might have(or should).
cola:
doesn't compile
bison -v -y -d -o parser.c cola.y
cola.y:75.7-11: type redeclaration for class_decl
cola.y:84.7-11: type redeclaration
At 10:12 PM 2/6/2003 +0100, Leopold Toetsch wrote:
Improvements welcome - and I'm a really bad C programmer, I won't do it.
*cough*
If you are a "bad" C programmer, what is your "good" language? :)
-Melvin
At 10:39 AM 1/18/2003 -0500, [EMAIL PROTECTED] wrote:
The Jako compiler uses imcc as well...
While we are plugging...
and Cola too :)
-Melvin
At 02:12 PM 9/10/2002 +0200, Leopold Toetsch wrote:
>"perl6 --test -r" runs (i.e. executes inside imcc) _all_ perl6 tests
>(including t/compiler/8_5.p6) now correctly, _if_ GC is turned off.
Does this include the patch you sent me? I was unable to apply it
so it sort of sat in my queue.
-Melvin
At 12:41 PM 9/4/2002 -0400, Andrew Kuchling wrote:
>[Please CC: me on any responses.]
>First reason I don't work on it very much:
>
>1. Frankly, it's not much fun. I can spend my free time writing
>Python code, an environment I like, or I can work in the unfamiliar
>and uncomfortable Parrot build
At 02:06 PM 8/29/2002 -0700, Steve Fink wrote:
>On Thu, Aug 29, 2002 at 04:48:20PM -0400, Andy Dougherty wrote:
> > On Thu, 29 Aug 2002, Steve Fink wrote:
> >
> > > - Adds %option nounput to imcc.l. This avoids a warning when
> > >compiling the output file. This one is correct, at least.
> >
At 12:15 PM 8/28/2002 -0700, Steve Fink wrote:
>Anyone else notice that imcc eats something called PIR, for _P_arrot
>_I_ntermediate um... _R_anguage? I think Melvin was avoiding PIL
_R_epresentation
I'm influenced mostly by my favorite compiler book by Steven Muchnick. He
has 3 intermediate lan
At 10:45 PM 8/25/2002 -0400, Bryan C. Warnock wrote:
>Minor language and POD reworkings. Does anyone have the original
>description of PMCs? The entry is truncated.
Applied.
Jeff wins the "Who took all the inodes?" prize for 2002.
-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
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 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?"
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 becau
At 09:49 PM 8/20/2002 -0700, Sean O'Rourke wrote:
>This is what you'll need. It uses dlopen(), and is likely Bad in a number
>of other ways, but if you're on a fairly normal UNIX, it should allow imcc
>to grok what P6C produces for regexes.
Sean, I'm replying publicly because I'd like to hear ot
At 03:45 PM 8/16/2002 -0400, Jerrad Pierce wrote:
>I was wondering if perl would be handling negative array indices in the
>same manner as perl 5?
>That is to FETCHSIZE + index = real index, before attempting to fetch
>the element.
>It would be swell if the index was passed along as negative, and
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
> &g
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 cal
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 Parr
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 w
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 concer
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 w
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
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 effic
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: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.
>
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.
># http://rt.perl.org/rt2/Ticket/Display.html?id=15883 >
>
>
>SGI cc gets upset by enum bit arit
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.
># http://rt.perl.org/rt2/Ticket/Display.html?id=15882 >
>
>
>I thought "exit code 0.01171875" w
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.
># http://rt.perl.org/rt2/Ticket/Display.html?id=15880 >
>
>
>I think the generic platform.c sho
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.
># http://rt.perl.org/rt2/Ticket/Display.html?id=15879 >
>
>
>Using ld for ld does not work.
Ap
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.
>
At 07:21 PM 7/30/2002 +, via RT wrote:
># New Ticket Created by Angel Faus
># Please include the string: [perl #15850]
># in the subject line of all future correspondence about this issue.
># http://rt.perl.org/rt2/Ticket/Display.html?id=15850 >
>
>This patch makes imcc again take in account
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.
># http://rt.perl.org/rt2/Ticket/Display.html?id=15846 >
>
>
>This patch supersedes my previous l
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
>&
Thanks sir, applied.
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
e
^ Pad goes away, with "b" and "a", so the outer values
should be back in effect.
>
> find_lex P3, "a"
> print P3 # prints 12
> print "\n"
> end
I'll apply this, since it is clean, but the semantics need adjustment.
Thanks,
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
At 10:23 AM 7/30/2002 +0200, Leopold Toetsch wrote:
>Dan Sugalski wrote:
>>Just out of curiosity, I presume the (rather abysmal) perl 6 numbers
>We have already the same Mops as perl5, but additionaly 2.3 seconds
>overhead. Just running the byte code is as fast as perl5.
>
>Without jit, mops.p6 p
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
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.
># http://rt.perl.org/rt2/Ticket/Display.html?id=15676 >
Thanks Nicholas. Applied.
-Melvin
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
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
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
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 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
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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
>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
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
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
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
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 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 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 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 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 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 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
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
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()
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
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 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 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 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
201 - 300 of 597 matches
Mail list logo
