At a glance
- #332, implement goto
definition with low CPU and memory overhead.
Worksheet mode for Dotty IDE
We have been working on supporting a [worksheet mode in Dotty
IDE](https://github.com/lampepfl/dotty/pull/5102). Worksheets are interactive buffers in an editor
that can evaluate expressions and display their results. They offer a simple interface to quickly
try out things during the development process.
Worksheets have been merged in Dotty and will be part of the next release.
Configure new Scala projects from Dotty IDE
In order to improve the user experience for new Scala developers, Dotty IDE will now offer to create
a new sbt project when a Scala file is opened, and then configure itself automatically.
This way, getting started with Scala and getting help from an IDE becomes as simple as creating a
new Scala file in an empty directory.
This work has been merged in Dotty IDE and will be part of the next release.
Integrate Dotty IDE with sbt server
There are currently two ways to start Dotty IDE:
launchIDEin an existing sbt shell
Open VSCode in a directory that contains an up-to-date IDE configuration
This situation is not optimal, because we want Dotty IDE to stay current with the build definition
that sbt has. Dotty IDE will now communicate with sbt server to trigger the generation of the
configuration files that Dotty IDE needs.
In the future, we can imagine more integrations between
Dotty IDE and sbt (running tests, etc.).
This work has been merged in Dotty IDE and willbe part of the next release.
Other improvements to Dotty IDE
In some cases, Dotty IDE would be confused when using
go to definition on overridden methods and
would not show all the possible alternatives.
A bug caused all trees that where unpickled from TASTY rather than read from source to be excluded
in all searches. This has been fixed.
Dotty IDE used to have difficulty selecting what symbol to jump to when doing
go to definition
on constructor calls. It learned how to distinguish between them and be smart about its choices.
Dotty IDE mainly works within a single project. For instance, it is not able to rename symbols
between different projects, and will only find references within a single project. We are currently
working on adding support for multi-project setups and hope to have it integrated in the next
release of Dotty.
Mainly worked on the video lectures of the “Programming Reactive
Systems” MOOC. Coordinated the recording of Roland Kuhn’s videos,
Reviewed the videos after they were edited, also reviewed
Konrad Malawski’s videos, and prepared a couple of lectures to record.
Introduced changes to the grading infrastructure so that it
can used for internal courses at EPFL.
Deployed the new sbt-1-based graders.
Hired a couple of new teaching assistants.
Starting filling the course content on the edX portal.
Build pipelining is a technique to start the compilation of modules in a build
before their dependencies have finished compilation. An experimental
implementation of build pipelining has been merged to master in
Added more projects to our community build such as Finagle or Scalding.
Benchmarked batch compilation of big builds. The current results can still
change, but on average We see an improvement between 0 and 30% in compilation
time on an 8-core machine (4 physical cores, 4 virtual cores). We can expect
more accentuated performance benefits in local development, where doing
incremental compilation or compiling a subset of the build graph which
tends to exhibit more sequential dependencies than the full build graph.
- Started writing a technical document explaining in depth the feature, its
trade-offs and design. There are many trade-offs in the context of mixed
Java and Scala compilation and a heavy use of macros.
This feature is being prepared for production-ready use. It will be supported
in 2.11.x, 2.12.x and 2.13.x only.
remove scala 2.10 support
help publish downstream dependencies for scala
API updates / refactoring
handle standard repositories and mirror ones the same way (remove bits of code relying on directory listings, which usually miss files on mirrors, #899)
rework artifact handling methods, wipe some hacks they were relying on (#902)
replace a few
Stringtypes in the API by tagged types (#902)
rework CLI source code (remove dependency on scalaz, make the
resolvecommand easier to test and re-use, #934)
move most README content to a website, updated upon each push to master, updated the content a bit
CLI to publish artifacts
CLI to install applications
security / GPG-related features
(Formerly known as jupyter-scala)
- add web site (#228)
maybe try to resume / revive an on-going effort, from a year ago, that aimed at making the various scala kernels for Jupyter converge
document the new / less known features of almond (spark UX related ones in particular)
To read/watch more about the SIP:
Next SIP meeting is taking place on the 22nd October 2018 at 5 PM CEST, please join and comment live on our Channel.
Beginning of November the SIP Committee is meeting face-to-face at EPFL, Lausanne, Switzerland to discuss many future changes in 3-day long gathering. We are working on a program and how to include the community in live streams at certain points in the day. Stay tuned, more info coming soon.