WIP: try out the autocxx branch #11

mkovaxx · 2025-02-05T01:50:43Z

Trying to make it work on my setup.
Rust 1.84.1 on macOS, Macbook Pro M2.

crates/mfem-sys/build.rs

crates/mfem-cpp/build.rs

mkovaxx · 2025-02-05T01:56:42Z

This is the error I'm getting now.

error: failed to run custom build command for `mfem-sys v0.2.0 (/Users/k/prog/mfem-rs/crates/mfem-sys)`

Caused by:
  process didn't exit successfully: `/Users/k/prog/mfem-rs/target/debug/build/mfem-sys-7fb481d7d70ae46a/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=MFEM_DIR
  CMAKE_TOOLCHAIN_FILE_aarch64-apple-darwin = None
  CMAKE_TOOLCHAIN_FILE_aarch64_apple_darwin = None
  HOST_CMAKE_TOOLCHAIN_FILE = None
  CMAKE_TOOLCHAIN_FILE = None
  CMAKE_GENERATOR_aarch64-apple-darwin = None
  CMAKE_GENERATOR_aarch64_apple_darwin = None
  HOST_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None
  CMAKE_PREFIX_PATH_aarch64-apple-darwin = None
  CMAKE_PREFIX_PATH_aarch64_apple_darwin = None
  HOST_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_aarch64-apple-darwin = None
  CMAKE_aarch64_apple_darwin = None
  HOST_CMAKE = None
  CMAKE = None
  running: cd "/Users/k/prog/mfem-rs/target/debug/build/mfem-sys-0bce584f69d89d98/out/build" && CMAKE_PREFIX_PATH="" "cmake" "/Users/k/prog/mfem-rs/crates/mfem-sys/MFEM" "-DCMAKE_OSX_ARCHITECTURES=arm64" "-DCMAKE_INSTALL_PREFIX=/Users/k/prog/mfem-rs/target/debug/build/mfem-sys-0bce584f69d89d98/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC --target=arm64-apple-darwin -mmacosx-version-min=15.0" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC --target=arm64-apple-darwin -mmacosx-version-min=15.0" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC --target=arm64-apple-darwin -mmacosx-version-min=15.0" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Debug"
  -- Looking for mfem ...
  -- Configuring done (0.0s)
  -- Generating done (0.0s)
  -- Build files have been written to: /Users/k/prog/mfem-rs/target/debug/build/mfem-sys-0bce584f69d89d98/out/build
  running: cd "/Users/k/prog/mfem-rs/target/debug/build/mfem-sys-0bce584f69d89d98/out/build" && MAKEFLAGS="-j --jobserver-fds=8,9 --jobserver-auth=8,9" "cmake" "--build" "." "--target" "install" "--config" "Debug"
  Install the project...
  -- Install configuration: "Debug"
  -- Installing: /Users/k/prog/mfem-rs/target/debug/build/mfem-sys-0bce584f69d89d98/out/share/mfem_info.txt
  cargo:root=/Users/k/prog/mfem-rs/target/debug/build/mfem-sys-0bce584f69d89d98/out
  cargo:rustc-link-search=native=/Users/k/prog/mfem-rs/crates/mfem-cpp/target/debug/build/mfem-cpp-7f4a913d23cf406a/out/build
  cargo:rustc-link-lib=mfem

  --- stderr
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/config/config.hpp:47:2: error: "Either DOUBLE or SINGLE precision must be specified"
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/config/config.hpp:51:11: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/config/config.hpp:53:23: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/config/config.hpp:57:11: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/config/config.hpp:59:23: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/hash.hpp:511:38: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/hash.hpp:518:38: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/hash.hpp:993:44: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/optparser.hpp:102:19: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/kdtree.hpp:641:20: error: use of undeclared identifier 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/kdtree.hpp:644:20: error: use of undeclared identifier 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/kdtree.hpp:647:20: error: use of undeclared identifier 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:41:30: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:45:8: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:47:31: error: use of undeclared identifier 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:59:8: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:61:14: error: unknown type name 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:61:28: error: use of undeclared identifier 'real_t'
  /Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:61:49: error: no matching literal operator for call to 'operator""_r' with argument of type 'unsigned long long' or 'const char *', and no matching literal operator template
  fatal error: too many errors emitted, stopping now [-ferror-limit=]
  thread 'main' panicked at crates/mfem-sys/build.rs:29:10:
  autocxx builder: ParseError(AutocxxCodegenError(Bindgen(ClangDiagnostic("/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/config/config.hpp:47:2: error: \"Either DOUBLE or SINGLE precision must be specified\"\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/config/config.hpp:51:11: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/config/config.hpp:53:23: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/config/config.hpp:57:11: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/config/config.hpp:59:23: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/hash.hpp:511:38: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/hash.hpp:518:38: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/hash.hpp:993:44: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/optparser.hpp:102:19: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/kdtree.hpp:641:20: error: use of undeclared identifier 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/kdtree.hpp:644:20: error: use of undeclared identifier 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/general/kdtree.hpp:647:20: error: use of undeclared identifier 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:41:30: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:45:8: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:47:31: error: use of undeclared identifier 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:59:8: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:61:14: error: unknown type name 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:61:28: error: use of undeclared identifier 'real_t'\n/Users/k/prog/mfem-rs/crates/mfem-cpp/mfem/linalg/vector.hpp:61:49: error: no matching literal operator for call to 'operator\"\"_r' with argument of type 'unsigned long long' or 'const char *', and no matching literal operator template\nfatal error: too many errors emitted, stopping now [-ferror-limit=]\n"))))
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

