- Libraries - Haskell.org

RE: cabal design
by Simon Marlow 17 Sep '05

17 Sep '05

Ok, I've read through this discussion. Could somebody explain to me why this whole "virtualization" thing can't be solved by simply adding the flag --package-db=<file> to Cabal? It would be another option in the --user/--global family. The idea isn't new - I'm sure we've discussed this before. It seems to suffer from none of the problems of the other suggestions, but perhaps I'm missing something. For Hugs, the <file> would actually specify a directory. Additionally, --package-db=<file> is a step on the way to other things that we want to do (--in-place). It seems to me that the requirement is basically this: - To be able to install packages in a group, such that all packages in the group are registered in a single, separate, package database. the fact that in the proposed use cases the packages are also installed under a pseudo-root is a red herring as far as Cabal is concerned. We don't care where you install your packages or what files they contain. So the question becomes how to specify which "package group" a package should be registered in. I propose the simplest thing: tell Cabal the location of a package database. The other proposals (--prefix and --root) require Cabal to magically derive the location of the package database from the "root" directory, but that's magic that we don't need/want IMO. I'm happy to add support for GHC_PACKAGE_PATH, as requested in this discussion. Cheers, Simon

4 3

AVL library update
by Adrian Hey 15 Sep '05

15 Sep '05

Hello, I've put a new version 2.3 of Data.Tree.AVL here.. http://homepages.nildram.co.uk/~ahey/HLibs/Data.Tree.AVL/ Changes in this version include.. * Added genPush' and genPushMaybe' functions which provide strictness control which was missing from earlier versions. * Added symmetric difference to the set functions * I decided to use the prefix "assert" for partial function names. So there has been a bit of renaming (old names are still OK but deprecated, and I might have missed a few :-) Regards -- Adrian Hey

1 1

RE: cabal packaging and --libdir
by Simon Marlow 13 Sep '05

13 Sep '05

On 13 September 2005 10:52, Jens Petersen wrote: > I think a --libdir option is needed in Cabal to help packagers > that need to specific where libraries are installed. > > For example Fedora Core x86_64 (amd64) arch 64bit libs should be > installed under $prefix/lib64, whereas cabal assumes $prefix/lib. > > Could a --libdir please be added or is there another way? I had a proposal for this recently, but it hasn't been implemented yet: http://www.haskell.org//pipermail/libraries/2005-August/004232.html (there are earlier and later messages in that thread). Cheers, Simon

1 0

cabal packaging and --libdir
by Jens Petersen 13 Sep '05

13 Sep '05

I think a --libdir option is needed in Cabal to help packagers that need to specific where libraries are installed. For example Fedora Core x86_64 (amd64) arch 64bit libs should be installed under $prefix/lib64, whereas cabal assumes $prefix/lib. Could a --libdir please be added or is there another way? Jens -- Fedora Haskell packages http://haskell.org/fedora

1 0

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