August 2015 - Haskell-Cafe

Darcs Hacking Sprint #9 (September 18th-20th, Paris)
by Guillaume Hoffmann 15 Sep '15

15 Sep '15

Dear Hackers the next Darcs Sprint that will be in Paris, on September 18-20 at IRILL (near Place d'Italie). Please check out the details at: http://darcs.net/Sprints/2015-09 Here are three things to know 1. Everybody is welcome to join us. We'd love to have you, whatever your Haskell or Darcs hacking experience. Also, if you've got a wacky idea for the future of version control, or a cool use for the Darcs library, you should join us too :-) 2. Please let us know if you're attending. Just add your name to http://wiki.darcs.net/Sprints/2015-09 and you're good to go. You can also send us an email. 3. We can reimburse travel costs (within reason!). Let us know if you'd like a reimbursement, and save your receipts. Many thanks to everybody who participated in our fundraising drives or who gave money on the side. Thanks also to the Software Freedom Conservancy for making fundraising and reimbursements so painless! If you can't join us in person, but you'd like to cheer us on, say hello at http://darcs.net/Donations ! see you in one month! Guillaume

1 1

ANNOUNCE: ioctl 0.0.1
by Maciej Piechotka 13 Sep '15

13 Sep '15

A package for type-safe I/O control. Currently only ioctl is supported. Currently simply a extract from my tuntap fork TODO: - Return the integer as well as structure (will break the API) - Port for Windows Network.Socket.IOCtl (as soon as I manage to setup some sane environment on this platform) - Wrapping around DeviceIoControl Example (in hsc): data NotRead = NotRead instance NotRead Int where ioctlReq _ = #const FIONREAD notRead s = ioctlsocket' s NotRead Regards

2 1

"Assignment" in do blocks?
by Anupam Jain 08 Sep '15

08 Sep '15

Hi all, I'd like to propose an inbuilt "assignment" operator for use within do-blocks. Here's a common pattern - do foo <- someaction do something with foo -- Here we "update" the value of foo let foo' = bar foo -- The code from this point onwards shouldn't use foo -- but there is no way to enforce that What I'd like to do instead is something like - let foo = bar foo But to Haskell this is a recursive definition instead of an update to the previous value. I can do this instead - foo <- return $ bar foo which works fine but (I assume) GHC currently can't optimise it for arbitrary monads. Also it won't necessarily work if the monad laws don't hold. It would be nice to have an "assignment arrow", say (<-=), which lets GHC optimise this, so - foo <-= bar foo ... desugars to something like - foo' (bar foo) where foo' foo = ... -- Anupam

7 11

How to combine simulations
by martin 01 Sep '15

01 Sep '15

Hello all, I've been trying hard to come up with an idea how to build a DES from smaller parts. So far, I came to the conclusion, that somewhere there must be an operation which takes an Event and maybe emits an Event (and appends to a log and updates some state). Those Events whould come from and go to the "environment" the simulation runs in. My mental model is two billiard tables, which are connected through a hole in the cushion and which each have a player. When I look at one such table, it would have to respond to Events from its player and from the other table and it would send events to its player ("all balls at rest") and to the other table. If I add the other table and the two players then the combined simulation would not emit any events at all and it would not respond to any events except maybe as START event. It would only depend on its initial state. But if I add only the player, but not the other table, it would still send events to the other table and respond to events from that other table. My problem is the type of Events. I could create a type which encompasses all possible events, but that violates the idea of composablitly. Somehow I would need to be able to take a system which accepts "player events" and "other table events", compose it with an other table and end up with a system which only accepts "player events" but no more "other table events" and similarly for the emitted events. And I don't quite know how to do this. Hope this makes some sense. Any pointers (which go beyond "aivika has a simulation component") would also be much appreciated.

2 1

Backing up ghc version, just for one sandbox?
by David Banas 31 Aug '15

31 Aug '15

Hi all, Is it possible to back up the ghc version, just for a single sandbox? Thanks, -db

1 0

Compiling non-registered packages into a sandbox?
by David Banas 31 Aug '15

31 Aug '15

Hi all, How do I compile a non-Hackage registered package into a local sandbox? Let’s say I have: /proj_dir/ - .cabal-sandbox/ - cabal.sandbox.config - dep_pkg/ - dep_pkg.cabal - Setup.lhs - … I’d like to compile the dep_pkg package into my proj_dir sandbox; can I do this, if dep_pkg is NOT registered with Hackage? If so, how? Thanks, -db

2 1

New Functional Programming Job Opportunities
by Functional Jobs 31 Aug '15

31 Aug '15

Here are some functional programming job opportunities that were posted recently: Full Stack Haskell Software Engineer at Linkqlo Inc http://functionaljobs.com/jobs/8859-full-stack-haskell-software-engineer-at… Cheers, Sean Murphy FunctionalJobs.com

1 0

Thread-safe GHC
by Corentin Dupont 31 Aug '15

31 Aug '15

Hello, I am wondering if GHC itself is thread-safe. I am using Hint, and it reports that GHC is not thread-safe, and that I can't safely run two instances of the interpreter simultaneously. Is that still the case? Thanks! Corentin ---------- Forwarded message ---------- From: Daniel Gorín <jcpetruzza(a)gmail.com> Date: Thu, Aug 27, 2015 at 5:09 PM Subject: Re: Thread-safe Hint To: Corentin Dupont <corentin.dupont(a)gmail.com> Hi Corentin, sorry for the late reply. Until relatively recently, the problem was still on. But I too remember seeing something related to this issue being fixed (iirc, the problem was the runtime linker, which used global state), so perhaps it is already fixed in 7.10. If you can verify this, it shouldn’t be hard to show the error message only on old versions of ghc. I’ll be away for a couple of weeks, but if you want to look into this and send a patch, I’ll merge it when I return. Cheers, Daniel > On 24 Aug 2015, at 10:43 am, Corentin Dupont <corentin.dupont(a)gmail.com> wrote: > > Hello Daniel, > I noticed the following message in Hint: > This version of GHC is not thread-safe,can't safely run two instances of the interpreter simultaneously. > > Is it still the case with recent versions of GHC? > It would be neat to be able to launch several instances of the interpreter. In my game Nomyx I have several "match-up" going on and having one instance of the interpreter would be nicer. Otherwise I am obliged to reset the interpret each time I want to interpret something, which is time consuming (2-3 seconds). > > Thanks, > C

1 0

Re: [Haskell-cafe] Discussion: The CLOEXEC problem
by Donn Cave 31 Aug '15

31 Aug '15

Quoth David Turner <dave.c.turner(a)gmail.com>, > Could you be a bit more specific? Which bits of pre-existing software > didn't have a FD_CLOEXEC bit and would be broken by this proposal? Well, of course to be precise, the bit's always there, it's just normally not set - that's the normal environment that anything written up to now would expect. And of course, anything that depends on a GHC-opened file to stay open over an exec would be broken. I can't enumerate the software that meets that criterion. > Since Python recently decided to go through this exact transition, their > experience should be instructive. Do you know if there was negative fallout > from PEP 0466? I gave up on Python a long time ago and don't follow what goes on. If recently means less than a decade or so, though, it's not much to go on. If the problem addressed by the O_CLOEXEC proposal is obscure, the problems it may create are even more so - I'll certainly concede that - and it could take a lot of experience before those problems would be well known enough to show up if you went looking for them. > When thinking about FDs from outside the Haskell runtime (whether inherited > or simply opened in an external library), can you give an example of a case > where such a FD causes a problem if inherited and yet cannot be set as > FD_CLOEXEC at source? Sorry, I'm confused here. Files opened within GHC and externally have equal potential to work as intended or to cause problems, it seems to me. If we infer from the proposal that GHC-opened files with CLOEXEC unset may cause a problem, then it follows that other files with CLOEXEC unset also may cause the same problem. The proposal addresses only the former, and not the latter, and only for normal files - while the ordinary solution, as implemented in UNIX popen(3), deals with all - pipes, sockets, etc. Donn

6 10

Idiomatic way to parse bytecodes
by Gautier DI FOLCO 31 Aug '15

31 Aug '15

Hello all, I have some bytecodes to parse and I look for the most idiomatic way to do it. It's mostly JVM Bytecode, long story short, I have some embedded JVM Bytecodes: * one part is specification-defined, from 0x00 to 0xB8, differ from the regular JVM Bytecode * and the other part is proprietary and changes often I have two main goals: * print the signification of each bytecodes (a more explicit one than the hexadecimal value of the bytecode) * Do some analysis on it, spot patterns, apply markov model on it and so on. The issue with JVM Bytecode in general is that each bytecode hasn't been made equal. Some of them requires parameters, some of them modify the length of the next bytecode, etc. I'm not looking for a way to parse bytecode quickly, or for a library doing it for me. I look for a simple/composable/idiomatic way to do it. So if you have any thoughts, papers, articles or even code snippets (part of a library of not) that is done in the Haskell-way, please, share it :) Thanks in advance for your help.

4 4