[ANNOUNCE] sbt 0.13.2-M1 is released

[Josh Suereth]

sbt 0.13.2-M1 is published. 

0.13.2-M1 is predominantly a bugfix release, but this milestone contains new features improvements we'd like to ensure are stable before releasing:

• New incremental compilation algorithm which should help reduce the amount of files touched on recompile.  To enable incremental compilation, add this setting:
  
  incOptions := incOptions.value.withNameHashing(true)
  
  
  
• The sbt launcher[1] has the ability to launch servers in addition to applications.  You can now create servers which bind to dynamic ports and discover the port using a new --locate option on the launcher.  Fledgling docs [2] [3] are available for this feature.

Use it in an existing 0.13 project by modifying project/build.properties to be:

sbt.version=0.13.2-M1

There is a new launcher[1], but the 0.13.{0,1} launcher should work fine with 0.13.2-M1.  No changes should be necessary to your project definition and all plugins published for 0.13.x should still work. 

Please try out the new features and report back any issues you find!

Thanks, 
The sbt Team

[1] http://repo.typesafe.com/typesafe/ivy-releases/org.scala-sbt/sbt-launch/0.13.2-M1/sbt-launch.jar

[2] https://github.com/sbt/sbt/blob/0.13/src/sphinx/Launcher/Configuration.rst#6-the-server-section

[3] https://github.com/sbt/sbt/blob/0.13/src/sphinx/Launcher/Architecture.rst#service-discovery-and-isolation

[Naftoli Gugenheim]

On Thu, Jan 9, 2014 at 9:52 AM, Josh Suereth <joshua....@gmail.com> wrote:

sbt 0.13.2-M1 is published. 

0.13.2-M1 is predominantly a bugfix release, but this milestone contains new features improvements we'd like to ensure are stable before releasing:

• New incremental compilation algorithm which should help reduce the amount of files touched on recompile.  To enable incremental compilation, add this setting:
  
  incOptions := incOptions.value.withNameHashing(true)
  

Exciting that this is now available! One thing, perhaps it would be more readable and similar to other settings, if there was a separate Boolean setting like incrementalNameHashing (or a more general IncrementalAlgorithm type), and incOptions or whatever would have a dependency on that setting.

• The sbt launcher[1] has the ability to launch servers in addition to applications.  You can now create servers which bind to dynamic ports and discover the port using a new --locate option on the launcher.  Fledgling docs [2] [3] are available for this feature.

Nice, I didn't expect this so soon!

Use it in an existing 0.13 project by modifying project/build.properties to be:

sbt.version=0.13.2-M1

There is a new launcher[1], but the 0.13.{0,1} launcher should work fine with 0.13.2-M1.  No changes should be necessary to your project definition and all plugins published for 0.13.x should still work. 

Please try out the new features and report back any issues you find!

Thanks, 
The sbt Team

[1] http://repo.typesafe.com/typesafe/ivy-releases/org.scala-sbt/sbt-launch/0.13.2-M1/sbt-launch.jar

[2] https://github.com/sbt/sbt/blob/0.13/src/sphinx/Launcher/Configuration.rst#6-the-server-section

[3] https://github.com/sbt/sbt/blob/0.13/src/sphinx/Launcher/Architecture.rst#service-discovery-and-isolation

--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAFLqJkzj_%2B4bgbtPE_yxacZVcf3p-ffbE%2BY2gJpKyo3LP8LoZA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Grzegorz Kossakowski]

On 10 January 2014 07:40, Naftoli Gugenheim <nafto...@gmail.com> wrote:

On Thu, Jan 9, 2014 at 9:52 AM, Josh Suereth <joshua....@gmail.com> wrote:

sbt 0.13.2-M1 is published. 

0.13.2-M1 is predominantly a bugfix release, but this milestone contains new features improvements we'd like to ensure are stable before releasing:

• New incremental compilation algorithm which should help reduce the amount of files touched on recompile.  To enable incremental compilation, add this setting:
  
  incOptions := incOptions.value.withNameHashing(true)
  

Exciting that this is now available! One thing, perhaps it would be more readable and similar to other settings, if there was a separate Boolean setting like incrementalNameHashing (or a more general IncrementalAlgorithm type), and incOptions or whatever would have a dependency on that setting.

