To all committers: upcoming 2.9.0 RC1

On 2/8/11 9:46 AM, Antonio Cunei wrote:
> We are now getting closer to the release of the first release candidate
> for the new 2.9.0. If there are no major obstacles, we could in theory
> issue a first RC as soon as next week.
>
> At this time, we ask all committers and core contributors to let us know
> whether they still have any pending work on the compiler code base or on
> the system libraries that they think it is essential to complete before
> 2.9.0.RC1. Also, if there are any unfixed bugs in trunk that you
> consider critical for some reason, this is the time to call for our
> attention.
>
> Conversely, if there is any code in trunk that should *not* be part of
> 2.9.0 (for instance because it can't be polished in time for the
> release), please let me know at this time so that we can deal with it
> appropriately. We will prepare more detailed release notes, detailing
> exactly what is new, once the code base is in good shape for the RC1
> release.

I think it will consume all my time into next week just to fully answer
the question.

My mind reels just contemplating it.

I will try to answer this question more usefully in the near future.

I'm still working on the Compiler plugin "with flags" trait that will help IDEs configure scalac plugins.  I think I might be able to clean it up this weekend and have it ready for commit.

On Tue, Feb 8, 2011 at 12:46 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

All,

We are now getting closer to the release of the first release candidate for the new 2.9.0. If there are no major obstacles, we could in theory issue a first RC as soon as next week.

At this time, we ask all committers and core contributors to let us know whether they still have any pending work on the compiler code base or on the system libraries that they think it is essential to complete before 2.9.0.RC1. Also, if there are any unfixed bugs in trunk that you consider critical for some reason, this is the time to call for our attention.

All the code and the fixes that are currently in trunk will be included in the upcoming 2.9.0 RC1, and eventually in the final. If you are not sure whether your favorite issue has been addressed, you can try using a recent nightly build: http://www.scala-lang.org/node/212/distributions

