Re: GHC documentation outdated

Am Do., 16. Apr. 2020 um 16:38 Uhr schrieb Wolfgang Jeltsch < wolfgang...@jeltsch.info>: > the URL > > > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html > > seems to still point to the GHC 8.8.3 documentation. > Even worse: http://hackage.haskell.org/package/base has

Re: Gitlab workflow

Am Do., 11. Juli 2019 um 14:32 Uhr schrieb Bryan Richter : > [...] When references to commits (in emails etc.) get invalidated, > it adds confusion and extra work. Seeing this happen is what led me to > wonder why people even prefer this strategy. > I think there is a misunderstanding here: You

Re: Gitlab workflow

Am So., 7. Juli 2019 um 17:06 Uhr schrieb Bryan Richter : > How does the scaling argument reconcile with the massive scope of the > Linux kernel, the project for which git was created? I can find some middle > ground with the more specific points you made in your email, but I have yet > to

Re: Gitlab workflow

Am Sa., 6. Juli 2019 um 19:06 Uhr schrieb Bryan Richter : > [...] Rather than argue against GHC's current practices, however, I would > like > to understand them better. What issues led to a rebase-only workflow? > Which expert opinions were considered? What happy stories can people > relate? We

Re: Why align all pinned array payloads on 16 bytes?

Am Di., 16. Okt. 2018 um 23:18 Uhr schrieb Simon Marlow : > I vaguely recall that this was because 16 byte alignment is the minimum > you need for certain foreign types, and it's what malloc() does. Perhaps > check the FFI spec and the guarantees that mallocForeignPtrBytes and > friends provide?

Re: Parser.y rewrite with parser combinators

Am Di., 9. Okt. 2018 um 15:45 Uhr schrieb Richard Eisenberg < r...@cs.brynmawr.edu>: > [...] What I'm trying to say here is that tracking the backtracking level > in types doesn't seem like it will fly (tempting though it may be). > ... and even if it did fly, parser combinators with

Re: Parser.y rewrite with parser combinators

Am Di., 9. Okt. 2018 um 09:18 Uhr schrieb Vladislav Zavialov < vlad.z.4...@gmail.com>: > [...] With parser combinators > > 1. Parse into an expression (linear in the amount of tokens) > 2. If it turns out we needed a pattern, backtrack and parse into a > pattern (linear in the amount of tokens)

Re: Parser.y rewrite with parser combinators

Am Di., 9. Okt. 2018 um 00:25 Uhr schrieb Vladislav Zavialov < vlad.z.4...@gmail.com>: > [...] That's true regardless of implementation technique, parsers are > rather > delicate. I think it's not the parsers themselves which are delicate, it is the language that they should recognize. > A

Re: GHC 8.6.1 release status

Am Mo., 20. Aug. 2018 um 23:40 Uhr schrieb Matthew Pickering < matthewtpicker...@gmail.com>: > I think the release should include this fix to haddock. Will that happen? > > https://github.com/haskell/haddock/pull/905 Will the release contain the fix

Re: [Haskell-cafe] Access violation when stack haddock haskell-src-exts since LTS 12.0

Am Mo., 23. Juli 2018 um 05:49 Uhr schrieb Yuji Yamamoto < whosekitenever...@gmail.com>: > Thank you very much! > > I confirmed the replaced haddock executable can successfully generate the > docs! > Yesterday I had quite some trouble because of the Haddock problem, too, and I guess I'm not

Re: Re: potential for GHC benchmarks w.r.t. optimisations being incorrect

2018-05-06 16:41 GMT+02:00 Andreas Klebinger : > [...] If we only consider 16byte (DSB Buffer) and 32 Byte (Cache Lines) > relevant this reduces the possibilities by a lot after all. [...] > Nitpick: Cache lines on basically all Intel/AMD processors contain 64 bytes,

Re: Basic Block Layout in the NCG

