- Haskell-Cafe - Haskell.org

Re: [Haskell] Re: Trying to install binary-0.4
by Duncan Coutts 21 Oct '07

21 Oct '07

(moving to haskell-cafe) On Sun, 2007-10-21 at 14:55 +0200, Udo Stenzel wrote: > Duncan Coutts wrote: > > New tarball releases of Cabal-1.2.1, bytestring-0.9, binary-0.4.1, tar > > and others (zlib, bzlib, iconv) will appear on hackage in the next few > > days. > > I just tried one of them, iconv. First it wants a recent cabal; that's > fine, I installed the darcs version. Then I get this: > > | Codec/Text/IConv.hs:64:17: > | Could not find module `Data.ByteString': > | it is a member of package bytestring-0.9, which is hidden > > Okay, it obviously tries to be smart, but doesn't know that I upgraded > to a separate ByteString library. Right. > So I take out the gunk about 'flag(bytestring-in-base)' and try again: > | Setup: At least the following dependencies are missing: > | base <2.0||>=2.2 > > Of course that was to be expected, since I have base-2.0 hacked to not > get in conflict with bytestring-0.9, and you (Duncan) couldn't possibly > anticipate this (or could you?). Right. It expects that if you have base >= 2.0 && < 2.2 then that version of base exports Data.ByteString. That's not an unreasonable assumption I think. You can hack the .cabal file further to make it work in your situation, but I don't suggest that's a great long term solution. If you wanted to hack it you'd change it to just: build-depends: base, bytestring >= 0.9 without any 'if' or flags and without cpp-options: -DBYTESTRING_IN_BASE. > Now what am I supposed to do? Give my messed up base a new version > number? (Which one?) Rewrite every single cabal file, hoping that > they never become Turing complete turning the exercise into a reverse > engineering fest rivaling the ICFP contest? Bite the bullet and > install GHC from darcs? So you've changed the API of base-2.1.1 so that will break packages that expect that they know what the api of base-2.1.1 actually is. You can either hack the .cabal files of things you try to install (which would be a pain, I don't recommend it) or you could revert your changes to your base package. > For the time being, I'll go with 'ghc --make'. And I think that cabal > configurations are an exceptionally bad idea carried to perfection. Don't get me wrong, I'm not claiming that the changes in what is in and what is out of the base package could not have been handled better. Configurations just happen to be one mechanism that we have available now to enable packages to build with various versions of the base package. The other alternative seemed to be that they'd only work with an old or a new version but not both. There are plenty of things that we could have done better to make the base changes less disruptive but I really don't think you can blame configurations for that or for adding to that problem. If we had made different decisions at various points we would not need configurations for this purpose right now. We'd still need configurations for other things. Configurations serve other purposes too. They're not just for managing the mess over moving modules between packages. They're generally to allow changes in the way a package is built depending on the environment in which the package is built to reduce the need for non-portable configure scripts and wadges of fragile code in Setup.hs files. > They make things worse, not better. (And that's just GHC 6.6... I don't > want to even think about what happens on Hugs, JHC and YHC.) It's mostly orthogonal to the Haskell implementation since the base package is shared by all Haskell implementations. > What would it take to talk you into giving up on supporting the broken > base-2.0 and incorporating a patch to unbreak it into the bytestring > setup? Can I stop the insanity by simply writing that patch? What kind of change are you suggesting? We have to support base 2.x because that is the versions of base that come with ghc-6.6.x. We cannot sensibly install the separate bytestring package with ghc-6.6.x because it would clash with the base package there. We cannot easily upgrade base in existing installations of ghc because ghc is just not designed with that in mind at the moment. The solution we're using at the moment is to use the separate bytestring package with ghc-6.4 and ghc-6.8 and to use the version of the bytestring code in base-2.x for ghc-6.6.x. That's what the newest versions of zlib, bzlib, iconv, binary, tar etc do. They all work with ghc-6.4, 6.6 and 6.8 (using Cabal-1.2.x). > > So all will not be plain sailing for the first few weeks after > > ghc-6.8 comes out as maintainers update their packages. People will have > > to be patient and/or stick to ghc-6.6 for a bit. > > Okay, so now we have *three* almost-stable versions of GHC in wide > circulation, all of them broken in different ways with respect to cabal > packages. I feel tears welling up... So far this weekend I've uploaded to hackage: Cabal-1.2.1, bytestring-0.9, unix-compat-0.1.1, tar-0.1.1 and Kolmodin uploaded binary-0.4.1. When hackage itself is using Cabal-1.2.1 then I can also upload zlib-0.4, bzlib-0.4, iconv-0.4. All these packages (with the exception of bytestring-0.9 with ghc-6.6 as I explained) work with all recent versions of ghc. I've also been checking that the packages that will come with ghc-6.8 will also work with ghc-6.6 and 6.4 (where it makes sense for them to do so). These packages will be released separately on hackage too. This required using configurations in many cases to allow the packages to build with several base/ghc versions. I do understand you've have a bad experience with incompatible bits of software and different versions of build systems etc, but I really think the situation is not that bad. The right thing to do is to use the latest Cabal-1.2.x with whichever version of ghc you happen to have and not to use a hacked version of base. There is no need to upgrade immediately to ghc-6.8, in fact at the moment that'd make the situation worse since most packages need tweaks to work with it. Duncan

