- Libraries - Haskell.org

lambdabot setup
by Valery V. Vorotyntsev 06 Feb '08

06 Feb '08

Dear, lazy programmers, Please let me know the proper place to report lambdabot bugs, and feel free to ignore the rest of message. Are you still reading? In this case you may want to know that *** I've successfully installed lambdabot with GHC 6.9! :) *** Kudos to Cale & the IRC crowd for making my day [http://tunes.org/~nef/logs/haskell/08.02.04] Boring part: $ darcs get http://code.haskell.org/lambdabot $ cd lambdabot $ runhaskell Setup configure --prefix=$HOME --user $ runhaskell Setup build $ touch LICENSE # see the patch attached $ runhaskell Setup install Interesting part: $ lambdabot -e 'hoogle map' Initialising plugins ...........Plugin.Djinn: couldn't find djinn binary ...........................sending message to bogus server: IrcMessage {msgServer = "freenode", msgLBName = "urk!<outputmessage>", msgPrefix = "", msgCommand = "NAMES", msgParams = [""]} .................. done. A Hoogle error occured. Exception: all servers detached exception: State/seen: openBinaryFile: does not exist (No such file or directory) $ hoogle map Could not find hoogle database, looked for: hoogle.txt In order to make `hoogle' binary usable, one should copy `hoogle.txt' file to "$(dirname $(which hoogle))/" directory: $ cp State/hoogle.txt ~/bin/ # FIXME $ hoogle map [...success...] To my believe, it's a package's responsibility to copy data files to proper locations (during `runhaskell Setup install' step). And hoogle _plugin_ still doesn't work though. $ lambdabot Initialising plugins ...........Plugin.Djinn: couldn't find djinn binary ...........................sending message to bogus server: IrcMessage {msgServer = "freenode", msgLBName = "urk!<outputmessage>", msgPrefix = "", msgCommand = "NAMES", msgParams = [""]} .................. done. lambdabot> hoogle map A Hoogle error occured. lambdabot> lambdabot: user error (<eof>) Exception: all servers detached Thank you. -- vvv PS: Tue Feb 5 18:38:55 EET 2008 "Valery V. Vorotyntsev" <valery.vv(a)gmail.com> * `LICENSE' file added Tue Feb 5 18:37:12 EET 2008 "Valery V. Vorotyntsev" <valery.vv(a)gmail.com> * lambdabot.cabal: add `build-type' to make Cabal happy

2 3

Proposal: Add concatMapM function (#2042)
by Twan van Laarhoven 06 Feb '08

06 Feb '08

Hello library people, I have noticed that many projects include a 'concatMapM' function: concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] I think this is useful in general, so let's add it to Control.Monad. Trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2042 Deadline for discussion: 2 weeks from now, January 28 Twan

25 94

fgl-bug
by Christian Maeder 05 Feb '08

05 Feb '08

