- Haskell-Cafe - Haskell.org

FRP, Simulations and Time (Sodium et. al)
by martin 18 Mar '14

18 Mar '14

FPR is usually described as a way to model interactions with the real world. I believe the same ideas should be applicable to simulations. Instead of "real" events I would use fake events. This however only makes sense when the Time associated with the Events (and Behaviors) is not wallclock time, but some kind of virtual time. I looked briefly into Sodium and found no way to use "my own time". Steven Blackheath even said during a presentation, that Time in Sodium is just another Behavior. I am not sure if I understood this correctly, but it gives me the feeling, that the only Time available in Sodium is wallclock time, which would make it unsuitable for simulations. Could someone give me some insights whether or not FRP is suitable for simulations? Does my reasoning about Time make any sense? Do different libraries treat Time in different ways, such that some are suitable for simulations, while others are not? Martin

3 5

GSoC Proposal: Pandoc improvements including EPUB 3.0 reader
by Matthew Pickering 18 Mar '14

18 Mar '14

I'm looking to submit a proposal to (mainly) add an EPUB reader to pandoc. I've spent the last few weeks getting to know the code base and wrote a proposal in the last few days. I would really appreciate any comments on the proposal and any further suggestions or things to look out for! Looking forward to doing some hacking on pandoc independent of this! Full proposal: https://www.dropbox.com/s/tdiimqa8mj22vq3/gsoc.pdf Has anyone looked into MathML -> Latex conversion? It would be nice to have this in the EPUB parser to deal with embedded equations. Below is a sketch outline of the suggested implementation. *Embedded Base64 images* - Replace Target in the Image constructor with a new constructor which can either be a Target as before or a base64 encoding. - Update HTML5 reader to read embedded images successfully. *EPUB 3.0 reader* - Utilise the HTML parser with rawTags enabled - Extract additional information about structure from walking over the AST

1 0

Yi project proposal for GSOC 2014
by Mateusz Kowalczyk 17 Mar '14

17 Mar '14

