issues / 2.10.1-RC1 & 2.11.0-X planning

[Adriaan Moors]

Hi,

as you may have noticed, issues have been shuffled around a bit on jira

please take some time in the coming weeks to ruthlessly decide which issues you believe should & can be fixed in time for the Feb 11 deadline of 2.10.1-RC1

i'm trying to get a handle on what must be fixed for 2.10.1 versus 2.11 -- if the above deadline is not feasible based on the bug counts we end up with at fix-by == 2.10.1-RC1, we'll have to rethink our schedule

the reasoning in sorting bugs:

• no (active) maintainer --> not scheduled
• 2.11: 
• specialisation
• reflection
• optimizer
• non-urget api changes (even if backwards compatible)
• spec changes/updates/clarifications
• 2.10.1-RC1
• critical fixes
• "easy" fixes that enhance the quality of the release
• (as experimental features, reflection & macros may also receive updates in 2.10.x releases, but they must not impact the non-experimental side of the language -- i.e., the regression risk must be extremely low)

Since 2.11.0-M1 is pretty close to 2.10.1-RC1, I fully expect to have issues flow over, waterfall-style, to the later milestones, but that's okay for (early) milestones anyway.

I've also removed the redundant Unreleased-Foo versions, as a version has a property "released".

Let's make it a coordinated effort to set the fix-by field to the next relevant release.

Note that this means there's already a 2.10.0-RC6 version, though I hope it will never see the light of day. 

I invite you to have a look at https://issues.scala-lang.org/browse/SI/#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel to get a sense of the currently proposed cycle for 2.11.

Now's a good a time as any to comment on those dates, though I'm preparing a more formal release-schedule-defining process (along the same lines as our SIP process, but applied to the release roadmap itself).

cheers

adriaan

[Paul Phillips]

On Wed, Dec 12, 2012 at 11:35 PM, Adriaan Moors <adriaa...@typesafe.com> wrote:

• 2.11: 

• specialisation
• reflection
• optimizer
• non-urget api changes (even if backwards compatible)
• spec changes/updates/clarifications

We should also apply the surgical knife in 2.11 to extracting the most easily separable elements of the library into separate and optional libraries. Right now scala-library.jar is over 7 Mb. It could half that size without most people noticing anything had gone missing.

The most easily separable pieces, not to mention the ones in the worst state of repair, are:

 - xml

 - collections views

From memory these would in combination recapture between 1 and 1.5 Mb.

Another easily separable piece (not in poor repair to my knowledge but also not yet in wide use) are the parallel collections, which again from memory would recapture about 1 Mb.

[Simon Ochsenreither]

We should also apply the surgical knife in 2.11 to extracting the most easily separable elements of the library into separate and optional libraries. Right now scala-library.jar is over 7 Mb. It could half that size without most people noticing anything had gone missing.

The most easily separable pieces, not to mention the ones in the worst state of repair, are:

 - xml

 - collections views

From memory these would in combination recapture between 1 and 1.5 Mb.

Another easily separable piece (not in poor repair to my knowledge but also not yet in wide use) are the parallel collections, which again from memory would recapture about 1 Mb.

Absolutely agree with that and like to suggest modularizing the JSON library and parser combinators.

• The JSON classes feel a bit like they were meant as a code example for the parser combinator library. Compared to hand-tuned libraries, they seem to be too slow for any serious usage. There has to be a reason why it is not used in the wild. I guess it would make sense to ask those Scala projects which use other JSON libraries and investigate why they don't use the one shipping with Scala.
• There are many great third-party parser combinator libraries out there and I think the ecosystem could benefit from more competition here. Not bundling one with the standard lib could level the playing field and increase innovation, especially with macros around the corner.

[Paul Phillips]

On Thu, Dec 13, 2012 at 9:12 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

• The JSON classes feel a bit like they were meant as a code example for the parser combinator library. Compared to hand-tuned libraries, they seem to be too slow for any serious usage. There has to be a reason why it is not used in the wild. I guess it would make sense to ask those Scala projects which use other JSON libraries and investigate why they don't use the one shipping with Scala.

I may be misremembering but I thought we agreed long ago to deprecate and remove the json library. I'm displeased to see that it's not even deprecated.

• There are many great third-party parser combinator libraries out there and I think the ecosystem could benefit from more competition here. Not bundling one with the standard lib could level the playing field and increase innovation, especially with macros around the corner.

I agree on this as well - I was holding back a little in case enumerating too many items might activate any automatic resistance systems and interfere with my extracting the largest pieces.

[Daniel Sobral]

On Thu, Dec 13, 2012 at 3:15 PM, Paul Phillips <pa...@improving.org> wrote:

On Thu, Dec 13, 2012 at 9:12 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

• The JSON classes feel a bit like they were meant as a code example for the parser combinator library. Compared to hand-tuned libraries, they seem to be too slow for any serious usage. There has to be a reason why it is not used in the wild. I guess it would make sense to ask those Scala projects which use other JSON libraries and investigate why they don't use the one shipping with Scala.

I may be misremembering but I thought we agreed long ago to deprecate and remove the json library. I'm displeased to see that it's not even deprecated.

I think it turned out to be used somewhere, but maybe I'm confusing it with the awful automata stuff, which is used by XML.

 

• There are many great third-party parser combinator libraries out there and I think the ecosystem could benefit from more competition here. Not bundling one with the standard lib could level the playing field and increase innovation, especially with macros around the corner.

I agree on this as well - I was holding back a little in case enumerating too many items might activate any automatic resistance systems and interfere with my extracting the largest pieces.

--
Daniel C. Sobral

I travel to the future all the time.

[Adriaan Moors]

I totally agree we should excise, deprecate & modularize -- let's track this so we don't forget in 2.11:

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

[Simon Ochsenreither]

I'd also like to suggest adding the scala.sys package to the list.

[Simon Ochsenreither]

Continuing https://github.com/scala/scala/pull/1903 as suggested by Adriaan.

I think there are basically two categories and appropriate actions we'd have to consider:

- Broken stuff (which has alternatives) which we want to get rid of: first deprecation, then removal
- Stuff which works, but is not high-quality/popular enough to justify it shipping with the main jar: modularization (put into separate jar)

I'm wondering if there is a third category where we would both deprecate and modularize something. I think the only result would be to get deprecated stuff out of the main jar ahead of the removal phase. But if this was possible, would there be any case where we wouldn't use this possibility by default?

As far as I see proposed candidates for modularization are:

• scala.sys
• collection views
• parser combinators

(These would join the ranks of scala-swing.jar and scala-reflect.jar)

Candidates for removal:

• scala.actors
  
• scala.util.parsing.json
• scala.util.grammar
• scala.util.regexp
• scala.util.automata (BerrySethiGlushkov and friends (If they are still required for XML, at least make them private. No one should ever see these classes))
• small parts of scala.xml, e. g. the demo applications

Looking at the packages above, there is one thing which becomes increasingly clear and which I'd like to repeat once again:

Putting stuff in scala.util is—in 99% of the cases—a clear code smell.

[Simon Ochsenreither]

Considering the amount of progress already made with type macro replacements, let's add scala.Enumeration to the to-be-removed list.

[Rex Kerr]

On Thu, Jan 17, 2013 at 7:03 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Continuing https://github.com/scala/scala/pull/1903 as suggested by Adriaan.

I think there are basically two categories and appropriate actions we'd have to consider:

- Broken stuff (which has alternatives) which we want to get rid of: first deprecation, then removal
- Stuff which works, but is not high-quality/popular enough to justify it shipping with the main jar: modularization (put into separate jar)

I'm wondering if there is a third category where we would both deprecate and modularize something. I think the only result would be to get deprecated stuff out of the main jar ahead of the removal phase. But if this was possible, would there be any case where we wouldn't use this possibility by default?

As far as I see proposed candidates for modularization are:

• scala.sys

Er, why?  To make it extra-awkward in order to use one or two tiny system-dependent classes, so that people will stop using them at all and just use the Java equivalents instead?

I can see an argument for removal (not heavily used, can manage okay with Java), but not for modularization.  This saves what, 170k out of 7115k (~2%)?  If you care about that amount of space you'll be using ProGuard already, and it will already cut it out.

 

• collection views

That would be good if they can be made cleanly separable.

 

• parser combinators

Meh.  These are one of the unique features of the Scala library, and again  it's not much space (285k, ~4%).

 

(These would join the ranks of scala-swing.jar and scala-reflect.jar)

Candidates for removal:

• scala.actors
  

Okay.  They're effectively already gone.

 

• scala.util.parsing.json

Haven't used them, so I'm not sure how broken they are.   It's a nice capability to have if it works.  If it doesn't, it shouldn't mislead people.  It doesn't add appreciably to the jar size (136k)

• scala.util.grammar

Sounds good.

• scala.util.regexp

Yes, this is just a distraction from Regex in scala.util.matching

 

• scala.util.automata (BerrySethiGlushkov and friends (If they are still required for XML, at least make them private. No one should ever see these classes))

Indeed.

• small parts of scala.xml, e. g. the demo applications

Sure.

Looking at the packages above, there is one thing which becomes increasingly clear and which I'd like to repeat once again:

Putting stuff in scala.util is—in 99% of the cases—a clear code smell.

Well, the point of util is that you can put anything there.  Anything in util can be promoted to the top level and be just as clear.  Sometimes, however, you want to have a grab-bag of lesser-used things, and util is a good spot for that.  I'm not sure why Either and Try were demoted to util (wouldn't have been my choice), but it's an entirely sensible spot for Sorting, continuations and logging, which is well over 99%.  Parsing could be moved to top-level (but not without json and parser combinators).

Also, what about scala.text?  Could that be moved into util?  It's kind of silly that it's taking up top-level namespace like that.

Also, I want to see a fully-working something-that-is-better-than-scala.Enumeration before deprecating Enumeration.  The (with alternatives) proviso is important, and Enumeration is not badly broken, just too awkward to be worth it.

  --Rex

[Simon Ochsenreither]

Er, why?  To make it extra-awkward in order to use one or two tiny system-dependent classes, so that people will stop using them at all and just use the Java equivalents instead?

Because it is working, mostly documented (afair), but not often used. Additionally, it doesn't seems to be one of the more easily separable parts of the library. Maybe other people can comment on it.

 

Meh.  These are one of the unique features of the Scala library, and again  it's not much space (285k, ~4%).

See comment above:

There are many great third-party parser combinator libraries out there and I think the ecosystem could benefit from more competition here. Not bundling one with the standard lib could level the playing field and increase innovation, especially with macros around the corner.

 

• scala.util.parsing.json

Haven't used them, so I'm not sure how broken they are.   It's a nice capability to have if it works.  If it doesn't, it shouldn't mislead people.

Same case as above. There are tons of faster, more efficient, actually maintained and documented JSON parsers out there. Plus same argument with type macros.

• scala.util.grammar

Sounds good.

https://github.com/scala/scala/pull/1918/files#L40L0
 

Putting stuff in scala.util is—in 99% of the cases—a clear code smell.

Well, the point of util is that you can put anything there.  Anything in util can be promoted to the top level and be just as clear.  Sometimes, however, you want to have a grab-bag of lesser-used things, and util is a good spot for that.  I'm not sure why Either and Try were demoted to util (wouldn't have been my choice), but it's an entirely sensible spot for Sorting, continuations and logging, which is well over 99%.  Parsing could be moved to top-level (but not without json and parser combinators).

I strongly disagree with that. We are developing a standard library here, not some node.js module.

A grab-bag of lesser-used things just doesn't deserve to exist in a standard library

scala.util is a prime example of the broken-window theory. People see the sad state of scala.util and think it is an excuse to put more untested, unmaintained, undocumented code into it.

Java is suffering from a new exploit every other week because of a similar “library as a grab-bag of stuff” approach. Let's not do that.

I've been doing this deprecation dance for some time already, and I'd like to see the day were we remove more cruft than we accumulate at least once in my life.

 

Also, what about scala.text?  Could that be moved into util?  It's kind of silly that it's taking up top-level namespace like that.

Or we could get rid of it. It's one file ... that's exactly what gist.github.com was invented for.

 

Also, I want to see a fully-working something-that-is-better-than-scala.Enumeration before deprecating Enumeration.

Use Java enums, just like for RuntimeAnnotations. They work perfectly well. Having a Scala-native way to define them would be great, but solely getting rid of scala.Enumeration would already be a net improvement.

 

The (with alternatives) proviso is important, and Enumeration is not badly broken, just too awkward to be worth it.

Searching for “Enumeration” in the bug tracker might convince otherwise.

Bye,

Simon

[Rex Kerr]

On Thu, Jan 17, 2013 at 12:35 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Er, why?  To make it extra-awkward in order to use one or two tiny system-dependent classes, so that people will stop using them at all and just use the Java equivalents instead?

Because it is working, mostly documented (afair), but not often used. Additionally, it doesn't seems to be one of the more easily separable parts of the library. Maybe other people can comment on it.

"Let's make Scala more inconvenient and harder to use for command-line style scripting tasks" does not seem to me to be a good idea.

 

 

Meh.  These are one of the unique features of the Scala library, and again  it's not much space (285k, ~4%).

See comment above:

There are many great third-party parser combinator libraries out there and I think the ecosystem could benefit from more competition here. Not bundling one with the standard lib could level the playing field and increase innovation, especially with macros around the corner.

Well, we could use the same justification to drop the collections library, too.  Personally, I don't want the playing field level.  I want the close field to contain everything I need to get as much work done as possible.

 

 

• scala.util.parsing.json

Haven't used them, so I'm not sure how broken they are.   It's a nice capability to have if it works.  If it doesn't, it shouldn't mislead people.

Same case as above. There are tons of faster, more efficient, actually maintained and documented JSON parsers out there. Plus same argument with type macros.

Maybe someone with a fast, efficient, maintained and documented JSON parser could be encouraged to allow their parser to be part of the standard library.

 

Putting stuff in scala.util is—in 99% of the cases—a clear code smell.

Well, the point of util is that you can put anything there.  Anything in util can be promoted to the top level and be just as clear.  Sometimes, however, you want to have a grab-bag of lesser-used things, and util is a good spot for that.  I'm not sure why Either and Try were demoted to util (wouldn't have been my choice), but it's an entirely sensible spot for Sorting, continuations and logging, which is well over 99%.  Parsing could be moved to top-level (but not without json and parser combinators).

I strongly disagree with that. We are developing a standard library here, not some node.js module.

A grab-bag of lesser-used things just doesn't deserve to exist in a standard library

You'll need to justify this more for me to be convinced at all.  As far as I can tell:

  * Some library features are needed often

  * Some are needed, but not so often

  * Some are easily grouped into large categories

  * Some are not so easily grouped but still necessary

Your solution demands that if code is not needed so often and is not easily grouped, it should be removed entirely, or it should take up the most-valuable top-level namespace.

This is a really strange design decision.  It violates standard principles of naming (e.g. Huffman coding) where you want the commonly-used things to be easy-to-use, and the less-common things to be less-easy.  The idea of "utilities" is itself a pretty clear idea, and thus allows an obvious place to look for less common features that you hope still exist.

I'd argue exactly the opposite: a bunch of stuff in scala. should be demoted to scala.util.:

  * DelayedInit

  * deprecatedName

  * FallbackArrayBuilding

  * languageFeature

  * LowPriorityImplicits

  * Predef

  * Responder  // Goes with CPS

  * ScalaReflectionException  // Goes with reflection

  * Specializable

  * StringContext

  * UninitializedFieldError

  * compat.Platform   // to util.Platform

  * ref

  * text

because although these things are needed, the standard library user mostly doesn't need to refer to them except in special cases, and in two cases they take up really handy words that one might wish to use for something more important.  (Granted, Scala's pretty good about name collisions.)

 

scala.util is a prime example of the broken-window theory. People see the sad state of scala.util and think it is an excuse to put more untested, unmaintained, undocumented code into it.

This is what code reviews and standards are for.  Deprecating packages that people have decided to put some unmaintained code in is a losing strategy.  If people want to put U3 code (untested, unmaintained, undocumented) in the standard library, do you seriously think that not having a ".util" to put it in will stop them?  I'd rather trust people to raise their game than to go around hacking away names (rather than particular bits of code).  Fix the windows, tell people "don't break more!".

 

Java is suffering from a new exploit every other week because of a similar “library as a grab-bag of stuff” approach. Let's not do that.

Fine, we wont create scala.grabBag.securityRisk :)

 

I've been doing this deprecation dance for some time already, and I'd like to see the day were we remove more cruft than we accumulate at least once in my life.

Sure, that would be nice.  But not using util for a useful purpose is not the best way to go about that.

 

 

Also, what about scala.text?  Could that be moved into util?  It's kind of silly that it's taking up top-level namespace like that.

Or we could get rid of it. It's one file ... that's exactly what gist.github.com was invented for.

Sure, I can count the number of times I've wished for a poorly-documented pretty-printing library in the standard library on the fingers of zero hands.

 

 

Also, I want to see a fully-working something-that-is-better-than-scala.Enumeration before deprecating Enumeration.

Use Java enums, just like for RuntimeAnnotations. They work perfectly well. Having a Scala-native way to define them would be great, but solely getting rid of scala.Enumeration would already be a net improvement.

Whoever ditches Enumeration should also be responsible for fixing all instances of it in the code base, including Swing.  This is not likely to be a great deal of fun.

 

 

The (with alternatives) proviso is important, and Enumeration is not badly broken, just too awkward to be worth it.

Searching for “Enumeration” in the bug tracker might convince otherwise.

It's not _badly_ broken.  Deprecation as a mechanism by which to alert people of the bugs that do exist may be sensible, but deprecation without a fix is about as clear an indication of a broken window as there is.  This is a signal not just to library maintainers but also people who may consider adopting Scala (and can look more scary than it really is).

  --Rex

 

[Simon Ochsenreither]

Hi,

"Let's make Scala more inconvenient and harder to use for command-line style scripting tasks" does not seem to me to be a good idea.

How would it get harder? It would ship with the distribution, would be on the classpath, nothing would change, except that people could just drop scala-sys.jar if they wouldn't need it. But I don't have any strong opinions on it. I just think that combining all the modularizing stuff could easily shave of another megabyte, even if the individual items don't weigh in that much.

There are many great third-party parser combinator libraries out there and I think the ecosystem could benefit from more competition here. Not bundling one with the standard lib could level the playing field and increase innovation, especially with macros around the corner.

Well, we could use the same justification to drop the collections library, too.  Personally, I don't want the playing field level.  I want the close field to contain everything I need to get as much work done as possible.

No, not really. I think most people would agree that Scala's collections are state-of-the-art tech, that's completely different in the parser combinator case. Additionally, I don't see multiple competing third-party collection packages in the wild, unlike parser combinators.

Nevertheless, if we can modularize collections ... I would have nothing against a 200KB bare-bone scala-core.jar.

 

Maybe someone with a fast, efficient, maintained and documented JSON parser could be encouraged to allow their parser to be part of the standard library.

With type macros arriving in 2.11, I think the whole “let's throw away static typing and use strings” approach to handle JSON, XML, ... is just completely obsolete. Let's wait and see how this stuff works out.

A grab-bag of lesser-used things just doesn't deserve to exist in a standard library

You'll need to justify this more for me to be convinced at all.  As far as I can tell:

  * Some library features are needed often

  * Some are needed, but not so often

  * Some are easily grouped into large categories

  * Some are not so easily grouped but still necessary

Your solution demands that if code is not needed so often and is not easily grouped, it should be removed entirely, or it should take up the most-valuable top-level namespace.

No. It should removed entirely. No idea why it should be moved to a top-level namespace instead, that's not what I suggest. My focus on scala.util comes from the fact that people seem to assume that it should have lower quality standards than the rest of the library. Moving it around doesn't solve any problems with it. Packages are names, and names are an important part of any API. If code violates this, it shouldn't be included until the naming issues are fixed.

 

This is a really strange design decision.  It violates standard principles of naming (e.g. Huffman coding) where you want the commonly-used things to be easy-to-use, and the less-common things to be less-easy.

Considering that I don't see dozens of new people queuing up to help maintaining the standard library, I prefer having a strict upper bound on the length of the Huffman codes, which means enforcing high standards for all packages.

 

I'd argue exactly the opposite: a bunch of stuff in scala. should be demoted to scala.util.:

  * DelayedInit

  * deprecatedName

  * FallbackArrayBuilding

  * languageFeature

  * LowPriorityImplicits

  * Predef

  * Responder  // Goes with CPS

  * ScalaReflectionException  // Goes with reflection

  * Specializable

  * StringContext

  * UninitializedFieldError

  * compat.Platform   // to util.Platform

  * ref

  * text

 

I think most items above could be moved to far better packages than scala.util. For instance @deprecatedName, along with @deprecated, @deprecatedInheritance and @deprecatedOverriding could be moved to scala.annotation. The internal stuff should go into scala.runtime.

 ... do you seriously think that not having a ".util" to put it in will stop them?

It won't completely stop them, but it will make it more difficult if the standard place for “oh, I wrote some nice class ... I have neither documented it nor any use-cases ... why not put it into scala.util and let it rot there?”-stuff is closed permanently.
 

I've been doing this deprecation dance for some time already, and I'd like to see the day were we remove more cruft than we accumulate at least once in my life.

Sure, that would be nice.  But not using util for a useful purpose is not the best way to go about that.

My point is that most of the time, there are no useful purposes of scala.util. Wanting to put something into scala.util is often a symptom that we have not thought enough about the naming and the purpose of that code.

 

Whoever ditches Enumeration should also be responsible for fixing all instances of it in the code base, including Swing.  This is not likely to be a great deal of fun.

It would be a pleasure for me to do that.

The (with alternatives) proviso is important, and Enumeration is not badly broken, just too awkward to be worth it.

Searching for “Enumeration” in the bug tracker might convince otherwise.

It's not _badly_ broken.  Deprecation as a mechanism by which to alert people of the bugs that do exist may be sensible, but deprecation without a fix is about as clear an indication of a broken window as there is.  This is a signal not just to library maintainers but also people who may consider adopting Scala (and can look more scary than it really is)

Even “slightly” broken should be too much to ship with the standard library. Adding @deprecated("Use Java enums instead") would be straight-forward fix.

Bye,

Simon

[Rex Kerr]

On Thu, Jan 17, 2013 at 3:51 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Hi,

"Let's make Scala more inconvenient and harder to use for command-line style scripting tasks" does not seem to me to be a good idea.

How would it get harder? It would ship with the distribution, would be on the classpath, nothing would change, except that people could just drop scala-sys.jar if they wouldn't need it.

Fair enough; I guess the intersection of executing with java blah blah and doing command-line stuff is pretty small; being on the classpath is probably okay.

 

But I don't have any strong opinions on it. I just think that combining all the modularizing stuff could easily shave of another megabyte, even if the individual items don't weigh in that much.

Most of that would be views.

 

There are many great third-party parser combinator libraries out there and I think the ecosystem could benefit from more competition here. Not bundling one with the standard lib could level the playing field and increase innovation, especially with macros around the corner.

Well, we could use the same justification to drop the collections library, too.  Personally, I don't want the playing field level.  I want the close field to contain everything I need to get as much work done as possible.

No, not really. I think most people would agree that Scala's collections are state-of-the-art tech,

I don't.  Some aspects are awesome (Vector in many use cases, flexibility, overall power of methods, type safety, etc.), and some aren't.  They're painful to extend (though they grant massive power once you do), some have buggy/not-very-well-maintained bits (views, mostly), there are duplications within the library (LinkedList, ListBuffer, MutableList all inside collection.mutable), poor design for efficiency in places (e.g. tuple vs not in maps), questionable naming conventions (can't always tell if something is mutable or immutable), performance gotchas (List is the default Seq, but seq.length is O(n)), and so on.

Now, overall I'm very, very glad that the collections library is there.  I use that more heavily than I use any other part of the library because collections are such a central part of programming.  But I wholeheartedly endorse the Akka/scala.actors approach.  If you identify a replacement that has desirable features, deprecated the old one and fold in the new one.  Don't just jettison it from the library if it's part of sensible core functionality (which both actors and parser combinators arguably are).

 

that's completely different in the parser combinator case. Additionally, I don't see multiple competing third-party collection packages in the wild, unlike parser combinators.

Well, there's debox, basis, and scalaz' collections, off the top of my head, and hasn't someone wrapped Guava?

 

Nevertheless, if we can modularize collections ... I would have nothing against a 200KB bare-bone scala-core.jar.

At some point you're just manually doing the work of tools like ProGuard so you can make people type more lines of /usr/lib/scala/2.11/lib/scala-core.jar:/usr/lib/scala/2.11/lib/scala-collections-core.jar:/usr/lib/scala/2.11/lib/scala-collections-views.jar:/usr/lib/scala/2.11/lib/scala-xml.jar:/usr/lib/scala/2.11/lib/scala-left-handle-of-sink-faucet.jar:...

If the idea is to also provide comprehensive jars, fair enough.  But beyond a basic "you probably need this" and "you probably don't, but just in case..." divisions, I don't think you gain much except a bookkeeping hassle by splitting jars into tiny bits.

 

 

Maybe someone with a fast, efficient, maintained and documented JSON parser could be encouraged to allow their parser to be part of the standard library.

With type macros arriving in 2.11, I think the whole “let's throw away static typing and use strings” approach to handle JSON, XML, ... is just completely obsolete. Let's wait and see how this stuff works out.

Er, XML in Scala is not exactly a good example of throwing away static typing.

 

A grab-bag of lesser-used things just doesn't deserve to exist in a standard library

You'll need to justify this more for me to be convinced at all.  As far as I can tell:

  * Some library features are needed often

  * Some are needed, but not so often

  * Some are easily grouped into large categories

  * Some are not so easily grouped but still necessary

