On Sep-24, Leopold Toetsch wrote:
> No. But you are right. That's the code (/s\$I2/\$I1/) that ".args"
> should produce. Perhaps we shoud name the directive ".flatten_arg".
Yes, that makes its purpose more clear than calling it ".args".
>
> Is it supposed to do deep flattening? Do we need ".deep
> Okay, we're starting to get some library code. I've a full (hopefully)
> ncurses interface .pasm file, and Leo's got Parrot::DWIM. Shall we add a
> lib/ subdirectory for assembly and/or imcc library code? (We really ought
> to discuss versioned, user-based namespacing, but maybe another day)
> Which version of ICU is in parrot/icu. Maybe 2.6 would be the most
> likely to build.
> As an update would probably best be done by delete and replace, perhaps
> it could coincide with the great renaming?
Actually, it would be best to do the update by applying 2.6 over
whatever is there and
On Wed, Sep 24, 2003 at 12:30:04PM +, Michael Scott wrote:
> # New Ticket Created by Michael Scott
> # Please include the string: [perl #24029]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=24029 >
>
>
> call_list.
I've added a B and b type to the NCI interface, which as a parameter just
returns the address or the value of the data pointer to the buffer in an S
register. These are needed for the full ncurses interface, amongst other
things (I expect). I can, and have, written the C code to make this happen
Dan Sugalski writes:
> In the variable list case things are messier, definitely. This requires a
> small chunk of code to decide which register things need to go in
> dynamically, with overflow on the overflow array. For this, I think we're
> going to need a "setp Ix, Py" op which does indirect
In an attempt to get a handle on IMCC syntax, I thumped up the traditional
life program a bit. To make it more interesting, I also converted it over
to use curses (well, OK, ncurses) to do the displaying.
The life program, which isn't that interesting as these things go, is in
examples/assembly
Okay, we're starting to get some library code. I've a full (hopefully)
ncurses interface .pasm file, and Leo's got Parrot::DWIM. Shall we add a
lib/ subdirectory for assembly and/or imcc library code? (We really ought
to discuss versioned, user-based namespacing, but maybe another day)
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Hrm. That does mean that we may want two entry points for a segment, the
> init point and the run point. For perl, the two are the same, but for a
> language like C they'd be different. I still dislike magic names, so I'd
> prefer slots in the header. (Or,
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Wed, 24 Sep 2003, Leopold Toetsch wrote:
>> .pcc_sub symbols automatically get entered into the global stash. The
>> lexer should probably allow '::' as a valid symbol char though.
> We need to get some of this moved down into the base assembler as wel
I managed to build ICU4C 2.6 on Mac OS X 10.2 by working around the gcc
-E -MMD bug. See
http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/
ParrotDistributionUnicodeSupport for details.
Which version of ICU is in parrot/icu. Maybe 2.6 would be the most
likely to build.
As an update woul
On Wed, 24 Sep 2003, Leopold Toetsch wrote:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch writes:
> >> I don't. I don't know, what the autorun should initialize. Do you have
> >> examples, what is/will be accomplished in the init "sub".
>
> > Considering that subs have to be manual
On Wed, 24 Sep 2003, Luke Palmer wrote:
> Okay, considering that it's hard to pack registers into an array, and
> that it's easy to unpack an array into registers (in the context of
> signatures), why don't we make the unprototyped calling conventions just
> to pass everything in the overflow arra
On Wed, 24 Sep 2003, Michael Scott wrote:
> I'm sitting here watching CVS download ICU and I'm wondering whether it
> wouldn't be better if it was removed from the repository?
It'd be better if we got it building, really.
Dan
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
>> Okay, considering that it's hard to pack registers into an array, and
>> that it's easy to unpack an array into registers (in the context of
>> signatures), why don't we make the unprototyped calling convention
# New Ticket Created by Michael Scott
# Please include the string: [perl #24030]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24030 >
t/src/hash.t
test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too big:
999
# New Ticket Created by Michael Scott
# Please include the string: [perl #24029]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24029 >
call_list.txt has two "i 4i" lines.
-- attachment 1 ---
On Tue, 23 Sep 2003, Amir Karger wrote:
> Apologies if I'm repeating myself, but I think I accidentally posted my
> "parrotZ status" a few days ago using Google groups instead of email.
> Did noone receive my mail, or was it just too long to read?
It's a one-way gateway. Posting via the perl.org
On Wed, 24 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> [ autorun of loaded byte code ]
>
> >>But how to pass arguments then? Init code might need some.
>
> > What arguments, though? This is just a chance to give the segment an
> > initialization run, nothing m
I'm sitting here watching CVS download ICU and I'm wondering whether it
wouldn't be better if it was removed from the repository?
It could be replaced by parrot/icu/README to give some sense of
continuity.
Maybe this could be done during the great renaming?
The appropriate version could then b
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>> I don't. I don't know, what the autorun should initialize. Do you have
>> examples, what is/will be accomplished in the init "sub".
> Considering that subs have to be manually inserted into the symbol
> table,
.pcc_sub symbols au
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 24, 2003 at 12:23:59PM +0200, Leopold Toetsch wrote:
>> > runtime/parrot/lib ?
> Do we have an Acme directory yet?
Not even lib. It could go into runtime/parrot/include though, this is at
least searched for :)
>>Dami^WLeopold Toetsc
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Okay, considering that it's hard to pack registers into an array, and
> that it's easy to unpack an array into registers (in the context of
> signatures), why don't we make the unprototyped calling conventions just
> to pass everything in the overflow array
On Wed, Sep 24, 2003 at 12:23:59PM +0200, Leopold Toetsch wrote:
> Leopold Toetsch wrote:
> > I should clean up and comment it a bit, then I could submit it - where?
> > runtime/parrot/lib ?
Do we have an Acme directory yet?
>Dami^WLeopold Toetsch (as if you couldn't guess)
"Yet anothe
On Tue, Sep 23, 2003 at 07:51:25PM -0700, Amir Karger wrote:
> Apologies if I'm repeating myself, but I think I accidentally posted my
> "parrotZ status" a few days ago using Google groups instead of email.
> Did noone receive my mail, or was it just too long to read?
My understanding is that the
Amir Karger <[EMAIL PROTECTED]> wrote:
> One of the things I mentioned there is that I would love to have some
> very simple examples of PIR files.
Please download YAL. It translates a currently very C-like language to
PIR and has a lot (but not enough) tests, that show the various HLL
constructs
Leopold Toetsch wrote:
As we don't have any libs yet, I thought, I start with an important one.
It works like Acme::DWIM.
Here is the pod for it, extracted from the source via:
$ perldoc DWIM.imc > DWIM.pod.txt
I should clean up and comment it a bit, then I could submit it - where?
runtime/parro
Marcus Thiesen <[EMAIL PROTECTED]> wrote:
> Hi,
> I'd like to add one more to the library of trivia languages. It is not
> as strange as Bf or Ook! and it is actually a real (teaching) language.
> Enter: URM
Nice.
Some remarks:
- could you parrotify the Makefile and urmc. (i.e. no hardcoded "pa
Marcus Thiesen <[EMAIL PROTECTED]> wrote:
> Enter: URM
[ some more remarks ]
src> my $roffset = 15; ### imcc does that, don't know why
Its for PCC (Parrot Calling Conventions). The register allocator starts
to allocate registers from 16..31 first, so that only the top halve of
one register bank
Leopold Toetsch writes:
> Steve Fink <[EMAIL PROTECTED]> wrote:
> >> That is you pass (3, _AV_x[0], ... _AV_x[i], _AV_y[0], ...).
>
> > Ok, we don't seem to be communicating.
>
> Ok. Restart. Brain reset. I had a thinko somewhere.
>
> > I proposed .args simply because it seemed easier to impleme
Leopold Toetsch writes:
> I don't. I don't know, what the autorun should initialize. Do you have
> examples, what is/will be accomplished in the init "sub".
Considering that subs have to be manually inserted into the symbol
table, perhaps the init code would add all the subs in a package to its
na
Steve Fink <[EMAIL PROTECTED]> wrote:
>> That is you pass (3, _AV_x[0], ... _AV_x[i], _AV_y[0], ...).
> Ok, we don't seem to be communicating.
Ok. Restart. Brain reset. I had a thinko somewhere.
> I proposed .args simply because it seemed easier to implement than
> runtime .arg directives. Would
Apologies if I'm repeating myself, but I think I accidentally posted my
"parrotZ status" a few days ago using Google groups instead of email.
Did noone receive my mail, or was it just too long to read?
One of the things I mentioned there is that I would love to have some
very simple examples of PI
Ah, I reread one of your earlier posts. It appears that you are
proposing to pass the arguments in a PerlArray. So flattening is
possible.
Then what I am saying is that
sub f($a,$b) { ... }
is going to expect $a to be in P5 and $b to by in P6. In your scheme,
$a would be in P5[0] and $b would
34 matches
Mail list logo