Conversely, if there is any code in trunk that should *not* be part of 2.9.0 (for instance because it can't be polished in time for the release), please let me know at this time so that we can deal with it appropriately. We will prepare more detailed release notes, detailing exactly what is new, once the code base is in good shape for the RC1 release.

Committers: it's time to let us know your status!

Thanks,
Toni
Scala Team, EPFL

If I may make a humble suggestion... How about calling it an alpha, or at least beta?
-0xe1a

On 02/08/2011 10:46 AM, Antonio Cunei wrote:
> All,
>
> We are now getting closer to the release of the first release candidate
> for the new 2.9.0. If there are no major obstacles, we could in theory
> issue a first RC as soon as next week.
>
> At this time, we ask all committers and core contributors to let us know
> whether they still have any pending work on the compiler code base or on
> the system libraries that they think it is essential to complete before
> 2.9.0.RC1. Also, if there are any unfixed bugs in trunk that you
> consider critical for some reason, this is the time to call for our
> attention.

#3605 didn't make it into 2.8.1:

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

Would it be possible to get that into 2.9.0?

Thanks,

Derek

On Tue, Feb 8, 2011 at 8:39 PM, Derek Chen-Becker wrote:
> On 02/08/2011 10:46 AM, Antonio Cunei wrote:
>> All,
>>
>> We are now getting closer to the release of the first release candidate
>> for the new 2.9.0. If there are no major obstacles, we could in theory
>> issue a first RC as soon as next week.
>>
>> At this time, we ask all committers and core contributors to let us know
>> whether they still have any pending work on the compiler code base or on
>> the system libraries that they think it is essential to complete before
>> 2.9.0.RC1. Also, if there are any unfixed bugs in trunk that you
>> consider critical for some reason, this is the time to call for our
>> attention.
>
> #3605 didn't make it into 2.8.1:
>
> https://lampsvn.epfl.ch/trac/scala/ticket/3605
>
> Would it be possible to get that into 2.9.0?
>
If it's fixed in trunk it will automatically be in 2.9.0.

Cheers

What is wrong with just calling it an RC? It really is an RC, so why not call a spade a spade?

Donna

On Feb 8, 2011, at 8:03 PM, Alex Cruise wrote:

> If I may make a humble suggestion... How about calling it an alpha, or at least beta?

Alex, are you are suggesting calling it an alpha or beta and allowing some additional features to flesh out?

On Tue, Feb 8, 2011 at 3:25 PM, Donna Malayeri <lindydonna@gmail.com> wrote:

What is wrong with just calling it an RC?  It really is an RC, so why not call a spade a spade?

Donna

On Feb 8, 2011, at 8:03 PM, Alex Cruise wrote:

> If I may make a humble suggestion... How about calling it an alpha, or at least beta?

On Tue, Feb 8, 2011 at 12:43 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Alex, are you are suggesting calling it an alpha or beta and allowing some additional features to flesh out?

When the first thing labelled 2.9.0-* is tagged, built and announced, the number of people who are testing the 2.9.x code stream will dramatically increase.  Calling something an RC is a psychological signal that it's very close to production-ready, and I don't know that what's in trunk right now has seen sufficient real-world testing to meet that expectation.
It's purely psychological, but managing expectations is often worthwhile. :)
-0xe1a

I agree.  I also think allowing some time for new features to alter slightly, after some libraries/projects start toying with them is not a bad idea.  Especially the new Dynamic stuff.

On Tue, Feb 8, 2011 at 4:07 PM, Alex Cruise <alex@cluonflux.com> wrote:

On Tue, Feb 8, 2011 at 12:43 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Alex, are you are suggesting calling it an alpha or beta and allowing some additional features to flesh out?

When the first thing labelled 2.9.0-* is tagged, built and announced, the number of people who are testing the 2.9.x code stream will dramatically increase.  Calling something an RC is a psychological signal that it's very close to production-ready, and I don't know that what's in trunk right now has seen sufficient real-world testing to meet that expectation.
It's purely psychological, but managing expectations is often worthwhile. :)
-0xe1a

On 2/8/11 1:07 PM, Alex Cruise wrote:
> When the first thing labelled 2.9.0-* is tagged, built and announced,
> the number of people who are testing the 2.9.x code stream will
> dramatically increase. Calling something an RC is a psychological
> signal that it's very close to production-ready, and I don't know that
> what's in trunk right now has seen sufficient real-world testing to meet
> that expectation.

Just as with all previous releases (see lengthy discussions from the
past) I am unambiguously against calling something an "RC" unless we
expect to ship it the way it is in the absence of new information. (The
condition could be a little weaker than that, but not a lot.) So far
I've lost this one.

Ok, so perhaps "beta" is a better name.

But here's an additional (possibly crazy) idea...

Following the long tradition of interesting codenames for a release or project, why not do the same for Scala releases? One idea: names based on famous staircases (http://en.wikipedia.org/wiki/Stairway#Notable_stairways).

For example:
2.8 Spiez
2.9 Mount Tai
3.0 Ha'iku (or "Haiku" for short)
3.1 Flørli
3.2 Penrose
etc

Donna

On Feb 8, 2011, at 11:00 PM, Paul Phillips wrote:

> On 2/8/11 1:07 PM, Alex Cruise wrote:
>> When the first thing labelled 2.9.0-* is tagged, built and announced,
>> the number of people who are testing the 2.9.x code stream will
>> dramatically increase. Calling something an RC is a psychological
>> signal that it's very close to production-ready, and I don't know that
>> what's in trunk right now has seen sufficient real-world testing to meet
>> that expectation.
>
> Just as with all previous releases (see lengthy discussions from the past) I am unambiguously against calling something an "RC" unless we expect to ship it the way it is in the absence of new information. (The condition could be a little weaker than that, but not a lot.) So far I've lost this one.

I like your not-so-crazy idea a lot :)

--
Christos KK Loverdos

On 9 Φεβ 2011, at 0:12, Donna Malayeri wrote:

> Ok, so perhaps "beta" is a better name.
>
> But here's an additional (possibly crazy) idea...
>
> Following the long tradition of interesting codenames for a release or project, why not do the same for Scala releases? One idea: names based on famous staircases (http://en.wikipedia.org/wiki/Stairway#Notable_stairways).
>
> For example:
> 2.8 Spiez
> 2.9 Mount Tai
> 3.0 Ha'iku (or "Haiku" for short)
> 3.1 Flørli
> 3.2 Penrose
> etc
>
> Donna
>
> On Feb 8, 2011, at 11:00 PM, Paul Phillips wrote:
>
>> On 2/8/11 1:07 PM, Alex Cruise wrote:
>>> When the first thing labelled 2.9.0-* is tagged, built and announced,
>>> the number of people who are testing the 2.9.x code stream will
>>> dramatically increase. Calling something an RC is a psychological
>>> signal that it's very close to production-ready, and I don't know that
>>> what's in trunk right now has seen sufficient real-world testing to meet
>>> that expectation.
>>
>> Just as with all previous releases (see lengthy discussions from the past) I am unambiguously against calling something an "RC" unless we expect to ship it the way it is in the absence of new information. (The condition could be a little weaker than that, but not a lot.) So far I've lost this one.
>

>>>>> "Donna" == Donna Malayeri writes:

Donna> perhaps "beta" is a better name.

+1

http://en.wikipedia.org/wiki/Software_release_life_cycle : "The term
release candidate (RC) refers to a version with potential to be a final
product." It's plan that the first 2.9 prerelease doesn't have a
snowball's chance in hell of becoming the final.

(And by the way, I'm very excited and pleased at the prospect of having
a prerelease to sink my teeth into! So far I've done no testing at all
of 2.9, since there isn't a ScalaTest build for 2.9 yet. I imagine that
once there is a prerelease of some kind -- by any name or number -- Bill
V. will build ScalaTest for it, and then I can begin testing and so can
many others.)

I like the codenames. It makes a version "mean" something, to some extent. Of course, major and minor versions only.

On Tue, Feb 8, 2011 at 20:12, Donna Malayeri <lindydonna@gmail.com> wrote:

Ok, so perhaps "beta" is a better name.

But here's an additional (possibly crazy) idea...

Following the long tradition of interesting codenames for a release or project, why not do the same for Scala releases?  One idea: names based on famous staircases (http://en.wikipedia.org/wiki/Stairway#Notable_stairways).

For example:
2.8 Spiez
2.9 Mount Tai
3.0 Ha'iku (or "Haiku" for short)
3.1 Flørli
3.2 Penrose
etc

Donna

On Feb 8, 2011, at 11:00 PM, Paul Phillips wrote:

> On 2/8/11 1:07 PM, Alex Cruise wrote:
>> When the first thing labelled 2.9.0-* is tagged, built and announced,
>> the number of people who are testing the 2.9.x code stream will
>> dramatically increase.  Calling something an RC is a psychological
>> signal that it's very close to production-ready, and I don't know that
>> what's in trunk right now has seen sufficient real-world testing to meet
>> that expectation.
>
> Just as with all previous releases (see lengthy discussions from the past) I am unambiguously against calling something an "RC" unless we expect to ship it the way it is in the absence of new information.  (The condition could be a little weaker than that, but not a lot.) So far I've lost this one.

--
Daniel C. Sobral

I travel to the future all the time.

Hi everyone!

What about TreeHashMap? (
https://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala...
)

Currently it is shipped with trunk, but it doesn't do anything.
Maybe it shouldn't be included in the 2.9 distribution (or be
activated again before that).

Bye,

Simon

Yes, that one is obsolete. We should definitely remove it.

Thanks,
hubert

On 02/09/2011 01:58 PM, Simon Ochsenreither wrote:
> Hi everyone!
>
> What about TreeHashMap? (
> https://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala...
> )
>
> Currently it is shipped with trunk, but it doesn't do anything.
> Maybe it shouldn't be included in the 2.9 distribution (or be
> activated again before that).
>
> Bye,
>
> Simon
>
>

Hi,
Personally, I would be against calling something RC unless you truly believe that you could potentially simply drop the RC suffix and ship that as the release. The point of a release candidate is that it *is* what you intend to release - that it is expected to become the release by fiat of simply renaming it by dropping 'release candidate', unless there are issues that require attention prior to release.
Since the 2.9.* series is ready for public consumption and testing, I'd strongly urge that it be put out as a beta. I expect that there are probably APIs and certainly implementation details that need tweaking in the light of real-world use, prior to declaring it a finished product, and we would not want to incorrectly imply that these details are set in stone and that it is safe to develop (or plan to develop) mission-critical applications against it.
Just my 2c
Matthew
--
Matthew Pocockmailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozer(0191) 2566550

On 08/02/2011 18:46, Antonio Cunei wrote:
> All,
>
> We are now getting closer to the release of the first release candidate
> for the new 2.9.0. If there are no major obstacles, we could in theory
> issue a first RC as soon as next week.
> [...]
> Conversely, if there is any code in trunk that should *not* be part of 2.9.0
> (for instance because it can't be polished in time for the release)
[...]

I'm a poor user and my vote is nowhere near binding, but I would love to
see "RC" on a version and be able to imply "that really code will be in
final, modulo some rare blocking bugs". On the other hand, if a lot of
code is still in flux, please don't name it RC, but beta or something
like that.

Again, it's just my point of vu as an user.

I fully agree that an RC is a release candidate. That's what we intend
to ship. The purpose of this pre-announcement was to give everyone a
wakeup call, that we do what needs to be done to get there before the
RC goes out, or, if that's not possible in time, stop the clock.

Cheers

On 2/8/11 9:46 AM, Antonio Cunei wrote:
> Committers: it's time to let us know your status!

- scala.sys.process: I still need to improve some names and document it.

- scala.Dynamic: while we don't necessarily need to go with any of my
ideas, I think it's inadequately baked in its current form. Specifics
in those emails.

- case class inheritance: if we are removing it as plocinic indicates in
#4109, then let's remove it. I'd like to do it because I can simplify
other code at the same time.

- Somebody in the world should know whether windows is working before we
start encouraging people to download things.

- I have doubts about the implementation of #3825 and think it should be
changed or removed.

- I think #4214 is alerting us to a serious issue which will take me
time to figure out. We now generate syntactically valid signatures, but
it was too much to hope that that would be enough. This is a big issue
with 2.8.0 and 2.8.1 and I think we should treat it as a blocker for
2.9.0. I will try to summarize the issue sometime soon.

- I have to fix the empty package thing with the repl.

- regression #4188 (almost surely mine) should be a blocker.

- scala.DelayedInit: I'm not convinced this is very baked either, but
that might be partly because the first few times I tried it were too
early, and as yet I'm still not entirely sure what the semantics are
supposed to be. It would be nice if there was some illustrative usage
in trunk other than the Application trait.

Here is an example. I'm not clear on what this should do, but it
doesn't seem right that all of A, B, and C below behave identically
(i.e. they all act like B.) There are three printlns added to
Application in obvious places.

trait A extends DelayedInit {
println("A")
}

trait B {
println("B")
}

trait C extends DelayedInit {
println("C")

def delayedInit(x: => Unit): Unit = {
println("C.delayedInit.")
x
}
}

object Bippy extends A with B with C with Application {
println("Bippy!")
}

// Output:
//
// A
// B
// C
// Application.delayedInit.
// Application entering main.
// Application executing a proc.
// Bippy!

The comment for def delayedInit in Application says "Instead it is
called as compiler-generated code for those classes, objects, and traits
that inherit from the `DelayedInit` trait and that do not themselves
define a `delayedInit` method." So at least trait A above ought to be in
that category, or at least someone reading that comment would think so.
How are these supposed to compose?

...

I will stop there but I admit that isn't remotely comprehensive. So
without getting into endless lists, I am particularly interested in
making sure the new marker traits don't leave us with regrets.

On Wed, Feb 9, 2011 at 22:53, Paul Phillips <paulp@improving.org> wrote:
 

- Somebody in the world should know whether windows is working before we start encouraging people to download things.

 Windows Vista 64:
Welcome to Scala version 2.9.0.r0-b20110207010216 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_23).
It hasn't run through the tests though (192MB isn't enough). I'm updating it right now and I'll ensure the tests are run. If anything comes up, I'll get in touch. 

