December 2012 - Haskell-Cafe

Re: [Haskell-cafe] Design of a DSL in Haskell
by Brent Yorgey 03 Dec '12

03 Dec '12

(Sorry, forgot to reply to the list initially; see conversation below.) On Mon, Dec 03, 2012 at 03:49:00PM +0100, Joerg Fritsch wrote: > Brent, > > I believe that inside the do-block (that basically calls my > interpreter) I cannot call any other Haskell function that are not > recognized by my parser and interpreter. This seems to just require some sort of "escape mechanism" for embedding arbitrary Haskell code into your language. For example a primitive embed :: a -> CWMWL a (assuming CWMWL is the name of your monad). Whether this makes sense, how to implement embed, etc. depends entirely on your language and interpreter. However, as you imply below, this may or may not be possible depending on the type a. In that case I suggest making embed a type class method. Something like class Embeddable a where embed :: a -> CWMWL a I still get the feeling, though, that I have not really understood your question. > I am also trying to learn how I could preserve state from one line > of code of my DSL to the next. I understand that inside the > interpreter one would use a combination of the state monad and the > reader monad, but could not find any non trivial example. Yes, you can use the state monad to preserve state from one line to the next. I am not sure what you mean by using a combination of state and reader monads. There is nothing magical about the combination. You would use state + reader simply if you had some mutable state as well as some read-only configuration to thread through your interpreter. xmonad is certainly a nontrivial example but perhaps it is a bit *too* nontrivial. If I think of any other good examples I'll let you know. -Brent > > > On Dec 3, 2012, at 1:23 PM, Brent Yorgey wrote: > > > On Sun, Dec 02, 2012 at 03:01:46PM +0100, Joerg Fritsch wrote: > >> This is probably a very basic question. > >> > >> I am working on a DSL that eventuyally would allow me to say: > >> > >> import language.cwmwl > >> main = runCWMWL $ do > >> eval ("isFib::", 1000, ?BOOL) > >> > >> I have just started to work on the interpreter-function runCWMWL and I wonder whether it is possible to escape to real Haskell somehow (and how?) either inside ot outside the do-block. > > > > I don't think I understand the question. The above already *is* real > > Haskell. What is there to escape? > > > >> I thought of providing a defautl-wrapper for some required prelude > >> functions (such as print) inside my interpreter but I wonder if > >> there are more elegant ways to co-loacate a DSL and Haskell without > >> falling back to being a normal library only. > > > > I don't understand this sentence either. Can you explain what you are > > trying to do in more detail? > > > > -Brent > >

2 2

Can not use ST monad with polymorphic function
by Dmitry Kulagin 03 Dec '12

03 Dec '12

Hi Cafe, I try to implement some sort of monadic fold, where traversing is polymorphic over monad type. The problem is that the code below does not compile. It works with any monad except for ST. I suspect that monomorphism is at work here, but it is unclear for me how to change the code to make it work with ST. fold :: Monad m => (Int -> m ()) -> m () fold f = mapM_ f [0..20] selectFold :: Monad m => String -> IO ((Int -> m ()) -> m ()) selectFold method = do -- in real program I'd like to choose between -- different fold methods, based on some IO context return fold useFold :: Monad m => ((Int -> m ()) -> m ()) -> m () useFold fold' = fold' f where f _ = return () -- some trivial iterator main = do fold'' <- selectFold "some-method-id" print $ runST $ useFold fold'' Thank you! Dmitry

4 5

To my boss: The code is cool, but it is about 100 times slower than the old one...
by Fixie Fixie 03 Dec '12

03 Dec '12

Hi all haskellers I every now and then get the feeling that doing my job code in Haskell would be a good idea. I have tried a couple of times, but each time I seem to run into performance problems - I do lots of heavy computing. The problem seems to be connected to lazy loading, which makes my programs so slow that I really can not show them to anyone. I have tried all tricks in the books, like !, seq, non-lazy datatypes... I was poking around to see if this had changed, then I ran into this forum post: http://stackoverflow.com/questions/9409634/is-indexing-of-data-vector-unbox… The last solution was a haskell program which was in the 3x range to C, which I think is ok. This was in the days of ghc 7.0 I then tried compile the programs myself (ghc 7.4.1), but found that now the C program now was more that 100x faster. The ghc code was compiled with both O2 and O3, giving only small differences on my 64-bit Linux box. So it seems something has changed - and even small examples are still not safe when it comes to the lazy-monster. It reminds me of some code I read a couple of years ago where one of the Simons actually fired off a new thread, to make sure a variable was realized. A sad thing, since I am More that willing to go for Haskell if proves to be usable. If anyone can see what is wrong with the code (there are two haskell versions on the page, I have tried the last and fastest one) it would also be interesting. What is your experience, dear haskellers? To me it seems this beautiful language is useless without a better lazy/eager-analyzer. Cheers, Felix

