EstebanLM wrote

is cool. I would like to explore the possibility to replace our command line parser with getopt. You know… is more compatible at the end :)

I find the implementation of our command line handlers very confusing. It seems like it grew organically from a smaller idea and the design got out of control. There are many assumptions that can make it hard to extend, especially to combine multiple options, as Ben and I discovered when implementing the "don't run startup scripts" handler. It would be nice to revisit starting from a behavioral specification. ----- Cheers, Sean -- View this message in context: http://forum.world.st/GetOpt-tp4793474p4793621.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

phil@highoctane.be wrote:

On Tue, Dec 2, 2014 at 4:06 PM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:

EstebanLM wrote > is cool. > I would like to explore the possibility to replace our command line parser > with getopt. You know… is more compatible at the end :)

I find the implementation of our command line handlers very confusing. It seems like it grew organically from a smaller idea and the design got out of control. There are many assumptions that can make it hard to extend, especially to combine multiple options, as Ben and I discovered when implementing the "don't run startup scripts" handler. It would be nice to revisit starting from a behavioral specification.

Well, what makes you say that? The core CommandLineHandler itself is pretty generic and can do a lot of things.

Then, yeah, what is under is quite varied. But that's to be expected when trying out "new tech".

I've been making one of my own here for a given project with about 20-30 commands and I had to put in some structure indeed.

Is that part available somewhere that can be reviewed ? cheers -ben

phil@highoctane.be wrote:

On Tue, Dec 2, 2014 at 4:30 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

phil@highoctane.be <mailto:phil@highoctane.be> wrote:

On Tue, Dec 2, 2014 at 4:06 PM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com> <mailto:sean@clipperadams.com <mailto:sean@clipperadams.com>>__> wrote:

EstebanLM wrote > is cool. > I would like to explore the possibility to replace our command line parser > with getopt. You know… is more compatible at the end :)

I find the implementation of our command line handlers very confusing. It seems like it grew organically from a smaller idea and the design got out of control. There are many assumptions that can make it hard to extend, especially to combine multiple options, as Ben and I discovered when implementing the "don't run startup scripts" handler. It would be nice to revisit starting from a behavioral specification.

Well, what makes you say that? The core CommandLineHandler itself is pretty generic and can do a lot of things.

Then, yeah, what is under is quite varied. But that's to be expected when trying out "new tech".

I've been making one of my own here for a given project with about 20-30 commands and I had to put in some structure indeed.

Is that part available somewhere that can be reviewed ?

You mean?

CommandLineHandler and CommandLineArguments is in the base image.

No, I meant.. "I had to put in some structure indeed" or is it too application specific? cheers -ben

Can you be more concrete because I like what Camillo designed. Le 2/12/14 16:06, Sean P. DeNigris a écrit :

EstebanLM wrote

...

is cool. I would like to explore the possibility to replace our command line parser with getopt. You know… is more compatible at the end :) I find the implementation of our command line handlers very confusing. It seems like it grew organically from a smaller idea and the design got out of control. There are many assumptions that can make it hard to extend, especially to combine multiple options, as Ben and I discovered when implementing the "don't run startup scripts" handler. It would be nice to revisit starting from a behavioral specification.

----- Cheers, Sean -- View this message in context: http://forum.world.st/GetOpt-tp4793474p4793621.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

I liked that you propose yourself also to edit the zeroConf chapter. Thanks. I must admit that I'M FED UP to feel the only one with Sven that seems to be able to write a documentation in our wonderful community. So at least changes should be retrofitted in the available doc. Do not worry LaTex is easy and we will probably convert Deep into Pharo into Pillar. Stef Le 2/12/14 09:37, Esteban Lorenzano a écrit :

is cool. I would like to explore the possibility to replace our command line parser with getopt. You know… is more compatible at the end :)

thanks phil.

Esteban

...

On 02 Dec 2014, at 08:45, phil@highoctane.be <mailto:phil@highoctane.be> wrote:

I have made Ian Piumarta's GST GetOpt work in Pharo 3.0

See:

http://www.smalltalkhub.com/#!/~philippeback/GetOpt <http://www.smalltalkhub.com/#%21/%7Ephilippeback/GetOpt>

Nice tool even if we have some other support in CommandLineHandlers. But for a quick parameters setting in your own CommandLineHandler, it is fast to use and easy to debug.

