On Fri, Jun 28, 2019 at 11:03:27AM +0100, Phillip Wood wrote:
> > I considered that, too, but I think it is safe. stdio has its own
> > locking, so every individual call is atomic. The potentially problematic
> > case would be where we switch back from line buffering to no-buffering,
> > and someb
Dear Peff and Dscho
On 27/06/2019 22:10, Jeff King wrote:
> On Thu, Jun 27, 2019 at 02:00:54PM +0200, Johannes Schindelin wrote:
>
>>> We can use setvbuf() to toggle buffering back and forth, but I'm not
>>> sure if there's a way to query the current buffering scheme for a stdio
>>> stream.
>>
>>
Jeff King writes:
> I'm also not entirely convinced it's worth caring about this problem at
> all (whether the solution is buffering here, or just adding the "\n"
> back to the original strings). It's true that p1451 shows off a
> measurable improvement, but I think it's a silly, pathological cas
On Thu, Jun 27, 2019 at 07:32:53PM +0700, Duy Nguyen wrote:
> > It's also not possible for translators to do this by mistake
>
> This (accidentally dropping \n which sometimes is significant) is the
> part that I made me prefer *printf_ln(). I had been translating for
> years, as far back as 2003
On Thu, Jun 27, 2019 at 04:27:07PM +0700, Duy Nguyen wrote:
> > int fprintf_ln(FILE *fp, const char *fmt, ...)
> > {
> > + char buf[1024];
> > int ret;
> > va_list ap;
> > +
> > + /* Fast path: format it ourselves and dump it via fwrite. */
> > + va_start(ap, fm
On Thu, Jun 27, 2019 at 02:00:54PM +0200, Johannes Schindelin wrote:
> > I can get similar speedups by formatting into a buffer:
> [..]
> > But we shouldn't have to resort to that.
>
> Why not?
My thinking was that it was introducing an extra copy of the data. But
on further reflection, it proba
Duy Nguyen writes:
>> without
>> being caught, because msgfmt will catch this (and other common issues):
>>
>> po/de.po:23: 'msgid' and 'msgstr' entries do not both end with '\n'
>
> Ok good. And with the downside of degraded performance, sure remove
> all the *printf_ln()
Sounds good. Than
On Thu, Jun 27, 2019 at 7:18 PM Ævar Arnfjörð Bjarmason
wrote:
> Why shouldn't we just move back to plain fprintf() with "\n"? Your
> 9a0a30aa4b ("strbuf: convenience format functions with \n automatically
> appended", 2012-04-23) doesn't explain why this is a convenience for
> translators.
>
> Wh
On Thu, Jun 27 2019, Duy Nguyen wrote:
> On Thu, Jun 27, 2019 at 1:00 PM Jeff King wrote:
>>
>> On Thu, Jun 27, 2019 at 01:25:15AM -0400, Jeff King wrote:
>>
>> > Taylor and I noticed a slowdown in p1451 between v2.20.1 and v2.21.0. I
>> > was surprised to find that it bisects to bbb15c5193 (fs
Hi Peff,
On Thu, 27 Jun 2019, Jeff King wrote:
> On Thu, Jun 27, 2019 at 01:25:15AM -0400, Jeff King wrote:
>
> > Taylor and I noticed a slowdown in p1451 between v2.20.1 and v2.21.0. I
> > was surprised to find that it bisects to bbb15c5193 (fsck: reduce word
> > legos to help i18n, 2018-11-10).
On Thu, Jun 27, 2019 at 1:00 PM Jeff King wrote:
>
> On Thu, Jun 27, 2019 at 01:25:15AM -0400, Jeff King wrote:
>
> > Taylor and I noticed a slowdown in p1451 between v2.20.1 and v2.21.0. I
> > was surprised to find that it bisects to bbb15c5193 (fsck: reduce word
> > legos to help i18n, 2018-11-1
On Thu, Jun 27, 2019 at 01:25:15AM -0400, Jeff King wrote:
> Taylor and I noticed a slowdown in p1451 between v2.20.1 and v2.21.0. I
> was surprised to find that it bisects to bbb15c5193 (fsck: reduce word
> legos to help i18n, 2018-11-10).
>
> The important part, as it turns out, is the switch t
Taylor and I noticed a slowdown in p1451 between v2.20.1 and v2.21.0. I
was surprised to find that it bisects to bbb15c5193 (fsck: reduce word
legos to help i18n, 2018-11-10).
The important part, as it turns out, is the switch to using fprintf_ln()
instead of a regular fprintf() with a "\n" in it.
13 matches
Mail list logo
