September 2005 - Libraries

StringMaps available
by Adrian Hey 13 Sep '05

13 Sep '05

Hello, I've put the first release of Data.StringMap here.. http://homepages.nildram.co.uk/~ahey/HLibs/Data.StringMap/ The implementation is a bit different than what was discussed earlier as I decided the first version would burn heap unecessarily. It's still based on Tries though. I'm afraid I won't be able to do much Haskelling for a few months so not much will be added in the near future. But if anybody would like to use this but finds the absence of some function or other a show stopping issue then let me know and I'll add it. Regards -- Adrian Hey

1 0

[Announce] CabalFind 0.1
by Dimitry Golubovsky 12 Sep '05

12 Sep '05

Some time ago, I expressed an idea that certain search engines may be used to collect information about existing .cabal packages whose developers made them indexable by those engines. Finally, I have written an experimental library, CabalFind. The library provides a generalized interface to search engines, and also sample implementations for Google and Yahoo* I haven't set it up as a separate project, say, on SourceForge because I am not sure whether it is feasible to do so. Instead, I am suggesting that the developers of Haskell Library Infrastructure decide whether this library may serve as a basis for some library infrastructure maintenance utilities. The library may be downloaded at darcs get http://www.golubovsky.org/repos/cabalfind/ or http://www.golubovsky.org/repos/cabalfind/cabalfind.tar.gz The .cabal file for the package is tailored for GHC 6.2.2. For use with 6.4, changes may be necessary, as the XML Toolbox for 6.4 no longer includes the HTTP module, so HTTP.cabal needs to be included in build-depends. More information provided at http://haskell.org/hawiki/CabalFind Any feedback is appreciated. ------ * Only these two search engines are found to be able to search by URI suffix (.cabal in our case); without this feature package search becomes very inefficient. -- Dimitry Golubovsky Anywhere on the Web

1 0

HSQL / MySQL Problem (was GHCI Problem)
by Dominic Steinitz 11 Sep '05

11 Sep '05

> > >Am Sonntag, 4. September 2005 16:26 schrieb Dominic Steinitz: >>/ Can anyone tell me why ghci has this problem whereas ghc itself doesn't and >/>/ how I fix it. >/>/ >/>/ Thanks, Dominic. >/>/ >/>/ [dom at tility <http://www.haskell.org/mailman/listinfo/libraries> LAMH]$ ghci -package hsql-mysql >/>/ ___ ___ _ >/>/ / _ \ /\ /\/ __(_) >/>/ / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98. >/>/ / /_\\/ __ / /___| | http://www.haskell.org/ghc/ >/>/ \____/\/ /_/\____/|_| Type :? for help. >/>/ >/>/ Loading package base-1.0 ... linking ... done. >/>/ Loading package hsql-1.6 ... linking ... done. >/>/ Loading package hsql-mysql-1.6 ... ghc-6.4: can't load .so/.DLL for: c >/>/ (/usr/lib/libc.so: invalid ELF header) >/>/ [...] >/ >It looks like the package description of hsql-mysql explicitly mentions "-lc" >for linking (or something like that). Simply removing that superfluous flag >should fix the problem, but I'm only guessing here, as I've never used that >package. > >Cheers, > S. > Sven, Thanks for the suggestion but it's not obvious to me what I'm looking for. Here's the package description. Dominic. [dom@tility HSQL]$ ghc-pkg describe hsql-mysql name: hsql-mysql version: 1.6 license: BSD3 copyright: maintainer: stability: homepage: package-url: description: MySQL driver for HSQL. category: Database author: Krasimir Angelov <kr.angelov(a)gmail.com> exposed: True exposed-modules: Database.HSQL.MySQL hidden-modules: import-dirs: /usr/local/lib/hsql-mysql-1.6/ghc-6.4 library-dirs: /usr/local/lib/hsql-mysql-1.6/ghc-6.4 /usr//lib/mysql hs-libraries: HShsql-mysql-1.6 extra-libraries: mysqlclient z crypt nsl m c nss_files nss_dns resolv include-dirs: /usr//include/mysql includes: depends: base-1.0 hsql-1.6 hugs-options: cc-options: -mcpu=i486 -fno-strength-reduce -IDatabase/HSQL ld-options: framework-dirs: frameworks: haddock-interfaces: haddock-html:

2 2

ANNOUNCE: Gtk2Hs special release with cairo support
by Duncan Coutts 09 Sep '05

09 Sep '05

