From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B4EF8139694 for ; Tue, 13 Jun 2017 22:14:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 11A53E0D97; Tue, 13 Jun 2017 22:14:03 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A5B4AE0CC7 for ; Tue, 13 Jun 2017 22:14:02 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id B64DA341779; Tue, 13 Jun 2017 22:14:00 +0000 (UTC) Message-ID: <1497392022.29918.1.camel@gentoo.org> Subject: Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE) From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Wed, 14 Jun 2017 00:13:42 +0200 In-Reply-To: <20170613122745.455b39f7@gentoo.org> References: <1496071993.31087.1.camel@gentoo.org> <1496352685.30502.4.camel@gentoo.org> <20170602132758.50a5f734@gentoo.org> <1496411717.29233.5.camel@gentoo.org> <20170603130000.4f88fb14@gentoo.org> <1496503989.15351.1.camel@gentoo.org> <20170603185835.57741ff0@gentoo.org> <20170604105938.2b40157f@gentoo.org> <20170605095516.0b463432@gentoo.org> <1496671825.1230.3.camel@gentoo.org> <20170605192433.6238797b@gentoo.org> <1496686212.1222.4.camel@gentoo.org> <20170606140803.051f8048@gentoo.org> <1496770744.1157.1.camel@gentoo.org> <20170607101759.7e21f0f6@gentoo.org> <1496827679.2129.3.camel@gentoo.org> <20170607115654.2a5da5e2@gentoo.org> <1496999960.29391.1.camel@gentoo.org> <20170609134110.418ae6ac@gentoo.org> <1497012847.25475.4.camel@gentoo.org> <20170609161619.1b72ad5b@gentoo.org> <1497025310.25475.7.camel@gentoo.org> <20170611180518.5e28ddfa@gentoo.org> <20170612110836.7b670c93@gentoo.org> <1497295036.1575.10.camel@gentoo.org> <20170613122745.455b39f7@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-BUaY7BkyRtueys0XGD76" X-Mailer: Evolution 3.22.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Archives-Salt: a3286b73-07ea-434f-96c7-1750f0e0cb11 X-Archives-Hash: 58f6ace30aaece55f8f4e2d053a5a618 --=-BUaY7BkyRtueys0XGD76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On wto, 2017-06-13 at 12:27 +0200, Alexis Ballier wrote: > On Mon, 12 Jun 2017 21:17:16 +0200 > Micha=C5=82 G=C3=B3rny wrote: >=20 > > 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: > >=20 > > 1. You do not have to define 'falsify' for anything other than pure > > flags -- which makes it easy to inline it. > >=20 > > 2. ||, ??, ^^ groups are only flat lists of flags -- which makes > > reordering and processing them trivial. > >=20 > > 3. The algorithm is recursive only on USE-conditional groups. This > > makes it trivial to make it iterative. Optimizations become trivially > > possible. >=20 >=20 > 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 :=3D) ) 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. >=20 > 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=C2=A0(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. > >=20 > > 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. >=20 > 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 >=20 > 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 ;-). --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-BUaY7BkyRtueys0XGD76 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKmBAABCgCQFiEEbbsHzE8NrQbqCv5BsHoa6u+0Rk4FAllAY5dfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZObG0P/RfxkOAr86cvIUAxoh88IhugXbIm4GkX hq7uxByRgpLKLLbeXrqWoDJPD0oSngDeOwW6IrlGiuOhzEW4ToipMq0BEebg+lgn 1XcgR2VS+agEKV9byPNWBTYEDM89RTfg3+FOryLXPm06N6ewl+oD2Ah5tjNFp8eJ lg9x8HeHQFu45uAp6vyUEQQu9XHWRE6xBuCO3QaO5Y5Swvvls71mP39Msuh097Na CzvR1HM29gGxP9hXvDsd5YIoM+P/t06Y6VeCr8WuqXAHLljbd2LJJ97Xp7okJ3jB VBlHcbnOcIULGhtprwEWAmu+qtxfSt25MEgfKR26e65+2ck733rczwu80FrTz94a GYLN1oGlG0Pi4KJqC41RygOh2bh7NfJlVy7iYXGvtix0MCozMgsiiX9Ic6QNYFiT xdNgvv9MD2KcPY633ZJphKMedb2NPfI920DgE54WXvPU+X91btC6/07TDHup+oCU OO0yq3MMm0HfmdohmtxEuU8ZC/YgYdqnwFPJXtPvqoc0lZ6f42hYZO80wHejVhI0 GogHZBhXjIQ2kGdW7fK2E/AgrAjVLKsw3bcKVuc0lFI44tj59IWz4gvHlKxaPjEF ZuhXAAKlmq3nfUEzfaL1GlDbTtQnUPSDzbhJDCniXgSnn4hIQ7KvOv9b8zOIx+9l z4pmyDqYhTZS =4+WC -----END PGP SIGNATURE----- --=-BUaY7BkyRtueys0XGD76--