July 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Commandline

by Norbert Hartl

Sven, that's it. I didn't know you can do it this way. So this an pragmatic approach that can be optimized later towards tiny image and/or coral. Great, thanks, Norbert Am 24.07.2014 um 16:17 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Norbert, > > On 24 Jul 2014, at 12:37, Norbert Hartl <norbert(a)hartl.name> wrote: > >> What are you using to do jobs on the commandline. I'm sick of doing bash and sed,perl,jq,... stuff. What would be the quickest start when using a normal image? And what if I want to give coral a start. Does it work in 3.0? Best place to load stuff from? >> >> thanks, >> >> Norbert > > Actually, you need nothing more than a standard image to do the following: > > #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit > FileStream stdout nextPutAll: Smalltalk arguments printString; cr. > FileStream stdout nextPutAll: 42 factorial asString; cr. > > Make sure to name the file .st and obviously change the paths involved. > You can write any Pharo code, access stdout, stderr, stdin, arguments. > With FileSystem you can do a lot of magic. > > If you make the file executable, you can do: > > $ ./test.st > #('--quit' './test.st') > 1405006117752879898543142606244511569936384000000000 > > HTH, > > Sven > > PS: the above invokes the STCommandLineHandler which does proper #shebang handling. Absolute paths are needed. > > >

July 24, 2014

Re: [Pharo-users] Commandline

by phil＠highoctane.be

Le 24 juil. 2014 16:20, "Dale Henrichs" <dale.henrichs(a)gemtalksystems.com> a Ã©crit : > > Esteban, > > Right now the classes are embedded in my tODE common package (I use the parser in Pharo and GemStone) ... I'll pull out the classes and tests (rename them so you can evolve the implementation independent of tODE) and give you a pointer when I'm done... > > Dale I also need such a thing badly. I've been writing a ton of bash lately for data collection. One question I have is how fast the load of an image and processing by an image is when compared with bash. Also, one strength in bash is the variable cutting shortcuts like ${var#stuff} and ${var%stuff} I am in for using all of the command line related tools as I deeply believe that would help in pushing Phato forward. Phil > > > On Thu, Jul 24, 2014 at 7:12 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> On 24 Jul 2014, at 16:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >>> Norbert, >>> >>> I've just recently made the decision to start using Pharo3.0 to do all of the heavy lifting for my GsDevKit project[1] shell scripts. >>> >>> I use boilerplate bash code to setup the environment[2] and then call Pharo CommandLineHandler[3] to do the real work ... >>> >>> I embed the script repository[4] in the project, so the script code matches the directory structure and I build the command line pharo image[5] as part of my installation. >>> >>> I've been pretty pleased with the results, too. It's pretty straightforward to run the scripts from within an interactive Pharo for debugging and it beats the heck out of trying to do *simple things* with bash... >>> >>> My only wish is that CommandLine had better getopts support - I have a posix getopts commandline parser implementation that iI use for tODE that I'd be willing to share ... hint hint:). >> >> >> and we would be glad to integrate, if is somewhere :) >> >> Esteban >> >>> >>> Dale >>> >>> [1] https://github.com/GsDevKit/gsDevKitHome#open-source-development-kit-for-ge… >>> [2] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone >>> [3] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone#L78-82 >>> [4] https://github.com/GsDevKit/gsDevKitHome/tree/master/repository >>> [5] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createTodeImage#L6… >>> >>> >>> On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> What are you using to do jobs on the commandline. I'm sick of doing bash and sed,perl,jq,... stuff. What would be the quickest start when using a normal image? And what if I want to give coral a start. Does it work in 3.0? Best place to load stuff from? >>>> >>>> thanks, >>>> >>>> Norbert >>>> >>>> >>> >> >

July 24, 2014

Re: [Pharo-users] Commandline

by Norbert Hartl

