Hi Ben. Yes in deed, it's quite dangerous and it's not meant to be used without thinking about the impact. In any case you cannot even execute this command without sudo (since the installation is on /usr/local/bin).
In a nutshell im using it for installing scale, and updating it. And a i leave it there believing that the user of this method is wise enough :). In any case, i'm not willing to ban #snapshot:andQuit:, what will save the image in the middle of the script execution and it will be really dirty. So, i give a cleaner way to do it. Any case this is meant to update the image in a way that import makes not sense. Like loading a new version of scale. punctually Import is something i want to have for the next version :). But there are many steps in the middle. Thanks for the feedback! Santiago. On Tue, 25 Oct 2016 at 06:01 Ben Coman <b...@openinworld.com> wrote: > On Mon, Oct 24, 2016 at 5:48 PM, Denis Kudriashov <dionisi...@gmail.com> > wrote: > > Really nice project, Santiago. > > > > I have few questions: > > > > - what "system saveAfterRun" actually do? > > > > As I understand it saves image when script completes. Imaging during > script > > I loaded Seaside. Does this command makes Seaside accessible from any > scale > > scripts? > > Image persistence is one of Pharo's most useful features, but I think > its a liability for a system scripting environment. As a > philosophical point, Python/Ruby (somewhat) guarantee scripts start > with the same state each time they are run. I believe this is an > important attribute for system scripting. "saveAfterRun" seems > detrimental to that because you can break the environment for other > scripts, and you can't just reset state by deleting you script. Also > its harder to share scripts since dependencies are not recorded in the > script if the system state has changed. Python/Ruby handle this via a > module import/require facility. Perhaps Scale could provide a > facility to install a Configuration, then export it via Fuel as a > "module" that could be imported into Scale scripts. Loading via Fuel > should be fast enough (??) that Seaside could be accessible from any > Scale script without too much runtime overhead. (I'll add this as an > Issue if discussion indicates interest). > > cheers -ben > > > > > > - system execute: aString into: anImageBundle > > > > What is anImageBundle here? > > > > - What you think to make scripts working as workspace? All undeclared > > variables will be added to environment automatically. And in case of > > saveAfterRun they will became accessible from any scale scripts. > > > > > > 2016-10-23 20:34 GMT+02:00 Santiago Bragagnolo > > <santiagobragagn...@gmail.com>: > >> > >> Hi everybody. > >> > >> We are officially releasing a first version of scale. > >> > >> Scale is a command line handler that is there for making easier the life > >> of the people that uses scripting in linux. As such, we only tested it > so > >> far in linux. It will be for sure easy to adapt it to mac because its a > >> *nix, but not for windoze. > >> > >> IMPORTANT REMARK: scale is not meant to develop applications, it is > meant > >> to develop scripts in Pharo, to be launched from the command line. This > >> means that scale does not provide a top level syntax to declare classes > or > >> methods: people should do that as any normal Pharo application. Scale > should > >> be used to invoke such applications. > >> > >> When would you use scale? > >> - For example, to replace some bash scripts used for common boring > tasks > >> (and you are using python or ruby there :P) > >> - Another example, would be when you want to replace bash scripts that > >> chain things like: > >> ./pharo eval --save "something" > >> ./pharo eval --save "other something" > >> ... > >> > >> Github: https://github.com/guillep/Scale > >> Oneliner to install: (note it needs sudo) > >> > >> wget -O- > >> https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh | > sudo > >> bash > >> > >> > >> In the repository there is some user level documentation based on > examples > >> and a list of available methods on the magical variable system. There > are > >> many examples as well on the repository. > >> > >> Last but not least, I'm using this project in others two projects, where > >> it proof it self quite powerful what keeps me on maintaining Scale. > >> > >> These projects are: > >> > >> Pharo Android VM building https://github.com/sbragagnolo/pharo-vm > >> > >> Here I use it for automating the creation of a > >> * new building image, > >> * the creation of new resource image (for deploying on the > android > >> apk), > >> * linking the android sources into the building directory > >> * generating the code from the console > >> > >> MakrosTool https://github.com/sbragagnolo/MakrosTool > >> > >> MakrosTool is an extension of scale that adds a second magical variable > >> for building up component reification in a ROS based environment. > >> > >> > >> Santiago & Guille > >> > >> > >> > >> > >> > > > >
