From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170]) by dpdk.org (Postfix) with ESMTP id DB78B37AA for ; Sun, 3 Jan 2016 09:06:29 +0100 (CET) Received: from mhall-osx-home.local (99-34-229-174.lightspeed.sntcca.sbcglobal.net [99.34.229.174]) by mail.mhcomputing.net (Postfix) with ESMTPSA id 14D49BA; Sun, 3 Jan 2016 03:06:28 -0500 (EST) To: dev@dpdk.org References: <20151123071037.GA1771@mhcomputing.net> From: Matthew Hall Message-ID: <5688D684.2070107@mhcomputing.net> Date: Sun, 3 Jan 2016 00:06:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151123071037.GA1771@mhcomputing.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] OK to reindent the pktgen (mix of tabs and spaces, etc.)? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 08:06:30 -0000 Hello, In over a month I didn't get a reply if it would be OK to clean up the inconsistent tabs and spaces indents in the pktgen, to make it easier for the community to read the code and help maintain it and add bug fixes. It would be very helpful if I could get a response and a plan for this if my proposal is not acceptable, or it's not going to be very pleasant to patch any bugs I find when testing it, as some of the stuff I'd want to work on in the pktgen comes from files with weird indentation that is not consistent and thus painful to send patches. Sincerely, Matthew. On 11/22/15 11:10 PM, Matthew Hall wrote: > I would like to reindent it using the following astyle command, with a few > small hand edits past that level, to get it closer to most other DPDK code as > the inconsistent mix of tabs, spaces, etc. makes it difficult to read and > debug when it has issues. > > Obviously the upstream Lua and common/wr_* code would not be included as they > seem to be copied from elsewhere w/ different upstream standards. > > If I were to make the big diff needed for this, would this item be acceptable > upstream? > > Otherwise it is going to be hard to get more people working on the code > reliably as it will be hard for others to follow besides the original authors. > > astyle \ > --max-code-length=132 \ > --style=attach \ > --break-closing-brackets \ > --add-brackets \ > --indent=force-tab=8 \ > --indent-switches \ > --indent-labels \ > --indent-col1-comments \ > --pad-oper \ > --pad-header \ > --unpad-paren \ > --align-pointer=type \ > --align-reference=type \ > --suffix=none \ > --lineend=linux \ > ./app/**/*.{c,h} > > Sincerely, > Matthew. >