monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Testsuite status (SoC)


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Re: Testsuite status (SoC)
Date: Thu, 13 Jul 2006 17:27:44 -0500

On Thu, 2006-07-13 at 01:43 -0700, Nathaniel Smith wrote:
> On Wed, Jul 12, 2006 at 01:09:19AM -0500, Timothy Brownawell wrote:
> > The new testsuite seems to be "done" now, but some things aren't optimal
> > yet. In particular I'd like to make tester fairly independent from the
> > rest of monotone by factoring out sanity.{cc,hh} and dependencies into a
> > libsanity or similar, and by making tester (and libsanity) not depend on
> > paths.{cc,hh} or the vocab* files (or constants.{cc,hh}).
> > 
> > So far it looks like sanity and dependencies make very minimal use of
> > these files, so this shouldn't be (much of) a problem. I'll post again
> > when I have a better idea of exactly how much would need to be changed.
> 
> I can't really tell how important these refactorings are from your
> description, but that's okay, because I trust your taste.  I do want
> to just double-check that you're not doing more work in this
> particular direction than you otherwise would, just because it's what
> you wrote up for SoC -- IIUC, last year some of your time ended up
> being used less effectively than it might have, because the project
> you were worked on was superceded by the unfolding roster design
> plans, but you kept on to make sure you fulfilled the SoC
> requirements.  So, just re-emphasizing that if you feel like calling
> the testsuite good enough and starting working on per-file DAGs or
> building a better automate or whatever else, cool; and if not (or not
> yet), cool too.

The reason behind the refactorings is that tester seems like it could be
a very useful project on its own. But, if it's all tangled up with the
rest of the monotone sources, having it be independent becomes a bit of
a pain.

So far I have sanity dependencies reduced to ui, quick_alloc, platform,
simplestring_xform, constants, and numeric_vocab. constants is only used
for default_encoding by split_into_lines, and for log_line_sz in
sanity.cc.

The lua extensions still depend on paths, transforms, and vocab.

Changes to get this are:
        * add a platform_wrapped.hh, so the platform-specific functions can
take strings instead of paths. Should be ok, since they don't do path
operations on them.
        * sanity::filename becomes a string instead of a system_path
        * display_width moves from charset to ui, and now takes a string.
Almost every place it was used, it was called as
display_width(utf8(whatever)). I'm considering instead to make sanity
not depend on ui, in which case this can be put back. (this particular
change may be slightly questionable)
        * ui.redirect_log_to now takes a string instead of a system_path. This
can also be put back if I make sanity not depend on ui.

What I have so far is attached as a diff, and is available on
nvm.tbrownaw.tester-spinoff .

Tim

Attachment: diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]