Reading keyboard input

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Reading keyboard input

Jeppe Nejsum Madsen
Hi,

I'm trying to launch the Scala REPL (using my project classpath)

Here's my task:

task scalaConsole << {
  javaexec { JavaExecSpec spec ->
    scalaHome = System.getenv()['SCALA_HOME']
    spec.jvmArgs("-Dscala.home=$scalaHome")
    spec.setMain("scala.tools.nsc.MainGenericRunner")
    spec.classpath(configurations.scalaTools.asPath)
  }
}

It launches the REPL ok, but it seems to exit immediately. My guess is
it figures out there's no console.

Any hints how to start an interactive task that requires keyboard input?

/Jeppe

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Reading keyboard input

Adam Murdoch-3

On 02/10/2010, at 4:53 AM, Jeppe Nejsum Madsen wrote:

Hi,

I'm trying to launch the Scala REPL (using my project classpath)

Here's my task:

task scalaConsole << {
 javaexec { JavaExecSpec spec ->
   scalaHome = System.getenv()['SCALA_HOME']
   spec.jvmArgs("-Dscala.home=$scalaHome")
   spec.setMain("scala.tools.nsc.MainGenericRunner")
   spec.classpath(configurations.scalaTools.asPath)
 }
}

It launches the REPL ok, but it seems to exit immediately. My guess is
it figures out there's no console.

Any hints how to start an interactive task that requires keyboard input?

By default, the standard input of a child process is attached to an empty stream. And so, the scala REPL just exits immediately because it reaches the end of its input straight away.

You can attach the stdin of the build process to the stdin of the child process by doing something like:

javaexec { spec ->
    ...
    spec.standardInput = System.in
}

This is the theory, anyway. It doesn't work particularly well at the moment.

One reason is that the input is buffered in the build process. I've just checked in a fix to deal with this, so that input is flushed to the child process as soon as it is read in. This makes it usable to some degree. However, there are a couple of other problems.

Firstly, the input is mixed up with the status line: http://jira.codehaus.org/browse/GRADLE-1147.

Secondly, once the child process exits, the javaexec { } method continues to block until some more input is typed at the console. And then it complains that it can't write to the now-exited process.


--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz

Reply | Threaded
Open this post in threaded view
|

Re: Reading keyboard input

Jeppe Nejsum Madsen
On Wed, Oct 6, 2010 at 8:19 AM, Adam Murdoch <[hidden email]> wrote:

>
> On 02/10/2010, at 4:53 AM, Jeppe Nejsum Madsen wrote:
>
> Hi,
>
> I'm trying to launch the Scala REPL (using my project classpath)
>
> Here's my task:
>
> task scalaConsole << {
>  javaexec { JavaExecSpec spec ->
>    scalaHome = System.getenv()['SCALA_HOME']
>    spec.jvmArgs("-Dscala.home=$scalaHome")
>    spec.setMain("scala.tools.nsc.MainGenericRunner")
>    spec.classpath(configurations.scalaTools.asPath)
>  }
> }
>
> It launches the REPL ok, but it seems to exit immediately. My guess is
> it figures out there's no console.
>
> Any hints how to start an interactive task that requires keyboard input?
>
> By default, the standard input of a child process is attached to an empty
> stream. And so, the scala REPL just exits immediately because it reaches the
> end of its input straight away.
> You can attach the stdin of the build process to the stdin of the child
> process by doing something like:
> javaexec { spec ->
>     ...
>     spec.standardInput = System.in
> }
> This is the theory, anyway. It doesn't work particularly well at the moment.
> One reason is that the input is buffered in the build process. I've just
> checked in a fix to deal with this, so that input is flushed to the child
> process as soon as it is read in. This makes it usable to some degree.

Yes, that worked.

> However, there are a couple of other problems.
> Firstly, the input is mixed up with the status11
> line: http://jira.codehaus.org/browse/GRADLE-1147.

Any plans to resolve this before 1.0?

> Secondly, once the child process exits, the javaexec { } method continues to
> block until some more input is typed at the console. And then it complains
> that it can't write to the now-exited process.

While annoying I can probably live with this for this use case :-)

/Jeppe

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Reading keyboard input

Adam Murdoch-3

On 18/10/2010, at 3:26 AM, Jeppe Nejsum Madsen wrote:

On Wed, Oct 6, 2010 at 8:19 AM, Adam Murdoch <[hidden email]> wrote:

On 02/10/2010, at 4:53 AM, Jeppe Nejsum Madsen wrote:

