On my archlinux system I did a fresh installation of:
mono 3.0.7
monodevelop 4.0.8
monodevelop-debugger-gdb 4.0
When I debug an application the debugger doesn't stop on the breakpoints, even not on the System.Diagnostics.Debugger.Break (); code.
And an error windows is displayed with the following message :
Could not connect to the debugger
Does anyone know how to fix it?
This is due to a recent gnome-terminal change. Recent gnome-terminal no longer accepts the --disable-factory argument.
Install the xterm package, then in a gnome-terminal session do the following:
$ unset GNOME_DESKTOP_SESSION_ID
$ monodevelop
This will cause monodevelop to use xterm as its external terminal and all should be well.
As a workaround untick the "Run on external console" checkbox in your running project settings. You can find this option in the "Run" tab from the settings pane.
Another factor which will cause break points to not be hit is if you don't have "Emit debugging information" button set.
You'll find this setting in "Project" tab then at the bottom of the menu " Option". Then look for "Build" tree branch then "Compiler" option. The checkbox for "Emit debugging information" is here.
I had a similar problem - breakpoints was not triggered while checkbox "Use MSBuild build engine" was checked in the project properties.
Related
When running as a normal user, if you click on Netbeans->Preferences the window will open, shake, flash, freeze, and not let you do anything. The same thing happens with the Tools->Plugins. Running as super user it works perfectly. I have cleaned up all NetBeans related files. You can see it in action here.
It's useless as it is.
Ive found a partial workaround for this.
You need to setup the OS not to open new documents as new tab.
Go to the Apple Menu, select System Preferences > General. In the Prefer tabs when opening documents option, select "never".
Then restart Netbeans and try to open Netbeans preferences.
If you don't want a system-wide change, you can set the following setting. It should affect only applications running on JDK, run this in terminal:
defaults write net.java.openjdk.cmd "AppleWindowTabbingMode" never
It turns out that is a problem related to the AppleWindowTabbingMode
settings. I was using "always", since I want that apps like Finder and
other use new tabs rather than new windows.
This settings worked fine with NetBeans since Catalina. So I reset the
behavior to "never" only for NetBeans, with the follow command
defaults write net.java.openjdk.cmd "AppleWindowTabbingMode" never
With this setting NetBeans works finally fine!
Sources: apparently, it's a bug, please see here and corresponding JDK bug.
Also, it's not a problem with NetBeans only. It affects AndroidStudio also see here for example:
If you choose to run it as root, here's what I use:
#!/bin/bash
APP=/Applications/NetBeans/Apache\ NetBeans\ 12.2.app/Contents/MacOS/netbeans
COMPLAINT="Netbeans must run as %U because of bugs in the UI implementation :{"
PROMPT=$(echo -e "${COMPLAINT}\nPlease enter your login password for privilege escalation:")
sudo -p "${PROMPT}" -b -s "${APP}"
This lets me limp by with a recent JDK (15.0.2) which placates the corresponding NetBeans (12.2, as you can see from the code). The -b option tells sudo to run the app in the background, which in this case means simply that the Terminal in which you ran this script will not be polluted with JDK whinging about "illegal reflective access".
Just like Node.js.
Running and debugging Node.js NodeJs Debugging
WebStorm supports the V8 Inspector Protocol, so you're good:
Go to "Debug Configurations" (Alt+Shift+9)
Add a configuration ("+" on top left corner)
Select "Attach to Node.js/Chrome"
Make sure the "Chrome" option is selected (should be default)
Click "Apply" and "Debug" to start the debugger
Create your breakpoints
With the debugger running, run your script with the --inspect-brk option:
deno run --inspect-brk -A app.ts
Now it will work as intended with the IDE. You can use the Debug view to step in, over, etc.
We should expect a plugin some time in the future.
From deno debugger:
Deno supports the V8 Inspector Protocol.
It's possible to debug Deno programs using Chrome Devtools or other clients that support the protocol (eg. VSCode).
You can run and debug files using Deno with the Deno plugin.
I'm trying to debug a test using nosetests in PyCharm. I need to stop at a breakpoint and do some interactive debugging using the PyCharm debug console. However, whenever I type anything at the debug console prompt, nothing is printed; I just get a new prompt. The debug console works perfectly with pytest, but I need to use nosetests for this particular test. How can I get the console to work correctly?
Most likely your nose runner suppressing stdout. Try running nosetests with -s
Under the "Tools" menu, select "Edit Configurations." In the dialog, expand "Python tests" and select the nosetests you are running. Add "-s" as an "Additional Argument".
Under the Tools menu, select Edit Configurations. In the dialog, expand Python tests and select the nosetests you are running. On the Configuration tab, under the Nosetests section, make sure the checkbox in front of Params is checked and then add -s as a parameter to it. Apply and Save.
I recently installed git 1.8 for windows and chose to install the cheetah plugin for windows explorer shell integration. However, I don't see any options pop-up in the right click menu. Is there something I have to do to get it to appear in the right-click menu?
I am using Windows 7 Enterprise 64bit.
In:
C:\Program Files (x86)\Git\git-cheetah
Do:
regsvr32 git_shell_ext64.dll
This at least gets you 3 context menus (don't know if cheetah plugin cause I never saw it :-)
Is this a bug or what? I thought installer should be doing this (things like registering DLLs).
P.S. of course you have to run this command as Administrator.
P.P.S. Start | Run, type cmd.exe, then RIGHT CLICK cmd.exe and select "run as administrator". Apparently you also have to restart Windows Explorer to see the context menu.
Cheetah plugin seems to be broken in Git-1.8.3-preview20130601 on some systems (including mine). Re-registering .dll file as suggested didn't helped. The way I fixed it is:
Install older version - Git-1.8.1.2-preview20130201 with Cheetah
plugin.
While updating to Git-1.8.3-preview20130601 deselect context
menu integration (no worries, it won't uninstall a plugin).
The registry entry is separate for when you right click on a folder icon versus right clicking on space inside a folder.
If memory serves "Cheetah" only works with the former.
Example
I have the same problem on Windows 7 with Git-1.8.3-preview20130601 version.
Supposedly when you select the Cheetah plugin on install it also installs the git-gui and gitk tools as well, but these were not showing up in the right click menu either.
After adding the path to the git cmd folder I at least got git-gui and gitk to be available. ie add to your PATH variable:
"path to git directory install"\cmd
I'd like to add a file to my project that has a list of gbd commands and load that into GDB within xcode at any breakpoint. Looking at GDB documentation I see the "source" commmand, but it is unknown within xcode's gdb. Has anyone had success doing this?
source -f commandfile.gdb
Thanks,
The source command appears to work although no options are supported if you are really using gdb as the debugger. In the debug console make sure it says "(gdb)" as the prompt. The default debugger now is LLDB instead of GDB. You can change this under Product -> Edit Scheme… and select the "Info" tab at the top. The "Debugger" popup will present you with GDB or LLDB.