October 2013 - ghc-devs

Re: Are we expecting any other package version bumps before the 7.8 release?
by Austin Seipp 15 Oct '13

15 Oct '13

(Grrr, my email client is borked and using the wrong reply email it seems... Resent.) To answer the question, no. Herbert wanted to pull the trigger on some of this stuff in array since it had been deprecated for quite a while, so we went at it. Herbert also has an extremely detailed look at the status of 7.8 libraries as it stands: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/Libraries - I don't think we'll be removing any more deprecated stuff, so you should be OK to make another release. On Fri, Oct 11, 2013 at 6:06 PM, Johan Tibell <johan.tibell(a)gmail.com> wrote: > Hi, > > We have to make another Cabal release before 7.8 to deal with the major > version bump in array. Are there any other package version bumps before the > 7.8 release? If not I will make another release of Cabal. > > -- Johan > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Build error: No (or multiple) ghc rts package is registered
by Roman Cheplyaka 15 Oct '13

15 Oct '13

Hi, I tried to build GHC HEAD today, but eventually got this error: ghc-cabal: No (or multiple) ghc rts package is registered!! make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 I did "make clean" before starting the build — is it not sufficient? Roman

2 3

Re: ghc-compete, a repository of fingerprints, and continuous integration
by Simon Marlow 15 Oct '13

15 Oct '13

On 11/10/2013 14:15, Ian Lynagh wrote: > The reason we switched to submodules wasn't to make bisecting easier: It > was so that we can make temporary local changes to 3rd party libraries > (when changes to GHC or our libraries require them), and then jump back > to an official upstream commit without upstream needing to merge our > changes. Ah yes, thanks for pointing that out. So we must use submodules for libraries with a separate upstream unless we can find another solution to this problem. Cheers, Simon

1 0

Re: Wither Haskell Platform 2013.4.0.0
by Bob Ippolito 14 Oct '13

14 Oct '13

On Monday, October 14, 2013, Dag Odenhall wrote: > On Mon, Oct 14, 2013 at 12:20 AM, Brandon Allbery <allbery.b(a)gmail.com<javascript:_e({}, 'cvml', 'allbery.b(a)gmail.com');>> > wrote: > > Nope. Arch is a rolling release distribution whose policy is directly >> opposed to the "stable release" philosophy of the Platform. They will >> package latest versions of everything, not a "stable release". You *cannot* >> satisfy their requirements with the Platform; ignore them. > > I would say it depends on what you mean by “latest”, since one answer > could be “latest haskell-platform”. Does Arch Linux ship the latest Python > packages, even if an older version is included in the stdlib of the latest > Python release? > There isn't a separate "Python" and "Python Platform". Packages that ship with Python are maintained in Python's repository. Those that are also maintained separately usually have another package/module name altogether so both can be installed without interfering with one another. -bob

2 1

Re: [commit: packages/unix] master: Fix assumption that RLIM_INFINITY is a simple number (b092e35)
by Herbert Valerio Riedel 14 Oct '13

14 Oct '13

Hello Bryan, Thanks for catching this! (see also comment below) [...] > commit b092e35f4c99bfab12247e93c7fa478de638276a > Author: Bryan O'Sullivan <bos(a)serpentine.com> > Date: Sat Oct 12 16:45:50 2013 -0700 > > Fix assumption that RLIM_INFINITY is a simple number > > On MacOS X, it is defined as "(((__uint64_t)1 << 63) - 1)", and > hence cannot be used inside C preprocessor logic. > >>--------------------------------------------------------------- > > b092e35f4c99bfab12247e93c7fa478de638276a > System/Posix/Resource.hsc | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/System/Posix/Resource.hsc b/System/Posix/Resource.hsc > index a0d0d35..58cff6f 100644 > --- a/System/Posix/Resource.hsc > +++ b/System/Posix/Resource.hsc > @@ -95,13 +95,16 @@ packResource ResourceTotalMemory = (#const RLIMIT_AS) > > unpackRLimit :: CRLim -> ResourceLimit > unpackRLimit (#const RLIM_INFINITY) = ResourceLimitInfinity [...] I wonder though, how could that even have compiled in the past on OSX if the expanded RLIM_INFINITY macro #define in the LHS pattern wouldn't result in a simple number? Cheers, hvr

2 2

Re: GHC HEAD vs Hackage, panic-free edition
by Bryan O'Sullivan 14 Oct '13

14 Oct '13

On Sun, Oct 13, 2013 at 2:14 AM, Michael Snoyman <michael(a)snoyman.com>wrote: > The issue with yesod-core was an issue from the underlying hamlet package. > hamlet has some internal functions which are used by the TH-generated code > it produces, and those internal functions were not previously exported. > With previous versions of GHC, this wasn't a problem, though 7.8 seems to > have an issue with it. Is this an intended change? > I wouldn't know, porque yo no hablo el idioma del diablo llamado TH :-)

