Python 3.x compatibility

Hi can someone "please" help me out here and tell me when we will have "Python 3.x" compatibility in Python-Ogre? I already sent an email to Andy. But she hasn't replied to me as yet. Guys please help me out here, I have a team about to hang up development in waiting for the python 3.x compatibility to come out. Please let me know ASAP thanks.

viewtopic.php?f=3&t=14194
might help

Already seen it dude That's why I sent Andy a message, but she hasn't replied X|

I've put a BETA release of the core Ogre modules (including OIS) up on source forge for testing with Python 3.2 - check it out here

There hasn't been any testing (expect to run a couple of the demos) so please report any issues you have as a bug report on source forge.

The SVN has NOT been updated (yet) to allow general building of a Python 3 version as I need to do significant clean up and resync - plus get patches into the Py++ project...

Regards
Andy

I've put a BETA release of the core Ogre modules (including OIS) up on source forge for testing with Python 3.2 - check it out here

There hasn't been any testing (expect to run a couple of the demos) so please report any issues you have as a bug report on source forge.

The SVN has NOT been updated (yet) to allow general building of a Python 3 version as I need to do significant clean up and resync - plus get patches into the Py++ project...

Regards
Andy
Good job, I haven't tried your beta version for Windows but did attempt to update to python3 on Linux but ran into problems with constant segfaults with the core Ogre modules.
I'm looking forward to look at the changes you made when you have updated svn / py++.

Out of curiosity, what will be the expected benefits of running with Python 3.x?

The SVN has NOT been updated (yet) to allow general building of a Python 3 version as I need to do significant clean up and resync - plus get patches into the Py++ project...

Regards
Andy

When are the changes (python-ogre/py++) for Python 3 likely to be updated on svn?

Created a new branch as don't want to break any 2.x work -- look in branches/Python-3.x

Andy

Created a new branch as don't want to break any 2.x work -- look in branches/Python-3.x

Andy
Thanks I'll take a look some time later today.

Also some py++ changes in ./pyplusplus that need to be used..

What versions of pygccxml \ pyplusplus are you using? Last time I looked both svn versions wouldn't build against python3 without a number of modifications.

Does ./pyplusplus contain all the necessary updates?

I spent 'much' time on getting py++ to work natively with Python 3.x and have it to the point where it all seems to work but the generated code is wrong There is also the issue that scones also doesn't (or didn't) support Python 3.x...

Hence the process for building Python-Ogre for 3.x is to use Python 2.x to generate and compile the code (using the code_repository updates for Py++ from the Python-Ogre branch)... I did have to hard code the python version in the build scripts (need to make this a switch) which is one if the reasons this is currently not in the trunk..

Andy

I spent 'much' time on getting py++ to work natively with Python 3.x and have it to the point where it all seems to work but the generated code is wrong There is also the issue that scones also doesn't (or didn't) support Python 3.x...

Hence the process for building Python-Ogre for 3.x is to use Python 2.x to generate and compile the code (using the code_repository updates for Py++ from the Python-Ogre branch)... I did have to hard code the python version in the build scripts (need to make this a switch) which is one if the reasons this is currently not in the trunk..

Andy
Ok, I'll try the approach you mentioned.

@Andy, sorry I didn't have time to try this out I will this weekend.

I've made the updates (pretty minor) for Ogre 1.8 modules, there is still an issue with the demos closing down properly. If you want me to upload the changes to sourceforge or wait until nearer the Ogre 1.8 release let me know.

By all means update the SVN.....

Thanks
Andy

Will do. I will try and resolve the segfault problems on demo shutdown/close - problem occurs on deleting the ScriptCompilerManager (OgreScriptCompiler dtor); no problems on C++.

There are also some changes to variable names which mean libraries using Ogre Singleton may have to be patched, so it may take a bit longer.

https://bitbucket.org/sinbad/ogre/chang ... ingleton.h

Andy, I did try a build of the OIS module for Python 3.x using Python 2.x to generate and compile the code but ran into a number of issues:

1) Problems with logger , what module is this?

