Re: [Pharo-project] Inter-image communication
Some time back I posted (to Squeak) the idea of doing development using two images. One image would be your development image, i.e. the image you would eventually release as your product. It would be a restricted version of the image you have in Squeak/Pharo now. The other image would be your software development tool image, roughly analogous to what the Eclipse development environment is. The advantage of such a set up would be that changes to your development image would not blow up your tool image. You could also leave out anything from your development image you didn't actually need in you product such as perhaps editors, debuggers, windows, etc. depending upon what software your product actually needed. I have no plans to actually try this anytime soon. But I am wondering: Would RemoteSmalltalk be helpful in (be a foundation for) creating such a utility? Regards, Ralph Boland Le 11/08/2010 20:17, Sean P. DeNigris a ?crit :
St?phane Ducasse wrote:
rst? RemoteSmalltalk?
rst = RemoteSmalltalk = SO COOL!!!
I easily shared objects from a Pharo 1.1 image with 4 other local images - including a Squeak 4.1 image!
For a hoot:
1. In a Pharo 1.1 image with rST installed doit: "Transcript open. RSTSamples serverStartup"
2. In a Squeak 4.1 image with rST installed doit: "RSTBroker startOnPort: self clientPort logging: false.
remoteTranscript := ('Transcript@' , self serverBrokerID) asLocalObject. remoteTranscript show: 'everything is ok! (from client side)'; cr"
3. Pick up jaw after you see that the squeak image has sent a message to the Pharo image's Transcript, whose contents now appear as 'everything is ok! (from client side)'
n.b. According to the docs, in both images, doit: "RSTBroker stop"
How to load: I have no write access to rST, so the required packages can be loaded as follows: "Gofer new squeaksource: 'KomHttpServer'; package: 'DynamicBindings'; load.
Gofer new squeaksource: 'KomHttpServer'; package: 'KomServices'; load.
Gofer new squeaksource: 'SPDProjectUpdates'; package: 'rST'; load."
Thanks for the pointer!
1. This seriously frees me to play with objects in different forks and versions because I know I can beam the live objects to another image whenever I want, and not have them stranded. 2. This seems like it should be perfect for scripting an image, but what shared object would allow arbitrary code to be run on the server? I played with Workspace, but got lost down the delegation rabbit hole
Sean
p.s. I got it loading with minimal changes - just had to fix the underscore assignments, and break the dependency to an old version of KomServices.
On 12 août 2010, at 15:58, Ralph Boland wrote:
Would RemoteSmalltalk be helpful in (be a foundation for) creating such a utility?
Yes. But, we need an appropriate set of tools. We (Douai's team) developed a few tools a while ago as part of the UbiquiTalk project. We had a remote-workspace working quite fine. We started an experiment with a remote browser based on omni-browser. But, it was a failure. Omnibrowser does a lot of computations resulting into a lot of network traffic. The browser was to slow to be usable. We started introducing caches, but there were too many things to cache so we gave up. Noury
Regards,
Ralph Boland
Le 11/08/2010 20:17, Sean P. DeNigris a ?crit :
St?phane Ducasse wrote:
rst? RemoteSmalltalk?
rst = RemoteSmalltalk = SO COOL!!!
I easily shared objects from a Pharo 1.1 image with 4 other local images - including a Squeak 4.1 image!
For a hoot:
1. In a Pharo 1.1 image with rST installed doit: "Transcript open. RSTSamples serverStartup"
2. In a Squeak 4.1 image with rST installed doit: "RSTBroker startOnPort: self clientPort logging: false.
remoteTranscript := ('Transcript@' , self serverBrokerID) asLocalObject. remoteTranscript show: 'everything is ok! (from client side)'; cr"
3. Pick up jaw after you see that the squeak image has sent a message to the Pharo image's Transcript, whose contents now appear as 'everything is ok! (from client side)'
n.b. According to the docs, in both images, doit: "RSTBroker stop"
How to load: I have no write access to rST, so the required packages can be loaded as follows: "Gofer new squeaksource: 'KomHttpServer'; package: 'DynamicBindings'; load.
Gofer new squeaksource: 'KomHttpServer'; package: 'KomServices'; load.
Gofer new squeaksource: 'SPDProjectUpdates'; package: 'rST'; load."
Thanks for the pointer!
1. This seriously frees me to play with objects in different forks and versions because I know I can beam the live objects to another image whenever I want, and not have them stranded. 2. This seems like it should be perfect for scripting an image, but what shared object would allow arbitrary code to be run on the server? I played with Workspace, but got lost down the delegation rabbit hole
Sean
p.s. I got it loading with minimal changes - just had to fix the underscore assignments, and break the dependency to an old version of KomServices.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Noury Bouraqadi-2 wrote:
Yes. But, we need an appropriate set of tools. We (Douai's team) developed a few tools a while ago as part of the UbiquiTalk project. We had a remote-workspace working quite fine.
Is this code available? Remote workspace was the first thing I noticed missing from my rST experience. Thanks, Sean -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2325234.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Sat, Aug 14, 2010 at 4:11 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
Noury Bouraqadi-2 wrote:
Yes. But, we need an appropriate set of tools. We (Douai's team)
developed
a few tools a while ago as part of the UbiquiTalk project. We had a remote-workspace working quite fine.
Is this code available?
I guess http://www.squeaksource.com/UbiquiTalk
Remote workspace was the first thing I noticed missing from my rST experience.
Thanks, Sean -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2325234.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 14 août 2010, at 18:53, Mariano Martinez Peck wrote:
On Sat, Aug 14, 2010 at 4:11 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Noury Bouraqadi-2 wrote:
Yes. But, we need an appropriate set of tools. We (Douai's team) developed a few tools a while ago as part of the UbiquiTalk project. We had a remote-workspace working quite fine.
Is this code available?
Yes. More info on: http://vst.ensm-douai.fr/UbiquiTalk Noury
Thanks, Sean -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2325234.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Noury
While some of the suggestions (AMQP, STOMP) were over my head, I'm in the process of getting UbiquiTalk to work and already have rST going. But, for my use case i.e. sending remote commands between (only) two images on the same machine, why not just send the commands as strings over a socket, and evaluate them with the compiler? Obviously there's no security, but since it's in-house only... A proof-of-concept is below: Server image: server := Socket newTCP. server listenOn: 8081. server waitForConnectionFor: 600. server sendData: 'Workspace open' Client image: client := Socket newTCP. client connectTo: (NetNameResolver localHostAddress) port: 8081. Compiler evaluate: client receiveData. Add a loop and we're all set. Sean -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2400616.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Sean, I added you as a developer to the rST project as well as UbiquiTalk. Noury On 30 août 2010, at 21:29, Sean P. DeNigris wrote:
While some of the suggestions (AMQP, STOMP) were over my head, I'm in the process of getting UbiquiTalk to work and already have rST going.
But, for my use case i.e. sending remote commands between (only) two images on the same machine, why not just send the commands as strings over a socket, and evaluate them with the compiler? Obviously there's no security, but since it's in-house only... A proof-of-concept is below:
Server image: server := Socket newTCP. server listenOn: 8081. server waitForConnectionFor: 600. server sendData: 'Workspace open'
Client image: client := Socket newTCP. client connectTo: (NetNameResolver localHostAddress) port: 8081. Compiler evaluate: client receiveData.
Add a loop and we're all set.
Sean -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2400616.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Noury
Noury Bouraqadi-2 wrote:
I added you as a developer to the rST project as well as UbiquiTalk.
Thanks, I'll copy the files over. Sean -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2401752.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 08/12/2010 03:58 PM, Ralph Boland wrote:
Some time back I posted (to Squeak) the idea of doing development using two images. One image would be your development image, i.e. the image you would eventually release as your product. It would be a restricted version of the image you have in Squeak/Pharo now. The other image would be your software development tool image, roughly analogous to what the Eclipse development environment is. The advantage of such a set up would be that changes to your development image would not blow up your tool image. You could also leave out anything from your development image you didn't actually need in you product such as perhaps editors, debuggers, windows, etc. depending upon what software your product actually needed. I have no plans to actually try this anytime soon. But I am wondering:
Would RemoteSmalltalk be helpful in (be a foundation for) creating such a utility?
In fact, the most ambitious effort in this direction is the stuff Craig Latta did in Spoon. He created a "umbilical cord" on the VM level so he could do really transparent remote debugging etc. This was needed since he wanted to create a real minimal image, and he got down below 100kb, but that was probably very hard to do without these special "remote" tools. regards, Göran
participants (5)
-
Göran Krampe -
Mariano Martinez Peck -
Noury Bouraqadi -
Ralph Boland -
Sean P. DeNigris