Phil

Well, after looking at the command line handlers in the image for the way options are handled, I was of opinion that I wanted something like getopt. So, I looked around and found that implementation of Ian that I plugged into the CommandLineArguments in my activate methods. I like the dictionary + block approach I have quite a couple commands (like --create-user -u xxx -p xxx -e xxx -n xxx -g xxx) and it was a pain to write the options parsing. So, something like this in my XXToolsCommandLineHandler activate ... self activateCreateUser ... activateCreateUser GetOpt new at: $u put: [ :opt :arg | userName := arg ]; at: $p put: [ :opt :arg | ... ]; at: $e put: [ :opt :arg | ... ]; at: $n put: [ :opt :arg | ... ]. at: $g put: [ :opt :arg | ... ]; parse: self arguments. "wrapped in some error handling" XXTools makeUserNames: userName ... No more need to dig into a number of isXXXX methods and optionAt:... I think we should make this work with more integration etc but I have other fish to fry at the moment and this works well for me. We need more doc on the CommandLineHandlers but it is a fantastic piece of Pharo! Combined with a small image, it would be a terrific tool. I am investing some time on those CLI things as I need them for servers and even if Bash is cool for some things, Pharo is better in terms of cleanliness. One factor is the time taken for loading the image. Maybe should we look into something like a pharod, a daemon that would just run scripts and a lightweight CLI tool that would pass the scripts to it. Something like: http://www.martiansoftware.com/nailgun/ I think we could steal their C client right away/ Phil On Tue, Dec 2, 2014 at 10:17 AM, stepharo <stepharo@free.fr> wrote:

Can you just tell me a bit more :)

Le 2/12/14 08:45, phil@highoctane.be a écrit :

...

I have made Ian Piumarta's GST GetOpt work in Pharo 3.0

See:

http://www.smalltalkhub.com/#!/~philippeback/GetOpt < http://www.smalltalkhub.com/#%21/%7Ephilippeback/GetOpt>

Nice tool even if we have some other support in CommandLineHandlers. But for a quick parameters setting in your own CommandLineHandler, it is fast to use and easy to debug.

Phil

On 02 Dec 2014, at 11:24, Torsten Bergmann <astares@gmx.de> wrote:

...

Combined with a small image, it would be a terrific tool.

That was/is the goal of Coral. http://rmod.lille.inria.fr/coral/ <http://rmod.lille.inria.fr/coral/>

afaik the goal of coral was/is what “scale” is trying also to do… the getopt library is just a command line parser :) Esteban

Dont know about its current state.

Thx T.

On Tue, Dec 2, 2014 at 4:42 PM, Damien Pollet <damien.pollet@gmail.com> wrote:

Coral is currently broken because I didn't maintain it through the pharo releases (the current CommandLine stuff is more or less extracted from it). However, the option-parsers part should still be OK, it's the hooking at image startup that is not up to date.

For me the leverage is coming from the ability to declare classes in a file and use them. A là GST. Can't we have that? Coral is interestingly engineered but what good does it gives if we cannot use it? Maybe a Coral-light would be way sufficient as a part we can hook into the system. Like you see in the ScriptRunner of Guille in Scale. Turn bits of Coral into the ScriptRunner and we can go a long way (and in a lot of places, including sending scripts around through whatever servers). Phil

There were/are multiple goals :

- make a text-file friendly syntax for code, to make it possible to quickly put some logic in a file with #!/usr/bin/env pharo at the top to run it as any other shell command. Obviously this has some overlap with filetree.

- provide a framework to declare commands in a convenient way (with automatic --help documentation, completion helpers for shells, etc). This is using PetitParser to analyse the arguments list, and provides off-the-shelf parsers for the common patterns -x -aBc --long-option --foo=value.

IMHO getopt could be nice for the VM options, but for scripts it's really procedural and string-oriented, at least for the implementations I have some experience with (ruby, shell). For any real script, you want something higher-level, like http://docopt.org

There is also a problem specific to us : a given image can have many command line handlers installed, so there needs to be some dispatch / priority resolution to make the composition work.

On 2 December 2014 at 11:24, Torsten Bergmann <astares@gmx.de> wrote:

...

...

Combined with a small image, it would be a terrific tool.

That was/is the goal of Coral. http://rmod.lille.inria.fr/coral/