- scala.DelayedInit: I'm not convinced this is very baked either, but that might be partly because the first few times I tried it were too early, and as yet I'm still not entirely sure what the semantics are supposed to be.  It would be nice if there was some illustrative usage in trunk other than the Application trait.

I wonder if it would be possible to make the Application "fix" without actually exposing the DelayedInit API at this time? 
--
Daniel C. Sobral

I travel to the future all the time.

On 02/10/2011 01:53 AM, Paul Phillips wrote:
> - case class inheritance: if we are removing it as plocinic indicates
> in #4109, then let's remove it. I'd like to do it because I can
> simplify other code at the same time.

I wasn't sure if I should go ahead with that as I was stopped from
removing all the deprecated things for 2.9 at some point.

So just say a word and I will make your wish come true.

Thanks,
hubert

I think we concluded that we'd wait for the next release before
removing things that were deprecated in 2.8. Things deprecated earlier
can be removed now. Since we deprecated case classes in 2.8 (right?)
we need to leave them in, by that logic.

On 02/10/2011 12:28 PM, martin odersky wrote:
> I think we concluded that we'd wait for the next release before
> removing things that were deprecated in 2.8. Things deprecated earlier
> can be removed now. Since we deprecated case classes in 2.8 (right?)
> we need to leave them in, by that logic.

