Re: Digest for scala-internals@googlegroups.com - 9 Messages in 3 Topics

On Fri, Aug 5, 2011 at 1:14 PM, Bill Venners <bill@artima.com> wrote:

Hi All,

I'm on digest of this list so I don't see these until the next
morning. I had not made the connection about sbt using an earlier
Scala version meaning I'm not dependent on a new build of it. That was
the main reason I didn't switch over. The other was, though, simply
that the ant build works and time invested moving over to sbt is time
I don't spend doing something that actually adds value to ScalaTest
for users.

What could be a good first step is a parallel sbt build that just
builds and possibly deploys. We have a lot of other stuff in our ant
file that need not be moved over necessarily. 

Josh if you want to take
a stab at bringing the sbt build you did previously up to date that
would be great. At the very least it could support whatever Josh is
thinking about for the mambo-build. Josh what would you need for the
mambo build?

I don't know what mambo is. Am i missing something? 

ScalaTest itself does not take long to compile, but its
tests of itself take a very long time and a lot of memory. So much
that I tend to do it in steps. First I compile without MustMatchers,
then I generate MustMatchers and recompile again. One thing we could
do with the sbt build is just build ScalaTest and not worry about its
tests of itself. Though if you're looking to see if changes to Scala
break things, then compiling those tests would be a good "test" for
Scala itself. Some Scala bugs that ScalaTest has uncovered have shown
up only in the tests.

To the best of my knowledge, I was able to do the full build, and run all of the tests. This included generating the MustMatchers. I did a thorough job. I will try to achieve all of that again.   One more thought:  Parallel ant/sbt builds are fine for now, but please allow me to suggest moving entirely to sbt, especially if I can get most or all of what you have in ant into the sbt build. Maintaining two build systems seems like something that will only lead to trouble. I'm willing to implement and support it. 

Bill

