- ghc-devs - Haskell.org

RE: [Haskell] ETA on 7.10.3?
by Simon Peyton Jones 02 Sep '15

02 Sep '15

Ah, well https://github.com/ku-fpg/hermit/issues/144#issuecomment-128762767 links in turn to https://github.com/ku-fpg/hermit/issues/141, which is a long thread I can't follow. Ryan, Andy: if 7.10.2 is unusable for you, for some reason, please make a ticket to explain why, and ask for 7.10.3. Simon From: Haskell [mailto:haskell-bounces@haskell.org] On Behalf Of David Banas Sent: 02 September 2015 13:19 To: Ben Gamari Cc: haskell(a)haskell.org Subject: Re: [Haskell] ETA on 7.10.3? Hi Ben, Thanks for your reply. My problem is the project I'm currently working on is dependent upon HERMIT, which doesn't play well with 7.10.2, as per: https://github.com/ku-fpg/hermit/issues/144#issuecomment-128762767 (The nature of that comment caused me to think that 7.10.3 was in play.) Thanks, -db On Sep 2, 2015, at 12:05 AM, Ben Gamari <ben(a)smart-cactus.org<mailto:ben@smart-cactus.org>> wrote: David Banas <capn.freako(a)gmail.com<mailto:capn.freako@gmail.com>> writes: Hi, Does anyone have an ETA for ghc v7.10.3? (I'm trying to decide between waiting and backing up to 7.8.2, for a particular project.) Currently there are no plans to do a 7.10.3 release. 7.10.2 does has a few issues, but none of them are critical regressions but none of them appear critical enough to burn maintenance time on. Of course, we are willing to reevaluate in the event that new issues arise. What problems with 7.10.2 are you struggling with? Cheers, - Ben

2 1

Re: Planning for the 7.12 release
by Harry . 01 Sep '15

01 Sep '15

What's the status of splitting up base? This has been spoken about a few times but I can't find any public activity from GHC or Libraries HQ.

2 2

RE: Planning for the 7.12 release
by Ben Gamari 31 Aug '15

31 Aug '15

Andrey sent this report regarding the status of the new Shake build system he is working on but it seems it must have bounced from ghc-devs. Hopefully this time it makes it. Cheers, - Ben Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> writes: > Hi all, > > I aim at releasing a first working prototype of the new build system before 7.12 comes out. It will have limited functionality, and will most likely be fragile until we adjust it to multiple working environments. (I take great care to translate all flags with appropriate conditions to the new build system, but mistakes/omissions are inevitable.) > > Do we want to include it into 7.12? I don't have a strong opinion on this but tend to agree with Niklas: we don't necessarily need to tie this to a GHC release, since it will only be used by a small number of early adopters first, and they will be able to simply clone the latest version of the build system from the github repository. > > > For the record, here is my current to-do list: > > * Build utils (ghc-cabal, etc). At the moment I rely on the old build system for this, hence the error shown by Ben. > > * Build rts. > > * Build auto-generated code (GHC/Prim.hs etc). > > * Release a first prototype and start fixing issues found by early adopters. > > * Add support for validation & testing. > > * Add support for cross compilation. > > * Write a tutorial for using/extending the build system. > > > I'm currently on holidays, and September will be busy (teaching starts), but I believe a prototype will be ready by December. > > > Once all of the above is complete we may consider putting the new build system into the GHC source tree and all GHC devs will start migrating to it. I imagine the old build system will still be used for a while, so both will coexist. > > Cheers, > Andrey > > P.S. Hope this reaches the ghc-devs mailing list this time... >

1 0

Installing ghc-7.10.2 linux binary distro on SuSE
by Levent Erkok 31 Aug '15

31 Aug '15

Hello all, I've been having a lot of trouble installing the binary-distro's on a SuSE machine. Unfortunately, I don't have root privileges and thus my options are rather limited. The problem seem to boil down to the use of the function pthread_setname_np. It appears the problem was noted before, and Simon Marlow added a corresponding configure check for platforms that do not have this function. See here: https://mail.haskell.org/pipermail/ghc-devs/2014-October/006707.html Alas, none of the binary distributions listed on https://www.haskell.org/ghc/download_ghc_7_10_2#binaries seem to be built against a system that does not have this function. So, I was unable to install 7.10.2 successfully. Essentially, I'm looking for a binary distro on SuSE, or with a libc that doesn't have the GNU extensions such as pthread_setname_np; if anyone would be kind enough to put out such a binary distro, that'd really be appreciated. (Yes, I tried building from the source; but in the corporate environment with so many things controlled, that did not go very far.) Thanks, -Levent.

5 8

Thread-safe GHC
by Corentin Dupont 31 Aug '15

31 Aug '15

