Re: Call for GHC Maintainers

Moritz, Moritz Angermann writes: > I know that there are some people who deeply care for personal or > professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of You skipped GHC 8.2 ;-) In any way, I'd be interested in helping making GHC 8.2.3+ happen! Cheers, Herbert signature.asc

Re: Question about negative Integers

On Fri, Nov 15, 2019 at 5:04 PM Sylvain Henry wrote: > Question is: do we need/want to keep this behavior? Yes ;-) I chose it quite intentionally after benchmarking and carefully examining various approaches, and with the intent to use a common-denominator representation which would be easy

Re: Proposal: Don't read environment files by default

On 2019-03-28 at 18:33:58 +, Michael Peyton Jones wrote: > +1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the approach used > by many other tools that handle this kind of thing. For example: ..just because everyone else does it this way doesn't mean that it's the best way.. I'd

Re: Proposal: Don't read environment files by default

On 2019-03-28 at 15:55:01 +0200, Bryan Richter wrote: [...] > If we want Nix-style builds, let's do them Nix style, and use a shell. Cabal supports multiple workflows/idioms. Sometimes you want a transient sub-shell (which is the one you're e.g. limited to when using Stack), while sometimes you

Re: Proposal: Don't read environment files by default

Matthew, I realize this to be a controversial issue, but what you're suggesting is effectively an attempt at cutting this cabal V2 feature off at the knees ("If Cabal won't change its default let's cripple this feature on GHC's side by rendering it pointless to use in cabal"). If ghc environment

Re: Discussion: Hadrian's defaults

On Thu, Mar 14, 2019 at 4:20 PM Spiwack, Arnaud wrote: > >- The -c option should be the default. > > Very strong -1 from me on this one; I've been quite vocal on the Hadrian issue tracker early on and multiple times against having Hadrian invoke ./configure at all, even more so against

Re: [GHC DevOps Group] The future of Phabricator

On 2018-11-02 at 08:13:37 +, Simon Marlow wrote: > What about the wiki? Can we migrate that off Trac too? I worry that it's a lot of work to migrate it away while preserving the special markup and features that Trac provides; so the resulting pages will require a significant amount of manual

Re: The future of Phabricator

On 2018-10-30 at 11:53:18 +, Matthew Pickering wrote: [...] > A compelling argument to move to gitlab is the possibility of tighter > integration between the patches and tickets. You don't need to move to GitLab to achieve that, do you? In fact, we had this project where somebody invested

Re: [GHC DevOps Group] The future of Phabricator

On 2018-10-30 at 00:54:42 -0400, Ben Gamari wrote: > TL;DR. For several reasons I think we should consider alternatives to >Phabricator. My view is that GitLab seems like the best option. > > > Hello everyone, > > Over the past year I have been growing increasingly weary of our >

Re: [ANNOUNCE] GHC 8.6.1 released

Hello everyone, Here's an addendum to the announcment as it ommitted an important detail: GHC 8.6.1 is only guaranteed to work properly with tooling which uses lib:Cabal version 2.4.0.1 or later. As such, GHC 8.6.1 works best with ​`cabal-install` 2.4.0.0 or later; please upgrade to

Re: Any ways to test a GHC build against large set of packages (including test suites)?