mkovaxx · 2025-02-05T12:58:59Z

Seems like all the C++ errors are gone now.

Now I'm getting these from Rust:

warning: ambiguous glob re-exports
   --> crates/mfem-sys/src/lib.rs:229:9
    |
228 | pub use ffi::mfem::*;
    |         ------------ but the name `Operator` in the type namespace is also re-exported here
229 | pub use ffi_cxx::*;
    |         ^^^^^^^^^^ the name `Operator` in the type namespace is first re-exported here
    |
    = note: `#[warn(ambiguous_glob_reexports)]` on by default

warning: `mfem-sys` (lib) generated 1 warning
error[E0599]: no method named `as_mut_ptr` found for struct `UniquePtr<FiniteElementSpace>` in the current scope
   --> crates/mfem-sys/examples/ex1.rs:135:70
    |
135 |     let mut b = UniquePtr::emplace(unsafe { LinearForm::new1(fespace.as_mut_ptr()) });
    |                                                                      ^^^^^^^^^^
    |
help: there is a method `as_mut` with a similar name
    |
135 |     let mut b = UniquePtr::emplace(unsafe { LinearForm::new1(fespace.as_mut()) });
    |                                                                      ~~~~~~

error[E0599]: no method named `as_mut_ptr` found for struct `UniquePtr<FiniteElementSpace>` in the current scope
   --> crates/mfem-sys/examples/ex1.rs:146:72
    |
146 |     let mut x = UniquePtr::emplace(unsafe { GridFunction::new2(fespace.as_mut_ptr()) });
    |                                                                        ^^^^^^^^^^
    |
help: there is a method `as_mut` with a similar name
    |
146 |     let mut x = UniquePtr::emplace(unsafe { GridFunction::new2(fespace.as_mut()) });
    |                                                                        ~~~~~~

error[E0599]: no method named `as_mut_ptr` found for struct `UniquePtr<FiniteElementSpace>` in the current scope
   --> crates/mfem-sys/examples/ex1.rs:152:72
    |
152 |     let mut a = UniquePtr::emplace(unsafe { BilinearForm::new2(fespace.as_mut_ptr()) });
    |                                                                        ^^^^^^^^^^
    |
help: there is a method `as_mut` with a similar name
    |
152 |     let mut a = UniquePtr::emplace(unsafe { BilinearForm::new2(fespace.as_mut()) });
    |                                                                        ~~~~~~

For more information about this error, try `rustc --explain E0599`.
error: could not compile `mfem-sys` (example "ex1") due to 3 previous errors

