From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id E77A5604F5 for ; Tue, 17 Nov 2020 09:48:27 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D9C3BD808 for ; Tue, 17 Nov 2020 09:48:27 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 4CB62D7FE for ; Tue, 17 Nov 2020 09:48:27 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 1C00943614 for ; Tue, 17 Nov 2020 09:48:27 +0100 (CET) To: =?UTF-8?Q?Dominic_J=c3=a4ger?= Cc: Proxmox VE development discussion References: <20201116101457.61771-1-d.jaeger@proxmox.com> <16bc7f15-a092-f021-a710-a1900baf41f6@proxmox.com> <20201117083556.GA1845190@mala.proxmox.com> From: Thomas Lamprecht Message-ID: <5dc95bdf-1ead-f32b-bc28-aeddb9d643fa@proxmox.com> Date: Tue, 17 Nov 2020 09:48:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Thunderbird/83.0 MIME-Version: 1.0 In-Reply-To: <20201117083556.GA1845190@mala.proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.090 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH manager] vzdump mail: Refactor text part X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 08:48:27 -0000 On 17.11.20 09:35, Dominic J=C3=A4ger wrote: > On Mon, Nov 16, 2020 at 06:12:37PM +0100, Thomas Lamprecht wrote: >> >> Or move out even more than just the format string generation out, so t= hat it >> becomes a simple loop calling >> >> $text .=3D render_task_plain($vmid, $task); >> >> or something similar to that. >=20 > my $namelength =3D 20; > $text .=3D sprintf ("%-10s %-${namelength}s %-6s %10s %10s %s\n", > qw(VMID NAME STATUS TIME SIZE FILENAME)); > my $render_task_plain =3D sub { > my ($vmid, $task) =3D @_; > my $successful =3D $task->{state} eq 'ok'; > $text .=3D sprintf("%-10s %-${namelength}s %-6s %10s " . > ($successful ? "%10s": "%8.2fMB")." %s\n", $task->{vmid}, > $name, $task->{state}, format_time($task->{backuptime}), $size, > $filename); > }; > foreach my $task (@$tasklist) { > $text .=3D render_task_plain($vmid, $task); > } >=20 > Not sure about this, we cannot move the heading into render_task_plain = =3D> Still > two format strings? So I don't really see how we would benefit from the= > additional sub. the line rendering is cleanly separated, headings are headings, those are= often separated - one would need a column definition structure to solve t= hat, e.g.: my $columns =3D { 'heading 1' =3D> "%fmt1", 'heading 2' =3D> "%fmt2", }; maybe reusing the exisitng CLI formatter module (with borders disabled) f= rom pve-common could be used? So that we do not have two slightly over engine= ered ways of doing this ^^ But, I'd go for a middle ground for now (see below), as that could be ano= ther wormhole to get pulled into. :) >=20 >> we could avoid the sub and the if by using the $size_conversion direct= ly in >> the format string? >=20 > I personally would prefer this idea. Then we can still decide if we pre= fer > 1. Short, but two format strings written out >=20 > my $namelength =3D 20; > $text .=3D sprintf ("%-10s %-${namelength}s %-6s %10s %10s %s\n", > qw(VMID NAME STATUS TIME SIZE FILENAME)); > foreach my $task (@$tasklist) { > my $successful =3D $task->{state} eq 'ok'; > $text .=3D sprintf("%-10s %-${namelength}s %-6s %10s " .=20 > ($successful ? "%10s": "%8.2fMB")." %s\n", $task->{vmid}, $name, > $task->{state}, format_time($task->{backuptime}), $size, $filename); If, I'd prefer some other formatting, each param on it's own line: my $size_fmt =3D $successful ? "%10s": "%8.2fMB"; $text .=3D sprintf( "%-10s %-${namelength}s %-6s %10s $size_fmt %s\n", $task->{vmid}, $name, $task->{state}, format_time($task->{backuptime}), $size, $filename, ); above format, oriented on what rustfmt normally does for such things, is = IMO more readable than the other proposed variants. > } >=20 > 2. or a longer version. We could put all the decisions into the $fmt s= ub (idea > thanks to Hannes). Then it's a little longer, but relatively easy to re= ad I > think, and has no two written out format strings. >=20 > my $namelength =3D 20; > my $fmt =3D sub { > my ($successful) =3D @_; > my $fmt =3D "%-10s %-${namelength}s %-6s %10s "; > $fmt .=3D $successful ? "%10s": "%8.2fMB"; > $fmt .=3D " %s\n"; > return $fmt; > }; > $text .=3D sprintf ($fmt->(1), qw(VMID NAME STATUS TIME SIZE FILENAME))= ; > foreach my $task (@$tasklist) { > my $name =3D substr($task->{hostname}, 0, $namelength); > my $successful =3D $task->{state} eq 'ok'; > my $size =3D $successful ? format_size ($task->{size}) : 0; > my $filename =3D $successful ? $task->{target} : '-'; > $text .=3D sprintf($fmt->($successful), $task->{vmid}, $name, > $task->{state}, format_time($task->{backuptime}), $size, $filename); > } >=20