similar to: [LLVMdev] expand tabs in test

Anyone out there interested in helping out with a subversion pre-commit hook to: - remove trailing whitespace, - expand tabs to spaces, - detect 80-col violations, as well as detect other style guideline breakage? I just ran into the trailing whitespace problem: Eclipse and other editors like to trim excess whitespace from source. However, when one commits a patch with trailing whitespace

On Tue, Feb 17, 2009 at 2:35 PM, Mike Stump <mrs at apple.com> wrote: > On Feb 17, 2009, at 2:21 PM, Scott Michel wrote: > > - remove trailing whitespace, > > - expand tabs to spaces, > > I'd argue for not changing anything, just fail it. > Trimming whitespace is innocuous, at best. Expanding tabs to spaces, I might be inclined to agree is a 'fail' since

Here's a simple one to expand the remaining tabs in llvm: -------------- next part -------------- A non-text attachment was scrubbed... Name: tabs-4.patch Type: application/octet-stream Size: 676 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080406/e2444d58/attachment.obj> -------------- next part --------------

On May 9, 2008, at 3:10 AM, Nicolas Capens wrote: > Please note that I'm not trying to compile from C code, I try to > generate > functions at run-time directly. I want to keep it target-independent > too, so > I can't use intrinsics either. Ah, but you can use any intrinsic that is target independent.... The gcc vector stuff is meant to work on all targets as I

On Feb 18, 2009, at 1:41 AM, Julien Lerouge wrote: > Yet another _fun_ way of doing this is to setup a buildbot slave just > for that. The slave can fix minor stuff like tabs and trailing > whitespaces on its own (checking the changes back in), and yell for > things like 80-col violations and whatnot where the changes would > not be > so trivial. If you're going to change

On Thu, Jul 3, 2008 at 9:09 AM, Devang Patel <dpatel at apple.com> wrote: >> On Wed, Jul 2, 2008 at 7:00 PM, Mike Stump <mrs at apple.com> wrote: >>> If we apply their logic to llvm, we can dominate, if we just target 8 >>> cores. :-) > > Does this mean llvm can not dominate if llvm target 1 core machine > also ? Making an optimizer/code generator

- Devang On May 9, 2008, at 5:03 PM, Mike Stump <mrs at apple.com> wrote: > > Ah, but you can use any intrinsic that is target independent.... The > gcc vector stuff is meant to work on all targets as I recall. Do you mean GCC has target independent vector intrinsics?

On Wed, Jul 2, 2008 at 7:00 PM, Mike Stump <mrs at apple.com> wrote: > On Jul 2, 2008, at 4:39 PM, Eli Friedman wrote: >> Another perspective on this sort of issue, if you haven't seen it: >> http://weblogs.mozillazine.org/roc/archives/2007/10/ >> tablua_fracta.html. > > If we apply their logic to llvm, we can dominate, if we just target 8 > cores. :-)

On Fri, May 9, 2008 at 8:42 PM, Devang Patel <dpatel at apple.com> wrote: > > > - > Devang > > On May 9, 2008, at 5:03 PM, Mike Stump <mrs at apple.com> wrote: >> >> Ah, but you can use any intrinsic that is target independent.... The >> gcc vector stuff is meant to work on all targets as I recall. > > Do you mean GCC has target independent

On Jul 3, 2008, at 10:28 AM, Eli Friedman wrote: > On Thu, Jul 3, 2008 at 9:09 AM, Devang Patel <dpatel at apple.com> wrote: >>> On Wed, Jul 2, 2008 at 7:00 PM, Mike Stump <mrs at apple.com> wrote: >>>> If we apply their logic to llvm, we can dominate, if we just >>>> target 8 >>>> cores. :-) >> >> Does this mean llvm can

On Feb 17, 2009, at 2:21 PM, Scott Michel wrote: > - remove trailing whitespace, > - expand tabs to spaces, I'd argue for not changing anything, just fail it.

> On Wed, Jul 2, 2008 at 7:00 PM, Mike Stump <mrs at apple.com> wrote: >> If we apply their logic to llvm, we can dominate, if we just target 8 >> cores. :-) Does this mean llvm can not dominate if llvm target 1 core machine also ?

On Tue, Feb 17, 2009 at 02:21:23PM -0800, Scott Michel wrote: > Anyone out there interested in helping out with a subversion pre-commit hook > to: > > - remove trailing whitespace, > - expand tabs to spaces, > - detect 80-col violations, > > as well as detect other style guideline breakage? > > I just ran into the trailing whitespace problem: Eclipse and other

For the complete truth in advertising, this was pretty much a trial balloon to gauge reaction. I'm not a big fan of rejecting commits for style violations, but the dev guide has certain guidelines regarding formatting and style. And we're all supposed to be good citizens... My biggest nit, however, was contemplating a commit where 80%+ was trailing whitespace trimming. Yeah, my editor

Some lines are indented by tabs and some lines are indented by spaces, in R source code. This might due to the fact that the source code is not from a single person. But I think that it is better to enforce a single convention. My editor defaults a tab to 8 spaces. So some source doesn't seem to be indented correctly in my editor. Since tab may be displayed differently in different editor, I

On Aug 13, 2008, at 10:11 AM, Devang Patel wrote: > On Aug 12, 2008, at 9:05 PM, Bill Wendling wrote: >> For some reason, they placed a whole bunch of >> ObjC-building code into darwin.c, then had it call this function in >> darwin-c.c. If I try to put that function into darwin.c, all hell >> breaks loose. So even though the Fortran stuff wouldn't call the >>

On Oct 31, 2008, at 9:44 AM, Devang Patel wrote: >>> f951: warning: command line option "-Wformat" is valid for C/C++/ >>> ObjC/ObjC++ but not for Fortran > Try this not so elegant and untested patch. I'd not expect this to work for Ada, java or Pascal.

On Oct 30, 2008, at 11:02 PM, Chris Lattner wrote: > On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: >> ps We do have one oddity left in llvm-gfortran from current llvm >> svn. I find everytime I compile something with llvm-gfortran that >> I get a series of warning messages... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/

On Oct 8, 2009, at 5:18 PM, Mike Stump wrote: > On Oct 8, 2009, at 4:52 PM, Stuart Hastings wrote: >> Currently, to get LLVM to build "Apple-style," it's necessary to >> copy two files (utils/buildit/GNUmakefile and utils/buildit/ >> build_llvm) into the top-level directory. > > Why not: > > $ RC_ARCHS="x86" make > echo Apple Build.

>From 6f128e90afb055f9899011c4a592eb289e678936 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Thu, 19 Nov 2009 11:39:10 +0100 Subject: [PATCH libguestfs] syntax-check: expand TABs in generator.ml * src/generator.ml: Expand leading TABs to spaces. --- src/generator.ml | 46 +++++++++++++++++++++++----------------------- 1 files changed, 23 insertions(+), 23