Eclipse plugin hardening
"type BoxedBoolanArray not found" definitely means only that your
referenced self-contained Scala library is fragged (not any
dependencies). Are you using SCALA_HOME or replacing SCALA_LIB in any
of your projects you can't open? If you want, you could actually give
me one of the projects (assuming its relatively self contained) and I
can try opening it.
We should really figure out away around that as we require loading up
the entire compiler instance to even get at the parser. Maybe I could
convince Martin into reducing the "Global" dependency so that the
compiler is more modular, but it seems like a big change in the
compiler for me (trees refer to symbols and types, everything gets
pulled in and the definitions initializer is run). Maybe explicit
initialization of definitions would work better. Another option is to
harden definitions so that it will spew out an error and disable the
type checker but not result in a crash if some symbol is not
available. Still another option is to always fall back on the scala
library that's included in the plugin, if what the user has specified
can't be handled by the compiler.
On Tue, Jul 1, 2008 at 9:11 PM, Josh Suereth
> +1 Committing to the trunk...
> Now for my rant:
> I'm also having trouble runnning the plugin, but then again I was trying to
> dogfood as well. Not sure when the change happened, but currently I cannot
> open the plugin project. I've been able to start small projects on my own
> and the plugin works ok until I type the magic phrase that crashes it.
> I'm still getting the BoxedBooleanArray type not found issue, however I can
> start a new project, and the problem does not show up. Not sure what kind
> of classloading/typeloading magic is happening but I haven't been able to
> find any relevant information about this issue. The OSGi bundles appear to
> be wired correctly because a new project will work fine
> (compiling/running/editing/etc), so I doubt it's an OSGi startup issue.
> I know eclipse has a "friend" classloader feature it added on top of OSGi.
> Is this needed for the compiler/runtime plugin so that classes from other
> plugins are available at runtime? I haven't had a stable plugin since the
> scala runtime / compiler were pulled out into separate plugin, hence my
> theory on classloaders.
> Anyway... enough ranting. I'd say commit what you have to the trunk. Just
> yesterday I wanted to write some java code and use it in scala... I'm
> already dealing with a buggy plugin. If you commit what you have, who
> knows. Maybe I'll even be able to fix a bug.
> On Tue, Jul 1, 2008 at 6:06 AM, Sean McDirmid <sean.mcdirmid@...>
>> But it could be that Ingo's coding style is tickling a part of the
>> plugin that hasn't been tickled very much yet. Some features of Scala
>> are not well tested by specific users, that is why its important to
>> get a wide audience to test the plugin.
>> This happens with scalac all the time (especially when I write code :) ).
>> On Tue, Jul 1, 2008 at 5:12 PM, Miles Sabin <miles@...> wrote:
>> > I don't think things are a bad as you're making out. Like Sean I'm
>> > dogfooding the plugin (including the JDT integration stuff that I'm
>> > about to commit) and it's quite usable. Which means usable for the
>> > compiler and plugin projects which are far from trivial. Yes, things
>> > go wrong occasionally and I sometimes have to restart Eclipse or
>> > modify a .scala file in the text editor because the Scala editor is
>> > confused. It requires a little patience, but it's worth and I don't
>> > think I've ever lost data.
>> >> However, please keep more than just the latest version on the update
>> >> site so
>> >> one revert to an older potentially more stable version.
>> > Somewhat to my surprise it turns out that this is already happening,
>> > http://www.scala-lang.org/downloads/distrib/files/nightly/
>> > The ch.epfl.lamp.sdt_2.7.1.*.zip files are the last two weeks worth of
>> > plugin nightly builds. You can download them and install them as an
>> > Eclipse local update site.
>> > Cheers,
>> > Miles