basic_expressions compiles successfully but in Mathematica, as shown in the image, the first arguments get Echoed and then it returns failure. Subsequent calls return the string without any Echoing.

Did I miss something ?

   Compiling wstp-sys v0.2.1
   Compiling wolfram-library-link-sys v0.2.1
   Compiling wstp v0.2.1
   Compiling wolfram-library-link v0.2.1
error[E0308]: mismatched types
   --> C:\Users\Administrator\.cargo\registry\src\github.com-1ecc6299db9ec823\wolfram-library-link-0.2.1\src\numeric_array.rs:175:12
    |
175 |     Cast = MNumericArray_Convert_Cast,
    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`

error[E0308]: mismatched types
   --> C:\Users\Administrator\.cargo\registry\src\github.com-1ecc6299db9ec823\wolfram-library-link-0.2.1\src\numeric_array.rs:176:13
    |
176 |     Check = MNumericArray_Convert_Check,
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`

error[E0308]: mismatched types
   --> C:\Users\Administrator\.cargo\registry\src\github.com-1ecc6299db9ec823\wolfram-library-link-0.2.1\src\numeric_array.rs:177:14
    |
177 |     Coerce = MNumericArray_Convert_Coerce,
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`

error[E0308]: mismatched types
   --> C:\Users\Administrator\.cargo\registry\src\github.com-1ecc6299db9ec823\wolfram-library-link-0.2.1\src\numeric_array.rs:178:13
    |
178 |     Round = MNumericArray_Convert_Round,
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`

error[E0308]: mismatched types
   --> C:\Users\Administrator\.cargo\registry\src\github.com-1ecc6299db9ec823\wolfram-library-link-0.2.1\src\numeric_array.rs:179:13
    |
179 |     Scale = MNumericArray_Convert_Scale,
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`

error[E0308]: mismatched types
   --> C:\Users\Administrator\.cargo\registry\src\github.com-1ecc6299db9ec823\wolfram-library-link-0.2.1\src\numeric_array.rs:180:19
    |
180 |     ClipAndCast = MNumericArray_Convert_Clip_Cast,
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`

error[E0308]: mismatched types
   --> C:\Users\Administrator\.cargo\registry\src\github.com-1ecc6299db9ec823\wolfram-library-link-0.2.1\src\numeric_array.rs:181:20
    |
181 |     ClipAndCheck = MNumericArray_Convert_Clip_Check,
    |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`

error[E0308]: mismatched types
   --> C:\Users\Administrator\.cargo\registry\src\github.com-1ecc6299db9ec823\wolfram-library-link-0.2.1\src\numeric_array.rs:182:21
    |
182 |     ClipAndCoerce = MNumericArray_Convert_Clip_Coerce,
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`

error[E0308]: mismatched types
   --> C:\Users\Administrator\.cargo\registry\src\github.com-1ecc6299db9ec823\wolfram-library-link-0.2.1\src\numeric_array.rs:183:20
    |
183 |     ClipAndRound = MNumericArray_Convert_Clip_Round,
    |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`

error[E0308]: mismatched types
   --> C:\Users\Administrator\.cargo\registry\src\github.com-1ecc6299db9ec823\wolfram-library-link-0.2.1\src\numeric_array.rs:184:20
    |
184 |     ClipAndScale = MNumericArray_Convert_Clip_Scale,
    |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u32`, found `i32`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `wolfram-library-link` due to 10 previous errors

Have searched around for an answer but haven't found anything useful, here is my problem: While iterating between Mathematica and the IDE (VS Code in this case) I couldn't go past the first build as Mathematica locks the DLL library so the build fails with this error:

fatal error LNK1104: cannot open file 'C:\...\target\debug\deps\hello_cargo.dll'

Anyone knows of a workaround other than quitting completely out of Mathematica? And apologies if this is not the right place..

The new #[init] macro is an alternative to manually defining a WolframLibrary_initialize() function.

Before:

#[no_mangle]
pub unsafe extern "C" fn WolframLibrary_initialize(data: sys::WolframLibraryData) -> c_int {
    match wll::initialize() {
        Ok(()) => 0,
        Err(()) => 1,
    }

    // Initialization tasks. Careful not to `panic!()`!
}

After:

#[wll::init]
fn init() {
    // Initialization tasks. Okay to `panic!()`.
}

This commit adds bindings, examples, and basic tests for the LibraryLink managed expression API.

@okofish FYI. Happy to hear any feedback you have on using this API, or have any suggestions on documentation or ergonomics.

Normally, the wrapper function that is automatically generated by the #[export(wstp)] macro will catch Rust panics and translate them into a Wolfram Failure["RustPanic", ..] expression that is written to the WSTP Link as the return value of the function.

However, if the Link already contains partially written data, the catch-panic-and-write-to-link logic was not fully resetting the link to clear that partially written data before writing the Failure[..] result.

When this happened, instead of the function returning either the partial expression (which would not be meaningful) or the panic Failure[..], the Wolfram Kernel would appropriately detect that the link contained uninterpretable partial data, and yield instead the expression (LibraryFunctionError["LIBRARY_FUNCTION_ERROR", 6]) representing the error code returned by the function, which is not helpful at determining the cause of the panic.

With this change, partial data written to the link will be cleared before the Failure[..] expression is written, so that a complete expression is available to be read from the link upon returning to the Wolfram Kernel.

The following example illustrates a situation where this bug occurred:

#[export(wstp)]
fn do_something(link: &mut Link) {
    link.put_function("List", 3).unwrap(); // Start writing a list of three elements
    todo!(); // Panic with an incomplete List[... expression left on the link
}

This is a fix for #29.

The existing code assumed that the Wolfram LibraryLink constants would have the same size and signedness on all platforms. This assumption was not correct on Windows targeting MSVC, where constants that would be u32 on other platforms would be i32.

See also:

• https://github.com/rust-lang/rust-bindgen/issues/1244
• https://github.com/rust-lang/rust-bindgen/issues/1361

I changed my mind after making #38. The phrase 'call back' is a bit too technical and less likely to be familiar than simply 'evaluate', which is a clearer statement of what's happening.

Additionally, a 'callback function' (i.e. a function pointer / closure) is one mechanism for executing code across a library / language boundary, but that is not at all the mechanism used for Rust -> Wolfram evaluations. The new name avoids this potentially misleading connotation.

The file is called ManualWSTP.wlt, but the include_str!(..) call used "ManualWstp.wlt".

This worked on macOS (where I develop) because macOS is case-insensitive. This failed on docs.rs because docs.rs uses Linux build environments, and Linux is case-sensitive.