similar to: [Incubation] Request to incubate mlir-npcomp

On Wed, Jun 24, 2020 at 9:54 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: > On Tue, Jun 23, 2020 at 2:40 PM Stella Laurenzo via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > We originally started it as a fork of the LLVM repository, but > transitioned to the MLIR standalone template, and we found it more > productive to iterate out of tree in this fashion,

> On Jun 24, 2020, at 9:53 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, Jun 23, 2020 at 2:40 PM Stella Laurenzo via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> We originally started it as a fork of the LLVM repository, but transitioned to the MLIR standalone template, and we found it more productive to iterate out of tree in

Uh-oh: Failed to publish: GitHub error 404 on POST https://api.github.com/repos/llvm/mlir-npcomp/pulls/42/reviews: Not Found (The llvm organization may need to authorize Reviewable as an accepted third party application.) Can an admin take the suggested action on the mlir-npcomp project in the LLVM org? I've followed the instructions in this help doc

The idea of adding an “incubation” stage to projects in the LLVM world seems to be positively received. I also noticed that we don’t really document the new project policy in general in the LLVM Developer Policy. To help with both of these Stella and I worked together to draft up a new section for the LLVM developer policy (incorporating the existing “New Targets” section). Ahead of proposing a

Hi all, Today, we maintain a high bar for getting a new subproject into LLVM: first a subproject has to be built far enough along to “prove its worth” to be part of the LLVM monorepo (e.g. demonstrate community, etc). Once conceptually approved, it needs to follow all of the policies and practices expected by an LLVM subproject. This is problematic for a couple reasons: it implicitly means that

For the past several months, members of the ‘CIRCT’ group have been working to begin adapting MLIR for hardware design. We believe that this area would benefit from good open source infrastructure enabling research and, eventually, the next generation of commercial tools. We have collected several dialects and envision a number of lowering flows using these dialects. We have reached the point

Sure, I'll summarize with respect to the criterion in the document: - Must be generally aligned with the mission of the LLVM project to advance compilers, languages, tools, runtimes, etc. CIRCT is a compiler which is built around LLVM/MLIR. We anticipate building code generation for ASIC and FPGA backends along with specialized accelerators, while leveraging existing LLVM backends for

This looks to be a reasonable starting point. A couple of nit picks, none are blockers. 1. I'd hold off on handing out the sub-domain for the moment. This feels more official than we probably want for a random incubator.  I reserve the right to change my mind here, but maybe we should delay this part until we see what actual incubators look like?  As an alternative, maybe

Hah, whoops, sorry about that. This is the correct link: https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit <https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit> -Chris > On Jun 30, 2020, at 1:41 PM, Thomas Lively <tlively at google.com> wrote: > > Hi Chris, > > I'm also seeing an access denied

Has anyone tried out reviewable.io yet? It integrates with GitHub pull requests, but provides a separate UI for doing the review which promises to fix a lot of the issues encountered with Github's review interface. Some of the things it claims to support which seem like important additions: - Tracking the resolved status of each discussion point - Rebasing a PR without losing review history.

> On Jun 30, 2020, at 11:52 AM, Roman Lebedev <lebedev.ri at gmail.com> wrote: > > On Tue, Jun 30, 2020 at 9:44 PM Chris Lattner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> The idea of adding an “incubation” stage to projects in the LLVM world seems to be positively received. I also noticed that we don’t really document the new project policy in

On 04/06/18 13:51, Ulf Volmer wrote: > On 06.04.2018 18:25, m.roth at 5-cent.us wrote: >> CentOS 7 box. As there's no package in any of the repos, we're trying to >> install scikit-learn in the user's space. It refuses. My late try was, >> after d/l a .whl from last year, hoping that would work with the numpy >> package in the regular repos, I did a pip

Valeri Galtsev wrote: <snip> >>> On Fri, 6 Apr 2018 17:25 , <m.roth at 5-cent.us> wrote: >>> >>>> CentOS 7 box. As there's no package in any of the repos, we're trying >>>> to install scikit-learn in the user's space. It refuses. My late try was, >>>> after d/l a .whl from last year, hoping that would work with the numpy

Hola erreros Estoy rizando el rizo con esto de las matrices sparse y he encontrado la forma de hacerlo en python, que va rapidísimo. Por tanto tengo una matriz sparse en un objeto python con esta info: <138493x26744 sparse matrix of type '<type 'numpy.int64'> Quiero hacer lo mismo con R pero me he topado con la lentitud de los bucles para rellenar la sparse (también por mi

CentOS 7 box. As there's no package in any of the repos, we're trying to install scikit-learn in the user's space. It refuses. My late try was, after d/l a .whl from last year, hoping that would work with the numpy package in the regular repos, I did a pip install --user scikit-learn..., and it still seems to want to write to system space: OSError: [Errno 13] Permission denied:

How difficult is it to get a good feel for the internals of R, if you want to learn the general code base, but also the CPU intensive stuff ( much of it in C or Fortran?) and the ways in which the general code and the CPU intensive stuff is connected together? R has a very large audience, but my understanding is that only a small group have a good understanding of the internals (and some of those

> On Jul 8, 2020, at 8:52 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > It would be nice to have an external MLIR user in the project, and > this project seems really well organised and relevant. +1 from me, > too. I think that flang beat us to the punch as the first external MLIR user :-) but thank you for your support Renato! -Chris > > On

Hi Steve, Thanks for the update! This will fix the ugliest hack I have on my build script. I know I wasn't doing the nicest thing, but it's nice to see that what I needed wasn't that far away. I'll update my scripts and get back to you. Really appreciate, thanks! Renato On Fri, 10 Jul 2020, 07:59 Stephen Neuendorffer, < stephen.neuendorffer at gmail.com> wrote: >

Renato, I'm happy to kibitz on the build problems. Cmake seems to be working well at this point for us, but it took quite a bit to get there and there are some pitfalls. I'm aware of some namespace issues in mlir, but haven't gotten around to dealing with them. Steve On Thu, Jul 9, 2020, 3:47 AM Renato Golin <rengolin at gmail.com> wrote: > On Wed, 8 Jul 2020 at 22:43,

Richard Demeny wrote: > Just sudo it > > On Fri, 6 Apr 2018 17:25 , <m.roth at 5-cent.us> wrote: > >> CentOS 7 box. As there's no package in any of the repos, we're trying to >> install scikit-learn in the user's space. It refuses. My late try was, >> after d/l a .whl from last year, hoping that would work with the numpy >> package in the