Hello, I am wondering if GHC itself is thread-safe. I am using Hint, and it reports that GHC is not thread-safe, and that I can't safely run two instances of the interpreter simultaneously. Is that still the case? Thanks! Corentin ---------- Forwarded message ---------- From: Daniel Gorín <jcpetruzza(a)gmail.com> Date: Thu, Aug 27, 2015 at 5:09 PM Subject: Re: Thread-safe Hint To: Corentin Dupont <corentin.dupont(a)gmail.com> Hi Corentin, sorry for the late reply. Until relatively recently, the problem was still on. But I too remember seeing something related to this issue being fixed (iirc, the problem was the runtime linker, which used global state), so perhaps it is already fixed in 7.10. If you can verify this, it shouldn’t be hard to show the error message only on old versions of ghc. I’ll be away for a couple of weeks, but if you want to look into this and send a patch, I’ll merge it when I return. Cheers, Daniel > On 24 Aug 2015, at 10:43 am, Corentin Dupont <corentin.dupont(a)gmail.com> wrote: > > Hello Daniel, > I noticed the following message in Hint: > This version of GHC is not thread-safe,can't safely run two instances of the interpreter simultaneously. > > Is it still the case with recent versions of GHC? > It would be neat to be able to launch several instances of the interpreter. In my game Nomyx I have several "match-up" going on and having one instance of the interpreter would be nicer. Otherwise I am obliged to reset the interpret each time I want to interpret something, which is time consuming (2-3 seconds). > > Thanks, > C

1 0

GHC 7.10 complie time regression
by Kazu Yamamoto 31 Aug '15

31 Aug '15

Hi, I found that the compile time of GHC 7.10 against specific packages gets much longer than previous versions. Here is example: https://travis-ci.org/kazu-yamamoto/iproute/builds/77427248 On my local MacBook Air, I see the same phenomena: GHC 7.8: cabal build 8.81s user 0.94s system 103% cpu 9.430 total GHC 7.10: cabal build 37.86s user 3.49s system 98% cpu 42.066 total Is this known regression? --Kazu

3 4

Documentation for GHC.IO.Exception
by Phil Ruffwind 30 Aug '15

30 Aug '15

On Hackage, there seems to be no documentation for GHC.IO.Exception in base, but the package can in fact be imported so it's not exactly an internal package. directory and likely many other packages do use the GHC-specific error types like InappropriateType in exceptions, so it would be useful if there were a documentation page for these things even if there isn't any text. As it is right now, the discoverability of these error types is very low as you need to know the magical URL to show the source code: https://hackage.haskell.org/package/base/docs/src/GHC.IO.Exception.html That's also partly a problem with Haddock; AFAIK there's no way to navigate to the Source Code packages of modules whose documentation is disabled, even though they are in fact present if you can figure out the URL. So would it be OK to open up this module or is there a reason for keeping them discreet?

1 0

Planning for the 7.12 release
by Ben Gamari 29 Aug '15

29 Aug '15

Hello everyone! With the 7.10.1 release nearly six months behind us and 7.10.2 out of the way, now is a good time to begin looking forward to 7.12. In keeping with the typical release pace, we are aiming to have a release candidate ready in mid-December 2015 and a final release in January 2016. The items that that we currently believe have a good chance of making it in to 7.12 are listed on the release status page [1], which I've summarized below (in no particular order), * Support for implicit parameters providing callstacks and source locations * Support for wildcards in data and type family instances * A new, type-indexed type representation, data TTypeRep (a :: k). * Introduction of visible type application * Support for reasoning about kind equalities * Support for Injective Type Families * Support for the Strict language extension * Support for Overloaded Record Fields, allowing multiple uses of the same field name and a form of type-directed name resolution. * A huge improvement to pattern matching (including much better coverage of GADTs) * Backpack is chugging along; we have a new user-facing syntax which allows multiple modules to be defined a single file, and are hoping to release at least the ability to publish multiple "units" in a single Cabal file. * Support for Applicative Do, allowing GHC to desugar do-notation to Applicative where possible. * Improved DWARF based debugging support including backtraces from Haskell code * An Improved LLVM Backend that ships with every major Tier 1 platform. These items are a bit less certain but may make it in if the authors push forward quickly enough, * Support for Type Signature Sections, allowing you to write (:: ty) as a shorthand for (\x -> x :: ty). * A (possible) overhaul of GHC's build system to use Shake instead of Make. * A DEPRECATED pragma for exports Is your pet project missing from this list? If you have a patch that you believe is on-track to make it in for 7.12, please let us know. Moreover, if you have an issue that you urgently need fixed in 7.12, please express you interest on the appropriate ticket. User feedback helps us immensely in figuring out how to best place our priorities. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.12.1

13 26

Cabal and simultaneous installations of the same package
by Simon Peyton Jones 29 Aug '15

29 Aug '15

Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon

11 21

Re: Planning for the 7.12 release
by Ryan Scott 28 Aug '15

28 Aug '15

Something I wanted to try to implement before GHC 7.12 are extensions to DeriveFunctor, DeriveFoldable, and DeriveTraversable which would allow for automatic derivation of Bifunctor, Bifoldable, and Bitraversable. (This has already been implemented using Template Haskell in an unreleased version of the bifunctors package [1], so implementing it in GHC should be straightforward.) I haven't made an issue for this yet since I was waiting on the results of #10448 [2] (which would put Bifoldable and Bitraversable in base, in addition to Bifunctor, which was added in 7.10). Currently, Edward Kmett is listed as the owner of that issue, but I would be happy to tackle it if it means we could get it in time for GHC 7.12. Ryan S. ----- [1] https://github.com/ekmett/bifunctors/tree/8e975aead363802610dedccf414b884f9… [2] https://ghc.haskell.org/trac/ghc/ticket/10448

1 0