On Sun, May 3, 2015 at 10:34 PM, Tudor Girba <tu...@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-gtinspector-and-gtspotter/ > > 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, p...@highoctane.be <p...@highoctane.be> > wrote: > >> >> Le 3 mai 2015 12:28, "Esteban Lorenzano" <esteba...@gmail.com> a écrit : >> > >> > >> >> On 02 May 2015, at 23:28, p...@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" <esteba...@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 <emaring...@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, "p...@highoctane.be" <p...@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.f...@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" >
