- Libraries - Haskell.org

Re: [Haskell-cafe] Unmaintained packages and hackage upload rights
by Carter Schonwald 30 Jan '14

30 Jan '14

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 <bgamari.foss(a)gmail.com> wrote: > Clark Gaebel <cgaebel(a)uwaterloo.ca> 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(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

[Proposal] Add default implementation of mappend/mempty in terms of mconcat
by Niklas Haas 27 Jan '14

27 Jan '14

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

8 8

A modest proposal (re the Platform)
by Mark Lentczner 20 Jan '14

20 Jan '14

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?

8 8

Re: A modest proposal (re the Platform)
by Andres Löh 20 Jan '14

20 Jan '14

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

1 0

Hashtables: 'Basic' hashtables performance quirks on Win64
by kyra 18 Jan '14

18 Jan '14

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

2 1

Releasing containers 0.5.3.2 -- before GHC 7.8?
by Ryan Newton 16 Jan '14

16 Jan '14

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

7 8

System.FilePath.splitFileName
by Christian Maeder 15 Jan '14

15 Jan '14

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/Syst… Cheers Christian

1 0

Who remembers HP 2013.4.0.0...?
by Mark Lentczner 11 Jan '14

11 Jan '14

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.

7 12

Broken documentation on Hackage.
by Mateusz Kowalczyk 07 Jan '14

07 Jan '14

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.

8 18

Win32-2.3.0.0 not on Hackage
by Mikhail Glushenkov 06 Jan '14

06 Jan '14

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

3 3