- ghc-devs - Haskell.org

cvs-ghc mailing list dead?
by Steven Shaw 10 Dec '17

10 Dec '17

This email list <https://mail.haskell.org/mailman/listinfo/cvs-ghc> appears to be dead but I figured it might forward to ghc-devs <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>. Just checking...

1 0

Moving hadrian to submodule
by Ben Gamari 08 Dec '17

08 Dec '17

Hello everyone, A bit over a month ago we merged hadrian into the ghc tree as a subtree. Unfortunately, those working on Hadrian have found the subtree mechanism to provide a rather poor developer experience. Consequently, today I will be ripping out the subtree and replacing it with a submodule. After pulling the commit performing this change you will likely need to do the following to emplace the new submodule, $ git submodule update --init $ git -C hadrian checkout . Cheers, - Ben

3 2

unix/tests/user001
by Simon Peyton Jones 08 Dec '17

08 Dec '17

On Linux I get this validate failure all the time. What should I do? I've trained myself to ignore it, but that seems wrong Simon Unexpected failures: ../libraries/unix/tests/user001.run user001 [bad stdout] (normal) =====> user001(normal) 1 of 1 [0, 0, 0] cd "./user001.run" && "/5playpen/simonpj/HEAD/inplace/test spaces/ghc-stage2" -o user001 user001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "./user001.run" && ./user001 Actual stdout output differs from expected: diff -uw "./user001.run/user001.stdout.normalised" "./user001.run/user001.run.stdout.normalised" --- ./user001.run/user001.stdout.normalised 2017-12-08 10:22:59.835931843 +0000 +++ ./user001.run/user001.run.stdout.normalised 2017-12-08 10:22:59.835931843 +0000 @@ -4,8 +4,8 @@ getEffectiveGroupID: OK getGroups: OK getEffectiveUserName: OK -getGroupEntryForID: OK -getGroupEntryForName: OK +getGroupEntryForID: ERROR: getGroupEntryForID: does not exist (no such group) +getGroupEntryForName: ERROR: getGroupEntryForID: does not exist (no such group) getAllGroupEntries: OK getUserEntryForID: OK getAllUserEntries: OK *** unexpected failure for user001(normal)

2 3

Can't push to haddock
by Simon Peyton Jones 07 Dec '17

07 Dec '17

I'm trying to push a patch that needs a supporting change to haddock. I've pushed the haddock change to the ghc-head branch of ssh://git@github.com/haskell/haddock.git, which is (according to 'packages') the relevant haddock upstream repo. But when I try to push the GHC patch, I get this message bash$ git push Counting objects: 45, done. Delta compression using up to 32 threads. Compressing objects: 100% (45/45), done. Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done. Total 45 (delta 43), reused 0 (delta 0) remote: performing commit message validations... remote: Commit message validation passed! remote: performing submodule-ref update validations... remote: Submodule update(s) detected in fa29df02a1b0b926afb2525a258172dcbf0ea460: remote: utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65 remote: *FAIL* commit not found in submodule repo ('../haddock.git') remote: or not reachable from persistent branches remote: hooklet hooks/update.secondary.d/check-submodule-refs failed remote: hooks/update.secondary died remote: error: hook declined to update refs/heads/master To ssh://git@git.haskell.org/ghc.git ! [remote rejected] HEAD -> master (hook declined) error: failed to push some refs to 'ssh://git@git.haskell.org/ghc.git' simonpj@cam-05-unx:~/code/HEAD$ What's up? I have pushed the haddock commit! THanks Simon

1 1

Re: Long standing annoying issue in ghci
by Brandon Allbery 05 Dec '17

05 Dec '17