Hi Artem, On Fri, Aug 10, 2018 at 11:05 AM Artem Pelenitsyn wrote: > The task seems to be not solvable even if an affected package (stm in your > case and primitive in mine) has already adopted in its master the breaking > change but has no corresponding release on Hackage (which will always

Re: How do you build base with your own compiler?

Note that `base` is mostly a normal cabal package and you can easily build it with `cabal new-build` if that's any help. On Thu, Jun 28, 2018 at 7:09 PM Christopher Done wrote: > > I've built the GHC compiler along with libraries/base in the canonical way. > > Now, I want to compile base with my

Re: Site of ghc.haskell.org is down?

Hi *, Should be fixed now. Please check. -- hvr On Sun, Apr 15, 2018 at 7:49 PM, Simon Peyton Jones via ghc-devs wrote: > I'm getting this too. > > -- > The owner of ghc.haskell.org has configured their website improperly. To > protect your information from being

Re: 8.5 build failure

Hi Simon et al. On Tue, Apr 3, 2018 at 5:37 PM, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > It seems to be caused by some missing Makefile dependency > > > > It may be significant that the dependency is a module in libraries/base > GHC/IO.hs-boot depending on one

Re: [Haskell-cafe] GHC 8.2.2 for WSL Ubuntu 16.04

Hello *, Even though WSL may eventually address this issue for good, I've setup a new WSL-optimised flavour of my PPA for Ubuntu 16.04 LTS https://launchpad.net/~hvr/+archive/ubuntu/ghc over at https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl I don't have experience myself with Ubuntu

Re: Can't push to haddock

Hi, On 2017-12-19 at 08:31:06 +0100, Sven Panne wrote: > This is a tradeoff: Doing it that way, you catch incorrect commits a > little bit later, but it makes the overall arcane repository magic > quite a bit simpler, probably removing the need for mirroring. We'd need mirroring anyway, as we

Re: The build is broken (Solaris/x86, FreeBSD/{i386,amd64})

On 2014-04-15 at 06:52:42 +0200, Jan Stolarek wrote: >> I think Simon Marlow is even more conservative, and >> does his validate builds in a separate tree so he catches missing >> files. > I thought everyone is doing that. Btw, using such a workflow[1] is actually almost a necessity if you

Re: Observation on Hadrian's relative performance re current buildsystem

Hi Malcolm, On 2017-11-18 at 11:09:28 +, Malcolm Wallace wrote: [...] > But surely the timing for a full build from scratch is not the most > important thing to compare? In my work environment, full builds are > extremely rare; the common case is an incremental build after pulling >

Observation on Hadrian's relative performance re current buildsystem

Hello GHC devs, I took the opportunity to give Hadrian a test-run to see whether it could live up to the big promise of delivering a "more scalable, faster" system than the current GNU Make based system. Unfortunately, my preliminary results don't back this claim, and actually make Hadrian appear

Re: Hadrian

Hi Moritz (et al.), On 2017-10-20 at 09:32:29 +0800, Moritz Angermann wrote: > a) why a git subtree if we keep working on github with hadrian, wouldn't that > imply using a submodule? We use submodules for >all the other ghc boot libs that are not part of the tree and are > developed on

ANN: Overlay Hackage Package Index for GHC HEAD

Hi GHC devs, A long-standing common problem when testing/dogfooding GHC HEAD is that at some point during the development cycle more and more packages from Hackage will run into build failures. Obviously, constantly nagging upstream maintainers to release quickfixes for unreleased GHC HEAD

Re: Semigroup repeat (base package)

Hi, On Sun, Sep 10, 2017 at 9:24 AM, Harendra Kumar wrote: > I could not find a function that repeats a value using a semigroup append. I > am looking for something like this: > > srepeat :: Semigroup a => a -> a > srepeat x = xs where xs = x <> xs > > Is it already

Re: Convenient URL alias for Trac tickets

Good idea! ...btw, note that a couple years ago, I set up the little known http://ghc.haskell.org/ticket/1234 alias... :-) On Fri, Sep 1, 2017 at 8:26 PM, Ben Gamari wrote: > Hello everyone, > > Earlier today a contributor requested that we have an easier-to-remember

Re: Alex install failure

On Sat, Aug 19, 2017 at 12:43 AM, Simon Peyton Jones via ghc-devs wrote: > | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by > | any chance? > > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. So > what? Then you're

Re: GHC release timing and future build infrastructure

Hi! On 2017-08-03 at 08:41:59 +0200, Ara Adkins wrote: [...] > I nevertheless see `stack` as a huge boon for easing adoption of new > compiler versions (and hence new language features/extensions). Since I totally disagree about Stack being beneficial to the quick adoption of new features,

Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward))

mply have those files installed in a place we can easily locate (again, from a custom Setup.hs) Does this make any sense; which option do you prefer? Also, I'd like to know if you can think of reasons why or situations when the reinstalled lib:ghc wouldn't work; or other reasons why this is a b

Re: Removing Hoopl dependency?

Hi Simon, On 2017-06-09 at 09:50:51 +0200, Simon Peyton Jones via ghc-devs wrote: [...] >> Stackage only allows one version of each package > > I didn’t know that, but I can see it makes sense. That makes a strong > case for re-doing it as a new package hoopl2 The limitations of Stackage's

Re: 8.2 and earlier build times

On Wed, May 17, 2017 at 10:56 AM, Simon Peyton Jones via ghc-devs wrote: > That's great news! Faster than GHC 7.8! We should advertise this :-). However, not everything is back to 7.8 levels when looking at the time-dimension, e.g. for regex-tdfa-1.2.2 (with reasonably

