From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 3AAA73858439 for ; Tue, 14 Feb 2023 13:00:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3AAA73858439 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id B994030067DA; Tue, 14 Feb 2023 14:00:22 +0100 (CET) Received: by r6.localdomain (Postfix, from userid 1000) id 953D73401F4; Tue, 14 Feb 2023 14:00:22 +0100 (CET) Message-ID: Subject: Re: Any concrete plans after the GDB BoF? From: Mark Wielaard To: Andrew Burgess Cc: Simon Marchi , Joel Brobecker , Simon Marchi via Gdb Date: Tue, 14 Feb 2023 14:00:22 +0100 In-Reply-To: <87r0utu6ew.fsf@redhat.com> References: <83485199-965e-7ff5-1dc8-d027b74b56f7@arm.com> <5924814b-2e53-da09-6125-48ac5a5296e7@simark.ca> <87mt5kunum.fsf@redhat.com> <20230212124345.GH2430@gnu.wildebeest.org> <87r0utu6ew.fsf@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) MIME-Version: 1.0 X-Spam-Status: No, score=-3029.9 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Andrew, On Mon, 2023-02-13 at 11:54 +0000, Andrew Burgess wrote: > Mark Wielaard writes: >=20 > > But is there already a verions that works? I think that is the > > difference between the python black formatter for python code and the > > clang-format for C and C++ code. It seems for the python code there is > > a supported format that matches what is used, but for clang-format > > there is not (yet?). >=20 > I'm a little confused by your point here. You (correctly) point out > above that the output from black is pretty stable across versions. >=20 > But here it almost seems like you're suggesting that we should chase the > latest clang-format because it doesn't (currently) support the style we > use. Which would seem to suggest we are hoping it _will_ change, which > suggests output instability, which, surely, is a bad thing? But like I > said, I didn't really understand the question here... Sorry, I was just observing that I believe the python with black case and the C and C++ case with clang-format are not the same. I think we are in agreement that the python case is probably fine (we just disagree about whether it is future proof - I think we can use whatever version of black, you are skeptical that the formatting will stay the same). But for clang-format we don't have a format that seems acceptable (to at least to some people) and older versions seems to produce different formatting from newer versions. Cheers, Mark