September 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

darcs patch: Implementation of aton and ntoa outside ... (and 1 more)
by Robert Marlow 16 Nov '06

16 Nov '06

Mon Sep 25 16:55:55 JST 2006 Robert Marlow <bobstopper(a)bobturf.org> * Implementation of aton and ntoa outside the IO monad This is a second attempt at the earlier patch inet_ntoa and inet_aton can be implemented purely to avoid the need for the IO monad. Additionally, inet_addr is currently incorrect due to using the inet_addr C function which is considered obsolete due to incorrectly failing while converting 255.255.255.255 as an address. Mon Sep 25 17:12:52 JST 2006 Robert Marlow <bobstopper(a)bobturf.org> * Fixed bugs in names of aton and ntoa

5 7

darcs patch: Improve Control.Monad.filterM:
by Spencer Janssen 24 Oct '06

24 Oct '06

Fri Aug 4 13:49:57 CDT 2006 Spencer Janssen <sjanssen(a)cse.unl.edu> * Improve Control.Monad.filterM: * filterM is defined in terms of foldr, making it a good consumer in GHC's fusion framework * filterM uses linear stack space with respect to the number of items that the predicate returns true, rather than the total number of elements in the input.

6 11

Building extra-libs using Cabal
by Simon Peyton-Jones 04 Oct '06

04 Oct '06

The Haskell libraries are gradually moving towards being buildable using Cabal, rather than by GHC's make system. This is good. But here are two bug reports telling what doesn't work: http://hackage.haskell.org/trac/ghc/ticket/893 http://hackage.haskell.org/trac/ghc/ticket/894 (missing Setup.hs, and/or Haddock parsing errors). Ross has fixed some of these (thanks!). This message is to invite package maintainers to work on fix the remaining glitches. (We won't undertake to fix this for GHC 6.6, because these packages can be upgraded separately.) The relevant packages are: Haddock errors: http://hackage.haskell.org/trac/ghc/ticket/894 network xhtml opengl openal alut Missing Setup http://hackage.haskell.org/trac/ghc/ticket/893 arrows fgl haskell-src html hunit mtl quickcheck time Thanks! Simon

3 5

bug report: Cabal hides library
by Bulat Ziganshin 29 Sep '06

29 Sep '06

Hello libr, i think it's appropriate place to complain about Cabal? situation: ghc 6.4.2 (2006.06.09) with built-in Cabal. i install package with the following dependencies: Build-Depends: base, ArrayRef==0.1, fps>=0.7, template-haskell there are ArrayRef 0.1 (hidden) and ArrayRef 0.1.1 (exposed) installed Cabal correctly selects ArrayRef 0.1 when building the lib. but on installation it makes the following trick: Registering Streams-0.2.2... Reading package info from ".installed-pkg-config" ... done. Warning: hiding the following packages to avoid conflict: ArrayRef-0.1.1 Streams-0.1.6 hiding old version of Stream library is correct, but why the hell it hides old ArrayRef library??? as the final result, both old and new ArrayRef libraries are hidden: >ghc-pkg list C:/Base/Compiler/ghc-6.4\package.conf: (ArrayRef-0.1), (ArrayRef-0.1.1), Cabal-1.1.4, GLUT-2.0, HGL-3.1, HUnit-1.1, OpenGL-2.0, QuickCheck-1.0, (Streams-0.1.6), Streams-0.2.2, Win32-1.0, base-1.0, (concurrent-1.0), (data-1.0), fgl-5.2, fps-0.7, haskell-src-1.0, haskell98-1.0, (hssource-1.0), (lang-1.0), mtl-1.0, (net-1.0), network-1.0, objectio-1.0, parsec-1.0, readline-1.0, rts-1.0, stm-1.0, template-haskell-1.0, (text-1.0), (util-1.0), (win32-1.0) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

sof patch for --ghc-pkg-config-file=
by Isaac Jones 29 Sep '06

29 Sep '06

Emailing to libraries@, please followup to cabal-devel. Here's a patch from Sigbjorn which adds --ghc-pkg-config-file= to cabal. This is an oldish patch, but I haven't stopped getting requests for this feature :) This allows you to create a "local" package config file, rather than using the --user or --global files, this is useful for in-place building, as when you're developing a set of related packages. I still have some debate about whether this patch should go in; it assumes a model of package registration where you have a config file (as opposed to a directory) which isn't the case for nhc or Hugs. But the idea doesn't seem to bother anyone but me, and the flag is clearly marked as a ghc-related flag, so I'm thinking of letting it through. Opinions? Does anyone want to massage this to work w/ the current cabal head? peace, isaac ------------------------------------------------------------ Changed paths: M /Distribution/Make.hs M /Distribution/Setup.hs M /Distribution/Simple/Build.hs M /Distribution/Simple/Configure.hs M /Distribution/Simple/GHCPackageConfig.hs M /Distribution/Simple/Install.hs M /Distribution/Simple/LocalBuildInfo.hs M /Distribution/Simple/Register.hs M /Distribution/Simple.hs M /tests/ModuleTest.hs A couple of extensions: - support for specifying what GHC package configuration file to use during (un)registration. Specified via the command-line option --ghc-pkg-config-file=<path> which is understood by 'configure', 'install', 'register', and 'unregister' commands. - better handling of package-specific header files during installation. If you use the Include-Dirs: and Includes: fields in your .cabal file to refer to package-local header files and directories, these will be created&copied during 'install'. i.e., suppose you spec the following: Include-Dirs: /usr/local/include/openssl, include Includes: include/openssl-exts.h, +openssl/openssl.h The 'install' action will emit the following ghc-pkg fields when updating/installing the GHC package: include_dirs = [ "/usr/local/include/openssl", "/path/to/your/pkg/installation/lib/directory/include"] c_includes = [ "openssl-exts.h", "openssl/openssl.h"] and creates the directory in include_dirs's second element, followed by copying openssl-exts.h into that directory. Note: - only directories that don't start with '/' are created inside the package's install directory. - Includes: entries that are prefixed with '+' are assumed to be referring to non-package header files and aren't (attempted) copied into the package's installation tree. Bit of a twiddly hack, but supporting the distinction between package and non-package header files does seem to be necessary.

3 3

darcs patch: Implementation of aton and ntoa outside the IO monad
by Robert Marlow 26 Sep '06

26 Sep '06

Sun Sep 24 10:06:48 JST 2006 Robert Marlow <bobstopper(a)bobturf.org> * Implementation of aton and ntoa outside the IO monad inet_ntoa and inet_aton can be implemented purely to avoid the need for the IO monad. Additionally, inet_addr is currently incorrect due to using the inet_addr C function which is considered obsolete due to incorrectly failing while converting 255.255.255.255 as an address.

5 9

darcs patch: Implementation of aton and ntoa outside the IO monad
by Robert Marlow 25 Sep '06

25 Sep '06

Mon Sep 25 16:55:55 JST 2006 Robert Marlow <bobstopper(a)bobturf.org> * Implementation of aton and ntoa outside the IO monad This is a second attempt at the earlier patch inet_ntoa and inet_aton can be implemented purely to avoid the need for the IO monad. Additionally, inet_addr is currently incorrect due to using the inet_addr C function which is considered obsolete due to incorrectly failing while converting 255.255.255.255 as an address.

1 0

Missing file in the installation of the 'time' package
by Alain Cremieux 23 Sep '06

23 Sep '06

Hello, The file 'HsTime.h' is not installed with the 'time' package. This produces a compile error with ghc in '-O' mode. I have to make a manual link to the file in the source package to correct it (it is in ghc/libraries/time/include). The file is not needed in not optimized mode. Alain

1 0