From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Goldish Subject: Re: [KVM-AUTOTEST PATCH] KVM test: refactor kvm_config.py Date: Thu, 10 Feb 2011 11:14:05 +0200 Message-ID: <4D53AC5D.4070507@redhat.com> References: <1297216207-28375-1-git-send-email-mgoldish@redhat.com> <20110209160603.GO4914@us.ibm.com> <20110209162107.GG3933@otherpad.lan.raisama.net> <20110209233101.GG26301@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: autotest@test.kernel.org, Uri Lublin , Eduardo Habkost , kvm@vger.kernel.org To: Ryan Harper Return-path: In-Reply-To: <20110209233101.GG26301@us.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autotest-bounces@test.kernel.org Errors-To: autotest-bounces@test.kernel.org List-Id: kvm.vger.kernel.org On 02/10/2011 01:31 AM, Ryan Harper wrote: > * Eduardo Habkost [2011-02-09 10:22]: >> On Wed, Feb 09, 2011 at 10:06:03AM -0600, Ryan Harper wrote: >>>> >>>> Instead of regular expressions in the filters, the following syntax is used: >>>> >>>> , means OR >>>> .. means AND >>>> . means IMMEDIATELY-FOLLOWED-BY >>> >>> Is there any reason we can't use | for or, and & for AND? I know this >>> is just nit picking, but, it certainly reads easier and doesn't need a >>> translation. AFAICT, in the implementation, we're just using .split(), >>> so, I think the delimiters aren't critical. >> >> I think the main reason is that " " also means "OR" today (as we use >> .split() and I guess we don't want to diverge too much from the previous >> format), and having C-like operators that don't allow spaces would lead >> to confusion. e.g. I am sure somebody would try to write >> "foo & bar | baz" eventually--how would we interpret that? > > isn't the comma taking the place for " " as OR? Are you keeping both? We're keeping both because that allows for some degree of backward compatibility. The new syntax is backward compatible with simple scripts that don't use any regexp operators like .* and |. > ".." looks like a mistake to me where one meant to put "." > > I'd suggest ignoring " " as a OR operator, then as with most operations, > you need either parens or order of operation precendence which one > can use to interpret foo & bar | baz. > > >> >>> >>>> >>>> Example: >>>> >>>> only qcow2..Fedora.14, RHEL.6..raw..boot, smp2..qcow2..migrate..ide >>>> >>>> means select all dicts whose names have: >>>> >>>> (qcow2 AND (Fedora IMMEDIATELY-FOLLOWED-BY 14)) OR >>>> ((RHEL IMMEDIATELY-FOLLOWED-BY 6) AND raw AND boot) OR >>>> (smp2 AND qcow2 AND migrate AND ide) >>> >>> >>> config = "qcow2&Fedora.14|RHEL.6&raw&boot|smp2&qcow2&migrate&ide" >>> >>> config >>> 'qcow2&Fedora.14|RHEL.6&raw&boot|smp2&qcow2&migrate&ide' >>> >>> config.split("|") >>> ['qcow2&Fedora.14', 'RHEL.6&raw&boot', 'smp2&qcow2&migrate&ide'] >> >> What bothers me about the examples above is the absense of spaces, that >> makes it not very readable to my eyes. > > I don't disagree, but the . and .. I don't find very readable either and > I need a look-up table to distinguish , from .. and . and " ". The > logical operators are well known and recognized. I thought , was intuitive enough: only boot, reboot, migrate seems pretty nice to me. I also thought '.' was obvious because it appears in test names, which leaves us with '..': only Fedora..boot I thought this could be read as "I don't care what's between Fedora and boot". Does that make any sense to you? Either way, if we use | and &, I don't think we'll support parentheses because that would greatly complicate the code.