The problem is that the old backend assumes it is alone in the
universe and even when not in use will interact with the gpu.  Most
notably in this case it will forcibly destroy any primary context on
exit.  The only problem is that we are also using the primary context
and our cleanup handlers run after those of the old backend.

This is a major problem because cublas uses the runtime api which will
create a context whenever it thinks it needs one (like for cudaFree).
However all the allocations are from the old context that the old
backend destroyed.  So when it tries to clean up its resources the
low-level handlers get confused and we end up in a segmentation fault.

As to why it doesn't always happen, I figure it's because sometimes we
get lucky and addresses line up or something.

Anyway, if we stop the old backend from calling cudaThreadExit() the
segfaults go away.  This may cause a very small leakage of resources
for the few seconds we are running until we exit, but I don't think
this will be a problem.

Buildbot split job

Fix the recommended compiler so that it matches the platform instructructions

remove python2x.py, fix imports associated with it

delete options 'full' and 'economic' in test_qr_modes

Test min version and more recent version of NumPy and SciPy.

Drop support for python 2.6 in CDataType

Fix optimization order and jenkins

Fix error reported

Add a metaclass implementation of __props__ and generalize it to all theano objects

Drop old version

add xunit to jenkins pretest

theano objects.

This will remove problems with inheriting __eq__ or __hash__ that
shadows our own.

Cgt opt

Name dilated convolution to help people find it with that name.

Correctly check which sync to call, in case both back-end are availab…

Changed courses URL

_name_for_ctx do not iter for loop enough

_name_for_ctx do not iter for loop enough
raise identation error fixed

http://www.mila.umontreal.ca/Home/courses moved.