Switching http://llvm.org/demo to clang or providing a separate clang demo

I was hoping to show a friend some examples of clang's excellent
diagnostic output (& try out the spellcheck/typo cases) but it seems
that the llvm demo still uses llvm-gcc.

What would it take to switch it over to clang? Is it just a matter of
changing the cgi script to point to clang instead of llvm-gcc, or will
the actual demo machine need configuration changes (
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/demo/index.cgi?view=markup
refers to vadve's home directory
(/home/vadve/shared/llvm-gcc4.0-2.1/bin/)) I wouldn't mind adding some
compiler flags there too - especially C++0x, warning levels, etc.

It also looks like this is pointing to a rather old build of LLVM (2.1).

I was hoping to show a friend some examples of clang's excellent
diagnostic output (& try out the spellcheck/typo cases) but it seems
that the llvm demo still uses llvm-gcc.

Yup, and its several releases old (basically since I stopped being release manager).

What would it take to switch it over to clang? Is it just a matter of
changing the cgi script to point to clang instead of llvm-gcc, or will
the actual demo machine need configuration changes

It takes building and install clang on llvm.org and updating the script.

(
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/demo/index.cgi?view=markup
refers to vadve's home directory
(/home/vadve/shared/llvm-gcc4.0-2.1/bin/)) I wouldn't mind adding some
compiler flags there too - especially C++0x, warning levels, etc.

It also looks like this is pointing to a rather old build of LLVM (2.1).

That is not the the right script. Regardless, I'll try to do this in the next week. I have a busy schedule for the next 2 weeks, so feel free to ping me if I havent done it in a week.

Thanks,
Tanya

Hey David,

This would be really really great, the demo page is long need for a rewrite. FYI the right path to the demo page is here:
http://llvm.org/viewvc/llvm-project/www/trunk/demo/

-Chris

I just noticed that going from the Demo page to Hints section and then to llvm2cpp gives an error (404 Not Found).

It takes building and install clang on llvm.org and updating the script.
... I'll try to do this in the next week.

Cool - thanks. Strangely the (correct) script that Chris linked to his
reply has a clang path in PREPENDPATHDIRS but I don't really know what
it does with it. It looks like, potentially, clang could just be added
as an alternative without any changes to the machine itself (if that
path, /opt/clang-releases/llvm/bin, is usable) though given llvm-gcc's
limited future it might as well be removed.

[Chris]

This would be really really great, the demo page is long need for a rewrite. FYI the right path to the demo page is here:
http://llvm.org/viewvc/llvm-project/www/trunk/demo/

Thanks - I'd gotten the link (& started thinking about the demo page
to see if it had 0x support, etc) from a recent clang checkin. It
looks like it's a clang copy & there's this file:
http://clang.llvm.org/demo/what%20is%20this%20directory.txt

It seems like that directory's a bit redundant & rather than having a
separate clang demo, we'd just update the llvm demo to use clang
instead of llvm-gcc, yes?

I'm wondering what would be the most practical way to work on
improvements. Small ones that don't require testing (if there's
already support for one command line argument, say, then adding more
shouldn't be painful/hard/risky) I can submit patches for & wait for
them to go live, but I wouldn't want to burden the list with lots of
patches as a means of developing/debugging/fixing changes when they go
live. I guess it would be easier for someone with direct access to the
machine to just hack at the script & check the changes live, then
checkin the result.

But I'm happy to have a crack at blind/unvalidated patches to improve
the functionality if that's useful.

- David

This would be really really great, the demo page is long need for a rewrite. FYI the right path to the demo page is here:
http://llvm.org/viewvc/llvm-project/www/trunk/demo/

Thanks - I'd gotten the link (& started thinking about the demo page
to see if it had 0x support, etc) from a recent clang checkin. It
looks like it's a clang copy & there's this file:
http://clang.llvm.org/demo/what%20is%20this%20directory.txt

It seems like that directory's a bit redundant & rather than having a
separate clang demo, we'd just update the llvm demo to use clang
instead of llvm-gcc, yes?

yes, I had no idea we had a clang/demo. We should just make it be the llvm demo page.

I'm wondering what would be the most practical way to work on
improvements. Small ones that don't require testing (if there's
already support for one command line argument, say, then adding more
shouldn't be painful/hard/risky) I can submit patches for & wait for
them to go live, but I wouldn't want to burden the list with lots of
patches as a means of developing/debugging/fixing changes when they go
live. I guess it would be easier for someone with direct access to the
machine to just hack at the script & check the changes live, then
checkin the result.

I'd suggest copying this to "demo/index2.cgi" and leaving the original alone. Hack it up all you want, and play with it live. When you're happy with it, we can talk about switching it over as the default, replacing the old one. Seem reasonable?

