- ghc-devs - Haskell.org

Re: Improving the "Get Haskell Experience"
by Michael Snoyman 12 Jul '15

12 Jul '15

I think it depends somewhat on operating system, since there are permissions issues to be dealt with regarding user vs global installation. In principle though: I think the HP installers would install to a non-stack-specific location, and then stack would simply use that GHC based on its inclusion in the PATH. (I'm also guessing this will tie in nicely with Linux distro packages, which would likely want ghc to live in /usr/bin). On Sun, Jul 12, 2015 at 10:11 AM Dan Burton <danburton.email(a)gmail.com> wrote: > Stack has the capability of downloading and installing GHC on demand, as > well as auto-updating itself. Both of these features, by default, occur in > subdirectories of the user's home directory. (Slightly different on Windows > but same idea.) Would the Platform install GHC to the stack location > directly, or install it system-wide as previously? (Stack can still make > use of GHC anywhere on your path.) > > On Sunday, July 12, 2015, Michael Snoyman <michael(a)snoyman.com> wrote: > >> I'm +1 on nailing down an LTS release cycle, I've been pushing for it, >> and planning that it would happen after the first few releases. I'm fine >> with doing it starting with the next release if that's desired. >> >> The cygwin/msys conflict is a problematic one. stack has more flexibility >> addressing this than MinGHC did, since stack can control the PATH more >> directly. What we do now is, by default, add msys to the beginning of the >> PATH, and provide a command line option to not use msys at all. I believe >> this combination has addressed the bug reports we've received in the past. >> >> That's not to say I'm opposed to generating binary databases; I'm >> actually in favor of having that option for all platforms at some point >> (there's an open stack issue about it[1]). But it's a significant amount of >> work, and I think if possible we should defer it until we've figured out >> initial integration points. >> >> [1] https://github.com/commercialhaskell/stack/issues/117 >> >> On Sun, Jul 12, 2015 at 9:20 AM Gershom B <gershomb(a)gmail.com> wrote: >> >>> I’m ccing cabal-devel, as that list seems pertinent to this discussion >>> too. In general I’m in favor of unifying efforts such as this. >>> >>> For windows, I’d still like the _option_ to get prebuilt library >>> binaries for the full platform db. The modularity means that they can be >>> just downloaded in a separate folder now, rather than installed into e.g. >>> the global db? If so, that’s a nice win. Here is my motivation — I tried >>> the minghc installer and it mainly worked, but it played terribly with >>> cygwin, which I use pervasively. So I found myself in a situation where one >>> set of paths worked with cygwin, and the other set of paths let me build >>> the network library. I still have some anxieties about those sorts of >>> issues, and being able to “just download the binaries” would make me feel a >>> bit safer about at least one workaround should things get too muddled up. >>> >>> If we synchronize LTS and “platform libs,” then I would like A) some way >>> of distinguishing “blessed platform libs” from “other libs in LTS” (to >>> solve the “curation problem” which has always been a goal of the platform) >>> and B) a standardized release schedule for LTS. >>> >>> (And, of course, I assume this will _not_ be for the platform release >>> upcoming, which is due very shortly, but we’ll have a longer lead time to >>> integrate and shake out all the various issues and test, etc.) >>> >>> —Gershom >>> >>> >>> On July 12, 2015 at 12:04:22 PM, Mark Lentczner ( >>> mark.lentczner(a)gmail.com) wrote: >>> > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop >>> > shipping pre-built packages, so we banish cabal hell, and have a single >>> > common way to 'get Haskell' that just works.* >>> > >>> > At ICFP '14, there were several long group discussions of the state of >>> > "getting Haskell", including Haskell Platform, Stackage, and other >>> > approaches. Over the last year, there have been a few more public >>> > discussions and evolution on the ideas, and other installer >>> developments. >>> > In particular, Stackage's LTS package sets are a direct development >>> from >>> > this work, and the release of stack has offered new options. >>> > >>> > Today, drawing from all this good work and ideas from so many, we'd >>> would >>> > like to propose a concrete plan: >>> > >>> > - Haskell Platform becomes the standard way to get *GHC* and related >>> > tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a >>> > user-friendly, cross-platform installer that gives a standard way to >>> "get >>> > Haskell" for most users. >>> > - Use the *stack* model for package installation: >>> > - The global db has only the GHC packages >>> > - There is a package db for each curated set, Haskell Platform >>> > becomes one such set >>> > - Projects each have their own package db, much like sandboxes. >>> > - Haskell Platform's installer will no longer include pre-built, >>> > pre-installed packages other than GHC's set. Instead, it is configured >>> so >>> > that *stack* can be used to build and install, on as needed, the >>> > corresponding Haskell Platform release packages. >>> > >>> > We think this plan solves many different community needs: >>> > >>> > - We have a clear way to "get Haskell" that works for a wide variety of >>> > use cases. >>> > - HP installer gets much smaller, and about as minimal as a working >>> > installation can get. >>> > - By leaving most packages out of the global database, users of >>> > cabal-install, will now have far fewer problems. Sandbox builds should >>> now >>> > never give users "cabal hell" like warnings. >>> > - By building and installing the Platform packages into it's own >>> package >>> > db, users get the benefit of building and installing these common >>> packages >>> > only once per system, yet can easily bypass them for any given project >>> if >>> > desired. >>> > - Since the Platform packages are now built and installed as needed, >>> > installing on smaller systems or servers without OpenGL will work. >>> > >>> > To do this, we have a bit of work ahead of us: We need to settle on >>> > installation layout for each OS (including getting msys into the >>> Windows >>> > installer); decide on the naming and versioning of the Platform >>> package set >>> > (is it just LTS? does it have a different life cycle? etc...); getting >>> > *stack* ready such a distribution; and configuring (or updating) >>> > *cabal-install* to support the three-layer package db scheme. We think >>> we >>> > can do this in short order. >>> > >>> > We recognize this represents a significant change for the Platform, and >>> > will require buy-in from the various parts, especially *ghc*, *cabal*, >>> and >>> > *stack*. We'd like to get your input. >>> > >>> > - Michael & Mark >>> > _______________________________________________ >>> > Libraries mailing list >>> > Libraries(a)haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> > >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> -- >> > You received this message because you are subscribed to the Google Groups >> "haskell-stack" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to haskell-stack+unsubscribe(a)googlegroups.com. >> To post to this group, send email to haskell-stack(a)googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/haskell-stack/CAKA2JgKYuBMU5wtbjGV72dDKvS… >> <https://groups.google.com/d/msgid/haskell-stack/CAKA2JgKYuBMU5wtbjGV72dDKvS…> >> . > > >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > -- Dan Burton > > -- > You received this message because you are subscribed to the Google Groups > "haskell-stack" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-stack+unsubscribe(a)googlegroups.com. > To post to this group, send email to haskell-stack(a)googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/haskell-stack/CALSygwfNjyxWFL0y4-_5aSyZZV… > <https://groups.google.com/d/msgid/haskell-stack/CALSygwfNjyxWFL0y4-_5aSyZZV…> > . > For more options, visit https://groups.google.com/d/optout. >

1 0

Re: Improving the "Get Haskell Experience"
by Mark Lentczner 12 Jul '15

12 Jul '15

No - we are not talking about the upcoming, 7.10.2 HP release. It would for the next major release after that. Yes, stack has only been out ~1 month, but it has already shown traction in the community, and it has a clear working solution for managing "curated" pacakge sets, like Haskell Platform.

1 0

Re: GHC 7.10.2 plans
by Páli Gábor János 11 Jul '15

11 Jul '15

Hello Ben, 2015-07-10 16:46 GMT+02:00 Ben Gamari <ben(a)well-typed.com>: > Hopefully by Monday we > will have a pretty good idea of whether the tree is fit for release. [..] > As I understand it, a subset of you have in the past offered binary builds > for other platforms [..] > > Would you be willing to do this again? [..] Assuming we can get a final, > Stackage-validated source tarball by Monday, when do you think we could > have all of these prepared? Sure, I can do that for FreeBSD/i386 and FreeBSD/amd64, like I did in the past. Thanks, Gábor

1 0

How to stop the thread from yielding per 20ms?
by Zhen Zhang 10 Jul '15

10 Jul '15

Hi, I am trying to stop the GHC thread scheduler from atomically do round-robin scheduling. It might be strange that I am asking for that, in fact, my intention is to implement the “Lightweight Concurrency” on top of current RTS system. I am trying to use `GHC.Event`’s timeout mechanism to interfere with the scheduling behavior and it seems working a bit. But the automatic scheduling at the same time by RTS renders this effort invalid. For this part, I have tried to modify `rts/Scheduler.c`, masked some `startTimer` in `schedule()`, change the `appendToQueue` to `pushOnQueue` in `scheduleHandleYield` but nothing really works. (The GHC is still doing RR scheduling, even I changed some key code I thought) So I am curious if anyone familiar with the RTS could give me some suggestions on this problem. Thanks a lot! Zhen

3 3

Re: [GHC] #10627: Regression: cabal install of numeric-prelude hangs
by George Colpitts 10 Jul '15

10 Jul '15

Hello Henning, Brent Do you think you could advance this bug by coming up with a smaller example? I wish I could do it but I think I would be pretty slow at that. Sorry. It would be good if others could see if they can compile numeric-prelude using 7.10.2 on other platforms, i.e. it would be good to know if this bug is specific to the Mac platform. Thanks George On Fri, Jul 10, 2015 at 5:51 PM, GHC <ghc-devs(a)haskell.org> wrote: > #10627: Regression: cabal install of numeric-prelude hangs > -------------------------------------+------------------------------------- > Reporter: George | Owner: > Type: bug | Status: new > Priority: high | Milestone: 7.10.2 > Component: Compiler | Version: 7.10.2-rc2 > Resolution: | Keywords: > Operating System: MacOS X | Architecture: > Type of failure: Compile-time | Unknown/Multiple > crash | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: > -------------------------------------+------------------------------------- > > Comment (by George): > > Sorry, I don't think I can, I will however send mail to the package > maintainer, Henning Thielemann and cc Brent Yorgey whose species package > depends on numeric prelude. I set the priority as high as it seems that > shipping a release that can't compile a package it could previously is not > a good thing. The impact of the bug is not clear. However, I personally > don't need this fix. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10627#comment:5> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Re: GHC 7.10.2 plans
by Karel Gardas 10 Jul '15

10 Jul '15

Hi Ben, count with me. I always thought it may be a good idea to allow some time to builders to do their job. For me this means few hours for i386/amd64 solaris build and test and unfortunately about a day (~10 hours) of noisy run for sparc solaris build but I'll do it last time since I hope 7.12 will have fixed SPARC NCG which should cut the time to half or I'll buy faster sparc gear. :-) Generally speaking Monday morning is the best time for me. Then Wednesday. Cheers, Karel On 07/10/15 04:46 PM, Ben Gamari wrote: > Hi GHCers, > > So 7.10.2 is, believe it or not, slowly converging. After finding and > fixing a number of regressions since 7.10.1 (including, unfortunately, a > few only found this week), I think we finally have a source tree that > could possibly be called 7.10.2. > > I have been in communication with Herbert, who has built .debs from a > snapshot of the ghc-7.10 branch. They are currently available on his > PPA [1] (see the ghc-7.10.2-7.10.1.20150710-0 debs). Michael will be > using these to do a trial-build of Stackage. Hopefully by Monday we > will have a pretty good idea of whether the tree is fit for release. > > When all of this happens we will be ready to cut the release. As usual, > I will be doing binary builds for 32- and 64-bit Linux and Windows. As I > understand it, a subset of you have in the past offered binary builds > for other platforms, > > * Mark: Mac OS X, some Haskell Platform platforms > * Pali: FreeBSD > * Karel: Solaris > > Would you be willing to do this again? Ideally we would have these > packages available the day of the release. Assuming we can get a final, > Stackage-validated source tarball by Monday, when do you think we could > have all of these prepared? > > I'm willing to hold off announcing the release until late next week or > all of these releases are available, whichever happens first (unless > there is widespread agreement within this group that this is not enough > time). > > Cheers, > > - Ben > > > [1] https://launchpad.net/~hvr/+archive/ubuntu/ghc/ >

1 0

validate slow failures on os x 7.10 branch
by Carter Schonwald 10 Jul '15

10 Jul '15

hey all, I ran ./validate on 7.10 branch commit 51de9342b915688f1222760c74b9a63e44c533d3 earlier today heres the summary at the end, are these the expected test failures ? Unexpected results from: TEST="setnumcapabilities001 allocLimit4 conc012 conc034 joao-circular T7861 tcrun023 TH_StaticPointers sigcabal01 readRun004 CgStaticPointers StaticArraySize ghci024 mul2 quotRem2 add2 array001 retc001 dsrun014 DsStaticPointers GcStaticPointers linker_unload ListStaticPointers T7919 retc002 T3245 T2497 T10489 T2276_ghci topHandler03 haddock.Cabal" OVERALL SUMMARY for test run started at Fri Jul 10 12:04:03 2015 EDT 0:27:43 spent to go through 4451 total tests, which gave rise to 17100 test cases, of which 3620 were skipped 306 had missing libraries 12957 expected passes 165 expected failures 0 caused framework failures 0 unexpected passes 51 unexpected failures 1 unexpected stat failures Unexpected failures: ../../libraries/array/tests array001 [exit code non-0] (hpc,optasm,threaded2,dyn,optllvm) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad exit code] (ghci) codeGen/should_run StaticArraySize [bad stdout or stderr] (ghci) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc034 [exit code non-0] (optasm,threaded2,dyn,optllvm) concurrent/should_run setnumcapabilities001 [bad stderr] (threaded2) deSugar/should_run DsStaticPointers [bad exit code] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver/retc001 retc001 [bad exit code] (normal) driver/retc002 retc002 [bad exit code] (normal) ffi/should_run T2276_ghci [bad exit code] (ghci) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (ghci) perf/should_run T3245 [bad stdout or stderr] (ghci) programs/joao-circular joao-circular [bad stdout or stderr] (ghci) rts GcStaticPointers [bad exit code] (ghci) rts ListStaticPointers [bad exit code] (ghci) rts T7919 [bad exit code] (optasm,threaded1,dyn,optllvm) rts linker_unload [bad exit code] (normal) th TH_StaticPointers [bad exit code] (ghci) typecheck/should_compile T10489 [exit code non-0] (normal,hpc,optasm,optllvm) typecheck/should_compile T2497 [exit code non-0] (optasm,optllvm) typecheck/should_run T7861 [bad exit code] (normal,hpc,optasm,ghci,threaded1,threaded2,dyn,optllvm) typecheck/should_run tcrun023 [bad stdout or stderr] (ghci) Unexpected stat failures: perf/haddock haddock.Cabal [stat not good enough] (normal) == Start post-testsuite package check Timestamp 2015-07-10 16:04:01 UTC for /Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d/package.cache Timestamp 2015-07-10 16:04:01 UTC for /Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d (same as cache) using cache: /Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d/package.cache db stack: ["/Users/v645736/.ghc/x86_64-darwin-7.10.1.20150710/package.conf.d","/Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d"] modifying: Nothing flag db stack: ["/Users/v645736/.ghc/x86_64-darwin-7.10.1.20150710/package.conf.d","/Users/v645736/ghc-7.10.2/bindisttest/install dir/lib/ghc-7.10.1.20150710/package.conf.d"] == End post-testsuite package check