mkovaxx · 2025-02-05T13:46:39Z

Getting close. Now it's a linker error. 🤪

          Undefined symbols for architecture arm64:
            "mfem::AttributeSets::AttributeSets(mfem::Array<int> const&)", referenced from:
                mfem::Mesh::Mesh() in libmfem_sys-2790b860c5b53609.rlib[22](e57ba3d9849530b2-gen0.o)
                mfem::Mesh::Mesh() in libmfem_sys-2790b860c5b53609.rlib[22](e57ba3d9849530b2-gen0.o)
          ld: symbol(s) not found for architecture arm64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)
          

error: could not compile `mfem-sys` (example "ex1") due to 1 previous error

mkovaxx · 2025-02-05T14:36:27Z

crates/mfem-sys/build.rs

    }
    if let "windows" = std::env::consts::OS {
        let current = std::env::current_dir().unwrap();
        build.include(current.parent().unwrap());
    }
+    build.define("MFEM_USE_DOUBLE", Some("true"));


Note to self: None would also work here.

I don't think it does the right thing. The MFEM library should report whether it was compiled with single or double precision — you cannot change that in mfem-sys.

Agreed, I added this line just to get it working.

When mfem-cpp has the bundled feature enabled, this setting must also be provided, correct?
What do you think about introducing a feature for this, e.g. single-precision (making double precision the default)?

To be clear: it doesn't need to happen in this change. We can just file an issue and do it later.

I pushed some additional commits to the autocxx branch. It is better to do it know—it affects the code generation (need to use real_t). Moreover, it pushed me to better understand the mfem-sys cmake call. I also had some problem with defining a type to specify cxx functions that may be f32 or f64 depending on the library. Maybe it is possible to do better.

crates/mfem-sys/examples/ex1.rs

Chris00 · 2025-02-05T18:30:21Z

warning: ambiguous glob re-exports
   --> crates/mfem-sys/src/lib.rs:229:9
    |
228 | pub use ffi::mfem::*;
    |         ------------ but the name `Operator` in the type namespace is also re-exported here
229 | pub use ffi_cxx::*;
    |         ^^^^^^^^^^ the name `Operator` in the type namespace is first re-exported here
    |
    = note: `#[warn(ambiguous_glob_reexports)]` on by default

Are you using the latest version of the branch — this is normally fixed in later commits.

Chris00 · 2025-02-05T18:34:34Z

Sorry, I don' have much time to work on this these days — I'm full with other duties...

I will try to set up CI so tests on various platforms ans various compiler versions are automatically performed.

Chris00 · 2025-02-06T00:02:59Z

I set up CI. Linux and MacOS pass (with the bundled feature, the available packages being too old or ill installed) but Windows has a linking error (for a deprecated function).

Chris00 · 2025-02-06T00:03:43Z

See https://github.com/Chris00/mfem-rs/actions/runs/13168862035

mkovaxx · 2025-02-06T04:10:00Z

I've rebased this branch onto your latest autocxx branch.
Still getting that linker error.
Might be related to the recent upgrade to macOS 14.4... 🤔

Chris00 · 2025-02-06T08:41:57Z

I've rebased this branch onto your latest autocxx branch. Still getting that linker error.

There are more commits on my repo but I'd like the Windows CI to pass before pushing them.

Might be related to the recent upgrade to macOS 14.4... 🤔

Well, at least you have access to the library and can list the symbols. Less fun on the CI! 😅

mkovaxx · 2025-02-06T14:57:35Z

@Chris00 I've incorporated your CI config into main, then rebased this branch onto it.
Now it builds and runs successfully.

...but it fails with a runtime error:

$ cargo run -p mfem-sys --features bundled --example ex1 -- --mesh crates/mfem-cpp/mfem/data/escher.mesh
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1m 18s
     Running `target/debug/examples/ex1 --mesh crates/mfem-cpp/mfem/data/escher.mesh`
