I've had a strange bug that's baffled me for a long time. I finally
got serious about tracking it down, and managed to reduce it to a
small program that exhibits the unexpected behaviour, namely that a
createProcess seems to block writing to and closing a socket.
Here's the example program:
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/04/13 21:50, Johan Tibell wrote:
On Tue, Apr 9, 2013 at 12:40 PM, Joe Nash joen...@blackvine.co.uk
wrote:
I would be interested in discussing this project with a potential
mentor if one happens to be reading. I'm a second year Computer
Quoth Evan Laforge qdun...@gmail.com,
sleep = Process.createProcess (Process.proc sleep [5])
sleep = Process.createProcess
((Process.proc sleep [5]) {Process.close_fds = True})
- Because the client uses buffered I/O (hGetContents in this case, but
hGet-anything would be the same), it
Hi,
I'm interested in participating in the GSoC by improving GHC with one of
these two features:
1) Implement native support for compiling modules in parallel (see
#910http://hackage.haskell.org/trac/ghc/ticket/910).
This will involve making the compilation pipeline thread-safe, implementing
the
Hi,
I think the first proposal may be a bit too much for a GSoC, depending on
how much you actually are familiar with the code base. If you can write
down everything that needs to be done, in a detailed way (I mean a *lot* of
details), for each of these steps, and if you sincerely consider all of
Hi,
I've been working on this problem for some time and I was hoping for some
feedback. I'm trying to implement an embedded language that can thread a
global structure through the evaluation of a term.
A mini version of this language only includes three functions, lam, app and
ext (lambda, apply
Hey Patrick,
both are excellent ideas for work that would be really valuable for the
community!
(independent of whether or not they can be made into GSOC sided chunks )
---
I'm actually hoping to invest some time this summer investigating improving
the numerics optimization story in ghc. This
Hello,
I'm interested in doing some improvments on the Yi editor for my Google
summer of code by implementing a completion pop up list for any buffer and a
smart completion for haskell.
But I don't really know if this kind of project could be acceptable, for the
following reason:
1) Should a
Hello all, (cc'd stream fusion paper authors)
I noticed that the current implementation of stream fusion does
not support multiple-return stream combinators, e.g.
break :: (a - Bool) - [a] - ([a], [a]). I thought a little
bit about how might one go about implement this, but the problem
seems
On 22/04/2013, at 11:07 , Edward Z. Yang ezy...@mit.edu wrote:
Hello all, (cc'd stream fusion paper authors)
I noticed that the current implementation of stream fusion does
not support multiple-return stream combinators, e.g.
break :: (a - Bool) - [a] - ([a], [a]). I thought a little
bit
I've got a solution for this problem and it will form the basis of
Repa 4, which I'm hoping to finish a paper about for the upcoming
Haskell Symposium.
Sounds great! You should forward me a preprint when you have something
in presentable shape. I suppose before then, I should look at
On 22/04/2013, at 12:23 , Edward Z. Yang ezy...@mit.edu wrote:
I've got a solution for this problem and it will form the basis of
Repa 4, which I'm hoping to finish a paper about for the upcoming
Haskell Symposium.
Sounds great! You should forward me a preprint when you have something
in
GHC for the most part is already thread-safe. There are a few data
structures that persist between module compilations, but they're mostly
just caches that're already modified in an atomic fashion. Interleaving
updates to these caches shouldn't cause any problems as long as the updates
are done
Good points. I did not take into account whether proposal #2 may be worth
it in light of -fllvm. I suppose that even if the LLVM codegen is able to
perform similar optimizations, it would still be beneficial to implement
proposal #2 as a core-to-core pass because the transformations it performs
14 matches
Mail list logo