> > AIR users will still have to use the DebuggableWorker class as base
> > class for their workers and the main app as well though.
> I'm not sure we can convince all developers to rewrite their workers,
> but I hope no fatal error happens if fdb fails to suspend worker.
FDB not being able to halt the player, won't IntelliJ hang up in that case ?
> - I have to suspend at least one worker to be able to send 'break'
> command. Fdb suspends/sets breakpoint/resumes other workers if needed,
> at the end all workers are in the same state as before break command
> - the same about 'delete' command.
Correct.
Note: For the "delete" command, you can now delete unresolved BP, that wasn't
the case before.
> - when breakpoint is hit, only one worker is paused.
Not correct, look at the debugTickler() at DebuggableWorker.as:56, if I set a
BP there and somewhere else in another worker and this last one is hited first,
it doesn't mean that the first one won't be hited in between, 2 workers can
then be in suspend mode because I received 2 break events even though FDB will
process them one at time.
> I have one more request for the IDE integration. Using part of file name
> in 'break' command is dangerous, more than one file may match. Even
> using full file name is not strict enough: we have a lot of users who
> had the same-named files in different packages. Currently IntelliJ IDEA
> tries to use file id instead of file name whenever possible, but with
> your fixes I start thinking about a different approach. Will it be easy
> to support relative path in 'break' command syntax? In this case I'll be
> sending path relative to src root, e.g. 'break
> flash/display/Sprite.as:99'? Implementation should normalize slashes in
> known file paths as I'd like to always pass '/' whereas paths returned
> by Flash Player may contain '\'.
Ok, implemented, will commit today, you can now do:
break mx\core\DebuggableWorker.as:56
or
break mx/core/DebuggableWorker.as:56
> > I just wonder, is it easily doable to modify the Breakpoint UI like
> > what is done for Java and adding a combobox to access threads on top
> > of the Frame list ?
> Shouldn't be extremely hard.
Can't wait to see that :-)
Thanks,
Frédéric THOMAS
> Date: Wed, 28 May 2014 22:19:10 +0400
> From: alexander.doros...@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: [FDB] Integration
>
> On 28.05.2014 16:06, Frédéric THOMAS wrote:
> > AIR users will still have to use the DebuggableWorker class as base
> > class for their workers and the main app as well though.
> I'm not sure we can convince all developers to rewrite their workers,
> but I hope no fatal error happens if fdb fails to suspend worker.
> > I had no problems using it with IntelliJ, waiting for more tests /
> > feedback from you though :-)
> It really seems to work! Please check if I get all correctly:
> - I have to suspend at least one worker to be able to send 'break'
> command. Fdb suspends/sets breakpoint/resumes other workers if needed,
> at the end all workers are in the same state as before break command
> - the same about 'delete' command.
> - when breakpoint is hit, only one worker is paused.
>
> I have one more request for the IDE integration. Using part of file name
> in 'break' command is dangerous, more than one file may match. Even
> using full file name is not strict enough: we have a lot of users who
> had the same-named files in different packages. Currently IntelliJ IDEA
> tries to use file id instead of file name whenever possible, but with
> your fixes I start thinking about a different approach. Will it be easy
> to support relative path in 'break' command syntax? In this case I'll be
> sending path relative to src root, e.g. 'break
> flash/display/Sprite.as:99'? Implementation should normalize slashes in
> known file paths as I'd like to always pass '/' whereas paths returned
> by Flash Player may contain '\'.
> > I just wonder, is it easily doable to modify the Breakpoint UI like
> > what is done for Java and adding a combobox to access threads on top
> > of the Frame list ?
> Shouldn't be extremely hard.
>
> Alex
