Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Norbert Hartl]

> Am 01.02.2017 um 11:56 schrieb Denis Kudriashov :
> 
> 
> 2017-02-01 9:41 GMT+01:00 Norbert Hartl  >:
> 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?

I'm not sure, yet. But what I do is inspecting SeamlessProxy objects which 
won't enable extra tabs and views for the object. And if it does I don't know 
if the communication overhead is not too hardcore. In my dreams there is a 
remote image without GTTools and a GTenabled image on my laptop and still I can 
use GT features on remote objects. I know but … hey you asked! ;)

Norbert

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Norbert Hartl]

> Am 01.02.2017 um 13:44 schrieb Torsten Bergmann :
> 
>>> 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'"
> 
> Did you check out my OSRaspbian project loadable from the catalog? It uses
> UFFI and is working on Pi.
> 
Ok, thanks. As the next attempt is using an Raspberry pi it seems to be a 
perfect fit 

Norbert

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

2017-02-01 13:44 GMT+01:00 Torsten Bergmann :

> 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 :)

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Torsten Bergmann]

>>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'"

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

Bye
T.

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

2017-02-01 9:41 GMT+01:00 Norbert Hartl :

> 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?

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

2017-02-01 9:41 GMT+01:00 Norbert Hartl :

> 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'"

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Esteban Lorenzano]

> On 1 Feb 2017, at 09:41, Norbert Hartl  wrote:
> 
> Great job!!! A dream comes true. If there is a working UFFI for ARM then we 
> have a pretty decent stack for IoT times.

there is not reason why it shouldn’t work… backend is reported to be working… 
but well, you are free to test it :)

Esteban

> 

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Norbert Hartl]

> Am 30.01.2017 um 13:14 schrieb Norbert Hartl :
> 
>> 
>> Am 30.01.2017 um 11:49 schrieb Sven Van Caekenberghe > >:
>> 
>>> 
>>> On 30 Jan 2017, at 11:43, Norbert Hartl >> > wrote:
>>> 
 
 Am 30.01.2017 um 11:36 schrieb Denis Kudriashov >:
 
 Hi Sean.
 
 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris >:
 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?
> 
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 :).

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

2017-01-30 13:36 GMT+01:00 Denis Kudriashov :

> 2017-01-30 13:14 GMT+01:00 Norbert Hartl :
>
>> 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.
>

Ok. It is fixed now. Just load stable version.

Reason was related to my post about two listener sockets.
TCPServer is registered on startup list and it recreates listener socket
when image resumes.
>From command line it happens twice. First instance is created from command
line handler which registers it on startup list. But when command line is
evaluated Pharo start process startup list which lead to duplicated socket
creation.
Now TCPServer handles it properly.

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

2017-01-30 15:45 GMT+01:00 Sven Van Caekenberghe :

> > 2017-01-30 14:16 GMT+01:00 p...@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.


Thank's Sven. I will add suitable method to start Pharm server

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Sven Van Caekenberghe]

> On 30 Jan 2017, at 15:39, Denis Kudriashov  wrote:
> 
> 
> 2017-01-30 14:16 GMT+01:00 p...@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.

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

2017-01-30 14:16 GMT+01:00 p...@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.

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[p...@highoctane.be]

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  wrote:

>
> Am 30.01.2017 um 11:49 schrieb Sven Van Caekenberghe :
>
>
> On 30 Jan 2017, at 11:43, Norbert Hartl  wrote:
>
>
> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov :
>
> Hi Sean.
>
> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris :
> 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 :).
>
>
>

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

2017-01-30 13:14 GMT+01:00 Norbert Hartl :

> 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.

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Norbert Hartl]

> Am 30.01.2017 um 11:49 schrieb Sven Van Caekenberghe :
> 
>> 
>> On 30 Jan 2017, at 11:43, Norbert Hartl  wrote:
>> 
>>> 
>>> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov :
>>> 
>>> Hi Sean.
>>> 
>>> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris :
>>> 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 :).

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

2017-01-30 11:49 GMT+01:00 Sven Van Caekenberghe :

> > On 30 Jan 2017, at 11:43, Norbert Hartl  wrote:
> >
> >>
> >> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov :
> >>
> >> Hi Sean.
> >>
> >> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris :
> >> 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

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Sven Van Caekenberghe]

> On 30 Jan 2017, at 11:43, Norbert Hartl  wrote:
> 
>> 
>> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov :
>> 
>> Hi Sean.
>> 
>> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris :
>> 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 :).

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Norbert Hartl]

> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov :
> 
> Hi Sean.
> 
> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris  >:
> 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 :).

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

Hi Sean.

2017-01-28 19:06 GMT+01:00 Sean P. DeNigris :

> 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.

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 :).

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Sean P. DeNigris]

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-images-remotely-tp4930602p4931986.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Norbert Hartl]

Von meinem iPad gesendet

> Am 28.01.2017 um 19:06 schrieb Sean P. DeNigris :
> 
> 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...
> 
I think security should be established by something else not necessarily remote 
debugging tools. As you most probably protect your pharo web image with a 
frontend web server you do the same in this environment.
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.
> 

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Sean P. DeNigris]

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...



-
Cheers,
Sean
--
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.

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[stepharong]

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


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




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Ben Coman]

On Wed, Jan 25, 2017 at 4:27 AM, Denis Kudriashov  wrote:
> Thank's to all :).
>
> 2017-01-24 14:29 GMT+01:00 Ben Coman :
>>
>>
>> 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

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

2017-01-24 17:00 GMT+01:00 Tudor Girba :

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

Yes, It is Seamless on most low level. And Calypso environment model for
browser

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

Thank's to all :).

2017-01-24 14:29 GMT+01:00 Ben Coman :

>
> 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

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Tudor Girba]

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  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 :
> 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

"Every successful trip needs a suitable vehicle."

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Sven Van Caekenberghe]

> On 24 Jan 2017, at 16:34, Thierry Goubier  wrote:
> 
> Impressive!

Indeed !

Great work, Denis.

> 2017-01-24 13:52 GMT+01:00 Denis Kudriashov :
> 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
> 

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Thierry Goubier]

Impressive!

2017-01-24 13:52 GMT+01:00 Denis Kudriashov :

> 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
>

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Alexandre Bergel]

Just watched the video. Very cool!!

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Jan 24, 2017, at 9:52 AM, Denis Kudriashov  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

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Tudor Girba]

Nice job, Denis!

Doru


> On Jan 24, 2017, at 1:52 PM, Denis Kudriashov  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."

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Ben Coman]

On Tue, Jan 24, 2017 at 8:52 PM, Denis Kudriashov 
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.
>
>
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

[Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[Denis Kudriashov]

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