A quick look into track shows r19206 (10/21/09) so yes, it was
deprecated in 2.8.
I'm wondering whether we shouldn't really make an exception here as case
class inheritance is just wrong and whoever is using it is just asking
for trouble.
Besides I doubt Paul will be willing to waste his time on fixing bugs
related to it (as it will be removed anyway) if any occurs (and I think
I have seen one or two in the meantime related exactly to it).

Thanks,
hubert

> -- Martin
>
> On Thu, Feb 10, 2011 at 12:23 PM, Hubert Plociniczak
> wrote:
>> On 02/10/2011 01:53 AM, Paul Phillips wrote:
>>> - case class inheritance: if we are removing it as plocinic indicates in
>>> #4109, then let's remove it. I'd like to do it because I can simplify other
>>> code at the same time.
>> I wasn't sure if I should go ahead with that as I was stopped from removing
>> all the deprecated things for 2.9 at some point.
>>
>> So just say a word and I will make your wish come true.
>>
>> Thanks,
>> hubert
>>
>>
>>
>
>

On Thu, Feb 10, 2011 at 12:42 PM, Hubert Plociniczak
wrote:
>
> On 02/10/2011 12:28 PM, martin odersky wrote:
>>
>> I think we concluded that we'd wait for the next release before
>> removing things that were deprecated in 2.8. Things deprecated earlier
>> can be removed now. Since we deprecated case classes in 2.8 (right?)
>> we need to leave them in, by that logic.
>
> A quick look into track shows r19206 (10/21/09) so yes, it was deprecated in
> 2.8.
> I'm wondering whether we shouldn't really make an exception here as case
> class inheritance is just wrong and whoever is using it is just asking for
> trouble.
> Besides I doubt Paul will be willing to waste his time on fixing bugs
> related to it (as it will be removed anyway) if any occurs (and I think I
> have seen one or two in the meantime related exactly to it).
>
I don't feel very strongly about it. Paul, do you think we should remove it now?

Cheers

I quite prefer more caution in removing features so quickly. This would make it that much harder for people to migrate code to 2.9. Perhaps the deprecation message can have a stronger warning, indicating that case class inheritance has known bugs.

That said, I agree with Hubert that it is not a good idea to waste time on case class inheritance bugs.

Donna

> On Thu, Feb 10, 2011 at 12:42 PM, Hubert Plociniczak
> wrote:
>>
>> On 02/10/2011 12:28 PM, martin odersky wrote:
>>>
>>> I think we concluded that we'd wait for the next release before
>>> removing things that were deprecated in 2.8. Things deprecated earlier
>>> can be removed now. Since we deprecated case classes in 2.8 (right?)
>>> we need to leave them in, by that logic.
>>
>> A quick look into track shows r19206 (10/21/09) so yes, it was deprecated in
>> 2.8.
>> I'm wondering whether we shouldn't really make an exception here as case
>> class inheritance is just wrong and whoever is using it is just asking for
>> trouble.
>> Besides I doubt Paul will be willing to waste his time on fixing bugs
>> related to it (as it will be removed anyway) if any occurs (and I think I
>> have seen one or two in the meantime related exactly to it).
>>
> I don't feel very strongly about it. Paul, do you think we should remove it now?
>
> Cheers
>

On Thu, Feb 10, 2011 at 1:53 AM, Paul Phillips wrote:
> On 2/8/11 9:46 AM, Antonio Cunei wrote:
>>
>> Committers: it's time to let us know your status!
>
> - scala.sys.process: I still need to improve some names and document it.
>
OK.

> - scala.Dynamic: while we don't necessarily need to go with any of my ideas,
> I think it's inadequately baked in its current form.  Specifics in those
> emails.

There was a long discussion about how to name the method, which has
been settled, I think.

I did not come back to your question about the refinement wrt
primitive types. Sorry that fell between the cracks. I'll do so ASAP.
If we still disagree afterwards we can postpone Dynamic. On the other
hand, given the excited uptake it has seen, I would only want to
remove it from 2.9 if we have good reasons.

>
> - case class inheritance: if we are removing it as plocinic indicates in
> #4109, then let's remove it.  I'd like to do it because I can simplify other
> code at the same time.
>
I'm with Donna on this one. Strenghten the warning but don't remove just yet.

> - Somebody in the world should know whether windows is working before we
> start encouraging people to download things.
>
> - I have doubts about the implementation of #3825 and think it should be
> changed or removed.
>
I am happy to see it removed for now, given that we want to revisit
PartialFunction after 2.9 is out.

> - I think #4214 is alerting us to a serious issue which will take me time to
> figure out.  We now generate syntactically valid signatures, but it was too
> much to hope that that would be enough.  This is a big issue with 2.8.0 and
> 2.8.1 and I think we should treat it as a blocker for 2.9.0.  I will try to
> summarize the issue sometime soon.
>

Yes, that looks like a blocker, I agree.

> - I have to fix the empty package thing with the repl.
>
> - regression #4188 (almost surely mine) should be a blocker.

Agreed.

