[Mono-list] IKVM+Rhino=JS for mono?

2004-06-17 Thread Stuart Ballard
It occurred to me that it might be possible to run Rhino under IKVM to 
get a quick boost into a mature ECMAScript implementation for Mono. 
Presumably, with a couple of tweaks to ignore the cli. prefix that 
IKVM inserts for .NET classes, it would do most of what's required for 
the .NET platform's JavaScript.

I have no time or knowledge to pursue this myself, but I'm throwing the 
idea out there in case anyone wants to run with it. It might be possible 
to get Rhino+IKVM to production quality quicker than the from-scratch 
ECMAScript implementation that's being worked on at the moment. Worst 
case, we end up with two high-quality ECMAScript implementations to 
choose between :)

Stuart.
--
Stuart Ballard, Senior Web Developer
NetReach, Inc.
(215) 283-2300, ext. 126
http://www.netreach.com/
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] IKVM+Rhino=JS for mono?

2004-06-17 Thread Carlos Alberto Cortez
Hi:

Currently I'm helping Cesar Lopez Nataren to port the Rhino Lexer and
Parser stuff, and then finish the JScript compiler implementation. Maybe
it would be a good idea to finish to port to C#, than trying to use them
with IKVM, since you would have to run ikvm on top on mono, and then run
rhino on top of ikvm, representing a big overhead.

By the way, if you are interested in the first approach, you could try
to port Rhino and we could finish the JScript compiler earlier.

Carlos.

El jue, 17-06-2004 a las 14:06, Stuart Ballard escribi:
 It occurred to me that it might be possible to run Rhino under IKVM to 
 get a quick boost into a mature ECMAScript implementation for Mono. 
 Presumably, with a couple of tweaks to ignore the cli. prefix that 
 IKVM inserts for .NET classes, it would do most of what's required for 
 the .NET platform's JavaScript.
 
 I have no time or knowledge to pursue this myself, but I'm throwing the 
 idea out there in case anyone wants to run with it. It might be possible 
 to get Rhino+IKVM to production quality quicker than the from-scratch 
 ECMAScript implementation that's being worked on at the moment. Worst 
 case, we end up with two high-quality ECMAScript implementations to 
 choose between :)
 
 Stuart.
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] IKVM+Rhino=JS for mono?

2004-06-17 Thread Stuart Ballard
Carlos Alberto Cortez wrote:
Hi:
Currently I'm helping Cesar Lopez Nataren to port the Rhino Lexer and
Parser stuff, and then finish the JScript compiler implementation. Maybe
it would be a good idea to finish to port to C#, than trying to use them
with IKVM, since you would have to run ikvm on top on mono, and then run
rhino on top of ikvm, representing a big overhead.
If you use ikvmc, the overhead isn't that huge and could be reduced 
further with a small amount of work (which would help other users of 
IKVM as well).

A small amount of overhead for mapping certain method calls (not all) on 
java.lang.Object and java.lang.String is unavoidable, as is a larger 
amount of overhead when exceptions are used, but exceptions are slow 
anyway and shouldn't be used in performance-critical parts of the code.

The rest of the current overhead, as far as I know, is memory overhead 
caused by the need to have all of IKVM.GNU.Classpath.dll and all of 
IKVM.Runtime.dll loaded even when not all of it is in use. Classpath.dll 
could be split up by Java package so that you might only need to load 
the java.lang equivalents and maybe java.io. IKVM.Runtime.dll could have 
the JIT compiler split out because you don't need it when you're in 
static mode, unless you're doing dynamic loading of classes. I believe 
that the IKVM author plans on doing these things anyway, eventually, 
although they won't make Mono 1.0.

It occurs to me that perhaps Rhino *does* do dynamic loading of classes 
and so that overhead would be significant. Still, I imagine that adding 
a CIL-generator as an alternative to the Java bytecode generator would 
be less work than porting the entire code to C# - and you could benefit 
from ongoing improvements to Rhino in the future. (Of course, you can 
use System.Reflection.Emit directly from Java code to make the CIL 
generator simpler to write)

Obviously I can't tell you what to do, and like I said, I don't have 
time to work on this myself. I can only suggest what I think would save 
you some work...

Stuart.
--
Stuart Ballard, Senior Web Developer
NetReach, Inc.
(215) 283-2300, ext. 126
http://www.netreach.com/
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] IKVM+Rhino=JS for mono?

2004-06-17 Thread Carlos Alberto Cortez
Hi again,

I think that some of the points you exposed are valid and are very
interesting. However, the Rhino lexer  parser have together only about
300 lines of code, so that is not *that much* code.

However, it looks like the approach you mentioned could be valid for
other projects that could need it and have a bigger complexity.

Regards,
Carlos.

El jue, 17-06-2004 a las 14:56, Stuart Ballard escribi:
 Carlos Alberto Cortez wrote:
  Hi:
  
  Currently I'm helping Cesar Lopez Nataren to port the Rhino Lexer and
  Parser stuff, and then finish the JScript compiler implementation. Maybe
  it would be a good idea to finish to port to C#, than trying to use them
  with IKVM, since you would have to run ikvm on top on mono, and then run
  rhino on top of ikvm, representing a big overhead.
 
 If you use ikvmc, the overhead isn't that huge and could be reduced 
 further with a small amount of work (which would help other users of 
 IKVM as well).
 
 A small amount of overhead for mapping certain method calls (not all) on 
 java.lang.Object and java.lang.String is unavoidable, as is a larger 
 amount of overhead when exceptions are used, but exceptions are slow 
 anyway and shouldn't be used in performance-critical parts of the code.
 
 The rest of the current overhead, as far as I know, is memory overhead 
 caused by the need to have all of IKVM.GNU.Classpath.dll and all of 
 IKVM.Runtime.dll loaded even when not all of it is in use. Classpath.dll 
 could be split up by Java package so that you might only need to load 
 the java.lang equivalents and maybe java.io. IKVM.Runtime.dll could have 
 the JIT compiler split out because you don't need it when you're in 
 static mode, unless you're doing dynamic loading of classes. I believe 
 that the IKVM author plans on doing these things anyway, eventually, 
 although they won't make Mono 1.0.
 
 It occurs to me that perhaps Rhino *does* do dynamic loading of classes 
 and so that overhead would be significant. Still, I imagine that adding 
 a CIL-generator as an alternative to the Java bytecode generator would 
 be less work than porting the entire code to C# - and you could benefit 
 from ongoing improvements to Rhino in the future. (Of course, you can 
 use System.Reflection.Emit directly from Java code to make the CIL 
 generator simpler to write)
 
 Obviously I can't tell you what to do, and like I said, I don't have 
 time to work on this myself. I can only suggest what I think would save 
 you some work...
 
 Stuart.
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list