RC2 candidate for the first 2.8.0 beta

The Lift 280_port branch is up to date with the latest beta.

On Wed, Nov 25, 2009 at 1:41 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

All,

The second release candidate for 2.8.0.Beta1 is available for testing; several bugs found in the previous candidate have been fixed. You can obtain this candidate from the links below, as well as from the scala-tools.org Maven repository:

http://www.scala-lang.org/downloads/distrib/files/scala-2.8.0.Beta1-RC2.tgz
http://www.scala-lang.org/downloads/distrib/files/scala-2.8.0.Beta1-RC2.zip
http://www.scala-lang.org/downloads/distrib/files/scala-2.8.0.Beta1-RC2-installer.jar
http://www.scala-lang.org/downloads/distrib/files/scala-2.8.0.Beta1-RC2-jvm5.tgz
http://www.scala-lang.org/downloads/distrib/files/scala-2.8.0.Beta1-RC2-devel-docs.tgz
http://www.scala-lang.org/downloads/distrib/files/scala-2.8.0.Beta1-RC2-sources.tgz
http://www.scala-lang.org/downloads/distrib/files/scala.library_2.8.0.Beta1-RC2.jar

This is a candidate for the first, preliminary beta release of 2.8.0: it is  only intended to help developers port their code onto the new 2.8 codebase, and it is not production-quality code.

Developers: please try your projects against this initial version and let us know. This candidate is also built without optimization; if there are no reports of significant problems with this version, we will proceed with the subsequent release of an optimized RC3.

Please let us know your status!
Toni

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Antonio Cunei wrote:
> All,
>
> The second release candidate for 2.8.0.Beta1 is available for testing;
> several bugs found in the previous candidate have been fixed. You can
> obtain this candidate from the links below, as well as from the
> scala-tools.org Maven repository:

Great!

With the change in annotations from

@Test { val expected = classOf[Foo] }

to

@Test(expected=classOf[Foo])

plus some other minor changes Scala Migrations compiles and passes its test suite.

Should the following compile, it does in 2.7.7, but in this release it says:

class Test
{
def foo(): Int =
{
val i = 10
case class Foo(j: Int)
i
}
}

t3.scala:6: error: forward reference extends over definition of value i
case class Foo(j: Int)
^
one error found

Granted, it isn't great style, but I like declaring local case classes in
complicated methods just before I use the class. The real code is here; look
for "case class InstallRemove":

http://code.google.com/p/scala-migrations/source/browse/src/main/scala/c...

I can move the case class definition before val's to fix this, but this seems
like a restriction in the language.

Blair

On Thu, Nov 26, 2009 at 3:31 AM, Blair Zajac wrote:
> Antonio Cunei wrote:
>>
>> All,
>>
>> The second release candidate for 2.8.0.Beta1 is available for testing;
>> several bugs found in the previous candidate have been fixed. You can obtain
>> this candidate from the links below, as well as from the scala-tools.org
>> Maven repository:
>
> Great!
>
> With the change in annotations from
>
>  @Test { val expected = classOf[Foo] }
>
> to
>
>  @Test(expected=classOf[Foo])
>
> plus some other minor changes Scala Migrations compiles and passes its test
> suite.
>
> Should the following compile, it does in 2.7.7, but in this release it says:
>
> class Test
> {
>  def foo(): Int =
>  {
>    val i = 10
>    case class Foo(j: Int)
>    i
>  }
> }
>
>  t3.scala:6: error: forward reference extends over definition of value i
>      case class Foo(j: Int)
>               ^
>  one error found
>
It should compile. I'll look into it.

I'm pretty sure this bug is caused by my "fix" to
  http://lampsvn.epfl.ch/trac/scala/ticket/2489

Synthetic members (enterSyntheticSym in Namers) are now added
to the beginning of a statement-list:
  http://lampsvn.epfl.ch/trac/scala/changeset/19561

Lukas



On Thu, Nov 26, 2009 at 07:27, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, Nov 26, 2009 at 3:31 AM, Blair Zajac <blair@orcaware.com> wrote:
> Antonio Cunei wrote:
>>
>> All,
>>
>> The second release candidate for 2.8.0.Beta1 is available for testing;
>> several bugs found in the previous candidate have been fixed. You can obtain
>> this candidate from the links below, as well as from the scala-tools.org
>> Maven repository:
>
> Great!
>
> With the change in annotations from
>
>  @Test { val expected = classOf[Foo] }
>
> to
>
>  @Test(expected=classOf[Foo])
>
> plus some other minor changes Scala Migrations compiles and passes its test
> suite.
>
> Should the following compile, it does in 2.7.7, but in this release it says:
>
> class Test
> {
>  def foo(): Int =
>  {
>    val i = 10
>    case class Foo(j: Int)
>    i
>  }
> }
>
>  t3.scala:6: error: forward reference extends over definition of value i
>      case class Foo(j: Int)
>               ^
>  one error found
>
It should compile. I'll look into it.