Greetings, GSOC 2014 proposal period opens in ~4 hours and I'm hoping to participate this year as well. This time around I'd quite like to work on Yi. As we did last year, I think it's worthwhile to put up the proposals on café for people to comment on before they are submitted on Google's site. I paste it in full below so that it is easier to respond to parts of it (although I do ask that you don't quote the whole thing if it's not necessary). In case any changes happen, the most up-to-date version should be at https://gist.github.com/Fuuzetsu/9462709 Please feel free to nitpick on anything, throw in suggestions and ask for clarifications. I will give 5 days of discussion period on this after which point I'll submit it on Google's site. I appreciate all feedback. Thanks! Yi concurrency, usability and hackability ------------------------------------------ * What is the goal of the project you propose to do? There are two main goals of the project: the first is to implement concurrency in the Yi text editor. The second aim is to start bringing Yi into the territory of usable and hackable editors. Dmitry Ivanov who's currently in charge of Yi has agreed to mentor this project. * In what ways will this project benefit the wider Haskell community? While the project itself isn't one of the core ones (such as GHC, Haddock and Cabal), I feel that there are a couple of benefits to the community: 1. Work on Yi (now and in the future) will undoubtedly spawn new Haskell libraries usable in other projects. My personal experience with Yi shows that it's actually very comfortable to write a generic library which does what we need and then having a separate package which uses the library to actually interact with Yi. 2. Haskellers come closer to escaping the ELisp/vimscript hell. We can get a nicer programming environment, made and extensible in the language of our choice and get to use all the libraries that we're used to while we're at it. 3. We'll have more Real World™ Haskell applications. On a more serious note, it can serve as a good example of how to do certain things with Haskell: off the top of my head, it demonstrates the use of dyre and gtk2hs in a real-world scenario rather than a 5 line example on the Haskell wiki. If the project is successful, we can add concurrency to this. Other than the Haskell community in general, this project should benefit anyone with some interest in text editors. I think it's safe to say that happens to be a large majority of Haskellers: most of us want nicer integration with Haskell tools and libraries[citation needed] and now it'll be possible through direct, type-checked library access. * Can you give some more detailed design of what precisely you intend to achieve? The concurrency goal will involve careful study of Yi's inner workings in order to try and accommodate concurrency in Yi's editor state. There are various ways to do concurrency and the first part of the project will concentrate on settling for one. An example of two different ways is to extend the existing Yi engine with classical tools (MVars, channels) to accommodate for concurrency that way. An alternative way would be to modify the engine so that concurrency support is natural. Such experiment was started [here](https://github.com/ethercrow/y) using the sodium FRP package which would give us concurrency ‘for free’. The experiment is not complete and this is the kind of thing that will first be explored. Of course once we settle for a method, time will be spent implementing it. In the end, this should allow us to do things such as fire Yi events periodically or do network transfers without having to halt the whole editor. Editors such as emacs which are single-threaded effectively hop back-and-forth between tasks on a single thread. We aim to provide the ability to simply have tasks on different threads which allows us to take advantage of system resources much better. The second part of the project is to make Yi more usable and hackable. Usability here involves fixing bugs apparent to the user and hackability involves bugs apparent to developers. Further, as part of usability, I plan to implement as many editor modes as I find time for. Specifically, here are some open bugs that I hope to either fix or to make a considerate progress on: #445, #397, #517, #519, #515, #516, #513 (concurrency), #512, #507, #504, #502, #501, #499, #497, #493, #487, #478, #477, #468, #465, #399, #396, #391, #390, #382, #322, #295, #172, #160, #106, #145, #112, #82, #509. All the bug numbers can be viewed on [GitHub](https://github.com/yi-editor/yi/issues/). Please note that some of these are documentation bugs: Yi suffers from poor documentation and I believe that's what the main problems in gaining developers and users has been. When time or area I'm working on allows, missing documentation will be written. If I find any issue that have been fixed or are no longer applicable, the reports will simply be closed. The issues are very varied: unicode problems, keymap problems, highlighter problems, reloading problems, testing problems, mode problems… There is certainly enough work to entertain anyone for a longer amount of time while making Yi visibly better. The list of issues is simply an indicator of which problems the second goal of the project will concentrate on, rather than as a promise of which bugs are guaranteed to be fixed by the end of it. Alongside this goal, I'll write any modes for Yi as I find time for them. The completion of concurrency part of the project allows us to write many of the modes frequently requested by people wishing to use Yi which are currently impossible/unfeasible to write. * What deliverables do you think are reasonable targets? Can you outline an approximate schedule of milestones? The plan is based on the GSoC time line: 20 April - 19 May – while this is a bonding period, I'm already a part of the Yi community and have a fair grasp of it. I'd start to look into this project as early as this period (and in fact I plan to make steps towards it before this date which means some of the outlined issues might get fixed early ;) ). 19 May - 23 June – coding period; by this point I expect to have decided on which concurrency model we'll use and have a good idea of how it'll be implemented. By the end of this period, concurrency should either be completed or nearly done, depending on any unexpected problems that might come up. The deliverable would be Yi with (at least some) concurrency support. 24 June - 11 August – second part of the coding period; work on any of the listed (or unlisted bugs) and finish up concurrency if it is still not done. Write extra Yi modes, libraries and documentation as time allows. 11 August - 18 August – post-coding period; write any missing documentation, promote any cool new stuff we wrote ;) While I can not think of a specific deliverable, many bugs should now be fixed, Yi should have a lot more documentation, tests and modes. As a final note regarding the time line, it is not strictly necessary that the project implements concurrency first: while some bugs might need such support, many simply do not. If it's convenient to fix something that I had originally planned to for the second part of the project, I'll do so. * What relevant experience do you have? e.g. Have you coded anything in Haskell? Have you contributed to any other open source software? Been studying advanced courses in a related topic? Second year CS student. I program on regular basis using Haskell. I contribute to a bunch of FOSS projects as it seems necessary (see [my GitHub](https://github.com/Fuuzetsu)) I have successfully completed GSOC in 2013 which involved working on Haddock. To this day I help out with Haddock which often involves looking at the large GHC code base. * In what ways do you envisage interacting with the wider Haskell community during your project? e.g. How would you seek help on something your mentor wasn't able to deal with? How will you get others interested in what you are doing? I have a [blog](http://fuuzetsu.co.uk/blog) which gets propagated onto Haskell Planet. I'm active on IRC and many Haskell-related mailing lists. IRC, mailing lists and any relevant literature is where I'd seek help were I to get stuck on something my mentor can't help me with. I find that news about Yi are very popular and get propagated by the community itself very easily so I doubt there will be any problem getting people interested. I'm very easily reachable over e-mail and IRC and all the development is done in public. * Why do you think you would be the best person to tackle this project? I've been interested in Yi for a couple of months and have already wrote some commits, closed quite a few issues and filed even more issues on my own. I have access to the Yi repository and I help anyone looking to get started with Yi. I have about 2 years of Haskell experience and had my fair share of staring at library code. As mentioned before, I'm active as a member of the community and help out with one of the core Haskell projects (Haddock). -- Mateusz K.

13 27

Hackage down?
by Iavor Diatchki 17 Mar '14

17 Mar '14

Hello, It looks like Hackage has stopped responding? (2:50pm PDT, 17 March 2014). -Iavor

2 1

projects page
by Ketil Malde 17 Mar '14

17 Mar '14

