I have been using the Brackets editor for writing html- and js-files and testing them in Chrome with the live preview (having a server and using localhost, whatever the inner-workings of that is).
Recently this process called "node.exe *32", "Node.js: Server-side Javascript" has been running and taking up all the processing power (or 50% but I guess it's only because it uses one core(?)). Of course this makes the program totally unusable because in the long run it will heat up my laptop and perhaps destroy it permanently (luckily I have Core-Temp that will warn me when it overheats if I don't notice it).
The process won't shut off even when I close the editor and I have to kill it from the manager. Sometimes the things I'm doing in Brackets won't work when I kill it (and try and continue to use Brackets) but for example now that I tested everything seems ok even after killing the node.exe process.
What is causing this and how to stop it? Or what would be some other editors where I can write html, css and js files and test them in Chrome with a push of a button?
EDIT Again the program won't work after the process is killed and now the process even seems to be reborn whenever I kill it. It must be a virus of the most malicious kind???
I "solved" it myself by renaiming node.exe in the Brackets folder to something else. Now it won't run but at least the live preview still works. Don't know if xhttpxml-requests or that sort of cross-origin -stuff will work but it's OK for now if I don't use them.
Oh, it's just the file://... in the address bar so it's like not running the server I assume, so it's the same thing that I just opened the file to Chrome "as is". Well, at least I can now use the editor.
Still would like to know some answers.
Related
Newbie question here, it seems... I'm losing my mind. Why is this so hard? I've been programming other languages for years, but I'm relatively new to node and JS. I've read and watched as much as I can find official and unofficial on the web about this and it's either years old or significantly different from my situation, so not very helpful.
I'd really, really appreciate anyone who can understand my (pretty simple, I would have thought!?) specific case and help me get this set up to just work. Possible?
macOS 10.15.6 Catalina.
As I understand it, node comes with the OS. It's Node.js 12.8.1
VS Code 1.48.2
I create a new file, name it abcd.js. VS Code figures out it's javascript. I add some code - read a file of JSON from the disk, make some changes, console.log some stuff (appears under the Output tab). I run it.* All good and works.
Now... Run menu > "Start Debugging". Or, There's a Run/Debug icon in the sidebar that shows a "Run and Debug" button which I click on. Both of those ask me for an environment - I choose Node.js, and the Debug console outputs this:
/usr/local/bin/node path/to/my/file.js
Debugger listening on ws://127.0.0.1:56430/30b0c2aa-278b-4540-94c4-825d30b94f57
For help see https://nodejs.org/en/docs/inspector
And that's it. I have breakpoints, but it doesn't stop on them. Something happens (too quick to see what it is). I don't think it's actually running my code because nothing new shows up under the Output tab.
There's also a note in that sidebar saying "To customize Run and Debug create a launch.json file." I've experimented with that as much as I can, but nothing I do seems to help.
I've been programming for years. I'm used to other languages and IDEs (eg. C, Java, AppleScript, Swift, others), where you open the IDE, write some code, hit run (or debug), it may or may not build a target (depending on the language and environment), but then it runs the code (opens the target app, or runs in the IDE, and allows you to step through the code, breakpoints, etc. in the IDE if debugging). Is JS/node programming radically different from this somehow?
*One theory:
I'm not doing this through any terminal or any browser. Maybe that's the problem...? At some point I installed a "Code Runner" plugin that I believe is what is running my code. It was a while ago, but if I recall correctly maybe I turned to that because I was looking for the experience I've described above, and this plugin gave me that where the "normal" node setup process didn't? Perhaps my problem is that that plugin simplifies RUNNING js scripts so much that my issues with DEBUGGING exist because that plugin allows me to bypass other usual complications with running JS/Node scripts (but doesn't have any debugging functionality of its own)?
My thanks to #ippi for his/her comment with a gif video. Not sure if the following really answers my question, but I'm posting it in case it helps anyone else.
I took some time to clean up my Mac a little, and I completely uninstall VSCode, all its extensions and supporting files and started again.
I re-installed Code from scratch, didn't add any extensions, and then tried what #ippi's video showed.
It still didn't work - I got more or less the same output as in my post, and I'm not sure if it was running the code or not.
I had an urgent deadline to meet so didn't come back to it till now - two days later - and now, it's working.
A couple of things changed in that time though I really don't know what fixed this, if it was either of those or anything else. The two changes I can remember that I've done the last two days are:
Despite my post saying my node was 12.8.1, sometime in the last couple of days it turned into 8.something. I updated it to the latest v12.8.3, and
to meet that deadline I used node inspect myfile.js in Terminal for a bit.
The inspect (mostly) worked to meet my deadline, but still a hassle compared to what's shown in #ippi's video. I definitely wanted to get it working that way.
So… updating node fixed it? Running it in the terminal for a bit fixed it? Something else? I'm at a loss to know what did it. But it's working now.
Thanks again to #ippi for that. It pointed me in a good direction at least - to clean up my install a bit, if nothing else.
Maybe this will help someone else sometime in the future.
It seems the ultimate answer is:
It should just work out of the box (possibly subject to updating node to its latest). If it doesn't then:
The issue most likely isn't that you have to do any fancy configuring or whatnot to make it work.
Instead, most likely something is wrong with your installation and/or OS and you should explore that.
#ippi's video attached in case his/her link ever breaks:
I have a .js file that normally gets executed by cscript.exe (i.e. is not run in the browser and cannot be run there).
I know, that I can feed cscript.exe the //X parameter in order to get asked for a debugger to choose. Ok. That's fine.
I select "Visual Studio 2005 Debugger", IDE comes up, execution stops on the first line. Fine.
Script terminates (or I terminate it), I edit something and want to debug it again.
Simple thought would be just to hit F5 and run the debugger again. But this doesn't work. VS just tells me that it couldn't find any debugging symbols in cscript.exe:
What now? Starting cscript.exe from the command line again for each debug run is quite cumbersome in my opinion.
Is there a way to simply debug the script with VS? Also hints for other debugging tools would be appreciated.
Edit:
The answer of t0nyh0 is pretty close. I create a dummy console application, compile and the debugger comes up. However, two things are not perfect
cscript.exe always asks for the debugger to use (which instance of VS).
Could this be overcome by specifying a certain debugger instance directly in the command line?
In order to fire a post-build event, there have to be some modifications in the sources. Currently, I simply add/delete a blank line to trigger building of my dummy project.
Is there a way to always execute the post-build script, even if nothing has changed?
There might not be a way to attach the debugger to cscript.exe itself, but you may be able to create a post-build event that runs a batch file that executes the cscript.exe //x myScript.js command so that every time you build, it executes for you automatically.
See this for more information on post-build events: http://msdn.microsoft.com/en-us/library/ke5z92ks(v=vs.80).aspx
While not a debugger tool, you should consider using a JavaScript testing framework for Visual Studio, such as Chutzpah, which will most likely make your life a lot easier.
Along with standard browser debugging tools (Firebug or Chrome Inspector), I've found that's all I usually need to build clean, tested, mostly-bug-free JavaScript code.
I don't have cscript at hand, but I think you can try to attach VS to the process manually.
After you start up your js using cscript.exe //x myScript.js, click "Debug - Attach to Process", find your cscript.exe process and attach to it.
I forget if VS2005 has this function but VS2008 and VS2010 do.
It is the native debug action that VS takes to debug (attach to the running process). If this doesn't work, I don't think you can do this using Visual Studio.
Best Javascript Debugger is Rhino Debugger See http://www.mozilla.org/rhino/debugger.html .
it is open source and you can get the source code of the Debugger GUI.
you can customise it as you wish :-) .
I grabbed the latest dojo code to play around with the DOH robot. I have installed two exact copies of the dojo/dijit/dojox/util package: one on the root level of my server and one under /js/.
localhost/dojo
/dijit
/dojox
/util
Then another copy under:
localhost/js/dojo
js/dijit
js/dojox
js/util
When I navigate to http://localhost/util/doh/tests/Robot.html
, the DOH robot initializes fine and everything runs (the mouse moves, tests pass, etc.)
When I try to do the same thing, only in the /js folder, (eg, http://localhost/js/util/doh/tests/Robot.html) I almost always get the error:
Error: doh.robot not available; skipping test.
Sometimes the robot will load up fine and pass all of the tests. Sometimes I will have the Java popup asking permission to use the robot (when this happens, I get the doh.robot unavailable error.)
Any idea what could be causing this, or some tips to keep this from happening?
I have tried the following things (and even tried all combinations of these steps):
clear firefox settings (ctl+shif+del, check all)
f5, ctl+f5
kill the java process
restart the browser
restart the server
restart the computer
tried all different browsers, same effect
recompiled/resigned the DOHRobot.jar
The thing that really irks me is that I have seen it work fine before, so I know that java and plugins are installed correctly.
I can always go back to the top level and run the robot just fine; the problem only happens when I am in the /js/ directory.
Any tips would be great! Thanks
EDIT I think it works now. The problem was that I was recompiling the robot but not signing the JAR correctly. (Check the .bat file when you compile and notice how it looks for the keystore in the directory above you; when I was making the keystore it saved to the default user directory.) Even though I wasn't changing any of the java code, the JAR was still signed incorrectly. Also if anyone does this, one step I forgot to include was to clear the Java cache! I'm not sure how much that matters.
Anyway I think this is solved; it looks like I wasn't exactly describing the problem correctly either.
I have a web page which includes insane amount of minified JS files. The web page works perfectly fine on my local network but throws some JS error on staging. There is an issue in JS and I wan't to debug it. When I load the JS in Firebug's script tag it appears in one long horizontal line. Is there a way out in Firebug that expands or beautifies the script for debugging? I know I can use jsbeautifier but they wont help me. I can not upload an expanded file to CDN, defeats the purpose of using CDN.
Points to be noted,
a) I can not control the box which serves JS, its on CDN, I mentioned it.
b) I can use beautifiers etc but would that help me in debugging the script in run time? IMHO, no
c) Being bound by NDA and other legal things I can not share the script but its a generic problem, you can encounter it with a minified jQuery
Beautify your script
Add the CDN host in /etc/hosts or your local DNS to resolve it to your own web server
Host the beautified version and everything that you need on said web server
Both Firefox and Chrome (versions as of this edit) support beautifying script with the {} button available in the inspector.
Just load the minified file and press the {} button at the bottom and it instantly beautifies, making breakpoints and other debugging possible. (True for Chrome too)
This is a common problem and the Chrome dev team have recently come up with an elegant solution, which they've called Source Maps - see http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ for more info, I think you'll find it's exactly what you (and the rest of us) have been crying out for! :)
This is more a workaround, but it can help. The idea is that we will replace files coming from the server by files on your machine.
This will work with any browser.
It takes a bit of setup the first time (15 minutes maybe), but then it can be very convenient.
It can also helps testing your bug-fixes in a live/prod environment.
Get Fiddler (it's a web debugging proxy), install it, run it.
http://www.fiddler2.com/fiddler2/
(Restart browser after install to get the Fiddler extension)
If you debug an HTTPS website, check this first:
http://www.fiddler2.com/Fiddler/help/httpsdecryption.asp
From now on, you should see in Fiddler ("Web Sessions" pane on the left) all downloads made by your browser, including JS files.
If not, check this : Fiddler not displaying sessions
Find the file you want to debug in the list (Ctrl+F works)
Click on the file. Then either:
get the file content from the inspectors pane (textView tab), beautify it, save to a file on your local computer
or have access to a file which contains the source code (ex: from your source control)
Go to AutoResponder tab (top left pane).
Select "Enable automatic responses" checkbox.
Select "Unmatched requests passthrough" checkbox.
Drag your file from left pane to right pane (prefills rule editor at the bottom)
Set the other field with the path of your local file
Click the Save button
Reload the page and enjoy your debugging session.
Fiddler can do many more things, but this use-case answers the initial question.
Consider a Change!
Firefox w/ Firebug was my favorite JavaScript debugging method for almost a year, but I've recently moved to Google-Chrome's Developer-Tools which is far more superior.
Chrome supports an On-The-Fly (built-in feature) beautification of JavaScript resources
Once beautified, you are free to debug the JavaScript resource file, as it was "natively" downloaded beautified from the web-server. Breaking-points are set by clicking the line number.
One of the most extremely powerful feature,
Is once You've Stopped In A Breaking-point, You Are Free To Execute Commands (using console) In The Same Scope You ARE In The Breaking-point. In Firefox you can't do that.
Its so easy to debug (even anonymous functions), You'll never be back to Firefox.
Try It!
Pretty-print your JavaScript. Google this and you'll find multiple on-line JS beautifiers.
I happen to use http://jsbeautifier.org/ myself and it works fine, but search for others and use one that suits your needs.
Caveat: You still won't be able to get meaningful local variable names (which are usually renamed by a minifier). If the code was compiled by the Closure Compiler, then you absoutely won't get any useful information back at all, even when beutified, because then all variables and functions and properties are mangled (not only local ones).
Now, if your problem is with debugging code that comes from outside (e.g. a CDN), obviously that code would be minified, and you can't save your beautified version back there. In this case, you can replace the tags that load code from a CDN with a url pointing to your local version, then you can beautify the code (downloaded from the CDN) into your own server and you can then debug with FireBug.
Now, if you don't even control the HTML that contains those tags (e.g. they reside on a outside server), then unfortunately there is no way for you to do what you want without physically downloading the entire site to your own server. Even if you downloaded the entire site (with all the files), it may not work since the site may be driven by a back-end processing language or accesses a back-end database. In such case you'll also need to simulate all those data. It can be done, however -- you just have to go through a lot of pain. My recommendation is to save a version of the web page and run it on your own server, serving beautified code from your own server to debug.
Placing breakpoints on JavaScript makes debugging much easier, but if your code has already made it to production then it's probably been minified. How can you debug minified code? Helpfully, some of the browsers have an option to un-minify your JavaScript.
In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file and then press the "{ }" (pretty print) icon located in the bottom panel.
In Internet Explorer, click the tool icon by the script selection drop down to find the option to format the JavaScript.
Opera will automatically prettify minified JavaScript. Source
I have a page that has a byzantine amount of JavaScript code running. In Internet Explorer only, and only version 8, I get a long-script warning that I can reliably reproduce. I suspect it is event handlers triggering themselves in an infinite loop.
The developer tools are limping horribly under the weight of the script running, but I do seem to be able to get the log to tell me what line of script it was executing when I aborted, but it is inevitably some of the deep plumbing of the ExtJS code we use, and I can't tell where it is in my stack of code.
A way of seeing the call stack would work, but preferably I'd like to be able to just break into the debugger when I get the long script warning so I can just step through the stack.
There is a similar question posted, but the answers given were for a not-the-right-tool, or the not terribly helpful advice to eliminate half my code at a time on a binary hunt for the infinite loop. If my code were simple enough that I could do that, it probably wouldn't have gotten the infinite loop in the first place. If I could reproduce the problem in Firebug, I'd probably be a lot happier too.
Here is what I would do:
Go to http://www.microsoft.com/whdc/devtools/debugging/default.mspx and install the Debugging Tools for Windows. You want to run WinDBG when this is installed.
Follow the steps outlined at http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx#a to setup the symbol server connection and have the symbols automatically downloaded to your local drive (c:\websymbols -- or whatever).
Run IEXPLORE.EXE under WinDBG. The help file should give you assistance in doing this if necessary. You need a couple of commands once you get Internet Explorer running and such. First, go ahead and get that large script going.
Break into the debugger (CTRL-SCROLLLOCK to break).
a. Do a LN to "list nearest" to get the DLL files that are loaded. Hopefully, you'll have JSCRIPT.DLL loaded in memory.
b. Type .reload /f to force the reloading of all of the symbols. This will take a while. Now, after this is done, type LN again and you should see that the proper JSCRIPT.PDB has been downloaded to your system in the symbols directory you setup earlier.
Depending on what you want to do, you may need to restart the debugger, but you can do this: After the initial break on WINDBG load, you can type "sxe ld jscript.dll" and it will break when jscript.dll loads.
This is the tricky part, because once this loads, you don't have the code for jscript.dll, but you have the proper symbols (if they are not loaded, then reload them with .reload /f). You can view the functions available by typing "x!jscript" and you'll get a full list of all of the functions and variables.
Pick one, set a break point, and then you should be able to track what is happening to your script.
If nothing else is accomplished, by using the .reload /f process, you can get the appropriate jscript.pdb files loaded on your system. It's possible you could use these in conjunction with Visual Studio to do additional debugging in that manner, but I'm not so sure how well that will work.
I've run in to this before and have had some luck with enabling the developer tools along with Visual Studio. When an error is encountered the page loading is halted, and I could then load up Visual Studio to see the specific line causing the trouble.
This site has some information on using Visual Studio along with the Internet Explorer debugger: Using Visual Studio to Debug JavaScript in IE