Dont know about its current state.

Thx T.

-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

On Wed, Dec 3, 2014 at 9:51 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Phil,

On Dec 2, 2014, at 2:18 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:

Well, after looking at the command line handlers in the image for the way options are handled, I was of opinion that I wanted something like getopt.

So, I looked around and found that implementation of Ian that I plugged into the CommandLineArguments in my activate methods.

I like the dictionary + block approach

I have quite a couple commands (like --create-user -u xxx -p xxx -e xxx -n xxx -g xxx) and it was a pain to write the options parsing.

So, something like this in my XXToolsCommandLineHandler

activate ... self activateCreateUser ...

activateCreateUser

GetOpt new at: $u put: [ :opt :arg | userName := arg ]; at: $p put: [ :opt :arg | ... ]; at: $e put: [ :opt :arg | ... ]; at: $n put: [ :opt :arg | ... ]. at: $g put: [ :opt :arg | ... ]; parse: self arguments. "wrapped in some error handling" XXTools makeUserNames: userName ...

No more need to dig into a number of isXXXX methods and optionAt:...

I think we should make this work with more integration etc but I have other fish to fry at the moment and this works well for me.

We need more doc on the CommandLineHandlers but it is a fantastic piece of Pharo!

Combined with a small image, it would be a terrific tool.

I am investing some time on those CLI things as I need them for servers and even if Bash is cool for some things, Pharo is better in terms of cleanliness.

One factor is the time taken for loading the image.

I bet that if you measure it you'll find that the load time is very small and the bulk of the time is in unnecessary or insane activities. One if these, which Ben Coman's recent changes above my 64-bit microsecond clock should have fixed is a spin loop of up to a second to synchronize the second and millisecond clocks. Another is a GC to start the new weakness facilities.

I found these either by profiling (clock sync; I can give you a change set that allows profiling across a snapshot, quit, resume) or using the VM simulator (GC to check for finalization facilities).

Nice to know! Yeah, send me the .cs, I am eager to try. The sim is not working for my Pharo. I admit that I've let that on the backburner when Clement told me he was using your image for that. (little depressing moment). I've used strace a bit to see what the VM was doing as well as instrumenting some plugins on a custom VM build. There is the dtrace enabled VM possibility (Ardian's thing) and this should be explored too for instrumentation.

Maybe should we look into something like a pharod, a daemon that would just run scripts and a lightweight CLI tool that would pass the scripts to it.

IMO all that needs to be fine is to take a careful look at start-up and eliminate costly but unnecessary activities. You should easily be able to get startup times down to tens if milliseconds on modem hardware.

Yes it is fast when starting stuff. But when repeated a ton of times, it becomes long. It will be nice to get things super fast indeed. That would be a great bonus. Phil

Something like: http://www.martiansoftware.com/nailgun/

I think we could steal their C client right away/

Phil

On Tue, Dec 2, 2014 at 10:17 AM, stepharo <stepharo@free.fr> wrote:

...

Can you just tell me a bit more :)

Le 2/12/14 08:45, phil@highoctane.be a écrit :

...

I have made Ian Piumarta's GST GetOpt work in Pharo 3.0

See:

http://www.smalltalkhub.com/#!/~philippeback/GetOpt < http://www.smalltalkhub.com/#%21/%7Ephilippeback/GetOpt>

Nice tool even if we have some other support in CommandLineHandlers. But for a quick parameters setting in your own CommandLineHandler, it is fast to use and easy to debug.

Phil

On Wed, Dec 3, 2014 at 5:29 AM, Ben Coman <btc@openinworld.com> wrote:

Eliot Miranda wrote:

...

One if these, which Ben Coman's recent changes above my 64-bit microsecond clock should have fixed is a spin loop of up to a second to synchronize the second and millisecond clocks.

Is this in the image or VM ? I didn't notice this.

In the image. See secondsWhenClockTicks in Pharo 2 and Pharo 3. Its also in Squeak :-(. It is called from DateAndTime class>>#startUp: via DateAndTime class>>#initializeOffsets. It throws away on average half a second on every launch. Looks like it is not used in Pharo 4. I found these either by profiling (clock sync; I can give you a change set

...

that allows profiling across a snapshot, quit, resume) or using the VM simulator (GC to check for finalization facilities).

That would be interesting to try.

cheers -ben

-- best, Eliot