-Chris

I'd suggest copying this to "demo/index2.cgi" and leaving the original alone. Hack it up all you want, and play with it live. When you're happy with it, we can talk about switching it over as the default, replacing the old one. Seem reasonable?

Sure - works for me. Though it'll be a little noisy to the commits
list, perhaps - and I'll likely need commit privileges to make the
most of it.

Another minor detail: How does the llvm.org website get updated from
svn submissions? Some kind of trigger?

- David

I'd suggest copying this to "demo/index2.cgi" and leaving the original alone. Hack it up all you want, and play with it live. When you're happy with it, we can talk about switching it over as the default, replacing the old one. Seem reasonable?

Sure - works for me. Though it'll be a little noisy to the commits
list, perhaps - and I'll likely need commit privileges to make the
most of it.

Okay, this is a good point, it's probably best to try to do most of this locally, then push out tested patches. It can still be to an alternate version of the script until it's ready to go, but it would be best to avoid the thrash.

Another minor detail: How does the llvm.org website get updated from
svn submissions? Some kind of trigger?

It's auto-updated as a post-commit hook.

-Chris

Okay, this is a good point, it's probably best to try to do most of this locally, then push out tested patches. It can still be to an alternate version of the script until it's ready to go, but it would be best to avoid the thrash.

Ok - I'll see about setting up a local mirror/experimental area
locally when I get a chance.

Thanks,
- David

Okay, this is a good point, it's probably best to try to do most of this locally, then push out tested patches. It can still be to an alternate version of the script until it's ready to go, but it would be best to avoid the thrash.

Ok - I'll see about setting up a local mirror/experimental area
locally when I get a chance.

Seems someone else got to this a while ago, but perhaps didn't quite
get enough feedback or have enough time to see it through:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038828.html
http://llvm.org/bugs/show_bug.cgi?id=1440

If someone wants to give feedback on the changes posted in the bug I
can try to update it, or we can start again from scratch.

I'm just working on getting this setup myself so I can see how it
looks/works locally.

- David

Aha, this is the problem with attaching patches to bugs: noone sees them. It is *much much* better to send patches to a -commits list.

The patch looks like reasonable progress to me!

-Chris

FYI, I have moved the demo page over to use Clang. Chris wants me to output assembly too, so I'll add that shortly.

-Tanya

FYI, I have moved the demo page over to use Clang. Chris wants me to output assembly too, so I'll add that shortly.

Yep, I just saw - it looks good with clang diagnostic output, etc. Thanks

I'll try my hand at colorizing(& bolding as appropriate) the clang
diagnostic output at some point soon.

- David

Seems someone else got to this a while ago, but perhaps didn’t quite
get enough feedback or have enough time to see it through:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038828.html
http://llvm.org/bugs/show_bug.cgi?id=1440

If someone wants to give feedback on the changes posted in the bug I
can try to update it, or we can start again from scratch.

I’m just working on getting this setup myself so I can see how it
looks/works locally.

Aha, this is the problem with attaching patches to bugs: noone sees them. It is much much better to send patches to a -commits list.

The patch looks like reasonable progress to me!

So, colored clang diagnostics finally work :slight_smile: & as a side-benefit, I got around to setting up my own demo test area (it actually wasn’t too painful at all - the cgi script’s fairly standalone, just had to point it to my llvm install & away it went - great) so I should be able to prototype stuff there & submit fairly sane patches directly against www/demo/index.cgi without too much churn.

So, now to figure out what to do with the page. The bug/patch I mentioned above seems to still have some outstanding issues (given the discussion in the bug itself) - cross compiling on the demo machine/website won’t come for free. Any ideas on what we should do there? Should we actually get the demo machine setup with all the necessary libs/things to do real cross compilation?

I’d like to roll in whatever work was already done for that patch that’s actually applicable before I go forward with my own ideas. But for myself, the first thing I’d work on (& have worked up partially on my prototype site) is C++ version selection (could be generalized to all language versions supported by clang) and library selection (would require libc++ to be installed on the demo server, if it’s not already there).

Any particular end goal you have in mind that would be worth doing some up-front design for, or is it good to just go adding these little bits on here & there & then try to redesign if we see a way to make it all fit together better?

  • David

Seems someone else got to this a while ago, but perhaps didn’t quite
get enough feedback or have enough time to see it through:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038828.html
http://llvm.org/bugs/show_bug.cgi?id=1440

If someone wants to give feedback on the changes posted in the bug I
can try to update it, or we can start again from scratch.

I’m just working on getting this setup myself so I can see how it
looks/works locally.

