August 2020 - Glasgow-haskell-users

Does newByteArray clear?
by David Feuer 27 Aug '20

27 Aug '20

I'm looking to play around with an array-based structure with sub-linear worst-case bounds. Array is pretty awkward in that context because creating a new one takes O(n) time to initialize it. Is that all true of newByteArray, or can I get one with arbitrary garbage in it for cheap?

3 3

Haskell Implementors' Workshop lightning talks
by Ben Gamari 25 Aug '20

25 Aug '20

Hello everyone, The Haskell Implementors' Workshop will be held this Friday, August 28th, colocated with virtual ICFP. As usual, we will have a number of slots for lightning-talks. These are five-minute-long talks where you can present libraries, language extension ideas, plugins, tools... anything that the Haskell implementor community might find interesting. We are collecting talk submissions via Google Forms [1] and will notify speakers of their slots on August 27th. We are looking forward to seeing you there! Cheers, - Ben [1] https://forms.gle/a8sZQNRRMe9H9YnX8

1 0

What does freezing an array really do?
by David Feuer 21 Aug '20

21 Aug '20

I know that a frozen array doesn't have to be searched for elements in a younger generation, but how does it differ from an unfrozen array that hasn't been mutated since the last collection? David

3 3

Linking completely statically
by Volker Wysk 13 Aug '20

13 Aug '20

Hi! I know of the command line argument "-static". But this only affects the Haskell libraries. I want to link some programs completely statically, no external libraries needed. When just linking with "-static" I still have those dynamically linked things: desktop ~/bin $ ldd sicherung linux-vdso.so.1 (0x00007ffdab53f000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3633da0000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3633d95000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3633d90000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3633d8a000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3633d67000) libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f3633ce3000) libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f3633cd7000) libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007f3633ccb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3633ad9000) /lib64/ld-linux-x86-64.so.2 (0x00007f3633f0c000) Is it possible to link the remaining libraries statically too? Regards, Volker

6 9

Re: Linking completely statically
by Herrmann, Andreas 11 Aug '20

11 Aug '20

Hi Volker, > Is it possible to link the remaining libraries statically too? > Yes, it is possible to generate fully statically linked Haskell binaries. Though it requires a bit of setup. For example the GNU C library glibc is not really intended for fully static linking, but you can use musl as an alternative libc instead. Probably the easiest way is to use static-haskell-nix [1]. Usage instructions are available in the project README. See [2] if you're not familiar with Nix. Recently, the Haskell extension to Bazel, rules_haskell, also gained the ability to generate fully statically linked binaries building on top of Nix, see [3]. Best, Andreas [1]: https://github.com/nh2/static-haskell-nix [2]: https://nixos.org/ [3]: https://rules-haskell.readthedocs.io/en/latest/haskell-use-cases.html#build…

3 2

Re: Linking completely statically
by Volker Wysk 10 Aug '20

10 Aug '20

Am Sonntag, den 09.08.2020, 09:53 -0400 schrieb Brandon Allbery: > If you are obeying all the necessary restrictions on glibc, or you > are > using a different libc such as musl which is designed for static > linking, then "-Wl,-static" should be sufficient. Doing this with > glibc will likely result in a crash unless the same version of glibc > is available at runtime. Thanks for the tip! But I'll let it be for now. Cheers, Volker > > On 8/9/20, Volker Wysk <post(a)volker-wysk.de> wrote: > > Am Sonntag, den 09.08.2020, 08:59 -0400 schrieb Brandon Allbery: > > > Linux is not friendly to static linking, and you would need to > > > either > > > package or match exact versions of things like the nss and locale > > > libraries that are dynamically loaded at runtime and don't show > > > up in > > > ldd. This limitation comes from glibc and is documented in its > > > manual. > > > > That's bad. But, like you said, it *is* possible. The dar (disk > > archiver) program comes with a statically linked version > > "dar_static": > > > > % ldd dar_static > > Das Programm ist nicht dynamisch gelinkt > > > > ("The program isn't linked dynamically.") > > > > From your answer, I assume that this isn't supported by GHC. > > > > Cheers > > Volker > > > > > > > On Sun, Aug 9, 2020, 08:50 Volker Wysk <post(a)volker-wysk.de> > > > wrote: > > > > Hi! > > > > > > > > I know of the command line argument "-static". But this only > > > > affects > > > > the Haskell libraries. I want to link some programs completely > > > > statically, no external libraries needed. > > > > > > > > When just linking with "-static" I still have those dynamically > > > > linked > > > > things: > > > > > > > > desktop ~/bin $ ldd sicherung > > > > linux-vdso.so.1 (0x00007ffdab53f000) > > > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 > > > > (0x00007f3633da0000) > > > > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 > > > > (0x00007f3633d95000) > > > > libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 > > > > (0x00007f3633d90000) > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 > > > > (0x00007f3633d8a000) > > > > libpthread.so.0 => /lib/x86_64-linux- > > > > gnu/libpthread.so.0 > > > > (0x00007f3633d67000) > > > > libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 > > > > (0x00007f3633ce3000) > > > > libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 > > > > (0x00007f3633cd7000) > > > > libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 > > > > (0x00007f3633ccb000) > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > > > > (0x00007f3633ad9000) > > > > /lib64/ld-linux-x86-64.so.2 (0x00007f3633f0c000) > > > > > > > > > > > > Is it possible to link the remaining libraries statically too? > > > > > > > > Regards, > > > > Volker > > > > _______________________________________________ > > > > Glasgow-haskell-users mailing list > > > > Glasgow-haskell-users(a)haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >

1 0

[ANNOUNCE] Glasgow Haskell Compiler 8.10.2 released
by Ben Gamari 09 Aug '20

09 Aug '20

Hello all, The GHC team is happy to announce the release of GHC 8.10.2. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.2/ GHC 8.10.2 fixes a number of issues in present in GHC 8.10.1 including: * Fixes a bug in process creation on Windows (#17926). * Fixes a code generation bug resulting in incorrect code generation for foreign calls with complex arguments (#18527) * Fixes a bug causing object merging to fail when the lld linker is in use (#17962) * Introduces a workaround for a Linux kernel bug in the implementation of the timerfd mechanism (#18033). * Fixes a few specialiser regressions (#17810, #18120) as well introduces a variety of miscellaneous specialiser improvements (#16473, #17930, #17966) * Fixes a potential loss of sharing due to left operator sections (#18151). * Fix bootstrapping of GHC with the LLVM backend on x86-64 (#17920). * A few important correctness fixes for the low-latency garbage collector. Users of `--nonmoving-gc` are strongly encouraged to upgrade promptly. Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running `xattr -cr .` on the unpacked tree before running `make install`. This situation will hopefully be improved for GHC 9.0.1 with the resolution of #17418 [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17418

1 0