>
> - scala.DelayedInit: I'm not convinced this is very baked either, but that
> might be partly because the first few times I tried it were too early, and
> as yet I'm still not entirely sure what the semantics are supposed to be.
>  It would be nice if there was some illustrative usage in trunk other than
> the Application trait.
>
> Here is an example.  I'm not clear on what this should do, but it doesn't
> seem right that all of A, B, and C below behave identically (i.e. they all
> act like B.) There are three printlns added to Application in obvious
> places.
>
>  trait A extends DelayedInit {
>    println("A")
>  }
>
>  trait B {
>    println("B")
>  }
>
>  trait C extends DelayedInit {
>    println("C")
>
>    def delayedInit(x: => Unit): Unit = {
>      println("C.delayedInit.")
>      x
>    }
>  }
>
>  object Bippy extends A with B with C with Application {
>    println("Bippy!")
>  }
>
>  // Output:
>  //
>  // A
>  // B
>  // C
>  // Application.delayedInit.
>  // Application entering main.
>  // Application executing a proc.
>  // Bippy!
>
> The comment for def delayedInit in Application says "Instead it is called as
> compiler-generated code for those classes, objects, and traits that inherit
> from the `DelayedInit` trait and that do not themselves define a
> `delayedInit` method." So at least trait A above ought to be in that
> category, or at least someone reading that comment would think so.  How are
> these supposed to compose?
>

I just cleaned that up. The comment in Application was wrong.
DelayedInit only delays initialization code of classes and objects,
not traits. I changed the spec to emphasize this point as well.

The tricky thing about DelayedInit is not the trait itself, but the
things the compiler has to do to push things under delayedInit.
Since that happens everytime someone inherits from Application, I'd
wager that delayedInit is pretty well tested by now.

Note also that there are several classes like Application that could
be simplified. For instance SimpleSwingApplication needs a method
definition for a top-frame which could be removed.

Besides Application, I know that one could make a very neat actor
system with DelayedInit. Something like this:

new Actor {
// setup code
otherActor ! this
react {
case Msg1 => ...
case Msg2 => ...
}
}

Given that (a) Application was a sore for a long time -- what other
Scala feature had "don't use this!" plastered over it? -- and (b) this
is a fully functional fix for these kinds of problems, I'd tend to
leave it as it is.

Cheers

On 2/10/11 4:07 AM, martin odersky wrote:
> I don't feel very strongly about it. Paul, do you think we should remove it now?

I'm torn. With most deprecated things I am for erring on the side of
leaving it in, but when we're talking about something which is a
minefield of bugs which aren't going to be fixed, there's a good case
for erring the other way.

As a side note, it was mentioned that I wouldn't want to "waste my time"
fixing case class inheritance bugs (and I know the term "waste" was
probably about their already being deprecated, but anyway) I would like
to clarify that fixing case class inheritance bugs has proven to be
beyond my ability, not that I am or would be unwilling to do it. All
bugs are welcome in paulp's bug fixing hut, but sometimes we have to
shake hands and go our separate ways.

On 02/10/2011 04:34 PM, Paul Phillips wrote:
> On 2/10/11 4:07 AM, martin odersky wrote:
>> I don't feel very strongly about it. Paul, do you think we should
>> remove it now?
>
> I'm torn. With most deprecated things I am for erring on the side of
> leaving it in, but when we're talking about something which is a
> minefield of bugs which aren't going to be fixed, there's a good case
> for erring the other way.
>
> As a side note, it was mentioned that I wouldn't want to "waste my
> time" fixing case class inheritance bugs (and I know the term "waste"
> was probably about their already being deprecated, but anyway)

That's what I meant. Any other meaning wasn't intended.

> I would like to clarify that fixing case class inheritance bugs has
> proven to be beyond my ability, not that I am or would be unwilling to
> do it. All bugs are welcome in paulp's bug fixing hut, but sometimes
> we have to shake hands and go our separate ways.

On 2/10/11 5:19 AM, martin odersky wrote:
> Given that (a) Application was a sore for a long time -- what other
> Scala feature had "don't use this!" plastered over it? -- and (b) this
> is a fully functional fix for these kinds of problems, I'd tend to
> leave it as it is.

Thanks for clarifying DelayedInit. That reminds me though: I think we
should seriously consider renaming Application to "App" or something
even further away like scala.Runner. The problem is that, as you say,
Application has "don't use this" plastered all over it. The web now has
2, 3, 4? years of accumulated blog posts all doing their best to tarnish
the name. You can't outrun that sort of thing in any reasonable amount
of time: we will be discussing scala from our rocking chairs before the
web starts forgetting.

It's like opening a new business at a location where a con artist had
been swindling people for years. You might not mind using the building,
but if you don't even bother to change the name of the business...

On 2/10/11 5:19 AM, martin odersky wrote:
> what other Scala feature had "don't use this!" plastered over it?

Oh darn, I missed my chance at the rhetorical question. Don't give me
openings like that, you know I can't help myself.

- Enumeration
- XML pattern matching
- io.Source

And if we lower the requirement from "plastered" to "smeared" or
"lightly bedaubed", we can throw in at least

- XML in general
- case class inheritance (ha ha, not for long)
- protected[qualifier]

Not that I disagree with the message.

Hi Hubert!

> A quick look into track shows r19206 (10/21/09) so yes, it was
> deprecated in 2.8.
> I'm wondering whether we shouldn't really make an exception here as
> case class inheritance is just wrong and whoever is using it is just
> asking for trouble.
> Besides I doubt Paul will be willing to waste his time on fixing bugs
> related to it (as it will be removed anyway) if any occurs (and I think
> I have seen one or two in the meantime related exactly to it).

My uninformed suggestion would be to remove it for 2.9, considering
not only that it is wrong and has bugs, but that it also crashes the
compiler, an example would be #3661 (closed as wontfix), which has
only been fixed by chance in trunk.

Just my 2 cents ...

Bye,

Simon

