Hi,

this really sounds like a discussion on the color of the bike shed.
Anyway...

On Saturday 28 May 2011, WAROQUIERS Philippe wrote:
> >> Is there a need for vgdb to stick with 2 letters? I much would prefer "clg"
> >> instead. Since years I use the alias clg='valgrind --tool=callgrind', and 
> >> in
> >> the callgrind sources I use the CLG_ prefix quite often.
> >> 
> >
> >I agree with Josef it would be best if we could drop the
> >2-letter-acronym requirement.

While not important in this context, these 2-letter-acronyms are
used a lot in the source, e.g. used in
  cachegrind/cg_main.c
  MC_(clo_mc_level)
  VG_IS_TOOL_USERREQ('M','C',arg[0])

But the only place where they get user-visible is with
  cg_{merge,diff,annotate}
and now with the vgdb commands.

> >My preference would be to use the tool
> >name instead (and not some form of abbreviation). That increases
> >usability as it eliminates all confusion. I fail to see the value of
> >having to use an abbreviated tool name in certain contexts. It's just
> >one more thing to remember. And it's not clear to me what the value is
> >in return.

Of course faster typing. Does not matter in a shell with autocompletion,
but for vgdb/gdb promt (?). On the other hand, we do not support

 valgrind --tool=cg ...


> The 2 letters is just a convention, we can use more letters.
> 
> The only "requirement" are:
>   * it should be non-ambiguous, i.e. it is better to have
>     a command for a certain tool to not be confused with a command
>     from another tool or with a standard core valgrind command.
>     So, the idea was that standard core commands are starting
>     with vg. while tool commands starts with their own unique
>     prefix (e.g. mc. ms. and the to be chosen for callgrind).

I see.

Hmm... vgdb only relays to one tool instance. While I see that
having a separate namespace for core commands can be useful, we
do not really do something like that for command line options, too
(I see some exceptions: --vgdb-poll, but also --cachegrind-out-file).

>     The main reason to have short prefix is that that such commands
>     are typed often, and the prefix must be typed in full.

Do we really need that prefix?

Comparing with "--help", which outputs command line help for both
valgrind core and the tool, it even could make sense to support
"monitor set ..." for both valgrind core and tool settings without
using a prefix.

> So, for callgrind, we can use clg.  as suggested by Josef
> or use cl or ...

Having to remember that "cg" was cachegrind and "clg" was callgrind
is a further burden to the user, and easily gets confusing.

If we can avoid that issue, we should do it. On the command line,
there is no way: valgrind commands compete with all other commands on the
system, and using "<tool>_foo" really seems better than
"<2-letter-acronym of tool>_foo".

But for vgdb commands, I now do not really see a need for the prefix.
As we have our own namespace, we can simply avoid conflicts without a prefix.
And for that matter, "vgdb d" is even faster to type than "vgdb ct.d".
I also find it more natural to say "gdb set instrumentation off" for the
according callgrind_control command.

> I would not like long commands (and/or long arguments that are
> ambiguous unless you type many of the leading characters).

Me too.

Josef

> But if I am in the very few that likes short things to type, I can
> survive with long prefixes and start typing
>    list-files-in-directories --output-long-format-with-dates :).
> (of course, I like a lot the gnu convention to have both short and
> long option names, but that looks an overkill for gdbsrv in valgrind).
> 
> Philippe
> 
> 
> ____
>  
> This message and any files transmitted with it are legally privileged and 
> intended for the sole use of the individual(s) or entity to whom they are 
> addressed. If you are not the intended recipient, please notify the sender by 
> reply and delete the message and any attachments from your system. Any 
> unauthorised use or disclosure of the content of this message is strictly 
> prohibited and may be unlawful.
>  
> Nothing in this e-mail message amounts to a contractual or legal commitment 
> on the part of EUROCONTROL, unless it is confirmed by appropriately signed 
> hard copy.
>  
> Any views expressed in this message are those of the sender.
> 
> 


------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to