Ingo Maier | 1 Jul 2008 09:34
Picon
Picon
Favicon

Re: [scala-user] Poll - Eclipse plugin potentially destabilizing commit

> * Yes! Commit to the trunk, I don't mind if nightlies are a bit
> unstable for a few days.

Honestly, the trunk _is_ unstable. Right now. It was never stable. For 
anything more than trivial projects it keeps crashing and I either have 
to restart eclipse or disable the Scala editor. I'd vote for commit into 
trunk. I don't think I'd really try it if it were branched in this early 
stage. However, please keep more than just the latest version on the 
update site so one revert to an older potentially more stable version.

Ingo

Sean McDirmid | 1 Jul 2008 09:41
Picon

Re: Re: [scala-user] Poll - Eclipse plugin potentially destabilizing commit

Right now the current one is unstable? I'm dogfooding and trying to
wring out all the crashes. Something in the compiler changed recently
that destroyed inter-project recompilation, but I think I fixed it.
Please if there are any crashes in the trunk, at least send me some
stack traces so I can plug them.

On Tue, Jul 1, 2008 at 3:34 PM, Ingo Maier <ingo.maier@...> wrote:
>> * Yes! Commit to the trunk, I don't mind if nightlies are a bit
>> unstable for a few days.
>
> Honestly, the trunk _is_ unstable. Right now. It was never stable. For
> anything more than trivial projects it keeps crashing and I either have to
> restart eclipse or disable the Scala editor. I'd vote for commit into trunk.
> I don't think I'd really try it if it were branched in this early stage.
> However, please keep more than just the latest version on the update site so
> one revert to an older potentially more stable version.
>
> Ingo
>

Miles Sabin | 1 Jul 2008 11:12
Gravatar

Re: Poll - Eclipse plugin potentially destabilizing commit

On Tue, Jul 1, 2008 at 8:34 AM, Ingo Maier <ingo.maier@...> wrote:
> > * Yes! Commit to the trunk, I don't mind if nightlies are a bit
> > unstable for a few days.
>
> Honestly, the trunk _is_ unstable. Right now. It was never stable. For
> anything more than trivial projects it keeps crashing and I either have to
> restart eclipse or disable the Scala editor. I'd vote for commit into trunk.
> I don't think I'd really try it if it were branched in this early stage.

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,
(Continue reading)

Sean McDirmid | 1 Jul 2008 12:06
Picon

Re: Re: [scala-user] Poll - Eclipse plugin potentially destabilizing commit

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 :) ).

Sean

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.
(Continue reading)

Josh Suereth | 1 Jul 2008 15:11
Picon
Gravatar

Re: Re: [scala-user] Poll - Eclipse plugin potentially destabilizing commit

+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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
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 :) ).

Sean

On Tue, Jul 1, 2008 at 5:12 PM, Miles Sabin <miles-XKJT71GPLR04Q++5jOxPmw@public.gmane.org> 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
>

Sean McDirmid | 1 Jul 2008 15:27
Picon

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.

Thoughts?

On Tue, Jul 1, 2008 at 9:11 PM, Josh Suereth
<joshua.suereth@...> wrote:
> +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@...>
> wrote:
>>
>> 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 :) ).
>>
>> Sean
>>
>> 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
>> >
>
>

DavidVillagra | 1 Jul 2008 21:25
Picon

more plugin problems


Hello again,
I updated my scala plugin so that I am now using the most recent
nightly plugin (7/01/08) for my scala/lift code in eclipse.  I also
updated to Eclipse 3.4 "Ganymede".  This is the URL that I am using
for the plugin:
http://www.scala-lang.org/downloads/distrib/files/nightly/scala.update/

When I try to debug my program I get the following error message:
ERROR - Failed to Boot
java.lang.VerifyError: class liftBasic.gid.model.User$ overrides final
method count.()J
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$000(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)
        at bootstrap.liftweb.Boot.boot(Boot.scala:24)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at net.liftweb.util.ClassHelpers$$anonfun$createInvoker
$1.apply(ClassHelpers.scala:343)
        at net.liftweb.util.ClassHelpers$$anonfun$createInvoker
$1.apply(ClassHelpers.scala:341)
        at net.liftweb.http.DefaultBootstrap$$anonfun$boot
