search for: optiongroup

I was thinking about this more, and perhaps a more preferable solution would have some kind of OptionGroup parameter to constructors of cl options. This would of course be optional, with the default being a global one. Then, ParseCommandLineOptions() could instead take as an optional parameter an OptionGroup, and would then only work on cl options in that group. Would this approach be preferable? -Ale...

...<handler>name</handler> etc... </matchhandler> *Option Group* Some plugins and the core have options which work in groups. Hints can be provided to group these options so that configuration tools will be able to display them as a grid rather than as individual options. <optiongroup> <option name="opacity_match" /> <option name="opacity_values" /> </optiongroup> *Web based information* I think it would be a very nice feature to add some web based attributes which means things can be easily updated without the user updating the...

On Mar 4, 2009, at 12:15 AM, Alexei Svitkine wrote: > I was thinking about this more, and perhaps a more preferable solution > would have some kind of OptionGroup parameter to constructors of cl > options. This would of course be optional, with the default being a > global one. Hi Alexei, Sorry for the delay, I've been swamped lately and tend to process email in LIFO order :( > Then, ParseCommandLineOptions() could instead take as an option...

I don't have any opinions about this. Chris? Evan On Feb 17, 2009, at 8:00 PM, Alexei Svitkine wrote: > The motivation behind this patch is that tools that use LLVM as a > library and want to use its command line parsing facilities may not > want all the various options defined in the LLVM libraries to be > available - simply because they may not be relevant. > > This patch

...ommands[subcommand]._run( File "/usr/local/samba/lib/python2.4/site-packages/samba/netcmd/__init__.py", line 201, in _run return self.subcommands[subcommand]._run( File "/usr/local/samba/lib/python2.4/site-packages/samba/netcmd/__init__.py", line 142, in _run parser, optiongroups = self._create_parser(argv[0]) File "/usr/local/samba/lib/python2.4/site-packages/samba/netcmd/__init__.py", line 130, in _create_parser prog=prog,epilog=epilog) Are there any links for those successfully upgrade their samba 3 to samba 4? Regards, Mario

...I am thinking of consolidating the common options shared across all the Unix variant flavors in CommonOptions.td. > > The options that are shared between Darwin/GnuLD are :- > > a) -o > b) -L > c) -emit-yaml > d) --help > e) -mllvm > That would make it difficult to use OptionGroup (as darwin driver has) so the —help output is organized. Also, the windows driver uses ‘/‘ so its entries use F<> instead of Flag<>, so I not sure how you can factor these out. It also means that when looking at possible options, you’d have to look in two files instead of one. >...

The motivation behind this patch is that tools that use LLVM as a library and want to use its command line parsing facilities may not want all the various options defined in the LLVM libraries to be available - simply because they may not be relevant. This patch adds an optional "Prefix" parameter to ParseCommandLineOptions(). If set, this will make inaccessible any options that do not

...at I'm interested in). -Alexei On Mon, Mar 9, 2009 at 12:14 AM, Chris Lattner <clattner at apple.com> wrote: > On Mar 4, 2009, at 12:15 AM, Alexei Svitkine wrote: >> >> I was thinking about this more, and perhaps a more preferable solution >> would have some kind of OptionGroup parameter to constructors of cl >> options. This would of course be optional, with the default being a >> global one. > > Hi Alexei, > > Sorry for the delay, I've been swamped lately and tend to process email in > LIFO order :( > >> Then, ParseCommandLineOpti...

Hi Nick, There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. As the first step, I am thinking of consolidating the common options shared across all the Unix variant flavors in CommonOptions.td. The options that are shared between Darwin/GnuLD are :- a) -o b) -L c)

Hi all, i tried to set up the helper method "grouped_programs_selector" in application_helpers.rb. Since i dont have a deep understanding of Ruby itself, I pretty much copied the Grouped Selection List (Chapter 17, pp. 259, 260) example from Dave & David''s Book. The optiongroups are properly created by my method, but there are no options inside. Maybe you can debug this one? -snip- from index.rhtml <%= option_groups_from_collection_for_select( grouped_programs_selector(:programs, :programtypes), # calling application_helper - method. :options, :type_name, :id,...

...mon options shared across all the Unix variant flavors in CommonOptions.td. >> >> The options that are shared between Darwin/GnuLD are :- >> >> a) -o >> b) -L >> c) -emit-yaml >> d) --help >> e) -mllvm >> > That would make it difficult to use OptionGroup (as darwin driver has) so the —help output is organized. Also, the windows driver uses ‘/‘ so its entries use F<> instead of Flag<>, so I not sure how you can factor these out. It also means that when looking at possible options, you’d have to look in two files instead of one. Ah ok....

Hi, A feature I've wanted in lit for a while is a having a timeout per test. Attached are patches that implement this idea. I'm e-mailing llvm-dev rather than llvm-commits because I want to gather more feedback on my initial implementation and hopefully some answers to some unresolved issues with my implementation. Currently in lit you can set a global timeout for all of the tests but