On wto, 2017-06-13 at 12:27 +0200, Alexis Ballier wrote: > On Mon, 12 Jun 2017 21:17:16 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > > > I've actually started typing the initial specification yesterday [1]. > > As you can see, banning the extra constraints has made the algorithms > > much simpler. In particular: > > > > 1. You do not have to define 'falsify' for anything other than pure > > flags -- which makes it easy to inline it. > > > > 2. ||, ??, ^^ groups are only flat lists of flags -- which makes > > reordering and processing them trivial. > > > > 3. The algorithm is recursive only on USE-conditional groups. This > > makes it trivial to make it iterative. Optimizations become trivially > > possible. > > > While you're right in one sense, you're mixing two different things > here. What you wrote *is* recursive. It does not recurse just because > you're assuming a restricted syntax. You're only saving two things: > you don't need to define how to enforce to false (that is 3 lines not 3 > pages :=) ) and you're avoiding the nested use conditionals that are > already ill defined per the current spec (foo? bar is equivalent to > && ( foo bar ) when nested) which I believe is already another problem. > > Then, remember how I wanted to be much more drastic than you in the > beginning by killing all ||,&&,^^ etc. and keep only use > conditionals in REQUIRED_USE ? Well, that's where the complexity comes. > The whole deal then is to define rewriting rules for the AST so that > the algorithm you describe executes the exact same instructions but the > new AST only has use conditionals. This is more like writing a compiler > for the spec, so this does not belong to the spec and there is no > issue here.
I'm looking for a compromise here. Killing those groups completely is going to make things harder for users. Keeping them with functionality limited to what's used in ~99.9% ebuilds (based on your numbers) is IMO a better choice. > [BTW: checking the rewrite rules behave properly is what I meant by > rebasing solve() on top of it and being happy with it] Could you reiterate the current solving rules (trueify/falsify)? Are they equal to the ones you listed last, or does the current implementation change anything? > > Nevertheless, feel free to play with the full implementation. If > > you're interested, you can play with the complex cases more. In > > particular, I'm wondering whether nsolve will actually consider most > > of them solvable. > > > > As for the results, I think it is the point where we start preparing > > pull requests with REQUIRED_USE changes to see whether the developers > > agree with such changes. > > If by that you also include code cleanup and writing tests then yes :) I'm not sure if we're talking about the same thing. I'm talking about filing pull requests against ebuilds whose REQUIRED_USE is rejected by nsolve. I think it'd serve as a reasonable field test for whether developers agree with the imposed restrictions. > > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse > > I really don't like the reordering thing. Even the restricted > syntax does not fix the issue with '^^ ( a b ) b? ( a )' already > mentioned here. It'd be much better and simpler for the spec just to > assign a fixed value and use the solving rules with those. You're not going to convince me by providing examples that are utterly broken by design and meaningless ;-). -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
