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 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: 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: 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: 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 > wrote: > > > 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
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
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: 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: 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
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
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 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 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 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 06:38:46PM +0100, Herbert Valerio Riedel wrote: > Ian Lynagh 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 -- 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 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 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
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
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 (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: 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: 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: 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: 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 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: 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 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 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 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?
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?
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 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: 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
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
Re: Newtype wrappers
On Mon, Jan 14, 2013 at 09:03:38PM +0200, Roman Cheplyaka wrote: > * Simon Peyton-Jones [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: 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 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: 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: 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: 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: Pragmas in Lexer
On Sat, Dec 29, 2012 at 11:24:23AM +0100, JP Moresmau wrote: > > let prTS = lexTokenStream sb lexLoc flg > > This prints: > ["ITblockComment \" CPP #\"","ITmodule","ITconid > \"Main\"","ITwhere","ITvocurly","ITvarid \"main\"","ITequal","ITvarid > \"undefined\""] > > Why is the first token ITblockComment and not ITlanguage_prag? Do I need to > enable something special to get pragma tokens? lexTokenStream uses mkPState, but I think you need to use pragState to get the language pragmas. (see Lexer.x). 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 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
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 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: 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
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: 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
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: 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: 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: 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: 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: 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=infoneeded&status=new&status=patch&component=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: 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 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: 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: 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: 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
> 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="++
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: 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
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 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 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 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 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 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 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 12:34:03PM +0100, Herbert Valerio Riedel wrote: > Ian Lynagh 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 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: 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 +0000, 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 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 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
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: 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: 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: 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: 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: [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
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
ANNOUNCE: GHC version 7.6.1
= The (Interactive) Glasgow Haskell Compiler -- version 7.6.1 = The GHC Team is pleased to announce a new major release of GHC, 7.6.1. Here are some of the highlights of the 7.6 branch since 7.4: * Polymorphic kinds and data promotion are now fully implemented and supported features. * Windows 64bit is now a supported platform. * It is now possible to defer type errors until runtime using the -fdefer-type-errors flag. * The RTS now supports changing the number of capabilities at runtime with Control.Concurrent.setNumCapabilities. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.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: Fwd: Request for comments on proposal for literate programming using markdown
On Thu, Aug 23, 2012 at 10:28:46AM +, Philip Holzenspies wrote: > Below message was rejected because I included the screenshot which was to > big. The screenshot referred to is now here: > > http://tinypic.com/r/2yy6tcy/6 (screenshot shows: http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/src/TcRnDriver.html ) > Well, I thought it would be reasonably obvious, but apparently, people like > the current output enough to want to keep it. See attached screenshot; this > drove me crazy, but that was just me. Oh, I never look at that. But the problem here is that HsColour is apparently treating the literate text as if it were HTML. Unless there is some sort of pragma indicating that that is the case, surely it should put the literate blocks in a tag? And perhaps colour them, or use some sort of border, to distinguish them from the code. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Request for comments on proposal for literate programming using markdown
On Mon, Aug 13, 2012 at 08:45:51AM +, Philip Holzenspies wrote:
>
> Absolutely true, but I came across this in the GHC-source itself. I would
> like the GHC-source to be literateable (not a work, but you know what I mean)
> in markdown.
FWIW, I'm not sure the work necessary to maintain correctly marked-up
commentary is worth the gain.
But that aside, why not use a doc generator that first unlits the
\begin{code}...\end{code} style, and then treats the non-code sections
as markdown format? You'd need to either not use blockquotes, or provide
some way to escape the ">"s.
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.1 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.6.1: http://www.haskell.org/ghc/dist/7.6.1-rc1/ This includes the source tarball, installers for 32bit and 64bit Windows, and bindists for amd64/Linux, i386/Linux, amd64/OSX and i386/OSX. 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: Fwd: ghc-7.6 branch
Hi Johan, On Wed, Jun 27, 2012 at 03:06:39PM -0700, Johan Tibell wrote: > > On Wed, Jun 27, 2012 at 12:53 PM, Ian Lynagh wrote: > > If a GHC release needs an unreleased change in one of the libraries, and > > the maintainer (for whatever reason) is not responding to e-mails, > > should the GHC release be held up indefinitely? You didn't give a clear answer to my question. Am I right in thinking that your answer would be "Yes, the GHC release should be delayed indefinitely"? (or at least, for long enough for the maintainer to be declared MIA) > Again, note that GHC is no different from any other package here. > > I think the problem is one of misunderstanding how the > process of managing dependencies ought to work (and how it works > elsewhere.) "We must release a new version of so-and-so lib because we > made such-and-such change" is wrong. Upstream changes (i.e. to GHC > deps) ought to happen before downstream releases of dependent code > (i.e. GHC.) This is actually the main reason that the situation between GHC and the libraries it uses is different to most other packages, both within Haskell and without: It is true that ghc depends on (for example) containers; but containers also depends on base, and base/ghc are so intertwined that they are essentially the same package (at least, I don't think you're suggesting that we should make separate base and ghc releases). That is what I mean by them being part of the same system. For example, I recently removed the 'catch' export from Prelude, and this required corresponding changes in Cabal, Win32 and haskeline. It's not possible to make the change in the base library without making the corresponding changes, or the GHC build would break, and there's no reason the maintainers of the other packages would make the change if I didn't ask them to. A more mundane example is library dependencies. If we make a change in filepath that requires bumping its major version, then we need libraries such as Cabal to relax their dependency on filepath or, again, the GHC build would break. > Has maintainer's not being responsive been a problem for GHC in the > past? Yes. Some of the upstreams respond so fast that it makes my head spin, while others often either don't respond or continually promise to get to things soon. (again, these are good, well-meaning people, who do a lot for the community). > I believe this is the first time I've seen an email of this kind > from GHC HQ. Generally these mails are all directly to maintainers. They're generally longer than this, but in essence it normally goes something like mail 1: "Could you take a look at this patch please?" mail 2: "Did you have a minute to look at that patch?" mail 3: "I think the patch is good. Would it help if I pushed it for you?" mail 4: "This is blocking other things, so I'd like to push it. Please let me know within a week if you object" (there may be multiple mail 2s, and mail 3 sometimes gets an affirmative response). Once this has happened a few times, we tend to suggest switching to a system where we just push by default, without the need for the mails and the delay (in fact, more-or-less what Gershom suggested). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
On Wed, Jun 27, 2012 at 11:42:24AM -0700, Johan Tibell wrote: > On Wed, Jun 27, 2012 at 8:12 AM, Ian Lynagh wrote: > > On Tue, Jun 26, 2012 at 04:30:02PM -0700, Johan Tibell wrote: > >> > >> I just want to see things changed. :) > > > > We're happy to try to improve things, but I'm not sure what change you > > want exactly. > > I want GHC to stop releasing other people's code, unless they've > explicitly asked GHC to do so. Other than that, you can do what you > want. Here's an honest question: If a GHC release needs an unreleased change in one of the libraries, and the maintainer (for whatever reason) is not responding to e-mails, should the GHC release be held up indefinitely? If the answer is "yes", then perhaps we should go back to community maintainership for all the libraries that GHC ships with. As well as being entities in their own right, those libraries are also part of larger systems (ghc, and perhaps also other Haskell implementations). If the answer is "no", then there are going to be times when we need to ship GHC with a version of a library that is not yet released. With the best will in the world, there are always going to be people who are swamped by real life, people on vacation, or even people who unbeknownst to us have died. But all that is really tangential to the main issue: even if the answer to the above question is "no", that does not mean that we need to routinely release libraries maintained by active upstreams. If upstream is responsive, then we can discuss with them what code to use and what releases need to be made. The original e-mail was intended to be the first in that discussion. Perhaps we phrased it badly, or perhaps you have bad memories of previous mistakes or of previous systems of releasing, but all we were trying to do is to find out what code we should set up the new stable branch to use. We're happy to discuss concrete changes to the way things work. But (a) I don't think any change is necessary if your goal is for us to not make containers releases, and (b) GHC is a complex beast, and it already take lots of work over a period of weeks (or sometimes months) to get a release out. I'm keen to keep the process as lightweight as possible. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
On Tue, Jun 26, 2012 at 04:30:02PM -0700, Johan Tibell wrote: > > I just want to see things changed. :) We're happy to try to improve things, but I'm not sure what change you want exactly. We could change the default for GHC stable branches to: * Use the tag for the latest release, unless that isn't suitable, in which case use HEAD but note that it isn't necessarily easy to tell in advance if the latest release is suitable. For example, if library A decides to use a new major version number, then library B may need to relax its dependency on library A. Of course, we will make any decisions in discussion with the maintainers. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cannot build user's guide
On Mon, Jun 25, 2012 at 02:34:34PM +0100, José Pedro Magalhães wrote: > > (Btw, validate goes through. Does validate not build the user's guide?) It only builds it if the tools are available. I think that's mainly because they're a bit fiddly to install on Windows. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault/access violation in generated code
Hi Bas, On Sun, Jun 17, 2012 at 05:11:35PM +0200, Bas van Dijk wrote: > > module Main where > > import Foreign > import qualified Foreign.Concurrent as FC > import Control.Concurrent > import Bindings.Libusb.InitializationDeinitialization > > main :: IO () > main = do > ctxPtr <- alloca $ \ctxPtrPtr -> do > _ <- c'libusb_init ctxPtrPtr > peek ctxPtrPtr > > fp <- newForeignPtr p'libusb_exit ctxPtr > -- fp <- FC.newForeignPtr ctxPtr $ c'libusb_exit ctxPtr > > threadDelay 300 > print $ fp == fp What happens if you just call c'libusb_exit ctxPtr at the end, instead of using a finalizer? Are you able to reproduce this with just a .c file that is compiled and linked with the program, rather than needing libusb? That would make it easier to reproduce, to understand, and to add a test. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Windows 64bit GHC port: First alpha release
Dear GHC users, Windows 64bit GHC port: First alpha release --- The Industrial Haskell Group has recently funded work by Well-Typed to make a Windows 64bit port of GHC. The port will officially be released as part of the upcoming GHC 7.6.1 release, but in the mean-time we are pleased to announce that an alpha release is available. You can download the installer for the alpha release from http://www.haskell.org/ghc/dist/win64_alpha1/ If you encounter any problems with the alpha, please report them as GHC bugs in the normal way: http://hackage.haskell.org/trac/ghc/wiki/ReportABug If any significant issues are found, then the platform page at http://hackage.haskell.org/trac/ghc/wiki/WindowsGhc will also be updated. About the IHG - The Industrial Haskell Group (IHG) is an organisation to support the needs of commercial users of the Haskell programming language. The IHG funds work to improve the Haskell ecosystem for industrial Haskell users. http://industry.haskell.org/ About Well-Typed Well-Typed LLP is a Haskell services company, providing Haskell consultancy services and writing bespoke Haskell applications. 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: Mac OS X: compiling for 10.5 under 10.6
On Tue, Jun 05, 2012 at 03:07:09PM +0200, Soenke Hahn wrote: > > If not, does that mean, > ghc-7.4.1 does not support OS X 10.5? As far as I know, if you build GHC 7.4.1 on OS X 10.5 then it will work, but I haven't tried it so I may be wrong. However, binaries built on newer versions (including the binaries we build) may not work on OS X 10.5. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: can't compile ghc-7.4.1: No rule to make target `libraries/process/ghc.mk'
On Wed, May 30, 2012 at 08:44:26PM +1000, Tim Cuthbertson wrote: > > Configuring hsc2hs-0.67... > make[1]: *** No rule to make target `libraries/process/ghc.mk'. Stop. > make: *** [all] Error 2 > > Any hints? That file should be included in the source tarball. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc trac not sending verification emails?
On Tue, May 29, 2012 at 10:09:47AM +1000, Tim Cuthbertson wrote: > I signed up for an account on http://hackage.haskell.org/trac/ghc/ to > report a couple of bugs, but can't file them until my email address is > verified. > > I've tried two different email addresses, waited more than 24 hours, > and checked my spam folder but sill don't see anything. Is email > sending busted? I know that the cabal trac is migrating to github, > does that affect GHC's trac as well? Looks like we sent 2 mails to t...@gfxmonk.net, at: 2012-05-26 22:18:31 2012-05-27 04:46:20 (I think those times are in PDT). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 7.4.2 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.4.2: http://www.haskell.org/ghc/dist/7.4.2-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. 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: 7.4.2 release plan update
On Tue, May 08, 2012 at 09:22:04PM +0100, Ian Lynagh wrote: > > A quick 7.4.2 release plan update: > > We've been having trouble with our nightly builds, so we haven't managed > to put out a release candidate yet. As soon as we have builds ready, > we'll put the RC out, and all being well the release will follow one or > two weeks later. I forgot to mention: You can see a list of fixed tickets in 7.4.2 here: http://hackage.haskell.org/trac/ghc/query?status=closed&order=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=component&milestone=7.4.2&resolution=fixed and there are release notes here: http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/release-7-4-2.html Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
