clops-users

[Clops-users] usage after parsing

[David W <di...@ho...>]

The main question that I have is what would be the most efficient way to dispatch on options?

The CLI that I'm working on basically consists of two levels of options--commands and options. The best analogy is something like Busybox, where there's a single binary (in this case jar file) that implements multiple commands, each with its own set of options (if any).

So to be more concrete, in the "ARGS" section of the CLOPS file, I have command1 through commandN defined. I can check for the presence of a single command via iscommandNSet(). I'm wondering if there's a more efficient way of dispatching or testing for the command instead of doing a massive if/else-if statement, perhaps with enums or something (the enum could be used to create a proper subclass corresponding to a specific command). I would almost be tempted to define an enum with the same command names, create the correct method name programmatically (prepend "is" and append "Set" to the enum value), and then iterate through the list of enums, calling the automatically-generated method for checking to return back the correct enum.

Basically, any pointers or suggestions at this point would be great. Normally I would ruminate on this for a bit, but I'm in a crunch situation and would appreciate some pointers. Thanks.

_________________________________________________________________
Rediscover Hotmail®: Get e-mail storage that grows with you. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Storage2_042009

Re: [Clops-users] usage after parsing

[Fintan F. <fi...@gm...>]

Hi David,

Thanks for the question. If I understand you correctly, what I would
recommend is this:

-Create a "virtual option" (i.e. an option that is not reachable in the
FORMAT:: section, but is defined in ARGS::) of type "enum".
e.g.
  ChosenCommand:{}:{enum}:[choices="CMD1,CMD2,CMD3"]

-Create some fly rules to set the ChosenCommand option when any of your
commands are set. I'm not sure if you know about fly rules, but they are
rules that can are triggered when a certain option is set.
e.g.
  CMD1 {$(CMD1)} -> ChosenCommand := {"CMD1"};

There's quite a bit going on in that example, so I'll break it down. The
first CMD1 indicates that it is a rule that should be fired when option CMD1
is set. The curly braces are used to delimit where you can write arbitrary
Java code. In the first case the code must be a boolean expression. In the
second case it is an expression that is of the correct type for the object
we are assigning to, which in this case is a String for ChosenCommand.

You could read the whole rule as: If CMD1 is set then check if CMD1 is true.
If it is true set ChosenCommand to the value "CMD1".

The $(CMD1) inside the braces is a placeholder that is converted into code
that gets the value for the CMD1 option. I'm assuming your commands are all
boolean options? If they are booleans and you are not allowing the user to
write CMD1=false (disallow by setting property allowarg="false" in the
option definition), then you can omit the {$(CMD1)} as this will always be
true. Thus:
  CMD1 -> ChosenCommand := {"CMD1"};

-In the code where you direct the program's execution by the option values,
you can simply get the value of the option ChosenCommand. Note that if you
use the enum option type, we automatically generate an enum with the choices
you provided in the option's specification. The enum definition will appear
in the generated OptionInterface, and will be the return type for the
getChosenCommand() method.

I hope I've answered your question. If any of the above is not clear, or you
want to know more, just ask.

Cheers,

Fintan

On Thu, Apr 30, 2009 at 4:47 PM, David W <di...@ho...> wrote:

>  The main question that I have is what would be the most efficient way to
> dispatch on options?
>
> The CLI that I'm working on basically consists of two levels of
> options--commands and options. The best analogy is something like Busybox,
> where there's a single binary (in this case jar file) that implements
> multiple commands, each with its own set of options (if any).
>
> So to be more concrete, in the "ARGS" section of the CLOPS file, I have
> command1 through commandN defined. I can check for the presence of a single
> command via iscommandNSet(). I'm wondering if there's a more efficient way
> of dispatching or testing for the command instead of doing a massive
> if/else-if statement, perhaps with enums or something (the enum could be
> used to create a proper subclass corresponding to a specific command). I
> would almost be tempted to define an enum with the same command names,
> create the correct method name programmatically (prepend "is" and append
> "Set" to the enum value), and then iterate through the list of enums,
> calling the automatically-generated method for checking to return back the
> correct enum.
>
> Basically, any pointers or suggestions at this point would be great.
> Normally I would ruminate on this for a bit, but I'm in a crunch situation
> and would appreciate some pointers. Thanks.
>
> ------------------------------
> Rediscover Hotmail®: Get e-mail storage that grows with you. Check it out.<http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Storage2_042009>
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>
>

