- ghc-devs - Haskell.org

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

GitLab email
by Ben Gamari 04 Nov '19

04 Nov '19

Hi everyone, On Friday I finished importing the prime.haskell.org Trac instance into GitLab. For this process I had to disable mail delivery to ensure that users weren't spammed by import messages. Unfortunately, it looks like I neglected to reenable mail after the import had concluded. I re-enabled mail about half an hour ago and consequently you may find yourself facing a few more messages than usual this morning. Sorry for the inconvenience! Cheers, - Ben

1 0

Working in my own branch with changes in submodules
by Alejandro Serrano Mena 01 Nov '19

01 Nov '19

Dear GHC devs, I am currently working on my own fork of GHC ( https://gitlab.haskell.org/trupill/ghc) and as part of it I need to do some changes to the Cabal and haskeline libraries. However, since they are in submodules, I am not sure about how I can commit those changes, share them with others, and rebase my changes against the current HEAD for these submodules. Thanks in advance and kind regards, Alejandro

2 1

DriverPipeline/HscMain DynFlags mystery
by Ömer Sinan Ağacan 01 Nov '19

01 Nov '19

Hi, We recently did some refactoring in HscMain and DriverPipeline to generate interfaces after final Cmms are generated (previously interfaces would be generated after the tidying pass). It's mostly done but there's one thing that I couldn't figure out after two full days of debugging (I also asked a few people about it on IRC), so I wanted to ask here in case someone here knows. Previously the interface value (ModIface) would be generated and written to disk in `HscMain.finish`. The DynFlags we use to generate the ModIface and to write it to disk would be the one passed to `HscMain.hscIncrementalCompile`. In the new implementation part of the interface is still generated in `HscMain.hscIncrementalCompile` (see mkPartialIface), using the same DynFlags as before. But more stuff is added after the final Cmms are generated (see mkFullIface calls in DriverPipeline) using DynFlags in `compileOne'` or `runPhase` (called by `runPipeline`). It turns out these DynFlags are different enough from the one passed to `HscMain.hscIncrementalCompile` that some tests fail (I remember a backpack test, but there may be more). ("Full" interfaces are written to disk right after generation) See [1] for the hack I added as a workaround. Basically I keep the DynFlags passed to hscIncrementalCompile so that I can generate the final interfaces correctly. The question is what's changing in DynFlags that makes things go wrong. I tried looking at the fields used by mkFullIface and hscMaybeWriteIface, but as far as I can see none of the fields used by these functions are different from the DynFlags passed to hscIncrementalCompile. If anyone knows what's going on any help would be appreciated. Thanks, Ömer [1]: https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/main/HscTypes.hs#L2…

2 2