From mark.lentczner at gmail.com Sat Jan 4 21:35:48 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 4 Jan 2014 13:35:48 -0800 Subject: Who remembers HP 2013.4.0.0...? Message-ID: I do - I'm just a lame-o this cycle! Please review the status below - I'll have the 'prerelease' branch in github updated this weekend, and packages out (src tarball and Mac installers) out this coming week. - Mark *Resolved Issues* - fgl - haven't heard from Ivan, so we'll stay with the status quo. - aeson / dlist - log round'a'bout discussion resulted in decision to omit aeson this cycle. - alex / happy - I haven't heard from the maintainers on the major version bump, but they are both active here and so I'm assuming it is a go. *Current Proposed Versions* *GHC 7.6.3* -- same as last time (erroneously listed as a version bump last time) *Packages with no changes:* fgl, haskell-src, html, HUnit, mtl, parsec, QuickCheck, random, regex-base, regex-compat, regex-posix, split, stm, text, transformers, xhtml, zlib *Packages held back:* cgi: 3001.1.7.5 (3001.1.8.4* requires MonadCatchIO-mtl)* *Packages with minor version bumps:* HTTP: 4000.2.8 ? 4000.2.10 ? bump from prior 2013.4.0.0 list network: 2.4.1.2 ? 2.4.2.2 ? bump from prior 2013.4.0.0 list parallel: 3.2.0.3 ? 3.2.0.4 syb: 0.4.0 ? 0.4.1 unordered-containers: 0.2.3.0 ? 0.2.3.3 vector: 0.10.0.1 ? 0.10.9.1? primitive: 0.5.0.1 ? 0.5.1.0? *Packages with major version bumps:* case-insensitive: 1.0.0.1 ? 1.1.0.1 hashable: 1.1.2.5 ? 1.2.1.0 GLUT: 2.4.0.0 ? 2.5.0.1 GLURaw: 1.3.0.0 ? 1.4.0.0 OpenGL: 2.8.0.0 ? 2.9.1.0 OpenGLRaw: 1.3.0.0 ? 1.4.0.0 alex: 3.0.5 ? 3.1.0 *pending okay* happy: 1.18.10 ? 1.19.0 *pending okay* *Cabal:* Cabal: 1.16.0 ? 1.18.1.2 *consensus seems to be that this will be okay* cabal-install: 1.16.0.2 ? 1.18.0.2 *Platform Packagers:* This will be the last HP source release that contains all the ad hoc scripts for packaging. I canvased the group last time and as I recall, everyone said they just used the .cabal file - and no one used the scripts. I plan to replace them with a new tool built for the needs of the tarball release, and ditch this old set of scripts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at redivi.com Sat Jan 4 21:47:57 2014 From: bob at redivi.com (Bob Ippolito) Date: Sat, 4 Jan 2014 13:47:57 -0800 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: Great! I was hoping to hear an update about this soon :) Is there anything we can do to help? On Sat, Jan 4, 2014 at 1:35 PM, Mark Lentczner wrote: > I do - I'm just a lame-o this cycle! > > Please review the status below - I'll have the 'prerelease' branch in > github updated this weekend, and packages out (src tarball and Mac > installers) out this coming week. > > - Mark > > *Resolved Issues* > > - fgl - haven't heard from Ivan, so we'll stay with the status quo. > - aeson / dlist - log round'a'bout discussion resulted in decision to > omit aeson this cycle. > - alex / happy - I haven't heard from the maintainers on the major > version bump, but they are both active here and so I'm assuming it is a go. > > *Current Proposed Versions* > *GHC 7.6.3* -- same as last time (erroneously listed as a version bump > last time) > > *Packages with no changes:* > fgl, haskell-src, html, HUnit, > mtl, parsec, QuickCheck, random, > regex-base, regex-compat, regex-posix, > split, stm, text, transformers, > xhtml, zlib > > *Packages held back:* > cgi: 3001.1.7.5 (3001.1.8.4* requires MonadCatchIO-mtl)* > > *Packages with minor version bumps:* > HTTP: 4000.2.8 ? 4000.2.10 ? bump from prior 2013.4.0.0 list > network: 2.4.1.2 ? 2.4.2.2 ? bump from prior 2013.4.0.0 list > parallel: 3.2.0.3 ? 3.2.0.4 > syb: 0.4.0 ? 0.4.1 > unordered-containers: 0.2.3.0 ? 0.2.3.3 > vector: 0.10.0.1 ? 0.10.9.1? > primitive: 0.5.0.1 ? 0.5.1.0? > > *Packages with major version bumps:* > case-insensitive: 1.0.0.1 ? 1.1.0.1 > hashable: 1.1.2.5 ? 1.2.1.0 > > GLUT: 2.4.0.0 ? 2.5.0.1 > GLURaw: 1.3.0.0 ? 1.4.0.0 > OpenGL: 2.8.0.0 ? 2.9.1.0 > OpenGLRaw: 1.3.0.0 ? 1.4.0.0 > > alex: 3.0.5 ? 3.1.0 *pending okay* > happy: 1.18.10 ? 1.19.0 *pending okay* > > *Cabal:* > Cabal: 1.16.0 ? 1.18.1.2 *consensus seems to be that this will be > okay* > cabal-install: 1.16.0.2 ? 1.18.0.2 > > > *Platform Packagers:* > This will be the last HP source release that contains all the ad hoc > scripts for packaging. I canvased the group last time and as I recall, > everyone said they just used the .cabal file - and no one used the scripts. > I plan to replace them with a new tool built for the needs of the tarball > release, and ditch this old set of scripts. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Sat Jan 4 21:50:55 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Sat, 4 Jan 2014 22:50:55 +0100 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: Hi Mark, On Sat, Jan 4, 2014 at 10:35 PM, Mark Lentczner wrote: > I do - I'm just a lame-o this cycle! > > Please review the status below - I'll have the 'prerelease' branch in github > updated this weekend, and packages out (src tarball and Mac installers) out > this coming week. Regarding the Windows installer - I'm really busy right now, and will have time to work on it only in the second half of this month (after 17th January). Also, I think that the version number should be 2014.2.0.0. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From tim at blitzcode.net Sat Jan 4 23:20:19 2014 From: tim at blitzcode.net (Tim C. Schroeder) Date: Sun, 5 Jan 2014 00:20:19 +0100 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: Hello Mark, One of the major anticipated features of this HP release is the OS X 10.9 support. Since the GHC version won't change for this release, I assume that everybody is confident that 7.6.3 + a clang wrapper script is all that is required? I'm just a bit worried seeing bugs like this one: https://ghc.haskell.org/trac/ghc/ticket/8490 Would be a shame to get a HP release and then finding out that we'd really need a handful of fixes from 7.8 to get things fully working on 10.9. Also, regarding OS 10.6 64bit: https://ghc.haskell.org/trac/ghc/ticket/8094 https://ghc.haskell.org/trac/ghc/ticket/8511 The current HP page lists OS X 10.6 64bit + XCode 4.1 as a supported, but from what I can tell from my two machines this has been broken ever since HP 2012.2.0.0. I think at least the download page should be updated to reflect this. Thanks for the update and sorry if I'm just bringing up some points that have already been discussed / resolved. Cheers, Tim On Jan 4, 2014, at 10:35 PM, Mark Lentczner wrote: > I do - I'm just a lame-o this cycle! > > Please review the status below - I'll have the 'prerelease' branch in github updated this weekend, and packages out (src tarball and Mac installers) out this coming week. > > - Mark > > Resolved Issues > fgl - haven't heard from Ivan, so we'll stay with the status quo. > aeson / dlist - log round'a'bout discussion resulted in decision to omit aeson this cycle. > alex / happy - I haven't heard from the maintainers on the major version bump, but they are both active here and so I'm assuming it is a go. > Current Proposed Versions > GHC 7.6.3 -- same as last time (erroneously listed as a version bump last time) > > Packages with no changes: > fgl, haskell-src, html, HUnit, > mtl, parsec, QuickCheck, random, > regex-base, regex-compat, regex-posix, > split, stm, text, transformers, > xhtml, zlib > > Packages held back: > cgi: 3001.1.7.5 (3001.1.8.4 requires MonadCatchIO-mtl) > > Packages with minor version bumps: > HTTP: 4000.2.8 ? 4000.2.10 ? bump from prior 2013.4.0.0 list > network: 2.4.1.2 ? 2.4.2.2 ? bump from prior 2013.4.0.0 list > parallel: 3.2.0.3 ? 3.2.0.4 > syb: 0.4.0 ? 0.4.1 > unordered-containers: 0.2.3.0 ? 0.2.3.3 > vector: 0.10.0.1 ? 0.10.9.1? > primitive: 0.5.0.1 ? 0.5.1.0? > > Packages with major version bumps: > case-insensitive: 1.0.0.1 ? 1.1.0.1 > hashable: 1.1.2.5 ? 1.2.1.0 > > GLUT: 2.4.0.0 ? 2.5.0.1 > GLURaw: 1.3.0.0 ? 1.4.0.0 > OpenGL: 2.8.0.0 ? 2.9.1.0 > OpenGLRaw: 1.3.0.0 ? 1.4.0.0 > > alex: 3.0.5 ? 3.1.0 pending okay > happy: 1.18.10 ? 1.19.0 pending okay > > Cabal: > Cabal: 1.16.0 ? 1.18.1.2 consensus seems to be that this will be okay > cabal-install: 1.16.0.2 ? 1.18.0.2 > > > Platform Packagers: > This will be the last HP source release that contains all the ad hoc scripts for packaging. I canvased the group last time and as I recall, everyone said they just used the .cabal file - and no one used the scripts. I plan to replace them with a new tool built for the needs of the tarball release, and ditch this old set of scripts. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Jan 5 00:08:19 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 4 Jan 2014 16:08:19 -0800 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: The first bug is very hard to decipher how what that user is experiencing may or may not apply to how HP on a stock 10.9/Xcode 5 system will work. In particular that user is using homebrew and a homebrew installed gcc. As one side effect of homebrew is a whole new/different set of libs (for example, there is a well known issue with homebrew and iconv, and I've seen reports in other contexts than Haskell). The second two bugs are what they are. I'm don't see how we could do anything different in the packaging of HP to fix them... other than perhaps build GHC from scratch on my machine (rather than Ian's) - but still not sure that will fix the second one. - Mark ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Jan 5 00:10:15 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 4 Jan 2014 16:10:15 -0800 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: On Sat, Jan 4, 2014 at 2:41 PM, George Colpitts wrote: > Any reason why alex wouldn't be 3.1.3 and happy 1.19.2? > Nope, none at all. Bumped. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Jan 5 00:58:30 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 4 Jan 2014 19:58:30 -0500 Subject: hackage helpers!! Message-ID: hey all, isn't there supposed to be an ACLs level for hackage helpers? (ie folks who can force docbuilders to rebuild docs for packager, edit pkg info stuff, etc?) Am I correct in thinking no ones in that group yet? (i know duncan asked for volunteers, but I don't think anyone's been put in that group yet!) cheers! -Carter -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at blitzcode.net Sun Jan 5 07:35:41 2014 From: tim at blitzcode.net (Tim C. Schroeder) Date: Sun, 5 Jan 2014 08:35:41 +0100 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: Thanks for the clarifications! I just saw a number of 7.6.3 + 10.9 reports about linker issues and such popping up in the last few months and remember some work being done to backport a couple of fixes for a 7.6.4 release. If all will be fine with standard Apple Cmd Line Tools, that's great. I don't think the 10.6 64bit issue is a HP issue in any way. I also tied building my own GHC from source, it did nothing to resolve that crash. I only think it's problematic that the HP download page has been listing 10.6 + XCode 4.1 + GHC 64bit as a working combination when that stopped being the case quite some time ago. It does not seem like that bug will get fixed, so I was just suggesting to update the download page to recommend only the 32bit GHC for 10.6 users. Cheers, Tim On Jan 5, 2014, at 1:08 AM, Mark Lentczner wrote: > The first bug is very hard to decipher how what that user is experiencing may or may not apply to how HP on a stock 10.9/Xcode 5 system will work. In particular that user is using homebrew and a homebrew installed gcc. As one side effect of homebrew is a whole new/different set of libs (for example, there is a well known issue with homebrew and iconv, and I've seen reports in other contexts than Haskell). > > The second two bugs are what they are. I'm don't see how we could do anything different in the packaging of HP to fix them... other than perhaps build GHC from scratch on my machine (rather than Ian's) - but still not sure that will fix the second one. > > - Mark > ? From fuuzetsu at fuuzetsu.co.uk Sun Jan 5 10:15:31 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sun, 05 Jan 2014 10:15:31 +0000 Subject: Broken documentation on Hackage. Message-ID: <52C930C3.4080800@fuuzetsu.co.uk> Hi all, It seems that we are having a rather big issue with Hackage in recent months and I'm sure many of you have noticed: a lot of packages aren't getting their docs built. As far as I can tell, there can be multiple reasonable causes: * Dependencies fail to build so your package does * Your package fails to build directly * Your package requires non-cabal libraries which aren't installed * Your package requires different version of install libraries While all of these are understandable, there also seem to be problems with some packages which are seemingly perfectly fine otherwise. This problem is not new and has been reported[1]. There is even a system in place with Hackage 2 that would grant package owners to manually upload documentation and a system where some people (trustees and package maintainers) have the ability to do things like deleting the broken docs to have the builder try again[3] but it seems that this isn't actually used[4]. Over night I hacked up a quick program to parse some Hackage parts to see just how much stuff was broken. I have only considered the most recent package versions. Out of the 7761 packages, 811 came up with missing documentations. While it is a big number (~9.56%), it includes every package on Hackage. Next thing that follows is to restrict the search a bit. Only considering packages from 2013 and the still very young 2014, 210 are missing documentation. 140 of those were uploaded since August 2013 (around the Hackage 2 move). Remember that this is only for most recent versions on Hackage. Assuming that we didn't have a large spike in package uploads in second half of 2013 (I don't know, are there any charts or something?), that's unreasonably more than in the first half of 2013. It should be fairly clear that something is broken and I'd love to know what. I snooped around in #hackage today for a bit and there doesn't seem to be much sense of the urgency. Granted, people are busy but isn't this a pretty important issue? It's not like it's recent either. What can we do? Why isn't it fixed? Are there any suspects? Why isn't the trustee system being used to mitigate this problem a bit while it's being fixed? Is there any way to improve the amount of things that can be built by trying to work out any of the points at the top of this e-mail? Honestly, scrolling through the build logs of packages, all failures seem reasonable (Haddock parse failure, no dependencies installed?) and yet somehow I find myself having to click on older version of packages to get docs very often recently. What changed? Is there even anything to fix? Maybe I'm just getting unlucky with the packages I click on recently. I have uploaded the list of packages with missing documentation that have been uploaded on Hackage in 2013 and 2014 to [5]. The format is: (packageUrl, MissingDocs (Maybe reason) packageVersion dateUploaded). If your package is on there, you might want to consider uploading the docs by hand for now! Packages with ?Nothing? for a reason have no build log. See [6] for a reason for those. See [7] for how to view build logs yourself. PS: I'm unsure if these are the right lists to e-mail. I've been told that Cabal folk maintain Hackage issues and considering so many broken docs, libraries might also be interested in it. Feel free to point me elsewhere. PPS: There also seems to be a lot of 404 errors while trying to click on some docs on some older packages that probably existed in the past. Perhaps they were lost in the Hackage move or are a different issue all together. [1]: https://github.com/haskell/hackage-server/issues/145 [2]: https://github.com/haskell/hackage-server/issues/145#issuecomment-29468613 [3]: https://github.com/haskell/hackage-server/issues/145#issuecomment-29422332 [4]: http://hackage.haskell.org/packages/trustees/ [5]: http://fuuzetsu.co.uk/misc/sorted.txt [6]: https://github.com/haskell/hackage-server/issues/145#issuecomment-30129142 [7]: https://github.com/haskell/hackage-server/issues/145#issuecomment-29472445 -- Mateusz K. From svenpanne at gmail.com Sun Jan 5 14:04:56 2014 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 5 Jan 2014 15:04:56 +0100 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: 2014/1/4 Mark Lentczner : > [...] > GLUT: 2.4.0.0 ? 2.5.0.1 > [...] It would be nice to use 2.5.0.2 instead, the only changes (apart from a different Travis CI config) are slightly different dependencies in the .cabal file. These popped up when testing the GLUT package on Travis CI (https://travis-ci.org/haskell-opengl/GLUT). Another point: I am not sure if everybody is aware of the fact that building OpenGLRaw with clang will *not work*, and a wrapper won't help. The reason is that clang's -traditional behavior is fundamentally broken, see e.g. the recent discussion on ghc-devs and on https://github.com/haskell-opengl/OpenGLRaw/issues/18. We're in the same boat as imake and xrdb, and the clang people have not been very responsive about this long-known problem. From svenpanne at gmail.com Sun Jan 5 14:14:31 2014 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 5 Jan 2014 15:14:31 +0100 Subject: Broken documentation on Hackage. In-Reply-To: <52C930C3.4080800@fuuzetsu.co.uk> References: <52C930C3.4080800@fuuzetsu.co.uk> Message-ID: My ALUT package is among the ones without documentation, and I have a theory what's wrong (probably a missing installed C library/package libalut-dev, see https://github.com/haskell-openal/ALUT/blob/master/.travis.yml). Two questions: * As a package maintainer, how can I find out why the documentation is not built/published on Hackage? Logs, etc.? * Who should be contacted to polish the server a bit (i.e. install libalut-dev)? Currently things are very opaque from the outside, both from a technical and from an organizational point of view, and manually uploading documentation which is effectively guaranteed to be wrong/outdated/etc. sooner or later is not a solution IMHO. Cheers, S. From selinger at mathstat.dal.ca Sun Jan 5 18:15:01 2014 From: selinger at mathstat.dal.ca (Peter Selinger) Date: Sun, 5 Jan 2014 14:15:01 -0400 (AST) Subject: Broken documentation on Hackage. In-Reply-To: <52C930C3.4080800@fuuzetsu.co.uk> Message-ID: <20140105181501.D1D528C017C@chase.mathstat.dal.ca> I agree. Two of my packages are in your list: easyrender and newsynth (both have "Nothing" for a reason in your list). The problem for me is that, although you seem to have access to build logs, I don't. I have not found the way to access the hackage build logs for my packages or their documentation. Could you let me know where I can find them? For both packages, the documentation builds just fine on my local machine. It also builds fine in a virtual machine, under Windows and Ubuntu. Since I don't have access to Hackage's build logs, I cannot really figure out why the documentation is not building there. This is what has prevented me from fixing it. I even created "candidates" for the packages, before uploading the packages to the main index. Again, the documentation did not build, and again, I could not find any logs to tell me what went wrong. So the whole "candidate" mechanism has so far been useless to me. You mentioned that there is a way to upload the documentation manually. I'd love to do that. But how? I don't see any buttons or links on the package maintainer's pages that would allow me to do that. Any help appreciated, -- Peter Mateusz Kowalczyk wrote: > > Hi all, > > It seems that we are having a rather big issue with Hackage in recent > months and I'm sure many of you have noticed: a lot of packages aren't > getting their docs built. As far as I can tell, there can be multiple > reasonable causes: > > * Dependencies fail to build so your package does > * Your package fails to build directly > * Your package requires non-cabal libraries which aren't installed > * Your package requires different version of install libraries > > While all of these are understandable, there also seem to be problems > with some packages which are seemingly perfectly fine otherwise. This > problem is not new and has been reported[1]. There is even a system in > place with Hackage 2 that would grant package owners to manually upload > documentation and a system where some people (trustees and package > maintainers) have the ability to do things like deleting the broken docs > to have the builder try again[3] but it seems that this isn't actually > used[4]. > > Over night I hacked up a quick program to parse some Hackage parts to > see just how much stuff was broken. I have only considered the most > recent package versions. Out of the 7761 packages, 811 came up with > missing documentations. While it is a big number (~9.56%), it includes > every package on Hackage. Next thing that follows is to restrict the > search a bit. Only considering packages from 2013 and the still very > young 2014, 210 are missing documentation. 140 of those were uploaded > since August 2013 (around the Hackage 2 move). Remember that this is > only for most recent versions on Hackage. Assuming that we didn't have a > large spike in package uploads in second half of 2013 (I don't know, are > there any charts or something?), that's unreasonably more than in the > first half of 2013. > > It should be fairly clear that something is broken and I'd love to know > what. I snooped around in #hackage today for a bit and there doesn't > seem to be much sense of the urgency. Granted, people are busy but isn't > this a pretty important issue? It's not like it's recent either. > > What can we do? Why isn't it fixed? Are there any suspects? Why isn't > the trustee system being used to mitigate this problem a bit while it's > being fixed? Is there any way to improve the amount of things that can > be built by trying to work out any of the points at the top of this > e-mail? Honestly, scrolling through the build logs of packages, all > failures seem reasonable (Haddock parse failure, no dependencies > installed=85) and yet somehow I find myself having to click on older > version of packages to get docs very often recently. What changed? Is > there even anything to fix? Maybe I'm just getting unlucky with the > packages I click on recently. > > I have uploaded the list of packages with missing documentation that > have been uploaded on Hackage in 2013 and 2014 to [5]. The format is: > (packageUrl, MissingDocs (Maybe reason) packageVersion dateUploaded). If > your package is on there, you might want to consider uploading the docs > by hand for now! Packages with =91Nothing=92 for a reason have no build log. > See [6] for a reason for those. See [7] for how to view build logs yourself. > > PS: I'm unsure if these are the right lists to e-mail. I've been told > that Cabal folk maintain Hackage issues and considering so many broken > docs, libraries might also be interested in it. Feel free to point me > elsewhere. > PPS: There also seems to be a lot of 404 errors while trying to click on > some docs on some older packages that probably existed in the past. > Perhaps they were lost in the Hackage move or are a different issue all > together. > > [1]: https://github.com/haskell/hackage-server/issues/145 > [2]: > https://github.com/haskell/hackage-server/issues/145#issuecomment-29468613 > [3]: > https://github.com/haskell/hackage-server/issues/145#issuecomment-29422332 > [4]: http://hackage.haskell.org/packages/trustees/ > [5]: http://fuuzetsu.co.uk/misc/sorted.txt > [6]: > https://github.com/haskell/hackage-server/issues/145#issuecomment-30129142 > [7]: > https://github.com/haskell/hackage-server/issues/145#issuecomment-29472445 > -- = > > Mateusz K. > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > From fuuzetsu at fuuzetsu.co.uk Sun Jan 5 22:38:14 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sun, 05 Jan 2014 22:38:14 +0000 Subject: Broken documentation on Hackage. In-Reply-To: References: <52C930C3.4080800@fuuzetsu.co.uk> Message-ID: <52C9DED6.2080405@fuuzetsu.co.uk> On 05/01/14 14:14, Sven Panne wrote: > My ALUT package is among the ones without documentation, and I have a > theory what's wrong (probably a missing installed C library/package > libalut-dev, see > https://github.com/haskell-openal/ALUT/blob/master/.travis.yml). Two > questions: > > * As a package maintainer, how can I find out why the documentation > is not built/published on Hackage? Logs, etc.? I mention a link to a GitHub post in my opening post which outlines how to access the log. In case of ALUT, the build log is at [1] http://hackage.haskell.org/package/ALUT-2.3.0.1/reports/1/log and indeed a C library is missing. > * Who should be contacted to polish the server a bit (i.e. install > libalut-dev)? No idea, but I'd love to find out myself! I'm just a disgruntled Hackage user myself. > Currently things are very opaque from the outside, both from a > technical and from an organizational point of view, and manually > uploading documentation which is effectively guaranteed to be > wrong/outdated/etc. sooner or later is not a solution IMHO. You would be uploading documentation for a specific package version. So for example, if you upload something for ALUT 2.3.0.1 and later upload upload ALUT 2.4, either the docs will be built fine (which would be ideal) or you will have to upload them yourself again for that version. I agree that this is subpar but I think it's better than nothing. There should really be a ?upload documentation? button on the site or maybe even a Cabal flag or maybe even ability to bundle documentation in the package tarball when uploading it, to act as a fallback if package fails to build. I suppose this is something that has to be discussed. Ideally, it should just work. > > Cheers, > S. > [1]: http://hackage.haskell.org/package/ALUT-2.3.0.1/reports/1/log -- Mateusz K. From fuuzetsu at fuuzetsu.co.uk Sun Jan 5 23:18:33 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sun, 05 Jan 2014 23:18:33 +0000 Subject: Broken documentation on Hackage. In-Reply-To: <20140105181501.D1D528C017C@chase.mathstat.dal.ca> References: <20140105181501.D1D528C017C@chase.mathstat.dal.ca> Message-ID: <52C9E849.4080400@fuuzetsu.co.uk> On 05/01/14 18:15, Peter Selinger wrote: > I agree. Two of my packages are in your list: easyrender and newsynth > (both have "Nothing" for a reason in your list). If a package has Nothing for a reason, that means that no build log is available. From what I've read yesterday, it's a problem with their report system and I think it happens when cabal can't find dependency candidates for your package. I link to a comment on GitHub in my opening post which explains this. > The problem for me is that, although you seem to have access to build > logs, I don't. I have not found the way to access the hackage build > logs for my packages or their documentation. Could you let me know > where I can find them? I do not have any special access to Hackage, I didn't even log in. See my opening post for how to access the build log or see my reply to Sven for an example. I really think there should be a button on the site for this. If the build logs existed for newsynth, you could do the following: check general build status[1] then check the first report[2] then check the build log for the first report[3]. If the build status is empty, you won't have any reports. Check out [4][5][6] for an example on a package which failed to build and has logs. Effectively, the Nothing in my ?report? indicates no build status. > For both packages, the documentation builds just fine on my local > machine. It also builds fine in a virtual machine, under Windows and > Ubuntu. Since I don't have access to Hackage's build logs, I cannot > really figure out why the documentation is not building there. This is > what has prevented me from fixing it. I suspect Hackage fails to resolve your dependencies, at least that what seems to be causing no logs. See [7] for a comment and [8] for an existing GitHub issue (although one without any activity). > I even created "candidates" for the packages, before uploading the > packages to the main index. Again, the documentation did not build, > and again, I could not find any logs to tell me what went wrong. So > the whole "candidate" mechanism has so far been useless to me. > > You mentioned that there is a way to upload the documentation > manually. I'd love to do that. But how? I don't see any buttons or > links on the package maintainer's pages that would allow me to do > that. I post a link in my opening post to a comment about this. See [9]. I just tried to do it for one of my packages (yi-monokai-0.1.1.1) and here are the steps I took: 1. cd ~/programming/yi-monokai 2. cabal configure && cabal build && cabal haddock --hyperlink-source 3. cd dist/doc 4. mv yi-monokai yi-monokai-0.1.1.1-docs 5. tar -c -v -z -Hustar -f yi-monokai-0.1.1.1-docs.tar.gz yi-monokai-0.1.1.1-docs 6. curl -X PUT -H 'Content-Type: application/x-tar' -H 'Content-Encoding: gzip' --data-binary '@yi-monokai-0.1.1.1-docs.tar.gz' 'http://USERNAME:PASSWORD at hackage.haskell.org/package/yi-monokai-0.1.1.1/docs' With these steps, my little package now has documentation. There's some info on format at [10]. I might write a small blog post outlining these steps later as it was not easy to figure out. > Any help appreciated, -- Peter [1]: http://hackage.haskell.org/package/newsynth-0.1.0.0/reports/ [2]: http://hackage.haskell.org/package/newsynth-0.1.0.0/reports/1 [3]: http://hackage.haskell.org/package/newsynth-0.1.0.0/reports/1/log [4]: http://hackage.haskell.org/package/yi-monokai-0.1.1.1/reports/ [5]: http://hackage.haskell.org/package/yi-monokai-0.1.1.1/reports/1 [6]: http://hackage.haskell.org/package/yi-monokai-0.1.1.1/reports/1/log [7]: https://github.com/haskell/hackage-server/issues/145#issuecomment-30129142 [8]: https://github.com/haskell/hackage-server/issues/142 [9]: https://github.com/haskell/hackage-server/issues/145#issuecomment-29468613 [10]: https://github.com/haskell/hackage-server/issues/56 -- Mateusz K. From mark.lentczner at gmail.com Mon Jan 6 05:35:37 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 5 Jan 2014 21:35:37 -0800 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: Okay - the pre-release branch has been updated. Please check that haskell-platform.cabal and see if it makes sense to you! https://github.com/haskell/haskell-platform/blob/pre-release/haskell-platform.cabal - Mark ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Mon Jan 6 06:11:03 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon, 6 Jan 2014 07:11:03 +0100 Subject: Win32-2.3.0.0 not on Hackage Message-ID: Hi all, I've noticed that Win32-2.3.0.0 (that ships with GHC 7.6.3) is not on Hackage, even though the previous versions are. Can someone who has the appropriate permissions please upload it? The 2.3.0.0 version corresponds to the current state of the ghc-7.6 branch in the source repository [1]. [1] http://git.haskell.org/packages/Win32.git -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From the.dead.shall.rise at gmail.com Mon Jan 6 06:25:50 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon, 6 Jan 2014 07:25:50 +0100 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: Hi Mark, On Mon, Jan 6, 2014 at 6:35 AM, Mark Lentczner wrote: > Okay - the pre-release branch has been updated. Please check that > haskell-platform.cabal and see if it makes sense to you! > > https://github.com/haskell/haskell-platform/blob/pre-release/haskell-platform.cabal Shouldn't async be bumped to 2.0.1.5? Also, is there a reason we're using text-0.11.3.1 instead of 1.0.0.1? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From mark.lentczner at gmail.com Mon Jan 6 07:33:38 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 5 Jan 2014 23:33:38 -0800 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: only change in async 2.0.1.5 was: "Bump base dependencies for GHC 7.8" -- not quite relevant text bumpd to 1.0.0.[01] after I had made that list. Seems like a good call to bump it. - Mark ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Mon Jan 6 10:25:15 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 06 Jan 2014 11:25:15 +0100 Subject: Win32-2.3.0.0 not on Hackage In-Reply-To: (Mikhail Glushenkov's message of "Mon, 6 Jan 2014 07:11:03 +0100") References: Message-ID: <87eh4le7as.fsf@gnu.org> Hi, On 2014-01-06 at 07:11:03 +0100, Mikhail Glushenkov wrote: > I've noticed that Win32-2.3.0.0 (that ships with GHC 7.6.3) is not on > Hackage, even though the previous versions are. Can someone who has > the appropriate permissions please upload it? The 2.3.0.0 version > corresponds to the current state of the ghc-7.6 branch in the source > repository [1]. > > [1] http://git.haskell.org/packages/Win32.git related (and to be closed once this is fixed): https://github.com/haskell/win32/issues/12 From malcolm.wallace at me.com Mon Jan 6 10:27:21 2014 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Mon, 06 Jan 2014 10:27:21 +0000 Subject: Broken documentation on Hackage. In-Reply-To: <52C930C3.4080800@fuuzetsu.co.uk> References: <52C930C3.4080800@fuuzetsu.co.uk> Message-ID: On 5 Jan 2014, at 10:15, Mateusz Kowalczyk wrote: > It seems that we are having a rather big issue with Hackage in recent > months and I'm sure many of you have noticed: a lot of packages aren't > getting their docs built. As far as I can tell, there can be multiple > reasonable causes: > > * Dependencies fail to build so your package does > * Your package fails to build directly > * Your package requires non-cabal libraries which aren't installed > * Your package requires different version of install libraries I think the fundamental problem is that Haddock is now built on top of ghc. So if a package cannot be built by ghc (for whatever reason, e.g. missing C library dependency), then it cannot be documented either. This is a good deal less than useful. A documentation generator ought to do a reasonable job, even if the code it is looking at is technically not-compilable. At work, we have a stand-alone documentation generator for Haskell, which requires no compiler. Haddock also was once stand-alone. I think it might be time to wind the clock backwards and retrieve this desirable property. Regards, Malcolm From hvr at gnu.org Mon Jan 6 10:33:20 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 06 Jan 2014 11:33:20 +0100 Subject: Win32 maintainership (was: Win32-2.3.0.0 not on Hackage) In-Reply-To: <87eh4le7as.fsf@gnu.org> (Herbert Valerio Riedel's message of "Mon, 06 Jan 2014 11:25:15 +0100") References: <87eh4le7as.fsf@gnu.org> Message-ID: <87a9f9e6xb.fsf_-_@gnu.org> Hello Bryan, I see you're listed as maintainer for win32, I understand you're quite busy these days, but win32 seems to be piling up issue reports and pull requests and the package seems a bit under-maintainer judging from the commit history. Do you still consider yourself the maintainer for win32? Cheers, hvr On 2014-01-06 at 11:25:15 +0100, Herbert Valerio Riedel wrote: > On 2014-01-06 at 07:11:03 +0100, Mikhail Glushenkov wrote: >> I've noticed that Win32-2.3.0.0 (that ships with GHC 7.6.3) is not on >> Hackage, even though the previous versions are. Can someone who has >> the appropriate permissions please upload it? The 2.3.0.0 version >> corresponds to the current state of the ghc-7.6 branch in the source >> repository [1]. >> >> [1] http://git.haskell.org/packages/Win32.git > > related (and to be closed once this is fixed): > > https://github.com/haskell/win32/issues/12 From schlepptop at henning-thielemann.de Mon Jan 6 10:51:47 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 06 Jan 2014 11:51:47 +0100 Subject: Broken documentation on Hackage. In-Reply-To: References: <52C930C3.4080800@fuuzetsu.co.uk> Message-ID: <52CA8AC3.1020508@henning-thielemann.de> Am 06.01.2014 11:27, schrieb Malcolm Wallace: > I think the fundamental problem is that Haddock is now built on top of ghc. So if a package cannot be built by ghc (for whatever reason, e.g. missing C library dependency), then it cannot be documented either. This is a good deal less than useful. A documentation generator ought to do a reasonable job, even if the code it is looking at is technically not-compilable. > > At work, we have a stand-alone documentation generator for Haskell, which requires no compiler. Haddock also was once stand-alone. I think it might be time to wind the clock backwards and retrieve this desirable property. I think the clean solution would be a real "GHC as a collection of libraries" instead of "GHCi as a library". Then haddock could use the GHC parser without its type checker etc. for documentation purposes. The haskell-suite might become the project to fill that gap. It might still be difficult to generate docs in the presence of module re-exports, type class instances, missing type signatures, template haskell etc. From Christian.Maeder at dfki.de Mon Jan 6 11:29:36 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon, 06 Jan 2014 12:29:36 +0100 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: Message-ID: <52CA93A0.5060900@dfki.de> Hi, I would propose to update to the latest text-1.0.0.1 version and other packages depending on it (ie. parsec-3.1.4) (A name containing 2014 would make more sense to me.) Cheers Christian Am 04.01.2014 22:35, schrieb Mark Lentczner: > I do - I'm just a lame-o this cycle! > > Please review the status below - I'll have the 'prerelease' branch in > github updated this weekend, and packages out (src tarball and Mac > installers) out this coming week. > > - Mark > > *Resolved Issues* > > * fgl - haven't heard from Ivan, so we'll stay with the status quo. > * aeson / dlist - log round'a'bout discussion resulted in decision to > omit aeson this cycle. > * alex / happy - I haven't heard from the maintainers on the major > version bump, but they are both active here and so I'm assuming it > is a go. > > *Current Proposed Versions* > *GHC 7.6.3* -- same as last time (erroneously listed as a version bump > last time) > > *Packages with no changes:* > fgl, haskell-src, html, HUnit, > mtl, parsec, QuickCheck, random, > regex-base, regex-compat, regex-posix, > split, stm, text, transformers, > xhtml, zlib > * > * > *Packages held back:* > cgi: 3001.1.7.5 (3001.1.8.4/ requires MonadCatchIO-mtl)/ > > *Packages with minor version bumps:* > HTTP: 4000.2.8 ? 4000.2.10? bump from prior 2013.4.0.0 list > network: 2.4.1.2 ? 2.4.2.2? bump from prior 2013.4.0.0 list > parallel: 3.2.0.3 ? 3.2.0.4 > syb: 0.4.0 ? 0.4.1 > unordered-containers: 0.2.3.0 ? 0.2.3.3 > vector: 0.10.0.1 ? 0.10.9.1? > primitive: 0.5.0.1 ? 0.5.1.0? > * > * > *Packages with major version bumps:* > case-insensitive: 1.0.0.1 ? 1.1.0.1 > hashable: 1.1.2.5 ? 1.2.1.0 > > GLUT: 2.4.0.0 ? 2.5.0.1 > GLURaw: 1.3.0.0 ? 1.4.0.0 > OpenGL: 2.8.0.0 ? 2.9.1.0 > OpenGLRaw: 1.3.0.0 ? 1.4.0.0 > > alex: 3.0.5 ? 3.1.0 /pending okay/ > happy: 1.18.10 ? 1.19.0 /pending okay/ > > *Cabal:* > Cabal: 1.16.0 ? 1.18.1.2 /consensus seems to be that this will > be okay/ > cabal-install: 1.16.0.2 ? 1.18.0.2 > > > *Platform Packagers:* > This will be the last HP source release that contains all the ad hoc > scripts for packaging. I canvased the group last time and as I recall, > everyone said they just used the .cabal file - and no one used the > scripts. I plan to replace them with a new tool built for the needs of > the tarball release, and ditch this old set of scripts. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From fuuzetsu at fuuzetsu.co.uk Mon Jan 6 11:59:35 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 06 Jan 2014 11:59:35 +0000 Subject: Broken documentation on Hackage. In-Reply-To: References: <52C930C3.4080800@fuuzetsu.co.uk> Message-ID: <52CA9AA7.6020604@fuuzetsu.co.uk> On 06/01/14 10:27, Malcolm Wallace wrote: > > On 5 Jan 2014, at 10:15, Mateusz Kowalczyk wrote: > >> It seems that we are having a rather big issue with Hackage in recent >> months and I'm sure many of you have noticed: a lot of packages aren't >> getting their docs built. As far as I can tell, there can be multiple >> reasonable causes: >> >> * Dependencies fail to build so your package does >> * Your package fails to build directly >> * Your package requires non-cabal libraries which aren't installed >> * Your package requires different version of install libraries > > I think the fundamental problem is that Haddock is now built on top of ghc. So if a package cannot be built by ghc (for whatever reason, e.g. missing C library dependency), then it cannot be documented either. This is a good deal less than useful. A documentation generator ought to do a reasonable job, even if the code it is looking at is technically not-compilable. It is because it uses GHC to type check the modules and generate the signatures. I agree that there should be some kind of fall back but it would be a great deal less useful of an output. > At work, we have a stand-alone documentation generator for Haskell, which requires no compiler. Haddock also was once stand-alone. I think it might be time to wind the clock backwards and retrieve this desirable property. Was Haddock ever stand alone? AFAIK it used to be part of GHC and then David Waern separated it into a separate package. I honestly can't think of how it would ever have been stand-alone (that is not relying on GHC to do part of the work). > > Regards, > Malcolm > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Mateusz K. From schlepptop at henning-thielemann.de Mon Jan 6 12:32:06 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 06 Jan 2014 13:32:06 +0100 Subject: Broken documentation on Hackage. In-Reply-To: <52CA9AA7.6020604@fuuzetsu.co.uk> References: <52C930C3.4080800@fuuzetsu.co.uk> <52CA9AA7.6020604@fuuzetsu.co.uk> Message-ID: <52CAA246.3080806@henning-thielemann.de> Am 06.01.2014 12:59, schrieb Mateusz Kowalczyk: > On 06/01/14 10:27, Malcolm Wallace wrote: >> >> At work, we have a stand-alone documentation generator for Haskell, which requires no compiler. Haddock also was once stand-alone. I think it might be time to wind the clock backwards and retrieve this desirable property. > > Was Haddock ever stand alone? AFAIK it used to be part of GHC and then > David Waern separated it into a separate package. I honestly can't think > of how it would ever have been stand-alone (that is not relying on GHC > to do part of the work). The versions with leading zero by Simon Marlow used a custom parser. http://hackage.haskell.org/package/haddock-0.8 From malcolm.wallace at me.com Mon Jan 6 13:46:22 2014 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Mon, 06 Jan 2014 13:46:22 +0000 Subject: Broken documentation on Hackage. In-Reply-To: <52CAA246.3080806@henning-thielemann.de> References: <52C930C3.4080800@fuuzetsu.co.uk> <52CA9AA7.6020604@fuuzetsu.co.uk> <52CAA246.3080806@henning-thielemann.de> Message-ID: <731AB412-609C-4838-871E-9217B7754A4E@me.com> On 6 Jan 2014, at 12:32, Henning Thielemann wrote: > Am 06.01.2014 12:59, schrieb Mateusz Kowalczyk: >> On 06/01/14 10:27, Malcolm Wallace wrote: >>> >>> Haddock also was once stand-alone. I think it might be time to wind the clock backwards and retrieve this desirable property. >> >> Was Haddock ever stand alone? AFAIK it used to be part of GHC and then >> David Waern separated it into a separate package. > > The versions with leading zero by Simon Marlow used a custom parser. Yes, early versions of Haddock assumed that the developer would always write a type signature for any top-level value that is exported. No need to rely on a compiler to infer a type. Although inference is hugely useful, I think the discipline of actually writing down what the compiler infers for you is an absolutely essential software engineering practice. It is one good step towards future maintainability of the library. At my workplace, for instance, our git repo infrastructure is configured to reject any code that exports a value without an explicit type signature. Regards, Malcolm From allbery.b at gmail.com Mon Jan 6 14:33:19 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 6 Jan 2014 09:33:19 -0500 Subject: Broken documentation on Hackage. In-Reply-To: References: <52C930C3.4080800@fuuzetsu.co.uk> Message-ID: On Mon, Jan 6, 2014 at 5:27 AM, Malcolm Wallace wrote: > > I think the fundamental problem is that Haddock is now built on top of > ghc. So if a package cannot be built by ghc (for whatever reason, e.g. > missing C library dependency), then it cannot be documented either. This > is a good deal less than useful. A documentation generator ought to do a > reasonable job, even if the code it is looking at is technically > not-compilable. > > At work, we have a stand-alone documentation generator for Haskell, which > requires no compiler. Haddock also was once stand-alone. I think it might > be time to wind the clock backwards and retrieve this desirable property. > The problem with that was you didn't get documentation if you used any GHC extension added within the past year or so. You can't win.... -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Mon Jan 6 15:38:59 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 6 Jan 2014 16:38:59 +0100 Subject: Broken documentation on Hackage. In-Reply-To: References: <52C930C3.4080800@fuuzetsu.co.uk> Message-ID: On Mon, Jan 6, 2014 at 3:33 PM, Brandon Allbery wrote: > On Mon, Jan 6, 2014 at 5:27 AM, Malcolm Wallace wrote: >> >> I think the fundamental problem is that Haddock is now built on top of >> ghc. So if a package cannot be built by ghc (for whatever reason, e.g. >> missing C library dependency), then it cannot be documented either. This >> is a good deal less than useful. A documentation generator ought to do a >> reasonable job, even if the code it is looking at is technically >> not-compilable. >> >> At work, we have a stand-alone documentation generator for Haskell, which >> requires no compiler. Haddock also was once stand-alone. I think it might >> be time to wind the clock backwards and retrieve this desirable property. >> > > The problem with that was you didn't get documentation if you used any GHC > extension added within the past year or so. You can't win.... > This problem keeps popping up in our various tooling efforts so I thought it'd be worth pointing out that the general problem has been discussed in a paper. Martin Odersky touched on the more general problem of trying to have two * complete (e.g. supporting all extensions in our case) and * identically behaving implementations of the same compiler (or part of a compiler in our case) in the Scalable Component Abstractions paper [1]. It is very difficult and requires a huge amount of work. The Scala solution is the cake pattern which lets the Scala compiler expose itself as two different APIs, used for two different purposes (in their case the compiler proper and a reflection API). Even if relying on the GHC API is a bit of a pain, it's better than relying on a subtly different implementation that supports some subset of the features. 1. http://lampwww.epfl.ch/~odersky/papers/ScalableComponent.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Jan 6 16:20:18 2014 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 6 Jan 2014 17:20:18 +0100 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: <52CA93A0.5060900@dfki.de> References: <52CA93A0.5060900@dfki.de> Message-ID: Not really related to the version discussion in this thread, but a good time for a reminder when building the Windows installer: http://trac.haskell.org/haskell-platform/ticket/226 (Ancient glut32.dll bundled with the Haskell platform) is still open... From the.dead.shall.rise at gmail.com Mon Jan 6 18:48:14 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon, 6 Jan 2014 19:48:14 +0100 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: <52CA93A0.5060900@dfki.de> Message-ID: Hi, On Mon, Jan 6, 2014 at 5:20 PM, Sven Panne wrote: > Not really related to the version discussion in this thread, but a > good time for a reminder when building the Windows installer: > http://trac.haskell.org/haskell-platform/ticket/226 (Ancient > glut32.dll bundled with the Haskell platform) is still open... Yes, I remember about this. It's still open because: a) There was no new HP release during this period and so no need to update the installer. b) I can't access my haskell-platform trac account. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From selinger at mathstat.dal.ca Mon Jan 6 20:00:55 2014 From: selinger at mathstat.dal.ca (Peter Selinger) Date: Mon, 6 Jan 2014 16:00:55 -0400 (AST) Subject: Broken documentation on Hackage. In-Reply-To: <52C9E849.4080400@fuuzetsu.co.uk> Message-ID: <20140106200056.06D1D8C017C@chase.mathstat.dal.ca> Thank you, this worked like a charm! (Modulo using dist/doc/html instead of dist/doc). Now all my packages have online documentation. One day I'd still like to find out why it didn't build automatically. But as long as documentation builder doesn't generate a log saying what problem it thought could not be solved, there is no way of knowing really. Thanks again, -- Peter Mateusz Kowalczyk wrote: > > On 05/01/14 18:15, Peter Selinger wrote: > > I agree. Two of my packages are in your list: easyrender and newsynth > > (both have "Nothing" for a reason in your list). > > If a package has Nothing for a reason, that means that no build log is > available. From what I've read yesterday, it's a problem with their > report system and I think it happens when cabal can't find > dependency candidates for your package. I link to a comment on GitHub > in my opening post which explains this. > > > The problem for me is that, although you seem to have access to build > > logs, I don't. I have not found the way to access the hackage build > > logs for my packages or their documentation. Could you let me know > > where I can find them? > > I do not have any special access to Hackage, I didn't even log in. See > my opening post for how to access the build log or see my reply to > Sven for an example. I really think there should be a button on the > site for this. If the build logs existed for newsynth, you could do > the following: check general build status[1] then check the first > report[2] then check the build log for the first report[3]. If the > build status is empty, you won't have any reports. > > Check out [4][5][6] for an example on a package which failed to build > and has logs. > > Effectively, the Nothing in my ?report? indicates no build status. > > > For both packages, the documentation builds just fine on my local > > machine. It also builds fine in a virtual machine, under Windows and > > Ubuntu. Since I don't have access to Hackage's build logs, I cannot > > really figure out why the documentation is not building there. This is > > what has prevented me from fixing it. > > I suspect Hackage fails to resolve your dependencies, at least that > what seems to be causing no logs. See [7] for a comment and [8] for an > existing GitHub issue (although one without any activity). > > > I even created "candidates" for the packages, before uploading the > > packages to the main index. Again, the documentation did not build, > > and again, I could not find any logs to tell me what went wrong. So > > the whole "candidate" mechanism has so far been useless to me. > > > > You mentioned that there is a way to upload the documentation > > manually. I'd love to do that. But how? I don't see any buttons or > > links on the package maintainer's pages that would allow me to do > > that. > > I post a link in my opening post to a comment about this. See [9]. > I just tried to do it for one of my packages (yi-monokai-0.1.1.1) and > here are the steps I took: > > 1. cd ~/programming/yi-monokai > 2. cabal configure && cabal build && cabal haddock --hyperlink-source > 3. cd dist/doc > 4. mv yi-monokai yi-monokai-0.1.1.1-docs > 5. tar -c -v -z -Hustar -f yi-monokai-0.1.1.1-docs.tar.gz > yi-monokai-0.1.1.1-docs > 6. curl -X PUT -H 'Content-Type: application/x-tar' -H > 'Content-Encoding: gzip' --data-binary > '@yi-monokai-0.1.1.1-docs.tar.gz' > 'http://USERNAME:PASSWORD at hackage.haskell.org/package/yi-monokai-0.1.1.1/docs' > > With these steps, my little package now has documentation. There's > some info on format at [10]. I might write a small blog post outlining > these steps later as it was not easy to figure out. > > > Any help appreciated, -- Peter > > [1]: http://hackage.haskell.org/package/newsynth-0.1.0.0/reports/ > [2]: http://hackage.haskell.org/package/newsynth-0.1.0.0/reports/1 > [3]: http://hackage.haskell.org/package/newsynth-0.1.0.0/reports/1/log > [4]: http://hackage.haskell.org/package/yi-monokai-0.1.1.1/reports/ > [5]: http://hackage.haskell.org/package/yi-monokai-0.1.1.1/reports/1 > [6]: > http://hackage.haskell.org/package/yi-monokai-0.1.1.1/reports/1/log > [7]: > https://github.com/haskell/hackage-server/issues/145#issuecomment-30129142 > [8]: https://github.com/haskell/hackage-server/issues/142 > [9]: > https://github.com/haskell/hackage-server/issues/145#issuecomment-29468613 > [10]: https://github.com/haskell/hackage-server/issues/56 > -- > Mateusz K. > From carter.schonwald at gmail.com Mon Jan 6 20:25:29 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 6 Jan 2014 15:25:29 -0500 Subject: Broken documentation on Hackage. In-Reply-To: <20140106200056.06D1D8C017C@chase.mathstat.dal.ca> References: <52C9E849.4080400@fuuzetsu.co.uk> <20140106200056.06D1D8C017C@chase.mathstat.dal.ca> Message-ID: i'm sure patches are welcome to improve hackage infrastructure in these ways! :) On Mon, Jan 6, 2014 at 3:00 PM, Peter Selinger wrote: > Thank you, this worked like a charm! (Modulo using dist/doc/html > instead of dist/doc). Now all my packages have online documentation. > > One day I'd still like to find out why it didn't build automatically. > But as long as documentation builder doesn't generate a log saying > what problem it thought could not be solved, there is no way of > knowing really. > > Thanks again, -- Peter > > Mateusz Kowalczyk wrote: > > > > On 05/01/14 18:15, Peter Selinger wrote: > > > I agree. Two of my packages are in your list: easyrender and newsynth > > > (both have "Nothing" for a reason in your list). > > > > If a package has Nothing for a reason, that means that no build log is > > available. From what I've read yesterday, it's a problem with their > > report system and I think it happens when cabal can't find > > dependency candidates for your package. I link to a comment on GitHub > > in my opening post which explains this. > > > > > The problem for me is that, although you seem to have access to build > > > logs, I don't. I have not found the way to access the hackage build > > > logs for my packages or their documentation. Could you let me know > > > where I can find them? > > > > I do not have any special access to Hackage, I didn't even log in. See > > my opening post for how to access the build log or see my reply to > > Sven for an example. I really think there should be a button on the > > site for this. If the build logs existed for newsynth, you could do > > the following: check general build status[1] then check the first > > report[2] then check the build log for the first report[3]. If the > > build status is empty, you won't have any reports. > > > > Check out [4][5][6] for an example on a package which failed to build > > and has logs. > > > > Effectively, the Nothing in my ?report? indicates no build status. > > > > > For both packages, the documentation builds just fine on my local > > > machine. It also builds fine in a virtual machine, under Windows and > > > Ubuntu. Since I don't have access to Hackage's build logs, I cannot > > > really figure out why the documentation is not building there. This is > > > what has prevented me from fixing it. > > > > I suspect Hackage fails to resolve your dependencies, at least that > > what seems to be causing no logs. See [7] for a comment and [8] for an > > existing GitHub issue (although one without any activity). > > > > > I even created "candidates" for the packages, before uploading the > > > packages to the main index. Again, the documentation did not build, > > > and again, I could not find any logs to tell me what went wrong. So > > > the whole "candidate" mechanism has so far been useless to me. > > > > > > You mentioned that there is a way to upload the documentation > > > manually. I'd love to do that. But how? I don't see any buttons or > > > links on the package maintainer's pages that would allow me to do > > > that. > > > > I post a link in my opening post to a comment about this. See [9]. > > I just tried to do it for one of my packages (yi-monokai-0.1.1.1) and > > here are the steps I took: > > > > 1. cd ~/programming/yi-monokai > > 2. cabal configure && cabal build && cabal haddock --hyperlink-source > > 3. cd dist/doc > > 4. mv yi-monokai yi-monokai-0.1.1.1-docs > > 5. tar -c -v -z -Hustar -f yi-monokai-0.1.1.1-docs.tar.gz > > yi-monokai-0.1.1.1-docs > > 6. curl -X PUT -H 'Content-Type: application/x-tar' -H > > 'Content-Encoding: gzip' --data-binary > > '@yi-monokai-0.1.1.1-docs.tar.gz' > > ' > http://USERNAME:PASSWORD at hackage.haskell.org/package/yi-monokai-0.1.1.1/docs > ' > > > > With these steps, my little package now has documentation. There's > > some info on format at [10]. I might write a small blog post outlining > > these steps later as it was not easy to figure out. > > > > > Any help appreciated, -- Peter > > > > [1]: http://hackage.haskell.org/package/newsynth-0.1.0.0/reports/ > > [2]: http://hackage.haskell.org/package/newsynth-0.1.0.0/reports/1 > > [3]: http://hackage.haskell.org/package/newsynth-0.1.0.0/reports/1/log > > [4]: http://hackage.haskell.org/package/yi-monokai-0.1.1.1/reports/ > > [5]: http://hackage.haskell.org/package/yi-monokai-0.1.1.1/reports/1 > > [6]: > > http://hackage.haskell.org/package/yi-monokai-0.1.1.1/reports/1/log > > [7]: > > > https://github.com/haskell/hackage-server/issues/145#issuecomment-30129142 > > [8]: https://github.com/haskell/hackage-server/issues/142 > > [9]: > > > https://github.com/haskell/hackage-server/issues/145#issuecomment-29468613 > > [10]: https://github.com/haskell/hackage-server/issues/56 > > -- > > Mateusz K. > > > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bos at serpentine.com Mon Jan 6 22:54:20 2014 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon, 6 Jan 2014 14:54:20 -0800 Subject: Win32 maintainership (was: Win32-2.3.0.0 not on Hackage) In-Reply-To: <87a9f9e6xb.fsf_-_@gnu.org> References: <87eh4le7as.fsf@gnu.org> <87a9f9e6xb.fsf_-_@gnu.org> Message-ID: On Mon, Jan 6, 2014 at 2:33 AM, Herbert Valerio Riedel wrote: > I see you're listed as maintainer for win32, I understand you're quite > busy these days, but win32 seems to be piling up issue reports and pull > requests and the package seems a bit under-maintainer judging from the > commit history. Do you still consider yourself the maintainer for win32? > Would you believe that for some reason, I wasn't getting any notifications of activity on the win32 github repo. I just fixed that, and now that I know that there's a backlog, I'll start working through it. That said, if someone else wants to jump in too, or instead of me, have at it :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Mon Jan 6 22:55:29 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 06 Jan 2014 22:55:29 +0000 Subject: Broken documentation on Hackage. In-Reply-To: <52C930C3.4080800@fuuzetsu.co.uk> References: <52C930C3.4080800@fuuzetsu.co.uk> Message-ID: <52CB3461.2020101@fuuzetsu.co.uk> On 05/01/14 10:15, Mateusz Kowalczyk wrote: > Hi all, > > It seems that we are having a rather big issue with Hackage in recent > months and I'm sure many of you have noticed: a lot of packages aren't > getting their docs built. As far as I can tell, there can be multiple > reasonable causes: > > [snip] > > [1]: https://github.com/haskell/hackage-server/issues/145 > [2]: > https://github.com/haskell/hackage-server/issues/145#issuecomment-29468613 > [3]: > https://github.com/haskell/hackage-server/issues/145#issuecomment-29422332 > [4]: http://hackage.haskell.org/packages/trustees/ > [5]: http://fuuzetsu.co.uk/misc/sorted.txt > [6]: > https://github.com/haskell/hackage-server/issues/145#issuecomment-30129142 > [7]: > https://github.com/haskell/hackage-server/issues/145#issuecomment-29472445 > Greetings again, After some feedback from people over yesterday and some digging today, few things became apparent: * cross-package linking is broken with manual documentation * ?Contents? link takes you somewhere else now * I said ?cd dist/doc? instead of ?cd dist/doc/html? Here is what you can do to fix the package links and contents page: add the following flags to the ?cabal haddock? command: --html-location='http://hackage.haskell.org/package/$pkg/docs' --contents-location='http://hackage.haskell.org/package/$pkg' I'm not sure of implication of this for specific version package links. Note also that you do need to put in ?$pkg?, that is a cabal directive. As usual, I welcome any comments and improvements. -- Mateusz K. From selinger at mathstat.dal.ca Tue Jan 7 01:23:09 2014 From: selinger at mathstat.dal.ca (Peter Selinger) Date: Mon, 6 Jan 2014 21:23:09 -0400 (AST) Subject: Broken documentation on Hackage. In-Reply-To: <52CB3461.2020101@fuuzetsu.co.uk> Message-ID: <20140107012309.76E118C017C@chase.mathstat.dal.ca> Thanks, that's even better! However, I find that the --contents-location option to cabal haddock does not work properly. Apparently it not only prevents index.html from being built (which makes modest sense), but it also prevents index-frames.html from being built (which does not). So in the frames view, one of the frames will just say "Sorry, it's just not here". That's not very nice. Also, if one loads the "/frames.html" URL directly, it still points to the non-existing index.html, rather than the one given by --contents-location. I think these are bugs. For example, see http://hackage.haskell.org/package/yi-monokai-0.1.1.1/docs/Yi-Style-Monokai.html and click on "Frames". One workaround is to run "cabal haddock" twice: first without the --contents-location option, and then with it. Slightly annoying, but it works. It has the disadvantage that if one goes directly to the ".../frames.html" URL, one will still see the old index.html. Another workaround is to omit the --contents-location option altogether, and to manually create an index.html that is just a forward to the correct location, i.e.: If your browser does not take you there automatically, please go to http://hackage.haskell.org/package/newsynth-0.1.0.0. Only this last solution seems to do the correct thing all the time. For an example, see http://hackage.haskell.org/package/newsynth-0.1.0.0/docs/frames.html Your instructions have been *very* helpful. But it's a lot of details and finnicky cabal directives to keep track of for doing this all the time. I've turned your instructions into a Makefile to automate this task; see attached. In principle, only the first two lines should need to be customized. Then "make doc-upload" will build the documentation and upload it correctly. I know, Cabal somehow was supposed to make Makefiles obsolete. Alas. Fortunately, the Makefile is only for the package maintainer, and not for the package user. -- Peter Mateusz Kowalczyk wrote: > > On 05/01/14 10:15, Mateusz Kowalczyk wrote: > > Hi all, > > > > It seems that we are having a rather big issue with Hackage in recent > > months and I'm sure many of you have noticed: a lot of packages aren't > > getting their docs built. As far as I can tell, there can be multiple > > reasonable causes: > > > > [snip] > > > > [1]: https://github.com/haskell/hackage-server/issues/145 > > [2]: > > https://github.com/haskell/hackage-server/issues/145#issuecomment-29468613 > > [3]: > > https://github.com/haskell/hackage-server/issues/145#issuecomment-29422332 > > [4]: http://hackage.haskell.org/packages/trustees/ > > [5]: http://fuuzetsu.co.uk/misc/sorted.txt > > [6]: > > https://github.com/haskell/hackage-server/issues/145#issuecomment-30129142 > > [7]: > > https://github.com/haskell/hackage-server/issues/145#issuecomment-29472445 > > > > Greetings again, > > After some feedback from people over yesterday and some digging today, > few things became apparent: > * cross-package linking is broken with manual documentation > * ?Contents? link takes you somewhere else now > * I said ?cd dist/doc? instead of ?cd dist/doc/html? > > Here is what you can do to fix the package links and contents page: > add the following flags to the ?cabal haddock? command: > > --html-location='http://hackage.haskell.org/package/$pkg/docs' > --contents-location='http://hackage.haskell.org/package/$pkg' > > I'm not sure of implication of this for specific version package links. > Note also that you do need to put in ?$pkg?, that is a cabal directive. > > As usual, I welcome any comments and improvements. > -- > Mateusz K. > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 1569 bytes Desc: Makefile URL: From fuuzetsu at fuuzetsu.co.uk Tue Jan 7 02:28:17 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 07 Jan 2014 02:28:17 +0000 Subject: Broken documentation on Hackage. In-Reply-To: <20140107012309.76E118C017C@chase.mathstat.dal.ca> References: <20140107012309.76E118C017C@chase.mathstat.dal.ca> Message-ID: <52CB6641.2000907@fuuzetsu.co.uk> On 07/01/14 01:23, Peter Selinger wrote: > Thanks, that's even better! > > However, I find that the --contents-location option to cabal haddock > does not work properly. Apparently it not only prevents index.html > from being built (which makes modest sense), but it also prevents > index-frames.html from being built (which does not). So in the frames > view, one of the frames will just say "Sorry, it's just not here". > That's not very nice. Also, if one loads the "/frames.html" URL > directly, it still points to the non-existing index.html, rather than > the one given by --contents-location. I think these are bugs. > > For example, see > http://hackage.haskell.org/package/yi-monokai-0.1.1.1/docs/Yi-Style-Monokai.html > and click on "Frames". Ah, I do not use frames so I did not notice. > One workaround is to run "cabal haddock" twice: first without the > --contents-location option, and then with it. Slightly annoying, but > it works. It has the disadvantage that if one goes directly to the > ".../frames.html" URL, one will still see the old index.html. > > Another workaround is to omit the --contents-location option > altogether, and to manually create an index.html that is just a > forward to the correct location, i.e.: > > > If your browser does not take you there automatically, please go to > http://hackage.haskell.org/package/newsynth-0.1.0.0. > > Only this last solution seems to do the correct thing all the time. > For an example, see > http://hackage.haskell.org/package/newsynth-0.1.0.0/docs/frames.html > > Your instructions have been *very* helpful. But it's a lot of details > and finnicky cabal directives to keep track of for doing this all the > time. I've turned your instructions into a Makefile to automate this > task; see attached. In principle, only the first two lines should need > to be customized. Then "make doc-upload" will build the documentation > and upload it correctly. That looks very useful but I have a few questions about it: * Why a Makefile as opposed to a Bash script or something? I don't think there's a way to pass arguments into a Makefile like to Bash scripts, save for environmental variables. I'd much rather prefer a command line flag for a script in my PATH rather than having to change the file each time. * This file makes us change the top two lines (user and package name) and uses ?read? for everything else. Why not fully go with one way or the other? Personally, I'd prefer arguments rather than ?read? (much easier to repeat commands/script against) but it's up to personal taste. * Can we not grab to project name from the cabal file just like you do with version? * Your ?--html-location? has ?$$pkg? in it, how come? Is that some kind of escape? * Considering you seem to know what you're doing much more than I am, is there any way to detect cabal sandboxes? I'm trying your makefile now (running with make -f /tmp/Makefile doc-upload) and it's giving me an error: ``` [snip] Haddock coverage: 100% ( 18 / 18) in 'Yi.Style.Monokai' Documentation created: dist/doc/html/yi-monokai/index.html rm -r yi-monokai-0.1.1.1-docs rm: cannot remove ?yi-monokai-0.1.1.1-docs?: No such file or directory make: *** [yi-monokai-0.1.1.1-docs.tar.gz] Error 1 ``` It works fine if I comment out the ?rm -r?. Perhaps that should be allowed to fail somehow. > I know, Cabal somehow was supposed to make Makefiles obsolete. Alas. > Fortunately, the Makefile is only for the package maintainer, and not > for the package user. > > -- Peter I think that cabal-install should really have the option to do all this rather than have people write up scripts like this, resulting in trial and error. -- Mateusz K. From carter.schonwald at gmail.com Tue Jan 7 02:42:12 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 6 Jan 2014 21:42:12 -0500 Subject: Broken documentation on Hackage. In-Reply-To: <52CB6641.2000907@fuuzetsu.co.uk> References: <20140107012309.76E118C017C@chase.mathstat.dal.ca> <52CB6641.2000907@fuuzetsu.co.uk> Message-ID: agreed, cabal-install should definitely get support for doing this correctly added in. (since this is going to become a common activity for maintainers who's libs need extra things installed that the doc builders lack) Any volunteers? On Mon, Jan 6, 2014 at 9:28 PM, Mateusz Kowalczyk wrote: > On 07/01/14 01:23, Peter Selinger wrote: > > Thanks, that's even better! > > > > However, I find that the --contents-location option to cabal haddock > > does not work properly. Apparently it not only prevents index.html > > from being built (which makes modest sense), but it also prevents > > index-frames.html from being built (which does not). So in the frames > > view, one of the frames will just say "Sorry, it's just not here". > > That's not very nice. Also, if one loads the "/frames.html" URL > > directly, it still points to the non-existing index.html, rather than > > the one given by --contents-location. I think these are bugs. > > > > For example, see > > > http://hackage.haskell.org/package/yi-monokai-0.1.1.1/docs/Yi-Style-Monokai.html > > and click on "Frames". > > Ah, I do not use frames so I did not notice. > > > One workaround is to run "cabal haddock" twice: first without the > > --contents-location option, and then with it. Slightly annoying, but > > it works. It has the disadvantage that if one goes directly to the > > ".../frames.html" URL, one will still see the old index.html. > > > > Another workaround is to omit the --contents-location option > > altogether, and to manually create an index.html that is just a > > forward to the correct location, i.e.: > > > > > > If your browser does not take you there automatically, please go to > > > http://hackage.haskell.org/package/newsynth-0.1.0.0. > > > > Only this last solution seems to do the correct thing all the time. > > For an example, see > > http://hackage.haskell.org/package/newsynth-0.1.0.0/docs/frames.html > > > > Your instructions have been *very* helpful. But it's a lot of details > > and finnicky cabal directives to keep track of for doing this all the > > time. I've turned your instructions into a Makefile to automate this > > task; see attached. In principle, only the first two lines should need > > to be customized. Then "make doc-upload" will build the documentation > > and upload it correctly. > > That looks very useful but I have a few questions about it: > * Why a Makefile as opposed to a Bash script or something? I don't > think there's a way to pass arguments into a Makefile like to Bash > scripts, save for environmental variables. I'd much rather prefer a > command line flag for a script in my PATH rather than having to change > the file each time. > > * This file makes us change the top two lines (user and package name) > and uses ?read? for everything else. Why not fully go with one way or > the other? Personally, I'd prefer arguments rather than ?read? (much > easier to repeat commands/script against) but it's up to personal taste. > > * Can we not grab to project name from the cabal file just like you do > with version? > > * Your ?--html-location? has ?$$pkg? in it, how come? Is that some > kind of escape? > > * Considering you seem to know what you're doing much more than I am, > is there any way to detect cabal sandboxes? > > I'm trying your makefile now (running with make -f /tmp/Makefile > doc-upload) and > it's giving me an error: > > ``` > [snip] > Haddock coverage: > 100% ( 18 / 18) in 'Yi.Style.Monokai' > Documentation created: dist/doc/html/yi-monokai/index.html > rm -r yi-monokai-0.1.1.1-docs > rm: cannot remove ?yi-monokai-0.1.1.1-docs?: No such file or directory > make: *** [yi-monokai-0.1.1.1-docs.tar.gz] Error 1 > ``` > > It works fine if I comment out the ?rm -r?. Perhaps that should be > allowed to fail somehow. > > > I know, Cabal somehow was supposed to make Makefiles obsolete. Alas. > > Fortunately, the Makefile is only for the package maintainer, and not > > for the package user. > > > > -- Peter > > I think that cabal-install should really have the option to do all > this rather than have people write up scripts like this, resulting in > trial and error. > > -- > Mateusz K. > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinger at mathstat.dal.ca Tue Jan 7 04:07:11 2014 From: selinger at mathstat.dal.ca (Peter Selinger) Date: Tue, 7 Jan 2014 00:07:11 -0400 (AST) Subject: Broken documentation on Hackage. In-Reply-To: <52CB6641.2000907@fuuzetsu.co.uk> Message-ID: <20140107040712.010D68C017C@chase.mathstat.dal.ca> Hi Mateusz, of course you could do the same thing with a bash script. It's a matter of personal taste and workflow. Just for the record, you can pass arguments into a Makefile like this: "make PACKAGE=bla". And "$$" is indeed an escape, to denote a literal dollar sign (as opposed to a Makefile variable). Sorry about the bug. It should be "rm -rf". I'm not sure about the wisdom of adding new functionality to cabal-install just to compensate for bugs in the Hackage documentation builder. It seems that the packages build correctly everywhere else, so there is no reason in principle why the Hackage documentation builder could not be fixed to build them. I see the manual uploading as more of a temporary workaround. As for the bug with --contents-location and frames, it doesn't come up in the Hackage documentation builder because it apparently disables frames. There must be another (undocumented?) option for turning frames off. -- Peter Mateusz Kowalczyk wrote: > > > Your instructions have been *very* helpful. But it's a lot of details > > and finnicky cabal directives to keep track of for doing this all the > > time. I've turned your instructions into a Makefile to automate this > > task; see attached. In principle, only the first two lines should need > > to be customized. Then "make doc-upload" will build the documentation > > and upload it correctly. > > That looks very useful but I have a few questions about it: > * Why a Makefile as opposed to a Bash script or something? I don't > think there's a way to pass arguments into a Makefile like to Bash > scripts, save for environmental variables. I'd much rather prefer a > command line flag for a script in my PATH rather than having to change > the file each time. > * This file makes us change the top two lines (user and package name) > and uses ?read? for everything else. Why not fully go with one way or > the other? Personally, I'd prefer arguments rather than ?read? (much > easier to repeat commands/script against) but it's up to personal taste. > > * Can we not grab to project name from the cabal file just like you do > with version? > > * Your ?--html-location? has ?$$pkg? in it, how come? Is that some > kind of escape? > > * Considering you seem to know what you're doing much more than I am, > is there any way to detect cabal sandboxes? > > I'm trying your makefile now (running with make -f /tmp/Makefile > doc-upload) and > it's giving me an error: > > ``` > [snip] > Haddock coverage: > 100% ( 18 / 18) in 'Yi.Style.Monokai' > Documentation created: dist/doc/html/yi-monokai/index.html > rm -r yi-monokai-0.1.1.1-docs > rm: cannot remove ?yi-monokai-0.1.1.1-docs?: No such file or directory > make: *** [yi-monokai-0.1.1.1-docs.tar.gz] Error 1 > ``` > > It works fine if I comment out the ?rm -r?. Perhaps that should be > allowed to fail somehow. > > > I know, Cabal somehow was supposed to make Makefiles obsolete. Alas. > > Fortunately, the Makefile is only for the package maintainer, and not > > for the package user. > > > > -- Peter > > I think that cabal-install should really have the option to do all > this rather than have people write up scripts like this, resulting in > trial and error. From Christian.Maeder at dfki.de Thu Jan 9 13:47:49 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu, 09 Jan 2014 14:47:49 +0100 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: <52CA93A0.5060900@dfki.de> References: <52CA93A0.5060900@dfki.de> Message-ID: <52CEA885.7040407@dfki.de> Hi, I've just noticed that text-1.1.0.0 was uploaded and that the (earlier adapted) constraint (text >= 0.2 && < 1.1) for parsec-3.1.4 is again too narrow. http://hackage.haskell.org/package/text http://hackage.haskell.org/package/parsec I assume text-1.1.0.0 is an improvement that should go into the platform, but the platform cannot keep track with such rapidly moving targets like the text package. When can we expect the text package to become more stable? Which text (and parsec) version should go into the next HP release? Cheers Christian Am 06.01.2014 12:29, schrieb Christian Maeder: > Hi, > > I would propose to update to the latest text-1.0.0.1 version and other > packages depending on it (ie. parsec-3.1.4) > > (A name containing 2014 would make more sense to me.) > > Cheers Christian From aslatter at gmail.com Fri Jan 10 13:51:24 2014 From: aslatter at gmail.com (Antoine Latter) Date: Fri, 10 Jan 2014 07:51:24 -0600 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: <52CEA885.7040407@dfki.de> References: <52CA93A0.5060900@dfki.de> <52CEA885.7040407@dfki.de> Message-ID: I currently expect the change in parsec to be a simple change in the package description, so it will be fine for inclusion in the next platform if needed. On Jan 9, 2014 7:47 AM, "Christian Maeder" wrote: > Hi, > > I've just noticed that text-1.1.0.0 was uploaded and that the (earlier > adapted) constraint (text >= 0.2 && < 1.1) for parsec-3.1.4 is again too > narrow. > > http://hackage.haskell.org/package/text > http://hackage.haskell.org/package/parsec > > I assume text-1.1.0.0 is an improvement that should go into the platform, > but the platform cannot keep track with such rapidly moving targets like > the text package. > > When can we expect the text package to become more stable? > Which text (and parsec) version should go into the next HP release? > > Cheers Christian > > Am 06.01.2014 12:29, schrieb Christian Maeder: > >> Hi, >> >> I would propose to update to the latest text-1.0.0.1 version and other >> packages depending on it (ie. parsec-3.1.4) >> >> (A name containing 2014 would make more sense to me.) >> >> Cheers Christian >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslatter at gmail.com Sat Jan 11 06:18:16 2014 From: aslatter at gmail.com (Antoine Latter) Date: Sat, 11 Jan 2014 00:18:16 -0600 Subject: Who remembers HP 2013.4.0.0...? In-Reply-To: References: <52CA93A0.5060900@dfki.de> <52CEA885.7040407@dfki.de> Message-ID: Hi Mark, I don't know what your approach is going to be for 'text' but if you will be including versions 1.0.* or 1.1.* you'll also need to pull in a newer version of 'parsec'. I've released parsec versions 3.1.4 & 3.1.5, whose only changes bump the 'text' dependency to 1.0.* and 1.1.* respectively. Take care, Antoine On Fri, Jan 10, 2014 at 7:51 AM, Antoine Latter wrote: > I currently expect the change in parsec to be a simple change in the > package description, so it will be fine for inclusion in the next platform > if needed. > On Jan 9, 2014 7:47 AM, "Christian Maeder" > wrote: > >> Hi, >> >> I've just noticed that text-1.1.0.0 was uploaded and that the (earlier >> adapted) constraint (text >= 0.2 && < 1.1) for parsec-3.1.4 is again too >> narrow. >> >> http://hackage.haskell.org/package/text >> http://hackage.haskell.org/package/parsec >> >> I assume text-1.1.0.0 is an improvement that should go into the platform, >> but the platform cannot keep track with such rapidly moving targets like >> the text package. >> >> When can we expect the text package to become more stable? >> Which text (and parsec) version should go into the next HP release? >> >> Cheers Christian >> >> Am 06.01.2014 12:29, schrieb Christian Maeder: >> >>> Hi, >>> >>> I would propose to update to the latest text-1.0.0.1 version and other >>> packages depending on it (ie. parsec-3.1.4) >>> >>> (A name containing 2014 would make more sense to me.) >>> >>> Cheers Christian >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Tue Jan 14 16:41:48 2014 From: rrnewton at gmail.com (Ryan Newton) Date: Tue, 14 Jan 2014 11:41:48 -0500 Subject: Releasing containers 0.5.3.2 -- before GHC 7.8? Message-ID: Hi guys, I'm wondering if we can do a hackage release of 0.5.3.2? That "splitRoot" function is in there, and my ability to deploy parallel code that uses containers depends on people getting it! Are there any other changes since 0.5.3.1? Replacing containers seems like a real pain for end users, so it would be great if 0.5.3.2 could come with GHC 7.8. Currently, it looks like the GHC repo is up to date in that it includes 0.5.3.1. I realize it is late days for this, but: - It's been a month since we put splitRoot in; I've been using it heavily and it I'm pretty confident that it's correct. (It's so simple!) - Nothing else is touched, so there is very little liability associated with this version bump. And, as you know, if we don't make this round it's a long latency before the next chance. That is, before we can expect people to do parallel folds over Data.Set or Data.Map without installation headache. Any objections? -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Tue Jan 14 17:01:50 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 14 Jan 2014 19:01:50 +0200 Subject: Releasing containers 0.5.3.2 -- before GHC 7.8? In-Reply-To: References: Message-ID: <20140114170150.GA31232@sniper> * Ryan Newton [2014-01-14 11:41:48-0500] > Replacing containers seems like a real pain for end users Is it a real pain? Why? I just tried 'cabal install containers', and it went flawlessly. To make it clear, I'm not in any way opposed to containers upgrade, but that phrase struck me as odd. The only issue I'm aware of is related to the GHC API, but high-performance parallel algorithms and the GHC API are rarely used together in the same project. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From rrnewton at gmail.com Tue Jan 14 19:19:57 2014 From: rrnewton at gmail.com (Ryan Newton) Date: Tue, 14 Jan 2014 14:19:57 -0500 Subject: Releasing containers 0.5.3.2 -- before GHC 7.8? In-Reply-To: <20140114170150.GA31232@sniper> References: <20140114170150.GA31232@sniper> Message-ID: On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka wrote: > * Ryan Newton [2014-01-14 11:41:48-0500] > > Replacing containers seems like a real pain for end users > > Is it a real pain? Why? > One thing I ran into is that cabal sandboxes want consistent dependencies. And when users get to this point where they need to grab our latest containers, they've got a bunch of core/haskell platform packages that depend on the old containers. I didn't mean that there was anything difficult about containers itself, just that almost everything else depends on it. -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Jan 14 19:23:12 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 14 Jan 2014 14:23:12 -0500 Subject: Releasing containers 0.5.3.2 -- before GHC 7.8? In-Reply-To: References: <20140114170150.GA31232@sniper> Message-ID: have you tried installing a newer version of containers yourself globally, and making the other one hidden? Or just making the global one ghc comes with hidden? On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton wrote: > > > > On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka wrote: > >> * Ryan Newton [2014-01-14 11:41:48-0500] >> > Replacing containers seems like a real pain for end users >> >> Is it a real pain? Why? >> > > One thing I ran into is that cabal sandboxes want consistent dependencies. > And when users get to this point where they need to grab our latest > containers, they've got a bunch of core/haskell platform packages that > depend on the old containers. > > I didn't mean that there was anything difficult about containers itself, > just that almost everything else depends on it. > > -Ryan > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwbarton at gmail.com Tue Jan 14 20:15:32 2014 From: rwbarton at gmail.com (Reid Barton) Date: Tue, 14 Jan 2014 15:15:32 -0500 Subject: Releasing containers 0.5.3.2 -- before GHC 7.8? In-Reply-To: References: <20140114170150.GA31232@sniper> Message-ID: On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton wrote: > On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka wrote: > >> * Ryan Newton [2014-01-14 11:41:48-0500] >> > Replacing containers seems like a real pain for end users >> >> Is it a real pain? Why? >> > > One thing I ran into is that cabal sandboxes want consistent dependencies. > And when users get to this point where they need to grab our latest > containers, they've got a bunch of core/haskell platform packages that > depend on the old containers. > > I didn't mean that there was anything difficult about containers itself, > just that almost everything else depends on it. > In addition to the general pain of updating packages at the base of the dependency hierarchy, there is also the fact that the template-haskell package depends on containers. As far as I know upgrading template-haskell is impossible, or at least a Very Bad Idea, so any library that wants to use an updated version of containers can't use template-haskell, or even be linked into an application that uses template-haskell directly or through another library. As far as I am concerned as a GHC user, versions of containers that aren't the one that came with my GHC might as well not exist. For example if I see that a package has a constraint "containers >= 0.10", I just assume I cannot use the library with GHC 7.4. Thus I'm strongly in favor of synchronizing containers releases with releases of GHC. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Jan 14 20:40:41 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 14 Jan 2014 15:40:41 -0500 Subject: Releasing containers 0.5.3.2 -- before GHC 7.8? In-Reply-To: References: <20140114170150.GA31232@sniper> Message-ID: ok, thats a good point On Tue, Jan 14, 2014 at 3:15 PM, Reid Barton wrote: > On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton wrote: > >> On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka wrote: >> >>> * Ryan Newton [2014-01-14 11:41:48-0500] >>> > Replacing containers seems like a real pain for end users >>> >>> Is it a real pain? Why? >>> >> >> One thing I ran into is that cabal sandboxes want consistent >> dependencies. And when users get to this point where they need to grab our >> latest containers, they've got a bunch of core/haskell platform packages >> that depend on the old containers. >> >> I didn't mean that there was anything difficult about containers itself, >> just that almost everything else depends on it. >> > > In addition to the general pain of updating packages at the base of the > dependency hierarchy, there is also the fact that the template-haskell > package depends on containers. As far as I know upgrading template-haskell > is impossible, or at least a Very Bad Idea, so any library that wants to > use an updated version of containers can't use template-haskell, or even be > linked into an application that uses template-haskell directly or through > another library. > > As far as I am concerned as a GHC user, versions of containers that aren't > the one that came with my GHC might as well not exist. For example if I see > that a package has a constraint "containers >= 0.10", I just assume I > cannot use the library with GHC 7.4. Thus I'm strongly in favor of > synchronizing containers releases with releases of GHC. > > Regards, > Reid Barton > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fox at ucw.cz Tue Jan 14 21:33:16 2014 From: fox at ucw.cz (Milan Straka) Date: Tue, 14 Jan 2014 22:33:16 +0100 Subject: Releasing containers 0.5.3.2 -- before GHC 7.8? In-Reply-To: References: Message-ID: <20140114213316.GA32711@auryn.cz> Hi Johan, I think releasing 0.5.4 is a good idea. Could I ask you to do the release as usual, please? We added the splitRoot function, so it should really be 0.5.4 and not only 0.5.3.2. Actually, we added Functor instance to Graph.SCC and Functor and Applicative instances to Graph.SetM, but Graph is rarely used, so I would deliberately break PVP and not do a major version bump. Thanks, cheers, Milan > -----Original message----- > From: Ryan Newton > Sent: 14 Jan 2014, 11:41 > > Hi guys, > > I'm wondering if we can do a hackage release of 0.5.3.2? That "splitRoot" > function is in there, and my ability to deploy parallel code that uses > containers depends on people getting it! Are there any other changes since > 0.5.3.1? > > Replacing containers seems like a real pain for end users, so it would be > great if 0.5.3.2 could come with GHC 7.8. Currently, it looks like the GHC > repo is up to date in that it includes 0.5.3.1. > > I realize it is late days for this, but: > > - It's been a month since we put splitRoot in; I've been using it > heavily and it I'm pretty confident that it's correct. (It's so simple!) > - Nothing else is touched, so there is very little liability associated > with this version bump. > > And, as you know, if we don't make this round it's a long latency before > the next chance. That is, before we can expect people to do parallel folds > over Data.Set or Data.Map without installation headache. > > Any objections? > -Ryan From johan.tibell at gmail.com Tue Jan 14 21:47:31 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 14 Jan 2014 22:47:31 +0100 Subject: Releasing containers 0.5.3.2 -- before GHC 7.8? In-Reply-To: <20140114213316.GA32711@auryn.cz> References: <20140114213316.GA32711@auryn.cz> Message-ID: I'll make a release in the next few days. On Tue, Jan 14, 2014 at 10:33 PM, Milan Straka wrote: > Hi Johan, > > I think releasing 0.5.4 is a good idea. Could I ask you to do the > release as usual, please? > > We added the splitRoot function, so it should really be 0.5.4 and not > only 0.5.3.2. Actually, we added Functor instance to Graph.SCC and > Functor and Applicative instances to Graph.SetM, but Graph is rarely > used, so I would deliberately break PVP and not do a major version bump. > > Thanks, > cheers, > Milan > > > -----Original message----- > > From: Ryan Newton > > Sent: 14 Jan 2014, 11:41 > > > > Hi guys, > > > > I'm wondering if we can do a hackage release of 0.5.3.2? That > "splitRoot" > > function is in there, and my ability to deploy parallel code that uses > > containers depends on people getting it! Are there any other changes > since > > 0.5.3.1? > > > > Replacing containers seems like a real pain for end users, so it would be > > great if 0.5.3.2 could come with GHC 7.8. Currently, it looks like the > GHC > > repo is up to date in that it includes 0.5.3.1. > > > > I realize it is late days for this, but: > > > > - It's been a month since we put splitRoot in; I've been using it > > heavily and it I'm pretty confident that it's correct. (It's so > simple!) > > - Nothing else is touched, so there is very little liability > associated > > with this version bump. > > > > And, as you know, if we don't make this round it's a long latency before > > the next chance. That is, before we can expect people to do parallel > folds > > over Data.Set or Data.Map without installation headache. > > > > Any objections? > > -Ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Maeder at dfki.de Wed Jan 15 14:42:32 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed, 15 Jan 2014 15:42:32 +0100 Subject: System.FilePath.splitFileName Message-ID: <52D69E58.7060903@dfki.de> Hi, I suggest to improve the documentation for System.FilePath.splitFileName. The sentence "combine is the inverse" (of splitFileName) is misleading, as the following example shows: Prelude System.FilePath> uncurry combine $ splitFileName "bob" "./bob" adding normalize to the result only also gives not (String) identity: Prelude System.FilePath> normalise $ uncurry combine $ splitFileName "./bob" "bob" I suggest to change it to: "combine is the inverse modulo normalise or equalFilePath" Maybe also the following combine examples should be added: combine "./" "bob" == "./bob" combine "." "bob" == "./bob" http://www.haskell.org/ghc/docs/latest/html/libraries/filepath-1.3.0.1/System-FilePath-Posix.html#g:5 Cheers Christian From hvr at gnu.org Thu Jan 16 07:54:34 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 16 Jan 2014 08:54:34 +0100 Subject: Releasing containers 0.5.3.2 -- before GHC 7.8? In-Reply-To: (Ryan Newton's message of "Tue, 14 Jan 2014 11:41:48 -0500") References: Message-ID: <878uugpdj9.fsf@gnu.org> On 2014-01-14 at 17:41:48 +0100, Ryan Newton wrote: > I'm wondering if we can do a hackage release of 0.5.3.2? That "splitRoot" > function is in there, and my ability to deploy parallel code that uses > containers depends on people getting it! Are there any other changes since > 0.5.3.1? > > Replacing containers seems like a real pain for end users, so it would be > great if 0.5.3.2 could come with GHC 7.8. Currently, it looks like the GHC > repo is up to date in that it includes 0.5.3.1. Done (actually is do.. erm... containers-0.5.4.0): http://git.haskell.org/ghc.git/commitdiff/69cf5c4cb8aba309e5c495008b69089e5431a095 Cheers, hvr From kyrab at mail.ru Sat Jan 18 09:38:34 2014 From: kyrab at mail.ru (kyra) Date: Sat, 18 Jan 2014 13:38:34 +0400 Subject: Hashtables: 'Basic' hashtables performance quirks on Win64 Message-ID: <52DA4B9A.4050508@mail.ru> Having built Agda on 64-bit GHC 7.6.3 on Windows I've stumbled on Agda being unbearable slow (I tried it on Penryn and Sandy Bridge computers). The culprit turned out to be Agda uses 'BasicHashTable' in src/full/Agda/TypeChecking/Serialise.hs (line 98). Switching either to Cuckoo or Linear immediately cures the problem. The problem does not manifest itself on 32-bit Windows build or any Linux build. Also 'Basic' hashtable perform better than Cuckoo and Linear in standard benchmarks on Win64. And at the same time in Agda scenario it's performance degrades by a *couple of orders of magnitude*! Thus, *all* things are important here: 64-bit, Windows, Agda use case. I wonder what stands behind this behaviour? What are specifics of 'Basic' hashtable implementation and how to fix this or should this be fixed at all? Regards, Kyra From greg at gregorycollins.net Sat Jan 18 12:01:09 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Sat, 18 Jan 2014 13:01:09 +0100 Subject: Hashtables: 'Basic' hashtables performance quirks on Win64 In-Reply-To: <52DA4B9A.4050508@mail.ru> References: <52DA4B9A.4050508@mail.ru> Message-ID: Can you isolate which of the hash table instances is slow? The basic hash table uses linear probing and may perform badly if the hash function has poor clustering behavior. Some versions of "hashable" set "hash = id" for Int, which may not help matters. The benchmarks I have, as you suggest, say that it performs well -- but they are incomplete. I can't optimize what I don't test: if you can isolate a minimal example where it performs much worse than it should, I would appreciate that. As far as Windows goes, I don't use it and don't have access to such a machine, I would need help to debug and fix this. G On Sat, Jan 18, 2014 at 10:38 AM, kyra wrote: > Having built Agda on 64-bit GHC 7.6.3 on Windows I've stumbled on Agda > being unbearable slow (I tried it on Penryn and Sandy Bridge computers). > The culprit turned out to be Agda uses 'BasicHashTable' in > src/full/Agda/TypeChecking/Serialise.hs (line 98). > > Switching either to Cuckoo or Linear immediately cures the problem. > > The problem does not manifest itself on 32-bit Windows build or any Linux > build. > > Also 'Basic' hashtable perform better than Cuckoo and Linear in standard > benchmarks on Win64. And at the same time in Agda scenario it's performance > degrades by a *couple of orders of magnitude*! > > Thus, *all* things are important here: 64-bit, Windows, Agda use case. > > I wonder what stands behind this behaviour? What are specifics of 'Basic' > hashtable implementation and how to fix this or should this be fixed at all? > > Regards, > Kyra > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Jan 19 23:14:37 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 19 Jan 2014 15:14:37 -0800 Subject: A modest proposal (re the Platform) Message-ID: Looks like GHC 7.8 is pretty near release. And while I know that we really like to have a GHC out for a while, and perhaps see the .1 release, before we incorporate it into the Platform, this GHC, while including many new and anticipated things, seems pretty well hammered on. Combine that with the now two-month late (all my fault) HP release for 2013.4.0.0 isn't slated to really have all that much new in it, in part because it is the same GHC as the last HP release. Now - it would really look foolish, and taken poorly (methinks) if we release a HP this month - only to have GHC 7.8 release early Feb. Folks would really be head scratching, and wondering about the platform. SO - I'm proposing ditching the now late 2013.4.0.0 (I admit, I'm finding it hard to get excited by it!) and instead move right to putting out 2014.2.0.0 - aimed for mid-March to mid-April. This release would have several big changes: - GHC 7.8 - New shake based build for the Platform - Support for validation via package tests - Support for a "server variant" (no OpenGL or other GUI stuff if we had any) - Automated version info w/historical version matrix page - Several significant packages: I'd like to see Aeson at the very least, updated OpenGL stuff I'd also propose changes for the Mac build (though this is obviously independent): - Built from GHC source, not dist. release. (guarantees consistent release) - Only 64bit (I know, controversial...) Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sun Jan 19 23:19:18 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 19 Jan 2014 15:19:18 -0800 Subject: A modest proposal (re the Platform) In-Reply-To: References: Message-ID: +1 On Jan 19, 2014 3:15 PM, "Mark Lentczner" wrote: > Looks like GHC 7.8 is pretty near release. > > And while I know that we really like to have a GHC out for a while, and > perhaps see the .1 release, before we incorporate it into the Platform, > this GHC, while including many new and anticipated things, seems pretty > well hammered on. > > Combine that with the now two-month late (all my fault) HP release for > 2013.4.0.0 isn't slated to really have all that much new in it, in part > because it is the same GHC as the last HP release. > > Now - it would really look foolish, and taken poorly (methinks) if we > release a HP this month - only to have GHC 7.8 release early Feb. Folks > would really be head scratching, and wondering about the platform. > > SO - I'm proposing ditching the now late 2013.4.0.0 (I admit, I'm finding > it hard to get excited by it!) and instead move right to putting out > 2014.2.0.0 - aimed for mid-March to mid-April. > > This release would have several big changes: > > - GHC 7.8 > - New shake based build for the Platform > - Support for validation via package tests > - Support for a "server variant" (no OpenGL or other GUI stuff if we > had any) > - Automated version info w/historical version matrix page > - Several significant packages: I'd like to see Aeson at the very > least, updated OpenGL stuff > > I'd also propose changes for the Mac build (though this is obviously > independent): > > - Built from GHC source, not dist. release. (guarantees consistent > release) > - Only 64bit (I know, controversial...) > > Thoughts? > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at redivi.com Sun Jan 19 23:20:34 2014 From: bob at redivi.com (Bob Ippolito) Date: Sun, 19 Jan 2014 15:20:34 -0800 Subject: A modest proposal (re the Platform) In-Reply-To: References: Message-ID: +1 I'm just a user, but I'm very excited about the possibility of getting a GHC 7.8 platform release sooner than later (especially considering Mio and the other great additions). Another release with the same GHC wouldn't do me much good. On Sun, Jan 19, 2014 at 3:14 PM, Mark Lentczner wrote: > Looks like GHC 7.8 is pretty near release. > > And while I know that we really like to have a GHC out for a while, and > perhaps see the .1 release, before we incorporate it into the Platform, > this GHC, while including many new and anticipated things, seems pretty > well hammered on. > > Combine that with the now two-month late (all my fault) HP release for > 2013.4.0.0 isn't slated to really have all that much new in it, in part > because it is the same GHC as the last HP release. > > Now - it would really look foolish, and taken poorly (methinks) if we > release a HP this month - only to have GHC 7.8 release early Feb. Folks > would really be head scratching, and wondering about the platform. > > SO - I'm proposing ditching the now late 2013.4.0.0 (I admit, I'm finding > it hard to get excited by it!) and instead move right to putting out > 2014.2.0.0 - aimed for mid-March to mid-April. > > This release would have several big changes: > > - GHC 7.8 > - New shake based build for the Platform > - Support for validation via package tests > - Support for a "server variant" (no OpenGL or other GUI stuff if we > had any) > - Automated version info w/historical version matrix page > - Several significant packages: I'd like to see Aeson at the very > least, updated OpenGL stuff > > I'd also propose changes for the Mac build (though this is obviously > independent): > > - Built from GHC source, not dist. release. (guarantees consistent > release) > - Only 64bit (I know, controversial...) > > Thoughts? > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Sun Jan 19 23:31:06 2014 From: danburton.email at gmail.com (Dan Burton) Date: Sun, 19 Jan 2014 15:31:06 -0800 Subject: A modest proposal (re the Platform) In-Reply-To: References: Message-ID: > > I'm proposing ditching the now late 2013.4.0.0 (I admit, I'm finding it > hard to get excited by it!) and instead move right to putting out > 2014.2.0.0 - aimed for mid-March to mid-April. +1 for fast-tracking GHC 7.8 into the next HP release. (I have no experience or opinion on the Mac build stuff.) -- Dan Burton -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Jan 20 00:02:27 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 19 Jan 2014 19:02:27 -0500 Subject: RFC: include a cabal-install executable in future GHC releases Message-ID: Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at fpcomplete.com Mon Jan 20 00:05:24 2014 From: johnw at fpcomplete.com (John Wiegley) Date: Sun, 19 Jan 2014 18:05:24 -0600 Subject: A modest proposal (re the Platform) In-Reply-To: (Dan Burton's message of "Sun, 19 Jan 2014 15:31:06 -0800") References: Message-ID: >>>>> Dan Burton writes: +1 John From the.dead.shall.rise at gmail.com Mon Jan 20 00:11:36 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon, 20 Jan 2014 01:11:36 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: Hi, On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald wrote: > > point being: It'd be great for haskell usability (and egads amounts of > config time, even by seasoned users) the ghc bindists / installers included > a cabal-install binary For Windows, we provide a stand-alone cabal.exe on the Cabal site [1]. I guess we could do the same for Linux and OS X. [1] http://www.haskell.org/cabal/download.html -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From carter.schonwald at gmail.com Mon Jan 20 00:14:57 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 19 Jan 2014 19:14:57 -0500 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: that still requires some discovery though! The idea (i'd hope) would be to make the "my first ghc install on a vm" (for experts and new folks both) go from #install ghc via whatever mechanism, eg wget, guntar, cd blah ; make install PREFIX=yah #figure out how to install cabal, eg discover wget and then ./bootstrap # cabal install thingsIwannaTry to # install ghc via some wget and make #cabal install nice things On Sun, Jan 19, 2014 at 7:11 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > Hi, > > On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald > wrote: > > > > point being: It'd be great for haskell usability (and egads amounts of > > config time, even by seasoned users) the ghc bindists / installers > included > > a cabal-install binary > > For Windows, we provide a stand-alone cabal.exe on the Cabal site [1]. > I guess we could do the same for Linux and OS X. > > [1] http://www.haskell.org/cabal/download.html > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Mon Jan 20 02:37:21 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon, 20 Jan 2014 03:37:21 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: Hi, On Mon, Jan 20, 2014 at 1:14 AM, Carter Schonwald wrote: > that still requires some discovery though! The idea (i'd hope) would be to > make the "my first ghc install on a vm" (for experts and new folks both) Regardless, I think it should be the Cabal developers' job to provide pre-built cabal-install binaries. The choice of whether or not to ship them with the GHC binary tarballs falls to GHC HQ. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From haskell-oren at ben-kiki.org Mon Jan 20 05:24:33 2014 From: haskell-oren at ben-kiki.org (Oren Ben-Kiki) Date: Mon, 20 Jan 2014 07:24:33 +0200 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: Hear hear! This would be most welcome. On Mon, Jan 20, 2014 at 2:14 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > that still requires some discovery though! The idea (i'd hope) would be to > make the "my first ghc install on a vm" (for experts and new folks both) > > go from > > #install ghc via whatever mechanism, eg wget, guntar, cd blah ; make > install PREFIX=yah > #figure out how to install cabal, eg discover wget and then ./bootstrap > # cabal install thingsIwannaTry > > to > # install ghc via some wget and make > #cabal install nice things > > > On Sun, Jan 19, 2014 at 7:11 PM, Mikhail Glushenkov < > the.dead.shall.rise at gmail.com> wrote: > >> Hi, >> >> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald >> wrote: >> > >> > point being: It'd be great for haskell usability (and egads amounts of >> > config time, even by seasoned users) the ghc bindists / installers >> included >> > a cabal-install binary >> >> For Windows, we provide a stand-alone cabal.exe on the Cabal site [1]. >> I guess we could do the same for Linux and OS X. >> >> [1] http://www.haskell.org/cabal/download.html >> >> -- >> () ascii ribbon campaign - against html e-mail >> /\ www.asciiribbon.org - against proprietary attachments >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Jan 20 05:38:58 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 20 Jan 2014 00:38:58 -0500 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: indeed, after thinking a wee bit more, yes, it'd be AMAZING if cabal devs made binaries visibly available to the community! (also, it does seem like cabal / cabal-install docs aren't super discoverable for some people) On Mon, Jan 20, 2014 at 12:24 AM, Oren Ben-Kiki wrote: > Hear hear! This would be most welcome. > > > On Mon, Jan 20, 2014 at 2:14 AM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> that still requires some discovery though! The idea (i'd hope) would be >> to make the "my first ghc install on a vm" (for experts and new folks both) >> >> go from >> >> #install ghc via whatever mechanism, eg wget, guntar, cd blah ; make >> install PREFIX=yah >> #figure out how to install cabal, eg discover wget and then ./bootstrap >> # cabal install thingsIwannaTry >> >> to >> # install ghc via some wget and make >> #cabal install nice things >> >> >> On Sun, Jan 19, 2014 at 7:11 PM, Mikhail Glushenkov < >> the.dead.shall.rise at gmail.com> wrote: >> >>> Hi, >>> >>> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald >>> wrote: >>> > >>> > point being: It'd be great for haskell usability (and egads amounts of >>> > config time, even by seasoned users) the ghc bindists / installers >>> included >>> > a cabal-install binary >>> >>> For Windows, we provide a stand-alone cabal.exe on the Cabal site [1]. >>> I guess we could do the same for Linux and OS X. >>> >>> [1] http://www.haskell.org/cabal/download.html >>> >>> -- >>> () ascii ribbon campaign - against html e-mail >>> /\ www.asciiribbon.org - against proprietary attachments >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon Jan 20 07:53:56 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 20 Jan 2014 09:53:56 +0200 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: <20140120075356.GA14101@sniper> Agreed, this would improve usability of binary GHC releases a lot, and I don't see any downsides. +1 Roman * Carter Schonwald [2014-01-19 19:02:27-0500] > Hey everyone, > > I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install > (aka cabal) executable, but not include the library deps of cabal-install > that aren't already distributed with ghc.(unless ghc should have those deps > baked in, which theres very very good reasons not to do.). > > currently if someone wants just a basic haskell install of the freshest ghc > they have to install a ghc bindist, then do a boostrap build of > cabal-install by hand (if they want to actually get anything done :) ). > > This is not a human friendly situation for folks who are new to haskell > tooling, but want to try out haskell dev on a server style vm or the like! > > point being: It'd be great for haskell usability (and egads amounts of > config time, even by seasoned users) the ghc bindists / installers included > a cabal-install binary > > thoughts? > -Carter > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From andres.loeh at gmail.com Mon Jan 20 08:29:57 2014 From: andres.loeh at gmail.com (=?ISO-8859-1?Q?Andres_L=F6h?=) Date: Mon, 20 Jan 2014 09:29:57 +0100 Subject: A modest proposal (re the Platform) In-Reply-To: References: Message-ID: Hi. I can understand the motivation of this proposal, but I'm slightly worried: (1) I haven't really followed the discussion, but it was my understanding that the currently released platform requires manual patching on MacOS X, whereas the new one wouldn't? If so, would it not be wise to release as soon as possible? (2) Simply because GHC 7.8 is itself so long delayed and so full of new features, I think it's realistic to assume that quite a few library glitches will appear even after it's released. Also, GHC bugs may be found only after formal release (despite all the hammering, the use of GHC pre release isn't quite comparable with the amount of testing it gets afterwards; IMHO, there might very well be need for a GHC 7.8.2). I'm all for trying to get an HP based on GHC 7.8 out as possible, but how soon would that actually happen, realistically? Sooner than 6 months from now? Cheers, Andres From hvr at gnu.org Mon Jan 20 09:00:51 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 20 Jan 2014 10:00:51 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: (Carter Schonwald's message of "Sun, 19 Jan 2014 19:02:27 -0500") References: Message-ID: <87ha8zc9j0.fsf@gnu.org> On 2014-01-20 at 01:02:27 +0100, Carter Schonwald wrote: > I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install > (aka cabal) executable, but not include the library deps of cabal-install > that aren't already distributed with ghc.(unless ghc should have those deps > baked in, which theres very very good reasons not to do.). +1 PS: ...would this affect the source-dist tarball as well? From voldermort at hotmail.com Mon Jan 20 09:03:57 2014 From: voldermort at hotmail.com (harry) Date: Mon, 20 Jan 2014 01:03:57 -0800 (PST) Subject: HP Server Release (was: A modest proposal (re the Platform)) In-Reply-To: References: Message-ID: <1390208637725-5742565.post@n5.nabble.com> As someone who frequently installs Haskell on servers, I'm interested in what you have in mind. My install process basically consists of 3 steps: 1) Install GHC from bindist 2) Delete all the documentation (except licenses), and all the stuff that's only needed for profiling, dynamic linking, and GHCi; 3) Install caball-install I'm not interested in any other pre-installed packages, because cabal-install will download and install what's needed when it needs it. The basic idea of HP - a pre-selected set of libraries to base development on - is only meaningful for developer workstations, not the servers that they deploy their software to. As for making it easier to install a working Haskell system, there's a separate proposal to include cabal-install with the bindist. -- View this message in context: http://haskell.1045720.n5.nabble.com/A-modest-proposal-re-the-Platform-tp5742537p5742565.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From voldermort at hotmail.com Mon Jan 20 09:05:39 2014 From: voldermort at hotmail.com (harry) Date: Mon, 20 Jan 2014 01:05:39 -0800 (PST) Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: <1390208739099-5742566.post@n5.nabble.com> It would be preferable for the installer to download the latest cabal install build at runtime, rather than package whatever the latest version was when GHC was built. -- View this message in context: http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742544p5742566.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From hvr at gnu.org Mon Jan 20 09:16:55 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 20 Jan 2014 10:16:55 +0100 Subject: HP Server Release In-Reply-To: <1390208637725-5742565.post@n5.nabble.com> (harry's message of "Mon, 20 Jan 2014 01:03:57 -0800 (PST)") References: <1390208637725-5742565.post@n5.nabble.com> Message-ID: <878uubc8s8.fsf@gnu.org> Hi, On 2014-01-20 at 10:03:57 +0100, harry wrote: > As someone who frequently installs Haskell on servers, I'm interested in what > you have in mind. My install process basically consists of 3 steps: > > 1) Install GHC from bindist > 2) Delete all the documentation (except licenses), and all the stuff that's > only needed for profiling, dynamic linking, and GHCi; > 3) Install caball-install ...that's exactly -- except that I don't bother for 2) unless I have space-constraints -- exactly how I proceed for server installs as well... > I'm not interested in any other pre-installed packages, because > cabal-install will download and install what's needed when it needs it. The > basic idea of HP - a pre-selected set of libraries to base development on - > is only meaningful for developer workstations, not the servers that they > deploy their software to. btw, if one really wants to use the HP-blessed versions of certain packages, one can instruct `cabal-install` via longish `--constraints` argument[1], so no need to distribute a binary build of those libs. Cheers, hvr [1]: https://github.com/hvr/multi-ghc-travis#haskell-platform-configurations From roma at ro-che.info Mon Jan 20 09:19:00 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 20 Jan 2014 11:19:00 +0200 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <1390208739099-5742566.post@n5.nabble.com> References: <1390208739099-5742566.post@n5.nabble.com> Message-ID: <20140120091900.GA19549@sniper> * harry [2014-01-20 01:05:39-0800] > It would be preferable for the installer to download the latest cabal install > build at runtime, rather than package whatever the latest version was when > GHC was built. Once you have cabal-install, you can easily update it with cabal install cabal-install Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From fox at ucw.cz Mon Jan 20 10:24:33 2014 From: fox at ucw.cz (Milan Straka) Date: Mon, 20 Jan 2014 11:24:33 +0100 Subject: A modest proposal (re the Platform) In-Reply-To: References: Message-ID: <20140120102433.GA30710@auryn.cz> Hi all, > -----Original message----- > From: Mark Lentczner > Sent: 19 Jan 2014, 15:14 > > Looks like GHC 7.8 is pretty near release. > > SO - I'm proposing ditching the now late 2013.4.0.0 (I admit, I'm finding > it hard to get excited by it!) and instead move right to putting out > 2014.2.0.0 - aimed for mid-March to mid-April. +1. Cheers, Milan From voldermort at hotmail.com Mon Jan 20 12:30:29 2014 From: voldermort at hotmail.com (harry) Date: Mon, 20 Jan 2014 04:30:29 -0800 (PST) Subject: HP Server Release In-Reply-To: <878uubc8s8.fsf@gnu.org> References: <1390208637725-5742565.post@n5.nabble.com> <878uubc8s8.fsf@gnu.org> Message-ID: <1390221029628-5742579.post@n5.nabble.com> Herbert Valerio Riedel wrote > ...that's exactly -- except that I don't bother for 2) unless I have > space-constraints -- exactly how I proceed for server installs as > well... Space constraints are common these cloudy days. Take a look at the Heroku build packs for example. -- View this message in context: http://haskell.1045720.n5.nabble.com/A-modest-proposal-re-the-Platform-tp5742537p5742579.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From voldermort at hotmail.com Mon Jan 20 12:32:12 2014 From: voldermort at hotmail.com (harry) Date: Mon, 20 Jan 2014 04:32:12 -0800 (PST) Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <20140120091900.GA19549@sniper> References: <1390208739099-5742566.post@n5.nabble.com> <20140120091900.GA19549@sniper> Message-ID: <1390221132593-5742580.post@n5.nabble.com> Roman Cheplyaka-2 wrote > Once you have cabal-install, you can easily update it with > cabal install cabal-install Which will also have to download and build all the dependencies, as they aren't included. Not the end of the world, but a fresh cabal-install would be a nicer user experience. -- View this message in context: http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742544p5742580.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From acowley at seas.upenn.edu Mon Jan 20 16:55:09 2014 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Mon, 20 Jan 2014 11:55:09 -0500 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> > On Jan 19, 2014, at 7:02 PM, Carter Schonwald wrote: > > Hey everyone, > > I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). > > currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). > > This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! > > point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary > > thoughts? > -Carter +1 cabal-install works very well, and is key to getting a Haskell development environment up and running. The only downside is if there is much call for minimal GHC binary distributions: If we would need to provide multiple downloads, that starts to verge into HP territory. So I shall clarify my +1 to say that I always want a cabal-install executable with my GHC, but it would be good to hear from people who really don't want that extra baggage. Anthony From schlepptop at henning-thielemann.de Mon Jan 20 17:05:22 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 20 Jan 2014 18:05:22 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> Message-ID: <52DD5752.2060500@henning-thielemann.de> Am 20.01.2014 17:55, schrieb Anthony Cowley: > cabal-install works very well, and is key to getting a Haskell development environment up and running. The only downside is if there is much call for minimal GHC binary distributions: If we would need to provide multiple downloads, that starts to verge into HP territory. So I shall clarify my +1 to say that I always want a cabal-install executable with my GHC, but it would be good to hear from people who really don't want that extra baggage. For me it would mean duplication. Whenever I install GHC I already have a running cabal-install and I can install a new one, if a new version of cabal-install is released. I think the banner above the GHC download page makes pretty clear, that the binary GHC tarball is not intended for comfort use. Maybe the banner can be extended by a hint, where cabal-install executables can be downloaded. From ivan.miljenovic at gmail.com Mon Jan 20 23:01:00 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 21 Jan 2014 10:01:00 +1100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <52DD5752.2060500@henning-thielemann.de> References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> Message-ID: On 21 January 2014 04:05, Henning Thielemann wrote: > Am 20.01.2014 17:55, schrieb Anthony Cowley: > > >> cabal-install works very well, and is key to getting a Haskell development >> environment up and running. The only downside is if there is much call for >> minimal GHC binary distributions: If we would need to provide multiple >> downloads, that starts to verge into HP territory. So I shall clarify my +1 >> to say that I always want a cabal-install executable with my GHC, but it >> would be good to hear from people who really don't want that extra baggage. > > > For me it would mean duplication. Whenever I install GHC I already have a > running cabal-install and I can install a new one, if a new version of > cabal-install is released. > > I think the banner above the GHC download page makes pretty clear, that the > binary GHC tarball is not intended for comfort use. Maybe the banner can be > extended by a hint, where cabal-install executables can be downloaded. I think I prefer this approach. Especially since "automatically download the latest cabal-install available" might lead to the installer being run some time in the future and getting a version of cabal-install that only works with newer versions of GHC and thus you get something that can't work anyway. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From voldermort at hotmail.com Tue Jan 21 08:42:09 2014 From: voldermort at hotmail.com (harry) Date: Tue, 21 Jan 2014 00:42:09 -0800 (PST) Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> Message-ID: <1390293729166-5742615.post@n5.nabble.com> Agreed. The significant barrier here isn't that cabal-install isn't delivered with GHC (that's HP's job), it's that there isn't a pre-build binary for linux at all, and that the binaries aren't linked to from the GHC download site. -- View this message in context: http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742544p5742615.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From ganesh at earth.li Tue Jan 21 19:22:48 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue, 21 Jan 2014 19:22:48 +0000 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: <52DEC908.70806@earth.li> I feel this blurs the roles of GHC and the Platform. Can't the cabal-install that comes with the Platform can be used with a later GHC installation? If that's correct, then the only use case that this proposal covers is someone who wants to use a bleeding edge GHC and no other version on a new machine. A separate binary distribution of cabal-install should be more than adequate for that and it avoids coupling GHC to other things. So a weak -1. On 20/01/2014 00:02, Carter Schonwald wrote: > Hey everyone, > > I'd like to propose that GHC releases 7.8.1 onwards include a > cabal-install (aka cabal) executable, but not include the library deps > of cabal-install that aren't already distributed with ghc.(unless ghc > should have those deps baked in, which theres very very good reasons not > to do.). > > currently if someone wants just a basic haskell install of the freshest > ghc they have to install a ghc bindist, then do a boostrap build of > cabal-install by hand (if they want to actually get anything done :) ). > > This is not a human friendly situation for folks who are new to haskell > tooling, but want to try out haskell dev on a server style vm or the like! > > point being: It'd be great for haskell usability (and egads amounts of > config time, even by seasoned users) the ghc bindists / installers > included a cabal-install binary > > thoughts? > -Carter > > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From johan.tibell at gmail.com Tue Jan 21 19:32:19 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 21 Jan 2014 11:32:19 -0800 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <52DEC908.70806@earth.li> References: <52DEC908.70806@earth.li> Message-ID: We could offer OS X and Linux binaries in addition to the Windows binaries already downloaded on the cabal home page (http://www.haskell.org/cabal/) if someone could commit to building them. Aside: Right now building the Windows binaries is a very ad-hoc process (I email Mikhail who has a Windows machine and ask him to build one). I'm not very keen to make the process even slower, given that that will mean I will make fewer cabal releases. Ideally the binaries could be produced on a build bot. The very least we should have the Makefile in the cabal repo being able to create the binary in a reproducible manner. -- Johan On Tue, Jan 21, 2014 at 11:22 AM, Ganesh Sittampalam wrote: > I feel this blurs the roles of GHC and the Platform. > > Can't the cabal-install that comes with the Platform can be used with a > later GHC installation? If that's correct, then the only use case that > this proposal covers is someone who wants to use a bleeding edge GHC and > no other version on a new machine. A separate binary distribution of > cabal-install should be more than adequate for that and it avoids > coupling GHC to other things. > > So a weak -1. > > > On 20/01/2014 00:02, Carter Schonwald wrote: > > Hey everyone, > > > > I'd like to propose that GHC releases 7.8.1 onwards include a > > cabal-install (aka cabal) executable, but not include the library deps > > of cabal-install that aren't already distributed with ghc.(unless ghc > > should have those deps baked in, which theres very very good reasons not > > to do.). > > > > currently if someone wants just a basic haskell install of the freshest > > ghc they have to install a ghc bindist, then do a boostrap build of > > cabal-install by hand (if they want to actually get anything done :) ). > > > > This is not a human friendly situation for folks who are new to haskell > > tooling, but want to try out haskell dev on a server style vm or the > like! > > > > point being: It'd be great for haskell usability (and egads amounts of > > config time, even by seasoned users) the ghc bindists / installers > > included a cabal-install binary > > > > thoughts? > > -Carter > > > > > > > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh at earth.li Tue Jan 21 20:44:52 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue, 21 Jan 2014 20:44:52 +0000 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: <52DEC908.70806@earth.li> Message-ID: <52DEDC44.70209@earth.li> If you can't find any better options, I can try to run a buildbot on a laptop that's probably mostly online. On 21/01/2014 19:32, Johan Tibell wrote: > We could offer OS X and Linux binaries in addition to the Windows > binaries already downloaded on the cabal home page > (http://www.haskell.org/cabal/) if someone could commit to building them. > > Aside: Right now building the Windows binaries is a very ad-hoc process > (I email Mikhail who has a Windows machine and ask him to build one). > I'm not very keen to make the process even slower, given that that will > mean I will make fewer cabal releases. Ideally the binaries could be > produced on a build bot. The very least we should have the Makefile in > the cabal repo being able to create the binary in a reproducible manner. > > -- Johan > > > > On Tue, Jan 21, 2014 at 11:22 AM, Ganesh Sittampalam > wrote: > > I feel this blurs the roles of GHC and the Platform. > > Can't the cabal-install that comes with the Platform can be used with a > later GHC installation? If that's correct, then the only use case that > this proposal covers is someone who wants to use a bleeding edge GHC and > no other version on a new machine. A separate binary distribution of > cabal-install should be more than adequate for that and it avoids > coupling GHC to other things. > > So a weak -1. > > > On 20/01/2014 00:02, Carter Schonwald wrote: > > Hey everyone, > > > > I'd like to propose that GHC releases 7.8.1 onwards include a > > cabal-install (aka cabal) executable, but not include the library deps > > of cabal-install that aren't already distributed with ghc.(unless ghc > > should have those deps baked in, which theres very very good > reasons not > > to do.). > > > > currently if someone wants just a basic haskell install of the > freshest > > ghc they have to install a ghc bindist, then do a boostrap build of > > cabal-install by hand (if they want to actually get anything done > :) ). > > > > This is not a human friendly situation for folks who are new to > haskell > > tooling, but want to try out haskell dev on a server style vm or > the like! > > > > point being: It'd be great for haskell usability (and egads amounts of > > config time, even by seasoned users) the ghc bindists / installers > > included a cabal-install binary > > > > thoughts? > > -Carter > > > > > > > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > From carter.schonwald at gmail.com Tue Jan 21 21:47:44 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 21 Jan 2014 16:47:44 -0500 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <52DEDC44.70209@earth.li> References: <52DEC908.70806@earth.li> <52DEDC44.70209@earth.li> Message-ID: Ok, so either a) provide a ghc + cabal-install binary included (heck, its easy to update to a cabal install anyways, and the ~/.cabal/bin path will be before wherever the ghc pkgs are installed anyways. The same argument could be made for packaging happy and alex with ghc too! ). After all, i already have a happy / alex from cabal-installing them from earlier, why should ghc install it again? :p b) either way, perhaps the cabal-install devs/maintainers should standardize making some binaries available On Tue, Jan 21, 2014 at 3:44 PM, Ganesh Sittampalam wrote: > If you can't find any better options, I can try to run a buildbot on a > laptop that's probably mostly online. > > > On 21/01/2014 19:32, Johan Tibell wrote: > > We could offer OS X and Linux binaries in addition to the Windows > > binaries already downloaded on the cabal home page > > (http://www.haskell.org/cabal/) if someone could commit to building > them. > > > > Aside: Right now building the Windows binaries is a very ad-hoc process > > (I email Mikhail who has a Windows machine and ask him to build one). > > I'm not very keen to make the process even slower, given that that will > > mean I will make fewer cabal releases. Ideally the binaries could be > > produced on a build bot. The very least we should have the Makefile in > > the cabal repo being able to create the binary in a reproducible manner. > > > > -- Johan > > > > > > > > On Tue, Jan 21, 2014 at 11:22 AM, Ganesh Sittampalam > > wrote: > > > > I feel this blurs the roles of GHC and the Platform. > > > > Can't the cabal-install that comes with the Platform can be used > with a > > later GHC installation? If that's correct, then the only use case > that > > this proposal covers is someone who wants to use a bleeding edge GHC > and > > no other version on a new machine. A separate binary distribution of > > cabal-install should be more than adequate for that and it avoids > > coupling GHC to other things. > > > > So a weak -1. > > > > > > On 20/01/2014 00:02, Carter Schonwald wrote: > > > Hey everyone, > > > > > > I'd like to propose that GHC releases 7.8.1 onwards include a > > > cabal-install (aka cabal) executable, but not include the library > deps > > > of cabal-install that aren't already distributed with ghc.(unless > ghc > > > should have those deps baked in, which theres very very good > > reasons not > > > to do.). > > > > > > currently if someone wants just a basic haskell install of the > > freshest > > > ghc they have to install a ghc bindist, then do a boostrap build > of > > > cabal-install by hand (if they want to actually get anything done > > :) ). > > > > > > This is not a human friendly situation for folks who are new to > > haskell > > > tooling, but want to try out haskell dev on a server style vm or > > the like! > > > > > > point being: It'd be great for haskell usability (and egads > amounts of > > > config time, even by seasoned users) the ghc bindists / installers > > > included a cabal-install binary > > > > > > thoughts? > > > -Carter > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Libraries mailing list > > > Libraries at haskell.org > > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Jan 22 08:57:45 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 22 Jan 2014 09:57:45 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <52DEC908.70806@earth.li> (Ganesh Sittampalam's message of "Tue, 21 Jan 2014 19:22:48 +0000") References: <52DEC908.70806@earth.li> Message-ID: <874n4w2y2e.fsf@gnu.org> On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: > I feel this blurs the roles of GHC and the Platform. IMO, that's a weak argument, as the roles are already blurred: GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be provided by the HP instead. Moreover, GHC ships with a set of base libraries (which, and thus effectively GHC forces 20 or so packages (fixed to specific package versions) into the HP and takes away authority from the HP release process. But now the difficult to explain thing is that GHC also bundles the library part of CABAL but deliberately leaves out CABAL's frontend tool `cabal-install` only to justify the existence of the HP a bit more? :-) Cheers, hvr From schlepptop at henning-thielemann.de Wed Jan 22 09:08:02 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed, 22 Jan 2014 10:08:02 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <874n4w2y2e.fsf@gnu.org> References: <52DEC908.70806@earth.li> <874n4w2y2e.fsf@gnu.org> Message-ID: <52DF8A72.1000003@henning-thielemann.de> Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel: > On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: >> I feel this blurs the roles of GHC and the Platform. > > IMO, that's a weak argument, as the roles are already blurred: > GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be > provided by the HP instead. At least haddock is bound to the specific GHC version. I don't know how strict is the relation between hp2ps and hpc and GHC. Cabal-install on the other hand can be exchanged. > Moreover, GHC ships with a set of base > libraries (which, and thus effectively GHC forces 20 or so packages > (fixed to specific package versions) into the HP and takes away > authority from the HP release process. Yes, that's unfortunate. My prefered solution would be that GHC is only shipped with package 'ghc', whereas 'base', 'Cabal', 'containers' et.al. can be built by the user. Btw. on Debian/Ubuntu I can install cabal-install from the distribution repositories. With this one I can build newer versions of cabal-install. From marlowsd at gmail.com Wed Jan 22 09:25:24 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 22 Jan 2014 09:25:24 +0000 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <1390293729166-5742615.post@n5.nabble.com> References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> <1390293729166-5742615.post@n5.nabble.com> Message-ID: <52DF8E84.1080100@gmail.com> On 21/01/2014 08:42, harry wrote: > Agreed. The significant barrier here isn't that cabal-install isn't delivered > with GHC (that's HP's job), it's that there isn't a pre-build binary for > linux at all, and that the binaries aren't linked to from the GHC download > site. Your Linux distro already provides a cabal-install that will work with the latest GHC, just "apt-get install cabal" or equivalent, then "cabal install cabal-install" to update it if necessary. Cheers, Simon From haskell-oren at ben-kiki.org Wed Jan 22 10:02:46 2014 From: haskell-oren at ben-kiki.org (Oren Ben-Kiki) Date: Wed, 22 Jan 2014 12:02:46 +0200 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <52DF8E84.1080100@gmail.com> References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> <1390293729166-5742615.post@n5.nabble.com> <52DF8E84.1080100@gmail.com> Message-ID: I don't think that "apt-get install cabal" actually solves the core issue that sparked this thread for several reasons. As someone who had to install GHC from scratch without having sudo access on a (non-Debian) machine, I can testify that the fact that the cabal binary is not part of the GHC distribution, and doesn't have an easily located downloadable binary, has caused me a lot of trouble. AFAIK there isn't any clear description of how someone is supposed to deal with such a situation (unless something has been added in the past year). For example, The problem of handling the distro's package manager (whatever it is) with a language's package is a separate and thorny issue, which I think can't be "perfectly" solved short of unrealistic rewrite-the-world solutions. E.g., what happens if you do apt-get install cabal" and then use cabal to update itself to the newest version? What happens if you then "apt-get upgrade" and there's a newer version than the one apt installed, but it is older than the one you installed manually? etc. I think that "something" need to be done to make it easier to set up GHC + cabal, independently of HP (unless HP becomes the "one true way" to install Haskell, which I doubt is the case). On Wed, Jan 22, 2014 at 11:25 AM, Simon Marlow wrote: > On 21/01/2014 08:42, harry wrote: > >> Agreed. The significant barrier here isn't that cabal-install isn't >> delivered >> with GHC (that's HP's job), it's that there isn't a pre-build binary for >> linux at all, and that the binaries aren't linked to from the GHC download >> site. >> > > Your Linux distro already provides a cabal-install that will work with the > latest GHC, just "apt-get install cabal" or equivalent, then "cabal install > cabal-install" to update it if necessary. > > Cheers, > Simon > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Jan 22 11:55:53 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 22 Jan 2014 12:55:53 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <52DF8A72.1000003@henning-thielemann.de> (Henning Thielemann's message of "Wed, 22 Jan 2014 10:08:02 +0100") References: <52DEC908.70806@earth.li> <874n4w2y2e.fsf@gnu.org> <52DF8A72.1000003@henning-thielemann.de> Message-ID: <87ppnk1b92.fsf@gnu.org> On 2014-01-22 at 10:08:02 +0100, Henning Thielemann wrote: > Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel: >> On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: >>> I feel this blurs the roles of GHC and the Platform. >> >> IMO, that's a weak argument, as the roles are already blurred: > >> GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be >> provided by the HP instead. > > At least haddock is bound to the specific GHC version. When I look at http://hackage.haskell.org/package/haddock, there are multiple versions, 2.12.0 and the 4 versions of 2.13.*, which are all declared to work with ghc == 7.6.*, that is, 5 haddock versions compatible with 3 released versions of GHC 7.6. So while it may be bound to a major version of the GHC API, haddock can obviously have more releases than GHC has releases (otherwise it could just carry GHC's version), and can therefore be updated. From roma at ro-che.info Wed Jan 22 12:22:41 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 22 Jan 2014 14:22:41 +0200 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <87ppnk1b92.fsf@gnu.org> References: <52DEC908.70806@earth.li> <874n4w2y2e.fsf@gnu.org> <52DF8A72.1000003@henning-thielemann.de> <87ppnk1b92.fsf@gnu.org> Message-ID: <20140122122241.GA25668@sniper> * Herbert Valerio Riedel [2014-01-22 12:55:53+0100] > On 2014-01-22 at 10:08:02 +0100, Henning Thielemann wrote: > > Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel: > >> On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: > >>> I feel this blurs the roles of GHC and the Platform. > >> > >> IMO, that's a weak argument, as the roles are already blurred: > > > >> GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be > >> provided by the HP instead. > > > > At least haddock is bound to the specific GHC version. > > When I look at http://hackage.haskell.org/package/haddock, there are > multiple versions, 2.12.0 and the 4 versions of 2.13.*, which are all > declared to work with ghc == 7.6.*, that is, 5 haddock versions > compatible with 3 released versions of GHC 7.6. So while it may be bound > to a major version of the GHC API, haddock can obviously have more > releases than GHC has releases (otherwise it could just carry GHC's > version), and can therefore be updated. Henning could be more specific in his claim that "haddock is bound to the specific GHC version". I guess he's referring to the binary rather than source distribution's compatibility. Assuming static linking w.r.t. the ghc package, the incompatibility with a different GHC version could still arise from the fact that haddock (as any other GHC API using application, I suppose) makes use of the GHC's lib directory, although I don't know the details. If we are talking about installing haddock from source (using cabal-install), then it should be no different from installing, say, ghc-mod. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From schlepptop at henning-thielemann.de Wed Jan 22 13:29:47 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed, 22 Jan 2014 14:29:47 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <20140122122241.GA25668@sniper> References: <52DEC908.70806@earth.li> <874n4w2y2e.fsf@gnu.org> <52DF8A72.1000003@henning-thielemann.de> <87ppnk1b92.fsf@gnu.org> <20140122122241.GA25668@sniper> Message-ID: <52DFC7CB.70903@henning-thielemann.de> Am 22.01.2014 13:22, schrieb Roman Cheplyaka: > * Herbert Valerio Riedel [2014-01-22 12:55:53+0100] >> >> When I look at http://hackage.haskell.org/package/haddock, there are >> multiple versions, 2.12.0 and the 4 versions of 2.13.*, which are all >> declared to work with ghc == 7.6.*, that is, 5 haddock versions >> compatible with 3 released versions of GHC 7.6. So while it may be bound >> to a major version of the GHC API, haddock can obviously have more >> releases than GHC has releases (otherwise it could just carry GHC's >> version), and can therefore be updated. > > Henning could be more specific in his claim that "haddock is bound to > the specific GHC version". What I mean is: The Haddock that comes with GHC has a name like haddock-ghc-7.6.3 and when I (cabal-)install a package with a certain GHC versions then the haddock-ghc according to the ghc version is chosen. If I install a package for different GHC versions then I get a warning that the global haddock database version does not match the one of the GHC version used for the particular package. Now, I become uncertain whether this is an argument pro or contra including Haddock in the binary GHC tarball. From johan.tibell at gmail.com Wed Jan 22 15:45:21 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 22 Jan 2014 07:45:21 -0800 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <874n4w2y2e.fsf@gnu.org> References: <52DEC908.70806@earth.li> <874n4w2y2e.fsf@gnu.org> Message-ID: On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel wrote: > On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: > > I feel this blurs the roles of GHC and the Platform. > > IMO, that's a weak argument, as the roles are already blurred: > > GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be > provided by the HP instead. Moreover, GHC ships with a set of base > libraries (which, and thus effectively GHC forces 20 or so packages > (fixed to specific package versions) into the HP and takes away > authority from the HP release process. But now the difficult to explain > thing is that GHC also bundles the library part of CABAL but > deliberately leaves out CABAL's frontend tool `cabal-install` only to > justify the existence of the HP a bit more? :-) > Cabal is part of GHC's build process and GHC uses data types from Cabal. That's why it's there. It's not because we want Cabal to be included (just like we don't want to ship those libs.) These are technical limitations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Jan 22 16:18:08 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 22 Jan 2014 11:18:08 -0500 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: <52DEC908.70806@earth.li> <874n4w2y2e.fsf@gnu.org> Message-ID: ANYWAYS :) the point is: there is a nonzero population of haskell folks who want to use ghc + cabal-install on a machine where they may not have admin / package manager powers, AND it requires some amount of cabal-install familiarity (or asking around) to find out about the ./boot-strap script that cabal comes with. (I've definitely had 1-2 incidents where on a new server i did the bootstrap process by hand before i found out about that script) at the very very least, the directions for boostrap cabal-install should be more discoverable On Wed, Jan 22, 2014 at 10:45 AM, Johan Tibell wrote: > On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel wrote: > >> On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: >> > I feel this blurs the roles of GHC and the Platform. >> >> IMO, that's a weak argument, as the roles are already blurred: >> >> GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be >> provided by the HP instead. Moreover, GHC ships with a set of base >> libraries (which, and thus effectively GHC forces 20 or so packages >> (fixed to specific package versions) into the HP and takes away >> authority from the HP release process. But now the difficult to explain >> thing is that GHC also bundles the library part of CABAL but >> deliberately leaves out CABAL's frontend tool `cabal-install` only to >> justify the existence of the HP a bit more? :-) >> > > Cabal is part of GHC's build process and GHC uses data types from Cabal. > That's why it's there. It's not because we want Cabal to be included (just > like we don't want to ship those libs.) These are technical limitations. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslatter at gmail.com Thu Jan 23 04:06:21 2014 From: aslatter at gmail.com (Antoine Latter) Date: Wed, 22 Jan 2014 22:06:21 -0600 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> <1390293729166-5742615.post@n5.nabble.com> <52DF8E84.1080100@gmail.com> Message-ID: On Wed, Jan 22, 2014 at 4:02 AM, Oren Ben-Kiki wrote > > > For example, The problem of handling the distro's package manager > (whatever it is) with a language's package is a separate and thorny issue, > which I think can't be "perfectly" solved short of unrealistic > rewrite-the-world solutions. E.g., what happens if you do apt-get install > cabal" and then use cabal to update itself to the newest version? What > happens if you then "apt-get upgrade" and there's a newer version than the > one apt installed, but it is older than the one you installed manually? etc. > > I do this all the time and haven't ran into a problem yet. Is there something in particular you expect to break? I install GHC from my distro database and use that to bootstrap my way into whatever Haskell dev environment I feel is suitable. At the moment that looks like "sudo apt-get install cabal-install" (or whatever the appropriate syntax is) followed by "cabal update && cabal install cabal-install". I guess this would break if Debian slipped in a new version of GHC behind my back, but they're pretty cautious about that sort of thing, and the fix would be re-building my user-install of cabal-install. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Thu Jan 23 04:24:13 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 23 Jan 2014 15:24:13 +1100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> <1390293729166-5742615.post@n5.nabble.com> <52DF8E84.1080100@gmail.com> Message-ID: On 23 January 2014 15:06, Antoine Latter wrote: > On Wed, Jan 22, 2014 at 4:02 AM, Oren Ben-Kiki > wrote >> >> >> For example, The problem of handling the distro's package manager >> (whatever it is) with a language's package is a separate and thorny issue, >> which I think can't be "perfectly" solved short of unrealistic >> rewrite-the-world solutions. E.g., what happens if you do apt-get install >> cabal" and then use cabal to update itself to the newest version? What >> happens if you then "apt-get upgrade" and there's a newer version than the >> one apt installed, but it is older than the one you installed manually? etc. >> > > I do this all the time and haven't ran into a problem yet. Is there > something in particular you expect to break? > > I install GHC from my distro database and use that to bootstrap my way into > whatever Haskell dev environment I feel is suitable. > > At the moment that looks like "sudo apt-get install cabal-install" (or > whatever the appropriate syntax is) followed by "cabal update && cabal > install cabal-install". > > I guess this would break if Debian slipped in a new version of GHC behind my > back, but they're pretty cautious about that sort of thing, and the fix > would be re-building my user-install of cabal-install. I think the issue here is that we typically put "$HOME/.cabal/bin" at the front of our PATH so that we get the "new" cabal-install that we received from "cabal install cabal-instal"... but if the distro updates it to an even newer version, we won't see that newer version as it's located later in the PATH, and thus we can't rely on our distro packagers to figure out when there's a newer version of various utilities. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From voldermort at hotmail.com Thu Jan 23 08:07:33 2014 From: voldermort at hotmail.com (harry) Date: Thu, 23 Jan 2014 00:07:33 -0800 (PST) Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> <1390293729166-5742615.post@n5.nabble.com> <52DF8E84.1080100@gmail.com> Message-ID: <1390464453869-5742716.post@n5.nabble.com> Ivan Lazar Miljenovic wrote > I think the issue here is that we typically put "$HOME/.cabal/bin" at > the front of our PATH so that we get the "new" cabal-install that we > received from "cabal install cabal-instal"... but if the distro > updates it to an even newer version, we won't see that newer version > as it's located later in the PATH, and thus we can't rely on our > distro packagers to figure out when there's a newer version of various > utilities. I've been having the opposite problem with HP - it puts the global bindir before the user bindir. Took me a while the first time to work out why cabal install cabal-install always succeeded, but cabal install still complained about being outdated. -- View this message in context: http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742544p5742716.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From haskell at nand.wakku.to Fri Jan 24 21:42:41 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Fri, 24 Jan 2014 22:42:41 +0100 Subject: [Proposal] Add default implementation of mappend/mempty in terms of mconcat Message-ID: <20140124224241.GA5255@nanodesu.talocan.mine.nu> Hello, I noticed that the current Monoid class doesn't actually provide default implementations of mappend/mempty in terms of mconcat, even though this is technically very simple: > mempty = mconcat [] > mappend a b = mconcat [a, b] This would be a rather small and non-invasive change that shouldn't break any existing programs. The main downside is that an empty Monoid declaration would produce no warnings, but #7633 gives us the ability to solve this. Discussion period: 2 weeks From ganesh at earth.li Sat Jan 25 17:59:43 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat, 25 Jan 2014 17:59:43 +0000 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> <1390293729166-5742615.post@n5.nabble.com> <52DF8E84.1080100@gmail.com> Message-ID: <52E3FB8F.3030106@earth.li> > I think that "something" need to be done to make it easier to set up > GHC + cabal, independently of HP (unless HP becomes the "one true > way" to install Haskell, which I doubt is the case). Isn't that what this banner on http://www.haskell.org/ghc/download_ghc_7_6_3 is supposed to signify? "Stop! For most users, we recommend installing the Haskell Platform instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together." For the people who want GHC to include cabal-install, what are the obstacles to using the Haskell Platform instead? One possibility I can see is disk space. The other reason, raised by Carter at the start of this thread, is wanting to use the freshest GHC. Cheers, Ganesh From carter.schonwald at gmail.com Sat Jan 25 18:27:03 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 25 Jan 2014 13:27:03 -0500 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <52E3FB8F.3030106@earth.li> References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> <1390293729166-5742615.post@n5.nabble.com> <52DF8E84.1080100@gmail.com> <52E3FB8F.3030106@earth.li> Message-ID: the point is: there should be some *easy* way to get/install cabal-install binaries for those who aren't in a situation where haskell platform is appropriate. I generally regard haskell platform as "for students", "people with enterprise support cycles" and "oh shit, my haskelll install is borked and i need to get things working again right nowwwwww". I understand that certain distros/package managers regard it as a stable substrate (rightfully, cf my remark about support cycles). But that doesn't preclude people from doing their own setup, and if that is common place (as I believe it is, though i've not done a survey), having binaries at are easy to install is a reasonable goal! -Carter On Sat, Jan 25, 2014 at 12:59 PM, Ganesh Sittampalam wrote: > > I think that "something" need to be done to make it easier to set up > > GHC + cabal, independently of HP (unless HP becomes the "one true > > way" to install Haskell, which I doubt is the case). > > Isn't that what this banner on > http://www.haskell.org/ghc/download_ghc_7_6_3 is supposed to signify? > > "Stop! > > For most users, we recommend installing the Haskell Platform instead of > GHC. The current Haskell Platform release includes a recent GHC release > as well as some other tools (such as cabal), and a larger set of > libraries that are known to work together." > > For the people who want GHC to include cabal-install, what are the > obstacles to using the Haskell Platform instead? > > One possibility I can see is disk space. The other reason, raised by > Carter at the start of this thread, is wanting to use the freshest GHC. > > Cheers, > > Ganesh > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From glaebhoerl at gmail.com Sat Jan 25 18:48:05 2014 From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sat, 25 Jan 2014 19:48:05 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: +1 to this proposal. The benefits are obvious and practical: when installing a new GHC, it will save users the tedium of having to figure out how to build a cabal-install and then do so before they can install the packages they actually want. The drawbacks are indefinite and amorphous: the download is a little bit larger. So what? It further blurs the line between GHC and the Platform. Who does this harm? People who already have a cabal-install will now have a second one. What discomfort will this cause them? On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Hey everyone, > > I'd like to propose that GHC releases 7.8.1 onwards include a > cabal-install (aka cabal) executable, but not include the library deps of > cabal-install that aren't already distributed with ghc.(unless ghc should > have those deps baked in, which theres very very good reasons not to do.). > > currently if someone wants just a basic haskell install of the freshest > ghc they have to install a ghc bindist, then do a boostrap build of > cabal-install by hand (if they want to actually get anything done :) ). > > This is not a human friendly situation for folks who are new to haskell > tooling, but want to try out haskell dev on a server style vm or the like! > > point being: It'd be great for haskell usability (and egads amounts of > config time, even by seasoned users) the ghc bindists / installers included > a cabal-install binary > > thoughts? > -Carter > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh at earth.li Sat Jan 25 21:44:44 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat, 25 Jan 2014 21:44:44 +0000 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> <1390293729166-5742615.post@n5.nabble.com> <52DF8E84.1080100@gmail.com> <52E3FB8F.3030106@earth.li> Message-ID: <52E4304C.7080800@earth.li> I guess my point is that the platform should be suitable for almost everyone. That was certainly the way I perceived the intention when it was first launched. How about just extracting the latest cabal binaries from the Platform after each release and making them available for separate download? That way there's no extra burden on the cabal or GHC maintainers and no need to solve the general problem of making more frequent cabal binary distributions. On 25/01/2014 18:27, Carter Schonwald wrote: > the point is: there should be some *easy* way to get/install > cabal-install binaries for those who aren't in a situation where haskell > platform is appropriate. > > I generally regard haskell platform as "for students", "people with > enterprise support cycles" and "oh shit, my haskelll install is borked > and i need to get things working again right nowwwwww". I understand > that certain distros/package managers regard it as a stable substrate > (rightfully, cf my remark about support cycles). > > But that doesn't preclude people from doing their own setup, and if that > is common place (as I believe it is, though i've not done a survey), > having binaries at are easy to install is a reasonable goal! > > -Carter > > > On Sat, Jan 25, 2014 at 12:59 PM, Ganesh Sittampalam > wrote: > > > I think that "something" need to be done to make it easier to set up > > GHC + cabal, independently of HP (unless HP becomes the "one true > > way" to install Haskell, which I doubt is the case). > > Isn't that what this banner on > http://www.haskell.org/ghc/download_ghc_7_6_3 is supposed to signify? > > "Stop! > > For most users, we recommend installing the Haskell Platform instead of > GHC. The current Haskell Platform release includes a recent GHC release > as well as some other tools (such as cabal), and a larger set of > libraries that are known to work together." > > For the people who want GHC to include cabal-install, what are the > obstacles to using the Haskell Platform instead? > > One possibility I can see is disk space. The other reason, raised by > Carter at the start of this thread, is wanting to use the freshest GHC. > > Cheers, > > Ganesh > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From haskell at benmachine.co.uk Sat Jan 25 22:06:24 2014 From: haskell at benmachine.co.uk (Ben Millwood) Date: Sat, 25 Jan 2014 22:06:24 +0000 Subject: [Proposal] Add default implementation of mappend/mempty in terms of mconcat In-Reply-To: <20140124224241.GA5255@nanodesu.talocan.mine.nu> References: <20140124224241.GA5255@nanodesu.talocan.mine.nu> Message-ID: <20140125220624.GA961@srcf.ucam.org> I'm not sure how I feel about the proposal, but I'd just like to add that in fact the laws for Monoid can also be expressed in terms of mconcat: mconcat [x] = x mconcat . concat = mconcat . map mconcat (for those who appreciate that sort of thing, these are the laws for mconcat to be a monad algebra for the list monad). On Fri, Jan 24, 2014 at 10:42:41PM +0100, Niklas Haas wrote: >Hello, > >I noticed that the current Monoid class doesn't actually provide default >implementations of mappend/mempty in terms of mconcat, even though this >is technically very simple: > >> mempty = mconcat [] >> mappend a b = mconcat [a, b] > >This would be a rather small and non-invasive change that shouldn't >break any existing programs. The main downside is that an empty Monoid >declaration would produce no warnings, but #7633 gives us the ability to >solve this. > >Discussion period: 2 weeks >_______________________________________________ >Libraries mailing list >Libraries at haskell.org >http://www.haskell.org/mailman/listinfo/libraries From allbery.b at gmail.com Sat Jan 25 22:39:51 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 25 Jan 2014 17:39:51 -0500 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <52E4304C.7080800@earth.li> References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> <1390293729166-5742615.post@n5.nabble.com> <52DF8E84.1080100@gmail.com> <52E3FB8F.3030106@earth.li> <52E4304C.7080800@earth.li> Message-ID: On Sat, Jan 25, 2014 at 4:44 PM, Ganesh Sittampalam wrote: > I guess my point is that the platform should be suitable for almost > everyone. That was certainly the way I perceived the intention when it > was first launched. > It's supposed to be suitable for the average user. This tends to exclude people working in various restricted settings (such as small hosted containers, or servers where the UI libraries the Platform offers are not available and not useful) and developers working at the bleeding edge, etc. "Almost everyone" is almost impossible. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Sun Jan 26 08:40:19 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 26 Jan 2014 09:40:19 +0100 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: <52E4304C.7080800@earth.li> (Ganesh Sittampalam's message of "Sat, 25 Jan 2014 21:44:44 +0000") References: <545ACB1D-784F-4D92-A320-91934FDA1471@seas.upenn.edu> <52DD5752.2060500@henning-thielemann.de> <1390293729166-5742615.post@n5.nabble.com> <52DF8E84.1080100@gmail.com> <52E3FB8F.3030106@earth.li> <52E4304C.7080800@earth.li> Message-ID: <87wqhn5e6k.fsf@gnu.org> Hello Ganesh, On 2014-01-25 at 22:44:44 +0100, Ganesh Sittampalam wrote: > How about just extracting the latest cabal binaries from the Platform > after each release and making them available for separate download? > > That way there's no extra burden on the cabal or GHC maintainers and no > need to solve the general problem of making more frequent cabal binary > distributions. Btw, unless I'm missing something, from http://www.haskell.org/platform/linux.html it doesn't look like there's a binary tar-ball distribution of the HP for Linux in the style of the GHC binary distribution tarballs, from which the executable could be extracted. What's more, the page refers to distribution-specific packages, which potentially lag behind wrt to the latest released HP version, and they don't allow for parallel installs of multiple HP versions (as opposed to the GHC binary tarball distributions) Greetings, hvr From austin at well-typed.com Mon Jan 27 00:39:32 2014 From: austin at well-typed.com (Austin Seipp) Date: Sun, 26 Jan 2014 18:39:32 -0600 Subject: RFC: include a cabal-install executable in future GHC releases In-Reply-To: References: Message-ID: Hello, My input is this: I think a lot of confusion stems from some documentation that just needs to be cleared up. I think that just cleaning up the pages so that: * http://www.haskell.org/cabal has binaries for Tier 1 platforms: OS X, Windows, FreeBSD i386/amd64, Linux i386/amd64. IMO, there should be a clear 'Download pre-built binaries' on the immediate front page that cannot be missed. * http://www.haskell.org/ghc/download still points to the platform for most users (i.e. the platform is more long-term stable/supported,) but also mentions cabal install binaries. They can be linked to directly from the subsection for each platform: "Download GHC 7.8.1 Mac OS X x86-64 - also download from here" I personally think this would go a significant way to making it easier for people to bootstrap environments. (IMO, both the GHC and Cabal homepage could both do with a visual makeover as well, to make this all the more apparent and easily accessible.) As for cabal install binaries: I can easily provide dedicated hardware (thanks to Rackspace) for Windows, FreeBSD or Linux build machines. I also have a dedicated OS X machine in Oxford (thanks to Duncan) that can be used to build binaries for OS X as well. So I can absolutely provide resources for Cabal developers to build them if they'd like. At least for T1 platforms. As for shipping with GHC itself: this is technically possible, but slightly annoying to implement, and it also makes the build processes for a release slightly more annoying (which is mostly my problem.) But it is all doable. However, keep in mind I *do not* maintain the binary distributions for everything, nor do Cabal devs have access to all hardware - so all people making upstream releases for their platforms (i.e. Solaris, PowerPC, ARM/Linux, etc) must also package cabal themselves. But perhaps that's not a huge deal. I guess my vote on this is ultimately neutral. I think it can be fixed by simply making the downloads more clear. Alternatively we can package cabal-install. I'll leave the decision up to users at large and their votes. On Sun, Jan 26, 2014 at 7:08 AM, Daniil Frumin wrote: > cabal-install doesn't even have to be distributed in one tar.gz with > GHC, just merely mentioning cabal-install binaries on > http://www.haskell.org/ghc/download will surely help (assuming we get > to actually have the cabal-install binaries :) > > On Sat, Jan 25, 2014 at 10:48 PM, G?bor Lehel wrote: >> +1 to this proposal. The benefits are obvious and practical: when installing >> a new GHC, it will save users the tedium of having to figure out how to >> build a cabal-install and then do so before they can install the packages >> they actually want. The drawbacks are indefinite and amorphous: the download >> is a little bit larger. So what? It further blurs the line between GHC and >> the Platform. Who does this harm? People who already have a cabal-install >> will now have a second one. What discomfort will this cause them? >> >> >> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald >> wrote: >>> >>> Hey everyone, >>> >>> I'd like to propose that GHC releases 7.8.1 onwards include a >>> cabal-install (aka cabal) executable, but not include the library deps of >>> cabal-install that aren't already distributed with ghc.(unless ghc should >>> have those deps baked in, which theres very very good reasons not to do.). >>> >>> currently if someone wants just a basic haskell install of the freshest >>> ghc they have to install a ghc bindist, then do a boostrap build of >>> cabal-install by hand (if they want to actually get anything done :) ). >>> >>> This is not a human friendly situation for folks who are new to haskell >>> tooling, but want to try out haskell dev on a server style vm or the like! >>> >>> point being: It'd be great for haskell usability (and egads amounts of >>> config time, even by seasoned users) the ghc bindists / installers included >>> a cabal-install binary >>> >>> thoughts? >>> -Carter >>> >>> >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > > -- > Sincerely yours, > -- Daniil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From sjoerd at w3future.com Mon Jan 27 10:42:32 2014 From: sjoerd at w3future.com (Sjoerd Visscher) Date: Mon, 27 Jan 2014 11:42:32 +0100 Subject: [Proposal] Add default implementation of mappend/mempty in terms of mconcat In-Reply-To: <20140124224241.GA5255@nanodesu.talocan.mine.nu> References: <20140124224241.GA5255@nanodesu.talocan.mine.nu> Message-ID: This seems rather pointless; I?m having trouble coming up with an example where mconcat would be easier or more elegant to implement. Do you have an example? On 24 Jan 2014, at 22:42, Niklas Haas wrote: > Hello, > > I noticed that the current Monoid class doesn't actually provide default > implementations of mappend/mempty in terms of mconcat, even though this > is technically very simple: > >> mempty = mconcat [] >> mappend a b = mconcat [a, b] > > This would be a rather small and non-invasive change that shouldn't > break any existing programs. The main downside is that an empty Monoid > declaration would produce no warnings, but #7633 gives us the ability to > solve this. > > Discussion period: 2 weeks > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries From mail at joachim-breitner.de Mon Jan 27 12:23:08 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Jan 2014 12:23:08 +0000 Subject: [Proposal] Add default implementation of mappend/mempty in terms of mconcat In-Reply-To: References: <20140124224241.GA5255@nanodesu.talocan.mine.nu> Message-ID: <1390825388.2549.9.camel@kirk> Hi, Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher: > This seems rather pointless; I?m having trouble coming up with an > example where mconcat would be easier or more elegant to implement. Do > you have an example? maybe cases where you implement mconcat for performance reasons anyways (but are there good examples for that?), and then you don?t want to be bothered with the simple cases.... Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From schlepptop at henning-thielemann.de Mon Jan 27 12:26:59 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Mon, 27 Jan 2014 13:26:59 +0100 Subject: [Proposal] Add default implementation of mappend/mempty in terms of mconcat In-Reply-To: <1390825388.2549.9.camel@kirk> References: <20140124224241.GA5255@nanodesu.talocan.mine.nu> <1390825388.2549.9.camel@kirk> Message-ID: <52E65093.2010400@henning-thielemann.de> Am 27.01.2014 13:23, schrieb Joachim Breitner: > Hi, > > Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher: >> This seems rather pointless; I?m having trouble coming up with an >> example where mconcat would be easier or more elegant to implement. Do >> you have an example? > > maybe cases where you implement mconcat for performance reasons anyways > (but are there good examples for that?), I think it is useful to define a custom mconcat in cases where it matters whether it is a left or a right fold. > and then you don?t want to be bothered with the simple cases.... From fuuzetsu at fuuzetsu.co.uk Mon Jan 27 12:32:04 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 27 Jan 2014 12:32:04 +0000 Subject: [Proposal] Add default implementation of mappend/mempty in terms of mconcat In-Reply-To: <52E65093.2010400@henning-thielemann.de> References: <20140124224241.GA5255@nanodesu.talocan.mine.nu> <1390825388.2549.9.camel@kirk> <52E65093.2010400@henning-thielemann.de> Message-ID: <52E651C4.50500@fuuzetsu.co.uk> On 27/01/14 12:26, Henning Thielemann wrote: > Am 27.01.2014 13:23, schrieb Joachim Breitner: >> Hi, >> >> Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher: >>> This seems rather pointless; I?m having trouble coming up with an >>> example where mconcat would be easier or more elegant to implement. Do >>> you have an example? >> >> maybe cases where you implement mconcat for performance reasons anyways >> (but are there good examples for that?), > > I think it is useful to define a custom mconcat in cases where it > matters whether it is a left or a right fold. > > > and then you don?t want to be bothered with the simple cases.... > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > You can still define your own mconcat and not use the default definition. There's no case for this proposal from that aspect. -- Mateusz K. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Jan 27 13:29:28 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 27 Jan 2014 13:29:28 +0000 Subject: [Proposal] Add default implementation of mappend/mempty in terms of mconcat In-Reply-To: <52E651C4.50500@fuuzetsu.co.uk> References: <20140124224241.GA5255@nanodesu.talocan.mine.nu> <1390825388.2549.9.camel@kirk> <52E65093.2010400@henning-thielemann.de> <52E651C4.50500@fuuzetsu.co.uk> Message-ID: <20140127132928.GC28385@weber> On Mon, Jan 27, 2014 at 12:32:04PM +0000, Mateusz Kowalczyk wrote: > On 27/01/14 12:26, Henning Thielemann wrote: > > Am 27.01.2014 13:23, schrieb Joachim Breitner: > >> Hi, > >> > >> Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher: > >>> This seems rather pointless; I?m having trouble coming up with an > >>> example where mconcat would be easier or more elegant to implement. Do > >>> you have an example? > >> > >> maybe cases where you implement mconcat for performance reasons anyways > >> (but are there good examples for that?), > > > > I think it is useful to define a custom mconcat in cases where it > > matters whether it is a left or a right fold. > > > > > and then you don?t want to be bothered with the simple cases.... > > You can still define your own mconcat and not use the default > definition. There's no case for this proposal from that aspect. Sure, but if you are going to define your own mconcat for performance reasons, it would then be nice not to *have to* define your own mappend, or mempty. Tom From andreas.abel at ifi.lmu.de Mon Jan 27 14:56:57 2014 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Mon, 27 Jan 2014 15:56:57 +0100 Subject: [Proposal] Add default implementation of mappend/mempty in terms of mconcat In-Reply-To: <20140127132928.GC28385@weber> References: <20140124224241.GA5255@nanodesu.talocan.mine.nu> <1390825388.2549.9.camel@kirk> <52E65093.2010400@henning-thielemann.de> <52E651C4.50500@fuuzetsu.co.uk> <20140127132928.GC28385@weber> Message-ID: <52E673B9.1050209@ifi.lmu.de> +1 for the original proposal. These are valid default implementations. Nothing more to say. On 27.01.2014 14:29, Tom Ellis wrote: > On Mon, Jan 27, 2014 at 12:32:04PM +0000, Mateusz Kowalczyk wrote: >> On 27/01/14 12:26, Henning Thielemann wrote: >>> Am 27.01.2014 13:23, schrieb Joachim Breitner: >>>> Hi, >>>> >>>> Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher: >>>>> This seems rather pointless; I?m having trouble coming up with an >>>>> example where mconcat would be easier or more elegant to implement. Do >>>>> you have an example? >>>> >>>> maybe cases where you implement mconcat for performance reasons anyways >>>> (but are there good examples for that?), >>> >>> I think it is useful to define a custom mconcat in cases where it >>> matters whether it is a left or a right fold. >>> >>> > and then you don?t want to be bothered with the simple cases.... >> >> You can still define your own mconcat and not use the default >> definition. There's no case for this proposal from that aspect. > > Sure, but if you are going to define your own mconcat for performance > reasons, it would then be nice not to *have to* define your own mappend, or > mempty. > > Tom > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel at ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/ From fuuzetsu at fuuzetsu.co.uk Mon Jan 27 16:17:45 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 27 Jan 2014 16:17:45 +0000 Subject: [Proposal] Add default implementation of mappend/mempty in terms of mconcat In-Reply-To: <20140127132928.GC28385@weber> References: <20140124224241.GA5255@nanodesu.talocan.mine.nu> <1390825388.2549.9.camel@kirk> <52E65093.2010400@henning-thielemann.de> <52E651C4.50500@fuuzetsu.co.uk> <20140127132928.GC28385@weber> Message-ID: <52E686A9.5030106@fuuzetsu.co.uk> On 27/01/14 13:29, Tom Ellis wrote: > On Mon, Jan 27, 2014 at 12:32:04PM +0000, Mateusz Kowalczyk wrote: >> On 27/01/14 12:26, Henning Thielemann wrote: >>> Am 27.01.2014 13:23, schrieb Joachim Breitner: >>>> Hi, >>>> >>>> Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher: >>>>> This seems rather pointless; I?m having trouble coming up with an >>>>> example where mconcat would be easier or more elegant to implement. Do >>>>> you have an example? >>>> >>>> maybe cases where you implement mconcat for performance reasons anyways >>>> (but are there good examples for that?), >>> >>> I think it is useful to define a custom mconcat in cases where it >>> matters whether it is a left or a right fold. >>> >>> > and then you don?t want to be bothered with the simple cases.... >> >> You can still define your own mconcat and not use the default >> definition. There's no case for this proposal from that aspect. > > Sure, but if you are going to define your own mconcat for performance > reasons, it would then be nice not to *have to* define your own mappend, or > mempty. > > Tom > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > Oh, sorry, I haven't read the original post and jumped to conclusions. +1 from me -- Mateusz K. From petr.mvd at gmail.com Wed Jan 29 13:57:03 2014 From: petr.mvd at gmail.com (=?ISO-8859-1?Q?Petr_Pudl=E1k?=) Date: Wed, 29 Jan 2014 14:57:03 +0100 Subject: incorrect MonadPlus law "v >> mzero = mzero"? Message-ID: Hi, this law apparently fails for a MonadPlus instance that has more than one possible failure value. Consider: runIdentity . runErrorT $ ((ErrorT . Identity $ Left "failure") >> mzero :: ErrorT String Identity ()) evaluates to `Left "failure"`, which isn't equal to ErrorT's mzero `Left ""`. This isn't just the case of ErrorT, it fails for any MonadPlus with multiple failure values. For example lift (tell "foo") >> mzero :: MaybeT (Writer String) () is again distinct from mzero. Actually, no monad transformer with a MonadPlus instance can satisfy the law, because the first part in front of `>> mzero` can introduce side effects in the underlying monad. I'm not sure what should be the proper solution. Perhaps to change the laws to: return x >> mzero = mzero (v >> mzero) >>= f = (v >> mzero)` That is, if an expression ends with `mzero`, it behaves like `mzero`. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Jan 30 17:01:53 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 30 Jan 2014 12:01:53 -0500 Subject: [Haskell-cafe] Unmaintained packages and hackage upload rights In-Reply-To: <8761p1fm1n.fsf@gmail.com> References: <20140130163055.GA19868@sniper> <8761p1fm1n.fsf@gmail.com> Message-ID: I HAVE A SOLUTION for anyone who asks me, I will help manage the "this isn't maintained, i wanna take over maintership" pestering emails that need to happen. that said, you'll still need to email me to ask me to do that, or pester me on IRC as applicable. (which may take just as much time as "hey i'd like to take over maintainership of X on hackage please" sent to the libraries list) Point being, if someone finds the prospect of doing the pestering needed to do the process overwhelming, ask me nicely, and i'll try to help push it along (while keeping them in CC and such, though they of course will have to chime in at some point) should this thread also touch on the the libraries mailing list? ccing it just in case :) point being, we need to have a responsive, *responsible* way of quickly resolving these things that easy to do. time for comments: 2 weeks -Carter On Thu, Jan 30, 2014 at 11:53 AM, Ben Gamari wrote: > Clark Gaebel writes: > > > How does the process of taking over maintenance add latency to your work? > > > > 1) Check out broken version of package. > > 2) Fix locally, bump version number locally. > > 3) cabal sandbox add-source ../fixed-package in any package that needs > the > > fixed version. > > 4) Email hackage admins for upload rights. > > 5) Continue working on your actual project. > > 6) Receive upload privileges one day. > > 7) Upload fixed package. > > > > As far as I can tell, the only real latency cost here is that paid to fix > > the broken version. > > > In my experience, step 4 involved several round trips between a number > of different people. Admittedly, this is in part because it's easy to > forget about the broken package after you have fixed it locally. > > Cheers, > > - Ben > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: