Shall we merge hnix and it's store ? (and some more questions :-)) #827
Replies: 2 comments
-
It sounds familiar to what Type Class instances with Type Family data type declaration solve. I remember that solution by a card game engine story: "I want to implement an engine for all kinds of card games. I made basic card operations (take, put, play ... etc). I tried to differentiate between card decks and with type classes. But type classes bind to only one data type and that means to the only one type of a deck. Card games have very different decks: Taro decks, 36, 52, decks for RPG games, Uno, 52+Joker." The guy found that TypeFamilies data type allows supporting all kinds of card decks. Readonly store is for other things then the writable store (& writable store ideally should only write and prevent all other actions), so they can be seen as two types of card games with a store. |
Beta Was this translation helpful? Give feedback.
-
I'd waited until GitHub Actions CI allows to not only show Bool of a workflow, but also mark workflow as a (yellow/orange) warning. Or use some other CI for those checks that we would select as a warning. Otherwise, we would have the implicit dichotomy between the flows and our modes of software development, there are two flows: flow through Hackage and flow through If we have "a warning (yellow/orange) level" option for the CI builds - CI maintainers would be able to easily switch between the project build modes. For example, after the release, when the first breaking change arrives in the above projects - the project may start to switch to the BTW, merging the projects means extending the CI builds infrastructure, but that GitHub CI machinery already allows. Overall I am ready for the merge of repos at any time. Because the HNix would split into ~4 packages, having the 6 in one place seems like no difference. |
Beta Was this translation helpful? Give feedback.
-
I got some real speedup (25% faster) by... using a readonly store 🎉
Not really a surprise, and yet there is something to investigate because nix does not pay this 3s penalty for using a remote store. Did I miss some optimisation somewhere ?
Anyway, the point of this discussion is to come with a real example where changes in hnix and hnix-store are (again) synchonized:
Also, this implementation only works because we do some hash caching in hnix, which we added to speed-up the remote store implem. But with this caching we do not have to use the remote store.
I think a readonly, in-memeory store is a saner default for hnix, especially for tests. Or at least a --readonly option for the tests.
And my last problem is: How to switch dynamically the MonadStore instance based on the Options we have (--readonly, --store, etc ?). From what I understand from haskell, type classes may not be the right tool.
Beta Was this translation helpful? Give feedback.
All reactions