Re: scala enumerations not importing in 2.8

I switch to the Sun JVM, but still get those two problems:

1) 'ant compile' hits errors (like the PolygonMode) if I don't run
'ant clean' first every time
2) The file reading code seems to produce errors in the OpenGL library
I didn't see before, so I'm assuming something minor changed there
between 2.7 and 2.8. Would there be any reason the following code my
have changed from 2.7? I use similar code for loading icons, so I'm
wondering if it's something to do with changes with Source.

val fragFile = name + ".frag"
val fragUrl = this.getClass().getResource(fragFile)
val fragSource = Source.fromURL(fragUrl).getLines.toList.toArray
val fragLengths = fragSource.map(line => line.length)

On Sun, Aug 22, 2010 at 9:31 AM, Anthony Accioly wrote:
> Stratton,
> Could you try installing the Sun JVM? OpenJDK has several quirks and
> incompatibilities with the official JVM that are still work in progress. If
> that don't help I would start checking the ant script, file permissions and
> folder / package structure.
> Here is a link that might
> help http://blog.mansonthomas.com/2010/05/ubuntu-1004-install-and-set-sun-jdk-as.html.
>
> On Sun, Aug 22, 2010 at 2:40 AM, Josh Stratton
> wrote:
>>
>> val vertUrl = this.getClass().getResource(vertFile)
>>          val vertSource = Source.fromURL(vertUrl).getLines.toList.toArray
>>          val vertLengths = vertSource.map(line => line.length)
>>
>> [...]
>> #
>> #  Internal Error (nmethod.cpp:1847), pid=9097, tid=3078646640
>> #  Error: guarantee(cont_offset != 0,"unhandled implicit exception in
>> compiled code")
>> #
>> # JRE version: 6.0_18-b18
>> # Java VM: OpenJDK Server VM (16.0-b13 mixed mode linux-x86 )
>> # Derivative: IcedTea6 1.8.1
>> # Distribution: Ubuntu 10.04 LTS, package 6b18-1.8.1-0ubuntu1
>> # An error report file with more information is saved as:
>> # /home/stratton/josh_projects/potassium/hs_err_pid9097.log
>
>
> --
> Anthony Accioly
>

Stratton,
No clue about (1). Maybe force="true" in the scalac ant task to force code recompilation? Or maybe you are having a package structure / file permission problem as I suggested before (javac or copy tasks may be replacing some scalac compiled classes, or maybe you are even experiencing a cross-compilation bug, but I wouldn't jump the gun in that sense). I noticed two other things about your compile target. It seems to be copying scala source files to the build directory (you are just excluding java files), and it its calling the task <jar> to build a jar file in the "./build" directory. I would recommend neither (modify the run target to include class files, exclude that <jar> task from the compile target, and take a look at what the copy task is really doing).
About (2), nothing is jumping to my eyes about that code. But if you are suspicious about Source.getLines, why don't you print the contents of fragSource / fragLengths with println(fragSource.mkString("\n")) and check the output?
Cheers

On Sun, Aug 22, 2010 at 7:15 PM, Josh Stratton <strattonbrazil@gmail.com> wrote:

I switch to the Sun JVM, but still get those two problems:

1) 'ant compile' hits errors (like the PolygonMode) if I don't run
'ant clean' first every time
2) The file reading code seems to produce errors in the OpenGL library
I didn't see before, so I'm assuming something minor changed there
between 2.7 and 2.8.  Would there be any reason the following code my
have changed from 2.7?  I use similar code for loading icons, so I'm
wondering if it's something to do with changes with Source.

         val fragFile = name + ".frag"
         val fragUrl = this.getClass().getResource(fragFile)
         val fragSource = Source.fromURL(fragUrl).getLines.toList.toArray
         val fragLengths = fragSource.map(line => line.length)

--
Anthony Accioly

