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.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