Your solution demands that if code is not needed so often and is not easily grouped, it should be removed entirely, or it should take up the most-valuable top-level namespace.

No. It should removed entirely.

Okay, great, let's remove LowPriorityImplicits and FallbackArrayBuilding and see how well things work.

 

No idea why it should be moved to a top-level namespace instead, that's not what I suggest.

You cannot help but suggest that if you refuse to consider putting things in util.

 

My focus on scala.util comes from the fact that people seem to assume that it should have lower quality standards than the rest of the library.

So change that assumption.  Require high quality code there.

 

Moving it around doesn't solve any problems with it.

Absolutely.  Improve code quality in util if that's a problem.  And anywhere else it's not up to par.

 

Packages are names, and names are an important part of any API. If code violates this, it shouldn't be included until the naming issues are fixed.

 

I'd argue exactly the opposite: a bunch of stuff in scala. should be demoted to scala.util.:

  * DelayedInit

  * deprecatedName

  * FallbackArrayBuilding

  * languageFeature

  * LowPriorityImplicits

  * Predef

  * Responder  // Goes with CPS

  * ScalaReflectionException  // Goes with reflection

  * Specializable

  * StringContext

  * UninitializedFieldError

  * compat.Platform   // to util.Platform

  * ref

  * text

 

I think most items above could be moved to far better packages than scala.util. For instance @deprecatedName, along with @deprecated, @deprecatedInheritance and @deprecatedOverriding could be moved to scala.annotation. The internal stuff should go into scala.runtime.

Sure, you can call "util" "runtime" instead.  Any name that gets the point across is fine.  That doesn't make it any better-thought-through (either the naming or what code goes there).  Right now "runtime" is a mix of things that are truly runtime-only and various utility stuff that I'd probably put into util instead.  For example, why does Tuple2Zipped have any more to do with "runtime" than any other code you might want to execute at runtime?

I guess my meta-point is that repainting the bike shed doesn't necessarily make the bikes in it any better, and also that change is costly for everyone involved, so it should really be worth it.

 

The (with alternatives) proviso is important, and Enumeration is not badly broken, just too awkward to be worth it.

Searching for “Enumeration” in the bug tracker might convince otherwise.

It's not _badly_ broken.  Deprecation as a mechanism by which to alert people of the bugs that do exist may be sensible, but deprecation without a fix is about as clear an indication of a broken window as there is.  This is a signal not just to library maintainers but also people who may consider adopting Scala (and can look more scary than it really is)

Even “slightly” broken should be too much to ship with the standard library. Adding @deprecated("Use Java enums instead") would be straight-forward fix.

As long as there's an ignore-this-deprecation flag for compilation _and_ a committment not to actually remove them until after a sensible replacement is actually found, I wouldn't mind.  Enumeration doesn't work as well as one would like, but it doesn't work so poorly as to be worth ripping out every instance where it still exists, which is what you are saying should happen with deprecation.

I prefer not having mixed scala-java sources, also.  It's doable, but it's another bookkeeping headache that I personally don't get excited about.

  --Rex

 

[Alois Cochard]

It's still pretty much a work-in-progress, but what you see in the README is working and is imo clearly better than what scala.Enumeration give us:

https://github.com/aloiscochard/enum-paradise

 

  --Rex

[Rex Kerr]

That looks much better!

But what's the overhead/performance of the macro-style vs. old-style enumerations?  I can envision two classes created per name, where before it was a single instance of a class.

  --Rex

[Simon Ochsenreither]

That looks much better!

Agree, Alois did some impressive work.

 

But what's the overhead/performance of the macro-style vs. old-style enumerations?  I can envision two classes created per name, where before it was a single instance of a class.

My "envisioned" end result would be an enum construct compatible to Java enums. This means one instance per item.¹


¹ If you add overridden methods to the individual items, it will necessarily create an anonymous class. But that's all exactly what happens in Java.

[Rex Kerr]

On Fri, Jan 18, 2013 at 8:27 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

That looks much better!

Agree, Alois did some impressive work.

 

But what's the overhead/performance of the macro-style vs. old-style enumerations?  I can envision two classes created per name, where before it was a single instance of a class.

My "envisioned" end result would be an enum construct compatible to Java enums. This means one instance per item.¹

Great.  But let's actually have this, or an idea that performance / overhead is reasonable, before deprecating.

Requiring people to switch to something that doesn't fit their needs, then switch to Java enums because Scala's are deprecated, then switch to the new Scala enums which do fit their needs (e.g. to get rid of the mixed build process) doesn't sound like a very smooth transition path.

  --Rex

 

[Matthew Pocock]

If we turn down 10 individual things because each is only 4% of the jar, we have cumulatively passed over a 40% size reduction.

For me the question is not how big or is but is it internally tightly coupled and externally loosely coupled, and does it represent a unit of functionality that developers will tend to use or not use as a unit? Moving forward, is it something that could be patched in isolation?

Sent from my android - may contain predictive text entertainment.

[Rex Kerr]

There weren't 10 things on the table, there were three; one was a clear win, and the other two added up to less than 5% total and seemed a bit questionable to me.

I agree that if we had ten things that were 4% each, we shouldn't reject each one individually.  But right now, 2.10 looks something like

  54%   scala.collections

  12%   scala.util   // 7% parsing (4% comb.), 5% other

  10%   scala.

   8%   scala.xml

   3.7% scala.runtime

   3.5% scala.concurrent

   2.7% scala.math

   2.4% scala.sys

   1.5% scala.io

   1.1% scala.reflect

   0.3% scala.text

   0.3% scala.annotation

   0.2% scala.ref

   0.2% scala.testing

   0.1% scala.beans

   0.0% scala.compat

 

(does not quite add up to 100% due to rounding and not counting entirely deprecated packages).

So you either tackle collections, or it's going to be small potatoes.  Parts of util and all of xml and concurrent would probably be the easiest wins; together that's maybe 20%.

  --Rex

[Paul Phillips]

On Fri, Jan 18, 2013 at 7:57 AM, Rex Kerr <ich...@gmail.com> wrote:

So you either tackle collections, or it's going to be small potatoes.  Parts of util and all of xml and concurrent would probably be the easiest wins; together that's maybe 20%.

Perhaps we don't know or have forgotten that some concrete albeit slightly old data is available.

  https://github.com/paulp/scala/tree/prime

% git log -n1 paulp/prime

commit 7977b719f861ff8b6d9d56cbf6325b51e1c39234 (paulp/prime)

Author: Paul Phillips <pa...@improving.org>

Date:   7 months ago

    % ant all.clean dist

    

      BUILD SUCCESSFUL

      Total time: 4 minutes 41 seconds

    

      % ls -l dists/scala-2.10.0-20120629-074811-e990f84192/lib/

      -rw-r--r--  1 paulp  admin   181757 Jun 29 07:56 config-0.4.0.jar

      -rw-r--r--  1 paulp  admin    53497 Jun 29 07:56 forkjoin.jar

      -rw-r--r--  1 paulp  admin   202396 Jun 29 07:56 jline-2.7.jar

      -rw-r--r--  1 paulp  admin   142789 Jun 29 07:56 scala-asm.jar

      -rw-r--r--  1 paulp  admin  8129917 Jun 29 07:56 scala-compiler.jar

      -rw-r--r--  1 paulp  admin  2631211 Jun 29 07:56 scala-library.jar

      -rw-r--r--  1 paulp  admin  2995724 Jun 29 07:56 scala-reflect.jar

      -rw-r--r--  1 paulp  admin   838493 Jun 29 07:56 scala-repl.jar

[Jason Zaugg]

On Fri, Jan 18, 2013 at 4:57 PM, Rex Kerr <ich...@gmail.com> wrote:

There weren't 10 things on the table, there were three; one was a clear win, and the other two added up to less than 5% total and seemed a bit questionable to me.

I agree that if we had ten things that were 4% each, we shouldn't reject each one individually.  But right now, 2.10 looks something like

To me, JAR size is a secondary concern. We're really looking for liberate parts of the library. 

Right now, all contributions to scala/scala are subject to the same process for code review, source and binary compatibility, and are governed by a single release schedule. But perhaps scala-swing, for example, could attract more external contributions if it could be released more frequently, and if contributions didn't filter through the central scala/scala pull request queue, and pass the entire scala test suite. (Our current policy only accepts tested patches, but we have no test framework for scala-swing, so by the letter of the law its development is frozen.) Perhaps some young libraries could offer weaker compatibility guarantees until they graduated, but are of sufficient use to include in a distro (like scala-reflect today).

I don't believe that we'll find _that_ many candidates for extraction: the stdlib isn't that big to start with, and post-factum modularization efforts usually get stuck on thorny circular dependencies, which are hard to decouple in a backwards compatible way (collection.parallel <-> collection, for example.)

