From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 3356D384B0C1 for ; Sat, 13 Jun 2020 06:44:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3356D384B0C1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eliz@gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]:53930) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjzuJ-0004D7-Lj; Sat, 13 Jun 2020 02:44:47 -0400 Received: from [176.228.60.248] (port=4122 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jjzuJ-0004Pk-5A; Sat, 13 Jun 2020 02:44:47 -0400 Date: Sat, 13 Jun 2020 09:44:36 +0300 Message-Id: <83k10b4g8b.fsf@gnu.org> From: Eli Zaretskii To: Ludovic =?utf-8?Q?Court=C3=A8s?= , Doug Evans Cc: gdb-patches@sourceware.org In-Reply-To: <874krg8jo9.fsf@gnu.org> (message from Ludovic =?utf-8?Q?Cour?= =?utf-8?Q?t=C3=A8s?= on Fri, 12 Jun 2020 16:04:22 +0200) Subject: Re: [PATCH 1/2] guile: Add support for Guile 2.2. References: <20200612132710.14364-1-ludo@gnu.org> <20200612132710.14364-2-ludo@gnu.org> <83sgf04clq.fsf@gnu.org> <874krg8jo9.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 06:44:49 -0000 > From: Ludovic Courtès > Cc: gdb-patches@sourceware.org > Date: Fri, 12 Jun 2020 16:04:22 +0200 > > > More importantly, I don't understand why we'd want to remove the > > documentation of these functions. Are we removing the functions as > > well (I don't think I saw the code being removed)? If we are not > > removing the functions, why remove their docs? You say that the > > corresponding Guile functionality is superseded by setvbuf, but > > doesn't it mean the GDB-specific capability based on that will be > > rewritten using the new Guile features, and we can continue supporting > > them? > > These four functions are not used in tests, in documented examples, nor > in Guile’s own GDB plugin. > > ‘setvbuf’ is not entirely a drop-in replacement because: (1) it doesn’t > allow you to query a port’s buffer size, only to change it, and (2) it > doesn’t distinguish between the read and write buffers. Consequently, > these functions cannot be implemented on 2.2/3.0, or at least not > easily. > > Since they are unused, and I can’t see a valid use case for those over > ‘setvbuf’, I chose to remove them from the manual as a way to deprecate > them. > > WDYT? So what is the plan wrt GDB accessing memory of the inferior via Guile? Specifically, which parts of the features described in "Memory Ports in Guile" in the manual will continue be supported with Guile 2.2 and later? can we make at least the accessors work with those newer versions of Guile? In any case, I don't like the method of deprecating features by removing their documentation. I think we should say explicitly in that section which methods are deprecated and why. The fact that they are deprecated should also be in NEWS. This all assumes that other GDB developers agree that they are not needed; I don't have enough relevant experience to have an opinion. Maybe Doug (CC'ed) could chime in. I also think that Guile should provide proper replacements for the functionality you mentioned, because evidently at least GDB thought they could be put to good use. But this is outside of the scope of GDB maintenance, something for the Guile developers to consider. > > Also, does any of this need to be called out in NEWS? > > Oh sure. Should that go in a separate commit or in the same? The same is better. > PS: I lost Git access to sourceware.org some years ago because my > registered SSH key was DSA, IIRC. Should I apply to restore it? > What’s the procedure? I think you should write to overseers@sourceware.org and ask them what to do. Thanks.