AbstractMethodError after compilation with sbt 0.11.2

[Scott Morrison]

Hi all,

I have a project for which "sbt test" crashes with an AbstractMethodError. Tweaking the whitespace and running "sbt test" again succeeds. I'm not absolutely sure that this is a problem with sbt vs. the scala compiler, but I'm hoping someone here can help me.

Steps to reproduce:

----------------------------------------

1) Download the code and run the tests:

hg clone -r cc4c0dc0a2d9 https://bitbucket.org/categoricaldata/categoricaldata
cd categoricaldata
./sbt test

which produces an AbstractMethodError in withLocallyFinitelyGeneratedSource, which is implemented in net.categoricaldata.category.functor.withFinitelyGeneratedSource.withFinitelyGeneratedTarget$CosliceFunctor$CosliceFunctorOver$F.

2) Add some whitespace to the critical file, via

echo >> src/main/scala/net/categoricaldata/category/functor/withFinitelyGeneratedSource/withFinitelyGeneratedTarget.scala 

Run the tests again

./sbt test

and we no longer get an AbstractMethodError (the tests fail some other way, that's fine for now).

----------------------------------------

We can investigate the critical file via

scalap -cp target/scala-2.9.2-RC2/classes/  "net.categoricaldata.category.functor.withFinitelyGeneratedSource.withFinitelyGeneratedTarget\$CosliceFunctor\$CosliceFunctorOver\$F"

The output after the first compilation is here, and after the second compilation is here. The only difference is one line gets added: 

  def onGenerators(scala.Any): scala.Any;

I don't understand enough about the scala compiler (especially in regards abstract member types) to understand the significance of the change in output from scalap. I'm very happy to investigate further, especially if someone can point me in the right direction. Unfortunately at this point I don't really know what to do to diagnose whether this is an sbt problem or a scala problem. Any advice very much appreciated!

best regards,

Scott Morrison

(ps --- I posted previously about this issue over at scala-user, but didn't get much response.)

[Scott Morrison]

Hi everyone,

I'm now pretty certain that this is an sbt problem, not a scala
compiler problem. Using the scala plugin for eclipse, I can generate
this AbstractMethodError by running the test
net.categoricaldata.category.LeftPushforwardTest. If I change the
build manager under the scala compiler settings from "sbt" to
"refined", the problem vanishes.

Should I file a bug report?

I think I can work around this problem for now (sbt compile, touch the
critical file, then sbt test), but it's pretty painful. Any other
recommended workarounds would be very much appreciated.

best,
Scott Morrison

[Josh Suereth]

I would file a bug, but I'm really curious about this now...

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.

[Mark Harrah]

On Thu, 12 Apr 2012 08:36:45 -0400
Josh Suereth <joshua....@gmail.com> wrote:

> I would file a bug, but I'm really curious about this now...

It would be rather strange for sbt to cause an AbstractMethodError on a clean compile. An incremental compile I could understand, but a fresh compile is strange. I can reproduce it, but it is a rather large test case and I won't have time in the near future to narrow it down to see if it is sbt or scalac. That it works in Eclipse doesn't necessarily mean it is sbt's fault as the issue could just be triggered by the ordering of source files or something like that. (This has happened before. It is a good initial check to compare with Eclipse, though.)

I see that you have compiled against 2.10.0-M2 at some point. Do you see the problem with that version as well?

-Mark

[Scott Morrison]

Hi Mark and Josh,

thanks for having a look. The same problem occurs with scala 2.10.0-M2 (again compiling under sbt 0.11.2).

I've created a branch of our project in which I cut out everything extraneous I could; it's at "hg clone -r 76b788f5f923 https://bitbucket.org/categoricaldata/categoricaldata". Unfortunately the test case is still rather large. It's doing some complicated mathematics [1] and all the very many "simpler" things that our code is doing seems to work just fine! This means I don't really know where to start producing a simpler test case. I've done some elementary code coverage, and there aren't any obvious things I can cut out of this branch.

In the meantime, can anyone think of a hack to insist that whenever sbt tries to compile, it does "compile, touch a certain file, compile"? That would at least get us back to the point we can continue development, even if it doesn't help hunt down the lurking horror.

best regards,

Scott

[1] Hold on to your hat: Checking if two functors i and j from a finitely presented category C to FinSet (finite sets) are isomorphic, where the functor i is obtained as i = F_!(k), where F: D --> C is a functor from some other finitely presented category D, and F_! denotes the left adjoint of the pullback functor F_* : C-Sets --> D-Sets, and k is some functor from D to FinSet. We're checking this isomorphism by preparing a certain auxiliary functor H(i,j) : M --> FinSet and computing the limit of H(i,j). Kawow!

[Scott Morrison]

Argh, my mistake, the cut down branch of the project I created is
revision b5fd18c96b58.