To mark the end of Paolo Martini’s project to add support for the cairo vector graphics library (cairographics.org) we are pleased to announce a special “tech preview” release of Gtk2Hs including Paolo’s contributions. Here’s a screenshot from a demo program Paolo and others wrote to show off the combination of Haskell, cairo and Gtk+. http://haskell.org/gtk2hs/gallery/Cairo-demo/Cairo_demo_13 You can see more of his latest screenshots in his blog. http://haskell.org/gtk2hs/archives/category/cairo/ As of version 2.8, Gtk+ now depends on cairo and uses it for much of it’s drawing. It is a great advance over Gtk’s previous drawing API. The cairo website describes it thusly: Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System, win32, and image buffers. Experimental backends include OpenGL (through glitz), Quartz, XCB, PostScript and PDF file output. Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (for example, through the X Render Extension). The cairo API provides operations similar to the drawing operators of PostScript and PDF. Operations in cairo including stroking and filling cubic Bézier splines, transforming and compositing translucent images, and antialiased text rendering. All drawing operations can be transformed by any affine transformation (scale, rotation, shear, etc.). We encourage anyone who has Gtk+ 2.8 installed to give this Gtk2Hs release a try and to experiment with using the cairo drawing API. Bug reports and cool screenshots will be gratefully accepted. Download: http://haskell.org/gtk2hs/gtk2hs-0.9.9.5.tar.gz The release includes some demos showing how to use cairo in a stand alone fashion to produce PNG image files and also demos showing how to use the cairo API for drawing in a Gtk+ GUI (both real-time and non-real-time). There is also some preliminary reference documentation available: http://haskell.org/gtk2hs/docs/gtk2hs-docs-0.9.9.5/ This release is not intended for packaging for distros. The next ordinary release will of course retain the cairo support. It is intended that the cairo package will eventually be distributed separately since it is useful in non-GUI programs too. This project was undertaken by Paolo as part of Google’s Summer of Code programme. In our opinion his project has been a success and so we would like to recommend to Paolo’s official mentor at Google and the judges that he be counted amongst the successful SoC programme participants and awarded the full project grant. Duncan (on behalf of the Gtk2Hs team)

1 0

dumb cabal question
by Frederik Eaton 05 Sep '05

05 Sep '05

By the way, as I've been thinking about Cabal, I remembered this question to which I haven't found an answer. I realize that I haven't been party to the initial discussions, but John Meacham didn't know the answer either, so I will ask it. As I understand it, Cabal is meant to provide people with a compiler-independent way to build Haskell packages. So it (a) builds packages while (b) abstracting over compiler interfaces. Why was the decision made to couple these two functions into a single project? It seems to me that maybe having two separate projects would be more manageable and useful. - The first project would provide a standard command-line interface to Haskell compilers. There would be operations such as: compile a file into an object file (may be a no-op); link a bunch of object files into a package; install a package into the following package database; create an empty package database; merge two package databases; find dependencies of a module. And options like: use the following other packages, search for packages in the following package database. Basically, the things that compilers can do, but given a standard interface. - The second project would provide a build system. I guess there would be a lot of options here. There seems to be a demand for a system with some main declarative specification file which can be processed by external tools to find out what dependencies a project has on other projects, etc., which Cabal is responding to. So perhaps people would write something like this. However, if there were two separate projects, then developers would also have the freedom to use a build system like 'make', or something more sophisticated and unforeseen, with the generic compiler interface as well. By decoupling the standard compiler interface and the build system, one would be able to make improvements independently to each one. Design and development would be faster, users would have more choices, it would be easier to experiment with new versions of each project. So, back to my question. Why couple the two? Frederik -- http://ofb.net/~frederik/

4 8

GHCI Problem
by Dominic Steinitz 05 Sep '05

05 Sep '05

Can anyone tell me why ghci has this problem whereas ghc itself doesn't and how I fix it. Thanks, Dominic. [dom@tility LAMH]$ ghci -package hsql-mysql ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Loading package hsql-1.6 ... linking ... done. Loading package hsql-mysql-1.6 ... ghc-6.4: can't load .so/.DLL for: c (/usr/lib/libc.so: invalid ELF header) dom@tility LAMH]$ ghc -o ListReminders ListReminders.hs -package WASH-CGI -package hsql-mysql [dom@tility LAMH]$

2 1

cabal design wiki pages
by Frederik Eaton 04 Sep '05

04 Sep '05

Hi all, I've put up some pages on the wiki to provide a forum for discussion about the design of Cabal, as Isaac has asked me to do. http://haskell.org/hawiki/Cabal/Design Things still need to be done. The TODO list, which I just copied from the Cabal distribution, probably needs to be edited (maybe it should only contain current items?). This is partly an experiment to see what can be accomplished with the wiki model. I was kind of depending on email change notification being available (I was told that it was) to make things quicker, but it hasn't been enabled on this installation. Shae Erisson is apparently working on it. There are some things that I want to point people to, however. The first is a discussion about how to add proper virtualization to Cabal: http://haskell.org/hawiki/Cabal/VirtualizationRequirements There are some proposals. The second is a set of questions that have been raised by myself and others about the GHC packaging system in the process: http://haskell.org/hawiki/GHCPackageDesignFAQ It would be nice if someone could add answers to the second document, to compliment my questions. I don't know how much time I'll have to spend on Cabal after this, since I'll be in school. I've pointed out what I think are some serious design flaws in the way both Cabal and GHC think about packages, which will become more apparent and more serious if these tools get wider adoption, and I hope that my comments have been valued. Frederik -- http://ofb.net/~frederik/

1 0