Confirmed. Putting synthetics first generates:

def foo {
  object Foo { def apply() = new Foo }
  val i = 1
  class Foo()
}

Forward reference to "class Foo" in the factory. I'll fix this.

Lukas


On Thu, Nov 26, 2009 at 08:42, Lukas Rytz <lukas.rytz@epfl.ch> wrote:

I'm pretty sure this bug is caused by my "fix" to
  http://lampsvn.epfl.ch/trac/scala/ticket/2489

Synthetic members (enterSyntheticSym in Namers) are now added
to the beginning of a statement-list:
  http://lampsvn.epfl.ch/trac/scala/changeset/19561

Lukas



On Thu, Nov 26, 2009 at 07:27, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, Nov 26, 2009 at 3:31 AM, Blair Zajac <blair@orcaware.com> wrote:
> Antonio Cunei wrote:
>>
>> All,
>>
>> The second release candidate for 2.8.0.Beta1 is available for testing;
>> several bugs found in the previous candidate have been fixed. You can obtain
>> this candidate from the links below, as well as from the scala-tools.org
>> Maven repository:
>
> Great!
>
> With the change in annotations from
>
>  @Test { val expected = classOf[Foo] }
>
> to
>
>  @Test(expected=classOf[Foo])
>
> plus some other minor changes Scala Migrations compiles and passes its test
> suite.
>
> Should the following compile, it does in 2.7.7, but in this release it says:
>
> class Test
> {
>  def foo(): Int =
>  {
>    val i = 10
>    case class Foo(j: Int)
>    i
>  }
> }
>
>  t3.scala:6: error: forward reference extends over definition of value i
>      case class Foo(j: Int)
>               ^
>  one error found
>
It should compile. I'll look into it.

Antonio Cunei wrote:
> Developers: please try your projects against this initial version and
> let us know. This candidate is also built without optimization; if there

ScalaQuery builds and passes all unit tests with both RC1 and RC2. I had
to add one new type annotation for RC2. The situation is similar to this:

def f[T](g: String => T): T = g("")
def f[T](g: => T): T = f { s: String => g }
f(0)
f(s => 0) /* s requires type annotation */

This simplified example already fails in RC1, so it's probably not
considered a bug. I don't know what the difference is but the real code
works without the annotation in RC1 (and earlier builds).

(Trunk is a different matter. Since 20091126 I'm getting bad classfiles
and subtle test case failures.)

Lukas,

Should I open a ticket to track this?

Regards,
Blair

On Nov 26, 2009, at 3:04 AM, Lukas Rytz wrote:

> Confirmed. Putting synthetics first generates:
>
> def foo {
> object Foo { def apply() = new Foo }
> val i = 1
> class Foo()
> }
>
> Forward reference to "class Foo" in the factory. I'll fix this.
>
> Lukas
>
>
> On Thu, Nov 26, 2009 at 08:42, Lukas Rytz wrote:
> I'm pretty sure this bug is caused by my "fix" to
> http://lampsvn.epfl.ch/trac/scala/ticket/2489
>
> Synthetic members (enterSyntheticSym in Namers) are now added
> to the beginning of a statement-list:
> http://lampsvn.epfl.ch/trac/scala/changeset/19561
>
> Lukas
>
>
>
>
> On Thu, Nov 26, 2009 at 07:27, martin odersky wrote:
> On Thu, Nov 26, 2009 at 3:31 AM, Blair Zajac wrote:
> > Antonio Cunei wrote:
> >>
> >> All,
> >>
> >> The second release candidate for 2.8.0.Beta1 is available for testing;
> >> several bugs found in the previous candidate have been fixed. You can obtain
> >> this candidate from the links below, as well as from the scala-tools.org
> >> Maven repository:
> >
> > Great!
> >
> > With the change in annotations from
> >
> > @Test { val expected = classOf[Foo] }
> >
> > to
> >
> > @Test(expected=classOf[Foo])
> >
> > plus some other minor changes Scala Migrations compiles and passes its test
> > suite.
> >
> > Should the following compile, it does in 2.7.7, but in this release it says:
> >
> > class Test
> > {
> > def foo(): Int =
> > {
> > val i = 10
> > case class Foo(j: Int)
> > i
> > }
> > }
> >
> > t3.scala:6: error: forward reference extends over definition of value i
> > case class Foo(j: Int)
> > ^
> > one error found
> >
> It should compile. I'll look into it.
>

