llvm dev - May 2017 - Email list just for front end developers?

On Thu, 11 May 2017 20:14:11 +1000 Dean Michael Berris via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> FWIW, I think the "modern" way of doing any of this is with any
one
> of the following services (that don't need to be owned/maintained
> by the LLVM Foundation):
> 
>   - Stack Overflow (maybe if it gets large enough, get a
"vertical"
> for just LLVM usage)
Unfortunately, stack overflow works best for questions where there
are a lot of people who know the answers and people are willing
to actively log in day after day to answer questions. It works great
for "how do I use SQL to do something" but less well for small
niches. The LLVM questions I've seen posed there seem to usually have
zero or one answers rather than the large number common things get.
>   - Reddit (if there isn't an /r/llvm yet, that might be a good
> "community" place for less llvm-dev worthy material)
Maybe. I like mailing lists because you don't have to poll them.
Having to log in constantly to a service to see if there is
discussion waiting is a bit of a pain. (I have to admit I've never
been much of a reddit fan in general.)
>   - Slack (if there isn't one yet, maybe an llvm-users slack
> instance for more persistent discussions)
There is an IRC channel already, though my experience with it as a
help mechanism has been mixed as it seems more geared towards the
middle and back end. And even if people decided this was a good idea,
without the LLVM foundation documenting it somewhere, no one will
find it.

All that said, I might be wrong and these might be the better path.

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

On 12 May 2017, at 04:03, Perry E. Metzger via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Unfortunately, stack overflow works best for questions where there
> are a lot of people who know the answers and people are willing
> to actively log in day after day to answer questions.
It also works best for answers that are correct for a long time.  Look at
StackOverflow’s C++ section and you’ll find a load of questions where the
flagged-correct answer is pre-C++11 and there’s a much better answer if you use
a current standard.  In comparison to LLVM, C++ evolves very slowly and it’s not
that uncommon for the correct and best answer now to be entirely wrong and
dangerous advice in six months time.

I would be very happy (as someone who has been working on LLVM front ends since
2008) to participate in a front-end developers’ mailing list.

David

If anyone is creating it... I'd be happy to join.

It might be better for the llvm-team also (fewer non llvm-dev emails) and
for us front-end users/developers (even though is interesting, fewer main
team discussions emails).

2017-05-12 12:07 GMT+02:00 David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org>:
> On 12 May 2017, at 04:03, Perry E. Metzger via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Unfortunately, stack overflow works best for questions where there
> > are a lot of people who know the answers and people are willing
> > to actively log in day after day to answer questions.
>
> It also works best for answers that are correct for a long time.  Look at
> StackOverflow’s C++ section and you’ll find a load of questions where the
> flagged-correct answer is pre-C++11 and there’s a much better answer if you
> use a current standard.  In comparison to LLVM, C++ evolves very slowly and
> it’s not that uncommon for the correct and best answer now to be entirely
> wrong and dangerous advice in six months time.
>
> I would be very happy (as someone who has been working on LLVM front ends
> since 2008) to participate in a front-end developers’ mailing list.
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
Best,
Marcelo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170512/bcca97bc/attachment.html>

Hi,


2017-05-11 20:03 GMT-07:00 Perry E. Metzger via llvm-dev <
llvm-dev at lists.llvm.org>:
> On Thu, 11 May 2017 20:14:11 +1000 Dean Michael Berris via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > FWIW, I think the "modern" way of doing any of this is with
any one
> > of the following services (that don't need to be owned/maintained
> > by the LLVM Foundation):
> >
> >   - Stack Overflow (maybe if it gets large enough, get a
"vertical"
> > for just LLVM usage)
>
> Unfortunately, stack overflow works best for questions where there
> are a lot of people who know the answers and people are willing
> to actively log in day after day to answer questions. It works great
> for "how do I use SQL to do something" but less well for small
> niches. The LLVM questions I've seen posed there seem to usually have
> zero or one answers rather than the large number common things get.
>
> >   - Reddit (if there isn't an /r/llvm yet, that might be a good
> > "community" place for less llvm-dev worthy material)
>
> Maybe. I like mailing lists because you don't have to poll them.
> Having to log in constantly to a service to see if there is
> discussion waiting is a bit of a pain. (I have to admit I've never
> been much of a reddit fan in general.)
>
> >   - Slack (if there isn't one yet, maybe an llvm-users slack
> > instance for more persistent discussions)
>
> There is an IRC channel already, though my experience with it as a
> help mechanism has been mixed as it seems more geared towards the
> middle and back end.

I think you should persevere a bit more on the IRC side. Keep in mind that
it is more active during the US timeframe.
Most questions I don't see answered are about specific of the clang
frontend internals, but not about LLVM. I totally expect questions on the
IR Builder to be answered. Some of the questions about "what IR to generate
to do X" are easily answered by "Have you tried clang?" (I
usually followup
with a link to godbolt...).


> And even if people decided this was a good idea,
> without the LLVM foundation documenting it somewhere, no one will
> find it.
>
You're mistaken on the role of the LLVM foundation: it is mostly
administrative.

If you feel something is not documented correctly, please submit a patch.
The LLVM community as a whole is responsible for this.
(you can checkout llvm.org webpages, they are in the SVN repository, and
commit access to LLVM gives you commit access to the website as well).

We may benefit from a more dedicated section of http://llvm.org/docs for
frontend developers, feel free to take the lead on developing such a
section and starting with documentation and examples.
Note I'm not really fond of wiki because 1) it diverges from the way we
handle documentation, 2) it does not integrate with our review flow (commit
mailing list) and 3) it is harder to keep up to date (example in the doc
can come with test that can be part of `make check` so that everyone
maintains it when an API changes).


> All that said, I might be wrong and these might be the better path.

"better" or "best" are hard to predict and evaluate. Also it
is usually in
my opinion a matter of tradeoff: you may win on some aspect but lose on
others. So different people who would weight these aspects differently may
end up on a different conclusion regarding the "better" end results.

About having a mailing list specific for frontend developer, the risk I see
is the same as http://lists.llvm.org/pipermail/cfe-users/ : there may not
be many people there to answer questions. Especially as we're talking about
"unstable" LLVM APIs: the people with all the knowledge are supposed
to on
llvm-dev.
I also think that asking the kind of question you mentioned: "what is the
API to create a global string?" are appropriate to ask on llvm-dev, and
pinging the thread after a few days should help getting an answer
(sometimes I may see such question but I'm busy and figure that someone
else will answer, if there is a ping after a week I'm more likely to spend
some time answering it).

Overall I also agree with Sean that what seems missing in the tutorial is
an overview of how to navigate the LLVM codebase to know where to look to
find the right API for the job.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170520/a8f7b547/attachment-0001.html>