- Haskell-Cafe - Haskell.org

Haskell wiki admins -- who are they?
by Jason Dusek 04 Feb '11

04 Feb '11

I am having some trouble getting in to my account on the Haskell wiki. I requested a password ~24 hours ago reset but have not received the email yet. Who should I contact about this? -- Jason Dusek Linux User #510144 | http://counter.li.org/

1 0

ANN: HackageOneFive: Reverse dependency lookup for all packages on Hackage
by Simon Hengel 04 Feb '11

04 Feb '11

Hello, I wrote a tiny Snap app that provides reverse dependency lookup for all packages on Hackage. A git repository is at: https://github.com/sol/HackageOneFive Setup instructions are provide in the README[1] file. It uses a PostgreSQL database for storage but it should be trivial to port this to e.g. SQLite. As always feedback and patches are gladly welcome! btw: Is there still progress on Hackage 2.0? Cheers, Simon [1] https://github.com/sol/HackageOneFive#readme

2 2

Re: [Haskell-cafe] OSX i386/x86 and x86_64 - time to switch supported platforms?
by John Lato 04 Feb '11

04 Feb '11

> > From: Max Bolingbroke <batterseapower(a)hotmail.com> > > On 4 February 2011 02:35, Steve Severance <steve(a)medwizard.net> wrote: > > Wholly support moving OSX to x64. x86 should be supported only on a > > best effort basis for legacy. > > Moving from x86 to x64 has advantages and disadvantages from my POV. > Advantages: > * Able to address more memory > * More registers for code generation > * Haskell dependencies wouldn't need to be built for x86 on Snow > Leopard (though if we swapped to x64 on Leopard as well, the Leopard > users would start having to build 64-bit libraries specially) > > Disadvantages: > * Pointers become wider, and Haskell data structures mostly consist > of pointers. This will bloat memory use of Haskell programs. > * Generated binaries won't work on older Macs that don't have a > 64-bit OS/CPU. This is important if you are distributing compiled > Haskell binaries, which is not something I personally do but which is > probably important to support > > Did I miss anything? > I'm moderately in favor of making the primary supported platform x86_64, except for the distribution issue. If i386 were maintained but not necessarily targeted for improvement that would be fine by me. > I don't know if anyone using a 64-bits GHC on e.g. Linux has reported > experience of whether moving to 64-bits is a net win or not from a > performance perspective. My guess is that it is a win for certain > classes of programs (numerically intensive, "high performance > Haskell"), and a loss for programs making extensive use of laziness, > boxed data structures etc. > For my code, x86_64 (OS X) is a net win. It's sometimes significantly faster, and hasn't ever been noticeably slower. The biggest gains seems to be I/O, although I haven't really investigated this. Cheers, John

2 1

Problems with iteratees
by wren ng thornton 04 Feb '11

04 Feb '11

