Thanks @haichen and @tqchen! This is really cool, and new users will certainly
benefit from that.
I'm curious to understand why we are (I assume) self-hosting, rather than using
pypi. Is this due to ASF licensing rules as well?
Also, are the scripts and parameters you're using to generate the
Understood. Thanks @tqchen!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tlcpack-thirdparty-binary-packages/7903/6)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.org/email/uns
I think the idea is good, I remember it was raised on one of the code reviews
by @FrozenGene, to fulfill this use-case of users who are not interested in
`tvmc run` their modules, but instead, want to get an object file to link their
own apps.
The question now is how do we name optional thing
@ztatlock @hogepodge thanks for organising, it was really cool meetup!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/tvm-community-meeting-october-15-2020/8112/3)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here
[quote="tiandiao123, post:11, topic:5165"]
I am wondering how this command line know its input shapes
[/quote]
Hi @tiandiao123, you can check
https://github.com/apache/incubator-tvm/blob/main/python/tvm/driver/tvmc/frontends.py,
where all the input formats are dealt with. This is where we dis
Catching up with all the messages here, it looks like there are two problems
and two solutions for the subsets of `tvmc` commands in discussion:
**P1:** **How can we create something that allows uTVM to be integrated
bare-metal and RTOS?** This is aimed to provide TVM/TVMC as *tools* to be
in
[quote="areusch, post:14, topic:9049"]
by “improving `tvmc compile` to generate a more comprehensive set of outputs in
the Model Library Format,” we are also proposing that the current µTVM
compilation flow be split into two pieces: 1) generating Model Library Format
and 2) building a project
@hogepodge thanks for doing the work on enabling nightly packages.
I got a question about the names of the packages: why do we need to have
different names, as in `tlcpack` and `tlcpack-nightly` being published as
different things?
cc @mjs @manupa-arm @tqchen
---
[Visit
Topic](https://d
Currently we don't do any sort of automated testing to make sure our Docker
images are healthy, so it is not uncommon that the images are sometimes broken
and we don't have visibility of the issues. Only when we decide to update the
images, then it causes massive pain (e.g.
https://github.com
[quote="areusch, post:1, topic:11710"]
* Is this process a reasonable burden to add to the community?
* Are the voting process and comment periods reasonable?
[/quote]
I think both process burden and the proposed timelines to get it done are
adequate. I'm fully supportive of what is proposed he
I think this is a great initiative @pzq. The only suggestion I'd put on top of
it, is that we also can make the Python side to - generally - respect the same
rules, environment variables, etc. Just to keep in mind that we can offer a
better experience for our users if these rules apply more wi
I think every advance that closes the gap between the Docker images being
updated and the PRs is much welcome.
One of the reasons it is not _live_ as it would seem logical to be, is because
of security reasons (based on a chat long ago with @tqchen). We can't blindly
run a docker rebuild for
Thanks @gromero for starting this RFC! I think sorting out commit messages will
have a very good impact down the line in organising the project as a whole.
Adding automation to check/enforce this is a great and I support it very much,
but I think the important thing at project level as a resul
13 matches
Mail list logo