In WebStorm, I have a Node application and I simply hit debug and on load the debugger stops on a bunch of seemingly random lines in node_modules. I can continue through about 5 files until I get to a router/index.js file that gets stuck on a single line for countless continues.
I have no breakpoints in any of the node_modules files, obviously, and WebStorm does not show a breakpoint. However it stops every time. My solution has been to mute all breakpoints, wait for the app to load, and then unmute. Sometimes, though, I have to re-add my breakpoints if I want the checkbox to check and be able to hit those breakpoints. At this point I have no issues. Any idea why it's getting stuck in node_modules with no breakpoints?
Figured out a workaround. I chose "view breakpoints" and although the points that were consistently stopped at were not listed, I simply removed all breakpoints, and I can now debug without stopping in random node_modules.
I ran into a similar issue in Webstorm 2017.2.4 while debugging clusters and workers. I have a file named worker.js and a number of breakpoints in it. When I debug through Webstorm, the debugger is pulling up every file it can find named worker.js and breaking on the same line number as marked in the "real" worker.js.
The only workaround right now is to rename the file while debugging it.
Sometimes a file may have hidden chars in it that confuses the parser, and setting a breakpoint in your primary file causes a break at a random line.
to determine if you have hidden chars open vi alongside the webstorm view of same file.
in vi...
:set list
:set number
from the top of the file scroll down looking at the end of each line to see if the $ isn't where you think it should be when moving down the same line in Webstorm editor.
if you find something like...
let j = 'hello' $
in the vi view, but see
let j = 'hello'^
^ being your cursor in webstorm, delete from the cursor one char. It will not move, keep going until the first visible char is deleted, then put it back, move to the next occurrence.
I've also encountered this problem and solved it by moving entrypoint code to another file, for example "lib/main.js".
index.js :
module.exports = require('./lib/main');
Related
I'm using Pylint with Sublime Text 3 on Windows 8.1. It is configured to run on save with Ctrl+S:
// Set to true to automatically run Pylint on save
"run_on_save": true,
and I like this.
The problem arises when I hit a shortcut for the 'Build' command - Ctrl+B or F7 without the file being saved: the Python script and Pylint start simultaneously and the script output (I see in 'Build result' pane below) often becomes broken (much of the printout disappears), or that causes Pylint error message boxes or crashes of my Sublime Text.
But nothing is wrong when I first save the file with Ctrl+S and then run it.
The question is can I configure Pylint for the delayed start (say, 1 second) after Ctrl+S so it will not affect the script run?
P.S. A brief search over Pylint settings of Sublime-linter settings did not yield useful results.
The resources I checked: Running Pylint, Pylint FAQ, Sublime Linter Settings. I did not find anything interesting about modifying pylintrc file (pylintrc example).
Any ideas? Thanks in advance.
You could write a plugin that inherits the ViewEventListener class and implement the on_post_save_async() callback method to sleep for a second (is that really enough, will it always be enough!?) and then use self.view.run_command() to launch Pylint. Ensure run_on_save is false if you do so. Here's the relevant bit of the API.
BUT doing that is NOT a good idea — you're asking for further problems with the output panels, error messages, and Sublime crashes.
I suggest you take full control of manually launching the linter. Set the Pylint run_on_save setting to false. Assign convenient keys to launch the linter when you want it and get out of the habit of running it automatically every time you save a file. Linters are like spell checkers, it is much more efficient to run them from time to time and make all the necessary changes in one go, rather than having the linter run over and over again, repeatedly validating the same code, just to check the most recent few lines.
If you try and write larger and larger amounts of code without building or linting then in time the accuracy and speed of your coding will improve.
How do you go about debugging a non-responsive python/PyQt application in PyCharm?
I am an experienced programmer, but new to all thing python. I have been given a large application (36,000 lines), which works under Windows, to port to Linux.
Having made just a handful of changes for OS-specific stuff, when I run the application it comes up with its main window. But then after a few seconds it becomes dimmed, and when I close the window I am asked to confirm to end "the window is not responding".
(Aside: On a whim I decided to try running the app via sudo, and surprisingly it works fine. I have tried doing strace running as root versus non-root, but I'm fairly sure there is nothing obvious in the way of file accesses/permissions etc. that differs. This may be a clue, but just as likely to be a red-herring, e.g. if it's an "uninitialized variable".)
If I debug it inside PyCharm, at that point I expect to click the "Pause Program" button, so that I can get a trace back and begin to see where it is in the code, and start stepping or whatever. However, that button does nothing at this stage? Maybe it only "works" when on "a python instruction"?
If I force a core dump (from the keyboard) and examine with gdb, I can see that the stack frame shows it is way down inside libQtCore/libQtGui, in processEvents on a call to read.
So how do I begin to go about debugging why it is (presumably) busy doing something at this point, or at least not responding? Any tips would be welcome. I do hope this question will not fall foul of SO's "too general" policy, any tips to get someone going on debugging a "non-responsive" program would be welcome.
To answer my own question, since no responses seem to be forthcoming.
In this case, the problem turned out to lie in a file which is imported into other files, named pyperclip.py. That had code outside of any function, and in a path through the source executed under Linux but I think not under Windows, which included:
app = PyQt4.QtGui.QApplication([])
cb = PyQt4.QtGui.QApplication.clipboard()
Clearly some attempt to gain a clipboard object. For whatever reason, this appears to work when run as su, but when run as the logged on user it causes the whole application to "hang". Removing those two lines solved the unresponsiveness.
In terms of what I learnt from this for debugging unresponsive applications: you need to debug not from the entry point of the program, as I would have expected, but rather right from the start of each file, and actually step into each import line just in case it is executing some initial code. Horrible!
Is there anyone who has good experience with debugging larger coffee script projects in Webstorm?
I have a nodejs project having 200K+ lines and it driving me crazy debugging that. 50% of breakpoints set in coffeescript files are hit, but in most cases I need to find a generated .js file and put the breakpoint in the respective place. That .js-file breakpoints work well with 100% accuracy. But managing at the same time js and coffee script files is really pain in the neck. Of course I might have case when there is one file and breakpoint in one coffee line works well and on the next line doesn't.
I'm using standard coffee transpiler (1.8, same with the previous versions), but I tried as well coffee-script-redux and result were the same.
Any good or bad experience with that?
Very often (as in multiple times an hour), when I save my file :w, vim tells me "E13: File exists (add ! to override)"
I don't know why it does this, I can't reliably reproduce it, it feels random.
This is my vimrc, note that it sets nobackup, nowritebackup, and noswapfile, and there is a function to strip trailing whitespace that gets run when I save a file.
Also, I tend to have 20 vims open at once, all backgrounded, often editing the same file. Also not improbable that I have the same buffer open in multiple windows (ie :vsp) and might open it, then reopen it with the e command a lot, possibly from a relative filepath, or possibly from an absolute one (the cmap %/ <C-R>=expand("%:p:h")."/"<CR>). No idea if any of this matters. Next time I have this issue, I'll check my ls and report anything odd.
Update:
When I tried to save "lib/seeing_is_believing/wrap_expressions.rb" (note that this is a different file than the one in the gif), this happened again. Here is the ss, it's buffer 3:
Update2 (for #mMontu)
I just realized that there are two errors happening here. The one in the screenshot is the readonly thing. The one in the gif is the more common one, E13: File exists (add ! to override)
The one I just hit is E13 File exists, for this one, readonly is not set:
Update 3
I'm pretty sure the problem is the ZoomWin plugin. I had switched it up to a newer version, and it simply didn't work right. So I stopped using it for a bit, and didn't have this issue. Then switched it back, b/c I miss its functionality (it's my favourite vim plugin), and the problems started again. Possibly it's ZoomWin in conjunction with NerdTree window. Probably not the lib authors' faults, vim in general seems fragile and buggy. Maybe I'll try NeoVim, see if they've done a better job. Maybe it's time to try Atom or Emacs again.
It seems that if there were read errors opening the file, Vim will print an error on :w. This can be seen by running :f:
"MANIFEST.in" [Read errors] 1 line --100%--
The errors aren't necessarily errors in reading the contents of file; they can be caused by a plugin.
I think the main problem is that the file has been modified externally, see http://vim.wikia.com/wiki/Have_Vim_check_automatically_if_the_file_has_changed_externally to reload it whenever this happens
I somehow cannot get the TeX-PDF plugin to compile the files appropriately. It states in the plugin description that it defaults ot pdflatex, which I have on my Windows 7, it is mapped in the path variable. It spits out the error:
compiled with errors
which is baically an undefined case (there are no errors in the file, it compiles with pdflatex from the cmd well).
I tried almost all of the solutions for VIM (like vim-latex, atp, etc) but I can't get them to work with pdflatex. I just want to be able to avoid the process in the command line. I need a step by step, or really well explained guide, because I am sick of reading all the manuals from top to bottom, and not having a result.
If you
:set shellcmdflag=/k
any external shell command invoked from Vim will keep the console window open. You'll see the exact command-line that the plugin uses to compile, and can investigate from there what's wrong. Once you've found the problem, you need to "work backwards" to see how you can get the fix into the plugin; maybe there's a setting to influence the compilation. (I don't know / use the plugin myself.)