pnoltes commented on PR #627:
URL: https://github.com/apache/celix/pull/627#issuecomment-2041540655
Sound like a plan :+1: .
> For now I would start with making myself more familiar with Celix. I was
already able to develop a basic understanding of most of the concepts of Celix.
But I definitely need to further enhance this. I will start by installing Celix
and trying to get your Rust examples to work, lets see if I can also make it
work with the latest version 2.4.
>
Trying Apache Celix using version 2.4 is fine, but generally speaking the
master branch is also quite stable for exploring Apache Celix.
1 note: We are currently working towards a Apache Celix 3.0.0, so a major
update. I expect this
has no real impact on learning Apache Celix, because a major part of the
backwards incompatible updates focus on dropping older APIs, which are not or
not well documented anyways. For a complete overview of the backwards
incompatible changes see the top level `CHANGES.md` file.
> The next step would be to get a better understanding of the invariants
that need to be upheld when using the C API. I saw, that a lot of these are
already documented, but I assume there are more and maybe also implicit ones.
When this is done, the Rust API can be designed. Of course I want to leverage
the Rust type system to make sure that the invariants of the C API are upheld.
Your POC is also a great starting point.
> For now I think this is already a lot to do. Let's see where this leads
me. :) In any case, an ASF Contributor Agreement will not be an obstacle.
Great to hear, when this is needed I will give an additional trigger.
> Topics I stumbled upon but which I have put in my backlog for now:
>
> **Allocation:** by default allocating and deallocating on different sides
of the ffi might lead to undefined behaviour. There are several possible
solutions to this
>
> 1. implementing a (global) allocator in Rust that delegates to the
Celix allocator
>
> 2. making sure that both happens on the same side of the FFI by the
Rust type system
>
>
> **Type conversion:** There are various types in the C API that are similar
to Rust types but can not be used as smoothly without further adjustments on
the Rust side. For example the `array_list` type is similar to a vector (with
some additions).
>
> 1. So one solution to use such a type smoothly in Rust, you basically
would have to reimplement the interface of the `std::vec` type.
>
> 2. Another solution is to just copy the elements to the corresponding
type before/after passing the ffi boundary. This might be inefficient however.
>
> 3. A third solution might only be possible when allocation and
deallocation happen on the same side of the ffi boundary. I think it could then
be possible to create a `std::vec` from the internals of an `array_list`
without another allocation just by using the pointer, the size and the capacity
an `array_list` already provides. Together with the additions of an
`array_list` this could be packaged in a simple wrapper type.
Good to hear, you are already seeing some topics and I think the topics are
a good starting point. I was not aware that a separate way of mem allocation
was needed/desired. But as stated, I am not a Rust expert, so help is welcome :)
I will also try to eventual get this PR merged. Not as a stable or even
completely usable addition, but then we at least have a Rust starting point in
the master branch. But I am currently focusing on something else, so I am not
sure yet when I have to pick up this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
