- Libraries - Haskell.org

(lib network) Should inet_aton be called instead of inet_addr ?
by Marc Weber 24 Sep '08

24 Sep '08

Hi @ll Reading http://linux.die.net/man/3/inet_addr I noticed that inet_addr is obsolete and inet_aton should be used because inet_addr indicates error by returning -1 which is a valid address (255.255.255.0) as well. Don't know wether it's worth changing or wether inet_aton is peresent on all systems Marc Weber

4 5

ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready
by ChrisK 23 Sep '08

23 Sep '08

Hello one and all, Amid much rejoicing, my Haskell version of protocol-buffer is now released (version 0.2.9). What is this for? What does it do? Why? Shorter answer: It generates Haskell data types that can be converted back and forth to lazy ByteStrings that interoperate with Google's generated code in C++/Java/python. It is a pure Haskell re-implementation of the Google code at http://code.Google.com/apis/protocolbuffers/docs/overview.html which is "...a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more." Google's project produces C++, Java, and Python code. This one produces Haskell code. The release tarball (with 3 Haskell packages inside, see README in source) is at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers The darcs repository has moved to http://darcs.haskell.org/packages/protocol-buffers2/ You will also need a recent ghc compiler, the "binary" package and the "utf8-string" package from hackage.haskell.org (same site as mentioned above). The source compiles to 3 things: 1) the package "protocol-buffers" with the library API 2) the package "protocol-buffers-descriptor" with the descriptor.proto code 3) The 'hprotoc' executable which is a command line program similar to 'protoc'. The "examples" sub-directory in the code has the Haskell version of the "addressbook.proto" example and is compatible with Google's similar example code. The code generated from unittest.proto (and unittest_import.proto) includes messages TestAllTypes and TestAllExtensions which have been extensively tested by QuickCheck to ensure they can be wire encoded and decoded (see the "tests" sub-directory in the code). The user API, as exported by Text.ProtocolBuffers, allows for converting messages back and forth to the lazy ByteString type. And such messages can be merged, and the defaults accessed via the MessageAPI type class. The messages in Haskell as just regular data types and are thus immutable. Required types are simple record fields, optional types are Maybe, and repeated types are Seq (from Data.Sequence). Extensions are supported via Key data that allows access to the extension fields. Extensible messages contain an opaque ext'field entry of type ExtField that contains the map data structure to contain the extension field values. The User API allows for serializing messages as the usual series of fields. It also provides for a length prefix to be written to create delimited messages. It also provides to write a wire tag with any field number before the length and message data. This last form looks like a field on the wire, and there is a special api call to read back just the one message and its field number. This last API is similar to the one that is part of the C# API. No benchmarks have been run yet. Any suggestions? Unsupported for the moment is loading and storing "unknown" fields. It can be added sooner if someone has a use for this. Unsupported indefinitely is code generation for Services and Methods. I have yet to look into how this is presented in the other languages. The API to read a single message field, as mentioned above, might be extended to read any type instead of just messages. optional clever_quote { <autrijus> Perl: "Easy things are easy, hard things are possible" <autrijus> Haskell: "Hard things are easy, the impossible just happened" } Cheers! Chris Kuklewicz

7 8

Following up on a patch for the network package (trac #2005)
by Judah Jacobson 22 Sep '08

22 Sep '08

Hi all, A few weeks ago I proposed a (1-line) patch to the network package to fix trac bug #2005 (getnameinfo error on OS X): http://www.haskell.org/pipermail/libraries/2008-July/010239.html And then I forgot about it until today; looks like it's been sitting in limbo since I sent it. Any chance of this making it into 6.10.1? Thanks, -Judah

2 1

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 11 Sep '08

11 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