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
Sick of sed and Perl ? There is fun in Object Icon and Rebol ( r3 or Red ) ( Icon, UNICON or pythonic Converge PL.) And I even use xcurl scripts for MIT Curl ( www.curl.com ) (now SCSK Curl at www.curlap.com ) But Object Icon has to be built at the command line ;-) I gave up on Io and have been neglecting Falcon PL The downside to Curl is that it used Regexp ; rebol Parse is such a treat ! ( PEG packrat equiv.) On 24 July 2014 07:37, Norbert Hartl <norbert@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
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@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
I've used GST in the past for simple scripting too. Worth a try! 2014-07-24 13:24 GMT+02:00 Robert Shiplett <grshiplett@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@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.
Am 24.07.2014 um 13:32 schrieb Bernat Romagosa <tibabenfortlapalanca@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@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@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.
What are you using to do jobs on the commandline. I'm sick of doing bash and sed,perl,jq,... stuff. Me too. I dream about editing my pharo script in Pharo, deploying them from pharo and debugging them if necessary. What would be the quickest start when using a normal image? passing a code snippet via the command line as described in the zeroconf chapter. And what if I want to give coral a start. Does it work in 3.0? Best place to load stuff from?
I agree with you. Damien C made a lot of changes to make sure that we can run the image on readonly folder. Because you want to have a image in /usr/bin/ whatever and load your scripts. About coral I think that starting to use it is worth. Right you can launch scripts and even define classes. To me coral is orthogonal to the scripts. I was thinking that we would have a much better support for OSProcess (via NB). To me this is the most important point. Better OS integration. Having an alternate syntax for methods is secondary or less priority. Stef
I don't know if my "Atlas" library could be of assistance here. Atlas will allow you to use python and python libraries from inside pharo via a socket bridge. I am very noob when it comes to terminal but I hear that python is very popular for command line stuff especially on linux and macos where it comes included. So if you run Atlas from headless pharo it should work and give you access to full power of python, but there are a few stuff I need to add to it. Of course the disadvantage here is that you still need to know python and its libraries. On Thu, Jul 24, 2014 at 2:52 PM, stepharo <stepharo@free.fr> wrote:
What are you using to do jobs on the commandline. I'm sick of doing bash
and sed,perl,jq,... stuff.
Me too. I dream about editing my pharo script in Pharo, deploying them from pharo and debugging them if necessary.
What would be the quickest start when using a normal image?
passing a code snippet via the command line as described in the zeroconf chapter.
And what if I want to give coral a start. Does it work in 3.0? Best
place to load stuff from?
I agree with you. Damien C made a lot of changes to make sure that we can run the image on readonly folder. Because you want to have a image in /usr/bin/ whatever and load your scripts.
About coral I think that starting to use it is worth. Right you can launch scripts and even define classes. To me coral is orthogonal to the scripts.
I was thinking that we would have a much better support for OSProcess (via NB). To me this is the most important point. Better OS integration. Having an alternate syntax for methods is secondary or less priority.
Stef
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-gem... [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#L67... On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert@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
On 24 Jul 2014, at 16:07, Dale Henrichs <dale.henrichs@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-gem... [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#L67...
On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert@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
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@gmail.com> wrote:
On 24 Jul 2014, at 16:07, Dale Henrichs <dale.henrichs@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-gem... [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#L67...
On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert@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
Le 24 juil. 2014 16:20, "Dale Henrichs" <dale.henrichs@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@gmail.com>
wrote:
On 24 Jul 2014, at 16:07, Dale Henrichs <dale.henrichs@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-gem...
[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#L67...
On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert@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
On 24 Jul 2014, at 16:34, phil@highoctane.be wrote:
One question I have is how fast the load of an image and processing by an image is when compared with bash.
Obviously, it is slower, there is a whole image that needs to be loaded, etc. $ cat test.st #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr. $ time ./test.st 1405006117752879898543142606244511569936384000000000 real 0m0.644s user 0m0.516s sys 0m0.067s So about half a second overhead. Sven
Am 24.07.2014 um 16:42 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 24 Jul 2014, at 16:34, phil@highoctane.be wrote:
One question I have is how fast the load of an image and processing by an image is when compared with bash.
Obviously, it is slower, there is a whole image that needs to be loaded, etc.
$ cat test.st #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr.
$ time ./test.st 1405006117752879898543142606244511569936384000000000
real 0m0.644s user 0m0.516s sys 0m0.067s
So about half a second overhead.
That#s what I meant pixelflux:cmdline norbert$ time ./test.st #('--quit' './test.st') 1405006117752879898543142606244511569936384000000000 real 0m0.414s user 0m0.284s sys 0m0.054s Then I just opened the image executed "ImageCleaner cleanupForProduction" and saved. pixelflux:cmdline norbert$ time ./test-cofp.st #('--quit' './test-cofp.st') 1405006117752879898543142606244511569936384000000000 real 0m0.338s user 0m0.225s sys 0m0.051s If it is an issue at all this is easy to mitigate. A real test would include a complexer scenario where other files are loaded and this way others would be in the same range as pharo I guess. Norbert
Sven, I'm using Pharo3.0 and it appears that the .st scripts have to be located in the same directory as the image and changes files ... I see that you are using Pharo4.0 ... So is it possible to get Pharo3.0 to work on .st files in arbitary directores? Dale On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Jul 2014, at 16:34, phil@highoctane.be wrote:
One question I have is how fast the load of an image and processing by an image is when compared with bash.
Obviously, it is slower, there is a whole image that needs to be loaded, etc.
$ cat test.st #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr.
$ time ./test.st 1405006117752879898543142606244511569936384000000000
real 0m0.644s user 0m0.516s sys 0m0.067s
So about half a second overhead.
Sven
On 25 Jul 2014, at 21:25, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Sven,
I'm using Pharo3.0 and it appears that the .st scripts have to be located in the same directory as the image and changes files ... I see that you are using Pharo4.0 ...
So is it possible to get Pharo3.0 to work on .st files in arbitary directores?
Are you using the shebang or direct version ? In any case, I am always using absolute paths. Does that not work for you ?
Dale
On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Jul 2014, at 16:34, phil@highoctane.be wrote:
One question I have is how fast the load of an image and processing by an image is when compared with bash.
Obviously, it is slower, there is a whole image that needs to be loaded, etc.
$ cat test.st #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr.
$ time ./test.st 1405006117752879898543142606244511569936384000000000
real 0m0.644s user 0m0.516s sys 0m0.067s
So about half a second overhead.
Sven
Sven, Without putting a test.st file in /Users/daleh/gsDevKitHome/pharo, I get the following (it works if I `cp ./test.st /Users/daleh/gsDevKitHome/pharo`): nehalem:junk daleh$ pwd /Users/daleh/junk nehalem:junk daleh$ cat test.st #!/Users/daleh/gsDevKitHome/pharo/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/daleh/gsDevKitHome/pharo/todeClient.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr. nehalem:junk daleh$ ./test.st FileDoesNotExist: File @ /Users/daleh/gsDevKitHome/pharo/test.st FileHandle>>streamError FileHandle>>readStream FileSystem>>readStreamOn: FileReference>>readStream FileReference(AbstractFileReference)>>readStreamDo: STCommandLineHandler>>installSourceFile: STCommandLineHandler>>installSourceFiles in Block: [ :reference | self installSourceFile: reference ]...etc... OrderedCollection>>do: STCommandLineHandler>>installSourceFiles in Block: [ sourceFiles do: [ :reference | self installSourc...etc... BlockClosure>>ensure: STCommandLineHandler>>installSourceFiles STCommandLineHandler>>activate STCommandLineHandler class(CommandLineHandler class)>>activateWith: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self handleArgument: (self arguments ifEmpty: [ ...etc... BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activate PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ] WorldState>>runStepMethodsIn: WorldMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle MorphicUIManager>>spawnNewProcess in Block: [ ... On Fri, Jul 25, 2014 at 12:29 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 25 Jul 2014, at 21:25, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Sven,
I'm using Pharo3.0 and it appears that the .st scripts have to be located in the same directory as the image and changes files ... I see that you are using Pharo4.0 ...
So is it possible to get Pharo3.0 to work on .st files in arbitary directores?
Are you using the shebang or direct version ? In any case, I am always using absolute paths. Does that not work for you ?
Dale
On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Jul 2014, at 16:34, phil@highoctane.be wrote:
One question I have is how fast the load of an image and processing by an image is when compared with bash.
Obviously, it is slower, there is a whole image that needs to be loaded, etc.
$ cat test.st #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr.
$ time ./test.st 1405006117752879898543142606244511569936384000000000
real 0m0.644s user 0m0.516s sys 0m0.067s
So about half a second overhead.
Sven
Yes, for some reason, the shebang (#!) machinery passes ./test2.st as argument to pharo, which it seems can only be resolved if it is in the image directory (as opposed to the current shell directory). I have no time to look at this now, but I vaguely remember that pharo mixed the concept of current working directory and image directory (at least in some places). On 25 Jul 2014, at 21:43, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Sven, Without putting a test.st file in /Users/daleh/gsDevKitHome/pharo, I get the following (it works if I `cp ./test.st /Users/daleh/gsDevKitHome/pharo`):
nehalem:junk daleh$ pwd /Users/daleh/junk nehalem:junk daleh$ cat test.st #!/Users/daleh/gsDevKitHome/pharo/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/daleh/gsDevKitHome/pharo/todeClient.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr. nehalem:junk daleh$ ./test.st FileDoesNotExist: File @ /Users/daleh/gsDevKitHome/pharo/test.st FileHandle>>streamError FileHandle>>readStream FileSystem>>readStreamOn: FileReference>>readStream FileReference(AbstractFileReference)>>readStreamDo: STCommandLineHandler>>installSourceFile: STCommandLineHandler>>installSourceFiles in Block: [ :reference | self installSourceFile: reference ]...etc... OrderedCollection>>do: STCommandLineHandler>>installSourceFiles in Block: [ sourceFiles do: [ :reference | self installSourc...etc... BlockClosure>>ensure: STCommandLineHandler>>installSourceFiles STCommandLineHandler>>activate STCommandLineHandler class(CommandLineHandler class)>>activateWith: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self handleArgument: (self arguments ifEmpty: [ ...etc... BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activate PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ] WorldState>>runStepMethodsIn: WorldMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle MorphicUIManager>>spawnNewProcess in Block: [ ...
On Fri, Jul 25, 2014 at 12:29 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 25 Jul 2014, at 21:25, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Sven,
I'm using Pharo3.0 and it appears that the .st scripts have to be located in the same directory as the image and changes files ... I see that you are using Pharo4.0 ...
So is it possible to get Pharo3.0 to work on .st files in arbitary directores?
Are you using the shebang or direct version ? In any case, I am always using absolute paths. Does that not work for you ?
Dale
On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Jul 2014, at 16:34, phil@highoctane.be wrote:
One question I have is how fast the load of an image and processing by an image is when compared with bash.
Obviously, it is slower, there is a whole image that needs to be loaded, etc.
$ cat test.st #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr.
$ time ./test.st 1405006117752879898543142606244511569936384000000000
real 0m0.644s user 0m0.516s sys 0m0.067s
So about half a second overhead.
Sven
Sven, It was just that in your example you didn't mention that the .st file had to be in the image directory and I was sorta hoping that there was a real solution to that problem ... It does mean that for gsDevKit I will still need to use bash wrapper files for all scripts that may be copied to arbitrary locations on disk ... oh well ... If that problem gets fixed, I will convert gsDevKit to use pharo-based scripts for almost everything:) Dale On Fri, Jul 25, 2014 at 1:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, for some reason, the shebang (#!) machinery passes ./test2.st as argument to pharo, which it seems can only be resolved if it is in the image directory (as opposed to the current shell directory).
I have no time to look at this now, but I vaguely remember that pharo mixed the concept of current working directory and image directory (at least in some places).
On 25 Jul 2014, at 21:43, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Sven, Without putting a test.st file in /Users/daleh/gsDevKitHome/pharo, I get the following (it works if I `cp ./test.st /Users/daleh/gsDevKitHome/pharo`):
nehalem:junk daleh$ pwd /Users/daleh/junk nehalem:junk daleh$ cat test.st
#!/Users/daleh/gsDevKitHome/pharo/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/daleh/gsDevKitHome/pharo/todeClient.image st --quit
FileStream stdout nextPutAll: 42 factorial asString; cr. nehalem:junk daleh$ ./test.st FileDoesNotExist: File @ /Users/daleh/gsDevKitHome/pharo/test.st FileHandle>>streamError FileHandle>>readStream FileSystem>>readStreamOn: FileReference>>readStream FileReference(AbstractFileReference)>>readStreamDo: STCommandLineHandler>>installSourceFile: STCommandLineHandler>>installSourceFiles in Block: [ :reference | self installSourceFile: reference ]...etc... OrderedCollection>>do: STCommandLineHandler>>installSourceFiles in Block: [ sourceFiles do: [ :reference | self installSourc...etc... BlockClosure>>ensure: STCommandLineHandler>>installSourceFiles STCommandLineHandler>>activate STCommandLineHandler class(CommandLineHandler class)>>activateWith: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self handleArgument: (self arguments ifEmpty: [ ...etc... BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activate PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ] WorldState>>runStepMethodsIn: WorldMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle MorphicUIManager>>spawnNewProcess in Block: [ ...
On Fri, Jul 25, 2014 at 12:29 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 25 Jul 2014, at 21:25, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Sven,
I'm using Pharo3.0 and it appears that the .st scripts have to be located in the same directory as the image and changes files ... I see that you are using Pharo4.0 ...
So is it possible to get Pharo3.0 to work on .st files in arbitary directores?
Are you using the shebang or direct version ? In any case, I am always using absolute paths. Does that not work for you ?
Dale
On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Jul 2014, at 16:34, phil@highoctane.be wrote:
One question I have is how fast the load of an image and processing by an image is when compared with bash.
Obviously, it is slower, there is a whole image that needs to be loaded, etc.
$ cat test.st #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr.
$ time ./test.st 1405006117752879898543142606244511569936384000000000
real 0m0.644s user 0m0.516s sys 0m0.067s
So about half a second overhead.
Sven
You can try to get the current working directory this way: argumentsAsFileReferences |pwd | pwd := (Smalltalk os environment at: 'PWD' ifAbsent: [ Smalltalk os environment at: 'CD' ]) asFileReference. ^ self argumentsWithoutOptions collect: [ :each | pwd resolveReference: each asFileReference ] This works when passing arbitrary files as argument to a shell script doing an exec on arbitraryPath/pharo afterwards. (This is how GitFileTree-MergeDriver handles being called by git with file paths). Now, it would be necessary to fix that on the default .st loading :) Thierry Le 25/07/2014 22:05, Sven Van Caekenberghe a écrit :
Yes, for some reason, the shebang (#!) machinery passes ./test2.st as argument to pharo, which it seems can only be resolved if it is in the image directory (as opposed to the current shell directory).
I have no time to look at this now, but I vaguely remember that pharo mixed the concept of current working directory and image directory (at least in some places).
On 25 Jul 2014, at 21:43, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Sven, Without putting a test.st file in /Users/daleh/gsDevKitHome/pharo, I get the following (it works if I `cp ./test.st /Users/daleh/gsDevKitHome/pharo`):
nehalem:junk daleh$ pwd /Users/daleh/junk nehalem:junk daleh$ cat test.st #!/Users/daleh/gsDevKitHome/pharo/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/daleh/gsDevKitHome/pharo/todeClient.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr. nehalem:junk daleh$ ./test.st FileDoesNotExist: File @ /Users/daleh/gsDevKitHome/pharo/test.st FileHandle>>streamError FileHandle>>readStream FileSystem>>readStreamOn: FileReference>>readStream FileReference(AbstractFileReference)>>readStreamDo: STCommandLineHandler>>installSourceFile: STCommandLineHandler>>installSourceFiles in Block: [ :reference | self installSourceFile: reference ]...etc... OrderedCollection>>do: STCommandLineHandler>>installSourceFiles in Block: [ sourceFiles do: [ :reference | self installSourc...etc... BlockClosure>>ensure: STCommandLineHandler>>installSourceFiles STCommandLineHandler>>activate STCommandLineHandler class(CommandLineHandler class)>>activateWith: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self handleArgument: (self arguments ifEmpty: [ ...etc... BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activate PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ] WorldState>>runStepMethodsIn: WorldMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle MorphicUIManager>>spawnNewProcess in Block: [ ...
On Fri, Jul 25, 2014 at 12:29 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 25 Jul 2014, at 21:25, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Sven,
I'm using Pharo3.0 and it appears that the .st scripts have to be located in the same directory as the image and changes files ... I see that you are using Pharo4.0 ...
So is it possible to get Pharo3.0 to work on .st files in arbitary directores? Are you using the shebang or direct version ? In any case, I am always using absolute paths. Does that not work for you ?
Dale
On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Jul 2014, at 16:34, phil@highoctane.be wrote:
One question I have is how fast the load of an image and processing by an image is when compared with bash. Obviously, it is slower, there is a whole image that needs to be loaded, etc.
$ cat test.st #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr.
$ time ./test.st 1405006117752879898543142606244511569936384000000000
real 0m0.644s user 0m0.516s sys 0m0.067s
So about half a second overhead.
Sven
Oooooh! That might just do the trick for me... Turns out that I've got one more problem in that the gsDevKit pharo vm and/or gsdevkit image files can be installed in arbitrary locations ... for this one I guess I need to consider installing pharo and pharo-ui in /usr/local/ ... will work for Linux and Mac ... for Windows, I'm already jumping through some ugly hoops... Thanks Thierry and Sven! Dale On Fri, Jul 25, 2014 at 1:53 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
You can try to get the current working directory this way:
argumentsAsFileReferences |pwd | pwd := (Smalltalk os environment at: 'PWD' ifAbsent: [ Smalltalk os environment at: 'CD' ]) asFileReference. ^ self argumentsWithoutOptions collect: [ :each | pwd resolveReference: each asFileReference ]
This works when passing arbitrary files as argument to a shell script doing an exec on arbitraryPath/pharo afterwards.
(This is how GitFileTree-MergeDriver handles being called by git with file paths).
Now, it would be necessary to fix that on the default .st loading :)
Thierry
Le 25/07/2014 22:05, Sven Van Caekenberghe a écrit :
Yes, for some reason, the shebang (#!) machinery passes ./test2.st as
argument to pharo, which it seems can only be resolved if it is in the image directory (as opposed to the current shell directory).
I have no time to look at this now, but I vaguely remember that pharo mixed the concept of current working directory and image directory (at least in some places).
On 25 Jul 2014, at 21:43, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Sven,
Without putting a test.st file in /Users/daleh/gsDevKitHome/pharo, I get the following (it works if I `cp ./test.st /Users/daleh/gsDevKitHome/pharo`):
nehalem:junk daleh$ pwd /Users/daleh/junk nehalem:junk daleh$ cat test.st #!/Users/daleh/gsDevKitHome/pharo/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/daleh/gsDevKitHome/pharo/todeClient.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr. nehalem:junk daleh$ ./test.st FileDoesNotExist: File @ /Users/daleh/gsDevKitHome/pharo/test.st FileHandle>>streamError FileHandle>>readStream FileSystem>>readStreamOn: FileReference>>readStream FileReference(AbstractFileReference)>>readStreamDo: STCommandLineHandler>>installSourceFile: STCommandLineHandler>>installSourceFiles in Block: [ :reference | self installSourceFile: reference ]...etc... OrderedCollection>>do: STCommandLineHandler>>installSourceFiles in Block: [ sourceFiles do: [ :reference | self installSourc...etc... BlockClosure>>ensure: STCommandLineHandler>>installSourceFiles STCommandLineHandler>>activate STCommandLineHandler class(CommandLineHandler class)>>activateWith: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self handleArgument: (self arguments ifEmpty: [ ...etc... BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activate PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ] WorldState>>runStepMethodsIn: WorldMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle MorphicUIManager>>spawnNewProcess in Block: [ ...
On Fri, Jul 25, 2014 at 12:29 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 25 Jul 2014, at 21:25, Dale Henrichs <dale.henrichs@gemtalksystems. com> wrote:
Sven,
I'm using Pharo3.0 and it appears that the .st scripts have to be located in the same directory as the image and changes files ... I see that you are using Pharo4.0 ...
So is it possible to get Pharo3.0 to work on .st files in arbitary directores?
Are you using the shebang or direct version ? In any case, I am always using absolute paths. Does that not work for you ?
Dale
On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 24 Jul 2014, at 16:34, phil@highoctane.be wrote:
One question I have is how fast the load of an image and processing by
an image is when compared with bash.
Obviously, it is slower, there is a whole image that needs to be loaded, etc.
$ cat test.st #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit FileStream stdout nextPutAll: 42 factorial asString; cr.
$ time ./test.st 1405006117752879898543142606244511569936384000000000
real 0m0.644s user 0m0.516s sys 0m0.067s
So about half a second overhead.
Sven
2014-07-24 11:07 GMT-03:00 Dale Henrichs <dale.henrichs@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
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@gmail.com> wrote:
2014-07-24 11:07 GMT-03:00 Dale Henrichs <dale.henrichs@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
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@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-gem... [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#L67...
On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert@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
Norbert, Ah, yes different use case ... for the scripts I'm writing I wanted to leverage "loaded code" as I've got a whole class hierarchy supporting the GsDevKit environment and did not relish the idea of doing that all in bash distributed across a number of different scripts ... Haha, I live in tODE all the time, where Smalltalk _is_ the scripting language so I don't feel your particular brand of pain:) Dale On Thu, Jul 24, 2014 at 7:33 AM, Norbert Hartl <norbert@hartl.name> wrote:
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@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-gem... [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#L67...
On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <norbert@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
Am 24.07.2014 um 16:56 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:
Haha, I live in tODE all the time, where Smalltalk _is_ the scripting language so I don't feel your particular brand of pain:)
*takingjohnwaynepose* That's good for ya, boy! But I've got a business to runâ¦*nods* N.
Hi Norbert, On 24 Jul 2014, at 12:37, Norbert Hartl <norbert@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.
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@stfx.eu>:
Hi Norbert,
On 24 Jul 2014, at 12:37, Norbert Hartl <norbert@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.
participants (11)
-
Bernat Romagosa -
Dale Henrichs -
Esteban A. Maringolo -
Esteban Lorenzano -
kilon alios -
Norbert Hartl -
phil＠highoctane.be -
Robert Shiplett -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier