0.9.9-SNAPSHOT changes

[Mark Harrah]

I made a couple of changes that will impact users running off of the 0.9 branch (and then releases starting with 0.9.9).

1) Projects are discovered reflectively again. I really didn't want any reflective discovery in 0.9, but forgetting to add a project is a preventable error, so I did it. The consequence is that you have to either delete your 'lazy val projects = Seq(...)' line (enabling reflective discovery) or add 'override' to it (to continue manually listing projects). If you stick with manually listing them, lazy val is not strictly necessary for 'projects'. A def is fine.

2) Keys are now backed by a Manifest in order to fix issue #27. The consequence is you can define keys inline multiple times as long as the type is the same. Something that might break is if you did this before, because adding the Manifest breaks type inference:

https://issues.scala-lang.org/browse/SI-4653

An example, both of these can go in the same build file:

TaskKey[Int]("demo") := 3

TaskKey[Int]("demo") += 2

Before, you would get an error about a key collision (to ensure type safety). SI-4653 means the [Int] part is required.

As always, thanks for the feedback so far.

-Mark

[ijuma]

On Friday, 27 May 2011 03:29:00 UTC+1, Mark Harrah wrote:

I made a couple of changes that will impact users running off of the 0.9 branch (and then releases starting with 0.9.9).

Thanks Mark, I agree with both changes. It's nice not to need to add all the projects manually for the default case and being able to define keys multiple times also makes the builds less error-prone (I had run across this problem myself in a shared method that created some settings and was used from multiple other methods).

With 0.10 approaching quickly and the release of 2.9.0.1 a few days ago, it would be nice to move SBT to 2.9.0.1 and then release 0.9.9 soon so that the combination can get some testing. Is that your plan?

Best,

Ismael

[Mark Harrah]

On Thu, 26 May 2011 23:41:04 -0700 (PDT)
ijuma <ism...@juma.me.uk> wrote:

> On Friday, 27 May 2011 03:29:00 UTC+1, Mark Harrah wrote:
> >
> > I made a couple of changes that will impact users running off of the 0.9
> > branch (and then releases starting with 0.9.9).
>
> Thanks Mark, I agree with both changes. It's nice not to need to add all the
> projects manually for the default case and being able to define keys
> multiple times also makes the builds less error-prone (I had run across this
> problem myself in a shared method that created some settings and was used
> from multiple other methods).

In general, I think it is still better to explicitly declare keys globally. Not that you disagree, but now seems like a good time to mention it. That way, you can refer to a key in Scala, get the compiler to check that you spelled it right, and not have to duplicate the type definition. Keys should also have descriptions and you don't want to duplicate or omit that either.

> With 0.10 approaching quickly and the release of 2.9.0.1 a few days ago, it
> would be nice to move SBT to 2.9.0.1 and then release 0.9.9 soon so that the
> combination can get some testing. Is that your plan?

I've been undecided on 2.9, but you're right that a decision needs to happen now. Let's do the following. If you are using 0.9.8, please get a rough idea of how long common actions take (whatever is important to you: startup time, project compilation time, build compilation time, adding a setting with 'set', ...). I will make 0.9.9 based on 2.9.0-1 this weekend. Recheck your timings and of course note any correctness issues. If we encounter serious problems that would be difficult to resolve quickly or require 2.9.0-1 + 1, we can revert to 2.8.1 and revisit the issue after 0.10.0. Does that sound reasonable?

-Mark

[Heiko Seeberger]

On 27 May 2011 19:56, Mark Harrah <dmha...@gmail.com> wrote:

I've been undecided on 2.9, but you're right that a decision needs to happen now.  Let's do the following.  If you are using 0.9.8, please get a rough idea of how long common actions take (whatever is important to you: startup time, project compilation time, build compilation time, adding a setting with 'set', ...).  I will make 0.9.9 based on 2.9.0-1 this weekend.  Recheck your timings and of course note any correctness issues.  If we encounter serious problems that would be difficult to resolve quickly or require 2.9.0-1 + 1, we can revert to 2.8.1 and revisit the issue after 0.10.0.  Does that sound reasonable?

Very good plan! I will take timings for sbteclipse.

Heiko

-- 

Heiko Seeberger

Twitter: hseeberger
Blog: heikoseeberger.name

[ijuma]

On Friday, 27 May 2011 18:56:05 UTC+1, Mark Harrah wrote:

In general, I think it is still better to explicitly declare keys globally.  Not that you disagree, but now seems like a good time to mention it.  That way, you can refer to a key in Scala, get the compiler to check that you spelled it right, and not have to duplicate the type definition.  Keys should also have descriptions and you don't want to duplicate or omit that either.

