CoPaR issueshttps://git8.cs.fau.de/software/copar/-/issues2023-12-14T07:54:38Zhttps://git8.cs.fau.de/software/copar/-/issues/22Become compatible to GHC 9.62023-12-14T07:54:38ZThorsten WißmannBecome compatible to GHC 9.6Joshua Moerman sent me some commits to make copar compatible to newer ghc versions. He wrote:
> Also, I have managed to use copar with the most recent GHC. It requires some changes to the code. And I think it would be nice to incorporat...Joshua Moerman sent me some commits to make copar compatible to newer ghc versions. He wrote:
> Also, I have managed to use copar with the most recent GHC. It requires some changes to the code. And I think it would be nice to incorporate some of them already with older versions of GHC:
> - Eq will become a superclass of Eq1 (with qualified constraints, GHC 9.6). Similar for Show1. So to be forward-compatible, some instances have to be added.
> Patch: https://git.cs.ou.nl/joshua.moerman/copar/-/commit/17c54b5c9b5f681f3e65ab9515fd4bb40958687b
> - ST will no longer have a MonadFail instance (GHC 9.4). I have removed some pattern-matches in do-notation. They have been replaced with non-exhaustive pattern matches.
> Patch: https://git.cs.ou.nl/joshua.moerman/copar/-/commit/8dd4528a98fc0f387885a2a3d406c90bdec878ad
>
> (Some other changes were necessary, like updating some dependencies. I did not do that in a principled manner.)
I propose to simply merge those commits (via `git cherry-pick`).https://git8.cs.fau.de/software/copar/-/issues/21Make Data.Partition.isRefinement faster2023-12-14T07:50:17ZThorsten WißmannMake Data.Partition.isRefinement fasterJoshua Moerman has a faster version of `isRefinement`, namely one which is quasilinear, whereas copar's implementation `Data.Partition.isRefinement` is quadratic. Here's Joshua's implementation:
https://git.cs.ou.nl/joshua.moerman/mealy-...Joshua Moerman has a faster version of `isRefinement`, namely one which is quasilinear, whereas copar's implementation `Data.Partition.isRefinement` is quadratic. Here's Joshua's implementation:
https://git.cs.ou.nl/joshua.moerman/mealy-decompose/-/blob/main/src/Partition.hs?ref_type=heads#L33
For Joshua's example, the speedup was a factor of 40x.https://git8.cs.fau.de/software/copar/-/issues/20Merge SigManager and Computer ?2023-01-06T15:19:56ZSilas KuderMerge SigManager and Computer ?Either Thread is mostly idle, when the other is working, so they could be combined with relative ease.
But given that both files are ~200 lines, it will make the combined file rather unwieldy.Either Thread is mostly idle, when the other is working, so they could be combined with relative ease.
But given that both files are ~200 lines, it will make the combined file rather unwieldy.https://git8.cs.fau.de/software/copar/-/issues/19Split blocks smarter2023-01-06T15:12:40ZSilas KuderSplit blocks smarterWhile the SigManager cannot go full Paige-Tarjan within ```buildAllNewBlocks``` he could use the heuristic of "Let the biggest subblock retain its ID". Whether the heuristic is useful enough to warrant its computation, should be tested.While the SigManager cannot go full Paige-Tarjan within ```buildAllNewBlocks``` he could use the heuristic of "Let the biggest subblock retain its ID". Whether the heuristic is useful enough to warrant its computation, should be tested.https://git8.cs.fau.de/software/copar/-/issues/18InList can be an unboxed vector2022-08-23T18:41:32ZSilas KuderInList can be an unboxed vectorDistributed.Types.InList is an unchanging list of State-Worker-Pairs, both of which are aliases for Int.
Implementing it as unboxed vector would save space and improve access time.Distributed.Types.InList is an unchanging list of State-Worker-Pairs, both of which are aliases for Int.
Implementing it as unboxed vector would save space and improve access time.https://git8.cs.fau.de/software/copar/-/issues/14Port to ghc-8.82020-10-14T11:15:12ZHans-Peter DeifelPort to ghc-8.8Currently, compiling with `base 4.13` results in compilation failures related to `MonadFail`.
The issue is that `MonadParsec` does not (and probably never will) require `MonadFail`, but our lexer primitives are written using a `MonadPar...Currently, compiling with `base 4.13` results in compilation failures related to `MonadFail`.
The issue is that `MonadParsec` does not (and probably never will) require `MonadFail`, but our lexer primitives are written using a `MonadParsec` constraint and also use `fail` quite a bit. A simple fix would be to add a `MonadFail` constraint to the `MonadParser` constraint alias, a proper fix would be to remove `fail` in favor of better error reporting mechanisms provided by `megaparsec`.Bastian KauschkeBastian Kauschke