- Libraries - Haskell.org

Request: multiple categories for libraries
by Conal Elliott 16 Jan '07

16 Jan '07

How about multiple categories (i.e., tags) rather than single categories for libraries? - Conal

3 4

Re: Control.Monad.Error documentation
by Andriy Palamarchuk 16 Jan '07

16 Jan '07

The deadline for this proposal passed: http://hackage.haskell.org/trac/ghc/ticket/1059 I attached the patch to the ticket. Any last-minute comments? Can somebody commit it? Thanks, Andriy ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail

1 0

hs-plugins runtime error with GHC 6.6: index out of range
by Cyril Schmidt 15 Jan '07

15 Jan '07

After upgrading from GHC 6.4.2 to GHC 6.6 and rebuilding hs-plugins package, I noticed that hs-plugins does not work anymore. When I try to load a plugin, I get an "Index out of range" error. For example, when I compile the hs-plugins\testsuite\make\simple example and run the executable, the error message is a.out: Ix{Int}.index: Index (65536) out of range ((0,11)) Other tests give similar results; the values of the index and the range vary. Does anybody know what is wrong here? I use hs-plugins-1.0-rc0 and GHC 6.6 on Windows (hs-plugins worked fine with GHC 6.4.2). Cheers, Cyril

4 4

Library dilemma / Cofunctor class
by Conal Elliott 14 Jan '07

14 Jan '07

I have a dilemma about library building that I'm expect comes up for other people as well. I'm working on a library that includes a Cofunctor instance. I'd love to import whatever standard module has the Cofunctor class, and maybe use some Cofunctor combinators. But, alas, I haven't found such a thing, and I'm wondering what to do. If I keep my Cofunctor class in my own library, the generality does no good to me or anyone else. I certainly wouldn't expect someone to install my library just to get Cofunctor. Just as I wouldn't want a dependency on some other mostly-irrelevant library just to get Cofunctor. Another option is for me to make a tiny Cofunctor package with just a single class declaration, and make my library dependent on it. I guess that's the cleanest way and is what I'm leaning toward. And maybe it could grow into a more useful Cofunctor library with the addition of functions on generic Cofunctor types. Does anyone have useful functionality to go into a Cofunctor module (beyond the class declaration)? Comments, advice, brainstorming most welcome. Cheers, - Conal

2 2

Crypto Package Proposal
by Dominic Steinitz 13 Jan '07

13 Jan '07