Re: GHC 8.2.1-rc1 source tarball availability

$ tar xOf ghc-8.2.0.20170404-src.tar.xz ghc-8.2.0.20170404/GIT_COMMIT_ID ; echo d67f0471cd3584c5a548ff30c9023b599b598d3e On Tue, Apr 4, 2017 at 9:01 AM Alan & Kim Zimmerman wrote: > There is no tag in the source tree, which commit has been used? > > Alan > > On 4 April

Re: Allow top-level shadowing for imported names?

Hi, On 2016-10-04 at 13:12:54 +0200, Yuras Shumovich wrote: > On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote: > >> It makes additions of names to libraries far less brittle. You can >> add a >> new export with a mere minor version bump, and many of the situations >> where >> that causes

Allow top-level shadowing for imported names?

Hi *, I seem to recall this was already suggested in the past, but I can't seem to find it in the archives. For simplicity I'll restate the idea: foo :: Int -> Int -> (Int,Int) foo x y = (bar x, bar y) where bar x = x+x results merely in a name-shadowing warning (for

Re: How, precisely, can we improve?

On 2016-09-28 at 03:51:22 +0200, Richard Eisenberg wrote: [...] > Despite agreeing that wikis are sometimes wonky, I thought of a solid > reason against moving: we lose the Trac integration. A Trac wiki page > can easily link to tickets and individual comments, and can use > dynamic features

Re: Pusing to haddock

On 2016-06-13 at 23:44:14 +0200, Ben Gamari wrote: > Simon Peyton Jones writes: >> Devs, >> I want to push to the haddock repo, to fix the build. But I can’t. >> .git/modules/utils/haddock/ contains >> >> [remote "origin"] >> >>url = git://git.haskell.org/haddock.git

Re: Why upper bound version numbers?

On 2016-06-09 at 19:43:42 +0200, David Fox wrote: >> or even worse silent failures where the code behaves >> subtly wrong or different than expected. Testsuites mitigate this to >> some degree, but they too are an imperfect solution to this hard >> problem. > ​It seems to me that if you have any

Re: Why upper bound version numbers?

On 2016-06-07 at 02:58:34 +0200, Dominick Samperi wrote: > I guess what you are saying is that this policy will prevent packages > from installing with new versions of ghc until the maintainer has had > a chance to test the package with the new version, and has updated the > upper version limit.

Proposal: Left-Associative Semigroup Operator Alias in "Data.Semigroup"

Hello! In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>) subtly conflicts with definitions of (<>) in pretty printing APIs, for which the left-associative variant is sometimes desirable. This subtle overloading of (<>) is error-prone, as one has to remember which version of

Re: Stop rejecting Summary: Signed-off-by: ... OR patch Phabricator

On 2016-05-13 at 00:40:03 +0200, Edward Z. Yang wrote: > Currently the commit hooks reject commit messages that look like: > > Summary: Signed-off-by: Edward Z. Yang > > Unfortunately, if I do a one line commit message with -s, Phabricator > will automatically reformat

Re: [ANNOUNCE] GHC 8.0.1 source tarball available

On 2016-05-12 at 12:47:05 +0200, Ben Gamari wrote: [...] > I've pushed the result to the ghc-8.0 branch and have pushed a set of > new source tarballs to the usual URL. The new release commit is > > b594f8191273f4c913bc8413d30fd3061bb577c1 fyi, an easy way to verify you have the intended

Re: GHC 8 and Template Haskell

On 2016-04-15 at 00:04:05 +0200, Iavor Diatchki wrote: > Sure, I'd be happy to help whoever needs help---just let me know. Great... :-) > The change that one would have to do is: whenever you'd used "InstaceD" > replace it with "InstanceD Nothing". I've done a quick grep for InstanceD over

Re: GHC 8 and Template Haskell

On 2016-04-14 at 23:11:26 +0200, Iavor Diatchki wrote: [...] > If we were to delay things, we would ship a version of the library that has > missing functionality *and* we'll break everyone's code on the next > release. > If we make the change now, then at least when people fix their TH >

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

On 2016-02-18 at 13:32:59 +0100, Andrey Mokhov wrote: [...] > Interesting! In the new Shake-based build system we also need to > automagically generate .hs files using Alex et al. My first > implementation was slow but then I realised that it is possible to > scan the source tree only once and

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

