Thanks both of you for quick response:-)
Important part of email "* For now:"
----- Original Message -----
> On Fri, Apr 05, 2013 at 06:47:10AM -0400, Jiri Zupka wrote:
> > >
> > > I think ":" would work, but it looks strange because the final ":" has a
> > > different meaning from the ":" in the middle.
> > >
> > > >
> > > > 3) Exchange '>' to '::'
> > > > little more performance expensive
> > >
> > > Why exactly "::" would have any performance problem?
> >
> > only comparison of char and multiple char and more one if many times.
>
> It doesn't like one extra string comparison will will affect the
> performance of the parser at all. If we were worried about those tiny
> optimizations we wouldn't be writing the parser in Python. :-)
>
> >
> > >
> > >
> > > > only host_os::linux2 should work
> > > > host_os::linux1: var = 2 could work but
> > > > host_os::linux1: work but
> > > > var1 = 2
> > > >
> > > > 4) Exchange '>' to '-'
> > > >
> > > > only host_os-linux2 should work
> > > > host_os-linux1: var = 2 could work but not good visible
> > >
> > > What "not good visible" means?
> >
> > If you have lots of
> >
> > host_os-guest1.virt_os-linux.sdff-aaaaa.
> >
> > Then it could be hard to see in first sight in logs. could be hidden in
> > text.
> > And as you wrote before looks like part of name.
> >
> > >
> > > > host_os-linux1:
> > > > var1 = 2
> > > >
> > > > Which of this version do you prefer most or do you prefer some
> > > > different
> > > > version?
> > >
> > > So, the main problem here seems to be how to make the "<condition>:"
> > > blocks look good and intuitive.
> > >
> > > The answer is: I don't know! I need to think about it a little.
> > > Currently I see two main possible approaches:
> > >
> > > * The ones you proposed above (Use something else than "=").
> > > I believe any of ":", "::" or "-" look better than ">". I think I
> > > would choose "::". ":" is confusing (see my comment above), "-"
> > > doesn't look like an "operator", but just part of the variant name.
> > > * Require some kind of delimiter when "=" is involved. e.g.:
> > > only [host_os=linux2]
> > > [host_os=linux2]: var = 2
> > > [host_os=linux2]:
> > > var = 2
> > > [host_os == "linux2"]: var = 2
> > >
> > > I would love to hear suggestions from others as well. Paolo?
> >
> > I like this version. It could be easy and fast for parsing. And good
> > visible.
> > only [host_os=linux2]
> > [host_os=linux2]: var = 2
> > [host_os=linux2]:
> > var = 2
> >
> > disadvantage: This breaks today syntax. There could be choice
> > for named variant and filtering with name in config have to be
> >
> > only [host_os=linux2]
> >
> > for unnamed it could stay as it for keep compatibility.
>
> It should stay compatible, yes.
>
> >
> > only linux2
> > but could be replaced by
> > only [linux2]
>
> Exactly. Just like quotes are recommended but optional when assigning
> strings, The [] delimiter could be recommended but optional on variant
> name/conditions.
>
> I like that approach because we could slowly change the parser to accept
> more complex expressions inside [].
>
> Also: I would like to make sure all the following formats work:
>
> [host_os=linux2]
> [host_os = linux2]
> [host_os="linux2"]
> [host_os = "linux2"]
>
> In other words: instead of making the semantics based on
> substring-matching in th config-dictionary names (the long
> "foo.bar.baz.etc" strings), it is now a human-readable expression that
> describes a subset of variants/dictionaries.
>
I agree and as Pablo wrote
> > [host_os = "linux2"]: var = 2
> Without quotes, I think. Like [host_os = linux2].
same requirement.
and I agree.
But output for logs could stay in old syntax because this is better for reading
if on screen is lots of lines. But it is only cosmetic problem.
It could be easy changed.
>
> >
> >
> > only [host_os=linux2.guest_os]
> > or
> > only linux2.guest_os
>
> I don't know if you did that on purpose, but the above case is
> interesting because it contains two components ("linux2.guest_os") in
> the variant value.
Yes it was purpose. For coding this is the easiest variant. But it depends
where we want go with parser. My first aim was make changes in config syntax
with as less as possible changes in code. but I'm not against making more
changes.
>
> I mean, this is easy to make work:
>
> variants guest_os:
> - Linux
> - Windows
>
> only [guest_os=Linux]
>
>
> Now, what about this:
>
> variants guest_os:
> - Fedora
> variants: # this one could be "variants fedora_version:"
> - 15
> - 16
> - 17
> - RHEL
> variants: # this one could be "variants rhel_version:"
> - 5
> - 6
>
> In this case, how can somebody say "I want only Fedora 15"?
>
> Some alternatives I see:
>
> (I am including all that came to my mind, including ones that I
> find wrong or ugly)
>
> only Fedora.15 # already works
> only [guest_os=Fedora.15] # looks wrong to me
> only [guest_os = "Fedora" and fedora_version = "15"] # I like this one, but
> requires a more complex parser
> only [guest_os = "Fedora" && fedora_version = "15"] # Like above, but for
> people who like C operators
> only [guest_os=Fedora]..[fedora_version=15] # This follows the
> existing rules about "..", but looks weird
> only [guest_os=Fedora].15 # makes sense, follows
> the existing rules about ".", but looks weird
> only [guest_os=Fedora..fedora_version=15] # looks really wrong
> to me
Not important question:
If "only [guest_os = "Fedora" and fedora_version = "15"]" version is
preferred
then I can't see different with "only [guest_os=Fedora..fedora_version=15]"
what about
filters:
only [guest_os=Fedora] and [fedora_version=15]
only [guest_os=Fedora] or [fedora_version=15]
condition:
[guest_os=Fedora] or [fedora_version=15]:
>
> I have two questions:
>
> * Which formats are going to be accepted by the parser?
> * From the formats that work, which format are we going to recommend
> to users?
* For less number of changes in code are the best variants:
only [guest_os=Fedora.15] # looks wrong to me
# less changes in code
only [guest_os=Fedora..fedora_version=15] # looks really wrong to me
# less changes in code
only [guest_os=Fedora].15 # makes sense, follows
# good too
only [guest_os=Fedora]..[fedora_version=15] # This follows the
existing rules about "..", but looks weird
use "[""]" only as marker for filter code.
* But if there is good reason for changing syntax of filter at all. It is
possible too.
But I don't see really big advance for users. In this case.
only [guest_os = "Fedora" and fedora_version = "15"] # I like this one, but
requires a more complex parser
* It is possible do some basic lexical analyse for future extension. It will be
more funny.
* For now:
1) filter from in the middle of way.
good:
only [guest_os=Fedora].15 # makes sense,
follows # good too
only [guest_os=Fedora]..[fedora_version=15] # This follows the
existing rules about "..", but looks weird
wrong will not be acceptable by parser:
only [guest_os=Fedora.15] # looks wrong to me
# less changes in code
only [guest_os=Fedora..fedora_version=15] # looks really wrong
to me # less changes in code
2) for variants
added metadata variants _name_ [default=aaa] [xxx] [yyy]: for possibility
future extensibility as you and Pablo mentioned in your responses.
3) default variant could be expanded by parser parameters. Good idea.
4) default should be easy way enabled and disabled.
5) Warning for special characters.
Please send me your comments to this part. I'll start work on this as soon as
possible.
>
> >
> >
> > host_os=linux2.guest_os: this will be interpreted like variable
> > assignation.
> > [host_os=linux2.guest_os]: condition.
> >
> > It could be little confusing for users..
>
> I believe in this case the blame is on anybody who write a line like the
> one above in a real config file. Even without the named-variants support
> the above line looks ambiguous and ugly to me because of the final ":"
> and the lack of quotes.
>
> We could even change the parser to print a warning in case people use
> special characters (like space, "[", "]", ":", "=", ",", etc) inside
> variable values without using quotes.
>
Yes it is good idea.
--
Jiří
>
> >
> > This version is quite overkill from my point of view.
> > [host_os == "linux2"]: var = 2
> >
> > I tried to ask person which never see this syntax how they understand
> > host_os::linux2 and [host_os=linux2]
> > and they choosed [host_os=linux2] as more intuitive understandable.
>
> Makes sense to me.
>
> --
> Eduardo
>
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
