[issue560] Getting source code

Alexander Staubo <[EMAIL PROTECTED]> added the comment: On 11/24/07, Juliusz Chroboczek <[EMAIL PROTECTED]> wrote: > > | darcs: getCurrentDirectory: resource exhausted (Too many open files) > > > This sounds like a Darcs bug, but it's not one I have heard before. > > I've definitely seen this iss

[issue560] Getting source code

David Roundy <[EMAIL PROTECTED]> added the comment: On Sat, Nov 24, 2007 at 05:07:29PM +0100, Juliusz Chroboczek wrote: > > | darcs: getCurrentDirectory: resource exhausted (Too many open files) > > > This sounds like a Darcs bug, but it's not one I have heard before. > > I've definitely seen t

[issue560] Getting source code

Juliusz Chroboczek <[EMAIL PROTECTED]> added the comment: > | darcs: getCurrentDirectory: resource exhausted (Too many open files) > This sounds like a Darcs bug, but it's not one I have heard before. I've definitely seen this issue, but I don't remember how it ended. I seem to recall that it's

[issue560] Getting source code

David Roundy <[EMAIL PROTECTED]> added the comment: On Fri, Nov 09, 2007 at 04:06:21PM -, David Roundy wrote: > Of course, it could be that this is just the bug that you already fixed in > the lazy reading code, in which case we could perhaps close this > ticket... although improving the erro

[issue560] Getting source code

David Roundy <[EMAIL PROTECTED]> added the comment: On Fri, Nov 09, 2007 at 03:52:21PM -, Eric Kow wrote: > Is there any chance at all that Simon M's strict readFile would be > helpful here, adapted to FastPackedString? Or are they irrelevant > here, for example, because we are already doing

[issue560] Getting source code

Eric Kow <[EMAIL PROTECTED]> added the comment: Is there any chance at all that Simon M's strict readFile would be helpful here, adapted to FastPackedString? Or are they irrelevant here, for example, because we are already doing something like it? http://www.haskell.org//pipermail/haskell/attac

[issue560] Getting source code

David Roundy <[EMAIL PROTECTED]> added the comment: On Fri, Nov 09, 2007 at 03:31:09AM -, Richard Giraud wrote: > Given how easy it is to increase the limit, I'm guessing that the limit is a > way of detecting and stopping runaway processes. If this is the case, then I > don't consider thi

[issue560] Getting source code

Richard Giraud <[EMAIL PROTECTED]> added the comment: Given how easy it is to increase the limit, I'm guessing that the limit is a way of detecting and stopping runaway processes. If this is the case, then I don't consider this a bug; OS X is doing what it should and darcs is doing what it sh

[issue560] Getting source code

Richard Giraud <[EMAIL PROTECTED]> added the comment: Added script from running 1.1.0pre1. __ Darcs bug tracker <[EMAIL PROTECTED]> __Script started on Thu Nov 8 19:50:55 2007 neptune:~/Documents/wo

[issue560] Getting source code

Richard Giraud <[EMAIL PROTECTED]> added the comment: Added script from running 1.0.9. __ Darcs bug tracker <[EMAIL PROTECTED]> __Script started on Thu Nov 8 19:48:26 2007 neptune:~/Documents/worksp

[issue560] Getting source code

Richard Giraud <[EMAIL PROTECTED]> added the comment: I compiled darcs 1.0.9 and 1.1.0pre1 with the --disable-mmap and the result is still the same. __ Darcs bug tracker <[EMAIL PROTECTED]> __

[issue560] Getting source code

David Roundy <[EMAIL PROTECTED]> added the comment: On Thu, Nov 08, 2007 at 07:44:15PM -, Richard Giraud wrote: > After doing some investigation, this appears to the be result of OS X > limiting > the number of files that a process can have open. Increasing this limit > makes > the issue

[issue560] Getting source code

Richard Giraud <[EMAIL PROTECTED]> added the comment: After doing some investigation, this appears to the be result of OS X limiting the number of files that a process can have open. Increasing this limit makes the issue disappear. By default, user accounts are limited to 256 open files (per