[9fans] Bug in print(2) g verb

[9fans] Bug in print(2) g verb

[Paul Patience]

I already sent this mail, but it seems that 9fans didn't
receive it.

The g verb in print(2) does not work properly. The precision
flag (%.ng) is supposed to print n significant figures, but
it prints n+1 significant figures. This change fixes this
behaviour.

diff -r d6b623d4cac0 sys/src/libc/fmt/fltfmt.c
--- a/sys/src/libc/fmt/fltfmt.c	Sat Feb 23 14:05:51 2013 +0100
+++ b/sys/src/libc/fmt/fltfmt.c	Wed Feb 27 15:59:34 2013 -0500
@@ -187,6 +187,8 @@
 	 * c3 digits of trailing '0'
 	 * c4 digits after '.'
 	 */
+	if(chr == 'g') /* Significant figures. */
+		prec--;
 	c1 = 0;
 	c2 = prec + 1;
 	c3 = 0;

Re: [9fans] Bug in print(2) g verb

[Rob Pike]

In plan9port at least, it seems correct.

%.5g prints 12346 given 12345.67890.

Do you have an example it gets wrong?

-rob

Re: [9fans] Bug in print(2) g verb

[Paul A. Patience]

Without the change, it should get
any example wrong. This is with
native Plan 9, though. Plan9port's
fltfmt.c is not the same, so it must
be working correctly.

term% cat foo.c
#include <u.h>
#include <libc.h>

void
main(void)
{
	print("%.5g\n", 12345.67890);
	exits(nil);
}
term% 8.out
12345.7

Re: [9fans] Bug in print(2) g verb

[Kurt H Maier]

On Thu, Feb 28, 2013 at 04:08:24PM -0800, Rob Pike wrote:
> In plan9port at least, it seems correct.

He wasn't asking about plan9port.

Re: [9fans] Bug in print(2) g verb

[Rob Pike]

But the code looks the same in plan9port at that point. So it looks
like a fix was made somewhere else in that file and not put back into
the Plan 9 sources. The proposed fix is perhaps not the best one.

-rob

Re: [9fans] Bug in print(2) g verb

[Steve Simon]

> So it looks
> like a fix was made somewhere else in that file and not put back into
> the Plan 9 sources.

Just an idea, but now that gcc has kenc compatibility modes thanks to a GO author,
plan9ports could be merged back with mainline plan9 to a large extent.
It could then become a much smaller porting layer and a script which pulls
down much of /sys/src/cmd from plan9.

The idea is for both communities to take advantage of each others bug fixes
and enhancements.

This relies on gcc running everywhere p9p runs (which may or may not be true),
and somone with the time to do the work...

-Steve

Re: [9fans] Bug in print(2) g verb

[Anthony Sorace]

On Mar 1, 2013, at 10:58, "Steve Simon" <steve@quintile.net> wrote:

> This relies on gcc running everywhere p9p runs...

s/gcc/sufficiently modern gcc/
I think that's the bigger issue. How far back in time is p9p looking to support platforms from? I have at least one box in the basement with a much older gcc on it. In my particular case, nothing prevents me from upgrading (except how painful dealing with gcc is), but I doubt that's true for everyone.

Relatedly, does anyone happen to know whether clang/llvm have these extensions as well?

Re: [9fans] Bug in print(2) g verb

[Paul A. Patience]

Plan9port's implementation of fltfmt.c seems
different enough to me that it isn't possible to
simply take the fix from there and add it to
plan9. Perhaps I'm missing something.

The g verb already acts differently in plan9port
and native plan 9: print("%g\n", 0.1) prints .1 in
plan 9 and 0.1 in plan9port. I don't why they're
different, but the former behaviour is unfortunate
for the native port of awk I am completing
(started by boyd).

Others are of course welcome to come up with fixes
for this problem.

Re: [9fans] Bug in print(2) g verb

[erik quanstrom]