[crates/mfem-sys/examples/ex1.rs:53:5] mesh.GetNE() = c_int(
    42,
)
[crates/mfem-sys/examples/ex1.rs:69:5] mesh.GetNE() = c_int(
    21504,
)
[crates/mfem-sys/examples/ex1.rs:110:9] fec_name = "H1_3D_P1"
Number of finite element unknowns: 4401
ex1(82265,0x200368840) malloc: Corruption of tiny freelist 0x158605d90: size too small (3/24)
ex1(82265,0x200368840) malloc: *** set a breakpoint in malloc_error_break to debug
zsh: abort      cargo run -p mfem-sys --features bundled --example ex1 -- --mesh

Chris00 · 2025-02-06T21:55:32Z

I cannot reproduce it:

cargo run -p mfem-sys --example ex1 -- --mesh crates/mfem-cpp/mfem/data/escher.mesh
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.06s
     Running `target/debug/examples/ex1 --mesh crates/mfem-cpp/mfem/data/escher.mesh`
[crates/mfem-sys/examples/ex1.rs:53:5] mesh.GetNE() = c_int(
    42,
)
[crates/mfem-sys/examples/ex1.rs:69:5] mesh.GetNE() = c_int(
    21504,
)
[crates/mfem-sys/examples/ex1.rs:110:9] fec_name = "H1_3D_P1"
Number of finite element unknowns: 4401
Size of linear system: 4401
[crates/mfem-sys/examples/ex1.rs:182:5] a_mat.Type() = MFEM_SPARSEMAT
   Iteration :   0  (B r, r) = 0.044126
   Iteration :   1  (B r, r) = 0.0593054
   Iteration :   2  (B r, r) = 0.0187582
   Iteration :   3  (B r, r) = 0.00453997
   Iteration :   4  (B r, r) = 0.000766598
   Iteration :   5  (B r, r) = 7.97563e-05
   Iteration :   6  (B r, r) = 6.13697e-06
   Iteration :   7  (B r, r) = 9.00502e-07
   Iteration :   8  (B r, r) = 3.85438e-07
   Iteration :   9  (B r, r) = 8.87763e-08
   Iteration :  10  (B r, r) = 1.153e-08
   Iteration :  11  (B r, r) = 4.34484e-10
   Iteration :  12  (B r, r) = 3.18756e-11
   Iteration :  13  (B r, r) = 6.70036e-12
   Iteration :  14  (B r, r) = 5.33459e-13
   Iteration :  15  (B r, r) = 8.76958e-14
   Iteration :  16  (B r, r) = 1.54921e-14
Average reduction factor = 0.408126

but this is interesting: some memory was maybe freed twice?

mkovaxx · 2025-02-07T01:47:03Z

@Chris00 You're right; I just tried it on another computer (a Mac Mini M2), and getting your results now. So something is off on the Macbook. I'll try to re-clone the repo...

mkovaxx · 2025-02-07T02:23:30Z

@Chris00 Yep, after re-cloning the repo, I'm getting the same results as you.

I'd like to rebase the autocxx branch onto the latest main. Is that cool with you?

Chris00 · 2025-02-07T06:56:18Z

@Chris00 Yep, after re-cloning the repo, I'm getting the same results as you.

I'd like to rebase the autocxx branch onto the latest main. Is that cool with you?

Please see #8 (comment)

Chris00 · 2025-02-07T12:34:05Z

May you try the current autocxx branch?

The environment variable DEP_MFEM_ROOT has been renamed MFEM_DIR as this seems to be the expected name https://mfem.org/building/

Chris00 · 2025-02-08T09:18:33Z

When mfem-cpp has the bundled feature enabled, this setting must also be provided, correct?

No, the precision with which mfem was compiled is provided in config/_config.hpp — we should not override that. That file actually provides more macros giving information about mfem compilation (such as MFEM_INSTALL_DIR). The information about single/double precision is also accessible via cmake. ATM in the autocxx branch, mfem-sys/build.rs uses that to check that mfem was compiled with double precision and issues an error otherwise (mfem-cpp specifically requests double precision—I added a `define` for that a few commits back).

What do you think about introducing a feature for this, e.g. single-precision (making double precision the default)?

