- Haskell-Cafe - Haskell.org

PLMW: Mentoring at POPL. Second Call for Participation
by Gareth Smith 04 Dec '12

04 Dec '12

Students! You have until Sunday to apply for funding to come to both POPL and PLMW! CALL FOR PARTICIPATION SIGPLAN Programming Languages Mentoring Workshop, Rome Tuesday January 22, 2013 Co-located with POPL 2013 PLMW web page: http://www.doc.ic.ac.uk/~gds/PLMW/index.html After the resounding success of the first Programming Languages Mentoring Workshop at POPL 2012, we proudly announce the 2nd SIGPLAN Programming Languages Mentoring Workshop (PLMW), co-located with POPL 2013 and organised by Nate Foster, Philippa Gardner, Alan Schmitt, Gareth Smith, Peter Thieman and Tobias Wrigstad. The purpose of this mentoring workshop is to encourage graduate students and senior undergraduate students to pursue careers in programming language research. This workshop will provide technical sessions on cutting-edge research in programming languages, and mentoring sessions on how to prepare for a research career. We will bring together leaders in programming language research from academia and industry to give talks on their research areas. The workshop will engage students in a process of imagining how they might contribute to our research community. We especially encourage women and underrepresented minority students to attend PLMW. Since PLMW will be in Rome this year, we particularly look forward to seeing Eastern European students at the workshop. This workshop is part of the activities surrounding POPL, the Symposium on Principles of Programming Languages, and takes place the day before the main conference. One goal of the workshop is to make the POPL conference more accessible to newcomers. We hope that participants will stay through the entire conference, and will also attend the POPL tutorials on Monday 21st January which are free to PLMW registered attendees. Through the generous donation of our sponsors, we are able to provide scholarships to fund student participation. These scholarships will cover reasonable expenses (airfare, hotel and registration fees) for attendance at both the workshop and the POPL conference. Students attending this year will get one year free student membership of SIGPLAN The workshop registration is open to all. Students with alternative sources of funding are welcome. APPLICATION for PLMW scholarship: The scholarship application can be accessed from the workshop web site (http://www.doc.ic.ac.uk/~gds/PLMW/index.html) The deadline for full consideration of funding is 9th December, 2012. Selected participants will be notified from Friday 14th December, and will need to register for the workshop by December 24th. SPONSORS: Google Imperial College London Jane Street Monoidics NSF Resource Reasoning SIGPLAN vmware

1 0

Is it possible to have constant-space JSON decoding?
by Iustin Pop 04 Dec '12

04 Dec '12

Hi, I'm trying to parse a rather simple but big JSON message, but it turns out that memory consumption is a problem, and I'm not sure what the actual cause is. Let's say we have a simple JSON message: an array of 5 million numbers. I would like to parse this in constant space, such that if I only need the last element, overall memory usage is low (yes, unrealistic use, but please bear with me for a moment). Using aeson, I thought the following program will be nicely-behaved: > import Data.Aeson > import qualified Data.Attoparsec.ByteString.Lazy as AL > import qualified Data.ByteString.Lazy as L > > main = do > r <- L.readFile "numbers" > case AL.parse json r :: AL.Result Value of > AL.Fail _ context errs -> do > print context > print errs > AL.Done _ d -> case fromJSON d::Result [Value] of > Error x -> putStrLn x > Success d -> print $ last d However, this uses (according to +RTS -s) ~1150 GB of memory. I've tried switching from json to json', but while that uses slightly less memory (~1020 MB) it clearly can't be fully lazy, since it forces conversion to actual types. Looking at the implementation of "FromJSON [a]", it seems we could optimise the code by not forcing to a list. New (partial) version does: > AL.Done _ d -> case d of > Array v -> print $ V.last v And this indeed reduces the memory, when using json', to about ~700MB. Better, but still a lot. It seems that the Array constructor holds a vector, and this results in too much strictness? Looking at the memory profiles (with "json" and "Array"), things are quite interesting - lots of VOID, very small USE, all generated from Data.Aeson.Parser.Internal:array. Using -hd, we have a reasonable equal split between various attoparsec combinators, Data.Aeson.Parser.Internal epressions, etc. So, am I doing something wrong, or is it simply not feasible to get constant-space JSON decoding? Using the 'json' library instead of 'aeson' is no better, since that wants the input as a String which consumes even more memory (and dies, when compiled with -O2, with out of stack even for 64MB stack). thanks, iustin

4 7

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

03 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 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