I want to debug my scala app with vscode.
My gradle run task looks as simple:
task run(type: JavaExec, dependsOn: build) {
debug true
main = mainClassFile
classpath sourceSets.main.runtimeClasspath
classpath configurations.runtime
}
The launch entry:
{
"type": "java",
"name": "Debug (Attach)",
"request": "attach",
"hostName": "localhost",
"port": 5005
}
Now when I launch the debugger, it waits for the vscode client.
But I am not able to set any breakpoints in vscode in order to stop the debugger. For now it runs until the end, after vscode connected.
I am using the Scala and Scala Language Server.
Does someone know how to add breakpoints?
Latest release of Scala Metals (0.8.0) has a debug support - the release has an animation showing usage of debugging in Visual Studio Code, which works the same way as debugging in other languages.
This is an initial support so some cases might not be supported (see "known limitations" in the release notes of Metals 0.8.0), but you should be able to start using them.
Before that debugging was simply not supported by Scala Metals, and everyone writing Scala in need of such feature was recommended to use IntelliJ with Scala plugin.
Related
Metals announced that "It is now possible to run and test directly from VS Code using the new "Run", "Test", "Debug" and "Debug test" buttons." There is a nice gif showing what it can do, and I don't know how to get to that point.
I tried to launch VS Code debugger with the following configurations in launch.json
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "scala",
"request": "launch",
"name": "Untitled",
"mainClass": "com.playZip.Unzip",
"args": [],
"jvmOptions": []
}
]
}
and got this error message:
Couldn't find a debug adapter descriptor for debug type 'scala' (extension might have failed to activate)
Somebody on Gitter scalameta/metals had this problem and the answer was that he needs Bloop to support utest and I think mine does because there's a file .bloop/play-zip-test.json in my sbt project, but I'm not 100% if my Bloop supports utest and what to do if it doesn't. I tried running bloop utest and it failed because I don't have Bloop CLI installed. I have Bloop that comes with Metals.
Document how to run or debug applications #2005 added official debugging documentation at Running and debugging your code which documents two approaches
via code lenses run | debug
via a launch.json configuration
Here is a hello world example how to debug a test using VSC and Metals via launch.json approach. We will use
lihaoyi/utest library and set a breakpoint in a test.
Execute sbt new scala/scala-seed.g8 to create correct project structure
Open... sbt project with VSC or simply cd into project and execute code .
Replace ScalaTest with utest in build.sbt
libraryDependencies += "com.lihaoyi" %% "utest" % "0.7.2" % "test",
testFrameworks += new TestFramework("utest.runner.Framework")
Replace test/scala/example/HelloSpec.scala with HelloTests.scala
package example
import utest._
object HelloTests extends TestSuite{
val tests = Tests{
test("test1"){
1
}
}
}
Import sbt build with View | Command Palette... | Metals: Import Build
Put a breakpoint at line 8 and click Run and Debug
Select Test Suite for Pick the kind of class to debug
Leave empty for Enter the name of the build target
Write example.HelloTests for Enter the name of the class to debug
Write Debug example.HelloTests for Enter the name of configuration
This should create .vscode/launch.json
{
"version": "0.2.0",
"configurations": [
{
"type": "scala",
"name": "Debug example.HelloTests",
"request": "launch",
"testClass": "example.HelloTests"
}
]
}
Now you should be able to Start Debugging by clicking the green triangle and stop at the breakpoint
Not sure if your problem is solved, but I did see the same issue before. To get more information about the error, you can check the Metals output. See the picture below:
From the output tab, select Metals. More detail of the error should be available.
In my case, the reason I got this error (Couldn't find a debug adapter descriptor for debug type 'scala' (extension might have failed to activate) ) is because the Java installed in my machine does not support JDI.
Message: Debugging is not supported because bloop server is running on a JRE /usr/lib/jvm/java-8-openjdk-amd64/jre with no support for Java Debug Interface: 'JDI implementation is not provided by the vendor'. To enable debugging, install a JDK and restart the bloop server.
I guess your case is probably the same. To solve it, just install a Java implementation supports JDI. For example, openjdk version "11.0.8" 2020-07-14 works fine with Metals on Ubuntu. You can do this to install it.
$ sudo apt install openjdk-11-jdk
If it still not works, make sure Metals: Java Home in VS Code settings points to the right Java version.
I ran into this same problem and it came down to the buildTarget. I have a multiple module project. When I looked at the metals logs this is what I saw:
Caused by: scala.MatchError: scala.meta.internal.metals.debug.BuildTargetNotFoundException: Build target not found: (of class scala.meta.internal.metals.debug.BuildTargetNotFoundException)
My Scala project
/client_accounts
/migrations
/app
Updated the launch.json to "buildTarget": "app", and it worked. Error reporting could be a bit better.
So if you get this error look at the logs for the root cause.
Class not found exception in Visual studio code because vs-code debug takes output class files form bin directory like eclipse but i am using GRADLE for build so MapperImpl.java which is implementation files in mapper are created in the build folder i don't know how to solve the issue i tried to change the classpath all the solutions i tried but nothing working please i need your help
I am also posting the vs code file launch.json
{
"type": "java",
"name": "Debug (Launch)-Application<RestApi>",
"request": "launch",
"mainClass": "ae.org.nge.Application",
"projectName": "RestApi",
"vmArgs": "-DngeConfig=C:/Users/Manoj.Dhayalan/source/myapp/Application/config/myapp-config.properties -Dserver.port=8081 -Dspring.profiles.active=dev"
}
I don't use Visual Studio Code but I managed to change the location of generated class file by putting this lines into my build.gradle file:
compileJava {
options.setAnnotationProcessorGeneratedSourcesDirectory(file("$projectDir/src/main/generated"))
}
This way gradle will generate MyMapperImpl in src instead of build folder and it should be also recognized by VS Code.
I'm struggling with setting up environment for old tech project with PHP5.
My OS is Windows and I have installed so far VSCode plugins: PHP Debug, PHP Intelephense, PHPUnit, PHPUnit Test Explorer.
I downloaded phpunit-5.7.27.phar and configured VSCode according to documentation.
Settings.json
{
"php.validate.executablePath": "C:/wamp64/bin/php/php5.6.40/php.exe",
"phpunit.phpunit": "C:/wamp64/bin/php/php5.6.40/phpunit-5.7.27.phar",
"phpunit.php": "C:/wamp64/bin/php/php5.6.40/php.exe",
"intelephense.environment.phpVersion": "5.6.40",
"intelephense.environment.includePaths": [
"C:/wamp64/bin/php/php5.6.40/phpunit-5.7.27.phar",
"C:/wamp64/bin/php/php5.6.40/php.exe",
"C:/wamp64/bin/php/php5.6.40/"
]
}
Launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000,
"xdebugSettings": {
"max_children": 256,
"max_data": 500,
"max_depth": 3
}
},
]
}
What works for me fine is breakpointing on running app with xdebug and running unittests with Cmd+Shift+P.
What I need help with are as follows:
Code editor shows error for PHP unit classes and methods (even though unittests are executing fine as is). Do I need to add to path something besides phar file? Is VSCode non-compatible with phar files? The same happens for PHPUnit\Framework\TestCase.
I can't figure out how to configure Test Explorer plugin to show nicely tests tree. Does it require some configuration in Launch.json? Launching tests with Cmd+Shift+P displays results only in terminal.
PHP Intelephense requires installed PHPUnit with composer in workspace.
composer require --dev phpunit/phpunit
PHPUnit Test Explorer has by default Phpunit: Files setting set to {test,tests}/**/*Test.php, so changing it to proper glob should allow plugin to detect all tests.
I'm trying to debug Hy code in Visual Studio Code. I have downloaded the hy-mode theme and it works great. There's only one problem. The hy-mode theme disables breakpoints.
I can add a breakpoint to my Hy code by switching to a totally unrelated language (like CoffeeScript) and then my Python debugger works. But I can't add breakpoints when I'm in hy-mode.
I debug code by writing a Python file that imports a Hy file. When I run the Python pdb debugger on the Python file, pdb debugs the Hy code just fine. But I can't add breakpoints to the Hy file when I'm have hy-mode active.
Is there a way to edit a Visual Studio Code theme so that to allow the insertion of breakpoints?
I found a solution to this problem. By adding "hy" to the languageIds list in the following files I can get Hy files to display breakpoints.
./ms-python.python-2019.8.30787/package.json
ms-python.python-2019.8.30787/out/client/package.json
"debuggers": [
{
"type": "python",
"label": "Python",
"languages": [
"python"
],
"enableBreakpointsFor": {
"languageIds": [
"python",
"html",
"jinja",
"hy"
]
},
I'd like to be able to build Scala applications in Sublime Text 3 on Mac 10.9.3. I have Scala 2.11.1 and sbt 0.13.5 installed and they all work fine. I installed them by homebrew.
However, I can't seem to find how to create a build system for Scala projects. For example, this one doesn't work:
{
"cmd": ["sbt", "test"],
"selector": "source.scala",
"working_dir": "${project_path}"
}
I found a couple of different ones as well but they didn't work for me, either. Your thoughts?
UPDATE:
[Errno 2] No such file or directory: 'sbt'
[cmd: ['sbt', 'test']]
[dir: /Users/alex/Documents/projects/scala/dir1]
[path: /usr/bin:/bin:/usr/sbin:/sbin]
[Finished]
UPDATE2:
{
"cmd": ["/usr/local/bin/sbt", "test"],
"selector": "source.scala",
"working_dir": "${project_path}"
}
An app:
class MainTest extends App {
println("Hellowa!")
}
The output:
[0m[[0minfo[0m] [0mSet current project to scala (in build file:/Users/alex/Documents/projects/scala/)[0m
[0m[[0minfo[0m] [0mCompiling 1 Scala source to /Users/alex/Documents/projects/scala/target/scala-2.10/classes...[0m
[0m[[32msuccess[0m] [0mTotal time: 4 s, completed Jun 16, 2014 4:51:38 PM[0m
[Finished in 7.2s]
Homebrew installs executables in /usr/local/bin, but the error text you have now provided shows that that directory isn't in your path.
Two ways you could fix it:
1) Change "cmd": ["sbt", "test"], to "cmd": ["/usr/local/bin/sbt", "test"],
2) Add /usr/local/bin to your PATH environment variable. Note that you'll need to do this in such a way that GUI apps like Sublime Text notice the change; see e.g. Setting environment variables in OS X? for details
Could SublimeSBT that's "Scala SBT build tool integration for Sublime Text 2 and Sublime Text 3." be a solution?
Why wouldn't you :D I am using SublimeSBT for quite some time, and the only complexity it's invoking cmd+shift+p followed by sbt start continuous testing. I would advice you to give SBTSublime a try before baking your own build system.
Personally I use SublimeREPL that support SBT. SublimeREPL allows you to launch SBT from Sublime. This avoided me to download another package, cause I already used SublimeSBT for python. I wanted a minimal configuration to code in scala, because my IDE was to slow. I first try to use my on build system but end up using SBT. The SBT offers great advantages in comparaison to other way of building your project.
First it compiles only files that need to (those who have been modified, and those who depend on them).
Second it's very handy for importing library. One line into your build.sbt file allows you to import library from github (usually this line is explicited on the github main page).
And third you can compile on every save, with the command "~compile", or "~; compile; runMain 'mainclass' "
I find the later pretty useful as it is often long to compile with scala. I often start to add a simple function, save, and while it's compiling I improve my first draw.
The main constraint is you have to put your code in src/main/scala or src/main/java if you have some Java files too, and you have to open the whole root directory with sublime.
Windows only!
If you already add the bin folder to the PATH variable:
{
"cmd": ["sbt.bat", "test"],
"selector": "source.scala",
"working_dir": "${project_path}"
}