December 2008 - Libraries

Re: [Haskell-cafe] Cabal Install & Links to Source from Haddock Docs
by R Hayes 23 Dec '08

23 Dec '08

Thank you. As it turns out, I was aware of that recipe. What I wanted was to be able to use cabal install's nice dependency following features and still get source links in my documentation. Personally, I feel that inclusion of source and docs should be the DEFAULT for cabal, as well as for binary distributions of ghc. -rhayes On Dec 21, 2008, at 1:11 AM, Thomas Hartman wrote: > the answer: not cabal install, just cabal. > > thartman@thartman-laptop:~/haskellInstalls/smallInstalls/ > pureMD5-0.2.3> > thartman@thartman-laptop:~/haskellInstalls/smallInstalls/ > pureMD5-0.2.3>cabal > --help | grep -i doc > haddock Generate Haddock HTML documentation. > thartman@thartman-laptop:~/haskellInstalls/smallInstalls/ > pureMD5-0.2.3>cabal > haddock --help | grep -i link > --hyperlink-source Hyperlink the documentation to the source > code > thartman@thartman-laptop:~/haskellInstalls/smallInstalls/ > pureMD5-0.2.3>cabal > haddock --hyperlink-source > > 2008/12/21 R Hayes <rfhayes(a)reillyhayes.com>: >> >> Is there a way I can get Haddock Docs WITH links to source (local) >> from >> modules installed with "cabal install xxx"? >> >> Getting the docs themselves is pretty easy by changing either >> ~/.cabal/config or using --enable-documentation. >> >> Automatically generating the source (colourised or not) and >> integrated links >> eludes me. >> >> -r >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >>

2 1

cabal-install sends invalid proxy password
by Valery V. Vorotyntsev 18 Dec '08

18 Dec '08

Dear lazy programmers, I was surprised to discover that `cabal-install' -- a popular utility for installing Hackage packages -- cannot work with HTTP proxies. Despite all the necessary code linked in. `cabal update' command returns HTTP 407 (Proxy Authentication Required) error. The problem is explained below and patches follow. * * * Our office LAN has an HTTP proxy server with authorization. And my shell environment has a variable like http_proxy='http://user:password@proxyhost:proxyport/' tcpdump-ing shows that `cabal update' sends invalid credentials in HTTP "CONNECT" request. The proper string would be "user:password" (base64-encoded) while `cabal' sends "user:password@". There's no surprise proxy server denies connection! I've traced the problem down to `userinfo' function, defined in network-2.2.0.1/Network/URI.hs:451: > -- RFC3986, section 3.2.1 > > userinfo :: URIParser String > userinfo = > do { uu <- many (uchar ";:&=+$,") > ; char '@' > ; return (concat uu ++"@") > } Let us see section 3.2 of RFC3986: > authority = [ userinfo "@" ] host [ ":" port ] > [... > ...] The user information, if present, is followed by a > commercial at-sign ("@") that delimits it from the host. There is no reason for "@" character to be a part of `userinfo' expression. * * * So, the Right Way(TM) to make cabal-install go through proxies is fixing `userinfo' function of `network' package (see the `network-2.2.0.1.patch'). Until then, we should have a workaround in `cabal-install' (cabal-install-0.6.0.patch). I do. Happy hacking! -- vvv

3 4

Re: [Haskell] possible bug in pretty-1.0.1.0
by Duncan Coutts 18 Dec '08

18 Dec '08

On Mon, 2008-12-15 at 08:17 -0800, John MacFarlane wrote: > I noticed a difference in how "hang" works between pretty-1.0.0.0 and > pretty-1.0.1.0. I think it's a bug. If this isn't the right place to > report it, please let me know where I should. (Maintainer is listed > as libraries(a)haskell.org, but that is a closed mailing list. Perhaps > Cabal should include a report-bugs-at field?) I'd just like to advertise the fact that as of Cabal-1.6 you can put a bug-reports field in your .cabal file and it will be displayed by hackage. We would like to encourage all package authors to use this. It can be a mailto: url to a maintainer or mailing list or it can be a http: url to a bug tracker website. (Cabal-1.6 also supports specifying darcs/git/whatever repos) Duncan

2 2

Re: possible bug in pretty-1.0.1.0
by Benedikt Huber 16 Dec '08