> No clue about (1). Maybe force="true" in the scalac ant task to force code
> recompilation? Or maybe you are having a package structure / file permission
> problem as I suggested before (javac or copy tasks may be replacing some
> scalac compiled classes, or maybe you are even experiencing a
> cross-compilation bug, but I wouldn't jump the gun in that sense).
> I noticed two other things about your compile target. It seems to be copying
> scala source files to the build directory (you are just excluding java
> files), and it its calling the task to build a jar file in the
> "./build" directory. I would recommend neither (modify the run target to
> include class files, exclude that task from the compile target, and
> take a look at what the copy task is really doing).
> About (2), nothing is jumping to my eyes about that code. But if you
> are suspicious about Source.getLines, why don't you print the contents of
> fragSource / fragLengths with println(fragSource.mkString("\n")) and check
> the output?
> Cheers

I'm guessing the ant script needs to be cleaned up quite a bit as I
was just learning it when I threw it together. I thought it was
working well enough in 2.7 though. Maybe 2.8 just didn't like the
things I was getting away with. I'll look into your suggestions.

I've output the data and it looks okay to me. I don't know if there
are any subtle differences. I'll keep plugging away that. Maybe
newlines aren't read in anymore and need to be there? I'm sure I'll
be able to figure it out soon enough.

Thanks everyone.

>
> On Sun, Aug 22, 2010 at 7:15 PM, Josh Stratton
> wrote:
>>
>> I switch to the Sun JVM, but still get those two problems:
>>
>> 1) 'ant compile' hits errors (like the PolygonMode) if I don't run
>> 'ant clean' first every time
>> 2) The file reading code seems to produce errors in the OpenGL library
>> I didn't see before, so I'm assuming something minor changed there
>> between 2.7 and 2.8.  Would there be any reason the following code my
>> have changed from 2.7?  I use similar code for loading icons, so I'm
>> wondering if it's something to do with changes with Source.
>>
>>          val fragFile = name + ".frag"
>>          val fragUrl = this.getClass().getResource(fragFile)
>>          val fragSource = Source.fromURL(fragUrl).getLines.toList.toArray
>>          val fragLengths = fragSource.map(line => line.length)
>>
>
>
> --
> Anthony Accioly
>

Looking at the docs of Source between 2.7 and 2.8, it seems getLines
does indeed no longer include the end-line, which OpenGL didn't like.
I added a mapping to tack it on and it seems to work fine again.

val fragSource = Source.fromURL(fragUrl).getLines.toList.toArray
val fragSource = Source.fromURL(fragUrl).getLines.map(line
=> line + "\n").toList.toArray

On Sun, Aug 22, 2010 at 7:26 PM, Josh Stratton wrote:
>> No clue about (1). Maybe force="true" in the scalac ant task to force code
>> recompilation? Or maybe you are having a package structure / file permission
>> problem as I suggested before (javac or copy tasks may be replacing some
>> scalac compiled classes, or maybe you are even experiencing a
>> cross-compilation bug, but I wouldn't jump the gun in that sense).
>> I noticed two other things about your compile target. It seems to be copying
>> scala source files to the build directory (you are just excluding java
>> files), and it its calling the task to build a jar file in the
>> "./build" directory. I would recommend neither (modify the run target to
>> include class files, exclude that task from the compile target, and
>> take a look at what the copy task is really doing).
>> About (2), nothing is jumping to my eyes about that code. But if you
>> are suspicious about Source.getLines, why don't you print the contents of
>> fragSource / fragLengths with println(fragSource.mkString("\n")) and check
>> the output?
>> Cheers
>
> I'm guessing the ant script needs to be cleaned up quite a bit as I
> was just learning it when I threw it together.  I thought it was
> working well enough in 2.7 though.  Maybe 2.8 just didn't like the
> things I was getting away with.  I'll look into your suggestions.
>
> I've output the data and it looks okay to me.  I don't know if there
> are any subtle differences.  I'll keep plugging away that.  Maybe
> newlines aren't read in anymore and need to be there?  I'm sure I'll
> be able to figure it out soon enough.
>
> Thanks everyone.
>
>>
>> On Sun, Aug 22, 2010 at 7:15 PM, Josh Stratton
>> wrote:
>>>
>>> I switch to the Sun JVM, but still get those two problems:
>>>
>>> 1) 'ant compile' hits errors (like the PolygonMode) if I don't run
>>> 'ant clean' first every time
>>> 2) The file reading code seems to produce errors in the OpenGL library
>>> I didn't see before, so I'm assuming something minor changed there
>>> between 2.7 and 2.8.  Would there be any reason the following code my
>>> have changed from 2.7?  I use similar code for loading icons, so I'm
>>> wondering if it's something to do with changes with Source.
>>>
>>>          val fragFile = name + ".frag"
>>>          val fragUrl = this.getClass().getResource(fragFile)
>>>          val fragSource = Source.fromURL(fragUrl).getLines.toList.toArray
>>>          val fragLengths = fragSource.map(line => line.length)
>>>
>>
>>
>> --
>> Anthony Accioly
>>
>

One clue might be related to these files. When I do a compile, it
grabs all the scala files. However, doing a second compile, it only
grabs a handful of files (one containing the enumeration I was having
difficulty with).

Compiling source files: com/googlecode/copper/panel/Popup.scala,
com/googlecode/copper/select/Select.scala,
com/googlecode/copper/tools/FaceScale.scala,
com/googlecode/copper/tools/Tool.scala,
com/googlecode/copper/work/Work.scala

The file permissions on these files seem the same as the surrounding files:

-rw-r--r-- 1 stratton stratton 1186 2010-08-22 19:56
./src/com/googlecode/copper/work/Work.scala

