Hi,
please look at https://github.com/autotest/virt-test/pull/227
This pull request adds features:
virt: Adds possibility to exclude filter from config.
virt: Adds possibility filter defaults variant from variants
virt: Adds named variants to Cartesian config.
ypu:
There should be repaired bug https://github.com/autotest/virt-test/issues/199
in the pull-request.
please check it and let me know.
regards,
Jiří Župka
----- Original Message -----
> Hi Eduardo,
> thank you for your answer and reading my long use-case.
>
> ----- Original Message -----
> > Hi, Jiri,
> >
> > I will read your long use-case description more carefully later,
> > but
> > answering the other comments:
> >
> > On Fri, Feb 22, 2013 at 09:13:31AM -0500, Jiri Zupka wrote:
> > [...]
> > > > >
> > > > > I chose delete filter instead of delete filter directly from
> > > > > parser
> > > > > tree.
> > > >
> > > > I would like something clearer than "delete". We call our
> > > > filtering
> > > > commands "only" and "no", not "add_filter", because the config
> > > > file
> > > > is
> > > > declarative, not imperative. The action of "deleting" a filter
> > > > gives
> > > > the
> > > > impression of an imperative model, instead of declarative.
> > >
> > > There is del already implemented for delete keys in dictionary.
> > > It
> > > should only
> > > extends functionality for filters.
> >
> > OK, let me correct what I have said:
> >
> > - Assignment of variables when expanding a given
> > test-dictionary/variant-combination is "imperative" (with
> > instructions
> > that will be executed in a given order) due to "+=" and "del"
> > - Definition of filters and variants is (up to now) 100%
> > declarative
> >
> > >
> > > I don't talk about function delete filters in next paragraph and
> > > I
> > > almost agree with your arguments.
> > > The delete filter is quite discussable thing. It is only for more
> > > comfort.
> > >
> > > In general I don't see any really good reason why to block good
> > > features only for
> > > stay in some paradigm. Yes there could be some already created
> > > proof of concept.
> > > But cart config is quite easy and small language. Lots of
> > > languages
> > > are using
> > > multi-paradigmatic (like python) and it adds more flexibility and
> > > comfort for users
> > > in my point of view. Using of autotest should be mainly easy for
> > > users.
> >
> > In the case of the naming of "del", my worry is not about
> > "following
> > a
> > paradigm", but about keeping the "model in our minds" of config
> > file
> > sane for humans. It's more a question about usability: keeping the
> > system understandable by humans (both groups: people who write and
> > read
> > config files, and people who maintain the config file parsing
> > code).
>
> Nice to hear:-)
>
> >
> > In other words: when talking about the name of "del", I am
> > specifically
> > thinking about finding a name/syntax that can be understood easily,
> > when
> > somebody is reading a config file that uses the feature, or trying
> > to
> > understand how the feature works.
> >
> > Personally, I would call the new feature a "filtering exception",
> > not
> > "deletion of filters". It keeps the message that the system isbased
> > on a
> > set of filter declarations that are then combined according to the
> > rules, not a set of instructions that will be executed in sequence.
> >
>
> Oh ok now I see. I'll try to think about some better name.
>
> >
> > Another thing that I worry about (not related to the naming of
> > "del",
> > but to the feature itself), is that every time we change the config
> > file
> > semantics, we risk making the (computational) complexity of the
> > config-dictionary generation grow out of control. Our cartesian
> > config
> > file algorithm is at least O(n^2) already, but we fortunately keep
> > it
> > under control by making some optimizations that work for our
> > existing
> > config files[1].
>
> Understand
>
> >
> > To give an example where this broke in the past because the system
> > was
> > "too flexible": originally the config file filters were based on
> > regular
> > expressions. It sounds wonderful and very flexible. The problem: we
> > had
> > to check for regular expression matches for _every single_ variant
> > combination, to make the filters work as documented. The config
> > file
> > parser was heavy and slow, and this approach became unfeasible when
> > our
> > number of variants started to grow.
> >
>
> I'll try do my best in changes. I have already heard about this
> problem from Lucas (Lmr)
> and I was using old version too..
>
> >
> > [1] To make things worse, I know of at least one bug in the
> > optimization
> > code that I don't completely understand yet. I really hope we don't
> > find
> > out that the existing optimization logic is fundamentally flawed.
> > https://github.com/autotest/virt-test/issues/199
>
> I also hope and I try to repair it too.
>
> >
> > --
> > Eduardo
> >
>
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