On Fri Mar  1 17:54:53 EST 2013, paul-a.patience@polymtl.ca wrote:
> Plan9port's implementation of fltfmt.c seems
> different enough to me that it isn't possible to
> simply take the fix from there and add it to
> plan9. Perhaps I'm missing something.
>
> The g verb already acts differently in plan9port
> and native plan 9: print("%g\n", 0.1) prints .1 in
> plan 9 and 0.1 in plan9port. I don't why they're
> different, but the former behaviour is unfortunate
> for the native port of awk I am completing
> (started by boyd).
>
> Others are of course welcome to come up with fixes
> for this problem.

here are all the places where %g is used with a prec.
i think this should be trivial to fix.  we just
need to agree to fix it.  i would vote for fixing it.

- erik

---
chula; g '%([# +]|-)?([*0-9]+)?(\.[*0-9]+)g' /sys/src|grep -v printf|grep -v '/awk/|/gs/'
/sys/src/ape/lib/fmt/test.c:34: 	print("%2.18g\n", 1.0);
/sys/src/cmd/aux/msexceltables.c:286: 					Bprint(bo, "%-*.*g", min, max, c->number);
/sys/src/cmd/aux/vga/main.c:331: 			trace("refresh %.1g\n", rr);
/sys/src/cmd/aux/vga/main.c:333: 				fprint(2, "reducing %.1g to 85Hz\n", rr);
/sys/src/cmd/du.c:65: 		print("%.6g%s\t%q\n", val, pfxes[scale], name);
/sys/src/cmd/du.c:67: 		print("%.6g\t%q\n", (double)amt/unit, name);
/sys/src/cmd/hoc/code.c:586: 	print("%.12g\n", d.val);
/sys/src/cmd/hoc/code.c:595: 	print("%.12g ", d.val);
/sys/src/cmd/ip/gping.c:936: 		seprint(g->msg+n, e, " %3.3g", f/1000000);
/sys/src/cmd/nettest.c:143: 		print("%llud bytes in %g s @ %.2g MB/s (%ldms; limit %.2g MB/s)\n", i, delta, ratemb, sleepms, maxr);
/sys/src/cmd/nettest.c:146: 		print("%llud bytes in %g s @ %.2g MB/s (0ms)\n", i, delta, ratemb);
/sys/src/games/mp3enc/timestatus.c:153:               "%9.4f" SPEED_CHAR "|"  :  "%#9.5g" SPEED_CHAR "|",
/sys/src/libmach/machdata.c:209: 	return snprint(buf, n, "%.18g", fr);
/sys/src/libmach/machdata.c:242: 	return snprint(buf, n, "%.9g", fr);
/sys/src/libstdio/dtoa.c:8:  *	printed as %.17g.  Then atof(s) is exactly y.

Re: [9fans] Bug in print(2) g verb

[Richard Miller]

> /sys/src/cmd/hoc/code.c:586: 	print("%.12g\n", d.val);

Conceivably changing this could break somebody's rc script which depends on
hoc leaving out the leading zero.  But unlikely (one hopes) that someone with
the taste to use Plan 9 would write anything so fragile...

I vote we converge with plan9port's behaviour on this.

Re: [9fans] Bug in print(2) g verb

[erik quanstrom]

> Conceivably changing this could break somebody's rc script which depends on
> hoc leaving out the leading zero.  But unlikely (one hopes) that someone with
> the taste to use Plan 9 would write anything so fragile...

looks like /rc/bin is safe, but ironicly, uptime(1) hacks around the current
behavior.

- erik