8 21

Is anyone working on a sparse matrix library in Haskell?
by Mark Flamer 02 Dec '12

02 Dec '12

I am looking to continue to learn Haskell while working on something that might eventually be useful to others and get posted on Hackage. I have written quite a bit of Haskell code now, some useful and a lot just throw away for learning. In the past others have expressed interest in having a native Haskell sparse matrix and linear algebra library available(not just bindings to a C lib). This in combination with FEM is one of my interests. So my questions, is anyone currently working on a project like this? Does it seem like a good project/addition to the community? I'm also interested if anyone has any other project idea's, maybe even to collaborate on. Thanks -- View this message in context: http://haskell.1045720.n5.nabble.com/Is-anyone-working-on-a-sparse-matrix-l… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

8 12

[ANN] xmobar 0.16 released
by Jose A. Ortega Ruiz 02 Dec '12

02 Dec '12

I've just released xmobar 0.16, the lightweight text-based system monitor written in Haskell. See http://projects.haskell.org/xmobar, and full release notes below. As always, thanks a bunch to the many contributors, who keep helping me improving xmobar and making it more and more useful. The continuous flow of patches and suggestions is one the nicest things about hacking on and maitaining xmobar. This is a somewhat risky release, because some users are reporting problems with GHC 7.6.1 and xmonad (see links below), but there are so many new features and fixes, and happy users of the unstable version, that i thought a release was in order. Please, do not hesitate to complain about problems you might encounter: i'll do my best to fix them in subsequent releases. Thanks! ## Version 0.16 (Dec 3, 2012) _New features_ - New monitor `AutoMPD`, which uses asynchronous events to display MPD status (thanks to Ben Boeckel). - New monitor `BufferedPipeReader` displaying data from multiple pipes (thanks to Jochen Keil). - New monitor `DynNetwork`, which detects the active interface automatically, by Reto Hablützel - New monitor, `Locks`, displaying the status of lock keys, by Patrick Chilton. - Extension for DBUS signal handling (Jochen Keil) - Hide/Reveal: one can send signals to xmobar and make it (un)hide itself (Jochen again). - `PipeReader`'s default text is now configurable, by Reto Hablützel. - Dependencies updated to latest mtl and libmpd (thanks to Sergei Trofimovich). - Dependencies on the deprecated dbus-core removed in favour of dbus 0.10 (thanks to Jochen Keil). - MPris2 now includes genre and composer among its fields. _Bug fixes_ - `DiskIO` now can report overall activity in all partitions of a device which is not mounted itself (e.g., sda when sda1, sda3, etc. are the mounted partitions). Thanks to John Soros. See [github #73]. - `DiskU`, the disk usage monitor, works again correctly on Linux, instead of randomly crashing every now and then, and reporting wrong used size. - When using antialiased fonts, we were causing a memory leak in the X server by repeatedly allocating colors that, apparently, the server doesn't know how to get rid of (even when told so!). We're caching them now and X server memory doesn't grow. - Compilation errors and warnings with GHC 7.6 removed (thanks to Raghavendra D Prabhu for his reports in [github #71]). _Known problems_ Some users have reported problems with xmobar compiled with GHC 7.6 in ArchLinux: see [github #78] and pointers therein. Please, send reports of any problems or successes in that regard so that we can fix any remaining issues. Thanks! [github #71]: https://github.com/jaor/xmobar/issues/71 [github #73]: https://github.com/jaor/xmobar/issues/73 [github #78]: https://github.com/jaor/xmobar/issues/78

1 0

How to incrementally update list
by Branimir Maksimovic 02 Dec '12

02 Dec '12

Problem is following short program:list = [1,2,3,4,5] advance l = map (\x -> x+1) l run 0 s = srun n s = run (n-1) $ advance s main = do let s = run 50000000 list putStrLn $ show s I want to incrementally update list lot of times, but don't knowhow to do this.Since Haskell does not have loops I have to use recursion,but problem is that recursive calls keep previous/state parameterleading to excessive stack.and memory usage.I don't know how to tell Haskell not to keep previousstate rather to release so memory consumption becomesmanagable. Is there some solution to this problem as I think it is rathercommon?

7 11

Is there any movement/need in new 'base' package and co?
by Евгений Пермяков 02 Dec '12

02 Dec '12

