Hi Karel,
On Thu, Dec 14, 2017 at 01:35:30PM +0100, Karel Gardas wrote:
> 8.2 and later, including HEAD should be better and better. I've done
> some work on this (mainly passing your patches to the HEAD of that
> time)
I'm aware of it, and I really appreciate it.
> and also some core GHC developers (Ben Gamari IIRC) are testing
> on OpenBSD (latest release) now, so I think your life as GHC
> maintainer should be more easier.
Well, updating the ghc port itself isn't *that* painful (most of
the time). IIRC, it took me half a day to get ghc-8.0 into shape
last year, and the current work on getting ghc-8.2 working as a
port took less than 8 hours so far (build new bootstrappers, curse
when it fails, fix things, try again, build ghc-8.2.2, update
pkt/PLIST and all the library versions in lang/ghc/Makefile).
The time consuming task it to fix / bump / update all the hs-ports
for a new version of ghc. That takes several iterations (using dpb
-uR), where you have to at least update the MODGHC_PACKAGE_KEY and
regenrate pkg/PLIST. And for some ports, you have to patch the
.cabal file, because nothing changed for real, but the .cabal file in
the distribution tarball contains too tight dependencies (for
example, on the version number of ghc's base library).
So, as glad as I am about ghc improvements, they won't reduce the
work on updating the ghc port *and* all ports depending on it.
> Completely other matter is:
> - GHC memory allocation strategy -- big mmap where it is supported
I'm not aware of this topic.
> - GHC RWX memory usage, hence wxneeded
As I wrote earlier, work on this may be easier with ghc-8.2. I tried
it with ghc-7.10 by sprinkling some mprotects in rts/Linker.c, but
it was as mess (and failed at some completly unrelated part in ghc's
rts).
> - GHC/base usage of unsafe string primitives
To you mean those warnings about sprintf, strcpy etc.? Last time i
looked, they looked all "save" (no real danger of overflows or
truncation). But of course, it would be helpful to fix them.
Ciao,
Kili