On 2016-02-16 at 08:00:49 +0100, Sven Panne wrote: >> 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. I simple

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

On 2016-02-15 at 21:05:29 +0100, Sven Panne wrote: [...] >* Given the myriad of warning-related options, It is *extremely* hard to > figure out which one caused the actual warning in question. The solution to > this is very easy and done this way in clang/gcc (don't remember which one, > I'm

Re: New type of ($) operator in GHC 8.0 is problematic

On 2016-02-15 at 12:00:23 +0100, Yuras Shumovich wrote: [...] >> - It is possible to have unlifted types about even without >> -XMagicHash. -XMagicHash is simply a lexer extension, nothing more. >> By convention, we use the # suffix with unlifted things, but there's >> no requirement here.

Re: Reconsidering -Wall and -Wcompat

On 2016-02-15 at 11:33:09 +0100, Boespflug, Mathieu wrote: [...] > * include -Wcompat and -Wall, but make it "magic" so that -Wcompat > never causes a build to fail even when users set -Wall -Werror. Tbh, I don't like the "magic" part at all. In fact, I currently rely on `-Wcompat -Werror`

Re: Reconsidering -Wall and -Wcompat

On 2016-02-14 at 19:51:19 +0100, Sven Panne wrote: [...] > As stated on the Wiki, stuff in -Wcompat will often be non-actionable, > so the only option I see if -Wcompat is included in -Wall will be > -Wno-compat for all my projects. This depends on what we mean by "actionable". I'm not sure I'd

Re: Reconsidering -Wall and -Wcompat

On 2016-02-15 at 04:47:56 +0100, Richard Eisenberg wrote: > On Feb 14, 2016, at 1:51 PM, Sven Panne wrote: >> >> IMHO, the distinction between "during development" and "outside of it" is >> purely hypothetical. > > I find this comment quite interesting, as I see quite a

Re: [ANNOUNCE] Shaking up GHC

On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote: >> Are there any plans as to how to include it in the GHC tree? Does it >> ship with all the libraries required to build the build system, will we >> have a mini-build system to bootstrap it? If I recall correctly, we rely >> on Cabal sandboxes

Re: [ANNOUNCE] Shaking up GHC

On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote: [...] > My suggestion, and what I'd expect, is to make Shake part of GHC's > included lib, just like process or xhtml. please don't; the only reason we include process and xhtml because we *have* to. The less we *have* to bundle, the better.

Re: vectorisation code?

On 2016-01-22 at 17:23:18 +0100, Geoffrey Mainland wrote: > I didn't mean to suggest that DPH should be part of every build, just > that it should be part of *some* regular build. > > If we're willing to do that, then I'm certainly willing to get DPH > back up and running. What's the situation

Re: CallStack naming

On 2016-01-20 at 06:39:32 +0100, Richard Eisenberg wrote: > I'm sure there's an easy answer to this, but I'm wondering: why is the > CallStack feature implemented with implicit parameters instead of just > a magical constraint? Whenever I use this feature, I don't want to > have to enable

GHC 8.0 Migration Guide & Ubuntu GHC8/cabal packages (was: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1)

On 2016-01-13 at 16:43:35 +0100, Ben Gamari wrote: > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide can be found at > >

Re: ExprWithTySigOut

Hi, Btw, I also used that annoying pattern in https://phabricator.haskell.org/D1185 to represent type-signature sections before/after typechecking: ​ -- | Type-signature operator sections ​ ​ | TySigSection(LHsType id) ​ (PostRn id [Name]) -- wildcards ​ ​ |

Re: Can't push to haddock repo

In the GHC tree: $ grep haddock packages utils/haddock- - ssh://g...@github.com/haskell/haddock.git says that the upstream repo for Haddock is ssh://... (there are some comments in the 'packages' file that explain what the last column

Status of deprecation/warning features (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

On 2015-09-28 at 04:56:13 +0200, David Feuer wrote: [...] > That's an excellent idea, and I think it makes sense to offer it at the > module level as well as the class level. Just change DEPRECATED to REMOVED > when it's actually removed. Speaking of such, has the deprecated export > proposal

Re: MIN_VERSION macros

On 2015-09-25 at 20:48:52 +0200, Richard Eisenberg wrote: > I've run into this issue, too. Post a feature request! I can't imagine > it's too hard to implement. For the current external CPP we'll probably have to create a temporary file with the definitions (just like cabal does) to -include (as

ANN: CfN for new Haskell Prime language committee

Dear Haskell Community, In short, it's time to assemble a new Haskell Prime language committee. Please refer to the CfN at https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html for more details. Cheers, hvr -- PGP fingerprint: 427C B69A AC9D 00F2 A43C AF1C BA3C

Re: download all of Hackage?

On 2015-09-14 at 16:43:44 +0200, Richard Eisenberg wrote: > Is there an easy way to download (but not compile) all of Hackage? I > know of the hackager package, but that's about compiling. I just want > a whole big load of Haskell code to play with. I thought I could find > a link on Hackage to do

Arcanist "lite" Haskell reimplementation (was: Proposal: accept pull requests on GitHub)

On 2015-09-03 at 11:53:40 +0200, Thomas Miedema wrote: [...] > In my opinion it's is a waste of our time trying to improve `arc` (it is > 34000 lines of PHP btw + another 7 LOC for libphutil), when `pull > requests` are an obvious alternative that most of the Haskell community > already

Re: Shared data type for extension flags

On 2015-09-02 at 10:00:40 +0200, Matthew Pickering wrote: > Surely the easiest way here (including for other tooling - ie > haskell-src-exts) is to create a package which just provides this > enumeration. GHC, cabal, th, haskell-src-exts and so on then all > depend on this package rather than

Re: more releases

On 2015-09-02 at 12:43:57 +0200, Ben Gamari wrote: [...] > The question is whether users want more rapid releases. Those working on > GHC will use their own builds. Most users want something reasonably > stable (in both the interface sense and the reliability sense) and > therefore I suspect

Re: Planning for the 7.12 release

On 2015-09-01 at 13:57:17 +0200, Harry . wrote: > Proposal: Make Semigroup as a superclass of Monoid > https://mail.haskell.org/pipermail/libraries/2015-April/025590.html The plan is to (at the very least) move Data.Semigroups and Data.List.NonEmpty to base for GHC 7.12 If we have enough time we

Please help beta test no-reinstall Cabal (was: Cabal and simultaneous installations of the same package)

Good news, everyone! ...you may be interested to know this has finally come to fruition (just in time for HIW): http://blog.ezyang.com/2015/08/help-us-beta-test-no-reinstall-cabal/ Cheers, hvr On 2015-03-23 at 09:45:48 +0100, Simon Peyton Jones wrote: Dear Cabal developers You'll

Re: Planning for the 7.12 release

For the record, I wanted to implement this feature a couple of months ago but then got side-tracked. If somebody wants to pick it up (which would be great), please lemme know. In the meantime I've created https://ghc.haskell.org/trac/ghc/ticket/10803 and write up the little information I

Re: Planning for the 7.12 release

On 2015-08-28 at 12:31:13 +0200, Kosyrev Serge wrote: [...] * A (possible) overhaul of GHC's build system to use Shake instead of Make. Is there a breakdown of what remains to be done on this front? Btw, here's the GitHub repo were you can track the progress:

Re: Planning for the 7.12 release: MonadFail

On 2015-08-27 at 18:38:46 +0200, Simon Peyton Jones wrote: Great. Is there a ticket? If not, we'll probably lose track of it. https://ghc.haskell.org/trac/ghc/ticket/10751 :-) ___ ghc-devs mailing list ghc-devs@haskell.org

Querying the git commit id of GHC snapshots (was: ANNOUNCE: GHC 7.10.2 Release Candidate 1)

On 2015-07-03 at 05:26:44 +0200, Greg Weber wrote: Is the 7.10.2 hvr ppa using this RC? ...it's easy to check, as since 7.10 we embed the Git commit id into the source-tarball as well as into the generated ghc binary: $ /opt/ghc/7.10.2/bin/ghc --info | grep Git ,(Project Git commit

Re: Abstract FilePath Proposal

On 2015-06-27 at 03:30:56 +0200, Bardur Arantsson wrote: [...] I am *entirely* behind this in priciple and if it doesn't break too much of Hackage, also in practice, but... ... how much of Hackage *does* this break? This won't be for free: I expect most packages which currently do more than

Re: Abstract FilePath Proposal

On 2015-06-27 at 14:56:33 +0200, David Fox wrote: [...] ​I've had success with a slightly different How: What was your concrete use-case btw? Phase 1: Replace FilePath with a type class, with instances for the old FilePath (i.e. String) and the new implementation. what would that comprise

Abstract FilePath Proposal

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello *, What? = We (see From: CC: headers) propose, plain and simple, to turn the currently defined type-synonym type FilePath = String into an abstract/opaque data type instead. Why/How/When? = For details (including

Native -XCPP Conclusion (was: RFC: Native -XCPP Proposal)

plan 4[1]? [1]: https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp [2]: http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/8869 Thanks, HVR On 2015-05-06 at 13:08:03 +0200, Herbert Valerio Riedel wrote: Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language

Re: GHC build failure

On 2015-06-11 at 16:37:47 +0200, Wolfgang Jeltsch wrote: I just updated my GHC HEAD copy via git pull and tried to rebuild GHC with BuildFlavour set to devel2. I got the following error message: ghc/InteractiveUI.hs:68:8: error: Could not find module ‘Control.DeepSeq’ It

Re: MonadFail proposal (MFP): Moving fail out of Monad

On 2015-06-10 at 00:42:12 +0200, David Luposchainsky wrote: [...] I think there are two important consequences of MonadFail. First of all, we can all safely write failable patterns if we so desire. Second, the compiler can ensure other people's codebases do not lie to us (knowingly or

Re: MonadFail proposal (MFP): Moving fail out of Monad

On 2015-06-09 at 22:43:30 +0200, David Luposchainsky wrote: [...] https://github.com/quchen/articles/blob/master/monad_fail.md Here's a short abstract: - Move `fail` from `Monad` into a new class `MonadFail`. [...] +1 obviously :-) ___ ghc-devs

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

Hi Yitzchak, On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote: [...] Bardur Arantsson wrote: I don't see any need for an option. Just bundle cpphs together with GHC and build/use it as an external program. AFAICT this has absolutely no licensing implications for GHC, derived from GHC or

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

On 2015-05-21 at 18:02:57 +0200, Brandon Allbery wrote: On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC

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

On 2015-05-21 at 16:54:11 +0200, Bardur Arantsson wrote: [...] That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser. fork/exec is almost certainly going to be negligable compared

Re: GHC Trac slow again

On 2015-05-20 at 12:48:50 +0200, Simon Peyton Jones wrote: Did you manage to fix your Trac re-initialiser? Trac is soul-destroyingly slow today ...the periodic apache2 reloader is still working... not sure why it's still slow *today*... (otoh, for me it's currently not that slow)

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

Hello, On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: If the intention is to use cpphs as a library, won't the license affect every program built with the GHC API? That seems to be a high price to pay. Yes, every program linking the `ghc` package would be affected by LGPL+SLE albeit

Re: RFC: Native -XCPP Proposal

On 2015-05-06 at 18:53:08 +0200, Howard B. Golden wrote: At the risk of antagonizing some (most? all?) of you, how about... -XCPP stands for the native CPP -XGNUCPP stands for GNU's GCC CPP -XClangCPP stands for Clang's CPP -XCPPHS stands for CPPHS Assuming this was a serious suggestion,

Re: RFC: Native -XCPP Proposal

On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project

RFC re #10196 GHC 7.10.2: Allow Unicode Lm category for 2nd+ character on in identifiers

Hello *, As you may be aware, GHC 7.10.1 updated its Unicode catalog to version 7.0, thereby causing some subscript symbols to change character properties, thereby causing GHC 7.10.1 to reject some Unicode-subscript characters that GHC 7.8.4 accepted. See

RFC: Native -XCPP Proposal

Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a traditional mode c-preprocessor. This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed

Re: RFC: Native -XCPP Proposal

On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote: As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a traditional mode c-preprocessor. Yes. This is one of my favourite things in GHC-land --

Re: Help wanted: working on the GHC webpage

Hi Sergey, On 2015-04-03 at 15:16:24 +0200, Sergey Bushnyak wrote: [...] 3) Also, it might be easier to publish blog posts on this site, like weekly news, without linking to `track`. I can reuse some code we are using for building haskell.od.ua (OdHug, Odessa Haskell User Group) Why would

Re: wither the Platform

On 2015-03-25 at 15:24:30 +0100, Mark Lentczner wrote: [...] Concrete proposal based on that and the other fine input in the responses: *Simultaneous Release:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC

Re: wither the Platform

On 2015-03-25 at 06:52:22 +0100, Mark Lentczner wrote: On Tue, Mar 24, 2015 at 8:20 PM, Gershom B gersh...@gmail.com wrote: install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package with an API binding for some webservice which has not been updated in two years and requires an

Re: wither the Platform

On 2015-03-25 at 10:52:20 +0100, Simon Peyton Jones wrote: [...] • Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded. [...] I guess the solution is to release a new version of HP. IMHO, if HP releases are to happen more

Re: Shake fails test with GHC 7.10 RC3

On 2015-03-21 at 08:21:20 +0100, Herbert Valerio Riedel wrote: On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote: [...] 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact no one else hit this with RC2 might just be because its a very recent regression. We

Re: Shake fails test with GHC 7.10 RC3

On 2015-03-18 at 16:33:00 +0100, Neil Mitchell wrote: [...] I was wondering if there have been any state hack related changes or other potentially dangerous optimisation changes since RC2? I'll continue to try reducing the bug, but it's somewhat difficult as the larger system is quite big,

Re: How to better parallelize GHC build.

On 2015-03-07 at 11:49:53 +0100, Karel Gardas wrote: [...] Is there anything else which may be done to fix that issue? Is someone already working on some of those? (I mean those reasonable from the list)? are you aware of https://ghc.haskell.org/trac/ghc/wiki/Building/Shake and

Re: Proposal: Turn on ScopedTypeVariables by default

On 2015-02-23 at 18:45:20 +0100, David Feuer wrote: I know this will be controversial, because it can break (weird) code and because it's not Haskell 2010, but hey, you can't make brain salad without breaking a few heads. Are you suggesting enabling -XScopedTypeVariables for -XHaskell98 and

Re: Behavior change of Data.Char

On 2015-02-19 at 06:19:18 +0100, Kazu Yamamoto (山本和彦) wrote: It seems to me that some characters of GHC 7.10.1RC2 behave differently from those of GHC 7.8.4: 7.8.4 7.10.1RC2 isLower (char 170)TrueFalse Fwiw, the motivation for that particular change

Re: Building vector with GHC HEAD

On 2015-02-17 at 14:19:43 +0100, Jan Stolarek wrote: Devs, I'm not sure if this is the best place to ask this question but I'm almost certain someone here will have the answer. I want to build upstream master branch of vector library using GHC HEAD and cabal 1.22. Alas my attempts have

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2

On 2015-02-17 at 13:47:50 +0100, Takenobu Tani wrote: I modified System/Process/Internals.hs locally and build on MinGW 32bit. Then I was successful to build on 32bit Windows 7. Shall I write a bug report on trac or any? or ghc7.10.1.rc2 will not support 32 bit Windows? Please file a

Re: Trouble pushing changes?

On 2015-02-10 at 02:20:39 +0100, Iavor Diatchki wrote: [...] Any ideas what that's about? Perhaps, it is simply that I don't have permission to push to `deep-seq`? You have to push to GitHub's upstream of deepseq: $ awk '/^libraries\/deepseq/ { print $4 }' packages

Re: Merge FlexibleContexts with FlexibleInstances?

On 2015-02-06 at 07:05:35 +0100, David Feuer wrote: In my limited experience thus far, it seems to me that a substantial majority of modules that start out needing one of these end up needing the other one too. They appear to be two sides of the same coin, each allowing for (slightly) more

Re: 7.10.1RC2 compile problem? ghc: internal error: PAP object entered!

On 2015-01-31 at 14:34:35 +0100, George Colpitts wrote: Maybe this is something I shouldn't be doing, but I thought it was worth mentioning in case I have found a compiler bug. Should I file a bug for this? cabal install *--allow-newer=base* accelerate ... [10 of 10] Compiling

Re: Make one-shot a per-registration property

On 2015-01-30 at 05:36:21 +0100, Austin Seipp wrote: You won't have permissions to push it to 7.10. I can try to get to it soon, but I make no guarantees until next week (out of town atm). CC Herbert, who can probably get to it more promptly than I can. I'll look into it later today ...for

76-fold regression GHC 7.10-7.11 in T9961 byte-allocation

Hello *, I noticed something odd while validating the GHC 7.10 branch: bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) ExpectedT9961(normal) bytes allocated: 772510192 +/-5% Lower bound

  1   2   3   4   >