From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A94E959CA3 for ; Tue, 15 Mar 2016 00:18:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 325CBE0881; Tue, 15 Mar 2016 00:18:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 69C4AE087B for ; Tue, 15 Mar 2016 00:18:36 +0000 (UTC) Received: from [10.128.12.197] (unknown [100.42.98.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 854EF340C3F for ; Tue, 15 Mar 2016 00:18:35 +0000 (UTC) Subject: Re: [gentoo-portage-dev] [Patch] Repoman rewrite stage2 modularization conversion complete To: gentoo-portage-dev@lists.gentoo.org References: <20160110134008.4fce78c0.dolsen@gentoo.org> <5693CCAF.7020102@gentoo.org> <20160305133705.42b54258.dolsen@gentoo.org> <56E6F167.4050806@gentoo.org> <56E6F343.80005@gentoo.org> <20160314105256.37fb8e90.dolsen@gentoo.org> From: Zac Medico Message-ID: <56E754D3.5080308@gentoo.org> Date: Mon, 14 Mar 2016 17:18:27 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20160314105256.37fb8e90.dolsen@gentoo.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: 72330d7a-6d86-49ed-b1bf-23810a5c1414 X-Archives-Hash: b2ea2adac26b567c311f0de8aef44a60 On 03/14/2016 10:52 AM, Brian Dolbec wrote: > On Mon, 14 Mar 2016 10:22:11 -0700 > Zac Medico wrote: > >> On 03/14/2016 10:14 AM, Zac Medico wrote: >>> On 03/05/2016 01:37 PM, Brian Dolbec wrote: >>> >>>> Zac, I'm done with code changes in the rewrite. Ready for a last >>>> look before a merge. Can you have a look again? I did some >>>> changes/fixes and rebased them in. Floppym hasn't reported any >>>> more bugs, so I think it's ready for broader testing in a >>>> release. Then we can work on moving all the test data to a >>>> separate file in the tree or downloaded... >>> >>> The dynamic_data stuff in Scanner is a little hard to follow. Then >>> it calls dynamic_data.update(rdata), is there any chance that the >>> update operation might clobber something that shouldn't have been >>> clobbered? >> >> To clarify my question, suppose that one function returns {'foo': >> True} and another one returns {'foo', False}, so now there first >> {'foo': True} setting is forgotten. Is that going to be a problem? > > No, as stated in my other reply. There are only a few things that are > modified. Mostly as I made a new module, following the original > order the checks were run. As data was discovered missing it was added > to dynamic_data from the previous check that supplied it to the Scanner > class. So, only data needed later was passed back to update the > dynamic_data. > > Also all those checks originally ran in one huge 1k LOC loop with > another slightly smaller ebuild loop nested inside it. So all those > variables were subject to change already by previous code run. In the > stage1 rewrite, I/we did the same thing in creating the separated > checks classes. After the check was done, only the data required was > brought back into the primary loop. > I've found what may be a real instance of the kind of problem I was worried about. The 'allvalid' key is set in both pym/repoman/modules/scan/ebuild/isebuild.py and pym/repoman/modules/scan/ebuild/ebuild.py, and its non-trivial for me to determine whether this is a real problem or not. -- Thanks, Zac