[darcs-devel] darcs patch

[Ian Lynagh]

On Wed, Dec 01, 2004 at 05:16:34AM -0500, David Roundy wrote:
> Ian, thanks for all the work.  Have you run tests to see how much the speed
> or memory usage has improved?

It's certainly improved both overall on the cases I was testing with.
If you have any examples where things get worse I'll have a look at
them.

> It did look like there were a some places,
> especially the execPS changes where your changes would increase the memory
> usage.  I presume these are insignificant?

How exactly do you mean?

The renderPSWith shouldn't result in the PS being copied as it ends up
with concatPS [ps] which is just ps.

Or do you mean the laziness between the pipes was being useful?
Hmm, if that's the case we might want
    execPSToStringPipe >>= execPipe >>= execPipe >>= execStringToPS
or something.

> > [CVS GHC fixes
> > Ian Lynagh <igloo at earth.li>**20041130132940] {
> > hunk ./Diff.lhs 21
> > -import Posix ( setFileTimes, epochTime )
> > +#if __GLASGOW_HASKELL__ < 603
> > +import Posix
> > +#else
> > +import System.Posix
> > +#endif
> > +             ( setFileTimes, epochTime )
> 
> I don't care for this change, since it'll leave the build broken with a
> recent ghc on windows, where System.Posix isn't available.  We have our
> hokey win32/Posix.hs workaround, which is incomptatible with this change.
> :( What we really should do is write a wrapper around the System.Posix
> functions we need, which should perhaps abstract away a bit of their
> behavior.
> 
> Or is does 603 mean ghc 6.3?

It does. Does that make a difference?

> > hunk ./Lock.lhs 156
> > +#if __GLASGOW_HASKELL__ < 603
> > hunk ./Lock.lhs 158
> > +#else
> > +                          h <- openFd fd Nothing False fname
> > +                                      ReadWriteMode True False
> > +#endif
> 
> This change suggests that my configure test failed to work as it ought,
> since Lock.lhs imports Workaround.openFd, which ought to have the same type
> regardless of which ghc we're compiling with... I think...

Ah, it probably means I changed autoconf.mk by hand rather than running
configure with a suitable argument - sorry  :-)

> > [Turn off profiling -auto-all for SHA1 as it makes it  stack overflow
> > Ian Lynagh <igloo at earth.li>**20041130173526] {
> > hunk ./autoconf.mk.in 49
> > +SHA1.o : SHA1.lhs
> > +	$(GHC) $(CPPFLAGS) $(GHCFLAGS) -no-auto-all -c $<
> > +
> > }
> 
> Can we do this as an inline pragma in SHA1.lhs itself? I think I would
> prefer that way of doing things.  That way the property of needing this
> flag is localized in the file itself, which just seems right.

Unfortunately -no-auto-all is a static flag, so it can't be set in an
OPTIONS pragma. I don't know if there's a good reason for this.


Thanks
Ian