June 2005 - Libraries

cabal permissions problems
by Frederik Eaton 25 Jun '05

25 Jun '05

I think I remember running into something like this a long time ago and mentioning it to someone, is it fixed in a new version of Cabal? I'm using ghc 6.4... The problem is that executable files are installed to be only executable by user: $ ls -al built/bin/ total 3644 drwxrwxr-x 2 frederik frederik 4096 2005-06-25 15:35 . drwxrwxr-x 3 frederik frederik 4096 2005-06-24 19:57 .. -rwxrw-r-- 1 frederik frederik 1183668 2005-06-25 15:40 fcq -rwxrw-r-- 1 frederik frederik 2528637 2005-06-25 15:40 fcq-www.cgi $ umask 002 I haven't experienced this with any other installation procedures, only Cabal. Thanks, Frederik -- http://ofb.net/~frederik/

1 0

ANNOUNCE: Gtk2Hs version 0.9.8 released
by Duncan Coutts 24 Jun '05

24 Jun '05

Gtk2Hs - A Haskell GUI library based on the Gtk+ GUI Toolkit. Version 0.9.8 is now available from: http://haskell.org/gtk2hs/ Changes since 0.9.7: * much greater API coverage, including the new Gtk+ 2.6 APIs * Yampa/wxHaskell-style properties added for all widgets * improved reference documentation, there is more of it and the docs for each module are now split into sections. * works with GHC 6.4 * there is now an easy-to-use installer for Windows * build process now works in 80Mb of RAM rather than 380Mb * added functions for manipulating Pixbufs using the Haskell mutable array interface * fixed a limitation on signal handlers on Sparc machines * minor API changes * minor bug fixes * completed GPL to LGPL conversion * internal code cleanups and improvements The API changes are documented here: http://haskell.org/gtk2hs/archives/2005/06/20/api-changes-between-gtk2hs-09… Other changes since the last release announcement: * new screenshots, including HRay and HanDict: http://haskell.org/gtk2hs/screenshots/ * we are now included in the Gnome news feed: http://planet.gnome.org/news/ Gtk2Hs feature highlights: * automatic memory management * Unicode support * nearly full coverage of Gtk+ 2.6 * bindings for several Gnome modules: * libglade for loading GUIs from xml files at run-time. This allows you to design your user interface visually with the Glade user interface builder. (This works on Windows too.) * GConf, Gnome's system for storing app preferences * SourceView, code editor widget with syntax highlighting * the Mozilla browser rendering engine in a widget * API reference documentation * multi-platform support with native look * LGPL licence Platforms and requirements: * an installer for Windows is available * packages are now available for Fedora Core 3,4 and Gentoo * packages for other platforms should become available soon * builds from source on Linux, Windows, MacOS X and Solaris * builds with GHC 6.4.x, 6.2.x, 6.0.x and 5.04.x * works with Gtk+ version 2.0 through to 2.2, 2.4 and 2.6 * optional Gnome support requires Gnome 2.0 or better * optional Mozilla support requires Mozilla 1.4 or better Goals for the 1.0 release: * autumn 2005 release * a stable API for the 1.0.x series * complete coverage of the Gtk+ API (we're about 90% there now) * support for OpenGL 3D rendering API * support for cairo 2D rendering API * bindings for more Gnome modules * introductory and other tutorials * packages for all popular platforms Please report all problems to gtk2hs-users(a)sourceforge.net Contributions and feedback are also most welcome. Duncan

2 3

rfc: package mounting
by Frederik Eaton 23 Jun '05

23 Jun '05

