- ghc-devs - Haskell.org

Cannot unsubscribe
by cheater00 cheater00 14 Dec '17

14 Dec '17

I went to http://mail.haskell.org/cgi-bin/mailman/options/ghc-devs logged in and clicked on "unsubscribe" and no unsubscription email shows up. What do i do to unsubscribe? Thanks

1 1

Long standing annoying issue in ghci
by cheater00 cheater00 14 Dec '17

14 Dec '17

Hi guys, this one seems to have gotten buried under more important things, but maybe someone would like to take a look at it none the less? I've been encountering it literally every day for the last 4 years. I sometimes find it difficult to find read the past commands 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. https://ghc.haskell.org/trac/ghc/ticket/9364 Thanks a lot.

4 9

Re: [GHC] #14537: Do not link to msvcrt.dll
by Phyx 13 Dec '17

13 Dec '17

Add a -v3 to ghc to see what's happening. On Wed, Dec 13, 2017, 07:23 GHC <ghc-devs(a)haskell.org> wrote: > #14537: Do not link to msvcrt.dll > -------------------------------------+------------------------------------- > Reporter: johndoe | Owner: (none) > Type: feature request | Status: closed > Priority: normal | Milestone: > Component: Compiler | Version: 8.2.1 > (Linking) | > Resolution: invalid | Keywords: > Operating System: Windows | Architecture: > | Unknown/Multiple > Type of failure: Other | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by johndoe): > > Well, I tried to modify `specs` directly, but project failed to build: > I've got messagebox that `setup.exe` crashed. > That was on my local machine, but the same you can see on appveyor: > https://ci.appveyor.com/project/johnd0e/pandoc/build/1.0.79 > > I am not sure, maybe my `specs` file is not good: > https://github.com/johnd0e/pandoc/blob/master/specs > But it worked well with other project (not GHC). > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14537#comment:12> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

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