Re: AlternateLayoutRule
On Tue, May 13, 2014 at 11:20:25PM -0700, John Meacham wrote: Okay, I believe I have come up with a modified version that accepts many more programs and doesn't require complicated comma handling, you can make all decisions based on the top of the context stack. It also allows many useful layouts that were illegal under the old system. From your description, the rule still sounds quite complex. It depends whether the objective is a rule that is close enough to the current rule that we can switch with very little code breaking, or a rule that is simple to explain to newcomers to the language (but which will require much more code tweaking when updating packages to compile with the new standard). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: AlternateLayoutRule
On Tue, May 13, 2014 at 09:32:31PM +0100, Simon Marlow wrote:
On 13/05/14 15:04, John Meacham wrote:
Hi, I noticed that ghc now supports an 'AlternateLayoutRule' but am
having trouble finding information about it. Is it based on my
proposal and sample implementation?
http://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html
Yes it is, but I think we had to flesh it out with a few more cases.
Ian will know more, he implemented it in GHC.
I'm not sure what we should do about it. I think Ian's motivation
was to experiment with a view to proposing it as a replacement for
the layout rule in Haskell', but (and this is my opinion) I think it
ends up not being as clean as we might have hoped, and the cases
where it doesn't work in the same way as the old rule aren't easily
explainable to people.
I ask because I was going to rewrite the jhc lexer and would like to
use the new mechanism in a way that is compatible with ghc. If it is
already using my code, so much the better.
It's based on your code, but I had to essentially completely re-write it
to work with the way that GHC's parser works; I don't think sharing the
code will be feasible.
I also fixed some bugs (e.g. I think that with your code,
foo = let { x = x }
in x
turns into something like
foo = let { x = x }
} in x
) and made some tweaks after trying it on GHC+bootlibs, but I don't have
details to hand.
However, the consensus was that the new rule has too many cases, due to
trying to match the old rule as closely as possible, and despite that it
doesn't have the advantage that it is a drop-in replacement. ISTR Cabal
in particular needed several changes to compile with it
(0aba7b9f2e5d8acea156d575184a4a63af0a1ed3). Most of them were code of
the form
case e of
p - e'
where bs
needing the 'where' clause to be less indented.
The plan, yet to be implemented, was to remove some of the cases of the
new rule, making it easier to understand, specify and implement, at the
expense of breaking more code when the switch is flipped.
Ideally, there would be a period during which compilers would check
during compilation whether the new rule would give a different token
sequence to the old rule, and warn if so.
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: AlternateLayoutRule
On Tue, May 13, 2014 at 03:11:16PM -0700, John Meacham wrote: ah cool, can you point me to which file it is implemented in in the source so I can copy your new rules? It's lexTokenAlr and friends in compiler/parser/Lexer.x It's a while since I looked at it, but IIRC it's not as clean to read as your specification code was, as GHC needs a function that it can call that will just give it the next token. That means that we need to keep some state for what we've recently seen, and if we want to return multiple tokens then we can only return the first one, and need to store the rest to be returned by subsequent calls Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal for trailing comma and semicolon
On Tue, Aug 13, 2013 at 09:47:49PM +0100, Simon Marlow wrote: On 17/05/13 20:01, Ian Lynagh wrote: I'd be in favour of allowing a trailing or leading comma anywhere that comma is used as a separator. TupleSections would need to be changed or removed, though. The type constructors for tuples look like (,,,), so they would have to be a special case. Ugh, true. I'd much rather leave tuples out of it: the precise number of commas in a tuple is significant. It would be rather unpleasant to have [1,2,3,] ::[Int] (1,2,3,) :: Int - (Int, Int, Int, Int) Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: NoImplicitPreludeImport
On Tue, Jun 04, 2013 at 01:06:25PM +0100, Simon Marlow wrote: Hardly anybody uses haskell98 or haskell2010, so we would still have a backwards compatibility problem. I meant 'base' to be included in 'these packages'; I've clarified the wiki page. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: NoImplicitPreludeImport
On Tue, Jun 04, 2013 at 01:15:58PM +1000, Manuel M T Chakravarty wrote: If a module contains an import of the form import Prelude.XYZ then it also automatically uses the NoImplicitPrelude language pragma. Otherwise, the Prelude remains to be implicitly defined as before. What about these?: import Prelude.XYZ as Foo import Foo as Prelude.XYZ Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Proposal: NoImplicitPreludeImport
Dear Haskellers, I have made a wiki page describing a new proposal, NoImplicitPreludeImport, which I intend to propose for Haskell 2014: http://hackage.haskell.org/trac/haskell-prime/wiki/NoImplicitPreludeImport What do you think? Thanks to the folks on #ghc who gave some comments on an earlier draft. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: NoImplicitPreludeImport
On Tue, May 28, 2013 at 11:41:44AM -0400, Edward Kmett wrote: I'm definitely in favor of having the *option* to shut off the import of the Prelude without entangling the notion of overriding all of the desugarings. I do, however, feel that removing the Prelude from base is a rather strong step, which hasn't seen much support. Just to clarify: This proposal is to stop importing the module implicitly, not to actually remove the module. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: NoImplicitPreludeImport
On Tue, May 28, 2013 at 08:58:29AM -0700, Johan Tibell wrote: The likely practical result of this is that every module will now read: module M where #if MIN_VERSION_base(x,y,z) import Prelude #else import Data.Num import Control.Monad ... #endif for the next 3 years or so. Not so. First of all, if Prelude is not removed then you can just write import Prelude But even this is not necessary during the transition period: see http://hackage.haskell.org/trac/haskell-prime/wiki/NoImplicitPreludeImport#Backwardscompatibility for a way that backwards compatibility can be maintained, with additional imports not being needed until code migrates to the split-base packages. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Missing snapshots
On Sun, May 12, 2013 at 04:50:40PM -0400, Carter Schonwald wrote: huh you're right! I seem to recall that that snapshots hadn't been updated since december while they were still up though... Yes, uploading new snapshots is waiting for me to find some time to implement a way to upload without needing an account. I've no idea what happened to the old ones, though. On Sun, May 12, 2013 at 8:10 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukwrote: On the GHC download page [1], there are no available snapshots. Both HEAD and STABLE branch dist directories are empty. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Haskell 2014
Dear Haskellers, We are pleased to announce that the Haskell 2014 committee has now formed, and we would be delighted to receive your proposals for changes to the language. Please see http://hackage.haskell.org/trac/haskell-prime/wiki/Process for details on the proposal process. The committee will meet 4 times a year, to consider proposals completed before: * 1st August * 1st November * 1st February * 1st May so if you have been meaning to put the finishing touches to a proposal, then we would encourage you to do so by the end of July! The source for the Haskell report will be updated as proposals are accepted, but new versions of the standard will only be released once a year, during January. The Haskell 2014 committee is comprised of: * Carlos Camarão * Iavor Diatchki * Ian Lynagh (chair) * John Meacham * Neil Mitchell * Ganesh Sittampalam * David Terei * Bas van Dijk * Henk-Jan van Tuyl Thanks Ian (Haskell 2014 committee chair) -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Haskell 2014
Dear Haskellers, We are pleased to announce that the Haskell 2014 committee has now formed, and we would be delighted to receive your proposals for changes to the language. Please see http://hackage.haskell.org/trac/haskell-prime/wiki/Process for details on the proposal process. The committee will meet 4 times a year, to consider proposals completed before: * 1st August * 1st November * 1st February * 1st May so if you have been meaning to put the finishing touches to a proposal, then we would encourage you to do so by the end of July! The source for the Haskell report will be updated as proposals are accepted, but new versions of the standard will only be released once a year, during January. The Haskell 2014 committee is comprised of: * Carlos Camarão * Iavor Diatchki * Ian Lynagh (chair) * John Meacham * Neil Mitchell * Ganesh Sittampalam * David Terei * Bas van Dijk * Henk-Jan van Tuyl Thanks Ian (Haskell 2014 committee chair) -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
ANNOUNCE: GHC version 7.6.3
= The (Interactive) Glasgow Haskell Compiler -- version 7.6.3 = The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.3. This is a bugfix release relative to 7.6.2, so we recommend upgrading. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/release-7-6-3.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: porting to uClibc-based 686 Linux
On Thu, Apr 18, 2013 at 06:48:12AM -0400, Dubiousjim wrote: On Wed, Apr 17, 2013 at 11:18:52PM +0100, Ian Lynagh wrote: On Fri, Apr 05, 2013 at 11:12:38PM -0400, Dubiousjim wrote: target$ inplace/bin/ghc-stage2 -o hello-cross hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello-cross ... target$ ./hello-cross Can't modify application's text section; use the GCC option -fPIE for position-independent executables. You can pass -fPIE to gcc by using the -optc-fPIE flag. Thanks Ian. There's much I don't fully understand about ghc, but I read somewhere that the -optc-* options would only be applied when building via intermediate C files, which isn't happening in the compilation process specified above. Is this incorrect, or have I misunderstood something? Ah, sorry, I assumed that you were doing an unreg build. If I were you I'd probably start off by trying to do an unreg cross-compile with HEAD. However, the unreg build is currently broken in HEAD (http://hackage.haskell.org/trac/ghc/ticket/7792), but I'm hoping to have a fix soon. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] ANNOUNCE: GHC version 7.6.3
= The (Interactive) Glasgow Haskell Compiler -- version 7.6.3 = The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.3. This is a bugfix release relative to 7.6.2, so we recommend upgrading. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/release-7-6-3.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: porting to uClibc-based 686 Linux
On Fri, Apr 05, 2013 at 11:12:38PM -0400, Dubiousjim wrote: target$ inplace/bin/ghc-stage2 -o hello-cross hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello-cross ... target$ ./hello-cross Can't modify application's text section; use the GCC option -fPIE for position-independent executables. You can pass -fPIE to gcc by using the -optc-fPIE flag. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Does GHC on cygwin have an I/O manager?
On Sun, Mar 24, 2013 at 10:19:14AM +0200, kudah wrote: Does ghc still build under cygwin Sorry, no; we only support targetting mingw, not cygwin. Also, is it possible yet to build a ghc cross-compiler targeting windows? I don't think anyone's tried. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
On Thu, Mar 21, 2013 at 10:21:25AM +0800, John Lato wrote: What would be ideal would be if this library API freeze coincided with the snapshot (odd-numbered) release. I was only thinking of about a 2 week period, and only on the stable branch. Freezing the library APIs in HEAD after a snapshot release would mean it wouldn't be possible to do anything that required a library API change for 6+ months, which I don't think would be the best solution. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
We've had long discussions about snapshot releases, and the tricky part is that while we would like people to be able to try out new GHC features, we don't want to add to the burden of library maintainers by requiring them to update their libraries to work with a new GHC release more than once a year. The impression that I have from the responses so far is that most people who would like a snapshot release want to use it as their regular compiler, which will probably mean they want to use other libraries with it, which in turn will probably mean changes to libraries are needed (even if only bumping version bounds). It's therefore likely to mean more work for library maintainers (even if it's only checking and applying patches, it's still work). On Wed, Mar 20, 2013 at 01:23:04PM -0400, Carter Schonwald wrote: a) I often spend some time prior to recent GHC releases trying to build all the various major packages, and often send in patches to maintainers during that window (or at least the start of patches). Having a fixed snapshot release that maintainers can use to validate any such future proofing patches would be tremendously helpful Thank you for doing this, but doing it for snapshot releases too would probably double the work most maintainers need to do. But perhaps we should announce a library API freeze some time before the first RC on a stable branch. That way people can safely update their dependencies at that point, and by the time the RC is out people testing the RC will be able to test more without running into problems installing libraries. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.2 Release Candidate 1
Hi David, On Tue, Jan 22, 2013 at 09:39:40PM -0800, David Terei wrote: This bug is still present in mainline. Any chance of it being fixed? I've just built HEAD with 7.6.2, so I think this has been fixed. If not, please give me more details on how to reproduce it. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Release plans
Hi all, Thank you to everyone who gave us feedback on when we should release 7.8.1, and on future release plans in general. We've looked at all the responses, and we think that the best plan is to continue to make major releases annually, with minor patch-level releases between them. Additionally, we may recommend particular snapshots, and provide binary builds for all tier-1 platforms, for people who wish to test new features etc in HEAD. There is more detail on how all this will work here: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Releases We will therefore aim for a 7.8.1 release in October. We do not currently expect to make a 7.6.3 release, although that may change if serious bugs in 7.6.2 are discovered. Would a 7.7.x recommended snapshot be useful to you? Tell us if you want one. Compared to 7.6 it would contain: * polykinded Typeable library * major improvements in DPH (vectorisation avoidance, new vectoriser) * type holes * rebindable list syntax * major changes to the type inference engine * type level natural numbers * overlapping type families * the new code generator * support for vector (SSE/AVX) instructions * Scheduler changes to the RTS to improve latency Is it worth us putting out a preview, or are you happy to work from the nightly snapshots and wait for the full release in October? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
On Tue, Mar 12, 2013 at 09:47:21AM +0100, Joachim Breitner wrote: This is especially true when the shim packages are less simple to use, due to the handling of Prelude. Just to make sure I am following you, I think you are saying: Everything would work fine if there was a Prelude in base (used by packages that still use base, and not the shims) and a Prelude in one of the shim packages (used by packages that exclusively use the shims, and not base). The problem is that Prelude doesn't fit in any of the sensible shim packages (as it contains, for example, both pure and file IO functions), but having a shim package purely for the Prelude seems excessive. This is a problem regardless of whether we do A or B or both. I think we should avoid getting bogged down in one small detail at this stage. If we make the bulk of the changes now then we still have a few months to polish the result before it gets effectively frozen by being released. If you don't like the idea of putting it in its own package, then I think either the file-io package (as that's the worst thing it contains) or the pure package (as that's the package most likely to be depended on anyway) would make most sense. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
On Tue, Mar 12, 2013 at 03:58:28PM +0100, Joachim Breitner wrote: Both have issues: Putting it in file-io will cause everyone to depend on file-io If it ended up there, then we'd presumably encourage people to use NoImplicitPrelude and import e.g. list functions from Data.List rather than Prelude. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
On Wed, Feb 27, 2013 at 04:54:35PM +, Simon Marlow wrote: On 25/02/13 18:05, Ian Lynagh wrote: Personally, I don't think the language report should be specifying the content of libraries at all, It's not that straightforward, because the language report refers to various library functions, types and classes. For example, integer literals give rise to a constraint on Num, so we have to say what Num is. Guards depend on Bool, the translation of list comprehensions refers to map, and so on. It could be whittled down certainly (we actually removed a few libraries in Haskell 2010), but there's still a core that is tied to the language definition. Yes, OK, my language was a bit strong: s/at all/any more than necessary/ Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
On Mon, Feb 25, 2013 at 02:25:03PM +, Simon Peyton-Jones wrote: | I added a Goals section to | http://hackage.haskell.org/trac/ghc/wiki/SplitBase Thanks. But the first goal, which is the dominant one, is very unclear to me as my comments mentioned. A description of what the problem is, and why a simple API wrapper approach would not solve it, would be useful. On the wiki page you say: SPJ: But that goal needs a bit of unpacking. Suppose we divided base into six, base1, base2, base3, etc, but each was a vertical silo and every other package depended on all six. Then nothing would be gained; bumping any of them would cause a ripple of bumps down the line. but even if we did just divide base up into vertical silos then I don't think most packages would depend on them all; for example, most packages would probably not depend on file-io or concurrency. But in any case, I'd hope we would also make some horizontal cuts, and I expect very few packages would need to depend on ghc-io-manager etc. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
On Mon, Feb 25, 2013 at 02:31:56PM +0100, Joachim Breitner wrote: Hopefully the problem here (often-changing base) is big enough and the alternative (more purpose-oriented and more stable) packages are attractive enough to make people use the new set. I'm pretty confident that most packages won't do more than the minimal base bumping while importing base continues to work. * base would still be an opaque blob, with too many modules and cyclic imports, which makes development tricky Does it really make development tricky? I’d rather expect it to make development easier, because you _can_ mix, say, IO and Foreign stuff easily and even use some of that in lower levels. If it were less tricky to separate it, then my experiment at https://github.com/nomeata/packages-base/tree/base-split would have been less work... It's tricky to make changes to the core modules, because that generally requires changing imports, and it's hard to see how to actually do that without making an import loop (or without making more import loops than are necessary). In general there's actually a fair amount of flexibility in which way module imports go (e.g. you can move a Cl Ty instance from the Cl module to the Ty module or vice-versa), but in base it's hard to see how to structure things best: there are approaching 200 modules, half of which are tied up in a recursive knot, with 13 hs-boot modules (2 of which import other hs-boot modules). In any case there is still the problem: What and where is the Prelude... but maybe let’s postpone this. I'd put it in its own package for now, and then look at whether/what it should be merged with later. I'm in 2 minds about it. On the one hand, I'm sure that lots of people won't like a single-module package that essentially everything depends on. But on the other hand, Prelude is both magic and broad, so it would make some sense to have it in its own package. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
On Mon, Feb 25, 2013 at 11:29:42AM -0500, Stephen Paul Weber wrote: Somebody claiming to be Ian Lynagh wrote: On Mon, Feb 25, 2013 at 02:31:56PM +0100, Joachim Breitner wrote: In any case there is still the problem: What and where is the Prelude... but maybe let’s postpone this. I'd put it in its own package for now, and then look at whether/what it should be merged with later. Why shouldn't Prelude (and other really stable, standard modules) just live in the `haskell2010` package? If we did that then every package would depend on haskell2010, which is fine until haskell2013 comes along and they all need to be changed (or miss out on any improvements that were made). Even the really stable modules change, incidentally. For example, since Haskell 2010, the Show superclass of Prelude.Num was removed, Prelude no longer exports catch, and Data.List gained a function dropWhileEnd. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
On Mon, Feb 25, 2013 at 06:38:46PM +0100, Herbert Valerio Riedel wrote: Ian Lynagh i...@well-typed.com writes: [...] If we did that then every package would depend on haskell2010, which is fine until haskell2013 comes along and they all need to be changed (or miss out on any improvements that were made). ...wouldn't there also be the danger of type(class)-incompatible (e.g. the superclass breakages for startes) changes between say haskell2010 and haskell2013, that would cause problems when trying to mix libraries depending on different haskell20xx library versions? I think that actually, for the Num/Show change, the hasell98/haskell2010 packages just incorrectly re-export the new class. Personally, I don't think the language report should be specifying the content of libraries at all, and I doubt anyone really uses the haskell* packages. A separate library specification, perhaps based on the Haskell Platform, would make more sense IMO. But that's another debate :-) Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package
On Fri, Feb 22, 2013 at 07:52:00PM +0100, Joachim Breitner wrote: Of course with too much splitting one runs in the Bane of the Orphaned Instances – neither should base-foreign require base-float nor the other way around, but Storable Double needs to be define somewhere... This is no different than the question of whether the instance should be in Foreign.Storable or GHC.Types. One has to import/depend-on the other, and it doesn't matter which: it's an implementation issue, and doesn't affect people importing/depending-on the modules/packages. In this case, GHC.Types.Double is in ghc-prim, so you will presumably need to leave the instance in Foreign.Storable in base-foreign. Also, I notice that there is an issue with “internal” modules (mostly GHC.something) that should not be part of some stable API, but needed to implement packages further down. Should they just not be considered part of the “public” (and PVP-relevant) API? Or should there be two packages, e.g. base-pure-internal and base-pure, where the latter re-exports those modules that are meant for public consumption? If it's easy to split out the GHC.* modules, then that's probably better. If not (e.g. because Public.A imports GHC.B, which import Public.C, which imports GHC.D) then it's probably not worth the bother. So, what is the general opinion? Looks good to me! Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package
On Fri, Feb 22, 2013 at 11:38:04AM -0800, Johan Tibell wrote: Glad to see you're making progress on this. Once we're done exploring how fine-grained we can make the division we might want to pull back a bit I definitely agree with Once we're done. Once we have made all the splits we might want to make, it'll be a lot easier to see the big picture and merge packages we decide should be merged. It's a lot harder to work the other way, as it's tricky to see what is or isn't possible. In addition, I don't think we want to say that e.g. pure data structures can't depend on the FFI. While their current implementation might not use the FFI, what if we want to use it in the future. We'd have to reshuffle the packages again. I think the issue is what a package exports, rather than what it depends on. Changing the package dependencies later won't affect users of the package. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Fri, Feb 15, 2013 at 02:45:19PM +, Simon Marlow wrote: Remember that fingerprinting is not hashing. For fingerprinting we need to have a realistic expectation of no collisions. I don't think FNV is suitable. I'm sure it would be possible to replace the C md5 code with some Haskell. Performance *is* important here though - Typeable is in the inner loop of certain generic programming libraries, like SYB. We currently just compare hash(str) for equality, right? Could we instead compare (hash str, str) ? That would be even more correct, even if a bad/cheap hash function is used, and would only be slower for the case where the types match (unless you're unlucky and get a hash collision). In fact, we may be able to arrange it so that in the equal case the strings are normally exactly the same string, so we can do a cheap pointer equality test (like ByteString already does) to make the equal case fast too (falling back to actually checking the strings are equal, if they aren't the same string). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Thu, Feb 14, 2013 at 03:48:51PM +0100, Joachim Breitner wrote: Yesterday, I experimented a bit with base’s code, first beginning with as few modules as possible and adding what’s required; then starting with the whole thing and trying to remove e.g. IO. But clearly it is not easy: 1. Int requires throw DivideByZero; Monad requires error. That pulls in Exceptions. 2. Exceptions require Typeable. 3. Typeable is implemented with GHC.Fingerprint. 4. GHC.Fingerprint is implemented with Foreign and IO. 5. Foreign clearly needs Int and the like. so it is not clear how to pull out a pure base without IO and Foreign. Are there any good tricks how to break these interdependencies? We'll probably end up with a package (let's say ghc-bottom for now) right at the bottom of the hierarchy which contains a minimal set of definitions for Typeable, throw, etc, in modules like GHC.Typeable, GHC.IO (or, if it's small and the dependencies are circular, might be easier to have it all in a single module). It might be possible to merge this into ghc-prim later, but don't worry about that for now. These definitions would then be re-exported by Data.Typeable, Control.Exception etc higher up. Other libraries would be discouraged from depending on ghc-bottom, either socially or by needing to jump through extra hoops in a .cabal file fo allow it. However, this is the hard end to start from, because the modules right at the bottom depend on things much higher up, with cyclic imports. It'll be a lot easier to pull modules off the top instead, as nothing imports them. They also tend to be less magical (e.g. don't have wired-in names). Also, don't worry about necessarily pulling out /all/ the modules you want for a package all at once. Once you have smaller chunks it'll be easier to see what changes are necessary to move modules up/down. You may also need to leave e.g. some of IO lower down than the io package in a GHC.* module, and then to re-export it from io. Once the top has been pulled at as much as possible, it'll be a lot easier to see what's going on with the remainder, and work out what needs to be done to break the biggest loops. There are other issues, some avoidable (such as the hard-coded base:Num constraint on literals); I collected a list on http://hackage.haskell.org/trac/ghc/wiki/SplitBase Right, for things with built-in syntax you'll have to update GHC's wired-in names as you go. This will mostly just mean changing the modules, e.g. gHC_ENUM = mkBaseModule (fsLit GHC.Enum) in compiler/prelude/PrelNames.lhs might become gHC_ENUM = mkGhcPureModule (fsLit GHC.Enum) with mkGhcPureModule defined analogously to mkBaseModule, but occasionally you might want to move a definition to another module. If you get stuck, just yell. Maybe the proper is to reverse the whole approach: Leave base as it is, and then build re-exporting smaller packages (e.g. a base-pure) on top of it. The advantage is: * No need to rewrite the tightly intertwined base. * Libraries still have the option to have tighter dependencies. * Base can evolve with lots of breaking changes, as long as they do not affect the API by the smaller packages. * Development of this collection can happen outside the GHC tree. * Alternative implementations for (some of) these packages can be created, if the reason why they could not be moved out of base is one of implementation, not of API Disadvantages: * No-one would use the new packages unless they come with GHC; e.g. not a perfect analogy, but compare the number of rev-deps according to http://packdeps.haskellers.com/reverse of the various *prelude* packages vs base: 4831 base 6 basic-prelude 8 classy-prelude 4 classy-prelude-conduit 2 custom-prelude 1 general-prelude 1 modular-prelude 17 numeric-prelude 2 prelude-extras * If it comes with GHC, it would mean us permanently maintaining the two levels * base would still be an opaque blob, with too many modules and cyclic imports, which makes development tricky Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Wed, Feb 13, 2013 at 06:28:22PM +0100, Joachim Breitner wrote:
Am Mittwoch, den 13.02.2013, 13:58 + schrieb Ian Lynagh:
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.
can you transparently re-export a module from another package? I.e. if
base depends on io, IO provides System.IO, is there a way for base to
tell ghc to pretend that System.IO is in base, but that there is no
conflict if io happens to be un-hidden as well.
No. But there are currently no packages that depend on both base and io,
and anyone adding a dependency on io would remove the base dependency at
the same time.
It seems that something like this would be required to move modules from
base to something below it without breaking existing code.
I don't see why that's necessary. base would end up containing a load of
modules that look something like
{-# LANGUAGE PackageImports #-}
module System.IO (module X) where
import io System.IO as X
Also, if it works that smooth, this would not have to be one big
reorganization, but could be done piece by piece.
It's tricky to do it piece by piece. It's hard to remove individual
sensible pieces in the first place, and it means that you can't
subsequently move modules between packages later without breaking code
depending on the new packages.
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.
Why remove base? If it is just a list of dependencies and list of
modules to be re-exported, then keeping it (but advocate that it should
not be used) should not be too much a burden.
* Any package using it doesn't benefit from the reduced version bumps,
so we do actually want packages to move away from it
* Even though base (probably) wouldn't require a lot of work at any one
time, it would require a little work every now and again, and that
adds up to a lot of work
* Any time a module is added to one of the new packages, either we'd
have to spend time adding it to base too, or packages continuing to
use base wouldn't (easily) be able to use that new module.
(This is assuming that the reorganizing should not change existing
module names. If your plan was to give the modules new names, this
problem does not exist, but I’d rather prefer the less intrusive
approach.)
The odd module might be renamed, and there will probably be a handful of
definitions that move from one module to another, but for the most part
I was envisaging that we'd end up with the same modules exporting the
same things.
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Wed, Feb 13, 2013 at 07:32:06PM +0100, Joachim Breitner wrote: I have started a wikipage with the list of all modules from base, for a first round of shuffling, grouping and brainstorming: http://hackage.haskell.org/trac/ghc/wiki/SplitBase Great, thanks for taking the lead on this! 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. Why remove base? If it is just a list of dependencies and list of modules to be re-exported, then keeping it (but advocate that it should not be used) should not be too much a burden. * Any package using it doesn't benefit from the reduced version bumps, so we do actually want packages to move away from it We want them to do so. We should not force them (most surely will...) A lot of packages won't react until something actually breaks. (and I suspect many are unmaintained and unused, and won't react even once it does break). * Even though base (probably) wouldn't require a lot of work at any one time, it would require a little work every now and again, and that adds up to a lot of work Hopefully it is just updating the set of modules to be exported, sounds like it could be automated, given a list of packages. * Any time a module is added to one of the new packages, either we'd have to spend time adding it to base too, or packages continuing to use base wouldn't (easily) be able to use that new module. Hence we should add them; shouldn’t be too much work. I realised that there's actually no reason that the new 'base' package has to come with GHC (even immediately after the break-up); it can just be a package on Hackage (and, if desired, in the Haskell Platform). So it could easily be maintained by someone else, and thus be not much work for you, and 0 work for me :-) Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 10:09:56AM +0800, John Lato wrote: What I would like to see are more patch-level bugfix releases. I suspect the reason we don't have more is that making a release is a lot of work. So, Ian, what needs to happen to make more frequent patch releases feasible? Well, * actually making a release takes time * I assume that you also want more patches merged from the HEAD, rather than just putting intermediate releases out, in which case merging those patches also takes time. And most of the small fixes already get merged, so you'd be looking at merging bigger changes which are more likely to require resolving conflicts, and so take even more time so basically to make more releases we'd need to spend less time doing other stuff (or for someone else to look after the branch). Bigger changes, and especially changes that need altering for the stable branch, are also more likely to introduce bugs. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: I cannot compile ghc-7.6.2
On Sun, Feb 10, 2013 at 06:35:25PM +0800, Magicloud Magiclouds wrote: Linuxmint Nadia, ghc-7.6.1 was built and running OK. Just downloaded ghc-7.6.2, without changing anything and environment, and boot and configure returned OK, I got these. What happened? /usr/local/bin/ghc -H32m -O --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall \ -DCABAL_VERSION=1,16,0 \ -odir bootstrapping \ -hidir bootstrapping \ -ilibraries/Cabal/Cabal \ -ilibraries/filepath \ -ilibraries/hpc \ rm -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... done. libraries/Cabal/Cabal/Distribution/ParseUtils.hs:88:18: Could not find module `Data.Map' It is a member of the hidden package `containers-0.5.0.0'. Use -v to see a list of the files searched for. make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 It looks like there is a problem with your bootstrapping compiler, possibly caused by having more than one copy of containers installed. ghc-pkg check or ghc-pkg list might help. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
I'm not too optimistic we could actually get the final release out during February, assuming we want to allow a couple of weeks for people to test an RC. Does the Haskell Platform actually want to commit to using a GHC release with tons of [new] stuff, that has had little testing, days or weeks after its release? I thought the idea was that it would favour known-good releases over the latest-and-greatest, but perhaps I misunderstood or the philosophy has changed. Thanks Ian On Thu, Feb 07, 2013 at 09:00:37AM -0500, Richard Eisenberg wrote: Geoff's reasoning seems quite sound. +1 for February release. On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland mainl...@apeiron.net wrote: In practice the versions of GHC that are widely used are those that are included in the platform. Maybe we should coordinate with their next release? They are targeting a May 6 release, and the release process is starting March 4, so it sounds like the original GHC release plan (February release) would be a good fit for the platform as it would allow library writers to catch up and ensure that STABLE was tested enough for inclusion in the platform. It would be a shame to miss the platform release. Geoff On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote: Dear GHC users, * * *Carter*: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? *Andreas*: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we’d make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically: · major improvements in DPH (vectorisation avoidance, new vectoriser) · type holes · rebindable list syntax · major changes to the type inference engine · type level natural numbers · overlapping type families · the new code generator · support for vector (SSE/AVX) instructions Whenever it comes it would definitely be great to include Andreas friends’ work: · Scheduler changes to the RTS to improve latency The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn’t been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn’t happen otherwise.) So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. There seem to be pros and cons each way. I don’t have a strong opinion. If you have a view, let us know. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bang patterns
On Mon, Feb 04, 2013 at 07:26:16PM -0500, Edward Kmett wrote: If space sensitivity or () disambiguation is being used on !, could one of these also be permitted on ~ to permit it as a valid infix term-level operator? I don't think there's any reason ~ couldn't be an operator, defined with the (~) x y = ... syntax. Allowing it to be defined with infix syntax would be a little trickier. Hmm, I've just realised that if we decide to make !_ and !foo lexemes, then we'd also want !(+) to be a lexeme, which presumably means we'd want (+) to be a single lexeme too (and also `foo`, for consistency). But I don't think making that change would be problematic. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Bang patterns
On Mon, Feb 04, 2013 at 10:37:44PM +, Simon Peyton-Jones wrote: I don't have a strong opinion about whether f ! x y ! z = e should mean the same; ie whether the space is significant. I think it's probably more confusing if the space is significant (so its presence or absence makes a difference). I also don't feel strongly, although I lean the other way: I don't think anyone writes f ! x when they mean f with a strict argument x, and I don't see any particular advantage in allowing it. In fact, I think writing that is less clear than f !x, so there is an advantage in disallowing it. It also means that existing code that defines a (!) operator in infix style would continue to work, provided it puts whitespace around the !. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Bang patterns
On Sun, Feb 03, 2013 at 10:34:04PM +, Ben Millwood wrote: On Fri, Feb 01, 2013 at 05:10:42PM +, Ian Lynagh wrote: The first is suggested by A bang only really has an effect if it precedes a variable or wild-card pattern on http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns We could therefore alter the lexical syntax to make strict things into lexems, for example reservedid - ... | _ | !_ strictvarid - ! varid etc. This would mean that f !x is 2 lexemes, and f ! x 3 lexemes, with the former defining the function 'f' and the latter defining the operator '!'. This has 3 downsides: * It would require also accepting the more radical proposal of making let strict, as it would no longer be possible to write let ![x,y] = undefined in () We really can't make let strict, in my view: its laziness is sort of fundamental. I don't see why the given example necessitates it though: just use case-of in that scenario. Well, true, that's another option. It's rather unpleasant when you have multiple bindings, as when converted to 'case's, each 'case' requires you to indent deeper (or to use more braces). The third is to parse '!' in patterns in the same way that '~' is parsed in patterns, except that (!) would be accepted as binding the operator '!'. This means that f ! x defines f. This is roughly how it's done at present, right? I think it's roughly what GHC does now, yes. You missed the option of going the way of ~ and making ! an illegal name for an operator. Obvious drawbacks, probably not a good idea, but it would be the most consistent solution, so I wouldn't dismiss it immediately. Yes, OK. That's basically option 3 as far as patterns are concerned, but also disallows ! as an operator. (If we do come up with a way that doesn't involve making ! illegal, maybe we should consider allowing ~ as an operator as well!) Right, if we went for option 3 then making ~ an operator in the same way as ! would be possible. I think we should be cautious about doing so, though, as it's a semi-one-way change, i.e. once it's an operator and people start using it it becomes a lot trickier to revert the decision. Anyway, in light of my above comments, I think I like the first option the best (so bang patterns only apply to variables, let doesn't become strict). So just to clarify what you're proposing, this wouldn't be valid: let ![x] = e in ... and I guess these wouldn't either?: let !x = e in ... let [!x] = e in ... let (x, ~(y, !z)) = e in ... but these would?: let f !x = e in ... case x of ~(y, !z) - () i.e. you wouldn't be able to use ! in the 'pat' in the decl - pat rhs production. You'd also no longer support: do ![x] - e; ... and so again for consistency I guess these wouldn't work?: do !x- e; ... do [!x] - e; ... do (x, ~(y, !z)) - e; ... i.e. you also wouldn't be able to use ! in the 'pat' in the stmt - pat - exp ; production. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: GHC compilation error (re-post).
On Fri, Jan 18, 2013 at 01:05:05PM -0700, Caitlin wrote: I deleted the Haskell Platform installation, manually removed all traces of GHC and the Hakell Platform from my registry and various folders, then re-installed the Haskell Platform. I created a folder under the 'C:\' drive, copied my .hs files there, changed to that subfolder started ghci. The file loaded without error. This seems like a problem the developers might address in the next release? Thanks for the report. I've fixed it in HEAD. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bang patterns
Hi all,
I would like to get a full specification of the bang patterns syntax,
partly so it can be proposed for H', and partly so we can resolve
tickets like http://hackage.haskell.org/trac/ghc/ticket/1087 correctly.
I think there are 3 possibilities:
The first is suggested by A bang only really has an effect if it
precedes a variable or wild-card pattern on
http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
We could therefore alter the lexical syntax to make strict things into
lexems, for example
reservedid - ...
| _
| !_
strictvarid - ! varid
etc. This would mean that f !x is 2 lexemes, and f ! x 3 lexemes,
with the former defining the function 'f' and the latter defining the
operator '!'.
This has 3 downsides:
* It would require also accepting the more radical proposal of making
let strict, as it would no longer be possible to write
let ![x,y] = undefined in ()
* It would mean that f !x and f !(x) are different. Probably not a
big issue in practice.
* It may interact badly with other future extensions. For example,
{-# LANGUAGE ViewPatterns #-}
f !(view - x) = ()
should arguably be strict in x.
(you might also argue that it should define the operator '!'.
Currently, in ghc, it defines an 'f' that is lazy in x, which IMO is a
bug).
The second is to parse '!' differently depending on whether or not it is
followed by a space. In the absence of a decision to require infix
operators to be surrounded by spaces, I think this is a bad idea: Tricky
to specify, and to understand.
The third is to parse '!' in patterns in the same way that '~' is parsed
in patterns, except that (!) would be accepted as binding the operator
'!'. This means that f ! x defines f.
So my proposal would be to go with option 3. What do you think? And did
I miss any better options?
Thanks
Ian
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
Hi Malcolm, On Wed, Dec 12, 2012 at 10:40:53AM +, Malcolm Wallace wrote: Please send nominations to haskell-2011-commit...@haskell.org, summarising your interest and experience. The existing committee will (I hope) make some decision on how to proceed, in early January 2013. Any progress on this? Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
On Fri, Feb 01, 2013 at 05:31:53PM +, Malcolm Wallace wrote: The committee has received no nominations. At least one was sent. Does haskell-2011-commit...@haskell.org accept mails from non-members? Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
ANNOUNCE: GHC version 7.6.2
= The (Interactive) Glasgow Haskell Compiler -- version 7.6.2 = The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.2. This release fixes a number of bugs relative to 7.6.1, so we recommend upgrading. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/release-7-6-2.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] ANNOUNCE: GHC version 7.6.2
= The (Interactive) Glasgow Haskell Compiler -- version 7.6.2 = The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.2. This release fixes a number of bugs relative to 7.6.1, so we recommend upgrading. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/release-7-6-2.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Newtype wrappers
On Mon, Jan 14, 2013 at 03:28:15PM -0800, Johan Tibell wrote: On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge qdun...@gmail.com wrote: I assume it would change from doesn't compile to works if you add the required import. It's the same as the FFI thing, right? If you don't import M (T(..)), then 'foreign ... :: T - IO ()' gives an error, but import it and coerces T to its underlying type (hopefully that's a C type). This is what I thought Simon meant. If so, I don't think it's a good idea, as adding the import removes a compiler error in favor of a runtime error. If the programmer really wanted to do something this unsafe, she should use unsafeCoerce. Simon's proposal would mean that import Data.Set.Internal newtype wrap w :: Set Int - Set Age would be possible, in the same way that import Data.Set.Internal w :: Set Int - Set Age w (BinSet x y) = BinSet (MkAge x) (MkAge y) w Empty = Empty would be possible. i.e. it wouldn't let you write anything that you couldn't write anyway (although it would make it easier to write, and it would have better performance). The adding an import makes it compile issue is a red herring IMO. Adding the import also makes my second example work for the same reason; it's just more obvious that the constructor is needed in the second example as it's visible in the code. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newtype wrappers
On Mon, Jan 14, 2013 at 09:03:38PM +0200, Roman Cheplyaka wrote: * Simon Peyton-Jones simo...@microsoft.com [2013-01-14 18:09:50+] Friends I'd like to propose a way to promote newtypes over their enclosing type. Here's the writeup http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers Any comments? Why not just have a pseudo-function 'coerce'? By pseudo-function I mean something that can be used anywhere (or almost anywhere?) where a function can, but is a keyword and doesn't have a type. (It'd be similar to ($) as implemented by GHC, I figure.) The static semantics would be to compute the inner and outer types to the extent possible, and then behave as if the function was defined as a wrapper or unwrapper function for those types. In case when it is ambiguous, an error is issued, and the standard tricks can be used to refine the type (including annotation coerce itself with a type). It would be even better if we implemented a syntax for type arguments. Then, if type application was written f @ t, you would be able to (or perhaps required to) write coerce @ from_type @ to_type expr Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.2 Release Candidate 1
Hi Sean, On Mon, Dec 10, 2012 at 04:04:34PM +0100, Sean Leather wrote: On Sun, Dec 9, 2012 at 10:39 PM, Ian Lynagh wrote: Please test as much as possible; bugs are much cheaper if we find them before the release! I tried to build the source tarball on Mac OS X 10.5.8. I used GHC 7.6.1, which I also built myself (without any problem) and installed in /Library/Frameworks/GHC.framework/Versions/7.6.1/usr. I got this: HC [stage 0] ghc/stage1/build/hschooks.o ghc/hschooks.c:36:0: error: conflicting types for ‘StackOverflowHook’ Thanks for the report! I've fixed it in the 7.6 branch. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.2 Release Candidate 1
On Thu, Dec 13, 2012 at 12:31:09PM +0100, Goetz Isenmann wrote: This change https://github.com/ghc/ghc/commit/106f0434144199276add8860c146c542cc67513b is missing for a success build on DragonFly-3.2/x86_64 Thanks, I've merged it to the 7.6 branch now. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bytestring and GHC 7.6.2
On Tue, Jan 08, 2013 at 08:10:18PM +, Duncan Coutts wrote: Either way, lemme know if this is all fine, and I'll make the 0.10.0.2 release. Looks good, thanks! I've updated the GHC 7.6 repo to match the tag. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Separating build tree from the source tree
Hi Jan, On Sat, Dec 15, 2012 at 04:08:23PM +0100, Jan Stolarek wrote: [killy@xerxes : /dane/uczelnia/projekty/ghc-build] ./configure checking for gfind... no checking for find... /usr/bin/find checking for GHC version date... configure: WARNING: cannot determine snapshot version: no .git or _darcs directory and no VERSION file It looks like test -d .git fails on openSUSE for some reason. See the FP_SETUP_PROJECT_VERSION macro in aclocal.m4. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: building GHC for Slackware/Salix
Hi Tim, On Sun, Dec 09, 2012 at 11:53:32AM -0300, tim.beech wrote: My build script unpacks the binary distribution for unknown linux and builds GHC against that. (Both are version 7.4.2.) I have avoided installing anything else (such as the Haskell Platform) so as to keep as close as possible to the ideal of a package as a transparent, reproducible process that only depends on the source. As far as I can tell from the build prerequisites http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Tools the only consequence is that documentation is only created as html, not pdf and ps as well. You don't need the haskell-platform to build the docs; I suspect you're missing dblatex. Unexpected failures: lib/Time T5430 [bad stdout] (normal) perf/compiler parsing001 [stat not good enough] (normal) simplCore/should_compile spec-inline [stderr mismatch] (optasm) That is after running the fast version of the test suite, which the documentation says should pass 100%. My second question is, do these results suggest anything as to where the problem may lie, and how important it is? You'd need to look at how the tests failed. If you add TEST=T5430 parsing001 spec-inline to the command you were running the testsuite with then it'll run just those tests, which will make it easier to see what's happening. When I then installed the new package and built the Haskell Platform against it (using the build script at http://slackbuilds.org), although the installation nonetheless appeared to be succesful, the build script failed at the very end where it tries to do ghc-pkg recache When I did this manually, I discovered root permissions were needed. Is that normal? I'm not familiar with the HP build script, I'm afraid. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to start with GHC development?
On Sat, Dec 15, 2012 at 09:41:12AM +0100, Jan Stolarek wrote: Dnia piątek, 14 grudnia 2012, Ian Lynagh napisał: I think the main problem is that it's a very broad question. The answer to how should I get started would be completely different for if you wanted to implement a type system extension, port GHC to a new platform, or fix a bug in ghci All three task have one thing in common though - the GHC build system. Project sources are over 500MB, there are many subrepositories, build scripts etc - this is really intimidating at first and I guess that seeing all that was a bit discouraging. Now that I know the compiler itself is about 9MB it doesn't look that bad :) Wiki indeed seems to have all the information required. It's just that it would be good to give beginners a _precise_ list of things they should read to begin hacking. OK, so how can we improve it? I've just made one change that might help: On http://hackage.haskell.org/trac/ghc/wiki/Building Working Conventions was mentioned in the opening paragraph of as something to also see, which perhaps made it sound like it should be read first, which I don't think was the intention. I've moved it to the bottom of the list instead, so you won't see it before going through Setting up your system for building GHC, Getting the sources and Getting started with the build system. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to start with GHC development?
On Fri, Dec 14, 2012 at 02:44:19PM +, Simon Peyton-Jones wrote: This thread has made it clear that we should do more to help people find a way in to GHC. I think the main problem is that it's a very broad question. The answer to how should I get started would be completely different for if you wanted to implement a type system extension, port GHC to a new platform, or fix a bug in ghci (just to pick 3 examples; I think that trying to enumerate on a wiki page all the possible ways in which you could get started would be infeasible). I just had a quick look at how easy things are to find from http://hackage.haskell.org/trac/ghc/ and they look OK to me. One thing I wonder is how understandable the commentary link is to someone who doesn't already know what it is. Would something like A developer's guide to GHC be better? That might be too long for the sidebar, though. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient
On Fri, Dec 14, 2012 at 12:53:36PM -0800, Johan Tibell wrote: I've been tracking down a few (unrelated) performance bugs related to conversions between primitive types. What these issues had in common is that some rule failed to fire and the conversion went via Integer, killing performance. How do we best write a test that make sure that fromIntegral conversions between these types don't regress? Is it possible to test the output of the simplifier or do we have to do something less direct, like writing a loop that does such conversions and make sure that the allocation stay low? We have some tests looking at the -ddumjp-simpl output, e.g. integerConstantFolding. I'm not sure if we have one for type conversions OTTOMH. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient
Hi Carter, On Fri, Dec 14, 2012 at 04:34:29PM -0500, Carter Schonwald wrote: A related question I have is that I've some code that will map the singleton Nats to Ints, and last time I looked into this/ had a chat on the ghc-users list, it sounded like sometimes having Integer values constructed in between are unavoidable. Is that still the case with post 7.6.1 ghc? (And or, how might I be able to help?) I don't know what a singleton Nat is, but if you mean Word then that's what Johan's been working on. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Mailing list reorganisation
Hi all, Following a recent discussion, we propose to reorganise the GHC-related mailing lists so that we end up with: glasgow-haskell-users For user discussions ghc-devs For developer discussions ghc-commits For automated commit messages from the git repositories ghc-builds For automated nightly build reports ghc-tickets For automated messages from trac We would remove cvs-ghc cvs-libraries cvs-other glasgow-haskell-bugs but leave the archives in place, and for now forwarding messages to cvs-* to ghc-devs, and glasgow-haskell-bugs to ghc-tickets. (cvs-libraries and cvs-other are included in this list, because we think they are mainly used by libraries that GHC HQ maintains, or by GHC's lagging repos of libraries that other people maintain). The initial subscriber lists for ghc-devs, ghc-commits and ghc-builds would be the union of the subscribers of cvs-ghc, cvs-libraries and cvs-other. For ghc-tickets it would be the subscriber list for glasgow-haskell-bugs. Does that sound reasonable? Does anyone have any further questions or comments? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-7.6.2 breaks haddock interface...
Hi Joachim,
On Wed, Dec 12, 2012 at 12:20:35AM +0100, Joachim Breitner wrote:
I built GHC 7.6.2-rc1 for Debian.
Thanks for testing!
Provides: haddock, [-haddock-interface-21-] {+haddock-interface-22+}
i.e. upstream has bumped the haddock interface number. I really was not
expecting this from a minor release.
@GHC devs: Is that intentional?
CCing the haddock dev list.
I.e., is there really a change to the
on-disk format of the .haddock files? Can we expect this to be stable
until 7.6.2 final?
In general, please only bump the interface number if really required,
makes live much easier for us (and probably also for some of your other
users).
@Debian: If the answer is yes, what should we do? I think I have
automated rebuilding everything (at least everything in Darcs) enough to
make that not as painful as it used to be, but it would still take some
time. On the other hand, it would break Haskell in experimental for some
time (maybe a week, optimistically). But then, it is already partly
broken.
Won't you have to rebuild everything anyway, due to the GHC version
number in the .hi files changing?
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 7.6.2 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.6.2: http://www.haskell.org/ghc/dist/7.6.2-rc1/ This includes the source tarball, installers for Windows, and bindists for Windows, Linux, OS X and FreeBSD, on x86 and x86_64. We plan to make the 7.6.2 release early in 2013. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: building GHC for antique OSX
On Sun, Dec 09, 2012 at 05:45:17PM -0500, wren ng thornton wrote: I'm one of those curmudgeons still working on OSX 10.5.8. Recently I finally got around to building the latest GHC and, FWIW, everything seems to have worked out fine. I did get a few failed tests in the testsuite though, and I'm curious what they mean or if they're actually cause for concern? Unexpected failures: ../../libraries/directory/tests T4113 [bad stdout] (normal) concurrent/should_runconc070 [bad stdout or stderr] (ghci) ghci/should_run 3171 [bad stdout] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat too good] (normal) perf/haddock haddock.compiler [stat too good] (normal) stat too good is definitely not a cause for concern. It just means that haddock's performance was better than expected. For the others, you'd have to look at why they failed (add TEST=T4113 conc070 3171 to the testsuite make command you ran if you want to rerun only those tests). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCI segfault on Double math
Hi Ron, On Fri, Dec 07, 2012 at 03:33:01PM -0500, Ron Alford wrote: I'm trying to see if this is reproducible, or it's just my machine. This sounds like http://hackage.haskell.org/trac/ghc/ticket/7043 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On Thu, Dec 06, 2012 at 09:15:06PM +, Simon Marlow wrote: On 06/12/12 17:04, Ian Lynagh wrote: It's true that we do give e-mailing it as a (less preferred) way for users to submit a bug on http://hackage.haskell.org/trac/ghc/wiki/ReportABug but I wonder if we shouldn't change that. It's rare that we get a bug report e-mailed, and normally we ultimately end up creating a trac ticket for it anyway. I'm sure that people who really want to submit a bug report and for whatever reason can't use trac will e-mail it somewhere sensible. +1. ghc-bugs used to be for user-generated bug reports, but now it is almost exclusively Trac-generated emails. I don't think anything is gained by suggesting that people email bug reports any more. I've removed that option from ReportABug. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On Thu, Dec 06, 2012 at 06:25:49PM +0200, Roman Cheplyaka wrote: +1. I'd like to follow GHC development discussions, but getting all the commits is too much. I'm surprised by this, FWIW. I think skimming the commits is a good way to get an idea of what's going on, while discussions between developers tend to be focussed on particular obscure points (e.g. discussing correctness of a murky corner in the intersection between 2 new type system extensions, or discussing the way PIC is handled on OSX/PowerPC) which I wouldn't have thought were of much interest to any party not involved in the discussion and familiar with the details. Anyway, I'm not really too fussed about what mailing lists we have. I'll just subscribe to them all anyway :-) Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
On Thu, Dec 06, 2012 at 12:29:01PM +, Simon Peyton-Jones wrote: My own understanding is this: A GHC *user* is someone who uses GHC, but doesn't care how it is implemented. A GHC *developer* is someone who wants to work on GHC itself in some way. The current mailing lists: * glasgow-haskell-users: for anything that a GHC *user* cares about * glasgow-haskell-bugs: same, but with a focus on bug reporting I see glasgow-haskell-bugs as being mainly for developers, who want to see what bugs are coming in. It's true that we do give e-mailing it as a (less preferred) way for users to submit a bug on http://hackage.haskell.org/trac/ghc/wiki/ReportABug but I wonder if we shouldn't change that. It's rare that we get a bug report e-mailed, and normally we ultimately end up creating a trac ticket for it anyway. I'm sure that people who really want to submit a bug report and for whatever reason can't use trac will e-mail it somewhere sensible. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The end of an era, and the dawn of a new one
On Thu, Dec 06, 2012 at 09:56:55PM +1100, Ben Lippmeier wrote: I suppose I'm the default owner of the register allocators and non-LLVM native code generators. Great, thanks! By the way, if you feel like doing some hacking this holiday season, then you might be interested in http://hackage.haskell.org/trac/ghc/ticket/7063 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The end of an era, and the dawn of a new one
On Wed, Dec 05, 2012 at 12:42:33PM -0800, Johan Tibell wrote: I will maintain the I/O manager as per usual Excellent, thanks! There are a couple of tickets that are currently assigned to me that look like they might be IO manager bugs: http://hackage.haskell.org/trac/ghc/ticket/4245 http://hackage.haskell.org/trac/ghc/ticket/7133 I'm unlikely to have time to look at either of them in the near future, so please feel free to reassign them to yourself and take a look. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The end of an era, and the dawn of a new one
On Wed, Dec 05, 2012 at 12:37:22PM -0800, David Terei wrote: I have always considered the LLVM code generator my responsibility and will continue to do so. Great, thanks! I don't seem to find the time to make improvements to it but make sure to keep it bug free and working with the latest LLVM releases. So if others want are interested in working on it then there is plenty of room for that but I'll continue to maintain it and be responsible for it at the least. And of course, if anyone does find themselves looking for an LLVM-related ticket to fix, there's a component for them in trac: http://hackage.haskell.org/trac/ghc/query?status=infoneededstatus=newstatus=patchcomponent=Compiler+%28LLVM%29 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Patch to enable GHC runtime system with thr_debug_p options...
On Mon, Dec 03, 2012 at 09:11:07PM +0100, Joachim Breitner wrote: Dear GHC HQ: Would you advice against or for providing a RTS in the thr_debug_p and thr_debug ways in the Debian package? The main reasons not to add RTS ways are that they take time to build, and use disk space once built. For a distribution, it probably makes sense to build all of them (even if some are put in a separate ghc-rts-extra-ways package) as the compile-time is shared amongst many users, and it is harder for the user to build extra ways. It's also true that non-default ways are less-well-tested, but that doesn't necessarily mean they are buggier. And building them certainly shouldn't cause any bugs when not using those extra ways. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extending GHCi
On Tue, Dec 04, 2012 at 04:23:02PM +0100, Dennis Felsing wrote: Is there a way to extend GHCi without copying some of its source code? Someone was looking at moving the ghci code into a library, which may mean you need to copy less code, at least. I'm not sure what the status of that is, though. Is there a chance of having these features flow back into mainline GHCi once they are properly implemented? Sure, providing the complexity is not disproportionately high for the functionality. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Fri, Nov 30, 2012 at 12:28:41PM +, Simon Marlow wrote: Static by default, GHCi is dynamic: * still can't do this on Windows We can do it on Windows: We can use side-by-side assemblies. (well, assuming we fix #5987). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Performance Tsar
On Fri, Nov 30, 2012 at 09:38:10AM -0800, Johan Tibell wrote:
On Fri, Nov 30, 2012 at 9:11 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
If Bryan and Johan are the Performance Tsars the future looks bright. Or at
least fast. Thank you.
If someone could point me to the build bot script that we run today
that would be a great start.
The code is at http://darcs.haskell.org/builder/
The config, including the build steps, is attached.
Thanks
Ian
module Config (config) where
import Builder.BuildSteps
import Builder.Config
import Builder.Utils
import Data.Maybe
config :: Config
config = Config {
config_fromAddress = fromAddress,
config_emailAddresses = emailAddresses,
config_urlRoot = urlRoot,
config_clients = clients
}
fromAddress :: String
fromAddress = bit.buc...@galois.com
emailAddresses :: [String]
emailAddresses = [cvs-...@haskell.org]
urlRoot :: String
urlRoot = http://darcs.haskell.org/ghcBuilder/;
clients :: [(String, UserInfo)]
clients = []
stable :: BuildTime - BuildTime
-- stable _ = NoBuilds
stable bt = bt
data Branch = Head | Stable
data GhcBuildConfig = GhcBuildConfig {
gbc_branch :: Branch,
gbc_repo :: Maybe String,
gbc_extraGitFlags :: [String],
gbc_iscc :: Maybe String,
gbc_installExtraPackages :: Maybe Bool,
gbc_haddockDocs :: Maybe Bool,
gbc_latexDocs :: Maybe Bool,
gbc_hscolourSources :: Maybe Bool,
gbc_docbookHtml :: Maybe Bool,
gbc_docbookPdf :: Maybe Bool,
gbc_docbookPs :: Maybe Bool,
gbc_bootInterpreter :: String,
gbc_makeCommand :: Maybe String,
gbc_mainMakeFlags :: [String],
gbc_configureFlags :: [String],
gbc_unregisterised :: Bool,
gbc_fullTestsuite :: Bool,
gbc_publishResults :: Maybe (String, -- command to publish
String, -- location to publish to
Bool) -- publish docs too?
}
basicConfig :: GhcBuildConfig
basicConfig = GhcBuildConfig {
gbc_branch = Head,
gbc_repo = Nothing,
gbc_extraGitFlags = [],
gbc_iscc = Nothing,
gbc_installExtraPackages = Nothing,
gbc_haddockDocs = Nothing,
gbc_latexDocs = Nothing,
gbc_hscolourSources = Nothing,
gbc_docbookHtml = Nothing,
gbc_docbookPdf = Nothing,
gbc_docbookPs = Nothing,
gbc_bootInterpreter = perl,
gbc_makeCommand = Nothing,
gbc_mainMakeFlags = [],
gbc_configureFlags = [],
gbc_unregisterised = False,
gbc_fullTestsuite = False,
gbc_publishResults = Nothing
}
headConfig :: GhcBuildConfig
headConfig = basicConfig {
gbc_installExtraPackages = Just True
}
stableConfig :: GhcBuildConfig
stableConfig = basicConfig {
gbc_branch = Stable
}
completeBuild :: GhcBuildConfig - GhcBuildConfig
completeBuild c = c {
gbc_haddockDocs = Just True,
gbc_latexDocs = Just True,
gbc_hscolourSources = Just True,
gbc_docbookHtml = Just True,
gbc_docbookPdf = Just True,
gbc_docbookPs = Just True
}
ghcBuildSteps :: GhcBuildConfig - [BuildStep]
ghcBuildSteps gbc =
[BuildStep {
bs_name = git clone,
bs_subdir = .,
bs_mailOutput = False,
bs_prog = git,
bs_args = let gitRepo = case gbc_repo gbc of
Just r - r
Nothing -
http://darcs.haskell.org/ghc.git/;
in [clone] ++ branchFlags ++ gbc_extraGitFlags gbc ++ [gitRepo, build]
},
BuildStep {
bs_name = create mk/build.mk,
bs_subdir = build,
bs_mailOutput = False,
bs_prog = sh,
bs_args = let ls = [V=1]
++ [InstallExtraPackages= ++ toYesNo b | Just b - [gbc_installExtraPackages gbc]]
++ [HADDOCK_DOCS= ++ toYesNo b | Just b - [gbc_haddockDocs gbc]]
++ [LATEX_DOCS= ++ toYesNo b | Just b - [gbc_latexDocs gbc]]
++ [HSCOLOUR_SRCS=++ toYesNo b | Just b -
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 12:34:03PM +0100, Herbert Valerio Riedel wrote: Ian Lynagh i...@well-typed.com writes: [...] There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. btw, how is it planned to have .so libraries interact with the soon-to-be-released cabal-install sandbox feature? I don't think anything special needs to be done. The RPATHs will still point to the right DLL if it's in a sandbox. Please let me know if there's a problem that I'm missing, though! Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 12:28:31AM +0100, Joachim Breitner wrote: here comes the obligatory butting in by the Debian Haskell Group: Given the current sensitivity of the ABI hashes we really do not want to have Programs written in Haskell have a runtime dependency on all the included Haskell libraries. So I believe we should still link Haskell programs statically in Debian. Note that you'll have to link ghc dynamically or ghci won't work. This won't cause dependency problems, though, as ghc comes with all the libraries that it needs. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 09:09:58AM +, Simon Marlow wrote: On 27/11/12 23:28, Joachim Breitner wrote: Hence, Debian will continue to provide its libraries built the static way. So let me try to articulate the options, because I think there are some dependencies that aren't obvious here. It's not a straightforward choice between -dynamic/-static being the default, because of the GHCi interaction. Here are the 3 options: (1) (the current situation) GHCi is statically linked, and -static is the default. Uses the RTS linker. (2) (the proposal, at least for some platforms) GHCi is dynamically linked, and -dynamic is the default. Does not use the RTS linker. (3) GHCi is dynamically linked, but -static is the default. Does not use the RTS linker. Packages must be installed with -dynamic, otherwise they cannot be loaded into GHCi, and only objects compiled with -dynamic can be loaded into GHCi. You seem to be saying that Debian would do (3), but we hadn't considered that as a viable option because of the extra hoops that GHCi users would have to jump through. We consider it a prerequisite that GHCi continues to work without requiring any extra flags. I think what Joachim means is that the binaries /in Debian packages/ will be explicitly linked with -static, but the open question below is about whether to make -static or -dynamic the default for GHC. Open question: What should GHC on Debian do when building binaries, given that all libraries are likely available in both ways – shared or static. Shared means that all locally built binaries (e.g. xmonad!) will suddenly break when the user upgrades its Haskell packages, as the package management is ignorant of unpackaged, locally built programs. I’d feel more comfortable if that could not happen. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 09:20:57AM +, Simon Marlow wrote: My personal opinion is that we should switch to dynamic-by-default on all x86_64 platforms, and OS X x86. The performance penalty for x86/Linux is too high (30%), FWIW, if they're able to move from x86 static to x86_64 dynamic then there's only a ~15% difference overall: Run Time -1 s.d. - -18.7% +1 s.d. - +60.5% Average - +14.2% Mutator Time -1 s.d. - -29.0% +1 s.d. - +33.7% Average - -2.6% GC Time -1 s.d. - +22.0% +1 s.d. - +116.1% Average - +62.4% I am slightly concerned about the GC overhead on x86_64/Linux (8%), but I think the benefits outweigh the penalty there, and I can probably investigate to find out where the overhead is coming from. Improving this would also help the above, of course. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 04:00:02PM +0900, Jens Petersen wrote: Could you say more about the impact to ghc-7.6.2 Cabal? For example, question 8 is about whether Cabal should also build static libraries for a dynamic-by-default compiler. We would like to ship a version of Cabal that does the right thing with GHC 7.6.2. That will hopefully mean that by the time GHC 7.8 is released, people will have a Haskell Platform that contains a cabal-install that knows the right way to build things for GHC 7.8. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 06:43:09AM +, Ganesh Sittampalam wrote: On 27/11/2012 14:52, Ian Lynagh wrote: GHC HEAD now has support for using dynamic libraries by default (and in particular, using dynamic libraries and the system linker in GHCi) for a number of platforms. This has some advantages and some disadvantages, so we need to make a decision about what we want to do in GHC 7.8. There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. We would like to make these as soon as possible, so that GHC 7.6.2 can ship with a Cabal that works correctly. The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault If I understand the problem on Windows correctly, you can use dynamic libraries for ghci, but using them for compiled executables is difficult because there's no good solution for having the compiled exe find its DLLs. Right. If so, does that mean that you intend to switch over ghci to dynamic and build static+dynamic by default, or are you going to leave ghci as static? Leave ghci as static. My general feeling about Windows is that it's ok for the end result to be a little annoying, because Windows DLLs *are* annoying and it's nothing to do with GHC. In particular I think in practice most Windows developers will have admin rights and could live with the ghc installation and cabal install having to be done as elevated operations. Where they weren't done with admin rights, then ghc -o could warn the user that the DLLs need to be copied locally (or even copy them itself and tell the user it happened). Personally, I would prefer the C stub option to that. More generally, if you can implement the half a plan you mentioned elsewhere in the thread for quickly building both static and dynamic ways, then the combination of the ABI and performance issues mean that I'm marginally in favour of keeping static linking as the default for executables on all platforms, but building the dynamic libraries for ghci. That would solve the installing libraries takes twice as long problem, but not the ghci can't load modules compiled with ghc -c problem. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 01:28:54PM +, Simon Marlow wrote: On 28/11/12 12:48, Ian Lynagh wrote: On Wed, Nov 28, 2012 at 09:20:57AM +, Simon Marlow wrote: My personal opinion is that we should switch to dynamic-by-default on all x86_64 platforms, and OS X x86. I should have deleted the above sentence. The performance penalty for x86/Linux is too high (30%), FWIW, if they're able to move from x86 static to x86_64 dynamic then there's only a ~15% difference overall: Run Time -1 s.d. - -18.7% +1 s.d. - +60.5% Average - +14.2% Mutator Time -1 s.d. - -29.0% +1 s.d. - +33.7% Average - -2.6% GC Time -1 s.d. - +22.0% +1 s.d. - +116.1% Average - +62.4% The figures on the wiki are different: x86 static - x86_64 dynamic has +2.3% runtime. What's going on here? +2.3% on OS X, +14.2% on Linux. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 01:34:22PM +, Ganesh Sittampalam wrote: On 28/11/2012 13:13, Ian Lynagh wrote: More generally, if you can implement the half a plan you mentioned elsewhere in the thread for quickly building both static and dynamic ways, then the combination of the ABI and performance issues mean that I'm marginally in favour of keeping static linking as the default for executables on all platforms, but building the dynamic libraries for ghci. That would solve the installing libraries takes twice as long problem, but not the ghci can't load modules compiled with ghc -c problem. Can't ghc -c also produce both static and dynamic objects? That's true, it could. Simon will point out that build systems will need updating if we start generating more/different files, but perhaps the pain would be worthwhile. I've been thinking about how to actually implement the half-plan. How about this? (don't worry about the names I've used for things for now): * Add a new way, dynstatic. Compiling Foo this way makes Foo.ds_hi Foo.ds_s_o -- static Foo.ds_d_o -- dynamic and by default links statically. There's a flag to make it link dynamically instead. * When compiling things the dynstatic way, all dependencies must be compiled the dynstatic way * When compiling things the static way, dependencies can be compiled either the static or the dynstatic way * When compiling things the dynamic way, dependencies can be compiled either the dynamic or the dynstatic way * Cabal compiles dynstatic by default * ghc compiles dynstatic (linking statically) by default * ghci uses dynamic libraries on all platforms * If we are worried about performance of the compiler, then ship ghc as a static binary and ghci as a separate dynamic binary. The size of the two combined is only 2-3% larger than just the static binary. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Wed, Nov 28, 2012 at 11:04:44AM -0500, Stephen Paul Weber wrote: Building them also in the dynamic way for the sake of GHCi users seems possible. Perhaps Debian could just ship a GHCi that uses the RTS linker, as now? The change is to be made for some platforms, we could opt to have Debian not be such a platform. This isn't a good long-term plan. Even if we don't actively remove support for other platforms (which we plan to do), they'll probably bitrot, and the current bugs won't be fixed. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Dynamic libraries by default and GHC 7.8
Hi all, GHC HEAD now has support for using dynamic libraries by default (and in particular, using dynamic libraries and the system linker in GHCi) for a number of platforms. This has some advantages and some disadvantages, so we need to make a decision about what we want to do in GHC 7.8. There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. We would like to make these as soon as possible, so that GHC 7.6.2 can ship with a Cabal that works correctly. The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault If you have a few minutes to read it then we'd be glad to hear your feedback, to help us in making our decisions Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote: Somebody claiming to be Ian Lynagh wrote: GHC HEAD now has support for using dynamic libraries by default (and in particular, using dynamic libraries and the system linker in GHCi) for a number of platforms. The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault IIRC, one of the problems with dynamic linking in GHC is that when the GHC version is different, the ABI can often be different enough to making such shared libraries incompatible with each other / binaries made on different GHCs. This makes distribution a potential nightmare (where you have to package all the *.so files and send them along with your binary, which is essentially the same as static linking, but more pain). Is this no longer the case, or am I completely misremembering this? That is still the case. However, if you want to distribute binaries then you will still be able to build with -static if you don't want to have ot bundle a load of DLLs. It's only the default that will change. Also, you say for a number of platforms and that wiki page says Currently, we don't know how to do dynamic-by-default on Windows in a satisfactory way. So I assume Windows is not one of the platforms that would be seeing this change? We would love for Windows to be one of the platforms, but currently we can't do it on Windows. So unless that changes, Windows will not be one of the platforms, correct. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Tue, Nov 27, 2012 at 12:07:34PM -0500, Stephen Paul Weber wrote: Somebody claiming to be Ian Lynagh wrote: On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote: IIRC, one of the problems with dynamic linking in GHC is that when the GHC version is different, the ABI can often be different enough to making such shared libraries incompatible with each other / binaries made on different GHCs. This makes distribution a potential nightmare (where you have to package all the *.so files and send them along with your binary, which is essentially the same as static linking, but more pain). That is still the case. However, if you want to distribute binaries then you will still be able to build with -static if you don't want to have ot bundle a load of DLLs. It's only the default that will change. If the default changes, though, that would mean that before distribution I would have to re-build all my cabal packages with -static? And if I change my default so that cabal builds with -static GHCI would no longer work for me? You can configure Cabal to build both static and dynamic libraries whenever you install anything - but it'll take twice as long. We actually have half a plan to fix this, so that a single compilation would build both static and dynamic libraries. Most of the work (parsing, type checking, optimising) can be shared; it's just the codegen phase that needs to be different. The tricky bit is that it only works if all the dependencies have been compiled for both ways at the same time too. If any dependencies were built with different options for static and dynamic, or even if there was just a different random name generated, then things can go wrong. So we need to work out the details so that nothing breaks. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Tue, Nov 27, 2012 at 08:38:21PM +0100, Matthias Kilian wrote: On Tue, Nov 27, 2012 at 02:52:48PM +, Ian Lynagh wrote: The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault If you have a few minutes to read it then we'd be glad to hear your feedback, to help us in making our decisions Regarding Question 7 (enable dynamic by default on other platforms) and OpenBSD: as long as it's easy to disable it again, I'll be happy with *any* decision. It will be easy to turn it off, but depending on the platform we might have removed support for GHCi when it's turned off. Does ghci work for you currently? Is this a registerised or unregisterised build? That's partially because currently we've even a patch explicitely disabling shared library support in our ports/packages system (last time I tried with shared lib support, I got some segfaults in the midst of the build, and unfortunately I'm still too short of time to debug/fix it). That's a bit bizarre. With shared libraries enabled, there still won't be any dynamically linked programs actually run. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Tue, Nov 27, 2012 at 01:34:59PM -0800, Evan Laforge wrote: I don't totally understand how ghci loading would work. I assume that for external packages it will go load x.so instead of x.a, but what about local modules? I assume ghc -c is still going to produce .o files, so does that mean ghci will have to interpret all local moules? No, it links them into a temporary .so in /tmp and dlopens that. On the plus side, it seems like this would do wonders for link time, which is currently about 15s of machine grinds to a halt for me. I didn't see mention of it on the page, but I assume linking a binary with lots of giant packages is going to be a lot faster if they can be loaded on demand at runtime... or is just going to make startup really slow? It looks like it's fractionally slower on x86_64/Linux: Using static libraries with ghci: $ time echo GHC.maxPrecedence | ghc --interactive -package ghc -v0 9 1.00s user 0.12s system 100% cpu 1.122 total Using dynamic libraries with ghci: $ time echo GHC.maxPrecedence | ghc --interactive -package ghc -v0 9 1.01s user 0.15s system 101% cpu 1.141 total Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use `trace` while debuging GHC
On Sun, Nov 11, 2012 at 05:24:06PM -0800, Iavor Diatchki wrote: There used to be a value called `tracingDynFlags` that I could use to dump values, but it has disappeared... Did it get moved somewhere, or is there a better way to get the same effect? There is now StaticFlags.unsafeGlobalDynFlags. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RULES for ByteString are not fired
Hi Kazu, On Tue, Aug 28, 2012 at 01:37:32PM +0900, Kazu Yamamoto wrote: I seems to us (my friends and me) that term rewriting rules for ByteString are not fired in recent GHCs. Thanks for the report. I've filed a ticket here: http://hackage.haskell.org/trac/ghc/ticket/7374 Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC on OpenIndiana
Hi Apostolos, On Sun, Sep 16, 2012 at 09:07:56AM -0400, asyropou...@aol.com wrote: http://www.haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html#sec-booting-from-hc Some community members have made Solaris binary distributions in the past. It would be easier to start from one of those rather than trying to port GHC. It looks like the latest one is here: http://www.haskell.org/ghc/download_ghc_7_0_3#x86solaris checking build system type... i386-pc-solaris2.11 checking host system type... i386-pc-solaris2.11 checking target system type... i386-pc-solaris2.11 HOST: i386-pc-solaris2.11 Can't work out build platform Not e that configure.ac contains a section on Solaris: You probably need to normalise solaris2* to solaris2 in aclocal.m4 (search for solaris). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How do I build GHC 7.6 from source?
On Tue, Sep 18, 2012 at 12:48:13PM -0700, Iavor Diatchki wrote: Hello, I was just trying to build the GHC-7.6 branch from source and the build failed with type-errors, because the libraries used by GHC have moved on since the release, and sync all just gets the most recent version. Use this: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Gettingabranch to get the ghc-7.6 branch. Why do you want to build 7.6 but not 7.6.1, OOI? More generally, I run into this problem all the time with people trying to build the branch I work on, so it really would be nice if we started using sub-modules to keep track of this dependency. I talked to folks at ICFP about this, and one idea was that we could check in the fingerprint for a branch into the repo, and track the dependencies this way, but this is See http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystate The nightly build logs include a fingerprint. exactly what git's submodule machinery does, so it seems pointless to implement the functionality which is already there with a standard interface. Thoughts? http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Theperspectiveonsubmodules Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 7.6.1
On Thu, Sep 06, 2012 at 09:42:53AM -0700, Johan Tibell wrote: 2. Could you please push all the packages that were released in GHC 7.6.1 to Hackage as well? I've now uploaded those that we maintain. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
On Thu, Sep 06, 2012 at 06:32:38PM +0200, Christian Hoener zu Siederdissen wrote: Awesome, I have been playing with GHC 7.6.0 until today and been very happy. Btw. isn't this the version that officially includes -fnew-codegen / HOOPL? Because the new codegen is optimizing the my ADPfusion library nicely. I lost 50% speed with new features, gained 100% with new codegen, meaning new features come for free ;-) I suspect that you'll find that the new codegen doesn't work 100% perfectly in 7.6, although I don't know the details - perhaps it just isn't as fast as it could be. It'll be the default in 7.8, though. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