It's indirectly already there: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#t… Possibly an additional pointer needs to be in the FAQ/things to watch out for section. On Tue, Dec 5, 2017 at 5:13 PM, David Feuer <david(a)well-typed.com> wrote: > It sounds like this should be added to the GHCi documentation, even if > it's not strictly about GHCi. > > > > David Feuer > Well-Typed, LLP > > -------- Original message -------- > From: Evan Laforge <qdunkan(a)gmail.com> > Date: 12/5/17 4:49 PM (GMT-05:00) > To: Brandon Allbery <allbery.b(a)gmail.com> > Cc: ghc-devs(a)haskell.org > Subject: Re: Long standing annoying issue in ghci > > Here's what I use: > > :set prompt "\ESC[46m\STX%s>\ESC[39;49m\STX " > > I believe \STX is a signal to haskeline for control sequences. > Documentation is here: > https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt > > On Tue, Dec 5, 2017 at 12:57 PM, Brandon Allbery <allbery.b(a)gmail.com> > wrote: > > On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 < > cheater00(a)gmail.com> > > wrote: > >> > >> without color coding the prompt so I can't really turn it off. It > >> seems like a simple arithmetic issue somewhere in the readline > >> implementation. > > > > > > It's not arithmetic except in the sense that it's not doing *any* math. > > Color codes in a terminal are necessarily implemented as character > sequences > > (this is pretty much the definition of a terminal interface), and > haskeline > > makes no effort to recognize them, so it treats them the same as > displayed > > character sequences and skips over them as if they were displayed > > characters. > > > > GNU readline handles this by recognizing the character mode sequences as > not > > taking up character positions (this is more complex than you think given > > that GNU readline doesn't assume all terminals obey the ANSI standard; > as it > > turns out, neither does haskeline, so it actually gets a bit nasty), and > > recognizing the special behavior of carriage return, and providing \[ \] > > escapes to declare the sequence inside as "invisible" to to character > > positioning (and it's on the person crafting the prompt to insure that it > > actually is). Beyond that, it'd actually have to implement a 'terminal > > emulator' internally to get it right in all cases --- and i'd be on the > user > > to ensure their declared terminal type matches the actual one well enough > > for the 'terminal emulator' to reflect the terminal's actual behavior, so > > it'd be a potential source of even weirder behavior. > > > > So, (a) haskeline issue, not strictly ghc/ghci, and (b) not really > fixable, > > but partially work-around-able for common cases. > > > > -- > > brandon s allbery kf8nh sine nomine > associates > > allbery.b(a)gmail.com > ballbery(a)sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

2 1

Re: Long standing annoying issue in ghci
by David Feuer 05 Dec '17

05 Dec '17

