soulomoon
> I don't think we need to complicate the API by introducing side conditions - we just need to try evaluating dependencies in order. This means instead of maintaining a...
Oh i see how it goes, it would means kicking up deps linearly. It does solve the problem in a more direct way, but I am a bit worried on...
Let try a linear approach and do some benchmark to see how much we lost. But I doubt the speculative builds would be better than annotating the dependencies with an...
> I guess we could also just throw exceptions when preconditions are violated, and have these exceptions be caught and ignored by hls-graph. > > Instead of > > ```...
> Yes that was the concern, but we could still build all rules depended on simultaneously using the uses family of functions as well as the applicative combinators () in...
Good news @wz1000 looks good on linearity deps: | version | configuration | name | success | samples | startup | setup | userT | delayedT | 1stBuildT | avgPerRespT...
Another run the linearity approach, I guess stopping the extra dep does helps a great deal. | version | configuration | name | success | samples | startup | setup...
> If this patch avoids that we can have more confidence that it is working as intended. ok, let's see if we trigger error here ------------------------------------- > Earlier it was...
Also, I have added a test case to prevent phantom dependencies from occuring again in hls-graph.
> In the end I got the (improved) error after 180 iterations of running that test. But it seems to occur less frequently now. "message": "called GetLinkable for a file...