2018-05-05 21:23 GMT+02:00 Andreas Klebinger : > [...] I came across cases where inverting conditions lead to big > performance losses since suddenly block layout > got all messed up. (~4% slowdown for the worst offenders). [...] > 4% is far from being "big", look e.g.

Re: [ANNOUNCE] GHC 8.4.1 released

2018-03-08 17:57 GMT+01:00 Ben Gamari : > The GHC developers are very happy to announce the 8.4.1 release of > Glasgow Haskell Compiler. [...] Just a few tiny remarks regarding "base": *

Re: Can't push to haddock

2017-12-19 12:47 GMT+01:00 Phyx : > Cool, then let's turn to media reports then such as > https://techcrunch.com/2017/07/31/github-goes-down-and-takes-developer- > productivity-with-it/ do you have one for git.haskell.org going down? Of course this question is a classic

Re: Can't push to haddock

2017-12-19 11:07 GMT+01:00 Phyx : > These are just a few of the times github has been down in 2017 > http://currentlydown.com/github.com compared to haskell.org http:// > currentlydown.com/haskell.org [...] > I can't see any data for haskell.org on that page, apart from the

Re: Can't push to haddock

2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel : > We'd need mirroring anyway, as we want to keep control over our > infrastructure and not have to trust a 3rd party infrastructure to > safely handle our family jewels: GHC's source tree. > I think this is a question of

Re: Can't push to haddock