Hi Naftoli!

There are more incremental compiler settings than just nameHashing, check IncOptions class.

We would have to introduce a setting for most of those options which probably doesn't make much sense. Normally, you shouldn't need to tweak those options and just stick to defaults. In particular, once name hashing stabilizes we'll switch to it by default.

--
Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski

[Naftoli Gugenheim]

On Fri, Jan 10, 2014 at 8:42 AM, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:

On 10 January 2014 07:40, Naftoli Gugenheim <nafto...@gmail.com> wrote:

On Thu, Jan 9, 2014 at 9:52 AM, Josh Suereth <joshua....@gmail.com> wrote:

sbt 0.13.2-M1 is published. 

0.13.2-M1 is predominantly a bugfix release, but this milestone contains new features improvements we'd like to ensure are stable before releasing:

• New incremental compilation algorithm which should help reduce the amount of files touched on recompile.  To enable incremental compilation, add this setting:
  
  incOptions := incOptions.value.withNameHashing(true)
  

Exciting that this is now available! One thing, perhaps it would be more readable and similar to other settings, if there was a separate Boolean setting like incrementalNameHashing (or a more general IncrementalAlgorithm type), and incOptions or whatever would have a dependency on that setting.

Hi Naftoli!

There are more incremental compiler settings than just nameHashing, check IncOptions class.

I think I've seen sbt (plugin) APIs that still work that way, with a number of separate settings.

 

We would have to introduce a setting for most of those options which probably doesn't make much sense. Normally, you shouldn't need to tweak those options and just stick to defaults. In particular, once name hashing stabilizes we'll switch to it by default.

Okay, if most users are never going to have to configure it then it doesn't really need aesthetic wrapping. :)

 

--
Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski

--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAD%2BExr%2BSFzWUxO_ZqFZujMM-XpDG5A8TfLgSQNB7pSk9FKxEtA%40mail.gmail.com.

[Filippo De Luca]

Happy to see that.

[tr...@groosker.com]

Nice! 

Works well on simple projects, but I get an error when trying to compile my multi-project:

(facelift-core/compile:compile) java.lang.AssertionError: assertion failed: When `nameHashing` is disabled `names` relation should be empty: $names

Source code at https://github.com/tbje/facelift

Any ideas?

[Josh Suereth]

Is the name hashing setting defined on all projects, or just on one?

--

You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/e1e02851-08ab-4727-8980-6ce83ee47dee%40googlegroups.com.

[Patrick Mahoney]

I am currently blocked by this same error. I can confirm that the incOptions has name hashing defined (and true) in all projects within the build.

-Patrick

[tr...@groosker.com]

It's actually not set at all for any of the projects. I just changed my build.properties.

[Grzegorz Kossakowski]

On 23 January 2014 11:01, <tr...@groosker.com> wrote:
>
> Nice!
>
> Works well on simple projects, but I get an error when trying to compile my multi-project:
>
> (facelift-core/compile:compile) java.lang.AssertionError: assertion failed: When `nameHashing` is disabled `names` relation should be empty: $names
>
> Source code at https://github.com/tbje/facelift
>
> Any ideas?

Hi Trond!

I just cloned your project and applied the following patch:

diff --git a/project/Build.scala b/project/Build.scala
index 31e1d5d..2c7b3df 100644
--- a/project/Build.scala
+++ b/project/Build.scala
@@ -20,6 +20,7 @@ object BuildSettings {
"-target:jvm-1.6",
"-encoding", "UTF-8"
),
+ incOptions := incOptions.value.withNameHashing(true),
publishTo := {
val publishDir =
Option(System.getProperty("publish.dir")).getOrElse(System.getProperty("user.dir"))
val publishPath =
"/[organization]/[module](_[scalaVersion])/[revision]/[artifact](_[scalaVersion])-[revision](-[classifier]).[ext]"
diff --git a/project/build.properties b/project/build.properties
index 638d14e..fdc4c86 100644
--- a/project/build.properties
+++ b/project/build.properties
@@ -1 +1 @@
-sbt.version=0.13.1
\ No newline at end of file
+sbt.version=0.13.2-M1

I tried compiling it and everything works. Could you provide exact
steps that allow me to reproduce the problem you are seeing?

[Patrick Mahoney]

In our case, I found something a bit odd.

$ > sbt clean compile

-this works. Attempting to compile again...

$ > sbt compile

-this fails with
[error] (macros/compile:compile) java.lang.AssertionError: assertion failed: When `nameHashing` is disabled `names` relation should be empty: $names.

Now I enter the sbt console,

sbt > compile
[error] (macros/compile:compile) java.lang.AssertionError: assertion failed: When `nameHashing` is disabled `names` relation should be empty: $names

sbt > project macros

sbt - macros > clean

sbt - macros > compile

success

sbt - macros > compile

also success.

If I do this to each of the projects and then compile the root project without leaving sbt console, success. If I exit, and then run sbt compile from the command line again, it fails. It's like the analysis cache at the top level is stale or something, but I can't find how to clean it.

-Patrick

--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAD%2BExrJCen1wmNPn6BcpM2cOTeLbB4j3Wc5%2BA%3Dy14k0A0zGYZg%40mail.gmail.com.

[Grzegorz Kossakowski]

On 23 January 2014 18:37, Patrick Mahoney <pat...@auvik.com> wrote:
> In our case, I found something a bit odd.
>
> $ > sbt clean compile
> -this works. Attempting to compile again...
> $ > sbt compile
> -this fails with
> [error] (macros/compile:compile) java.lang.AssertionError: assertion failed:
> When `nameHashing` is disabled `names` relation should be empty: $names.
>
> Now I enter the sbt console,
> sbt > compile
> [error] (macros/compile:compile) java.lang.AssertionError: assertion failed:
> When `nameHashing` is disabled `names` relation should be empty: $names
> sbt > project macros
> sbt - macros > clean
> sbt - macros > compile
> success
> sbt - macros > compile
> also success.
>
> If I do this to each of the projects and then compile the root project
> without leaving sbt console, success. If I exit, and then run sbt compile
> from the command line again, it fails. It's like the analysis cache at the
> top level is stale or something, but I can't find how to clean it.

Hi Patrick!

This is indeed very odd and it seems like you are experiencing a real bug.

The failing assertion is here:
https://github.com/sbt/sbt/blob/0.13/compile/persist/src/main/scala/sbt/inc/TextAnalysisFormat.scala#L228

It means we are reading incremental compiler's state from disk and
what we read appears to be malformed. Specifically, it looks like name
hashing is disabled but the relation 'used names' is non-empty at the
same time. However, used names extraction should kick in only when
name hashing is enabled. I reread the code implementing the logic
relevant here and I don't see any obvious problem with it.

How many subprojects do you have? If not too many then maybe you could
share target/streams/compile/incCompileSetup/\$global/streams/inc_compile
file for each subproject when you see the failure? Those are the files
read by TextAnalysisFormat and I expect one of them to be malformed.
Maybe just by looking at those files I could figure out what's going
on here.

[tr...@groosker.com]

Hi Greg!

The problem went away after "rm -rf target". 

I tried going back to sbt-0.13.1 compile and then move forward again but no problem. It might also have been from an earlier version of sbt.

Anyways, you could add a notice about manually removing the target folder if strange things happen. I tried cleaning first, but without any luck.

Trond

[Patrick Mahoney]

Hello Grzegorz,

I just sent off the two analysis files to your email address. Please let me know if there is anything I can provide that might make your lives easier.

-Patrick

--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAD%2BExrJFvFRa-b-SBmSGzpZt_%2Bf-767d%2BSvhf_aX-XsFg6xqNQ%40mail.gmail.com.

[Patrick Mahoney]

Hello Grzegorz,

Just wanted to make sure you received the analysis files. Let me know if I need to resend or get them to you by some other means.

-Patrick

[Grzegorz Kossakowski]

Hi Patrick!

I got the analysis files and I looked at them briefly. It appears like dependency extraction is broken so for some. Could you disable name hashing, delete target directory, start sbt and rebuild your project. Once that is done, could you send me macros-inc_compile file so I can compare the one you sent me (with name hashing enabled) and the other one when the name hashing is disabled?

PS. I'm a bit slow at responding because I'm traveling.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAJeBnVWbOiqo2Py1w9LFA%3D%3DZEd_ShoOrge9%2BgZEeP4KCOa-sXg%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

[eugene yokota]

Hi,

Ran into a suspect regression. The code compiles on 0.13.1.

If you grab the latest sbt-appengine and change the build.properties to 0.13.2-M1 and clean compile, you get:

sbt-appengine> compile

[info] Updating {file:/x/sbt-appengine/}sbt-appengine...

[info] Resolving org.fusesource.jansi#jansi;1.4 ...

[info] Done updating.

[info] Compiling 2 Scala sources to /x/sbt-appengine/target/scala-2.10/sbt-0.13/classes...

[error] /x/sbt-appengine/src/main/scala/AppenginePlugin.scala:162: exception during macro expansion: 

[error] java.lang.NullPointerException

[error] at sbt.appmacro.Instance$.sbt$appmacro$Instance$$addType$1(Instance.scala:170)

[error] at sbt.appmacro.Instance$$anonfun$sbt$appmacro$Instance$$sub$1$1.apply(Instance.scala:178)

[error] at sbt.appmacro.Instance$$anonfun$sbt$appmacro$Instance$$sub$1$1.apply(Instance.scala:177)

[error] at sbt.appmacro.Converted$Success.transform(Convert.scala:33)

[error] at sbt.appmacro.Instance$.sbt$appmacro$Instance$$sub$1(Instance.scala:177)

[error] at sbt.appmacro.Instance$$anonfun$1.apply(Instance.scala:183)

[error] at sbt.appmacro.Instance$$anonfun$1.apply(Instance.scala:183)

[error] at sbt.appmacro.ContextUtil$appTransformer$2$.transform(ContextUtil.scala:227)

[error] at sbt.appmacro.ContextUtil$appTransformer$2$.transform(ContextUtil.scala:222)

[error] at scala.reflect.internal.Trees$class.itransform(Trees.scala:1217)

[error] at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:13)