[9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[arnold]

Changing the subject here...

"Paul A. Patience" <paul-a.patience@polymtl.ca> wrote:

> ....
> for the native port of awk I am completing
> (started by boyd).

I was under the impression that awk was a native port, but I could
be wrong.

In any case, I recommend that you start with BWK's latest, which is
availble on github:

	git clone git://github.com/onetrueawk/awk

And also talk to Erik who did some work on bringing the Plan 9 awk into
sync with BWK's a little while back.

HTH,

Arnold

P.S. The git repo includes his test suite in the file awktest.a; it should
probably be unarchived in a separate directory from the source.

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[Paul A. Patience]

I am actually the one who asked bwk for his test
suite, which he later put on github. I started
with some gawk tests while waiting for the test
suite, however.

As for plan9's awk, it runs on ape. I am trying
to make it run without ape. I had thought of
starting with the latest version of awk, but
boyd's port was nearly complete (it's in contrib).
All I've been doing is making small bugfixes here
and there. I'm not finished yet, but it won't be
too much longer, hopefully. Perhaps after that I
can take a look at the latest awk.

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[erik quanstrom]

> As for plan9's awk, it runs on ape. I am trying
> to make it run without ape. I had thought of

don't.  it's not worth it.

- erik

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[Kurt H Maier]

On Sun, Mar 03, 2013 at 02:08:20PM -0500, erik quanstrom wrote:
> > As for plan9's awk, it runs on ape. I am trying
> > to make it run without ape. I had thought of
>
> don't.  it's not worth it.
>
> - erik
>

[citation needed]

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[erik quanstrom]

On Sun Mar  3 14:12:19 EST 2013, khm-9@intma.in wrote:
> On Sun, Mar 03, 2013 at 02:08:20PM -0500, erik quanstrom wrote:
> > > As for plan9's awk, it runs on ape. I am trying
> > > to make it run without ape. I had thought of
> >
> > don't.  it's not worth it.
> >
> > - erik
> >
>
> [citation needed]

uh, no.  this is obvious.

awk is designed for a posix environment.
ape is the plan 9 posix environment.  they'll
be happy together.

- erik

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[Kurt H Maier]

On Sun, Mar 03, 2013 at 02:18:11PM -0500, erik quanstrom wrote:
> awk is designed for a posix environment.

bullshit.  was ls also designed for a posix environment?  awk is at
least ten years older than posix.

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[erik quanstrom]

On Sun Mar  3 14:29:15 EST 2013, khm-9@intma.in wrote:
> On Sun, Mar 03, 2013 at 02:18:11PM -0500, erik quanstrom wrote:
> > awk is designed for a posix environment.
>
> bullshit.  was ls also designed for a posix environment?  awk is at
> least ten years older than posix.

should i say "the current ot awk source"?  it's certainly not
designed for plan 9.

- erik

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[Kurt H Maier]

On Sun, Mar 03, 2013 at 02:31:07PM -0500, erik quanstrom wrote:
> On Sun Mar  3 14:29:15 EST 2013, khm-9@intma.in wrote:
> > On Sun, Mar 03, 2013 at 02:18:11PM -0500, erik quanstrom wrote:
> > > awk is designed for a posix environment.
> >
> > bullshit.  was ls also designed for a posix environment?  awk is at
> > least ten years older than posix.
>
> should i say "the current ot awk source"?  it's certainly not
> designed for plan 9.
>
> - erik
>

That wasn't the section of the message you quoted.

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

On Sun, Mar 3, 2013 at 2:31 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> should i say "the current ot awk source"?  it's certainly not
>  designed for plan 9.
>

Regardless you are right that it is clearly not worth porting to 'native'
Plan 9 libraries or APIs; what, if anything, would be the benefit of such
an effort?

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 833 bytes --]

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[Kurt H Maier]

On Sun, Mar 03, 2013 at 07:10:09PM -0500, Dan Cross wrote:
> On Sun, Mar 3, 2013 at 2:31 PM, erik quanstrom <quanstro@quanstro.net>wrote:
>
> > should i say "the current ot awk source"?  it's certainly not
> >  designed for plan 9.
> >
>
> Regardless you are right that it is clearly not worth porting to 'native'
> Plan 9 libraries or APIs; what, if anything, would be the benefit of such
> an effort?
>
>         - Dan C.

