September 2014 - Haskell-Cafe

Re: [Haskell-cafe] Parallel interruptible computations
by Julian K. Arni 09 Sep '14

09 Sep '14

Are you looking for something like amb/unamb? [0] In particular, if you look at the comments in the source for 'race', it should be pretty intuitive how to go from there to "run x computations, kill the remaining ones after y return". You just need to fiddle with the MVar, possibly adding another thread and MVar that represents whether the calculation can already be completed. [0] https://hackage.haskell.org/package/unamb-0.2.5/docs/src/Data-Unamb.html#amb

2 1

End of support for test-framework-smallcheck and test-framework-golden
by Roman Cheplyaka 08 Sep '14

08 Sep '14

I'm going to stop maintaining the test-framework-smallcheck and test-framework-golden packages. I recommend switching to tasty's tasty-smallcheck and tasty-golden, respectively. If you are interested in taking over these test-framework packages, let me know. Otherwise, I will continue supporting them for the next 3 months and abandon/deprecate them afterwards. Roman

1 0

Can't create a static Linux executable when using hmatrix
by Kai Zhang 08 Sep '14

08 Sep '14

Hi Cafe, I am trying to build a static exec to be run on another machine, and I failed probably due to hmatrix. How can I fix this? Thanks! Test code: import Numeric.LinearAlgebra.Data main = print (fromLists [[2,3,3], [2,3,3]] :: Matrix Double) When complied with "ghc -O2 -static -optc-static -optl-static test.hs -optl-pthread", gave me lots of errors: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In function `dgees_': (.text+0xbc4): undefined reference to `dcopy_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In function `dgees_': (.text+0xed9): undefined reference to `dswap_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In function `dgees_': (.text+0x1304): undefined reference to `dswap_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In function `dgees_': (.text+0x1377): undefined reference to `dswap_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0xf9a): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0xfd4): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x1022): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x103b): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x109c): undefined reference to `idamax_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x1125): undefined reference to `drot_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x12aa): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x12e4): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x1332): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x134b): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x13ac): undefined reference to `idamax_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x143d): undefined reference to `drot_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x148e): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x14bc): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x14fe): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x152c): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgehrd.o): In function `dgehrd_': (.text+0x65d): undefined reference to `dtrmm_' . . .

4 7

ANNOUNCE: buildable-0.1.0.0
by Ivan Lazar Miljenovic 08 Sep '14

08 Sep '14

Have you ever wanted to deal with the builders for various data types in a polymorphic/overloaded fashion? I'm needing to do so and couldn't find any existing code that did so, so I decided to rectify this: http://hackage.haskell.org/package/buildable As a (very contrived) example: λ> build ((365 :: Dec Int) <| fromValue (Char7 ' ') |> (365 :: BigEndian Int16) |> (" omega=𝟂 " :: Utf8 String) |> Utf16 (LE ("hello" :: LT.Text))) :: SB.ByteString "365 \SOHm omega=\240\157\159\130 h\NULe\NULl\NULl\NULo\NUL" -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Re: [Haskell-cafe] Parallel interruptible computations
by Corentin Dupont 08 Sep '14

08 Sep '14

Hi guys, thanks for the nice answers! I'll give you a little bit more context: I'm designing an event engine. I have instances for Applicative, Alternative, Monad, MonadPlus. It's like that: -- | Composable events data Event a where SumEvent :: Event a -> Event a -> Event a -- The first event to fire will be returned. AppEvent :: Event (a -> b) -> Event a -> Event b -- Both events should fire, and then the result is returned. PureEvent :: a -> Event a -- Create a fake event. The result is useable with no delay. EmptyEvent :: Event a -- An event that is never fired. BindEvent :: Event a -> (a -> Event b) -> Event b -- The first event should fire, then a second event is created using the result. BaseEvent :: BaseEvent a -> Event a -- Embed a base event. ShortcutEvents :: [Event a] -> ([Maybe a] -> Maybe b) -> Event b -- The function is called each time an event fires, as soon as the result can be computed from the available data, it is returned, dismissing the events that haven't fired yet. instance Functor Event where fmap f a = pure f <*> a instance Applicative Event where pure = PureEvent (<*>) = AppEvent instance Alternative Event where (<|>) = SumEvent empty = EmptyEvent instance Monad Event where (>>=) = BindEvent return = PureEvent instance MonadPlus Event where mplus = SumEvent mzero = EmptyEvent The Applicative instance is good if you have two events and you want both of them to fire ("and"). The Alternative instance is good if you have two events and you need only one to fire ("or"). But what if you have several events, but you need only a part of them to fire in order to construct a final result? Say you have 10 events, but the 5 first to fire will give you enough data to construct a result. You cannot do that with Applicative/Alternative because with Applicative, you need *all* events results, with Alternative you need *only one*. That's why I added this primitive "ShortcutEvents" in my DSL, but I'm not convinced by it. So my questions are: 1. is ShortcutEvents expressible in term of Applicative/Alternative/Monad/MonadPlus? 2. if not is their a well known typeclass that covers this case? 3. if not is their a better way to write it? I especially don't like the list of Event, I'd prefer a more generic writing. What if I want a structure containing the events, instead of a list? What if I want event of various types (say a pair (Event a, Event b) for example)? Note that I'm not working with streams of events (like in traditional FRP frameworks): just with single events (the "BaseEvents") that I want to combine with each other. Those "BaseEvents" will fire only once. The final result of the combination of events will trigger a callback. Cheers, Corentin