[error] at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:13)

[error] at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2897)

[error] at sbt.appmacro.ContextUtil$appTransformer$2$.transform(ContextUtil.scala:232)

[error] at sbt.appmacro.ContextUtil$appTransformer$2$.transform(ContextUtil.scala:222)

[error] at scala.reflect.api.Trees$Transformer$$anonfun$transformTrees$1.apply(Trees.scala:2900)

[error] at scala.reflect.api.Trees$Transformer$$anonfun$transformTrees$1.apply(Trees.scala:2900)

[error] at scala.collection.immutable.List.loop$1(List.scala:170)

[error] at scala.collection.immutable.List.mapConserve(List.scala:186)

[error] at scala.reflect.api.Trees$Transformer.transformTrees(Trees.scala:2900)

[error] at scala.reflect.internal.Trees$class.itransform(Trees.scala:1219)

[error] at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:13)

[error] at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:13)

[error] at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2897)

[error] at sbt.appmacro.ContextUtil$appTransformer$2$.transform(ContextUtil.scala:230)

[error] at sbt.appmacro.ContextUtil$appTransformer$2$.transform(ContextUtil.scala:222)

[error] at scala.reflect.api.Trees$Transformer$$anonfun$transformTrees$1.apply(Trees.scala:2900)

[error] at scala.reflect.api.Trees$Transformer$$anonfun$transformTrees$1.apply(Trees.scala:2900)

[error] at scala.collection.immutable.List.loop$1(List.scala:170)

[error] at scala.collection.immutable.List.mapConserve(List.scala:186)

[error] at scala.reflect.api.Trees$Transformer.transformTrees(Trees.scala:2900)

[error] at scala.reflect.internal.Trees$class.itransform(Trees.scala:1219)

[error] at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:13)

[error] at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:13)

[error] at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2897)

[error] at sbt.appmacro.ContextUtil$appTransformer$2$.transform(ContextUtil.scala:230)

[error] at sbt.appmacro.ContextUtil.transformWrappers(ContextUtil.scala:236)

[error] at sbt.appmacro.Instance$.contImpl(Instance.scala:183)

[error] at sbt.std.TaskMacro$.iInitializeMacro(TaskMacro.scala:236)

[error] at sbt.std.TaskMacro$.inputTaskMacro0(TaskMacro.scala:225)

[error] at sbt.std.TaskMacro$.inputTaskMacroImpl(TaskMacro.scala:220)