Hi all, It looks like there's been a bit of recent discussion regarding module and package namespaces. There is a certain possible design feature that I don't think has been mentioned yet, that I think would be very helpful, so I thought I should at least bring it up. What I want is to be able to build a module namespace for a program out of packages in much the same way that filesystem namespaces are built, namely with mounting operations, rather than just by "union" or "overlay" operations as in the status quo. In other words I would like to be able to specify along with the "-package" option a "mount point" for that package in the module namespace. One possible option syntax might be e.g. "-package my-graphics-lib -package-base Graphics.UI.MyGraphicsLib". (Also, for backward compatibility and convenience, packages should probably be able to specify a default "mount point", to allow existing compiler command-line syntax to be used.) The idea is that with such a feature, library packages could get rid of the common module path prefixes which currently must be specified in every module in the library (such as "Graphics.UI.MyGraphicsLib" above). These prefixes would instead be specified once by each user of the library package (unless the default was desired), perhaps after the package import option on the compiler command line. Modules would have simple unqualified names within the library, like "Button" or "Window" which, if the package mount point were specified as say "Graphics.UI.MyGraphicsLib" in a certain compiler invocation, would be mapped to "Graphics.UI.MyGraphicsLib.Button" and "Graphics.UI.MyGraphicsLib.Window" respectively for code compiled by that invocation. But they could just as easily be mapped to "MGL.Button" etc. in a different invocation in a different project if a different mount point were preferred or were necessary to eliminate a namespace collision. There would be many benefits to being able to do things this way. First, developers would be able to move shared code across libraries without having to worry about the need to make widespread trivial changes to reflect the new module names. I could copy a 'Debug' or 'Util' module into my library from another library, and not have to go through the code to update the module hierarchy base location - furthermore I could incorporate new upstream changes easily without having to repeat this menial fixing-up procedure each time. While it's true that new version control systems like 'darcs' are meant to handle search-and-replace style changes effectively, I think that as far as this issue goes, a VC-based solution would be less elegant and less usable than what I am proposing. Second, this would decouple some aspects of the design process that in my opinion shouldn't be coupled. I would be able to start writing a library before deciding on a name, for instance - currently I at least have to stick in a dummy name as the module namespace base to avoid potential conflicts with other library imports while testing. But under this proposal I could just concentrate on building interior, bottom-up functionality first - at the end of the process a certain set of the package modules would be marked for external visibility, would comprise the exterior interface, and would suggest to me a fitting package name. Setting this name would only involve touching the cabal file rather than every single source file in my library. This would also make it easier to merge and split packages. Third, it would encourage the use of lightweight modules, by reducing the maintenance overhead of each module. Currently modules are the only way (correct me) to partition parts of the top-level namespace of a program - this is OK except that especially in libraries each module contains a certain amount of administrative paperwork, which is to say that it has to know the name of the library that contains it, because that, or some form of it, has to be part of the module name; and other importers of the module have to specify this information too; and as argued above there is a little work involved in touching up these references when code moves between libraries or when the library name changes. As a result I think people end up sticking more code in the same module at times when multiple modules would have been otherwise more suitable. Fourth, I think there would be psychological benefits. I think it's a bit patronizing to the programmer that he has to pretend to remind himself "you are in the following package" at the top of each file. I think people can easily enough keep track of that amount of state. It's as if the building code required me to put a sign with the current city and country in each room of my house. These are bits of context that I can easily call to mind if necessary, but which I would sometimes like to temporarily forget about. I believe programming is somewhat the same. We've come a long way from languages like C where one has to decide whether to precede each symbol in a library with an otherwise-meaningless identifier like "Py_", or risk namespace collisions with other libraries - but I don't think we're at the end of the road yet. It's true that if a module occurs in a package then that is its package, but often the package name doesn't do anything to suggest what the module functionality is - maybe the module exists only because other package modules depend on it, or maybe the package provides an assortment of otherwise unrelated functionality in its modules. In other words, the package name may describe something that the module functionality is only *applicable* to, or it may just be a catchy name. Being able to leave out this not-quite-relevant piece of information would make package-distributed code more conceptually streamlined, easier to quote out of context in e.g. papers, etc. Haskell is really a beautiful language - it's very dense and I think it is one of its great advantages that it allows the programmer to eliminate from code almost all save that which is absolutely relevant to its functionality - this proposal would take the language further in that direction. There is a strong tradition in science to put things in taxonomies, in static hierarchies, and people have tried to do this with collections of code libraries too, perhaps in imitation of scientists. One thing to note however is that the things from the natural world such as the genes of biological organisms change a lot more slowly than man-made code does. Science is different from engineering. A related reason that language designers may be drawn to requiring users to participate in universal classifications is that doing so projects an artificial aura of stability and organization onto the evolving code situation. But these designers, in shading themselves from progress, also stifle it. They create a central administrative hoop which couples all packages and impacts the scalability of the collective development effort. What I'm proposing would be a big departure from the practice of languages like Perl and Java that demand such a global module hierarchy. I've been told that the Haskell community is trying to make it so that two packages can have modules of the same name, as long as they aren't imported in the same compilation unit. My proposal would go further by (1) removing the latter restriction (2) allowing the package code to be completely ignorant of any "mount point". By the way, if you look at some aspects of operating system interfaces I think you'll see that often the choice I'm suggesting has already been made. For instance, you don't have to specify your current working directory with every command you execute, and furthermore the same command can easily be used in different working directories without modification; you can install binaries at different locations in the filesystem; you can mount filesystems at different mount-points, etc. One further thing, there have been proposals to simplify the importing of collections of modules from a certain point in the namespace, etc. I hope it is realized that they are independent from my proposal. They would not be very useful in implementing my proposal, at least I think any such solution would be far from optimal; and vice-versa. Modules and packages are quite distinct constructs, modules are needed for namespace partitioning and packages are needed to delineate administrative boundaries and sources of change. Both are necessary and both deserve special consideration in the ongoing design of Haskell. I will not be surprised if it seems strange to people that I attach such importance to what is likely seen as an unimportant detail of the language, but I do, and I hope that people will consider my suggestion. Also, I haven't said anything about implementation. I realize that this would probably require some modification to the linker. I hope I'm correct in assuming that the modifications will be relatively easy to make, provided it turns out of course that this feature is really something that people want. Frederik P.S. Thanks to John Meacham for a useful discussion. -- http://ofb.net/~frederik/

