Re: [perl #32645] [TODO] Generic PMC type info
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, there's no easy way to ask a PMC, are you hashlike?. Ha? $ cat does.imc .sub main @MAIN $P0 = new Array $I0 = does $P0, array print $I0 $P1 = new PerlHash $I0 = does $P1, hash print $I0 print \n $I0 = does $P1, array print $I0 $I0 = does $P0, hash print $I0 print \n .end $ ./parrot does.imc 11 00 leo
Re: continuation enhanced arcs
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... bugger. So, unless we make the register allocator solve the halting problem, the rule becomes If you're playing silly beggars with continuations and you're expecting to get at something in a 'surprising' way, stuff it in a lexical or we guarantee that you will be anally violated by an enraged waterbuffalo that's just sick to death of non-determinism? This would make quite a fine explanation in the docs, except that's a bit unclear about stuff *it*. The waterbuffalo is concerned of preserved *temporary* variables too. leo
[CVS ci] opcode cleanup 1 - minus 177 opcodes
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/ops.num is now the ultimate source of valid opcodes, except for opcodes in ops/experimental.ops, which are included in core_ops*.c nethertheless [1] I'll remove some more ops RSN so you might wait to use this version in production. Opcodes to be removed: 1) Almost half of the non-PMC compare and branch opcodes according to: lt a, b, L1 = ge b, a, L1 2) Very likley (unless one loudly hollers): all opcodes with FLOATVAL constants except set_x_nc and assign_x_nc . These are 107 opcodes with no counterpart in JIT or hardware. The constants have to be loaded from the constant table anyway, so we might that just do it in a separate opcode. leo
Re: [perl #32643] [TODO] Remove Perl* PMCs from opcodes
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
Re: cvs commit: parrot/ops cmp.ops ops.num
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
Re: [CVS ci] opcode cleanup 1 - minus 177 opcodes
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 correct: $ /usr/bin/perl -le 'print $a $b: , $a $b, \n$b = $a: , $b = $a while ($a, $b) = splice @ARGV, 0, 2' 1 2 1 1 1 2: 1 2 = 1: 1 1 1: 1 = 1: 1 After experimenting, I think that it should be lt a, b, L1 = gt b, a, L1 Which works for the subtle problem that I thought of: $ /usr/bin/perl -le 'print $a $b: , $a $b, \n$b $a: , $b $a while ($a, $b) = splice @ARGV, 0, 2' 1 2 1 1 nan 1 1 2: 1 2 1: 1 1 1: 1 1: nan 1: 1 nan: So I was wrong on that one. (NaNs may be crazy, but at least they're still commutative.) If I'm right, then this doesn't say good things about the completeness of our regression tests. Nicholas Clark
Re: cvs commit: parrot/ops cmp.ops ops.num
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 ba (le I1, I0) and not to b=a (lt I1, I0)...? (The same for isge a, b = islt b, a) It's easy to get it wrong :) See also Nick's post. (a = b) := (a b || a == b) := (b a || a == b) ... jens leo
Re: EcmaScript
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 parrot? I believe not. That's really something that should get done, though... 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. I have only the smallest knowledge of other languages (have made some tries at Scheme and Ruby, but I don't really feel comfortable with them), but I have used JavaScript since first introduced in nn2 and I'd love to contribute. Could one write an initial compiler in JavaScript, compile from SEE or SpiderMonkey and then run the compiler on that implementation? Absolutely. Compilers do *not* have to be integrated in with parrot -- my current work project uses Parrot as its back end, but the compiler's written in perl as a standalone program. Works just fine. (Though a Javascript compiler written in Javascript could bootstrap itself pretty nicely. That'd be cool... :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] opcode cleanup 1 - minus 177 opcodes
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 and shuffled - please recompile your PBCs [1] * ops/ops.num is now the ultimate source of valid opcodes, except for opcodes in ops/experimental.ops, which are included in core_ops*.c nethertheless Could you undo this please? Now is not the time to be trimming ops out. We can do that later, closer to release, if we choose to do it at all. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] opcode cleanup 1 - minus 177 opcodes
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... In any case, there is some stuff worth keeping, IMHO: * (is)?l[t,e]_i_i_i and (is)?g[t,e]_i_i_i *are* redundant * rand* should not be ops * lcm_n_i_i doesnt make any sense as the result is an integer * constant folding (no need for opvariants with two constant args) now is as good as ever for those Then there are changes that need more thought: * replacing *_i_n with *_n_n uses a N-register and might put stress on the register allocator in case of heavy floating code. Doing these now smells in fact a bit like premature optimisation... So I would like to propose salami-tactic and try to find the offending slices (the ones with the pepper) instead of rejecting the whole salami. just my 2 cents though tom
Re: EcmaScript
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 in the process of absorbing a set of patches to add continuation support. Actually, I've spent the last couple of hours looking into three implementations: Narcissus, Rhino and SpiderMonkey (and SEE a little, too). I'd say Narcissus seems like a far better starting point for at least two things: First of all, it's a JavaScript in JavaScript implementation. Second, it's by far the easiest to get a grip of. (Probably because of what language it's written in. C and Java contains so much syntactic sugar...) The bad part is that Narcissus is an interpreter and not a bytecode compiler, unlike the other two. As for continuations, I've known about Cocoon for a while, and their Rhino with proper tail recursion and first class continuations. It's neat, and I'd certainly not go any other way. (Parrot should make this easy, compared to JVM/CLR...) 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 templates for such objects. I don't really think it's that strange. Essentially, all objects contain a reference to their prototype. When getting a member of an object, the object will first check it's own members for the corresponding identifier, then ask it's prototype, and so on until the prototype chain is depleted. Setting is always done on the object itself. It's really not so much inheritance as it is conditional runtime delegation. Functions are of course first class and shouldn't differ from any other member - there is no native method/property distinction in JavaScript, even though host object may have such a distinction. The difference between a function and a method is the binding of the this keyword. Privacy is all handled by the closure creation, so that should be a freebie with implementing constructors. Note that the prototype delegation system could very well exist on an object which inherits properties from a class, if the host allowed it. The systems are orthogonal. But then I expect that to get ugly fast, especdially with a Ruby-like class system... Hopefully LiveConnect can be tweaked so that it can give the same automatic wrapping/unwrapping of parrot native objects as it provides for Rhino and Java natives in JVM. -- David liorean Andersson uri:http://liorean.web-graphics.com/
Re: EcmaScript
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 JavaScript are little more than bundles of properites, some of which may be functions. And classes are essentially templates for such objects. I don't really think it's that strange. Essentially, all objects contain a reference to their prototype. When getting a member of an object, the object will first check it's own members for the corresponding identifier, then ask it's prototype, and so on until the prototype chain is depleted. Setting is always done on the object itself. It's really not so much inheritance as it is conditional runtime delegation. Functions are of course first class and shouldn't differ from any other member - there is no native method/property distinction in JavaScript, even though host object may have such a distinction. This seems to me to be very much the way Python works as well, though the emphasis is different. (That is, the common case in Python is to define methods per-class rather than per-instance, and in JavaScript it's the opposite. But that's not a technological difference, just a cultural one.) I would think that the implementations would share a lot. I agree with both of you (and with Luke's observation on the existance of a find_method vtable entry, which I've used to good advantage already inside PyClass.pmc). What I am finding is that a very different approach is embedded inside object.c and needs to be factored out into what is currently (mis-)named ParrotObject and ParrotClass. I have ideas on how this should be handled, but my needs are not (yet) urgent, and Dan has expressed an interest in making the change, so I'm willing to wait for a little bit. - Sam Ruby
[perl #32667] [TODO] IMCC Documentation
# 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 changed recently, thanks. leo
PGE issues
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 pge_parse.o pge_gen.o pge_opt.o pge_parsep5.o pge_parseglob.o ld: multiple definitions of symbol _pge_cmeta pge_parse.o definition of _pge_cmeta in section (__DATA,__common) pge_parseglob.o definition of _pge_cmeta in section (__DATA,__common) ld: multiple definitions of symbol _pge_ctype pge_parse.o definition of _pge_ctype in section (__DATA,__common) pge_parseglob.o definition of _pge_ctype in section (__DATA,__common) /usr/bin/libtool: internal link edit command failed make: *** [pge.dylib] Error 1 This is on OS X: Darwin oolong 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc It did work for a little while.