> This is a candidate for the first, preliminary beta release of 2.8.0: it is
> only intended to help developers port their code onto the new 2.8
> codebase, and it is not production-quality code.
>
> Developers: please try your projects against this initial version and let
> us know. This candidate is also built without optimization; if there are no
> reports of significant problems with this version, we will proceed with the
> subsequent release of an optimized RC3.

I'm disappointed to see substantial, pre-planned changes (scaladoc 2) checked
in during what I expected to be a stabilization phase. Why did the release
process start before all features were in?

I understand the separate steps for unoptimized and optimized, but if there
are other big planned changes coming (specialization of the library and
compiler?), please wait until they are all in before publishing more
snapshots.

-Mark

On Sat, 2009-11-28 at 22:57 -0500, Mark Harrah wrote:
> I'm disappointed to see substantial, pre-planned changes (scaladoc 2) checked
> in during what I expected to be a stabilization phase. Why did the release
> process start before all features were in?
>
> I understand the separate steps for unoptimized and optimized, but if there
> are other big planned changes coming (specialization of the library and
> compiler?), please wait until they are all in before publishing more
> snapshots.

I think it's not as black and white as you suggest. It's not easy to
track problems when there are lots of changes interacting with each
other. As such, I believe it's good to have alpha releases (which is
what these beta candidates are, pretty much) that allow some coordinated
testing.

The expectation would be that the code would generally work after the
first porting effort. If it doesn't, then it's likely a regression
(which should be reported) or a change that was necessary but may not
have been apparent without input and testing from the community.

Specialization (to use your example) is similar to -optimise in that
user code should behave the same, just faster.

Personally, I'd like to see a snapshot where all the low-level
dependencies (scalacheck, scalatest, specs, configgy) compile and run
their own tests successfully before -optimise and specialisation are
enabled.

Best,
Ismael

On Sun, Nov 29, 2009 at 9:11 AM, Ismael Juma wrote:
> Personally, I'd like to see a snapshot where all the low-level
> dependencies (scalacheck, scalatest, specs, configgy) compile and run
> their own tests successfully before -optimise and specialisation are
> enabled.
Oh, yes, please! I tried to build my project with 2.8 but couldn't run
the tests because I couldn't get a recent specs version running with
maven. If someone manages to get the complete specs/scalatest/scala
chain running with maven, please post the versions you used.

The point with ScalaDoc was that we needed something new to properly
document the collection libraries. The old ScalaDoc simply was too
restrictive to do it. I realized too late that the new ScalaDoc was
not exactly release quality. I propose therefore to partly revert and
have the new and old ScalaDoc exists as alternatoves for a while.

There are no other major changes planned for the final beta.

Cheers

No it's already fixed in trunk.

On Sat, Nov 28, 2009 at 21:25, Blair Zajac <blair@orcaware.com> wrote:

Lukas,

Should I open a ticket to track this?

Regards,
Blair

On Nov 26, 2009, at 3:04 AM, Lukas Rytz wrote:

> Confirmed. Putting synthetics first generates:
>
> def foo {
>   object Foo { def apply() = new Foo }
>   val i = 1
>   class Foo()
> }
>
> Forward reference to "class Foo" in the factory. I'll fix this.
>
> Lukas
>
>
> On Thu, Nov 26, 2009 at 08:42, Lukas Rytz <lukas.rytz@epfl.ch> wrote:
> I'm pretty sure this bug is caused by my "fix" to
>   http://lampsvn.epfl.ch/trac/scala/ticket/2489
>
> Synthetic members (enterSyntheticSym in Namers) are now added
> to the beginning of a statement-list:
>   http://lampsvn.epfl.ch/trac/scala/changeset/19561
>
> Lukas
>
>
>
>
> On Thu, Nov 26, 2009 at 07:27, martin odersky <martin.odersky@epfl.ch> wrote:
> On Thu, Nov 26, 2009 at 3:31 AM, Blair Zajac <blair@orcaware.com> wrote:
> > Antonio Cunei wrote:
> >>
> >> All,
> >>
> >> The second release candidate for 2.8.0.Beta1 is available for testing;
> >> several bugs found in the previous candidate have been fixed. You can obtain
> >> this candidate from the links below, as well as from the scala-tools.org
> >> Maven repository:
> >
> > Great!
> >
> > With the change in annotations from
> >
> >  @Test { val expected = classOf[Foo] }
> >
> > to
> >
> >  @Test(expected=classOf[Foo])
> >
> > plus some other minor changes Scala Migrations compiles and passes its test
> > suite.
> >
> > Should the following compile, it does in 2.7.7, but in this release it says:
> >
> > class Test
> > {
> >  def foo(): Int =
> >  {
> >    val i = 10
> >    case class Foo(j: Int)
> >    i
> >  }
> > }
> >
> >  t3.scala:6: error: forward reference extends over definition of value i
> >      case class Foo(j: Int)
> >               ^
> >  one error found
> >
> It should compile. I'll look into it.
>
>  -- Martin
>
>

