From mboxrd@z Thu Jan  1 00:00:00 1970
From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Subject: Re: [WIP][PATCH] download: Don't report the progress too fast
Date: Wed, 30 Aug 2017 10:45:51 +0200
Message-ID: <87shg978ao.fsf@gnu.org>
References: <87d17ilhzq.fsf@member.fsf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38623)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1dmydK-0001Zx-Ae
	for guix-devel@gnu.org; Wed, 30 Aug 2017 04:45:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1dmydG-0000VV-Dm
	for guix-devel@gnu.org; Wed, 30 Aug 2017 04:45:58 -0400
In-Reply-To: <87d17ilhzq.fsf@member.fsf.org> (=?utf-8?B?IuWui+aWh+atpiIn?=
	=?utf-8?B?cw==?= message of "Sat, 26 Aug 2017 18:51:21 +0800")
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel/>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
To: =?utf-8?B?5a6L5paH5q2m?= <iyzsong@member.fsf.org>
Cc: guix-devel@gnu.org

Hello =E5=AE=8B=E6=96=87=E6=AD=A6,

iyzsong@member.fsf.org (=E5=AE=8B=E6=96=87=E6=AD=A6) skribis:

> Hello, our progress report of 'guix download' can refresh too fast.  For
> example, it blinks much with this script:

Indeed, that=E2=80=99s always annoyed me.  I=E2=80=99m glad you=E2=80=99re =
looking at it!

> I'd like limiting its rate to render every 300ms.  So I write a
> higher-order function that does nothing when the previous invocation not
> happened some time (the interval) ago.  For lacking a proper name in my
> mind, I just call it 'rate-limited'.  Then using it to modify the
> 'progress-proc', let it render every 300ms.
>
> It seems working as I want, but will lost the last report, the progress
> will never finish to 100%...  There is no way to know a report is the
> last or not in the 'progress-proc' with only the 'transferred' parameter
> when the 'size' of file is unknown.

What about sacrificing elegance, and instead put that logic directly in
=E2=80=98progress-proc=E2=80=99 itself, where we know whether we=E2=80=99re=
 at 100% or not?  I=E2=80=99m
very much in favor of pragmatic choices in such circumstances.

(Also, longer-term, we=E2=80=99d want to do that other way around, which is=
 to
update the report every N milliseconds, as opposed to just printing
something when a chunk has been transferred.)

WDYT?

Ludo=E2=80=99.