yade-dev team mailing list archive

[noreply@xxxxxxxxxxxxx]

------------------------------------------------------------
revno: 2404
committer: Václav Šmilauer <eudoxos@xxxxxxxx>
branch nick: trunk
timestamp: Tue 2010-08-17 08:54:26 +0200
message:
  1. Adjust docs for changes in the last commit
  2. Add version requirement for python-sphinx to debian/control-template (Anton: that's the reason why the build fails in maverick; I uploaded 1.0~hg... into yade-users/external so it should build fine in a few hours; there is no use uploading 0.6 which is in maverick already)
modified:
  debian/control-template
  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 'debian/control-template'
--- debian/control-template	2010-08-15 04:19:57 +0000
+++ debian/control-template	2010-08-17 06:54:26 +0000
@@ -2,7 +2,7 @@
 Section: x11
 Priority: optional
 Maintainer: Václav Šmilauer <eudoxos@xxxxxxxx>
-Build-Depends: debhelper (>= 5), scons, freeglut3-dev, libboost-dev (>=1.35), libboost-date-time-dev (>=1.35), libboost-filesystem-dev (>=1.35), libboost-thread-dev (>=1.35), libboost-regex-dev (>=1.35), libboost-python-dev (>=1.35), libboost-iostreams-dev (>=1.35), libboost-program-options-dev, libboost-serialization-dev, libloki-dev, liblog4cxx9-dev | liblog4cxx10-dev, docbook-to-man, ipython, libgts-dev, python-numpy, g++(>>4.0), libvtk5-dev, libgl1-mesa-dev, gdb, ipython, python-matplotlib, python-tk, libeigen2-dev, libqglviewer-qt4-dev @', binutils-gold' if DISTRIBUTION not in ('hardy','intrepid','jaunty','lenny') else ''@ @', texlive-latex-recommended, texlive-latex-extra, lmodern, texlive-pictures, texlive-xetex, python-sphinx, python-bibtex, graphviz, dvipng' if DISTRIBUTION not in ('hardy','intrepid','jaunty','lenny') else ''@, python-xlib, python-qt4, pyqt4-dev-tools
+Build-Depends: debhelper (>= 5), scons, freeglut3-dev, libboost-dev (>=1.35), libboost-date-time-dev (>=1.35), libboost-filesystem-dev (>=1.35), libboost-thread-dev (>=1.35), libboost-regex-dev (>=1.35), libboost-python-dev (>=1.35), libboost-iostreams-dev (>=1.35), libboost-program-options-dev, libboost-serialization-dev, libloki-dev, liblog4cxx9-dev | liblog4cxx10-dev, docbook-to-man, ipython, libgts-dev, python-numpy, g++(>>4.0), libvtk5-dev, libgl1-mesa-dev, gdb, ipython, python-matplotlib, python-tk, libeigen2-dev, libqglviewer-qt4-dev @', binutils-gold' if DISTRIBUTION not in ('hardy','intrepid','jaunty','lenny') else ''@ @', texlive-latex-recommended, texlive-latex-extra, lmodern, texlive-pictures, texlive-xetex, python-sphinx (>=1.0~hg20100604), python-bibtex, graphviz, dvipng' if DISTRIBUTION not in ('hardy','intrepid','jaunty','lenny') else ''@, python-xlib, python-qt4, pyqt4-dev-tools
 Standards-Version: 3.7.2
 
 Package: yade@_VERSION@

=== modified file 'doc/sphinx/prog.rst'
--- doc/sphinx/prog.rst	2010-08-15 17:21:04 +0000
+++ doc/sphinx/prog.rst	2010-08-17 06:54:26 +0000
@@ -1697,27 +1697,27 @@
 ^^^^^^
 The :yref:`Omega` class handles all simulation-related functionality: loading/saving, running, pausing. 
 
-In python, the wrapper class to the singleton is instantiated [#oinst]_ as global variable ``O``. Because there is no separate ``Scene`` class in python, :yref:`Omega` is used to access its contents from python. Although multiple ``Scene`` objects may be instantiated in c++, it is always the current scene that :yref:`Omega` represents.
+In python, the wrapper class to the singleton is instantiated [#oinst]_ as global variable ``O``. For convenience, :yref:`Omega` is used as proxy for scene's attribute: although multiple ``Scene`` objects may be instantiated in c++, it is always the current scene that :yref:`Omega` represents.
 
 The correspondence of data is literal: :yref:`Omega.materials` corresponds to ``Scene::materials`` of the current scene; likewise for :yref:`materials<Omega.materials>`, :yref:`bodies<Omega.bodies>`, :yref:`interactions<Omega.interactions>`, :yref:`tags<Omega.tags>`, :yref:`cell<Omega.cell>`, :yref:`engines<Omega.engines>`, :yref:`initializers<Omega.initializers>`, :yref:`miscParams<Omega.miscParams>`.
 
-Some variables do not correspond literally, for historical reasons (which should be fixed):
+To give an overview of (some) variables:
 
 ======================== ===================================
 Python                   c++
 ======================== ===================================
-:yref:`Omega.iter`       ``Scene::currentIteration``
+:yref:`Omega.iter`       ``Scene::iter``
 :yref:`Omega.dt`         ``Scene::dt``
-:yref:`Omega.time`       ``Scene::simulationTime``
-:yref:`Omega.realtime`   ``Omega::getComputationTime()``
-:yref:`Omega.stopAtIter` ``Scene::stopAtIteration``
+:yref:`Omega.time`       ``Scene::time``
+:yref:`Omega.realtime`   ``Omega::getRealTime()``
+:yref:`Omega.stopAtIter` ``Scene::stopAtIter``
 ======================== ===================================
 
 ``Omega`` in c++ contains pointer to the current scene (``Omega::scene``, retrieved by ``Omega::instance().getScene()``). Using :yref:`Omega.switchScene`, it is possible to swap this pointer with ``Omega::sceneAnother``, a completely independent simulation. This can be useful for example (and this motivated this functionality) if while constructing simulation, another simulation has to be run to dynamically generate (i.e. by running simulation) packing of spheres. 
 
 .. rubric:: Footnotes
 
-.. [#oinst] It is understood that instantiating ``Omega()`` in python only instantiated the wrapper class, not the singleton itself.
+.. [#oinst] It is understood that instantiating ``Omega()`` in python only instantiates the wrapper class, not the singleton itself.
 
 Engine loop
 ------------