move method back to top level(where it compiled previously) and it won't compile Oo
(sbt always compiles ok, bloop structure is generated via opening a project in VSCode and testing with
bloop compile dotty-complex)
Issue might be related to scalacenter/bloop#1289
raised an issue in Dotty: lampepfl/dotty#9024
if we can fix it easily in Bloop it would probably it would also be useful, but I think it is most likely not only Bloop that will have this issue
Hi everyone I am wondering if anyone else is running into this issue but when I do
bloop console <some-project I get the above strange error when bloop or coursier tries to download some things (scala compiler and reflect !?). Has anyone else tried to run bloop console with the latest release (1.4.1)?
@maxstreese Hmmm, can you make sure you have the latest version of coursier installed?
8 replies
is anyone else experiencing this strange error on java 14?
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)
Can you open a PR adding a
trim in https://github.com/jvican/snailgun/blob/master/core/src/main/scala/snailgun/protocol/Protocol.scala#L193 ?
It's weird the Nailgun server is returning that status code. How are you using bloop?
What does Bloop do differently for SJS projects besides just compile? Like I see it generating sjsir files, but to what end? Who uses those? Is there a way to disable that stuff when using Bloop/Metals? I just want compilation for symbol lookup, etc. I don’t want every incremental change to build SJS artifacts that I’m not gonna use.
@matthughes sjs files are just like class files, they are produced by the scalajs compiler plugin
@maxstreese @jvican this may be of interest, i was encountering some problems like this several days ago: https://github.com/scalacenter/bloop/issues/1226#issuecomment-625749487
17 replies
the problem boils down to bloop's built-in coursier being outdated, i believe
i think that bloop never uses the system coursier
Hi! I'm having trouble using scala metals and I think the problem might be with bloop. Maybe my gradle project isn't set up properly for it. I have a gradle project with multiple subprojects. After bloop is run, i have a json file for one subproject that references another subproject in its classpath:
"/Users/work/src/PROJECT_ROOT/.bloop/common/build/classes" Unfortunately, that directory doesn't exist. I'm assuming it should so that coc-metals can get completion info. Any ideas?
Only bloop output i've noticed is
which seems a little fast
2020.05.28 11:50:38 INFO compiling common (239 java sources) 2020.05.28 11:50:38 INFO time: compiled common in 78mswhich seems a little fast
When I run my application and I read from StdIn it seems to hang forever not getting input. I execute
bloop run <project> and in my main I have val action = StdIn.readLine(). I type things and press 'Enter' but it is not received by my app. It works okay with sbt run but as I already have everything compiled and ready to run it would be awesome to be able to get this working
Is it possible to provide some flag or workaround it in any way?
@pear-programmer Although the project file refers to
From the log message it looks like Bloop has successfully compiled your project. The reason it's so quick is that Bloop will only recompile if it thinks something has changed - fast incremental compilation is its forte. You can try
I see it says
...../.bloop/PROJECT_NAME/build/classes, in reality the class file location is slightly different - depending on the client you use (e.g. CLI, Metals). You should see class files under ...../bloop/PROJECT_NAME/build/bloop-XXXX-classes or similar.From the log message it looks like Bloop has successfully compiled your project. The reason it's so quick is that Bloop will only recompile if it thinks something has changed - fast incremental compilation is its forte. You can try
bloop clean then bloop compile PROJECT_NAME to see it compile from scratch.I see it says
(239 java sources) so I'm assuming this is a Java project? While Bloop will compile and run java projects, Metals does not support Java files scalameta/metals-feature-requests#5 - you won't get any code completion on them. Vote on the issue if you need that.
it "just worked (tm)"
and using the BSP support solved a TON of intellij glitches we are having.
responsiveness for our standard workflow is significantly improved and opened up new simpler possibilities thanks again
@kpbochenek I've also run into it recently but haven't got around to reporting it. I've checked the issue tracker now: scalacenter/bloop#882
Hmm the issue mentions underlying problem with nailgun: facebook/nailgun#115 but Bloop uses https://github.com/jvican/snailgun now. Yet the issue persists...
@kpbochenek @rkrzewski yes, we need to figure out what to do so that stdin is working again, it's quite hard to make it work from the stdin
i would appreciate if someone could have a look at it