I'm working on a project that's using John Lato's old implementation of iteratees (iteratee >= 0.3.5 && < 0.4; I'm hoping to migrate to 0.7 soon, but that's a ways off yet) and I'm running into some issues I haven't been able to untangle. Maybe a new set of eyes can help... The overarching program brings three things together for doing some interprocess communication: the medium is Posix FIFOs, the messages themselves are encoded with Google's Protocol Buffers[1], and the control flow for getting and processing the messages is handled by iteratees. The error message indicates iteratees are at fault, though it could be an error elsewhere instead. First, some boilerplate. -- For messageWithLengthEnumeratee only {-# LANGUAGE ScopedTypeVariables #-} import qualified Text.ProtocolBuffers.Reflections as R import qualified Text.ProtocolBuffers.WireMessage as W import qualified Text.ProtocolBuffers.Get as G import qualified Data.ByteString as S import qualified Data.ByteString.Lazy as L import qualified Data.Iteratee as I import Data.Iteratee.WrappedByteString import Data.Word (Word8) import Control.Monad (liftM) -- | Return a final value, and the remainder of the stream. idone :: a -> c el -> I.IterGV c el m a idone a xs = I.Done a (I.Chunk xs) {-# INLINE idone #-} -- | Convert a continuation into 'I.IterGV'. icontinue :: (I.StreamG c el -> m (I.IterGV c el m a)) -> I.IterGV c el m a icontinue k = I.Cont (I.IterateeG k) Nothing {-# INLINE icontinue #-} -- | Throw an error message. ifail :: (Monad m) => String -> I.IterGV c el m a ifail msg = ierror (I.Err msg) {-# INLINE ifail #-} -- | An 'I.IterGV' variant of 'I.throwErr'. ierror :: (Monad m) => I.ErrMsg -> I.IterGV c el m a ierror err = I.Cont (I.throwErr err) (Just err) {-# INLINE ierror #-} toLazyBS :: S.ByteString -> L.ByteString toLazyBS = L.fromChunks . (:[]) {-# INLINE toLazyBS #-} toStrictBS :: L.ByteString -> S.ByteString toStrictBS = S.concat . L.toChunks {-# INLINE toStrictBS #-} Now we have the code for converting the Get monad used by protocol buffers into an iteratee. This should be correct, and it's pretty straightforward. -- | Convert a 'G.Result' iteratee state into a 'I.IterGV' -- iteratee state. result2iterv :: (Monad m) => G.Result a -> I.IterGV WrappedByteString Word8 m a result2iterv (G.Finished rest _ a) = idone a (WrapBS $ toStrictBS rest) result2iterv (G.Failed _ msg) = ifail msg result2iterv (G.Partial k) = I.Cont (iterify k) Nothing -- | Convert a protobuf-style continuation into an -- iteratee-style continuation. iterify :: (Monad m) => (Maybe L.ByteString -> G.Result a) -> I.IterateeG WrappedByteString Word8 m a iterify k = I.IterateeG $ \s -> return $! case s of I.Chunk (WrapBS xs) -> result2iterv $ k (Just $ toLazyBS xs) I.EOF Nothing -> result2iterv $ k Nothing I.EOF (Just err) -> ierror err -- | A variant of 'G.runGet' as an iteratee. runGetIteratee :: (Monad m, R.ReflectDescriptor a, W.Wire a) => G.Get a -> I.IterateeG WrappedByteString Word8 m a runGetIteratee g = I.IterateeG $ \s -> return $! case s of I.Chunk (WrapBS xs) -> result2iterv $ G.runGet g (toLazyBS xs) I.EOF Nothing -> result2iterv $ G.runGet g L.empty I.EOF (Just err) -> ierror err Okay, now we have an iteratee which consumes a stream of bytestrings and will render a protocol buffer message. But what we really want is an enumeratee to do this repeatedly so we can use an iteratee to consume the stream of messages. I have the following definition which typechecks, but doesn't seem to work. The call to convStream seems like it always hangs: -- | A variant of 'G.runGet' as an enumeratee. runGetEnumeratee :: (Monad m, R.ReflectDescriptor a, W.Wire a) => G.Get a -> I.EnumeratorN WrappedByteString Word8 [] a m b runGetEnumeratee = I.convStream . liftM (Just . (:[])) . runGetIteratee Once we have a working definition of runGetEnumeratee, then we can define the specific enumeratee we need: -- | An enumeratee for converting bytestrings into protocol -- buffer messages. messageWithLengthEnumeratee :: forall m msg a . (Monad m, R.ReflectDescriptor msg, W.Wire msg) => I.EnumeratorN WrappedByteString Word8 [] msg m a messageWithLengthEnumeratee = runGetEnumeratee (W.messageWithLengthGetM :: G.Get msg) And then at the use site we have the following: let processRequest = ... :: msg -> IO () I.run -- run the [()], sending EOF . I.joinIM -- push monadic effects inside . I.enumFdFollow fifo_in -- read from the Fd forever . I.joinI -- when EOF bytestrings, EOF msgs . messageWithLengthEnumeratee -- ByteStrings -> messages $ I.mapM_ processRequest -- process messages I think this part is correct too, but just to be sure... the goal is that we should read bytestrings from the FIFO forever (or until the other process closes their end), and then we read off the messages one by one, handing them off to processRequest to interpret them and respond accordingly. When I put this all together, the process is killed with: control message: Just (Err "endOfInput") Data.Iteratee.Base.run is the origin of the "control message:" part of the error, but I don't know where (Err "endOfInput") is coming from since Data.Iteratee.Base only uses (Err "EOF") or (Err "Divergent Iteratee"). I believe runGetEnumeratee is where the problem is, though it could also be the use site or something in one of the libraries. Any help would be appreciated. [1] http://hackage.haskell.org/package/protocol-buffers http://hackage.haskell.org/package/hprotoc -- Live well, ~wren

3 6

How to #include into .lhs files?
by Conal Elliott 04 Feb '11

04 Feb '11

Does anyone have a working example of #include'ing Haskell code into a bird-tracks-style .lhs file with GHC? Every way I try leads to parsing errors. Is there documentation about how it's supposed to work? Help much appreciated. - Conal

4 4

OSX i386/x86 and x86_64 - time to switch supported platforms?
by Max Cantor 04 Feb '11

04 Feb '11

I originally posted this on haskell-GHC-users, but was curious how the wider community felt. The last 32-bit, Intel Mac was the Mac Mini, discontinued in August 2007. The bulk of them were discontinued in 2006, along with PowerPC Macs. Does it make sense to relegate OSX x86_64 to community status while the 32-bit version is considered a supported platform? Given that I'm far from experienced enough to be able to contribute meaningfully to GHC, I'm not complaining about anyone's efforts, just that those efforts might be a bit misallocated. I'd venture a guess that far more people are interested in running 64-bit GHC on OSX than in running GHC on what is now fairly antiquated hardware. mc

6 9

Instancing "Typeable" for monad transformers?
by John Millikin 04 Feb '11

04 Feb '11

Is there any reasonable way to do this if I want to cast a monadic value? For example: > castState :: (Typeable a, Typeable s, Typeable1 m, Typeable b) => a -> Maybe (StateT s m b) > castState = Data.Typeable.cast None of the common monad transformers declare instances of Typeable, so I don't know if the concept itself even works. The use case here is one of my library users wants to return an Iteratee from code running in "hint", which requires any extracted values be typeable. My first attempt at an extension-free instance is something like this: > import Data.Enumerator > import Data.Typeable > > instance (Typeable a, Typeable1 m) => Typeable1 (Iteratee a m) where > typeOf1 i = rep where > typed :: (a -> b) -> b -> a -> a > typed _ _ a = a > > ia :: a -> Iteratee a m b > ia = undefined > > im :: m c -> Iteratee a m b > im = undefined > > rep = mkTyConApp (mkTyCon "Data.Enumerator.Iteratee") [tyA, tyM] > tyA = typeOf (typed ia i undefined) > tyM = typeOf1 (typed im i undefined) which, besides being ugly, I have no idea if it's correct.

4 3

Problem cabal installing wxcore with ghc 7.0.1 on linux x86_64
by Alexander McPhail 04 Feb '11

04 Feb '11

zen:~# cabal install wxcore --enable-documentation --global Resolving dependencies... [1 of 1] Compiling Main ( /tmp/wxcore-0.12.1.617977/wxcore-0.12.1.6/Setup.hs, /tmp/wxcore-0.12.1.617977/wxcore-0.12.1.6/dist/setup/Main.o ) Linking /tmp/wxcore-0.12.1.617977/wxcore-0.12.1.6/dist/setup/setup ... generating: src/haskell/Graphics/UI/WXCore/WxcClassTypes.hs reading class definitions: parsing: src/include/wxc.h parsing: src/include/wxc_types.h parsing: src/include/wxc_glue.h parsing: src/include/db.h parsing: src/include/dragimage.h parsing: src/include/graphicscontext.h parsing: src/include/sound.h parsing: src/include/managed.h parsing: src/include/mediactrl.h parsing: src/include/previewframe.h parsing: src/include/printout.h parsing: src/include/textstream.h parsing: src/include/stc.h parsing: src/include/stc_gen.h generated 539 class definitions. ok. generating: src/haskell/Graphics/UI/WXCore/WxcClassInfo.hs reading class definitions: parsing: src/include/wxc.h parsing: src/include/wxc_types.h parsing: src/include/wxc_glue.h parsing: src/include/db.h parsing: src/include/dragimage.h parsing: src/include/graphicscontext.h parsing: src/include/sound.h parsing: src/include/managed.h parsing: src/include/mediactrl.h parsing: src/include/previewframe.h parsing: src/include/printout.h parsing: src/include/textstream.h parsing: src/include/stc.h parsing: src/include/stc_gen.h generated 381 class info definitions ok. parsing: src/include/wxc.h parsing: src/include/wxc_types.h parsing: src/include/wxc_glue.h parsing: src/include/db.h parsing: src/include/dragimage.h parsing: src/include/graphicscontext.h parsing: src/include/sound.h parsing: src/include/managed.h parsing: src/include/mediactrl.h parsing: src/include/previewframe.h parsing: src/include/printout.h parsing: src/include/textstream.h parsing: src/include/stc.h parsing: src/include/stc_gen.h ignore: parse error : //WXCOLORREF wxColour_GetPixel( TSelf(wxColour) _obj ); generating: src/haskell/Graphics/UI/WXCore/WxcClassesAL.hs reading class definitions: parsing: src/include/wxc.h parsing: src/include/wxc_types.h parsing: src/include/wxc_glue.h parsing: src/include/db.h parsing: src/include/dragimage.h parsing: src/include/graphicscontext.h parsing: src/include/sound.h parsing: src/include/managed.h parsing: src/include/mediactrl.h parsing: src/include/previewframe.h parsing: src/include/printout.h parsing: src/include/textstream.h parsing: src/include/stc.h parsing: src/include/stc_gen.h generated 1560 methods for 120 classes. generating: src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs generated 2184 methods for 123 classes. generating: src/haskell/Graphics/UI/WXCore/WxcClasses.hs generated 3744 total methods for 243 total classes. ok. parsing: src/eiffel/wxc_defs.e parsing: src/eiffel/wx_defs.e parsing: src/eiffel/stc.e generating: src/haskell/Graphics/UI/WXCore/WxcDefs.hs generated 2454 constant definitions ok. setup: failed cabal: Error: some packages failed to install: wxcore-0.12.1.6 failed during the configure step. The exception was: ExitFailure 1

1 0

Re: [Haskell-cafe] Problems with iteratees
by John Lato 04 Feb '11

04 Feb '11

> > From: wren ng thornton <wren(a)freegeek.org> > On 2/2/11 11:25 PM, Maciej Wos wrote: > > I think the problem is that the iteratee you give to I.convStream > > always returns Just [something] while you should return Nothing on > > EOF. > > That makes sense for the hanging problem (which I only noticed during > debugging). Though I still get the the same error message when running > the whole program... > I don't have too much to add to Maciej and Oleg's reply, except that I'd recommend looking at the Wave codec over the Tiff reader in those versions of iteratee. I don't think that's the only problem, though, because then you'd be getting a "Divergent iteratee" error. The "endOfInput" error is suspicious, and I think you'll need to track it down to solve this problem. It doesn't appear to be from either iteratee or protocol-buffers. Could it be coming from your IO library? I wonder if the enumerator is trying to force a read after EOF has been reached for some reason? As an experiment, you could try using a custom convStream function like this: convStream2 :: Monad m => IterateeG s el m (Maybe (s' el')) -> EnumeratorN s el s' el' m aconvStream2 fi iter = fi >>= check where check (Just xs) = lift (runIter iter (Chunk xs)) >>= docase check (Nothing) = return iter docase (Done a _) = return . return $ a docase (Cont k Nothing) = convStream2 fi k docase (Cont k (Just "endOfInput")) = convStream2 (return Nothing) k docase (Cont _ (Just e)) = return $ throwErr e This may help determine if it's a problem with IO or with the message parsing. John > > On Thu, Feb 3, 2011 at 10:06 AM, wren ng thornton<wren(a)freegeek.org> > wrote: > >> When I put this all together, the process is killed with: > >> > >> control message: Just (Err "endOfInput") > >> > >> Data.Iteratee.Base.run is the origin of the "control message:" part of > the > >> error, but I don't know where (Err "endOfInput") is coming from since > >> Data.Iteratee.Base only uses (Err "EOF") or (Err "Divergent Iteratee"). > I > >> believe runGetEnumeratee is where the problem is, though it could also > be > >> the use site or something in one of the libraries. Any help would be > >> appreciated. > > -- > Live well, > ~wren >

2 1

Haskell AES
by tsuraan 04 Feb '11

04 Feb '11

I'd like to use AES in a haskell program that I'm writing. I've come across three libraries in hackage that do AES: the library named AES, the Crypto library, and the SimpleAES library. The library named AES says in its documentation for the "crypt" function that it is not thread-safe. What exactly does this mean in haskell? Does it mean that if you have separate AESCtx instances in different forkIO "threads", that things will break? Or does it just mean that using the same AESCtx in multiple forkIO threads is a bad idea? I'm asking about that one comment because it looks like SimpleAES is probably a wrapper around AES, and the Crypto library also says it uses a library named AES, although one by an author not listed in the hackage AES library entry. Can anybody shed some light on the state of AES encryption in haskell? What is the preferred library, especially for us in a program that has many forkIO'd "threads"?

1 0