- ghc-devs - Haskell.org

Re: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images
by Alan & Kim Zimmerman 21 Jul '15

21 Jul '15

Ok. But it may be worth manually fixing the version on the official web site once 7.10.2 comes out On Tue, Jul 21, 2015 at 9:19 PM, GHC <ghc-devs(a)haskell.org> wrote: > #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: > Type: bug | Status: new > Priority: normal | Milestone: 7.10.3 > Component: Documentation | Version: 7.10.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: Phab:D958, > | Phab:D970 > -------------------------------------+------------------------------------- > Changes (by bgamari): > > * milestone: 7.10.2 => 7.10.3 > > > Comment: > > I think we may need to punt on this for 7.10.2. I spent several hours on > this today and have been entirely unable to get even the an `<img>` tag to > be produced in the HTML, much less a rendered image. Sadly DocBook appears > to be an antiquated disaster. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10416#comment:14> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Trac error
by Tamar Christina 20 Jul '15

20 Jul '15

Hi All, Did something change with Trac recently? I am able to browse it fine when not logged in, but when I log in I get presented with: Oops… Trac detected an internal error: AttributeError: 'FakeSession' object has no attribute 'authenticated' There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue. on basically any page I try going to and directly after the login action. I have tried multiple devices and browsers. Regards, Tamar

1 0

build system question build-prog and bindisttest
by Tamar Christina 19 Jul '15

19 Jul '15

Hi All, In my ghc.mk I have declared: $(eval $(call build-prog,driver/ghc-split,dist,0)) $(eval $(call bindist,driver/ghc-split,ghc.mk)) compilation is fine but during testing I get this error: ===--- building final phase Bad GHC version '7.8.3' for 'bindisttest/a/b/c/ghc-7.11.20150719/bin/ghc-split.exe' bindisttest/ghc.mk:21: recipe for target 'test_bindist' failed I assume this is because I tell it to build ghc-split at stage 0, so it's using the bootstrapping compiler which in my case is 7.8.3. Now it's perfectly fine to build this at stage 1 or 2, but when I change it to either of those building fails telling me that ghc-stage1 or ghc-stage2 cannot be found... Could the dependency check me wrong? How do I go about fixing this? Regards, Tamar

2 4

Re: Improving the "Get Haskell Experience"
by Greg Weber 19 Jul '15

19 Jul '15

The main reason I am using stack is for its support for building a project containing multiple packages. There aren't any other tools that make this a first-class concept that is easy to use and not buggy. In addition, stack has a first-class concept of curated package sets. All of these are required to have smooth installs in real world projects, and they aren't likely to appear in cabal-install in a short time frame. On the other hand, stack already has good package distribution. But providing both cabal-install and stack is the right choice that helps keep the Haskell platform relevant and avoid new users having to go through multiple installation steps. On Sun, Jul 12, 2015 at 12:07 PM, <amindfv(a)gmail.com> wrote: > The HP is a place for tools which have stabilized. A few reasons why I > don't think stack is ready: > > - stack has initial interest from the community, but so did ghc-dev and > hsenv. It's still (imo) in proof of concept stage, and we don't know where > its lessons will ultimately end up. In those other two cases, they ended up > being folded into cabal, which is one likely scenario with stack. > > - There are other solutions on the horizon! There's a GSOC project that > will add nix-style package management to cabal. This should eliminate most > (all?) the cabal hell we know and love, and that's why most stack users are > trying it, no? > > - The HP is for stable apis for users, too -- we provide tools that users > won't have to unlearn or re-learn. Most languages don't have two package > managers! We're clearly in an unstable state, which isn't when we should > add to the HP. > > If 9 months from now stack is clearly the right tool for the job (i.e. > we're considering deprecating cabal), then I'd definitely consider > supporting adding it to the HP but otherwise i'm strongly -1. (If it needs > saying, I don't think stack is a bad tool). > > tl;dr: The dust hasn't settled. Please don't add tools to the HP which we > don't know will be in common use (in their current form) a year from now. > > Tom > > > El Jul 12, 2015, a las 12:25, Mark Lentczner <mark.lentczner(a)gmail.com> > escribió: > > > 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. > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

4 4

New release of GHC 7.8 to support OS X El Capitan
by Oleg Grenrus 18 Jul '15

18 Jul '15

Hi, first some background: there is an issue with having Haskell on the next OS X “El Capitan”: [1] caused by security updates in the operating system. The cause is too old `unix` package, the same issue as in [2] Could someone verify that my understanding of the issue is correct, i.e. how Cabal-the-tool and Cabal-the-library interoperate. For me it seems, that one of the easiest ways to fix the issue (for the users), is to have a new release in 7.8 branch, with updated `unix` dependency. Or is it there too might hassle to be possible? Related issues: [3] [4] [1] https://github.com/haskell/cabal/issues/2653 <https://github.com/haskell/cabal/issues/2653> [2] https://github.com/haskell/unix/pull/18 <https://github.com/haskell/unix/pull/18> [3] https://github.com/commercialhaskell/stack/issues/563 <https://github.com/commercialhaskell/stack/issues/563> [4] https://github.com/ghcformacosx/ghc-dot-app/issues/39#issuecomment-122088535 <https://github.com/ghcformacosx/ghc-dot-app/issues/39#issuecomment-122088535> Greetings, Oleg P.S. hopefully Windows 10 doesn’t pose similar surprises.

4 3

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