Bart Janssens
Bart Janssens
I have no idea why, but iterating over the jlarray seems to return the Julia type, so replacing your loop with the following seems to work: ```c++ for (auto e...
You can't modify the Julia value in-place because the numbers (both `Float64` and `Complex`) are immutable. I think something like this should work: ```c++ s[0] = jlcxx::convert_to_julia(jlcxx::convert_to_cpp(s[0]) + 1); ```
I agree that if it causes breakage that it should be a feature release, but I'm actually not sure why it breaks. I was expecting the upgrade to 0.8.2 to...
I think you're right, this should have been marked as a breaking change. While upgrading CxxWrap gets the correct libcxxwrap automatically, depending packages are not recompiled against the new lib...
The trick is to specialize `jlcxx::BuildParameterList`, there is an example for this in https://github.com/JuliaInterop/CxxWrap.jl/blob/master/deps/src/jlcxx/examples/parametric.cpp for the type `NonTypeParam`.
It's possible, but you do need to enumerate all the allowed template parameter values in the C++ files. If you need truly on-the-fly compilation of C++ templates based on parameters...
I'm not sure if this really will work in all cases, allocating memory on the C++ side and freeing it on the Julia side could cause problems. You should also...
Ah, actually I had put in that assert for debugging purposes and forgot to remove it. If you build from libcxxwrap master or just remove the assert yourself, an exception...
Gist with logs here: https://gist.github.com/barche/1c7b2ee2562965bffb5e26ccda1abaee
Another possible workaround is building with MSVC, this is pretty easy using AppVeyor. But then there are other caveats due to not using the exact same compiler as the one...