In such case, libraries depending on mfem will need to define their feature to reflect the choice of mfem and write conditional code. However, the choice of precision for mfem only makes sense for `bundled`; if the library was installed system-wide, the compilation must fail in case the precision mismatches. What should the feature name be? `precision-f32`? Note that the mfem `real_t` is already accessible from the autocxx bindings — we have to find a better name for the “Rust like” bindings.

mkovaxx · 2025-02-08T10:27:02Z

@Chris00 I'm trying to make the mfem submodule point at your commit in their repo, but I can't figure out how to do this. Can you please help me out here?

EDIT: I just needed to git fetch origin 7aa3e764fa3c67bec85178be79514e1880fe851e in the submodule... 😅

Chris00 · 2025-02-08T11:29:30Z

@Chris00 I'm trying to make the mfem submodule point at your commit in their repo, but I can't figure out how to do this. Can you please help me out here?

You are right, it points to the wrong commit. I don't know how it is possible that the CI tests did not fail (I cloned this repository afresh and git switch autocxx; git submodule init; git submodule update do the right thing despite the commit being in my personal repo. This may not last however (the commit may be gc) so I will update the commit to an existing one inside the mfem repo. Working with git submodules feels brittle and frustating IMHO.

mkovaxx · 2025-02-08T11:36:48Z

You are right, it points to the wrong commit. I don't know how it is possible that the CI tests did not fail (I cloned this repository afresh and git switch autocxx; git submodule init; git submodule update do the right thing despite the commit being in my personal repo. This may not last however (the commit may be gc) so I will update the commit to an existing one inside the mfem repo. Working with git submodules feels brittle and frustating IMHO.

Just an idea, but we could ask them to create a v4.7.1 tag that contains your patch. Then we could easily refer to the tag instead of that unwieldy commit... I find that the MFEM authors/maintainers are very sensible people, so I'm sure they'd be cool with this.

Chris00 · 2025-02-08T11:59:27Z

Good idea. I've done so.

mkovaxx · 2025-02-13T08:34:54Z

@Chris00 This is ready, and all checks are passing. Are you okay with merging this into the autocxx branch?

mkovaxx self-assigned this Feb 5, 2025

mkovaxx mentioned this pull request Feb 5, 2025

Use autocxx #8

Open

mkovaxx commented Feb 5, 2025

View reviewed changes

crates/mfem-sys/build.rs Outdated Show resolved Hide resolved

mkovaxx commented Feb 5, 2025

View reviewed changes

crates/mfem-cpp/build.rs Outdated Show resolved Hide resolved

mkovaxx changed the title ~~try out the autocxx branch~~ WIP: try out the autocxx branch Feb 5, 2025

mkovaxx marked this pull request as draft February 5, 2025 01:57

mkovaxx requested a review from Chris00 February 5, 2025 01:57

mkovaxx commented Feb 5, 2025

View reviewed changes

Chris00 reviewed Feb 5, 2025

View reviewed changes

crates/mfem-sys/examples/ex1.rs Outdated Show resolved Hide resolved

mkovaxx force-pushed the mate-try-autocxx branch from e51bba4 to b6e25b9 Compare February 6, 2025 04:08

mkovaxx force-pushed the mate-try-autocxx branch from b6e25b9 to ad2af86 Compare February 6, 2025 14:51

mkovaxx changed the base branch from autocxx to main February 6, 2025 14:58

mkovaxx changed the base branch from main to autocxx February 7, 2025 02:18

mkovaxx requested a review from Chris00 February 7, 2025 02:24

mkovaxx marked this pull request as ready for review February 7, 2025 02:24

Chris00 force-pushed the autocxx branch from f3f735a to ca54baf Compare February 7, 2025 12:33

mfem-sys: Store information from cmake directly in the struct

99d9d5a

The environment variable DEP_MFEM_ROOT has been renamed MFEM_DIR as this seems to be the expected name https://mfem.org/building/

Use autocxx to generate most bindings on mfem-sys

a4d03a5

mkovaxx force-pushed the mate-try-autocxx branch 2 times, most recently from 0bc2c77 to d67ce58 Compare February 8, 2025 09:57