Re: [Clops-users] usage after parsing

[David W <di...@ho...>]

Fintan, thanks. I hadn't even looked at the fly rules and didn't
realize how powerful they could be. I tried out what you described and
that worked.

I don't suppose there would be a way to use fly
rules and virtual options to create a new instance of a user defined
object? With the method mentioned previously, I would just need to pass
an enum value to a factory if I needed to create objects of a specific
type. I was wondering if I could even bypass the creation of this
factory and have CLOPS return back a new object of the type that I need
(they would all be subclasses of a single base class). So basically, it
would be nice if I could define an arg with type "Command" and then be
able to return back "CMD1Command" and "CMD2Command" depending on which
command was set.

Date: Thu, 30 Apr 2009 19:14:44 +0100
Subject: Re: [Clops-users] usage after parsing
From: fi...@gm...
To: di...@ho...
CC: clo...@li...

Hi David,

Thanks for the question. If I understand you correctly, what I would recommend is this:

-Create a "virtual option" (i.e. an option that is not reachable in the FORMAT:: section, but is defined in ARGS::) of type "enum".

e.g.
  ChosenCommand:{}:{enum}:[choices="CMD1,CMD2,CMD3"]

-Create some fly rules to set the ChosenCommand option when any of your commands are set. I'm not sure if you know about fly rules, but they are rules that can are triggered when a certain option is set. 

e.g.
  CMD1 {$(CMD1)} -> ChosenCommand := {"CMD1"};

There's quite a bit going on in that example, so I'll break it down. The first CMD1 indicates that it is a rule that should be fired when option CMD1 is set. The curly braces are used to delimit where you can write arbitrary Java code. In the first case the code must be a boolean expression. In the second case it is an expression that is of the correct type for the object we are assigning to, which in this case is a String for ChosenCommand.


You could read the whole rule as: If CMD1 is set then check if CMD1 is
true. If it is true set ChosenCommand to the value "CMD1".

The $(CMD1) inside the braces is a placeholder that is converted into code that gets the value for the CMD1 option. I'm assuming your commands are all boolean options? If they are booleans and you are not allowing the user to write CMD1=false (disallow by setting property allowarg="false" in the option definition), then you can omit the {$(CMD1)} as this will always be true. Thus:

  CMD1 -> ChosenCommand := {"CMD1"};

-In the code where you direct the program's execution by the option values, you can simply get the value of the option ChosenCommand. Note that if you use the enum option type, we automatically generate an enum with the choices you provided in the option's specification. The enum definition will appear in the generated OptionInterface, and will be the return type for the getChosenCommand() method.


I hope I've answered your question. If any of the above is not clear, or you want to know more, just ask.

Cheers,

Fintan


_________________________________________________________________
Rediscover Hotmail®: Get e-mail storage that grows with you. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Storage2_042009

Re: [Clops-users] usage after parsing

[Mikoláš J. <mik...@gm...>]

Hi David,

  technically this is possible as you can extend the option types
yourself and the rules can contain any java code.

However, it's something that I'd discourage you from doing as the
CLOPS file was meant to be as Java-independent as possible and should
express only the logic of options, not the program. There's always a
blurry line between the program and option processing, so this is a
matter of personal opinion.

mikolas

