Hi.
I am glad announce first version of PharmIDE project which is complete toolset for remote development of Pharo images. It includes:
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.html. Best regards, Denis |
On Tue, Jan 24, 2017 at 8:52 PM, Denis Kudriashov <[hidden email]> wrote:
Amazing stuff Denis. It will be very interesting over time to hear of how people's workflows adapt to use this. 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)" cheers -ben |
In reply to this post by Denis Kudriashov
Nice job, Denis!
Doru > On Jan 24, 2017, at 1:52 PM, Denis Kudriashov <[hidden email]> wrote: > > 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.html. > > Best regards, > Denis -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done." |
In reply to this post by Denis Kudriashov
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 <[hidden email]>:
PharoScreenshot.png (322K) Download Attachment |
In reply to this post by Denis Kudriashov
Just watched the video. Very cool!!
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
|
In reply to this post by Denis Kudriashov
Impressive!
2017-01-24 13:52 GMT+01:00 Denis Kudriashov <[hidden email]>:
|
> On 24 Jan 2017, at 16:34, Thierry Goubier <[hidden email]> wrote: > > Impressive! Indeed ! Great work, Denis. > 2017-01-24 13:52 GMT+01:00 Denis Kudriashov <[hidden email]>: > 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.html. > > Best regards, > Denis > |
In reply to this post by Pavel Krivanek-3
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 <[hidden email]> 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 <[hidden email]>: > 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.html. > > Best regards, > Denis > > <PharoScreenshot.png> -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle." |
In reply to this post by Ben Coman
Thank's to all :). 2017-01-24 14:29 GMT+01:00 Ben Coman <[hidden email]>:
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.
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 |
In reply to this post by Tudor Girba-2
2017-01-24 17:00 GMT+01:00 Tudor Girba <[hidden email]>:
Yes, It is Seamless on most low level. And Calypso environment model for browser |
In reply to this post by Denis Kudriashov
On Wed, Jan 25, 2017 at 4:27 AM, Denis Kudriashov <[hidden email]> wrote:
> Thank's to all :). > > 2017-01-24 14:29 GMT+01:00 Ben Coman <[hidden email]>: >> >> >> 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 Don't throw away the host/IP and port from the title bar. They will remain useful. Its just to have an additional ID. cheers -ben |
In reply to this post by Denis Kudriashov
Denis Since I'm basically the head of the team that pays you :) I would really like to have a chance to talk about the name of this environment. Because we will have to market it to a lot of people so I would like to take the time to think about a name that looks like a name. Stef
-- Using Opera's mail client: http://www.opera.com/mail/ |
Administrator
|
In reply to this post by Denis Kudriashov
Awesome! Have you considered security at all yet? Leaving a port open which allows arbitrary code to be executed reomotely seems very dangerous...
Cheers,
Sean |
Von meinem iPad gesendet > Am 28.01.2017 um 19:06 schrieb Sean P. DeNigris <[hidden email]>: > > Denis Kudriashov wrote >> I am glad announce first version of PharmIDE project which is complete >> toolset for remote development of Pharo images. > > Awesome! > > Have you considered security at all yet? Leaving a port open which allows > arbitrary code to be executed reomotely seems very dangerous... > Binding the socket to localhost and enable things like VPN or ssh tunneling is not to difficult to do and gives proper protection Norbert > > > > View this message in context: http://forum.world.st/Ann-PharmIDE-Pharo-remote-IDE-to-develop-farm-of-Pharo-images-remotely-tp4930602p4931875.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
Administrator
|
Thanks! That sounds vaguely familiar...
Cheers,
Sean |
In reply to this post by Sean P. DeNigris
Hi Sean. 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <[hidden email]>:
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. 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 :). |
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
|
> On 30 Jan 2017, at 11:43, Norbert Hartl <[hidden email]> wrote: > >> >> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <[hidden email]>: >> >> Hi Sean. >> >> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <[hidden email]>: >> 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). > 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 <[hidden email]>: > On 30 Jan 2017, at 11:43, Norbert Hartl <[hidden email]> wrote: Yes, I agree with you. That's why it is not in priority. But generally I think It would be nice option |
In reply to this post by Sven Van Caekenberghe-2
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
|
Free forum by Nabble | Edit this page |