$1.apply(LiftRules.scala:585)
        at net.liftweb.http.DefaultBootstrap$$anonfun$boot
$1.apply(LiftRules.scala:585)
        at net.liftweb.util.Full.map(Can.scala:264)
        at net.liftweb.http.DefaultBootstrap$.boot(LiftRules.scala:585)
        at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:442)
        at net.liftweb.http.LiftFilter.init(LiftServlet.scala:421)
        at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:
97)
        at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
39)
        at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:
593)
        at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
        at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:
1220)
        at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:
513)
        at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:
448)
        at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
39)
        at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:
130)
        at org.mortbay.jetty.Server.doStart(Server.java:222)
        at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
39)
        at RunWebApp$.<init>(RunWebApp.scala:16)
        at RunWebApp$.<clinit>(RunWebApp.scala)
        at RunWebApp.main(RunWebApp.scala)

Eclipse doesn't recognize any problems with the code so it should
build fine, as it used to about a week ago before I updated my plugin
and my eclipse version.  When I look at the page on the web browser,
it partially works but where the navigation menu is supposed to be on
the left side, it just says "No Navigation Defined".

Any ideas on how to get around this problem?

Thanks,
David 
--

-- 
View this message in context: http://www.nabble.com/more-plugin-problems-tp18223441p18223441.html
Sent from the Scala - Tools mailing list archive at Nabble.com.

Daniel Spiewak | 2 Jul 2008 01:28
Picon
Gravatar

Re: Poll - Eclipse plugin potentially destabilizing commit

I figured I'd take your version out for a spin, Miles, since obviously it shouldn't go into trunk/ if it's unusable in terms of stability.  :-)  Anyway, just wanted to mention that it's an absolutely awesome job!  It's definitely a step up from the current trunk/.  However, there were three problems that I ran into, one of them somewhat critical:

  • Can't rename any files (complains that filename must end with .java)
  • Can't Ctrl+Click into any Scala Library classes (e.g. Map, Predef, etc).  Ctrl+Click works fine into project files, as well as Java elements
  • Package-explorer outline gets a few members wrong, such as pass-by-name parameters or Object#MODULE$
Other than that, seems fairly slick!  It would be nice to get a working Outline View, since obviously it's available now as part of the package explorer, but I'm patient.  I'm switching this over to my primary until there's a LAMP update site for this version, whether in branches/ or trunk/.

Oh, for those of you who are curious as to the improvements but don't feel like taking their sources into their own hands, I'm attaching a screenshot which outlines the interesting stuff.

Daniel

On Mon, Jun 30, 2008 at 8:09 AM, Miles Sabin <miles-XKJT71GPLR04Q++5jOxPmw@public.gmane.org> wrote:
Hi folks,

I'd like to take a quick poll on where to commit my dangerously
growing delta against the trunk.

It includes the current state of the JDT integration that I've
mentioned on these lists a few times in the last few weeks. As such
it's genuinely useful (particularly for navigating .scala files
containing multiple class, trait and object definitions) but hovering
somewhere in between a proof of concept and a beta.

In an ideal world we'd just peel a release branch off from the trunk
as it is now after which I'd commit without worrying too much if that
left the trunk (and the nightlies) a little unstable for a while.
Unfortunately that isn't really possible, because the current trunk of
the plugin depends on features from the trunk of the compiler (notably
access to incrementally updated ASTs and support for mixed Scala/Java
projects) which haven't been released yet. As such I don't think it
would be sensible to make a plugin release which was also a de facto
but unsupportable compiler release.

An alternative which was discussed at the last EPFL Scala development
meeting and got a tentative thumbs up is to leave the trunk as is, but
peel off an experimental "JDT integration" branch with a view to
merging that prior to a proper plugin release that was synchronized
with the next compiler release. The problem with that is that most of
the action will be happening on the branch, and the trunk will
essentially stagnate until the merge happens. And that makes the
nightlies a little pointless.

So I'd like your votes as follows,

* Yes! Commit to the trunk, I don't mind if nightlies are a bit
unstable for a few days.

* No! Commit to a branch, get back to me when that JDT stuff is closer
to being ready.

You can try before you buy by installing the update from here,

 http://www.milessabin.com/scala/scala.update/

which is a snapshot of the plugin, compiler and libraries as of this morning.

Cheers,


