New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: Add support for running Native and JS #5197
Conversation
metals/src/main/scala/scala/meta/internal/metals/BuildServerConnection.scala
Outdated
Show resolved
Hide resolved
scalaCliCodeLenses( | ||
textDocument, | ||
buildTargetId, | ||
classes, | ||
distance, | ||
isJVM, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so this only works for scala cli right now because it can run native and js, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works also for Bloop, but for sbt BSP it seems to only detect the JVM classes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mill gets a bunch of exceptions, but I don't want to dig into that yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Newest Mill doesn't get the exceptions, though it hangs for JS, not sure why. But that's not really related to this PR. We can turn it off for mill, but then we might forget about it.
metals/src/main/scala/scala/meta/internal/metals/ForwardingMetalsBuildClient.scala
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very cool. Just tested it out with nvim-metals as well and it all worked 🥳
metals/src/main/scala/scala/meta/internal/metals/debug/DebugProtocol.scala
Outdated
Show resolved
Hide resolved
Important drawback from this approach is that some logs might get mixed between the output, we could filter known things like |
Anyone willing to take a look at it to review? 😓 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have looked at the changes, as I've been interested in this in the context of a future speedup to test execution (on the JVM platform). However, I don't know the project well, so my remarks might make no sense, in which case please just ignore them, sorry. 😅
metals/src/main/scala/scala/meta/internal/metals/codelenses/RunTestCodeLens.scala
Outdated
Show resolved
Hide resolved
metals/src/main/scala/scala/meta/internal/metals/codelenses/RunTestCodeLens.scala
Show resolved
Hide resolved
metals/src/main/scala/scala/meta/internal/metals/debug/DebugProvider.scala
Outdated
Show resolved
Hide resolved
metals/src/main/scala/scala/meta/internal/metals/ForwardingMetalsBuildClient.scala
Outdated
Show resolved
Hide resolved
metals/src/main/scala/scala/meta/internal/metals/debug/DebugProvider.scala
Show resolved
Hide resolved
Thanks for the review! I will take a look at the remarks as soon as I can! |
metals/src/main/scala/scala/meta/internal/metals/StacktraceAnalyzer.scala
Outdated
Show resolved
Hide resolved
85cd09c
to
7bc75c5
Compare
Works by doing the bare minimum DAP requires and forwars the logs from the build server
This is finally ready to be reviewed if anyone has the time. |
@tgodzik do you have an idea what might be wrong here? Is shaded coursier sth from bloop? 🤔
|
It probably is from Bloop, where did you find that error? |
@tgodzik it's the result of running |
I can reproduce, you could run: |
Ok, here's the cause:
There is no temurin:8 for apple silicon. Replacing with zulu:8 fixes issue.Thanks @tgodzik for your help! |
cancelPromise.future.foreach { _ => | ||
completableFuture.cancel(true) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this has no effect. This methods is called from DebugProvider
, but promise is never completed so cancelation logic will never be called which results in dead code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the promise was being cancelled in the DebugRunner, but it was under a wrong message. Should have been under DisconnectRequest, but was under TerminateRequest.
Should work correctly and I added a test for that.
I also realised that running a main method if multiple are present was not possible, that's fixed too.
- make sure cancelation works correctly on disconnect request - send main class info in case of multiple classes - return error status if run fails
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left few nits and two questions. I might have some improvements in mind, but I still need to run this and see all moving pieces in action though.
if ( | ||
parameters | ||
.getDataKind() == b.DebugSessionParamsDataKind.SCALA_MAIN_CLASS | ||
) { | ||
runParams.setDataKind(parameters.getDataKind()) | ||
runParams.setData(parameters.getData()) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this sets main class info in case of multiple classes, right? It's not obvious from the code though. It'll be great if you add some comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment about it.
object ConfigurationDone { | ||
def unapply( | ||
request: DebugRequestMessage | ||
): Option[Option[dap.ConfigurationDoneArguments]] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is nested option intentional? I see that you're discarding unnaply result anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed, that was not intentional, probably a lot of things changed on the way.
cancelPromise, | ||
) | ||
} yield debugServer | ||
.flatMap { runner => | ||
currentRunner.set(runner) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what will happen if I run 2 different programs? Let assume that first one is long running computation and in the meantime I'll run another one. Will it mess logging or is it negligible corner case? I checked vscode now and I can debug two different programs 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
negligible corner case
I guess number of people trying to run on js and native platforms is already negligible 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a way currently to differentiate between the two programs, so this will not be possible. We can make it explicit.
There was a discussion in BSP about it, but I can't find it currently. We could identify each log message by the origin id maybe, let me check it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could identify each log message by the origin id maybe, let me check it.
just have in mind that this is probably minor issue and might not be worth spending too much time on it ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added an atomic boolean that should take care of it. It will be set to false only if run ends or the user disconnects, but that should work fine.
I also realized that we don't show errors proeprly if code lense failed to run, so I added that in the PR here: scalameta/metals-vscode#1449
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
atomic flag might not be the best looking solution, but it's a working one. Let's get this thing merged
metals/src/main/scala/scala/meta/internal/metals/debug/DebugProvider.scala
Outdated
Show resolved
Hide resolved
* Used to forward messages from the build server. Messages might | ||
* be mixed if the server is sending messages as well as output from | ||
* running. This hasn't been a problem yet, not perfect solution, | ||
* but seems to work ok. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'll forward all messages from the build server, e.g. if during a running I'll trigger a compilation or some different action, those logs might end up in "program output", right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, unfortunately. No way around it for now, we could do filtering I guess but some messages could end up anyway.
+ some small review fixes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good enough to me ;)
This works by doing the bare minimum that DAP requires and forwarding the logs from the build server.
We can later use this minimal DAP server to also run quicker test instead of setting up the entire debugging session
Resolves scalameta/metals-feature-requests#325