Jason Zaugg | 21 Apr 17:26 2014

Scala 2.11.0 is now available

We are very pleased to announce the final release of Scala 2.11.0!

There have been no code changes since RC4, just improvements to documentation and version bump to the most recent stable version of Akka actors. Here's difference between the release and RC4.

Code that compiled on 2.10.x without deprecation warnings should compile on 2.11.x (we do not guarantee this for experimental APIs, such as reflection). If not, please file a regression. We are working with the community to ensure availability of the core projects of the Scala 2.11.x eco-system, please see below for a list. This release is not binary compatible with the 2.10.x series, to allow us to keep improving the Scala standard library.

The Scala 2.11.x series targets Java 6, with (evolving) experimental support for Java 8. In 2.11.0, Java 8 support is mostly limited to reading Java 8 bytecode and parsing Java 8 source. Stay tuned for more complete (experimental) Java 8 support.

New features in the 2.11 series

This release contains all of the bug fixes and improvements made in the 2.10 series, as well as:

  • Collections
    • Immutable HashMaps and HashSets perform faster filters, unions, and the like, with improved structural sharing (lower memory usage or churn).
    • Mutable LongMap and AnyRefMap have been added to provide improved performance when keys are Long or AnyRef (performance enhancement of up to 4x or 2x respectively).
    • BigDecimal is more explicit about rounding and numeric representations, and better handles very large values without exhausting memory (by avoiding unnecessary conversions to BigInt).
    • List has improved performance on map, flatMap, and collect.
    • See also Deprecation above: we have slated many classes and methods to become final, to clarify which classes are not meant to be subclassed and to facilitate future maintenance and performance improvements.
  • Modularization
    • The core Scala standard library jar has shed 20% of its bytecode. The modules for xml, parsing, swing as well as the (unsupported) continuations plugin and library are available individually or viascala-library-all. Note that this artifact has weaker binary compatibility guarantees than scala-library -- as explained above.
    • The compiler has been modularized internally, to separate the presentation compiler, scaladoc and the REPL. We hope this will make it easier to contribute. In this release, all of these modules are still packaged in scala-compiler.jar. We plan to ship them in separate JARs in 2.12.x.
  • Reflection, macros and quasiquotes
    • Please see this detailed changelog that lists all significant changes and provides advice on forward and backward compatibility.
    • See also this summary of the experimental side of the 2.11 development cycle.
    • #3321 introduced Sprinter, a new AST pretty-printing library! Very useful for tools that deal with source code.
  • Back-end
    • The GenBCode back-end (experimental in 2.11). See  <at> magarciaepfl's extensive documentation.
    • A new experimental way of compiling closures, implemented by  <at> JamesIry. With -Ydelambdafy:method anonymous functions are compiled faster, with a smaller bytecode footprint. This works by keeping the function body as a private (static, if no this reference is needed) method of the enclosing class, and at the last moment during compilation emitting a small anonymous class that extends FunctionN and delegates to it. This sets the scene for a smooth migration to Java 8-style lambdas (not yet implemented).
    • Branch elimination through constant analysis #2214
  • Compiler Performance
    • Incremental compilation has been improved significantly. To try it out, upgrade to sbt 0.13.2 and add incOptions := incOptions.value.withNameHashing(true) to your build! Other build tools are also supported. More info at this sbt issue -- that's where most of the work happened. More features are planned, e.g. class-based tracking.
    • We've been optimizing the batch compiler's performance as well, and will continue to work on this during the 2.11.x cycle.
    • Improve performance of reflection SI-6638
  • IDE
  • REPL
  • Warnings
    • Warn about unused private / local terms and types, and unused imports, under -Xlint. This will even tell you when a local var could be a val.
  • Slimming down the compiler
    • The experimental .NET backend has been removed from the compiler.
    • Scala 2.10 shipped with new implementations of the Pattern Matcher and the Bytecode Emitter. We have removed the old implementations.
    • Search and destroy mission for ~5000 chunks of dead code. #1648

The Scala team and contributors fixed 613 bugs that are exclusive to Scala 2.11.0! We also backported as many as possible. With the release of 2.11, 2.10 backports will be dialed back.

A big thank you to everyone who's helped improve Scala by reporting bugs, improving our documentation, participating in mailing lists and other public fora, and -- of course -- submitting and reviewing pull requests! You are all awesome.

