Error in nightly Eclipse plugin

On Fri, Sep 25, 2009 at 9:58 AM, Silvio Bierman
wrote:
> Just updated my nightly and did a clean/build. After starting my application
> goes down with an Exception
>
> java.lang.ClassCastException: [Lnl.idfix.piglet.component.DivComponent;
> cannot be cast to scala.collection.Sequence

Why do you think this is an Eclipse issue?

Cheers,

Miles

Miles Sabin wrote:
>
>
> Why do you think this is an Eclipse issue?
>

Actually I dont. It must be a compiler issue but it is not clear to me how
compiler releases and eclipse plugin releases are related (if at all) and
since it happened after updating the SDT I thought I might start by
reporting it here in the tools section.

I did some more testing and the code

val subs = new Array[DivComponent](10)
println(subs.getClass.getName)

tells me subs is of type DivComponent. I reverted to the 20090919 nightly
and that made it go away.

Since I have noticed progress in the method/field completion area I am quite
eager to keep up, though :-)

Cheers,

Silvio

On Fri, Sep 25, 2009 at 1:25 PM, Silvio Bierman
wrote:
> Actually I dont. It must be a compiler issue but it is not clear to me how
> compiler releases and eclipse plugin releases are related (if at all) and
> since it happened after updating the SDT I thought I might start by
> reporting it here in the tools section.

Nightly builds of the IDE contain the matching nightly build of the
compiler and libraries.

In any case you should always check suspected errors which aren't
clearly IDE-related against the command line tools ... if you don't
then your query or bug report will very likely be misdirected.

> I did some more testing and the code

I suggest you start a new thread on the right list
(scala-user@listes.epfl.ch) with a more appropriate title ... you're
more likely to reach people who will help you with your issue.

Cheers,

Miles

Miles Sabin wrote:
>
> In any case you should always check suspected errors which aren't
> clearly IDE-related against the command line tools ... if you don't
> then your query or bug report will very likely be misdirected.
>
> I suggest you start a new thread on the right list
> (scala-user@listes.epfl.ch) with a more appropriate title ... you're
> more likely to reach people who will help you with your issue.
>

Hello Miles,

Done.

In the meantime I have reverted to the third last SDT build. I would not
mind patching the current one with a working compiler but did not see an
obvious way to do so. Is this possible (and worth the trouble)?

Gr. Silvio

On Sat, Sep 26, 2009 at 1:47 AM, Silvio Bierman
wrote:
> Done.
>
> In the meantime I have reverted to the third last SDT build. I would not
> mind patching the current one with a working compiler but did not see an
> obvious way to do so. Is this possible (and worth the trouble)?

It would be a lot of effort for not very much gain.

I recommend sticking with trunk and investigating temporary
workarounds for the compiler errors you're seeing rather than
reverting to an essentially random snapshot which happens to work for
you.

Cheers,

Miles

Miles Sabin wrote:
>
> I recommend sticking with trunk and investigating temporary
> workarounds for the compiler errors you're seeing rather than
> reverting to an essentially random snapshot which happens to work for
> you.
>

Hello Miles,

I normally would do that but since:

println(new Array[Int](5).getClass.getName)

prints:

[I

this bug is so fundamental that Scala is basically broken. I took out the
first piece of code that failed and the program stumbled perhaps twenty
lines further. This is something I can not work around.

My current codebase is a couple of thousand lines of Scala 2.8.recent code
(using stuff like parameter defaults) and although not working against
deadlines we need to roll out stuff in a couple of weeks. I see no other
option than reverting to a working (for us) snapshot).

That is why I asked about patching the SDT. I would prefer sticking to trunk
for SDT even if an incidental IDE issue might arise as long as my code
works.

Gr. Silvio

