From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Pirotte Newsgroups: gmane.lisp.guile.devel Subject: Re: [Guile-Lib PATCH] logger: Add flush-after-emit? property to . Date: Mon, 4 Mar 2024 03:19:08 -0300 Message-ID: <20240304031908.67e08532@tintin> References: <20240302041612.29833-1-maxim.cournoyer@gmail.com> <20240302202542.353ca019@tintin> <87r0gshu6y.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/8CUVIi4ZFpKCHLkBBG3/qag"; protocol="application/pgp-signature"; micalg=pgp-sha512 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29940"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel@gnu.org To: Maxim Cournoyer Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Mar 04 07:20:09 2024 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rh1gG-0007fj-82 for guile-devel@m.gmane-mx.org; Mon, 04 Mar 2024 07:20:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rh1fp-0003TZ-9K; Mon, 04 Mar 2024 01:19:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rh1fm-0003TA-Cg for guile-devel@gnu.org; Mon, 04 Mar 2024 01:19:39 -0500 Original-Received: from smtp.all2all.org ([79.99.200.14] helo=moses.all2all.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rh1fj-0006MU-Kl for guile-devel@gnu.org; Mon, 04 Mar 2024 01:19:37 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by moses.all2all.org (Postfix) with ESMTP id 6873367C007A; Mon, 4 Mar 2024 07:19:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at moses.all2all.org Original-Received: from moses.all2all.org ([127.0.0.1]) by localhost (moses.all2all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4c-57Rs8ahg; Mon, 4 Mar 2024 07:19:31 +0100 (CET) Original-Received: from tintin (unknown [168.227.184.167]) by moses.all2all.org (Postfix) with ESMTPSA id CEFBB67C0074; Mon, 4 Mar 2024 07:19:29 +0100 (CET) In-Reply-To: <87r0gshu6y.fsf@gmail.com> X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) Received-SPF: pass client-ip=79.99.200.14; envelope-from=david@altosw.be; helo=moses.all2all.org X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22337 Archived-At: --Sig_/8CUVIi4ZFpKCHLkBBG3/qag Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Maxim, > ... > My only concern about doing this, rephrasing what I wrote on the chat, > is that it'd be hard to validate the input value, as that validation > would need to be specialized to handlers, e.g. for some class we'd > want to disallow 'line as it wouldn't apply. > That's why I suggested keeping the flush on emit switch as an on/off > boolean, which can live in the base class of all , and > perhaps subclass into which would > accept a #:buffering-mode keyword whose accepted values would mirror > what setvbuf allows (line, block or none). I think that'd simplify > things at the implementation level and avoid user error or surprises. > Our current loggers could be derived from the new > class, while something like a would inherit directly > from , avoiding to handle users providing 'line or 'block > to #:buffering-mode, which would need to throw a user error. > Does that explain my point better (does it make sense?) If so, we can > keep the patch here as-is, and the work to add a new > with a #:buffering-mode keyword would become future work. Yes, it explains your point in a much better way, thanks Please go ahead and push the patch 'as is' ...=20 Cheers, David --Sig_/8CUVIi4ZFpKCHLkBBG3/qag Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhCJlRZtBM3furJHe83T9k6MFetcFAmXlZ9wACgkQ83T9k6MF etd3PAf/RAYZLWB7f7TBK3v2CePDddE84FqoGFzn/btFSB/YMqgDiLCr2dk4de3+ ggwuuwLhRNtek6K3jIy85MKXGCcZ5D/SsX+MqmB2ACiafgvb9MHVBRx5Rx4hU4Sb Mudme41Tw+pZtUnLSPFlyXSh9DTxbITPpdp4f5ANeomL43HsST9HBSRC3I3AH637 VB5NmaG7Lr/CZzbZ+6zEReQYHk/18AGQfwmHqcC8Eva2el2lHW/pSkR2MQ3QoACH DDgZsXJZiVrUgrGKwrS5XyZA8GjtZODgaFaWrE20OdExXTwW90doFfrYjLR/9IPG 5/b1OG1o3DFyUD1On9u8h4HDd72PqQ== =yb94 -----END PGP SIGNATURE----- --Sig_/8CUVIi4ZFpKCHLkBBG3/qag--