WIP: Javascript debugging - Web developer wanted

[mmayfield45]

Yeah, thats fine

[zoot]

I've done a bit of testing, it's working really well. A few nitpicks:

- The game supports "hotloading", meaning if a loaded script is changed on the disk while in a game session, it will be reloaded. Any chance the UI could reflect this? I assume the UI polls the debugging server anyway to see if it is break, so maybe it could poll for updated scripts too?

- Can we fit a 'hostname' field somewhere in the UI to allow the user to connect to a different host than 127.0.0.1? Would be useful for people with multiple computers.

- The place to click to set a breakpoint is not well-defined visually. If I click in the far right side of the line number, it doesn't set a break point, but if I click in the far left side it does.

[quantumstate]

This UI looks great. I did a bit of testing and it seems nice.

I've done a bit of testing, it's working really well. A few nitpicks:

- The game supports "hotloading", meaning if a loaded script is changed on the disk while in a game session, it will be reloaded. Any chance the UI could reflect this? I assume the UI polls the debugging server anyway to see if it is break, so maybe it could poll for updated scripts too?

Hotloading of javascript is probably not likely to work very well. I don't think it is worth bothering with this.

[zoot]

It seems to work for minor changes, but oh well.

Here's a different suggestion then: Would it be possible to show line numbers in the call stack? It can sometimes be helpful to know not just what function made a call, but also what part of the function made it.

[historic_bruno]

While we're nitpicking

• The call stack and values list boxes should be cleared if we're not in the debugger, as that data is no longer valid
  
• It should detect when the connection to the server is lost and reset the UI
  
• Hotkeys would definitely be nice
  
• Would it be possible to arrange the files in a hierarchical/tree list?
  
• I would also like to have some settings: host IP and SetSettingSimultaneousThreadBreak
  
• This may be wishful thinking and very hard to implement, but how about hovering tooltips to show a variable's value?
  
• I like the find (Ctrl+F) feature in the source view, too bad it also opens Firefox's find box :/
  

Requests for the debugger itself:

• Local variables, if possible, would be quite helpful
  
• Include variable types/classes
  
• How about a "BreakAll" command, that breaks into all script interfaces? And "Break id" to break into a single script interface?
  
• ClearBreakpoints to clear all existing breakpoints
  

[quantumstate]

While listing nice features to have I would add a watch window to the list. For the debugger itself it would be awesome to be able to execute code, I don't know if this would be possible though. It would let us modify variables etc.

[zoot]

Yves, obligatory spelling fix: https://github.com/z...9606b3ac98.diff

[Yves]

Yves, obligatory spelling fix: https://github.com/z...9606b3ac98.diff

Thank you, I'll fix it for the next patch.

I've uploaded a new patch (v0.9).

Changelog:

• Fixes the problem that functions could fail because StringifyJSON returned an exception. Credits go to historicbruno for figuring it out.
  
• Fixes an assertion failure when loading random maps because they don't initialize the profiler but try to use it now through the debugger.
  

[historic_bruno]

Adding to the wishlist:

• Catch JS exceptions using the debugger (if possible)
  
• Allow something like assert() to optionally break into the debugger when a condition is met. I believe it was quantumstate who proposed a JS assert(). In release builds it obviously wouldn't break into the debugger, but log a message instead.
  

[Yves]

• Catch JS exceptions using the debugger (if possible)
  

That should be possible. The API supports hooks for exceptions.

[zoot]

Could JS_SetSingleStepMode() be used for the assert() functionality? I don't positively know what it does, but the name sure suggests that it breaks execution.

[quantumstate]

It would be best if we exposed a debugBreak() function to javascript. Then you could insert breakpoints into your javascript and we could easily add one to the assert.

[zoot]

It would be best if we exposed a debugBreak() function to javascript. Then you could insert breakpoints into your javascript and we could easily add one to the assert.

Alternatively, you could just do assert(false) at the point where you want to break.

[Yves]

A new version is ready. This version is the one I'm going to commit this Thursday if there are no objections.

Feedback is very welcome.

