Re: exploring an interim solution for IDE support for Scala.Net

But SDT uses JDT.

-------------------------------------
Pedro Furlanetto wrote:

This might be of some help:

http://emonic.sourceforge.net/

From the page: "Emonic stands for Eclipse Mono Integration. It is an
Eclipse plug-in which allows you to build C# programs with Mono or
Microsoft .NET.". It OS with Eclipse Public License and the last
release is from January 7, so I guess it's been actively developed.

Some limited debugging should be feasible using the reflection API
that is been under development, assuming that it is .Net compatible
and that you are able to communicate with the running process and
create breakpoints.

Hope to have helped. Remember to keep us posted.

Cheers,
PF

On Sun, Mar 28, 2010 at 4:21 PM, Miguel Garcia wrote:
>
> Actually this is a question to myself, but if you feel like helping me think
> this out you're more than welcome, thanks!
>
> On the one hand we have IDE support for Scala on the JVM; and on the other
> we have a bunch of assemblies with .NET types plus the Scala.Net
> cross-compiler.
>
> Is there a way to represent those .NET types in a format consumable by
> current IDEs supporting Scala? If so, then the IDE in question could be used
> to develop Scala.Net apps (with all navigation and editing goodies running
> on the JVM-based IDE, but offloading the compilation to the Scala.Net
> compiler)
>
> As to what that "consumable representation" might be, two alternatives seem
> plausible candidates:
>
>  (a.1) Scala sources (containing type defs with empty method bodies)
> generated from the referenced assemblies in a manner similar to how .NET
> Reflector does its thing
>
>  (a.2) the Java stubs generated by ikvmstub,
> http://www.ikvm.net/devguide/java2net.html (this is bit less elegant because
> what used to be "System.IO.*" becomes "cli.System.IO.*" and later has to be
> unmangled)
>
> Regarding (a.1), all capabilities of the CLR type system are supported by
> Scala's type system, so no info would be lost. Granted, a convention is
> needed to represent in Scala sources the "API" of events and properties
> (same as under the hood of the C# compiler) but this does not compromise
> type safety. In any case, (a.1) or (a.2) need be performed only upon
> recompilation of the referenced assemblies, i.e. not that often.
>
> For example's sake, assuming (a.1) has been made to work, there are still a
> few TODOs:
>
>  (b.1) the IDE in question should be instructed to use the Scala.Net
> (presentation?) compiler rather than the built-in one
>
>  (b.2) hiding rt.jar (in particular java.lang.*) is necessary: the IDE
> plugin should not perform lookups there, but in System.bla.bla
>
> About IDE-based debugging . well I guess for that one would have to take the
> pdb file (debug info including source locations, generated by Scala.Net) and
> the .scala files to an IDE for Mono or .NET to perform the debugging there.
>
> Experience reports are welcome!
>
> Miguel
> http://www.sts.tu-harburg.de/people/mi.garcia/ScalaCompilerCorner/
>
>
>
>