git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Matheus Tavares <matheus.bernardino@usp.br>
Cc: git@vger.kernel.org, gitster@pobox.com,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v3 2/3] t0021: implementation the rot13-filter.pl script in C
Date: Mon, 01 Aug 2022 13:39:08 +0200	[thread overview]
Message-ID: <220801.86h72wi3kr.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <86e6baba460f4d0fce353d1fb6a0e18b57ecadaa.1659291025.git.matheus.bernardino@usp.br>


On Sun, Jul 31 2022, Matheus Tavares wrote:

> +static void reply_list_available_blobs_cmd(void)
> +{
> +	struct hashmap_iter iter;
> +	struct strmap_entry *ent;
> +	struct string_list_item *str_item;
> +	struct string_list paths = STRING_LIST_INIT_NODUP;
> +
> +	/* flush */
> +	if (packet_read_line(0, NULL))
> +		die("bad list_available_blobs end");

Shouldn't anything that's not an OS error (e.g. write error) be a BUG()
instead in this code? I.e. it would be a bug in our own testcode if we
feed the wrong data here, or if pkt-line doesn't work as we expect...

> +
> +	strmap_for_each_entry(&delay, &iter, ent) {
> +		struct delay_entry *delay_entry = ent->value;
> +		if (!delay_entry->requested)
> +			continue;
> +		delay_entry->count--;
> +		if (!strcmp(ent->key, "invalid-delay.a")) {
> +			/* Send Git a pathname that was not delayed earlier */
> +			packet_write_fmt(1, "pathname=unfiltered");
> +		}
> +		if (!strcmp(ent->key, "missing-delay.a")) {
> +			/* Do not signal Git that this file is available */
> +		} else if (!delay_entry->count) {
> +			string_list_append(&paths, ent->key);
> +			packet_write_fmt(1, "pathname=%s", ent->key);
> +		}
> +	}
> +
> +	/* Print paths in sorted order. */
> +	string_list_sort(&paths);
> +	for_each_string_list_item(str_item, &paths)
> +		fprintf(logfile, " %s", str_item->string);
> +	string_list_clear(&paths, 0);
> +
> +	packet_flush(1);
> +
> +	fprintf(logfile, " [OK]\n");

I think it should be called out in the commit message that this is not
what the Perl version is doing, i.e. it does things like:

	print $debug " [OK]\n";
	$debug->flush();

After having previously printed the equivalent of your
for_each_string_list_item() to the log file.

In Perl anything that uses PerlIO is subject to internal buffering,
which doesn't have the same semantics as stdio buffering.

I think in this case it won't matter, since you're not expecting to have
concurrent writers. You could even use fputc() here.

But a faithful reproduction of the Perl version would be something like
appending the output here to a "struct strbuf", and then "flushing" it
at the end when the perl version does a "$debug->flush()".

I don't think that's worth the effort here, and we should just say that
it doesn't matter. I just think we should note it. Thanks!

  parent reply	other threads:[~2022-08-01 11:59 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-22 19:42 [PATCH 0/2] t0021: convert perl script to C test-tool helper Matheus Tavares
2022-07-22 19:42 ` [PATCH 1/2] t/t0021: convert the rot13-filter.pl script to C Matheus Tavares
2022-07-23  4:52   ` Ævar Arnfjörð Bjarmason
2022-07-23  4:59   ` Ævar Arnfjörð Bjarmason
2022-07-23 13:36     ` Matheus Tavares
2022-07-22 19:42 ` [PATCH 2/2] t/t0021: replace old rot13-filter.pl uses with new test-tool cmd Matheus Tavares
2022-07-24 15:09 ` [PATCH v2] t/t0021: convert the rot13-filter.pl script to C Matheus Tavares
2022-07-28 16:58   ` Johannes Schindelin
2022-07-28 17:54     ` Junio C Hamano
2022-07-28 19:50     ` Ævar Arnfjörð Bjarmason
2022-07-31  2:52     ` Matheus Tavares
2022-08-09  9:36       ` Johannes Schindelin
2022-07-31 18:19   ` [PATCH v3 0/3] t0021: convert perl script to C test-tool helper Matheus Tavares
2022-07-31 18:19     ` [PATCH v3 1/3] t0021: avoid grepping for a Perl-specific string at filter output Matheus Tavares
2022-08-01 20:41       ` Junio C Hamano
2022-07-31 18:19     ` [PATCH v3 2/3] t0021: implementation the rot13-filter.pl script in C Matheus Tavares
2022-08-01 11:33       ` Ævar Arnfjörð Bjarmason
2022-08-02  0:16         ` Matheus Tavares
2022-08-09  9:45           ` Johannes Schindelin
2022-08-01 11:39       ` Ævar Arnfjörð Bjarmason [this message]
2022-08-01 21:18       ` Junio C Hamano
2022-08-02  0:13         ` Matheus Tavares
2022-08-09 10:00         ` Johannes Schindelin
2022-08-10 18:37           ` Junio C Hamano
2022-08-10 19:58             ` Junio C Hamano
2022-08-09 10:37         ` Johannes Schindelin
2022-08-09 10:47       ` Johannes Schindelin
2022-07-31 18:19     ` [PATCH v3 3/3] tests: use the new C rot13-filter helper to avoid PERL prereq Matheus Tavares
2022-08-15  1:06     ` [PATCH v4 0/3] t0021: convert perl script to C test-tool helper Matheus Tavares
2022-08-15  1:06       ` [PATCH v4 1/3] t0021: avoid grepping for a Perl-specific string at filter output Matheus Tavares
2022-08-15  1:06       ` [PATCH v4 2/3] t0021: implementation the rot13-filter.pl script in C Matheus Tavares
2022-08-15  1:06       ` [PATCH v4 3/3] tests: use the new C rot13-filter helper to avoid PERL prereq Matheus Tavares
2022-08-15 13:01       ` [PATCH v4 0/3] t0021: convert perl script to C test-tool helper Johannes Schindelin
2022-08-19 22:17         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=220801.86h72wi3kr.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=matheus.bernardino@usp.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).