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.

  

Reply via email to