yade-dev team mailing list archive

[noreply@xxxxxxxxxxxxx]

------------------------------------------------------------
revno: 2835
committer: Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>
branch nick: trunk
timestamp: Wed 2011-04-27 14:37:04 +0200
message:
  A section on devpt tools and check tests in programmer manual.
modified:
  doc/sphinx/prog.rst


--
lp:yade
https://code.launchpad.net/~yade-dev/yade/trunk

Your team Yade developers is subscribed to branch lp:yade.
To unsubscribe from this branch go to https://code.launchpad.net/~yade-dev/yade/trunk/+edit-subscription

=== modified file 'doc/sphinx/prog.rst'
--- doc/sphinx/prog.rst	2011-04-15 06:20:10 +0000
+++ doc/sphinx/prog.rst	2011-04-27 12:37:04 +0000
@@ -201,6 +201,38 @@
 
 See scons manpage for meaning of parameters passed to build functions, such as ``SHLIBPREFIX``.
 
+Development tools
+=================
+
+Integrated Development Environment and other tools
+---------------------------------------------------
+A frequently used IDE is Kdevelop. We recommend using this software for navigating in the sources, compiling and debugging. Other usefull tools for debugging and profiling are Valgrind and KCachegrind. A series a wiki pages are dedicated to these tools in the `development section <https://yade-dem.org/wiki/Yade#Development>`__ of the wiki.
+
+Hosting and versioning
+----------------------
+The Yade project is kindly hosted at `launchpad <https://launchpad.net/yade/>`__, which is used for source code, bug tracking, planning, package downloads and more. Our repository `can be http-browsed <http://bazaar.launchpad.net/~vcs-imports/yade/trunk/files>`__.
+
+The versioning software used is `Bazaar <http://www.bazaar-vcs.org>`__, for wich a short tutorial can be found in a `Yade's wiki pages <https://yade-dem.org/wiki/Quick_Bazaar_tutorial>`__. Bazaar is a distributed revision control system. It is available packaged for all major linux distributions.
+
+Build robot
+-----------
+A build robot hosted at `3SR lab. <http://www.3s-r.hmg.inpg.fr/3sr/?lang=en>`__ is tracking souce code changes.
+Each time a change in the source code is commited to the main development branch via bazaar. The "buildbot" downloads and compiles the new version, and start a series of tests.
+
+If a compilation error has been introduced, it will be notified to the yade-dev mailing list and to the commiter, thus helping to fix problems quickly.
+If the compilation is successfull, the buildbot starts unit regression tests and "check tests" (see below) and report the results. If all tests are passed, a new version of the documentation is generated and uploaded to the website in `html <https://www.yade-dem.org/doc/>`__ and `pdf <https://yade-dem.org/doc/Yade.pdf>`__ format. As a consequence, those two links always point to the documentation (the one you are reading now) of the last successfull build, and the delay between commits and documentation updates are very short (minutes).
+The buildbot activity and logs can be `browsed online <https://yade-dem.org/buildbot/>`__.
+
+Check tests
+-----------
+Check tests perform comparisons of simulation results between different versions of yade, as discussed in http://www.mail-archive.com/yade-dev@xxxxxxxxxxxxxxxxxxx/msg05784.html and the whole thread. They differ with regression tests in the sense that they simulate more complex situations and combinations of different engines, and usually don't have a mathematical proof (though there is no restriction on the latest). They compare the values obtained in version N with values obtained in a previous version or any other "expected" results. The reference values must be hardcoded in the script itself or in data files provided with the script. Check tests are based on regular yade scripts, so that users can easily commit their own scripts to trunk in order to get some automatized testing after commits from other developers.
+
+Since the check tests history will be mostly based on standard output generated by "yade --checks", a meaningfull checkTest should include some "print" command telling if something went wrong. If the script itself fails for some reason and can't generate an output, the log will contain "scriptName failure". If the script defines differences on obtained and awaited data, it should print some useful information about the problem and increase the value of global variable resultStatus. After this occurs, the automatic test will stop the execution with error message.
+
+An example check test can be found in checkTestTriax.py. It shows results comparison, output, and how to define the path to data files using "checksPath".
+Users are encouraged to add their own scripts into the scripts/test/checks/ folder. Discussion of some specific checktests design in users question is welcome.
+A check test should never need more than a few seconds to run. If your typical script needs more, try and reduce the number of element or the number of steps.
+
 Conventions
 ============
 
@@ -267,7 +299,6 @@
 
 .. [#opengldispatchers] Not considering OpenGL dispatchers, which might be replaced by regular virtual functions in the future.
 
-
 Documentation
 ---------------