Miles

Sean McDirmid | 2 Jul 2008 02:05
Picon

Re: more plugin problems

You probably need to rebuild lift for the new plugin, I don't think
the nightly build is binary compatible with the released version of
Scala.

Sean

On Wed, Jul 2, 2008 at 3:25 AM, DavidVillagra
<david.v.villagra@...> wrote:
>
> Hello again,
> I updated my scala plugin so that I am now using the most recent
> nightly plugin (7/01/08) for my scala/lift code in eclipse.  I also
> updated to Eclipse 3.4 "Ganymede".  This is the URL that I am using
> for the plugin:
> http://www.scala-lang.org/downloads/distrib/files/nightly/scala.update/
>
> When I try to debug my program I get the following error message:
> ERROR - Failed to Boot
> java.lang.VerifyError: class liftBasic.gid.model.User$ overrides final
> method count.()J
>        at java.lang.ClassLoader.defineClass1(Native Method)
>        at java.lang.ClassLoader.defineClass(Unknown Source)
>        at java.security.SecureClassLoader.defineClass(Unknown Source)
>        at java.net.URLClassLoader.defineClass(Unknown Source)
>        at java.net.URLClassLoader.access$000(Unknown Source)
>        at java.net.URLClassLoader$1.run(Unknown Source)
>        at java.security.AccessController.doPrivileged(Native Method)
>        at java.net.URLClassLoader.findClass(Unknown Source)
>        at java.lang.ClassLoader.loadClass(Unknown Source)
>        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
>        at java.lang.ClassLoader.loadClass(Unknown Source)
>        at java.lang.ClassLoader.loadClassInternal(Unknown Source)
>        at bootstrap.liftweb.Boot.boot(Boot.scala:24)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>        at java.lang.reflect.Method.invoke(Unknown Source)
>        at net.liftweb.util.ClassHelpers$$anonfun$createInvoker
> $1.apply(ClassHelpers.scala:343)
>        at net.liftweb.util.ClassHelpers$$anonfun$createInvoker
> $1.apply(ClassHelpers.scala:341)
>        at net.liftweb.http.DefaultBootstrap$$anonfun$boot
> $1.apply(LiftRules.scala:585)
>        at net.liftweb.http.DefaultBootstrap$$anonfun$boot
> $1.apply(LiftRules.scala:585)
>        at net.liftweb.util.Full.map(Can.scala:264)
>        at net.liftweb.http.DefaultBootstrap$.boot(LiftRules.scala:585)
>        at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:442)
>        at net.liftweb.http.LiftFilter.init(LiftServlet.scala:421)
>        at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:
> 97)
>        at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
> 39)
>        at
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:
> 593)
>        at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
>        at
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:
> 1220)
>        at
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:
> 513)
>        at
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:
> 448)
>        at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
> 39)
>        at
> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:
> 130)
>        at org.mortbay.jetty.Server.doStart(Server.java:222)
>        at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
> 39)
>        at RunWebApp$.<init>(RunWebApp.scala:16)
>        at RunWebApp$.<clinit>(RunWebApp.scala)
>        at RunWebApp.main(RunWebApp.scala)
>
> Eclipse doesn't recognize any problems with the code so it should
> build fine, as it used to about a week ago before I updated my plugin
> and my eclipse version.  When I look at the page on the web browser,
> it partially works but where the navigation menu is supposed to be on
> the left side, it just says "No Navigation Defined".
>
> Any ideas on how to get around this problem?
>
> Thanks,
> David
> --
> View this message in context: http://www.nabble.com/more-plugin-problems-tp18223441p18223441.html
> Sent from the Scala - Tools mailing list archive at Nabble.com.
>
>

Rafael de F. Ferreira | 2 Jul 2008 03:58

Re: Re: [scala-user] Poll - Eclipse plugin potentially destabilizing commit

In this spirit, I note that (on my machine) doing a clean build of
scalax using the plugin (both Miles' branch as well as a previous
nightly) completly hangs Eclipse.

On Tue, Jul 1, 2008 at 7:06 AM, Sean McDirmid
<sean.mcdirmid@...> wrote:
> 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 :) ).
>
> Sean
>
> 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
>>
>

--

-- 
Rafael de F. Ferreira.
http://www.rafaelferreira.net/


Gmane