| We don't currently have a good way to reproduce the problem from a | completely clean build, however it's easy to reproduce by doing two | builds and leaving the .hi files from the first build in place while | removing the .o files
Indeed. But is determinism in the face of .hi file changes Part of the Goal? | So we concluded that it was probably futile to aim for | fully-deterministic compilation by making the uniques the same every | time, and instead we should try to make compilation deterministic in the | face of non-deterministic uniques. Well that is bound to be fragile too. IF the uniques could be made deterministic, for the use-cases that are part of The Goal, then it would be a simple solution. Determinism in the face of non-det uniques. I suggest NOT monkeying with UniqFM or Data.Map. Rather, I think you should focuse on every use of ufmToList. There are a lot of these, and many of them will be totally fine to be non-deterministic. On a case-by-case basis (fragile) I guess you can find some canonical ordering. That might be hard in the case, say, of identical OccNames with different uniques (e.g. ds_343, ds_324). I suppose that in every case we'd have to look for some other way to canonicalise. Ugh. Still, one step at a time. Wiki page would be good. Simon _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
