Re: [Monotone-devel] nvm.options
2010/8/14 Timothy Brownawell tbrow...@prjek.net This is changed now. --verbosity is gone, --reallyquiet and --debug are deprecated, and there's a new --verbose / -v You rock! Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 08/10/2010 12:31 PM, Derek Scherger wrote: Sorry, I've been away and I'm late to the party on this but I'm not sure I like the --verbosity, --quiet, --debug and --reallyquiet options all that much. What about this as an alternative: - default verbosity is 0 as described above - verbosity can by increased with --verbose (-v) options: -v -v or -vv would set verbosity to 2 - verbosity can be decreased with --quiet (-q) options: -q -q or -qq would set verbosity to -2 - remove --debug, --reallyquiet and --verbosity in favour of multiple -v or -q options? I basically like it, except you never know where you are. That is, if someone has their defaults set to -q or -q -q, any frontend they use needs to be able to turn warnings and progress output back on without enabling debug output, or turn warnings back on without enabling progress output, etc. Hm. We don't currently allow (remote-)automate stdio users to turn on debug mode (the messages aren't captured, and in the remote case it would probably allow too much information leakage), so just giving -v -v would always set normal mode. If a frontend wants warnings but not standard P() messages... these are sufficiently distinguished in automate stdio output, and low enough in volume, that we can say frontends just have to deal with it. So if frontends can all use 'automate stdio' for everything, then I suppose it really isn't an issue. Or we could just say, setting this option in your defaults may do bad things to frontends/scripts that don't expect it. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Timothy Brownawell tbrow...@prjek.net writes: On 08/10/2010 12:31 PM, Derek Scherger wrote: Sorry, I've been away and I'm late to the party on this but I'm not sure I like the --verbosity, --quiet, --debug and --reallyquiet options all that much. What about this as an alternative: - default verbosity is 0 as described above - verbosity can by increased with --verbose (-v) options: -v -v or -vv would set verbosity to 2 - verbosity can be decreased with --quiet (-q) options: -q -q or -qq would set verbosity to -2 - remove --debug, --reallyquiet and --verbosity in favour of multiple -v or -q options? I basically like it, except you never know where you are. That is, if someone has their defaults set to -q or -q -q, any frontend they use needs to be able to turn warnings and progress output back on without enabling debug output, or turn warnings back on without enabling progress output, etc. You could do -q -q -q -q to guarantee verbosity is at -2, then add the desired number of -v. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 08/14/2010 07:06 PM, Stephen Leake wrote: Timothy Brownawelltbrow...@prjek.net writes: On 08/10/2010 12:31 PM, Derek Scherger wrote: Sorry, I've been away and I'm late to the party on this but I'm not sure I like the --verbosity, --quiet, --debug and --reallyquiet options all that much. What about this as an alternative: - default verbosity is 0 as described above - verbosity can by increased with --verbose (-v) options: -v -v or -vv would set verbosity to 2 - verbosity can be decreased with --quiet (-q) options: -q -q or -qq would set verbosity to -2 - remove --debug, --reallyquiet and --verbosity in favour of multiple -v or -q options? I basically like it, except you never know where you are. That is, if someone has their defaults set to -q or -q -q, any frontend they use needs to be able to turn warnings and progress output back on without enabling debug output, or turn warnings back on without enabling progress output, etc. You could do -q -q -q -q to guarantee verbosity is at -2, then add the desired number of -v. Hm, hadn't though to clamp the internal verbosity number like that. This is changed now. --verbosity is gone, --reallyquiet and --debug are deprecated, and there's a new --verbose / -v . -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Thomas Keller m...@thomaskeller.biz writes: Am 23.07.10 10:42, schrieb Stephen Leake: This would be easier if the manpage code was merged into this branch. And that may have to be tweaked for this anyway, so we should wait to land this until after the manpage branch lands. Actually this would not help much, because the code in this branch specifically outputs man format, not texinfo which we'd actually need. I meant it would be nice to have the man page available while doing this work, because it's easier to search in a man page than in the current output. Moot point now, since I've done it. If we however have several use cases for structured help output, like generating a man page dynamically from it, including it in the texinfo manual and maybe even use it for the zsh / bash completion scripts in a generic way, then maybe a general dump command tree command would indeed be more suitable. But what format should that use? XML? JSON? YAML? basicio? All these formats have their pros and cons, XML being the most versatile esp. when XSLT is used, but neither format is easy to process in shell scripts. I would not try to pick a universal output format. For texinfo fragment output, I'd just write more C++ code, hopefully reusing much of your man page generation code. Using C++ container operations to walk the command/option tree, dispatching to an output function at each node, makes the most sense. Note that the texinfo fragments go in separate files; I doubt other applications will want separate files. But I suppose there will be people that want to write new code in Python instead of C++, and they could use XML output. I'm open for suggestions. Depending on the amount of work this would introduce I tend to put this task after 0.99/1.0 though. Definitely. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 08/09/2010 06:28 PM, Thomas Keller wrote: - If I increase the verbosity to 2 or set --verbosity=2, the --debug output is shown (which is reasonable, but not yet documented in the option text) Whats up with that? Now that --verbosity=1 has no effect on the above mentioned commands anymore, what does 1 switch on at all? I still note that 2 switches on the debug mode - should that now be 1? Right now --verbosity=1 doesn't do anything. I was thinking we could reserve it in case we want to allow for something less detailed than full --debug output, if you think an empty placeholder there would be too confusing we can make 1 be --debug. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Am 10.08.2010 13:51, schrieb Timothy Brownawell: On 08/09/2010 06:28 PM, Thomas Keller wrote: - If I increase the verbosity to 2 or set --verbosity=2, the --debug output is shown (which is reasonable, but not yet documented in the option text) Whats up with that? Now that --verbosity=1 has no effect on the above mentioned commands anymore, what does 1 switch on at all? I still note that 2 switches on the debug mode - should that now be 1? Right now --verbosity=1 doesn't do anything. I was thinking we could reserve it in case we want to allow for something less detailed than full --debug output, if you think an empty placeholder there would be too confusing we can make 1 be --debug. I know it would be nice if we'd have a range from -2 to 2 with 0 (the default) in the middle, but just as we recently moved the functionality which _could_ be available through 1 to --full, I don't see much justification for anything else in the future to bring that back to life. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 08/10/2010 07:03 AM, Thomas Keller wrote: Am 10.08.2010 13:51, schrieb Timothy Brownawell: On 08/09/2010 06:28 PM, Thomas Keller wrote: - If I increase the verbosity to 2 or set --verbosity=2, the --debug output is shown (which is reasonable, but not yet documented in the option text) Whats up with that? Now that --verbosity=1 has no effect on the above mentioned commands anymore, what does 1 switch on at all? I still note that 2 switches on the debug mode - should that now be 1? Right now --verbosity=1 doesn't do anything. I was thinking we could reserve it in case we want to allow for something less detailed than full --debug output, if you think an empty placeholder there would be too confusing we can make 1 be --debug. I know it would be nice if we'd have a range from -2 to 2 with 0 (the default) in the middle, but just as we recently moved the functionality which _could_ be available through 1 to --full, I don't see much justification for anything else in the future to bring that back to life. Thomas. OK, this is changed now. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Am 10.08.10 01:07, schrieb Thomas Keller: Am 09.08.10 01:49, schrieb Timothy Brownawell: These are now --no-standard-rcfiles/--standard-rcfiles and --no-builtin-rcfile/--builtin-rcfile , with --nostd/--norc marked as deprecated. Very nice. This looks much better now, though I guess some people might not like these long option names. I guess discussions will up when this lands and is released in 0.99. Thank god we're then still one release away from 1.0 to calm the waves... maybe we can also come up with some smart solution by then, like accepting partial option names just what we do with command names? The easiest would probably be to match the common prefix, so --no-st could automatically match to --no-standard-rcfiles if there are no ambigiuous options or bail out possible expansions. From what I see in the code, it should be quite easy to do in getopt() in option.cc, right? Lets see if I can accomplish that... This has been implemented and tested in 050177c529f6e183a18c8a89ada62dcd4a1b5410. From my point of view everything looks green, so if you, Tim, want to merge it to mainline, go ahead. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Timothy Brownawell tbrow...@prjek.net writes: Also I think it really doesn't need to be mixed up with the (other) verbosity options; it controls the amount of expected output, while they control error/warning/debug messages. So I dropped --version and un-deprecated --full, and separated it from the others. Looks good. - All tests pass on OSX 10.5 I fixed some Windows failures in main, propagated to nvm.options, and fixed a leftover --verbose in unit-testsuite.lua. Now all tests pass on Win32 MinGW. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Am 09.08.10 01:49, schrieb Timothy Brownawell: On 07/20/2010 06:10 PM, Thomas Keller wrote: I wished that you'd have commented a few places a bit more though for us other devs so we properly use the new / changed macros (CMD_PRESET_OPTIONS is not mentioned f.e.) and have an idea what certain code paths do (just out of my head here, the `check_by_name_insertion' function in option.cc, but there are others as well). I cannot quite follow when OPTSET_REL is needed and when not and I see that some options are grouped in an optset and some aren't (which look as they belong together somehow as well, like the options for mtn log, or all the single options which control the export format for git_export). I've added some comments on these, do they help at all? Yes, they help indeed. I slowly get a clue and thats a good thing :) Minor other things I noticed on the way: - work.cc (get_options): `opts.key_dir_given = true;` is commented out, is the given-ness of an option now implicit so that this is no longer needed? My original drive here for the code was to let an options instance which got instantiated from _MTN/options look equal to an options instance which got instantiated from command line or elsewhere, so if keydir is present in _MTN/options, its surely given in the option instance - or what do you say? This is due to the interaction between --confdir and --keydir. If --keydir is not given and --confdir is, then --keydir will default to the keys subdirectory of the given confdir. This works by the --confdir option body looking at key_dir_given; if reading the keydir from _MTN/options set that, then --confdir would stop setting the default keydir when in a workspace. Excellent explanation. I've added it in 96917638555653c858055bc810072c30034e82e1 just in case somebody else stumbles upon that. - option.hh: minor nitpick, there are two enums, one option_parse_type and one allow_xargs_t, should the former be rather named option_parse_t to match the latter and other occurences or what is the point of suffixing _t at all? (Excuse my ignorance, I just never saw that anywhere else...) This is cleaned up now. And _t is a moderately-common suffix for typenames. In particular it can help slightly when the reasonable typename is also a reasonable variable name, for example size_t size might be a bit of a pain to read if the type didn't have the _t at the end. Understood, unfortunately we do not have this common naming everywhere, e.g. the path types come into my mind, but maybe we should list this in HACKING to make the naming semi-official at least for new development...? - options_list.hh still mentions OPT / GOPT in comments, comment on top notes 4 important macros, but there are now 6 This should be fixed now. - now that we have a very fine-grained verbosity control - do we want to keep --quient and --reallyquiet as UI sugar or should we deprecate them as well for 2.0? I think --quiet is somewhat standard across programs and should probably stay just for that (same for --debug). --reallyquiet is deprecated in favor of --verbosity=-2. Ok cool. The -2 might look a bit weird, but I actually find the explanation that the default verbosity is denoted with 0 quite elegant and therefor defendable on user inquiries :) - could we find a better cancel name for norc/yesrc or make norc deprecated and introduce load-rc/no-load-rc instead? Maybe we should name them even load-rc-files/no-load-rc-files, since this would be orthogonal to the other existing option rcfile, which, otherwise, should probably be just named rc. Same with nostd and others I missed - lets move forward and deprecate these misleading / non-standard option names. If the options get too long for a simple and quick usage, lets introduce more short versions for them. These are now --no-standard-rcfiles/--standard-rcfiles and --no-builtin-rcfile/--builtin-rcfile , with --nostd/--norc marked as deprecated. Very nice. This looks much better now, though I guess some people might not like these long option names. I guess discussions will up when this lands and is released in 0.99. Thank god we're then still one release away from 1.0 to calm the waves... maybe we can also come up with some smart solution by then, like accepting partial option names just what we do with command names? The easiest would probably be to match the common prefix, so --no-st could automatically match to --no-standard-rcfiles if there are no ambigiuous options or bail out possible expansions. From what I see in the code, it should be quite easy to do in getopt() in option.cc, right? Lets see if I can accomplish that... - options.hh (enum_string): I couldn't test this because of the above problems, but the code which checks for allowed values does not look like it would honor partial strings, i.e. on a enum_string foo,bar it should bail
Re: [Monotone-devel] nvm.options
Am 23.07.10 10:42, schrieb Stephen Leake: Stephen Leake stephen_le...@stephe-leake.org writes: We could modify the description of _every_ command that now has a resettable option. Tedious, but do-able. But perhaps we should consider generating the command options from the help texts, automatically? This would be a modification of the 'mtn manpage' command. That way the info manual would be as complete as the online help. Or maybe it's ok as is. Actually not quite, e.g. mtn serve currently lists two hidden options, --stdio and --no-transport-auth, so again I think we have to go over all these sections and tweak them accordingly, I'll work on this. I've done this as well. In general, I just added [no-] (or equivalent) to the option text, without changing the descriptions. That may be confusing, but I think it's ok. I think this is ok, many thanks for your work as well! This would be easier if the manpage code was merged into this branch. And that may have to be tweaked for this anyway, so we should wait to land this until after the manpage branch lands. Actually this would not help much, because the code in this branch specifically outputs man format, not texinfo which we'd actually need. If we however have several use cases for structured help output, like generating a man page dynamically from it, including it in the texinfo manual and maybe even use it for the zsh / bash completion scripts in a generic way, then maybe a general dump command tree command would indeed be more suitable. But what format should that use? XML? JSON? YAML? basicio? All these formats have their pros and cons, XML being the most versatile esp. when XSLT is used, but neither format is easy to process in shell scripts. I'm open for suggestions. Depending on the amount of work this would introduce I tend to put this task after 0.99/1.0 though. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Am 09.08.10 01:35, schrieb Timothy Brownawell: On 07/21/2010 06:15 PM, Thomas Keller wrote: Am 21.07.10 01:10, schrieb Thomas Keller: If the compilation issue is fixed, I'll check the UI again and may come up with other little things :) Some more observations: - --verbosity changes the level between -2 and 1 (default is 0) - but I actually can't see a difference between 0 and 1. The option text for --verbose says verbose completion output, but there is no difference between $ mtn ls certs h:net.venge.monotone (verbosity 0) and $ mtn --verbose ls certs h:net.venge.monotone (verbosity 1) i.e. both output mtn: expanding selection 'h:net.venge.monotone' mtn: expanded to 'c36b63fe53580cdf51cd5c6afa42fc4a30a1d095' It only affects 'complete', 'db info', and 'version' (the commands that take --full). Also I think it really doesn't need to be mixed up with the (other) verbosity options; it controls the amount of expected output, while they control error/warning/debug messages. So I dropped --version and un-deprecated --full, and separated it from the others. Ok, this is welcome. On a slightly related note - the option --verbose has -v as short option in many other programs I know, but --verbose and -v do have completly different meanings here - is that something we want? - If I increase the verbosity to 2 or set --verbosity=2, the --debug output is shown (which is reasonable, but not yet documented in the option text) Whats up with that? Now that --verbosity=1 has no effect on the above mentioned commands anymore, what does 1 switch on at all? I still note that 2 switches on the debug mode - should that now be 1? - I dislike the alphabetic ordering of our global options, because they spread all the verbosity-related cruft - and we have six (!) options for that purpose now: -v to increase --debug to set 2 --verbose to set 1 --quiet | -q to set -1 --reallyquiet to set -2 --verbosity to set to a number between -2 and 2 This really is a bit too many. I've dropped -v (and --verbose as above), and deprecated --reallyquiet in favor of --verbosity=-2. That leaves us with just 3 in this set (--verbosity=n, --quiet, and --debug). I think --quiet and --debug should probably stay, since they're somewhat standard. This change is welcome as well. It might mitigate the next problem a bit as well. Likewise, there are other sets of related options which would look great grouped together: --key | -k / --use-default-key --keydir --confdir --no-default-confdir / --allow-default-confdir --rcfile / --clear-rcfiles --norc / --yesrc --nostd / --stdhooks --dump --log (these two could get grouped into the verbosity-related group) Is it possible to group global options further, add an empty line between each group and sort the members of a group alphabetically? Should be doable, not sure how easy it would be. Probably this would mean overloading the meaning of OPTSET/OPTSET_REL a bit, to control formatting as well as the internal convenience and resettability functions they have now. I think its a nice feature, but it shouldn't block the landing of the branch, so decide yourself if you want to put additional effort into this. - Personally I like it a bit better if the long options are broken into the next line a little earlier, i.e. not before they've taken up 50% of the available space, but already if they've taken up 33%. The change is simple to do (ui.cc, desired_namewidth divided by 3, not two), so any objections against that? That's changed. Thanks! Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 07/23/2010 03:42 AM, Stephen Leake wrote: should we hide --min/max-netsync-version? Sounds like a good idea, I've added that. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 07/21/2010 06:15 PM, Thomas Keller wrote: Am 21.07.10 01:10, schrieb Thomas Keller: If the compilation issue is fixed, I'll check the UI again and may come up with other little things :) Some more observations: - --verbosity changes the level between -2 and 1 (default is 0) - but I actually can't see a difference between 0 and 1. The option text for --verbose says verbose completion output, but there is no difference between $ mtn ls certs h:net.venge.monotone (verbosity 0) and $ mtn --verbose ls certs h:net.venge.monotone (verbosity 1) i.e. both output mtn: expanding selection 'h:net.venge.monotone' mtn: expanded to 'c36b63fe53580cdf51cd5c6afa42fc4a30a1d095' It only affects 'complete', 'db info', and 'version' (the commands that take --full). Also I think it really doesn't need to be mixed up with the (other) verbosity options; it controls the amount of expected output, while they control error/warning/debug messages. So I dropped --version and un-deprecated --full, and separated it from the others. On a slightly related note - the option --verbose has -v as short option in many other programs I know, but --verbose and -v do have completly different meanings here - is that something we want? - If I increase the verbosity to 2 or set --verbosity=2, the --debug output is shown (which is reasonable, but not yet documented in the option text) - I dislike the alphabetic ordering of our global options, because they spread all the verbosity-related cruft - and we have six (!) options for that purpose now: -v to increase --debug to set 2 --verbose to set 1 --quiet | -q to set -1 --reallyquiet to set -2 --verbosity to set to a number between -2 and 2 This really is a bit too many. I've dropped -v (and --verbose as above), and deprecated --reallyquiet in favor of --verbosity=-2. That leaves us with just 3 in this set (--verbosity=n, --quiet, and --debug). I think --quiet and --debug should probably stay, since they're somewhat standard. Likewise, there are other sets of related options which would look great grouped together: --key | -k / --use-default-key --keydir --confdir --no-default-confdir / --allow-default-confdir --rcfile / --clear-rcfiles --norc / --yesrc --nostd / --stdhooks --dump --log (these two could get grouped into the verbosity-related group) Is it possible to group global options further, add an empty line between each group and sort the members of a group alphabetically? Should be doable, not sure how easy it would be. Probably this would mean overloading the meaning of OPTSET/OPTSET_REL a bit, to control formatting as well as the internal convenience and resettability functions they have now. - Personally I like it a bit better if the long options are broken into the next line a little earlier, i.e. not before they've taken up 50% of the available space, but already if they've taken up 33%. The change is simple to do (ui.cc, desired_namewidth divided by 3, not two), so any objections against that? That's changed. - All tests pass on OSX 10.5 :) -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 07/20/2010 06:10 PM, Thomas Keller wrote: I wished that you'd have commented a few places a bit more though for us other devs so we properly use the new / changed macros (CMD_PRESET_OPTIONS is not mentioned f.e.) and have an idea what certain code paths do (just out of my head here, the `check_by_name_insertion' function in option.cc, but there are others as well). I cannot quite follow when OPTSET_REL is needed and when not and I see that some options are grouped in an optset and some aren't (which look as they belong together somehow as well, like the options for mtn log, or all the single options which control the export format for git_export). I've added some comments on these, do they help at all? Minor other things I noticed on the way: - work.cc (get_options): `opts.key_dir_given = true;` is commented out, is the given-ness of an option now implicit so that this is no longer needed? My original drive here for the code was to let an options instance which got instantiated from _MTN/options look equal to an options instance which got instantiated from command line or elsewhere, so if keydir is present in _MTN/options, its surely given in the option instance - or what do you say? This is due to the interaction between --confdir and --keydir. If --keydir is not given and --confdir is, then --keydir will default to the keys subdirectory of the given confdir. This works by the --confdir option body looking at key_dir_given; if reading the keydir from _MTN/options set that, then --confdir would stop setting the default keydir when in a workspace. - option.hh: minor nitpick, there are two enums, one option_parse_type and one allow_xargs_t, should the former be rather named option_parse_t to match the latter and other occurences or what is the point of suffixing _t at all? (Excuse my ignorance, I just never saw that anywhere else...) This is cleaned up now. And _t is a moderately-common suffix for typenames. In particular it can help slightly when the reasonable typename is also a reasonable variable name, for example size_t size might be a bit of a pain to read if the type didn't have the _t at the end. - options_list.hh still mentions OPT / GOPT in comments, comment on top notes 4 important macros, but there are now 6 This should be fixed now. - now that we have a very fine-grained verbosity control - do we want to keep --quient and --reallyquiet as UI sugar or should we deprecate them as well for 2.0? I think --quiet is somewhat standard across programs and should probably stay just for that (same for --debug). --reallyquiet is deprecated in favor of --verbosity=-2. - could we find a better cancel name for norc/yesrc or make norc deprecated and introduce load-rc/no-load-rc instead? Maybe we should name them even load-rc-files/no-load-rc-files, since this would be orthogonal to the other existing option rcfile, which, otherwise, should probably be just named rc. Same with nostd and others I missed - lets move forward and deprecate these misleading / non-standard option names. If the options get too long for a simple and quick usage, lets introduce more short versions for them. These are now --no-standard-rcfiles/--standard-rcfiles and --no-builtin-rcfile/--builtin-rcfile , with --nostd/--norc marked as deprecated. - options.hh (enum_string): I couldn't test this because of the above problems, but the code which checks for allowed values does not look like it would honor partial strings, i.e. on a enum_string foo,bar it should bail out if only fo or ar is given, but currently does not, is that right? Yep, this should be fixed now. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 07/21/2010 05:18 AM, Stephen Leake wrote: The options no-unknown/unknown are defined twice - once as SIMPLE_OPTION(unknown ...) once as OPTSET_REL(automate_inventory_opts, no_unknown) SIMPLE_OPTION(no_unknown ...) That seems like it could be a problem, but it seems to work. Yeah... those seemed to me like logically separate things that really need separate descriptions. The reason it can work, is that on the first pass (before we know what command is being run) when *all* options are allowed there's a flag that tells the option parser to not I() on duplicate options so long as they both agree on whether to take an argument. I went back the the email thread; there is one issue that was brought up but not resolved: Change --conflicts-file/--resolve-conflicts-file/--resolve-conflicts to: --resolve-conflicts resolve conflicts non-interactively --resolve-conflicts-filearg use the given file instead of _MTN/conflicts dropping --conflicts-file. But I think that's best left for another time. Sounds good to me. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] nvm.options
We added a 'deprecate option' mechanism. Deprecated options don't show up in help, even with --hidden. So far, the only option we've deprecated is --full, replaced by --verbose. That's simple enough. But I can imagine a case where someone needs to see the help for the deprecated option in order to figure out how to use the replacement option. So perhaps --hidden should show the deprecated options? or some new option --show-deprecated? Similarly, we should have deprecated commands (not in this branch). For example, privkey, pubkey, read are apparently deprecated now. It is probably more important that there be a way to show the help for deprecated commands. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Am 05.08.10 15:40, schrieb Stephen Leake: We added a 'deprecate option' mechanism. Deprecated options don't show up in help, even with --hidden. So far, the only option we've deprecated is --full, replaced by --verbose. That's simple enough. But I can imagine a case where someone needs to see the help for the deprecated option in order to figure out how to use the replacement option. So perhaps --hidden should show the deprecated options? or some new option --show-deprecated? What about documenting the deprecated options and their replacements in monotone.texi? Just showing them again won't help the user much and it would just introduce new meta code we don't want to care about much. Similarly, we should have deprecated commands (not in this branch). For example, privkey, pubkey, read are apparently deprecated now. I second the request to introduce that and it might become even more needed when we hit 1.0, so we still provide backwards compatiblity. I wouldn't go so far to deprecate privkey, pubkey and read though - these are still used to backup / export / import keys or how do you want to handle these otherwise? One might deprecate the reader functionality packets other than keys though. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Thomas Keller m...@thomaskeller.biz writes: Am 05.08.10 15:40, schrieb Stephen Leake: We added a 'deprecate option' mechanism. Deprecated options don't show up in help, even with --hidden. So far, the only option we've deprecated is --full, replaced by --verbose. That's simple enough. But I can imagine a case where someone needs to see the help for the deprecated option in order to figure out how to use the replacement option. So perhaps --hidden should show the deprecated options? or some new option --show-deprecated? What about documenting the deprecated options and their replacements in monotone.texi? Just showing them again won't help the user much and it would just introduce new meta code we don't want to care about much. That works. Similarly, we should have deprecated commands (not in this branch). For example, privkey, pubkey, read are apparently deprecated now. I second the request to introduce that and it might become even more needed when we hit 1.0, so we still provide backwards compatiblity. These could also remain in monotone.texi, marked as deprecated. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Am 26.07.10 05:40, schrieb Timothy Brownawell:
On 07/21/2010 05:25 PM, Thomas Keller wrote:
Am 21.07.10 01:10, schrieb Thomas Keller:
Am 20.07.10 04:58, schrieb Timothy Brownawell:
On 07/18/2010 08:19 AM, Stephen Leake wrote:
Tim,
Just letting you know I've been keeping up with nvm.options, and it
all
looks very good so far.
I think it's ready to merge now. See anything I missed?
The current head (44c1dd7bbc276790c51463a83823d2e1339c7ff6) fails to
compile for me:
base.hh: In function ‘void dump(const T, std::string) [with T = long
unsigned int]’:
sanity.hh:451: instantiated from ‘void MusingT::gasp(std::string)
const [with T = size_t]’
cmd.cc:640: instantiated from here
base.hh:45: error: invalid application of ‘sizeof’ to incomplete type
‘dump_must_be_specialized_for_this_type’
make[1]: *** [cmd.o] Error 1
make: *** [all] Error 2
I added a specialization for size_t in
760adcf3915f59a0ba8e2c55ea652ef29deac477 and it compiles now.
That *breaks* it here, since apparently u64 and size_t are the same
thing (while your size_t / unsigned long doesn't match u64 or u32).
TYPE_U32 is defined as `unsigned int' in my config.h and when I look at
my stddef.h then I see that size_t is defined as `long unsigned int' and
while sizeof(unsigned int) and sizeof(long unsigned int) are size-wise
equal (4, ie. 32bit), the compiler doesn't pick the u32 (unsigned int)
specialization for size_t. So maybe the bug is already that TYPE_U32
isn't defined as `unsigned long' ?
I guess we need an autoconf thingy for this?
I read a bit about size_t in general and it seems to be only defined as
unsigned integral type saying nothing about its size. I wrote a
minimal test which shows the problem:
#include iostream
using namespace std;
template typename T void dump(T const )
{ cout no specialization picked endl; }
template void dump(unsigned int const v)
{ cout uint picked: v endl; }
template void dump(unsigned long const v)
{ cout ulong picked: v endl; }
int main(int argc, char ** argv)
{
size_t t = 3;
dump(t);
return 0;
}
When I execute this on Mac OS X, I get ulong picked, when I execute
this on my Fedora VM, I get uint picked. What is now the best way to
put something like this into an autoconf macro and what should be the
result? Adding a specialization for size_t in case we detect the problem
now seems to be a bit hacky from this perspective...
Do you have an idea what code produces the problem at all? cmd.cc:640
points me to a boolean assignment. I really wonder why we didn't stumble
upon this issue earlier...
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Am 26.07.10 15:00, schrieb Thomas Keller:
Am 26.07.10 05:40, schrieb Timothy Brownawell:
On 07/21/2010 05:25 PM, Thomas Keller wrote:
Am 21.07.10 01:10, schrieb Thomas Keller:
Am 20.07.10 04:58, schrieb Timothy Brownawell:
On 07/18/2010 08:19 AM, Stephen Leake wrote:
Tim,
Just letting you know I've been keeping up with nvm.options, and it
all
looks very good so far.
I think it's ready to merge now. See anything I missed?
The current head (44c1dd7bbc276790c51463a83823d2e1339c7ff6) fails to
compile for me:
base.hh: In function ‘void dump(const T, std::string) [with T = long
unsigned int]’:
sanity.hh:451: instantiated from ‘void MusingT::gasp(std::string)
const [with T = size_t]’
cmd.cc:640: instantiated from here
base.hh:45: error: invalid application of ‘sizeof’ to incomplete type
‘dump_must_be_specialized_for_this_type’
make[1]: *** [cmd.o] Error 1
make: *** [all] Error 2
I added a specialization for size_t in
760adcf3915f59a0ba8e2c55ea652ef29deac477 and it compiles now.
That *breaks* it here, since apparently u64 and size_t are the same
thing (while your size_t / unsigned long doesn't match u64 or u32).
TYPE_U32 is defined as `unsigned int' in my config.h and when I look at
my stddef.h then I see that size_t is defined as `long unsigned int' and
while sizeof(unsigned int) and sizeof(long unsigned int) are size-wise
equal (4, ie. 32bit), the compiler doesn't pick the u32 (unsigned int)
specialization for size_t. So maybe the bug is already that TYPE_U32
isn't defined as `unsigned long' ?
I guess we need an autoconf thingy for this?
I read a bit about size_t in general and it seems to be only defined as
unsigned integral type saying nothing about its size. I wrote a
minimal test which shows the problem:
#include iostream
using namespace std;
template typename T void dump(T const )
{ cout no specialization picked endl; }
template void dump(unsigned int const v)
{ cout uint picked: v endl; }
template void dump(unsigned long const v)
{ cout ulong picked: v endl; }
int main(int argc, char ** argv)
{
size_t t = 3;
dump(t);
return 0;
}
When I execute this on Mac OS X, I get ulong picked, when I execute
this on my Fedora VM, I get uint picked. What is now the best way to
put something like this into an autoconf macro and what should be the
result? Adding a specialization for size_t in case we detect the problem
now seems to be a bit hacky from this perspective...
I've talked with Thomas Moschny and he asked on ##c++ for a proper
solution of the problem. The answers were mainly to replace all custom
type specializations with real types, i.e. basically what I did
above, so u32, u64, size_t and all the others pick the proper
specialization based on their underlying type.
Now this might introduce the problem that we forget one or two
specializations on less common platforms which worked until now, because
our autoconf machinery picks different expansions for them.
For example, for s32, s64, u32 and u64 I have defined in config.h for
Mac OS X:
int
long long
unsigned int
unsigned long long
and we probably also need (at least for Linux)
long
unsigned long
(and cross fingers that they don't collide on some platforms)
What about Solaris, Windows (visualc/config.h has hardcoded int /
unsigned int for s32 / u32) and the BSDs?
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 07/26/2010 09:14 AM, Thomas Keller wrote: I've talked with Thomas Moschny and he asked on ##c++ for a proper solution of the problem. The answers were mainly to replace all custom type specializations with real types, i.e. basically what I did above, so u32, u64, size_t and all the others pick the proper specialization based on their underlying type. Now this might introduce the problem that we forget one or two specializations on less common platforms which worked until now, because our autoconf machinery picks different expansions for them. Actually the autoconf stuff (m4/numeric_vocab.m4) seems fairly simple, it uses short, int, and either long or long long. We always need 'long' (in case of size_t etc), so the only question is whether to specialize for 'long long'. I now have it defining a test macro in case it actually uses 'long long' to get s64 since it looks like 'long long' isn't actually in the standard... not sure this is exactly right/useful, since 'long long' is the only way we try to get a 64-bit type if 'long' is 32 bits. For example, for s32, s64, u32 and u64 I have defined in config.h for Mac OS X: int long long unsigned int unsigned long long and we probably also need (at least for Linux) long unsigned long (and cross fingers that they don't collide on some platforms) What about Solaris, Windows (visualc/config.h has hardcoded int / unsigned int for s32 / u32) and the BSDs? Should all be fine, but it will want USING_LONG_LONG defined if you have 'long long' for the 64-bit types. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 07/21/2010 05:25 PM, Thomas Keller wrote: Am 21.07.10 01:10, schrieb Thomas Keller: Am 20.07.10 04:58, schrieb Timothy Brownawell: On 07/18/2010 08:19 AM, Stephen Leake wrote: Tim, Just letting you know I've been keeping up with nvm.options, and it all looks very good so far. I think it's ready to merge now. See anything I missed? The current head (44c1dd7bbc276790c51463a83823d2e1339c7ff6) fails to compile for me: base.hh: In function ‘void dump(const T, std::string) [with T = long unsigned int]’: sanity.hh:451: instantiated from ‘void MusingT::gasp(std::string) const [with T = size_t]’ cmd.cc:640: instantiated from here base.hh:45: error: invalid application of ‘sizeof’ to incomplete type ‘dump_must_be_specialized_for_this_type’ make[1]: *** [cmd.o] Error 1 make: *** [all] Error 2 I added a specialization for size_t in 760adcf3915f59a0ba8e2c55ea652ef29deac477 and it compiles now. That *breaks* it here, since apparently u64 and size_t are the same thing (while your size_t / unsigned long doesn't match u64 or u32). I guess we need an autoconf thingy for this? -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Stephen Leake stephen_le...@stephe-leake.org writes: Thomas Keller m...@thomaskeller.biz writes: As I mentioned in my earlier mail the NEWS entry should include more details what options got hidden, deprecated, replaced and / or removed exactly. Yes, this is also a tedious task, but given the fact that not mentioning it might lead to weird user experiences, especially if the information is also nowhere available else, its a must. Ok. I'll work on this. I've now done this. I added two resetting options: GROUPED_SIMPLE_OPTION(diff_options, no_show_encloser, no-show-encloser/show-encloser, bool, gettext_noop(do not show the function containing each block of changes)) SIMPLE_OPTION(no_corresponding_renames, no-corresponding-renames/corresponding-renames, bool, gettext_noop(don't output corresponding renames if restricted on such nodes)) should we hide --min/max-netsync-version? We could modify the description of _every_ command that now has a resettable option. Tedious, but do-able. But perhaps we should consider generating the command options from the help texts, automatically? This would be a modification of the 'mtn manpage' command. That way the info manual would be as complete as the online help. Or maybe it's ok as is. Actually not quite, e.g. mtn serve currently lists two hidden options, --stdio and --no-transport-auth, so again I think we have to go over all these sections and tweak them accordingly, I'll work on this. I've done this as well. In general, I just added [no-] (or equivalent) to the option text, without changing the descriptions. That may be confusing, but I think it's ok. This would be easier if the manpage code was merged into this branch. And that may have to be tweaked for this anyway, so we should wait to land this until after the manpage branch lands. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Thomas Keller m...@thomaskeller.biz writes: Am 21.07.10 12:18, schrieb Stephen Leake: We need a NEWS entry, and something in monotone.texi. How about this: NEWS New Features - Options can now be overridden; you can specify --no-unknown --unknown on the command line. Similarly, you can specify --no-unknown in the get_default_command_options hook, then change it to --unknown on the command line. As I mentioned in my earlier mail the NEWS entry should include more details what options got hidden, deprecated, replaced and / or removed exactly. Yes, this is also a tedious task, but given the fact that not mentioning it might lead to weird user experiences, especially if the information is also nowhere available else, its a must. Ok. I'll work on this. Since we have quite a few things now which we at least plan to remove in 2.0, I start to think that adding a dedicated manual section for that purpose is a good idea. What do others think about that? Yes, that makes sense. We could modify the description of _every_ command that now has a resettable option. Tedious, but do-able. But perhaps we should consider generating the command options from the help texts, automatically? This would be a modification of the 'mtn manpage' command. That way the info manual would be as complete as the online help. Or maybe it's ok as is. Actually not quite, e.g. mtn serve currently lists two hidden options, --stdio and --no-transport-auth, so again I think we have to go over all these sections and tweak them accordingly, I'll work on this. if nobody steps up and finds a good way to include at least the command calling syntax from the main program. I think that's doable, and a good idea, but probably more work than I want to sign up for right now. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Timothy Brownawell tbrow...@prjek.net writes:
On 07/20/2010 05:44 AM, Stephen Leake wrote:
Timothy Brownawelltbrow...@prjek.net writes:
On 07/18/2010 08:19 AM, Stephen Leake wrote:
Tim,
Just letting you know I've been keeping up with nvm.options, and it all
looks very good so far.
I think it's ready to merge now. See anything I missed?
The per-command defaults are not there, but that could wait for later.
Otherwise looks good.
There's a CMD_PRESET_OPTIONS that's currently only used once (for
diff). Was there supposed to be something else as well?
Ah. I totally missed that (so much for my thorough review process.
Sigh).
That looks good, and I don't think there are any other options that need
it at the moment.
The options no-unknown/unknown are defined twice - once as
SIMPLE_OPTION(unknown ...)
once as
OPTSET_REL(automate_inventory_opts, no_unknown)
SIMPLE_OPTION(no_unknown ...)
That seems like it could be a problem, but it seems to work.
I went back the the email thread; there is one issue that was brought
up but not resolved:
Change --conflicts-file/--resolve-conflicts-file/--resolve-conflicts to:
--resolve-conflicts resolve conflicts non-interactively
--resolve-conflicts-file arg use the given file instead of _MTN/conflicts
dropping --conflicts-file.
But I think that's best left for another time.
We need a NEWS entry, and something in monotone.texi. How about this:
NEWS
New Features
- Options can now be overridden; you can specify --no-unknown
--unknown on the command line. Similarly, you can specify
--no-unknown in the get_default_command_options hook, then
change it to --unknown on the command line.
monotone.texi, in Command Reference header:
Many command options come in pairs that affect the same value. For example,
@command{mtn log} takes a @var{brief} option; this can be reversed by
@var{no-brief}. This is convenient when building command strings
automatically; @command{mtn log --brief --no-brief} is the same as
@command{mtn log}.
It also helps when setting options in the
@var{get_default_command_options} hook; those options can be
overridden on the command line. For example, if
@var{get_default_command_options} specifies @var{brief} for
@command{log}, you can override that with @command{mtn log
--no-brief}.
The command descriptions describe the most important options for each
command, and only one of each pair of options. For a complete list of
options, see the online help (@command{mtn help cmd}), or the manpage.
We could modify the description of _every_ command that now has a
resettable option. Tedious, but do-able. But perhaps we should consider
generating the command options from the help texts, automatically? This
would be a modification of the 'mtn manpage' command. That way the info
manual would be as complete as the online help.
Or maybe it's ok as is.
I scanned thru the Tutorial; I did not see a good place to use an
overridden option. I don't think we want to specify the
get_default_command_options hook in the tutorial.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Timothy Brownawell tbrow...@prjek.net writes:
On 07/20/2010 05:44 AM, Stephen Leake wrote:
Timothy Brownawelltbrow...@prjek.net writes:
On 07/18/2010 08:19 AM, Stephen Leake wrote:
Tim,
Just letting you know I've been keeping up with nvm.options, and it all
looks very good so far.
I think it's ready to merge now. See anything I missed?
The per-command defaults are not there, but that could wait for later.
Otherwise looks good.
There's a CMD_PRESET_OPTIONS that's currently only used once (for
diff). Was there supposed to be something else as well?
Ah. I totally missed that (so much for my thorough review process.
Sigh).
That looks good, and I don't think there are any other options that need
it at the moment.
The options no-unknown/unknown are defined twice - once as
SIMPLE_OPTION(unknown ...)
once as
OPTSET_REL(automate_inventory_opts, no_unknown)
SIMPLE_OPTION(no_unknown ...)
That seems like it could be a problem, but it seems to work.
I went back the the email thread; there is one issue that was brought
up but not resolved:
Change --conflicts-file/--resolve-conflicts-file/--resolve-conflicts to:
--resolve-conflicts resolve conflicts non-interactively
--resolve-conflicts-file arg use the given file instead of _MTN/conflicts
dropping --conflicts-file.
But I think that's best left for another time.
We need a NEWS entry, and something in monotone.texi. How about this:
NEWS
New Features
- Options can now be overridden; you can specify --no-unknown
--unknown on the command line. Similarly, you can specify
--no-unknown in the get_default_command_options hook, then
change it to --unknown on the command line.
monotone.texi, in Command Reference header:
Many command options come in pairs that affect the same value. For example,
@command{mtn log} takes a @var{brief} option; this can be reversed by
@var{no-brief}. This is convenient when building command strings
automatically; @command{mtn log --brief --no-brief} is the same as
@command{mtn log}.
It also helps when setting options in the
@var{get_default_command_options} hook; those options can be
overridden on the command line. For example, if
@var{get_default_command_options} specifies @var{brief} for
@command{log}, you can override that with @command{mtn log
--no-brief}.
The command descriptions describe the most important options for each
command, and only one of each pair of options. For a complete list of
options, see the online help (@command{mtn help cmd}), or the manpage.
We could modify the description of _every_ command that now has a
resettable option. Tedious, but do-able. But perhaps we should consider
generating the command options from the help texts, automatically? This
would be a modification of the 'mtn manpage' command. That way the info
manual would be as complete as the online help.
Or maybe it's ok as is.
I scanned thru the Tutorial; I did not see a good place to use an
overridden option. I don't think we want to specify the
get_default_command_options hook in the tutorial.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Am 21.07.10 12:18, schrieb Stephen Leake:
We need a NEWS entry, and something in monotone.texi. How about this:
NEWS
New Features
- Options can now be overridden; you can specify --no-unknown
--unknown on the command line. Similarly, you can specify
--no-unknown in the get_default_command_options hook, then
change it to --unknown on the command line.
As I mentioned in my earlier mail the NEWS entry should include more
details what options got hidden, deprecated, replaced and / or removed
exactly. Yes, this is also a tedious task, but given the fact that not
mentioning it might lead to weird user experiences, especially if the
information is also nowhere available else, its a must.
monotone.texi, in Command Reference header:
Many command options come in pairs that affect the same value. For
example,
@command{mtn log} takes a @var{brief} option; this can be reversed by
@var{no-brief}. This is convenient when building command strings
automatically; @command{mtn log --brief --no-brief} is the same as
@command{mtn log}.
It also helps when setting options in the
@var{get_default_command_options} hook; those options can be
overridden on the command line. For example, if
@var{get_default_command_options} specifies @var{brief} for
@command{log}, you can override that with @command{mtn log
--no-brief}.
The command descriptions describe the most important options for each
command, and only one of each pair of options. For a complete list of
options, see the online help (@command{mtn help cmd}), or the manpage.
Since we have quite a few things now which we at least plan to remove in
2.0, I start to think that adding a dedicated manual section for that
purpose is a good idea. What do others think about that?
We could modify the description of _every_ command that now has a
resettable option. Tedious, but do-able. But perhaps we should consider
generating the command options from the help texts, automatically? This
would be a modification of the 'mtn manpage' command. That way the info
manual would be as complete as the online help.
Or maybe it's ok as is.
Actually not quite, e.g. mtn serve currently lists two hidden options,
--stdio and --no-transport-auth, so again I think we have to go over all
these sections and tweak them accordingly, if nobody steps up and finds
a good way to include at least the command calling syntax from the main
program.
I scanned thru the Tutorial; I did not see a good place to use an
overridden option. I don't think we want to specify the
get_default_command_options hook in the tutorial.
We don't have to pack every little feature in the tutorial, this way the
tutorial just gets bigger and bigger. Some things might as well be put
in the advanced uses section.
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Timothy Brownawell tbrow...@prjek.net writes: On 07/18/2010 08:19 AM, Stephen Leake wrote: Tim, Just letting you know I've been keeping up with nvm.options, and it all looks very good so far. I think it's ready to merge now. See anything I missed? The per-command defaults are not there, but that could wait for later. Otherwise looks good. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 07/20/2010 05:44 AM, Stephen Leake wrote: Timothy Brownawelltbrow...@prjek.net writes: On 07/18/2010 08:19 AM, Stephen Leake wrote: Tim, Just letting you know I've been keeping up with nvm.options, and it all looks very good so far. I think it's ready to merge now. See anything I missed? The per-command defaults are not there, but that could wait for later. Otherwise looks good. There's a CMD_PRESET_OPTIONS that's currently only used once (for diff). Was there supposed to be something else as well? -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Am 20.07.10 04:58, schrieb Timothy Brownawell: On 07/18/2010 08:19 AM, Stephen Leake wrote: Tim, Just letting you know I've been keeping up with nvm.options, and it all looks very good so far. I think it's ready to merge now. See anything I missed? The current head (44c1dd7bbc276790c51463a83823d2e1339c7ff6) fails to compile for me: base.hh: In function ‘void dump(const T, std::string) [with T = long unsigned int]’: sanity.hh:451: instantiated from ‘void MusingT::gasp(std::string) const [with T = size_t]’ cmd.cc:640: instantiated from here base.hh:45: error: invalid application of ‘sizeof’ to incomplete type ‘dump_must_be_specialized_for_this_type’ make[1]: *** [cmd.o] Error 1 make: *** [all] Error 2 Other than that, tremendous work again from what I see in the code! I particularily like the functionality to hide internal options like bind_stdio, so they stop cluttering the namespace and do not confuse the user. The SIMPLE_OPTION macro with its support for enumerated values and sets and of course simple types makes it far easier to add new options. Finally, the unification of the option handling / command processing for automate stdio and friends is also very welcome, though its a bit out of scope for this branch. I wished that you'd have commented a few places a bit more though for us other devs so we properly use the new / changed macros (CMD_PRESET_OPTIONS is not mentioned f.e.) and have an idea what certain code paths do (just out of my head here, the `check_by_name_insertion' function in option.cc, but there are others as well). I cannot quite follow when OPTSET_REL is needed and when not and I see that some options are grouped in an optset and some aren't (which look as they belong together somehow as well, like the options for mtn log, or all the single options which control the export format for git_export). And I miss a NEWS entry which tells the user about the option changes, i.e. which options got deprecated, which got removed, which got replaced, which got hidden, aso. Minor other things I noticed on the way: - work.cc (get_options): `opts.key_dir_given = true;` is commented out, is the given-ness of an option now implicit so that this is no longer needed? My original drive here for the code was to let an options instance which got instantiated from _MTN/options look equal to an options instance which got instantiated from command line or elsewhere, so if keydir is present in _MTN/options, its surely given in the option instance - or what do you say? - option.hh: minor nitpick, there are two enums, one option_parse_type and one allow_xargs_t, should the former be rather named option_parse_t to match the latter and other occurences or what is the point of suffixing _t at all? (Excuse my ignorance, I just never saw that anywhere else...) - options_list.hh still mentions OPT / GOPT in comments, comment on top notes 4 important macros, but there are now 6 - now that we have a very fine-grained verbosity control - do we want to keep --quient and --reallyquiet as UI sugar or should we deprecate them as well for 2.0? - could we find a better cancel name for norc/yesrc or make norc deprecated and introduce load-rc/no-load-rc instead? Maybe we should name them even load-rc-files/no-load-rc-files, since this would be orthogonal to the other existing option rcfile, which, otherwise, should probably be just named rc. Same with nostd and others I missed - lets move forward and deprecate these misleading / non-standard option names. If the options get too long for a simple and quick usage, lets introduce more short versions for them. - options.hh (enum_string): I couldn't test this because of the above problems, but the code which checks for allowed values does not look like it would honor partial strings, i.e. on a enum_string foo,bar it should bail out if only fo or ar is given, but currently does not, is that right? If the compilation issue is fixed, I'll check the UI again and may come up with other little things :) Thanks for your work so far! Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
On 07/18/2010 08:19 AM, Stephen Leake wrote: Tim, Just letting you know I've been keeping up with nvm.options, and it all looks very good so far. I think it's ready to merge now. See anything I missed? -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] nvm.options
Tim, Just letting you know I've been keeping up with nvm.options, and it all looks very good so far. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
