support for SourceMaps

[clarity99]

It seems Chrome has added support for SourceMaps (https://plus.google.com/u/1/110412141990454266397/posts/Nvr6Se6eAPh, http://code.google.com/p/google-web-toolkit/wiki/SourceMaps) and Firefox seems to be working on it as well (https://wiki.mozilla.org/DevTools/Features/SourceMap).

I think support for this would be a great addition to JSIL, as knowing the original source code location would simplify debugging a lot.

[kg]

I was just looking at this. It should be possible to add; I've dug into it a bit before. The biggest obstacle is that ILSpy and Cecil don't have great PDB support.

[clarity99]

Any news on this?

[kg]

I haven't seen any progress on usability of source maps or any other implementations for tools like JSIL. When I looked into it (I spent a day or so hacking on it) it was extremely difficult to get working for very little positive result (if anything, source maps would make debugging JSIL js harder, not easier).

[clarity99]

Thanks for looking into it!

[markusjohnsson]

I've not used it myself, but as I understand it, GWT has support for source maps - is there a huge difference in the way JSIL works compared to GWT, or why is source maps a good idea for GWT but not for JSIL?

[kg]

I don't honestly know how source maps for GWT work; I've never used it. From looking at the spec it seems like GWT-with-sourcemaps wouldn't provide a very good debugging experiences. Honestly, I expect GWT uses them because it has to - once you run some Java through GWT and then Closure Compiler, the output JavaScript is basically noise, so source maps will at least restore readability.

So far one of my priorities is ensuring that JSIL output JS is relatively readable and it's easy to map the JS back to C# by looking at identifiers, etc. So source maps don't immediately provide much value if that's all they do - because you still don't have a 1-1 mapping between JS vars and C# vars, etc. Source maps would need to provide more PDB-level functionality like variable information, etc so that you'd actually be able to debug a JSIL app with them turned on, and the current spec doesn't do that.

Breakpoints are also a challenge since one line of C# might map to multiple lines of JS (or multiple lines of C# might map to one line of JS).

[JohnTasler]

I would really like to see debugging support for JSIL. I'm considering using TypeScript since it has this built-in with VS2012. in case you haven't read it, here is a good article on getting started.

https://hacks.mozilla.org/2013/05/compiling-to-javascript-and-debugging-with-source-maps/

[kg]

What use cases currently aren't addressed without source maps for you?

[markusjohnsson]

Proper source maps support from both JSIL and Visual Studio would provide a huge improvement in debugging experience - you can put a breakpoint in the code you are actually writing as opposed to looking for the corresponding code generated by JSIL. Some JSIL-generated code is hard to grok - IIRC string switch is one example, generators ("yield") another. Stepping through calls in the Chrome debugger is hard too - when doing "step into" there are usually several steps of method and property resolving in JSIL before actually calling the user function.

Being able to put a breakpoint in my own (C#) code and hit F5 in visual studio and have the application stop on my breakpoint enables me to think about my code only, without having to translate in my head on-the-fly.

TypeScript uses source maps for debugging (using Internet Explorer) in Visual Studio, but I don't know if it is possible to set up source maps for other languages in VS.

I guess the question is about use case. Should I develop and test my app for CLR and "port" it using JSIL (debugging would then mostly concern differences btw CLR and JSIL) or should I develop directly for JSIL (then I want to be able to debug my code). I rarely use ILDasm to look at the code generated by CSC, in the ideal world I wouldn't have to look at the JavaScript either (which is why I'm interested in JSIL in the first place).

That said, I have no idea how big an effort it would be and how good a result we could expect from source maps. I think we can forget about typing C# in the "immediate window", "My code only"/"External code" differentiation and probably C# properties in the watches window too. There would probably need to be a proper debugging server for that.

Perhaps a source code split screen like Visual Studio Web Essentials provides for TypeScript is a good idea to ease the mental C#<>JS transition while debugging.

[JohnTasler]

Since TypeScript is open source, we (the JSIL community) could probably borrow much of their source map and VS integration code. It's all written in TypeScript, BTW. Unfortunately, I really don't have the time right now to look into it much.

http://typescript.codeplex.com

On Wed, May 29, 2013 at 1:56 AM, Markus Johnsson notifications@github.comwrote:

Proper source maps support from both JSIL and Visual Studio would provide a huge improvement in debugging experience - you can put a breakpoint in the code you are actually writing as opposed to looking for the corresponding code generated by JSIL. Some JSIL-generated code is hard to grok - IIRC string switch is one example, generators ("yield") another. Stepping through calls in the Chrome debugger is hard too - when doing "step into" there are usually several steps of method and property resolving in JSIL before actually calling the user function.

Being able to put a breakpoint in my own (C#) code and hit F5 in visual studio and have the application stop on my breakpoint enables me to think about my code only, without having to translate in my head on-the-fly.

TypeScript uses source maps for debugging (using Internet Explorer) in Visual Studio, but I don't know if it is possible to set up source maps for other languages in VS.

I guess the question is about use case. Should I develop and test my app for CLR and "port" it using JSIL (debugging would then mostly concern differences btw CLR and JSIL) or should I develop directly for JSIL (then I want to be able to debug my code). I rarely use ILDasm to look at the code generated by CSC, in the ideal world I wouldn't have to look at the JavaScript either (which is why I'm interested in JSIL in the first place).

That said, I have no idea how big an effort it would be and how good a result we could expect from source maps. I think we can forget about typing C# in the "immediate window", "My code only"/"External code" differentiation and probably C# properties in the watches window too. There would probably need to be a proper debugging server for that.

Perhaps a source code split screen like Visual Studio Web Essentials provides for TypeScript is a good idea to ease the mental C#<>JS transition while debugging.

— Reply to this email directly or view it on GitHubhttps://github.com/kevingadd/JSIL/issues/76#issuecomment-18603769 .

[markusjohnsson]

The TypeScript compiler and language service is open source yes, but AFAIK, the Visual Studio plug-in is not.

[iskiselev]

Do anybody knows some tool that allow you dynamically switch between SourceMap provided view and original JavaScript right inside debug session? So, that it preserve current debug context - current line, stack, breakpoints? Otherwise source C# view will be not usable for a lot of tasks (but could help a little bit).

[iskiselev]

SourceMap support could be activated by adding "BuildSourceMap" : true in .jsilconfig.

[iskiselev]

Probably we need introduce something like debug translating options, that will skip clever optimizations (such as EliminateTemporaries, probably some others). Also we may need preserve generation of nop as ";" lines - it will help build more precious source map. @kg - do you have ideas which FunctionTransformPipeline steps are not necessary and was introduced only for speed improvements? We may try to prepare list of them here (or in wiki).

[kg]

At this point I think the vast majority of them are performance-related. It is possible some behaviorally-important passes depend on the output of optimization passes, though.

I think a debug translation mode is a good idea.