Ismael, Martin,

Thanks for the responses...

On Sunday 29 November 2009, martin odersky wrote:
> The point with ScalaDoc was that we needed something new to properly
> document the collection libraries. The old ScalaDoc simply was too
> restrictive to do it. I realized too late that the new ScalaDoc was
> not exactly release quality. I propose therefore to partly revert and
> have the new and old ScalaDoc exists as alternatoves for a while.

For me, the problem isn't whether ScalaDoc is ready, but that it was a planned
change introduced after the stabilization process was started. (Despite it
being incomplete, I personally would pick the new ScalaDoc over the old
version given the choice.)

The change means I have to target a new interface (or a new and an old
interface) in sbt, now. This is normally fine of course, I'm just saying that
since it was planned, it should have gone in before starting the release
process.

> There are no other major changes planned for the final beta.

Ok, thanks.

> On Sun, Nov 29, 2009 at 9:11 AM, Ismael Juma wrote:
> > On Sat, 2009-11-28 at 22:57 -0500, Mark Harrah wrote:
> >> I'm disappointed to see substantial, pre-planned changes (scaladoc 2)
> >> checked in during what I expected to be a stabilization phase. Why did
> >> the release process start before all features were in?
> >>
> >> I understand the separate steps for unoptimized and optimized, but if
> >> there are other big planned changes coming (specialization of the
> >> library and compiler?), please wait until they are all in before
> >> publishing more snapshots.
> >
> > I think it's not as black and white as you suggest. It's not easy to
> > track problems when there are lots of changes interacting with each
> > other. As such, I believe it's good to have alpha releases (which is
> > what these beta candidates are, pretty much) that allow some coordinated
> > testing.
> >
> > The expectation would be that the code would generally work after the
> > first porting effort. If it doesn't, then it's likely a regression
> > (which should be reported) or a change that was necessary but may not
> > have been apparent without input and testing from the community.
> >
> > Specialization (to use your example) is similar to -optimise in that
> > user code should behave the same, just faster.

I agree with the above for libraries. I'm referring to planned changes that
make for a moving target for tool writers and specifically to these planned
changes happening at this time.

> > Personally, I'd like to see a snapshot where all the low-level
> > dependencies (scalacheck, scalatest, specs, configgy) compile and run
> > their own tests successfully before -optimise and specialisation are
> > enabled.

Sure, I agree (the part where I said "I understand the separate steps").
Specialized was in fact a bad example, since it has been in trunk for a while
and I would agree with a separate step for specialization.

-Mark

Add SBT to the low-level dependencies...

On Sun, Nov 29, 2009 at 6:11 AM, Ismael Juma <mlists@juma.me.uk> wrote:

On Sat, 2009-11-28 at 22:57 -0500, Mark Harrah wrote:
> I'm disappointed to see substantial, pre-planned changes (scaladoc 2) checked
> in during what I expected to be a stabilization phase.  Why did the release
> process start before all features were in?
>
> I understand the separate steps for unoptimized and optimized, but if there
> are other big planned changes coming (specialization of the library and
> compiler?), please wait until they are all in before publishing more
> snapshots.

I think it's not as black and white as you suggest. It's not easy to
track problems when there are lots of changes interacting with each
other. As such, I believe it's good to have alpha releases (which is
what these beta candidates are, pretty much) that allow some coordinated
testing.

The expectation would be that the code would generally work after the
first porting effort. If it doesn't, then it's likely a regression
(which should be reported) or a change that was necessary but may not
have been apparent without input and testing from the community.