1 0

Re: Wither Haskell Platform 2013.4.0.0
by Matthias Kilian 13 Oct '13

13 Oct '13

On Sun, Oct 13, 2013 at 10:00:42PM +0200, Dag Odenhall wrote: > The obvious solution would be to track a major upstream with time-based > releases that isn't a Linux distribution itself. GNOME is a good candidate > for this. They typically produce new major versions one or two months > before the Linux distributions do, which gives the latter time to package > and test it. I don't understand the term "before the Linux distributions do". Do all Linux distributions agree on the same release schedule? I doubt so. And there are other operating systems with their completely own (and different) release schedules. For example, in OpenBSD the next release will happen in a little bit more than two weeks, but the versions of all readily built haskell packages for that release had been set in stone more than two months ago. Apart from that, I think neither haskell-platform nor ghc nor anyone else should even *try* to adjust their release schedule in favor of *any* operating system. Because that would introduce additional burdens and pressure on the (relatively small) group of people who are actively working and coordinating on ghc, core libraries, haskell-platform. Those working on Haskell should pick a schedule which they think matches their needs best. Operating system distributors then have to cope with that. If the haskell schedules doesn't fit nicely into a distributros schedule -- mayhbe bad luck, but what's the problem? This is the rule for *any* software project. And end-users always have the choice between using distribution packages or using binaries from haskell.org (well, at least for a few OS platforms) or building everything themselves. Look at debian: I guess a lot of people are using debian-stable, or even old-stable. I'm not sure, but I doubt those are even close to haskell-platform-2013.2.0.0 and/or ghc-7.6.3. (Correct me if I'm wrong) > It would also be good to have time-based release candidates > for haskell-platform to make this even smoother, especially since there are > much fewer people working on packaging and testing haskell-platform than > there is GNOME. I can only speak for myself, as the OpenBSD maintainer of (most) Haskell packages: I wouldn't have the time to test release candidates. When there's a new release of ghc, I start update the OpenBSD port when I've enough time to do so. And start to update depending libraries. Same for haskell-platform. And if something goes wrong, I just add local patches to our (OpenBSDs) ports. That's a quick&dirty approach, but it's less work (for me *and* Haskell developers) than going through a release candidate phase (and remember: I'm doing this when I have enough spare time, which might be weeks after a release candidate had been published). It would be interesting to hear from other people (like Joachim from Debian) how they deal with this ;-) > The primary audience for haskell-platform might be Windows users and > perhaps OS X users, but I think Linux is actually really important to this > goal, because a lot of library-producing and support-providing developers > use Linux, and currently the attitude seems to be dont use > haskell-platform, dont test your packages against haskell-platform, dont > advice beginners to use haskell-platform. Its just abstractly there for > others, unspecified. Where are you seeing this attitude? From some mails I got as the OpenBSD Haskell guy I had the impression that there are quite some users who *want* to use haskell-platform, because it's kind of "certified" combination of compiler, tools and libraries. Some users even don't want the latest and greatest haskell-platform, they're just happy with something which isn't completely rotten. For library authors not building/testing against the haskell-platform: well, that's a completely other issue, and I'm not going to blame anyone about it in *this* mail. > But to return to the thread topic: I dont really care if theres a release > with GHC 7.6 now or soon, but whatever happens I strongly feel there should > be a new haskell-platform with GHC 7.8 *no later than March 2014*, Why that pressure? Just wait how the new ghc goes, and if it's in a pretty state, update it in haskell-platform. Ciao, Kili -- Personally I learned Unix 22 years ago on a BSD system. I have some expectations of a Unix system based on that experience. When I log into a BSD system, I feel at home. When I log into a typical Linux distro, I feel alienated. -- Otto Moerbeek

1 0

Wither Haskell Platform 2013.4.0.0
by Mark Lentczner 13 Oct '13

13 Oct '13

Friends — Deep apologies for being so out of touch the last two months(*). In theory, we should be rev'ing up to produce Haskell Platform 2013.4.0.0, but I'd like to explore our options at this time: *1) Proceed as normal:* Such a release would use GHC 7.6.3, as did HP 2013.2.0.0, since that is still the current GHC release. Hence all the core library versions would remain the same, and by my rough eyeballing it, half the platform libraries would remain the same. The only big change might be OpenGL/GLUT libs, which has bumped a major version... though I don't know if that API change is too great or not. Given the time frame, we are unlikely to have any additional packages. This stance brings up the issue that 7.6.3, out of the box, won't work with Xcode 5, and hence the upcoming release of OS X Mavericks (10.9). *2) Delay a month:* This would give us time to consider new packages, which would make the release somewhat more valuable. However, a December release is hard due to holidays, so likelihood would be late December, or January release. *3) Ask GHC Central to produce 7.6.4:* This would incorporate the changes needed work with Xcode 5. This would clearly involve a month delay as in #2. *4) Skip it:* We could just decide that 2013.4.0.0 doesn't offer enough value to run the process now, and simply focus our efforts this cycle on improving the infrastructure that builds HP. Thoughts? I'm particularly interested to hear from HP library maintainers to know if there was/is something important to get out in an HP ASAP. I'd also like to better understand what our Xcode5 options are, and if/how/when we could see the latest cabal in the platform. Again, sorry that this small HP timing crisis is mostly my fault, — Mark (*) At least my excuse is that I was writing music with Haskell for those two months!

