Hi Everyone, All of the patches that add PyBind support have received reviews from Jason (thanks!), so they are technically ready to be submitted. However, since this is a large change, I would like to give everyone a chance to test it or add reviews before I submit it. I plan to let the change brew until Tuesday next week. Unless I hear otherwise, I'll hit the shiny blue button in Gerrit before 5pm UK time.
I have also posted some cleanup patches that remove the remaining traces of SWIG from the code base. These remove the remaining SWIG support from scons, Python, and some ifdefs from the c++ code. These all live in the pybind11/cleanups[1] topic. Thanks, Andreas [1] https://gem5-review.googlesource.com/#/q/topic:pybind11/cleanups On 31/03/2017 14:45, Jason Lowe-Power wrote:
Hi Andreas, I think it's OK for us to ignore the warnings. It isn't like SWIG didn't dump out 1000s of warnings before. I'll take a close look at the patch next Wed. or Thurs. Sorry for the delay. Jason On Wed, Mar 29, 2017 at 6:08 AM Andreas Sandberg <andreas.sandb...@arm.com> wrote:Hi Everyone, Some time ago, I posted a series of changes [1] to switch from SWIG to PyBind for our Python wrappers. I'd like to know what people think about this move at a high level. Do we want to make this change? These are the main benefits I have identified: * PyBind11 can be redistributed with gem5, which means that we have full control of the version used. This avoid a large number of hard-to-debug SWIG issues we have seen in the past. * PyBind11 doesn't rely on a custom C++ parser, instead it relies on wrappers being explicitly declared in C++. The leads to slightly more boiler-plate code in manually created wrappers, but doesn't doesn't increase the overall code size. A big benefit is that this avoids strange compilation errors when SWIG doesn't understand modern language features. * Unlike SWIG, there is no risk that the wrapper code incorporates incorrect type casts (this has happened on numerous occasions in the past) since these will result in compile-time errors. * It fixes a compiler error we have been experiencing with some some SWIG versions when compiled using clang 3.8. * It becomes easier to export new methods to Python. In the simplest case, a place holder method can be declared in Python and decorated with @cxxMethod, which inherits the doc string from the place holder. The new wrappers have the following known issues: * Global events can't be memory managed correctly. This was the case in SWIG as well. * GCC 5.x seems to generate C++ ODR warnings in some cases when compiling the fast binary. See Pierre's comment on [2]. * It changes the way custom methods are exported to Python (the export_methods class method is disappearing), which breaks the current API. Do we consider the ODR warnings to be serious enough to block this if we think the change is a good idea? I have been trying to reproduce them using PyBind's test suite, but without success so far. Cheers, Andreas [1] https://gem5-review.googlesource.com/#/q/topic:pybind11+(status:open+OR+status:merged) [2] https://gem5-review.googlesource.com/#/c/2231/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev_______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
