Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

@tqchen RFC rejected 😸 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1375932226 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

Closed #96. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#event-8183713990 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

I think we have all made our points pretty clear. >From technical pov I do not think have clear namespacing or scoping would >bring inconsistency, and if any, that would be more of a minor issue by >looking at the embedded API. They would be significant when looking at the >broader community

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> It will however, come with benefit of clarity for broader TVM communty > members who are interested in Bx but not in B, or both in (Bx-B) and B. As a > result the requested change, which i believe would be net positive for > developer users both in (Bx - B) and B. They are pretty actionable wi

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

We both agree that there are other aspects such as documentation of C that can be further improved, and also agree that they should not be part of this RFC. > strong requirement I was referring to the fact that the cost of maintaining namespacing is not a strong requirement for this particular

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> The suggestions are made on that basis not only considering embedded C and > rust API(we should of course take that into consideration as part of the > process like you suggested), but also general TVM project(and broader tvm > community) as a whole for this specific context of rust language i

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> C is used for a variety of use-cases and is foundational to much of the > software used in larger systems (not only embedded) I am not denying that fact. Assembly language can also be used to build up a broader spectrum of systems --just most people don't do that, and normal audiences of tvm

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> I also stated reasonings on why the interface_c name was a OK choice under > that the context of C, because C is a language that is mostly used for > embedded space -- rust do not have that same profile, as a result when we do > the development we need to consider it under the new context of r

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

That particular RFC you were referring to is about C interface and not rust. I also stated reasonings on why the interface_c name was a OK choice under that the context of C, because C is a language that is mostly used for embedded space -- rust do not have that same profile, as a result when w

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

I'd suggest your concerns might be better raised alongside https://discuss.tvm.apache.org/t/pre-rfc-api-change-formalizing-c-backend-api/10380 :smile_cat: -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1373406483 You are receiving

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> To incorporate that suggestion, this can be done through say > > * On compilation part, have proper namespace, file or folder structure to > indicate the grouping (that we are looking at embedded rust) so to avoid > confusion with other rust APIs. > * (a) introducing a new namespace; (b) use a

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

I still think you still misunderstood my comment :) The particular comment is suggesting possible approaches that would help give clarity of the rust embedded API in this RFC. You might feel that I am implying changes to embedded C API. While it is OK to for myself or others to give suggestion

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

> I am only referring to the clarifying the module with proper namespace, > folder structure and naming convention helps to bring the clarity to > developers and users as they start to interact with the APIs. > > For example, putting some of the API under `micro` namespace(actually any > namesp

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

Hi @Mousius I think you misunderstood my comments. Perhaps due to the possible confusion "scoping". I am not suggesting to change the interface design or re-define the way to interact with embedded C APIs. I am only referring to the clarifying the module with proper namespace, folder structure

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

I acknowledge your concerns @tqchen, the diversity of API in TVM is a problem beyond this RFC though. This RFC is aligned with the Embedded C APIs, which have a multitude of examples within the TVM repo. If we want to re-scope the embedded interfaces then I'd suggest we do that in a separate R

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

Thanks for the RFC. The main thing that I think worth doing is scoping, so that the relation of the proposed module can be reasonably understandable by the overall community. Here are two things ## Clarifying the interface - X0: TVM had a heavy focus on a fixed, small set of universal interfa

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

New APIs are now documented and I've raised https://github.com/apache/tvm/issues/13705 😸 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-137596 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

Heads up, we're working on an iteration on this RFC with more idiomatic Rust 😸 though anyone willing to take a first pass would be appreciated still. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1344537878 You are receiving this be

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

sorry for the long delay in review, I've been on holiday for a while now. I'll take a look over this. cc @mehrdadh @alanmacd @mkatanbaf -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1324139260 You are receiving this because you are

Re: [apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

This is here for a a few weeks already. Before merging this, just wanted to ping @apache/tvm-committers for visibility. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1313355179 You are receiving this because you are subscribed to th

[apache/tvm-rfcs] Embedded Rust API RFC (PR #96)

Co-authored-by: Ashutosh Parkhi You can view, comment on, or merge this pull request online at: https://github.com/apache/tvm-rfcs/pull/96 -- Commit Summary -- * Embedded Rust API RFC -- File Changes -- A rfcs/0094-embedded-rust-interface-api.md (275) -- Patc