4 4

Re: small improvement to roles mechanism
by Bryan O'Sullivan 12 Oct '13

12 Oct '13

On Fri, Oct 11, 2013 at 7:17 PM, Mark Lentczner <mark.lentczner(a)gmail.com>wrote: > Do I read Bryan's post correctly, that 20% of packages on hackage fail to > compile with GHC 7.8? > There are currently 5615 packages on Hackage. Of those, 3443 built successfully with 7.6.3 on my test machine yesterday, so let's call that the baseline. And of the 3443 that compile with 7.6.3, 1262 (37%) *fail* to compile with HEAD. You can find the complete list of regressing packages here: http://lpaste.net/94214

1 0

RE: small improvement to roles mechanism
by Simon Peyton-Jones 12 Oct '13

12 Oct '13

It's in the nature of type systems that as well as excluding bad programs they also exclude some good programs. So if we tighten up the type system (and GND allows seg-faults at the moment) that is certain to exclude some good programs. Would you like a flag to say "allow me to use GeneralisedNewtypeDeriving even if it is dangerous to do so"? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Johan Tibell Sent: 12 October 2013 00:15 To: Richard Eisenberg Cc: Stephanie Weirich; ghc-devs(a)haskell.org Devs Subject: Re: small improvement to roles mechanism Let me start by saying that I'm happy we're trying to fix the GND problem. Thanks for working on that. That being said: is this ready for mainstream consumption? We're forcing this on everyone without any language pragma or flags to opt-in/out. That is bad if we're not sure we're doing the right thing in some cases or if we're causing spurious failures. At ICFP I got the impression that very few people will be affected, but Bryan's result suggests there are more people than I thought. On Thu, Oct 10, 2013 at 8:26 PM, Richard Eisenberg <eir(a)cis.upenn.edu<mailto:eir@cis.upenn.edu>> wrote: In Bryan's recent test of GHC 7.8 against all of Hackage, there were three spurious errors caused by lack of role abstraction. Here are the class definitions where a nominal parameter is inferred, probably against the wishes of the author: from logict-0.2.3/Control.Monad.Logic.Class: > class (MonadPlus m) => MonadLogic m where > msplit :: m a -> m (Maybe (a, m a)) from monadLib-3.5.2/MonadLib: > class (Monad m) => ReaderM m i | m -> i where > ask :: m i from base/Control.Arrow: > class Arrow a => ArrowApply a where > app :: a (a b c, b) c In each of these, the last parameter of the class is given a nominal role because it appears as the parameter of a type variable. However, in each case, it appears as the parameter of a *class* type variable. This means that, if we somehow knew that the class author wanted the class to be usable with GND, we could simply check every instance declaration for that class to make sure that the relevant concrete instantiation has the right role. For example, when the user writes, for example > instance ArrowApply Foo where ... we check that Foo's first parameter has a representational role. If it doesn't, then the instance is rejected. An alternative, somewhat heavier idea would be to represent roles as class constraints. We could have > class NextParamNominal (c :: k) > class NextParamRepresentational (c :: k) GHC could "generate" instances for every datatype definition. For example: > type role Map nominal representational > data Map k v = ... would induce > instance NextParamNominal Map > instance NextParamRepresentational (Map k) Users would not be able to write these instances -- they would have to be generated by GHC. (Alternatively, there could be no instances, just a little magic in the constraint solver. Somewhat like Coercible.) Then, the classes above would just have to add a superclass, like this: > class (Arrow a, NextParamRepresentational a) => ArrowApply a where > app :: a (a b c, b) c The role inference mechanism would be made aware of role constraints and use this one to derive that ArrowApply is OK for GND. This "heavier" approach has a similar upshot to the first idea of just checking at instance declarations, but it is more customizable and transparent to users (I think). I'm not sure I'm advocating for this change (or volunteering to implement before the release candidate), but I wanted to document the idea and get any feedback that is out there. This would fix the breakage we've seen without totally changing the kind system. Thanks, Richard PS: Due credit is to migmit for suggesting the type-class idea on glasgow-haskell-users. _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

1 0