September 2008 - Libraries

HOC Packaging
by Jeff Wheeler 21 Sep '08

21 Sep '08

Hey, I've frequently been frustrated by HOC (Haskell Objective-C bindings), and I wonder if it is possible to cabalize it into the few packages (HOC, HOC-*) and put it on Hackage. It seems this is not done now so that the bindings can exactly match the interfaces on the system to which it is installed, which makes sense. However, it seems like on most all the systems (standard, up-to- date OS X machines), these interfaces are identical and do not need to be manually recreated by each individual on their own machine. Is it not possible to upload the packages for the latest OS X, and merely update it on *.0 releases? Jeff Wheeler

1 0

Arch Haskell News: Sep 20 2008
by Don Stewart 20 Sep '08

20 Sep '08

Highlights, * 576 packages now, up 13 from last week. Noteworthy, * hmpf:”Haskell binding to MPFR library” * protocol-buffers:”Parse Google Protocol Buffer specifications” * fckeditor:”Server-Side Integration for FCKeditor” * twidge:”Unix Command-Line Twitter and Identica Client” Full update list, http://archhaskell.wordpress.com/2008/09/20/arch-haskell-news-sep-20-2008/ -- Don

1 0

please check: are any of these warnings affecting your package? warnings during make (ghc head, windows)
by Claus Reinke 19 Sep '08

19 Sep '08