1 0

Re: [Haskell] Haskell XML RPC
by Bjorn Bringert 21 Jun '05

21 Jun '05

Johannes Waldmann wrote: > I am looking at the Haskell XML RPC library http://www.haskell.org/haxr/ > First of all, this is a very nice thing to have, and installation is > really easy, using Cabal and the packaged source archives. Hi Johannes, I'm the maintainer of HaXR, and I'll try to answer your questions as well as I can. I'm moving this thread over to the Haskell Libraries list. > *) Of course I want to dervie XmlRpcType instances automatically. > The examples suggest $(asXmlRpcStruct (reifyDecl Person)) > but I cannot get this to compile (with ghc-6.4). It seems reifyDecl is > gone, and reify has different type. I worked out this: > > helper name = asXmlRpcStruct > ( ( reify name ) >>= ( \ (TyConI dec) -> return dec )) > > $(helper ''Person) > > Does xmlrpc.cabal should contain a build-dependency > on template-haskell? (Otherwise I get linker errors.) Thanks for reporting this. I have fixed it in the development version available in the darcs repo at http://cvs.haskell.org/darcs/xmlrpc/ and made a new release today which fixes the TH support. > *) what is the recommended representation that should be created > for data T = A { .. } | B { .. } | ... i. e. discriminated unions? > Certainly some solution can be coded, but ... Hmm, I haven't had a need for that yet, so I haven't thought about it. If you come up with a good solution, we could modify THDeriveXmlRpcType to do it automatically. > *) what about the "Java side of things" - perhaps I want (need) > to interface to a Java Client. If it's Haskell-to-Haskell, > then both server and client of course can derive their > XmlRpcType instances from identical data declaraions > and everything is fine. For intergration with a different language, > what do you recommend: Start from a Haskell data declaration, > and derive a Java representation, directly or indirectly? > Or start from some language independent data declaration, > as it happens (I assume) for JAXB? Hmm, I guess it's up to you. If you come up with a good solution, or even a tool for autogenerating Haskell types and XmlRpcType instances from som language-independent description, I'll be happy to include it in HaXR. /Björn

1 0

RE: Default prefix for Cabal on Windows
by Simon Marlow 21 Jun '05

21 Jun '05

On 21 June 2005 12:42, Ross Paterson wrote: > Actually you have > > libdir = $(prefix)/lib/$(PackageId)/$(CompilerId) That's what I meant, sorry. Simon

1 0

RE: Default prefix for Cabal on Windows
by Simon Marlow 21 Jun '05

21 Jun '05

