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
Leopold Toetsch wrote:
I've checked in intial support for anonymous subroutines.
.sub foo @ANON
creates an anonymous subroutine.
Cool.
I can't seem to combine it with "non_prototyped".
- Sam Ruby
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 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 JavaScript are litt
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
Sam Ruby writes:
> 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 JavaScript are little more than bundles of
> properites, some of which may be functions. And classes are essenti
Dan Sugalski wrote:
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 tha
Should be working again, thanks to Josh Wilmes.
As a bonus, I found that one of my Tcl tests was unexpectedly succeeding.
A bit of a nit, but should the implementation & docs for the "does" opcode be moved to the
"pmc" file rather than the "object" file, since this is something available to every PMC? If
so, I can move it over.
I've also submitted a patch to the parrotcode site that adds the documentation for
"clas
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
Okay, I've made the final checkin to the string branch, one that
SKIPs the tests that fail because of the (very temporary, I hope)
lack of unicode support.
The branch is ready to get merged into the trunk and we can deal with
the fallout from that. Unfortunately this is *not* quite as finished
On Sat, 27 Nov 2004 22:48:42 +0100, liorean <[EMAIL PROTECTED]> wrote:
> CLR, JVM and C/C++ implementations exists. As parrot is supposed to be
> better for dynamic languages, I guess EcmaScript 3.0 would fit right
> in with parrot.
It should. EcmaScript is also a relatively small language, which w
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 parrot?
> I believe not. That's real
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 parrot?
I believe not. That's really something that should get done, though...
--
Schwäche zeigen heißt verlieren;
härte
Are there any projects to create an implementation of
EcmaScript/JavaScript that will run on top of parrot?
--
David "liorean" Andersson
http://liorean.web-graphics.com/>
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
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> 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
*g*
> I read this and thought of a subtle problem. So I tried some code, and
Whoops. Perhaps Dan was merely stringing me along. =-)
Closing call.
Leopold Toetsch via RT wrote:
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
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
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Here is a patch:
Thanks, I've inserted that line.
Please provide unified patches (patch -u | --unified). See also:
perldoc -F docs/submissions.pod
Please note that the preprocessor is still broken. It was merely
intended to have a look at created c
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,
28 matches
Mail list logo