Hi,

I'm trying to launch the Scala REPL (using my project classpath)

Here's my task:

task scalaConsole << {
 javaexec { JavaExecSpec spec ->
   scalaHome = System.getenv()['SCALA_HOME']
   spec.jvmArgs("-Dscala.home=$scalaHome")
   spec.setMain("scala.tools.nsc.MainGenericRunner")
   spec.classpath(configurations.scalaTools.asPath)
 }
}

It launches the REPL ok, but it seems to exit immediately. My guess is
it figures out there's no console.

Any hints how to start an interactive task that requires keyboard input?

By default, the standard input of a child process is attached to an empty
stream. And so, the scala REPL just exits immediately because it reaches the
end of its input straight away.
You can attach the stdin of the build process to the stdin of the child
process by doing something like:
javaexec { spec ->
    ...
    spec.standardInput = System.in
}
This is the theory, anyway. It doesn't work particularly well at the moment.
One reason is that the input is buffered in the build process. I've just
checked in a fix to deal with this, so that input is flushed to the child
process as soon as it is read in. This makes it usable to some degree.

Yes, that worked.

However, there are a couple of other problems.
Firstly, the input is mixed up with the status11
line: http://jira.codehaus.org/browse/GRADLE-1147.

Any plans to resolve this before 1.0?

Definitely before 1.0. Probably sooner than that. A simple work around is to set TERM=dumb:

TERM=dumb gradle scalaConsole

This works pretty well.


Secondly, once the child process exits, the javaexec { } method continues to
block until some more input is typed at the console. And then it complains
that it can't write to the now-exited process.

While annoying I can probably live with this for this use case :-)

This is fixed in head now.


--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz

Reply | Threaded
Open this post in threaded view
|

Re: Reading keyboard input

Jeppe Nejsum Madsen
On Mon, Oct 18, 2010 at 3:26 AM, Adam Murdoch <[hidden email]> wrote:

[...]

> This is fixed in head now.

Great! What are the plans for the 0.9 release (or just an rc2 :-)?
There have  been a quite a few nice changes added since 0.9-rc1, but
they aren't really useful for us yet since we rely on the gradle
wrapper, which iirc doesn't work with the nightly builds.

/Jeppe

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Reading keyboard input

Rene Groeschke
Hi,

Am Mo, 18.10.2010, 09:28, schrieb Jeppe Nejsum Madsen:

> On Mon, Oct 18, 2010 at 3:26 AM, Adam Murdoch <[hidden email]> wrote:
>
>
> [...]
>
>
>> This is fixed in head now.
>>
>
> Great! What are the plans for the 0.9 release (or just an rc2 :-)?
> There have  been a quite a few nice changes added since 0.9-rc1, but
> they aren't really useful for us yet since we rely on the gradle wrapper,
> which iirc doesn't work with the nightly builds.

you can configure the wrapper to use gradle snapshots from the snapshots
page. unfortunately they are not updated very often. In general it would
be nice to have at snapshot a snapshot a week or so. Earlier I was able to
configure my wrapper to use the hudson nightly builds of gradle, but the
hudson build server is down for weeks now.

regards,
René


>
> /Jeppe
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>
> http://xircles.codehaus.org/manage_email
>
>
>



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Reading keyboard input

Adam Murdoch-3
In reply to this post by Jeppe Nejsum Madsen

On 18/10/2010, at 6:28 PM, Jeppe Nejsum Madsen wrote:

On Mon, Oct 18, 2010 at 3:26 AM, Adam Murdoch <[hidden email]> wrote:

[...]

This is fixed in head now.

Great! What are the plans for the 0.9 release (or just an rc2 :-)?

I will try to do an rc2 in the next few days. Hopefully 0.9 won't be too long after that.

There have  been a quite a few nice changes added since 0.9-rc1, but
they aren't really useful for us yet since we rely on the gradle
wrapper, which iirc doesn't work with the nightly builds.

The wrapper should work with any Gradle build from 0.9-preview-1 onwards. You just need to configure the distributionVersion and/or baseUrl properties appropriately.

We don't publish snapshots very often, mainly because it's currently a manual process (which is a bit tragic, really, for a build automation tool). We will change this at some point, it's just a matter of finding the time. We also really, really want to have a much shorter release cycle once 0.9 is out. Until we sort these issues out, you can always grab a build from the CI server and host it somewhere: http://teamcity.jetbrains.com/viewType.html?buildTypeId=bt107&tab=buildTypeStatusDiv


--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz