>
> Oh: use -dcore-lint. That often nails the error much earlier
>
> Simon
>
> | -Original Message-
> | From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
> Behalf Of
> | David Roundy
> | Sent: 15 April 2009 15:02
> | To: cvs-ghc@haskel
by
darcs developers) that was in ghc 6.6, but doesn't seem to be related.
In that case, the workaround was to avoid using the GADT syntax.
Any suggestions?
--
David Roundy
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
David Roundy <[EMAIL PROTECTED]> added the comment:
I've verified (by pulling 4,918 patches) that this bug is fixed in
darcs-unstable, at least when using hashed repositories.
--
status: chatting -> resolved-in-unstable
__
Darcs bug t
On Mon, Dec 17, 2007 at 02:05:32PM -0800, Stefan O'Rear wrote:
> On Mon, Dec 17, 2007 at 12:23:33PM -0500, David Roundy wrote:
> > In either case, the sanest pure interface that I can imagine would involve
> > *darcs* seeing itself as doing parallel downloads, while the HTTP li
On Mon, Dec 17, 2007 at 04:30:47PM +, Duncan Coutts wrote:
> On Mon, 2007-12-17 at 11:15 -0500, David Roundy wrote:
> > On Mon, Dec 17, 2007 at 10:36:08AM -0500, Tim Chevalier wrote:
> > > I spent a few hours trying to implement this in darcs a few months
> > > ago
On Mon, Dec 17, 2007 at 10:36:08AM -0500, Tim Chevalier wrote:
> On 12/17/07, David Roundy <[EMAIL PROTECTED]> wrote:
> >
> > Any suggestions how to go about doing this? I quick look suggests that
> > libcurl can't handle http pipelining, and that no haskell HTT
On Thu, Dec 13, 2007 at 07:19:02PM -0800, Stefan O'Rear wrote:
> On Thu, Dec 13, 2007 at 07:12:45PM -0800, David Roundy wrote:
> > Still on my todo list (of issues that you've reported):
> >
> > 2. figuring out a nice way to speed up a lazy darcs get. Currently i
On Fri, Dec 14, 2007 at 10:04:57AM +, Simon Marlow wrote:
> David Roundy wrote:
> > Okay, it turns out that it was indeed bad strictness causing the trouble.
> > For some reason, I had made the PatchInfoAnd data type strict in both its
> > components, which meant that
On Thu, Dec 13, 2007 at 07:12:45PM -0800, David Roundy wrote:
> On Thu, Dec 13, 2007 at 09:50:50AM +, Simon Marlow wrote:
> > Simon Marlow wrote:
> > >David Roundy wrote:
> > >>Yikes! That's actually a very surprising bug. I'd be interested in
> >
On Thu, Dec 13, 2007 at 09:50:50AM +, Simon Marlow wrote:
> Simon Marlow wrote:
> >David Roundy wrote:
> >>Yikes! That's actually a very surprising bug. I'd be interested in
> >>hearing if it shows up if you run a darcs2 optimize first? Either way,
&
On Thu, Dec 13, 2007 at 01:36:09PM -0800, Stefan O'Rear wrote:
> On Thu, Dec 13, 2007 at 09:35:52AM +, Simon Marlow wrote:
> > David Roundy wrote:
> >> The difference here is that I haven't implemented the time-stamp
> >> synchronizing feature for hashe
arcs is
just find test cases where the performance lags behind that of older darcs.
Or also cases where it has always been unacceptable, but such problems are
less likely to be quickly fixable. This is all to say, in a week or two,
when you've got a shiny new version of darcs to play with...
us much time for hobbies. Contributions to
the development effort would be very much appreciated!
Incidentally, at this point, darcs development is also provides an
opportunity to play with GADTs and existential type witnesses, as we've
gotten that going in the code. I expect I'll end up
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.
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... althoug
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, be
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
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
David Roundy <[EMAIL PROTECTED]> added the comment:
This is definitely a bug, and I believe it's also been reported before. But
it's a tricky bug to fix (--partial repository bugs generally are). We (well,
*I*, to be honest) never intended for --partial repositories to be used
19 matches
Mail list logo
