The same as Phil mentioned, but with Emacs on Debian Wheezy you get a lot of ^M and Emacs says this about the coding system: - -- undecided-unix (alias: unix) No conversion on encoding, automatic conversion on decoding. Type: undecided (do automatic conversion) On Sun, May 3, 2015 at 5:46 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Sun, May 3, 2015 at 10:34 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I think this is an interesting use case, and it is already supported only in a less classic way :).
I just wrote a blog post about it:
http://www.humane-assessment.com/blog/managing-external-pharo-scripts-with-g...
Let me know if this works for you.
Nice, I need to go to 4.0 to get that Spotter thing :-)
One note: scripts are saved with the CR (or ^M) line ending by Pharo. Now, vim in Linux positively hates that (showing a single line with ^M s all over).
This also makes diffing files a pain (meld is not recognizing any lines etc).
So, I have to mac2unix convert them after they have been saved.
I think we should be much better LF (\n) citizens in the Linux world.
Phil
Cheers, Doru
On Sun, May 3, 2015 at 3:02 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Le 3 mai 2015 12:28, "Esteban Lorenzano" <estebanlm@gmail.com> a écrit :
On 02 May 2015, at 23:28, phil@highoctane.be wrote:
When some sysadmin has to edit them on servers, you want them in .st
files.
No class. No IDE. Not too much Smalltalk.
but then - if not smalltalk, the scripts should not be in the image⦠even in workspaces - if the sysadmin has to edit them, he can always do something like:
#! /bin/bash
pharo MyImage.image eval â my multilined more or less smalltalk scriptâ
- you can always see and edit your scripts by doing:
'play-cache' asFileReference inspect
(instead âplay-cacheâ you can put: âmy-script-folderâ, whatever)
and you will have a complete inspector that allows you to see and edit your scripts (who are in the file system, where a sysadmin can find them, and not in an obscure workspace).
also I bet you would take no more than 5â to add functionality to gtinspector (it is designed to be moldable, after all) to add new scripts, and no matter what other functionality you need⦠and the result will be a lot more âpharoishâ than storing it in a workspace.
I agree to these things for the Pharoish experience.
Just that those scripts are to be edited with Vim on remote boxes.
I don't want to convert a sysadmin to pharo.
I want pharo to be used as any other tool in the lineup.
My image builder is fullly in a class etc.
Also I am using Sebastian Sastre's ConfigurationFiles that do load conf/SomeConfFile.st
I have several such files:
- email addresses - mongodb conf - seaside ports, debug level.. - API config - configuration file for a tree structure - preferences
These are using code that get eval'd because it is practical to use variables etc.
e.g.
defaultBandwidth := 50 megabitsPerSecond.
....
#(10 20 30 40) do: [:id | config add: SomeModule new bandwidth: defaultBandwidth; id: id asString; label: 'SomeLab', is asString; picture:'some.jpg'; geoLocation: 45.55@44.42; yourself]
....
^config
I am preparing them in with Playground etc.
So nothing wrong with Playground.
I just like the simple workspace too.
I also added a : prefix in Spotlight to execute what I do type.
Going 4.0 is not yet done here. I am using 3.0 with GToolkit.
Phil
Esteban
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> 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> 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" <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> 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.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Bernardo E.C. Sent from a cheap desktop computer in South America.