Dale, thanks for this extensive explanation. That looks all really good but I think I'm looking for the exact opposite. You arrange a lot of pieces in a huge environment and you make it bootstrap itself. The environment/project is defined and all parts need to work together. I'm looking for help doing simple tasks. I have a lot of bash scripts but there is a border of complexity where shell scripts become a pain in the spine. And even more important I'm faster with smalltalk then with bash so I just need an easy entrance to the world/image here. I did some of this in the past with preloaded code that can be triggered by commandline handlers. But you get easily the problem that you need to load new code in the image before you can use it from the commandline which somewhat defeats the purpose. I would like something in between: Having supporting code in the image but I'm also able to do the same scripts from the shell. So you can easily move responsibility of things between commandline and image. Norbert Am 24.07.2014 um 16:07 schrieb Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > Norbert, > > I've just recently made the decision to start using Pharo3.0 to do all of the heavy lifting for my GsDevKit project[1] shell scripts. > > I use boilerplate bash code to setup the environment[2] and then call Pharo CommandLineHandler[3] to do the real work ... > > I embed the script repository[4] in the project, so the script code matches the directory structure and I build the command line pharo image[5] as part of my installation. > > I've been pretty pleased with the results, too. It's pretty straightforward to run the scripts from within an interactive Pharo for debugging and it beats the heck out of trying to do *simple things* with bash... > > My only wish is that CommandLine had better getopts support - I have a posix getopts commandline parser implementation that iI use for tODE that I'd be willing to share ... hint hint:). > > Dale > > [1] https://github.com/GsDevKit/gsDevKitHome#open-source-development-kit-for-ge… > [2] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone > [3] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone#L78-82 > [4] https://github.com/GsDevKit/gsDevKitHome/tree/master/repository > [5] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createTodeImage#L6… > > > On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > What are you using to do jobs on the commandline. I'm sick of doing bash and sed,perl,jq,... stuff. What would be the quickest start when using a normal image? And what if I want to give coral a start. Does it work in 3.0? Best place to load stuff from? > > thanks, > > Norbert > > >

July 24, 2014

Re: [Pharo-users] Deprecator

by stepharo

>> Regarding the name... while I get the value of cool, mysterious-sounding >> names for public-facing (or maybe at minimum cross-platform) projects, I'd >> rather these small tools that we often make be named as intention-revealing >> as possible. I've felt at times some unnecessary complication translating >> #(starfish shovel sandcastle) -> #(Socket Debugger Array) ;-p > Indeedâ¦ I used to be a fan of cute names, but now when looking at the packages > it makes it very hard for people to understand what is what. but this is just a tooling issue. With package metadata, people can add information. For example, if you add catalog metadata to a configuration, you get the description in the fly by help. Stef > > Marcus >

July 24, 2014

Re: [Pharo-users] Commandline

by Dale Henrichs

Esteban, The commandline parser produces an option dictionary (keys are long option names and values are the option values) and a collection of arguments. You provide a specification for the options (short name, whether or not options are required/optional or not expected) ... quite convenient. Dale On Thu, Jul 24, 2014 at 7:16 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-07-24 11:07 GMT-03:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com > >: > > > My only wish is that CommandLine had better getopts support - I have a > posix > > getopts commandline parser implementation that iI use for tODE that I'd > be > > willing to share ... hint hint:). > > Altough I'm used to Pharo's command line handlers now, it would be > great to have "standard" command line arguments. > > > Esteban A. Maringolo > >

July 24, 2014

Re: [Pharo-users] Commandline

by Norbert Hartl

Am 24.07.2014 um 13:32 schrieb Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>: > I've used GST in the past for simple scripting too. Worth a try! > Thanks but to me this doesn't sound like a good idea. Why? Because I like to have something that is easy to use. And I doubt that all things I like to use are available in GST. So while I basically like the idea I wouldn't even try. I have been burned enough in the past 20 years :) Norbert > > 2014-07-24 13:24 GMT+02:00 Robert Shiplett <grshiplett(a)gmail.com>: > I run server-side JavaScript but would not dream of using JS to do jobs ! > > Humour : for years the command-line params for VW Smalltalk were some kind of unpublished hush-hush secret for build mavens and image-stripping gurus on hp/ux servers. Not so for Gnu Smalltalk ;-) > > There is always APL ;-) > > > On 24 July 2014 07:37, Norbert Hartl <norbert(a)hartl.name> wrote: > What are you using to do jobs on the commandline. I'm sick of doing bash and sed,perl,jq,... stuff. What would be the quickest start when using a normal image? And what if I want to give coral a start. Does it work in 3.0? Best place to load stuff from? > > thanks, > > Norbert > > > > > > > -- > Bernat Romagosa.