Specialization (to use your example) is similar to -optimise in that
user code should behave the same, just faster.

Personally, I'd like to see a snapshot where all the low-level
dependencies (scalacheck, scalatest, specs, configgy) compile and run
their own tests successfully before -optimise and specialisation are
enabled.

Best,
Ismael

--
Daniel C. Sobral

I travel to the future all the time.

As one of the few people who manifested themselves publicly as not liking the new scaladoc, please, don't do this.
The new scaladoc is necessary, I understand that. Unfortunately, whenever two alternatives exists for the very same thing, effort is wasted and focus is lost.
Please, do not reintroduce the old scaladoc until and unless it is clear that Scala 2.8 cannot, at all, be released without it.

On Sun, Nov 29, 2009 at 8:14 AM, martin odersky <martin.odersky@epfl.ch> wrote:

The point with ScalaDoc was that we needed something new to properly
document the collection libraries. The old ScalaDoc simply was too
restrictive to do it.  I realized too late that the new ScalaDoc was
not exactly release quality. I propose therefore to partly revert and
have the new and old ScalaDoc exists as alternatoves for a while.

There are no other major changes planned for the final beta.

Cheers

On Sun, 2009-11-29 at 14:40 -0200, Daniel Sobral wrote:
> Add SBT to the low-level dependencies...

Definitely. The omission was not intentional.

Ismael

Hmm, I checked out trunk r19926 and built it and the last nightly r19928 and it's not working in either:

~/tmp/scala-2.8.0.r19928-b20091129020233$ ./bin/scala
Welcome to Scala version 2.8.0.r19928-b20091129020233 (Java HotSpot(TM) Server VM, Java 1.6.0_15).
Type in expressions to have them evaluated.
Type :help for more information.

scala> def foo {
| object Foo { def apply() = new Foo }
| val i = 1
| class Foo()
| }
:5: error: forward reference extends over definition of value i
object Foo { def apply() = new Foo }

Regards,
Blair

On Nov 29, 2009, at 3:07 AM, Lukas Rytz wrote:

> No it's already fixed in trunk.
>
> On Sat, Nov 28, 2009 at 21:25, Blair Zajac wrote:
> Lukas,
>
> Should I open a ticket to track this?
>
> Regards,
> Blair
>
> On Nov 26, 2009, at 3:04 AM, Lukas Rytz wrote:
>
> > Confirmed. Putting synthetics first generates:
> >
> >
> > object Foo { def apply() = new Foo }
> > val i = 1
> > class Foo()
> > }
> >
> > Forward reference to "class Foo" in the factory. I'll fix this.
> >
> > Lukas
> >
> >
> > On Thu, Nov 26, 2009 at 08:42, Lukas Rytz wrote:
> > I'm pretty sure this bug is caused by my "fix" to
> > http://lampsvn.epfl.ch/trac/scala/ticket/2489
> >
> > Synthetic members (enterSyntheticSym in Namers) are now added
> > to the beginning of a statement-list:
> > http://lampsvn.epfl.ch/trac/scala/changeset/19561
> >

Let me explain: your original example

 def foo(): Int = {
   val i = 1
   case class Foo(j: Int)
   i
 }

used to generate the following code in 2.7.x:

 def foo {
   val i = 1
   class Foo()
   object Foo { def apply() = new Foo }
   i
  }


after my change, trunk added the synthetic object to the beginning of the list of
statements, which created the forward reference "new Foo" extending over the definition
"val i = 1".

This has been fixed now. If you try your original example in trunk, it will work.

Lukas



On Mon, Nov 30, 2009 at 02:43, Blair Zajac <blair@orcaware.com> wrote:

Hmm, I checked out trunk r19926 and built it and the last nightly r19928 and it's not working in either:

~/tmp/scala-2.8.0.r19928-b20091129020233$ ./bin/scala
Welcome to Scala version 2.8.0.r19928-b20091129020233 (Java HotSpot(TM) Server VM, Java 1.6.0_15).
Type in expressions to have them evaluated.
Type :help for more information.

scala> def foo {
    |   object Foo { def apply() = new Foo }
    |   val i = 1
    |   class Foo()
    | }
<console>:5: error: forward reference extends over definition of value i
        object Foo { def apply() = new Foo }

Regards,
Blair

On Nov 29, 2009, at 3:07 AM, Lukas Rytz wrote:

> No it's already fixed in trunk.
>
> On Sat, Nov 28, 2009 at 21:25, Blair Zajac <blair@orcaware.com> wrote:
> Lukas,
>
> Should I open a ticket to track this?
>
> Regards,
> Blair
>
> On Nov 26, 2009, at 3:04 AM, Lukas Rytz wrote:
>
> > Confirmed. Putting synthetics first generates:
> >
> >
> >   object Foo { def apply() = new Foo }
> >   val i = 1
> >   class Foo()
> > }
> >
> > Forward reference to "class Foo" in the factory. I'll fix this.
> >
> > Lukas
> >
> >
> > On Thu, Nov 26, 2009 at 08:42, Lukas Rytz <lukas.rytz@epfl.ch> wrote:
> > I'm pretty sure this bug is caused by my "fix" to
> >   http://lampsvn.epfl.ch/trac/scala/ticket/2489
> >
> > Synthetic members (enterSyntheticSym in Namers) are now added
> > to the beginning of a statement-list:
> >   http://lampsvn.epfl.ch/trac/scala/changeset/19561
> >

Ahh, ok, thanks. Yes, it works in trunk.

Blair

On Nov 29, 2009, at 11:48 PM, Lukas Rytz wrote:

> Let me explain: your original example
>
> def foo(): Int = {
> val i = 1
> case class Foo(j: Int)
> i
> }
>
> used to generate the following code in 2.7.x:
>
> def foo {
> val i = 1
> class Foo()
> object Foo { def apply() = new Foo }
> i
> }
>
>
> after my change, trunk added the synthetic object to the beginning of the list of
> statements, which created the forward reference "new Foo" extending over the definition
> "val i = 1".
>
> This has been fixed now. If you try your original example in trunk, it will work.
>
> Lukas

On Sun, Nov 29, 2009 at 11:14:09AM +0100, martin odersky wrote:
> There are no other major changes planned for the final beta.

My life situation is such that I am having a terrible time getting
reasonable blocks of time in which to work, which has left me working on
a lot of low to medium priority items while the difficult yet high
priority ones continue to await extended concentration. As soon as
humanly possible I am going to send a list of items I think "should" be
done for 2.8, in quotes because there's no way I can do it all or even
most of it, so I'll need some input on priorities.

The pattern matcher still has serious bugs, which I understand but am
still not close enough to fixing. I am thinking now that the most
robust approach that I can do quickly (I hope) is to implement a very
naive transformation scheme which simply walks down the cases in order
(as used to exist long ago) and when situations like #313131 or #1697 or
their duplicates arise, fail over to that.

On Mon, Nov 30, 2009 at 4:30 PM, Paul Phillips wrote:
> On Sun, Nov 29, 2009 at 11:14:09AM +0100, martin odersky wrote:
>> There are no other major changes planned for the final beta.
>
> My life situation is such that I am having a terrible time getting
> reasonable blocks of time in which to work, which has left me working on
> a lot of low to medium priority items while the difficult yet high
> priority ones continue to await extended concentration.  As soon as
> humanly possible I am going to send a list of items I think "should" be
> done for 2.8, in quotes because there's no way I can do it all or even
> most of it, so I'll need some input on priorities.
>
> The pattern matcher still has serious bugs, which I understand but am
> still not close enough to fixing.  I am thinking now that the most
> robust approach that I can do quickly (I hope) is to implement a very
> naive transformation scheme which simply walks down the cases in order
> (as used to exist long ago) and when situations like #313131 or #1697 or
> their duplicates arise, fail over to that.
>
If there's nothing else that can be done, we'll probaby have to do it
that way. But please issue a fat compiler warning in that case.
Performance bugs are often worse than correctness bugs because they
are harder to diagnose.

Cheers

On Mon, Nov 30, 2009 at 04:41:42PM +0100, martin odersky wrote:
> If there's nothing else that can be done, we'll probaby have to do it
> that way. But please issue a fat compiler warning in that case.
> Performance bugs are often worse than correctness bugs because they
> are harder to diagnose.

In the case of #313131, yes, since the compiler just crashes. In the case
of #1697 it generates subtly incorrect bytecode, so anything would be an
improvement. However for sure I can complain loudly in both cases.

Hello.

Currently, Scaladoc 2 replaces the original Scaladoc in trunk only. It has not yet been ported to the branch from which 2.8 betas are built. As such, Scaladoc needn't interfere with the stabilisation process of the next 2.8 beta. In the original announcement, I had said that the 2.8 branch would use Scaladoc 2 immediately: this hadn't actually been decided, I am sorry for the incorrect statement.

