Presuming you can do:
(who => $name, why => $reason) := (why => $because, who => "me");
(from A6)
Does that imply that you can do:
sub routine (name => $nombre, date => $fecha) {...}
Anyway, I just realized that this is finally an elegant way to do
multiple, unordered return values:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> Basically all metadata has to be collected before any code can be emitted.
> I was thinking of generating an _init routine that creates the classes,
> so we have several possibilities.
Why? A class definition should AFAIK end up in the constant table as a
I'm working on getting class syntax added to PIR.
It appears IMCC's way of emitting instructions as it collects compilation
was a mistake (mine) and isn't going to work for metadata that needs to
be initialized first.
Basically all metadata has to be collected before any code can be emitted.
I was
On 10/22/2003 4:01 AM, Tim Bunce wrote:
> On Tue, Oct 21, 2003 at 03:01:20PM -0700, Ovid wrote:
>> Tim Bunce <[EMAIL PROTECTED]> wrote:
>>>
>>> I'd strongly recommend switching to Storable first. It did have problems
>>> but it's now very robust and far, far, faster than Data::Dumper+eval.
>>> Th
On Thu, 23 Oct 2003, Dan Sugalski wrote:
> At 4:43 PM -0400 10/23/03, Dan Sugalski wrote:
> >And I could certainly do with some help at this point.
> >
> >Parrot is *almost* put back together. There's some weird linking problem
> >that's keeping parrot from working out as it should, and I've not
At 4:43 PM -0400 10/23/03, Dan Sugalski wrote:
And I could certainly do with some help at this point.
Parrot is *almost* put back together. There's some weird linking problem
that's keeping parrot from working out as it should, and I've not been
able to track it down. If anyone feels like syncing
Leopold Toetsch wrote:
Here is a list of files that I consider to be unused:
Hmmm... obsolete... unused... sounds a lot like languages/perl6 :-P
- Joe
And I could certainly do with some help at this point.
Parrot is *almost* put back together. There's some weird linking problem
that's keeping parrot from working out as it should, and I've not been
able to track it down. If anyone feels like syncing up and giving it a
shot, I'd not mind it at all
Thanks Robert for the fixup.
Nothing like throwing a grenade to get people scrambling.
-Melvin
-Original Message-
From: Robert Spier <[EMAIL PROTECTED]>
Sent: Oct 23, 2003 1:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [COMMIT] imcc moves out of languages
> > So much for preserving reposito
On Thu, 23 Oct 2003, Simon Glover wrote:
>
> On Thu, 23 Oct 2003, Dan Sugalski wrote:
>
> > *.ops and ops.num are in the ops directory, where all ops should go from
> > now on.
> >
> > *.c is in the base directory
>
> Um, it actually appears to be in the src directory; the base directory
> is em
On Thu, 23 Oct 2003, Dan Sugalski wrote:
> *.ops and ops.num are in the ops directory, where all ops should go from
> now on.
>
> *.c is in the base directory
Um, it actually appears to be in the src directory; the base directory
is empty. Was this an intentional change of plan?
Simon
Robert Spier <[EMAIL PROTECTED]> wrote:
>> > So much for preserving repository history.
>> Yep. Is the history gone, or are you able to do something for it?
> I've reattached the history to the files. All should be well.
Thanks again for keeping the machinery running,
leo
> Robert (the great god of CVS) is going to do the final set of big moves
> later on. Or possibly already has, depending on when you get this. This
> may, probably will, break things for a while. The scoop is:
I have done this, and there is blood all over the walls.
> When this is done I'll fix u
> > So much for preserving repository history.
> Yep. Is the history gone, or are you able to do something for it?
I've reattached the history to the files. All should be well.
Depending on when you last updated, you _may_ see weird warnings on
your next update -- they should be harmless.
-R
docs/parrot_assembly.pod is just an earlier version of PDD 6.
On Thursday, Oct 23, 2003, at 18:34 Europe/Berlin, Leopold Toetsch
wrote:
Simon Glover wrote:
On Thu, 23 Oct 2003, Leopold Toetsch wrote:
Here is a list of files that I consider to be unused:
Can I also suggest:
optimizer.pl
lib
Robert (the great god of CVS) is going to do the final set of big moves
later on. Or possibly already has, depending on when you get this. This
may, probably will, break things for a while. The scoop is:
*.ops and ops.num are in the ops directory, where all ops should go from
now on.
*.c is in th
Simon Glover wrote:
On Thu, 23 Oct 2003, Leopold Toetsch wrote:
Here is a list of files that I consider to be unused:
Can I also suggest:
optimizer.pl
lib/Parrot/Optimizer.pm
They haven't been touched for 20 months / 16 months respectively, I
don't know of anybody using them, and I think
On Thu, 23 Oct 2003, Leopold Toetsch wrote:
> Here is a list of files that I consider to be unused:
> * ops2cgc.pl
>unused, functionality is in ops2c.pl
> * make.pl
>unused?, seems outdated
> * classes/csub.pmc
>AFAIK unused, we have NCI, method_util is outdated
> * classes/pointer.pm
At 08:41 AM 10/23/2003 +0200, Leopold Toetsch wrote:
Robert Spier <[EMAIL PROTECTED]> wrote:
[ quoting reordered ]
> Melvin Smith wrote:
>>
>> IMCC has graduated from the parrot/languages/imcc directory to
parrot/imcc.
Arghh[1]
Ok guys, let us not make mountains out of molehills.
> So much for
Almost forgot: imcc/examples to be (eventually) examples/imcc.
Mike
On Thu, 23 Oct 2003, Michael Scott wrote:
> Shouldn't imcc/docs (eventually) be docs/imcc, and imcc/t be t/imcc?
Yeah, but lets deal with the initial aftermat first...
> On Thursday, Oct 23, 2003, at 04:29 Europe/Berlin, Melvin Smith wrote:
>
> > IMCC has graduated from the parrot/languages/imcc
Shouldn't imcc/docs (eventually) be docs/imcc, and imcc/t be t/imcc?
Mike
On Thursday, Oct 23, 2003, at 04:29 Europe/Berlin, Melvin Smith wrote:
IMCC has graduated from the parrot/languages/imcc directory to
parrot/imcc.
Please update your trees.
We may still want to move the main up to the pa
On Thu, 23 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > 1.1 parrot/classes/delegate.pmc
>
> > /* These need to be elsewhere */
> > #define PARROT_VTABLE_INIT_METHNAME "__init"
>
> Done. These defines are now autogenerated by Vtable.pm and li
On Wed, 22 Oct 2003, Melvin Smith wrote:
> I propose a Halloween release. Nothing fancy, just something fun. :)
> We should be able to reach some sort of minor milestone to
> justify it I'm sure.
Oct 31, the screaming pumkin release? :) Sounds good -- lets see where we
stand on Monday and go from
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> 1.1 parrot/classes/delegate.pmc
> /* These need to be elsewhere */
> #define PARROT_VTABLE_INIT_METHNAME "__init"
Done. These defines are now autogenerated by Vtable.pm and live in
vtable.h. Hope that's ok. A PASM include vtable_met
Here is a list of files that I consider to be unused:
* ops2cgc.pl
unused, functionality is in ops2c.pl
* make.pl
unused?, seems outdated
* classes/csub.pmc
AFAIK unused, we have NCI, method_util is outdated
* classes/pointer.pmc
used AFAIK only by rx.ops - should be a ManagedStruct
If no o
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We probably need two API entries. One, a vararg version, that just takes a
> bunch of PMC pointers (or some sort of (ick) parameter signature), and a
> second that assumes you've set the registers up properly already.
Done both now. The (ick) signature va
Simon Glover <[EMAIL PROTECTED]> wrote:
> I don't think your fix is correct, since:
Yep, you are right, sorry.
> Having done some more nosing around, I see that PerlString doesn't
> actually have its own implementation of logical_or; instead, it falls
> back on the scalar.pmc version, which
28 matches
Mail list logo
