[darcs-users] soc progress 4

Petr Rockai me at mornfall.net
Thu Jun 18 06:32:22 UTC 2009


trentbuck at gmail.com (Trent W. Buck) writes:

[snip cpufreq bits]

Yep. I normally use cpufrequtils, which hide the gory details (without
introducing unpredictable automation). I just made the mistake of letting some
powermanagement daemon fiddle with settings (I think powerdevil is the
name). It's really my fault for being stupid, anyway.

>>   * Make lcs an optional dependency (use -fdiff to get the Diff
>>   module).
>
> Thanks!  What are the implications of *not* using lcs?  Do you take a
> performance hit, or what?  (Presumably there's a reason it's an optional
> dependency rather than being removed altogether.)

No performance hit. The option disables the Storage.Hashed.Diff module
altogether. Currently, darcs is not using this module at all (it has own
internal diffing mechanism based on hunk canonisation, which I use in
Darcs.Gorsvet -- see treeDiff). However, I am reluctant to drop the module
altogether, since eventually, I'd like to replace running external diff tool
with an internal haskell implementation of unidiff. Storage.Hashed.Diff
implements the most basic form of unidiff for now, and I intend to expand it to
cover the interesting bits of GNU diff. This would allow "darcs diff" to run
with same efficiency as darcs whatsnew. Currently, it has to make one or two
copies of the pristine tree and invoke external program (which is slow).

>>   * Use mmap instead of bytestring-mmap in readSegment (in Utils).
>>   * Cut down build-depends (no longer need bytestring-mmap nor binary).
>
> Thanks!
>
>> ... and darcs-hs:
>>
>>   * Use the mmap package instead of bytestring-mmap.
>
> Petr/Eric, can we get this into the 2.3 release?

Yes, that's the intention. Actually, I think Eric has already applied the patch
to mainline. There are still two days before freeze hits, so I'll try to get in
a last batch of changes this week. After that, all bets are off. :)

> Current Darcs head depends on hashed-storage, and hashed-storage (now)
> depends on mmap, but not bytestring-mmap.  Therefore, getting this
> change into 2.3 will mean that EVERYONE gets mmap support, rather than
> only those people who have BOTH mmap and bytestring-mmap installed.

> I guess since Darcs has an indirect mmap dependency (via
> hashed-storage), it might as well be made a required (not optional)
> dependency.  That reduces the dimensions of compile-time options by one,
> which means less to go wrong.  Yay!

I guess so. Admittedly, it's not so much of a win to use mmap with darcs, but I
guess it does help a little.

Yours,
   Petr.

-- 
Petr Ročkai | http://web.mornfall.net
A physicist is an atom's way of knowing about atoms. (George Wald)


More information about the darcs-users mailing list