- Haskell-Cafe - Haskell.org

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

03 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 03 Dec '12

03 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

what is the purpose of GHC.Exts.lazy?
by jared simpson 01 Dec '12

01 Dec '12

docs say: The call '(lazy e)' means the same as e, but lazy<http://hackage.haskell.org/packages/archive/base/latest/doc/html/GHC-Exts.h…> has a magical strictness property: it is lazy in its first argument, even though its semantics is strict. why do i want to use magic during strictness analysis?

1 0

Simple GUI Form
by Rune Harder Bak 01 Dec '12

01 Dec '12

Hi I have some input parameters data Input = ... that I need the user to enter in a gui pop-up. (windows people...) The rest of the app is not gui (or perhaps progress could be displayed in a log-window) What is the easiest way to make such a GUI form? It need to compile for both Linux and Windows, so I though WxWidgets was ideal, and I got wx[1] < 0.90 to install (using wxWidgets2.8) on both windows and linux. Now I just need to create the form, but how do you do that? Any clues or links to examples? I have never used wxwidgets on any platform or done any other form of GUI before for that matters. (apart from some Visual Basic ten years ago, and html). I tried looking at wx examples, but I couldn't find this simple use case explained anywhere. I installed wx in the first place because WxGeneric[2] seemed exactly what I needed, but I can't get it to compile using ghc7.4.2 from haskell-platform. Anybody got that working or have some other simple method? Help much appreciated! -Rune [1] http://hackage.haskell.org/package/wx-0.13.2.3 [2] http://hackage.haskell.org/package/WxGeneric

3 9

computation over containers, greatly simplified notation.
by Takayuki Muranushi 01 Dec '12

01 Dec '12

Dear all, I came up with an idea to greatly simplify some kinds of array computations. It should work well with many kinds of arrays. Is this new? https://gist.github.com/4162375 These few days, I've been trying to rewrite a hydrodynamic simulation code that used Data.Vector (~250 lines), to Repa [1] . It seemed promising, but soon I realized that I needed to use Repa.map and Repa.zipWith almost everywhere. I need careful thinking to transform every lines (that used vector's indexing) to Repa's point-free stile. Is there any better ways? Then I realized that I was the author of Paraiso [2], a DSL for stencil computation. One of its feature is to write down array computation just as if it were scalar computation. Basically what I need is ZipList-like Applicative instances for vectors and Repa arrays. Why not they support ZipVector? Because 'pure' of zipList was an infinite list and you can't do infinite vectors. Then I came up with this idea. https://gist.github.com/4162375 the wrapper W does several things: it represents the 'pure,' homogeneous array in a space-efficient manner, and also serves as a newtype-wrapper of Num (and possibly Fractional, Floating...) instances. Questions are: is this technology new? or promising? doomed? It seems to me like a free-Applicative, like the free-Monad theory. Are they related? The function 'backend' helps to mix in the non-zip-like computations. How can we remove the 'undefined' in the 'backend?' Some of Repa computations are Monads. W needs to be a monad transformer to incooperate this. Also I'm grateful to past cafe discussion on existing Zippable implementations [3][4] . [1] hackage.haskell.org/package/repa [2] http://hackage.haskell.org/package/Paraiso [3] http://www.haskell.org/pipermail/haskell-cafe/2009-July/064403.html [4] http://hackage.haskell.org/packages/archive/category-extras/latest/doc/html… -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

2 4

Are storable-mutable-vectors in two dimensions possible in Haskell?
by Fixie Fixie 01 Dec '12

01 Dec '12

Hello haskellers I am struggling with this package: Data.Vector.Storable.Mutable I am creating vectors like this: MV.new 1000 :: IO (V.MVector (PrimState IO) Int) Now I would like access to this vectors in linear time, like I could have done in C using pointers. The problem is that I do not know which datastructure to keep my vectors in. If I put them in a list, the access is very slow. Even a binary tree is very slow compared to a C-version. I have tried to make an array og vector of storable-mutable vectors, but have not manged to accomplish this - even though there must be a haskell way :-) Any clues? Cheers, Felix

2 2