Alain, In my view all development, including debugging, is done in AS. The JS output, like bytecode, should "just work".
EdB 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 >> -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