Not worth *what*?  Someone else's time?  The only reason we're talking
about a bug in print(2) is because of this waste-of-time native awk
work.  This isn't some kind of zero-sum game where the opportunity cost
of someone making a native awk is depriving us of valuable other
software.  Pretty much anything anyone writes for plan 9 is 'not worth
it' from an economical perspective; pretending Program A is worth less
than Program B is a little silly.  In the meantime Paul has fun, finds
bugs to fix, and I'm one step closer to eradicating ape on my systems.
He doesn't answer to 9fans; stop trying to get him to justify himself to
you.

khm

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[erik quanstrom]

On Sun Mar  3 13:55:37 EST 2013, arnold@skeeve.com wrote:
> Changing the subject here...
>
> "Paul A. Patience" <paul-a.patience@polymtl.ca> wrote:
>
> > ....
> > for the native port of awk I am completing
> > (started by boyd).
>
> I was under the impression that awk was a native port, but I could
> be wrong.
>
> In any case, I recommend that you start with BWK's latest, which is
> availble on github:
>
> 	git clone git://github.com/onetrueawk/awk
>
> And also talk to Erik who did some work on bringing the Plan 9 awk into
> sync with BWK's a little while back.

this is a long-finished project, which is included in 9atom.
i've been happy with the results.  there haven't been any odd fpes
with venti scores or what have you.

i thought this had been submitted, but i guess not.  if there is any
interest, i would be happy to submit it.

- erik

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[Richard Miller]

>> And also talk to Erik who did some work on bringing the Plan 9 awk into
>> sync with BWK's a little while back.
>...
> if there is any
> interest, i would be happy to submit it.

Here's one vote in favour.

Re: [9fans] doing a native awk port (was Re: Bug in print(2) g verb)

[erik quanstrom]

On Sun Mar  3 16:30:37 EST 2013, 9fans@hamnavoe.com wrote:
> >> And also talk to Erik who did some work on bringing the Plan 9 awk into
> >> sync with BWK's a little while back.
> >...
> > if there is any
> > interest, i would be happy to submit it.
>
> Here's one vote in favour.

good enough!

/n/sources/patch/bwk-awk-update

- erik

Re: [9fans] Bug in print(2) g verb

[Paul A. Patience]

I would also like it if %g acted the same in plan9
as everywhere else (printing 0.1 instead of .1 in
my example). That's also really easy to change.

It doesn't make sense for plan9port's %g to be
different from plan9, because now you cannot even
count on both prints to work the same way. Since
printf's %g works like plan9port right now, it
would make sense to change plan9's version.

I don't know the history behind %g's current
behaviour, however.

Re: [9fans] Bug in print(2) g verb

[erik quanstrom]

On Sun Mar  3 12:57:49 EST 2013, paul-a.patience@polymtl.ca wrote:
> I would also like it if %g acted the same in plan9
> as everywhere else (printing 0.1 instead of .1 in
> my example). That's also really easy to change.
>
> It doesn't make sense for plan9port's %g to be
> different from plan9, because now you cannot even
> count on both prints to work the same way. Since
> printf's %g works like plan9port right now, it
> would make sense to change plan9's version.
>
> I don't know the history behind %g's current
> behaviour, however.

i don't have access to 3e sources, but 2e does not
add the extra digit like current plan 9 source does.
(it does however omit the leading 0 on 0.1.)

looking at the differences, i think there's a clue in
the 2e comments

	/*
	 * n is number of digits to convert
	 * 1 before, f2 after, 1 extra for rounding
	 */

we can see that after the label "found:" c1 is set
to prec+1, but that's including the rounding digit.
(cf. "try decimal rounding" above.)

it looks like a simple error in converting the code
from the old non-va_args style to the current style.

- erik

p.s. i haven't talked to anyone to wrote the code, so
maybe somebody who knows more about this than i
could chime in?