A few issues with the recent CVS doings...
1) runtime/parrot/library/runtime/PGE.pir doesn't compile by default. Which it
can't, because:
2) PGE doesn't build by default. Should it? If so, then...
3) cd compilers/pge && make fails:
c++ -dynamiclib -L/usr/local/lib -flat_namespace -o pge.dylib pg
# New Ticket Created by Will Coleda
# Please include the string: [perl #32667]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32667 >
> BTW it would be great if someone could go through the imcc docs, a lot
> has change
Jeff Clites wrote:
On Nov 27, 2004, at 5:58 PM, liorean wrote:
On Sat, 27 Nov 2004 19:30:20 -0500, Sam Ruby <[EMAIL PROTECTED]>
wrote:
Overall, JavaScript would be a good match for Parrot. One place
where it would significantly diverge at the moment is in the concept
of a "class". Objects in
On Sat, 27 Nov 2004 19:30:20 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote:
> Probably the best base to start with is Rhino, which is a standalone open
> source JavaScript compiler written in Java - originally done by the
> JavaScript team at NetScape. This code is quite good. And coincidentally is
Dan Sugalski wrote:
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
>> [...]
>>
Could you undo this please? Now is not the time to be trimming ops out.
OTOH, it won't hurt anyone and it is already in.
So why bother, unless of course there is a technical reaso
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
* other VMs might already have a negative opcode count w this change ;)
* there are 3 incompatible changes: see ABI_CHANGES
* all other removed opcodes get replaced with equivalent ops
* opcodes got renumbered a
At 10:48 PM +0100 11/27/04, liorean wrote:
On Sat, 27 Nov 2004 21:11:07 +, Herbert Snorrason
<[EMAIL PROTECTED]> wrote:
On Sat, 27 Nov 2004 21:43:01 +0100, liorean <[EMAIL PROTECTED]> wrote:
> Are there any projects to create an implementation of
EcmaScript/JavaScript that will run on top of
Jens Rieks <[EMAIL PROTECTED]> wrote:
> On Saturday 27 November 2004, Leopold Toetsch wrote:
>> + gt I0, I1, L1 => lt I1, I0, L1
>> + isge I0, 100, I2 => isle I0, I2, 100
> But a>=b (gt I0, I1) is equivalence to b and not to b<=a (lt I1, I0)...? (The same for isge a, b <=> islt
On Sat, Nov 27, 2004 at 10:34:17AM +0100, Leopold Toetsch wrote:
> 1) Almost half of the non-PMC compare and branch opcodes according to:
>
> lt a, b, L1 => ge b, a, L1
I read this and thought of a subtle problem. So I tried some code, and I
surprised myself. I don't think that your logic is
On Saturday 27 November 2004, Leopold Toetsch wrote:
> Â + Âgt I0, I1, L1ÂÂ Â Â Â=> lt I1, I0, L1
> Â + Âisge I0, 100, I2 Â Â=> isle I0, I2, 100
But a>=b (gt I0, I1) is equivalence to b islt b, a)
jens
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
>> The following opcodes return 'PerlUndef' on failure, instead of
>> 'Undef' or null.
>>
>> open, socket, fdopen, dlfunc, dlvar, find_global
> Patch attached that changes all these to Undef.
Thanks, applied.
leo
See also subject "Too many opcodes".
* other VMs might already have a negative opcode count w this change ;)
* there are 3 incompatible changes: see ABI_CHANGES
* all other removed opcodes get replaced with equivalent ops
* opcodes got renumbered and shuffled - please recompile your PBCs [1]
* ops/
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> We don't have a problem WRT register preservation, the problem arises
>> due to register re-using.
> Ah! [a light goes on over Piers's head].
>>> Or am I missing something fundamental?
>> I don't know ;)
>
Will Coleda <[EMAIL PROTECTED]> wrote:
> Based on a conversation with Dan in IRC, it should be possible to
> interrogate PMCs about their generic type.
> For example, tcl's [array exists varName] returns true if the variable
> is defined /and/ is an array variable (in perl-speak, a hash).
> But,
14 matches
Mail list logo
