-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
julia 1.11: add some workarounds for jl_array changes #137
Conversation
I'm just curious did Julia break the C API? I mean it's not guaranteed stable yet I believe, except possibly some subset. But still practical breakage? Or is this about an added feature (that you could choose to now support)? |
|
Julia unfortunately has breaking C API changes all the time -- though at least these days they seem to avoid them in patch releases. |
It should at least be guaranteed to not happen in point releases, IMHO. Or people must then not upgrade (those who embed Julia, and well use C++ with...). There also doesn't seem like no reason for it (backporting needs to happen, but selectively, I doubt breaking the API needed for security, or even bug-fixes), Julia must be getting stable over time. So in fact also seems not needed for 1.x of changing x. Adding to the API should be ok, I feel like at least a subset of the C API should be usable. Calling C code is ok, that has never been broken, so I'm unsure why does C++ actually need more, i.e. any of the C (embedding) API? Could this project restrict itself to some stable subset? |
We are talking here about fixes for the julia development version, not backports. basically, for C API changes, minor releases 1.x are treated as semver major releases (so breaks happen) and patch releases as minor releases . Not great but I can see why to a degree. They are quite explicit about promising compatibility only at the language level, not for internal kernel APIs. And nothing here is specific to C++ |
Regarding the jl_array_t *some_array = ...; // e.g. a Vector{Any}
void **data = (void**)jl_array_data(some_array);
jl_value_t *some_value = ...;
data[0] = some_value;
jl_gc_wb(some_array, some_value); I suppose that way we can also avoid the |
This would be similar to the Right now the only failure in the tests seems to be JuliaInterop/CxxWrap.jl#390 or am I missing something?
That workaround was only needed for avoiding the |
FYI, I just noticed with example "C++ Calling Julia", just about to be registered in case helpful to you:
|
Thanks for the pointer, but no, TyJuliaCAPI.jl is not helpful here. (and while I think it is a noble effort, some of the comments in the README strike me as rather naive -- holding up Python as a paragon for stable APIs, much less ABIs completely ignores history. The Python C API had over 30 years to evolve, and is notoriously is not ABI stable, and has other issues -- one of multiple reasons why e.g. HPy is a thing. We definitely want a more stable C API for Julia at some point, and there certainly are lessons to be learned from Python and other systems; we (OSCAR team) have suffered from and worked through Julia API/ABI changes constantly, so we appreciate the need. But at the same time there are good reasons why Julia is not yet there... In any case, any efforts to get such a stable API without involving the Julia core dev team seems doomed to fail ... though perhaps I just am just to old and cynical when it comes to this kind of stuff ...) That said, this is all a red herring, it doesn't help us one bit with the issue at hand. |
I think the code here should be working, the tests still fail in the CI due to JuliaInterop/CxxWrap.jl#390, locally I get even more errors, see #391, because CxxWrap uses some internal string iteration methods that stopped working for the wide C++ strings. With the changes from this PR, JuliaInterop/CxxWrap.jl#390 applied and JuliaLang/julia#51671 temporarily reverted I got all tests to pass locally. |
1df29aa
to
26c76fa
Compare
this avoids the arrayset and manually dealing with the write barrier
I changed the code to use |
Python has (limited) stable API/ABI and maybe Julia should define similar JL_LIMITED_API:
I've not looked closely at TyJuliaCAPI.jl how they can promise a stable C API (and ABI?!) for Julia, presumably on top of its unstable C API, probably by locating the most practically stable subset, or thinking least likely to change, that could be defined stable (but hasn't...); for JL_LIMITED_API. I'm guessing that package is more of a promise to fix in the future if Julia changes... to at least localize in one place needed changes? |
Tests here use the |
for the changes in JuliaLang/julia#51319
cc: @fingolfin
Edit: The library seems to build but a test module fails with:
Not yet sure what to make of this.This might be fixed by JuliaLang/julia#51916.