This repository has been archived by the owner on Feb 3, 2018. It is now read-only.
Refactor hashing #143
Merged
Refactor hashing #143
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This provides a convenient way of letting the debugging func inject a newline after each write (for readability in debugging).
This separates a bunch of the static state/rules/information that comes from the root project and input parameters into a discrete subsystem. The only real benefit here is focusing the state tracked by the solver in on the actual algorithm of solving, and less so these static rules - which should make it a bit easier for other people to grok.
All changes are geared towards making "default"-type values explicit, as that increases the likelihood that equivalent inputs will produce identical hash digests.
Hashing functions are exquisitely sensitive to inputs - that's why they're useful. But it makes them a PITA to work with. Having an easy-to-scan visualization of hashing inputs in tests frees up cognitive capacity to focus on the algorithm.
Current coverage is 77.68% (diff: 90.29%)@@ master #143 diff @@
==========================================
Files 24 25 +1
Lines 3694 3759 +65
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 2855 2920 +65
- Misses 633 635 +2
+ Partials 206 204 -2
|
To further improve debugging of issues with the input hashing, this adds "section headers" - strings that are output prior to each type of data that's present in the cache. Also partially switched to progressive mutation table-based tests for input hashing, and added test cases that cover salient combinations of overrides, imports, and constraints.
Makes it easier to see problem spots on a quick scan.
These solve the problem, at least in the hasher, of the possibility for strings representing different types of versions to collide. For example, prior to this change, a branch constraint named "foo" and a version constraint named "foo" could cause the hasher to produce the same hash, even though the two inputs would not have admitted the same solution set.
krisnova
pushed a commit
to krisnova/dep
that referenced
this pull request
Apr 21, 2017
Refactor hashing
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#139 was prematurely merged.
rootdataopsDump Source unconditionally from constraints, normalizing via methodWe DON'T actually want to dump the source unconditionally, as they're not semantically equivalent - an empty
ProjectIdentifier.Sourceallows for the possibility of having the source switched on the fly by something that comes along later in the algorithm.