[darcs-devel] [issue2338] fix darcs dependencies with regards to Haskell Platform at time of release
ganesh at earth.li
Tue Aug 20 05:43:18 UTC 2013
The hashable dependency is fine, it's just having a dependency that
clashes with the Haskell Platform version that's problematic.
In general I would like for us to use well-maintained external code
(i.e. hashable) instead of our own internal code, but it obviously does
depend on the specifics of the situation.
If hashPS actually does perform better then we should feed that back to
the maintainers of hashable.
Do you have an easily reproducible benchmark that shows the difference
in speed on your machine and Guillaume's? If not, could you provide one?
Might be useful to gather a wider sample.
On 20/08/2013 01:02, José Neder wrote:
> There is not an specific need for hashable 1.2. It should work
> perfectly with any version since 1.0.0. But there is not a specific
> need even for hashable at all, in my test it runs better than the
> implementation of hashPS in Darcs.Util.ByteString, so this is why i
> added it, but is cumbersome to add a dependency, hashPS could be used
> instead of Data.Hashable.hash and avoid this dependency.
> I saw that Guillaume get another results in his machine(in his machine
> hashPS performs better), so maybe is better to use hashPS? i assume it
> depends heavily on the cpu in which it runs.
> 2013/8/19 Ganesh Sittampalam <bugs at darcs.net>:
>> Ganesh Sittampalam <ganesh at earth.li> added the comment:
>> For the containers dependency, patience diff is using Data.Map.Strict
>> from containers 0.5. I have a patch ready to go that embeds the source
>> for that module+dependencies inside darcs, under the namespace
>> Darcs.Data.Map.Strict (etc), and is used conditionally if we are
>> building with containers 0.4.
>> Please shout if you think this is too horrible to contemplate!
>> Darcs bug tracker <bugs at darcs.net>
>> darcs-devel mailing list
>> darcs-devel at darcs.net
More information about the darcs-devel