I'm using Visual Studio Code.
I just created a resolvejs application.
How to run the application step by step from vscode ?
Here is my debugging setup (in .vscode\launch.json):
{
"type": "node",
"request": "launch",
"name": "Debug",
"program": "${workspaceFolder}/run.js",
"args": [
"dev"
],
"runtimeExecutable": "${workspaceFolder}/node_modules/.bin/babel-node",
"runtimeArgs": [
"--nolazy",
"--inspect"
]
}
My breakpoints in my command handlers do not work.
Although file run.js is some kind of entry point in resolve framework-based application, it is not actual entry point for runtime phase. When resolve application is being launched by yarn dev / npm run dev command, in fact two actions are performed: building bundle using run.js (which by default uses config.[MODE].js files for appropriate mode) and launching target bundle in separate process with watch mode, which causes automatic rebuild on every file change in project (aka hot reload).
Bundle is stored at <APP_DIR>/dist/common/local-entry/local-entry.js. To allow debugging from IDE, spawned debug nodejs should invoke target bundle directly. It can be reached by separating application compile- and runtime phases.
Resolve includes command for application building without run it - yarn build / npm run build. This command builds application in production mode, but this behavior can be easily modified to development mode by editing run.js entry point - just find line case 'build': and replace following line from await build(merge(baseConfig, prodConfig)) to await build(merge(baseConfig, devConfig)). Or additional script for building app in dev mode can be appended, like yarn build-dev - amount of possible scripts is unlimited.
Then just run command yarn build and start debugger with pointing entry point as ${workspaceFolder}/dist/common/local-entry/local-entry.js. If source maps had built right, breakpoints should work fine.
Related
My Setup is the following:
I use a quite big python repository and code with VS Code with the following setup:
Version: 1.66.0 (user setup)
Commit: e18005f0f1b33c29e81d732535d8c0e47cafb0b5
Date: 2022-03-30T05:50:14.623Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: 9.8.177.11-electron.0
OS: Windows_NT x64 10.0.19041
Since yesterday the debugger doesn't start anymore. When I start it with the buttons or with F5, the debug toolbar shows up for a second and then it vanishes again. The normal run works perfectly, as well as when I run my file from a terminal.
I didn't really change something that I can remember, only that VS Code did an automatic update on Monday evening.
There is no Terminal output that I can show, since it is not opening a Debugging Console.
I used the debugger always directly from the file that I needed to debug and didn't specify any launch.json files.
What I already tried, is as mentioned using not the Debugger, but the Run command and started the files from a terminal outside of VS Code. Then my code runs as intended. But since I need the debugger for my work, this is not a good solution.
I also went back a few commits to the last step where I know it was working, but this didn't change it at all.
I tried to debug a simple "hello World" python script but there I have the same problem.
I used the automatic add configuration from VS Code and it added the following launch.json file to the .vscode folder in the repo. Together with this file it added a configuration called "Python: Aktuelle Datei" (german for current file). This also didn't help when I'm trying to launch it with this configuration.
{
// 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": [
{
"name": "Python: Aktuelle Datei",
"type": "python",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal",
"justMyCode": true
}
]
}
Is there anyone who encountered a similar issue?
After running Hardhat tests in the console with npx hardhat test I decided that being able to set break points would help me iterate faster.
How can I get Webstorm to run the underlying functions started by npx hardhat test so that I can use the built in Debugger?
I've since discovered that hardhat runs mocha under the hood.
To debug in WebStorm you can:
delete your existing configurations
create a new mocha configuration
set any configurations in 'Node options'. Note: since I'm forking the main net it takes a while for tests to start so I added the --timeout 10000 because mocha's default timeout is only 2000ms
select the mocha package, WebStorm doesn't select it by default
set your test file pattern
add const {ethers} = require('hardhat'); to your test file because it is no longer injected by hardhat during run time.
If the green debug icon does not appear I had success in closing and reopening WebStorm.
At this point I could successfully set break points in my test file but not in the MyContract.sol file. This is not surprising given that the contract is compiled before its run.
Create or open the package.json file for your Hardhat project.
Add a test NPM run script and save the file. Your package.json should look something like this.
{
"name": "hardhat-project",
"scripts": {
"test": "hardhat test"
},
"devDependencies": {
"#nomiclabs/hardhat-ethers": "2.0.2",
"#nomiclabs/hardhat-waffle": "2.0.1",
"chai": "4.3.4",
"ethereum-waffle": "3.4.0",
"ethers": "5.4.4",
"hardhat": "2.6.0"
}
}
In the left gutter of the editor pane, a little play icon should appear, click it and then click Debug "test".
I go through the instructions in a little more detail here, but this is the general idea. https://allendefibank.medium.com/how-to-debug-solidity-contracts-in-webstorm-hardhat-2ea0d3c4d582
If you're use typescript you need to import ts-mocha instead of mocha
I have a simple LinkedList implementation in Node. I want to test it using Mocha -- simply exercise different append/delete operations. And most importantly, I want to be able to stepthrough/debug my linkedlist as called from the mocha tests.
This is my launch.json:
{
"version": "0.1.0",
"configurations": [
{
"type": "node",
"request": "launch",
"protocol": "inspector",
"name": "Mocha All",
"windows":{
"runtimeExecutable": "c:\\Users\\alern\\AppData\\Roaming\\npm\\_mocha.cmd"
},
"args": [
"--colors",
"${workspaceFolder}\\test\\test.js"
],
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen"
}
]
}
when I press Run on my "Mocha All" configuration in VSCode,
global installation of mocha.cmd starts running, I see the following in the terminal:
cd 'd:\Projects\Algorithms\LinkedList'; & 'c:\Users\alern\AppData\Roaming\npm\_mocha.cmd' '--inspect-brk=30840' '--colors' 'D:\Projects\Algorithms\LinkedList\test\test.js'
(node:21524) ExperimentalWarning: The ESM module loader is experimental.
The above makes sense.
And then I see:
all of my tests simply rip through --- although I have setup some breakpoints in the Mocha scripts, they get ignored. So thats useless.
once all the tests are done (some successful, some not), at the end I get a popup that says:
"Cannot connect to runtime process, timeout after 10000ms - reason: Cannot connect to target: connect ECONNREFUSED 127.0.0.1:30840" This error feels like my process is done running and gone away, and VSCode or debugger are trying to connect to it?
In any case, what do I tweak to have my breakpoints stop execution? Thank you
The first thing I might try is to change the type to "pwa-node". I think mocha or VSCode recently made some changes that make that mandatory. You might also not want to set the runtime executable, but rather the "program". Generally the runtimeExecutable will be node, and if it's on your path VSCode should be able to find it automatically.
If all else fails I'd also try looking at the default configuration that ships with VSCode and see if that gives you any clues. That can be accessed by adding a new configuration through the "Add Configuration..." button. https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_launch-configurations-for-common-scenarios
I really like streamlit as an environment for research. Mixing a notebook/dashboard-like output I can design quickly with pure code for its definition (no cells etc.) as well as the ability to influence my code through widgets while it runs is a game changer.
For this purpose, I was looking for a way to run or even debug a streamlit application, since the tutorials only show it being started via the commandline:
streamlit run code.py
Is there a way to do either running or debugging from an IDE?
I found a way to at least run the code from the IDE (PyCharm in my case). The streamlit run code.py command can directly be called from your IDE. (The streamlit run code.py command actually calls python -m streamlit.cli run code.py, which was the former solution to run from the IDE.)
The -m streamlit run goes into the interpreter options field of the Run/Debug Configuration (this is supported by Streamlit, so has guarantees to not be broken in the future1), the code.py goes into the Script path field as expected. In past versions, it was also working to use -m streamlit.cli run in the interpreter options field of the Run/Debug Configuration, but this option might break in the future.
Unfortunately, debugging that way does not seem to work since the parameters appended by PyCharm are passed to streamlit instead of the pydev debugger.
Edit: Just found a way to debug your own scripts. Instead of debugging your script, you debug the streamlit.cli module which runs your script. To do so, you need to change from Script path: to Module name: in the top-most field (there is a slightly hidden dropdown box there...). Then you can insert streamlit.cli into the field. As the parameters, you now add run code.py into the Parameters: field of the Run/Debug Configuration.
EDIT: adding #sismo 's comment
If your script needs to be run with some args you can easily add them as
run main.py -- --option1 val1 --option2 val2
Note the first -- with blank: it is needed to stop streamlit argument parsing and pass to main.py argument parsing.
1 https://discuss.streamlit.io/t/run-streamlit-from-pycharm/21624/3
If you're a VS Code user, you can debug your Streamlit app by adding the following configuration to your launch.json file:
{
"name": "Python:Streamlit",
"type": "python",
"request": "launch",
"module": "streamlit",
"args": [
"run",
"${file}",
"--server.port",
"SPECIFY_YOUR_OWN_PORT_NUMBER_HERE" ]
}
Specifying the port number allows you to launch the app on a fixed port number each time you run your debug script.
Once you've updated your launch.json file, you need to navigate to the Run tab on the left gutter of the VS code app and tell it which Python config it should use to debug the app:
Selecting Debug config for python interpreter
Thanks to git-steb for pointing me to the solution!
I've come up with an alternative solution which allows you to use PyCharm debugging in a natural way. Simply set up a run script (which I call run.py which looks like this:
from streamlit import bootstrap
real_script = 'main_script.py'
bootstrap.run(real_script, f'run.py {real_script}', [], {})
and set that up as a normal Python run configuration in PyCharm.
Cannot comment so I have to put this as an answer.
An addition to #Ben's answer (module debugging part):
if your script needs to be run with some args you can easily add them as
run main.py -- --option1 val1 --option2 val2
Note the first -- with blank: it is needed to stop streamlit argument parsing and pass to main.py argument parsing
With some modification to #aiwa answer - This worked for me in the VS code version - 1.58
{
"configurations": [
{
"name": "Python:Streamlit",
"type": "python",
"request": "launch",
"module": "streamlit.cli",
"args": [
"run",
"${file}"
],
}
]
}
Aug, 12, 2022:
Please update your pip and streamlit versions. Sometime, it is mandatory to update all both version.
pip install pip --upgrade
pip install --upgrade streamlit
Open Pycharm Editor and go to the Edit Configuration file as mentioned below in picture. Do not clear streamlit in my dropdown box. Click on dropdown box.
Run/Debug Configurations:
You have to change three directories remember that script path.
1) You can obtain script path by typing which streamlit in terminal and paste the path in script path.
2) click on working directory and give directory of your python file which contain streamlit.
3) in Paramaters: give python file name like app.py with run.
Alongside other solutions, another easy and quick solution is using pdb library.
For instance;
st.dataframe(df)
import pdb; pdb.set_trace()
st.bar_chart(df)
When you run code, your IDE (or even command line) will stop at the 'set trace' point and the command line show you something like that:
(Pdb)>
In that case, you can call your variables and process them on the command line. For instance:
For other options of PDB library please see: https://docs.python.org/3/library/pdb.html
I use intellij with a mean stack and i want to debug the js file of my server.
Until now, i launch "grunt serve" in a line command from the directory where my project is and i have no problem.
In intellij there is two way to debug a project with nodejs. You can use the remote debug configuration. This way is working but not very confortable. you have to stop the debugguer each time you made a change in your js files and you have to restart the debugguer....
Or you can configure a GruntJs configuration.
I try to use this way but i don't have the same behavior that i have when i launch "grunt serve" in a terminal from the project directory. The process stuck at the "concurrent:server".
this is my configuration from intellij :
And this is the line command generated by intellij
/usr/bin/node --debug-brk=36118 --expose_debug_as=v8debug /home/bryan/Documents/projects/subscriptions/node_modules/grunt/node_modules/grunt-cli/bin/grunt --gruntfile /home/bryan/Documents/projects/subscriptions/subscriptions/Gruntfile.js -v -d serve
So my question is : What's the difference between using "grunt serve" in a terminal or using a grunt debug configuration from intelliJ ?
Well i found theses links from intelliJ Support
Solution :
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206320279-AngularJS-debug-grunt-server-hangs-at-Running-concurrent-server-concurrent-task
Explanation :
http://stackoverflow.com/questions/19252310/how-to-fork-a-child-process-that-listens-on-a-different-debug-port-than-the-pare
The problem is likely caused by the way Grunt spawns child tasks. By >default, the spawned child process uses the same debug port as a parent >process - as a result the forked process is suspended and the >application 'stalls'. See >http://stackoverflow.com/questions/19252310/how-to-fork-a-child-process->that-listens-on-a-different-debug-port-than-the-pare, for example.
Please try adding process.execArgv = []; at the top of the gruntfile.js
at the top of your Gruntfile.js - does it help?
And yes adding process.execArgv = [] at the top of GruntFile.js remove the stuck of "concurrent:serve" but my breakpoints don't work on port:5858
before overwritting process.execArgv here is content :
[ '--debug-brk=40305', '--expose_debug_as=v8debug' ]
At the start of the "grunt serve" i have this :
/usr/bin/node --debug-brk=40305 --expose_debug_as=v8debug /home/bryan/Documents/projects/subscriptions/node_modules/grunt/node_modules/grunt-cli/bin/grunt --gruntfile /home/bryan/Documents/projects/subscriptions/subscriptions/Gruntfile.js serve
debugger listening on port 40305
Running "serve" task
And at the end :
Running "express:dev" (express) task
Stopping Express server
Starting background Express server
debugger listening on port 5858
Express server listening on 9000, in development mode
In the intellij debugger variables panel its show "Connected to localhost:40305"
When i use a second debug configuration with nodejs debug remote on port :5858 breakpoints are working but this is ugly as i have described in my first question.
i tried this solution but nothings changes :
https://stackoverflow.com/questions/21957411/debugging-grunt-with-intellij?rq=1
my gruntfiles already own theses properties :
express: { dev: { options: { script: 'app/server.js', debug: true } } },
and theses modifications at line 71 in this file node_modules\grunt-express-server\tasks\lib\server.js, changing '--debug' to '--debug-brk='don't affect debugging.