David Roundy <[EMAIL PROTECTED]> writes:
> On Tue, Dec 26, 2006 at 03:35:26PM +0100, Benedikt Schmidt wrote:
>> David Roundy <[EMAIL PROTECTED]> writes:
>> > [...] For one thing, it'd be nice to make a WriteableDirectory monad
>> > for modifying Populations, so that we can use the same apply function
>> > on Populations as we do on Slurpies, lists of FilePaths and IO. It'd
>> > require a bit of an extension to the WriteableDirectory monad so that
>> > we'd not lose the patch name information, but a little function in the
>> > class (with null default) such as
>> >
>> > withNamedPatch :: PatchInfo -> m a -> m a
>> > withNamedPatch _ f = f
>> >
>> > which in the PopulationMonad would cause these changes to be annotated with
>> > the relevant patch id. If we made this change, it might also come in handy
>> > for other purposes. For example, when applying in the IO monad, we could
>> > automatically add to error messages a note indicating which patch failed,
>> > which would unify our error messages a bit, so that we wouldn't need to
>> > have quite so many cases where we catch errors in applying a patch just so
>> > we can add extra information about which patch was being applied.
>> >
>> > It could also be helpful if we ever were to develop a "pre-annotated"
>> > pristine cache.
>>
>> I'm working on a filecache (FilePath -> [PatchId] mapping) to speed up
>> annotate file and changes file. You can lookup if a patch touches
>> a certain file without traversing all the patches. Then you only have
>> to parse and apply the subset of patches that change the file for the
>> annotation info.
>>
>> I'm using
>> StateT [FileMod] m a
>> applied to Slurpy to find out which files are touched by a certain patch.
>> I didn't add anything to the WritableDirectory monad and call
>>
>> apply_to_slurpy_cache :: Bool -> Patch -> Slurpy -> IO ([FileMod], Slurpy)
>>
>> for each patch file instead.
>
> Hmmm. It seems to me like it could be done more cleanely with a
> modification to apply and WritableDirectory. But I suspect that your code
> could relatively easily be refactored in that direction if we thought it
> advisable, wouldn't you think?
Yes, that would be nicer. I'll take another look to see if i can use this
approach with monad transformers. I had some problems with creating
withFoo :: String -> m a -> m a
methods when using monad transformers, since I didn't find a way
to reuse the method from the inner monad.
A simple lift doesn't work here since you need
withFoo :: String -> StateT s m a -> StateT s m a
and only have withFoo :: String -> m a -> m a .
> Just out of curiosity, what is the slurpy needed for? Is it just to do the
> two things at once, or do you actually need it for updating the cache?
The base State layer is just responsible for keeping track of which
files are modified, e.g.
instance WriteableDirectory m => WriteableDirectory (CacheMonad m) where
mRemoveFile fn = do appendFn (RemoveFile fn)
lift $ mRemoveFile fn
the ReadableDirectory instance uses the inner monad (slurpy in this case)
to keep track of renames, file contents, etc which are used by apply.
instance ReadableDirectory m => ReadableDirectory (CacheMonad m) where
mDoesDirectoryExist = lift . mDoesDirectoryExist
>> For now, i added a optimize --filecache option to create the filecache and
>> read the filecache for annotate and changes. I'm using a Map String () for
>> now that uses the patchid as key and is used for checking if a certain
>> patch has to be applied. I don't use Population any more for the the single
>> file case if there is a filecache, but it's still used for annotate
>> directory.
>
> I'd like to see this (once working and not proof-of-concept) done in the
> Repository module, so that it is automatically kept up-to-date. Then we'd
> also want a RepoProperty to indicate that we have this cache, and optimize
> --filecache could update the _darcs/format file so that future changes will
> keep it in sync. Using the RepoFormat machinery (rather than just checking
> if the directory exists) will keep older versions of darcs from modifying a
> repository that has the cache (although they'll be able to read from it
> fine).
Sounds fine, updating the cache on apply shouldn't take much time.
>> There is some proof of concept code at http://beschmi.de/darcs-filecache/
>> and it really seems to make big difference for big repos. I hope to work
>> some more on it until and at the hackathon.
>
> I'm not sure when I'll have time to look at this, but look forward to
> checking it out!
I can send another mail when i've cleaned up the code a bit, this version
was mainly an exercise in how fast can i get something to compile to do
some timing to see if it's worth it.
Benedikt
_______________________________________________
darcs-devel mailing list
darcs-devel@darcs.net
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
