Hi Floh,

this is indeed a very interesting topic! I looked at this today. Here is my 
story so far...

Before I setup VSCode, I'd like to mention that I wasn't able to generate 
source maps for my project because Emscripten sourcemapper would choke on 
the size when doing buffer.toString at some point, so I decided to continue 
without them.

In VSCode, I decided to try installing the Chrome Debugger extension. That 
looked very promising. After installing the extension we configuring the 
launch.json, opening the folder and browsing to the .js files, if they were 
minified VSCode won't be able to put breakpoints. So first thing is to make 
sure to build with -g (which is equivalent of -g3), and use -O2 or -O3 
otherwise the code might be too large to be opened in VSCode. After this I 
was able to attach to Chrome, browse to my page and breakpoints would be 
hit. If the produced .asm.js or .js files are too big, VSCode will refuse 
to open them, in which case you are out of luck.

Cheers!

On Tuesday, February 2, 2016 at 2:28:45 PM UTC-5, Floh wrote:
>
> Hi,
>
> since the topic "Visual Studio" add-in popped up in another thread, and 
> debugging is still a bit of a pain point in browsers I remembered Visual 
> Studio Code again which was announced last year, and caused a bit of 
> confusion because it's not Visual Studio, but mainly an Electron-based text 
> editor like Atom, but with a debugger for Javascript and .NET applications, 
> and apparently has a fairly powerful extension system (I believe that the 
> debuggers are simply extensions, but not sure about that). Github repo is 
> here: https://github.com/Microsoft/vscode
>
> So I did a little (10 minute) experiment with emscripten, wrote a simple 
> hello world, compiled with source maps, and tried to get that debugged in 
> VS Code. Long story short: debugging the generated hello.js works, with 
> breakpoints and all, but I'm not able to set breakpoints or step through 
> the C source, even though VS Code theoretically has support for source maps 
> (Typescript debugging with source maps apparently works). I will continue 
> to investigate this a bit, it 'feels' like there's not much missing to make 
> basic source map debugging work.
>
> So... why would this be better than source map debugging in the browser? 
>
> Better hackability:
>
> VS Code extensions are written in Javascript, and instead of hoping that 
> source-map support in browsers improves for emscripten-compiled code, it 
> would (very likely) be much easier to add the missing parts to VS Code. 
> Maybe it would even be possible to add missing experimental source map 
> features (variable mapping?) that would only work between emscripten and 
> the VS Code debugging extension.
>
> I'm also not sure yet how debugging would work for emscripten applications 
> that use the canvas (it's trivial to get emscripten WebGL demos running 
> inside Electron, so may be not that hard). 
>
> So there, some food for thought ;)
> -Floh.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to