2017-05-10 13:49 GMT+02:00 Steven Costiou <steven.cost...@kloum.io>: > 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.