Concretely, according to git log --no-merges --oneline master --not 2.10.x --format='%aN' | sort | uniq -c | sort -rn, 111 people contributed code, tests, and/or documentation to Scala 2.11.x: Paul Phillips, Jason Zaugg, Eugene Burmako, Adriaan Moors, A. P. Marki, Simon Ochsenreither, Den Shabalin, Miguel Garcia, James Iry, Iain McGinniss, Rex Kerr, Grzegorz Kossakowski, Vladimir Nikolaev, Eugene Vigdorchik, François Garillot, Mirco Dotta, Rüdiger Klaehn, Raphael Jolly, Simon Schaefer, Kenji Yoshida, Paolo Giarrusso, Luc Bourlier, Antoine Gourlay, Hubert Plociniczak, Aleksandar Prokopec, Lex Spoon, Andrew Phillips, Vlad Ureche, Sébastien Doeraene, Josh Suereth, Jean-Remi Desjardins, Vojin Jovanovic, Viktor Klang, Valerian, Prashant Sharma, Pavel Pavlov, Michael Thorpe, Jan Niehusmann, Heejong Lee, George Leontiev, Daniel C. Sobral, Christoffer Sawicki, yllan, rjfwhite, Volkan Yazıcı, Ruslan Shevchenko, Robin Green, Roberto Tyley, Olivier Blanvillain, Mark Harrah, Lukas Rytz, James Ward, Iulian Dragos, Ilya Maykov, Eugene Yokota, Erik Osheim, Dan Hopkins, Chris Hodapp, Antonio Cunei, Andriy Polishchuk, Alexander Clare, 杨博, srinivasreddy, secwall, nermin, martijnhoekstra, kurnevsky, jinfu-leng, folone, Yaroslav Klymko, Xusen Yin, Trent Ogren, Tobias Schlatter, Thomas Geier, Stuart Golodetz, Stefan Zeiger, Scott Carey, Samy Dindane, Sagie Davidovich, Runar Bjarnason, Roland Kuhn, Robert Nix, Robert Ladstätter, Rike-Benjamin Schuppner, Rajiv, Philipp Haller, Nada Amin, Mike Morearty, Michael Bayne, Luke Cycon, Lee Mighdoll, Konstantin Fedorov, Julio Santos, Julien Richard-Foy, Juha Heljoranta, Johannes Rudolph, Jiawei Li, Jentsch, Jason Swartz, James Roper, Heather Miller, Havoc Pennington, Evgeny Kotelnikov, Dmitry Petrashko, Dmitry Bushev, David Hall, Daniel Darabos, Dan Rosen, Cody Allen, Carlo Dapor, Brian McKenna, Andrey Kutejko, Alden Torres.

Thank you all very much.

If you find any errors or omissions in these relates notes, please submit a PR!

Reporting Bugs / Known Issues

Please file any bugs you encounter. If you're unsure whether something is a bug, please contact the scala-user mailing list.

Before reporting a bug, please have a look at these known issues.

Scala IDE for Eclipse

The Scala IDE with this release built in is available from this update site for Eclipse 4.2/4.3 (Juno/Kepler). Please have a look at the getting started guide for more info.

Available projects

The following Scala projects have already been released against 2.11.0! We'd love to include yours in this list as soon as it's available -- please submit a PR to update these release notes.

"org.scalacheck" %% "scalacheck" % "1.11.3" "org.scalatest" %% "scalatest" % "2.1.3" "org.scalautils" %% "scalautils" % "2.1.3" "com.typesafe.akka" %% "akka-actor" % "2.3.2" "com.typesafe.scala-logging" %% "scala-logging-slf4j" % "2.0.3" "org.scala-lang.modules" %% "scala-async" % "0.9.1" "org.scalikejdbc" %% "scalikejdbc-interpolation" % "2.0.0-beta1" "com.softwaremill.scalamacrodebug" %% "macros" % "0.4" "com.softwaremill.macwire" %% "macros" % "0.6" "com.chuusai" %% "shapeless" % "1.2.4" "com.chuusai" %% "shapeless" % "2.0.0" "org.nalloc" %% "optional" % "0.1.0" "org.scalaz" %% "scalaz-core" % "7.0.6" "com.nocandysw" %% "platform-executing" % "0.5.0" "com.qifun" %% "stateless-future" % "0.1.1" "com.github.scopt" %% "scopt" % "3.2.0" "com.dongxiguo" %% "fastring" % "0.2.4" "com.github.seratch" %% "ltsv4s" % "1.0.0" "com.googlecode.kiama" %% "kiama" % "1.5.3" "org.scalamock" %% "scalamock-scalatest-support" % "3.0.1" "org.scalamock" %% "scalamock-specs2-support" % "3.0.1" "com.github.nscala-time" %% "nscala-time" % "1.0.0" "com.github.xuwei-k" %% "applybuilder70" % "0.1.2" "com.github.xuwei-k" %% "nobox" % "0.1.9" "org.typelevel" %% "scodec-bits" % "1.0.0" "org.typelevel" %% "scodec-core" % "1.0.0" "com.sksamuel.scrimage" %% "scrimage" % "1.3.20" "net.databinder" %% "dispatch-http" % "0.8.10" "net.databinder" %% "unfiltered" % "0.7.1" "io.argonaut" %% "argonaut" % "6.0.4"