I tried to follow the link from Google (Melange, http://www.google-melange.com/gsoc/org2/google/gsoc2014/haskell) to the ideas page - but it seems there are only outdated ideas there? Sorry if I wasn't paying attention in class, but how is this intended to work? Is there some other place I should look? -k -- If I haven't seen further, it is by standing in the footprints of giants

2 2

FRP, Simulations and Time (Sodium et. al)
by Sacha Sokoloski 17 Mar '14

17 Mar '14

So I'm also doing a lot of simulations, and have experimented with FRP as a basic toolset for defining my simulations. I experimented with Netwire for a while, and while I still think it's a good library, I eventually threw it away to rely simply on Mealy Arrows (Netwire is Arrow based FRP). From what I've seen, the point of FRP libraries is to handle interactivity. That's what all the functions in the libraries are about. If you do have a virtual time stream that you can simply define at runtime and doesn't require side effects, you may find, as I did, that you'll create a simplified type synonym for the FRP structure that you're working with, and then not really using the libraries at all. The point is ultimately that, although pure simulations could nicely be part of any more complicated FRP program, if all you want is to do pure simulations, then you'll be introducing a fair bit of computational/structural overhead to fit it within the FRP framework, without any real payoff. Cheers, - Sacha On 17/03/14 10:50 AM, haskell-cafe-request(a)haskell.org wrote: > Message: 1 > Date: Sun, 16 Mar 2014 14:23:37 +0100 > From: martin<martin.drautzburg(a)web.de> > To:haskell-cafe@haskell.org > Subject: [Haskell-cafe] FRP, Simulations and Time (Sodium et. al) > Message-ID:<5325A5D9.8070408(a)web.de> > Content-Type: text/plain; charset=ISO-8859-15 > > FPR is usually described as a way to model interactions with the real world. I believe the same ideas should be > applicable to simulations. Instead of "real" events I would use fake events. This however only makes sense when the Time > associated with the Events (and Behaviors) is not wallclock time, but some kind of virtual time. > > I looked briefly into Sodium and found no way to use "my own time". Steven Blackheath even said during a presentation, > that Time in Sodium is just another Behavior. I am not sure if I understood this correctly, but it gives me the feeling, > that the only Time available in Sodium is wallclock time, which would make it unsuitable for simulations. > > Could someone give me some insights whether or not FRP is suitable for simulations? > > Does my reasoning about Time make any sense? Do different libraries treat Time in different ways, such that some are > suitable for simulations, while others are not? > > Martin

2 1

Changes to cabal-install
by Amy de Buitléir 17 Mar '14

17 Mar '14

I have a couple of questions about the latest cabal-install release, and I haven't been able to find the release notes (checked GitHub, the Haskell.org wiki, googled, etc.) Here's what I'm running: amy@wombat$ cabal --version cabal-install version 1.18.0.3 using version 1.18.1.3 of the Cabal library Question 1 ---------- Until recently, the command cabal install --enable-tests used to build and run the tests. Now it seems I need to do cabal test which then compiles the tests and runs them. So is the --enable-tests flag doing anything, or is it now obsolete? Question 2 ---------- With my project, I do, in order: 1. cabal sandbox init --sandbox <directory> 2. cabal install --only-dependencies 3. cabal build --ghc-options=-Werror 4. cabal test But when I do step 3, I get a strange warning message: "The sandbox was created after the package was already configured." Huh? Creating the sandbox was the first thing I did! If instead, I replace step 3 with 3. cabal install --ghc-options=-Werror then I don't get the warning message until step 4.

4 4

Two research positions in functional probabilistic programming
by Tom Nielsen 17 Mar '14

17 Mar '14

Dear Cafe, Two positions involving substantial Haskell work are available for a project that seeks to combine functional and probabilistic programming. We are looking for two postdocs to work on a practical system for large-scale inference in scientific and clinical datasets using bayesian statistical models, embedded in a typed functional programming language and based on stochastic dynamical systems. * A typed hierarchical database that uses a Hindley-Milner-like typesystem (with records) to organise large, complex and heterogeneous data from a hospital. * Probabilistic inference over these complex datasets * Parallelizing Bayesian inference * Modelling clinical datasets (for instance ECG) using dynamical systems. Some of these ideas have been explored in our Baysig Language ( http://tinyurl.com/Baysig) and BayesHive project (https://BayesHive.com) - both Baysig and BayesHive are implemented in Haskell. However, these are academic research posts and there is scope for exploring different designs to meet the same aims. Here are the official adverts: http://ig5.i-grasp.com/fe/tpl_UniversityOfLeicester01.asp?newms=jj&id=85616… http://ig5.i-grasp.com/fe/tpl_UniversityOfLeicester01.asp?newms=jj&id=85615… The application deadline is April 10. If you think you may be interested, you are welcome to ask me (tanielsen(a)gmail.com or tomn(a)openbrain.org) or Tom Matheson (tm75(a)le.ac.uk) any questions. Tom Nielsen OpenBrain Ltd http://openbrain.co.uk

1 0

Want to get paid to hack on Haskell for the summer. GSoC deadline is 21 March
by Johan Tibell 17 Mar '14

17 Mar '14

Hi, If you're a student and want to get paid to write Haskell this summer, it's time to apply for this year's Google Summer of Code. The deadline is 21 March, 19:00 UTC. Here are some project ideas: http://blog.johantibell.com/2014/03/google-summer-of-code-projects.html -- Johan

1 0

Google Summer of Code?
by Chris Wong 17 Mar '14

17 Mar '14

Hello Cafe, I'm currently considering applying for the Summer of Code. Johan Tibell's idea of improving the Hackage login system [1] looks compelling, since I have worked with Happstack before [2]. Is there enough time to start a proposal? I know it's a bit late now -- but I would very much like to participate. Thanks Chris [1] http://blog.johantibell.com/2014/03/google-summer-of-code-projects.html [2] https://github.com/lfairy/sparkle

2 1