On Fri, May 1, 2009 at 12:22 AM, David W <di...@ho...> wrote:
> Fintan, thanks. I hadn't even looked at the fly rules and didn't realize how
> powerful they could be. I tried out what you described and that worked.
>
> I don't suppose there would be a way to use fly rules and virtual options to
> create a new instance of a user defined object? With the method mentioned
> previously, I would just need to pass an enum value to a factory if I needed
> to create objects of a specific type. I was wondering if I could even bypass
> the creation of this factory and have CLOPS return back a new object of the
> type that I need (they would all be subclasses of a single base class). So
> basically, it would be nice if I could define an arg with type "Command" and
> then be able to return back "CMD1Command" and "CMD2Command" depending on
> which command was set.
>
> ________________________________
> Date: Thu, 30 Apr 2009 19:14:44 +0100
> Subject: Re: [Clops-users] usage after parsing
> From: fi...@gm...
> To: di...@ho...
> CC: clo...@li...
>
> Hi David,
>
> Thanks for the question. If I understand you correctly, what I would
> recommend is this:
>
> -Create a "virtual option" (i.e. an option that is not reachable in the
> FORMAT:: section, but is defined in ARGS::) of type "enum".
> e.g.
>   ChosenCommand:{}:{enum}:[choices="CMD1,CMD2,CMD3"]
>
> -Create some fly rules to set the ChosenCommand option when any of your
> commands are set. I'm not sure if you know about fly rules, but they are
> rules that can are triggered when a certain option is set.
> e.g.
>   CMD1 {$(CMD1)} -> ChosenCommand := {"CMD1"};
>
> There's quite a bit going on in that example, so I'll break it down. The
> first CMD1 indicates that it is a rule that should be fired when option CMD1
> is set. The curly braces are used to delimit where you can write arbitrary
> Java code. In the first case the code must be a boolean expression. In the
> second case it is an expression that is of the correct type for the object
> we are assigning to, which in this case is a String for ChosenCommand.
>
> You could read the whole rule as: If CMD1 is set then check if CMD1 is true.
> If it is true set ChosenCommand to the value "CMD1".
>
> The $(CMD1) inside the braces is a placeholder that is converted into code
> that gets the value for the CMD1 option. I'm assuming your commands are all
> boolean options? If they are booleans and you are not allowing the user to
> write CMD1=false (disallow by setting property allowarg="false" in the
> option definition), then you can omit the {$(CMD1)} as this will always be
> true. Thus:
>   CMD1 -> ChosenCommand := {"CMD1"};
>
> -In the code where you direct the program's execution by the option values,
> you can simply get the value of the option ChosenCommand. Note that if you
> use the enum option type, we automatically generate an enum with the choices
> you provided in the option's specification. The enum definition will appear
> in the generated OptionInterface, and will be the return type for the
> getChosenCommand() method.
>
> I hope I've answered your question. If any of the above is not clear, or you
> want to know more, just ask.
>
> Cheers,
>
> Fintan
>
>
> ________________________________
> Rediscover Hotmail®: Get e-mail storage that grows with you. Check it out.
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>
>



-- 
Mikoláš Janota M. Sc.
School of Computer Science and Informatics,
University College Dublin,
Belfield,
Dublin 4,
Ireland

Re: [Clops-users] usage after parsing

[Fintan F. <fi...@gm...>]

I'd agree with Mikolas, but for slightly different reasons.

Extending the option types, by providing your own custom option class is
possible but will take a reasonable amount of work, largely in sufficiently
understanding the mechanisms involved in order to do so. I wouldn't advise
it in this case.

Even if you were to create a custom class, it will not be more succinct and
barely more efficient than creating a simple method that takes the created
option enum type as an argument, and returns an instance of the type that
you want (the body of the method just being a switch statement with each
case creating and returning the appropriate subclass type).

Hope this helps,

Fintan

On Fri, May 1, 2009 at 1:25 PM, Mikoláš Janota <mik...@gm...>wrote:

> Hi David,
>
>  technically this is possible as you can extend the option types
> yourself and the rules can contain any java code.
>
> However, it's something that I'd discourage you from doing as the
> CLOPS file was meant to be as Java-independent as possible and should
> express only the logic of options, not the program. There's always a
> blurry line between the program and option processing, so this is a
> matter of personal opinion.
>
> mikolas
>
> On Fri, May 1, 2009 at 12:22 AM, David W <di...@ho...> wrote:
> > Fintan, thanks. I hadn't even looked at the fly rules and didn't realize
> how
> > powerful they could be. I tried out what you described and that worked.
> >
> > I don't suppose there would be a way to use fly rules and virtual options
> to
> > create a new instance of a user defined object? With the method mentioned
> > previously, I would just need to pass an enum value to a factory if I
> needed
> > to create objects of a specific type. I was wondering if I could even
> bypass
> > the creation of this factory and have CLOPS return back a new object of
> the
> > type that I need (they would all be subclasses of a single base class).
> So
> > basically, it would be nice if I could define an arg with type "Command"
> and
> > then be able to return back "CMD1Command" and "CMD2Command" depending on
> > which command was set.
>