The following projects were released against 2.11.0-RC4, with an 2.11 build hopefully following soon:

"org.scalafx" %% "scalafx" % "8.0.0-R4" "org.scalamacros" %% "paradise" % "2.0.0-M7" "org.specs2" %% "specs2" % "2.3.10" "com.propensive" %% "rapture-core" % "0.9.0" "com.propensive" %% "rapture-json" % "0.9.1" "com.propensive" %% "rapture-io" % "0.9.1" "org.scalafx" %% "scalafx" % "1.0.0-R8" "com.clarifi" %% "f0" % "1.1.1" "org.parboiled" %% "parboiled-scala" % "1.1.6" "org.scala-stm" %% "scala-stm" % "0.7" "org.monifu" %% "monifu" % "0.4"

Cross-building with sbt 0.13

When cross-building between Scala versions, you often need to vary the versions of your dependencies. In particular, the new scala modules (such as scala-xml) are no longer included in scala-library, so you'll have to add an explicit dependency on it to use Scala's xml support.

Here's how we recommend handling this in sbt 0.13. For the full build and Maven build, see example.

scalaVersion := "2.11.0" crossScalaVersions := Seq("2.11.0", "2.10.3") // add scala-xml dependency when needed (for Scala 2.11 and newer) // this mechanism supports cross-version publishing libraryDependencies := { CrossVersion.partialVersion(scalaVersion.value) match { case Some((2, scalaMajor)) if scalaMajor >= 11 => libraryDependencies.value :+ "org.scala-lang.modules" %% "scala-xml" % "1.0.1" case _ => libraryDependencies.value } }

Important changes

For most cases, code that compiled under 2.10.x without deprecation warnings should not be affected. We've verified this by compiling a sizeable number of open source projects.

Changes to the reflection API may cause breakages, but these breakages can be easily fixed in a manner that is source-compatible with Scala 2.10.x. Follow our reflection/macro changelog for detailed instructions.

We've decided to fix the following more obscure deviations from specified behavior without deprecating them first.

  • SI-4577 Compile x match { case _ : Foo.type => } to Foo eq x, as specified. It used to be Foo == x (without warning). If that's what you meant, write case Foo =>.
  • SI-7475 Improvements to access checks, aligned with the spec (see also the linked issues). Most importantly, private members are no longer inherited. Thus, this does not type check: class Foo[T] { private val bar: T = ???; new Foo[String] { bar: String } }, as the bar in bar: String refers to the bar with type T. The Foo[String]'s bar is not inherited, and thus not in scope, in the refinement. (Example from SI-8371, see also SI-8426.)

The following changes were made after a deprecation cycle (Thank you,  <at> soc, for leading the deprecation effort!)

  • SI-6809 Case classes without a parameter list are no longer allowed.
  • SI-7618 Octal number literals no longer supported.

Finally, some notable improvements and bug fixes:

  • SI-7296 Case classes with > 22 parameters are now allowed.
  • SI-3346 Implicit arguments of implicit conversions now guide type inference.
  • SI-6240 Thread safety of reflection API.
  • #3037 Experimental support for SAM synthesis.
  • #2848 Name-based pattern-matching.
  • SI-6169 Infer bounds of Java-defined existential types.
  • SI-6566 Right-hand sides of type aliases are now considered invariant for variance checking.
  • SI-5917 Improve public AST creation facilities.
  • SI-8063 Expose much needed methods in public reflection/macro API.
  • SI-8126 Add -Xsource option (make 2.11 type checker behave like 2.10 where possible).

To catch future changes like this early, you can run the compiler under -Xfuture, which makes it behave like the next major version, where possible, to alert you to upcoming breaking changes.


