Reading input from application doesn't work

[msinton]

To reproduce, create a simple app such as:

object Main extends App {

  val x = readInt()
  val y = readInt()
  println(x + y)
}

When run and supply numbers (1, 2) you get the following unexpected error:

[E] Exception in thread "main" java.lang.NumberFormatException: For input string: "2"
[E] at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)

The same does not occur if running with sbt.

(p.s. Loving Bloop)

[jvican]

Caused by facebook/nailgun, ticket here. The issue is nailgun only reads line by line, and readInt only grabs four bytes of input, so it doesn't work with nailgun.

This kind of applications will work when the client is a BSP client (e.g. when Metals supports running applications, it will work). I have to close this ticket as wont fix since it needs a fix upstream. To work around this issue, I recommend replacing readInt by readLine and then parsing the string as an int.

[rtar]

readLine() does not seem to work either. It just hangs without ever passing input to the application.

[davidpdrsn]

I'm also having issues with this. Any possible solutions?

[jvican]

This is an important issue I intend to fix soon.

In the meanwhile, you should be able to run the application via Metals in VS Code. Metals can run application reliably because it uses DAP instead of Nailgun, and DAP allows for fine-grained user input to be transmitted over the wire.

[kammoh]

Hi,
Any updates on this issue?

bloop v1.4.8, JDK 15:

$ bloop console root
error: Unexpected error forces client exit!
java.lang.NumberFormatException: For input string: "0
"
        at java.lang.Integer.parseInt(Integer.java:652)
        at java.lang.Integer.parseInt(Integer.java:770)
        at snailgun.protocol.Protocol.$anonfun$processChunkFromServer$1(Protocol.scala:193)
        at scala.util.Try$.apply(Try.scala:213)
        at snailgun.protocol.Protocol.processChunkFromServer(Protocol.scala:180)
        at snailgun.protocol.Protocol.sendCommand(Protocol.scala:108)
        at snailgun.TcpClient.run(TcpClient.scala:34)
        at bloop.bloopgun.BloopgunCli.executeCmd$1(Bloopgun.scala:268)
        at bloop.bloopgun.BloopgunCli.fireCommand(Bloopgun.scala:274)
        at bloop.bloopgun.BloopgunCli.run(Bloopgun.scala:230)
        at bloop.bloopgun.Bloopgun$.main(Bloopgun.scala:638)
        at bloop.bloopgun.Bloopgun.main(Bloopgun.scala)

[2m]

I have a clean MacOS install with coursier installed via brew and bloop installed via coursier. I get this error when running bloop about:

~ ─╼ bloop about                                                                                  0
bloop v1.4.8

Using Scala v2.12.8 and Zinc v1.3.0-M4+46-edbe573e
Running on Java JDK v16.0.1 (/Library/Java/JavaVirtualMachines/adoptopenjdk-16.jdk/Contents/Home)
  -> Supports debugging user code, Java Debug Interface (JDI) is available.
Maintained by the Scala Center (Jorge Vicente Cantero, Martin Duhem)
error: Unexpected error forces client exit!
java.lang.NumberFormatException: For input string: "0
"
	at java.lang.Integer.parseInt(Integer.java:652)
	at java.lang.Integer.parseInt(Integer.java:770)
	at snailgun.protocol.Protocol.$anonfun$processChunkFromServer$1(Protocol.scala:193)
	at scala.util.Try$.apply(Try.scala:213)
	at snailgun.protocol.Protocol.processChunkFromServer(Protocol.scala:180)
	at snailgun.protocol.Protocol.sendCommand(Protocol.scala:108)
	at snailgun.TcpClient.run(TcpClient.scala:34)
	at bloop.bloopgun.BloopgunCli.executeCmd$1(Bloopgun.scala:268)
	at bloop.bloopgun.BloopgunCli.fireCommand(Bloopgun.scala:274)
	at bloop.bloopgun.BloopgunCli.run(Bloopgun.scala:230)
	at bloop.bloopgun.Bloopgun$.main(Bloopgun.scala:638)
	at bloop.bloopgun.Bloopgun.main(Bloopgun.scala)

[tgodzik]

This seems to be an issued with JDK 16, could you try with JDK 11? I think we fixed it in master, but will need to confirm. Anyway, I don't think this is related to current issue.

[frabbit]

I ran into the same issue, reading input from stdin is not working when running apps via bloop run. I guess it's the same reason why it's not working as expected with terminal libraries like jline for example.