2017-12-18 17:01 GMT+01:00 Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org>: > | It's for technical reasons, and the strongest one being: GitHub doesn't > | allow us to establish strong invariants regarding submodule gitlink > | referential integrity for submodules (which I implemented

Re: We need to add role annotations for 7.8

2014-03-24 15:14 GMT+01:00 Mark Lentczner : > Speaking from the vantage point of platform This pair of comments > (emphasis mine) have my alarm index on high: > > On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell > wrote: [...] >> So, the best

Re: A modest proposal (re the Platform)

Just a quick +1 for including GHC 7.8 in the next HP release. Regarding compiler features, shipping GHC 7.6.3 again would mean that the HP is still roughly at September 2012 (the first release of GHC 7.6.x). Furthermore, I don't fully buy into the argument that we should wait for 7.8 to stabilize:

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

2017-11-06 17:54 GMT+01:00 Ben Gamari : > Next time something like this arises please do open a ticket. > Yep, will do... > Yes, I have opened a differential adding such a flag. See D4164 [1]. > Please bikeshed to taste. > Thanks for the quick fix! > In general I would

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

2017-11-05 15:37 GMT+01:00 : > A better approach might be to develop a "machine-readable" output format > which then is kept stable, and can be enabled with a flag. Git has a > similar solution. > Without doubt, this is definitely the better approach, but this is hardly what can

Re: [ANNOUNCE] GHC 8.2.2 release candidate 2

This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent discussions on Haskell Cafe showed serious problems with Emacs' haskell-mode due to some ad hoc changes like https://phabricator.haskell.org/D3651. Related GitHub issues:

Re: perf.haskell.org update: Now using cachegrind

2017-09-30 17:56 GMT+02:00 Joachim Breitner : > [...] I also wonder whether, when using cachegrind, the results from > different machines are actually comparable. [...] > In general, they are not really comparable: cachegrind doesn't collect *actual* cache statistics,

Re: RTS changes affect runtime when they shouldn’t

2017-09-26 18:35 GMT+02:00 Ben Gamari : > While it's not a bad idea, I think it's easy to drown in information. Of > course, it's also fairly easy to hide information that we don't care > about, so perhaps this is worth doing regardless. > The point is: You don't know in

Re: RTS changes affect runtime when they shouldn’t

2017-09-23 21:06 GMT+02:00 Joachim Breitner : > what I want to do is to reliably catch regressions. The main question is: Which kind of regressions do you want to catch? Do you care about runtime as experienced by the user? Measure the runtime. Do you care abou code

Re: RTS changes affect runtime when they shouldn’t

2017-09-21 0:34 GMT+02:00 Sebastian Graf : > [...] The only real drawback I see is that instruction count might skew > results, because AFAIK it doesn't properly take the architecture (pipeline, > latencies, etc.) into account. It might be just OK for the average program, >

Re: Which stable GHC release is expected to have support for linear types?

2017-07-11 8:39 GMT+02:00 Joachim Breitner <m...@joachim-breitner.de>: > Am Montag, den 10.07.2017, 16:31 +0200 schrieb Sven Panne: > > You can happily move around any cloned repository, Git has absolutely > > no problem with that. What often breaks is some imperfect tool

Re: Which stable GHC release is expected to have support for linear types?

2017-07-10 13:41 GMT+02:00 Wolfgang Jeltsch : > I renamed the local directory after cloning. If Git really cannot deal > with this, then this is yet another reason for preferring darcs over Git. > [...] > You can happily move around any cloned repository, Git has

Re: [ANNOUNCE] GHC tarballs for Windows 10 Creators Update

2017-04-15 4:58 GMT+02:00 Ben Gamari : > [...} The new tarballs > are distinguished from the original releases with a `-win10` suffix. For > instance, the 64-bit 8.0.2 binary distribution can be found at, > > https://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-x86_64- >

Re: DeriveFoldable treatment of tuples is surprising

2017-03-21 22:29 GMT+01:00 Edward Kmett : > [... In general I think the current behavior is the least surprising as it > "walks all the a's it can" and is the only definition compatible with > further extension with Traversable. [...] > OTOH, the current behavior contradicts my

Re: How, precisely, can we improve?

Just a remark from my side: The documentation/tooling landscape is a bit more fragmented than it needs to be IMHO. More concretely: * We currently have *3* wikis: https://wiki.haskell.org/Haskell https://ghc.haskell.org/trac/ghc https://phabricator.haskell.org/w/

Re: ghc command line arguments parsing

2016-08-19 10:58 GMT+02:00 Harendra Kumar : > Funnily consistency was my point too and not convenience. I totally agree > that consistency is more important. The end objective is less referring to > manuals and rely more on intuition and consistency. Its all about making

Re: ghc command line arguments parsing

2016-08-18 19:59 GMT+02:00 Harendra Kumar : > [...] It only parses a flag which takes an argument. [...] > o_O AFAICT, this is even more non-standard and quite surprising... > As I explained above, I would prefer to keep this bug :-) and document it > especially for

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-16 10:49 GMT+01:00 Ben Gamari : > [...] To this end I recommend the following, > > * Someone propose a consistent vocabulary for warning flag names > > * We keep -fwarn- flags as they are currently > > * We keep the inconsistently named -W flags corresponding to

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-16 10:56 GMT+01:00 Herbert Valerio Riedel : > [...] but `sig(nature)s` has a precedent, so using `-sigs` wouldn't > introduce anything new. > I'm fine with "sigs", my point was only the fact that non-abbreviated words seem to be much more common in the flags names

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-16 0:35 GMT+01:00 Matthew Pickering : > I have renamed it to -Wmissing-pat-syn-signatures. > Hmmm, things are still wildly inconsistent: * "pat" is spelled "pattern" in other flags. * We still have both "sigs" and "signatures" as parts of the names.

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

2016-02-15 20:16 GMT+01:00 Ben Gamari <b...@smart-cactus.org>: > Sven Panne <svenpa...@gmail.com> writes: > The reason for this is that the things missing signatures are pattern > synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs > [1], which is ena

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

I'm a little bit late to the 8.0.1 show, but nevertheless: Motivated by the current discussion about -Wcompat and friends I decided to take a detailed look at the warnings in my projects and hit a regression(?): Somehow I'm unable to suppress the "Top-level binding with no type signature" warnings

Re: Reconsidering -Wall and -Wcompat

2016-02-14 17:12 GMT+01:00 Ben Gamari : > [...] This proposal is motivated by concern expressed by some that -Wcompat > would see little usage unless it is placed in one of the warning sets > typically used during development. One such set is -Wall, which enables > a generous

What is causing the "Unrecognized field abi" warning?

This shows up in more recent builds of my packages on Travis CI, e.g. https://travis-ci.org/haskell-opengl/OpenGL/jobs/93814917#L296, but I don't have a clue what's causing it (GHC? cabal? Something else?), if I should ignore it or if I should somehow act on that. :-/ My gut feeling is that it's

Re: What is causing the "Unrecognized field abi" warning?

2015-11-29 21:42 GMT+01:00 Edward Z. Yang : > [...] If the messages are bothersome, we could setup Cabal to not print out > fields if it knows that GHC doesn't support them. > I would very much appreciate that, especially given the fact that "old versions of GHC" include GHC HEAD

Re: Pattern Synonym Signature Confusion

2015-10-01 13:23 GMT+02:00 Matthew Pickering : > I think that the current state of pattern synonym signatures is quite > confusing, especially regarding the constraints. [...] Thanks to an off-list email from Matthew (thanks for that!) I found out that pattern

Re: HEADS UP: Need 7.10.3?

Building Haddock documentation on Windows for larger packages (e.g. OpenGLRaw) is broken in 7.10.2, similar to linking: The reason is once again the silly Windows command line length limitation, so we need response files here, too. Haddock 2.16.1 already has support for this, but this seems to be

Re: Making compilation results deterministic (#4012)

2015-09-14 19:04 GMT+02:00 Bartosz Nitka : > [...] Uniques are non-deterministic [...] > Just out of curiosity: Why is this the case? Naively, I would assume that you can't say much about the value returned by getKey, but at least I would think that in repeated program runs,

Re: Strange Changelog.md formatting on Hackage

2015-08-06 9:48 GMT+02:00 Joachim Breitner m...@joachim-breitner.de: Dear Sven, Am Mittwoch, den 05.08.2015, 16:57 +0200 schrieb Sven Panne: The formatting of https://hackage.haskell.org/package/StateVar-1.1.0.1/changelog is garbled, while the corresponding GitHub page https

Strange Changelog.md formatting on Hackage

The formatting of https://hackage.haskell.org/package/StateVar-1.1.0.1/changelog is garbled, while the corresponding GitHub page https://github.com/haskell-opengl/StateVar/blob/master/CHANGELOG.md looks OK. Can somebody give me a hint why this happens?

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 2

2015-07-07 7:26 GMT+02:00 Mark Lentczner mark.lentcz...@gmail.com: And now Windows RC2 for Haksell Platform is also here: http://www.ozonehouse.com/mark/platform/ [...] I noticed 2 problems so far: * The package cache is still always out of date (I thought there was a fix for that):

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 2

2015-07-07 13:30 GMT+02:00 Thomas Miedema thomasmied...@gmail.com: On Tue, Jul 7, 2015 at 10:54 AM, Sven Panne svenpa...@gmail.com wrote: * The package cache is still always out of date (I thought there was a fix for that): Please reopen https://ghc.haskell.org/trac/ghc/ticket/10205

Re: Abstract FilePath Proposal

2015-07-04 22:48 GMT+02:00 amin...@gmail.com: I'd argue that Haskell and GHC's history clearly shows we've answered that question and that overalll we value frequent small breaking changes over giant change roadblocks like Perl's or Python's. [...] I'm not sure that value is the right word.

Re: Abstract FilePath Proposal

2015-07-04 4:28 GMT+02:00 Carter Schonwald carter.schonw...@gmail.com: [...] What fraction of currently build able hackage breaks with such an Api change, and how complex will fixing those breaks. [...] I think it is highly irrelevant how complex fixing the breakage is, it will probably

Re: Abstract FilePath Proposal

2015-06-28 16:47 GMT+02:00 Boespflug, Mathieu m...@tweag.io: Notice that the kind of normalization I'm talking about, specified in the link I provided, does not include this kind of normalization. Because it requires the IO monad to perform correctly, and only on real paths. Here is the

Re: [Haskell-cafe] RFC: Native -XCPP Proposal

2015-05-06 16:21 GMT+02:00 Bardur Arantsson s...@scientician.net: +1, I'll wager that the vast majority of usages are just for version range checks. The OpenGL-related packages used macros to generate some binding magic (a foreign import plus some helper functions for each API entry), not just

Re: Branchless implementation for literal case – is it worth it?

2015-04-19 9:44 GMT+02:00 Joachim Breitner m...@joachim-breitner.de: [...] So my question to the general audience: Is such branchless code really better than the current, branching code? Can someone provide us with an example that shows that it is better? Do I need to produce different

Re: Branchless implementation for literal case – is it worth it?

2015-04-20 16:41 GMT+02:00 Joachim Breitner m...@joachim-breitner.de: The conclusion I draw from your mail, at last for our case, is: Don’t bother (and keep the compiler code simple). Is that a correct reading? Yes, I think that's the right approach. Do simple things like e.g. a distinction

Re: GHC 7.10.1 html docs all flat?

2015-03-31 20:20 GMT+02:00 Randy Polen randyhask...@outlook.com: [...] Just want to make sure this is what is expected, and then change the HP build code accordingly. [...] Hmmm, unless there is a strong reason to change this into a flat layout, I would propose to keep the docs hierarchical. I

Re: HP 2015.2.0.0 and GHC 7.10

2015-03-25 7:31 GMT+01:00 Mark Lentczner mark.lentcz...@gmail.com: [...] look over the the source file at GitHub that defines the release see if the version of your stuff looks right The OpenGLRaw and GLUTRaw versions are OK, for OpenGL and GLUT we should use newer versions I just released

Re: FYI: Cabal-1.22.1.0 has been released

2015-02-22 13:35 GMT+01:00 Johan Tibell johan.tib...@gmail.com: We will probably want to ship that with GHC 7.10. My usual request: A Ubuntu package for this in Herbert's Ubuntu PPA. :-) This way we can thoroughly test things in various combinations on Travis CI.

Re: Put Error: before error output

2015-01-23 12:55 GMT+01:00 Konstantine Rybnikov k...@k-bx.com: If warnings will be treated as errors it's fine to have Error: shown for them, I think. +1 for this, it is how e.g. gcc behaves with -Werror, too. So unless there is a compelling reason to do things differently (which I don't see

Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

2014-11-25 20:46 GMT+01:00 Austin Seipp aus...@well-typed.com: We are pleased to announce the first release candidate for GHC 7.8.4: https://downloads.haskell.org/~ghc/7.8.4-rc1/ [...] Would it be possible to get the RC on https://launchpad.net/~hvr/+archive/ubuntu/ghc? This way one could

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki

2014-11-20 9:36 GMT+01:00 Joachim Breitner m...@joachim-breitner.de: [...] With your extensions it will have to read the directory contents. In most situations, that should be fine, but it might cause minor inconveniences with very large directories, many search paths (-i flags) and/or very

Re: Can't install packages with my inplace compiler

Hmmm, is this cabal mess the reason for the problems with GHC head and Cabal head on https://travis-ci.org/haskell-opengl/StateVar/jobs/39533455#L102? I've brought up the problem in another thread, but there was no conclusion. As it is, there seems to be no way to test things with GHC head on

Re: cabal sdist trouble with GHC from head

2014-10-29 23:55 GMT+01:00 Herbert Valerio Riedel hvrie...@gmail.com: Fyi, there's a `cabal-install-head` package now[1] (may take a few minutes till its properly published in the PPA though); please test it and lemme know if it works as expected... [1]:

Re: cabal sdist trouble with GHC from head

2014-10-30 17:20 GMT+01:00 Austin Seipp aus...@well-typed.com: [...] So this just means that Cabal isn't necessarily *future compatible* with future GHCs - they may change the package format, etc. But it is backwards compatible with existing ones. OK, that's good to know. To be sure, I've just

Re: cabal sdist trouble with GHC from head

2014-10-22 15:16 GMT+02:00 Sven Panne svenpa...@gmail.com: Does anybody have a clue what's going wrong at the sdist step here? https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38707011#L104 This only happens with a GHC from head, a build with GHC 7.8.3 is fine: https://travis

Re: cabal sdist trouble with GHC from head

2014-10-23 15:01 GMT+02:00 Alan Kim Zimmerman alan.z...@gmail.com: cabal has changed for HEAD, you need to install 1.21.1.0 Hmmm, so we *force* people to update? o_O Perhaps I've missed an announcement, and I really have a hard time deducing this from the output on Travis CI. Is 1.21.1.0

Re: Making GHCi awesomer?

2014-10-22 3:20 GMT+02:00 Carter Schonwald carter.schonw...@gmail.com: i'm pretty sure they're usable in ghci... i think theres just certain flags that need to be invoked for one reason or another, but I could be wrong (and i've not tried in a while) I just gave a few OpenGL/GLUT examples a

cabal sdist trouble with GHC from head

Does anybody have a clue what's going wrong at the sdist step here? https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38707011#L104 This only happens with a GHC from head, a build with GHC 7.8.3 is fine: https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38707010 Any help highly

Re: [Haskell] ANNOUNCE: GHC version 7.8.3

2014-09-01 9:26 GMT+02:00 Simon Marlow marlo...@gmail.com: Hi Sven - you would need to compile the module with -dynamic or -dynamic-too to have it be picked up by the new dynamically-linked GHCi in 7.8. Ah, OK... Adding -dynamic makes this work, but with -dynamic-too, ghci still loads the

Re: Release building for Windows

2014-08-04 14:59 GMT+02:00 Mikhail Glushenkov the.dead.shall.r...@gmail.com: https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ Hmmm, this isn't very specific, it just says that there are probably bugs, but that's true for almost all code. :-) Are there any concrete issues with

Re: At long last: 2014.2.0.0 Release Candidate 1

2014-07-24 16:24 GMT+02:00 Mark Lentczner mark.lentcz...@gmail.com: On Thu, Jul 24, 2014 at 1:25 AM, Sven Panne svenpa...@gmail.com wrote: The source tarball is missing a few files for hptool: I'll try to catch them the next round... or pull requests on github welcome! The structure on GitHub

Re: At long last: 2014.2.0.0 Release Candidate 1

The source tarball is missing a few files for hptool: hptool/src/HaddockMaster.hs hptool/src/OS/Win.hs hptool/src/Releases.hs hptool/src/Releases2012.hs hptool/src/Releases2013.hs hptool/src/Templates.hs hptool/src/Website.hs I guess these are missing from

Re: Folding constants for floats

2014/1/14 Carter Schonwald carter.schonw...@gmail.com: maybe so, but having a semantics by default is huge, and honestly i'm not super interested in optimizations that merely change one infinity for another. What would the alternative semantics be? I'm not sure that I understood your reply: My

Re: Building GHC head with clang on Mavericks

2014/1/2 Carter Schonwald carter.schonw...@gmail.com: it looks like their work around is using ## rather than /**/ Well, actually lens is bypassing the problem by using cpphs, not the C preprocessor. :-P OpenGLRaw is part of the Haskell Platform, and cpphs is not, so I can't simply depend on it.

Re: Building GHC head with clang on Mavericks

Although it is not really GHC-related, this thread is sufficiently close to the problem described in https://github.com/haskell-opengl/OpenGLRaw/issues/18: AFAICT, Mac OS X 10.9's clang doesn't really honor -traditional, so what can I do to make things work with recent Macs without breaking all

Re: Building GHC head with clang on Mavericks

2014/1/2 Carter Schonwald carter.schonw...@gmail.com: sven,http://www.haskell.org/platform/mac.html has a wrapper script that makes clang play nice with CPP, though a simpler alternative one can be found on manuel's page [...] I've seen the wrappers before, but do they really solve the