At 06:26 PM 11/5/2003 -0500, Melvin Smith wrote:
>Also, anytime you use a temporary to assing a constant literal, you
s/assing/assign
=0)
-Melvin
At 04:10 PM 11/5/2003 -0700, Luke Palmer wrote:
Actually that was pretty good for an early version. You could help IMCC
out by not creating those PerlUndefs until you're going to assign to
them.
Also, anytime you use a temporary to assing a constant literal, you
should be able to use a I/S/N reg.
Thies C. Arntzen writes:
> hi,
>
> we've started a project (will have a web-page soon) that aims to
> port the php-language (www.php.net) to run on top of parrot.
Cool!
> we've written some initial code and i'm kinda stuck while
> writing the codegen (i target imc)
At 08:54 PM 11/5/2003 +0100, Thies C. Arntzen wrote:
we've started a project (will have a web-page soon) that aims to
port the
php-language (www.php.net) to run on top of parrot. we've written
some
First of all, welcome! :)
I'll read your mail in depth and send a followup reply,
hi,
we've started a project (will have a web-page soon) that aims to port the
php-language (www.php.net) to run on top of parrot. we've written some
initial code and i'm kinda stuck while writing the codegen (i target imc)
my problem is that php is typel
Hi Doug,
Doug McNutt writes:
> >The first source of discussion was around whether there is any
> >consistent meaning to array operations. The source of this was that
> >some felt that other people may want C<*> to mean something other
> >than element-wise multiplication by default (e.g. matrix inn
I have just finished reading "Perl 6 Essentials". It was much appreciated and I
proceeded to the perl6 web site to check out some changes that make perl useful for
tasks other than practical report extraction. In particular, things mathematical. When
I saw the wide array of math functions - vers
At 04:58 PM 11/5/2003 +0100, Juergen Boemmels wrote:
> I think it works with casts, unless there are cases where our INTVAL
> cannot hold a pointer. There are currently 2 cases:
Is it always guaranteed that an pointer fits in an INTVAL?
I'm not aware of any platform where size_t cannot hold a point
At 05:06 PM 11/5/2003 +0100, Juergen Boemmels wrote:
they should not be a reason for fdopen. The main goal why I wanted to
keep fdopen is in cases were parrot is embedded and the bytecode gets
called with an external FILE * pointer. This might be for example
yyin. But is it needed that this must be
Melvin Smith <[EMAIL PROTECTED]> writes:
> >PIOHANDLE is a low level OS handle (UNIX or Win32) and we to
> >create a ParrotIO around it.
> >PIOHANDLE is a stdio FILE * and we need to create a ParrotIO around it.
>
> One more comment. I don't even see the possibility of calling fdopen
> from t
Melvin Smith <[EMAIL PROTECTED]> writes:
> Hey Juergen,
>
> Here are a couple comments,
>
> At 03:18 PM 11/4/2003 +0100, Juergen Boemmels wrote:
> >currently there is no (simple) way to open a file on an other layer
> >than the default layer. But this is necessary if we want to take
> >advantage
Dan Sugalski wrote:
[ freeze/thaw writer/reader ]
... For this I think we're better off with
specific API functions since the set is small and bounded. If we really
want we can put them in some sort of vtable structure, which might not be
a bad thing.
Sort of vtable could be a real vtable too. I.e.
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>
>> Parrot Calling Convention Confusion
>> ... -- I thought they were exactly the same as an unprototyped call,
>> but you invoke the return continuation (P1) instead of P0, the other
>> registers
13 matches
Mail list logo
