- ghc-devs - Haskell.org

GHCi recompilation avoidance UI
by David Feuer 11 Dec '17

11 Dec '17

Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now refuses to load optimized code unless -fobject-code (and optimization flags) are enabled. I propose the following slight modification to https://ghc.haskell.org/trac/ghc/ticket/13604#comment:48 1. Optimization flags (except -O0) imply -fobject-code. This ensures that GHC respects optimization flags regardless of --interactive. 2. Even when -fobject-code is on, :load *M will load M as bytecode. This provides the "escape hatch" from -fobject-code that you need to use debugging features, etc. 3. New -fignore-optim-changes and -fignore-hpc-changes (Phab:D4123) flags should enable users to put together object code and bytecode with diverse optimization levels/options and HPC options while still updating automatically based on source changes and whether profiling is enabled. Does this seem like a reasonable way forward? David Feuer

5 8

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