- ghc-devs - Haskell.org

Status update on overloaded records work?
by Johan Tibell 16 Oct '13

16 Oct '13

Hi, I'm curious about the current status of the overloaded records work. Is the design the same as when the project started? Did we manage to keep the types simple? -- Johan

4 8

Re: Status update on overloaded records work?
by Adam Gundry 16 Oct '13

16 Oct '13

Hi Johan, all, Thanks for the interest in OverloadedRecordFields! I've been meaning to write a blog post on the current status, but you've beaten me to it. The extension is essentially finished, modulo a few minor issues that I need to work through, and should hit HEAD soon after 7.8 is cut. That will give us time to experiment with the feature before it goes public in 7.10. As AntC says, the wiki has more detail on the design. I've just updated it with some recent tweaks (thanks to Edward and Simon brainstorming at ICFP). You can also try out the prototype (which works in 7.6.3): https://github.com/adamgundry/records-prototype/blob/master/RecordsPrototyp… Adam On 16/10/13 07:19, Simon Peyton-Jones wrote: > Looping in Adam Gundry, who did the work! > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of AntC > | Sent: 15 October 2013 22:42 > | To: ghc-devs(a)haskell.org > | Subject: Re: Status update on overloaded records work? > | > | > Johan Tibell <johan.tibell@...> writes: > | > > | > I'm curious about the current status of the overloaded records work. > | > | Hi Johan, I think Adam has documented as he's gone along: > | http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Pla > | n > | (And that points to implementation notes.) > | > | I'll leave Adam/Simon to comment more fully, but from my point of view > | as > | an observer with some 'skin in the game' ... > | > | > Is the design the same as when the project started? > | > | No: > | - Higher-Ranked types can't be supported > | -- and SPJ's initial proposal put a lot of weight on them. > | There's an easy (IMO) work-round; > | but it does compromise backward compatibility. > | + Type changing update _is_ supported (with limits) > | I think that was a justified trade-off for H-R types. > | + Adam has been able to support Lenses. > | > | - (What I was hoping for but didn't get.) > | No compiler flag to suppress creating selector functions. > | This would have allowed records to be declared re-using the same > | name; > | but left it entirely to the developer as to how to access them. > | (I was trying to promote the TH and/or Lenses cottage industries.) > | > | > Did we manage to keep the types simple? > | > | I guess simplicity is in the eye of the beholder ;-) > | For 'gettable' fields, the sugar is as per SPJ's suggestion. > | There isn't sugar for updating. > | > | The un-sugared types are pretty gnarly. > | I suspect that'll mean obscure and confusing error messages. > | > | > | AntC -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Cabal-1.18.1.1 released
by Johan Tibell 16 Oct '13

16 Oct '13

I've released Cabal-1.18.1.1, which requires the fixes needed for the GHC 7.8 release. Please update the submodule to point to the Cabal-v1.18.1.1 tag. -- Johan

2 1

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