3 6

FFI question
by Vasili I. Galchin 08 Sep '14

08 Sep '14

Hello, I need memory refreshing about FFI because I need to fix a bug (plus I got down a rat hole because of Ukraine war :-(). Following a snippet of something I wrote: -- | lock all of the memory space of a process lockAllMemory :: LockAllFlags -> IO () lockAllMemory flags = do throwErrnoIfMinus1 "lockAllMemory" (c_mlockall cflags) return () where cflags = case flags of CURRENT -> (#const MCL_CURRENT) FUTURE -> (#const MCL_FUTURE) CURRENTandFUTURE -> (#const MCL_CURRENTandFUTURE) it is a file called LockedMem.hsc and the third arm CURRENTandFUTURE I just added to fix the this bug .. MCL_CURRENTandFUTURE ends up in LockedMem_make.c(sp??) but I get a undeclared nasty message when I try to build LockedMem.hsc... my bad... . Please help so I can go back to help Ukraine. Kind regarsd, Vasya

1 1

[ANN] haddock-2.15-0, haddock-api-2.15-0, haddock-library-1.1.1
by Mateusz Kowalczyk 07 Sep '14

07 Sep '14

Hello, I'd like to announce the release of Haddock 2.15.0. Before we dive in, I'd like to announce that Haddock development has moved out of the GHC tree and is now done against the latest compiler release. If in the past you wanted to contribute but were intimidated by having to make sure it works against GHC HEAD then here's your chance. Additionally, it now should also work with GHC 7.8.2 so if for whatever reason you're forced to use that, you can now get the latest Haddock features. If you want to contribute then please let us know, we're understaffed! Come chat at #haddock or send us an e-mail. If you have been using 2.14.x, you should be good to simply ‘cabal install haddock’. Now the changes: This is an API-breaking bugfix release so any tickets originally scheduled for 2.15.0 were pushed towards 2.16. Perhaps the biggest change is that ‘cabal install haddock’ will now only give you the Haddock binary. To use Haddock API, please depend on ‘haddock-api’ from now on. I have sent out an e-mail about this couple of weeks in advance to any reverse dependencies of ‘haddock’. This is to workaround cabal's inability to pass flags to dependencies from the cabal file. ‘haddock-library’ only got a minor bump, 1.1.0 → 1.1.1 improving its output. The Monoid instance for DocH is gone however as it was ill-formed to begin with. Changes in version 2.15.0 * Always read in prologue files as UTF8 (#286 and Cabal #1721) * parser: don't wrap headers in DocParagraph (#307) * parser: don't mangle append order for nested lists (pandoc #1346) * parser: preserve list ordering in certain scenarios (#313) * parser: update the attoparsec version used internally giving slight parsing performance boost. * Move development to be against latest GHC release and not GHC HEAD. * Further split up the package to separate the executable from the library, necessary by things like GHCJS. We now have ‘haddock-library’ which are the parts that don't use GHC API, ‘haddock-api’ which are (some of) the parts that do use GHC API and ‘haddock’ which merely provides the executable. * Export few extra functions in the API. * Add compatibility with GHC 7.8.2. * Omit unnecessary ‘forall’s (#315 and #86) * Remove some files which were really old or did not belong in the repository in the first place. Once again, we'd love to have more people on board be it for the HTML backend, refactoring, LaTeX/Hoogle backend, parser improvements, test writing, new feature implementation or bug fixing. Our issue tracker[1] is up to date if you are interested. Thanks! [1]: https://github.com/haskell/haddock/issues -- Mateusz K.

3 5

Re: [Haskell-cafe] Parallel interruptible computations
by Corentin Dupont 07 Sep '14

07 Sep '14

Nobody on those parallel interruptible computations/events? I believe this is related to FRP: we register on several events but only a part of them is enough to compute the result. But I don't see such operator in FRP frameworks such as reactive-banana... On Fri, Sep 5, 2014 at 12:59 PM, Corentin Dupont <corentin.dupont(a)gmail.com> wrote: > Hi guys! > I'm wondering if there is an abstraction (for example a typeclass) for > parallel interruptible computations. > I want several things to be computed in parallel. Those computations will > not finish at the same time, but as soon as enough result is gathered, the > remaining computations can be cancelled and the final result computed. > Clearly a Monad is not suited here: Monad are by definition for sequential > computation (since the result of the first computation is fed to the next). > > -> So the question is: is there an abstraction for parallel computations? > > Note that I'm not interrested with real implementations (such as with > threads) but with the abstraction. > For now I came up with: > > ShortcutEvents :: [Event a] -> ([a] -> Maybe b) -> Event b > > This takes a list of events and a function. The events can fire at > whatever moment, and as soon as one of the events fires, the function is > called with the results available so far. If the function returns Just, the > remaining events are cancelled and the final result is returned. > This is working fine, but I'd like a way to generalize this, especially to > generalize the list to any structure... > > The use case is a voting system: people can vote at whatever moment, but > sometime the result of the vote is known even if not everybody voted yet. > > Thanks! > Corentin >

3 2

Fwd: an idea for improving 'shrink'
by Petr Pudlák 06 Sep '14

06 Sep '14

Hi, since I got no response from the QuickCheck mail address, so I'm resending it here, if someone wants to comment on the idea. Best regards, Petr ---------- Forwarded message ---------- From: Petr Pudlák <petr.mvd(a)gmail.com> Date: 2014-07-06 20:13 GMT+02:00 Subject: an idea for improving 'shrink' To: QuickCheck developers <quickcheck(a)projects.haskell.org> Hi, I was learning about 'shrink' lately and I was trying to create some instances. It felt quite awkward until I realized that the operation for producing shrunk tuples is an applicative functor. I was playing with the idea for a while and I'm sending an experimental patch against QuickCheck master that shows the basics of the idea and how it can help constructing 'shrink' instances. If you feel that this is a good idea, let me know, I'll work on a full patch. Best regards, Petr

2 3

Functional dependency failure
by Alexander Pakhomov 06 Sep '14

06 Sep '14

Hi! I have following code: STRead.hs: import Control.Monad.Reader import Control.Monad.ST import qualified Data.Vector.Mutable as MV import qualified Data.Vector as V type ReadVecMonad s = ReaderT (MV.MVector s Int) (ST s) freezeV :: ReadVecMonad s (V.Vector Int) freezeV = ask >>= lift V.freeze Trying to compile this I have "Couldn't match type ... When using functional dependencies to combine" error following with kind mismatch and type with literaly the same type mismatch. How can I work this around? There's full error message: STRead.hs:9:11: Couldn't match type `V.MVector s Int' with `(->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int)' When using functional dependencies to combine MonadReader r (ReaderT r m), arising from the dependency `m -> r' in the instance declaration in `Control.Monad.Reader.Class' MonadReader ((->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int)) (ReaderT (V.MVector s Int) (ST s)), arising from a use of `ask' at STRead.hs:9:11-13 In the first argument of `(>>=)', namely `ask' In the expression: ask >>= lift V.freeze STRead.hs:9:19: Couldn't match kind `* -> *' with `*' Expected type: (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) Actual type: (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) Kind incompatibility when matching types: (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) :: * -> * (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) :: * In the return type of a call of `lift' In the second argument of `(>>=)', namely `lift V.freeze' STRead.hs:9:24: Couldn't match kind `*' with `* -> *' Expected type: V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) Actual type: V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) Kind incompatibility when matching types: (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) :: * (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) :: * -> * In the first argument of `lift', namely `V.freeze' In the second argument of `(>>=)', namely `lift V.freeze'

2 2