v2.0.1 -- and finally get a stable main#216
Merged
Merged
Conversation
Moved cmake.args into the [tool.scikit-build.cmake] section to avoid declaring the cmake key twice, which caused a parse error on Windows CI. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ARIES The conditional find_package(Boost COMPONENTS system) call for Boost < 1.89 was resetting Boost_LIBRARIES to only contain boost_system, causing the linker to fail finding serialization, log, filesystem, etc. on Windows. Re-find with all components so Boost_LIBRARIES remains complete. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
jrl-cmakemodules creates a bertini2-doc target when Doxygen is found, and on MSVC/clang-cl it's added to ALL so it builds unconditionally. The Windows CI runner has Strawberry Perl's doxygen pre-installed, causing the build to fail. CMAKE_DISABLE_FIND_PACKAGE_Doxygen=ON prevents find_package(Doxygen) from finding it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The manylinux build already installs eigenpy from source via cmake. Without --no-deps, pip tries to install eigenpy from PyPI, which pulls scipy from source requiring OpenBLAS compilation that fails. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…em class On Eigen 3.3.x (manylinux2014), EIGEN_MAKE_ALIGNED_OPERATOR_NEW defines operator new/delete. Placed in the private section, it made destructors of derived classes (StartSystem, MHomogeneous, User) ill-formed. Moving to public section fixes the access error. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Move Boost and eigenpy builds outside Python version loop (built once) - Add set -e for fail-fast behavior - Add -j$(nproc) for parallel compilation - Use glob for auditwheel instead of hardcoded version string - Drop EOL Python versions (cp38-310), keep cp311-312 - Include both /usr/local/lib and lib64 in LD_LIBRARY_PATH Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
b2 auto-detects Python 2.7 from the manylinux2014 container and tries to build Boost.Python for it, which fails (missing pyconfig.h). Write a user-config.jam and pass python=<ver> to b2 to restrict the build to only the target Python 3.11. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
PYBIN is the bin/ directory (e.g., /opt/python/cp312-cp312/bin). PYTHON_EXECUTABLE needs the actual binary, not the directory. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Removed unescaped ${PYBIN}/${DIR} lines that the host shell expanded
to empty before reaching the Docker container
- Replaced hardcoded pybertini-1.0a8 filename with glob pattern
- Use full path /io/wheelhouse/ for auditwheel input
- Escape $LD_LIBRARY_PATH so it resolves inside Docker
- Clean up wheelhouse between loop iterations
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There are some compiling errors while being compiled in windows * `size_t` is translated into `unsigned long` in linux, mac while `unsigned long long` in windows 10: `core/include/bertini2/eigen_extensions.hpp` and `core/test/classes/start_system_test.cpp` are modified * use `clang` of LLVM in Windows since MSVC has different compiling way for `template` * use `--no-isolation` for `scikit-build` in Windows For linux wheel naming convention, we cannot use x86_64, x86_i386 anymore for pypi repository. https://peps.python.org/pep-0600/ * use `auditwheel` for it Co-authored-by: HongKee Moon <moon@mpi-cbg.de>
the default branch is changed to 'develop'
Audit of System mutators surfaced four more public methods with the same stale-SLP / stale-derivatives pattern as operator+= and operator*=: - ReorderFunctionsByDegreeDecreasing / ReorderFunctionsByDegreeIncreasing swap entries in functions_; without invalidation, the SLP keeps the old index → function mapping, and jacobian_ entries become misaligned with the new function order. - SimplifyFunctions rewrites each function tree via Simplify(); without invalidation, the SLP retains the un-simplified structure (a performance leak, not a correctness one, since Simplify preserves math). - ClearVariables wipes variable groups; without invalidation the SLP refers to vanished variables and the cached variable ordering is stale. All four follow the canonical pattern used by AddFunction, Homogenize, etc.: set is_differentiated_ = false (and have_ordering_ = false where variables are also affected). New tests: - reorder_functions_decreasing_invalidates_slp_cache - reorder_functions_increasing_invalidates_slp_cache Both Eval before and after the reorder to verify the SLP follows the new ordering. SimplifyFunctions and ClearVariables are not directly testable through Eval (math-preserving / mask-by-downstream-AddVariableGroup) so no test is added for those — the fixes are by analogy to the established pattern. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… order Two-part fix for the macos-15-intel SIGABRT in System.eval: 1. mpfr_export.cpp ExposeFreeNumFns(): Replace `DefaultPrecision(DefaultPrecision())` with a direct read of the static default. On Boost 1.87 the getter may delegate to the thread-local (which is 0), causing DefaultPrecision(0) -> mpfr abort. Now: read mpfr_float::default_precision() directly, fall back to 50 (Boost's library default) if 0, and set thread_default_precision unconditionally. 2. system_export.cpp eval overload registration order: Register mpfr overloads before dbl so boost::python tries dbl first (LIFO resolution). A numpy int64 array previously caused eigenpy to probe Vec<mpfr> construction first; with thread_default_precision=0 on Boost>=1.87 that aborts before we even reach the dbl path. Explicitly passing Vec<mpfr_complex> still resolves to the mpfr overload — only ambiguous/numeric inputs are affected. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
1.87 lets thread_default_precision() return 0 on fresh threads and passes it straight to mpfr_init2 with no guard → SIGABRT. 1.90 pre-seeds thread- local precision from the global default and also guards against 0, matching the Homebrew version used in local development. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Previously the full matrix (macos-15-intel, all Python versions) only ran on pushes to main/develop and tags — too late to catch issues before merge. PRs targeting develop now get the full matrix so every platform is verified before the merge happens. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
SLPCompiler::Compile() grows the mpfr_complex memory block via std::vector::resize(), which default-constructs each new slot via mpfr_init2(x, thread_default_precision()). On Boost 1.87+ that thread-local value can be 0 on fresh threads, causing mpfr_init2 to abort with SIGABRT. Call DefaultPrecision(slp.precision_) just before the resize so both the static and thread-local defaults match the SLP's own precision. This makes the memory growth independent of whatever the thread default happened to be. This path is now hit by test_add_systems on macos-15-intel after the operator+= fix started invalidating is_differentiated_, which causes s1.eval() to trigger Differentiate() -> SLPCompiler::Compile().
An MPFR/Boost interaction causes a SIGABRT in pytest on macos-15-intel that we cannot reproduce locally. Pausing Intel macOS support pending a reproducer or an upstream fix. The release notes should call this out so users on Intel Macs know the wheels are not built or tested for that platform right now. The fast_matrix branch was already Intel-free; only the full_matrix branch needed editing. Re-add "macos-15-intel" to that branch's `os` list when ready to revisit.
Summarize the work that has accumulated on pr/212 since 1.0.3: PyPI wheels across Linux / macOS-arm / Windows for py3.9-3.13, the package rename to bertini2, scikit-build-core packaging, version unification via pyproject.toml, the GitHub Pages docs site, Boost 1.87->1.90 bump, this session's precision-handling fixes in System / SLP, and the removal of macos-15-intel from the supported matrix. Also rename the changelog header from "bertini" to "bertini2" to match the PyPI package name.
Enhance Windows compatibility and update CI configurations. Generate wheels. Some bug fixes along the way.
ofloveandhate
changed the title
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Fix/full matrix for main prs
libeigenpy alone is 588 MB uncompressed with debug symbols, pushing the manylinux wheel over TestPyPI/PyPI's 100 MB per-file limit. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
👷 ci: strip debug symbols from bundled Linux deps to reduce wheel size
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
👷 ci: fix docs workflow — pin eigenpy and enforce Sphinx warnings
Strip eigenpy on CMake install and skip symlinks in the post-install find/strip pass, which was silently failing on symlinked .so files. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…tions --strip-unneeded keeps debug sections; --strip-debug removes them. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
👷🏻 strip eigenpy symbols before packing wheels
increase version number to 2.0.1.dev2
Contributor
Author
|
2.0.1.dev2 was successfully published to testpypi. I need to download and test the wheels on a fresh python env before I merge in and release for real. |
Contributor
Author
|
🥳 I was able to install from TestPyPI in a fresh Micromamba environment with Python 3.13 on my Mac. gave And then I was able to import and use it!!! |
going to full version 2.0.1
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.