apso-devel
[Top][All Lists]
Advanced

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

Re: [Apso-devel] Logging system and defensive code (for Apso 0.3.0)


From: Jeronimo Pellegrini
Subject: Re: [Apso-devel] Logging system and defensive code (for Apso 0.3.0)
Date: Sat, 7 Apr 2007 06:09:27 -0300
User-agent: Mutt/1.5.13 (2006-08-11)

Hi Caio.

You forgot to reply to the list. :-)

On Sat, Apr 07, 2007 at 02:40:06AM -0300, Caio Marcelo wrote:
> On 4/6/07, Jeronimo Pellegrini <address@hidden> wrote:
> >  http://vislab-ccom.unh.edu/~schwehr/software/slogcxx/
> >  The reason for choosing it is the same behind the coice of Nettle:
> >  simplicity and ease of use.
> 
> You're thinking in embedding this dependency our tree or ask for
> a separate installation? In this case I prefer the former if the lib
> isn't too large...

It's small... But why not keep it separate?
If we keep too many things inside the Apso tree, we'd add complexity
to project administration -- and if we add other logging engines (or
switch to a different one) in the future, we'd have to drop an entire
subtree and create another. Maybe we could do something like:

. install nettle
. install monotone
. install slogcxx

Then compile Apso.
Installing the three packages should be easy (either with RPM/dpkg, or
with the old configure-make-make_install method), and that would already
include the header files for slogcxx and nettle.

One idea would be to not require a specific logging mechanism (or crypto
library, etc), so both these would work:

======
. install nettle
. install monotone
. install slogcxx
======

======
. install botan
. install mercurial
. install acme-logging-engine
======

But if you think there are reasons to keep the logging stuff in our
tree, please tell us.

> >- A test framework. Caio is also working on that. BTW, Caio, could you
> >  say more about your ideas for tests?
> 
> Actually right now I'm just moving the test stuff from src/ to tests/
> and trying to
> make everything work with less input, so I can do a basic functional
> test without
> thinking ;-), incrementally this could cover more and more scenarios.

That's nice!

> In parallel (and I think, for 0.3.0 or before), unit tests would be
> very helpful, too.
> Are you familiar with some simple way to do these?

I don't know a lot about testing. I do know that monotone uses Lua to
automate tests, but that doesn't mean it's the best approach for us.

Ideas:

- C++ unit tests.  We can use the boost test framework, as it's easy
  to use. But although this is good for testinf C++ functions, classes,
  etc, it's cumbersome for testing high-level functionality involving
  lots of directories, files, passing command line parameters, etc.

- Scripting. Maybe Lua or Python would be interesting? Or some other
  language/tool? It would be nice if we could add more tests easily,
  like:
  + Write a description of the test (*)
  + Add the test name to a list of testa
  + Call "run tests" and all tests are performed.


(*) A description of the test would include the "pre-test" state of the
    world, like the directories and files that should exist prior to
    the test; the "post-test" requirements (directory X should be
    created, file A should be deleted, file B should contain A's 
    content encrypted, etc)

What do you think?

J.





reply via email to

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