[error] at sbt.std.TaskMacro$.inputTaskAssignMacroImpl(TaskMacro.scala:135)

[error]     gae.requestLogs     := AppEngine.appcfgTask("request_logs", outputFile = Some("request.log")).evaluated,

[error]                         ^

[error] one error found

[error] (compile:compile) Compilation failed

[error] Total time: 7 s, completed Feb 5, 2014 11:43:07 PM

-eugene

[Mark Harrah]

Jason recently fixed https://github.com/sbt/sbt/issues/1031, which isn't the same, but might fix this too. Perhaps you can test with the 0.13 branch or with -M2 when it is out (not sure what Josh's plans are with the timing of -M2).

-Mark

> --
> You received this message because you are subscribed to the Google Groups "sbt-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/4e300db9-89af-4229-9d14-87e6ce8f0674%40googlegroups.com.

[Josh Suereth]

I'd like  cut M2 ASAP, but thursday/friday releases are usually a bad idea.   We'll go for monday at this point.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/20140206092006.55641832%40gmail.com.

[eugene yokota]

Same error using 0.13 branch -SNAPSHOT:

sbt-appengine> compile

[info] Updating {file:/x/sbt-appengine/}sbt-appengine...

[info] Resolving org.fusesource.jansi#jansi;1.4 ...

[info] Done updating.

[info] Compiling 2 Scala sources to /x/sbt-appengine/target/scala-2.10/sbt-0.13/classes...

[error] /Users/eed3si9n/work/sbt-appengine/src/main/scala/AppenginePlugin.scala:162: exception during macro expansion: 

[error] java.lang.NullPointerException

[error] at sbt.appmacro.Instance$.sbt$appmacro$Instance$$addType$1(Instance.scala:170)

....

[error]     gae.requestLogs     := AppEngine.appcfgTask("request_logs", outputFile = Some("request.log")).evaluated,

[error]                         ^

[error] one error found

[error] (compile:compile) Compilation failed

[error] Total time: 36 s, completed Feb 6, 2014 10:03:54 AM

sbt-appengine> sbtVersion

[info] 0.13.2-SNAPSHOT

-eugene

On Thu, Feb 6, 2014 at 9:20 AM, Mark Harrah <dmha...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/20140206092006.55641832%40gmail.com.

[Mark Harrah]

On Thu, 6 Feb 2014 10:07:50 -0500
eugene yokota <eed3...@gmail.com> wrote:

> Same error using 0.13 branch -SNAPSHOT:

Thanks, open an issue please.

-Mark

> To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CA%2BCq6KQLRAWp08b9uJ5EgX0r_%3DmXUS2QbLF44KaqzfP%2BA4DhOA%40mail.gmail.com.

[Eric Torreborre]

Hi guys,

Same problem here with specs2. I tried rm -rf target but that didn't work. A robust fix would be nice.

Thanks,

Eric.

[Josh Suereth]

Greg has a fix in.  0.13.2-M2 should be out tomorrow, if all goes according to plan.

--

You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/6550d30c-5b15-4c46-8b6f-6cb2ecd40f94%40googlegroups.com.

[Grzegorz Kossakowski]

On 20 February 2014 00:03, Josh Suereth <joshua....@gmail.com> wrote:

Greg has a fix in.  0.13.2-M2 should be out tomorrow, if all goes according to plan.

Here's the patch: https://github.com/sbt/sbt/pull/1122

[Alois Cochard]

Hi everyone,

I'm using it since yesterday, I just got that this morning:

[trace] Stack trace suppressed: run last model/compile:compile for the full output.

[error] (model/compile:compile) java.lang.IllegalArgumentException: requirement failed: Source file '/home/alois/timeout/jvm/target/classes.bak/sbt31129578467175808.class' does not exist.

[error] Total time: 2 s, completed Mar 12, 2014 11:23:42 AM

7. Waiting for source changes... (press enter to interrupt)

last m

> last model/compile:compile

>

Thanks

Alois

[Alois Cochard]

I add an other error on second try, but it work on third one:

[trace] Stack trace suppressed: run last model/compile:compile for the full output.

[error] (model/compile:compile) java.io.IOException: No such file or directory