On Fri, Aug 5, 2011 at 8:06 AM,
<2Bnoreply [at] googlegroups [dot] com" rel="nofollow">scala-internals+noreply@googlegroups.com> wrote:
>   Today's Topic Summary
>
> Group: http://groups.google.com/group/scala-internals/topics
>
> Digest for scala-internals@googlegroups.com - 6 Messages in 1 Topic [7
> Updates]
> Collections Testsuite needed? [1 Update]
> Mismatched symbols in scala.collection.parallel.package.CompositeThrowable
> [1 Update]
>
>  Topic: Digest for scala-internals@googlegroups.com - 6 Messages in 1 Topic
>
> Bill Venners <bill@artima.com> Aug 04 09:56AM -0700 ^
>
> Hi All,
>
> I just noticed this conversation. ScalaTest builds with ant, not sbt,
> and I never plan to make ScalaTest depend on sbt. Although I'd prefer
> to use sbt over ant in general, of course, I want to minimize the
> Scala libraries that ScalaTest depends on, so I can get new ScalaTest
> releases out quickly after Scala releases come out. My only Scala
> library dependency currently is ScalaCheck, so I only need to wait for
> that one. As a result I think ScalaTest should be easy to integrate
> into the Scala build if you want to. You need not build and run the
> tests. That takes a long time. You could just build the tool itself,
> which is relatively quick. If you want it to be sbt 0.10, we could add
> a parallel build that just builds the tool and nothing else via sbt
> and add that to the project.
>
> Where are the current collections tests, by the way? Are they up on
> github somewhere? I'd like to take a look at them.
>
> Thanks.
>
> Bill
>
> On Wed, Aug 3, 2011 at 6:16 AM,
>
> --
> Bill Venners
> Artima, Inc.
> http://www.artima.com
>
>
>
> Seth Tisue <seth@tisue.net> Aug 04 01:08PM -0400 ^
>
>> to use sbt over ant in general, of course, I want to minimize the
>> Scala libraries that ScalaTest depends on, so I can get new ScalaTest
>> releases out quickly after Scala releases come out.
>
> There isn't any connection between the Scala version that sbt uses
> internally and the Scala version (or versions, plural!) that it builds
> your project with. So when a new Scala version comes out, you don't
> need to wait for anything. You just keep using the sbt you were
> already using, and just tell it to including the new Scala version in
> your cross-build. It's not a problem.
>
> Furthermore, sbt has very good support for cross-building, so once you
> get it set up, it's nearly effortless to build and publish releases
> for all of the Scala versions you support.
>
> --
> Seth Tisue | Northwestern University | http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>
>
>
> Ismael Juma <ismael@juma.me.uk> Aug 04 06:08PM +0100 ^
>
>> to use sbt over ant in general, of course, I want to minimize the
>> Scala libraries that ScalaTest depends on, so I can get new ScalaTest
>> releases out quickly after Scala releases come out.
>
> Since Scala will itself depend on sbt to build, it seems to me that
> your releases won't be delayed if you depend on sbt.
>
> Best,
> Ismael
>
>
>
> Ismael Juma <ismael@juma.me.uk> Aug 04 06:47PM +0100 ^
>
>
>> There isn't any connection between the Scala version that sbt uses
>> internally and the Scala version (or versions, plural!) that it builds
>> your project with.
>
>
> This is only partially true because SBT relies on compiler API that is
> semi-public and it breaks when that API is changed.
>
> Best,
> Ismael
>
>
>
> Josh Suereth <joshua.suereth@gmail.com> Aug 04 01:59PM -0400 ^
>
> Hey Bill,
>
> I think others may have already stated this, but SBT separates classpaths so
> you don't have nested Scala dependencies. I'm actually bootstrapping Scala
> with SBT right now, and things are working out well. The only dependency is
> the JVM. If you have time sometime this week, feel free to google+ me or
> call. I'd love to describe the plans we have to aggregate a whole ton of
> projects into a gianormous nightly marathon.
>
> - Josh
>
>
>
>
> Seth Tisue <sethtisue@gmail.com> Aug 04 11:13AM -0700 ^
>
> On Thursday, August 4, 2011 1:47:48 PM UTC-4, ijuma wrote:
>>> your project with.
>
>> This is only partially true because SBT relies on compiler API that is
>> semi-public and it breaks when that API is changed.
>
> Shhhhhhhh!!!! We're trying to convince Bill :-)
>
> Yeah, it has happened (sbt 2.7.7 + Scala 2.9.1.RC1 = boom), but only very
> rarely.
>
> --
> Seth Tisue | Northwestern University | http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>
>
>
> joshcough <joshcough@gmail.com> Aug 04 11:24AM -0700 ^
>
> I have ScalaTest branches from two or three years ago that I could
> revive. I could also try to migrate them to sbt 0.10. I couldn't turn
> around and have it done by tomorrow, but I could get it done within a
> week I think.
>
> Here is one such branch:
> http://code.google.com/p/scalatest/source/browse/#svn%2Fbranches%2Fjosh-sbt-2
>
>
>
>
>
>  Topic: Collections Testsuite needed?
>
> "Rüdiger Keller" <ruediger.keller@googlemail.com> Aug 04 02:50PM +0200 ^
>
> Hi,
>
> I just checked in my first steps of the collections test suite based
> on sbt 0.10 and scalacheck.
>
> https://github.com/ruedigerk/collection-tests
>
> Feedback is welcome.
>
> Regards,
> Rüdiger
>
>
>
>
>
>  Topic: Mismatched symbols in
> scala.collection.parallel.package.CompositeThrowable
>
> Josh Suereth <joshua.suereth@gmail.com> Aug 04 08:13AM -0400 ^
>
> Somehow I think this breaks binary compatibility :(
>
> Still, this is *awesome*. I'd love to have this in 2.10!
>
>
>



--
Bill Venners
Artima, Inc.
http://www.artima.com

I'd love to be able to run the tests in the 'mambo' build.  That's the idea is to catch as many Scala bugs as possible 'nightly' or semi-nightly.
I'll get the requirements document out soon.  Right now I'm having a few people look at it to make sure I didn't miss anything.

On Fri, Aug 5, 2011 at 2:58 PM, Josh Cough <joshcough@gmail.com> wrote:

On Fri, Aug 5, 2011 at 1:14 PM, Bill Venners <bill@artima.com> wrote:

Hi All,

I'm on digest of this list so I don't see these until the next
morning. I had not made the connection about sbt using an earlier
Scala version meaning I'm not dependent on a new build of it. That was
the main reason I didn't switch over. The other was, though, simply
that the ant build works and time invested moving over to sbt is time
I don't spend doing something that actually adds value to ScalaTest
for users.

What could be a good first step is a parallel sbt build that just
builds and possibly deploys. We have a lot of other stuff in our ant
file that need not be moved over necessarily. 

Josh if you want to take
a stab at bringing the sbt build you did previously up to date that
would be great. At the very least it could support whatever Josh is
thinking about for the mambo-build. Josh what would you need for the
mambo build?

I don't know what mambo is. Am i missing something? 

ScalaTest itself does not take long to compile, but its
tests of itself take a very long time and a lot of memory. So much
that I tend to do it in steps. First I compile without MustMatchers,
then I generate MustMatchers and recompile again. One thing we could
do with the sbt build is just build ScalaTest and not worry about its
tests of itself. Though if you're looking to see if changes to Scala
break things, then compiling those tests would be a good "test" for
Scala itself. Some Scala bugs that ScalaTest has uncovered have shown
up only in the tests.

To the best of my knowledge, I was able to do the full build, and run all of the tests. This included generating the MustMatchers. I did a thorough job. I will try to achieve all of that again.   One more thought:  Parallel ant/sbt builds are fine for now, but please allow me to suggest moving entirely to sbt, especially if I can get most or all of what you have in ant into the sbt build. Maintaining two build systems seems like something that will only lead to trouble. I'm willing to implement and support it. 

Bill

On Fri, Aug 5, 2011 at 8:06 AM,
<2Bnoreply [at] googlegroups [dot] com" target="_blank" rel="nofollow">scala-internals+noreply@googlegroups.com> wrote:
>   Today's Topic Summary
>
> Group: http://groups.google.com/group/scala-internals/topics
>
> Digest for scala-internals@googlegroups.com - 6 Messages in 1 Topic [7
> Updates]
> Collections Testsuite needed? [1 Update]
> Mismatched symbols in scala.collection.parallel.package.CompositeThrowable
> [1 Update]
>
>  Topic: Digest for scala-internals@googlegroups.com - 6 Messages in 1 Topic
>
> Bill Venners <bill@artima.com> Aug 04 09:56AM -0700 ^
>
> Hi All,
>
> I just noticed this conversation. ScalaTest builds with ant, not sbt,
> and I never plan to make ScalaTest depend on sbt. Although I'd prefer
> to use sbt over ant in general, of course, I want to minimize the
> Scala libraries that ScalaTest depends on, so I can get new ScalaTest
> releases out quickly after Scala releases come out. My only Scala
> library dependency currently is ScalaCheck, so I only need to wait for
> that one. As a result I think ScalaTest should be easy to integrate
> into the Scala build if you want to. You need not build and run the
> tests. That takes a long time. You could just build the tool itself,
> which is relatively quick. If you want it to be sbt 0.10, we could add
> a parallel build that just builds the tool and nothing else via sbt
> and add that to the project.
>
> Where are the current collections tests, by the way? Are they up on
> github somewhere? I'd like to take a look at them.
>
> Thanks.
>
> Bill
>
> On Wed, Aug 3, 2011 at 6:16 AM,
>
> --
> Bill Venners
> Artima, Inc.
> http://www.artima.com
>
>
>
> Seth Tisue <seth@tisue.net> Aug 04 01:08PM -0400 ^
>
>> to use sbt over ant in general, of course, I want to minimize the
>> Scala libraries that ScalaTest depends on, so I can get new ScalaTest
>> releases out quickly after Scala releases come out.
>
> There isn't any connection between the Scala version that sbt uses
> internally and the Scala version (or versions, plural!) that it builds
> your project with. So when a new Scala version comes out, you don't
> need to wait for anything. You just keep using the sbt you were
> already using, and just tell it to including the new Scala version in
> your cross-build. It's not a problem.
>
> Furthermore, sbt has very good support for cross-building, so once you
> get it set up, it's nearly effortless to build and publish releases
> for all of the Scala versions you support.
>
> --
> Seth Tisue | Northwestern University | http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>
>
>
> Ismael Juma <ismael@juma.me.uk> Aug 04 06:08PM +0100 ^
>
>> to use sbt over ant in general, of course, I want to minimize the
>> Scala libraries that ScalaTest depends on, so I can get new ScalaTest
>> releases out quickly after Scala releases come out.
>
> Since Scala will itself depend on sbt to build, it seems to me that
> your releases won't be delayed if you depend on sbt.
>
> Best,
> Ismael
>
>
>
> Ismael Juma <ismael@juma.me.uk> Aug 04 06:47PM +0100 ^
>
>
>> There isn't any connection between the Scala version that sbt uses
>> internally and the Scala version (or versions, plural!) that it builds
>> your project with.
>
>
> This is only partially true because SBT relies on compiler API that is
> semi-public and it breaks when that API is changed.
>
> Best,
> Ismael
>
>
>
> Josh Suereth <joshua.suereth@gmail.com> Aug 04 01:59PM -0400 ^
>
> Hey Bill,
>
> I think others may have already stated this, but SBT separates classpaths so
> you don't have nested Scala dependencies. I'm actually bootstrapping Scala
> with SBT right now, and things are working out well. The only dependency is
> the JVM. If you have time sometime this week, feel free to google+ me or
> call. I'd love to describe the plans we have to aggregate a whole ton of
> projects into a gianormous nightly marathon.
>
> - Josh
>
>
>
>
> Seth Tisue <sethtisue@gmail.com> Aug 04 11:13AM -0700 ^
>
> On Thursday, August 4, 2011 1:47:48 PM UTC-4, ijuma wrote:
>>> your project with.
>
>> This is only partially true because SBT relies on compiler API that is
>> semi-public and it breaks when that API is changed.
>
> Shhhhhhhh!!!! We're trying to convince Bill :-)
>
> Yeah, it has happened (sbt 2.7.7 + Scala 2.9.1.RC1 = boom), but only very
> rarely.
>
> --
> Seth Tisue | Northwestern University | http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>
>
>
> joshcough <joshcough@gmail.com> Aug 04 11:24AM -0700 ^
>
> I have ScalaTest branches from two or three years ago that I could
> revive. I could also try to migrate them to sbt 0.10. I couldn't turn
> around and have it done by tomorrow, but I could get it done within a
> week I think.
>
> Here is one such branch:
> http://code.google.com/p/scalatest/source/browse/#svn%2Fbranches%2Fjosh-sbt-2
>
>
>
>
>
>  Topic: Collections Testsuite needed?
>
> "Rüdiger Keller" <ruediger.keller@googlemail.com> Aug 04 02:50PM +0200 ^
>
> Hi,
>
> I just checked in my first steps of the collections test suite based
> on sbt 0.10 and scalacheck.
>
> https://github.com/ruedigerk/collection-tests
>
> Feedback is welcome.
>
> Regards,
> Rüdiger
>
>
>
>
>
>  Topic: Mismatched symbols in
> scala.collection.parallel.package.CompositeThrowable
>
> Josh Suereth <joshua.suereth@gmail.com> Aug 04 08:13AM -0400 ^
>
> Somehow I think this breaks binary compatibility :(
>
> Still, this is *awesome*. I'd love to have this in 2.10!
>
>
>



--
Bill Venners
Artima, Inc.
http://www.artima.com