Commandline

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Commandline

NorbertHartl
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


Reply | Threaded
Open this post in threaded view
|

Re: Commandline

LogiqueWerks
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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Commandline

LogiqueWerks
In reply to this post by NorbertHartl
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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Commandline

Bernat Romagosa
I've used GST in the past for simple scripting too. Worth a try!


2014-07-24 13:24 GMT+02:00 Robert Shiplett <[hidden email]>:
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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Commandline

stepharo
In reply to this post by NorbertHartl

> 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

Reply | Threaded
Open this post in threaded view
|

Re: Commandline

kilon.alios
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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Commandline

Dale Henrichs-3
In reply to this post by NorbertHartl
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-gemstones-64-bit


On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Commandline

EstebanLM

On 24 Jul 2014, at 16:07, Dale Henrichs <[hidden email]> 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



On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Commandline

Esteban A. Maringolo
In reply to this post by Dale Henrichs-3
2014-07-24 11:07 GMT-03:00 Dale Henrichs <[hidden email]>:

> 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

Reply | Threaded
Open this post in threaded view
|

Re: Commandline

Sven Van Caekenberghe-2
In reply to this post by NorbertHartl
Hi Norbert,

On 24 Jul 2014, at 12:37, Norbert Hartl <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

Re: Commandline

Dale Henrichs-3
In reply to this post by EstebanLM
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 <[hidden email]> wrote:

On 24 Jul 2014, at 16:07, Dale Henrichs <[hidden email]> 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



On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: Commandline

NorbertHartl
In reply to this post by Bernat Romagosa

Am 24.07.2014 um 13:32 schrieb Bernat Romagosa <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Commandline

Dale Henrichs-3
In reply to this post by 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 <[hidden email]> wrote:
2014-07-24 11:07 GMT-03:00 Dale Henrichs <[hidden email]>:

> 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


Reply | Threaded
Open this post in threaded view
|

Re: Commandline

NorbertHartl
In reply to this post by Dale Henrichs-3
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 <[hidden email]>:

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-gemstones-64-bit


On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Commandline

philippeback
In reply to this post by Dale Henrichs-3


Le 24 juil. 2014 16:20, "Dale Henrichs" <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>> On 24 Jul 2014, at 16:07, Dale Henrichs <[hidden email]> 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-gemstones-64-bit
>>> [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-93
>>>
>>>
>>> On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <[hidden email]> 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
>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Commandline

NorbertHartl
In reply to this post by Sven Van Caekenberghe-2
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 <[hidden email]>:

> Hi Norbert,
>
> On 24 Jul 2014, at 12:37, Norbert Hartl <[hidden email]> 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.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Commandline

Sven Van Caekenberghe-2
In reply to this post by philippeback

On 24 Jul 2014, at 16:34, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: Commandline

Dale Henrichs-3
In reply to this post by NorbertHartl
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 <[hidden email]> 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 <[hidden email]>:

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-gemstones-64-bit


On Thu, Jul 24, 2014 at 3:37 AM, Norbert Hartl <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: Commandline

NorbertHartl

Am 24.07.2014 um 16:56 schrieb Dale Henrichs <[hidden email]>:

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.
Reply | Threaded
Open this post in threaded view
|

Re: Commandline

NorbertHartl
In reply to this post by Sven Van Caekenberghe-2

Am 24.07.2014 um 16:42 schrieb Sven Van Caekenberghe <[hidden email]>:

>
> On 24 Jul 2014, at 16:34, [hidden email] 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


12