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 <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"
������ ...

Oneliner to install: (note it needs sudo)��
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 is an extension of scale that adds a second magical variable for building up component reification in a ROS based environment.
��
��
Santiago & Guille