Hi Alain, for Jangaroo, I answered this question here: http://markmail.org/message/bwjwc7sxfbertu7f For Flex / FalconJx, it seems nobody was extremely fond of the idea to have to keep all the white-space and take care of generating JS code in the exact line of the source AS code. So we have to find another solution for the problem. One could be to use JavaScript source maps<http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/> to provide a link from the generated code back to the original code. Chrome's developer tools can already read source maps and display the original source code in the debugger. When you set a breakpoint there, the debugger knows where to break in the JS code and stops accordingly. It's like magic! Firefox and IE are going to implement this feature, too, but it is not there yet. I implemented experimental support for source maps in Jangaroo, you can see a screenshot of how it would feel here: http://twitter.yfrog.com/z/odaebmp Google Closure Compiler and Uglify2 can both generate source maps, but only from the generated JavaScript to the minified JavaScript. We would have to take care to create a source map from AS source code to our generated code. Closure provides a Java API, which I successfully used for the Jangaroo source maps prototype. We could even chain both source maps into a direct mapping from AS code to minified JavaScript. Note that minified JavaScript will still be harder to debug, as local variables and other identifiers have been renamed, functions may have been inlined and so on.
Greetings -Frank- On Mon, Jan 28, 2013 at 9:20 AM, Alain Ekambi <jazzmatad...@gmail.com>wrote: > One thing I was thinking about. How would debugging work ? Let's say I set > a break point in my as3 code how will debugging the js output look like > > Greets > > Alain > On Jan 28, 2013 8:37 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > > > Hi, > > > > > entire library + application". My example was that you change a single > > > file, but change it in a way that you add a dependency. Without > > > re-generating deps.js, base.js could not know in advance that the newly > > > > We're talking AS -> JS cross compilation. So changing one file would > > be changing one AS file. To turn that AS file into a JS file needs a > > compilation step. The generation of 'deps.js' is part of the > > compilation step. So, in the scenario we're discussing, the > > regeneration is of no consequence. Also, more importantly, 'deps.js' > > is only needed for the 'intermediate' output, not in the release > > output. I think if we're going to be comparing anything, we should be > > comparing 'production/release' code, not 'convinience/intermediate' > > code, right? > > > > >> > and compile it with Jangaroo 3 and also deploy the output. What do > you > > >> > think? > > >> > > >> I enabled "View Source" on the Flash output, so you can grab the AS > > >> source and put it through Jangaroo if you please. You can also pick up > > >> Alex's FlexJS source and do the same with that.Might be interesting to > > >> see what comes out and compare the various approaches when using a > > >> different compiler. > > >> > > > > > > Yes, I'll try to do that, but except from the deps.js file discussed > > above > > > I expect the difference to be rather small. > > > > So, if 'deps.js' is not needed -- like it's not needed in the > > 'release' output of my proof of concept -- there really isn't any > > practical difference between our approaches? > > > > > However, I still think it is better to consolidate than to offer too > much > > > to chose from (where it brings no benefit). And I'd still like to hear > > your > > > > I'd love to consolidate, and I'm reading your Wiki pages with interest > > on how to tackle some of the language inconsistencies between AS and > > JS. I just wish that we could work together on code, instead of going > > round and round on theory and relative merits of two different but > > equal approaches. > > > > > opinion on my warning that the input language for GCC is a dialect of > > > JavaScript (restrictions, extensions), not standard JavaScript. > > > > If by GCC you are referring to the compiler, [1] should answer your > > question. The Google Tools (which include, but are not limited to, the > > compiler) like to have their JavaScript in a 'pseudo-classical' > > pattern, but that doesn't mean they won't gladly handle other > > patterns, like "AMD". The JSDoc annotations are only there to help the > > GCC do an even better job, but are not required for the code to > > function as coded. What about the "input language for GCC" do you > > regard as a dialect of "vanilla JS"? > > > > EdB > > > > 1: https://developers.google.com/closure/compiler/faq#restrictions > > > > > > > > -- > > Ix Multimedia Software > > > > Jan Luykenstraat 27 > > 3521 VB Utrecht > > > > T. 06-51952295 > > I. www.ixsoftware.nl > > >