(copying to libraries, because many of these warnings come from extralibs) With the ghc release candidate coming up soon, it might be a good time to look at warnings? In a ghc head build on windows, there are many of them, even though ghc and the core libs have undergone a lot of cleaning. Even if I ignore ghc warnings like 'defined, but not used' 'binding shadowed', 'non-exhaustive match' (!), 'defaulting to', 'orphan instance', 'no type signature', etc., there are plenty of warnings left, some of which slightly worrying, suggesting include/documentation/cabal/deprecation trouble. Starting with only those matching '^Warning:', and listing only examples for each kind of warning, there are things like Warning: 'include-dirs: ../libraries/base/cbits' is a relative path outside of Warning: 'include-dirs: ../libraries/base/include' is a relative path outside Warning: 'include-dirs: stage2plus' directory does not exist. Warning: This package indirectly depends on multiple versions of the same Warning: HUnit.cabal: A package using section syntax should require Warning: defaultUserHooks in Setup script is deprecated. Warning: The documentation for the following packages are not installed. No (this is mostly rts, but also a couple of base-3) Warning: in export list of "GHC.Base": module not found: "GHC.Bool" Warning: in export list of "Data.Generics.Basics": module not found: "Data.Typeable" Warning: base:Control.Monad: could not find link destinations for: Data.Traversable.Id GHC.Arr.Array Data.Traversable.StateL Data.Traversable.StateR Text.ParserCombinators.ReadP.P (these are from a local build of ghc+extralibs on windows, yesterday, but there are also buildbot logs from a successful build: http://darcs.haskell.org/buildbot/head/builders/x86%20Windows%20head/builds… ) There are other warnings, too, eg: libtool: link: warning: undefined symbols not allowed in i386-unknown-mingw32 shared libraries ar cru .libs/libffi.a src/debug.o src/prep_cif.o src/types.o src/raw_api.o src/java_raw_api.o src/closures.o src/x86/ffi.o src/x86/win32.o libtool: install: warning: remember to run `libtool --finish /usr/local/lib' (on windows???) warning: implicit declaration of function `reallocf' warning: assignment makes pointer from integer without a cast Should I be worried?-) Claus

1 0

GHC version control
by Simon Peyton-Jones 16 Sep '08

16 Sep '08

Friends A few weeks back, we had a lively debate about what version control system to use for GHC. In the light of that discussion we promised a revised proposal. This is it. (We also promised a proposal about the build system: the final version is here: http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem) Constructive comments welcomed! Simon GHC Version Control proposal: Sept 2008 * We still want to move from Darcs to Git for GHC itself. The recent flurry of work on Darcs is very encouraging, but GHC is a particularly high-end client, and taking a direct dependency leads to stress at both ends. * We do not plan to change before the 6.10 release. Doing so would be destabilising at a time when we are trying to stabilise; and we need to devote all our active cycles to getting 6.10 out. Yes, that means it'll be more painful to move patches from the (Git) HEAD to the (Darcs) 6.10 branch, but we'll put up with that. We'll delay the change until the 6.10 branch seems to have settled down; i.e. roughly 6.10.2. * A very desirable goal is that it be possible to build GHC with only Git, rather than requiring every developer to actively use both Darcs and Git. But, many of the libraries are maintained by others (notably Cabal) who, for good reasons, do not want to move. In what follows the "Boot Libraries" are the ones required to build GHC. * So we propose the following: - The GHC repo will be in Git - Each Boot Library will (a) either be mastered in Git, with a read-only Darcs mirror (b) or be mastered in Darcs, with a read-only Git mirror (c) or be mastered in Darcs, with an occasional, manual process to copy a snapshot of the library from Darcs into GHC's Git repo. (Those Git files should be considered read-only.) - That means that if we want to modify a Darcs-mastered library we'll have to get the Darcs version, make the patch, test it, push it, and then the Git mirror will be right. Inconvenient, but we can live with that. We might even arrange it to be possible for super-developers to use the Darcs repo (rather than the mirror) direct from their tree. Ordinary developers can continue to be Git-only. - The same issue will arise for other people who want to modify a Git-mastered package. - Which is which will be decided on a case-by-case basis. The main criterion is: is GHC a passive client of the library, which is maintained by someone else (e.g. Cabal, containers), or is the library intimately coupled with GHC's inner workings (e.g. template-haskell)? If in doubt we should resolve ties in favour of darcs; we can always change our minds later, but changing and then changing back would be silly. * Our specific proposals for the master VCS for each boot library are: hsc2hs darcs haddock2 either: up to David Waern packages/array git packages/base git packages/base3-compat git packages/bytestring darcs packages/Cabal darcs packages/containers darcs packages/directory darcs packages/editline darcs packages/filepath darcs packages/ghc-prim git packages/haskell98 darcs packages/hpc either: up to Andy Gill packages/integer-gmp git packages/old-locale darcs packages/old-time darcs packages/packedstring darcs packages/pretty darcs packages/process git packages/random darcs packages/syb either: up to Utrecht packages/template-haskell git packages/unix git packages/Win32 git * Of these, probably the only contentious one is 'base', which is both very tightly coupled to GHC, but also used by nhc and Hugs. We humbly beg indulgence from Malcolm and Ross, and hope that the Darcs mirror be acceptable. They have kindly offered such indulgence! * array, process, unix, Win32 are also somewhat less obvious, but they are quite intimately connected to GHC

4 4

Time package broken with Windows and GHC Head
by Mitchell, Neil 15 Sep '08

15 Sep '08

Hi, Using GHC Head from Thursday, the Time package, as on Hackage, won't compile on Windows XP. There are some errors: In file included from cbits\HsTime.c:1:0: include\HsTime.h:16:0: error: syntax error before "int" cbits\HsTime.c: In function `get_current_timezone_seconds': cbits\HsTime.c:10:0: warning: implicit declaration of function `localtime' cbits\HsTime.c:10:0: warning: initialization makes pointer from integer without a cast cbits\HsTime.c:14:0: error: dereferencing pointer to incomplete type cbits\HsTime.c:24:0: error: `_tzname' undeclared (first use in this function) cbits\HsTime.c:24:0: error: (Each undeclared identifier is reported only once cbits\HsTime.c:24:0: error: for each function it appears in.) cbits\HsTime.c:25:0: error: `_timezone' undeclared (first use in this function) This is using a binary distribution, and using the darcs version of time. I don't know what these errors mean (or have time to investigate), and Ashley doesn't really have access to Windows at the moment. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

1 0

Unhelpful library documentation
by Gwern Branwen 13 Sep '08

13 Sep '08

I don't know if everyone has seen this, so I thought I'd mention this: <http://lukeplant.me.uk/blog.php?id=1107301692> > "Haskell API docs suck. A lot." "Haskell API documentation is very lacking for newbies. For instance, I want to understand how to create and use regexes. If you start at Text.Regex.Posix documentation, it tells you that =~ and =~~ are the high level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions are not actually documented at all!" "Since Haskell libraries are almost always implemented by Haskell gurus, and they implement them with themselves in mind (I have no objection to this, they are enthusiasts working for free), they use lots of clever code and advanced Haskell techniques. But this means that if you want people to actually use these libraries (and by consequence Haskell itself), the documentation for Haskell libraries has to be about an order of magnitude better than anything you'd find anywhere else. I suspect it is at least an order of magnitude worse than for something like .NET APIs, which means that relatively speaking the documentation of Haskell is currently in an absolutely dire state." These are all interesting points, but I found most interesting the conclusion: "Moving forward, I guess one problem is contributing to a library's documentation. There is nothing on the API doc pages that shows you how to do this. I suspect you need to check out the source with darcs (not something I do normally, I just use cabal) and then start email patches or something. Even then, I don't know if I would contribute any documentation -- 'howto' style documentation seems out of place on the API pages, but it is desperately needed." So, what can be done here? Offhand, I want to suggest adding a link to some sort of tutorial module or wiki page. Each page *does* mention that 'Maintainer libraries(a)haskell.org', but this really isn't helpful; it doesn't tell you where to get the original library source code, how to edit, what libraries@ *is* (anyone with a brain in their head is going to know that libraries@ is some sort of group interface, and is going to refrain from emailing it until they know that they aren't cluelessly spamming/offending potentially hundreds of Haskellers), and so on. Even better would be a link in the Description to the source: 'Control.Concurrent.QSemN is a module in the concurrent package; you can 'darcs get' it from http://foo.... For contributing, please module Contributing/wiki page haskell.org/wiki/Contributing_to_libraries', etc. Thoughts? -- gwern plutonium industrial UHF Reaction and data POCSAG Finksburg Merlin fake

4 5

Is Parsec's ParserError missing an Eq instance
by Manuel Holtgrewe 10 Sep '08

10 Sep '08

Hi I am trying to use HUnit to test my Parsec-based parsers. I have the following code: import Text.ParserCombinators.Parsec import Test.HUnit test1 = TestCase $ assertEqual "msg" (Right '1') (parse digit "error" "1") Running it gives the following error: HUnitParsec.hs:5:19: No instance for (Eq ParseError) arising from a use of `assertEqual' at HUnitParsec.hs:(5,19)- (8,32) Possible fix: add an instance declaration for (Eq ParseError) In the second argument of `($)', namely `assertEqual "msg" (Right '1') (parse digit "error" "1")' In the expression: TestCase $ assertEqual "msg" (Right '1') (parse digit "error" "1") In the definition of `test1': test1 = TestCase $ assertEqual "msg" (Right '1') (parse digit "error" "1") Is the missing Eq instance intentional? What is the recommended way to use HUnit to test Parsec parsers? Bests, Manuel

2 1

old-locale
by Ashley Yakeley 08 Sep '08

08 Sep '08

The time package uses old-locale. "Old" sounds like it should be replaced. What's old-locale been replaced by? -- Ashley Yakeley

1 0

#2532: Add Typeable instance to Data.Unique
by Jim Apple 07 Sep '08

07 Sep '08

http://hackage.haskell.org/trac/ghc/ticket/2532 Discussion deadline: Sept 7 Jim

3 5

Hackage/Cabal Broken?
by Ashley Yakeley 06 Sep '08

06 Sep '08

$ cabal --version cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library $ cabal update Downloading package list from server 'http://hackage.haskell.org/packages/archive' cabal: user error (Codec.Compression.Zlib: invalid stored block lengths) -- Ashley Yakeley

2 2