July 2006 - Libraries

RE: Idea to allow people to comment on Haskell docs
by Simon Peyton-Jones 09 Jan '07

09 Jan '07

| I've had a go at patching Haddock to put a link on the page for each | module. It's controlled by an optional --wiki=URL flag. | | As an example, I used this with the (devel version of the) Gtk2Hs docs: | | http://haskell.org/gtk2hs/docs/devel/ | | For example this page: | | http://haskell.org/gtk2hs/docs/devel/Graphics-Rendering-Cairo-SVG.html It looks great! But I'd never have found the link if you hadn't pointed me at it. Rather than "Wiki" say "User comments". And I think the per-entry [User comment] link is essential. Typically people are going to be looking at a particular thing. For example, here http://haskell.org/gtk2hs/docs/devel/Graphics-Rendering-Cairo-SVG.html#v %3AsvgRenderFromString is where I'd look for the link for svgRenderFromString. Does MediaWiki support anchors in the middle of a page? That's essential here -- we want one Wiki page for one Haddock page. On a closely related matter, Benjamin Pierce told me how often he wished that there was a link from the Haddock documentation to the source code for a function. Especially for Prelude functions, he's dead right. So another really useful Haddock enhancement would be the ability to add links to the source code from the Haddock docs --- again on a per-function basis. Do you feel like adding that too? Where should the code live? I'd suggest snap-shoting it at the moment that the Haddock docs are generated, and putting the files with the Haddock docs. Simon

12 15

Success Story: Cabal and Dlls
by Jason Dagit 01 Dec '06

01 Dec '06

Hello, I would like to report that I was able to use Cabal with Visual Haskell to build Dlls in windows. I have posted the details about this on the Haskell wiki (and started an extremely minimal Cabal page). If my content is in the wrong place, please feel free to move it (or edit it or whatever). http://www.haskell.org/haskellwiki/Cabal The trick was to take the final HSfoo-0.1.o file generated by the normal build process (and linked with the DllMain.c code) and tell ghc to build a dll. I use -package with each of the dependencies in the cabal file to link with the needed libraries. The resulting dll seems to be working. This approach is a bit hackish and while I've tried to implement as much of it as I can in a general way it requires you to hack your Setup.lhs file if you want to 1) build static 2) specify your exports 3) specify the name of the resulting dll. Also, it's only been tested on my setup which uses Visual Haskell so it may not be fit for general consumption. Finally, I just started really looking at Cabal yestarday so I may not have considered things which an experienced Cabal user would think about. Is it possible to get this functionality built directly into Cabal so that I tell it I want a DLL built from a library and it knows how to make it happen? Thanks, Jason

5 11

Replacing Network.CGI with NewCGI
by Bjorn Bringert 22 Aug '06

22 Aug '06

Any users of Network.CGI here? I would like to propose replacing the current Network.CGI module with what is now known as Network.NewCGI [2]. This has been mentioned briefly before [1]. The new module is backwards compatible with the old one (except for the export of Text.Html.Html, which is now Text.XHtml.Html). Here is what I would like to do: - Remove Network.CGI from the network package. - Change the name of Network.NewCGI to Network.CGI - Add the cgi package to http://darcs.haskell.org/packages/ - Add the xhtml package [3] to http://darcs.haskell.org/packages/ This is needed since the cgi package uses it to generate error pages. Any comments, suggestions, or objections? Here is a summary of the features of NewCGI: - Access to CGI parameters (e.g. form input) from both GET and POST requests. - Access to CGI environment variables. - Ability to set arbitrary response headers. - Support for HTTP cookies. - An efficient implementation of multipart/form-data using Data.ByteString. This allows for efficient handling of file uploads. - Wrapper functions for compatibility with the existing Network.CGI module. - A CGI monad transformer. - Basic exception handling and logging. - Low-level run functions that allow using NewCGI programs with protocols other than CGI, for example FastCGI [4]. /Björn [1] http://www.haskell.org/pipermail/libraries/2006-May/005391.html [2] http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/doc/ [3] http://www.cs.chalmers.se/~bringert/darcs/haskell-xhtml/doc/ [4] http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/doc/