1 0

Building a minimal/essential GHC
by Jakub Zalewski 09 Jul '15

09 Jul '15

Dear all, I am working on porting GHC to [native client]( https://developer.chrome.com/native-client) which has some degree of POSIX-compliance. I was thinking about building just the minimal/most essential parts of GHC that is enough to compile simple Haskell programs. I wanted to ask which parts of GHC are the most essential and sufficient enough to compile a simple Haskell program, for instance to compile `main = putStrLn "Hello, world!"`? I also wanted to ask how to force a GHC build without a particular package that comes by default, for instance how to build GHC without the `unix` package? Best wishes, Jakub

2 3

10527/5113
by Simon Peyton Jones 08 Jul '15

08 Jul '15

Ben I have pushed a new fix to the 7.10 branch, onto branch wip/T10572-2. (Don't apply this to HEAD.) Can you try it. I get validate failures as below, but I am hard pressed to see how they could be related. (The perf changes may be.) Simon Unexpected failures: codeGen/should_run T10414 [exit code non-0] (threaded2) driver T8959a [bad stderr] (normal) ghci/scripts T9878b [bad stderr] (ghci) simplCore/should_compile T4945 [bad stdout] (normal) th T10279 [stderr mismatch] (normal) Unexpected stat failures: perf/compiler T9961 [stat too good] (normal) perf/should_run T4830 [stat not good enough] (normal) perf/should_run T7436 [stat not good enough] (normal)

1 0

Windows broken -- again
by Simon Peyton Jones 08 Jul '15

08 Jul '15

I get this breakage on Windows. I have no idea who is responsible. Can someone fix? It looks as if throwIOIO really is always unused. Simon utils\ghc-pkg\Main.hs:1982:1: Warning: Defined but not used: 'throwIOIO'

1 0