Ok, so there is this problem. I just wanted to try the debugger on it. But i have the same problem with my own user code. For example i did open a remote browser, create a test package with a class TestClass and a method test>>^'1', 0. 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 ?) Le 2017-05-10 13:21, Denis Kudriashov a écrit :
Problem that right now many thinks in browser are not supported in remote scenario: most of refactorings are not work and as you see suggestion menu not works too.
It is local tools problem, the way how local tools communicate with remote environment to perform particular operations. When you try debug such operations local debugger stops at the place of remote request. Distributed debugger (which shows multiple process stacks) is not done. But it will not help here.
Generally there are many cases when transparent remoting is not working. And to fix concrete scenario proper model is needed which is taken into account that it can be distributed across network borders. In this case suggestion menu operates with local AST-nodes of remote method which is required non trivial logic to be handled properly.
Anyway these features will be supported in future..
2017-05-10 11:28 GMT+02:00 Steven Costiou <steven.costiou@kloum.io>:
While configuring my local and remote images to work with the remote debugger, there was a bug with the menu in the remote browser. So i wanted to try the debugger and figure out what was the problem using it, but i do not understand how to proceed. When the debugger opens, all i see is the fact that there was a remote problem, and that the proxy was unable to return a proper value.
I used a local image connected with a headless remote image. To reproduce the bug, go for example in ByteString >> at:put:, right click after the first dot and click "debug". See suggs-menu-bug.png.
When doing that i get debug-win.png and suggs-debug.png and as you can see i just know there was an error and what it was but i don't have an open debugger as i would normally expect in Pharo. How can i see the real problem occuring in the remote image ? How can i remotely fix this considering that my remote image is headless and it seems to be a problem tied to the remote thing, because locally it doesn't happen ? (or maybe it is a Calypso problem but anyway i cannot debug it...)
Steven.