It is clear, that current 'core' Haskell packages bear some weight of legacy and back-compatibility, and accumulates garbage/problems over time. Some of the garbage can be dropped and some was here for so long, that it can't be dropped without major buzz. For example, we have *Monad* type-class, that is hardwired into Haskell syntax. However, it allows arbitrary fail by definition, and not all monads should provide this option. Still, it is almost impossible to move the method into separate interface, as every *Monad* instance will have to be rewritten. Lack of standard packed text/binary string type is also a problem. It is not so problem on itself, as problem of support: different io packages, parser tools and so on have to choose what string type to use, which lead to fragmentation of library field. Hierarchy of numeric classes is also often questioned. More points of problems may be found if one will study Hackage long enough. So, the questions arise: - When problems will ruin the language? - When and which actions are needed to avoid this? - If major rewrite will be initiated, what problems it should target? - And how to make the transition easier? ====

2 1

Fwd: Conduit and pipelined protocol processing using a threadpool
by Alexander V Vershilov 02 Dec '12

02 Dec '12

Forwarding to maillist: Hi, Nicolas. Just my 2 cents. You can try to 'break' your server side application in two parts, reader and writer then you can have: main = do ch1 <- ... -- inbound channel of type (message ,outchannel) replicateM n $ forkIO $ sourceTBMChan ch1 $$ loop1 -- ^^ you can move this code into myApp if you need per client workers runTCPServer config $ \ad -> do ch2 <- ... -- outbound channel {- now will start 2 threads for reader and writer) bracket (forkIO $ sourceTBMChan ch2 $= appSource ad) (\t -> threadDestroy t >> atomically (closeTBMChan ch2)) (const $ appSource ad $$ loop2 ch2) where loop1 = do mm <- await case mm of Just (m, out) -> process m >>= atomically (writeTBMChan out) >> loop1 Nothing -> return () {- using conduit-stm in loop2 will fail as it will close channel at the end of the processing -} loop2 ch = await >>= \x -> when (isJust x) (writeTBMChan ch (fromJust x, ch) >> loop2 ch) I have not checked this code, but the same approach works 2 projects. -- Alexander Vershilov On 28 November 2012 09:21, Nicolas Trangez <nicolas(a)incubaid.com> wrote: > On Wed, 2012-11-28 at 09:17 +0200, Michael Snoyman wrote: >> >> >> >> On Tue, Nov 27, 2012 at 7:25 PM, Nicolas Trangez >> <nicolas(a)incubaid.com> wrote: >> Michael, >> >> On Tue, 2012-11-27 at 17:14 +0200, Michael Snoyman wrote: >> > I think the stm-conduit package[1] may be helpful for this >> use case. >> > Each time you get a new command, you can fork a thread and >> give it the >> > TBMChan to write to, and you can use sourceTBMChan to get a >> source to >> > send to the client. >> >> >> That's +- what I had in mind. I did find stm-conduit before >> and did try >> to get the thing working using it, but these attempts failed. >> >> I attached an example which might clarify what I intend to do. >> I'm aware >> it contains several potential bugs (leaking threads etc), but >> that's >> beside the question ;-) >> >> If only I could figure out what to put on the 3 lines of >> comment I left >> in there... >> >> Thanks for your help, >> >> Nicolas >> >> >> >> The issue is that you're trying to put everything into a single >> Conduit, which forces reading and writing to occur in a single thread >> of execution. Since you want your writing to be triggered by a >> separate event (data being available on the Chan), you're running into >> limitations. >> >> >> The reason network-conduit provides a Source for the incoming data and >> a Sink for outgoing data is specifically to address your use case. You >> want to take the data from the Source and put it into the Chan in one >> thread, and take the data from the other Chan and put it into the Sink >> in a separate thread. Something like: >> >> >> myApp appdata = do >> chan1 <- ... >> chan2 <- ... >> replicateM_ 5 $ forkIO $ worker chan1 chan2 >> forkIO $ appSource appdata $$ sinkTBMChan chan1 >> sourceTBMChan chan2 $$ appSink appdata >> >> >> You'll also want to make sure to close chan1 and chan2 to make sure >> that your threads stop running. > > Thanks, I +- figured that out last night. Only thing left is managing > the handshake before forking off the workers, if possible (otherwise > things become very messy IMHO), but ResumableSources etc might be of use > here. > > Maybe there's a library somewhere in here... > > Thanks a bunch, > > Nicolas > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- С уважением, Вершилов Александр ( mail-to: alexander.vershilov(a)gmail.com ) -- С уважением, Вершилов Александр ( mail-to: alexander.vershilov(a)gmail.com )

1 0

debugging memory corruption
by Evan Laforge 02 Dec '12

02 Dec '12

