Re: [glob2-devel] USL return Patch & Unit Testing Framework

[Leo Wandersleb]

Hi Brian

Numbeast . wrote:
> After a very brief conversation with giszmo3 I decided I would try
> tackling adding unit testing to Glob2.
Brave :)
> I started with libusl but quickly ran into a problem, USL provides no
> method of receiving the return value of a script. The value is dumped
> to cout but not saved for later. In order to test for the proper
> execution of scripts, it would be nice to know that a script returns
> (what the result of executing the last line is). I therefore made this
> small (2 additional lines) patch for intrepreter.cpp and intrepreter.h
> so that after USL step()s through a thread until it's state is
> state:STOP it saves the return value. After asking on irc i was told
> that this would be a good place to ask for this small diff to be
> committed (the diff is attached).
The following is made up by me from how I see distributed version
control system (dvcs):
mercurial is a DVCS. maybe you want to pack your version to some public
hoster like http://bitbucket.org
if you pick bitbucket, you can fork my account's glob2 at
http://bitbucket.org/giszmo/glob2/fork/
Forking formerly often smelled like "I'm not satisfied with the project.
I fork it thus splitting the community". In a DVCS context, this is
merely only branching as technically there is no main repository. They
are all the same. "fork" at bitbucket only means, you want to get a
repository under your control that has the history of the other project
so they don't need to host double the data.
This way you don't need to ask for write access to hg.globulation2.org.
You simply run your own repo. Once those in control of
hg.globulation2.org's repo think it is a good idea to import your
changes, they pull them into their repo. if they disappear, maybe debian
decides to compile from your version. whatever happens, distributed is
more stable and gives the control needed to everyone who wants to.
> On another subject, after a little thought I decided to use Boost:Test
> as the testing framework. Your wiki says you don't want any extra
> dependencies but in your mailing lists there have been a few comments
> to the effect of if something makes programming simpler you'll accept
> it, and I believe using Boost:Test is much easier and faster than
> implementing your own library. You probably allready have it installed
> considering you use Boost:Thread. Any feedback on this choice would be
> greatly appreciated.
As there is not much testing yet, please deal with the one test that
already is in and remove dependencies if it had introduced any and
replace them with Boost:Test.

Regards and thanx

Leo