November 2019 - ghc-devs

-dynamic-too implementation question
by Ömer Sinan Ağacan 25 Nov '19

25 Nov '19

Hi, If anyone here knows about how -dynamic-too is implemented feedback in #17502 would be appreciated. As far as I can see it's unnecessarily inefficient currently, and the code is very hard to follow, but it's possible that I'm missing something, and it'd be good to know what before investing time into it. Thanks, Ömer

1 0

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1-alpha1 released
by Ben Gamari 24 Nov '19

24 Nov '19

Hello all, The GHC team is happy to announce the availability of the first alpha release in the GHC 8.10 series. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1-alpha1/ GHC 8.10.1 will bring a number of new features including: * The new UnliftedNewtypes extension allowing newtypes around unlifted types. * The new StandaloneKindSignatures extension allows users to give top-level kind signatures to type, type family, and class declarations. * A new warning, -Wderiving-defaults, to draw attention to ambiguous deriving clauses * A number of improvements in code generation, including changes * A new GHCi command, :instances, for listing the class instances available for a type. * An upgraded Windows toolchain lifting the MAX_PATH limitation * Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events This release marks the beginning of the 8.10 pre-release cycle. The next alpha release will be in roughly two weeks. This next alpha will likely be the last release before the release candidate in late December. If all goes well the final release will be cut roughly two weeks after the candidate, in mid-January. This being an alpha release, there are a few issues that are still outstanding: * The new Alpine Linux binary distribution is not present due to an apparent correctness issue [1]; any help Alpine users can offer here would be greatly appreciated. * We have yet to sort out compliance with Apple's notarization requirements [2] which will be likely be necessary for users of macOS Catalina. * There is an issue with the users guide build that has yet to be sorted out. * There are a couple of non-regression correctness issues which we plan to fix for the final 8.10.1 but are not fixed in this release. * Debian 10 builds are not yet available. Please do test this release and let us know if you encounter any other issues. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17508 [2] https://gitlab.haskell.org/ghc/ghc/issues/17418

1 0

Service outage
by Ben Gamari 22 Nov '19

22 Nov '19

Hello all, DreamHost, which hosts our GitLab artifact and log storage, is currently having some network trouble. Artifact and CI log download will be unavailable until this is resolved. I have engaged with DreamHost to try to expedite resolution of the issue but have no yet heard back. Cheers, - Ben

1 0

gc.log file
by Simon Peyton Jones 18 Nov '19

18 Nov '19

Devs, I'm getting mysterious messages from git, below. I have no file gc.log in my tree. Also I have run 'git prune' but the message still occurs. Any ideas? Simon simonpj@MSRC-3645512:~/code/HEAD$ git push --force setsockopt IPV6_TCLASS 8: Operation not permitted: Counting objects: 34, done. Delta compression using up to 20 threads. Compressing objects: 100% (14/14), done. Writing objects: 100% (34/34), 8.83 KiB | 2.21 MiB/s, done. Total 34 (delta 32), reused 21 (delta 20) remote: remote: View merge request for wip/T16296: remote: https://gitlab.haskell.org/ghc/ghc/merge_requests/2161 remote: remote: warning: The last gc run reported the following. Please correct the root cause remote: and remove gc.log. remote: Automatic cleanup will not be performed until the file is removed. remote: remote: warning: There are too many unreachable loose objects; run 'git prune' to remove them. remote:

2 1

Problem with compiler perf tests
by Ömer Sinan Ağacan 17 Nov '19

17 Nov '19

Hi, Currently we have a bunch of tests in testsuite/tests/perf/compiler for keeping compile time allocations, max residency etc. in the expected ranges and avoid introducing accidental compile time performance regressions. This has a problem: we expect every MR to keep the compile time stats in the specified ranges, but sometimes a patch fixes an issue, or does something right (removes hacks/refactors bad code etc.) but also increases the numbers because sometimes doing it right means doing more work or keeping more things in memory (e.g. !1747, !2100 which is required by !1304). We then spend hours/days trying to shave a few bytes off in those patches, because the previous hacky/buggy code set the standards. It doesn't make sense to compare bad/buggy code with good code and expect them to do the same thing. Second problem is that it forces the developer to focus on a tiny part of the compiler to reduce the numbers to the where they were. If they looked at the big picture instead it might be possible to see rooms of improvements in other places that could be possibly lead to much more efficient use of the developer time. I think what we should do instead is that once it's clear that the patch did not introduce *accidental* increases in numbers (e.g. in !2100 I checked and explained the increase in average residency, and showed that the increase makes sense and is not a leak) and it's the right thing to do, we should merge it, and track the performance issues in another issue. The CI should still run perf tests, but those should be allowed to fail. Any opinions on this? Ömer

3 2

Question about negative Integers
by Sylvain Henry 16 Nov '19

16 Nov '19

