July 2015 - ghc-devs - Haskell.org

Cabal Include-Dirs link to RTS
by Matthew Le (RIT Student) 15 Jul '15

15 Jul '15

I am currently working on an alternative implementation of the STM monad and would like to keep my work as isolated as possible. To that end, I have tried to keep all my files separate in a confined package. The package consists of haskell files which are exported to the programmer, a C-- file which is used by the haskell functions, and a C file, which is called from some of the C-- primitives. Inside my C file, I need to call a couple of functions that exist in the RTS, such as "dirty_TVAR" from (rts/sm/Storage.h). Is there a good way to include this header file in my C file? I would like to be able to list rts/sm in my cabal file under Include-Dirs. I'm wondering if there is something analogous to an environment variable or anchor names (from SML/NJ compilation manager) that can tell me where the GHC source directory root is. As an example, I would like to do something to the effect of: library Include-Dirs: $GHC_ROOT/rts, $GHC_ROOT/rts/sm where $GHC_ROOT would tell cabal where to find the ghc source directory in the file system. I tried giving a relative path (which as expected does not work), giving the following warning: Warning: 'include-dirs: ../../rts' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. I can give an absolute path for my machine and everything compiles just fine, but this is obviously not portable. Any help would be much appreciated. -Matt

1 0

Travis failures
by Joachim Breitner 15 Jul '15

15 Jul '15

Hi, I don’t recall when it was the last time that we had a passing build on travis, so I had a look what’s wrong, and to my surprise the problem was not a build timeout, but rather two failing test cases: Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150713 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[3]: *** [T10294] Error 1 *** unexpected failure for T10294(normal) and: Actual stderr output differs from expected: --- ./th/T10596.stderr.normalised 2015-07-13 19:47:37.667428464 +0000 +++ ./th/T10596.comp.stderr.normalised 2015-07-13 19:47:37.667428464 +0000 @@ -1 +0,0 @@ -Just 100 \ No newline at end of file *** unexpected failure for T10596(normal) Full log at https://s3.amazonaws.com/archive.travis-ci.org/jobs/70789702/log.txt Does anyone have any idea about these? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 1

Backporting srcLoc to the GHC 7.10 branch
by Michael Snoyman 15 Jul '15

15 Jul '15

It looks like the srcLoc change[1] is something that some of our (FP Complete's) customers would be quite interested in getting access to sooner rather than later. Would there be any possibility of getting that patch merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at actually including it in 7.10.1, but would it be on the table for 7.10.2? We do of course have the option of backporting it ourselves and including it in a custom GHC we provide customers, but we generally try to stay as close to upstream as possible. [1] https://ghc.haskell.org/trac/ghc/ticket/9049

9 20

Can't build on Windows
by Simon Peyton Jones 15 Jul '15

15 Jul '15

I've just cloned GHC, on Windows and typed "sh validate". But it dies as below. And indeed the directory ghc-tarballs doesn't exist. Should it? How do I get it? Thanks Simon Target platform inferred as: i386-unknown-mingw32 GHC build : i386-unknown-mingw32 GHC host : i386-unknown-mingw32 GHC target : i386-unknown-mingw32 configure: Building in-tree ghc-pwd checking for path to top of build tree... C:/code/ghc-injective configure: Making in-tree mingw tree tar (child): ../../ghc-tarballs/mingw/binutils*.tar.lzma: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now ./configure: line 4217: inplace/mingw/bin/realgcc.exe: No such file or directory configure: In-tree mingw tree created

2 2

ANNOUNCE: GHC 7.10.2 Release Candidate 2
by Austin Seipp 14 Jul '15

14 Jul '15

We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc2 https://downloads.haskell.org/~ghc/7.10.2-rc2/docs/html/ This includes the source tarball and bindists for Windows, and Debian Linux. FreeBSD, OS X and Solaris binaries will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.2 final release in a week or two - so please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

10 13

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