Re: How does GHC implement layout?
On Sun, Apr 04, 2021 at 05:18:52PM -0500, Alexis King wrote: > On 4/4/21 1:52 PM, Iavor Diatchki wrote: > > > > Overall, I do think that Haskell's layout rule is more complicated than > > it needs to be, and this is mostly because of the rule that requires the > > insertion of a "virtual close curly" on a parse error. > > Yes, this does seem to be by far the trickiest bit. But I’d be sad not to > have it, as without it, even simple things like > >let x = 3 in e > > would not be grammatically valid. That is accepted by the AlternativeLayoutRule. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How does GHC implement layout?
On Mon, Apr 05, 2021 at 05:09:21PM +, Simon Peyton-Jones wrote: > Two people who may know more about the alternative layout rule are Simon > Marlow and Ian Lynagh (cc'd). It was originally designed by John Meacham: https://gitlab.haskell.org/haskell/prime/-/wikis/alternative-layout-rule https://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html It isn't exactly equivalent to the Haskell layout rule, but it's fairly close and much simpler (due to not having the "on a parse error" case). Thanks IAn ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: build system
On Tue, Jul 21, 2015 at 11:32:55PM +0200, Thomas Miedema wrote: > > To make things sequential: you can use `CPUS=1 ./validate`. You need "THREADS=1 ./validate". CPUS=1 would use 2 threads. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Wired-in data-constructors with UNPACKed fields
On Mon, Aug 18, 2014 at 10:01:17PM +, Simon Peyton-Jones wrote: > > My recommendation would be to try (3) first. Ian Lynagh (cc'd) may be able > to comment about why the inconsistency above arose in the first place, and > why we can't simply fix it. I don't know of any reason we can't. I think we didn't before because we didn't need to change S#, and didn't realise that there would be any benefit to doing so. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: the case of the missing Cabal doc
On Sun, Jun 29, 2014 at 11:04:20PM -0700, Mark Lentczner wrote: > In times of yore (prior to 7.8), when GHC build a bindist, it included the > generated HTML manual for Cabal. As of 7.8, this seems to have gone > missing-in-action. > > Anyone know where it went? It was converted to markdown, and GHC's build system doesn't know how to build markdown docs. It's in libraries/Cabal/Cabal/doc/. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC silently turns off dynamic output, should this be an error?
On Mon, Jun 23, 2014 at 12:58:16PM -0500, Christopher Rodrigues wrote: > > Additionally, is it ever valid to have a pair of .hi and .dyn_hi files with > different interface hashes? You can, for example, compile package foo the vanilla way with -O, and the dynamic way without -O. You'll then get mismatched hashes. If you then try to compile bar (which depends on foo) with -dynamic-too then the idea was that it would transparently fall back to compiling the two ways separately. Otherwise every build system (Cabal, make rules, etc) that wants to use -dynamic-too would have to handle this failure and either fail or fall back itself. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Ghc 7.8 branch broken
On Tue, May 27, 2014 at 11:51:55AM -0700, Bryan O'Sullivan wrote: > On Tue, May 27, 2014 at 5:57 AM, Richard Eisenberg wrote: > > > To build the manual, yes, in my experience. Builds without the manual work > > fine. > > Perhaps adding --nonet to the xsltproc command line is in order. It's already there. If the build is doing anything on the 'net, it should definitely be looked into and fixed! $ grep -C 5 nonet rules/docbook.mk $$(call removeTrees,$$(dir $$@)) "$$(XSLTPROC)" --stringparam base.dir $$(dir $$@) \ --stringparam use.id.as.filename 1 \ --stringparam html.stylesheet fptools.css \ --nonet \ $$(XSLTPROC_LABEL_OPTS) $$(XSLTPROC_OPTS) \ $$(XSLTPROC_HTML_STYLESHEET) \ $1/$2.xml cp mk/fptools.css $$(dir $$@) Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Buildbots
On Tue, Apr 01, 2014 at 12:46:05PM +0200, Joachim Breitner wrote: > > happy with buildbot, it might not be the worst choice. For reference, the reason we moved away from buildbot is that it needs to maintain a TCP connection for the duration of the build. With some builds taking many hours (either on old platforms, or on modern hardware but with a full testsuite run and nofib etc) it was common that a brief network glitch caused a build to not finish. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validating with Haddock
On Tue, Jan 07, 2014 at 06:39:36PM +, Mateusz Kowalczyk wrote: > On 07/01/14 18:21, Austin Seipp wrote: > > > > Also, the performance failures you're seeing are (I speculate) due to > > out of date performance numbers. Sometimes these numbers go up or down > > just due to code churn, but they're sometimes finnicky, because they > > may depend on the exact time a major GC happens or something. So a > > small wibble can cause them to sometimes occasionally fail. > > These are the numbers from the clean tree. The haddock perf numbers look pretty bad, especially the peak_megabytes_allocated: => haddock.base(normal) 429 of 3855 [0, 0, 0] peak_megabytes_allocated value is too high: Expectedpeak_megabytes_allocated: 139 +/-1% Actual peak_megabytes_allocated: 180 => haddock.Cabal(normal) 430 of 3855 [0, 1, 0] peak_megabytes_allocated value is too high: Expectedpeak_megabytes_allocated: 89 +/-1% Actual peak_megabytes_allocated: 150 => haddock.compiler(normal) 431 of 3855 [0, 2, 0] max_bytes_used value is too high: Expectedpeak_megabytes_allocated: 663 +/-1% Actual peak_megabytes_allocated: 794 I think it would be worth working out what's going on before merging more haddock changes. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC Api
On Fri, Jan 03, 2014 at 10:19:02AM +, Simon Peyton-Jones wrote: > | Is this with a statically linked or dynamically linked GHC? > > I don't know. How would I find out? (It's the one built by validate.) > > You are asking about GHC, but I guess there's also the question of whether > the test program itself is statically or dynamically linked. Oh, yes, sorry, I was thinking this was in ghci for some reason. You're right that it's the test program we need to know about. > Why would static/dynamic linking make a difference? That's very confusing! With dynamic linking, there will be one shared copy of base, and in particular one shared stdout buffer. The runtime will flush that buffer when the program exits. With static linking, you'll be loading a second copy of base in which the statement is evalauted, and that base will have a separate stdout buffer. GHCi flushes this when appropriate by calling flushInterpBuffers. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC Api
On Thu, Jan 02, 2014 at 03:10:24PM +, Simon Marlow wrote: > On 02/01/14 07:06, Simon Peyton-Jones wrote: > > > >Happy new year! And to you :-) > > runStmt “print True” -- (4) > > >4.The runStmt should print something somewhere, but it doesn’t. Why not? > > I've no idea! It does look like it should print something. Is this with a statically linked or dynamically linked GHC? Does doing runStmt "hFlush stdout" afterwards make it appear? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Interface loading and dynamic linking
On Sun, Dec 22, 2013 at 06:56:11PM -0500, Ben Gamari wrote: > Ian Lynagh writes: > > > On Sun, Dec 22, 2013 at 12:34:25PM -0500, Ben Gamari wrote: > >> > >> DYNAMIC_BY_DEFAULT = YES > > > > Dynamic-by-default was a previous experiment to get GHCi to use the > > system linker. We now use dynamic-too instead. > > > Causing GHCi to use the system linker is indeed my intent. Given the > currently rather broken state of the ARM runtime linker it seems like > the easiest way to get ARM supported as somewhat-first-class citizen is > to use the system linker. `DYNAMIC_BY_DEFAULT` provides an easy way to > accomplish this. You shouldn't need dynamic-by-default. It should Just Work in HEAD, both unregisterised and registerised. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Interface loading and dynamic linking
On Sun, Dec 22, 2013 at 12:34:25PM -0500, Ben Gamari wrote: > > DYNAMIC_BY_DEFAULT = YES Dynamic-by-default was a previous experiment to get GHCi to use the system linker. We now use dynamic-too instead. I'm not sure whether dynamic-by-default works, and in any case it's probably not something we want to keep supporting. I'd recommend removing it. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Repository Reorganization Question
On Thu, Dec 05, 2013 at 03:03:42PM +0100, Herbert Valerio Riedel wrote: > > However, if the testsuite/ was already checked out before the 'sync-all > pull', the 'testsuite/.git' folder won't be removed automatically (and > it shouldn't hurt either, as 'sync-all' won't traverse it anymore after > ghc.git was updated) But git commands under testsuite/ will use the wrong .git, won't they? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Template Haskell and stage-1
On Wed, Nov 06, 2013 at 01:43:02PM +, Simon Peyton-Jones wrote:
> I'd like to make -XtemplateHaskell simply illegal in a stage-1 compiler.
> After all, it is!
> But for some reason we use the stage1 compiler to generate dependencies for
> the DPH libraries; those libraries have {-# LANGUAGE TemplateHaskell #-}, so
> the dependency generation fails. See below.
> But WHY do we generate deps for DPH with stage1? We don't *compile* the DPH
> libraries with stage1, because they need TH. Can't we just generate deps
> with stage2?
It's due to the build system phases:
http://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/PhaseOrdering#GHCsphases
Stage2 doesn't exist during the phase in which DPH is configured.
Changing it to use stage 2 would probably mean adding another phase for
things that need to be configured by stage 2. This might mean slower
builds due to loss of parallelism, I'm not sure.
Perhaps the decision to build DPH with the GHC build system should be
revisited? It causes some complication, and it seems that more and more
people are disabling it anyway, in order to get faster builds.
Thanks
Ian
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ghc-compete, a repository of fingerprints, and continuous integration
On Fri, Oct 11, 2013 at 11:59:07AM +0100, Simon Marlow wrote: > On 07/10/13 22:06, Joachim Breitner wrote: > >in the best scratch-an-itch-tradition I have created a special git > >repository, called “ghc-complete”, which tracks the combined state of > >all GHC-related repositories. It uses GHC’s fingerprint utility and > >simply tracks the change of the fingerprint file over time: > >https://github.com/nomeata/ghc-complete > > > >The main use of this is to have a repo which I can enable to be > >continuously checked by Travis (a free CI hoster). So instead of having > >several people ask on IRC about what build or test suite failures are > >actually not their fault, they can now simply check the travis page: > >https://www.travis-ci.org/nomeata/ghc-complete/builds > > This is great. With a bit of extra tool support for this we could > actually do without submodules and go back to individual repos. The reason we switched to submodules wasn't to make bisecting easier: It was so that we can make temporary local changes to 3rd party libraries (when changes to GHC or our libraries require them), and then jump back to an official upstream commit without upstream needing to merge our changes. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Testsuite run dynamic and not
On Sun, Sep 08, 2013 at 01:30:25PM -0700, Edward Z. Yang wrote: > > The easy thing is to list the test twice in all.T but this seems wrong. Note that if you go that route then you need to make sure that the generated files don't share filenames (e.g. they don't both create a foo.o file), or things will go wrong when the two tests run in parallel. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: New official language extension tokens for GHC 7.8.1
On Mon, Sep 02, 2013 at 07:48:58AM +, Simon Peyton-Jones wrote: > | Which of the language extensions listed in `expectedGhcOnlyExtensions` > | are deemed ready for public consumption in GHC 7.8.1, > > Good question. Here's the list with my comments. We need input from Ian. on > > RelaxedLayout > AlternativeLayoutRule > AlternativeLayoutRuleTransitional > I have no idea about these three. AlternativeLayoutRule* aren't ready. I'm afraid I can't even remember what RelaxedLayout does OTTOMH. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ./sync-all get & git submodule URL dissonance (was: It's one of those days...)
On Thu, Aug 22, 2013 at 05:01:45PM +0200, Herbert Valerio Riedel wrote: > > Btw, the implementation in sync-all at > > https://github.com/ghc/ghc/blob/master/sync-all#L897-L912 > > seems a bit confusing; the "submodule init" in the "if ($command eq > "get" or $command eq "pull")" branch is probably never invoked. I probably forgot to remove the old block in https://github.com/ghc/ghc/commit/c3db2b2c449e21d0358f1ed4b7a5dd447477ac28 Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Literal overflow test fails
On Sat, Aug 03, 2013 at 09:47:07PM +, Simon Peyton-Jones wrote: > > libraries\Win32\Graphics\Win32\GDI\HDC.hs:145:14: Warning: > Literal 2147483648 of type Int overflows > > The offending code is: > > setTextCharacterExtra dc extra = > failIf (== 0x8000) "SetTextCharacterExtra" $ > c_SetTextCharacterExtra dc extra > > - should we use minBound here? The spec defines the failure value as 0x8000, so it would be better to use that constant: http://msdn.microsoft.com/en-us/library/windows/desktop/dd145092%28v=vs.85%29.aspx I had a similar problem with a 0xdeadbeef constant in the compiler source. I changed it to be fromIntegral (0xdeadbeef :: Word32) instead. I'd suggest doing similarly for the 0x8000. > - what should the new literal-overlflow code do for 0xblah constants? In my opinion, it's doing the right thing. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Add NegativeLiterals extension (ef73963)
On Wed, Jul 31, 2013 at 08:00:08PM +, Simon Peyton-Jones wrote: > > Thanks... but if you have added a new language extension, shouldn't you > document it in the user manual? What exactly is the different behaviour seen > by the user? Yep; I've just pushed a patch. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Unit-testing of GHC code
On Wed, Jul 31, 2013 at 04:10:46PM +0200, Jan Stolarek wrote: > > and so on (Hunit would only be a convenient interface here). The question is > how can I import a GHC module from within the testsuite and call its > functions to test it they behave propertly? An attempt to simply import the > module results in compilation error: > > Failed to load interface for ‛Foo’ > It is a member of the hidden package ‛ghc-7.7.20130731’. > Use -v to see a list of the files searched for. > > Is there a workaround for this? You need to use "-package ghc" if you want to use the GHC API. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: HEADS UP: New repository
Hi Gabor, On Wed, Jul 31, 2013 at 12:52:48PM +0200, Gabor Greif wrote: > > who is in charge of setting up the repo mirror on https://github.com/ghc/ ? I'm afraid I have no idea. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Unit-testing of GHC code
On Tue, Jul 30, 2013 at 05:28:12PM +0200, Jan Stolarek wrote: > I spent whole day looking for a bug that lurks somewhere in my code, but I > know I could find it in 2-3 hours if I only could write unit tests for my > code. So the question is: how can I write HUnit and QuickCheck (and maybe > SmallCheck) tests for GHC and possibly make them a part of testsuite? It's better not to use HUnit/QuickCheck/SmallCheck, as then you can add them to the testsuite and they can be run by everyone, without needing the libraries to be installed. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: Gitolite for repository management
I know nothing about gitolite, but one detail: On Tue, Jul 30, 2013 at 04:41:37AM -0500, Austin Seipp wrote: > > http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan In the "Developer changes" you talk about changing the remote URL. It should be possible to do this for all repos with a sync-all command or two, but I will leave working out exactly what command(s) to a git expert. I don't think any changes to sync-all should be needed, but I could be wrong. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
HEADS UP: New repository
Hi all, I've added a libffi-tarballs repo. This means that you'll need to do ./sync-all get after you next pull. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC head and .haddocks
Hi Edsko, On Mon, Jul 29, 2013 at 01:38:45PM +0100, Edsko de Vries wrote: > > HADDOCK_DOCS="YES " That space is almost certainly the problem. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC head and .haddocks
Hi Edsko, On Tue, Jul 23, 2013 at 12:38:25PM +0200, Edsko de Vries wrote: > > I'm trying to build and install ghc head, with the installation of the > .haddocks. I'm running into all kinds of trouble though. I have > docbook and docbook-xsl installed, docbook isn't related to building haddock docs. > am using the standard sample > build.mk with the "quick" profile, modified to have > > HADDOCK_DOCS = YES > BUILD_DOCBOOK_HTML = YES > > and configure confirms that it will build docs. A full 'make' however > leaves the source tree without any .haddock files inside, What does make show VALUE=HADDOCK_DOCS say? Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Repo permissions broken
On Mon, Jul 22, 2013 at 03:51:49PM -0700, Iavor Diatchki wrote: > > changing the default umask on the entire server is not necessary to fix > this problem. Git already has support for exactly this use case Well, I don't mind if someone wants to do the git thing too, but I think we want a umask of 002 regardless. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Repo permissions broken
On Mon, Jul 22, 2013 at 10:56:45AM +0100, Simon Marlow wrote: > > I vaguely recall that we used to do this with a post-commit hook to > do a 'chmod g+w -R' on the tree. I've now set the default umask on the new server to be 002, and I've chmod'ed the current trees, so I think it will be OK now. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding constant folding for Integer div and mod
On Fri, Jul 19, 2013 at 06:58:39PM +0200, Jan Stolarek wrote: > It seems that currently there are no built-in constant folding rules for > Integer div and mod. I plan on adding those rules, but before I do that I > wanted to ask whether there is a good reason that these rules don't exist? I can't think of one. If you discover one, please add it as a comment where the rules would otherwise be. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: git push failure
On Fri, Jul 19, 2013 at 10:22:05AM +0100, Simon Marlow wrote: > > remote: Host key verification failed. Ah, I've added github's host key to /etc/ssh/ssh_known_hosts so this should now be fixed. > remote: fatal: The remote end hung up unexpectedly > To simon...@darcs.haskell.org:/srv/darcs/packages/base.git >5c37ca9..0b02a2e master -> master > > Anyone know what's wrong? I think the push went through. It was only the github mirroring that failed. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Perf tests which are better than expected on perf builds
On Sat, Jul 20, 2013 at 11:26:10AM -0700, Edward Z. Yang wrote: > These tests have been doing better than expected in the nightlies > for some while. > > > Unexpected failures: > >perf/compiler T3064 [stat too good] (normal) > >perf/compiler T3294 [stat too good] (normal) > >perf/compiler T5642 [stat too good] (normal) > >perf/haddock haddock.Cabal [stat too good] (normal) > >perf/haddock haddock.base [stat too good] (normal) > > Unfortunately, fixing them is not a simple matter of shifting > the ranges up, since the tests only exceed expectations on > a /perf/ build, so on a normal build such as 'quick', these > tests all pass normally. > > I could bump up the upper bounds so that the builder stops bleating > about them; perhaps we could do something more complicated where the > expected performance depends on what level of optimization GHC was built > with (but I don't know how to implement this.) > > Thoughts? The problem with just widening the bounds to cover 2 different types of build is that it increases the chance that performance changes won't actually be noticed by thge person responsible. Having different bounds for different build configurations is a pain, because (a) the testsuite has to work out which set of bounds to use, and (b) you now have even more wobbly values to keep up-to-date. I think perhaps the best thing would be to add some sort of (per-test?) fudge factor for non-validate builds. That way validate will still find performance regressions, like it does today, but other builds are less likely to give false positives. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Future plans
Friends, For a number of reasons, I have decided to move on to new challenges, and so from the end of the month the GHC maintenance work will be taken over by other people within Well-Typed. I hope not to disappear completely, but in any case if there is anything you think only I might know, please tell me and I'll try to document it! A couple of topical items: First, I've written a brief summary of the GHC 7.8 release plans here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Please feel free to edit it if there's anything I've left out, or if there are any other errors. Second, there's been a bit of discussion recently about moving over to using git submodules for more repos, or using git subrepos instead, or merging some of our repos together. We didn't feel that there was a consensus on what to do, so we plan to do nothing for now, but this is an area that might want to be revisited after the 7.8 release. Finally, I would like to everyone at Well-Typed, the Simons, and too many other community members to list, for a fantastic seven years. It's been a pleasure working with you all, and I look forward to finding out where the future takes us. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Heads up: darcs.haskell.org server changed
On Sun, Jul 14, 2013 at 02:01:31PM -0700, Edward Z. Yang wrote: > I think the new box may be missing some software; the pre-commit hooks > are persistently failing. How so? Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Nightly builder server, and snapshots
Hi all, The nightly builder server is finally back up and running; sorry for the delay. If you use the latest client code, then the resulting bindist will also get uploaded to darcs.haskell.org. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: T3294 variies in whether it fails or not
On Tue, May 28, 2013 at 08:24:34AM +, Simon Peyton-Jones wrote:
> Ian
>
> Perf/compiler/T3294 has very different max_bytes_used when BINDIST=YES than
> without. See below.
>
> I don't know why. I don't know whether it matters. Maybe it's just the
> moment that GC strikes. But it's uncomfortable to have such an erratic test
> failure.
>
> Simon
>
> simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$ make
> TEST=T3294
> ,("max_bytes_used", "36726792")
>
> simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$ make
> TEST=T3294 BINDIST=YES
> ,("max_bytes_used", "43818472")
Hmm, my first (inplace) run was 41241960, but since then I'm reliably
getting 38586080 for inplace, and 38904040 for BINDIST=YES.
I'm not sure why they are different at all; perhaps it's just due to the
size of the package.conf or something.
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] Haddockify some comments in compiler/hsSyn/HsBinds.lhs
Hi Mateusz, On Thu, Jun 06, 2013 at 11:31:47PM +0100, Mateusz Kowalczyk wrote: > > I have turned some comments in compiler/hsSyn/HsBinds.lhs into Haddock > format. They were just sitting there, hidden from the world (to spite > anyone scratching their heads when looking through the generated docs, > like myself). They were already written so why not use them? I agree, they may as well be haddock comments. However, I tried applying your patch, and the build failed with errors like: compiler/hsSyn/HsBinds.lhs:56:32: parse error on input `-- ^ Bindings in a 'let' expression -- or a 'where' clause' doc comment parse failed: If @co :: T ts ~ rep_ty@ then: Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Heads up: darcs.haskell.org server changed
On Sat, Jul 13, 2013 at 05:14:59PM +0200, Gabor Greif wrote: > On 7/13/13, Ian Lynagh wrote: > > > > SSH will complain that the key has changed, and you will probably have > > to delete the corresponding line from ~/.ssh/known_hosts. The new key > > fingerprint is: > > 91:4e:95:fa:2e:34:6c:ba:68:af:71:29:ba:66:12:b0 > > I see this: > > RSA key fingerprint is 08:63:b5:86:3e:ae:e2:3c:b1:ea:c6:05:2d:71:db:5a. Ah, OK, I think you might actually see any of these: 2048 08:63:b5:86:3e:ae:e2:3c:b1:ea:c6:05:2d:71:db:5a root@rock (RSA) 256 91:4e:95:fa:2e:34:6c:ba:68:af:71:29:ba:66:12:b0 root@rock (ECDSA) 1024 e7:14:7a:92:7f:b6:5f:45:d3:0e:32:fc:0b:92:a0:ed root@rock (DSA) Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Heads up: darcs.haskell.org server changed
Hi all, darcs.haskell.org has now moved to the new server. SSH will complain that the key has changed, and you will probably have to delete the corresponding line from ~/.ssh/known_hosts. The new key fingerprint is: 91:4e:95:fa:2e:34:6c:ba:68:af:71:29:ba:66:12:b0 Please let me know if you see any problems. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: package installation woes with Template Haskell / dynamic libraries
On Thu, Apr 11, 2013 at 02:33:29PM -0400, Richard Eisenberg wrote: > > tl;dr: cabal fails to install a package where one module in the package uses > another module via Template Haskell, requiring a .dyn_o file. The compilation > order, though, makes .o files before .dyn_o files, so installation fails. Is > this my fault or cabal's? cabal-install HEAD compiled with Cabal HEAD should do the right thing. Older versions won't, as they don't know about GHCis that use dynamic libraries. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: foreign import from RTS into GHC source
On Wed, Jul 10, 2013 at 04:26:23PM -0500, Nicolas Frisby wrote: > I'm adding a foreign import in a GHC module from the RTS. I'm using a CPP > directive to avoid the import in the stage1 compiler, since the RTS > function I need doesn't necessarily exist in that version of the RTS. > > EG Is there a preference to use Config.cStage instead of CPP and the STAGE > symbol? It's always better to not use CPP if possible, but in this instance you'd presumably get a missing-symbol error, so CPP is necessary. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: How accessible is a dynamically-linked ghc?
On Wed, Jul 10, 2013 at 02:42:27PM -0500, Nicolas Frisby wrote: > 1) How much effort does it take for a user to install a > dynamically-linked ghc executable on Tier 1 platforms? Just download the > source and set DYNAMIC_GHC_PROGRAMS=YES? >From 7.8, the plan is for this to be the default on platforms that support it. > 2) Are the major GHC distributors planning on distributing > dynamically-linked ghc by default? GHC HQ, Haskell Platform, > http://www.haskell.org/ghc/distribution_packages? The plan is/was for this to be the only way to support GHCi, but see the discussion on http://ghc.haskell.org/trac/ghc/ticket/8039 Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Feature Request : Qualified module exports
On Mon, Jul 08, 2013 at 10:05:09PM +1000, Erik de Castro Lopo wrote: > > If this feature was only enabled with a -XQualifiedModuleExports pragma, > would that decrease your objection? If it's added, then it should definitely only be enabled when an extension is turned on. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Feature Request : Qualified module exports
On Mon, Jul 08, 2013 at 08:14:12PM +1000, Erik de Castro Lopo wrote: > >module MyModule >( qualified module T > ) >import qualified Data.Text as T > > so that any module which imports MyModule has access to the symbols > of Data.Text under the quaified module name T. Do you mean that after import MyModule that T.f is in scope? Won't that be confusing? What happens if you import MyModule as X ? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: use UniqSupply in FastString?
On Fri, Jul 05, 2013 at 12:14:06PM -0500, Nicolas Frisby wrote: > > I've been trying to let a statically-linked compiler shares its FastString > table with plugins. Why not use a dynamically linked compiler? Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: base] master: Remove uses of RecordWildCards in GHC.Event.TimerManager (1f81187)
On Wed, Jul 03, 2013 at 09:08:35AM +0100, Simon Marlow wrote: > On 08/06/13 19:14, Ian Lynagh wrote: > >commit 1f81187e63dcd4f160cfd1ce62efc4b1d26603dc > >Author: Ian Lynagh > >Date: Sat Jun 8 18:54:23 2013 +0100 > > > > Remove uses of RecordWildCards in GHC.Event.TimerManager > > curious: why? I wanted to be able to understand the code. It's easier if 'foo' doesn't sometimes have type 'b' rather than 'a -> b'. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Unreliability of the build system
On Mon, Jun 24, 2013 at 12:37:17PM +0100, Geoffrey Mainland wrote: > > It looks like "/home/gmainlan/ghc/ghc-working-build/bindisttest/install > dir/lib/ghc-7.7.20130624/package.conf.d" gets *younger*, leading to the > recache error. Rather odd... Any ideas why this is happening? That's expected: When we install xhtml, we add it to the DB, and the cache gets updated. It looks like the problem is this: Timestamp 2013-06-24 11:02:14.669097 UTC for [...]/package.conf.d/package.cache Timestamp 2013-06-24 11:02:14.669197 UTC for [...]/package.conf.d (NEWER I would guess that we assume that when we write package.cache, the directory gets updated with the same timestamp; but actually, both use the timestamp at which they really happen. This is of course much more likely to be a problem if your filesystem has sub-second precision. If that's it, then it should be possible to fix it by explicitly setting the modification time of the directory to match the cache when we write the cache in ghc-pkg. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows failures
On Mon, Jun 17, 2013 at 08:48:15PM +, Simon Peyton-Jones wrote: > This is 'sh validate" on 64bit Windows. Rather a lot of failures. Might you > look? Sure. > The perf tests seem to fail because it's comparing with the *32* bit numbers, > even though this is definitely a *64* bit laptop. Whether the entire build > system thinks it's a 32 bit machine, or just the testsuite, I can't tell. If you have a 64bit Windows machine, then you'll be able to run both the 32bit and 64bit GHC builds. If you run "ghc --info | grep Target" then you'll see which is being used - it'll say x86_64-unknown-mingw32 if it's 64bit, and i386-unknown-mingw32 if it's 32bit. I suspect that you have a 32bit GHC, so comparing with the 32bit numbers is right. They probably just need updating for recent wobbles. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Nightly builds
On Tue, Jun 18, 2013 at 09:23:15AM +, Simon Peyton-Jones wrote: > > * I believe that our nightly snapshots are still dead. Are these > constructed by buildbots? > > * How are the buildbots doing? > Is all this awaiting our shift of abott? Or is it orthogonal? Do we need > help from others? If so who? Yes, nightly builders and snapshots are waiting on the abbot replacement at the moment. I've just sent a mail to try to find out what the status of that is. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: How to build statically linking GHC?
On Mon, Jun 17, 2013 at 12:12:55PM +, Stephen Paul Weber wrote: > > Because I have to find and copy many files and then set up the > library path env vars when distributing. Especially since the > average Haskell project relies on *many* libraries, this gets crazy > fast. I'm a little confused. GHC still builds static programs by default. (well, statically-linked Haskell, dynamically-linked to C libs, like before). Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: spam on the wiki?
On Tue, Jun 11, 2013 at 10:52:57PM +0200, Jan Stolarek wrote: > I'm repasting Stefan Holdermans' mail from Haskell-cafe, because it also > concerns this issue: > > > attachments; see for example the bottom of > > http://hackage.haskell.org/trac/ghc/wiki/Building. > > Can someone with wiki admin rights have a go at it? Ta; I believe I've removed all the spam atachments on the ghc trac now. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: better library management ideas (was: how to checkout proper submodules)
On Wed, Jun 12, 2013 at 12:54:38AM +0200, Daniel Trstenjak wrote: > > > I guess [the merge commits] may not cause any actual problems, > > but it's certainly nicer > > not having them (which is what using submodules gives us). Just to clarify, my problem isn't so much that there are merge commits (although it would still be nicer if there weren't), but that it is hard to see whether we are in the same state as upstream, or to see what the differences between us and upstream are. > I don't quite understand how you should get rid of these merge commits > by using submodules, With submodules we can do cd libraries/Cabal git reset --hard cd .. git commit -a and we will jump to that commit, without needing to merge it with the commit that we were at before. > You can get rid of these merge commit by using the '--rebase' option of > git-pull. We can't rebase, as these patches are in everyone else's GHC tree. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: spam on the wiki?
On Tue, Jun 11, 2013 at 01:51:54PM -0500, Nicolas Frisby wrote: > I suppose I could have removed those links myself, but I first thought to > send this email in order to raise issue of perhaps removing that wiki > user's privileges or at least trying to contact them? > > Who has access privileges enough to do so? > > Or is the Trac security porous enough that this sort of thing happens > regularly at no one's fault? You have the choice of: (a) New users can improve the wiki content without needing to request special privs (b) Spammers can't spam the wiki Currently we've chosen (a). I thinkt here's a captcha of some sort, but it doesn't fully solve the problem. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: spam on the wiki?
On Tue, Jun 11, 2013 at 01:32:11PM -0500, Nicolas Frisby wrote: > I've yet to fully comprehend the build system, but I'm pretty sure these > links are not related. > > http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking?action=diff&version=33&old_version=32 Ta, removed. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: better library management ideas (was: how to checkout proper submodules)
On Mon, Jun 10, 2013 at 01:13:37PM +0200, Daniel Trstenjak wrote: > > On Mon, Jun 10, 2013 at 11:45:22AM +0100, Ian Lynagh wrote: > > Is this possible with subtrees?: > > > > * Initially ghc's Cabal repo is at the same commit as upstream > > * We make a local commit 123 in Cabal to fix some bug > > * Cabal upstream makes a commit 456 to fix the same bug differently > > * We jump to commit 456, in such a way that we don't end up merging > > with our 123 commit every time we pull from Cabal in the future > > Yes. > > Every repository that's added by git-subtree to your repository is > represented as a separate branch. So everything that applies to the > merging of branches also applies to the merging by git-subtree. I didn't follow that. Here's an example of what happens with just a plain git repo, with no branches, submodules or subrepos involved: -8<--8<--8<--8<- upstream$ git init upstream$ echo content > file upstream$ git add file upstream$ git commit -a -m initial $ git clone upstream ghc $ cd ghc ghc$ echo fix1 > file ghc$ git commit -a -m fix1 upstream$ echo fix2 > file upstream$ git commit -a -m fix2 ghc$ git pull --no-edit -X theirs upstream$ echo feature1 > file upstream$ git commit -a -m feature1 ghc$ git pull --no-edit -X theirs upstream$ echo feature2 > file upstream$ git commit -a -m feature2 ghc$ git pull --no-edit -X theirs -8<--8<--8<--8<- At the end of this, you'll see that the ghc repo has a number of merge commits. I guess they may not cause any actual problems, but it's certainly nicer not having them (which is what using submodules gives us). Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: better library management ideas (was: how to checkout proper submodules)
On Mon, Jun 10, 2013 at 11:23:13AM +0100, Geoffrey Mainland wrote: > > Side note: the fingerprint script *didn't even work* for almost > a year after it was introduced; see commit 73ce2e70. Which implies that wanting to go back in time is rare, so making it easy should be given low weight when considering the options? > 3) Use subtrees. Is this possible with subtrees?: * Initially ghc's Cabal repo is at the same commit as upstream * We make a local commit 123 in Cabal to fix some bug * Cabal upstream makes a commit 456 to fix the same bug differently * We jump to commit 456, in such a way that we don't end up merging with our 123 commit every time we pull from Cabal in the future Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: better library management ideas (was: how to checkout proper submodules)
On Sun, Jun 09, 2013 at 11:15:37AM -0500, Austin Seipp wrote: > > > I'm referring to Joachim Breitner's work on > > splitting the base. > > So what's the timeline here? As soon as possible after 7.8 is branched. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: base] master: IO manager: Edit the timeout queue directly, rather than using an edit list (e843e73)
On Sat, Jun 08, 2013 at 03:08:55PM -0700, Johan Tibell wrote: > Is this related to some bug? The edit list was there for a reason. :) It's related to, and fixes, #7653. > On Jun 8, 2013 1:19 PM, "Ian Lynagh" wrote: > > > Repository : ssh://darcs.haskell.org//srv/darcs/packages/base > > > > On branch : master > > > > commit e843e73690f828498f6e33bb89f47a50c3ab2ac9 > > Author: Ian Lynagh > > Date: Sat Jun 8 20:19:59 2013 +0100 > > > > IO manager: Edit the timeout queue directly, rather than using an edit > > list > > > > Fixes #7653. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: how to checkout proper submodules
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote: > > I know we had this discussion sometime recently I think, but can > someone *please* explain why we are in this situation of half > submodules, half random-floating-git-repository-checkouts? Submodules are very handy for libraries that someone else maintains: We can make a local change to the library when we need something fixed, and then, when upstream has a fix too, we can jump straight to their fix without having to do any merging. However, submodules have various disadvantages, e.g. http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ The main one for me is that it's fairly easy to lose local changes when using submodules. This is relatively unimportant for the libraries that someone else maintains, as we don't often make any local changes to lose. Even so, I've lost changes on a couple of occasions. So the reason we entered this state is that we didn't think the advantages outweighed the disadvantages for the other repositories. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validate fails: Var/Type length mismatch: [] [s{tv a15I} [tv]]
On Wed, Jun 05, 2013 at 12:17:07PM +0200, Jan Stolarek wrote: > I think that Iavor is facing the same problems that I reported on this list > on May 15th. I also > see ghcpkg01 failing (when run during the validation) and passing (when run > separately). When you ran it separately, did you say BINDIST=YES ? If you didn't then it would have used the inplace package.conf.d, not the bindisttest one. I recently added some "ghc-pkg check -v" calls in the validate script incidentally, so if you log the output of the validate run then that might give some more clues as to when/how it goes wrong. > Actual stderr output differs from expected: > --- /dev/null 2013-05-14 15:38:10.77100 +0200 > +++ ../../libraries/base/tests/IO/T3307.run.stderr 2013-05-15 > 09:21:45.695049002 +0200 > @@ -0,0 +1,2 @@ > +WARNING: cache is out of date: > /dane/uczelnia/projekty/ghc-validate/bindisttest/install > dir/lib/ghc-7.7.20130514/package.conf.d/package.cache > + use 'ghc-pkg recache' to fix. > *** unexpected failure for T3307(normal) > > I think that these problems are likely to be caused be build artifacts left > from previous > validation - package.cache files (and many others) are not removed by `make > maintainer-clean`. test_bindist in bindisttest/ghc.mk removes the entire "bindisttest/install dir" tree before installing the bindist there. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validate fails: Var/Type length mismatch: [] [s{tv a15I} [tv]]
On Fri, May 31, 2013 at 03:28:06PM -0700, Iavor Diatchki wrote: > Where would I find the test log? I just run `validate` without any special > parameters in the root directory of GHC. It's ./testlog Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validate fails: Var/Type length mismatch: [] [s{tv a15I} [tv]]
On Fri, May 31, 2013 at 10:14:23AM -0700, Iavor Diatchki wrote: > > So it seems that there is something that keeps changing... I wonder if it > might be some missing dependency, so when you run things in parallel > sometimes they fail? There are no dependencies in the testsuite. You're either seeing: * a bug in a test, which means it is affecting something outside of the test * a bug in a test, which causes it to inconsistently fail * some problem with your machine, e.g. dodgy RAM (from most to least likely). Note that in the first case it is not necessarily the failing test that is broken. The testlog may give more clues as to what is going wrong. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validate fails: Var/Type length mismatch: [] [s{tv a15I} [tv]]
Hi Iavor, On Thu, May 30, 2013 at 07:59:07PM -0700, Iavor Diatchki wrote: > > I don't think that these are related to my change, but I don't really know, > so I am not going to push the fix just yet. Could you please advice on how > to investigate further? For ghcpkg01, if you have a testlog from a validate run then you can search for the test in that. Otherwise you can do cd testsuite/tests make CLEANUP=1 TEST=ghcpkg01 fast if you were doing a --fast validate, or cd testsuite/tests make CLEANUP=1 TEST=ghcpkg01 fast BINDIST=YES for a normal valdiate, and see how it's failing. > PS: Is there some sort of a flag I could set in build.mk so that it always > builds with warnings and core lint? In some of my GHC trees this seems to > happen, and in others it does not, and for me it'd be quite helpful if it > always did. You can see what settings validate uses in mk/validate-settings.mk, and copy any that you want into mk/build.mk. In particular, these add lint flags: GhcStage2HcOpts += -O -dcore-lint GhcLibHcOpts+= -O -dcore-lint Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: atMost in GHC.Event.PSQ causes seqfault or bus error
Hi Kazu, On Fri, May 31, 2013 at 03:16:22PM +0900, Kazu Yamamoto wrote: > > After a long fight, I found that this is a bug of the "-O2" option of > GHC head on 32bit machine. Now, it is easy to reproduce this > segfault. Please read and try this: > > https://github.com/kazu-yamamoto/buggy-psq Great, thanks for your work in boiling this down! I've filed a ticket for it here: http://hackage.haskell.org/trac/ghc/ticket/7953 Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validate fails: Var/Type length mismatch: [] [s{tv a15I} [tv]]
On Thu, May 30, 2013 at 09:33:43PM +, Simon Peyton-Jones wrote: > I've pushed a fix. Thanks, looks good. The build then failed compiling GHC.TypeLits, so I've reverted commit f7fb908ad963f7180c30b55fba57a858b0391de4 Author: Iavor S. Diatchki which lets the build go through. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Validate fails: Var/Type length mismatch: [] [s{tv a15I} [tv]]
Hi all,
The validate build is failing for me with the below. Does anyone know
what's up please?
Thanks
Ian
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final all
"inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror
-Wall -H64m -O0-package-name dph-prim-par-0.8.0.1 -hide-all-packages -i
-ilibraries/dph/dph-prim-par/. -ilibraries/dph/dph-prim-par/dist-install/build
-ilibraries/dph/dph-prim-par/dist-install/build/autogen
-Ilibraries/dph/dph-prim-par/dist-install/build
-Ilibraries/dph/dph-prim-par/dist-install/build/autogen
-Ilibraries/dph/dph-prim-par/.-optP-include
-optPlibraries/dph/dph-prim-par/dist-install/build/autogen/cabal_macros.h
-package base-4.7.0.0 -package dph-base-0.8.0.1 -package
dph-prim-interface-0.8.0.1 -package dph-prim-seq-0.8.0.1 -package
old-time-1.1.0.1 -package random-1.0.1.1 -package vector-0.9.1 -Odph
-funbox-strict-fields -fcpr-off -Wall -XHaskell98 -XTypeFamilies -XGADTs
-XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators
-XFlexibleInstances -XFlexibleContexts -O2 -O -dcore-lint
-fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir
libraries/dph/dph-prim-par/dist-install/build -hidir
libraries/dph/dph-prim-par/dist-install/build -stubdir
libraries/dph/dph-prim-par/dist-install/build -dynamic-too -c
libraries/dph/dph-prim-par/./Data/Array/Parallel/Unlifted/Distributed/Data/USegd/DT.hs
-o
libraries/dph/dph-prim-par/dist-install/build/Data/Array/Parallel/Unlifted/Distributed/Data/USegd/DT.o
-dyno
libraries/dph/dph-prim-par/dist-install/build/Data/Array/Parallel/Unlifted/Distributed/Data/USegd/DT.dyn_o
Var/Type length mismatch:
[]
[s{tv a15I} [tv]]
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.7.20130530 for x86_64-unknown-linux):
Iface Lint failure
In interface for
dph-prim-par-0.8.0.1:Data.Array.Parallel.Unlifted.Distributed.Data.Vector
Unfolding of
dph-prim-par-0.8.0.1:Data.Array.Parallel.Unlifted.Distributed.Data.Vector.$fDTVector_$cnewMD{v
rS}
: Warning:
In the expression: base:Control.Monad.liftM2{v rC} [gid]
@
(dph-prim-par-0.8.0.1:Data.Array.Parallel.Unlifted.Distributed.Primitive.DT.MDist{tc
rD}
ghc-prim:GHC.Types.Int{(w) tc 3J} s3{tv
a1Zk} [tv])
@ (vector-0.9.1:Data.Vector.Mutable.STVector{tc
rB}
s3{tv a1Zk} [tv]
(vector-0.9.1:Data.Vector.Unboxed.Base.Vector{tc rU}
a4{tv a1Zi} [tv]))
@
(dph-prim-par-0.8.0.1:Data.Array.Parallel.Unlifted.Distributed.Primitive.DT.MDist{tc
rD}
(vector-0.9.1:Data.Vector.Unboxed.Base.Vector{tc rU}
a4{tv a1Zi} [tv])
s3{tv a1Zk} [tv])
@ (base:GHC.ST.ST{tc rE} s3{tv a1Zk} [tv])
(base:GHC.ST.$fMonadST{v rA} [gid[DFunId]] @
s3{tv a1Zk} [tv])
(dph-prim-par-0.8.0.1:Data.Array.Parallel.Unlifted.Distributed.Data.Vector.$WMDVector{v
rz} [gid[DataConWrapper]]
@ a4{tv a1Zi} [tv] @ s3{tv a1Zk} [tv])
((dph-prim-par-0.8.0.1:Data.Array.Parallel.Unlifted.Distributed.Data.Scalar.Base.$fDTInt8{v
ry} [gid]
@ s3{tv a1Zk} [tv] g{v a1Zl} [lid])
`cast` (Sym
(base:GHC.ST.NTCo:ST{tc rx}[0]
)
:: base:GHC.ST.STRep{tc r1j3}
s3{tv a1Zk} [tv]
(dph-prim-par-0.8.0.1:Data.Array.Parallel.Unlifted.Distributed.Primitive.DT.MDist{tc
rD}
ghc-prim:GHC.Types.Int{(w) tc
3J} s3{tv a1Zk} [tv])
~#
base:GHC.ST.ST{tc rE}
s3{tv a1Zk} [tv]
(dph-prim-par-0.8.0.1:Data.Array.Parallel.Unlifted.Distributed.Primitive.DT.MDist{tc
rD}
ghc-prim:GHC.Types.Int{(w) tc
3J}
s3{tv a1Zk} [tv])))
((\ (s4{v a21s} [lid]
:: ghc-prim:GHC.Prim.State#{(w) tc 32q}
s3{tv a1Zk} [tv]) ->
Re: --with-gcc does not work well
Hi Kazu,
On Thu, May 30, 2013 at 11:24:15AM +0900, Kazu Yamamoto wrote:
>
> >> This caused an error:
> >>
> >>Configuring terminfo-0.3.2.5...
> >>configure: WARNING: unrecognized options: --with-compiler,
> >> --with-iconv-includes, --with-iconv-libraries, --with-gmp-includes,
> >> --with-gmp-libraries, --with-gcc
> >>checking for gcc... cc
> >>checking whether the C compiler works... no
>
> > And what is the output of
> > /usr/local/bin/ghc --info | grep "C compiler command"
> > (assuming /usr/local/bin/ghc is your bootstrapping compiler)?
>
> % /usr/local/bin/ghc --info | grep "C compiler command"
> ,("C compiler command","cc")
This is working as expected, then. /usr/local/bin/ghc says that it uses
cc to compile C code, so when compiling C files for it we use cc. If
that's wrong then you can edit the 'settings' file for
/usr/local/bin/ghc.
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stuck
Hi Simon, On Tue, May 28, 2013 at 11:50:19AM +, Simon Peyton-Jones wrote: > > Apparently mk/config.mk.in contains > GHC_STAGE2 = $(ghc-stage2_INPLACE) > which is, I believe, essential to nofib. But I can't see anywhere that > ghc-stage2_INPLACE is set. It should work now. Let me know if you still have problems. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: --with-gcc does not work well
Hi Kazu, On Thu, Apr 25, 2013 at 12:44:24PM +0900, Kazu Yamamoto wrote: > >--with-gcc=/usr/local/bin/gcc47 >--with-gcc-4.2=/usr/local/bin/gcc47 > > This caused an error: > > Configuring terminfo-0.3.2.5... > configure: WARNING: unrecognized options: --with-compiler, > --with-iconv-includes, --with-iconv-libraries, --with-gmp-includes, > --with-gmp-libraries, --with-gcc > checking for gcc... cc > checking whether the C compiler works... no > configure: error: in `/usr/home/kazu/work/ghc/libraries/terminfo': > configure: error: C compiler cannot create executables What command was make running when this happened? There should have been a flag like --configure-option=--with-cc="/usr/bin/gcc" where /usr/bin/gcc is the value of CC_STAGE0. > -CC_STAGE0 = @CC_STAGE0@ > +CC_STAGE0 = $(CC) For CC_STAGE0, we deliberately use the C compiler that the bootstrapping GHC uses, not the value of gcc that you specify with --with-gcc. What is @CC_STAGE0@ replaced with in mk/config.mk? And what is the output of /usr/local/bin/ghc --info | grep "C compiler command" (assuming /usr/local/bin/ghc is your bootstrapping compiler)? Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: fixing up links to commits and ghc source on trac wiki/trackers
On Fri, May 24, 2013 at 04:52:47PM -0500, Austin Seipp wrote: > The catch is that we don't want to move off of what it's in Debian, > from what I remember. These are obviously slightly dated versions of > Trac. Of course that's a ridiculous understatement because the *real* > problem IMO is that haskell.org is still running Debian 5 (Lenny.) > We're beyond obsolete. > > I brought this up to Ian on IRC a week or two ago, and he informed me > that there are some planned infrastructure upgrades for some of the > haskell.org infrastructure. Right, the plan AFAIR is to consolidate lambda+abbot onto a single new Hetzner machine, with a handful of VMs. > I am not aware of who is in charge here. > > Personally, I'd like to see this happen sooner and not later now that > Wheezey is released. Yup, we're just waiting for someone to have time to do it now, AFAIK. CCing a couple of related lists. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows validate fails
On Tue, May 21, 2013 at 08:04:09PM +, Simon Peyton-Jones wrote: > Windows validation is failing (again). Error is below. This is a clean > build. Ian? This is the same problem I had before on Linux, but this time my > libraries are up to date. Did you validate on windows? Iconv may be > different on windows. Urk Ah, sorry, I'd fixed this but hadn't pushed the patch. Now pushed. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Integer constant folding in the presence of new primops
On Fri, May 17, 2013 at 11:49:26AM +0200, Jan Stolarek wrote: > > Now here's the tricky part. I'm testing this with test > lib/integer/integerConstantFolding in the > testsuite and the test fails because rules for quotRemInteger, divModInteger, > quotInteger and > remInteger don't fire, leaving the constants unfolded. I noticed that if I > mark eqInteger with > NOINLINE, then these rules fire, but then obviously comparisons like (100012 > :: Integer) == > 100012 don't get folded and the test fails anyway. I'm analyzing how the > function quotInteger and > others use eqInteger, but I don't see anything that would be obvious. If you remove everything but the quotInteger test from integerConstantFolding and compile with -ddump-rule-rewrites then you'll see that the eqInteger rule fires before quotInteger. This is presumably comparing against 0, as the definition of quot for Integer (in GHC.Real) is _ `quot` 0 = divZeroError n `quot` d = n `quotInteger` d > eqIntegerPrimIdKey = mkPreludeMiscIdUnique 70 > eqIntegerPrimName = varQual gHC_INTEGER_TYPE (fsLit "eqIntegerPrim") > eqIntegerPrimIdKey Do you also still have eqInteger wired in? It sounds like you might have given them both the same unique? Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: understanding ghc compilation driver architecture
On Sat, May 18, 2013 at 05:42:35PM -0400, Carter Schonwald wrote: > > I'm still learning a lot of the ghc code base, so I may have a few other > questions like this as I try to familiarize with ghc code. > > Is the dev list an ok forum for these sorts of questions? Yes, ask away. And hopefully, someone will answer :-) Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: understanding ghc compilation driver architecture
On Wed, May 15, 2013 at 12:45:01AM -0400, Carter Schonwald wrote: > > https://github.com/ghc/ghc/blob/master/compiler/main/DriverPipeline.hs#L803which > mentions the -fvia-c backend in 2-3 places I've updated that, ta. > 2) when the ghc driver is used to manage building c code for subsequent ffi > usage, it doesn't seem possible to use a c compiler to do *.c -> > *.o/dylib, instead it is only possible to do *.c-> *.s -> *.o/dylib. > > I'm curious about reasons c,s,o choice that are still in play. Well, it means that GHC can be used to compile hand-written asm, and it also means that you can do "ghc -S". Also, there's been no reason to change it. -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: guidance for using timeout_multiplier?
On Wed, May 01, 2013 at 03:38:13PM -0500, Nicolas Frisby wrote:
>
> Is it sensible for me to add the timeout_multiplier setup function in the
> respective all.T files if I can reproduce the time out? It looks like 3
> seconds ought to be fine for the ones I've investigated so far, so I was
> thinking of passing 0.01.
timeout_multiplier should only be use to make timeouts longer, not
shorter. Otherwise, on slow platforms, tests will timeout even when they
would otherwise pass.
If slow tests are a problem, and fixing them isn't an option, then I'd
suggest making a skip_broken helper (similar to expect_broken, except it
skips the test rather than expecting the wrong result) and marking them
something like
when(opsys('darwin'), skip_broken(nnn))
It's important to use a skip_broken rather than just skip, to ensure
that a ticket is filed and the test is linked to it.
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: FW: Missing snapshots
On Sat, May 18, 2013 at 06:14:52PM +0100, Mateusz Kowalczyk wrote: > > Is there any update on this please? Sorry, no progress yet. > Note that the mailing > list pointed to at the GHC download page (cvs-ghc) no longer exists. Ta, fixed! Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows validate failing
Hi Simon, On Sat, May 18, 2013 at 11:34:09AM +, Simon Peyton-Jones wrote: > My Windows build has started failing like this when I try "sh validate" > > make[1]: *** No rule to make target `windows-installer'. Stop. I've just pushed a patch to fix it. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: STM Commentary
On Fri, May 17, 2013 at 04:05:39PM -0400, Ryan Yates wrote: > > For a while now I've been working on understanding GHC's STM implementation > and I finally have something to share. I've written a commentary on the > implementation which can be found here: > > http://fryguybob.github.io/STM-Commentary/ Great! > My goal in writing this > was to fill in the gap found here > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/STM. I happy to > have it live where it is most appropriate. If anyone has opinions on that, > let me know. Why not put it on http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/STM ? If you sign up for an account on the trac then you should be able to edit that page. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Unreliability of the build system
On Fri, May 17, 2013 at 11:34:01AM -0500, Gabriel Dos Reis wrote: > > Can't the build bots instructed to systematically fire up on every > commit for testing on the various platforms you currently do? In principle, yes, although (a) many of them are on machines that are used to do something else during the day, and (b) the builders may often still be building the last patches when more patches are pushed. We already get testsuite results mailed to the list each night, though. What we need is for people to fix unexpected results in them. (admittedly we don't currently identify who/which patches caused a test to start failing; perhaps that would help). Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Unreliability of the build system
On Wed, May 15, 2013 at 12:25:14PM -0700, David Terei wrote: > > I'd point out though that GHC's 'no validate failures' is very > frequently violated which did confuse me a lot when getting started. This is at least partly caused by inconsistencies in test results. For example, a Linux developer might push a change that causes a failure on OS X, or one person might push a change that means that a perf test fails on someone else's machine but not his own (or perhaps even fails randomly, and they got lucky on their validate run). The first person is not aware that anything is wrong, and the second person just ignores the failure because their patches didn't cause it. In an ideal world, the second person would either fix the bug, revert thc bad change, or file a ticket and mark the test as broken. Unfortunately, the second person is generally trying to do something else when they discover the problem, and doesn't want to spend time fixing something they didn't break. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Unreliability of the build system
On Wed, May 15, 2013 at 02:10:29PM +0200, Jan Stolarek wrote: > > This has never happened to me. I can't even guess why it might happen to > > you. > Looking through the validation log I see that tests fail with this error > message: > > Actual stderr output differs from expected: > --- /dev/null 2013-05-14 15:38:10.77100 +0200 > +++ ../../libraries/base/tests/IO/T3307.run.stderr2013-05-15 > 09:21:45.695049002 +0200 > @@ -0,0 +1,2 @@ > +WARNING: cache is out of date: > /dane/uczelnia/projekty/ghc-validate/bindisttest/install > dir/lib/ghc-7.7.20130514/package.conf.d/package.cache > + use 'ghc-pkg recache' to fix. > *** unexpected failure for T3307(normal) > > Any ideas why this happens? The testsuite does check whether the package.cache timestamp changed while running a test. If it did then you'll get a Package cache timestamps do not match: [...] framework failure. Do you know whether that happened? Otherwise, looking at why the package.cache is out of date, along with what tests were run around the time that it happened, might give a clue as to what went wrong. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: testsuite] master: Fix library way detection; fixes the ImpSafeOnly* tests when BINDIST=YES (b32d38a)
On Sun, May 12, 2013 at 03:50:17PM +0200, Páli Gábor János wrote: > On Sun, May 12, 2013 at 3:02 PM, Ian Lynagh wrote: > > Oh, sorry, it's actually > > make show VALUE=BASE_LIBDIR BINDIST=YES > > that we want. > > BASE_LIBDIR=""/usr/home/user/ghc-working/bindisttest/install > dir/lib/ghc-7.7.20130510/base-4.7.0.0" /usr/local/lib" I've made it use ghc-prim rather than base, so we shouldn't get this extra directory. Hopefully that will fix it. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: testsuite] master: Fix library way detection; fixes the ImpSafeOnly* tests when BINDIST=YES (b32d38a)
On Sun, May 12, 2013 at 02:39:14PM +0200, Páli Gábor János wrote: > On Sun, May 12, 2013 at 1:32 PM, Ian Lynagh wrote: > > > What does > > make show VALUE=BASE_LIBDIR > > say in testsuite/tests? > > BASE_LIBDIR="/usr/home/user/ghc-validate/libraries/base/dist-install/build > /usr/local/lib" > > Ah, it seems there is another directory added? I was completely under > the impression that the problem is that the binary distribution is > installed to the directory with spaces in its name. Oh, sorry, it's actually make show VALUE=BASE_LIBDIR BINDIST=YES that we want. > > What command is being run to cause the error? > > I guess this is the HAVE_* lines, the [ -f file ] part that you have > changed in the commit. Right, but what does the actual shell command look like once all the make variable expansion has happened? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: testsuite] master: Fix library way detection; fixes the ImpSafeOnly* tests when BINDIST=YES (b32d38a)
On Sun, May 12, 2013 at 11:27:10AM +0200, Páli Gábor János wrote: > On Fri, May 10, 2013 at 3:40 PM, Ian Lynagh wrote: > > Fix library way detection; fixes the ImpSafeOnly* tests when BINDIST=YES > > > > We were checking paths with > > if [ -f '"/path/to/Prelude"' ] > > i.e. the " quotes were being quoted by the ' quotes. Now we just > > use " quotes (which come from the ghc-pkg output). > > This does not work (again) on the FreeBSD builder clients. Any > suggestions where else to fix this problem for them then? I'm confused. What does make show VALUE=BASE_LIBDIR say in testsuite/tests? What command is being run to cause the error? Does this work on FreeBSD?: [ -f "foo bar"baz ] && echo yes Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Safe Haskell validate failure
On Fri, May 10, 2013 at 09:25:42AM +0100, Simon Marlow wrote: > > These are still happening. Use BINDIST=YES to reproduce: > > => ImpSafeOnly01(normal) 22 of 124 [0, 0, 0] > cd ./check/pkg01 && $MAKE -s --no-print-directory > mkPackageDatabase.ImpSafeOnly01 VANILLA=--disable-library-vanilla > PROF=--disable-library-profiling DYN=--enable-shared Aha, the problem was that the detection of what library ways are available was broken. I've fixed it. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stuck again on submodules
On Thu, May 09, 2013 at 12:44:45PM +, Simon Peyton-Jones wrote: > aha, good catch. It looks as if my commit for cardinality analysis somehow > jiggered the Cabal tree. I have no idea how or why. > > How can I undo that? I think this will do it: cd libraries/Cabal git reset --hard b4d0c0f2846542dc2e2df189fe145a56ac9b30b6 cd ../.. git commit -a --amend assuming that "Implement cardinality analysis" is the latest patch. If it's not the latest patch, then you'll either have to do some rebasing, or just record a new patch instead of amending. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stuck again on submodules
Hi Simon, On Thu, May 09, 2013 at 12:31:22PM +, Simon Peyton-Jones wrote: > Afraid not. I'd tried "git submodule update". The command you give is a > no-op; libraries/Cabal is stuck on commit 14c5a3f; and that's what git > submodule status says it should be. But it shouldn't! What does git log -p libraries/Cabal say? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: questions about validating in the presence of known failures
On Thu, May 02, 2013 at 10:23:26AM -0500, Nicolas Frisby wrote: > > Question 2: Can we add another bit to unexpected results marking them as > known/unknown? Unexpected results are all unknown. If they're known then they're expected results. I've just written this on how to deal with validate failures not caused by local patches: http://hackage.haskell.org/trac/ghc/wiki/TestingPatches#ValidatehasfailingtestswithoutanylocalpatcheswhatdoIdo > Question 3: What's the status on the build bot farm? I hope to do some work on this soon, e.g. add a way for build results to be uploaded to the server by the builders. However, I've been spending my time on more pressing matters recently. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: HEAD not building on OS X
On Mon, Apr 29, 2013 at 01:32:38PM -0500, Nicolas Frisby wrote: > It seems this patch > > 50e78dafd0cac5ca3b28ef71559899f179343ddf > > changed some sed expressions in rts/ghc.mk that seem to be no longer firing > on my Mac now. Mac has a different flavor of BSD sed and such. Sorry; I've pushed a patch to fix this. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libgmp-related build error
On Thu, Apr 25, 2013 at 06:08:07PM -0400, Andreas Voellmy wrote: > I just tried to grab the latest GHC code so that I can test a bug fix for > IO manager on OS X, but I ran into build errors. The failing command was: > > gcc -E -m32 -m32 -fno-stack-protector > -Ilibraries/integer-gmp/gmp > -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist -MM > libraries/integer-gmp/mkGmpDerivedConstants/mkGmpDerivedConstants.c -MF > libraries/integer-gmp/mkGmpDerivedConstants/dist/build/.depend.c_asm.bit > libraries/integer-gmp/mkGmpDerivedConstants/mkGmpDerivedConstants.c:15:17: > error: gmp.h: No such file or directory I've just pushed a patch to fix this. I'd been caught out by validate not cleaning gmp, so my validate tree already had a built gmp in it. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Use ffi_prep_closure_loc rather than ffi_prep_closure (310735e)
On Sun, Apr 21, 2013 at 09:34:31PM +0300, Sergei Trofimovich wrote:
> > commit 310735e7adce0145c653386c21686b4a1b96aea9
> >
> > -r = ffi_prep_closure(cl, cif, (void*)wptr, hptr/*userdata*/);
> > +r = ffi_prep_closure_loc(cl, cif, (void*)wptr, hptr/*userdata*/, code);
> > if (r != FFI_OK) barf("ffi_prep_closure failed: %d", r);
>
> The barf() text (/ffi_prep_closure/ffi_prep_closure_loc/) might be adjusted
> as well.
Ta, fixed.
Thanks
Ian
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release redux
On Thu, Apr 18, 2013 at 12:21:26PM -0400, Ben Gamari wrote: > > what is the plan for > 7.8? Will it admit API breakage? Should we establish a timeframe for getting > work in before a formal release candidate is cut? 7.8 will be released as shortly after ICFP as we can. It will allow API changes. There's no hard timeframe yet, but the sooner a patch is sent, the more likely it is to make it in. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: HP 2013.2 and GHC 7.6.2
On Wed, Apr 17, 2013 at 05:37:37PM +0200, Gabor Greif wrote: > On 4/17/13, Iavor Diatchki wrote: > > Hello, > > > > cabal-install 1.16.0 and 1.16.0.1 have some serious bugs that one > > encounters rather quickly. For example, at work I wasted some time until I > > figured out that cabal was generating a 'Paths_' module that does not > > compile. Because of this, you can't even use it to install a newer > > version of itself, where the problem is fixed: you have to manually > > bootstrap the new version with the script! > > I came up with this. > > http://heisenbug.blogspot.fr/2013/02/old-cabal-subhell.html > > Pretty much what you have experienced. This doesn't appear to affect the Cabal that GHC 7.6.2 ships with. I get ... catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a catchIO = Exception.catch ... getBinDir = catchIO (getEnv "HTTP_bindir") (\_ -> return bindir) in Paths_HTTP. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: HP 2013.2 and GHC 7.6.2
Hi Iavor, On Wed, Apr 17, 2013 at 08:20:22AM -0700, Iavor Diatchki wrote: > > cabal-install 1.16.0 and 1.16.0.1 have some serious bugs GHC doesn't include cabal-install. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: HP 2013.2 and GHC 7.6.2
On Wed, Apr 17, 2013 at 02:48:26PM +0100, Duncan Coutts wrote: > > In the absence of a GHC-7.6.3, I'm not sure if it's practical for the HP > to bump the Cabal version. My proposal was 7.6.3 was a minimal release in a very short timeframe, to just fix #7748. Any additional changes introduce a possibility of regression. If you think that 7.6.2+1.16.0 would be OK, then it sounds like the fixes in 1.16.0.3 wouldn't be worth the risk (there are a number of GHC fixes that we won't be merging either, for the same reason). Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
Hi Simon, On Tue, Apr 16, 2013 at 03:55:16PM -, GHC wrote: > #7436: Derived Foldable and Traversable instances become extremely > inefficient due > to eta-expansion > > Comment(by simonpj): > > This one is fixed, just awaiting merging into 7.6.3 My suggestion was that we only fix #7748 in 7.6.3, as that seems to be a show-stopper. There are several other fixes that we would ordinarily merge into 7.6.3, but every change has a risk of causing a regression (after all, 7.6.2 made #7748 worse), and we want to get 7.6.3 out as quickly as possible (so as not to hold up the HP release) so we don't have the luxury of being able to have a long testing/RC phase. But if you think it's important enough, and the fix safe enough, please let me know and I'll merge it. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Build faliing on Windows
On Tue, Apr 16, 2013 at 08:34:41PM +, Simon Peyton-Jones wrote: > > However, if success on mode_t is required (which it is) for Windows, > shouldn't we get an error from configure, rather than ploughing on and only > bleating later when some obscure file doesn't compile? There are a lot of instances of that sort of thing in packages like base and unix. They'd really benefit from someone doing a sweep over them. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: HP 2013.2 and GHC 7.6.2
On Tue, Apr 16, 2013 at 03:18:01PM +0200, Christian Maeder wrote: > Am 16.04.2013 14:29, schrieb Richard Eisenberg: > > > >git clone http://darcs.haskell.org/ghc.git; cd ghc; ./sync-all --testsuite > >get; perl boot; ./configure; make > > Thanks, for this. Do I need to give a branch name (which one?) to > the "git clone" command (option -b)? Yes, you need to add "-b ghc-7.6" to both the clone and the sync-all command. Docs are here: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Gettingabranch Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: HP 2013.2 and GHC 7.6.2
On Fri, Apr 12, 2013 at 07:19:29AM -0700, Mark Lentczner wrote: > > There has been some discussion on haskell-platform & libraries mailing list > about the suitability of GHC 7.6.2 for the upcoming HP 2013.2. In particular, http://hackage.haskell.org/trac/ghc/ticket/7748 That does actually look quite nasty. Would a 7.6.3 that fixed that and had no other changes be acceptable? Simon, do you know if there is a reasonably non-invasive fix for that bug? And do you think it would be worth a micro-release? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