16 Dec '08

John MacFarlane schrieb: > I noticed a difference in how "hang" works between pretty-1.0.0.0 and > pretty-1.0.1.0. I think it's a bug. If this isn't the right place to > report it, please let me know where I should. (Maintainer is listed > as libraries(a)haskell.org, but that is a closed mailing list. Perhaps > Cabal should include a report-bugs-at field?) > > John > > GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help > ... > Prelude Text.PrettyPrint> putStrLn $ render $ hang (char '*') 4 (text "hi" $$ text "there") > Loading package pretty-1.0.0.0 ... linking ... done. > * hi > there > > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > ... > Prelude Text.PrettyPrint> putStrLn $ render $ hang (char '*') 4 (text "hi" $$ text "there") > Loading package pretty-1.0.1.0 ... linking ... done. > * > hi > there Hi John, I think you're right, from the perspective of 'hang' the last set of patches (http://hackage.haskell.org/trac/ghc/ticket/2393) indeed introduced a bug. Unfortunately a good description of what hang is _intended_ to mean is still missing in the documentation, but I'll assume that > hang (text "*") 4 (sep [ text "hi", text "there" ]) should either layout as > * hi there or > * hi > there If only the second layout is of interest (like in your example), then > hang' d1 n d2 = d1 $$ (nest n d2) should do the job. Related issue, we changed vcat to mean (foldr $+$ empty) instead of (foldr $$ empty) - either revert this change or update the documentation ? [1] Unfortunately, the situations is a bit trickier for hang (i.e. for sep[A, nest n B]); allowing overlap violates Invariant 7: The first line of the first layout has to be longer than the first line of the second layout because > sep [A, nest n B] ~ > oneLiner (A <+> B) `union` A $$ (nest n B) > with e.g. [A="a",B="b",n="4"] > "a b" `union` "a b" which causes the pretty printer to select an even longer! line if (A <+> B) doesn't fit on one line. I'm not sure how to resolve this - should sep [A, B] really overlap A and B if they do not fit on a line ??? Still, if it seems to be the right thing to do, it is easy to allow overlap in sep/cat. Otherwise hang might need to be changed. best regards, benedikt [1] Either hunk ./Text/PrettyPrint/HughesPJ.hs 114 - vcat is a list version of $$ + vcat is a list version of $+$ hunk ./Text/PrettyPrint/HughesPJ.hs 316 -vcat :: [Doc] -> Doc; -- ^List version of '$$'. +vcat :: [Doc] -> Doc; -- ^List version of '$+$'. or hunk ./Text/PrettyPrint/HughesPJ.hs 497 -vcat = reduceAB . foldr (above_' True) empty +vcat = reduceAB . foldr (above_' False) empty because of 505: above_' g p q = Above p g q 536: | Above Doc Bool Doc -- True <=> never overlap

1 0

old-time missing configure script?
by Brent Yorgey 16 Dec '08

16 Dec '08

Hi all, Does anyone know what is going on with the 'old-time' package? When I try installing it from Hackage via cabal-install, I get the error Configuring old-time-1.0.0.0... Warning: The 'build-type' is 'Configure' but there is no 'configure' script. cabal: configure script not found. cabal: Error: some packages failed to install: old-time-1.0.0.0 failed during the configure step. The exception was: exit: ExitFailure 1 And indeed, the build-type is specified as Configure but there is no configure script included. -Brent

1 0

Generics
by Simon Peyton-Jones 11 Dec '08

11 Dec '08

Jose As part of your work on the SYB library, could you spare the time to look into these two library bug reports? http://hackage.haskell.org/trac/ghc/ticket/2759 http://hackage.haskell.org/trac/ghc/ticket/2760 Many thanks Simon

3 8

Re: [Haskell-cafe] ANNOUNCE: haskell-src-exts 0.4.4
by Niklas Broberg 09 Dec '08

09 Dec '08

(CC libraries) > So when will we simply declare that haskell-src-exts is the new > haskell-src? :-) I talked about this with Ross Paterson at one point, and his main objection (which I very much agree with) was that haskell-src-exts doesn't let you *optionally* handle extensions, so in some cases valid H98 programs will be discarded due to syntax stealing (e.g. $x from TH). I've had ideas for how to fix this shortcoming for a long while, but never really had the time to actually implement it. It is still my hope and goal that haskell-src-exts will replace the haskell-src package, when it is ready to do so. What do others think about this? Cheers, /Niklas