Aha, this is the problem with attaching patches to bugs: noone sees them. It is much much better to send patches to a -commits list.

The patch looks like reasonable progress to me!

So, colored clang diagnostics finally work :slight_smile: & as a side-benefit, I got around to setting up my own demo test area (it actually wasn’t too painful at all - the cgi script’s fairly standalone, just had to point it to my llvm install & away it went - great) so I should be able to prototype stuff there & submit fairly sane patches directly against www/demo/index.cgi without too much churn.

So, now to figure out what to do with the page. The bug/patch I mentioned above seems to still have some outstanding issues (given the discussion in the bug itself) - cross compiling on the demo machine/website won’t come for free. Any ideas on what we should do there? Should we actually get the demo machine setup with all the necessary libs/things to do real cross compilation?

I wonder what the real benefit is here though versus the cost? If we are just trying to give a quick demo of LLVM/Clang, then how much value is in supporting multiple targets?

Also, whats the benefit in demoing targets that are not officially supported by releases?

I’d like to roll in whatever work was already done for that patch that’s actually applicable before I go forward with my own ideas. But for myself, the first thing I’d work on (& have worked up partially on my prototype site) is C++ version selection (could be generalized to all language versions supported by clang) and library selection (would require libc++ to be installed on the demo server, if it’s not already there).

I do think there are many things we could be displaying that Clang supports that we are not.

Any particular end goal you have in mind that would be worth doing some up-front design for, or is it good to just go adding these little bits on here & there & then try to redesign if we see a way to make it all fit together better?

I personally don’t have any ideas for the demo page, but anything you come up with I say go ahead and prototype if its small and anything large, I’d send to the list for discussion before spending a lot of time on it. I’m sure some of the active Clang developers may have opinions.

Thanks,
Tanya

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038828.html
http://llvm.org/bugs/show_bug.cgi?id=1440

So, now to figure out what to do with the page. The bug/patch I mentioned above seems to still have some outstanding issues (given the discussion in the bug itself) - cross compiling on the demo machine/website won’t come for free. Any ideas on what we should do there? Should we actually get the demo machine setup with all the necessary libs/things to do real cross compilation?

I wonder what the real benefit is here though versus the cost? If we are just trying to give a quick demo of LLVM/Clang, then how much value is in supporting multiple targets?

Also, whats the benefit in demoing targets that are not officially supported by releases?

For myself I’m not sure how the cost/benefit ratio comes out - both are fairly unknown to me. Mostly I was bringing this up to make sure the existing outstanding work, patch, and bug were resolved rather than left to rot some more. More or less I’m asking Chris if, given the points raised in the bug regarding multi-architecture targeting, he still felt it was something worth pursuing or not.

Thanks,

  • David

Are you interested in showing the -S output? I think it would be nice to be able to get (for example) ARMv7 and X86 output. I don’t think that going farther than that is a good idea though.

-Chris

Personally, I don’t have much interest in the back end side of things - for myself I’ll be more interested in improving the front end (C++0x, libc++, the static analyzer, maybe post-fixit code, etc). But I don’t want to work on lots more changes to the page while there’s still some pending work here that would be easier to use now than later.

Since Duncan brought up the major objection to producing incorrect assembly (due to not actually having a full cross-compiling story on the demo machine) I’ve included him on this mail.

I guess your take on it, Chris, was that what Bjarke put together is all you were interested in - demoing the ability for LLVM to produce multiple architecture assembly & it’s not too important to you if the libraries don’t match the target platform, etc. (I’m sure a lot of experiments on the demo page like that might not even use any libraries explicitly anyway)?

I’ll take another look at Bjarke’s patch & see about getting it up to date with the current code, maybe stripping out the extra architectures & bringing it back down to x86 and ARM so we have a talking point.

  • David

It’s true that headers wouldn’t be the right “cross compiling headers”, but I think that’s ok. The users of the demo page are not going to run the generated .s code, and x86-32 and ARM are pretty close (both 32-bit little endian). Another option is to just add X86-32/64.

-Chris

It’s true that headers wouldn’t be the right “cross compiling headers”, but I think that’s ok.

I don’t have a strong feeling either way - Duncan did, so perhaps he’ll speak up.

The users of the demo page are not going to run the generated .s code, and x86-32 and ARM are pretty close (both 32-bit little endian).

Another option is to just add X86-32/64.

That seems like a safe option to begin with & justifies adding the infrastructure such that the incremental cost of adding/removing ARM is low. I’ll look into Bjarke’s patch to see about isolating just that behavior for now (or all of his patch & see if anyone’s strongly opposed enough to veto the CR and/or change it back).

Thanks,

  • David