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.cost...@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.