> Trying to open any file
> triggers event at worker side and it halts. By the way that's a problem
> as well for the IDE integration: to set breakpoint it needs to suspend
> VM which is not possible if no events are fired. I'm not sure you can do
> anything with it at fdb side. But I think you can fix fdb so that it
> doesn't set breakpoint in the file where it was not asked to.
I've seen in the code where the problem comes from but not sure yet how to fix
it without to break something, the best is to raise a JIRA like that I can be
back on it after the initial commit.
> The best would be to check all workers suspended at the moment and set
> breakpoints for each of them that contains this file.
> If none found then the same message as for unresolved breakpoint is
> probably ok.
Will check that as well.
Thanks for pointing that out !
Frédéric THOMAS
> Date: Tue, 29 Apr 2014 20:53:28 +0400
> From: alexander.doros...@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: [FDB] Integration
>
> On 29.04.2014 20:23, Alex Harui wrote:
> > IMO, unless the discussion is going to cover proprietary aspects of
> > IntelliJ, it might be more like the "Apache Way" to share the code in a
> > git branch and continue to discuss on the list.
> No secrets of course. Ok, continuing here.
>
>
> Frédéric THOMAS wrote:
>
> > Also line 26 of BackWorker.as, there's no code, when I have the worker
> > 1 selected and break at this line it tells that to me, which is true
> > and if I do a *BackWorker.as:27 *it breaks.
> Yes, if the file is there for the current active worker which is
> suspended, then it works. Too many ifs. The real problem is setting
> breakpoints BEFORE the code is loaded. Fdb says that breakpoint is not
> yet resolved and it may be resolved later to the incorrect file or not
> resolved at all. Example for the latter case (the same command failed
> for the first time and succeeded the second time):
>
> Adobe fdb (Flash Player Debugger) [build 20140426]
> Copyright (c) 2004-2007 Adobe, Inc. 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) break BackWorker.as:27
> [SWF] C:\work\flex_projects\MP3Worker\bin-debug\MP3Worker.swf - 175?169
> bytes after decompression
> Breakpoint 1 created, but not yet resolved.
> The breakpoint will be resolved when the corresponding file or function
> is loaded.
> (fdb) c
> [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
>
> Attempting to resolve breakpoint 1, expression "BackWorker.as:27":
> There is no executable code on the specified line.
> Fix or remove bad breakpoints, then type 'continue'.
> (fdb) break BackWorker.as:27
> [SWF] C:\work\flex_projects\MP3Worker\bin-debug\MP3Worker.swf - 493?264
> bytes after decompression
> Breakpoint 2: file BackWorker.as, line 27
> Set additional breakpoints as desired, and then type 'continue'.
> (fdb)
>
> >
> > Bug 1: reproduced. (will check what I can do)
> >
> > Bug 2: Can't halt the player execution, it tells me to click a button,
> > what I do but failed to halt it, anyway, I think it is the way it
> > works at the end, I mean each command is sent to a particular worker
> > session, so, inside the same worker session it hasn't access to the
> > others, also the reason why in each instance of the worker we need to
> > set back the BP, watches and displays.
> >
> > What I can try to do instead is to display a message that the file has
> > not been found.
> To halt worker some event must be triggered there. Pressing a button
> won't help as UI belongs to the main thread. Trying to open any file
> triggers event at worker side and it halts. By the way that's a problem
> as well for the IDE integration: to set breakpoint it needs to suspend
> VM which is not possible if no events are fired. I'm not sure you can do
> anything with it at fdb side. But I think you can fix fdb so that it
> doesn't set breakpoint in the file where it was not asked to.
> The best would be to check all workers suspended at the moment and set
> breakpoints for each of them that contains this file.
> If none found then the same message as for unresolved breakpoint is
> probably ok.
>
> >
> > Any thoughts ?
> >
> > Frédéric THOMAS
> >
> > ------------------------------------------------------------------------
> > Date: Tue, 29 Apr 2014 19:48:39 +0400
> > From: alexander.doros...@jetbrains.com
> > To: webdoubl...@hotmail.com
> > Subject: Re: [FDB] Integration
> >
> > All bugs are there unfortunately.
> > Note that you do not need to download anything else except
> > moreworkers.zip and do not need to setup the project in the IDE. Zip
> > already contains compiled MP3Worker.swf that you start after typing
> > 'run' in fdb console.
> >
> > Here's the listing showing both bugs (see comments). Hint: to have
> > user readable text instead of placeholders like !workerChanged! you
> > need to copy flex/tools/debugger/cli/fdb_*.properties files from
> > fdb.jar from the AIR SDK into your fdb.jar.
> >
> > Apache fdb (Flash Player Debugger) [build 20140426]
> > Copyright 2014 The Apache Software Foundation.
> > (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
> > !linePrefixWhenWorkerCreated! 1
> > Additional ActionScript code has been loaded from a SWF or a frame.
> > To see all currently loaded files, type 'info files'.
> > !workerChanged! 1
> >
> > Set additional breakpoints as desired, and then type 'continue'.
> > (fdb) info workers
> > !mainThread! 0 - !workerRunning!
> > *!inWorker! {worker=1} - !workerSuspended! !workerSelected! // worker
> > 1 is active*
> > [SWF] C:\work\flex_projects\MP3Worker\bin-debug\MP3Worker.swf -
> > 493?264 bytes after decompression
> > Set additional breakpoints as desired, and then type 'continue'.
> > (fdb) worker 0
> > *!workerChanged! !mainThread! // fdb says that active worker is now
> > mainThread*
> > Set additional breakpoints as desired, and then type 'continue'.
> > (fdb) info workers
> > !mainThread! 0 - !workerRunning!
> > *!inWorker! {worker=1} - !workerSuspended! !workerSelected!**// but in
> > fact worker 1 remains active
> > *Set additional breakpoints as desired, and then type 'continue'.
> > (fdb) c
> > 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
> > !workerChanged! !mainThread!
> > (fdb) halt
> > Attempting to suspend Player execution...
> > Player stopped
> > (fdb) info workers
> > !mainThread! 0 - !workerSuspended! !workerSelected!
> > !inWorker! {worker=1} - !workerSuspended!
> > (fdb) show files
> > 1 /Users/leebrimelow/Documents/Adobe Flash Builder
> > 4.6/MP3Worker/src/MP3Worker.as, MP3Worker.as (!mainThread!)
> > 2 /Users/leebrimelow/Documents/Adobe Flash Builder
> > 4.6/MP3Worker/src/Workers.as, Workers.as (!mainThread!)
> > 1 /Users/leebrimelow/Documents/Adobe Flash Builder
> > 4.6/MP3Worker/src/BackWorker.as, BackWorker.as (!inWorker! {worker=1})
> > 2
> > /Users/kikko/work/tests/shineMP3_alchemy/src/fr/kikko/lab/ShineMP3Encoder.as,
> >
> > ShineMP3Encoder.as (!inWorker! {worker=1})
> > *(fdb) break BackWorker.as:26 // **there's no **BackWorker.as**file
> > for active worker (which is mainThread)
> > Breakpoint 1: file MP3Worker.as, line 26 // fdb sets the breakpoint
> > for a different file instead. I think because it also has id=1*
> > (fdb)
> >
> > On 29.04.2014 19:21, Frédéric THOMAS wrote:
> >
> > Hi Alexander,
> >
> > Attached here the fdb.jar, as you can see in the first message of
> > the thread, the output is not the same than the AIR fdb version,
> > also, keep in mind that on each instance of each worker you need
> > to set back the BP, watches and displays (once the worker is loaded).
> >
> > At the moment, I didn't take all the worker code from the
> > donation, the code used to evaluate expressions is still the same
> > than before, so, I'm not 100% sure my code works perfectly but
> > didn't find any bugs yet, the reason I did that is because the new
> > implementation is based on the Falcon AST tree and the build
> > script we have at the moment doesn't link it, I will work on this
> > script soon in order to be able to compile FDB with the new code
> > that evaluate the expressions.
> >
> > Please keep me in touch with your experiments as I'm very
> > interested and don't hesitate to raise bugs.
> >
> > Thanks,
> > Frédéric THOMAS
> >
> >
>
>
