Re: Google Dart
On 10/11/2011 09:08 AM, Krystal Mok wrote: Variance in Dart somehow bears a problem similar to the one in Java's array: http://try-dart-lang.appspot.com/s/qAoU The dartboard don't do any type checking at all. But yes, reading the doc it seems that generics are covariant and contravariant. Rémi On Mon, Oct 10, 2011 at 4:02 PM, Rémi Forax fo...@univ-mlv.fr mailto:fo...@univ-mlv.fr wrote: On 10/10/2011 09:51 AM, Marcus Lagergren wrote: FYI, Google Dart now has a twitter account : https://twitter.com/#!/dart_lang https://twitter.com/#%21/dart_lang https://twitter.com/#%21/dart_lang and Website is up http://www.dartlang.org/ /M OMG, Dart is the next Java not the next Javascript ! Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net mailto:mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Google Dart
On 10/10/2011 08:58 PM, Charles Oliver Nutter wrote: I agree it would be an interesting language on the JVM. It may be the dynamic Java I've wanted to make for a long time, with the added bonus of optional static types. This could almost be a weekend project atop invokedynamic. The type system is not that simple if you want to avoid to do one cast for each assignation (and for each method call arguments). I think you need one supplementary day :) - Charlie Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: dyn.js - invokedynamic-based js implementation
Adding some thoughts of my own… On Oct 11, 2011, at 1:00 AM, Rémi Forax wrote: And at the end, all predefined Javascript objects should be re-written in Javascript, with some native calls to Java but it will be easier for providing the core API. By example, for javascript Number, it should be a j.l.Double but with it's own vtable to add all Javascript predefined methods. The idea is that j.l.Double and Javascript Number are the same object at runtime but are seen differently in Java and in Javascript. Yes. You can do this really nicely with Dynalink linkers, here's how: - in your invoke dynamic bootstrapped, define two linkers as your prioritized linkers. First one is the public one (the one whose class you export in META-INF/services). The other is a private linker that only acts on java.lang.Number, java.lang.String, and java.lang.Boolean, and provides extra JS operations on them. That way, if your runtime encounters any of these types + a JS only method invocation (or type conversion) on them, you can implement the required JS semantics in this private linker. Further to Remi's points, I was looking at your usage of the linker, and I think you might be using it wrong :-). First, all your linkages seem to be unconditional (there's never a guard). This doesn't seem right, as you can't relink if your call site gets a POJO instead of a JS object. You're also using the linker to link a static print method -- you shouldn't use a dynamic linker for that; you should just emit the INVOKESTATIC at the call site instead of making it an INVOKEDYNAMIC call. Alternatively, you can prefix that too with dynjs:, see below. In general, for every usage were you'd just unconditionally link, you should just have an INVOKESTATIC/INVOKESPECIAL to a method in your runtime and not go through Dynalink. Your linker should first check whether what it was given is a DynObject (it should in fact implement TypeBasedGuardingDynamicLinker and claim it only links DynObject (or maybe DynAtom), and if so, provide the linking for the standard dyn:* operations on them. Mind you, you can still have your private dynjs:* operations defined by linker, that's fine (i.e. if you want to, replace print with dynjs:print too), just don't link them unconditionally, always link them with a guard of instanceof DynAtom/Scope/DynObject, or what's applicable. That way, you make your system more interoperable by allowing users of your runtime to supply -- if they know how to and want to -- definitions for these operations in their own linkers for their own objects. Attila. cheers, Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Google Dart
On 10/11/2011 2:03 AM, Rémi Forax wrote: On 10/10/2011 08:58 PM, Charles Oliver Nutter wrote: I agree it would be an interesting language on the JVM. It may be the dynamic Java I've wanted to make for a long time, with the added bonus of optional static types. This could almost be a weekend project atop invokedynamic. The type system is not that simple if you want to avoid to do one cast for each assignation (and for each method call arguments). I think you need one supplementary day :) IMO, I can see a few (possibly technical) reasons for designing it the way they did: a trivial implementation using dynamic types can ignore the types and still work. however, I don't like it per-se, as the way it leaves open the case that an implementation may be forced to use dynamially-typed references even when using declared types, which IMO partly defeats the point of using declared types. I more prefer it when declared types are a bit stronger, as in: if you declare the type of a variable, then the value in the variable *will* be that type. so, I think preferably this boils down to one of several major options: type-check the assignment (or pass as argument), and balk/reject-the-code if it will fail; implicitly coerce the value to the target type (maybe warn if unsafe, or balk if it is not a valid type conversion). (some prior versions of my language had it more as undefined, as in, if there is a type mismatch, one is liable to find their variable filled with garbage, as the type was treated mostly as an optimizer hint, but I later added implicit type coercion and made this the defined semantics). also, as for declared-type = physical-type, this more easily allows for the (efficient) implementation of variables as native machine types when applicable (such as in stack-frames or in objects), and one can save references mostly for other things. it also saves from endlessly marshaling values to/from reference types as part of performing operations (such as arithmetic). not that it has to be strictly this way though, for example, one can allow conversion to/from dynamic/variant types to involve implicit boxing/unboxing. but, anyways, one can be careful not to underestimate the amount of time/effort some things will take: for example, a recent idea of mine was to essentially shove a WAD2 variant into PE/COFF images post-link (for storing additional lumps, generally for VM metadata and bytecode). (note: WAD2 was a format used in Quake/Half-Life for storing textures. my variant is similar except that the header has a different/longer magic number, and optional indirect-names which allow for lump-names longer than 16 characters, also compression methods 8/9 are defined as Deflate and Deflate64). (there were technical reasons for me not choosing a ZIP variant here). I initially estimated this to be an approx 2 hour project. the project in-fact took a good portion of 2 days: the former night, mostly for writing out most of the code, and the next morning/afternoon mostly for debugging it all and making it work. - Charlie Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Help with JIT talk for tomorrow
Hi all, FYI - I checked with Georges Saab and he thinks there was simply an outage at Santa Clara. Let me know if the page is still down! There is a longer term plan to shift things off the older infrastructure, details TBA. Cheers, Martijn On 9 October 2011 21:59, Krystal Mok rednaxel...@gmail.com wrote: On Mon, Oct 10, 2011 at 3:43 AM, Sebastian Sickelmann sebastian.sickelm...@gmx.de wrote: Unfortunately http://wikis.sun.com/display/HotSpotInternals/Home seems to be down. :-( Same here. I was trying to access it last night and I got redirected to Bug Database instead. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Google Dart
Unfortunately, this thread has been a little off-topic for a while now. I don't think there is a good single forum for let's complain about Dart design decisions, and it probably isn't useful to do so, as every person I've spoken to on the subject has something completely different that they dislike about it, and not everyone agrees on each specific point anyway. On 12 October 2011 03:42, BGB cr88...@gmail.com wrote: however, I don't like it per-se, as the way it leaves open the case that an implementation may be forced to use dynamially-typed references even when using declared types, which IMO partly defeats the point of using declared types. The 'types should/should-not affect program behaviour' is a philosophical choice, and there are people who feel very strongly about it. Anyway, this doesn't preclude you from generating guarded, optimised code for the case that the types are as expected, and you can do this AOT. -- William Leslie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
