Thank's to all :). 2017-01-24 14:29 GMT+01:00 Ben Coman <btc@openinworld.com>:

Amazing stuff Denis. It will be very interesting over time to hear of how people's workflows adapt to use this.

I am going to work such way. I will develop completely from remote IDE. Mostly it will be experiment to discover possible problems. But at the end it will lead to real live remote programming. So we will be able to develop RPi, Beaglebone, Android/IOS devices in natural Pharo way. You could imaging difference to XCode or Eclipse.

One thought while I was watching the video, it might be useful if the remote images were named somehow, which could appear in the title bar of the remote tools in addition to IPaddress/DNSname:port. I can imagine having several images of different purposes running on one remote host and having multiple open from the one client and needing to keep track better. So for example @4:37, instead of the inspector showing "SeamlessProxy(42)" it would show "MyRemoteImage(42)"

Problem that now I not completely hook into inspector and debugger. So it is shown with such strange names but it points to non local nature without any effort. In future it will be handled better of course

That is really cool news! I think it is not so clear for everyone that the greatest achievement is foremost the communication model. Cheers, Doru

On Jan 24, 2017, at 4:26 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:

With Denis we tried to run PharmIDE on the minimal Pharo as the server. The debugger is still not usable but with some patches we can get nicely working browser, playground and inspector, see the attached screenshot.

Cheers, -- Pavel

2017-01-24 13:52 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>: Hi.

I am glad announce first version of PharmIDE project which is complete toolset for remote development of Pharo images. It includes: • remote debugger • remote inspector • remote playground • remote browser Old project RemoteDebuggingTools is deprecated. But it could be used for Pharo 5 images. PharmIDE targets Pharo 6 or later and provides everything which was done in original project.

For details and live demo look at my blog http://dionisiydk.blogspot.fr/2017/01/pharmide-pharo-remote-ide-to-develop.h....

Best regards, Denis

<PharoScreenshot.png>

-- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

On 24 Jan 2017, at 16:34, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Impressive!

Indeed ! Great work, Denis.

2017-01-24 13:52 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>: Hi.

I am glad announce first version of PharmIDE project which is complete toolset for remote development of Pharo images. It includes: • remote debugger • remote inspector • remote playground • remote browser Old project RemoteDebuggingTools is deprecated. But it could be used for Pharo 5 images. PharmIDE targets Pharo 6 or later and provides everything which was done in original project.

For details and live demo look at my blog http://dionisiydk.blogspot.fr/2017/01/pharmide-pharo-remote-ide-to-develop.h....

Best regards, Denis

NorbertHartl wrote

Binding the socket to localhost and enable things like VPN or ssh tunneling is not to difficult to do and gives proper protection

Thanks! That sounds vaguely familiar... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Ann-PharmIDE-Pharo-remote-IDE-to-develop-farm-of-Pharo... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisiydk@gmail.com>:

Hi Sean.

2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>: Have you considered security at all yet? Leaving a port open which allows arbitrary code to be executed reomotely seems very dangerous...

Norbert already answer you. I just put little summary. Currently there is two important issues which must be handled manually: - security. You can manage it by VPN or SSH - distributed garbage collection. You need perform "remotePharo disconnect" (or "PrmRemotePharo disconnectAll") at the end of your working session. It cleans server and client from distributed objects.

Last issue is at high priority in my todo. When I implement it unused distributed objects will be collected automatically like local ones. Security option can be added too. Seamless design allows to it. Probably It can be simple switch to SecureSocketStream instead of SocketStream.

My advize for security is two-fold. The first reason not to apply security features to seamless is that it complicates the code base with a feature that is done better elsewhere. The second reason is that one big reason why this can be unusable is latency. A high latency makes it very hard to use the toolkit. So removing everything adding latency should be avoided. Security is from the image perspective one of those things. thanks again for doing that. Norbert

Important thing here that I am really satisfied with Seamless design which I made. It was driven by tests which means that it only addresses existing features but allow stable evolution to new functionality. And I thing it is most important property of any system: provide stable way how to evolve. System can be broken and very buggy at some point but if design and tests are stable then system will move. By stable I mean "do not require big changes for any new bug or feature", "always iterative process". Just want to share these thoughts with you :).

2017-01-30 11:49 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

...

On 30 Jan 2017, at 11:43, Norbert Hartl <norbert@hartl.name> wrote:

...

Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisiydk@gmail.com>:

Hi Sean.

2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>: Have you considered security at all yet? Leaving a port open which

allows

...

arbitrary code to be executed reomotely seems very dangerous...

Norbert already answer you. I just put little summary. Currently there is two important issues which must be handled manually: - security. You can manage it by VPN or SSH - distributed garbage collection. You need perform "remotePharo disconnect" (or "PrmRemotePharo disconnectAll") at the end of your working session. It cleans server and client from distributed objects.

Last issue is at high priority in my todo. When I implement it unused distributed objects will be collected automatically like local ones. Security option can be added too. Seamless design allows to it. Probably It can be simple switch to SecureSocketStream instead of SocketStream.

My advize for security is two-fold. The first reason not to apply security features to seamless is that it complicates the code base with a feature that is done better elsewhere. The second reason is that one big reason why this can be unusable is latency. A high latency makes it very hard to use the toolkit. So removing everything adding latency should be avoided. Security is from the image perspective one of those things.

Explicit/manual SSH port forwarding is easy & safe. Doing it deliberately makes you more aware of what you are doing, which is very necessary in this case because of the huge danger involved (giving away full image control). But it will add its own latency (just like TLS would).

Yes, I agree with you. That's why it is not in priority. But generally I think It would be nice option

2017-01-30 13:14 GMT+01:00 Norbert Hartl <norbert@hartl.name>:

Unfortunately I couldn't test it because I installed the PharmIDE on my linux machine and it does not work. When starting the image a listening port is opened but 5 seconds later the port closes automatically. Has anyone tested it on a linux machine?

I am working on it. It happens when server starts from command line. Probably I do something wrong in my TCPServer implementation. Zinc server works fine. So I have example where there is no problems.

How can we start PharmIDE server so that it binds to localhost only on the server? Phil On Mon, Jan 30, 2017 at 1:14 PM, Norbert Hartl <norbert@hartl.name> wrote:

Am 30.01.2017 um 11:49 schrieb Sven Van Caekenberghe <sven@stfx.eu>:

On 30 Jan 2017, at 11:43, Norbert Hartl <norbert@hartl.name> wrote:

Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisiydk@gmail.com>:

Hi Sean.

2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>: Have you considered security at all yet? Leaving a port open which allows arbitrary code to be executed reomotely seems very dangerous...

Norbert already answer you. I just put little summary. Currently there is two important issues which must be handled manually: - security. You can manage it by VPN or SSH - distributed garbage collection. You need perform "remotePharo disconnect" (or "PrmRemotePharo disconnectAll") at the end of your working session. It cleans server and client from distributed objects.

Last issue is at high priority in my todo. When I implement it unused distributed objects will be collected automatically like local ones. Security option can be added too. Seamless design allows to it. Probably It can be simple switch to SecureSocketStream instead of SocketStream.

My advize for security is two-fold. The first reason not to apply security features to seamless is that it complicates the code base with a feature that is done better elsewhere. The second reason is that one big reason why this can be unusable is latency. A high latency makes it very hard to use the toolkit. So removing everything adding latency should be avoided. Security is from the image perspective one of those things.

Explicit/manual SSH port forwarding is easy & safe. Doing it deliberately makes you more aware of what you are doing, which is very necessary in this case because of the huge danger involved (giving away full image control). But it will add its own latency (just like TLS would).

Right. To make it a bit more concrete. If we use the example of Denis on port 40423 then a simple

$ ssh -L 40423:localhost:40423 pharmide-server.anydomain.com

will open a forwarding tunnel so you can connect with the PharmIDE client using

PrmRemoteIDE connectTo: (TCPAddress ip: #[127 0 0 1] port: 40423)

and you'll end up connecting to your remote image.

Unfortunately I couldn't test it because I installed the PharmIDE on my linux machine and it does not work. When starting the image a listening port is opened but 5 seconds later the port closes automatically. Has anyone tested it on a linux machine?

Norbert

thanks again for doing that.

Norbert

Important thing here that I am really satisfied with Seamless design which I made. It was driven by tests which means that it only addresses existing features but allow stable evolution to new functionality. And I thing it is most important property of any system: provide stable way how to evolve. System can be broken and very buggy at some point but if design and tests are stable then system will move. By stable I mean "do not require big changes for any new bug or feature", "always iterative process". Just want to share these thoughts with you :).

