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
Ah, this is just *beautiful* Thank you thank you thank you for making this available. Question: How is one creating a new scripting object and making it available? (like system etc). Phil On Sun, Oct 23, 2016 at 8:34 PM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
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
Thanks Phil! That's not easy to do now, Is mean to be a feature for the next version. By the moment you have to add the variable to SCScriptRunner and initialize the value maybe in initialize. This SCScriptRunner is the context of execution of the script. On Sun, 23 Oct 2016 at 21:48 phil@highoctane.be <phil@highoctane.be> wrote:
Ah, this is just *beautiful*
Thank you thank you thank you for making this available.
Question: How is one creating a new scripting object and making it available? (like system etc).
Phil
On Sun, Oct 23, 2016 at 8:34 PM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
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
Ok thanks, that will do for me. Phil On Sun, Oct 23, 2016 at 10:11 PM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
Thanks Phil! That's not easy to do now, Is mean to be a feature for the next version.
By the moment you have to add the variable to SCScriptRunner and initialize the value maybe in initialize.
This SCScriptRunner is the context of execution of the script.
On Sun, 23 Oct 2016 at 21:48 phil@highoctane.be <phil@highoctane.be> wrote:
Ah, this is just *beautiful*
Thank you thank you thank you for making this available.
Question: How is one creating a new scripting object and making it available? (like system etc).
Phil
On Sun, Oct 23, 2016 at 8:34 PM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
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
Hi all, and thanks Santi for rescuing Scale from the Limbo :). I saw already some discussions pointing to this thread indirectly. I want to answer some philosophical aspects, just to remove some burden from Santi who is the real one that should take credit for pushing this to the light ^^. 1) Why scale and not "pharo scripting". I saw an email from Norbert about this. Well, I remember we discussed this with Santi a couple of years ago about this, when we started and brainstormed about it, but I am not able to remember the exact details right now. But, I can still think about some arguments in favor of the current decision (which we may not keep in the future, hey :)) - First, Pharo is different from ruby and python in terms of deployment. In ruby and python, you have the main libraries that are shared and your application is deployed locally as files. We can think that the script becomes the application. In Pharo, to write an application we need to interact and change with the environment. Thus we cannot share it. You can think about scale as a read-only pharo environment deployed in your machine for scripting purposes. - Second, Scale is Pharo, but not only. Scale introduces a new command line handler to manage scripts. Scale introduces an interpreter that is the one that is in charge of executing the code, provide special bindings and syntax sugar to scripts (see e.g. the 'system' instance in scripts). Scale requires TaskIt and OSSubprocess to provide easy-to-use interaction with the system. Should all this be part of Pharo? Well I do not know but I prefer to keep it as a separate entity. Maybe we can call it a separate distribution, installation or whatever. - Third, if it is a matter of naming (which I think it is), something that comes out of the second point is that #! /usr/bin/local/scale => #! /usr/bin/local/pharo scale or better => #! /usr/bin/env pharo scale ? 2) We would appreciate if feedback is not lost in the mailing list but is converted in issues instead: https://github.com/guillep/Scale/issues Fell free to contribute, provide feedback or even check the code, it is really a simple and short project. It was nice that Santi implemented scale installation in scale :) Cheers, Guille On Sun, Oct 23, 2016 at 11:04 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Ok thanks, that will do for me.
Phil
On Sun, Oct 23, 2016 at 10:11 PM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
Thanks Phil! That's not easy to do now, Is mean to be a feature for the next version.
By the moment you have to add the variable to SCScriptRunner and initialize the value maybe in initialize.
This SCScriptRunner is the context of execution of the script.
On Sun, 23 Oct 2016 at 21:48 phil@highoctane.be <phil@highoctane.be> wrote:
Ah, this is just *beautiful*
Thank you thank you thank you for making this available.
Question: How is one creating a new scripting object and making it available? (like system etc).
Phil
On Sun, Oct 23, 2016 at 8:34 PM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
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
Guille I could not really understand the three points below. I have some questions: - "Scale introduces a new command line handler to manage scripts. " do you mean a separate way of managing command lines? - "syntax sugar to script" which one? the #! ... "Scale requires TaskIt and OSSubprocess to provide easy-to-use interaction with the system. Should all this be part of Pharo" - to me this is ok to get it separated but I believe that we should really think about that because to me Pharo should support exactly such kind of programs. Also if TaskIt enhance for real the concurrency model then why not using to support better Pharo? Stef Le 24/10/16 à 11:09, Guillermo Polito a écrit :
Hi all,
and thanks Santi for rescuing Scale from the Limbo :).
I saw already some discussions pointing to this thread indirectly. I want to answer some philosophical aspects, just to remove some burden from Santi who is the real one that should take credit for pushing this to the light ^^.
1) Why scale and not "pharo scripting". I saw an email from Norbert about this.
Well, I remember we discussed this with Santi a couple of years ago about this, when we started and brainstormed about it, but I am not able to remember the exact details right now. But, I can still think about some arguments in favor of the current decision (which we may not keep in the future, hey :))
- First, Pharo is different from ruby and python in terms of deployment. In ruby and python, you have the main libraries that are shared and your application is deployed locally as files. We can think that the script becomes the application. In Pharo, to write an application we need to interact and change with the environment. Thus we cannot share it. You can think about scale as a read-only pharo environment deployed in your machine for scripting purposes. - Second, Scale is Pharo, but not only. Scale introduces a new command line handler to manage scripts. Scale introduces an interpreter that is the one that is in charge of executing the code, provide special bindings and syntax sugar to scripts (see e.g. the 'system' instance in scripts). Scale requires TaskIt and OSSubprocess to provide easy-to-use interaction with the system. Should all this be part of Pharo? Well I do not know but I prefer to keep it as a separate entity. Maybe we can call it a separate distribution, installation or whatever.
- Third, if it is a matter of naming (which I think it is), something that comes out of the second point is that
#! /usr/bin/local/scale => #! /usr/bin/local/pharo scale
or better => #! /usr/bin/env pharo scale ?
2) We would appreciate if feedback is not lost in the mailing list but is converted in issues instead:
https://github.com/guillep/Scale/issues
Fell free to contribute, provide feedback or even check the code, it is really a simple and short project. It was nice that Santi implemented scale installation in scale :)
Cheers, Guille
On Sun, Oct 23, 2016 at 11:04 PM, phil@highoctane.be <mailto:phil@highoctane.be> <phil@highoctane.be <mailto:phil@highoctane.be>> wrote:
Ok thanks, that will do for me.
Phil
On Sun, Oct 23, 2016 at 10:11 PM, Santiago Bragagnolo <santiagobragagnolo@gmail.com <mailto:santiagobragagnolo@gmail.com>> wrote:
Thanks Phil! That's not easy to do now, Is mean to be a feature for the next version.
By the moment you have to add the variable to SCScriptRunner and initialize the value maybe in initialize.
This SCScriptRunner is the context of execution of the script.
On Sun, 23 Oct 2016 at 21:48 phil@highoctane.be <mailto:phil@highoctane.be> <phil@highoctane.be <mailto:phil@highoctane.be>> wrote:
Ah, this is just *beautiful*
Thank you thank you thank you for making this available.
Question: How is one creating a new scripting object and making it available? (like system etc).
Phil
On Sun, Oct 23, 2016 at 8:34 PM, Santiago Bragagnolo <santiagobragagnolo@gmail.com <mailto:santiagobragagnolo@gmail.com>> wrote:
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 <https://github.com/guillep/Scale> Oneliner to install: (note it needs sudo)
wget -O-https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh <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 <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 <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
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? - 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 <santiagobragagnolo@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
2016-10-24 11:48 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
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.
It makes me feel that it could allow things which are impossible with ruby, python or whatever.
Hi Denis! Thanks. There is an class called SCImageBundle. It represents the folder where you downloaded a pharo+vm. So you can instantiate it by hand SCImageBundle new directory: 'path' asFileReference. in any case, this is also the return of the following messages of the system object: #loadPharo: aVersion into: aFileReference #loadBaseline: aPackageName from: aRepository into: anImageBundle andSaveItAt: aDirectory #loadBaselineUI: aPackageName from: aRepository into: anImageBundle andSaveItAt: aDirectory So you can do something like (system home / #pharo) ensureCreateDirectory. pharo5 := system loadPharo: 50 into: system home / #pharo. pharo5WithScale := system loadBaseline: 'Scale' from: 'github://path' into: pharo5. Save after run just sets a flag. If to the end of the execution is on, it saves the image before shutting it down. If the script you are running is supposed to update the same image that is running you have to use this method (and run as sudo) On Mon, 24 Oct 2016 at 11:49 Denis Kudriashov <dionisiydk@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?
- 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 < santiagobragagnolo@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
2016-10-24 16:27 GMT+02:00 Santiago Bragagnolo <santiagobragagnolo@gmail.com
:
(system home / #pharo) ensureCreateDirectory. pharo5 := system loadPharo: 50 into: system home / #pharo. pharo5WithScale := system loadBaseline: 'Scale' from: 'github://path' into: pharo5.
Maybe we should add #execute: into SCImageBundle? With this we could simply write: pharo5 := system loadPharo: 50 into: system home / #pharo. pharo5 execute: myCodeString And maybe for convenience we could ask #asImageBundle on passed arguments of system #execute: methods? system execute: myCodeString into: 'myPharo' asFileReference
On Mon, Oct 24, 2016 at 5:48 PM, Denis Kudriashov <dionisiydk@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 <santiagobragagnolo@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
Python has virtualenv, where one can install its own little world. There is no reason we couldn't have an equivalent where a base scale image is copied and updated with whatever we feel like. http://docs.python-guide.org/en/latest/dev/virtualenvs/ Phil On Tue, Oct 25, 2016 at 5:59 AM, Ben Coman <btc@openinworld.com> wrote:
On Mon, Oct 24, 2016 at 5:48 PM, Denis Kudriashov <dionisiydk@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 <santiagobragagnolo@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
Yes you both are are right. This is why - we started to work on making sure that we can configure an image to be silent (no logging on changes) - we should have a way to save / launch configured images. Stef Le 25/10/16 à 09:03, phil@highoctane.be a écrit :
Python has virtualenv, where one can install its own little world. There is no reason we couldn't have an equivalent where a base scale image is copied and updated with whatever we feel like.
http://docs.python-guide.org/en/latest/dev/virtualenvs/
Phil
On Tue, Oct 25, 2016 at 5:59 AM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:
On Mon, Oct 24, 2016 at 5:48 PM, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@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 > <santiagobragagnolo@gmail.com <mailto:santiagobragagnolo@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 <https://github.com/guillep/Scale> >> Oneliner to install: (note it needs sudo) >> >> wget -O- >> https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh <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 <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 <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 >> >> >> >> >> >
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 <btc@openinworld.com> wrote:
On Mon, Oct 24, 2016 at 5:48 PM, Denis Kudriashov <dionisiydk@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 <santiagobragagnolo@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
participants (6)
-
Ben Coman -
Denis Kudriashov -
Guillermo Polito -
phil＠highoctane.be -
Santiago Bragagnolo -
stepharo