It works :) Thanks :)
Le 2017-05-10 14:22, Denis Kudriashov a écrit : > 2017-05-10 13:49 GMT+02:00 Steven Costiou <[email protected]>: > >> Then i do openPlayground and TestClass new inspect -> i got an inspector on >> the proxy object. If i do "self test inspect" inside it, i got the same >> debugger opening, telling me the error but with the "proxy stack" and not >> the test method where the problem is. Basically it seems that everything i >> try to remotely execute from the local image falls into this case. I did not >> try to start a process when starting the remote image so maybe this works. >> My question is, is there a way to remotely execute (user) code that will >> open the debugger on the "right" stack ? (or did i do something wrong ?) > > Currently to get real debugger from playground script you need evaluate fork > over expression. For example following code in remote playground: > >> [1/0] fork > > it will open debugger on remote process. But if you just execute "1/0" then > you will got local debugger with "RemoteException~" title without remote > stack. > > It works like that because remote request itself handles failures and > transfers them as result back to local image. It is suitable strategy for > many cases and it is most simple and safe to implement. But now there is no > way how to setup another strategy to open remote debugger. > So to escape internal communication handler you need fork evaluated > expression. When remote image produces unhandled error it will spawn debugger > which will be connected remote debugger in our case. That's why #fork is > needed: to ensure unhandled failures. > > I not hide this specifics inside remote playground because during debugging > of all this remote tools it is suitable to just see communication failure > instead of remote debugger. When remote debugger is opening it also > communicates with remote side and if communication logic is broken it leads > to infinite recursion and frozen image. > In future I will make this behaviour natural (like in local playground) but > right now my scenario is: > - evaluate desired code in playground. > - if It fails ( RemoteException with description of actual failure) then wrap > it with fork and got remote debugger.
