1. 13 Jul, 2021 1 commit
  2. 12 Jul, 2021 1 commit
  3. 10 Jul, 2021 1 commit
  4. 05 Jul, 2021 2 commits
  5. 24 Jun, 2021 1 commit
  6. 05 Jun, 2021 1 commit
  7. 27 May, 2021 1 commit
  8. 23 May, 2021 6 commits
  9. 07 May, 2021 1 commit
  10. 06 May, 2021 1 commit
  11. 03 May, 2021 1 commit
  12. 02 May, 2021 2 commits
  13. 15 Apr, 2021 2 commits
  14. 14 Apr, 2021 3 commits
  15. 09 Apr, 2021 1 commit
  16. 15 Mar, 2021 2 commits
  17. 13 Mar, 2021 2 commits
  18. 24 Feb, 2021 1 commit
  19. 07 Feb, 2021 1 commit
  20. 29 Jan, 2021 2 commits
  21. 10 Jan, 2021 1 commit
  22. 02 Jan, 2021 1 commit
  23. 23 Dec, 2020 2 commits
  24. 13 Dec, 2020 3 commits
    • Pino Toscano's avatar
      b599b4b8
    • Pino Toscano's avatar
      scripting: PyEval_CallObject -> PyObject_CallObject · 7f13da34
      Pino Toscano authored
      It turns out the PyEval_* APIs has always been publically exposed but
      undocumented; because of this, they were deprecated in Python 3.9.
      
      Switch PyEval_CallObject to PyObject_CallObject, which has been
      available for a very long time (even in Python 2.7).
      7f13da34
    • Pino Toscano's avatar
      scripting: fix Python initialization · 62e2c9b9
      Pino Toscano authored
      Apparently with Python 3.9 Py_Initialize() is needed even before
      creating PyObject's, i.e. what the default constructor of
      boost::python:dict does by calling PyDict_New().
      
      Hence, move the insertion of the 'kig' module followed by
      Py_Initialize() in the constructor of a separate helper class: this
      class will be a private base for PythonScripter::Private, which thus can
      properly initialize boost::python objects.
      62e2c9b9