1 0

SYB3 codebase
by Greg Meredith 21 Oct '07

21 Oct '07

Haskellians, Does anyone know the status of SYB3 codebase? It appears that FreshLib critically depends on it, but the code downloadable from http://homepages.cwi.nl/~ralf/syb3/code.html dies in make test on the first test with lgmaclt:~/work/src/projex/biosimilarity/HS1/Process/haskell/SYB3 lgm$ make test make test1 stem=geq1 ghci -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -v0 geq1.hs < Main.in > geq1.out geq1.hs:27:34: Inferred type is less polymorphic than expected Quantified type variable `a1' escapes Probable cause: `geq'' is applied to too few arguments In the first argument of `gzipWithQ', namely `geq'' In the first argument of `and', namely `(gzipWithQ geq' x y)' <interactive>:1:0: Not in scope: `main' diff -b geq1.out geq1.ref 0a1,4 > True > False > False > True make[1]: *** [test1] Error 1 make: *** [test] Error 2 lgmaclt:~/work/src/projex/biosimilarity/HS1/Process/haskell/SYB3 lgm$ Is there a newer version of this codebase? Has this functionality been folded into mainline Haskell tree somewhere? Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com

3 5

building hslogger
by Chris Hayden 21 Oct '07

21 Oct '07

Hello! I'm trying to build the most recent version of hslogger and have run into some issues. Below is the error message I receive. (I see that the same error has come up elsewhere: http://haskell.galois.com/packages/archive/hslogger/1.0.2/log) The hslogger (http://software.complete.org/hslogger) website indicates that questions should be posted here - I apologize if this is the wrong venue. Thank you, Chris runhaskell Setup.hs configure Setup.hs:19:35: Couldn't match expected type `(Either GenericPackageDescription PackageDescription, HookedBuildInfo)' against inferred type `PackageDescription' In the first argument of `(confHook defaultUserHooks)', namely `mydescrip' In the expression: let mydescrip = case os of "mingw32" -> ... _ -> ... in (confHook defaultUserHooks) mydescrip flags In the definition of `customConfHook': customConfHook descrip flags = let mydescrip = case ... of "mingw32" -> ... _ -> ... in (confHook defaultUserHooks) mydescrip flags

3 2

Why doesn't Hackage link to Haddock documentation anymore?
by Johan Tibell 20 Oct '07

20 Oct '07

Maybe I'm seeing things but from what I remember packages that used to have links to Haddock documentation in their exported modules list no longer has. It's a super useful feature! What happened to those packages? -- Johan

4 4

On the verge of ... giving up!
by Vimal 19 Oct '07

19 Oct '07

Dear Haskellers, I have been trying my best to read about Haskell from the various tutorials available on the internet and blogs. I havent been following YAHT properly, so its always been learning from 'bits and pieces' scattered around. For most languages (like C/C++/Ruby/Python), the above approach has helped me. But for Haskell, it is failing. I like learning by comparison with other similar languages. This approach worked for me when I tried learning Python+Perl together. The nicer syntax and easier object-orientedness made me leave Perl behind and pursue Python. I also tried it for Haskell (Lisp+OCaml+Haskell together). The next step I usually take in learning a language is, not to go by the topics found in textbooks, but by taking real world examples and then blindly try to solve it using that language as a tool. For e.g, I tried writing a terminal GTalk client for Python when I was learning it, and learnt so many features that way. I used to call this 'learning by need', and it worked, to the extent that I never knew how to take 'input' from the user, but knew how to write Objects in Python! (Since I never used input in that example :) I didnt want to repeat that mistake, so I made sure I would learn IO in Haskell, which initially turned out to be a disaster, due to the 'Moands' which sounded like 'Go Mads' to me. Then, I set out to learn Monads + Category Theory from a Math perspective. And since I haven't been introduced to abstract math (like Groups, etc.), I found this a little difficult. However I tried my best to understand the tiniest bit and waited for the tiniest spark that would enlighten me. It didn't work out. --snip-- Okay, so you might be wondering as to whats the whole point of this mail? Well, I am almost on the verge of giving up on something I really like to learn, just because I didn't go in the right order! So, I requested my institute to buy Dr. Graham Hutton's book. I would be getting hold of that quite soon, and am willing to start from the beginning. Meanwhile, could anyone suggest if there was anything wrong in my approach to learning Haskell/the other languages? I agree that the learning methodology is something personal and I have to find out what best suits me, but I would like to hear something from you, Haskellers, too. I have no need to hurry anything at this point of time. But after being introduced to the tiniest bit of Haskell, and after seeing such a large and active community here, and #haskell, I had the plan of conducting a Haskell Workshop, in our department (sometime in Feb next year, the dates have not been finalized). I just hope that I should be able to reach a substantial amount of familiarity with Haskell by that time! Sorry for the long mail, and pardon me if it was too boring. I just put my thoughts on <strike>paper</strike> a mail :) I did have a couple of ambitious projects in my mind when to help me learn Haskell. They were: 1. An online judge system (Like http://spoj.pl) I had already done one for contests that were held during our Technical festival here, using php. The ideas are laid out. All I had to focus on was learning Haskell. 2. A solver for the Peg-Solitaire. This was more of an academic interest. I have seen Richard Bird's presentation on 'How to write a functional pearl, with an example' and was quite impressed by it. But the actual modelling might be slightly tricky here, and I am yet to start off with it. Many thanks for your patience, Cheers, -- ~Vimal IIT Madras RLE :) encode = map (length &&& head) . group decode = concatMap (uncurry replicate)

