On Fri Mar 1 17:54:53 EST 2013, paul-a.patie...@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 pla
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
pri
On Sun Mar 3 12:57:49 EST 2013, paul-a.patie...@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, b
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
pri
Changing the subject here...
"Paul A. Patience" 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:
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
On Sun Mar 3 13:55:37 EST 2013, arn...@skeeve.com wrote:
> Changing the subject here...
>
> "Paul A. Patience" 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
> 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
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]
On Sun Mar 3 14:12:19 EST 2013, kh...@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 n
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.
On Sun Mar 3 14:29:15 EST 2013, kh...@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 curre
On Sun, Mar 03, 2013 at 02:31:07PM -0500, erik quanstrom wrote:
> On Sun Mar 3 14:29:15 EST 2013, kh...@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 environmen
>> 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.
On Sun Mar 3 16:30:37 EST 2013, 9f...@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
> /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 pla
> 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
be
On Sun, Mar 3, 2013 at 2:31 PM, erik quanstrom 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 ef
My 2ยข on the subject of native awk.
The only "native" features I have wanted are:
utf-8 clean - honestly I don't know if it is
alreay but my suspicion is that it is not.
an input parsing mode which respects rc tokenizing rules,
this would make things like du -a | a
On Sun, Mar 03, 2013 at 07:10:09PM -0500, Dan Cross wrote:
> On Sun, Mar 3, 2013 at 2:31 PM, erik quanstrom 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
> utf-8 clean - honestly I don't know if it is
> alreay but my suspicion is that it is not.
already done.
> an input parsing mode which respects rc tokenizing rules,
> this would make things like du -a | awk more reliable in the
> face of weird filenames.
can't this
21 matches
Mail list logo
