Menu
▾
▴
clops-users
|
From: Mikoláš J. <mik...@gm...> - 2009-08-08 23:20:39
|
I still don't understand what blankParamAllowed is good for. At the moment is just checked in process but argumentshape can take care of that. One possibility would be for the property to set between and argumentshape somehow. But I'm not quite sure how plus I don't like too much the overlaps between properties. I'd suggest to get rid of the property all together. -- Mikoláš |
|
From: Radu G. <rad...@gm...> - 2009-08-11 15:09:29
|
On Sun, Aug 9, 2009 at 12:20 AM, Mikoláš Janota<mik...@gm...> wrote: > I still don't understand what blankParamAllowed is good for. The error message "option X needs an argument" is better than "i don't know what this option is". |
|
From: Fintan F. <fi...@gm...> - 2009-08-11 20:21:46
|
Yes, this is it exactly. By having a boolean property to control this, we allow the option to match regardless of whether the argument is blank (empty string) in the option's regexp. Then, when we process we can give a useful error message if we do not allow blank arguments. If we do allow blank arguments, we just proceed. This raises an issue though. In the infinite lookahead parser we don't use process, so this case (and the interaction with using the newly introduced "defaultVal") must be handled separately. On Tue, Aug 11, 2009 at 4:09 PM, Radu Grigore <rad...@gm...> wrote: > On Sun, Aug 9, 2009 at 12:20 AM, Mikoláš Janota<mik...@gm...> > wrote: > > I still don't understand what blankParamAllowed is good for. > > The error message "option X needs an argument" is better than "i don't > know what this option is". > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Clops-users mailing list > Clo...@li... > https://lists.sourceforge.net/lists/listinfo/clops-users > |
|
From: Mikoláš J. <mik...@gm...> - 2009-08-11 21:06:53
|
On Tue, Aug 11, 2009 at 4:09 PM, Radu Grigore<rad...@gm...> wrote: > On Sun, Aug 9, 2009 at 12:20 AM, Mikoláš Janota<mik...@gm...> wrote: >> I still don't understand what blankParamAllowed is good for. > > The error message "option X needs an argument" is better than "i don't > know what this option is". > How's this different from head -nBAZOOM, ie the arg is there but it's not a digit? We can of course print an empty string in some different fashion than BAZOOM but I don't see the need for the blank param allowed property. I thought that that getMatchingOption says that the option matched and parse that it didn't work out for exactly this reason. As Fint noted, in infinite lookahead this is more trouble. -- Mikoláš |
|
From: Radu G. <rad...@gm...> - 2009-08-12 11:56:56
|
On Tue, Aug 11, 2009 at 10:06 PM, Mikoláš Janota<mik...@gm...> wrote: > How's this different from > head -nBAZOOM, ie the arg is there but it's not a digit? You get a different error message (unless there's a default value set). > As Fint noted, in infinite lookahead this is more trouble. The check should be moved out of process(), yes. In general, process() needs to be deprecated if we want to be able to keep the parsers in sync. |
|
From: Mikoláš J. <mik...@gm...> - 2009-08-12 14:14:58
|
On Wed, Aug 12, 2009 at 12:56 PM, Radu Grigore<rad...@gm...> wrote: > On Tue, Aug 11, 2009 at 10:06 PM, Mikoláš > Janota<mik...@gm...> wrote: >> How's this different from >> head -nBAZOOM, ie the arg is there but it's not a digit? > > You get a different error message (unless there's a default value set). > I don't understand. I was saying that both -nBAZOOM and -n"" are bad arguments. We might decide to print something else than "". We could say something like "empty argument is not valid for -n" when we get "" instead of "BAZOOM" In other words, !blankparamallowed can be derived from the fact that the option matched, didn't parse, and the string corresponding to the argument is empty. --m >> As Fint noted, in infinite lookahead this is more trouble. > > The check should be moved out of process(), yes. In general, process() > needs to be deprecated if we want to be able to keep the parsers in > sync. > -- Mikoláš Janota M. Sc. School of Computer Science and Informatics, University College Dublin, Belfield, Dublin 4, Ireland |
|
From: Radu G. <rad...@gm...> - 2009-08-12 12:36:39
|
On Wed, Aug 12, 2009 at 1:21 PM, Mikoláš Janota<mik...@gm...> wrote: > In other words, !blankparamallowed can be derived from the fact that > the option matched, didn't parse, and the string corresponding to the > argument is empty. That's how it used to work: IntegerOption.convertStringToValue does exactly that. In that case string options need to be handled with validity constraints, while integer options do not need a validity constraint. A small issue with this is that convertStringToValue doesn't know the text that matched on the prefix, so it can't say (now) "option -foo requires an argument", where "-foo" is the particular alias that was typed. |
|
From: Mikoláš J. <mik...@gm...> - 2009-08-12 12:59:04
|
>From what you are saying I can't figure out the difference between a
blank arg and malformed arg. And I believe that differentiating them
is a bad design.
Nevertheless, we seem to have a problem as "tail -nBAZOOM" gives me
Illegal option: -nBAZOOM
This means we don't handle well malformed args. The blankparamallowed
is just a heck that makes it work well if the malformed arg is a
blank.
m.
On Wed, Aug 12, 2009 at 1:36 PM, Radu Grigore<rad...@gm...> wrote:
> On Wed, Aug 12, 2009 at 1:21 PM, Mikoláš Janota<mik...@gm...> wrote:
>> In other words, !blankparamallowed can be derived from the fact that
>> the option matched, didn't parse, and the string corresponding to the
>> argument is empty.
>
> That's how it used to work: IntegerOption.convertStringToValue does
> exactly that. In that case string options need to be handled with
> validity constraints, while integer options do not need a validity
> constraint. A small issue with this is that convertStringToValue
> doesn't know the text that matched on the prefix, so it can't say
> (now) "option -foo requires an argument", where "-foo" is the
> particular alias that was typed.
>
--
Mikoláš Janota M. Sc.
School of Computer Science and Informatics,
University College Dublin,
Belfield,
Dublin 4,
Ireland
|
|
From: Radu G. <rad...@gm...> - 2009-08-12 13:50:56
|
On Wed, Aug 12, 2009 at 1:58 PM, Mikoláš Janota<mik...@gm...> wrote: > From what you are saying I can't figure out the difference between a > blank arg and malformed arg. It's nice to have a different error message and treat strings and integers uniformly. > Nevertheless, we seem to have a problem as "tail -nBAZOOM" gives me > Illegal option: -nBAZOOM > This means we don't handle well malformed args. It looks more like tail.clo is wrong. |
|
From: Mikoláš J. <mik...@gm...> - 2009-08-12 14:50:28
|
On Wed, Aug 12, 2009 at 2:50 PM, Radu Grigore<rad...@gm...> wrote:
> On Wed, Aug 12, 2009 at 1:58 PM, Mikoláš Janota<mik...@gm...> wrote:
>> From what you are saying I can't figure out the difference between a
>> blank arg and malformed arg.
>
> It's nice to have a different error message and treat strings and
> integers uniformly.
>
if the example with integers bothers you, consider
s:{"-s"}:{string-regexp} :[between="" regexp="a+" ]
why should -sxxx be considered differently from -s"" ? both "" and
"xxx" are wrong params
(if you want different message just print "" differently)
it seems silly to write
s:{"-s"}:{string-regexp} :[between="" regexp="a*" blankparamallowed="false"]
instead of
s:{"-s"}:{string-regexp} :[between="" regexp="a+" ]
we could probably add a check whether an "" matches the arguments
shape once "" returns as the arg
--m.
m.
>
>> Nevertheless, we seem to have a problem as "tail -nBAZOOM" gives me
>> Illegal option: -nBAZOOM
>> This means we don't handle well malformed args.
>
> It looks more like tail.clo is wrong.
>
--
Mikoláš Janota M. Sc.
School of Computer Science and Informatics,
University College Dublin,
Belfield,
Dublin 4,
Ireland
|
|
From: Radu G. <rad...@gm...> - 2009-08-12 18:00:34
|
On Wed, Aug 12, 2009 at 3:50 PM, Mikoláš Janota<mik...@gm...> wrote:
> it seems silly to write
> s:{"-s"}:{string-regexp} :[between="" regexp="a*" blankparamallowed="false"]
Especially when the default for blankParamAllowed is false.
> instead of
> s:{"-s"}:{string-regexp} :[between="" regexp="a+" ]
A better comparison would be with
s:{"-s"}:{string-regexp} :[between="" regexp="a+" blanparamallowed]
so that we simulate that blankParamAllowed check was removed from parse().
What do we see? An error message that doesn't mention the alias that
was typed, as I said. (There is, however, a ^ pointing to the right
place thanks to the latest additions by Fintan.)
Not to mention that string-regexp is quite different from string in
that it has validation and the whole point of using string as an
example in my previous emails was as an option without validation.
This discussion is getting silly. I'll stop now.
|
Thanks for helping keep SourceForge clean.
X