Hi all, Today I merged Mikhail's sandbox UI changes. I believe this is the biggest hurdle to get the next release out. We have a few remaining tickets: https://github.com/haskell/cabal/issues?milestone=20&state=open and then we should be good to go. I will start with #1106. I think we can punt on #1143. #1197 is important however. -- Johan
I'm having trouble with install --builddir. If I run $ cabal install --builddir /some/absolute/path test-framework I get an error after regex-posix is installed, during the build of test-framework: Text/Regex/Posix/Wrap.hsc:141:8: Could not find module `Text.Regex.Base.RegexLike' It is a member of the hidden package `regex-base-0.93.2'. Perhaps you need to add `regex-base' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. But if I run $ cabal install --builddir /some/absolute/path regex-posix $ rm -r /some/absolute/path $ cabal install --builddir /some/absolute/path test-framework I do not get the error. Between experiments I'm removing my ~/.cabal and ~/.ghc and running cabal update. Naively, it looks to me like using an absolute builddir has changed things so successive packages share the same intermediate files, which in turn has caused a later package to erroneously recompile a previously generated file. My ultimate aim is only to be able to use cabal-dev for my development builds, but without writing into my source tree. Is there any way to specify a build directory outside the source of a package without it winding up shared? Could/should cabal instead create a separate subdirectory within the specified builddir for each package to be built, so that specifying an external location didn't break things?(Continue reading)
Fri Mar 29 18:14:30 GMT 2013 Duncan Coutts <duncan <at> community.haskell.org>
* Remove the basic html package pages from the core and candidate features
Ignore-this: d1d21177dadd082d176d78130db247a2
M ./Distribution/Server/Features/Core.hs -39 +1
M ./Distribution/Server/Features/PackageCandidates.hs -20 +1
Sat Mar 30 08:50:03 GMT 2013 Duncan Coutts <duncan <at> community.haskell.org>
* Simplify Hook interface and remove a few unused feature hooks
Ignore-this: 66d7b02693ae0ee3168ca4f98fcdd17e
M ./Distribution/Server/Features/Core.hs -36 +22
M ./Distribution/Server/Features/DownloadCount.hs -1 +1
M ./Distribution/Server/Features/Html.hs -4 +4
M ./Distribution/Server/Features/NameSearch.hs -6 +6
M ./Distribution/Server/Features/PackageCandidates.hs -31 +22
M ./Distribution/Server/Features/PackageList.hs -9 +9
M ./Distribution/Server/Features/PreferredVersions.hs -7 +7
M ./Distribution/Server/Features/RecentPackages.hs -1 +1
M ./Distribution/Server/Features/Tags.hs -4 +4
M ./Distribution/Server/Features/Upload.hs -15 +3
M ./Distribution/Server/Features/Users.hs -19 +7
M ./Distribution/Server/Framework/Hook.hs -46 +15
Mon Apr 8 22:08:11 BST 2013 Duncan Coutts <duncan <at> well-typed.com>
* Change http code for the legacy passwd auth failure
Ignore-this: cd56b7525cfaac2d5bba8c30ea17a3f2
When someone tries to authenticate for a user account that has a legacy
password, we previously returned 401 without any auth methods. It turns out
that returning 401 in this case is a violation of the http spec because you
(Continue reading)
Hi, I just tried the sandbox functionality of cabal with the current version on github (b89d894947a9ec6fde78ebc6e7f6978f0b117eb1). If the source added by 'cabal sandbox-add-source' changes, than it gets rebuild by calling 'cabal sandbox-build', but not if I'm just calling 'cabal sandbox-install'. Is there a reason for this behavior? Greetings, Daniel
On Thu, 2013-04-04 at 15:46 +0100, Rob Stewart wrote:
> Hi Duncan, Edsko.
>
> I'd like to know where I should most appropriately submit a bug
> report, or indeed whether the behaviour that I am experiencing is a
> bug or a user misuse of cabal.
It's a consequence of a misunderstanding of how package names affect
types and how different cabal constructs give you different package
names.
> I have packaged up a very simple send/receive example into a cabalised
> archive. In there is a README that describes the problem succinctly,
> though I will repeat here for convenience. It appears to be weirdness
> with main-is and hs-source-dirs. In the .cabal file, there are three
> executables of the same Receiver.hs file - a receiver of a CH message.
> One appears to be defined in such a way that the CH primitives `match`
> and `expect` are *not* receiving the message types that are being sent
> by Sender.hs.
The problem is that your three programs are using different types.
ch-receiver-1 and ch-receiver-2 use the type
cabal-with-ch-executables-1.0:Bar.Baz.Types.Msg
while ch-receiver-3 uses the type
Bar.Baz.Types.Msg
(Continue reading)
Wed Mar 27 12:50:51 GMT 2013 Duncan Coutts <duncan <at> well-typed.com>
* Add link to cabal file editing to maintainers page
Ignore-this: 99bf7ccf84a4cfeab89406c672fa1d7f
M ./datafiles/templates/Html/maintain.html.st +5
Thu Mar 14 17:37:47 GMT 2013 Duncan Coutts <duncan <at> well-typed.com>
* Remove the google search from the package page
Ignore-this: 7c0346431aec1bc7f195cdd2037991c6
M ./Distribution/Server/Pages/Index.hs -8
Tue Mar 26 14:43:11 GMT 2013 Duncan Coutts <duncan <at> well-typed.com>
* Tweak page css based on feedback
Ignore-this: 6b91314fa8fc506a02b42d30ac390161
Center content, bigger font, wider page body, no justification of text
M ./datafiles/static/hackage.css -3 +2
Tue Mar 26 14:44:38 GMT 2013 Duncan Coutts <duncan <at> well-typed.com>
* Fix last few occurrences of HackageDB for simply Hackage
Ignore-this: b4bf3d65b92523f8d3d5a4cc2a1392f5
M ./datafiles/templates/UserSignupReset/ResetConfirm.st -1 +1
M ./datafiles/templates/UserSignupReset/ResetEmailSent.st -1 +1
M ./datafiles/templates/UserSignupReset/ResetRequest.st -1 +1
M ./datafiles/templates/UserSignupReset/SignupConfirm.st -1 +1
M ./datafiles/templates/UserSignupReset/SignupEmailSent.st -1 +1
M ./datafiles/templates/accounts.html.st -1 +1
Tue Mar 26 18:24:00 GMT 2013 Duncan Coutts <duncan <at> well-typed.com>
* Redo the maintainer links and page based on feedback
Ignore-this: 2805cd1d99d8f91721ca4671a3241ead
The feedback was that the links for maintainers were confusing for
ordinary users because it is not clear if they are allowed to use them
or not, and "maintain" is not very descriptive as a link name.
(Continue reading)
Hi everyone, Do we have a general notion of what we consider best practices for contributed code to Cabal? Perhaps we should formalise something? One of the reasons I wanted to get the wiki back online was in the hope that it had some pointers, but it doesn't seem to. (I've started migrating stuff anyway: have a look at https://github.com/haskell/cabal/wiki/Migration-from-trac for status). For example, many of the Cabal modules have explicit, and therefore quite long, import lists, with no clear organisation, and hence when adding new imports I have to read the entire list to make sure they are not already there, and then wonder where makes sense to insert them. Usually I just make something up with no pattern to it, and hence perpetuate the problem. I am happy to start things off with a proposal if no-one else wants to do the writing. Regards, Ben Millwood (benmachine)
On Fri, 2013-03-15 at 10:10 +0100, Herbert Valerio Riedel wrote: > Duncan Coutts <duncan.coutts <at> googlemail.com> writes: > > > [...] > > > I've been doing regression testing against hackage and I'm satisfied > > that the new parser matches close enough. I've uncovered all kinds of > > horrors with .cabal files in the wild relying on quirks of the old > > parser. I've made adjustments for most of them but I will be breaking a > > half dozen old packages (most of those don't actually build correctly > > because though their syntax errors are not picked up by the parser, they > > do cause failure eventually). > > btw, why not just keep the current parser as a "legacy" parser in the > code, for older .cabal files (or as a fallback parser, in case the new > stricter parsec-parser fails)? I'm satisfied at this point that the number of packages affected by the change is so low that it's not worth the extra maintenance. As I mentioned, most of the ones that break in the new parser are actually already broken in the sense that they will not build (because of mistakes in the .cabal file that just happen not to be caught by the old parser). So the amount of "real" breakage is trivial. Also, with the new hackage server we will be able to fix .cabal files post-release so if we do care about those few older packages we can actually fix them. Duncan(Continue reading)
Hi all, What is the purpose of the "install" command's "--only" flag? The documentation says "Only installs the package in the current directory", but this is already supported by running "cabal install" in the current directory without arguments. Would it be fine if I removed "--only"? -- -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On Thu, 2013-03-14 at 09:39 -0700, Jason Dagit wrote: > > Why did I choose parsec? Practicality dictates that I can only use > > things in the core libraries, and the nearest thing we have to that is > > the parser lib that is in the HP. I tried to use happy but I could not > > construct a grammar/lexer combo to handle the layout (also, happy is not > > exactly known for its great error messages). > > > > Failed attempt aside for a moment, I think you should reconsider happy. Can > you learn how to do layout from reading the GHC source? Yes I looked at it, though Haskell's layout is a bit different. > The happy documentation that explains how to attach a monad (you could > use it to communicate between alex and happy for layout info) is a bit > misleading but I have examples I can share with you. Yes, that's what I was doing. I've used happy with monadic lexers with feedback between the lexer and parser before, e.g. when I wrote the C parser now used in language-c. > I haven't specifically tackled the layout problem but I could try to > make a parser if it would help. > > One major benefit of using happy is that the productions of the grammar can > be analyzed for shift/shift and shift/reduce conflicts. Right, I know and that's great. For example there's no way I could have extended the C89 grammar I started with to cover C99 and GNU C(Continue reading)
 |
|
|
|
|
|
|
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
RSS Feed16 | |
|---|---|
66 | |
17 | |
28 | |
32 | |
75 | |
42 | |
108 | |
78 | |
35 | |
1 | |
33 | |
114 | |
239 | |
79 | |
467 | |
34 | |
33 | |
130 | |
46 | |
51 | |
51 | |
62 | |
91 | |
71 | |
114 | |
76 | |
110 | |
62 | |
116 | |
268 | |
42 | |
63 | |
53 | |
108 | |
125 | |
64 | |
116 | |
29 | |
57 | |
155 | |
103 | |
42 | |
91 | |
77 | |
62 | |
168 | |
124 | |
65 | |
134 | |
234 | |
330 | |
183 | |
119 | |
225 | |
102 | |
347 | |
122 | |
289 | |
295 | |
173 | |
325 | |
276 | |
360 | |
150 | |
170 | |
182 | |
192 | |
238 | |
70 | |
70 | |
57 | |
51 | |
39 | |
53 | |
69 | |
16 | |
79 | |
54 | |
18 | |
103 | |
29 | |
1 | |
22 |