Hi Josh, thanks for be so fast looking and solving this! :) your fix solve the problem I exposed in ButtonPlayGround and also was affecting to the code and that was fixed too! :)
I'm going to try other spots in our real app to see if that fixes that too and report it. Thanks again! :) Carlos El mié., 6 feb. 2019 a las 22:43, Josh Tynjala (<[email protected]>) escribió: > I tracked it down to royale-compiler commit > 7bfa137ff19adae3d9d874638dbd047d6f264dda in December 2018. In > GoogDepsWriter, a new call to finalLines.add() was added without a matching > call to addLineToSourceMap(). The source maps for ButtonPlayGround.js were > offset by several lines as a result. > > GoogDepsWriter is where we handle remove-circulars. It's a interesting > part of the compiler because it modifies the .js and .js.map files after > they've been written to the file system already. That makes GoogDepsWriter > somewhat difficult to test in my opinion. I'm not sure if there's a good > way to write tests for it to ensure that we don't have regressions like > this in the future. If we're lucky, we won't have to change > remove-circulars much anymore. If not, then special care should be taken in > GoogDepsWriter to ensure that both the js files and their source maps are > modified. > > By the way, I recommend this tool as a way to visualize source maps to > ensure that the lines match up: > > https://sokra.github.io/source-map-visualization/ > > As soon as I visualized the ButtonPlayGround files, I could see that the > source maps were not aligned to the correct lines. That's a good indication > that remove-circulars was involved, and it wasn't related to any changes to > the JS emitters. > > - Josh > > On 2019/02/06 20:33:46, Josh Tynjala <[email protected]> wrote: > > I'll take a look! Assuming that source maps broke in an emitter, I can > easily add more tests to help us avoid future regressions. > > > > - Josh > > > > > > On 2019/02/06 19:33:26, Carlos Rovira <[email protected]> wrote: > > > Hi > > > > > > I have an issue with yesterday changes that are causing some > regressions in > > > debugger, but don't know what could be the problem. > > > > > > Taking tour de Jewel : > > > > > > I put a break point in ButtonPlayGround.mxml line 29: > > > > > > private function clickHandler(event:MouseEvent):void { > > > button.emphasis = (button.emphasis == Button.PRIMARY) ? "" : > Button.PRIMARY; > > > <-- break point here > > > } > > > > > > (very simple right? ;)) > > > > > > > > > but...break point appears when Tour de Jewel is launched and stops in > > > ButtonPlayGround.js... that's no right ok? > > > > > > This is a regression, since that was not happening before. > > > > > > I assume that is caused for changes in compiler, but can ensure what > > > changes and when happened. > > > > > > I'd like to ask for some caution when doing changes in compiler, since > we > > > had a debugger working in a decent % of cases, maybe 90-95% of the > code I > > > test was working. I invested money to make it work for all, to use in > my > > > project and to help the community. But seems some changes are making > > > debugger be working less and less each time. I see the same problem in > some > > > parts of my own code that before was not happening. I was thinking in > > > invest more money in other things in Royale, but is hard to me to > explain > > > in my team this when things where we invested about 1-2 months ago > seems to > > > be now breaking. > > > > > > We all now Apache Royale is evolving each day, but I think changing > > > compiler should be do with changing debugger rules to avoid more > breaks of > > > things that was already working. > > > > > > So please, take into account that changes done should be done with > > > debugging capabilities in mind, or we'll always breaking debugger. > > > > > > Hope this make sense to all of you > > > > > > Thanks in advance > > > > > > > > > > > > -- > > > Carlos Rovira > > > http://about.me/carlosrovira > > > > > > -- Carlos Rovira http://about.me/carlosrovira