3 4

Three questions about patch to cabal
by Jeremy Shaw 16 Aug '06

16 Aug '06

Hello, I ran into a problem while trying to debianize libraries that use cabal. I want to provide profiling libraries by default, but I want them to be provided in a seperate .deb, so that you do not have to install them if you don't need them. So for 'mylib' I would generate two .debs: libghc6-mylib-dev libghc6-mylib-prof Cabal already has an --enable-library-profiling flag, but this causes the profiling and non-profiling libraries to be compiled at the same time into the same directory tree. This means I have to use regular expression to try to move the profiling libraries into a seperate package. I think a better solution would be to provide a mechanism to disable building the vanilla libraries, such as: --enable-library-vanilla --disable-library-vanilla This could also be extended to support other flags in the future, like: --enable/disable-library-parallel --enable/disable-library-bytecode --enable/disable-library-native This scheme seems mostly fine. Package maintainers can do multiple passes building exactly what they want on each pass. People compiling from source can just enable everything they want and build in a single pass. So, I have three questions: (1) Flag sanity checking Not all combinations of flags are sensible. For example, we can already specify: --disable-library-profiling --enable-executable-profiling Which will probably fail unless the executable does not depend on the libraries. These new flags would introduce further nonsense, such as: --enable-library-for-ghci --disable-library-vanilla That will fail because --enable-library-for-ghci requires building the vanilla libraries. The current code processes the flags in isolation -- so detecting conflicts will be a moderate change to the existing code. But I think it is the right thing to do, anyone disagree? (2) Is there a better set of flags Perhaps my problem is that I am using the wrong abstraction for the flags. Is there a different set of flags that would solve my problem with out introducing incompatible combinations? (3) Another name for vanilla libraries I need a name to describe libraries that are built without any 'special' flags like -prof or -parallel. Currently I am using --enable/disable-library-vanilla, but I think there might be a better choice. Other ideas are 'default', 'plain', or 'standard'. Thanks! j.

4 8

Cabal vs base
by Neil Mitchell 10 Aug '06

10 Aug '06

Hi, I'm interested in using Cabal to build the base library, just like any other library. Does this have any chance of working? How much work would it take? At the moment the libraries build script has broken on Windows loads of times, and if Cabal was used it would be nicer, less code, and more cross platform. I'd also like to compile libraries for Hat, Yhc and Catch, and if I can reuse cabal to do this that would be great. If this work was done, would it be possible to reduce the installation script for the full haskell.org libraries to get library, cabal config, cabal build, cabal install? So just a general question about what needs doing, who is capable of doing it, and what I can do to get it working. Thanks Neil

4 3

darcs patch: Remove a variable shadowing warning (and 1 more)
by Ian Lynagh 01 Aug '06

01 Aug '06

Sun Jul 30 17:39:33 BST 2006 Ian Lynagh <igloo(a)earth.li> * Remove a variable shadowing warning Sun Jul 30 17:49:44 BST 2006 Ian Lynagh <igloo(a)earth.li> * Silence warnings.

4 3

darcs patch: Eliminate some warnings
by Ian Lynagh 30 Jul '06

30 Jul '06

Sat Jul 29 23:08:54 BST 2006 Ian Lynagh <igloo(a)earth.li> * Eliminate some warnings Eliminate warnings in the libraries caused by mixing pattern matching with numeric literal matching.

1 0

Re: patch applied (ghc): Generalise Package Support
by Simon Marlow 28 Jul '06

28 Jul '06

