> Why to put some BP in on the suspended ones ? I meant : Why to put some BP only in the suspended ones ?
Also, the compiled FDB attached to the fixed issue is more up to date than the last one I sent you, I re-applied the mxml BP fix on it. Frédéric THOMAS > From: webdoubl...@hotmail.com > To: dev@flex.apache.org > Subject: RE: [FDB] Integration > Date: Wed, 30 Apr 2014 14:21:45 +0100 > > > > I created 2 tickets [1] for the merge, [2] for the fix, I > attached it the fixed FDB. Main thread with the target file is not > paused > > Switching workers when VM is paused after new worker creation seems to > > work now, that' great! > > Setting a breakpoint to the file that is not loaded yet and will be > > loaded later by a new worker also seems to work, that's even more cool! > > Yep :-) > > > I still see the issue with setting a breakpoint in incorrect file when > > all workers are loaded but the file belongs to non active one. See [1] > > > Next steps: > > > 1- Fix the bad message when a file is not found > > What do you mean? > > It seems I meant just what you said: > > I still see the issue with setting a breakpoint in incorrect file when > > all workers are loaded but the file belongs to non active one. See [1] > > But I reduced my sentence to the message: > > Breakpoint 1: file MP3Worker.as, line 30 // WRONG FILE > > > > BTW IntelliJ uses only breakpoints, no watches and displays. > > I will still need to apply the same logic to each potential command that > could have the same issue. > > > - 'break' command may be called with file name or with file id. If it is > > called with file id then probably the right thing is to apply the > > command to the current worker only > > Good point, I keep that ! > > > - the same file may belong to several workers. So probably fdb should > > iterate all suspended workers and try to set the breakpoint for all that > > contain this file. > > I would have suspended all workers instead and place a BP in each if it > belongs to. > Why to put some BP in on the suspended ones ? > > > - new workers that contain this file may appear later. And each existing > > worker that doesn't contain the file may get new bytecode loaded with > > this file. So despite of the result of the previous attempts fdb should > > remember the breakpoint location and try to set it for all new workers > > that appear later. Also each time when new code is loaded fdb should try > > to set breakpoint again for each existing worker that didn't contain the > > file before. > > Yep, was my goal too. > > Frédéric THOMAS > > > Date: Wed, 30 Apr 2014 15:37:38 +0400 > > From: alexander.doros...@jetbrains.com > > To: dev@flex.apache.org > > Subject: Re: [FDB] Integration > > > > On 30.04.2014 14:14, Frédéric THOMAS wrote: > > > I created 2 tickets [1] for the merge, [2] for the fix, I attached it the > > > fixed FDB. Main thread with the target file is not paused > > Switching workers when VM is paused after new worker creation seems to > > work now, that' great! > > Setting a breakpoint to the file that is not loaded yet and will be > > loaded later by a new worker also seems to work, that's even more cool! > > I still see the issue with setting a breakpoint in incorrect file when > > all workers are loaded but the file belongs to non active one. See [1] > > > Next steps: > > > 1- Fix the bad message when a file is not found > > What do you mean? > > > 2- New feature: Automaticaly set back the breakpoints, watches and > > > displays when another instance of the worker is created and the "-ide" > > > argument is passed to FDB > > The feature needs to be thoroughly thought over. There are too many > > cases to keep in mind: > > - 'break' command may be called with file name or with file id. If it is > > called with file id then probably the right thing is to apply the > > command to the current worker only > > - if 'break' command is followed by the file name then still there are a > > lot of cases: > > - definitely fdb should try to find this file in the current worker and > > set breakpoint if found > > - the same file may belong to several workers. So probably fdb should > > iterate all suspended workers and try to set the breakpoint for all that > > contain this file. > > - new workers that contain this file may appear later. And each existing > > worker that doesn't contain the file may get new bytecode loaded with > > this file. So despite of the result of the previous attempts fdb should > > remember the breakpoint location and try to set it for all new workers > > that appear later. Also each time when new code is loaded fdb should try > > to set breakpoint again for each existing worker that didn't contain the > > file before. > > > > BTW IntelliJ uses only breakpoints, no watches and displays. > > > > > 3- In the Falcon repo, merge FDB with its classes using the Falcon AST > > > > > > Any comments are welcome. > > > > > > Frédéric THOMAS > > > > > > [1] https://issues.apache.org/jira/browse/FLEX-34291 > > > [2] https://issues.apache.org/jira/browse/FLEX-34292 > > [1] > > Apache fdb (Flash Player Debugger) [build 20140430] > > Copyright 2013 The Apache Software Foundation. All rights reserved. > > (fdb) run > > Waiting for Player to connect > > Player connected; session starting. > > Set breakpoints and then type 'continue' to resume the session. > > (fdb) c > > [SWF] C:\work\flex_projects\MP3Worker\bin-debug\MP3Worker.swf - 175а169 > > bytes after decompression > > [WorkerCreate] 1 > > Additional ActionScript code has been loaded from a SWF or a frame. > > To see all currently loaded files, type 'info files'. > > Active worker has changed to worker 1 > > > > Set additional breakpoints as desired, and then type 'continue'. > > (fdb) c > > [SWF] C:\work\flex_projects\MP3Worker\bin-debug\MP3Worker.swf - 493а264 > > bytes after decompression > > halt > > Do you want to attempt to halt execution? (y or n) y > > Attempting to halt. > > To help out, try nudging the Player (e.g. press a button) > > Execution halted at 0x00009aeb (39659) > > (fdb) worker 0 > > Active worker has changed to worker Main Thread > > (fdb) halt > > Attempting to suspend Player execution... > > Player stopped > > (fdb) info workers > > Main Thread 0 - Suspended (Active) > > Worker 1 - Suspended > > (fdb) break BackWorker.as:30 > > Breakpoint 1: file MP3Worker.as, line 30 // WRONG FILE > > >