Changlog (I probably don't remember a lot of it)

• Set breakpoints in JS via: throw "Breakpoint";
  
• Displays local variables, the "this" object and the global object
  
• Works around circular references and some other problems which should allow it to display values correctly in most (if not all) cases
  
• Fixes some issues with stepping
  
• Fixes an issue with breakpoints on lines without code
  
• The debugger can now be enabled or disabled using a config setting. This works both in release and debug mode.
  
• Added a "Break" command
  
• Made two button ("Continue" and "Continue thread") instead of one ("Continue")
  

The GUI is attached.

The patch can be downloaded here.

User documentation is here: http://trac.wildfiregames.com/wiki/JavascriptDebugging

Technical documentation of the debugger here: http://trac.wildfiregames.com/wiki/JavascriptDebuggingServer

... I will still have to check the wiki for typos, I haven't spent much time on that yet.

JSDebugger.zip

[zoot]

Did some testing:

Displays local variables, the "this" object and the global object

I'm not sure how the 'this' object is supposed to work? I can't find 'this.entity' anywhere, for instance, even while in break on lines referring to it.

Also, apparently if I select a different stack frame, I have to 'step' before the 'Values' list is updated? Is it not possible to interrogate the various stack frames asynchrously, while the game remains in break?

Added a "Break" command

I'm not having much luck with this. I always end up in a non-existent file called "(eval)", resulting in this error in-game:

ERROR: CVFSFile: file (eval) couldn't be opened (vfs_load: -110101)

Other than that, it looks good!

[Yves]

I'm not sure how the 'this' object is supposed to work? I can't find 'this.entity' anywhere, for instance, even while in break on lines referring to it.

In which file on what line?

Also, apparently if I select a different stack frame, I have to 'step' before the 'Values' list is updated? Is it not possible to interrogate the various stack frames asynchrously, while the game remains in break?

You have to double-click on the stack frame.

I'm not having much luck with this. I always end up in a non-existent file called "(eval)", resulting in this error in-game:

ERROR: CVFSFile: file (eval) couldn't be opened (vfs_load: -110101)

I've seen this error too. It's because it tries to load the file "(eval)" from the vfs.

Eval is usually just one line of code that gets passed to the scriptinterface somewhere directly from c++. There's no real file associated with it.

It often stops in eval when you use "Break", but if you try a few times more it should also break somewhere else.

If there are multiple threads running you sometimes have to switch to the one you're interested in by double-clicking that thread.

[zoot]

In which file on what line?

simulation/components/Attack.js:435

var cmpPosition = Engine.QueryInterface(this.entity, IID_Position);

You have to double-click on the stack frame.

Yep, that did the trick.

Edited March 4, 2013 by zoot

[wraitii]

Gave it a go in release mode. Seems to work pretty nicely, doesn't slow it down toooo much (basically a .5 second lag quite regularly. Seems AI tied but can't be too sure)

[Yves]

Thank you guys for testing.

I'm not sure how the 'this' object is supposed to work? I can't find 'this.entity' anywhere, for instance, even while in break on lines referring to it.

simulation/components/Attack.js:435

That looks like a bug. I'll have a look at it.

[Yves]

I just committed the debugger here, here and here.

I've also had a look at the issue with properties missing in the "Values" panel.

Thanks to Philip and Alpha123 for helping me figuring it out. I haven't completely confirmed it yet but the problem seems to be what I explain here.

I've committed the debugger anyway because it's a problem that only affects the debugger and can be fixed later.

[zoot]

I just committed the debugger here, here and here.

Sweet. Pyrogenesis is becoming an industry quality engine

[zoot]

Would it be too much of a hack to have the debugging server launch a browser window with the UI when it encounters a "thrown" breakpoint in the code? Perhaps as an toggleable option? It would fit quite a lot better into my usual debugging workflow, than having to manually Alt-Tab out, browse through the file system, and finding the right file to open.

[Yves]

I think that could be done. There's already a function to open an url in the default web browser and adding another option to the config file isn't a problem either.

[historic_bruno]

How would that work with releases? Since they may not have source/tools available, and also it sounds annoying to maintain if we change the path of the debugger UI relative to the binary.

[zoot]

Right. Maybe it would be better to make a dedicated script that launches pyrogenesis and monitors whether it hits a breakpoint via the standard HTTP API, in which case it can launch the UI.