[error] Total time: 2 s, completed Mar 12, 2014 11:26:38 AM

> model/compile:compile

[info] Compiling 1 Scala source to /home/alois/timeout/jvm/model/target/classes...

[info] Compiling 4 Scala sources to /home/alois/timeout/jvm/model/target/classes...

[success] Total time: 4 s, completed Mar 12, 2014 11:26:52 AM

>

On Thursday, 9 January 2014 14:52:36 UTC, Josh Suereth wrote:

[Josh Suereth]

On Wed, Mar 12, 2014 at 7:22 AM, Alois Cochard <alois....@gmail.com> wrote:

Hi everyone,

I'm using it since yesterday, I just got that this morning:

[trace] Stack trace suppressed: run last model/compile:compile for the full output.

[error] (model/compile:compile) java.lang.IllegalArgumentException: requirement failed: Source file '/home/alois/timeout/jvm/target/classes.bak/sbt31129578467175808.class' does not exist.

[error] Total time: 2 s, completed Mar 12, 2014 11:23:42 AM

7. Waiting for source changes... (press enter to interrupt)

last m

> last model/compile:compile

>

I just issued a fix to the 'last' task.  If you're using 0.13.2-M3, can you show the directories in target/streams that have files?

[Alois Cochard]

Hey guys,

I got the error with M3, here is the output of last:

http://pastie.org/8916318

and a `ll -R` of target/streams

http://pastie.org/8916326

May The Force be with you.

Alois

[Grzegorz Kossakowski]

On 12 March 2014 12:22, Alois Cochard <alois....@gmail.com> wrote:

Hi everyone,

I'm using it since yesterday, I just got that this morning:

[trace] Stack trace suppressed: run last model/compile:compile for the full output.

[error] (model/compile:compile) java.lang.IllegalArgumentException: requirement failed: Source file '/home/alois/timeout/jvm/target/classes.bak/sbt31129578467175808.class' does not exist.

[error] Total time: 2 s, completed Mar 12, 2014 11:23:42 AM

7. Waiting for source changes... (press enter to interrupt)

last m

> last model/compile:compile

Hi Alois,

Do I understand it correctly that this happens only when name hashing enabled?

[Patrick Mahoney]

One note that might be made about enabling/disabling nameHashing within a build is that IDE project generation plugins like sbt-eclipse and sbt-idea maintain their own compiled files, and an sbt clean may not be enough. In my case,
find . -name "target" -exec rm -rf {} \;

was enough to work around the errors upon first running sbt gen-idea or sbt eclipse (these occurred even following a clean build that was successful - i suspect that sbt clean misses the project/project/target directory or some other gen-idea target directories that need cleaning). Unfortunately I didn't keep the error messages on hand when gen-idea failed following a successful clean build.

-Patrick

--

You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/d1d8fdd3-f1a7-4cfd-af9b-827402a637f9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alois Cochard]

If that help:
- happen only with name hashing
- I do not use an IDE

I tried to see if there is a pattern (like when switching branches)

But it feel quite random so far...

You received this message because you are subscribed to a topic in the Google Groups "sbt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sbt-dev/KmGEhFTMve0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAJeBnVUK%3DyNzgc_%3DeMZEGxU1D1_UFp%3Dck4Onit1_M7yHW_qEfw%40mail.gmail.com.

[Josh Suereth]

So, it looks like your last issue was, indeed, the one fixed in sbt 0.13.2-M3.  As for the incremental compiler issue, hoping Greg can help out here.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAJHA%2Bwpn8s6ezXv1NY_v6WzD6BaoJF3Rc7MEgkeX4MDg8x7Nmw%40mail.gmail.com.

[Grzegorz Kossakowski]

On 13 March 2014 19:25, Josh Suereth <joshua....@gmail.com> wrote:

So, it looks like your last issue was, indeed, the one fixed in sbt 0.13.2-M3.  As for the incremental compiler issue, hoping Greg can help out here.

I filed a ticket for this issue, let's track it further there: https://github.com/sbt/sbt/issues/1184

I've been starring at the log and the code but I couldn't figure out how name hashing could regress. The code responsible for class file management is shared between the old algorithm and the name hashing algorithm. 

We'll need more debug logging to pinpoint the issue. I'll submit a PR soon.