It sounds like this should be added to the GHCi documentation, even if it's not strictly about GHCi. David FeuerWell-Typed, LLP -------- Original message --------From: Evan Laforge <qdunkan(a)gmail.com> Date: 12/5/17 4:49 PM (GMT-05:00) To: Brandon Allbery <allbery.b(a)gmail.com> Cc: ghc-devs(a)haskell.org Subject: Re: Long standing annoying issue in ghci Here's what I use: :set prompt "\ESC[46m\STX%s>\ESC[39;49m\STX " I believe \STX is a signal to haskeline for control sequences. Documentation is here: https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt On Tue, Dec 5, 2017 at 12:57 PM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <cheater00(a)gmail.com> > wrote: >> >> without color coding the prompt so I can't really turn it off. It >> seems like a simple arithmetic issue somewhere in the readline >> implementation. > > > It's not arithmetic except in the sense that it's not doing *any* math. > Color codes in a terminal are necessarily implemented as character sequences > (this is pretty much the definition of a terminal interface), and haskeline > makes no effort to recognize them, so it treats them the same as displayed > character sequences and skips over them as if they were displayed > characters. > > GNU readline handles this by recognizing the character mode sequences as not > taking up character positions (this is more complex than you think given > that GNU readline doesn't assume all terminals obey the ANSI standard; as it > turns out, neither does haskeline, so it actually gets a bit nasty), and > recognizing the special behavior of carriage return, and providing \[ \] > escapes to declare the sequence inside as "invisible" to to character > positioning (and it's on the person crafting the prompt to insure that it > actually is). Beyond that, it'd actually have to implement a 'terminal > emulator' internally to get it right in all cases --- and i'd be on the user > to ensure their declared terminal type matches the actual one well enough > for the 'terminal emulator' to reflect the terminal's actual behavior, so > it'd be a potential source of even weirder behavior. > > So, (a) haskeline issue, not strictly ghc/ghci, and (b) not really fixable, > but partially work-around-able for common cases. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b(a)gmail.com ballbery(a)sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

How to load & parse an HI (interface) file?
by Saurabh Nanda 03 Dec '17

03 Dec '17

(GHC newbie alert -- is this the right mailing list for these kind of questions?) I"m writing some code to figure out all the instances of particular type-classes and after exploring a lot of options (hlint, haskell-src-exts, annotations, doctests, etc), I realized that the compiler had already figured it out and written it to disk for me! More digging led me to https://www.stackage.org/haddock/lts-9.0/ghc-8.0.2/LoadIface.html#v:loadSrc… after which I got stuck. How does one call this function? Specifically: * What is SDoc and how to construct a reasonable value for this argument? * IsBootInterface would mostly be False, right? * What does `Maybe FastString` represent and how does one construct it? * Finally how does one evaluate the resulting monadic action to get access to the underlying `ModIface`? -- Saurabh.

4 8

Re: GHC typecheck API
by Németh Boldizsár 01 Dec '17

01 Dec '17

Thank you for the suggestions! Setting the -fdefer-type-errors flag is indeed a good way to do it (with also adding Opt_DeferTypedHoles and Opt_DeferOutOfScopeVariables for other kind of errors). Boldizsár 2017.12.01. 4:12 keltezéssel, Christopher Done írta: > I suppose setting -fdefer-type-errors would also be handy in this > scenario! > > On Thu, 30 Nov 2017 at 15:37, Simon Peyton Jones via ghc-devs > <ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org>> wrote: > > This sounds like a good project! > > For the most part things look good: > > * Most type checker errors arise from *type constraints*. The type > checkder tries to solve these, but returns an elaborated syntax > tree (i.e. typechecked, and annotated with types) even if > constraint solving fails. > > * Some renamer errors are like this, notably out-of-scope > variables. (They just show up as another constraint.) > > However there is historical baggage. Back in the beginning, most > errors were treated by throwing an exception in the typechecker > monad; such exceptions can be caught, so that we can get more than > one error from the file, but no syntax tree is returned. Example > let f = <expression> in <body> > If there was an error in <expression> we'd throw an exception, > catch it at the 'let', give 'f' the type > f :: forall a. a > and continue to typecheck <body>. > > The trouble with the exception stuff is that you don't get an > elaborated syntax tree. > > So: I think you can get some of the way today, just by returning > the tree anyway even if there is an error to report. But it'd > take a bit more work to make more and more errors into things that > don't throw an exception. (Look for failTc, failRn in thd code.) > > I'm not very familiar with the GHC API for this part, but others > will be. I'm certain it can be improved, so rather than hacking > around what is there already, do propose and implement improvements. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org > <mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Németh > | Boldizsár > | Sent: 30 November 2017 05:42 > | To: ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > | Subject: GHC typecheck API > | > | Dear GHC developers, > | > | I'm developing a framework for development tools for Haskell. I > use the > | GHC API to parse and typecheck the source files. I recently > started to > | work on a quick-fix (automatic program correction) for Haskell > source > | code (correcting parenthesis problems, like 'putStrLn "xxx" ++ > show a' > | ==> 'putStrLn ("xxx" ++ show a)'). To do that I need to get the > typed > | syntax tree even if the program contains type or rename errors. > I could > | only do this by a nasty hack, adding a new TH module finalizer > | (tcg_th_modfinalizers) to extract the type checker's state before it > | fails. Is there a "correct" way to do this? I would not like this > | refactorings to be unusable if the GHC API changes. > | > | By the way, if you know of any similar attempt please let me know. > | > | Sincerely, > | Boldizsár Németh > | haskelltools.org <http://haskelltools.org> > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org <http://ell.org>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=02%7C01%7Csimonpj%40microsoft.com > <http://40microsoft.com>%7C364b8db55e064415650d08d537b > | > 5323f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636476173738772433&sda > | ta=Kf5rZYwht8ZGBtGNNH6Q44wLIeefxzHn2UfDIdrNNMU%3D&reserved=0 > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

3 3

GHC typecheck API
by Németh Boldizsár 30 Nov '17

30 Nov '17

Dear GHC developers, I'm developing a framework for development tools for Haskell. I use the GHC API to parse and typecheck the source files. I recently started to work on a quick-fix (automatic program correction) for Haskell source code (correcting parenthesis problems, like 'putStrLn "xxx" ++ show a' ==> 'putStrLn ("xxx" ++ show a)'). To do that I need to get the typed syntax tree even if the program contains type or rename errors. I could only do this by a nasty hack, adding a new TH module finalizer (tcg_th_modfinalizers) to extract the type checker's state before it fails. Is there a "correct" way to do this? I would not like this refactorings to be unusable if the GHC API changes. By the way, if you know of any similar attempt please let me know. Sincerely, Boldizsár Németh haskelltools.org

2 1

`binary` serializing datatypes deriving Generic wrong on arm (32bit) with GHC HEAD
by Moritz Angermann 28 Nov '17

28 Nov '17

Hi! while trying to make sure cross compilation with Template Haskell works properly with 8.4, I ran into the following situation: When serializing data types, e.g. `Name OccName NameFlavour` in the transmission of Template Haskell Splice results from a 32bit arm device to the x86_64 host ghc. We expect to see: ``` .- 0 (first constructor) .- 1 .- 4 (fifth constructor) .- 4 .- 3 v v v v v \NUL \NUL\NUL\NUL\NUL\NUL\NUL\NUL\SOHf \EOT \NUL \NUL\NUL\NUL\NUL\NUL\NUL\NUL\EOTmain \NUL\NUL\NUL\NUL\NUL\NUL\NUL\ETXTmp '--' '----------------------------------' '---------------------------------' NameSpace PkgName ModName '-------------------------------' '--------------------------------------------------------------------------------' OccName NameG NameSpace PkgName ModName :: NameFlavour '-----------------------------------------------------------------------------------------------------------------------' Name OccName NameFlavour :: Name ``` However, the `NameSpace` on the 32bit arm ends up being 8 bytes. Even though the full `Namespace` data type can be fully serialized in a single byte. The `binary` package tries to compute the size it needs for a generic data type, using the following logic (from binary/src/Data/Binary/Generic.hs): ``` class SumSize f where sumSize :: Tagged f Word64 newtype Tagged (s :: * -> *) b = Tagged {unTagged :: b} instance (SumSize a, SumSize b) => SumSize (a :+: b) where sumSize = Tagged $ unTagged (sumSize :: Tagged a Word64) + unTagged (sumSize :: Tagged b Word64) instance SumSize (C1 c a) where sumSize = Tagged 1 ``` Thus for a simple sum type `data X = A | B` we should get a `sumSize` of 2. The arm32 device however ends up getting 2^33, because `sumSize :: Tagged a Word64` and `sumSize :: Tagged b Word64` each end up being 2^32. With some help from the nice folks in #ghc, I was able to conjure up the following condensed test case: ``` {-# LANGUAGE DeriveGeneric, KindSignatures, PolyKinds, CPP, ScopedTypeVariables, TypeOperators, TypeSynonymInstances, FlexibleInstances #-} {-# OPTIONS_GHC -O2 #-} import GHC.Generics import Data.Word import Debug.Trace data X = A | B deriving (Show, Generic) main :: IO () main = print (sumSize :: Tagged (Rep X)) -- like traceShowId, but allows us to prepend a message. t :: Show a => String -> a -> a #if TRACE t msg x = traceShow (msg ++ show x) x #else t _ = id #endif class SumSize f where sumSize :: Tagged f newtype Tagged (s :: * -> *) = Tagged {unTagged :: WORD} deriving Show instance (SumSize a, SumSize b) => SumSize (a :+: b) where sumSize = t "SumSize (a :+: b): " $ Tagged $ unTagged (t "a :+: b => sumSize :: Tagged a: " $ sumSize :: Tagged a) + unTagged (t "a :+: b => sumSize :: Tagged b: " $ sumSize :: Tagged b) instance SumSize (C1 c a) where sumSize = t "SumSize (C1 c a): " $ Tagged 1 instance SumSize a => SumSize (M1 D c a) where sumSize = t "SumSize (M1 D c a): " $ Tagged . unTagged $ (sumSize :: Tagged a) ``` compiling this with `-DWORD=Word32 -DTRACE=1` yields the correct result (=2), with `-DWORD=Word64 -DTRACE=0` as well. With `-DWORD=Word64 -DTRACE=2` the wrong result (=2^33) Optimization flags seem not to play any role when everything is in a single module (as the test case). As such I have attached the `-ddump-simple -dsuppress-all` files for the Word64 and Word32 with TRACE=1, as well as the diff between the Word32 and Word64 dump. The output with WORD=Word32, TRACE=1 is: ``` "SumSize (C1 c a): Tagged {unTagged = 1}" "a :+: b => sumSize :: Tagged a: Tagged {unTagged = 4294967296}" "a :+: b => sumSize :: Tagged b: Tagged {unTagged = 4294967296}" "SumSize (a :+: b): Tagged {unTagged = 8589934592}" "SumSize (M1 D c a): Tagged {unTagged = 8589934592}" Tagged {unTagged = 8589934592} ``` with WORD=Word64, TRACE=1 is: ``` "SumSize (C1 c a): Tagged {unTagged = 1}" "a :+: b => sumSize :: Tagged a: Tagged {unTagged = 1}" "a :+: b => sumSize :: Tagged b: Tagged {unTagged = 1}" "SumSize (a :+: b): Tagged {unTagged = 2}" "SumSize (M1 D c a): Tagged {unTagged = 2}" Tagged {unTagged = 2} ``` Any help with this would be greatly appreciated! Cheers, Moritz PS: I'm not absolutely sure, but this might also be related to https://ghc.haskell.org/trac/ghc/ticket/13513

1 1