You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2019/02/06 19:33:26 UTC
Debugger regression
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
Re: Debugger regression
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Are you debugging js-debug or js-release?
On 2/6/19, 11:33 AM, "Carlos Rovira" <ca...@apache.org> 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
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C507054f63ae442d790f208d68c6a0092%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636850784263050163&sdata=fNThclAdG0YrfOmXkq%2FuzFhCi8yKaHypf24RFEAi8DU%3D&reserved=0
Re: Debugger regression
Posted by Carlos Rovira <ca...@apache.org>.
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 (<jo...@apache.org>)
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 <jo...@apache.org> 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 <ca...@apache.org> 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
Re: Debugger regression
Posted by Josh Tynjala <jo...@apache.org>.
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 <jo...@apache.org> 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 <ca...@apache.org> 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
> >
>
Re: Debugger regression
Posted by Josh Tynjala <jo...@apache.org>.
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 <ca...@apache.org> 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
>