On 17 June 2005 17:19, Ross Paterson wrote: > On Thu, Jun 16, 2005 at 04:46:18PM +0100, Simon Marlow wrote: >>> Simon Marlow wrote: >>> >>>> Ok, so $(ProgramFiles) is determined by the registry. Taking into >>>> account comments so far, I think we have: >>>> >>>> prefix = $(ProgramFiles)\Haskell\$(PackageName)-$(Version) >>>> libdir = $(prefix)\$(Compiler)-$(Version) >>>> bindir = $(prefix)\bin >>>> >>>> these are only defaults - users & packagers are free to change >>>> them. >> >> Slight modification after Brian's comments: if the package is an >> executable, then >> >> prefix = $(ProgramFiles)\$(PackageName)-$(Version) >> >> (i.e. only libraries on under $(ProgramFiles)\Haskell). > > The default value of $(prefix) under Unix recently silently changed > from /usr/local to /usr/local/$(Compiler)-$(Version). I'm not sure > that's the right thing: it's incompatible with the FHS and with > autoconf, and puts executables in a place that's not on my path. I've fixed that, and made the changes above. However, I think $(libdir) and $(bindir) should be configurable as options to ./setup configure (weren't we going to do that at one stage?). The story is now: On Windows, prefix | is_excutable = $(ProgramFiles)\$(PackageId) | is_library = $(ProgramFiles)\Haskell\$(PackageId) libdir = $(prefix)\$(CompilerId) bindir = $(prefix)\bin On Unix, prefix = "/usr/local" libdir = $(prefix)/$(PackageId)/$(CompilerId) bindir = $(prefix)/bin This is ok for the default prefix, but not great if you want to set prefix to /opt/pkg-1.0, for example - that's why we need to be able to set libdir independently. Cheers, Simon

2 1

Re: [Haskell-cafe] CGI module almost useless
by Sven Panne 18 Jun '05

18 Jun '05

[ Moving this thread slowly to the libraries list... ] Bjorn Bringert wrote: > John Goerzen wrote: > >> My apologies if this sounds like a bit of a rant; I know people put good >> effort into this, but.... >> >> The Network.CGI module in fptools (and GHC) is not very useful. I think >> that it should be removed or re-tooled. Here are the main problems with >> it: >> >> 1. It does not permit custom generation of output headers. Thus the CGI >> script cannot do things like set cookies, manage HTTP auth, etc. >> >> 2. It does not permit generation of anything other than text/html >> documents. Many CGI scripts are used to manage other types of >> documents. Notably this makes it incompatible with serving up even >> basic things like stylesheets and JPEGs. >> >> 3. It does not permit the use of any custom design to serve up HTML, >> forcing *everything* to go through Text.Html. This makes it impossible >> to do things like serving up HTML files from disk. >> >> 4. There is documentation in the code, but it is as comments only, and >> doesn't show up in the Haddock-generated GHC library reference. (Should >> be an easy fix) >> >> 5. It does not appear to support file uploads in any sane fashion >> >> Is there a better CGI module out there somewhere that I'm missing, or >> should I just set about writing my own? > > > I wrote this module (based on the Network.CGI code) a while ago: > > http://www.dtek.chalmers.se/~d00bring/darcs/blob/lib/Network/SimpleCGI.hs > > I don't remember what it does really, but I think it solves issues 1,2,3 > and some of 4. Although (among other people) I did some hacking in this module in the remote past, I don't have the time and energy to maintain and/or extend this module anymore. It would be really great if somebody more actively working in this area could take the spec lead here and push the development via discussions here on this library list. John? Björn? A few general design thoughts: * To keep people's mind sane, backwards compatibility with the existing Network.CGI would be a very worthy goal. * Don't use any Haskell language extension available. :-) Currently the module can be used e.g. by Hugs in H98 mode, and keeping it that way would again be something very desirable. Cheers, S.

5 6

RE: Default prefix for Cabal on Windows
by Simon Marlow 17 Jun '05

17 Jun '05

On 16 June 2005 16:23, Daan Leijen wrote: > Simon Marlow wrote: > >> Ok, so $(ProgramFiles) is determined by the registry. Taking into >> account comments so far, I think we have: >> >> prefix = $(ProgramFiles)\Haskell\$(PackageName)-$(Version) >> libdir = $(prefix)\$(Compiler)-$(Version) >> bindir = $(prefix)\bin >> >> these are only defaults - users & packagers are free to change them. >> >> Sound reasonable? > > Sounds fine to me. Slight modification after Brian's comments: if the package is an executable, then prefix = $(ProgramFiles)\$(PackageName)-$(Version) (i.e. only libraries on under $(ProgramFiles)\Haskell). Cheers, Simon

2 1

RE: Cabal help please
by Simon Marlow 17 Jun '05

17 Jun '05

On 16 June 2005 18:12, Adrian Hey wrote: > On Thursday 16 Jun 2005 4:48 pm, Isaac Jones wrote: >> "Simon Marlow" <simonmar(a)microsoft.com> writes: >>> On 16 June 2005 15:36, Adrian Hey wrote: >>>> Hello, >>>> >>>> I'm just getting around to tidying up the AVL library and releasing >>>> a new version and, of course thinking about Cabalising it too. But >>>> I'm finding difficult to figure out how to do this from the >>>> Cabal docs and Distribution library haddock. >>>> >>>> Anyway, what I want to do is.. >>>> Run cpphs on all the sources >>>> Compile the results using -split-objs (for ghc at least). >>> >>> Cabal doesn't support -split-objs at the moment. To do this you'll >>> need to write your own Makefile and hook it up to Cabal (possible, >>> but a bit fiddly I believe). >> >> Can someone outline what cabal needs to do to support this? > > I can't answer your question, but I can say using split objs is a > bit weird if you're not familiar with how ghc does it (dunno > if you are or not). The split objects don't seem to go in the > same directory as the main object (in this case a dummy object) > would go (according to hierarchical name). Instead they seem to > get placed in the root object directory $(OBJDIR). -split-objs is a bit weird, and I don't think it currently works with --make. So I think the best route is for us to fix GHC first, and then let you know what the (hopefully minimal) changes to Cabal should be. Cheers, Simon

1 0

Re: Default prefix for Cabal on Windows
by Brian Smith 17 Jun '05

17 Jun '05

* The "Program Files" folder usually has at least one space in its path, which could cause a lot of problems for Unix-centric software. For this reason alone, I always install anything that isn't Windows-specific into "c:\software" instead of "C:\Program Files." If the default prefix is going to be "Program Files" then there should be a note in the Cabal documentation that the application should expect to be installed into a directory with spaces in the path. * Even if a program is written in Haskell and is built with Cabal, I imagine that people who write Windows Haskell software for non-developers will not expect users to install the software via Cabal. Instead, they will provide an MSI with a GUI installer. That means that, for the most part, the only users of Cabal on Windows will be programmers. So, I think that the Cabal experience on Windows should be optimized for us. In particular, if I run "runghc Setup.hs install" when I am using MSYS Bash, I want the package to install into "/usr/local/" just like it would on Unix. * I don't think it makes sense for executable packages to have "Haskell" in their prefix unless they are explicitly "for Haskell." For example, Darcs isn't a Haskell tool; it is a versioning tool that happens to be implemented in Haskell, so it wouldn't make sense for it to be installed into "C:\Program Files\Haskell\Darcs-1.0," just like we wouldn't want it installed into "C:\Prgoram Files\C#\Darcs-1.0" if it was written in C#. Conversely, library packages are presumable Haskell-specific and so it makes sense for them to have "Haskell" in their prefix. Just my 2 cents. - Brian - Brian [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl… [2] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html… - Brian or > > 2) C:\Haskell\<package-name>-<version> > > where "Haskell" could also be "Packages" I guess. > > -- Daan Leijen > > Brian Smith wrote: > > On 6/15/05, *Simon Marlow* <simonmar(a)microsoft.com > > <mailto:simonmar@microsoft.com >> wrote: > > > > On 15 June 2005 05:49, Brian Smith wrote: > > > > > The documentation states in Section 3.1 that the default value of > > > "prefix" is "/usr/local" on Unix. However, it doesn't specify > > what the > > > prefix is on Windows. I found that the default value for prefix is: > > > C:\Program > > > Files\<package-name>\<compiler-name>-<compiler-version>. For example, > > > version 1.0 of a package named "Foo" compiled with GHC > > > 6.5 would have a default prefix of: > > > C:\Program Files\Foo\ghc-6.5 > > > > > > The compiler version is there to avoid conflicts in the case when you > > have multiple versions of GHC installed and the package is installed for > > each one. However, I don't think we currently include the compiler & > > version in the default $(libdir) on Unix, so whatever we do we should do > > > it consistently. > > > > > > Okay, that makes more sense to me. However, I think that executables > > should go in "C:\Program Files\<package-name>-<package-version>\bin," > > not <C:\Program > > Files\<package-name>\<compiler-name>-<compiler-version>\bin" as they do > > currently. > > > > - Brian > > > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > >

3 2