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. 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