Why would only these files be targeted? The Select.scala file, for
example, only has a trait and an object in it. I found that moving
them to separate files I still get an error for PolygonMode, but the
following errors are completely different for unrelated scala classes.

On Sun, Aug 22, 2010 at 7:34 PM, Josh Stratton wrote:
> Looking at the docs of Source between 2.7 and 2.8, it seems getLines
> does indeed no longer include the end-line, which OpenGL didn't like.
> I added a mapping to tack it on and it seems to work fine again.
>
>          val fragSource = Source.fromURL(fragUrl).getLines.toList.toArray
>          val fragSource = Source.fromURL(fragUrl).getLines.map(line
> => line + "\n").toList.toArray
>
>
> On Sun, Aug 22, 2010 at 7:26 PM, Josh Stratton wrote:
>>> No clue about (1). Maybe force="true" in the scalac ant task to force code
>>> recompilation? Or maybe you are having a package structure / file permission
>>> problem as I suggested before (javac or copy tasks may be replacing some
>>> scalac compiled classes, or maybe you are even experiencing a
>>> cross-compilation bug, but I wouldn't jump the gun in that sense).
>>> I noticed two other things about your compile target. It seems to be copying
>>> scala source files to the build directory (you are just excluding java
>>> files), and it its calling the task to build a jar file in the
>>> "./build" directory. I would recommend neither (modify the run target to
>>> include class files, exclude that task from the compile target, and
>>> take a look at what the copy task is really doing).
>>> About (2), nothing is jumping to my eyes about that code. But if you
>>> are suspicious about Source.getLines, why don't you print the contents of
>>> fragSource / fragLengths with println(fragSource.mkString("\n")) and check
>>> the output?
>>> Cheers
>>
>> I'm guessing the ant script needs to be cleaned up quite a bit as I
>> was just learning it when I threw it together.  I thought it was
>> working well enough in 2.7 though.  Maybe 2.8 just didn't like the
>> things I was getting away with.  I'll look into your suggestions.
>>
>> I've output the data and it looks okay to me.  I don't know if there
>> are any subtle differences.  I'll keep plugging away that.  Maybe
>> newlines aren't read in anymore and need to be there?  I'm sure I'll
>> be able to figure it out soon enough.
>>
>> Thanks everyone.
>>
>>>
>>> On Sun, Aug 22, 2010 at 7:15 PM, Josh Stratton
>>> wrote:
>>>>
>>>> I switch to the Sun JVM, but still get those two problems:
>>>>
>>>> 1) 'ant compile' hits errors (like the PolygonMode) if I don't run
>>>> 'ant clean' first every time
>>>> 2) The file reading code seems to produce errors in the OpenGL library
>>>> I didn't see before, so I'm assuming something minor changed there
>>>> between 2.7 and 2.8.  Would there be any reason the following code my
>>>> have changed from 2.7?  I use similar code for loading icons, so I'm
>>>> wondering if it's something to do with changes with Source.
>>>>
>>>>          val fragFile = name + ".frag"
>>>>          val fragUrl = this.getClass().getResource(fragFile)
>>>>          val fragSource = Source.fromURL(fragUrl).getLines.toList.toArray
>>>>          val fragLengths = fragSource.map(line => line.length)
>>>>
>>>
>>>
>>> --
>>> Anthony Accioly
>>>
>>
>

Strangely when I change the scalac task to fsc, the problem goes away
and everything compiles fine. I still get those five or so files
recompiling everything, but it's compiling. Weird. I can live with
that, though.

Another new issue switching to 2.8 seems to be my use of math
functions. Everything compiles fine, but I get a lot of these errors
at runtime. Usually around using something like Math.Pi or Math.max.
Switching to the scala version scala.math.max or scala.math.Pi seems
to also compile fine, but give the same error.

Exception in thread "AWT-EventQueue-0"
java.lang.IncompatibleClassChangeError: Found class scala.MathCommon,
but interface was expected

