On Tue, Mar 29 2022, Teng Long wrote:

quoted

Was there an on-list v0 (RFC?) or is this a range-diff against nothing?
Best not to include it until a v2 then.

My careless, there's no RFC, actually this patch should begin with v0 and
without range-diff.

No worries.

quoted

Sometimes it's better to split up patches, but I think these 3x should
really be squashed together. We make incremental progress to nowhere in
1/3 and 2/3, and it all comes together in 3/3. The 1-2/3 are trivial
enough that we can squash them in.

Sure.

quoted

+	trace2_data_string("midx", r, "core.multipackIndex",
+						   r->settings.core_multi_pack_index ? "true" : "false");

Weird indentation here.

Will fix.

*Nod*

quoted

I.e. surely you just want to create a region, and if you care enough to
log failure shouldn't we log that in open_midx_bitmap_1() if we care,

Actually, I just want to use "trace2_data_string()" at first because which informations I
want to append is not so many, or does "create a region" a preferred principle for using
TRACE2 APIs?

I think a begin/end region gives you everything you want here and more, i.e.:

 * We'll get start/end times on this (potentially expensive?) operation
   automatically.

 * You just log a "failed", but as the RFC-on-top shows we can just log
   the specific reason instead, either via error(), warning() or perhaps
   even trace2_data_string(). because it's within a region it'll be
   clear from the data what failed.

B.t.w. I noticed after sending that that this ad-hoc patch fails the
tests, it passed the one bitmap test I hacked it up against.

It was just there to make the point/demo that it looked easier to do
this one function call above where you were adding this.

quoted

and perhaps error() there instead of silently returning -1?

I think so, after I checked function "error_builtin()" and there is a "trace2_cmd_error_va()"
usage in it which is already support to print some debug infos using TRACE2 envs.

Exactly.