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,
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 ;)
I was. Hmm...
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]
*
[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
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
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 ba (le I1, I0)
and not to b=a (lt I1, I0)...? (The same for isge a, b = islt b, a)
jens
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
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
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 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
Should be working again, thanks to Josh Wilmes.
As a bonus, I found that one of my Tcl tests was unexpectedly succeeding.
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 that
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 essentially
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 reason...
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
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 little
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
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
# New Ticket Created by Will Coleda
# Please include the string: [perl #32667]
# in the subject line of all future correspondence about this issue.
# URL: 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
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
20 matches
Mail list logo