1 0

More on Proposal #2717: Add nubWith, nubOrd
by Bart Massey 08 Dec '08

08 Dec '08

As those who follow this list know, the consensus after discussion of Proposal #2717 was to just add nubOrd to Data.Set. Final question: should we add nubInt to Data.IntSet as well? It seems to me like the right thing to do, given the existence of Data.IntSet in the first place. Once this last question is answered, I will start a new proposal round with a "final" set of proposed patches. Bart Massey bart <at> cs.pdx.edu

7 11

treating spaces with Parsec
by ben.a 08 Dec '08

08 Dec '08

hello, i am trying to write a parser in haskell, using parsec. the task is as follows: a string shall go into a data type (String, [(String, [Integer])]). as an example: "LC.app : 0 , 2 22. abs : 1 ." shall give ("LC", [("app", [0, 2, 22]), ("abs", [1])]) the string is separated by dots, and the integers are separated by either commas or spaces (this is why i cannot use lexer). i have written the following parser, which is not elegant at all, and has the flaw that it does not accept the example because of the space between the 1 and the last dot. furthermore it won't accept newline as a separator for SepBy. -------- the types type Constructor = (String, [Integer]) type Sig = (String, [Constructor]) -- ("LC", [("app", [0, 0]), ("abs", [1])]) -------- the main parser parseString2 :: Parser Sig parseString2 = do spaces name <- word spaces eol sig <- endBy line eol return (name, sig) --------- the parser for one symbol line :: Parser Constructor line = do spaces constru <- word spaces (char ':') spaces ar <- sepBy number separator return (constru, ar) -------- the parser for the integer values number :: Parser Integer number = do ds <- many1 digit; return (read ds) -------- the end of line parser -------- two symbols are separated by at least one point or newline eol :: Parser () eol = do skipMany1 (char '.' <|> char '\n') -------- a separator between two integers is a space or a comma separator :: Parser () separator = skipMany1 (space <|> char ',') i would appreciate if somebody could help me. i tried to exploit all the manuals i found for haskell, but was not successful. greetings ben -- View this message in context: http://www.nabble.com/treating-spaces-with-Parsec-tp20857293p20857293.html Sent from the Haskell - Libraries mailing list archive at Nabble.com.

2 2

Announcing Haskell protocol-buffers version 1.2.2
by Chris Kuklewicz 07 Dec '08

07 Dec '08

Hi everyone, To keep up with protocol-buffers 2.0.3 here is an improved Haskell "hprotoc" version 1.2.2 : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers… http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc The darcs repository with all 3 packages is at http://darcs.haskell.org/packages/protocol-buffers2/ These ought to be compatible with the previous version 1.2.1. As usual, this code read a ".proto" file which describes message formats and generates Haskell modes to encode and decode corresponding data type to the binary wire format. Google's original protocol buffers are at http://code.google.com/apis/protocolbuffers/docs/overview.html and generate code for C++, Python, and Java. Other languages are listed on the wiki at http://code.google.com/p/protobuf/wiki/OtherLanguages (including Haskell). The two changes are support for the field-option-like syntax for EnumValueOptions, and adjacent string literals are concatenated. Note that strings are checked for valid utf8 encoding after concatenation, not individually. But backslash escape codes are decoded for each individual string, not after concatenation. If these quirks become problems they can be changed. The protoc bug fixed in 2.0.3: > * Fixed bug where .proto files which use custom options but don't actually > define them (i.e. they import another .proto file defining the options) > had to explicitly import descriptor.proto." did not affect hprotoc, which already did the Right Thing™ (I just tested to be sure). The protoc bug fixed in 2.0.3: > * If an input file is a Windows absolute path (e.g. "C:\foo\bar.proto") and > the import path only contains "." (or contains "." but does not contain > the file), protoc incorrectly thought that the file was under ".", because > it thought that the path was relative (since it didn't start with a slash). > This has been fixed. is unlikely to be be present in hprotoc. But since I never run or test on Windows I make no promises hprotoc is finding the correct relative paths on Windows. Cheers, Chris Kuklewicz

1 0