At Hac07, we discussed splitting up the crypto package to get rid of the dependency on NewBinary and so that you didn't have to have the whole of ASN.1 support if you just wanted to use md5 or base64. I've put the full proposal here (http://www.haskell.org/haskellwiki/Crypto_Library_Proposal) for people to comment on. Dominic.

1 0

parsing commandline arguments using parsec
by Marc Weber 13 Jan '07

13 Jan '07

Hello. I've rewritten the source position handing of parsec so that you can now use different position markers such as commandline arguments. You can find it with a demo application here: (Still very untested) http://www.mawercer.de/marcweber/haskell/fparsec/ Do you think this would be useful merging back (after fixing some small bugs like missing spaces in error message and adding some more documentation) ? Example application: ---------------------------------------------------- module Main where import Data.List import Text.ParserCombinators.Parsec.Prim import Text.ParserCombinators.Parsec.Combinator import Text.ParserCombinators.Parsec.Token import Text.ParserCombinators.Parsec.Char import Text.ParserCombinators.Parsec.Argument usage = unlines [ "cat <file> <file> (- means stdin/out)" , "tac <file> <file> (- means stdin/out)" , "calc 3 + 7 \\* 8 ... <- shell escape" ] cat :: ( String -> String ) -> String -> ArgParser () (IO ()) cat f s = do expectToken s input <- inputFile output <- outputFile return $ input >>= output . f calc :: ArgParser () (IO ()) calc = expectToken "calc" >> sum >>= return . print where sum = fmap (foldr1 (+)) (sepBy product (expectToken "+") ) product =fmap (foldr1 (*)) (sepBy value (expectToken "*")) value = intArg parser = choice [ cat id "cat" -- cat , cat (unlines . map reverse . lines) "tac" -- cat but reverse lines , calc -- simple calculator, only knows how to do + and * operations ] main = do action <- handleArgs parser () usage action ---------------------------------------------------- Marc Weber

1 0

Re: HDirect and GHC-6.6
by shelarcy 12 Jan '07

12 Jan '07

Hi Sigbjorn, Is there any plan to transition from CVS to darcs? HDirect is removed from darcs'ing fptools, and left cvs long ago. Because HDirect is not active. http://www.haskell.org/pipermail/cvs-ghc/2005-October/026817.html But HDirect is updated sometime. (We can see HDirect moves 'comlib' into a hierarchic setting, System.Win32.Com.* two month ago.) And Visual Haskell project changes comlib. http://www.haskell.org/pipermail/haskell/2006-September/018445.html http://www.haskell.org/pipermail/haskell-cafe/2006-September/018037.html Unfortunately these changes are independent. It forks comlib now. So I want to know what is common change both repository and what is useful change both version, easily. I think darcs'ing HDirect and two comlib branch realise it. And that helps to revive Visual Haskell's HDirect that can generate it's comlib source code. Best Regards, On Fri, 12 Jan 2007 00:53:59 +0900, Sigbjorn Finne <sof(a)galois.com> wrote: > you may want to check out the CVS version of HDirect, which > does have a version of the compiler which is reasonably up-to-date > wrt GHC + Cabalized versions of both the 'comlib' and 'hdirect' > libraries. > > foo$ export CVSROOT=:pserver:anoncvs@cvs.haskell.org:/cvs > foo$ cvs login > (Logging in to anoncvs(a)cvs.haskell.org) > CVS password: cvs > foo$ cvs co fptools/hdirect > > (Derived from CVS setup instructions at http://cvs.haskell.org/ ) > > I apologize for not having the time to work on or support that code. -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

2 1

FW: HDirect and GHC-6.6
by Simon Peyton-Jones 11 Jan '07

11 Jan '07

forwarding to libraries From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Fernand Lacas Sent: 10 January 2007 21:25 To: glasgow-haskell-users(a)haskell.org Subject: HDirect and GHC-6.6 Hello, This is my first post on this mailing list and I hope it will not be too off-topic. My point is that I have worked a little on the porting of the last (0.21) version of HDirect (http://www.haskell.org/hdirect/) to ghc 6.6. I succeeded in compiling the ihc.exe (idl compiler) but I'm now stuck on the boot-strapping of the COM library (which is required to have support for Automation). This seems to come from a new feature of the package management system, which includes the package's name in the interface files (.hi). Alas, on the beginning of this new year (happy new year to you all), I lack time to understand the cabal system to solve this. I've written to the people mentioned in the README (and others), which are supposed to support the library, but got no answer. I assume they are no longer supporting it. Thus, I simply wanted to know if someone on this list, more involved with ghc or haskell's community, would be interested to have the sources files so that, may be in the near future, hdirect could be up to date with ghc, and also that other people could benefit from that small contribution without re-inventing the wheel (my changes are not complex, but rather tedious because I had to track all deprecated libraries, correct a GHC-specific bug). I also think that hdirect build process should be translated to Cabal's setup (it currently uses Makefiles, but the build process is not straightforward, so the adaptation requires a knowledge I do not have of Cabal). Sincerely yours, Samuel P.-S. I do not check this mail on a daily basis, so it is possible I won't answer immediately, but within one or two days. Excuse my french, it is my mother tongue. __________________________________________________ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail

1 0

WikiHaddock
by Conal Elliott 10 Jan '07

10 Jan '07

Suppose Haddock's documentation language ("-- | ...") were an extended form of a common wiki markup language, and specifically Wikimedia's, because the Haskell wiki uses it. Instead of converting to HTML, Haddock could then pass through most markup unchanged and make wiki links out of its current link markup (modules & entities). Some benefits: - We'd all get a much richer (and extensible) markup language. - We'd have only a single markup language (Wikimedia's) to learn instead of two, and no need to convert between them manually. - Automatically generated links to user-comment pages would be wiki links, so one could tell by looking at them whether there are any comments already there. Comments? - Conal

3 4

ListClass simple implementation
by Marc Weber 10 Jan '07

10 Jan '07

Those who want to contribute: I've startet a darcs repository here darcs get shp@mawercer.de:/home/shp/darcs/ListClass pwd: shp Very much is still missing. Strange: I'm getting this error: marc@localhost /tmp/ListClass $ darcs get shp@mawercer.de:darcs/ListClass darcs failed: (sftp) failed to fetch files. source directory: darcs/ListClass/_darcs/patches source files: 20070110115136-ce738-38caa6448a675897ce2f755ad2caa8f4b060f33d.gz 20070110115103-ce738-4248ec806c18d50ae001281d6ff37b41eafb2889.gz 20070110032620-ce738-7c4ae0f11d3a40b397b31fbea82975b69ea0938d.gz sftp output: Request for subsystem 'sftp' failed on channel 0 Couldn't read packet: Connection reset by peer But you should be able to use scp Greetings Marc

2 2