On Sun, Aug 22, 2010 at 8:10 PM, Josh Stratton wrote:
> One clue might be related to these files.  When I do a compile, it
> grabs all the scala files.  However, doing a second compile, it only
> grabs a handful of files (one containing the enumeration I was having
> difficulty with).
>
> Compiling source files: com/googlecode/copper/panel/Popup.scala,
> com/googlecode/copper/select/Select.scala,
> com/googlecode/copper/tools/FaceScale.scala,
> com/googlecode/copper/tools/Tool.scala,
> com/googlecode/copper/work/Work.scala
>
> The file permissions on these files seem the same as the surrounding files:
>
> -rw-r--r-- 1 stratton stratton 1186 2010-08-22 19:56
> ./src/com/googlecode/copper/work/Work.scala
>
> Why would only these files be targeted?  The Select.scala file, for
> example, only has a trait and an object in it.  I found that moving
> them to separate files I still get an error for PolygonMode, but the
> following errors are completely different for unrelated scala classes.
>
> On Sun, Aug 22, 2010 at 7:34 PM, Josh Stratton wrote:
>> Looking at the docs of Source between 2.7 and 2.8, it seems getLines
>> does indeed no longer include the end-line, which OpenGL didn't like.
>> I added a mapping to tack it on and it seems to work fine again.
>>
>>          val fragSource = Source.fromURL(fragUrl).getLines.toList.toArray
>>          val fragSource = Source.fromURL(fragUrl).getLines.map(line
>> => line + "\n").toList.toArray
>>
>>
>> On Sun, Aug 22, 2010 at 7:26 PM, Josh Stratton wrote:
>>>> No clue about (1). Maybe force="true" in the scalac ant task to force code
>>>> recompilation? Or maybe you are having a package structure / file permission
>>>> problem as I suggested before (javac or copy tasks may be replacing some
>>>> scalac compiled classes, or maybe you are even experiencing a
>>>> cross-compilation bug, but I wouldn't jump the gun in that sense).
>>>> I noticed two other things about your compile target. It seems to be copying
>>>> scala source files to the build directory (you are just excluding java
>>>> files), and it its calling the task to build a jar file in the
>>>> "./build" directory. I would recommend neither (modify the run target to
>>>> include class files, exclude that task from the compile target, and
>>>> take a look at what the copy task is really doing).
>>>> About (2), nothing is jumping to my eyes about that code. But if you
>>>> are suspicious about Source.getLines, why don't you print the contents of
>>>> fragSource / fragLengths with println(fragSource.mkString("\n")) and check
>>>> the output?
>>>> Cheers
>>>
>>> I'm guessing the ant script needs to be cleaned up quite a bit as I
>>> was just learning it when I threw it together.  I thought it was
>>> working well enough in 2.7 though.  Maybe 2.8 just didn't like the
>>> things I was getting away with.  I'll look into your suggestions.
>>>
>>> I've output the data and it looks okay to me.  I don't know if there
>>> are any subtle differences.  I'll keep plugging away that.  Maybe
>>> newlines aren't read in anymore and need to be there?  I'm sure I'll
>>> be able to figure it out soon enough.
>>>
>>> Thanks everyone.
>>>
>>>>
>>>> On Sun, Aug 22, 2010 at 7:15 PM, Josh Stratton
>>>> wrote:
>>>>>
>>>>> I switch to the Sun JVM, but still get those two problems:
>>>>>
>>>>> 1) 'ant compile' hits errors (like the PolygonMode) if I don't run
>>>>> 'ant clean' first every time
>>>>> 2) The file reading code seems to produce errors in the OpenGL library
>>>>> I didn't see before, so I'm assuming something minor changed there
>>>>> between 2.7 and 2.8.  Would there be any reason the following code my
>>>>> have changed from 2.7?  I use similar code for loading icons, so I'm
>>>>> wondering if it's something to do with changes with Source.
>>>>>
>>>>>          val fragFile = name + ".frag"
>>>>>          val fragUrl = this.getClass().getResource(fragFile)
>>>>>          val fragSource = Source.fromURL(fragUrl).getLines.toList.toArray
>>>>>          val fragLengths = fragSource.map(line => line.length)
>>>>>
>>>>
>>>>
>>>> --
>>>> Anthony Accioly
>>>>
>>>
>>
>