In fact, the next 2.8 beta may be shipped with the old or the new Scaladoc. This will obviously depend on the amount of progress made on Scaladoc by then, and on comments by people who build against trunk. 2.8 beta may even contain both old and new Scaladoc, with an option to select which one to use.

I had assumed that Scaladoc does not represent a significant integration risk for 2.8. It is very different from library changes or language changes. I am aware of two kinds of programs that depend on Scaladoc: build tools and IDEs. In the former case, integration with Scaladoc 2 is trivial. In the latter, the change may be larger, but we are working with Miles to make IDE integration easy. Are there other programs that depend on Scaladoc that I should be aware of?

The release processes of Scaladoc and of the compiler and library are unrelated. It would have been possible to postpone the integration of Scaladoc 2 into trunk. However, as Martin mentioned, there is a strong incentive to integrate it now, to help documentation of new 2.8 libraries. Also, since the IDEs are not completely stable against 2.8 yet, Scaladoc integration fits right into their stabilisation process.

Arguably, human users of Scaladoc (readers of the documentations) may be "incompatible" with the new output for a while, but I don't think this is a problem of incompatibility in the sense used in this discussion.

Cheers,
Gilles.

> The point with ScalaDoc was that we needed something new to properly
> document the collection libraries. The old ScalaDoc simply was too
> restrictive to do it. I realized too late that the new ScalaDoc was
> not exactly release quality. I propose therefore to partly revert and
> have the new and old ScalaDoc exists as alternatoves for a while.
>
>>> I'm disappointed to see substantial, pre-planned changes (scaladoc 2) checked
>>> in during what I expected to be a stabilization phase. Why did the release
>>> process start before all features were in?
>>>
>>> I understand the separate steps for unoptimized and optimized, but if there
>>> are other big planned changes coming (specialization of the library and
>>> compiler?), please wait until they are all in before publishing more
>>> snapshots.
>>
>> I think it's not as black and white as you suggest. It's not easy to
>> track problems when there are lots of changes interacting with each
>> other. As such, I believe it's good to have alpha releases (which is
>> what these beta candidates are, pretty much) that allow some coordinated
>> testing.
>>
>> The expectation would be that the code would generally work after the
>> first porting effort. If it doesn't, then it's likely a regression
>> (which should be reported) or a change that was necessary but may not
>> have been apparent without input and testing from the community.
>>
>> Specialization (to use your example) is similar to -optimise in that
>> user code should behave the same, just faster.
>>
>> Personally, I'd like to see a snapshot where all the low-level
>> dependencies (scalacheck, scalatest, specs, configgy) compile and run
>> their own tests successfully before -optimise and specialisation are
>> enabled.

Hi Gilles,

I vote for Scaladoc 2 being the only scaladoc in 2.8, in its current state or
with improvements. I like the approach being taken to make documentation
easier to write and easier to maintain. I am happy to see a good effort
towards making the collections accessible. Changeset 19935 is a nice preview
in my opinion (& and should be replaced though, right?).

The only thing that I was trying to say in my email was that it would have
been preferable to have started the stabilization after planned features
(like Scaladoc) were merged. It was not intended to be a comment on its
suitability for inclusion in 2.8, only on the process.

I was not aware that trunk was not the same as the betas. This is my mistake.
sbt tries to support users building with any Scala version 2.7.2 or later, so
I must have been working off of a nightly snapshot in addition to the betas.

In any case, +1 to Scaladoc 2 in 2.8, sooner rather than later.

-Mark

