1. 23 Dec, 2017 1 commit
    • Jason Rhinelander's avatar
      Silence new MSVC C++17 deprecation warnings · 3be401f2
      Jason Rhinelander authored
      In the latest MSVC in C++17 mode including Eigen causes warnings:
      
          warning C4996: 'std::unary_negate<_Fn>': warning STL4008: std::not1(),
          std::not2(), std::unary_negate, and std::binary_negate are deprecated in
          C++17. They are superseded by std::not_fn(). You can define
          _SILENCE_CXX17_NEGATORS_DEPRECATION_WARNING or
          _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have
          received this warning.
      
      This disables 4996 for the Eigen includes.
      
      Catch generates a similar warning for std::uncaught_exception, so
      disable the warning there, too.
      
      In both cases this is temporary; we can (and should) remove the warnings
      disabling once new upstream versions of Eigen and Catch are available
      that address the warning. (The Catch one, in particular, looks to be
      fixed in upstream master, so will probably be fixed in the next (2.0.2)
      release).
      3be401f2
  2. 22 Oct, 2017 1 commit
    • Jason Rhinelander's avatar
      Miscellaneous travis-ci updates/fixes · 835fa9bc
      Jason Rhinelander authored
      - For the debian/buster docker build (GCC 7/C++17) install and use the
        system `catch` package; this also renames "COMPILER_PACKAGES" to
        "EXTRA_PACKAGES" since it now contains a non-compiler package.
      
      - Add a status message indicating the catch version being used for
        compiling the embedded tests
      
      - Simplify some bash code by using VAR+=" foo" to append (rather than
        VAR="${VAR} foo"
      
      - Fix CMAKE_INCLUDE_PATH appending: it was prepending the ':' but not
        the existing $CMAKE_INCLUDE_PATH value and so would end up with
        ":/eigen-path" if CMAKE_INCLUDE_PATH was already set.  (This wasn't
        bug that was actually noticed since currently nothing else sets it).
      835fa9bc
  3. 12 Sep, 2017 1 commit
  4. 24 Jun, 2017 2 commits
  5. 08 Jun, 2017 1 commit
    • Jason Rhinelander's avatar
      Destroy internals if created during Py_Finalize() · 4edb1ce2
      Jason Rhinelander authored
      Py_Finalize could potentially invoke code that calls `get_internals()`,
      which could create a new internals object if one didn't exist.
      `finalize_interpreter()` didn't catch this because it only used the
      pre-finalize interpreter pointer status; if this happens, it results in
      the internals pointer not being properly destroyed with the interpreter,
      which leaks, and also causes a `get_internals()` under a future
      interpreter to return an internals object that is wrong in various ways.
      4edb1ce2
  6. 07 Jun, 2017 1 commit
  7. 28 May, 2017 3 commits