Hallo Martin, I was going to use xdfWith from Data.Graph.Inductive.Query.DFS with Data.Graph.Inductive.Graph.out' as second argument, but 1. xdfWith is not exported 2. out' seems to be wrong (by looking at the source code) -- | All outward-directed 'LEdge's in a 'Context'. out' :: Context a b -> [LEdge b] out' c@(_,v,_,_) = map (\(l,w)->(w,v,l)) (context4l' c) ^^^ I think, the outgoing edge must be made as "(v,w,l)"! inn' looks correct: -- | All inward-directed 'LEdge's in a 'Context'. inn' :: Context a b -> [LEdge b] inn' c@(_,v,_,_) = map (\(l,w)->(w,v,l)) (context1l' c) Can 1. and 2. be fixed? I need the general xdfWith because I want to filter out some successors (or maybe I can filter to whole graph first). Cheers Christian

1 0

Fixing MonadIO
by Yitzchak Gale 05 Feb '08

05 Feb '08

Simon Marlow wrote: > Avoiding > exceptions because MonadIO has trouble with them is not a good enough > reason, IMO. We should fix MonadIO instead. I'm all for it! Below is a summary of the three approaches that have been proposed, as far as I can remember: 1. Make the functions in Control.Exception more polymorphic. This is part of the more general program of providing polymorphic IO described in Haskell' ticket 110. Brian Hulley attached to that ticket a version of Control.Exception that does this by introducing the MonadException subclass of MonadIO. http://hackage.haskell.org/trac/haskell-prime/attachment/ticket/110/Excepti… 2. In another branch from this thread, I suggested adding only the following three low-level exception handling functions to Control.Exception: startDelayingExceptions stopDelayingExceptions getDelayedException This would allow exception handling to be extended arbitrarily in other libraries, with only a small addition to Control.Exception. Simon Marlow pointed out that this mechanism would lose certain optimizations that exist, e.g., for preserving tail-recursion in block. That would be a cost of this generality. (Obviously we would retain the current mechanism for IO itself.) http://www.haskell.org/pipermail/libraries/2008-February/009159.html 3. Earlier in this thread, Judah Jacobson proposed adding additional liftIO functions to MonadIO, or a subclass, that match the kinds of the exception handling functions of Control.Exception. The kinds that would be needed are: For block and unblock: * -> * For catch: * -> (* -> *) -> * For setUncaughtExceptionHandler: (* -> *) -> * The liftIO for catch is the most general, so it could be reused for the others, but that would look a little ad hoc. This approach has the advantage that it does not require any change at all to Control.Exception, but it puts more of a burden on monad authors. http://www.haskell.org/pipermail/libraries/2008-January/009034.html Any other approaches? Any opinions about which of these would be best? Thanks, Yitz

3 3

darcs patch: Figure out timezone offset from timezone name
by David Leuschner 05 Feb '08

05 Feb '08

Sat Feb 2 12:33:17 CET 2008 David Leuschner <david(a)loisch.de> * Figure out timezone offset from timezone name

7 12

MonadIO and IO exceptions
by Yitzchak Gale 02 Feb '08

02 Feb '08

Judah Jacobson wrote: > I've already demonstrated how a library writer can solve that problem in: > http://www.haskell.org/pipermail/libraries/2008-January/009034.html Yes, that is indeed very nice. But I don't think it is a practical solution right now, for the following reasons: It requires that users be in a special monad; it doesn't work for regular MonadIO. So it isn't really a practical solution until it gets into MTL and people start porting their code. Providing an instance for MonadIO1 (or whatever we would call it) is an extra step for monad writers that may often be skipped. Also, there are obviously many other more complex cases beyond a simple bracket. How general is this technique? As you point out, even for bracket it does not work unless the "after" action is IO. What other restrictions are there in the general case? Perhaps we could fix those problems by also providing liftIOk for all kinds k that occur in the signatures of various functions in Control.Exception. But that would make the new monad even more unwieldy. As I suggested before, I think the best solution would be to define the functions of Control.Exception in terms of lower-level primitives that could then be used to define the functions directly for other monads. Perhaps something like this would be general enough to cover everything: -- Delay any exception and put in buffer startDelayingExceptions :: IO () -- Stop delaying exceptions stopDelayingExceptions :: IO () -- Retrieve delayed exception and clear buffer getDelayedException :: IO (Maybe Exception) There would be one exception buffer per thread. New exceptions would replace old ones, so users of this mechanism would be required to catch as catch can. Based on Simon Marlow's observation in our previous discussion on this topic, we would still want to leave around the current primitives as a special case optimization for IO. Regards, Yitz

1 0

Fwd: Readline read_history and write_history addition
by Alexander Dunlap 02 Feb '08

02 Feb '08

On Feb 2, 2008 1:14 PM, Yitzchak Gale <gale(a)sefer.org> wrote: > Alexander Dunlap wrote: > >>> For instances where an exception would be too intrusive, I don't see > >>> how it would be too hard to write a wrapper function > > I wrote: > >> In a library that does not have direct access to the IO > >> monad, it would be not just hard - it would be impossible. > >> That is because of type restrictions in the current versions > >> of catch, block, and friends. > > Judah Jacobson wrote: > > You haven't said why something like the following would not be sufficient: > > > > readHistoryM :: MonadIO m => String -> m Bool > > readHistoryM file = liftIO $ do > > result <- try (readHistory file) > > return (result == Right ()) > > Because a library - other than readline itself - can't > force its users to do that. > > OK. Here's a simplified real-world example. Say you want to > write a simple library that interfaces the text-to-speech facilities > available on multiple platforms. To play nicely with programs > written in a monadic style, the interface might be something like: > > class MonadIO m => Speech m where > sayText :: String -> m () > runSpeech :: m a -> IO a > > instance Speech SomeSpeechSystem where > sayText t = ... > runSpeech x = do > liftIO startSomeSpeechSystem > ret <- x > liftIO stopSomeSpeechSystem > return ret > > Unfortunately, bracket is not available. So if x throws an > uncaught IO exception, you may leave around zombies, > database corruption, missiles armed for launch, etc. > > Well, if your speech system doesn't arm any missiles, > you may consider it a reasonable risk to use this > library in programs that could throw an IO exception > on some rare error condition. > > But the proposal here is to raise the exception in a > common situation that will definitely occur in regular > usage. That may be fine in Java or Python, but it > is a bad idea for IO exceptions in Haskell. > > Alexander Dunlap wrote: > > So why couldn't you have a Utils.hs file that imports System.IO and > > provides the wrapper around readHistory? Then you can use the > > tryReadHistory function in your MonadIO-exporting module _exactly_ the > > same way as the original readHistory function. > > You can. But if you are writing a library, your users > might not. > > Regards, > Yitz > I don't understand. Why don't you compile the functions we are suggesting _into the library_? Alex

2 1

Proposal: Add variants of tails & inits not returning empty lists
by Maxime Henrion 31 Jan '08

31 Jan '08

Hi all, I just opened a Trac ticket (#1979), to suggest the addition of the inits1 and tails1 functions, which don't return empty lists unlike their counterpart. They're defined as such : inits1 = tail . inits tails1 = init . tails I've needed them a few times so I thought they would make a nice addition to the base package. And, I've got to say, the symmetry in this code is is nice :-). http://hackage.haskell.org/trac/ghc/ticket/1979 Cheers, Maxime

7 10

Security Notice: Buffer overflow fixed in PCRE library
by ChrisK 30 Jan '08

30 Jan '08

The PCRE library has just fixed a buffer overflow (related to UTF-8 mode). There are several haskell wrappers for the pcre library. If you use a wrapper for the PCRE library (libpcre) then you may want to upgrade the underlying library. http://pcre.org/news.txt states: > News about PCRE releases > ------------------------ > > Release 7.6 28-Jan-08 > --------------------- > > The main reason for having this release so soon after 7.5 is because it fixes a > potential buffer overflow problem in pcre_compile() when run in UTF-8 mode. In > addition, the CMake configuration files have been brought up to date. Cheers, Chris

1 0

Integrating editline with ghc
by Judah Jacobson 29 Jan '08

29 Jan '08

Hi all, I have managed to build ghc using the initial release of the editline package: Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ As I've mentioned before, there are two independent modules: - System.Console.Editline is a very basic (and experimental) interface to the native editline APIs. - System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline). Currently I'm using just the latter as a drop-in replacement for System.Console.Readline in ghci. I have added a --with-editline flag to ghc's configure script, which has no effect if it's not specified, and otherwise does the following: - Throw an error (at configure time) if editline isn't present (as $hardtop/libraries/editline) - Use the editline package instead of readline when building ghc stage 2 - Use CPP to make InteractiveUI.hs (the main ghci loop) import System.Console.Editline.Readline instead of System.Console.Readline. Does that sound like the right way to handle this? If so, I'll send a darcs patch. Also, should editline be made a boot-package or an extra-package (or neither)? Thanks, -Judah

12 48