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
