Re: BoxedRep UNPACK pragma

On Sat, Aug 12, 2023 at 5:20 PM Brandon Allbery wrote: > > The warning sounds correct to me: `Maybe` has two constructors? It says at https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/pragmas.html#unpack-pragma "Since 9.6.1, data types with multiple constructors can also be

Re: GHC development asks too much of the host system

> I once tried to generate ETAGS and use them from Emacs (with plain > haskell-mode): this > was quite nice. As Moritz, I didn't use much above syntax coloring, but ETAGS > allowed jumping to definitions, which is important. Maintaining tags wasn't > fun, > on the other hand. Package

Re: Haddock needs help

Talking as a Haskell user, but also a cabal maintainer: the Haddock work Hécate describes is crucial for the health and efficiency of the whole ecosystem and the sooner we can start it, the less drag it's going to have on the rest. Given that GHC expertise is not necessary for many of the tasks

Re: regression in ghc / cabal integration in 9.2.1

al/store/ghc-9.2.1/package.db" to the end of the command > > "ghc-pkg list". For compilation the workaround is to add "-package-db > > $HOME/.cabal/store/ghc-9.2.1/package.db" to the ghc-pkg. I don't understand > > why it was necessary for c

Re: regression in ghc / cabal integration in 9.2.1

Hi George, Since many versions of cabal, `install` only installs executables, not libraries, so if that worked for you, you must have had an old version of cabal. Please see https://github.com/haskell/cabal/issues/6481 for some context and to help you find a new workflow that works for you

Re: GHC | Some refactoring in tcInferApps (!116)

Richard, what you propose totally makes sense to me. Simon, Sylvain, indeed, when I click "toggle comments for this file" in the first patch, I can see not only an avatar, but the whole comment. However, this is only one comment, in both diffs, out of many, which adds to the confusion. May it be

Re: GHC | Some refactoring in tcInferApps (!116)

On Mon, Jan 14, 2019 at 10:28 AM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > > I suppose we could issue guidance NEVER to resolve a discussion, but that seems like the wrong conclusion. It seems gitlab's "resolve discussion" action is supposed to mean "I think nobody needs to

Re: GHC | Some refactoring in tcInferApps (!116)

> Yes, in the discussion tab I can. But of course that is out of context; you > just get a little (non-expandable) snippet. I lack the gitlab experience to push this any further, but I guess an "unresolve discussion" button/checkbox would at least be a stop-gap measure. I couldn't see such a

Re: GHC | Some refactoring in tcInferApps (!116)

> Looking here > https://gitlab.haskell.org/ghc/ghc/merge_requests/116//diffs > I see literally NO discussions with a "toggle discussion" button. Indeed if > I search for "toggle" I get no hits. Oh, I see, you are right with respect to the link you cited now. None of the buttons help, just as

Re: GHC | Some refactoring in tcInferApps (!116)

> Either way, I can’t see any comments whatsoever! It says 5/5 discussions > resolved, but I can’t actually see them. There is not “toggle discussion” > button anywhere. Hello Simon, Just below "5/5 discussions resolved" I can see 5 discussions with “toggle discussion” link to the right of

Re: [Q] Inlining done: evtRead

On Tue, Jan 8, 2019 at 2:10 AM Gabor Greif wrote: > > Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the > inliner to respect the pragma? Yes: https://gitlab.haskell.org/ghc/ghc/commit/b9b1f99954e69f23e9647d00e048938d5509ec14 But it's not on 8.6 branch (yet?).

Re: End of Windows Vista support in GHC-8.6?

On Wed, Mar 7, 2018 at 8:10 AM, Phyx wrote: > In my experience to get a 32 bit build you need to > install the full 32bit msys2. Not just the 32bit compiler in the 64 bit > msys2 (two installs can co-exist). That's also my experience on appveyor (but I'm not compiling GHC

Re: Performance degradation when factoring out common code

Hello, I've had a similar problem that's been fixed in 8.2.1: https://ghc.haskell.org/trac/ghc/ticket/12603 You can also use some extreme global flags, such as ghc-options: -fexpose-all-unfoldings -fspecialise-aggressively to get most the GHC subtlety and shyness out of the way when

Re: SPECIALISE INLINE pragma

> GHC tries hard NOT to choose an INLINE function as a loop breaker. But if > you write > > f x = if ... then 0 else (f x') > {-# INLINE f #-} > > then the only possible loop breaker is 'f', so GHC has to choose it. Indeed. > What else would you suggest? A warning would be very welcome. Given

Re: SPECIALISE INLINE pragma

> On the same topic, I also wrote a blog post simply explaining the > essential things to know > about the inliner and specialiser as I don't think they are generally > appreciated. Comments welcome! > > http://mpickering.github.io/posts/2017-03-20-inlining-and-specialisation.html LGTM. I'd

Re: Early inline

Yay! Is that related to the following ("I also want to investigate making INLINE pragmas fire in the "gentle" phase, on the grounds that that's what the programmer said.")? https://ghc.haskell.org/trac/ghc/ticket/12603#comment:30 On Fri, Feb 17, 2017 at 5:41 PM, Simon Peyton Jones via ghc-devs

Re: Resolving Windows 64-bit linker issues

Resending, since Roman's and Kyril's email addresses were mangled/missing. On Mon, Feb 16, 2015 at 3:43 PM, Simon Peyton Jones simo...@microsoft.com wrote: Darren Excellent! We have a Windows Task Force, consisting roughly of the folk in cc. So they would be the first group to ask. (I

Re: T9938 and T9939 failing

This looks like the result of the new cool patch by SPJ that detects redundant constraints. IIRC, it was supposed to be added to -Wall, but disabled for validate, at least for packages out of our control. ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Program runs out of memory using GHC 7.6.3

tt may be that GHC 7.8 optimizes the program better. Compile with -O0 and see if it runs out of memory, too. If so, you can just optimize the program by hand. I'd suggest making a heap profilie with -O0 or in GHC 7.6 and finding out where the memory goes. Of course, it's possible you've hit a

Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

OK. In that case, let's remember to get *that* version of cabal into 7.8.4. /me conditions himself with chocolate to help the remembering On Sat, Dec 13, 2014 at 11:02 PM, Thomas Tuegel ttue...@gmail.com wrote: On Sat, Dec 13, 2014 at 3:56 PM, Mikolaj Konarski miko...@well-typed.com wrote

Re: Can't compile GHC-7.8.3 from git, fails on haskell98 library

I've brought back the old section about fingerprint.py for 7.8.* to the GettingTheSources wiki page, updated it, to the best of my knowledge, and added the info from the email below. Please correct the section if I mixed up anything. I think, for as long as 7.8.* is in widespread use, the section

Re: Can't compile GHC-7.8.3 from git, fails on haskell98 library

Starting with GHC 7.8.x, fingerprints are written into annotated gpg-signed release tags: http://git.haskell.org/ghc.git/tag/refs/tags/ghc-7.8.3-release That way you're able to restore via the fingerprint for a given release via: ./utils/fingerprint/fingerprint.py restore -f (git show

Re: git question

Now I want to rebase to clean up. Can I just do a local rebase and then git push? Nothing special about the push? You need 'push -f' to force overwriting the old version of your branch. Please make sure you are not forcefully pushing while on master branch, though. ;) (I seem to remember

Re: git question

Right! I'm on branch wip/new-flatten-skolems-Oct14, so git push --force should push just that branch right? Right. But don't trust me, try with --dry-run. If I want to be super-safe, and say push only this branch would I say git push --force HEAD or git push

Re: RFC: Properly stated origin of code contributions

The current situation is suboptimal, as it's unclear where the threshold for adding yourself as an author to a module header is (whitespace/indentation cleanups, fixing/writing docs, removing lines, adding a 5-line function in a 500 line module, ...?), and it's a bit unfair to those that have

Re: git question

On Fri, Oct 31, 2014 at 12:37 PM, Daniel Trstenjak daniel.trsten...@gmail.com wrote: To ensure, that you're only operating on your current branch you can add to your '~/.gitconfig': [push] default = simple Oh, useful. (I seem to remember 'push -f' can be blocked on master, but I

Re: cabal error: http://hackage.haskell.org/packages/archive/00-index.tar.gz : ErrorMisc Error HTTP code: 502

Yes, unfortunatley, hackage was down. See https://status.haskell.org/ I think it's being brought up right now by our fearless volunteer infrastructure rapid response team (they are drafting!). Please try again. On Fri, Oct 31, 2014 at 8:45 PM, George Colpitts george.colpi...@gmail.com wrote:

Re: Tentative high-level plans for 7.10.1

Our intent has always been that that the latest version on each branch is solid. There have been one or two occasions when we have knowingly abandoned a dodgy release branch entirely, but not many. Perhaps we could do the opposite. Announce beforehand that a release branch X is going to be

win32 GHC 7.8.3 works under Wine and i386-linux GHC 7.8.3 works under amd64-linux

Well, sorf-of. A few extra unobvious parameters and workarounds are required in each case, but it's doable, (arguably) simpler than real cross-compilation and already exhibits problems that real cross-compilation may in some circumstances face. Wiki pages (kudos to all previous authors):

Re: win32 GHC 7.8.3 works under Wine and i386-linux GHC 7.8.3 works under amd64-linux

(cross-com^H^H^Hposting to glasgow-haskell-us...@haskell.org) Well, sorf-of. A few extra unobvious parameters and workarounds are required in each case, but it's doable, (arguably) simpler than real cross-compilation and already exhibits problems that real cross-compilation may in some

Re: slow Trac

status.haskell.org Yay, that's neat. I'll keep everyone posted Thank you, Austin. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04

The installation (and using the 32bit GHC on a 64bit Linux, to an extent) should now be possible, as described at https://ghc.haskell.org/trac/ghc/wiki/Building/Compiling32on64 On Fri, Apr 11, 2014 at 08:58:51AM -0500, Austin Seipp wrote: Kyrill, I think that at the moment, you can't really