A few hours ago I put up my personal Maven repo at
https://bitbucket.org/xeno.by/mavenrepo/raw/master/, uploaded a custom
snapshot of Scala and tried to build scalacheck against it.

After some googling I found out how to make SBT ignore the standard
scala-tools repo and load Scala from a custom repo, and adjusted
build.sbt accordingly: https://bitbucket.org/xeno.by/mavenrepo/src/d651aa74420e/build.sbt.

However, to my surprise, when presented with scalaVersion := "2.10.0-
SNAPSHOT", SBT still went to scala-tools and ignored the custom repo.
To be 100% sure I destroyed all relevant caches (~/.sbt, ~.ivy2) and
tried again - with no luck.

I think that my repository is fine, since: a) it replicates the
structure of scala-tools.org, b) maven-ant is okay with it and happily
down

and metadata is out-of-date, e.g.:
https://github.com/scala/scala/blob/master/src/build/maven/scala-compile....

Recently I've discovered that typechecking isn't idempotent w.r.t. unapplies, i.e. if you:1) take a well-typed pattern match that contains extractors
2) typecheck it3) reset all attrs 4) typecheck it
Then step #4 will crash, because of the <unapply-selector> guy that's generated during step #2.

This summary is intended for Scala contributors and maintainers, and assumes a certain familiarity with Scala's internals.

It is for your information only, provided “AS

I'm preparing a topic offer for a student project, to enable GenJVM to emit classfiles with version number >= 50.0

For that I'm considering ASM [1] because in addition to being fast, allow multi-threading (different threads emitting different classes), it can also compute stack map frames on the fly [2] [3].

Before moving forward with the topic offer, a question to the list: do you know of any previous attempts at the idea?


Miguel
http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/


[1] http://asm.ow2.org/

[Moved to scala-internals]

I do not write appeals of this nature with any frequency, and I
don't expect to make a habit of it. I recently experienced a couple
days where I allowed myself to pay no attention to all those little
matters which arise every day, and just work on the codebase.

After some feedback last week on the improved Inliner, I essentially refactored my changes adding documentation and additional improvements along the way. These are all the optimizations I see applicable in a sequential version (hint hint: there might be a parallel version in the future).

If you ask me, I think its code quality is ripe enough for a pull request into trunk. Which makes your feedback all the more important (and who doesn't want for -optimize to run about twice faster). It would be great if you could field-test the following branch with your apps of choice:

   https://github.com/magarciaEPFL/scala/tree/improvedInliner

Any reason for tree transformers to ignore the fun of UnApply?
https://github.com/scala/scala/blob/master/src/library/scala/reflect/api/Trees.scala#L1199