My idea was even to create objects that generate even bash scripts and all the rest but have objects that we can control and probably to be loaded in another image. I just hate all the undebuggable scripts. On Fri, Nov 24, 2017 at 3:16 AM, Ben Coman <btc@openinworld.com> wrote:
On 24 November 2017 at 05:13, despotadesdibujau <despotadesdibujau@gmail.com> wrote:
Hi Gabriel
This is cool. Thanks for sharing it with us. I really want an object responsible for deploying an app. :) Your effort is nice in that directory. Keep pushing
Stef Thanks!!!
Maxi Tabacman suggests me to reify the deployment process. I thought of something like to get up a minimal image from inside the development image, then to start the deployment process from the development image. I suppose that I would need to use Espell Object Spaces (Guillermo Polito), but in this case, I would need a special virtual machine (Oz Virtual Machine)... Something like Tornado, but not using the "Run Fail Grow" approach, but using a BaselineOf or ConfigurationOf approach.
Another idea (simpler than the idea above) is to communicate the two images using Teapot or Sockets: The Development image sends orders to the minimal image until it becomes on the deployment image.
This sounds like a good initiative, but Teapot seems a bit too specific and Sockets seems a bit too low level. Consider building on top of TelePharo, or being its sibling by building on top of Seamless. These seem better suited to being part of every image than Teapot. * http://forum.world.st/Ann-PharmIDE-is-renamed-to-TelePharo-and-moved-to-gith... * https://dionisiydk.blogspot.com.au/2017/01/pharmide-pharo-remote-ide-to-deve... * http://forum.world.st/Ann-Major-Seamless-update-td4907335.html
Others might comment on which is the best level abstraction to use.
cheers -ben
For the moment I need to test the process (on Pharo 6 and 7) using more complex applications until it becomes a reliable process.
Gabriel
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html