July 24, 2014

Re: [Pharo-users] Commandline

by Dale Henrichs

Esteban, Right now the classes are embedded in my tODE common package (I use the parser in Pharo and GemStone) ... I'll pull out the classes and tests (rename them so you can evolve the implementation independent of tODE) and give you a pointer when I'm done... Dale On Thu, Jul 24, 2014 at 7:12 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 24 Jul 2014, at 16:07, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > wrote: > > Norbert, > > I've just recently made the decision to start using Pharo3.0 to do all of > the heavy lifting for my GsDevKit project[1] shell scripts. > > I use boilerplate bash code to setup the environment[2] and then call > Pharo CommandLineHandler[3] to do the real work ... > > I embed the script repository[4] in the project, so the script code > matches the directory structure and I build the command line pharo image[5] > as part of my installation. > > I've been pretty pleased with the results, too. It's pretty > straightforward to run the scripts from within an interactive Pharo for > debugging and it beats the heck out of trying to do *simple things* with > bash... > > My only wish is that CommandLine had better getopts support - I have a > posix getopts commandline parser implementation that iI use for tODE that > I'd be willing to share ... hint hint:). > > > and we would be glad to integrate, if is somewhere :) > > Esteban > > > Dale > > [1] > https://github.com/GsDevKit/gsDevKitHome#open-source-development-kit-for-ge… > [2] https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone > [3] > https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createStone#L78-82 > [4] https://github.com/GsDevKit/gsDevKitHome/tree/master/repository > [5] > https://github.com/GsDevKit/gsDevKitHome/blob/master/bin/createTodeImage#L6… > > > On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> What are you using to do jobs on the commandline. I'm sick of doing bash >> and sed,perl,jq,... stuff. What would be the quickest start when using a >> normal image? And what if I want to give coral a start. Does it work in >> 3.0? Best place to load stuff from? >> >> thanks, >> >> Norbert >> >> >> > >

July 24, 2014

Re: [Pharo-users] Commandline

by Sven Van Caekenberghe

Hi Norbert, On 24 Jul 2014, at 12:37, Norbert Hartl <norbert(a)hartl.name> wrote: > What are you using to do jobs on the commandline. I'm sick of doing bash and sed,perl,jq,... stuff. What would be the quickest start when using a normal image? And what if I want to give coral a start. Does it work in 3.0? Best place to load stuff from? > > thanks, > > Norbert Actually, you need nothing more than a standard image to do the following: #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit FileStream stdout nextPutAll: Smalltalk arguments printString; cr. FileStream stdout nextPutAll: 42 factorial asString; cr. Make sure to name the file .st and obviously change the paths involved. You can write any Pharo code, access stdout, stderr, stdin, arguments. With FileSystem you can do a lot of magic. If you make the file executable, you can do: $ ./test.st #('--quit' './test.st') 1405006117752879898543142606244511569936384000000000 HTH, Sven PS: the above invokes the STCommandLineHandler which does proper #shebang handling. Absolute paths are needed.

July 24, 2014

Re: [Pharo-users] Commandline

by Esteban A. Maringolo

2014-07-24 11:07 GMT-03:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > My only wish is that CommandLine had better getopts support - I have a posix > getopts commandline parser implementation that iI use for tODE that I'd be > willing to share ... hint hint:). Altough I'm used to Pharo's command line handlers now, it would be great to have "standard" command line arguments. Esteban A. Maringolo

July 24, 2014

Re: [Pharo-users] Deprecator

by Marcus Denker

On 24 Jul 2014, at 16:14, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > camille teruel wrote >> This debugger has a little 'Rewrite' button > > O.M.G. That is fantastic! Let's get this into core quickly!! Thanks :) > :-) > Regarding the name... while I get the value of cool, mysterious-sounding > names for public-facing (or maybe at minimum cross-platform) projects, I'd > rather these small tools that we often make be named as intention-revealing > as possible. I've felt at times some unnecessary complication translating > #(starfish shovel sandcastle) -> #(Socket Debugger Array) ;-p Indeedâ¦ I used to be a fan of cute names, but now when looking at the packages it makes it very hard for people to understand what is what. Marcus

July 24, 2014