mkovaxx force-pushed the mate-try-autocxx branch from d67ce58 to 2ea7c26 Compare February 8, 2025 10:34

cleanup

ef6142a

mkovaxx force-pushed the mate-try-autocxx branch from 2ea7c26 to ef6142a Compare February 8, 2025 11:28

Chris00 mentioned this pull request Feb 8, 2025

[v4.7.1] Remove MesquiteSmooth which is not implemented mfem/mfem#4690

Closed

mkovaxx marked this pull request as draft February 9, 2025 00:11

mfem submodule at v4.8-rc0

d2eaa3e

mkovaxx marked this pull request as ready for review February 13, 2025 08:33

Chris00 merged commit 631853a into autocxx Feb 13, 2025
14 checks passed

Chris00 deleted the mate-try-autocxx branch February 13, 2025 21:20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: try out the autocxx branch #11

WIP: try out the autocxx branch #11

mkovaxx commented Feb 5, 2025 •

edited

Loading

mkovaxx commented Feb 5, 2025

mkovaxx commented Feb 5, 2025

mkovaxx commented Feb 5, 2025

mkovaxx Feb 5, 2025

Chris00 Feb 7, 2025

mkovaxx Feb 8, 2025

mkovaxx Feb 8, 2025

Chris00 Feb 10, 2025

Chris00 commented Feb 5, 2025 •

edited

Loading

Chris00 commented Feb 5, 2025

Chris00 commented Feb 6, 2025

Chris00 commented Feb 6, 2025

mkovaxx commented Feb 6, 2025

Chris00 commented Feb 6, 2025 via email

mkovaxx commented Feb 6, 2025

Chris00 commented Feb 6, 2025

mkovaxx commented Feb 7, 2025

mkovaxx commented Feb 7, 2025

Chris00 commented Feb 7, 2025

Chris00 commented Feb 7, 2025 •

edited

Loading

Chris00 commented Feb 8, 2025 via email

mkovaxx commented Feb 8, 2025 •

edited

Loading

Chris00 commented Feb 8, 2025

mkovaxx commented Feb 8, 2025 •

edited

Loading

Chris00 commented Feb 8, 2025

mkovaxx commented Feb 13, 2025

WIP: try out the autocxx branch #11

WIP: try out the autocxx branch #11

Conversation

mkovaxx commented Feb 5, 2025 • edited Loading

mkovaxx commented Feb 5, 2025

mkovaxx commented Feb 5, 2025

mkovaxx commented Feb 5, 2025

mkovaxx Feb 5, 2025

Choose a reason for hiding this comment

Chris00 Feb 7, 2025

Choose a reason for hiding this comment

mkovaxx Feb 8, 2025

Choose a reason for hiding this comment

mkovaxx Feb 8, 2025

Choose a reason for hiding this comment

Chris00 Feb 10, 2025

Choose a reason for hiding this comment

Chris00 commented Feb 5, 2025 • edited Loading

Chris00 commented Feb 5, 2025

Chris00 commented Feb 6, 2025

Chris00 commented Feb 6, 2025

mkovaxx commented Feb 6, 2025

Chris00 commented Feb 6, 2025 via email

mkovaxx commented Feb 6, 2025

Chris00 commented Feb 6, 2025

mkovaxx commented Feb 7, 2025

mkovaxx commented Feb 7, 2025

Chris00 commented Feb 7, 2025

Chris00 commented Feb 7, 2025 • edited Loading

Chris00 commented Feb 8, 2025 via email

mkovaxx commented Feb 8, 2025 • edited Loading

Chris00 commented Feb 8, 2025

mkovaxx commented Feb 8, 2025 • edited Loading

Chris00 commented Feb 8, 2025

mkovaxx commented Feb 13, 2025

mkovaxx commented Feb 5, 2025 •

edited

Loading

Chris00 commented Feb 5, 2025 •

edited

Loading

Chris00 commented Feb 7, 2025 •

edited

Loading

mkovaxx commented Feb 8, 2025 •

edited

Loading

mkovaxx commented Feb 8, 2025 •

edited

Loading