Whenever possible, unit tests should omit this parameter. Leaving-out the mode will ensure that unit tests use the default mode (defined in compile.mode.default_mode). This default_mode is set to the THEANO_DEFAULT_MODE environment variable, if it is present. If not, it defaults to 'FAST_RUN'.
Whenever possible, unit tests should omit this parameter. Leaving-out the mode will ensure that unit tests use the default mode (defined in compile.mode.default_mode). This default_mode is set to the THEANO_DEFAULT_MODE environment variable, if it is present. If not, it defaults to 'FAST_RUN'.
This allows the user to easily switch the mode in which unittests are run. For example the nightly-build system could iterates over all modes.
This allows the user to easily switch the mode in which unittests are run. For example to run all tests in all modes from a BASH script, type this:
>>> THEANO_DEFAULT_MODE=FAST_COMPILE nosetests
.. code-block:: bash
>>> THEANO_DEFAULT_MODE=FAST_RUN nosetests
>>> THEANO_DEFAULT_MODE=DEBUG_MODE nosetests
We don't do this as the debug mode generate the same error or more then the two previous one.
@@ -42,7 +42,11 @@ As a developer, you should clone this repository like this:
...
@@ -42,7 +42,11 @@ As a developer, you should clone this repository like this:
Nightly test
Nightly test
============
============
Each night we execute all tests. The result is sent by email to one of the develloper and if it their is some change, he forward it to the mailing list. Otherwise we know that nothing changed from the last time it was emailed. He don't read its email each weekend, so their can be some delay. For more detail :ref:`see <metadocumentation_nightly_build>`.
Each night we execute all the unit tests automatically.
The result is sent by email to one of the developers, who (at his discretion) forwards it to the mailing list.
Said developer may not read his email obsessively (especially on the weekend)
so there might be some latency in the process.
For more detail :ref:`see <metadocumentation_nightly_build>`.
@@ -100,18 +100,35 @@ You can see a list of all `pylint messages
...
@@ -100,18 +100,35 @@ You can see a list of all `pylint messages
.. _metadocumentation_nightly_build:
.. _metadocumentation_nightly_build:
The nightly build process.
The nightly build/tests process
---------------------------------------
---------------------------------------
The user lisa have a cronjob on the computer boltzmann. The cronjob execute the script ~/nightly_build/do_nightly_build_theano. This script make a an "hg pull -u" of theano and pylearn. Then it execute
The user ``lisa`` runs a cronjob on the computer ``boltzmann``.
This happens nightly.
The cronjob executes the script ``~/nightly_build/do_nightly_build_theano``.
This script performs a an "hg pull -u" of theano (and pylearn too).
We can't email directly to the mailing list as it is emailed as the root user. We didn't found a way to have google groups accept email from a user without sending an email to it. As we don't have root control from this domain, we won't receive the email.
in the updated ``theano`` directory.
The output is emailed automatically to one of the developers.
This line is executed with a several fixed ``SEED`` values, and in both
DEBUG_MODE and FAST_RUN modes.
Also, to have the crontab executed, the user must be logged onto the machine. The develloper that receive the email, keep a connection open to this machine.
We can't email directly to the mailing list as it is emailed as the root user.
We haven't yet found a way to have google groups accept email from a user without sending an email to it.
As we don't have root control from this domain, we won't receive the email.
We haven't pursued the option of configuring the ``lisa`` account to send
email from an official gmail account.
Also, to have the crontab executed, *the ``lisa`` user must be logged onto the machine*.
In a nutshell: Fred keeps a shell open on boltzmann at all times, gets the
email, and forwards it to the mailing list when something interesting shows up