Re: How does the IO manager handle reading regular files?

Also funny but perhaps not too surprising: If in my code, you replace `forkIO` by e.g. `forkOn 2`, then nondeterministically, sometimes the program hangs and sometimes it works with +RTS -N2. The higher you set -N, the more likely it is to work. If you put both the putStrLn loop and the

Re: How does the IO manager handle reading regular files?

Niklas Hambüchen writes: ... > > So GHC is trying to use `O_NONBLOCK` on regular files, which cannot > work and will block when used through unsafe foreign calls like that. > Yikes! > Is this a known problem? > Doesn't sound familiar to me. Sounds like a ticket is in order. Thanks

Re: How does the IO manager handle reading regular files?

Hey Ben, thanks for your quick reply. I think there's a problem. On 14/05/2018 15.36, Ben Gamari wrote: > I believe the relevant implementation is the RawIO instance defined in > GHC.IO.FD. The read implementation in particular is > GHC.IO.FD.readRawBufferPtr. There is a useful Note directly

Re: Plan for GHC 8.6.1

Even aside from committee feedback easily being weeks away for such a complex proposal, I’m also concerned about how the current proposed design changes to core seem a bit fragile with linear types. Perhaps I’m misunderstanding some of the current planned details , but I’m fairly confident that

Re: Plan for GHC 8.6.1

Matthew Pickering writes: > Perhaps Nested CPR will be ready :) ? https://phabricator.haskell.org/D4244 > > I am also working on the linear types branch. Arnaud is quite keen for > it to be ready for 8.6 but we still have a bit to go. > I'll admit that I'm a bit

Re: How does the IO manager handle reading regular files?

Niklas Hambüchen writes: > I just got reminded that epoll() has no effect on regular files on > Linux by reading an nginx article [1] [2] and why that is [3] [4]. > > By what means does the IO manager make reads (wraps around the read() > syscall on Linux) non-blocking? > > Does it

RE: HIE Files

Interesting. Please do keep the wiki page up to date so that it accurately describes the current design. For example, I hope you’ll flesh out what a “simplified, source aware, annotated AST derived from the Renamed/Typechecked Source” really is. Why not put the .hie-file info into the .hi

HIE Files

Hello, I will be working on a GSOC project that will allow GHC to output a new .hie file to be written next to .hi files. It will contain information about the typechecked Haskell AST, allowing tooling(like haddocks --hyperlinked-source and haskell-ide-engine) to work without having to parse,