But we should start with one or two candidates, and fine tune our build/test infrastructure to handle the brave new modular world..

-jason

[Paul Phillips]

On Fri, Jan 18, 2013 at 9:21 AM, Jason Zaugg <jza...@gmail.com> wrote:

To me, JAR size is a secondary concern. We're really looking for liberate parts of the library. 

Emphasis on this. I'm sure I sometimes speak of "jar size" but am indifferent to jar size itself. Jar size is a coarse but accurate proxy for many other things, correlating strongly positively with the maintenance burden on the core developers and strongly negatively with modularity/flexibility. We must give people a better chance to improve the parts they want to improve.

[Rex Kerr]

On Fri, Jan 18, 2013 at 12:21 PM, Jason Zaugg <jza...@gmail.com> wrote:

On Fri, Jan 18, 2013 at 4:57 PM, Rex Kerr <ich...@gmail.com> wrote:

There weren't 10 things on the table, there were three; one was a clear win, and the other two added up to less than 5% total and seemed a bit questionable to me.

I agree that if we had ten things that were 4% each, we shouldn't reject each one individually.  But right now, 2.10 looks something like

To me, JAR size is a secondary concern. We're really looking for liberate parts of the library. 

Right now, all contributions to scala/scala are subject to the same process for code review, source and binary compatibility, and are governed by a single release schedule.

Well, if it works out well, I'm all for it.  But I'm skeptical that this won't create more version compatibility pain than it solves in terms of better features.  At the end of the day, you don't want low-quality code to be part of the distribution, so someone is going to have to spend some time to make sure the code is decent.  Chopping it up into modules might help a little in that you could assign people to different areas (but you could do that anyway...), but I'm unconvinced that the solution is a solution without going all the way to just plain dropping the code from the distribution (at which point you're not responsible any more for whether it works).

Anyway, I hope it works.

  --Rex

P.S. If I had a patch to Swing, and the problem was a lack of unit tests, I'd write a unit test for the old broken case and the new case, and then it would pass the existing hurdle, correct?

 

[Jason Zaugg]

On Fri, Jan 18, 2013 at 7:41 PM, Rex Kerr <ich...@gmail.com> wrote:

Right now, all contributions to scala/scala are subject to the same process for code review, source and binary compatibility, and are governed by a single release schedule.

Well, if it works out well, I'm all for it.  But I'm skeptical that this won't create more version compatibility pain than it solves in terms of better features.  At the end of the day, you don't want low-quality code to be part of the distribution, so someone is going to have to spend some time to make sure the code is decent.  Chopping it up into modules might help a little in that you could assign people to different areas (but you could do that anyway...), but I'm unconvinced that the solution is a solution without going all the way to just plain dropping the code from the distribution (at which point you're not responsible any more for whether it works).

Yeah, the devil will be in the details. But the benefits are important. We will really value advice / feedback / reality checks from the community as we try this.

 

Anyway, I hope it works.

  --Rex

P.S. If I had a patch to Swing, and the problem was a lack of unit tests, I'd write a unit test for the old broken case and the new case, and then it would pass the existing hurdle, correct?

I'm not sure how one goes about testing GUI framework code, you might have to build some test infrastructure first.

-jason

[Rex Kerr]

Eh, it doesn't take much as long as you're willing to run the test on a single (non-headless) machine.  If it's layout, compare screen shots captured with java.awt.Robot.  If it's functionality, make Robot fiddle with your GUI and assert that the right thing happens (within a certain amount of time).

For lightweight testing you don't really need an "infrastructure".

  --Rex

[Paolo G. Giarrusso]

Il giorno venerdì 18 gennaio 2013 18:21:10 UTC+1, Jason Zaugg ha scritto:

On Fri, Jan 18, 2013 at 4:57 PM, Rex Kerr <ich...@gmail.com> wrote:

There weren't 10 things on the table, there were three; one was a clear win, and the other two added up to less than 5% total and seemed a bit questionable to me.

I agree that if we had ten things that were 4% each, we shouldn't reject each one individually.  But right now, 2.10 looks something like

To me, JAR size is a secondary concern. We're really looking for liberate parts of the library. 

Right now, all contributions to scala/scala are subject to the same process for code review, source and binary compatibility, and are governed by a single release schedule. But perhaps scala-swing, for example, could attract more external contributions if it could be released more frequently, and if contributions didn't filter through the central scala/scala pull request queue, and pass the entire scala test suite. (Our current policy only accepts tested patches, but we have no test framework for scala-swing, so by the letter of the law its development is frozen.) Perhaps some young libraries could offer weaker compatibility guarantees until they graduated, but are of sufficient use to include in a distro (like scala-reflect today).

 

Scala's standard library is a strange thing currently. Scala neither comes "with batteries included" (à la Python, or somewhat à la Java) nor has a minimal library limited to the core language (like Haskell?), including things like reflection and runtime support.

With Maven/SBT, the convenience of having something built-in is much reduced. Moreover, one of the goals of Scala is that you can do so much in a library that there's little need for built-in functionality.

I see only few advantages of having something in the *standard* library, excluding stuff which *has* to be there because it's part of the language (like reflection):

• standardization: to compose arbitrary components, they'll need to share some datatypes - if everybody used their own Int we'd be lost. Similarly if they'd use their own collection interfaces (implementations are a different matter), or their own variation of Option. Maybe they wouldn't even discover generic abstractions like Option - that's the Java case. Scala's a fine language for building adaptors (which can be implicit conversions), but building them is still work.
  This requires keeping carefully chosen core abstractions in, such as Option, much of the scala package and some of scala.math, such as scala.math.Ordering. It also extends to the interfaces of Scala collections - the compiler depends on them for handling e.g. repeated parameters.
• discoverability: if you want to choose library A for one use case at the expense of others, because you believe it's a very good one, then you might want to have it in the standard library, especially if standardization is useful.
  To me, this is an argument against the XML library since it's *not* the best library available (AFAIK). That library was a (failed) attempt to include "batteries" for a very important utility.
• stability: being in the standard library (should) imply a high-level of support and stability (binary/source compatibility, a deprecation policy, etc.). Of course, this is also a disadvantage.

The main disadvantage is that you're committing to support that library for much longer, that the number of core developers doesn't really correlate with the size of the standard library, etc. For a lot of stuff, picking the best which the community evolved might probably work better.

I believe we could investigate switching to a Haskell-Platform-like model, although I don't know which other libraries to include in this platform (I can only think of Scalaz).

Anyway, I've taken a closer look at Paul Phillips branch, using Github's compare interface: https://github.com/paulp/scala/compare/prime