Deprecation is essential to two of the 2.11.x series' three themes (faster/smaller/stabler). They make the language and the libraries smaller, and thus easier to use and maintain, which ultimately improves stability. We are very proud of Scala's first decade, which brought us to where we are, and we are actively working on minimizing the downsides of this legacy, as exemplified by 2.11.x's focus on deprecation, modularization and infrastructure work.

The following language "warts" have been deprecated:

  • SI-7605 Procedure syntax (only under -Xfuture).
  • SI-5479 DelayedInit. We will continue support for the important extends App idiom. We won't dropDelayedInit until there's a replacement for important use cases. (More details and a proposed alternative.)
  • SI-6455 Rewrite of .withFilter to .filter: you must implement withFilter to be compatible with for-comprehensions.
  • SI-8035 Automatic insertion of () on missing argument lists.
  • SI-6675 Auto-tupling in patterns.
  • SI-7247 NotNull, which was never fully implemented -- slated for removal in 2.12.
  • SI-1503 Unsound type assumption for stable identifier and literal patterns.
  • SI-7629 View bounds (under -Xfuture).

We'd like to emphasize the following library deprecations:

  • #3103#3191#3582 Collection classes and methods that are (very) difficult to extend safely have been slated for being marked final. Proxies and wrappers that were not adequately implemented or kept up-to-date have been deprecated, along with other minor inconsistencies.
  • scala-actors is now deprecated and will be removed in 2.12; please follow the steps in the Actors Migration Guide to port to Akka Actors
  • SI-7958 Deprecate scala.concurrent.future and scala.concurrent.promise
  • SI-3235 Deprecate round on Int and Long (#3581).
  • We are looking for maintainers to take over the following modules: scala-swingscala-continuations. 2.12 will not include them if no new maintainer is found. We will likely keep maintaining the other modules (scala-xml, scala-parser-combinators), but help is still greatly appreciated.

Deprecation is closely linked to source and binary compatibility. We say two versions are source compatible when they compile the same programs with the same results. Deprecation requires qualifying this statement: "assuming there are no deprecation warnings". This is what allows us to evolve the Scala platform and keep it healthy. We move slowly to guarantee smooth upgrades, but we want to keep improving as well!

Binary Compatibility

When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time. Safe run-time linkage (only!) means that the JVM does not throw a (subclass of) LinkageError when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala. Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you're compiling with, as long as they're binary compatibile. In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.

We check binary compatibility automatically with MiMa. We strive to maintain a similar invariant for thebehavior (as opposed to just linkage) of the standard library, but this is not checked mechanically (Scala is not a proof assistant so this is out of reach for its type system).

Forwards and Back

We distinguish forwards and backwards compatibility (think of these as properties of a sequence of versions, not of an individual version). Maintaining backwards compatibility means code compiled on an older version will link with code compiled with newer ones. Forwards compatibility allows you to compile on new versions and run on older ones.

Thus, backwards compatibility precludes the removal of (non-private) methods, as older versions could call them, not knowing they would be removed, whereas forwards compatibility disallows adding new (non-private) methods, because newer programs may come to depend on them, which would prevent them from running on older versions (private methods are exempted here as well, as their definition and call sites must be in the same compilation unit).

These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn't stop us from fixing 372 issues in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet commiting!) to extend it to include major versions in the future.


Note that so far we've only talked about the jars generated by scalac for the standard library and reflection.
Our policies do not extend to the meta-issue: ensuring binary compatibility for bytecode generated from identical sources, by different version of scalac? (The same problem exists for compiling on different JDKs.) While we strive to achieve this, it's not something we can test in general. Notable examples where we know meta-binary compatibility is hard to achieve: specialisation and the optimizer.

In short, if binary compatibility of your library is important to you, use MiMa to verify compatibility before releasing.
Compiling identical sources with different versions of the scala compiler (or on different JVM versions!) could result in binary incompatible bytecode. This is rare, and we try to avoid it, but we can't guarantee it will never happen.


Just like the 2.10.x series, we guarantee forwards and backwards compatibility of the "org.scala-lang" % "scala-library" % "2.11.x" and "org.scala-lang" % "scala-reflect" % "2.11.x" artifacts, except for anything under the scala.reflect.internal package, as scala-reflect is still experimental. We also strongly discourage relying on the stability of scala.concurrent.impl and scala.reflect.runtime, though we will only break compatibility for severe bugs here.

Note that we will only enforce backwards binary compatibility for the new modules (artifacts under the groupId org.scala-lang.modules). As they are opt-in, it's less of a burden to require having the latest version on the classpath. (Without forward compatibility, the latest version of the artifact must be on the run-time classpath to avoid linkage errors.)

Finally, Scala 2.11.0 introduces scala-library-all to aggregate the modules that constitute a Scala release. Note that this means it does not provide forward binary compatibility, whereas the core scala-library artifact does. We consider the versions of the modules that "scala-library-all" % "2.11.x"depends on to be the canonical ones, that are part of the official Scala distribution. (The distribution itself is defined by the new scala-dist maven artifact.)

License clarification

Scala is now distributed under the standard 3-clause BSD license. Originally, the same 3-clause BSD license was adopted, but slightly reworded over the years, and the "Scala License" was born. We're now back to the standard formulation to avoid confusion. 

Please refer to the full release notes for a changelog.

Jason Zaugg
Software Engineer

Typesafe – Build reactive apps!
Twitter:  <at> retronym

You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Meredith Gregory | 21 Apr 12:34 2014

A new distributed social communications platform written in scala

Dear Scalarazzi,

Here's a brief video that distills some of the key points coming out of the user trials we ran with members of this community. We would love your feedback. If after seeing the video more people would like to try the service, please feel free to contact me.

Love to all,


L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW
Seattle, WA 98136

+1 206.650.3740


You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Ian Robertson | 18 Apr 10:24 2014

Clock1 screen gadget using scalafx

Classic time day date and alarm functions. Uses scalafx.
Exploration and example of scalafx with deeper complete app functionality than samples and Ensemble. Use of scalafx rather than SceneBuilder/FXML/CSS supports fine grain user preferences and dynamic layout.
Developed and tested using scalafx_2.10-8.0.0-M4, scala-2.10.4, jdk-1.8.0


You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Nguyen Duc Dung | 18 Apr 03:53 2014

Slick 2.1.0-M1 released

We have just released Slick 2.1.0-M1, the first milestone for Slick 2.1. It should show up on Maven Central within the next few hours. You can find the source code here:https://github.com/slick/slick/tree/2.1.0-M1. Builds are available for Scala 2.10 (2.10.4 recommended) and 2.11.0-RC4.

These are the major new features added in this miletone:
  • OSGi support: Slick and Slick Extensions are now proper OSGi bundles.
  • Scala 2.11 support: Slick is cross-built for both Scala 2.10 and 2.11 from the same codebase.
  • Collection type constructor encoding in queries: All collection-valued queries now contain a type constructor (the default for tables being Seq, as before) that can be changed with a call to .to[...] (like in Scala Collections) at any point in a query, thus allowing arbitrary collections (including arrays) to be built with .run
  • Improved performance when reading JDBC ResultSets, including the option to define even more efficient custom mappings which can completely avoid boxing. SeeJdbcMapperTest and UnboxedBenchmark for examples.
  • Improved and more comprehensive API documentation.
  • Outer join emulation: All types of outer joins are now available on all databases. You can check for the corresponding capability flags to see if the support is native or emulated (with different joins and unions).
  • Code generator improvements.
  • All bug fixes from Slick 2.0.1 and some new ones on top of it, which are also scheduled to go into the upcoming Slick 2.0.2 maintenance release.

Source compatibility of the API has mostly been preserved between 2.0 and 2.1.0-M1 but there are some changes in the JDBC Invokers which may require source changes. There is no binary compatibility between the 2.0 and 2.1 series.

Note that this is not a production-ready or beta release. In particular, the manual has not yet been updated to reflect the changes and new features (but there are unit tests and scaladoc comments for them). The Slick Extensions package has been published along with this milestone release. Please provide feedback on the stability and API of this milestone release if you encounter any problems.

Here is a complete list of changes since 2.0.0:
  • 1c89ee8 Set version to 2.1.0-M1
  • 3ca772d Add some hooks to JdbcMappingCompilerComponent.
  • a10be62 Use Scala specialization for ResultConverter.
  • 513c956 Use positional access in JDBC ResultConverters.
  • 90cc8bf Optimize conversion of result and parameter values.
  • 935558e Deprecate more operators:
  • 9dccddc Improve scaladoc comments and clean up API for Slick 2.1.
  • a13e53a Remove IntrinsicSymbol
  • 85d4e00 Clean up dependencies
  • c8420b2 Improve OSGi integration:
  • 57c87f5 Add def size as alias for length to Query for more Scala collections api conformity
  • 55c2a01 Fix assertion error for multiple nameless fks or indices
  • 047bb07 First cut at OSGi-fun for slick.
  • b2a6dc1 Add docs for MappedColumnType import and hand-written case class companions.
  • 3a7f53c Prevent “no-symbol does not have an owner” when using MappedTo.
  • 338e959 Fix identity groupBy with type mappings.
  • 18f3cf2 Emulate outer joins where necessary.
  • 439305f Correctly propagate build failures to sbt’s exit code.
  • 82316d1 Fix codegen autoinc last as option for HLists (issue #704)
  • 76e638c Add test for outer joins and fix capability declarations.
  • b86cd4b Fix name collision with columns named ‘tag’ in codegen
  • f1c3737 Fix Scaladoc links
  • 2dca474 Scala 2.11 compatibility.
  • e71ed6e Add alias and documentation for ForeignKeyAction
  • 3fc16d8 Allow building of non-erased collections through ClassTags.
  • 6e981e5 Provide implicit CollectionTypeConstructors
  • e3ab1d8 Allow Query result type constructors to be changed.
  • 0139d27 Simplify Query internals.
  • 5c5c657 Encode the type constructor for the unpacked collection type into Query.
  • d0e1e99 Remove zero values from ScalaType.
  • 6d1cbd9 Simplify Option handling in JdbcProfile.
  • 1b5f1f4 Simplify Invokers
  • 754660c Add test for broken mapping to Char
  • e2ab531 Fixed issue #698 (MappedColumnType broken for Char)
  • 77a19aa Fixed issue #554 (ZIP joins)
  • ce04fe8 Modify DDL to run drop phases in LIFO order. Fixes issue #701.
  • c78ed2f Emulate empty join conditions where needed.
  • 7ae79d6 Add JDBC interop docs
  • 3555385 Add documentation for into method
  • 258a6bc Support casts to boolean and double in Access.
  • e065fcd Fix initialization order problem in generated code
  • 89c3c2e Reuse “simple” object for “Implicit” in driver implementations.
  • c6bc382 Remove deprecated features
  • 7e2d6b4 Update version numbers for 2.1
  • fc5cabe Enable documentation tests on Travis CI
  • 73064e9 Documentation improvements for 2.0.1.
  • 8b8ed11 Add test case for issue #645 (to be fixed in slick-extensions)
  • 1e5146c Implement casts for more basic data types in QueryInterpreter.
  • 2a54174 Add configuration for MySQL and PostgreSQL tests on Travis CI.
  • 386920a Add basic Travis CI configuration
  • e96132b Fix self-referencing table in codegen (#619)
  • d944e27 Expand Table refs into columns in “returning” projections.
  • 1f87cfb Add ddl for all tables to codegen
  • 4533b0c Substitute correct versions numbers from the build into the docs
  • b01241d Remove all special handling for products of size 1.
  • 2022107 Infer correct NominalType views even without the NominalType.
  • c59ba50 Fix a smorgasbord of bugs for more robust groupBy.
  • 73c9175 Add optional db authentication to default code generator runner
  • 1f76f36 Improve codegen docs: address spotted confusions, hlist fix, typos, formatting
  • 23e9450 Add row value constructor to codegen output Supersedes #614
  • b870f3d Generate scaladoc src links and graphs for test kit
  • be508cc Fix for #618, codegen single, non-option column tables.
  • 6d7610d Fix for taking Option GetResult from caller scope
  • e436802 Fix for #616, code gen generated wrong default value for Option columns
  • da01462 Fix some codegen docs
  • ae51292 Extend codegen HList test to 33 columns to test performance
  • b5f9144 Change codegen to avoid :: HCons type alias (as a possible workaround for #577)
  • b88337d Split compound types and compound values in codegen
  • 9f274cc Enable disabled codegen tests after fixing spurious compilation errors
  • 0d2e885 Document caching insert invoker
  • 217af59 Ensure that CountAll rewriting creates unique column names.
  • 5aad43f Add MiMa for Slick 2.0 stream
  • 98af9b6 Support Library.Max in QueryInterpreter.
  • e2ece2f Pass Slick version properly from sbt into Sphinx.
  • 0be0423 Fix for #597, negative int default value
  • abe9197 Add failing test for #175

You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Edward Kmett | 20 Apr 21:35 2014

CUFP 2014: Call For Presentations

Commercial Users of Functional Programming 2014: Call for Presentations

     CUFP 2014
                           Gothenburg, Sweden
          Sep 4-6
     Co-located with ICFP 2014
Sponsored by SIGPLAN
   Talk Proposal Submission Deadline 27 June 2014
                Submission Form: http://goo.gl/5BJLul

The annual CUFP workshop is a place where people can see how others
are using functional programming to solve real world problems; where
practitioners meet and collaborate; where language designers and users
can share ideas about the future of their favorite language; and where
one can learn practical techniques and approaches for putting
functional programming to work.

Giving a CUFP Talk

If you have experience using functional languages in a practical
setting, we invite you to submit a proposal to give a talk at the
workshop. We're looking for two kinds of talks:

Experience reports are typically 25 minutes long, and aim to inform
participants about how functional programming plays out in real-world
applications, focusing especially on lessons learned and insights
gained. Experience reports don't need to be highly technical;
reflections on the commercial, management, or software engineering
aspects are, if anything, more important.

Technical talks are also 25 minutes long, and should focus on teaching
the audience something about a particular technique or methodology,
from the point of view of someone who has seen it play out in
practice. These talks could cover anything from techniques for
building functional concurrent applications, to managing dynamic
reconfigurations, to design recipes for using types effectively in
large-scale applications. While these talks will often be based on a
particular language, they should be accessible to a broad range of

We strongly encourage submissions from people in communities that are
underrepresented in functional programming, including but not limited
to women; people of color; people in gender, sexual and romantic
minorities; people with disabilities; people residing in Asia, Africa,
or Latin America; and people who have never presented at a conference
before. We recognize that inclusion is an important part of our mission
to promote functional programming. So that CUFP can be a safe
environment in which participants openly exchange ideas, we abide by
the SIGPLAN Conference Anti-Harassment Policy
( http://www.sigplan.org/Resources/Policies/Anti-harassment ).

If you are interested in offering a talk, or nominating someone to do
so, please submit your presentation before 27 June 2014 via the form at 

You do not need to submit a paper, just a short proposal for
your talk! There will be a short scribe's report of the presentations and
discussions but not of the details of individual talks, as the meeting
is intended to be more a discussion forum than a technical

Nevertheless, presentations will be video taped and
presenters will be expected to sign an ACM copyright release

Note that we will need all presenters to register for the
CUFP workshop and travel to Gothenburg at their own expense.

Program Committee

    Edward Kmett (McGraw Hill Financial), co-chair
    Marius Eriksen (Twitter, Inc.), co-chair
    Ozgun Ataman (Soostone, Inc.)
    Tim Chevalier (AlephCloud)
    Derek Elkins (Now Business Intelligence)
    Matthew Might (University of Utah)
    Richard Minerich (Bayard Rock)
    Audrey Tang (Apple, Inc.)
    Jason Zaugg (Typesafe)

More information

For more information on CUFP, including videos of presentations from
previous years, take a look at the CUFP website at
http://cufp.org. Note that presenters, like other attendees, will need
to register for the event. Acceptance and rejection letters will be sent
out by July 16th.

Guidance on giving a great CUFP talk

Focus on the interesting bits: Think about what will distinguish your
talk, and what will engage the audience, and focus there. There are a
number of places to look for those interesting bits.

    Setting: FP is pretty well established in some areas, including
    formal verification, financial processing and server-side
    web-services. An unusual setting can be a source of interest. If
    you're deploying FP-based mobile UIs or building servers on oil
    rigs, then the challenges of that scenario are worth focusing
    on. Did FP help or hinder in adapting to the setting?

    Technology: The CUFP audience is hungry to learn about how FP
    techniques work in practice. What design patterns have you
    applied, and to what areas? Did you use functional reactive
    programming for user interfaces, or DSLs for playing chess, or
    fault-tolerant actors for large scale geological data processing? 
    Teach us something about the techniques you used, and why we
    should consider using them ourselves.

    Getting things done: How did you deal with large software
    development in the absence of a myriad of pre-existing support
    that are often expected in larger commercial environments (IDEs,
    coverage tools, debuggers, profilers) and without larger, proven
    bodies of libraries? Did you hit any brick walls that required
    support from the community?

    Don't just be a cheerleader: It's easy to write a rah-rah talk
    about how well FP worked for you, but CUFP is more interesting
    when the talks also spend time on what doesn't work. Even when the
    results were all great, you should spend more time on the
    challenges along the way than on the parts that went smoothly.

You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Jon Pretty | 15 Apr 23:46 2014

Rapture Core 0.9.0 released

Rapture Core version 0.9.0 has been released for Scala 2.10.4 and 2.11.0-RC4. This is the first release of Rapture Core which is available on Maven Central!

What is it?

Rapture Core provides several common library functions used in other Rapture modules (such as JSON and IO[1]).

Most notably, it provides return-type strategies which allow library designers to develop APIs which delegate to end users the choice in how failures get handled, by means of a single import or implicit. Return-type strategies available to end users include `throwExceptions`, `captureExceptions` (which returns Either), `returnFutures` (which executes the method asynchronously), `returnTry` and `explicit` which allows you to choose one of the other strategies on a case-by-case basis. Return-type strategies are composable, or users can write their own custom strategies.

For examples of how these work, see the Github page[2].

Where can I get it?

Github: https://github.com/propensive/rapture-core
SBT: "com.propensive" %% "rapture-core" % "0.9.0"


[1] Other Rapture modules are currently going through the release process, and announcements about these will be made shortly!
[2] https://github.com/propensive/rapture-core

You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Josh Suereth | 14 Apr 21:32 2014

[ANNOUNCE] sbt 0.13.2 is released!

sbt 0.13.2 is published.

0.13.2 is predominantly a bugfix release, but there are some small improvements.  See the Changes page[1], the fix notes[3] and the v0.13.1 commit list[2] for details.  This release is intended to be binary and source compatible with 0.13.{0,1}.  

Use it in an existing 0.13 project by modifying `project/build.properties` to be:

There is a new launcher[4], but the 0.13.{0,1} launcher(s) should work fine with 0.13.2.  No changes should be necessary to your project definition and all plugins published for 0.13.x should still work.

One new, optional, feature in this release is the name-hashing algorithm for the incremental compiler. To enable this algorithm, add the following setting in your build.sbt:

      incOptions := incOptions.value.withNameHashing(true)


You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Pablo Medina | 7 Apr 02:12 2014

CKite - Raft distributed consensus for Scala - Release 0.1.3

Hi all,

I'm glad to announce the release of CKite 0.1.3. CKite is a JVM implementation of the Raft distributed consensus algorithm written in Scala. It is a library with an easy to use API for distributed applications needing consensus agreement. 
Raft is a consensus algorithm that is designed to be easy to understand. It's equivalent to Paxos in fault-tolerance and performance. The difference is that it's decomposed into relatively independent subproblems, and it cleanly addresses all major pieces needed for practical systems.

The CKite release 0.1.3 is already available in Maven Central for you to start playing with it. Check it out!

Any comments, feedback, questions and contributions are very welcome.

Twitter:  <at> pablosmedina


You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Bill Venners | 5 Apr 21:45 2014

ScalaTest/ScalaUtils 2.1.3 released

Hi All,

Today we released version 2.1.3 of ScalaTest and ScalaUtils. I didn't send an announcement for 2.1.1 or 2.1.2 to these lists, so I'll include their changes in the list of enhancements and bug fixes below. 2.1.3 is maintenance release and should be binary compatible with previous 2.1.x releases.

View the release notes:


Enhancements since 2.1.0

- Added -z argument support to SBT integration.
- Enhanced Prettifier.default to handle scala.xml.NodeSeq and scala.xml.NodeBuffer.
- Enhanced Prettifier.default to handle object that has class type Fred extends Seq[Fred].
- Refactored Prettifier.default to use stringPrefix for better performance.
- Added -t argument support to sbt integration.
- Disallow any suffix for Runner command line arguments that do not take a suffix. This will give a better error message if someone enters -z"database" instead of -z "database".

Bug fixes since 2.1.0

- Added missing must support to noException, a [SomeException] and an [Exception] matcher syntax.
- Fixed StackOverflowError problem in Prettifier.default method when used with scala.xml.Node.
- Fixed an owner chain problem in the assert macro (issue 276).


Bill Venners
Artima, Inc.

You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Alexandru Nedelcu | 31 Mar 01:32 2014

Monifu 0.4 released

Monifu's stated goals:

  • to provide extensions to Scala’s standard library for multi-threading primitives, functional programming and whatever makes life easier
  • to cross-compile to Scala.js, for extra awesomeness

Homepage: https://github.com/alexandru/monifu

Version 0.4 adds Schedulers & Cancelables, see the documents:

Version 0.3 before it solidified the implementation for Atomic references, see the document: Atomic References

Version 0.5 that’s in the works will come with an initial implementation of Rx.Observable.

Hope you find it useful,

Alexandru Nedelcu

PGP Public Key:

You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Adriaan Moors | 26 Mar 19:04 2014

Re: [scala-internals] Scala 2.10.4 is now available!

Thanks for reporting & sorry about that!

We're looking into it: https://github.com/scala/make-release-notes/pull/69/files#r10989903

You received this message because you are subscribed to the Google Groups "scala-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-announce+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.