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: 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 e...@cis.upenn.eduwrote: 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: Interface loading and dynamic linking
On Sun, Dec 22, 2013 at 06:56:11PM -0500, Ben Gamari wrote: Ian Lynagh ig...@earth.li 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: 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: 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: 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: [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: 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
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: 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: 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: 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: 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
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
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: 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
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: 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
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: 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 i...@well-typed.com 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
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: 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: 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 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: 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: 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 ig...@earth.li wrote: Repository : ssh://darcs.haskell.org//srv/darcs/packages/base On branch : master commit e843e73690f828498f6e33bb89f47a50c3ab2ac9 Author: Ian Lynagh i...@well-typed.com 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: 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: 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]]
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: 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]]
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 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 diatchki@Perun.(none) which lets the build go through. Thanks Ian ___ 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: 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: 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: 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: 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: [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 ig...@earth.li 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 barbaz ] 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: 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: [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: [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: 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 05:37:37PM +0200, Gabor Greif wrote: On 4/17/13, Iavor Diatchki iavor.diatc...@gmail.com 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
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: 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: Stage1Only
On Fri, Apr 12, 2013 at 02:51:44PM +0200, Gabor Greif wrote: Apparently all_compiler depends on all_compiler_stage2 currently, which it should not, given $(Stage1Only)==YES. See http://hackage.haskell.org/trac/ghc/ticket/7639#comment:5 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
Re: integer-simple linker errors?
Hi Gabor, On Mon, Apr 08, 2013 at 08:15:34PM +0200, Gabor Greif wrote: I am getting below errors from libraries/integer-simple. Which integer-gmp / GHC change caused this? I looked briefly, but could not find anything. 0130407.so: undefined reference to `__word_encodeDouble' /libHSinteger-simple-0.1.1.0-ghc7.7.20130407.so: undefined reference to `__word_encodeFloat' It's plausible that no-one's ever tried to build integer-simple the dyn way before. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: default library path in HEAD
Hi Ilya, On Thu, Mar 21, 2013 at 09:21:11AM +, Simon Peyton-Jones wrote: Apparently, something has changed in the default library path, so the stage2 compiler cannot find base modules: My guess is that you don't have 'v' in your GhcLibWays, possibly due to an out-of-date mk/build.mk. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: build failure on FreeBSD 9.1
On Wed, Mar 20, 2013 at 04:42:55PM +0900, Kazu Yamamoto wrote: $ ldd /home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.7.20130319/bin/ghc-pkg | grep ffi libffi.so.6 = /home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.7.20130319/bin/../rts-1.0/libffi.so.6 (0x7fd2faf6e000) In my case: libffi.so.6 = not found (0) Ah, I'm optimistic that commit 51bf3653775ba734f7ca3de99234aba722a0c72c Author: Ian Lynagh i...@well-typed.com Date: Wed Mar 20 19:25:27 2013 + Fix build with non-Linux ELF OSes will fix this. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: I/O manager: relying solely upon kqueue is not a safe way to go
On Wed, Mar 20, 2013 at 02:03:21PM +0900, Kazu Yamamoto wrote: If you put SRC_HC_OPTS += -keep-tmp-files -tmpdir tmp in mk/build.mk or mk/validate.mk (depending on whether or not you are validating) then it will be used for all compilations. I did this for mk/build.mk but nothing changed. inplace/bin/ghc-stage1 -static -H32m -O -keep-tmp-files -tmpdir tmp -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -split-objs -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-db -rtsopts -dynamic-too -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o tmp/ghc63821_0/ghc63821_1.split__2.s:unknown:missing indirect symbols for section (__DATA,__la_sym_ptr2) Can you send me all the files in tmp/ghc63821_0 please? Could you also send me your complete mk/build.mk and mk/validate.mk, and the commands you're using to compile GHC, please? I don't create mk/build.mk so far. And you're just running make, with no -j flag or anything? 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: ghc] master: Track subrepos Cabal (cc097a4)
Hi Gabor, On Wed, Mar 20, 2013 at 02:38:27PM -0700, Gabor Greif wrote: commit cc097a43c851891c7a1535d2082c7e392230123d Author: Gabor Greif ggr...@gmail.com Date: Wed Mar 20 22:37:43 2013 +0100 Track subrepos Cabal If I'm understanding right, this adds a GHC-only patch to fix a couple of typos. Thanks you for your many typo fixes, but in the case of submodules this sort of patch should be sent upstream instead; that way less effort is needed overall, and there is no chance that the patches will be lost when we resync with upstream. We only make GHC-only patches when they are necessary to keep the build working. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: I/O manager: relying solely upon kqueue is not a safe way to go
On Mon, Mar 18, 2013 at 11:28:17AM +0900, Kazu Yamamoto wrote: inplace/bin/ghc-stage1 -static -H32m -O-package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. [...] libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o /var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pmgn/T/ghc41160_0/ghc41160_1.split__2.s:unknown:missing indirect symbols for section (__DATA,__la_sym_ptr2) make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/IntWord64.o] Error 1 make[1]: *** Deleting file `libraries/ghc-prim/dist-install/build/GHC/IntWord64.o' make: *** [all] Error 2 Can you mkdir tmp, rerun the command with -keep-tmp-files -tmpdir tmp and send me the temporary files please? This problem happens if a HS file is compiled though make. If I compiled it by copy-pasting inplace/bin/ghc-stage1, it works. I said that dtruss changes the behavior but it appeared that dtruss does not matter. Should I put -keep-tmp-files -tmpdir tmp to a makefile? If so, please give me a patch. If you put SRC_HC_OPTS += -keep-tmp-files -tmpdir tmp in mk/build.mk or mk/validate.mk (depending on whether or not you are validating) then it will be used for all compilations. Or you can make it more specific, e.g. libraries/ghc-prim_dist-install_EXTRA_HC_OPTS += -keep-tmp-files -tmpdir tmp will use it only for ghc-prim. Could you also send me your complete mk/build.mk and mk/validate.mk, and the commands you're using to compile GHC, please? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Vaidation crash
On Tue, Mar 19, 2013 at 07:49:39AM +, Simon Peyton-Jones wrote: I got this at the end of validation on Windows. Any ideas? AttributeError: TestConfig instance has no attribute 'ghc_th_way' Sorry, my fault; I've just pushed a patch to fix it. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Give hsc2hs different options in different stages; fixes #7705 (f1fcfff)
On Wed, Mar 13, 2013 at 12:18:02AM -0400, Bill Tutt wrote: If the bootstrapping compiler is the Haskell Platform on Windows this change can break the build if the Platofrm install directory includes spaces. Ah, thanks. Should be fixed now. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Advance notice that I'd like to make Cabal depend on parsec
On Sun, Mar 17, 2013 at 09:04:58PM +0100, Henning Thielemann wrote: On Sun, 17 Mar 2013, Ian Lynagh wrote: I think it would be feasible to stop GHC itself from using the human readable format. The only place I can think of it being used is in the package database, but we could use either Read/Show for that, or just exclusively use the binary format. I already needed the human readable format in order to check what information a custom configure file generated. You can use ghc-pkg describe p for that. I don't think you should ever need the human readable format unless you need to alter the package database by hand. -- 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 build error
On Fri, Mar 15, 2013 at 02:48:45PM +0100, Tuncer Ayaz wrote: libraries/vector/Data/Vector/Fusion/Stream/Monadic.hs:104:1: Failed to load interface for `GHC.Desugar' This should be fixed now. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: testsuite] master: Revert Accept unicode quotes in T2507 (937c039)
On Tue, Mar 12, 2013 at 08:26:46AM +, Simon Peyton-Jones wrote: | I don't know if there's an easy way to set a non-Unicode locale on | Windows; for now I've marked it as an expected failure. Is there a ticket for this bug? No, but the bug is in the testcase, not in GHC. Is it worth making a ticket for it? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: building on Mac
Hi Kazu, On Mon, Mar 11, 2013 at 01:45:22PM +0900, Kazu Yamamoto wrote: These days I can validate GHC head on Mac. But to my surprise, I cannot build GHC head on Mac. I verified this with both 32bit and 64bit bootstrapping GHC on Mac. Any ideas? ghc-stage1: could not execute: /usr/bin/gcc make[1]: *** [libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.p_o] Error 1 Does this always happen when compiling this file? Does /usr/bin/gcc exist? What does inplace/bin/ghc-stage1 --info | grep gcc say? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: SplitObjs not working
On Mon, Mar 04, 2013 at 01:55:40PM +, Simon Peyton-Jones wrote: I get the error below on HEAD. Could something be wrong with the build system? I assume it's the SplitObjs=YES. It sounded like something I might have broken yesterday, but turned out to be something I broke some time ago! I've just pushed a fix. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: I can't clone
On Fri, Mar 01, 2013 at 01:34:49PM +, Simon Peyton-Jones wrote: I keep getting this when attempting to clone a fresh repo. Can anyone help? Thanks Does it always fail on the Win32 package? == running git submodule update Cloning into 'libraries/Win32'... error: Empty reply from server while accessing http://darcs.haskell.org/libraries/Win32.git/info/refs fatal: HTTP request failed Clone of 'http://darcs.haskell.org/libraries/Win32.git/' into submodule path 'libraries/Win32' failed git failed: 256 at ./sync-all line 199. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Fixing breaking packages
On Fri, Mar 01, 2013 at 05:13:58PM +0100, Jan Stolarek wrote: There's one big difference here: rpm/dpkg are only used to install things by the system administrator. But in the case of Cabal, a user could install 'mypackage' (in their user package database) and the next day the sysadmin could install a different instance of 'mypackage' in the global database. Then we must come up with a way of handling such a situation. The first idea that comes to my head is that by default cabal would only use one database: either the global one managed by the system administrator or the local user database. Well, that basically means you can't use the local one, as base is in the global one. Even if you made it a 3 database system: * the 'ghc' database, containing base, directory, etc * the 'system' database, containing and packages from Debian (for example) * the 'user' database, containing things you install where you have the choice of (ghc + system) or (ghc + user) then that means that you can only use packages from your OS if every single package you want to use is packaged by the OS. You could imagine changing things so that packages installed by OS packages aren't actually visible, and there's some way to add them to your user database (provided that would keep everything consistent). Perhaps 'cabal install foo' would first check to see if there is a suitable 'global' foo that it can just register in its database. It would be a more klunky workflow, but perhaps better than the status quo. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: I can't clone
On Fri, Mar 01, 2013 at 05:49:24PM +, Simon Peyton-Jones wrote: On the path through todays pain I ended up looking at lots of git config files. I thought the libraries were in http://darcs.haskell.org/packages, but they now seem to be gotten from http://darcs.haskell.org/libraries. Both these directories exist, and I have no idea of the difference. What is the difference, please? They're identical; one is a symlink to the other. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Confusing commit messages about `type-nats`?
On Wed, Feb 27, 2013 at 04:04:20PM +, Ian Lynagh wrote: version of git packaged. Maybe I should just build it by hand. For now Done. I also had to hack the script, as git config log git config repository_uri both fail with the new git. I had a guess at what the answers should be and it seems to work now, anyway. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Find LLVM tools when version number at end (e.g., llc-3.0) (#7661) (64aaaa1)
On Fri, Feb 15, 2013 at 07:21:54PM +0100, Karel Gardas wrote:
On 02/15/13 07:03 PM, Ian Lynagh wrote:
+$1=`${FindCmd} ${GOOD_PATH} -type f -perm +111 -maxdepth 1 -regex
'.*/$3-[[0-9]]\.[[0-9]]' | ${SortCmd} -n | tail -1`
This feels rather unpleasant to me. Is it likely that someone will have
programs called llc-3.0 etc, but no llc?
Yes, Ubuntu 12.04 LTS installs LLVM 3.0 package in a way that, the
package binaries are installed into /usr/lib/llvm-3.0 directory and
inside /usr/bin there are llc-3.0 and opt-3.0 links created linking
to ../lib/llvm-3.0/bin/{llc|opt}.
So David is fixing real-world issue here.
But if you install 'llvm' (rather than 'llvm-3.0') then you get a
/usr/bin/llc
Analogously, on ubuntu, if you install 'gcc' then you get /usr/bin/gcc,
but if you install 'gcc-4.6' then you get /usr/bin/gcc-4.6; but we don't
search for gcc-* executables.
Thanks
Ian
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Today's validate failures
On Thu, Feb 14, 2013 at 10:42:33AM +, Simon Marlow wrote: Unexpected failures: perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) I'd guess these were broken by commit c3c9babf10990ccc36451b3758d6f19d749b879d Author: Simon Peyton Jones simo...@microsoft.com Date: Wed Feb 13 17:31:34 2013 + Significant (15%) bytes-allocated reduction in haddock.Cabal and haddock.base I'm not sure why, but I'm happy! but I don't know why Simon would get lower allocations. Perhaps something set in mk/validate.mk? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release?
On Wed, Feb 13, 2013 at 09:00:15AM +, Simon Marlow wrote: I believe Ian has done some experiments with splitting base further, so he might have more to add here. There are some sensible chunks that can be pulled out, e.g. Foreign.* can be pulled out into a separate package fairly easily IIRC. Part of the problem is that it's hard to see what's possible without actually doing it, because base is so large, and has so many imports and import loops. IMO by far the easiest way to improve base would be to start off by breaking it up into lots of small packages (some of which will probably be single-module packages, others may contain an entire hierarchy like Foreign.*, and others may contain an odd mixture of modules due to dependency problems). Then we can look at which packages ought to be split up, which ought to be coalesced, and which ought to be moved higher up or lower down the dependency tree, and then look at which module imports are preventing what we want to do and see if there's a way to fix them (either by moving a definition and reversing an import, or by changing an import to import something lower down the dependency tree instead). If we go this route, then we would probably want to end up without a package called 'base', and then to make a new package called 'base' that just re-exports modules from all the new packages. I imagine the first release would let people use the new base without warnings, a year later new base would give deprecated warnings, and the following year we'd remove it. We could do this process slower, but the sooner packages move off of base, the sooner they benefit from fewer major version bumps. The advantages would be: * the new packages would be easier to maintain than base is * we could more easily make other improvements we'd like to make, e.g. we could move the unix and Win32 packages further down the tree without having to do it in one big leap, and without having to put them below the whole of base * if one module causes a major version bump, then only libraries using that functionality would need to relax their dependencies, rather than every single package * some targets (JS, JVM, .NET, etc) or other implementations might want to do things like IO, concurrency, etc, completely differently. This way they'd just use a different io/concurrency package, rather than having to have a different implementation of parts of base * it would be nice if pure libraries could simply not depend on the io package etc, and thus clearly do no IO The disadvantage is that, at some point between the first release and the release that removes base, each package will have to have its dependencies updated. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Unicode support for Haddock
[CCing the haddock list] On Sun, Feb 03, 2013 at 07:07:54PM +, Max Bolingbroke wrote: Hi GHCers, I recently ran into a problem where Haddock does not correctly handle Unicode in doc comments. So for example with this file: module Example where -- | 好 ok :: Int - Int ok x = x -- | 个 misinterp :: Int - Int misinterp _ = (-1) -- | 漢 failure :: Int - Int failure x = x-1 Current versions of Haddock will output the documentation for ok correctly, will output an empty bulleted list as the documentation for misinterp and not output any documentation at all for failure (echoing a warning to stderr instead). This is kind of sad. There is a very old open ticket about this issue: http://trac.haskell.org/haddock/ticket/20. The patches I've attached to that ticket fix the problem by using the native Unicode support in Alex 3. I've also attached to the ticket a patch which makes the necessary changes to GHC's build system required to build this new Haddock correctly. Do these patches seem OK? Is it fine to insist on Alex 3? I think it was released in 2011 so I think by now we can assume that it is available on all machines that will want to build GHC. I'll leave looking at the patches to the haddock guys, but I think that it's reasonable to require that GHC developers have alex 3 now. If I understand the Haskell Platform pages correctly, the last release included alex 3.0.2, and the one before that included 3.0.1. If this patch is accepted, at some point we might want to think about switching to Alex 3's unicode support in GHC's own lexer rather than relying on the current hacks. My patches do not make any change along those lines. Yes; if haddock requires alex 3.0, then GHC effectively will too, so we may as well make use of it. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release?
On Sun, Feb 10, 2013 at 09:02:18PM +, Simon Peyton-Jones wrote: You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested. But the way you test new features is to write programs that use them, and programs depend on libraries. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release?
On Sun, Feb 10, 2013 at 09:30:23PM +, Simon Peyton-Jones wrote: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. But that's not what happens. GHC 7.8 is released. Someone installs it in order to try to use TypeHoles when developing their program. But their program depends on text, so they send Bryan a mail saying that text doesn't build with 7.8. And so the wave of updates begins. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release?
On Sat, Feb 09, 2013 at 12:06:12PM +, Simon Marlow wrote: As a straw man, let's suppose we want to do annual API releases in September, with intermediate non-API releases in February. That's a non-API release 5 months after the API release. 6.10.2 was 5 months after 6.10.1 (.3 was 1 month later, .4 a further 2) 6.12.2 was 4 months after 6.12.1 (.3 was 2 months later) 7.0.2 was 3.5 months after 7.0.1 (.3 was 1 month later, .4 a further 3) 7.2.2 was 3 months after 7.2.1 7.4.2 was 4 months after 7.4.1 7.6.2 was 4.5 months after 7.6.2 so if we do non-API releases, then perhaps it would make sense to stop doing minor releases (unless a release turns out to just be broken). Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Compiling DynFlags is jolly slow
On Mon, Feb 04, 2013 at 11:50:17AM +, Simon Marlow wrote: What about just moving PlatformConstants into a separate module? Done. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release?
On Thu, Feb 07, 2013 at 09:42:39AM -0800, Mark Lentczner wrote: I wish GHC would radically change it's release process. Things like 7.8 shouldn't be release as 7.8. That sounds major and stable. The web site will have 7.8 at the top. The warning to use the platform will fall flat because it makes the platform look out of date. Really, 7.8 should be in a different release channel, not on the front page. It should bake in that channel for six months - where only the third group of people will use it, until it is getting close to merge into main, at which point the fourth group will start to use it, so that the day it hits main, all the libraries just work. Ideally, the first two groups of people will not pay the slightest attention to it until it is further baked. It's a catch-22: We don't want people to use a new release until all the bugs have been found and fixed, and all the libraries have been updated. But if people don't use it, then the bugs won't be found and the libraries won't be updated. I think you're saying that you'd like the uptake of new GHC versions to be slower, which would mean fewer people would be using 7.6 now, but in the last few days I've seen the Debian guys have had to send mails to maintainers telling them that their packages don't work with 7.6: http://lists.debian.org/debian-haskell/2013/02/threads.html despite 7.6 having been out for 5 months and about to enter the HP. Perhaps more automatic Hackage building, with a group of people looking at the logs of failing packages and acting appropriately, is the way forward. Some cases (such as installation failed due to dependencies not being installable) you'd want to be handled automatically. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release?
On Fri, Feb 08, 2013 at 02:28:20PM +, Simon Marlow wrote: So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! 7.2 was billed as a technology preview rather than a regular stable release. However, it still required just as much effort as a regular stable release, both for us (we probably spent just as much time trying to make it bug-free, making builds, making docs, etc) and for the community (libraries still needed to adjust dependencies etc). One result of that extra effort was that the 7.4 release got delayed, and the delay was magnified by pushing it over the Christmas period. 7.6 was released roughly according to the regular yearly release plan (although the 7.4 delay made the gap between the two shorter). So in my opinion, 7.2 was a bad idea (but I don't think anyone knew that before we tried it), and I'd agree that we'd be better sticking to not-more-than-yearly major releases. I wouldn't oppose less-than-yearly (e.g. every 18 months) if that makes life easier for distros, library maintainers, the HP, etc. But I wouldn't advocate it either; from GHC's point of view, historically we've always had enough new stuff to justify a new major release after a year. 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 failures
On Thu, Feb 07, 2013 at 01:37:13PM +, José Pedro Magalhães wrote: Which is weird; getPermissions is saying that the file getPermissions001.hs is executable. But, then again, the file system is a mounted shared folder from NTFS, I suspect that all files in that filesystem appear to be executable. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Add the new random commit again (6a46b46)
Hi Gabor, On Tue, Feb 05, 2013 at 03:23:11PM +0100, Gabor Greif wrote: since you have pinned a commit that is on a branch, people whose clones do not track that branch will never see the commit: As far as I can see it's working now. If you're still having problems, does git pull rm -rf libraries/random ./sync-all get fix it? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Git confusion
Hi all, If I do git clone darcs.haskell.org:/srv/darcs/ghc.git cd ghc git show origin then the output is [...] Local branch configured for 'git pull': master merges with remote master [...] However, none of: git remote rm origin git remote add origin darcs.haskell.org:/srv/darcs/ghc.git git remote show origin git remote rm origin git remote add origin darcs.haskell.org:/srv/darcs/ghc.git -m master git remote show origin git remote rm origin git remote add origin darcs.haskell.org:/srv/darcs/ghc.git -t master git remote show origin git remote rm origin git remote add origin darcs.haskell.org:/srv/darcs/ghc.git -t master -m master git remote show origin have the Local branch configured for 'git pull': section. So having done git remote rm origin, how do I configure the git pull branches again? Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Git confusion
On Mon, Feb 04, 2013 at 07:12:19PM +, Ian Lynagh wrote: So having done git remote rm origin, how do I configure the git pull branches again? Looks like this does it: git remote add origin darcs.haskell.org:/srv/darcs/ghc.git git fetch origin git branch --set-upstream master origin/master Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Bug names
Hi all, Would anyone mind if I were to rename all the numeric bug names, e.g. rename 1750 to T1750? I find names like 1750 a pain to search for in testlog, as they match lines like = plugins01(normal) 1750 of 3403 [0, 6, 0]. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Abott down?
On Tue, Jan 22, 2013 at 12:23:09PM +, Tim Watson wrote: Is this the reason I can't seem to get to hackage this morning either? Yes. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