Re: [Clops-users] usage after parsing

[David W <di...@ho...>]

Yes, I can see both of your points. In any case, the recommended method
is reasonably clean and consolidated. I will be occupied for a while
with adding all the commands and options and the other cleanup that
needs to be done, but I figured I would ask another question looking
forward.

What are your thoughts or advice on generating
documentation or help. I haven't read in great detail about this yet,
so I don't know if there's much control over the documentation format.
At the least, our documentation person will create a user's guide for
the CLI. It would also be nice for the complete usage to be pretty
printed if help is specified on the command line or if there was an
error with an option. Is the generated documentation capable of this or
was it meant more functional--to make the CLOPS specification file more
readable?


Date: Fri, 1 May 2009 22:20:55 +0100
From: fi...@gm...
To: clo...@li...
Subject: Re: [Clops-users] usage after parsing

I'd agree with Mikolas, but for slightly different reasons.

Extending
the option types, by providing your own custom option class is possible
but will take a reasonable amount of work, largely in sufficiently
understanding the mechanisms involved in order to do so. I wouldn't
advise it in this case.


Even if you were to create a custom class, it will not be more
succinct and barely more efficient than creating a simple method that
takes the created option enum type as an argument, and returns an
instance of the type that you want (the body of the method just being a
switch statement with each case creating and returning the appropriate
subclass type).


Hope this helps,

Fintan


_________________________________________________________________
Windows Live™ Hotmail®:…more than just e-mail.
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_more_042009

Re: [Clops-users] usage after parsing

[Mikoláš J. <mik...@gm...>]

Hi David,

   the docs are generated via Velocity templates. Velocity is an
apache project, very similar to the C preprocessor
(http://velocity.apache.org/). There are several predefined templates
in the templates directory but you can define any template you want
and pass it as an argument to clops.

  Personally, I'm not too happy about printing rules, I think we could
improve it but still it seems difficult.

I think the templates that are in the project should give you an idea
what you can do (start by all.vm, help.vm), but of course, if you have
any questions let us know.

Regards,
  mikolas

On Sat, May 2, 2009 at 3:47 AM, David W <di...@ho...> wrote:
> Yes, I can see both of your points. In any case, the recommended method is
> reasonably clean and consolidated. I will be occupied for a while with
> adding all the commands and options and the other cleanup that needs to be
> done, but I figured I would ask another question looking forward.
>
> What are your thoughts or advice on generating documentation or help. I
> haven't read in great detail about this yet, so I don't know if there's much
> control over the documentation format. At the least, our documentation
> person will create a user's guide for the CLI. It would also be nice for the
> complete usage to be pretty printed if help is specified on the command line
> or if there was an error with an option. Is the generated documentation
> capable of this or was it meant more functional--to make the CLOPS
> specification file more readable?
>
>
> ________________________________
> Date: Fri, 1 May 2009 22:20:55 +0100
> From: fi...@gm...
> To: clo...@li...
> Subject: Re: [Clops-users] usage after parsing
>
> I'd agree with Mikolas, but for slightly different reasons.
>
> Extending the option types, by providing your own custom option class is
> possible but will take a reasonable amount of work, largely in sufficiently
> understanding the mechanisms involved in order to do so. I wouldn't advise
> it in this case.
>
> Even if you were to create a custom class, it will not be more succinct and
> barely more efficient than creating a simple method that takes the created
> option enum type as an argument, and returns an instance of the type that
> you want (the body of the method just being a switch statement with each
> case creating and returning the appropriate subclass type).
>
> Hope this helps,
>
> Fintan
>
>
> ________________________________
> Windows Live™ Hotmail®:…more than just e-mail. Check it out.
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>
>



-- 
Mikoláš Janota M. Sc.
School of Computer Science and Informatics,
University College Dublin,
Belfield,
Dublin 4,
Ireland