[darcs-devel] Re: darcs patch: Make annotate work on files with spaces in the name
Edwin Thomson <[EMAIL PROTECTED]> writes: > Fixes Issue 65 ( http://bugs.darcs.net/issue65 ) There is another patch for the whitespace issue in http://www.mail-archive.com/darcs-devel@darcs.net/msg02071.html I didn't get around to test it some more with > fn2ps_no_escape (FN fp) = packWords $ map (toEnum.fromEnum) fp instead of > fn2ps_no_escape (FN fp) = packWords $ encode fp but i'll try to do some tests with your patch and the other one over the weekend. Benedikt ___ darcs-devel mailing list darcs-devel@darcs.net http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
[darcs-devel] Re: darcs patch: Make annotate work on files with spaces in the name
David Roundy <[EMAIL PROTECTED]> writes: > On the other hand, this is among the oldest code in darcs that wasn't > written by myself (and therefore that I'm less likely to have cleaned up, > since it's not quite in my style), and could certainly do with some work to > make it more similar to the rest of the code. 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. This info is stored in _darcs/filecache/ as Touch RenamedTo RenamedFrom (RenamedFrom for backwards reading). 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. 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. Benedikt ___ darcs-devel mailing list darcs-devel@darcs.net http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
[darcs-devel] Re: darcs patch: Make annotate work on files with spaces in the name
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
[darcs-devel] Re: darcs patch: Make annotate work on files with spaces in the name
Benedikt Schmidt wrote: David Roundy <[EMAIL PROTECTED]> writes: On Tue, Dec 26, 2006 at 03:35:26PM +0100, Benedikt Schmidt wrote: 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. I look forward to this in eager anticipation... it's about 3rd on my darcs wishlist. The lack of this optimisation is why we can't offer access to GHC's repository via darcsweb, for example - every page view causes darcs to think for minutes. Also I can't fully integrate GHC's darcs repository into our Trac. I made a feature requst for this a while ago, in case you haven't seen it: http://bugs.darcs.net/issue124 Cheers, Simon ___ darcs-devel mailing list darcs-devel@darcs.net http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
Re: [darcs-devel] Re: darcs patch: Make annotate work on files with spaces in the name
I'm waiting for your conclusions before applying either patch. Juliusz ___ darcs-devel mailing list darcs-devel@darcs.net http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
Re: [darcs-devel] Re: darcs patch: Make annotate work on files with spaces in the name
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? 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? > This info is stored in _darcs/filecache/ as > > Touch > RenamedTo > RenamedFrom > > (RenamedFrom for backwards reading). Sounds reasonable. > 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). > 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! -- David Roundy http://www.darcs.net ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] Re: darcs patch: Make annotate work on files with spaces in the name
On Tue, Dec 26, 2006 at 04:50:17PM +0100, Benedikt Schmidt wrote: > David Roundy <[EMAIL PROTECTED]> writes: > > 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 . Hmmm. I must admit that I'm pretty ignorant regarding monad transformers... > > 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 I suspect that you can do without the inner monad. You might take a look at the FilePathMonad. This involves a Readable/WriteableDirectory monad that doesn't store most of the information, and works fine. Actually, apply pretty exclusively uses the WriteableDirectory functions, so stubs for the ReadableDirectory routines are pretty harmless (there is one mDoesDirectoryExist, used for setpref... but if you always return false, you're safe). It may be that we should modify the interface to remove some of these unused functions, although I'd hate to do that, as it'd make the interface less generally useful. Still, if the policy is that some functions don't need to be properly implemented, then it would probably be a good idea simply to remove those functions... And incidentally, I am now engaged to my girlfriend, Monica! :) :) :) -- David Roundy http://www.darcs.net ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] Re: darcs patch: Make annotate work on files with spaces in the name
On Wed, Dec 27, 2006 at 05:33:15AM -0800, David Roundy wrote: > And incidentally, I am now engaged to my girlfriend, Monica! :) :) :) Congratulations! -- Tommy Pettersson <[EMAIL PROTECTED]> ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
Re: [darcs-devel] Re: darcs patch: Make annotate work on files with spaces in the name
On Sun, Dec 31, 2006 at 07:27:36PM +0100, Tommy Pettersson wrote: > On Wed, Dec 27, 2006 at 05:33:15AM -0800, David Roundy wrote: > > And incidentally, I am now engaged to my girlfriend, Monica! :) :) :) > > Congratulations! Thanks! David (on the first day of class, with woefully little preparation...) ___ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