On Thu, Feb 10, 2011 at 6:23 PM, Paul Phillips wrote:
> On 2/10/11 5:19 AM, martin odersky wrote:
>>
>> Given that (a) Application was a sore for a long time -- what other
>> Scala feature had "don't use this!" plastered over it? -- and (b) this
>> is a fully functional fix for these kinds of problems, I'd tend to
>> leave it as it is.
>
> Thanks for clarifying DelayedInit.  That reminds me though: I think we
> should seriously consider renaming Application to "App" or something even
> further away like scala.Runner.  The problem is that, as you say,
> Application has "don't use this" plastered all over it.  The web now has 2,
> 3, 4? years of accumulated blog posts all doing their best to tarnish the
> name.  You can't outrun that sort of thing in any reasonable amount of time:
> we will be discussing scala from our rocking chairs before the web starts
> forgetting.
>

But a lot of books use Application. I think we leave it as is. Better
not to change things around too eagerly.

Cheers

On Thu, Feb 10, 2011 at 6:49 PM, Paul Phillips <paulp@improving.org> wrote:

On 2/10/11 9:43 AM, martin odersky wrote:

But a lot of books use Application. I think we leave it as is. Better
not to change things around too eagerly.

I didn't propose to eliminate Application, just to give us something better to hang our coats on.  trait Application extends Runner.  Right now we have to make this sharp versioning distinction: "from 2.9.0 this is the recommended way, but before that god help you if you use it!" With a different name this is not a problem.

Pretty sure these days books are the minority way (and falling) to learn anything technical.  (Not that I'm endorsing that trend.)

OTOH: "Update to Scala 2.9 and get an insta-fast Application"



--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

On 2/10/11 9:43 AM, martin odersky wrote:
> But a lot of books use Application. I think we leave it as is. Better
> not to change things around too eagerly.

I didn't propose to eliminate Application, just to give us something
better to hang our coats on. trait Application extends Runner. Right
now we have to make this sharp versioning distinction: "from 2.9.0 this
is the recommended way, but before that god help you if you use it!"
With a different name this is not a problem.

Pretty sure these days books are the minority way (and falling) to learn
anything technical. (Not that I'm endorsing that trend.)

On Thu, Feb 10, 2011 at 6:53 PM, √iktor Klang wrote:
>
>
> On Thu, Feb 10, 2011 at 6:49 PM, Paul Phillips wrote:
>>
>> On 2/10/11 9:43 AM, martin odersky wrote:
>>>
>>> But a lot of books use Application. I think we leave it as is. Better
>>> not to change things around too eagerly.
>>
>> I didn't propose to eliminate Application, just to give us something
>> better to hang our coats on.  trait Application extends Runner.  Right now
>> we have to make this sharp versioning distinction: "from 2.9.0 this is the
>> recommended way, but before that god help you if you use it!" With a
>> different name this is not a problem.
>>
>> Pretty sure these days books are the minority way (and falling) to learn
>> anything technical.  (Not that I'm endorsing that trend.)
>
> OTOH: "Update to Scala 2.9 and get an insta-fast Application"
>
Yes, I like that! -- Martin

On 10 February 2011 17:49, Paul Phillips <paulp@improving.org> wrote:

On 2/10/11 9:43 AM, martin odersky wrote:

But a lot of books use Application. I think we leave it as is. Better
not to change things around too eagerly.

I didn't propose to eliminate Application, just to give us something better to hang our coats on.  trait Application extends Runner.  Right now we have to make this sharp versioning distinction: "from 2.9.0 this is the recommended way, but before that god help you if you use it!" With a different name this is not a problem.

Pretty sure these days books are the minority way (and falling) to learn anything technical.  (Not that I'm endorsing that trend.)

Well... there's always new books coming out...  How about it Josh?  I know you're listening in!
--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.com kev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

Yes... I follow things like a hawk...
More rewriting if 2.9 beats the release of my book :)

On Thu, Feb 10, 2011 at 2:04 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

On 10 February 2011 17:49, Paul Phillips <paulp@improving.org> wrote:

On 2/10/11 9:43 AM, martin odersky wrote:

But a lot of books use Application. I think we leave it as is. Better
not to change things around too eagerly.

I didn't propose to eliminate Application, just to give us something better to hang our coats on.  trait Application extends Runner.  Right now we have to make this sharp versioning distinction: "from 2.9.0 this is the recommended way, but before that god help you if you use it!" With a different name this is not a problem.

Pretty sure these days books are the minority way (and falling) to learn anything technical.  (Not that I'm endorsing that trend.)

Well... there's always new books coming out...  How about it Josh?  I know you're listening in!
--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.com kev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

On Tue, Feb 8, 2011 at 5:22 PM, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Donna" == Donna Malayeri <lindydonna@gmail.com> writes:

 Donna> perhaps "beta" is a better name.

+1

http://en.wikipedia.org/wiki/Software_release_life_cycle : "The term
release candidate (RC) refers to a version with potential to be a final
product."  It's plan that the first 2.9 prerelease doesn't have a
snowball's chance in hell of becoming the final.

+1
Truth in advertising is good mojo.
-Lex

On 10 Feb 2011 20:26, "Josh Suereth" <joshua.suereth@gmail.com> wrote:
>
> Yes... I follow things like a hawk...
>
> More rewriting if 2.9 beats the release of my book :)
>

It's not a race!  No matter *what* Manning tell you :)

>
> On Thu, Feb 10, 2011 at 2:04 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
>>
>>
>>
>> On 10 February 2011 17:49, Paul Phillips <paulp@improving.org> wrote:
>>>
>>> On 2/10/11 9:43 AM, martin odersky wrote:
>>>>
>>>> But a lot of books use Application. I think we leave it as is. Better
>>>> not to change things around too eagerly.
>>>
>>>
>>> I didn't propose to eliminate Application, just to give us something better to hang our coats on.  trait Application extends Runner.  Right now we have to make this sharp versioning distinction: "from 2.9.0 this is the recommended way, but before that god help you if you use it!" With a different name this is not a problem.
>>>
>>> Pretty sure these days books are the minority way (and falling) to learn anything technical.  (Not that I'm endorsing that trend.)
>>
>>
>>
>> Well... there's always new books coming out...  How about it Josh?  I know you're listening in!
>>
>> --
>> Kevin Wright
>>
>> gtalk / msn : kev.lee.wright@gmail.com
>> mail: kevin.wright@scalatechnology.com
>> vibe / skype: kev.lee.wright
>> quora: http://www.quora.com/Kevin-Wright
>> twitter: @thecoda
>>
>>
>

On Tue, Feb 8, 2011 at 6:46 PM, Antonio Cunei wrote:
> Also, if there are any unfixed bugs in trunk that you consider
> critical for some reason, this is the time to call for our attention.

I've been using the nightlies to build scalaz, scalacheck, specs and
scalala, and have lodged a few regressions.

http://lampsvn.epfl.ch/trac/scala/ticket/4205
http://lampsvn.epfl.ch/trac/scala/ticket/4243
http://lampsvn.epfl.ch/trac/scala/ticket/4202 (see the comments for
non REPL repros)

I have workarounds for these two specialization bugs, but they can be
hard to track down if others hit the same problem:

http://lampsvn.epfl.ch/trac/scala/ticket/4013
http://lampsvn.epfl.ch/trac/scala/ticket/4012

-jason

On Thu, Feb 10, 2011 at 6:23 PM, Paul Phillips wrote:
> On 2/10/11 5:19 AM, martin odersky wrote:
>>
>> Given that (a) Application was a sore for a long time -- what other
>> Scala feature had "don't use this!" plastered over it? -- and (b) this
>> is a fully functional fix for these kinds of problems, I'd tend to
>> leave it as it is.
>
> Thanks for clarifying DelayedInit.  That reminds me though: I think we
> should seriously consider renaming Application to "App" or something even
> further away like scala.Runner.  The problem is that, as you say,
> Application has "don't use this" plastered all over it.  The web now has 2,
> 3, 4? years of accumulated blog posts all doing their best to tarnish the
> name.  You can't outrun that sort of thing in any reasonable amount of time:
> we will be discussing scala from our rocking chairs before the web starts
> forgetting.
>
> It's like opening a new business at a location where a con artist had been
> swindling people for years.  You might not mind using the building, but if
> you don't even bother to change the name of the business...

Here's another motivation to rebrand (and maybe to perform some
further inspections on the new premises):

scala> object App extends Application { val a = "" }
defined module App

scala> App.a
:9: error: value a is not a member of object App
App.a
^

scala> {object App extends Application { val a = "" }; App.a}
res0: java.lang.String = null

-jason

On Mon, Feb 14, 2011 at 10:41 PM, Jason Zaugg wrote:
> On Thu, Feb 10, 2011 at 6:23 PM, Paul Phillips wrote:
>> On 2/10/11 5:19 AM, martin odersky wrote:
>>>
>>> Given that (a) Application was a sore for a long time -- what other
>>> Scala feature had "don't use this!" plastered over it? -- and (b) this
>>> is a fully functional fix for these kinds of problems, I'd tend to
>>> leave it as it is.
>>
>> Thanks for clarifying DelayedInit.  That reminds me though: I think we
>> should seriously consider renaming Application to "App" or something even
>> further away like scala.Runner.  The problem is that, as you say,
>> Application has "don't use this" plastered all over it.  The web now has 2,
>> 3, 4? years of accumulated blog posts all doing their best to tarnish the
>> name.  You can't outrun that sort of thing in any reasonable amount of time:
>> we will be discussing scala from our rocking chairs before the web starts
>> forgetting.
>>
>> It's like opening a new business at a location where a con artist had been
>> swindling people for years.  You might not mind using the building, but if
>> you don't even bother to change the name of the business...
>
> Here's another motivation to rebrand (and maybe to perform some
> further inspections on the new premises):
>
> scala> object App extends Application { val a = "" }
> defined module App
>
> scala> App.a
> :9: error: value a is not a member of object App
>       App.a
>           ^
>
I believe that's

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

Which needs to be fixed for 2.9.

Cheers

Hi,

I would also like to propose looking into #3791[1] and #4155[2] before
releasing RC1.

It seems that most people from the earlier discussion agree that
- Double.MinValue/Float.MinValue should stay and
- the @deprecated introduced earlier in trunk 2.9 can be removed
again, together with Double.MinNegativeValue/Float.MinNegativeValue)