Definitely. In my case, I had the key defined only once, but it was inline in a method that was called from two different places. That caused the constructor to be invoked twice causing the issue. Since I did not refer to the key anywhere else, moving it out to a lazy val seemed like an unnecessary requirement. Not a big deal though. 

I've been undecided on 2.9, but you're right that a decision needs to happen now.  Let's do the following.  If you are using 0.9.8, please get a rough idea of how long common actions take (whatever is important to you: startup time, project compilation time, build compilation time, adding a setting with 'set', ...).  I will make 0.9.9 based on 2.9.0-1 this weekend.  Recheck your timings and of course note any correctness issues.  If we encounter serious problems that would be difficult to resolve quickly or require 2.9.0-1 + 1, we can revert to 2.8.1 and revisit the issue after 0.10.0.  Does that sound reasonable?

Sure. I should have some time tomorrow (Sunday) and Monday and am happy to do such testing.

Best,

Ismael

[Mark Harrah]

> > I've been undecided on 2.9, but you're right that a decision needs to
> > happen now. Let's do the following. If you are using 0.9.8, please get a
> > rough idea of how long common actions take (whatever is important to you:
> > startup time, project compilation time, build compilation time, adding a
> > setting with 'set', ...). I will make 0.9.9 based on 2.9.0-1 this weekend.
> > Recheck your timings and of course note any correctness issues. If we
> > encounter serious problems that would be difficult to resolve quickly or
> > require 2.9.0-1 + 1, we can revert to 2.8.1 and revisit the issue after
> > 0.10.0. Does that sound reasonable?
> >
> Sure. I should have some time tomorrow (Sunday) and Monday and am happy to
> do such testing.

Great, thanks. I will try to get it out today.

-Mark

[Mark Harrah]

> > With 0.10 approaching quickly and the release of 2.9.0.1 a few days ago, it
> > would be nice to move SBT to 2.9.0.1 and then release 0.9.9 soon so that the
> > combination can get some testing. Is that your plan?
>
> I've been undecided on 2.9, but you're right that a decision needs to happen now. Let's do the following. If you are using 0.9.8, please get a rough idea of how long common actions take (whatever is important to you: startup time, project compilation time, build compilation time, adding a setting with 'set', ...). I will make 0.9.9 based on 2.9.0-1 this weekend. Recheck your timings and of course note any correctness issues. If we encounter serious problems that would be difficult to resolve quickly or require 2.9.0-1 + 1, we can revert to 2.8.1 and revisit the issue after 0.10.0. Does that sound reasonable?

I have found 2.9.0 to be slower for an important case. Start up sbt and modify a setting from the command line, like:

$ sbt
> set name := "demo"

For sbt 0.9.8 + Scala 2.8.1, this takes 7 s for me. For sbt 0.9.9 + Scala 2.9.0-1, this takes 17 s. I reverted 0.9.10-SNAPSHOT locally to 2.8.1 and it returns to 7 s. I time this using:

$ time sbt 'set name := "demo"' < /dev/null

(You need to delete project/target/ between runs to clear the compiled settings cache.)

You can see the difference in compiling "object A" with 2.9.0-1 (4.1 s) and Scala trunk (1.7 s). I expect this is all startup time, since trunk includes improvements related to startup time. Therefore, I am inclined to revert to 2.8.1 for 0.10.0 and revisit 2.9.x when the startup time improvements in trunk are included in a 2.9.x version.

-Mark

[ijuma]

On Monday, 30 May 2011 22:49:08 UTC+1, Mark Harrah wrote:

For sbt 0.9.8 + Scala 2.8.1, this takes 7 s for me.  For sbt 0.9.9 + Scala 2.9.0-1, this takes 17 s.  I reverted 0.9.10-SNAPSHOT locally to 2.8.1 and it returns to 7 s.  I time this using:

Ouch! That's pretty bad. I feared that start-up would take a significant hit due to all the new classes in 2.9.

I expect this is all startup time, since trunk includes improvements related to startup time.  Therefore, I am inclined to revert to 2.8.1 for 0.10.0 and revisit 2.9.x when the startup time improvements in trunk are included in a 2.9.x version.

I think that makes sense. Would that have to wait until the series after 0.10.x or could it be done as part of the 0.10.x series?

Incidentally, I was in the process of doing some performance testing myself when I saw your commit reverting to 2.8.1 a few minutes ago. Given your results, it seems like it's better to postpone such testing for later.

Best,

Ismael

[anli]

On Tuesday, May 31, 2011 1:49:08 AM UTC+4, Mark Harrah wrote:

For sbt 0.9.9 + Scala 2.9.0-1, this takes 17 s.

Was it not-first run (I mean disk cache was filled in with all jars chain already)?

[Mark Harrah]