Hi GHC devs, As some of you may know, I am working on fixing several longstanding issues with GHC's big numbers implementation (Integer, Natural). You can read more about it here: https://gitlab.haskell.org/hsyl20/ghc/raw/hsyl20-integer/libraries/ghc-bign… To summarize, we would have a single `ghc-bignum` package with different backends (GMP, pure Haskell, etc.). The backend is chosen with a Cabal flag and new backends are way easier to add. All the backends use the same representation which allows Integer and Natural types and datacons to be wired-in which has a lot of nice consequences (remove some dependency hacks in base package, make GHC agnostic of the backend used, etc.). A major roadblock in previous attempts was that integer-simple doesn't use the same representations for numbers as integer-gmp. But I have written a new pure Haskell implementation which happens to be faster than integer-simple (see perf results in the document linked above) and that uses the common representation (similar to what was used in integer-gmp). I am very close to submit a merge request but there is a remaining question about the Bits instance for negative Integer numbers: We don't store big negative Integer using two's complement encoding, instead we use signed magnitude representation (i.e. we use constructors to distinguish between (big) positive or negative numbers). It's already true today in integer-simple and integer-gmp. However integer-gmp and integer-simple fake two's complement encoding for Bits operations. As a consequence, every Bits operation on negative Integers does *a lot* of stuff. E.g. testing a single bit with `testBit` is linear in the size of the number, a logical `and` between two numbers involves additions and subtractions, etc. Question is: do we need/want to keep this behavior? There is nothing in the report that says that Integer's Bits instance has to mimic two's complement encoding. What's the point of slowly accessing a fake representation instead of the actual one? Could we deprecate this? The instance isn't even coherent: popCount returns the negated numbers of 1s in the absolute value as it can't return an infinite value. Thanks, Sylvain

5 5

Quick Q: do all FFI (non-primop) calls involve State# and RealWorld?
by Christopher Done 09 Nov '19

09 Nov '19

Hi all, I tried compiling this file: {-# LANGUAGE NoImplicitPrelude #-}-- | Demonstrate various use of the FFI.module Foreign whereimport Foreign.Cforeign import ccall "math.h sin" sin :: CDouble -> CDoubleit :: CDoubleit = sin 1 And I’ve noticed that the annotated type given for this foreign op in Core, is (# State# RealWorld, CDouble #), whereas I would have expected e.g. CDouble. Meanwhile, the foreign op call is passed a RealWorld argument. Additionally, code that consumes the result of this foreign call expects a (# CDouble #) as a return value. So there are some assumptions I put in my interpreter to test this FFI call out: 1. Despite claiming to return the real world in a tuple, it actually should just return an unboxed tuple of the value. 2. It should ignore the RealWorld argument entirely. I assume, if I were to lift this function into returning IO, that I should indeed return the RealWorld argument given. So the lesson is: All FFI functions accept a RealWorld, and may return a 2-tuple of State# RealWorld *if* it’s impure, else it’ll return a 1-tuple of the value. Correct? Can someone confirm that my observations are right? Also, if so, is there somewhere I can read more about this? Cheers Chris

2 3

Implementing code ownership?
by Ömer Sinan Ağacan 09 Nov '19

09 Nov '19

Hi, In the thread "Proposed changes to merge request workflow" I agree with Matt that expecting a contributor to find reviewers will not work. I'm wondering if we implemented code ownership better it would somewhat help with the problem. If we had at least one responsive owner for every file then a reviewer would be automatically assigned to every MR, solving the problem. You may say that we simply don't have enough people to assign one responsive person to every file, but that's a problem that a new contributor won't be able to solve anyway, so this is not a disadvantage over the proposed plan. Ömer

1 0

Proposed changes to merge request workflow
by Ben Gamari 08 Nov '19

08 Nov '19

tl;dr. I would like feedback on a few proposed changes [1] to our merge request workflow. Hello everyone, Over the past six months I have been monitoring the operation of our merge request workflow, which arose rather organically in the wake of the initial move to GitLab. While it works reasonably well, there is clearly room for improvement: * we have no formal way to track the status of in-flight merge requests (e.g. for authors to mark an MR as ready for review or reviewers to mark work as ready for merge) * merge requests still at times languish without review * the backport protocol is somewhat error prone and requires a great deal of attention to ensure that patches don't slip through the cracks * there is no technical mechanism to prevent that under-reviewed patches from being merged (either intentionally or otherwise) to `master` To address this I propose [1] a few changes to our workflow: 1. Define explicit phases of the merge request lifecycle, systematically identified with labels. This will help to make it clear who is responsible for a merge request at every stage of its lifecycle. 2. Make it clear that it is the contributor's responsibility to identify reviewers for their merge requests. 3. Institute a final pre-merge sanity check to ensure that patches are adequately reviewed, documented, tested, and have had their ticket and MR metadata updated. Note that this is merely a proposal; I am actively seeking input from the developer community. Do let me know what you think. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/wikis/proposals/merge-request-workflow

9 13

Compiling binaries of bytecode: ever been considered?
by Christopher Done 04 Nov '19

04 Nov '19

Hi all, I was just wondering: has a compiler output mode ever been considered that would dump bytecode to a file, dynamic link to the ghc runtime, and then on start-up that program would just interpret the bytecode like ghci does? The purpose would be simply faster compile-and-restart times. Cheers, Chris

3 2