On Tuesday 01 December 2009 11:58, Gilles Dubochet wrote:
> Hello.
>
> Currently, Scaladoc 2 replaces the original Scaladoc in trunk only. It has
not yet been ported to the branch from which 2.8 betas are built. As such,
Scaladoc needn't interfere with the stabilisation process of the next 2.8
beta. In the original announcement, I had said that the 2.8 branch would use
Scaladoc 2 immediately: this hadn't actually been decided, I am sorry for the
incorrect statement.
>
> In fact, the next 2.8 beta may be shipped with the old or the new Scaladoc.
This will obviously depend on the amount of progress made on Scaladoc by
then, and on comments by people who build against trunk. 2.8 beta may even
contain both old and new Scaladoc, with an option to select which one to use.
>
>
> I had assumed that Scaladoc does not represent a significant integration
risk for 2.8. It is very different from library changes or language changes.
I am aware of two kinds of programs that depend on Scaladoc: build tools and
IDEs. In the former case, integration with Scaladoc 2 is trivial. In the
latter, the change may be larger, but we are working with Miles to make IDE
integration easy. Are there other programs that depend on Scaladoc that I
should be aware of?
>
> The release processes of Scaladoc and of the compiler and library are
unrelated. It would have been possible to postpone the integration of
Scaladoc 2 into trunk. However, as Martin mentioned, there is a strong
incentive to integrate it now, to help documentation of new 2.8 libraries.
Also, since the IDEs are not completely stable against 2.8 yet, Scaladoc
integration fits right into their stabilisation process.
>
> Arguably, human users of Scaladoc (readers of the documentations) may
be "incompatible" with the new output for a while, but I don't think this is
a problem of incompatibility in the sense used in this discussion.
>
> Cheers,
> Gilles.
>
>
> > The point with ScalaDoc was that we needed something new to properly
> > document the collection libraries. The old ScalaDoc simply was too
> > restrictive to do it. I realized too late that the new ScalaDoc was
> > not exactly release quality. I propose therefore to partly revert and
> > have the new and old ScalaDoc exists as alternatoves for a while.
> >
> >>> I'm disappointed to see substantial, pre-planned changes (scaladoc 2)
checked
> >>> in during what I expected to be a stabilization phase. Why did the
release
> >>> process start before all features were in?
> >>>
> >>> I understand the separate steps for unoptimized and optimized, but if
there
> >>> are other big planned changes coming (specialization of the library and
> >>> compiler?), please wait until they are all in before publishing more
> >>> snapshots.
> >>
> >> I think it's not as black and white as you suggest. It's not easy to
> >> track problems when there are lots of changes interacting with each
> >> other. As such, I believe it's good to have alpha releases (which is
> >> what these beta candidates are, pretty much) that allow some coordinated
> >> testing.
> >>
> >> The expectation would be that the code would generally work after the
> >> first porting effort. If it doesn't, then it's likely a regression
> >> (which should be reported) or a change that was necessary but may not
> >> have been apparent without input and testing from the community.
> >>
> >> Specialization (to use your example) is similar to -optimise in that
> >> user code should behave the same, just faster.
> >>
> >> Personally, I'd like to see a snapshot where all the low-level
> >> dependencies (scalacheck, scalatest, specs, configgy) compile and run
> >> their own tests successfully before -optimise and specialisation are
> >> enabled.
>

> From: gilles.dubochet@epfl.ch
> Subject: Re: [scala-internals] RC2 candidate for the first 2.8.0 beta
> Date: Tue, 1 Dec 2009 17:58:33 +0100
> To: scala-internals@listes.epfl.ch

> I had assumed that Scaladoc does not represent a significant integration risk for 2.8. It is very different from library changes
> or language changes. I am aware of two kinds of programs that depend on Scaladoc: build tools and IDEs. In the former
> case, integration with Scaladoc 2 is trivial. In the latter, the change may be larger, but we are working with Miles to make
> IDE integration easy. Are there other programs that depend on Scaladoc that I should be aware of?

Well, there's all the other IDEs that aren't Eclipse for example. Or has Miles' workload just increased?


View your other email accounts from your Hotmail inbox. Add them now.

> > I had assumed that Scaladoc does not represent a significant integration risk for 2.8. It is very different from library changes
> > or language changes. I am aware of two kinds of programs that depend on Scaladoc: build tools and IDEs. In the former
> > case, integration with Scaladoc 2 is trivial. In the latter, the change may be larger, but we are working with Miles to make
> > IDE integration easy. Are there other programs that depend on Scaladoc that I should be aware of?
>
> Well, there's all the other IDEs that aren't Eclipse for example. Or has Miles' workload just increased?

By "making IDE integration easy" I mean, of course, integration for all IDEs. Miles is giving his opinion on the matter, but the compiler's comment access API won't be Eclipse-specific.

Cheers,
Gilles.

On Wed, Dec 2, 2009 at 9:46 AM, christopher marshall
wrote:
>> In the latter, the change may be larger, but we are working with Miles to make
>> IDE integration easy. Are there other programs that depend on Scaladoc
>> that I should be aware of?
>
> Well, there's all the other IDEs that aren't Eclipse for example. Or has
> Miles' workload just increased?

We're trying as hard a possible to make infrastructure that can be
shared by all the IDEs and other tools.

In this particular case the plan is to provide IDE-independent API
which will map Scaladoc 2 in wiki markup format into Javadoc format.
The latter should be feedable into any existing API which expects to
see Javadoc.

Cheers,

Miles