On Sun, Sep 27, 2009 at 11:13 AM, Silvio Bierman
wrote:
>
>
>
> Miles Sabin wrote:
>>
>> I recommend sticking with trunk and investigating temporary
>> workarounds for the compiler errors you're seeing rather than
>> reverting to an essentially random snapshot which happens to work for
>> you.
>>
>
> Hello Miles,
>
> I normally would do that but since:
>
> println(new Array[Int](5).getClass.getName)
>
> prints:
>
> [I
>
> this bug is so fundamental that Scala is basically broken.

I don't understand. How is that a bug?

Martin Odersky wrote:
>
> On Sun, Sep 27, 2009 at 11:13 AM, Silvio Bierman
> wrote:
> I don't understand. How is that a bug?
>

You are probably mixing things up here.

On Sun, Sep 27, 2009 at 11:13 AM, Silvio Bierman
wrote:
> I normally would do that but since:
>
> println(new Array[Int](5).getClass.getName)
>
> prints:
>
> [I
What is this supposed to print? The equivalent Java program

class Test{
public static void main(String[] args){
System.out.println(new int[5]);
}
}

prints

[I@8dc8569

which is the same and as expected.

The problem you described in your first post is probably totally
unrelated, since it refers to a static type problem, in particular
that it looks like an array being no valid Sequence any more. This is
probably due to a bug to the still somewhat changing new 2.8
collection API. And that's the problem. You depend on code which still
is in flux. There will be more bugs you might trigger sooner or later.

Your error message says: "The value in front of ':*' has to be of type
Sequence. An Array of DivComponents is no sequence."

While the first part of this statement from the compiler is correct,
the second one obviously isn't. An Array should be a Sequence
actually. That's probably a compiler bug. I think your
misunderstanding stems from the way the signature of an Array of
objects is represented as [L;.

So here are the facts:
* 2.8 is still not finished, it has bugs and some parts of the design
are still changing
* The eclipse plugin nightly depends deeply on the Scala compiler
nightly. Bugs in the compiler/library will be instantly exposed in the
plugin.
* Your particular compiler version has a bug, treating Arrays as
being no Sequence.
* You can file this bug as a bug in the Scala compiler trac. Sooner
or later someone will look at it and fix it. Since you are using the
nightlies, the fix will be delivered to you soon, probably even the
next day after it is fixed.

In conclusion, it is very dangerous to depend on nightly builds for
production code. Particularly, if there is no official release date
for a stable version. Once you jumped and use the nightlies (and it is
good that someone actually does it) there is no way back. Sticking to
an older version helps in the short-term but is no general solution.

Johannes Rudolph-2 wrote:
>
> You are probably mixing things up here.
>

Yes, I know that. I was trying to minimaize the code to reproduce the error,
got a little mixed up and posted too quickly.

Johannes Rudolph-2 wrote:
>
> So here are the facts:
> * 2.8 is still not finished, it has bugs and some parts of the design
> are still changing
> * The eclipse plugin nightly depends deeply on the Scala compiler
> nightly. Bugs in the compiler/library will be instantly exposed in the
> plugin.
> * Your particular compiler version has a bug, treating Arrays as
> being no Sequence.
> * You can file this bug as a bug in the Scala compiler trac. Sooner
> or later someone will look at it and fix it. Since you are using the
> nightlies, the fix will be delivered to you soon, probably even the
> next day after it is fixed.
>
> In conclusion, it is very dangerous to depend on nightly builds for
> production code. Particularly, if there is no official release date
> for a stable version. Once you jumped and use the nightlies (and it is
> good that someone actually does it) there is no way back. Sticking to
> an older version helps in the short-term but is no general solution.
>

Yep, I know I am working on the edge here and accept the consequences. I
also understand that the SDT is tightly connected to the compiler and
therefore delivered combined with one.

I work with the nightlies because I like where 2.8 is going and since we are
just starting with Scala (after about ten years of working Java only) I find
it very unattractive to invest in 2.7 when it about to be superseded, even
if there is no release date set. The differences are so prominent that they
influence API design and it would be a pity to set things in stone that I
would have done differently with 2.8.

As a side effect I will run into bugs and will report them, just to help
with 2.8 development.

My remark about my having to produce something was to explain why I rolled
back to a previous nighty. I do not expect nightlies in general to be
usefull for production work.

Gr. Silvio

On Sun, Sep 27, 2009 at 10:38 AM, Silvio Bierman
wrote:
> The problem is this:
>
> val n = new Array[Int](5)
>
> def foo(i : Int*) = println(i.size)
>
> foo(n:_*)
>
> results in
>
> ClassCastException: [I cannot be cast to scala.collection.Sequence
>
> which breaks much of my code.

That's a bug ... have you created a ticket for it in Trac?

If you're going to continue to work with trunk, I'd still recommend
investigating workarounds rather than sticking with increasingly stale
snapshots. In this case the workaround is,

foo(n.toList:_*)

Assuming you create a ticket you'll be notified when the bug is fixed
and you can then revert to the original code.

Cheers,

Miles

Miles Sabin wrote:
>
> If you're going to continue to work with trunk, I'd still recommend
> investigating workarounds rather than sticking with increasingly stale
> snapshots. In this case the workaround is,
>
> foo(n.toList:_*)
>

Ok, I have done this. I had to make changes in about 10-12 locations so
these should be easy to revert once the repair is available.

Miles Sabin wrote:
>
> Assuming you create a ticket you'll be notified when the bug is fixed
> and you can then revert to the original code.
>

Someone on the scala-user group said he already created a ticket for a
problem that had the same cause so that should not be neccesary.

In general, is it encouraged to register tickets against nightlies? I can
imagine that sometimes code slips into a nightly that is being worked on
quite actively and tickets could then create a lot of noise.

I was under the impression that is was better to discuss issues with
nightlies on the lists.

Gr. Silvio

On Tue, Sep 29, 2009 at 11:01 AM, Silvio Bierman
wrote:
> In general, is it encouraged to register tickets against nightlies? I can
> imagine that sometimes code slips into a nightly that is being worked on
> quite actively and tickets could then create a lot of noise.
>
> I was under the impression that is was better to discuss issues with
> nightlies on the lists.

It doesn't hurt to raise them on the list, but if you're seeing a
regression relative to the current stable release, then it's usually
worth opening a ticket (once you've checked that there isn't already
one covering that issue).

Cheers,

Miles

On Sun, Sep 27, 2009 at 11:38 AM, Silvio Bierman
wrote:
>
>
>
> Martin Odersky wrote:
>>
>> On Sun, Sep 27, 2009 at 11:13 AM, Silvio Bierman
>> wrote:
>> I don't understand. How is that a bug?
>>
>>  -- Martin
>>
>>
>
> Of course it is not a bug. I was a bit too quick with my post, sorry for
> that.
>
> The problem is this:
>
> val n = new Array[Int](5)
>
> def foo(i : Int*) = println(i.size)
>
> foo(n:_*)
>
> results in
>
> ClassCastException: [I cannot be cast to scala.collection.Sequence
>
> which breaks much of my code.
>
OK. This should be fixed now in trunk.

Cheers

On Tue, Sep 29, 2009 at 03:01:46AM -0700, Silvio Bierman wrote:
> In general, is it encouraged to register tickets against nightlies?

Answering for the compiler/library and not the plugin, although I
realize that question was probably about the plugin:

In general, yes. With some exceptions we keep trunk in a state where
the test suite passes, which means if you notice breakage in a nightly
it is probably not adequately covered by the test suite. And since
(again with some exceptions) we don't close tickets without checking in
a regression test, each such ticket helps to pin mr. scala inside the
lines.

Also, a ticket which includes a small self-contained test case which
demonstrates the bug is 10x as helpful as one which does not.

Martin Odersky wrote:
>
> OK. This should be fixed now in trunk.
>

Thanks for the notice.

I just tried the nightly and it is indeed fixed.

Gr. Silvio

Paul Phillips wrote:
>
> On Tue, Sep 29, 2009 at 03:01:46AM -0700, Silvio Bierman wrote:
>> In general, is it encouraged to register tickets against nightlies?
>
> In general, yes. With some exceptions we keep trunk in a state where
> the test suite passes, which means if you notice breakage in a nightly
> it is probably not adequately covered by the test suite. And since
> (again with some exceptions) we don't close tickets without checking in
> a regression test, each such ticket helps to pin mr. scala inside the
> lines.
>
> Also, a ticket which includes a small self-contained test case which
> demonstrates the bug is 10x as helpful as one which does not.
>
>

Understood. I will file tickets from now on, if at all possible accompanied
by test code.

Gr. Silvio