34 78

Filesystem questions
by Andrew Coppin 19 Oct '07

19 Oct '07

I notice that getDirectoryContents appears to return its results in alphabetical order. Is this behaviour actually guaranteed? Related: Is there a way to get rid of "." and ".." in the results? (Obviously this causes directory recusion to malfunction.) I can of course manually filter them out, but it's annoying. Finally, why do doesDirectoryExist "C:" doesDirectoryExist "C:\" both yield False? (This frequently trips up programs that try to check that a destination folder exists.)

11 19

Pixel plotter
by Andrew Coppin 19 Oct '07

19 Oct '07

> http://darcs.haskell.org/~lemmih/hsSDL/ <http://darcs.haskell.org/%7Elemmih/hsSDL/> How do I use this? I've seen instructions floating around somewhere that if a library has a "Setup.hs", you're supposed to do runhaskell Setup configure runhaskell Setup build runhaskell Setup install However, the first command prints a huge stream of text and then complains about "can't find sh". (Well, why would you? It's Windows...)

5 6

Re: [Haskell] Fingerprints and hashing
by Bulat Ziganshin 19 Oct '07

19 Oct '07

Hello Simon, Thursday, October 11, 2007, 1:42:31 PM, you wrote: > For various applications (including identifying common > sub-expressions, and version tracking in GHC), I'd like a Haskell > library that supports simple fingerprint operations. lots of hash-related links was collected at http://www.encode.ru/forums/index.php?action=vthread&forum=1&topic=413 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Suspected stupid Haskell Question
by Big_Ham 19 Oct '07

19 Oct '07

Is there a library function to take a list of Strings and return a list of ints showing how many times each String occurs in the list. So for example: ["egg", "egg", "cheese"] would return [2,1] I couldn't find anything on a search, or anything in the librarys. Thanks BH. -- View this message in context: http://www.nabble.com/Suspected-stupid-Haskell-Question-tf4639170.html#a132… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

12 19

Re: [Haskell-cafe] Polymorphic (typeclass) values in a list?
by TJ 19 Oct '07

19 Oct '07

Henning Thielemann: > > class Renderable a where > > render :: a -> RasterImage > > > > scene :: Renderable a => [a] > > This signature is valid, but it means that all list elements must be of > the same Renderable type. Yes, that's exactly the restriction I'm unhappy about. > You could let the user plug together the alternatives for Renderable. That > is, declare the class Renderable and let the user define and instantiate > > data Figure > = Point Something > | Line Something > | Polygon Something But if I already have the types Point, Line, and Polygon, and I want to create a "union type" Figure as above, then my code will look like this: data Point = Point Something data Line = Line Something data Polygon = Polygon Something data Figure = FPoint Point | FLine Line | FPolygon Polygon aFigure = FPoint Point Something aListOfFigures = [FPoint Point Something, FPolygon Polygon Something, FLine Line Something] > > Is there a way of achieving what I want to do? Existentials maybe? I'm > > still learning the basic stuff and don't grok existentials at all, but > > I even if I use those, I'll still have to wrap things up in a > > constructor, won't I? > > I assume, that you could use > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.htm… That's a nice page :) From a quick reading, the best I came up with was this: data R = forall a. Renderable a => V a instance Show R where render (R a) = render a Which is precisely what I meant when I said that I'd still have to wrap things up in a constructor. Is this hidden type variable thing what "existential types" mean? OT: forall just introduces a new type variable, right? Thanks, TJ

3 2