+++ Gwern Branwen [Apr 13 09 20:13 ]:
> On Mon, Apr 13, 2009 at 1:05 PM, Eric Kow <[email protected]> wrote:
>> On Mon, Apr 13, 2009 at 12:40:32 -0400, Gwern Branwen wrote:
>>> Yes, that looks like the compression bug. The easy diagnosis is
>>> whether 'curl' fails and 'curl --compressed' succeeds.
>>
>> I can confirm with this diagnosis as well.
>>
>>> Supposedly, it's fixed in happstack-server darcs:
>>> http://groups.google.com.gi/group/HAppS/browse_thread/thread/419a012cdc60cd47
>>>
>>> But as I comment in a gitit-devel thread, I rebuilt from darcs
>>> everything, and the compressed issue didn't seem to go away.
>>
>> Another issue we have is performance. Loading http://test.darcs.net
>> seems to take about 15s wall time for me. Ian has helped us to figure
>> out what's going on and after some silly ps-usage on my part, we've
>> worked out that one thing it seems to be doing is
>>
>> darcs changes --xml-output --summary FrontPage.page
>>
>> which took 3 seconds wall time on test.darcs.net
>>
>> I suppose this is something that will be helped with the new filecache
>> feature that Benedikt's been working on. But otherwise, why is it
>> doing that? Is it possible to have an overview of what happens
>> darcs-wise when we call up a page in gitit?
>
> The key code is Darcs.hs in filestore. If you look, only two commands call
> --xml-output --summary, darcsLatestRevId and another; as it happens, all
> calls to those 2 in Gitit.hs couldn't possibly be the result of just viewing
> Front Page.page.
> But viewing Front Page.page does call 'retrieve', alias for 'darcsRetrieve' -
> and it calls it without a version ID (with Nothing). The definition of
> darcsRetrieve says:
>
> darcsRetrieve repo name Nothing =
> darcsLatestRevId repo name >>= darcsRetrieve repo name . Just
>
> Oops. So a patch looks like this:
>
> hunk ./Data/FileStore/Darcs.hs 259
> -darcsRetrieve repo name Nothing =
> - darcsLatestRevId repo name >>= darcsRetrieve repo name . Just
> +darcsRetrieve repo name Nothing = do (status, err, output) <-
> runDarcsCommand repo "query" ["contents", name]
> + if status == ExitSuccess
> + then return $ fromByteString output
> + else throwIO $ UnknownError $ "Error
> in darcs query contents:\n" ++ err
>
> This should work as far as efficiency & avoiding calling darcs changes go;
> however, it breaks an invariant in filestore! The tests believe that calling
> 'retrieve' on a directory should be an error; but 'darcs query contents' on a
> directory quietly returns successfully with the empty string.
You can restore that invariant by inserting the line
ensureFileExists repo name
before the runDarcsCommand call.
Note, however, that your change won't suffice by itself, because
filestore's "latest" function also gets called in formattedPage (which
needs to know the latest revision in order to determine whether it
can use a cached version) The way darcsLatestRevId works currently is
horribly inefficient. It calls
darcs changes --xml-output --summary [filename]
parses the whole thing, and returns the head of the list. Is there a
command that returns just the last change made that affects the given
file? I tried adding "--last=1", but that seems to count back in the
global patch stack, not in the patches affecting [filename].
In git we can just do
git rev-list --max-count=1 HEAD -- [filename]
which is very fast. I'm sure there's something comparable in darcs?
> I would test this in my local gitit installation, but HEAD gitit seems to be
> borked: even if I use the default.conf straight from gitit/data in a empty
> directory, it crashes on me (even --help crashes!) with the error message:
>
> gitit: (NoOption "default-page-type","get (DEFAULT/default-page-type)")
I just cloned a fresh copy from github, did 'cabal install', and then
'gitit', and it worked perfectly. Can you try that? I'm thinking maybe
you have an extra Paths_gitit.hs lying around or something. It looks
as if gitit is not finding the data file default.conf, which should be
installed as a data file (in ~/.cabal/share/gitit-0.6.1/data -- you
might check to make sure it's there).
John
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
