Re: [apache/tvm-rfcs] [RFC] On-Device Testing in TVM CI (PR #98)

> @gromero PTAL, thanks! argh! sorry, missed your previous ping long ago! So, just the nits in this comment (https://github.com/apache/tvm-rfcs/pull/98#discussion_r1123874703) are missing. Otherwise LGTM! -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs

Re: [apache/tvm] [VOTE] Issue Triage Workflow RFC (Issue #12743)

+1 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/12743#issuecomment-1241311328 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] [RFC] Add Commit Message Guideline (PR #88)

@areusch @driazati @tqchen @tkonolige @manupak @Lunderberg @mbaret @junrushao @Hzfengsy @slyubomirsky @ekalda thanks a lot for the reviews and support of this RFC! Tracking issue is created at: https://github.com/apache/tvm/issues/12690 Cheers. -- Reply to this email directly or view it on G

Re: [apache/tvm-rfcs] [RFC] Add Commit Message Guideline (PR #88)

OK, I agree @leandron @driazati Thanks. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/88#issuecomment-1218386487 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] [RFC] Add Commit Message Guideline (PR #88)

> @gromero I think I am getting a little confused at the difference between > messages in the commits composing the PR and the final commit in main. To > make things clearer, I think it would help to refer to to commit title and > commit message as PR title and PR description, respectively. PR t

Re: [apache/tvm-rfcs] [RFC] Add Commit Message Guideline (PR #88)

> Can you also include guidelines for 1. how the PR author can update their > commits if they are not up to this standard (rebase?) Let's say a PR has just been created. The idea is that regarding the commit message (that will compose the final commit message) it doesn't matter the commit(s) me

Re: [apache/tvm-rfcs] [RFC] Add Commit Message Guideline (PR #88)

@areusch @leandron Could you please help me on how to trigger a [VOTE] thread on this RFC? Cheers. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/88#issuecomment-1215261260 You are receiving this because you are subscribed to this thread. Message I

Re: [apache/tvm-rfcs] [RFC] Add Commit Message Guideline (PR #88)

@tqchen @jroesch @driazati @areusch @Mousius @manupak @tkonolige @mbaret @leandron @alanmacd -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/88#issuecomment-1215257266 You are receiving this because you are subscribed to this thread. Message ID:

[apache/tvm-rfcs] [RFC] Add Commit Message Guideline (PR #88)

This RFC proposes adding a Commmit Message Guideline to Apache TVM documentation to help guide contributors on how to write good commit messages when submitting code / Pull Requests. Co-authored-by: Leandro Nunes You can view, comment on, or merge this pull request online a

Re: [apache/tvm-rfcs] [RFC] A proposed update to the Docker images ci_* tag pattern (PR #66)

> > > @leandron, looking at Docker Hub (https://hub.docker.com/_/hello-world) > > > it would appear the convention for image names is to use `-` there as > > > well (i.e. `tlcpack/ci-cpu` rather than `tlcpack/ci_cpu`) can we go for > > > that one? > > > > > > Sure. I’ll push an updated version

Re: [apache/tvm-rfcs] [RFC] A proposed update to the Docker images ci_* tag pattern (PR #66)

@Mousius I don't have any further comments on it. Are you ok with the current state of this RFC? If so, could you please approve the changes so I can merge it? Thanks! -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/66#issuecomment-1148090614 You ar

Re: [apache/tvm-rfcs] [RFC][MLF] Model Library Format with Multiple Modules (PR #76)

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

Re: [apache/tvm-rfcs] [RFC] A proposed update to the Docker images ci_* tag pattern (PR #66)

> cc @Mousius @gromero can you approve? @leandron Hi. Are you still planing to change https://github.com/apache/tvm-rfcs/pull/66#discussion_r854052265 ? -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/66#issuecomment-1125764615 You are receiving th

[Apache TVM Discuss] [Development/pre-RFC] Commit Message Guideline

[quote="driazati, post:5, topic:12334, full:true"] These guidelines are definitely good to have and I think we should codify them in our docs! One big problem we have today is clicking the merge button on GitHub defaults to a bad commit message which [[RFC] Allow merging via PR comments](https

[Apache TVM Discuss] [Development/pre-RFC] Commit Message Guideline

@tqchen Thanks a lot for input and support. I've changed the category as pre-RFC and I'll add a few examples to the initial test. That's indeed necessary I agree. --- [Visit Topic](https://discuss.tvm.apache.org/t/commit-message-guideline/12334/7) to respond. You are receiving this beca

[Apache TVM Discuss] [Development/pre-RFC] Commit Message Guideline

Hi Tristan. Good question ;) In a sense that issue could be put into the class of the issues I mentioned as "Github-specif issues", because to me ideally such a comments should never exist in the first place. They exist in my understanding primarily because we want to keep the PR conversation

Re: [apache/tvm-rfcs] [RFC][TVMC] Add support for micro targets (PR #43)

@leandron Thanks a lot for the review. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/43#issuecomment-964728491

Re: [apache/tvm-rfcs] [RFC][TVMC] Add support for micro targets (PR #43)

@mehrdadh thanks for the review! Yes, if a Project API method implementation is absent a `TypeError` will be raised at the server side because the abstract method is not implemented when the Handler class is derived. Also as per https://github.com/apache/tvm-rfcs/blame/main/rfcs/0008-microtvm-p

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] TVMC: Add support for microTVM targets

RFC PR: https://github.com/apache/tvm-rfcs/pull/43 --- [Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-tvmc-add-support-for-microtvm-targets/11221/22) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://

Re: [apache/tvm-rfcs] [RFC][TVMC] Add support for micro targets (PR #43)

cc @areusch @mehrdadh @leandron @guberti -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/43#issuecomment-954271415

[apache/tvm-rfcs] [RFC][TVMC] Add support for micro targets (PR #43)

This RFC is about how TVMC (TVM CLI tool) can be extended to support microTVM targets, considering the variety of platforms supported by microTVM, like Zephyr and Arduino, and also considering future platforms, taking into account the use of custom/adhoc platforms provided by users at their conveni

[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] TVMC: Add support for microTVM targets

@areusch @mehrdadh Thanks for the initial reviews and inputs. I've fixed some grammar in the text I found on the second read and incorporated your suggestions. I believe I can go ahead promoting that to a RFC by creating a PR at https://github.com/apache/tvm-rfcs/ ? --- [Visit Topic](ht

Re: [apache/tvm-rfcs] [RFC][Project API] Extend metadata in ProjectOption (#33)

> @gromero please take a look at the comments here and lmk when it's ready for > another review @areusch Hi. Please take a look. I've also added the text stressing that every option must be associated at least to one API method, as per our discussion last week in the Meetup. Thanks. -- You ar

Re: [apache/tvm-rfcs] [RFC][Project API] Extend metadata in ProjectOption (#33)

> I apologise for the wall of requested changes @gromero, I've been very nit > picky over the clarity of the markdown which I think a find/replace will > almost immediately fix the majority of. > > Overall this all sounds sensible and makes sense to me as a change. @Mousius Actually, thanks a lo

Re: [apache/tvm-rfcs] [RFC][Project API] Extend metadata in ProjectOption (#33)

Thanks a lot for the review @leandron -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/33#issuecomment-920051153

Re: [apache/tvm-rfcs] [RFC][Project API] Extend metadata in ProjectOption (#33)

cc @areusch @manupa-arm -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/33#issuecomment-918581638

[apache/tvm-rfcs] [RFC][Project API] Extend metadata in ProjectOption (#33)

Hi, could the following RFC be reviewed please? It is about extending the current metadata associated with project options returned by the Project API. Thank you. Cheers, Gustavo You can view, comment on, or merge this pull request online at: https://github.com/apache/tvm-rfcs/pull/33 -- Co

Re: [apache/tvm] [VOTE] Adopt New Code Review Guideline (#8928)

+1 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/8928#issuecomment-914211248

Re: [apache/tvm-rfcs] Add Project API RFC (#8)

>> On generate_project method, and considering TVMC, my only comment is that it >> should allow a project creation based also on MLF .tar, instead of only a >> "live" executor. >I agree; let's merge additional logic in project.py to do this as follow-on to >this impl. Sure! I'll submit a follow

[Apache TVM Discuss] [Development/RFC] [RFC] TVMC: Add support for µTVM

> I agree we should support binary output. My thought is this would depend on > the TVM target in use–but we can talk about it Yeah I think so too. Like, I won't be good to always generated a .so and a .o (for example) for the static runtime case, which afaics will only be "interested" in the

[Apache TVM Discuss] [Development/RFC] [RFC] TVMC: Add support for µTVM

> Great, let’s discuss Model Library Format a bit further on another RFC. I > will try to start one early this week. Cool. Thanks :) >>> and a new command `tvmc micro gen-project` (or something) would be added to >>> generate the e.g. Zephyr project. >> >>oh that’s cool. Copying (or generati

[Apache TVM Discuss] [Development/RFC] [RFC] TVMC: Add support for µTVM

Hi Andrew! Thanks a lot for the review. > → First off, I agree with @manupa-arm and @leandron that we should split the > compilation process into two pieces: > > 1. performing `tvm.relay.build` on a model (e.g. `tvmc compile`) > 2. compiling a firmware binary (e.g. `tvmc micro build`) > I thi

[Apache TVM Discuss] [Development/RFC] [RFC] TVMC: Add support for µTVM

Hi Manupa, > So the RPC feels like an optional layer above the runtime that calls into the > runtime. When you have an fully fledged OS we can rely on dlopen to perform > the necessary linking, thus it was not an issue in the non-micro TVM use > cases. > So for tvm micro use-cases that does