Re: What is the error mean for bloomfilter?
On 05/16/2015 03:31 PM, Peng Yu wrote: I'm not sure how to fix the problem after reading the links you pointed. Would you please be specific what should be done? Thanks. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 On Sat, May 16, 2015 at 7:45 AM, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: Hi, On 16 May 2015 at 03:57, Peng Yu pengyu...@gmail.com wrote: Data/BloomFilter/Mutable.hs:136:9: Non type-variable argument in the constraint: [...] Not a Cabal issue: the library wasn't updated to work with GHC 7.10. See https://github.com/bos/bloomfilter/issues/11 and https://github.com/bos/bloomfilter/pull/10 It's not a cabal problem, it's not relevant on this list. The links you were given already point out that the issue is known and even a link to the pull request that fixes it. -- Mateusz K. ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: GSoC - request for mentor
On 28/03/14 08:17, Chris Wong wrote: Hi all, Like Mateusz Lenik, I am looking for a mentor for the Google Summer of Code. The project aims to make various improvements to Hackage, such as exposing build reports and documentation uploads. An initial proposal is here [1], though as Greg Weber notes, the details may change if the project is accepted. Feel free to ping me if mentoring interests you. Chris [1] http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/lambda_fairy/5741031244955648 ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel Hi, I can't read the proposal, I get You are not logged in as the user in the URL. Perhaps you should try giving us a different URL? -- Mateusz K. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
module ‘free-4.6.1:Main’ is defined in multiple files
Greetings, First of all to people reading this at ghc-devs, I don't expect this to be a direct problem caused by GHC but who knows, so I'm CC'ing it anyway. As you might know, GHC 7.8.1 is scheduled to release Very Soon™ (later today?). We got a report at Haddock Trac few weeks ago about a strange error, see http://trac.haskell.org/haddock/ticket/284. I have asked about this on cabal-devel before and Mikhail said that maybe it's https://github.com/haskell/cabal/pull/1374 but it's unlikely because the changes aren't ran by default. Today I got new reports of this problem and so far everyone on OSX seems to be affected! This suddenly became a big problem. To replicate: 1. Find OSX machine 2. Get GHC 7.8 rc2 package (which includes Haddock at that stage) 3. git clone g...@github.com:ekmett/free.git cd free 4. cabal install --only-dependencies --enable-documentation cabal configure cabal haddock The reason I'm barking up cabal-devel and ghc-devs is because I honestly can not think of anything that has changed since Haddock 2.13.2.1 that could possibly cause this. Does anyone have any idea at all? I think it would be very bad to release now and have everyone on OSX unable to build docs. FYI I get build docs on 32-bit Linux. No idea about Windows. Thanks, I hope to hear back soon. PS: How does one go about downgrading Cabal and cabal-install? If we wanted to check whether cabal is the problem, how? -- Mateusz K. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: module 'free-4.6.1:Main' is defined in multiple files
On 24/03/14 21:26, Mikhail Glushenkov wrote: Hi, On 24 March 2014 18:54, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: PS: How does one go about downgrading Cabal and cabal-install? If we wanted to check whether cabal is the problem, how? You can force the Cabal lib version to use (in case you have multiple versions installed) with 'install --cabal-lib-version'. To downgrade cabal-install itself to some older version you need to compile and install that version. About cabal-install, I'm mostly concerned about not breaking my whole existing system by installing an old version. Are there any steps I can take to retain sane setup? I don't have an OSX machine and I can't exactly ask people volunteering to break their Haskell environments. Are there any catches to having multiple Cabal libs installed or will the latest one always be used if not specified? -- Mateusz K. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Haddock fails with Module defined in multiple files
On 04/03/14 06:38, Mikhail Glushenkov wrote: Hi, On 4 March 2014 07:20, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: I don't follow the changes in cabal (even though I should) so it might be something really obvious that changed recently that we aren't aware of. Can this be related to https://github.com/haskell/cabal/pull/1374 ? I don't think that documentation for tests and benchmarks is enabled by default, though... Hm, perhaps it could be this but as you mention, I don't think it's a default (but what do I know, maybe it --all or something was made a default in the bindist). I imagine that this problem would have come up 9 months ago, when the commit was merged however. I will of course investigate further over the next few days but any help is appreciated, especially if this turns out to be a big problem considering GHC rc2 is out of the door. -- Mateusz K. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Hackage Travis build failures
On 16/02/14 15:51, Mikhail Glushenkov wrote: Hi, On 16 February 2014 10:33, Ian Ross i...@skybluetrades.net wrote: Does anyone have any idea what the source of the intermittent Travis failures for Hackage is? Cabal builds on Travis sometimes error out because of network connectivity problems. Example: https://travis-ci.org/haskell/cabal/jobs/18955110 ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel There was a blog post by Travis about the mysterious connectivity issues. They have introduced the retry command because of it. You might want to use it. -- Mateusz K. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Broken documentation on Hackage.
Oops, seems I sent to libraries. Let's keep the thread on cabal-devel only as here's where the replies happened. 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, -- Mateusz K. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Broken documentation on Hackage.
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@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Broken documentation on Hackage.
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.: meta HTTP-EQUIV=REFRESH content=0; url=http://hackage.haskell.org/package/newsynth-0.1.0.0; If your browser does not take you there automatically, please go to a href=http://hackage.haskell.org/package/newsynth-0.1.0.0http://hackage.haskell.org/package/newsynth-0.1.0.0/a. 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@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Broken documentation on Hackage.
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. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Broken documentation on Hackage.
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. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Broken documentation on Hackage.
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:passw...@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@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
