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 _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