Malcolm Wallace wrote: > I would caution against changing the syntax of imports too hastily. As > I recall, the outcome of the mailing list discussion (and wiki) on this > issue was that the proposed syntax changes do not give any new > expressive power over packages, that we do not already have (via > OPTIONS_GHC etc). Given that the user can already say everything about > packages they need to, in the source code, I question whether > arbitrarily breaking source-compatibility with other implementations > (and Haskell'98) is wise. Well, firstly we don't currently support using -package options inside OPTIONS_GHC, but that's certainly one option. Leaving it there is certainly attractive, because there's not much to do, and as you say it keeps the language changes to a minimum. It's also very close to the .NET story. Package-qualified imports give you two qualitative benefits over per-module -package flags: - they let you disambiguate imports in a single module - they let you use packages without populating the global module namespace Some people wanted to move in the direction of using package-qualified imports for *everything*, that is moving away from a single global module namespace. Certainly having a per-package module namespace is useful: for example in the GHC package we don't want to have to rename all our modules to be hierarchical, but in the absence of package-qualified imports we will probalby be forced to do that to avoid probable clashes in the global module namespace. I see the package-qualified import story as quite attractive. It's quite lightweight, easy to understand and not too hard to implement, and the fact that it parallels the story at the module level means that it is intuitive. I wouldn't say I'm completely sold on it (but Simon PJ is, I think). I'm not sure what the Cabal story would be if package flags are allowed in OPTIONS_GHC, it seems a bit hairy. On the other hand, Cabal works quite naturally with package-qualified imports - we just need a way to say in build-depends that a package dependency should not populate the global module namespace. Cheers, Simon

2 1

hSeek on text files
by Bulat Ziganshin 28 Jul '06

28 Jul '06

Hello Simon, Simon, are you remember problem with using hTell+hSeek on handles open in text (not binary) mode on Windows? afair, you was finished with the decision to use NoBuffering for text files on Windows? but this solution is very inefficient. i now thought about dealing with the same problem in my lib and found that there is another solution - prohibit using of hTell/hSeek on files open in text mode (on Unix, too?). i think this is better - one should either open file in binary mode and use random access or open file in text mode and read/write it sequentially. what you think about it? also, i will be glad to hear comments from other haskellers -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 4

[RFC] Network.Socket: change get/setSocketOption
by Bertram Felgenhauer 27 Jul '06

27 Jul '06

Hi, (This mail is related to http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/3788 ) What I'm proposing is to make SocketOption a proper ADT and change get- and setSocketOption to functions that take type constructors instead of tags as arguments, i.e. getSocketOption :: Socket -> (a -> SocketOption) -> IO a setSocketOption :: Socket -> (a -> SocketOption) -> a -> IO () To make that work, the two functions are implemented in a type class. I'll attach a patch bundle (in darcs send -o format) of two patches: 1) implement the infrastructure for this change. it is mostly backward compatible: As long as code doesn't explicitely mention the SocketOption type, it should work without modifications. 2) give the options more sensible types. -- this breaks existing code. For example, setSocketOption sock ReuseAddr 1 becomes setSocketOption sock ReuseAddr True (the patch includes the necessary fixes for the network package) What's missing is a solution for the problem that prompted this change, namely setting struct time_val values. To do that, I'd need some Storable type that maps to struct time_val. I think Network.* is not the proper place to implement that. Where should it go? - Foreign.C.Types - not generally useful enough, I think. - System.Time - not portable enough? - System.Posix.* - seems to be the right place to me. related stuff: http://cryp.to/hsdns/System/Posix/GetTimeOfDay.hsc -- quite close to what I'd like to have; conversions to, say, System.Time.ClockTime would be useful though. http://www.haskell.org/~simonmar/time/NewTime.hsc -- looks like a new System.Time to me; the CTimeVal handling seems to be identical to System.Time though Comments, questions and suggestions are welcome. Bertram P.S. thanks to heatsink on #haskell for the suggestion of passing constructors to the functions. That simplified the code a lot at a small loss of safety, and made the interface more similar to the old one.

2 3