from .logger import *
from .logger import (log_info, log_warning)
..
I had to update the generate_code.py and common_utils/*.py:
from logging import *
from logging import info as log_info
from logging import warning as log_warning
..

There were also some issues with log/string format output.

2) The build fails during compile with indexing_suite PyInt_FromLong / PySliceObject errors. These were the updates I made last time I attempted tried with Python3 (to at least make it build):

Index: indexing_suite/slice_handler.hpp
===================================================================
--- indexing_suite/slice_handler.hpp (revision 1856)
+++ indexing_suite/slice_handler.hpp (working copy)
@@ -31,6 +31,11 @@
#include <indexing_suite/slice.hpp>
#include <indexing_suite/python_iterator.hpp>

+#if PY_MAJOR_VERSION >= 3
+#define PyInt_FromLong(x) PyLong_FromLong(x)
+#endif
+
+
namespace boost { namespace python { namespace indexing {
template<class Algorithms, class Policy>
struct slice_handler
Index: indexing_suite/slice.hpp
===================================================================
--- indexing_suite/slice.hpp (revision 1856)
+++ indexing_suite/slice.hpp (working copy)
@@ -76,7 +76,11 @@
: m_slice (sl) // Leave index members uninitialized
{
PySlice_GetIndices(
+#if PY_MAJOR_VERSION >= 3
+ m_slice.ptr(),
+#else
reinterpret_cast<PySliceObject *> (m_slice.ptr()),
+#endif
length,
&m_start,
&m_stop,



3) stdint.h is back

The OIS module imports (but it also did last time I tried). I don't really want to continue until I'm sure I'm not doing something fundamentally wrong.

2) The build fails during compile with indexing_suite PyInt_FromLong / PySliceObject errors. These were the updates I made last time I attempted tried with Python3 (to at least make it build):

Index: indexing_suite/slice_handler.hpp
===================================================================
--- indexing_suite/slice_handler.hpp (revision 1856)
+++ indexing_suite/slice_handler.hpp (working copy)
@@ -31,6 +31,11 @@
#include <indexing_suite/slice.hpp>
#include <indexing_suite/python_iterator.hpp>

+#if PY_MAJOR_VERSION >= 3
+#define PyInt_FromLong(x) PyLong_FromLong(x)
+#endif
+
+
namespace boost { namespace python { namespace indexing {
template<class Algorithms, class Policy>
struct slice_handler
Index: indexing_suite/slice.hpp
===================================================================
--- indexing_suite/slice.hpp (revision 1856)
+++ indexing_suite/slice.hpp (working copy)
@@ -76,7 +76,11 @@
: m_slice (sl) // Leave index members uninitialized
{
PySlice_GetIndices(
+#if PY_MAJOR_VERSION >= 3
+ m_slice.ptr(),
+#else
reinterpret_cast<PySliceObject *> (m_slice.ptr()),
+#endif
length,
&m_start,
&m_stop,



My bad. I see that you have made all these changes in the pyplussplus dir. I applied your changes and built pyplussplus, then pointed my pyplusplus path to to the build directory but nothing had changed.

Installing pyplussplus resolved the problem, sorry for the noise.

Ok I fudged the logging/message formats from previous versions of python-ogre and updated to Ogre1.8. The main Ogre modules build and run, so good job with your updates. There is still issues with closing down the demos related to 1.8.

The compile time for the ogre module is increasing, coupled with the fact that any time an Ogre header is updated a complete rebuild is required.

I tried a couple of tests regarding batching the source files and the results for small modules as ois were good (90 seconds to compile/link). Also batching the really small files from the ogre module appeared to be compile faster but conversely the others were much slower and used significantly more RAM. Do you have any suggestions/ideas on how to reduce compile times?

Edit:
OK I wrote a simple script to batch the source files into chunks of 150KB , compile and link ( classes such as Vector3 in their own batch).

There were 80 source batches, no optimisation of headers etc. and compile time on a single core was 90 minutes, linking took only a minute. This was in comparison to 4-5 hours it normally takes to build on dual core machine. The module imported and ran OK.

Of course not very useful when it comes to rebuilds but it shows that it may be beneficial to introduce some form of batching the source files via py++(?) or a similar method in scons to that of Ogre's Unity build.

By all means update the SVN.....

Thanks
Andy
https://sourceforge.net/tracker/?group_ ... tid=916690

Still problem with shutting down demo properly on Linux. Feel free to use which parts you deem appropriate. It may save you some time when you get start your net round of updates.
<edit> The above is for python-ogre trunk </edit>