Remote Debugger bugs ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Remote Debugger bugs ?

Steven Costiou-2

Hi,

i'm confused with how to configure the remote debugger. I used this link to configure my images: http://dionisiydk.blogspot.fr/2017/01/pharmide-pharo-remote-ide-to-develop.html

 

I evaluated "1/0" in a playground in the remote image, and the exception opens in my local image. Now if i clic "abandon", the local image is ok but the remote is frozen. If i clic "proceed", the local image is frozen and the remote is ok.

 

So using the remote browser from my local image, i created a test class with a test method that does "^'1', 0" and i execute it in the remote image. The debugger opens the local image and i can debug it "^'1', 0 printString", accept and proceed. The inspector opens with the return value in the remote image and the local image is frozen again.

 

The only solution i have is to kill the image. I used Windows 7 for these tests. Is there anything i missed besides the configurations steps in the link above ?

RemoteBrowser and RemotePlayground seem to work fine, except some problems with the contextual menus in the browser.

Reply | Threaded
Open this post in threaded view
|

Re: Remote Debugger bugs ?

Denis Kudriashov
Hi.

2017-05-09 17:22 GMT+02:00 Steven Costiou <[hidden email]>:

I evaluated "1/0" in a playground in the remote image, and the exception opens in my local image. Now if i clic "abandon", the local image is ok but the remote is frozen. If i clic "proceed", the local image is frozen and the remote is ok.

Could you try just close window instead of abandon. I will check later but I never use this button in my workflow. 

 

So using the remote browser from my local image, i created a test class with a test method that does "^'1', 0" and i execute it in the remote image. The debugger opens the local image and i can debug it "^'1', 0 printString", accept and proceed. The inspector opens with the return value in the remote image and the local image is frozen again.

Normally it should work. I will try your scenario.

What the platform for local and remote images? both 32bits?  And how bad is network connection?

Reply | Threaded
Open this post in threaded view
|

Re: Remote Debugger bugs ?

Steven Costiou-2

Hi Denis,

2017-05-09 17:22 GMT+02:00 Steven Costiou <[hidden email]>:

I evaluated "1/0" in a playground in the remote image, and the exception opens in my local image. Now if i clic "abandon", the local image is ok but the remote is frozen. If i clic "proceed", the local image is frozen and the remote is ok.

 

Could you try just close window instead of abandon. I will check later but I never use this button in my workflow. 
 
 
Same problem.
 
 
 

So using the remote browser from my local image, i created a test class with a test method that does "^'1', 0" and i execute it in the remote image. The debugger opens the local image and i can debug it "^'1', 0 printString", accept and proceed. The inspector opens with the return value in the remote image and the local image is frozen again.

Normally it should work. I will try your scenario.
 
What the platform for local and remote images? both 32bits?  And how bad is network connection?

I use two images on the same computer (so its on localhost), using windows 7 64 bits but the two images are 32bits (pharo 6 60483).

Steven.

Reply | Threaded
Open this post in threaded view
|

Re: Remote Debugger bugs ?

Denis Kudriashov
In reply to this post by Steven Costiou-2
2017-05-09 17:22 GMT+02:00 Steven Costiou <[hidden email]>:
I evaluated "1/0" in a playground in the remote image

I found the issue. Debugging remote UI process is not supported well. When you close debugger remote UI process is terminated which makes remote image unresponsive.
But it is not completely frozen. You can spawn new UI process remotely:
remotePharo evaluate: [ UIManager default spawnNewProcess  ]. 
Or from remote playground just evaluate it directly:
UIManager default spawnNewProcess 

I will think how to support it properly. 
I wondering do you just play or you have real requirements for this scenario? (I not thought it is important)

Best regards,
Denis
Reply | Threaded
Open this post in threaded view
|

Re: Remote Debugger bugs ?

Steven Costiou-2

 

I found the issue. Debugging remote UI process is not supported well. When you close debugger remote UI process is terminated which makes remote image unresponsive.
But it is not completely frozen. You can spawn new UI process remotely:
remotePharo evaluate: [ UIManager default spawnNewProcess  ]. 
Or from remote playground just evaluate it directly:
UIManager default spawnNewProcess 
 
 
Thanks, it works :)
 
 
 
I will think how to support it properly. 
I wondering do you just play or you have real requirements for this scenario? (I not thought it is important)
 
No i am playing with it while configuring my images. It's easier to test things on both images with the uis when doing that. In the end i will embed the remote image in a raspberry pi and access it remotely, so the ui will (absolutely) not be needed. However, it is conceivable to have a desktop app that i want to connect to for example if a remote user experiences problems and i want to query things or to ask the user to perform operations.
If i do such queries i can make mistakes and i would have to proceed/abandon/close debug windows. In this case both will need a ui.
Reply | Threaded
Open this post in threaded view
|

Re: Remote Debugger bugs ?

Denis Kudriashov

2017-05-10 11:16 GMT+02:00 Steven Costiou <[hidden email]>:
In the end i will embed the remote image in a raspberry pi and access it remotely, so the ui will (absolutely) not be needed

I am currently working on RPI support. I will present it next week.
If you want to try:
Metacello new
        smalltalkhubUser: 'Pharo' project: 'IoT';
        configuration: 'IoT';
        version: #stable;
        load: 'RemoteToolsServer'.
Then from playground evaluate:
lib := remotePharo evaluate: [ WiringPiLibrary uniqueInstance].
board := RpiBoardBRev1 driver: (RpiWiringPiDriver lib: lib).
board inspect
It requires wiringPi external library which I think should be installed by default.
Anyway I will publish it next week with more details and demos.