-
Notifications
You must be signed in to change notification settings - Fork 525
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PackageResolver Refactor #2039
PackageResolver Refactor #2039
Conversation
currentStep.ClosedRequirements | ||
|> Set.union currentStep.OpenRequirements | ||
|> Set.add lastPackageRequirement | ||
|> Seq.filter (fun x -> x.Name = lastPackageRequirement.Name) | ||
|> Seq.sortBy (fun x -> x.Parent) | ||
|> Seq.filter ^ fun x -> x.Name = lastPackageRequirement.Name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please don't
this is really really hard to review- can you please split it in two PRs. one with the resolver change and one with all the cosmetical changes? thanks |
c562664
to
b38b4e3
Compare
@forki this fine? |
it seems the new resolver is not resolving correctly tests like ##1254 are red. can you confirm? |
b38b4e3
to
e2e41c7
Compare
a bug got reintroduced when I redid the commits |
#1883 install FSharp.Core from Chessie fails!? |
yeah these new packages are fucking up everything. MS is clearly out of control here. |
even when I try to run the integration tests on the core3 branch they don't complete |
do you have VS open at that time? or something else that keeps an handle on the nupkg? |
And from fake build? Am 23.11.2016 16:50 schrieb "Jared Hester" [email protected]:
|
the log in the gist is from the FAKE build |
Ok can you please try to find out which tool is locking it? Sorry for all the work, but this whole .net standard conversion is a real mess. |
#1977 seems to work on appveyor. (travis is expected to fail) |
|
||
let flags = StepFlags(flags.Ready,flags.UseUnlisted,hasUnlisted,flags.ForceBreak,flags.FirstTrial) | ||
if exploredPackage.Unlisted && not flags.UseUnlisted then | ||
tracefn " unlisted" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
now i'm pretty sure the bug is here, where I last made a change 🤦
which I'd had as
if exploredPackage.Unlisted && not flags.UseUnlisted then
tracefn " unlisted"
stepLoop flags (Inner(conflictState))
else
before, but that caused an infinite loop printing unlisted
@forki it'd be really useful for whoever has to work on this next, if you or someone else with a deeper understanding of what's going on in this module could add some comments explaining the processes. I'd do it myself, but I don't think I have a firm enough grasp and I wouldn't want to put down something that's wrong
@forki finally passed on appveyor 🎉 |
7d99e57
to
e144fd8
Compare
anything else I need to do for this? |
thanks so much. let's what the real world thinks about it ;-) |
Started working on this in an attempt to address #2030
I wasn't able to get the step function to the point where its tail recursive, but its much closer than it was before and it no longer relies on mutation across iterations.
I think it should be possible by adding a third case to
and using it as an argument for
step
to direct it down one of three pathways for the start of a step, an outer loop, or an inner loop, although when I tried coding that up I couldn't get it to work.I think this is the block of code that was causing the issues when I took that approach
but I'm not totally sure.