Some additional discussion is still necessary regarding
Double.Epsilon/Float.Epsilon:
- Deprecate, replace with
Double.MinPositiveValue/FLoat.MinPositiveValue (current situation)
- Depracate, replace with some other name
- Undeprecate, undo addition of
Double.MinPositiveValue/FLoat.MinPositiveValue

Shall I create a new (less inflamatory) ticket to track this or should
I reopen one/both of the existing one?

Thanks and bye!

Simon

[1] https://lampsvn.epfl.ch/trac/scala/ticket/3791
[2] https://lampsvn.epfl.ch/trac/scala/ticket/4155

On Tue, Feb 15, 2011 at 11:12 AM, Simon Ochsenreither
wrote:
> Hi,
>
> I would also like to propose looking into #3791[1] and #4155[2] before
> releasing RC1.
>
> It seems that most people from the earlier discussion agree that
>  - Double.MinValue/Float.MinValue should stay and
>  - the @deprecated introduced earlier in trunk 2.9 can be removed again,
> together with Double.MinNegativeValue/Float.MinNegativeValue)
>
> Some additional discussion is still necessarynd back regarding
> Double.Epsilon/Float.Epsilon:
>  - Deprecate, replace with Double.MinPositiveValue/FLoat.MinPositiveValue
> (current situation)
>  - Depracate, replace with some other name
>  - Undeprecate, undo addition of
> Double.MinPositiveValue/FLoat.MinPositiveValue
>
> Shall I create a new (less inflamatory) ticket to track this or should I
> reopen one/both of the existing one?
>
The decision here is to leave as is. The arguments were heard but not
sufficiently strong to go back. Essentially, you are asking that a
well-argued change in 2.8 should be reverted. I do not see any new
arguments wrt the discussion at that time, and we evidently can't
oscillate forth and back depending on the
latest mailing list thread.

