[llvm-dev] Email list just for front end developers?

[Perry E. Metzger via llvm-dev]

On Sat, 6 May 2017 21:38:50 -0700 Sanjoy Das
<sanjoy at playingwithpointers.com> wrote:
> Hi Perry,
> 
> On Sat, May 6, 2017 at 2:55 PM, Perry E. Metzger
> <perry at piermont.com> wrote:
> >> Let me put it this way -- I'm pretty sure if you take it on
> >> yourself to answer beginner questions on llvm-dev promptly,
> >> nobody will *complain*.  In fact, you're going to make some
> >> folks happy. :)
> >
> > Sure, but who will answer mine? Part of the reason I asked about
> > this was selfish, as I'd like access to other people in the same
> > situation as me who might know answers. (I don't think the people
> > here now will want to answer more questions, and many of my
> > questions doubtless border on inanely stupid but for the fact
> > that it is hard to find answers in the docs.)
>
> I don't see how people who don't have time to answer on llvm-dev
> will find time to answer on some other mailing list.

My belief was they would be different populations. That is why there
would be a separate list. The other list would attract mostly front
end devs. I would expect front end devs would be both more interested
in a list that discusses mostly things they care about (including IR
changes they need to be aware of) and more interested in mutual
assistance.

But never mind, it seems that I'm the only person who likes that idea,
so we're ignoring that possibility for the moment.

> > That said, I'm willing to give it a try, as an experiment. How
> > long should we attempt it for? If that's reasonably agreed to,
> > I'll
>
> Depends on how much time you have -- that's the limiting resource
> here.

By time I meant the question of how long one tries a strategy before
deciding to look for new strategies. :) Given that few questions about
front end things arrive on the -dev list, trying to help answering
them, for the moment, will only require that I attend more closely to
the postings, and that other people make a bit of an effort to answer
"dumb questions" as well.

Hopefully that will simply work. My skepticism comes from the feeling
that if it was really going to work, it would have already, but
there's no reason not to give it a good faith try.

On the wider issue:

LLVM has been transformative. There are now a lot more people
experimenting with compiling languages than ever before (including
me!) because LLVM removes a lot of the pain from constructing
everything past the IR.

However, until I started working with it personally, I didn't
understand how much work it was to learn how to use it, and much of
that work is because there is a very big gap between the programmers
guide + the tutorial (which makes it all look like you can learn the
whole thing in an afternoon) and what you actually need to figure out
to get things done. Much of what you need you have to puzzle out
painstakingly on your own, trying to make sense of the doxygen docs
and reading code, because there's less written down than one would
hope. Even the IR language reference, which is seemingly complete at
first glance, has some big gaps in it.

Given good enough resources, though, even more people could be using
LLVM to create compilers, which would be a great thing. And,
selfishly, given better resources, my own work would be easier. :)
Thus my overall interest.

> However, I liked your idea of maintaining a wiki-like thing.  Both
> http://llvm.org/docs/Frontend/PerformanceTips.html and
> http://llvm.org/docs/tutorial/ will be good additions there.

Parts of the programmer's manual
http://llvm.org/docs/ProgrammersManual.html are also essential, though
for a front end developer, especially one using the C API, not
everything is something you want to know, and it isn't initially
obvious when you need to read closely.

Anyway, given that you would prefer for it not to be an actual wiki,
what would be lower barrier to entry and Wiki-ish?

(A big issue with the current workflow, I think, is that for outsiders
submitting documentation updates the process is very heavyweight. Even
the use of svn vs. git increases the amount of work for casual users.
It's just not worth it as it stands for someone to say "hey, please
fix just this one sentence", especially if you've never contributed to
LLVM before. However, often even single sentence edits improve
comprehension. Having a low barrier for small fixes is one of the
reasons Wikipedia grew so fast. Of course, it is also the reason that
policing Wikipedia takes huge effort, so there's a tradeoff.)


Perry
-- 
Perry E. Metzger		perry at piermont.com