On Wed, Dec 3, 2014 at 9:51 AM, Eliot Miranda <[email protected]> wrote:
> Hi Phil, > > On Dec 2, 2014, at 2:18 AM, "[email protected]" <[email protected]> > 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 <[email protected]> wrote: > >> Can you just tell me a bit more :) >> >> Le 2/12/14 08:45, [email protected] 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 >>> >>> >>> >>> >> >> >
