[darcs-users] darcs patch: switch Darcs.Patch.FileName to be ByteString.Char8 int...
dagit at codersbase.com
Fri Oct 2 20:08:34 UTC 2009
On Fri, Oct 2, 2009 at 10:24 AM, Ian Lynagh <igloo at earth.li> wrote:
> On Fri, Oct 02, 2009 at 02:12:26PM +0200, Benjamin Franksen wrote:
> > cd linux-188.8.131.52
> > darcs initialize
> > darcs record -lam 'imported linux-184.108.40.206'
> > darcs: out of memory (requested 1048576 bytes)
> > I have 4GB of RAM. GHCRTS is not set in the environment.
> FWIW, this is a regression:
I don't know if it's in the bug tracker, but I've noticed it too. Thanks
for providing numbers.
> $ darcs --version
> 1.0.9rc1 (release candidate 1)
> $ time darcs record -lam 'imported linux-220.127.116.11' +RTS -sstderr
> 39 Mb total memory in use
Only 39Mb? That's less than the compressed patch, so I find it hard to
believe. Darcs 2.3.1 is taking around 500 megs of physical ram for me just
to abort before recording (eg., echo q | darcs record ... ). I guess I
should get a copy of 1.0.9 on my machine for doing comparisons with.
Ian, do you happen to know what version of ghc was used to compile your
I can't find it in roundup, but there is at least one bug where darcs had a
short cut for this use case but later the patch is prohibitively expensive
to work with. I don't know if that is the case with 1.0.9. It would
certainly be interested if you could actually do useful things with the
patch you have recorded (such as commute other patches with it). The fix
that I recall described in the bug report was to disable the special case
for record all so that users wouldn't end up with patches they can't work
If someone with better roundup-fu can find that bug report and teach me how
to search roundup effectively I would be appreciative. (it's frustrating
when you know the bug report exists but you can't find it...)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the darcs-users