On Mon, 30 May 2011 15:19:28 -0700 (PDT)
ijuma <ism...@juma.me.uk> wrote:

> On Monday, 30 May 2011 22:49:08 UTC+1, Mark Harrah wrote:
> >
> > For sbt 0.9.8 + Scala 2.8.1, this takes 7 s for me. For sbt 0.9.9 + Scala
> > 2.9.0-1, this takes 17 s. I reverted 0.9.10-SNAPSHOT locally to 2.8.1 and
> > it returns to 7 s. I time this using:
> >
> Ouch! That's pretty bad. I feared that start-up would take a significant hit
> due to all the new classes in 2.9.

I'm not sure what the cause is yet, but plain sbt startup time without a 'set' action doesn't appear to be much affected. I thought Paul's work that improved the startup time was on mainly compiler-related classes, but I could be wrong.

> > I expect this is all startup time, since trunk includes improvements
> > related to startup time. Therefore, I am inclined to revert to 2.8.1 for
> > 0.10.0 and revisit 2.9.x when the startup time improvements in trunk are
> > included in a 2.9.x version.
> >
> I think that makes sense. Would that have to wait until the series after
> 0.10.x or could it be done as part of the 0.10.x series?

I think moving to 2.9 would mean going to 0.11. I don't think there would be much practical difference compared with going from 0.10.x to 0.10.x+1. That is, the only reason for the bump would be for moving to Scala, and not because build files and plugins need drastic changes like 0.7->0.9.

> Incidentally, I was in the process of doing some performance testing myself
> when I saw your commit reverting to 2.8.1 a few minutes ago. Given your
> results, it seems like it's better to postpone such testing for later.

Yes, I agree.

-Mark

[Mark Harrah]

I repeated it multiple times in the same manner for each version. You can reproduce it from my previous instructions. (Be sure that you actually switch between 0.9.8 and 0.9.9). Independent confirmation would of course be useful.

-Mark

[anli]

For this A.scala

object A {
  def main(args: Array[String]) : Unit = {
    println("I'm live")
  }
}

and this script

#!/bin/bash

#SCALA_HOME="/wrk/dev/scala/2.8.1"
SCALA_HOME="/wrk/dev/scala/2.9.0.1"

PATH=$SCALA_HOME/bin:$PATH
scala -version
rm -f *.class
scalac A.scala
time scala A

I have got this output of the second script run for 2.8.1

$ time ./runit
Scala code runner version 2.8.1.final -- Copyright 2002-2010, LAMP/EPFL
I'm live

real    0m0.380s
user    0m0.407s
sys    0m0.033s

real    0m3.819s
user    0m7.123s
sys    0m0.150s

..and this one (againsecond run) for 2.9.0.1

$ time ./runit
Scala code runner version 2.9.0.1 -- Copyright 2002-2011, LAMP/EPFL
I'm live

real    0m0.236s
user    0m0.257s
sys    0m0.010s

real    0m3.686s
user    0m7.483s
sys    0m0.137s

[Paul Phillips]

The dive continues.

#!/usr/bin/env bash
#
# paulp's variation
#
for home in $@; do
PATH=$home/bin:$PATH
which scala
echo ""

scala -version
rm -f *.class
scalac A.scala
time scala A

echo ""
done

% ./run.sh /scala/inst/281 /scala/inst/29 /scala/inst/pack
/scala/inst/281/bin/scala

Scala code runner version 2.8.1.final -- Copyright 2002-2010, LAMP/EPFL
I'm live

real 0m0.701s
user 0m0.954s
sys 0m0.093s

/scala/inst/29/bin/scala

Scala code runner version 2.9.0.1 -- Copyright 2002-2011, LAMP/EPFL
I'm live

real 0m0.610s
user 0m0.762s
sys 0m0.103s

/scala/inst/pack/bin/scala

Scala code runner version 2.10.0.r-b20110530164830 -- Copyright

2002-2011, LAMP/EPFL
I'm live

real 0m0.454s
user 0m0.582s
sys 0m0.074s

[Mark Harrah]

The numbers I quoted when running scalac were for 2.9.0-1 (4 s) and trunk (2 s), not 2.8.1 and 2.9.0-1. I showed them to justify that trunk had startup time improvements and we wouldn't just be hoping for improvements by waiting. It is indeed interesting that 2.8.1 and 2.9.0-1 appear to have little difference for compiling a simple file (and I can reproduce this). It means that the cause is less obvious, but that is a secondary point.

The original comparison of sbt 0.9.8 and 0.9.9 is the important one. I repeated the tests and got the same result.

-Mark

On Mon, 30 May 2011 16:33:03 -0700 (PDT)
anli <andrew....@gmail.com> wrote:

> For this A.scala
>
> object A {
> def main(args: Array[String]) : Unit = {
> println("I'm live")
> }
> }
>
> and this script
>
> #!/bin/bash
>
> #SCALA_HOME="/wrk/dev/scala/2.8.1"
> SCALA_HOME="/wrk/dev/scala/2.9.0.1"
>
> PATH=$SCALA_HOME/bin:$PATH
> scala -version
> rm -f *.class
> scalac A.scala
> time scala A
>

> I have got this output of *the second* script run for 2.8.1

[anli]

Paul, probably we demonstrare different tendencies :) I'm just surprised Mark's results' such big difference (7 and 17 seconds for 2.8.1 and 2.9.0.1 respectively). And your results demonstrate our great near future - progress in trunk.

[Mark Harrah]

I'm interested in timing compilation time not code runtime, although that was secondary to timing the difference between sbt 0.9.8 and 0.9.9. (In the previous post, the whole script was timed in order to show compilation time.)

-Mark

[anli]

Mark, I also used 'time' to run script: $ time ./runit
And the second timing group is an overall scipt run's one: ~3.8 seconds for 2.8.1 and ~3.7 seconds for 2.9.0.1.

[anli]

Timing for A.scala compilation itself (user time) is ~6.5 s for 2.8.1 and ~7.2 s for 2.9.0.1.

[Paul Phillips]

Here are my times for scalac instead of for running it. No, that drop from 4.738s to 2.220s is not a misprint.

% ./run.sh /scala/inst/281 /scala/inst/29 /scala/inst/pack
/scala/inst/281/bin/scala

Scala code runner version 2.8.1.final -- Copyright 2002-2010, LAMP/EPFL

real 0m4.727s
user 0m8.879s
sys 0m0.426s
I'm live

real 0m0.718s
user 0m0.942s
sys 0m0.109s

/scala/inst/29/bin/scala

Scala code runner version 2.9.0.1 -- Copyright 2002-2011, LAMP/EPFL

real 0m4.738s
user 0m9.484s
sys 0m0.429s
I'm live

real 0m0.606s
user 0m0.768s
sys 0m0.099s

/scala/inst/pack/bin/scala

Scala code runner version 2.10.0.r25041-b20110530181906 -- Copyright 2002-2011, LAMP/EPFL

real 0m2.220s
user 0m3.592s
sys 0m0.265s
I'm live

real 0m0.453s
user 0m0.580s
sys 0m0.073s

[anli]

As for 2.8.1 and 2.9.0.1 - your results are in par with my ones (2.8.1 compilation is slightly faster rather 2.9.0.1). BTW, probably user time (sum of all consumed cores) is more appropriate for comparison rather real time: we all have different core numbers :)

[anli]

On Tuesday, May 31, 2011 4:29:59 AM UTC+4, Mark Harrah wrote:

It is indeed interesting that 2.8.1 and 2.9.0-1 appear to have little difference for compiling a simple file (and I can reproduce this).  It means that the cause is less obvious, but that is a secondary point.

With the aim to reproduce that difference (7 and 17 seconds) I have tried to build tag v0.9.9 but have got  'unresolved dependency: org.scala-tools.sbt#sbt_2.8.1;0.7.7: not found' error. I'm newbie in git also, probably have some mistake. Afrer xsbt cloning I just executed two commands:

xsbt $ git checkout v0.9.9
Note: checking out 'v0.9.9'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 9002720... move to 2.9.0-1, bump to 0.9.9
xsbt $ sbt
Getting org.scala-tools.sbt sbt_2.8.1 0.7.7 ...
...

unresolved dependency: org.scala-tools.sbt#sbt_2.8.1;0.7.7: not found
Error during sbt execution: Error retrieving required libraries
  (see /wrk/cvs/xsbt/project/boot/update.log for complete log)
Error: Could not retrieve sbt 0.7.7
xsbt $

[Mark Harrah]

It looks like you are using a xsbt 0.9.x launcher to run sbt 0.7.x.

-Mark

[anli]

Ugh... Didn't expect 0.7.x is still in use to build 0.9.x :)

OK, I have reproduced your tests and got

0.9.8:

real    0m5.531s
user    0m11.493s
sys    0m0.180s

0.9.9:

real    0m11.872s
user    0m20.769s
sys    0m0.277s

Ratio isn't such big as 7/17 on my machine, but still 2x.

[Mark Harrah]

On 5/31/11, anli <andrew....@gmail.com> wrote:
> Ugh... Didn't expect 0.7.x is still in use to build 0.9.x :)

I've tried to only publish stable sbt releases using the previous
stable release. It isn't as important as properly bootstrapping a
compiler, but it is still important for reproducibility.

> OK, I have reproduced your tests and got

Thanks for verifying this.

-Mark