From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: `message' not outputting the newline "atomically" Date: Mon, 24 Jun 2019 00:09:57 -0400 Message-ID: References: <83y31xr3aa.fsf@gnu.org> <26154872-1a5c-7302-0f32-b16aff8e0ae7@cs.ucla.edu> <83blytq90m.fsf@gnu.org> <95de57fb-ef8c-a65f-d3ca-4a9e7f0f38bc@cs.ucla.edu> <83a7ecquzb.fsf@gnu.org> <83tvckp5ni.fsf@gnu.org> <83r27op1wb.fsf@gnu.org> <60d1b05d-ef4c-252a-0626-8c69c103fdf0@cs.ucla.edu> <83o92rpk1g.fsf@gnu.org> <9d07a8e2-7f9b-bbfa-b73e-0d7aee09b099@cs.ucla.edu> <83zhmankgu.fsf@gnu.org> <31b12a41-18f2-d20c-55dc-28f7adb8606c@cs.ucla.edu> <83y31tm40j.fsf@gnu.org> <83r27kmk2m.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="145861"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 24 06:10:47 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hfGJb-000bpl-2j for ged-emacs-devel@m.gmane.org; Mon, 24 Jun 2019 06:10:47 +0200 Original-Received: from localhost ([::1]:47844 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hfGJZ-0007gF-Qx for ged-emacs-devel@m.gmane.org; Mon, 24 Jun 2019 00:10:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44048) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hfGJ7-0007dn-I8 for emacs-devel@gnu.org; Mon, 24 Jun 2019 00:10:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hfGJ5-0006JA-KV for emacs-devel@gnu.org; Mon, 24 Jun 2019 00:10:17 -0400 Original-Received: from [195.159.176.226] (port=44644 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hfGJ5-0006EJ-Dm for emacs-devel@gnu.org; Mon, 24 Jun 2019 00:10:15 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hfGIz-000bIC-9U for emacs-devel@gnu.org; Mon, 24 Jun 2019 06:10:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:PIVCQ07GzSZPwyzEGvTbOKMwIwA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238082 Archived-At: >> Seeing none of the 32 bytes of fingerprint instead of only seeing the >> first N of them seems like a very minor inconvenient. > > See my other message: seeing the full output could be priceless. Maybe in some hypothetical scenario. FWIW this kind of thing never happened to me, wheres garbled output is something I've seen at least once a week. > Besides, with the current buffering mode you might not see any of the > bytes at all. Yes, that's what I said. And I'm perfectly fine with that. If you think the output of each byte is important, you can add `fflush` in the loop, of course. > (Not that this is a very important example, but I didn't invent it.) In my experience buffered-but-not-printed output is only a problem if the programs gets to another place in the code, such that the lack of output leads you to believe the code hasn't yet reached that code when in fact it's already further. If it crashes in the middle, the actual output doesn't matter: the debugger will immediately tell you where the program was. >> Buffering can indeed be harmful, but only when significant >> computation/time can pass between the `fprintf` and the moment the >> corresponding text is "displayed", which is not the case here (nor >> anywhere else in Emacs's C code, according to my quick "grep stderr"). > The time has no influence on this, because no stdio implementation > I've seen flushes buffers based on time since the last output. It's significant when as a user you expected the output to appear a while ago and it hasn't appeared yet (it leads you to build up a flawed model in your head of what the program is actually doing). In my experience, this is the situation where buffering makes debugging painful. In the present case this is not an issue because the \n is printed right after and causes a flush. >> > So this looks like a net loss to me. >> I don't have a strong opinion on this, but FWIW, I see a net gain and no >> significant loss. > I see a net loss. Yup, we disagree ;-) Stefan