It seems most of his savings are not whole packages, but in a lots of bits and pieces of code. The problem with that is that they can't be modularized easily - not with the current interface, because you can't really split a package between JARs. So moving e.g. scala.collection.mutable.Synchronized* (https://github.com/paulp/scala/commit/5c9bdaf522a6b2531ab40fdfd5c21fe8766f4814) won't work. But maybe you could move them elsewhere and add deprecated type aliases to keep source compatibility.

Paul, the real question is: some of those changes don't affect the API and are useful. What are they waiting for? Is help wanted?

[Simon Ochsenreither]

I'd be happy already if we could just get that single change into 2.12: https://github.com/paulp/scala/commit/e7b1c063721354a05010bc91c63af003e91ef0f5

Considering that we have a superior replacement with the various string interpolation methods, could we at least deprecate it for 2.11?

[Paul Phillips]

On Sat, Jan 19, 2013 at 10:53 AM, Paolo G. Giarrusso <p.gia...@gmail.com> wrote:

Paul, the real question is: some of those changes don't affect the API and are useful. What are they waiting for? Is help wanted?

My difficulty for as long as I've been doing this is that I have a lot more energy to write code than I do for convincing people to use it. You think there's some useful code in there, that's the tip of the tip of the iceberg.

You, or anyone, is always welcome to extract anything I've written and to send a pull request against master. I have found that for each pull request I open, I can expect at least an hour of additional work - often a lot more - before it will be merged, if indeed it will be. Just trying to work through my backlog of already written code is a continual process of:

 - finding finished code

 - bringing up to date with master

 - sending pull request

 - which leads to various debates and most likely more code 

 - if I'm lucky, that closes one open loop. 500 to go!

I'm not complaining - the average quality of code going into trunk has gone up so much, this is a small price to pay - but even if I were willing to do nothing but navigate the pull request waters, I could not on my own catch up to the code I've already written. So "what are they waiting for", that's what.

I have this nice dream someone will come along and help me work through this. (This is only a portion.)

                   master...bud/<branch>  behind   ahead   last

                   ---------------------  ------   -----   ----

                                  master  -0          +0   2013-01-17   (2 days ago)

                        patmat-recursion  -88         +1   2013-01-08   (11 days ago)

                        compact-hash-map  -88         +3   2013-01-07   (12 days ago)

                     dealias-widen-redux  -102        +1   2013-01-02   (2 weeks ago)

               dealias-widen-redux-saved  -102        +5   2013-01-02   (2 weeks ago)

                     pr/reference-equals  -116        +2   2012-12-31   (3 weeks ago)

                      overriding-pairs-1  -136        +1   2012-12-28   (3 weeks ago)

                      overriding-pairs-2  -136        +2   2012-12-28   (3 weeks ago)

                      pr-soc-name-mangle  -136        +1   2012-12-28   (3 weeks ago)

                        pr/1813-addendum  -139        +2   2012-12-28   (3 weeks ago)

                        pr/1817-addendum  -139        +3   2012-12-28   (3 weeks ago)

                   pr/overriding-methods  -136        +3   2012-12-28   (3 weeks ago)

                     pr/overriding-pairs  -136        +2   2012-12-28   (3 weeks ago)

               util/measure-length-calls  -136        +1   2012-12-28   (3 weeks ago)

               refactor-companion-symbol  -136        +1   2012-12-27   (3 weeks ago)

               tmp-override-set-creation  -136        +1   2012-12-27   (3 weeks ago)

            topic/specialized-small-seqs  -136        +1   2012-12-27   (3 weeks ago)

          util/count-closure-allocations  -136        +1   2012-12-27   (3 weeks ago)

           trace-dealias-widen-normalize  -140        +5   2012-12-23   (4 weeks ago)

                   infer/dummy-type-args  -142        +7   2012-12-21   (4 weeks ago)

                      topic/existentials  -176        +8   2012-12-21   (4 weeks ago)

                              issue/3452  -176        +5   2012-12-20   (4 weeks ago)

                        issue/3452-saved  -176        +2   2012-12-20   (4 weeks ago)

                              issue/5301  -142        +3   2012-12-20   (4 weeks ago)

                             log-javaSig  -176        +1   2012-12-20   (4 weeks ago)

                topic/warn-value-discard  -176        +2   2012-12-20   (4 weeks ago)

          wip/warn-unnecessary-self-type  -181        +1   2012-12-19   (4 weeks ago)

                              zip-vs-jar  -181        +5   2012-12-19   (4 weeks ago)

             dec18-overriding-pairs-sigs  -182        +9   2012-12-18   (5 weeks ago)

       dec18-overriding-pairs-sigs-saved  -182        +8   2012-12-18   (5 weeks ago)

                   pr/move-implicit-tags  -182        +1   2012-12-18   (5 weeks ago)

                  context-more-immutable  -182        +5   2012-12-17   (5 weeks ago)

                 topic/no-pickle-skolems  -181        +9   2012-12-17   (5 weeks ago)

                     topic/predicate-ops  -182        +1   2012-12-17   (5 weeks ago)

                                  mytype  -182        +4   2012-12-16   (5 weeks ago)

                   tree-copiers-code-gen  -186        +1   2012-12-12   (5 weeks ago)

                        context-printing  -237        +4   2012-12-10   (6 weeks ago)

                     dec6-type-inference  -237        +2   2012-12-10   (6 weeks ago)

                            elim-sharing  -241        +1   2012-12-10   (6 weeks ago)

                      pos-sourcecode-bak  -242        +3   2012-12-10   (6 weeks ago)

                         pr-repairs/5717  -242        +2   2012-12-10   (6 weeks ago)

                          subtree-owners  -242        +1   2012-12-10   (6 weeks ago)

                           issues-genjvm  -242        +2   2012-12-09   (6 weeks ago)

                        subtree-analysis  -242        +2   2012-12-09   (6 weeks ago)

                    subtree-mark-mutable  -242        +1   2012-12-09   (6 weeks ago)

                                    scct  -529        +3   2012-12-08   (6 weeks ago)

                   tmp/no-name-in-select  -246        +5   2012-12-08   (6 weeks ago)

                        rangepos-in-long  -246       +26   2012-12-07   (6 weeks ago)

                          exhaustiveness  -249        +6   2012-12-06   (6 weeks ago)

                         match-fun-typer  -483        +1   2012-12-04   (7 weeks ago)

                             javap-java7  -269        +2   2012-12-03   (7 weeks ago)

               set-bound-types-in-parser  -269        +4   2012-12-03   (7 weeks ago)

                         reifier-cleanup  -273        +2   2012-12-02   (7 weeks ago)

            context-more-immutable-saved  -273       +34   2012-12-01   (7 weeks ago)

          context-more-immutable-saved-2  -273       +12   2012-12-01   (7 weeks ago)

                              issue/6735  -273        +1   2012-11-29   (7 weeks ago)

                           tree-checkers  -273        +1   2012-11-29   (7 weeks ago)

                            clones-redux  -274        +2   2012-11-27   (8 weeks ago)

               log-uninitialized-symbols  -274        +1   2012-11-27   (8 weeks ago)

                                 spatter  -274        +1   2012-11-27   (8 weeks ago)

                       atPhase-on-clones  -274        +7   2012-11-26   (8 weeks ago)

                  lambda-lift-duplicates  -274        +1   2012-11-25   (8 weeks ago)

                                    lint  -298        +4   2012-11-24   (8 weeks ago)

                         product-element  -511        +4   2012-11-24   (8 weeks ago)

                          warn-dead-code  -320        +1   2012-11-20   (9 weeks ago)

                 string-literal-warnings  -339        +1   2012-11-15   (9 weeks ago)

                            symbol-graph  -339        +6   2012-11-15   (9 weeks ago)

                      conifer/issue/4003  -344        +1   2012-11-14   (9 weeks ago)

        implicit-configures-lazy-locking  -343        +2   2012-11-14   (9 weeks ago)

                         static-analysis  -346       +12   2012-11-13   (10 weeks ago)

                           tree-lifetime  -346        +1   2012-11-13   (10 weeks ago)

                 wip/plausibly-inhabited  -580        +3   2012-11-13   (10 weeks ago)

                          parallel-typer  -347        +1   2012-11-12   (10 weeks ago)

                     wip/log-symbol-lies  -358        +5   2012-11-09   (2 months ago)

               wip/log-symbol-lies-saved  -358       +12   2012-11-09   (2 months ago)

                           typer-timings  -358        +5   2012-11-08   (2 months ago)

                 conifer/typeref-cleanup  -388        +3   2012-11-06   (2 months ago)

                            repl-checkin  -391        +7   2012-11-05   (3 months ago)

                         issue/441-saved  -400        +1   2012-11-04   (3 months ago)

                            nov4-salvage  -391        +2   2012-11-04   (3 months ago)

                            repl-current  -391        +9   2012-11-04   (3 months ago)

                    string-interpolation  -397        +1   2012-11-04   (3 months ago)

                           is-importable  -403        +2   2012-11-03   (3 months ago)

                        repl-current-new  -403       +11   2012-11-03   (3 months ago)

                        repl-current-tmp  -403        +6   2012-11-03   (3 months ago)

                      repl-triple-quotes  -403        +1   2012-11-03   (3 months ago)

                             scope-tests  -399        +2   2012-11-03   (3 months ago)

                           topic/expecty  -402        +3   2012-11-03   (3 months ago)

           topic/expecty-rich-assertions  -402        +9   2012-11-03   (3 months ago)

                     topic/trait-erasure  -1654       +1   2012-11-03   (3 months ago)

                           fix-sbt-build  -416        +1   2012-11-01   (3 months ago)

                     fix-checkinit-saved  -443        +4   2012-10-31   (3 months ago)

                              repl-notes  -443        +1   2012-10-31   (3 months ago)

                              issue/5962  -571        +2   2012-10-30   (3 months ago)

                              issue/6591  -443        +1   2012-10-30   (3 months ago)

                      value-classes/6411  -571        +3   2012-10-30   (3 months ago)

             conifer/truly-final-boolean  -727        +5   2012-10-29   (3 months ago)

                                repl-api  -443        +6   2012-10-29   (3 months ago)

                        repl-static-cell  -443       +12   2012-10-29   (3 months ago)

                        repl-typed-trees  -443        +5   2012-10-28   (3 months ago)

                          repl-type-tags  -443        +3   2012-10-27   (3 months ago)

                         delete-old-code  -443        +1   2012-10-26   (3 months ago)

                             parser/5606  -443        +1   2012-10-26   (3 months ago)

                          pos-sourcecode  -443        +3   2012-10-26   (3 months ago)

                      stem/topic/tailrec  -443        +2   2012-10-26   (3 months ago)

                             topic/paths  -443        +1   2012-10-26   (3 months ago)

                            weaken-types  -1650       +1   2012-10-26   (3 months ago)

                       companion-methods  -443        +2   2012-10-24   (3 months ago)

                         fewer-overrides  -444        +3   2012-10-23   (3 months ago)

                              infer/5103  -443        +1   2012-10-23   (3 months ago)

               infer/5294-beta-reduction  -443       +12   2012-10-23   (3 months ago)

                           infer/various  -443        +7   2012-10-23   (3 months ago)

                         log/scope-enter  -443        +1   2012-10-23   (3 months ago)

                            mini-patches  -443        +2   2012-10-23   (3 months ago)

                           pending-tests  -443        +3   2012-10-23   (3 months ago)

                       symbol-pairs/1459  -443        +1   2012-10-23   (3 months ago)

                       symbol-pairs/3452  -443        +1   2012-10-23   (3 months ago)

                              topic/repl  -443        +1   2012-10-23   (3 months ago)

          value-classes/6500-bad-bridges  -443        +3   2012-10-23   (3 months ago)

                             array-match  -1559       +1   2012-10-22   (3 months ago)

             conifer/missing-close-brace  -450        +5   2012-10-22   (3 months ago)

                       pairwise-iterator  -502        +1   2012-10-22   (3 months ago)

                  topic/compiler-hackers  -1654       +9   2012-10-22   (3 months ago)

        conifer/topic/context-and-errors  -502       +10   2012-10-21   (3 months ago)

        conifer/topic/reporting-function  -502        +1   2012-10-21   (3 months ago)

                  conifer/foreach-master  -450        +9   2012-10-20   (3 months ago)

             conifer/primitive-companion  -509        +4   2012-10-19   (3 months ago)

                        overriddenSymbol  -509       +11   2012-10-19   (3 months ago)

                     conifer/dummy-check  -510        +1   2012-10-18   (3 months ago)

   conifer/ident-is-this-selection-saved  -510        +2   2012-10-18   (3 months ago)

                        external-foreach  -579        +3   2012-10-18   (3 months ago)

              conifer/no-override-equals  -579        +2   2012-10-17   (3 months ago)

                conifer/external-foreach  -579        +3   2012-10-16   (3 months ago)

          conifer/external-foreach-saved  -579        +9   2012-10-16   (3 months ago)

                  value-class-extractors  -631       +10   2012-10-15   (3 months ago)

              create-from-cloned-symbols  -512        +3   2012-10-14   (3 months ago)

                       java7-io-wrappers  -512        +1   2012-10-14   (3 months ago)

                            qualify-name  -512        +1   2012-10-14   (3 months ago)

           salvage/classfile-transformer  -512        +1   2012-10-14   (3 months ago)

                       stable/coloncolon  -512        +2   2012-10-14   (3 months ago)

                        topic/ansi-color  -512        +2   2012-10-14   (3 months ago)

                     topic/class-and-jar  -512        +1   2012-10-14   (3 months ago)

                       topic/conditional  -512        +1   2012-10-14   (3 months ago)

                              topic/enum  -512        +1   2012-10-14   (3 months ago)

                       topic/error-hooks  -512        +1   2012-10-14   (3 months ago)

                            topic/hlists  -512        +5   2012-10-14   (3 months ago)

                            topic/jacoco  -512        +1   2012-10-14   (3 months ago)

                      topic/jacoco-redux  -512        +3   2012-10-14   (3 months ago)

                           topic/juniper  -512        +2   2012-10-14   (3 months ago)

                    topic/lib/fixed-list  -512        +1   2012-10-14   (3 months ago)

                     topic/lib/proptions  -512        +1   2012-10-14   (3 months ago)

                    topic/macro-splicing  -512        +1   2012-10-14   (3 months ago)

                       topic/nullFlatMap  -512        +1   2012-10-14   (3 months ago)

                      topic/object-sizer  -512        +1   2012-10-14   (3 months ago)

                     topic/proxy-checker  -512        +1   2012-10-14   (3 months ago)

                   topic/repl-preloading  -512        +1   2012-10-14   (3 months ago)

                       topic/sha-resolve  -512        +1   2012-10-14   (3 months ago)

                  topic/types_have_kinds  -512        +2   2012-10-14   (3 months ago)

              topic/weaken-until-visible  -512        +1   2012-10-14   (3 months ago)

           traversable-extension-methods  -512        +1   2012-10-14   (3 months ago)

                       typesafe-contains  -512        +1   2012-10-14   (3 months ago)

         conifer/no-contains-uncheckable  -513        +4   2012-10-11   (3 months ago)

               conifer/phases-out-of-run  -514        +1   2012-10-11   (3 months ago)

                 conifer/range-head-slow  -513        +1   2012-10-11   (3 months ago)

                   conifer/macro-minimum  -605        +1   2012-10-10   (3 months ago)

               conifer/macro-collections  -533        +6   2012-10-08   (3 months ago)

            conifer/genasm-genjvm-common  -638        +5   2012-10-07   (3 months ago)

            conifer/final-symbol-in-tree  -572        +3   2012-10-06   (4 months ago)

                 conifer/mkattributedref  -539       +12   2012-10-06   (4 months ago)

                      conifer/issue/6472  -554        +2   2012-10-04   (4 months ago)

      conifer/hacky-any2stringadd-report  -554        +1   2012-10-03   (4 months ago)

                         stringadd-macro  -554        +9   2012-10-03   (4 months ago)

                   conifer/gitattributes  -731        +1   2012-09-20   (4 months ago)

                      conifer/issue/6358  -799        +3   2012-09-16   (4 months ago)

              leaf/topic/pure-annotation  -828        +1   2012-09-15   (4 months ago)

                   no-unsafe-type-params  -835        +4   2012-09-13   (4 months ago)

               conifer/narrow-experiment  -842        +7   2012-09-12   (4 months ago)

                   conifer/topic/makeNew  -843        +1   2012-09-12   (4 months ago)

           conifer/topic/no-infer-anyval  -856        +1   2012-09-11   (4 months ago)

                  conifer/macro-list-map  -878        +2   2012-09-08   (4 months ago)

                    topic/no-eager-table  -878        +4   2012-09-08   (4 months ago)

                       overloaded-symbol  -1189       +1   2012-09-07   (4 months ago)

                               repl/4714  -828        +2   2012-09-07   (4 months ago)

                       symbol-pairs/1409  -828        +1   2012-09-07   (4 months ago)

                  conifer/topic/no-infer  -878        +6   2012-09-06   (5 months ago)

                  conifer/topic/duration  -886        +1   2012-09-05   (5 months ago)

         conifer/topic/module-forwarders  -887        +2   2012-09-04   (5 months ago)

                topic/makeAccessible-fix  -887        +1   2012-09-04   (5 months ago)

                      conifer/issue/6260  -914        +2   2012-09-02   (5 months ago)

         conifer/topic/flags-value-class  -899        +1   2012-09-02   (5 months ago)

                      conifer/issue/4714  -880        +2   2012-09-01   (5 months ago)

                      conifer/issue/4880  -880        +1   2012-09-01   (5 months ago)

             conifer/topic/any2stringadd  -929        +2   2012-09-01   (5 months ago)

                    topic/partest-sprint  -929        +1   2012-09-01   (5 months ago)

                         leaf/issue/4695  -930        +1   2012-08-30   (5 months ago)

                         leaf/issue/6245  -941        +2   2012-08-29   (5 months ago)

        conifer/topic/inferred-type-tree  -965        +3   2012-08-22   (5 months ago)

          conifer/topic/types_have_kinds  -932        +1   2012-08-22   (5 months ago)

                                stem/opt  -1004      +25   2012-08-17   (5 months ago)

                       stem/reusable-cbf  -1004       +1   2012-08-16   (5 months ago)

                         stem/issue/6135  -1004       +1   2012-08-15   (5 months ago)

                          topic/arrayops  -1025       +1   2012-08-15   (5 months ago)

                  leaf/jul11-attachments  -1004       +6   2012-08-14   (5 months ago)

            conifer/topic/compound-names  -1095       +2   2012-08-06   (6 months ago)

                   topic/blame-log-noise  -1095       +8   2012-08-06   (6 months ago)

           conifer/topic/no-nsc-in-tools  -1096       +1   2012-08-04   (6 months ago)

       conifer/topic/type-printing-saved  -1141       +4   2012-07-30   (6 months ago)

              stem/fewer-inline-warnings  -1152       +1   2012-07-29   (6 months ago)

                   stem/issue/4560-saved  -1179       +9   2012-07-24   (6 months ago)

                              stem/jul24  -1180       +3   2012-07-24   (6 months ago)

                         stem/issue/6117  -1189       +5   2012-07-21   (6 months ago)

                  stem/jul13-stale-redux  -1262       +4   2012-07-21   (6 months ago)

                      stem/jun18-reflect  -1262       +1   2012-07-21   (6 months ago)

              stem/salvage-repl-june2012  -1262       +3   2012-07-21   (6 months ago)

                stem/topic/compiler-docs  -1262       +1   2012-07-21   (6 months ago)

     stem/topic/outer-fields-test-update  -1192       +1   2012-07-21   (6 months ago)

                stem/optimize/findmember  -1297      +15   2012-07-14   (6 months ago)

                     topic/trace-symbols  -1298       +3   2012-07-13   (6 months ago)

             leaf/jun3-names-and-backend  -1559      +12   2012-07-12   (6 months ago)

                 stem/topic/scalaruntime  -2439       +2   2012-07-12   (6 months ago)

                  leaf/topic/javap-java7  -1319       +2   2012-07-11   (6 months ago)

                                   prime  -1319     +255   2012-07-11   (6 months ago)

                 leaf/jul3-origins-redux  -1376       +4   2012-07-04   (7 months ago)

                         stem/issue/5712  -1387       +4   2012-07-02   (7 months ago)

                   topic/generics-parser  -1387       +1   2012-07-02   (7 months ago)

              stem/topic/package-objects  -1394       +1   2012-06-30   (7 months ago)

                        stem/topic/tools  -1394       +1   2012-06-30   (7 months ago)

              stem/topic/typesafe-format  -1394       +3   2012-06-30   (7 months ago)

                topic/lib/equals-helpers  -1395       +1   2012-06-29   (7 months ago)

                 topic/no-auto-coercions  -7029       +4   2012-06-29   (7 months ago)

                    topic/phase-assembly  -3122       +3   2012-06-29   (7 months ago)

                stem/topic/methodhandles  -1400      +12   2012-06-27   (7 months ago)

                           prime-current  -1433     +262   2012-06-23   (7 months ago)

                       stem/topic/gradle  -1433       +2   2012-06-23   (7 months ago)

                stem/prime-imports-saved  -1439     +254   2012-06-22   (7 months ago)

                 stem/prime-jun22-backup  -1439     +260   2012-06-22   (7 months ago)

                           conifer/paolo  -1470       +9   2012-06-18   (7 months ago)

                         stem/issue/1570  -1470       +1   2012-06-18   (7 months ago)

                        stem/patches-dev  -1470       +6   2012-06-18   (7 months ago)

         stem/prime-reflect-global-saved  -1473     +230   2012-06-18   (7 months ago)

             stem/prime-this-object-jun1  -1578     +150   2012-06-18   (7 months ago)

               stem/topic/null-hardening  -1470       +1   2012-06-18   (7 months ago)

                   stem/topic/repl-javac  -1470       +1   2012-06-18   (7 months ago)

         stem/topic/clone-symbol-history  -1473       +1   2012-06-17   (7 months ago)

stem/topic/lift-classes-from-package-...  -1473       +1   2012-06-17   (7 months ago)

                         stem/issue/2897  -1476       +2   2012-06-16   (7 months ago)

                         stem/issue/4440  -1476       +1   2012-06-16   (7 months ago)

       stem/topic/freeze-thaw-collection  -1476       +1   2012-06-16   (7 months ago)

                   stem/topic/scalacheck  -1487       +5   2012-06-14   (7 months ago)

            stem/topic/connected-fbounds  -1491      +15   2012-06-12   (7 months ago)

     stem/topic/connected-fbounds-backup  -1491       +6   2012-06-12   (7 months ago)

    stem/topic/connected-fbounds-backup2  -1491      +10   2012-06-12   (7 months ago)

                 topic/connected-fbounds  -1491       +4   2012-06-12   (7 months ago)

                     prime-collections-2  -1551     +210   2012-06-08   (8 months ago)

                 stem/prime-contains-wip  -1552     +204   2012-06-07   (8 months ago)

                           topic/lubstub  -1559       +8   2012-06-06   (8 months ago)

                     topic/lubstub-prime  -1560     +193   2012-06-06   (8 months ago)

                  stem/topic/wrong-flags  -1559       +6   2012-06-05   (8 months ago)

             stem/jun3-names-and-backend  -1564      +11   2012-06-03   (8 months ago)

                  stem/prime-collections  -1578     +153   2012-06-02   (8 months ago)

               stem/prime-explicit-kinds  -1578     +149   2012-06-01   (8 months ago)

               stem/topic/prime-ordering  -1578     +151   2012-06-01   (8 months ago)

                stem/topic/fbounded-lubs  -1580       +5   2012-05-31   (8 months ago)

                          topic/lean-dev  -1588     +119   2012-05-29   (8 months ago)

             stem/topic/monomorphic-flag  -1587       +1   2012-05-27   (8 months ago)

                         stem/topic/repl  -1587       +7   2012-05-27   (8 months ago)

                           topic/erasure  -1589       +1   2012-05-26   (8 months ago)

               stem/topic/modular-patmat  -1595       +1   2012-05-25   (8 months ago)

              topic/lean-saved-manifests  -1607      +80   2012-05-24   (8 months ago)

                         stem/issue/5821  -1616       +2   2012-05-23   (8 months ago)

                        symbolic-freedom  -1961       +2   2012-05-23   (8 months ago)

                       stem/topic/cycles  -1637       +1   2012-05-21   (8 months ago)

                      stem/topic/erasure  -1650       +1   2012-05-19   (8 months ago)

                      stem/topic/nothing  -2503      +30   2012-05-19   (8 months ago)

                    stem/topic/positions  -2264       +6   2012-05-19   (8 months ago)

                     dynamic-named-param  -1654       +1   2012-05-18   (8 months ago)

                        stem/topic/mixin  -1654       +1   2012-05-18   (8 months ago)

               stem/topic/outer-pointers  -1654       +1   2012-05-18   (8 months ago)

                        stem/topic/range  -1654       +1   2012-05-18   (8 months ago)

             topic/depends-on-annotation  -2086       +3   2012-05-18   (8 months ago)

               topic/implicits-in-predef  -1654       +2   2012-05-18   (8 months ago)

                      topic/scalaruntime  -1654       +2   2012-05-18   (8 months ago)

                  topic/serialize-symtab  -1654       +1   2012-05-18   (8 months ago)

                          stable/yourkit  -1663       +1   2012-05-17   (8 months ago)

                                  jsr292  -4289     +255   2012-05-02   (9 months ago)

             topic/presentation-compiler  -2150       +1   2012-03-27   (10 months ago)

[Simon Ochsenreither]

• The JSON classes feel a bit like they were meant as a code example for the parser combinator library. Compared to hand-tuned libraries, they seem to be too slow for any serious usage. There has to be a reason why it is not used in the wild. I guess it would make sense to ask those Scala projects which use other JSON libraries and investigate why they don't use the one shipping with Scala.

I may be misremembering but I thought we agreed long ago to deprecate and remove the json library. I'm displeased to see that it's not even deprecated.

https://github.com/scala/scala/pull/2581

[Adriaan Moors]

Thanks, Simon!

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

See you at Scala Days (June 10–12, NYC)!

[Simon Ochsenreither]

I have split scala.util.parsing from the main library and moved it to a new scala-parsing.jar:

https://github.com/soc/scala/tree/SI-6811-parsing
(No guarantees that I have found all the places where the Ant build file needs to be modified!)

This saves us roughly 410 kB and brings scala-library.jar from 6.8 MB down to 6.4 MB.

Opinions?

[Simon Ochsenreither]

Any decision yet whether we want this?

[Simon Ochsenreither]

Anyone against deprecating scala.text, that is the single scala file in that package?
PR here: https://github.com/scala/scala/pull/2733

[Josh Suereth]

hmm, I seem to recall that on my deprecation list for 2.10.0, so I'm for.

On Sun, Jul 14, 2013 at 8:52 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Anyone against deprecating scala.text, that is the single scala file in that package?
PR here: https://github.com/scala/scala/pull/2733

[Rex Kerr]

It would be great especially for scaladoc if we could get rid of scala.text as soon as possible.  It doesn't add much to the weight of the library, but it's barely documented and eats up valuable screen estate when browsing the library.  Very much for deprecation!

  --Rex

On Sun, Jul 14, 2013 at 8:52 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Anyone against deprecating scala.text, that is the single scala file in that package?
PR here: https://github.com/scala/scala/pull/2733

[Seth Tisue]

On Sun, Jul 14, 2013 at 11:39 PM, Rex Kerr <ich...@gmail.com> wrote:
> It would be great especially for scaladoc if we could get rid of scala.text
> as soon as possible. It doesn't add much to the weight of the library, but
> it's barely documented and eats up valuable screen estate when browsing the
> library. Very much for deprecation!

Yeah, a great bang/buck on this. A whole package gone, and an
identifier ("text") removed from the default namespace:

scala> text
<console>:8: error: package scala.text is not a value
text
^

[Grzegorz Kossakowski]

+1

--
Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski