Hi, I didn't thought about sysadmin jobs on Smalltalk, like Ben, but seems like a good case for having stuff outside the image, but being image friendly. The options explained by Tudor[0] could be a good approach and may be the "..." button on the playground could have a dialog to rename page as file or something that makes the procedure of doble clicking the page name as a way to "communicate" with file system more explicit. [0] http://www.humane-assessment.com/blog/managing-external-pharo-scripts-with-g... My approach to give persistence to what I was doing on the workspace/playground was pretty different: After years of using Leo [1] I was very used to its tree-like interface, but I was thinking in something more interactive (like the IPython[2] notebook, but without loosing the trees, that gives context[3]) and more document oriented, like TeXmacs[4] and pandoc. From this kind of sources of inspiration I'm making grafoscopio[5], which is still pretty alpha, but let's you save scripts with context and mix them with documentation or write interactive documentation. The storage format is STON[6] [1] http://leoeditor.com/ [2] http://ipython.org/notebook.html [3] http://mutabit.com/mutabit/default/wiki/ipython-deepness [4] http://texmacs.org/ [5] http://smalltalkhub.com/#!/~Offray/Grafoscopio [6] https://github.com/svenvc/ston/blob/master/ston-paper.md So, it will not let you edit code from vim (by the way, I'm with Ben about more Unix/Internet friendly line endings for storage/exporting on external files), but It will bridge the document/script world, with the object world. Making such bridges with the external world is important for delivering the promises of the dynabook and pharo to more people. Cheers, Offray Ps: I have attached and screenshot of my "apprentice notes" grafoscopio notebook, to illustrate my point :-) El 02/05/15 a las 16:28, phil@highoctane.be escribió:
When some sysadmin has to edit them on servers, you want them in .st files.
No class. No IDE. Not too much Smalltalk.
Just the DSL on an as needed to know basis to configure things.
That's better that XML/YAML/JSON...
So, that's the case.
Startup scripts same story.
Phil
Le 2 mai 2015 17:56, "Esteban Lorenzano" <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> a écrit :
well⦠IMO those scripts also should be in a method. Probably under a class named: MyCoolProjectRunScripts or something like that⦠but in a class. If they are in a class you can: - save them with your project - version them - if you add <script> pragma, you can even execute them by clicking on it (Pharo 4).
so⦠even if you might have a case where you want the save/load⦠you actually have (what I consider) a better option.
Esteban
On 02 May 2015, at 15:17, Esteban A. Maringolo <emaringolo@gmail.com <mailto:emaringolo@gmail.com>> wrote:
Ditto here.
I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.
El may 2, 2015 4:38 AM, "phil@highoctane.be <mailto:phil@highoctane.be>" <phil@highoctane.be <mailto:phil@highoctane.be>> escribió:
playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.
I have scripts to do lots of cli things and I like the save as of the workspace.
But I have done extra key bindings for getting the ws or the playground.
Phil
Le 2 mai 2015 06:49, "Sergio Fedi" <sergio.fedi@gmail.com <mailto:sergio.fedi@gmail.com>> a écrit :
Oh! That link gives a GREAT explanation! Thanks.
On the subject of how to show it better, I'm not a graphic designer (although I'm working with one) so I'll ask him for some insights on the matter.
For now, he pointed out some issues like lack of consistency on some interfaces and some other details.
