On Tuesday, November 13, 2012, Adam Murdoch wrote: > > On 14/11/2012, at 1:37 AM, Luke Daley wrote: > > > On 13/11/2012, at 2:10 PM, Peter Niederwieser wrote: > > Now that 1.3 is almost out, I'd like to discuss potential next steps for > > improving our Scala support. Here is an initial list: > > > * Scala REPL support > > To make this work well, we need to solve the general problem of Java code > > reading from and writing to the console when running in Gradle (with and > > without Gradle Daemon). Currently, there are issues with the Gradle status > > line getting in the way, and control characters not being interpreted > > correctly. The latter is important for accessing the shell's history. > > > * Reusing the Scala compiler across builds > > We already reuse the compiler across ScalaCompile tasks in the same > > build, which led to big performance improvements. Reusing the compiler > > across builds (as done by sbt and Zinc/Nailgun) will provide further gains. > > In other words, we need to enhance the compiler daemon so that it can > > outlive a build. Question is if we add this capability specifically for the > > compiler daemon, or work towards a unified solution (for all daemons, or > for > > all daemons except the Gradle Daemon). > > > Without knowing the technical details, it seems crazy to me to do a Scala > specific solution here. > > > The question is more whether it's a compiler daemon specific solution or > some kind of common daemon solution. >
I would be interested in the performance gains it can bring to Groovy and Java projects. Hans > > My answer would be first a specific solution, moving incrementally towards > a common solution. > > For example, we might start by reusing the discovery mechanisms, where we > use the daemon registry infrastructure to find long running compiler daemon > instances. Then we might share more of the messaging infrastructure, so > that the build daemon (what we call 'the daemon') uses ObjectConnection to > do messaging. Then we might generalise the protocol, merging WorkerProcess > and DaemonClient so that the same (internal) API is used to kick off builds > or compilation or any other pieces of work. Then we might merge the single > use daemon and the worker process. And so on. > > Or we might come at it the other way, adding support for compilation to > DaemonClient, so that we use the long-running daemon or the single use > daemon for compilation, later generalising things and merging the daemon, > the compiler daemon and the worker process infrastructure. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