Stratton,
Glad you solved 2 of 3 :D.If you are not using force="true", the task will do partial compilations targeting modified files  (check http://www.scala-lang.org/node/98). This is the expected behavior, since you don't want to recompile every class every time you build. But if you're calling compile two times in a row (without modifying the files) and they are getting recompiled, then you are close to the source of the problem... Are there java classes with the same qualified name than those in your project? Or maybe the ant copy target is overwriting those files somehow. Try setting force="true", and fixing the call to the copy task, see if it helps.
Cheers,

On Mon, Aug 23, 2010 at 12:10 AM, Josh Stratton <strattonbrazil@gmail.com> wrote:

Why would only these files be targeted?  The Select.scala file, for
example, only has a trait and an object in it.  I found that moving
them to separate files I still get an error for PolygonMode, but the
following errors are completely different for unrelated scala classes.

--
Anthony Accioly

Stratton,
You are suffering from binary incompatibility (http://stackoverflow.com/questions/1980452/what-causes-java-lang-incompatibleclasschangeerror). If you do a full clean + rebuild and make sure you are using the same libs to compile and run the code it should be fixed.

On Mon, Aug 23, 2010 at 12:31 AM, Josh Stratton <strattonbrazil@gmail.com> wrote:

Exception in thread "AWT-EventQueue-0"
java.lang.IncompatibleClassChangeError: Found class scala.MathCommon,
but interface was expected

--
Anthony Accioly

Doing a full clean and rebuild doesn't seem to help. Does it have
anything to do with some of my java files using the java math libs?

Exception in thread "AWT-EventQueue-0"
java.lang.IncompatibleClassChangeError: Found class scala.MathCommon,
but interface was expected

On Sun, Aug 22, 2010 at 9:19 PM, Anthony Accioly wrote:
> Stratton,
> You are suffering from binary incompatibility
> (http://stackoverflow.com/questions/1980452/what-causes-java-lang-incompa...).
> If you do a full clean + rebuild and make sure you are using the same libs
> to compile and run the code it should be fixed.
>
> On Mon, Aug 23, 2010 at 12:31 AM, Josh Stratton
> wrote:
>>
>> Exception in thread "AWT-EventQueue-0"
>> java.lang.IncompatibleClassChangeError: Found class scala.MathCommon,
>> but interface was expected
>
>
> --
> Anthony Accioly
>

On Tue, Aug 31, 2010 at 07:16:12PM -0700, Josh Stratton wrote:
> Doing a full clean and rebuild doesn't seem to help. Does it have
> anything to do with some of my java files using the java math libs?
>
> Exception in thread "AWT-EventQueue-0"
> java.lang.IncompatibleClassChangeError: Found class scala.MathCommon,
> but interface was expected

It is most likely pre-2.8.0 bytecode turning up from somewhere.
MathCommon changed from trait to abstract class between RC2 and RC3.

How would I get around that? I pulled down the latest version of
scala 2.8.0 (the tgz) and am using the four jar files. I don't have
any class files anywhere in my project, so I think it's clean.

I had scala 2.8 (an earlier build) on the command-line, which might
have interfered, so I removed it. That seems to have gotten rid of
the runtime error, but now I don't have fsc, so my compiles fail on a
non-clean build every time with the enumeration error I had
previously. Do I need to do something in ant to setup my SCALA_HOME
envir? I don't have scala installed anymore, so I don't have the bin
directory with the actual fsc script. Can I just set it up to run
through the jars that come with the 2.8.0 package?

The fsc error:

[fsc] Cannot start compilation daemon.
[fsc] tried command: List(scala, scala.tools.nsc.CompileServer)
[fsc] java.lang.Exception: fsc failure

On Tue, Aug 31, 2010 at 7:50 PM, Paul Phillips wrote:
> On Tue, Aug 31, 2010 at 07:16:12PM -0700, Josh Stratton wrote:
>> Doing a full clean and rebuild doesn't seem to help.  Does it have
>> anything to do with some of my java files using the java math libs?
>>
>> Exception in thread "AWT-EventQueue-0"
>> java.lang.IncompatibleClassChangeError: Found class scala.MathCommon,
>> but interface was expected
>
> It is most likely pre-2.8.0 bytecode turning up from somewhere.
> MathCommon changed from trait to abstract class between RC2 and RC3.
>
> --
> Paul Phillips      | These are the climbs that apply men's soles.
> Future Perfect     |
> Empiricist         |
> up hill, pi pals!  |----------* http://www.improving.org/paulp/ *----------
>

On Tue, Aug 31, 2010 at 09:09:42PM -0700, Josh Stratton wrote:
> I had scala 2.8 (an earlier build) on the command-line, which might
> have interfered, so I removed it. That seems to have gotten rid of
> the runtime error, but now I don't have fsc, so my compiles fail on a
> non-clean build every time with the enumeration error I had
> previously. Do I need to do something in ant to setup my SCALA_HOME
> envir? I don't have scala installed anymore, so I don't have the bin
> directory with the actual fsc script. Can I just set it up to run
> through the jars that come with the 2.8.0 package?

Builds are fiddly beasts, I can't give you precise answers. The thing
with the enumeration building from clean but not incrementally sounds
like a candidate for compiler bug. You don't need to set SCALA_HOME,
but you probably need other setup which the fsc script does. Being
dependent on fsc is pretty suboptimal. Have you looked into sbt yet?
I'm sure it gets tiresome when something isn't working and people
suggest introducing even more unknowns, but sbt is miles ahead when it
comes to building. You could look at it as an opportunity.

And if you can't shake the enumeration error please report it.

> Builds are fiddly beasts, I can't give you precise answers.  The thing
> with the enumeration building from clean but not incrementally sounds
> like a candidate for compiler bug.  You don't need to set SCALA_HOME,
> but you probably need other setup which the fsc script does.  Being
> dependent on fsc is pretty suboptimal.  Have you looked into sbt yet?
> I'm sure it gets tiresome when something isn't working and people
> suggest introducing even more unknowns, but sbt is miles ahead when it
> comes to building.  You could look at it as an opportunity.

I guess I might as well take the plunge. Does it support the
functionality of jarjar?

> And if you can't shake the enumeration error please report it.

I reported it. I'll try this week to break it down to a smaller
reproduceable case.

https://lampsvn.epfl.ch/trac/scala/ticket/3817

Switching to sbt seems to have fixed the enumeration issue, but I seem
to be hitting problems left and right trying to do simple tasks like
moving resources to the path. I've found the 'copy-resources' action
to move my resources directory over, but according to the docs this
should be automatic when calling 'package', while it isn't in my jar
file unless I call 'copy-resources' beforehand. Also, the
documentation seems really sparse for things like forking a JVM while
specifying a new java.library.path. I've tried forking the JVM, but
then I hit errors like "java.lang.RuntimeException: Scala jars not
specified". I don't see anything talking about that in the docs and I
certainly can't be the only person running a ForkScalaRun instance.

override def fork = Some(new ForkScalaRun {
val newPath = System.getProperty("java.library.path") + nativeJOGL
override def runJVMOptions = super.runJVMOptions ++
Seq("-Djava.library.path=" + newPath)
})

I've tried the sbt google group, but it seems to be very low traffic.
It's a shame as sbt seems to have some really cool features compared
to ant. I think the default compile task works fine, but I can't seem
to get run or package working as the docs explain. Has anyone done
something similar with their sbt project?

On Wed, Sep 1, 2010 at 8:55 AM, Josh Stratton wrote:
>> Builds are fiddly beasts, I can't give you precise answers.  The thing
>> with the enumeration building from clean but not incrementally sounds
>> like a candidate for compiler bug.  You don't need to set SCALA_HOME,
>> but you probably need other setup which the fsc script does.  Being
>> dependent on fsc is pretty suboptimal.  Have you looked into sbt yet?
>> I'm sure it gets tiresome when something isn't working and people
>> suggest introducing even more unknowns, but sbt is miles ahead when it
>> comes to building.  You could look at it as an opportunity.
>
> I guess I might as well take the plunge.  Does it support the
> functionality of jarjar?
>
>> And if you can't shake the enumeration error please report it.
>
> I reported it.  I'll try this week to break it down to a smaller
> reproduceable case.
>
> https://lampsvn.epfl.ch/trac/scala/ticket/3817
>

Either construct the new instance of ForkScalaRun with the factory
method forkRun [1], or do as it does and override
ForkScalaRun#scalaJars appropriately

val si = buildScalaInstance
val fsr = new ForkScalaRun {
override def scalaJars = si.libraryJar :: si.compilerJar :: Nil
// ..
}

-jason

[1] http://github.com/harrah/xsbt/blob/1ca63f3d06440c77512ccd76d0d4be0a247ad...

On Fri, Sep 10, 2010 at 5:39 AM, Josh Stratton wrote:
>Also, the documentation seems really sparse for things like forking a JVM while
> specifying a new java.library.path.  I've tried forking the JVM, but
> then I hit errors like "java.lang.RuntimeException: Scala jars not
> specified".  I don't see anything talking about that in the docs and I
> certainly can't be the only person running a ForkScalaRun instance.
>
> override def fork = Some(new ForkScalaRun {
>     val newPath = System.getProperty("java.library.path")  + nativeJOGL
>      override def runJVMOptions = super.runJVMOptions ++
> Seq("-Djava.library.path=" + newPath)
>    })
>
> I've tried the sbt google group, but it seems to be very low traffic.
> It's a shame as sbt seems to have some really cool features compared
> to ant.  I think the default compile task works fine, but I can't seem
> to get run or package working as the docs explain.  Has anyone done
> something similar with their sbt project?
>
> On Wed, Sep 1, 2010 at 8:55 AM, Josh Stratton wrote:
>>> Builds are fiddly beasts, I can't give you precise answers.  The thing
>>> with the enumeration building from clean but not incrementally sounds
>>> like a candidate for compiler bug.  You don't need to set SCALA_HOME,
>>> but you probably need other setup which the fsc script does.  Being
>>> dependent on fsc is pretty suboptimal.  Have you looked into sbt yet?
>>> I'm sure it gets tiresome when something isn't working and people
>>> suggest introducing even more unknowns, but sbt is miles ahead when it
>>> comes to building.  You could look at it as an opportunity.
>>
>> I guess I might as well take the plunge.  Does it support the
>> functionality of jarjar?
>>
>>> And if you can't shake the enumeration error please report it.
>>
>> I reported it.  I'll try this week to break it down to a smaller
>> reproduceable case.
>>
>> https://lampsvn.epfl.ch/trac/scala/ticket/3817
>>
>

On Thursday, September 09, 2010 11:39:35 pm Josh Stratton wrote:
> Switching to sbt seems to have fixed the enumeration issue, but I seem
> to be hitting problems left and right trying to do simple tasks like
> moving resources to the path. I've found the 'copy-resources' action
> to move my resources directory over, but according to the docs this
> should be automatic when calling 'package', while it isn't in my jar
> file unless I call 'copy-resources' beforehand. Also, the
> documentation seems really sparse for things like forking a JVM while
> specifying a new java.library.path. I've tried forking the JVM, but
> then I hit errors like "java.lang.RuntimeException: Scala jars not
> specified". I don't see anything talking about that in the docs and I
> certainly can't be the only person running a ForkScalaRun instance.

[1] seems to cover it. There is a comment on the page discussing that error
message as well.

-Mark

[1] http://code.google.com/p/simple-build-tool/wiki/Forking

> override def fork = Some(new ForkScalaRun {
> val newPath = System.getProperty("java.library.path") + nativeJOGL
> override def runJVMOptions = super.runJVMOptions ++
> Seq("-Djava.library.path=" + newPath)
> })
>
> I've tried the sbt google group, but it seems to be very low traffic.
> It's a shame as sbt seems to have some really cool features compared
> to ant. I think the default compile task works fine, but I can't seem
> to get run or package working as the docs explain. Has anyone done
> something similar with their sbt project?
>
> On Wed, Sep 1, 2010 at 8:55 AM, Josh Stratton
wrote:
> >> Builds are fiddly beasts, I can't give you precise answers. The thing
> >> with the enumeration building from clean but not incrementally sounds
> >> like a candidate for compiler bug. You don't need to set SCALA_HOME,
> >> but you probably need other setup which the fsc script does. Being
> >> dependent on fsc is pretty suboptimal. Have you looked into sbt yet?
> >> I'm sure it gets tiresome when something isn't working and people
> >> suggest introducing even more unknowns, but sbt is miles ahead when it
> >> comes to building. You could look at it as an opportunity.
> >
> > I guess I might as well take the plunge. Does it support the
> > functionality of jarjar?
> >
> >> And if you can't shake the enumeration error please report it.
> >
> > I reported it. I'll try this week to break it down to a smaller
> > reproduceable case.
> >
> > https://lampsvn.epfl.ch/trac/scala/ticket/3817

> [1] seems to cover it.  There is a comment on the page discussing that error
> message as well.

I'm familiar with the page, but not the syntax. I'll have to try
again this weekend. As for the comment, I have seen it, but didn't
understand how to integrate it. His/her followup comment recommends
using the Basics section unless one knows what they're doing, which I
obviously do not. :)

I'll try something like this...

def forkConfiguration = new ForkScalaRun { def runJVMOptions:
Seq[String] = ... }
override def fork = Some(forkConfiguration)

>
> -Mark
>
> [1] http://code.google.com/p/simple-build-tool/wiki/Forking
>
>> override def fork = Some(new ForkScalaRun {
>>      val newPath = System.getProperty("java.library.path")  + nativeJOGL
>>       override def runJVMOptions = super.runJVMOptions ++
>> Seq("-Djava.library.path=" + newPath)
>>     })
>>
>> I've tried the sbt google group, but it seems to be very low traffic.
>> It's a shame as sbt seems to have some really cool features compared
>> to ant.  I think the default compile task works fine, but I can't seem
>> to get run or package working as the docs explain.  Has anyone done
>> something similar with their sbt project?
>>
>> On Wed, Sep 1, 2010 at 8:55 AM, Josh Stratton
> wrote:
>> >> Builds are fiddly beasts, I can't give you precise answers.  The thing
>> >> with the enumeration building from clean but not incrementally sounds
>> >> like a candidate for compiler bug.  You don't need to set SCALA_HOME,
>> >> but you probably need other setup which the fsc script does.  Being
>> >> dependent on fsc is pretty suboptimal.  Have you looked into sbt yet?
>> >> I'm sure it gets tiresome when something isn't working and people
>> >> suggest introducing even more unknowns, but sbt is miles ahead when it
>> >> comes to building.  You could look at it as an opportunity.
>> >
>> > I guess I might as well take the plunge.  Does it support the
>> > functionality of jarjar?
>> >
>> >> And if you can't shake the enumeration error please report it.
>> >
>> > I reported it.  I'll try this week to break it down to a smaller
>> > reproduceable case.
>> >
>> > https://lampsvn.epfl.ch/trac/scala/ticket/3817
>

On Friday, September 10, 2010 10:32:24 am Josh Stratton wrote:
> > [1] seems to cover it. There is a comment on the page discussing that
> > error message as well.
>
> I'm familiar with the page, but not the syntax. I'll have to try
> again this weekend. As for the comment, I have seen it, but didn't
> understand how to integrate it. His/her followup comment recommends
> using the Basics section unless one knows what they're doing, which I
> obviously do not. :)
>
> I'll try something like this...
>
> def forkConfiguration = new ForkScalaRun { def runJVMOptions:
> Seq[String] = ... }
> override def fork = Some(forkConfiguration)

The advice to use the Basics section referred to using the forkRun method as
shown in the Basics section and not a custom ForkScalaRun as shown in the
Advanced section. To set the jvm options, the third example is probably what
you want:

override def fork =
forkRun("-Xmx8G" :: Nil)

-Mark

> > [1] http://code.google.com/p/simple-build-tool/wiki/Forking
> >
> >> override def fork = Some(new ForkScalaRun {
> >> val newPath = System.getProperty("java.library.path") + nativeJOGL
> >> override def runJVMOptions = super.runJVMOptions ++
> >> Seq("-Djava.library.path=" + newPath)
> >> })
> >>
> >> I've tried the sbt google group, but it seems to be very low traffic.
> >> It's a shame as sbt seems to have some really cool features compared
> >> to ant. I think the default compile task works fine, but I can't seem
> >> to get run or package working as the docs explain. Has anyone done
> >> something similar with their sbt project?
> >>
> >> On Wed, Sep 1, 2010 at 8:55 AM, Josh Stratton
> >
> > wrote:
> >> >> Builds are fiddly beasts, I can't give you precise answers. The
> >> >> thing with the enumeration building from clean but not incrementally
> >> >> sounds like a candidate for compiler bug. You don't need to set
> >> >> SCALA_HOME, but you probably need other setup which the fsc script
> >> >> does. Being dependent on fsc is pretty suboptimal. Have you looked
> >> >> into sbt yet? I'm sure it gets tiresome when something isn't working
> >> >> and people suggest introducing even more unknowns, but sbt is miles
> >> >> ahead when it comes to building. You could look at it as an
> >> >> opportunity.
> >> >
> >> > I guess I might as well take the plunge. Does it support the
> >> > functionality of jarjar?
> >> >
> >> >> And if you can't shake the enumeration error please report it.
> >> >
> >> > I reported it. I'll try this week to break it down to a smaller
> >> > reproduceable case.
> >> >
> >> > https://lampsvn.epfl.ch/trac/scala/ticket/3817

> The advice to use the Basics section referred to using the forkRun method as
> shown in the Basics section and not a custom ForkScalaRun as shown in the
> Advanced section.  To set the jvm options, the third example is probably what
> you want:
>
>  override def fork =
>    forkRun("-Xmx8G" :: Nil)
>

Ah, okay. That works great.

override def fork = forkRun("-Djava.library.path=%s".format(nativeJOGL) :: Nil)

How exactly does one fetch resources using run? Will there be a
different path once they're compiled?

Before I had something like

this.getClass().getResource("object_button01.png")

where the PNG was sitting in the same directory as the class once I
tossed everything into a jar. When I use a similar directory
hierarchy in the resources/ path
(resources/com/googlecode/sunshine/panel/), it isn't found at during
the 'run' action. However, when I package everything together the
PNGs are sitting next to the classes again, so I expect the original
getResource("object_button01.png") would start working again. Do I
have to specify something to run so getResource() called by my classes
(unjarred) will go to the correct directory?

I wanted to thank everyone with their ideas including the advice to
switch over to sbt. At first it was a bit of a hassle, but it turned
out to be much easier to maintain than ant and got around that scalac
but ant was having.

If anyone is interested, I wrote a detailed blog entry on how I setup
my project. Comments and advice are welcome.

http://strattonbrazil.blogspot.com/2010/10/incorporating-scala-java-sbt-...

On Fri, Sep 10, 2010 at 8:20 PM, Josh Stratton wrote:
>> The advice to use the Basics section referred to using the forkRun method as
>> shown in the Basics section and not a custom ForkScalaRun as shown in the
>> Advanced section.  To set the jvm options, the third example is probably what
>> you want:
>>
>>  override def fork =
>>    forkRun("-Xmx8G" :: Nil)
>>
>
> Ah, okay.  That works great.
>
> override def fork = forkRun("-Djava.library.path=%s".format(nativeJOGL) :: Nil)
>
> How exactly does one fetch resources using run?  Will there be a
> different path once they're compiled?
>
> Before I had something like
>
> this.getClass().getResource("object_button01.png")
>
> where the PNG was sitting in the same directory as the class once I
> tossed everything into a jar.  When I use a similar directory
> hierarchy in the resources/ path
> (resources/com/googlecode/sunshine/panel/), it isn't found at during
> the 'run' action.  However, when I package everything together the
> PNGs are sitting next to the classes again, so I expect the original
> getResource("object_button01.png") would start working again.  Do I
> have to specify something to run so getResource() called by my classes
> (unjarred) will go to the correct directory?
>