So, no change at this time.

Hi Martin,

> The decision here is to leave as is.
Yes, that's what I would like to see, too.

> The arguments were heard but not sufficiently strong to go back.
> Essentially, you are asking that a well-argued change in 2.8 should
> be reverted.

No, I'm not asking that. It was not changed in 2.8 or 2.8.1.
There exists no Scala release with this bug in it to this date.

There isn't really something to go back to. I suggest that the current
behavior should stay as is and should not be deprecated in my opinion,
because it breaks the consistency between
Int.MinValue/Long.MinValue/Float.MinValue/Double.MinValue, which just
worked as intended.

> I do not see any new arguments wrt the discussion at that time, and
> we evidently can't oscillate forth and back depending on the latest
> mailing list thread.

There is really no oscillating imho, I'm suggesting that MinValue
stays consistent as it is at the moment across all value types and to
not deprecate/shuffle around fields without any benefit.

Thanks and bye,

Simon

Mailing list thread:
http://groups.google.com/group/scala-language/browse_thread/thread/7289d...

On Tue, Feb 15, 2011 at 12:44 PM, Simon Ochsenreither
wrote:
> Hi Martin,
>
>> The decision here is to leave as is.
>
> Yes, that's what I would like to see, too.
>
>> The arguments were heard but not sufficiently strong to go back.
>> Essentially, you are asking that a well-argued change in 2.8 should be
>> reverted.
>
> No, I'm not asking that. It was not changed in 2.8 or 2.8.1.
> There exists no Scala release with this bug in it to this date.
>
> There isn't really something to go back to. I suggest that the current
> behavior should stay as is and should not be deprecated in my opinion,
> because it breaks the consistency between
> Int.MinValue/Long.MinValue/Float.MinValue/Double.MinValue, which just worked
> as intended.
>
>> I do not see any new arguments wrt the discussion at that time, and we
>> evidently can't oscillate forth and back depending on the latest mailing
>> list thread.
>
> There is really no oscillating imho, I'm suggesting that MinValue stays
> consistent as it is at the moment across all value types and to not
> deprecate/shuffle around fields without any benefit.
>
Sorry! I was not aware of that. I am on the road and therefore it's
difficult for me to check old versions. Can someone confirm this? If
that's the case I think Simon's argument prevails. Essentially my
position is: 2.9 should behave like 2.8.1 here.

Thanks

Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_22).
Type in expressions to have them evaluated.
Type :help for more information.

scala> Double.MinValue
res0: Double = -1.7976931348623157E308

scala> java.lang.Double.MIN_VALUE
res3: Double = 4.9E-324

Welcome to Scala version 2.9.0.r24214-b20110209134919 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_22).
Type in expressions to have them evaluated.
Type :help for more information.

scala> Double.MinValue
warning: there were 1 deprecation warnings; re-run with -deprecation for details
res0: Double = -1.7976931348623157E308

So, deprecation was introduced after 2.8.1.

On Tue, Feb 15, 2011 at 11:04, martin odersky <martin.odersky@epfl.ch> wrote:

On Tue, Feb 15, 2011 at 12:44 PM, Simon Ochsenreither
<simon@ochsenreither.de> wrote:
> Hi Martin,
>
>> The decision here is to leave as is.
>
> Yes, that's what I would like to see, too.
>
>> The arguments were heard but not sufficiently strong to go back.
>> Essentially, you are asking that a well-argued change in 2.8 should be
>> reverted.
>
> No, I'm not asking that. It was not changed in 2.8 or 2.8.1.
> There exists no Scala release with this bug in it to this date.
>
> There isn't really something to go back to. I suggest that the current
> behavior should stay as is and should not be deprecated in my opinion,
> because it breaks the consistency between
> Int.MinValue/Long.MinValue/Float.MinValue/Double.MinValue, which just worked
> as intended.
>
>> I do not see any new arguments wrt the discussion at that time, and we
>> evidently can't oscillate forth and back depending on the latest mailing
>> list thread.
>
> There is really no oscillating imho, I'm suggesting that MinValue stays
> consistent as it is at the moment across all value types and to not
> deprecate/shuffle around fields without any benefit.
>
Sorry! I was not aware of that. I am on the road and therefore it's
difficult for me to check old versions. Can someone confirm this? If
that's the case I think Simon's argument prevails. Essentially my
position is: 2.9 should behave like 2.8.1 here.

Thanks

On Tue, Feb 15, 2011 at 2:20 PM, Daniel Sobral wrote:
> Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server VM,
> Java 1.6.0_22).
> Type in expressions to have them evaluated.
> Type :help for more information.
>
> scala> Double.MinValue
> res0: Double = -1.7976931348623157E308
>
> scala> java.lang.Double.MIN_VALUE
> res3: Double = 4.9E-324
>
> Welcome to Scala version 2.9.0.r24214-b20110209134919 (Java HotSpot(TM)
> 64-Bit Server VM, Java 1.6.0_22).
> Type in expressions to have them evaluated.
> Type :help for more information.
>
> scala> Double.MinValue
> warning: there were 1 deprecation warnings; re-run with -deprecation for
> details
> res0: Double = -1.7976931348623157E308
>
> So, deprecation was introduced after 2.8.1.
>
Got it, thanks! I agree we should revert then.