On 30 Jan 2017, at 15:39, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2017-01-30 14:16 GMT+01:00 phil@highoctane.be <phil@highoctane.be>: How can we start PharmIDE server so that it binds to localhost only on the server?

I do not know if it is possible from Pharo. Anybody know example with "Socket newTCP"? With "external OS tools" you can always hide port from outside world. Try to google it.

It is in your image already ! See ZnServer>>#bindingAddress: and ZnSingleThrededServer>>#initializeServerSocket In use in ZnServerTests>>#testEchoLocalInterface You will understand immediately, it is quite easy. Remember that once you start like that, you will only be able to connect locally.

Am 30.01.2017 um 13:14 schrieb Norbert Hartl <norbert@hartl.name>:

...

Am 30.01.2017 um 11:49 schrieb Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>>:

...

On 30 Jan 2017, at 11:43, Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:

...

Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>>:

Hi Sean.

2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>: Have you considered security at all yet? Leaving a port open which allows arbitrary code to be executed reomotely seems very dangerous...

Norbert already answer you. I just put little summary. Currently there is two important issues which must be handled manually: - security. You can manage it by VPN or SSH - distributed garbage collection. You need perform "remotePharo disconnect" (or "PrmRemotePharo disconnectAll") at the end of your working session. It cleans server and client from distributed objects.

Last issue is at high priority in my todo. When I implement it unused distributed objects will be collected automatically like local ones. Security option can be added too. Seamless design allows to it. Probably It can be simple switch to SecureSocketStream instead of SocketStream.

My advize for security is two-fold. The first reason not to apply security features to seamless is that it complicates the code base with a feature that is done better elsewhere. The second reason is that one big reason why this can be unusable is latency. A high latency makes it very hard to use the toolkit. So removing everything adding latency should be avoided. Security is from the image perspective one of those things.

Explicit/manual SSH port forwarding is easy & safe. Doing it deliberately makes you more aware of what you are doing, which is very necessary in this case because of the huge danger involved (giving away full image control). But it will add its own latency (just like TLS would).

Right. To make it a bit more concrete. If we use the example of Denis on port 40423 then a simple

$ ssh -L 40423:localhost:40423 pharmide-server.anydomain.com <http://pharmide-server.anydomain.com/>

will open a forwarding tunnel so you can connect with the PharmIDE client using

PrmRemoteIDE connectTo: (TCPAddress ip: #[127 0 0 1] port: 40423)

and you'll end up connecting to your remote image.

Unfortunately I couldn't test it because I installed the PharmIDE on my linux machine and it does not work. When starting the image a listening port is opened but 5 seconds later the port closes automatically. Has anyone tested it on a linux machine?

As a followup I need to say that it works now and it works like a charm. I installed one PharmIDE image on my server and did the SSL tunneling. Latency was very good or to say it was only that high that you can notice working on a remote image. I did only small tests but everything was working as expected. I think in the future we need to work out how we can inspect a remote object while using GT features. A lot of stuff in GT inspector is pretty useful. But then I assume it is really chatty at the same time making the remote usage less useful. Great job!!! A dream comes true. If there is a working UFFI for ARM then we have a pretty decent stack for IoT times. Bravo! Norbert

Norbert

...

...

thanks again for doing that.

Norbert

...

Important thing here that I am really satisfied with Seamless design which I made. It was driven by tests which means that it only addresses existing features but allow stable evolution to new functionality. And I thing it is most important property of any system: provide stable way how to evolve. System can be broken and very buggy at some point but if design and tests are stable then system will move. By stable I mean "do not require big changes for any new bug or feature", "always iterative process". Just want to share these thoughts with you :).

2017-02-01 9:41 GMT+01:00 Norbert Hartl <norbert@hartl.name>:

Great job!!! A dream comes true. If there is a working UFFI for ARM then we have a pretty decent stack for IoT times.

Thank's. UFFI works in my simple tests like "LibC system: 'ls'"

2017-02-01 13:44 GMT+01:00 Torsten Bergmann <astares@gmx.de>:

Did you check out my OSRaspbian project loadable from the catalog? It uses UFFI and is working on Pi.

I have it in mind but not try it yet :)

2017-02-01 9:41 GMT+01:00 Norbert Hartl <norbert@hartl.name>:

I think in the future we need to work out how we can inspect a remote object while using GT features. A lot of stuff in GT inspector is pretty useful. But then I assume it is really chatty at the same time making the remote usage less useful.

I know what needs to be done from my point of view. But what exactly missing from your perspective?