Working with remote debugger: how to debug something happening in the remote image ?
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.
Le 2017-05-10 11:28, Steven Costiou a écrit :
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.
Hem, i forgot to say that i did that in a remote browser after sending openBrowser to a PRRemotePharo
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.
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.
2017-05-10 13:49 GMT+02:00 Steven Costiou <steven.costiou@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.
It works :) Thanks :) Le 2017-05-10 14:22, Denis Kudriashov a écrit :
2017-05-10 13:49 GMT+02:00 Steven Costiou <steven.costiou@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.
2017-05-10 11:28 GMT+02:00 Steven Costiou <steven.costiou@kloum.io>:
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...)
If you want to fight with it then my first idea would be to find how method AST is built in sugs menu. Then try to look at senders of #astForStylingInCalypso which was implemented to support styling of remote methods. Try to use it somehow for sugs menu too. Maybe it will fix everything
If you want to fight with it then my first idea would be to find how method AST is built in sugs menu. Then try to look at senders of #astForStylingInCalypso which was implemented to support styling of remote methods. Try to use it somehow for sugs menu too. Maybe it will fix everything
Yes, i will have a look - i need the right click menu to properly work so i need that to be fixed. The workaround i used was to just disable suggestions by returning empty suggs collections, but i will see if i can do something better. Thanks Denis.
participants (2)
-
Denis Kudriashov -
Steven Costiou