Ever since upgrading to 7.6.1 I regularly get panics like this: seq: internal error: evacuate: strange closure type -1958168540 (GHC version 7.6.1 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I've seen some variations, but basically I think it just means someone is corrupting memory and it goes unnoticed until the GC trips over it. This happens infrequently (maybe once in 15m, very roughly, it's extremely inconsistent) in non-optimized code, and frequently (maybe once in 5m) in optimized code. This only happens during interactive use, not during testing or profiling. I had a problem like this once before, and it took a very long time to track down. And in fact, I never really tracked it down, I just got a test that could semi-reliably reproduce it, and then by trial and error discovered that if I changed the alignment of a particular Storable instance from 1 to 4, the problem stopped happening (and 1 should have been correct, it was a struct of chars). Not exactly a satisfying solution, and now I'm thinking all I did was make ghc 6 stop manifesting it, and with 7 it's back again. I'm most suspicious of the FFI usage since it's easy to corrupt memory in C++ and even easier to write a bogus Storable instance that does the same, but I really have no idea what or where. My first thought was to start cutting out portions (especially FFI-using portions) to try to isolate it, but it's slow going because it can sometimes take quite a while to the bug to come out again. My second thought was that I need a more automated way to reproduce it, but it's nontrivial because it only comes up when I'm using the interactive GUI parts, which are also incidentally a big chunk of FFI. And even if I do get a repro, as I did before, it just means I can more quickly poke randomly at things hoping they change it, but even if I can get it to stop happening it doesn't mean I understood it, or even really fixed it. This is also the kind of bug (well, it was last time), which is highly dependent on the code, so add one print and it stops happening. I have a sort of complicated scheme where I pass a wrapped haskell function callback along with a wrapped freeHaskellFunPtr to free the last one, along with itself, maybe it's something to do with that. Anyone out there with ideas or advice on how to track down this kind of bug? My next thought is to try to automate the GUI parts, or maybe just the FFI part, so I can write a program to randomly fuss with it until it crashes. I've also tried valgrind, but it doesn't report anything suspicious. But it also doesn't seem to work on FFI Storable corruption, I've tried intentionally inserting a bad poke and valgrind still won't report it. Thanks in advance for any insight! Actually, there's a whole other discussion which has been nagging at me for a while, though another thread would be more appropriate. But in short it's that it feels like hsc2hs is just too low level, and too error-prone. It's tempting to use because it comes with ghc, but it seems bad to tell people "haskell is a safe language, but as soon as you want to talk to C you're writing totally unchecked pokes and peeks". Maybe I should go evaluate the alternatives like c2hs, or maybe safety features can added to hsc2hs. Wouldn't it be nice to have ghc come with a high level and safe FFI language?

2 2

Why is boxed mutable array so slow?
by Branimir Maksimovic 02 Dec '12

02 Dec '12

I have made benchmark test inspired by http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/ What surprised me is that unboxed array is much faster than boxed array.Actually boxed array performance is on par with standard Haskell listwhich is very slow.All in all even unboxed array is about 10 times slower than Java version.I don't understand why is even unboxed array so slow.But! unboxed array consumes least amount of RAM.(warning, program consumes more than 3gb of ram) bmaxa@maxa:~/examples$ time ./Cumulboxed arraylast 262486571 seconds 4.972unboxed arraylast 262486571 seconds 0.776listlast 262486571 seconds 6.812 real 0m13.086suser 0m11.996ssys 0m1.080s -------------------------------------------------------------------------{-# LANGUAGE CPP, BangPatterns #-}import System.CPUTimeimport Text.Printfimport Data.Array.IOimport Data.Array.Baseimport Data.Intimport Control.DeepSeqimport System.Mem main :: IO()main = do (newArray_ (0,n'-1) :: IO(A)) >>= test "boxed array" performGC (newArray_ (0,n'-1) :: IO(B)) >>= test "unboxed array" performGC begin <- getCPUTime printf "list\nlast %d" $ last $ force $ take n' $ sum' data' end <- getCPUTime let diff = (fromIntegral (end - begin)) / (10^12) printf " seconds %.3f\n" (diff::Double) test s a = do putStrLn s begin <- getCPUTime init' a partial_sum a end <- getCPUTime let diff = (fromIntegral (end - begin)) / (10^12) last <- readArray a (n'-1) printf "last %d seconds %.3f\n" last (diff::Double) n' :: Intn' = 50 * 1000 * 1000 type A = IOArray Int Int32type B = IOUArray Int Int32 init' a = do (_,n) <- getBounds a init a 0 n where init a k n | k > n = return () | otherwise = do let !x = fromIntegral $ k + k `div` 3 unsafeWrite a k x init a (k+1) n partial_sum a = do (_,n) <- getBounds a k <- unsafeRead a 0 ps a 1 n k where ps a i n s | i > n = return () | otherwise = do k <- unsafeRead a i let !l = fromIntegral $ s + k unsafeWrite a i l ps a (i+1) n l data' :: [Int32]data' = [k + k `div` 3 | k <- [0..] ] sum' = scanl1 (+)

4 7