From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
From: mveety@mveety.com
Date: Mon, 11 May 2015 22:02:32 -0400
Message-ID: <fa438672bb309f74f0df687c56353cf9@styx>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5158c6b2-ead9-11e9-9d60-3106f5b1d025

Hey 9fans,
	I wrote a ports tree for 9front, but it should work fine on
labs Plan 9. It's a bit light on software and probably has bugs,
so I would really love comments on it and mkfiles for new software.
Take a look at the code, try it out, tell me what you think!

Ports repo: https://bitbucket.org/mveety/9front-ports , install it by
running install.rc . It installs to /sys/ports/ .

--
Veety



From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <fa438672bb309f74f0df687c56353cf9@styx>
References: <fa438672bb309f74f0df687c56353cf9@styx>
Date: Tue, 12 May 2015 06:16:41 +0200
Message-ID: <CAK8RtFpKAD=6LVVHAToqmej=AMBn5j+rOcJ7tVA7_DeT9PDRTw@mail.gmail.com>
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/alternative; boundary=20cf307ac79ff9c3070515dac269
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 51b9a2ac-ead9-11e9-9d60-3106f5b1d025

--20cf307ac79ff9c3070515dac269
Content-Type: text/plain; charset=UTF-8

Den 12 maj 2015 04:13 skrev <mveety@mveety.com>:
>
> Hey 9fans,
>         I wrote a ports tree for 9front, but it should work fine on
> labs Plan 9. It's a bit light on software and probably has bugs,
> so I would really love comments on it and mkfiles for new software.
> Take a look at the code, try it out, tell me what you think!
>
> Ports repo: https://bitbucket.org/mveety/9front-ports , install it by
> running install.rc . It installs to /sys/ports/ .
>
> --
> Veety
>
Awesome!

Just before I had to stop playing with porting to Plan9 (family/kids taking
time), I tried to bootstrap pkgsrc. That was probably doomed to fail. This
got a better chance of success.

As soon as time allows, I will try to migrate my old ports

--20cf307ac79ff9c3070515dac269
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Den 12 maj 2015 04:13 skrev &lt;<a href=3D"mailto:mveety@mve=
ety.com">mveety@mveety.com</a>&gt;:<br>
&gt;<br>
&gt; Hey 9fans,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 I wrote a ports tree for 9front, but it sh=
ould work fine on<br>
&gt; labs Plan 9. It&#39;s a bit light on software and probably has bugs,<b=
r>
&gt; so I would really love comments on it and mkfiles for new software.<br=
>
&gt; Take a look at the code, try it out, tell me what you think!<br>
&gt;<br>
&gt; Ports repo: <a href=3D"https://bitbucket.org/mveety/9front-ports">http=
s://bitbucket.org/mveety/9front-ports</a> , install it by<br>
&gt; running install.rc . It installs to /sys/ports/ .<br>
&gt;<br>
&gt; --<br>
&gt; Veety<br>
&gt;<br>
 Awesome!</p>
<p dir=3D"ltr">Just before I had to stop playing with porting to Plan9 (fam=
ily/kids taking time), I tried to bootstrap pkgsrc. That was probably doome=
d to fail. This got a better chance of success.</p>
<p dir=3D"ltr">As soon as time allows, I will try to migrate my old ports</=
p>

--20cf307ac79ff9c3070515dac269--



From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
From: mveety@mveety.com
Date: Tue, 12 May 2015 01:45:13 -0400
Message-ID: <1c66fd9a5499318dfc14634e17ed5aaa@styx>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5250017a-ead9-11e9-9d60-3106f5b1d025

Thanks Jens!  I can add you to the bitbucket if you wish so you can
contribute at your leisure. Also, if anyone else wants commit access,
just ask.  :) (I think bitbucket has some dumb limited commit bit
thing though.  Hopefully I'll get off it soon.)

--
Veety




From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 11 May 2015 23:19:24 -0700
From: Ori Bernstein <ori@eigenstate.org>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-Id: <20150511231924.c78f0e00d9ce48ae10d206f5@eigenstate.org>
In-Reply-To: <fa438672bb309f74f0df687c56353cf9@styx>
References: <fa438672bb309f74f0df687c56353cf9@styx>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 525baf98-ead9-11e9-9d60-3106f5b1d025

What I've wanted is less a ports tree and more a server that
takes images of some sort (tarballs?) in $home/lib/pkg and binds
the namespace in the right place. So, eg, I have "foo.tgz", which
may contain, for example:

    fortune.tgz:lib/fortunes.txt
    fortune.tgz:bin/fortune

Which would get mounted and bound in:

    /lib/fortunes.txt
    /bin/fortune

I've been thinking that it may even be possible to interpose a bit, and
provide /bin/fortune as a short stub that binds the data files into
a private namespace so that different packages can't stomp each other's
data files. Although that may be overthinking things.

On Mon, 11 May 2015 22:02:32 -0400, mveety@mveety.com wrote:

> Hey 9fans,
> 	I wrote a ports tree for 9front, but it should work fine on
> labs Plan 9. It's a bit light on software and probably has bugs,
> so I would really love comments on it and mkfiles for new software.
> Take a look at the code, try it out, tell me what you think!
>
> Ports repo: https://bitbucket.org/mveety/9front-ports , install it by
> running install.rc . It installs to /sys/ports/ .
>
> --
> Veety
>


--
    Ori Bernstein



From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Tue, 12 May 2015 12:26:08 +0200
Message-ID: <3681698.qAT3IkqOYy@krypton>
User-Agent: KMail/4.14.7 (Linux/4.0.2-1-ARCH; KDE/4.14.7; x86_64; ; )
In-Reply-To: <1c66fd9a5499318dfc14634e17ed5aaa@styx>
References: <1c66fd9a5499318dfc14634e17ed5aaa@styx>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5262353e-ead9-11e9-9d60-3106f5b1d025

On Tuesday 12 May 2015 01:45:13 mveety@mveety.com wrote:
> Thanks Jens!  I can add you to the bitbucket if you wish so you can
> contribute at your leisure. Also, if anyone else wants commit access,
> just ask.  :) (I think bitbucket has some dumb limited commit bit
> thing though.  Hopefully I'll get off it soon.)
>
> --
> Veety


cool my e-mail adress used for these things is staal1978@gmail.com
I just started watching the repo.

Some form questions:
* should categories be listed according to groups similar to OpenBSD ports?
(got some stuff for "archivers", "shell", "graphics" and "lang" ... and
perhaps a few more)
* for APE packages (for example libraries that depend on other APE libraries),
should this be a specific sub-category? for example ape/graphics/[package] ?
some binaries, libraries and headers should probably be installed in
/rc/bin/ape, $objtype/bin/ape/, $objtype/lib/ape and /sys/include/ape/
* Config/ports.conf
is "catagory" intentional or a typo?

I will see when I have time to play with this... I am eager to though :)



From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
Message-ID: <trinity-e0c3d813-167b-4a9b-9f00-57f9e5d127f9-1431565396352@3capp-gmx-bs72>
From: "Adrian Regenfuss" <a.regenfuss@gmx.de>
To: 9fans@9fans.net
Content-Type: text/html; charset=UTF-8
Date: Thu, 14 May 2015 03:03:16 +0200
In-Reply-To: <fa438672bb309f74f0df687c56353cf9@styx>
References: <fa438672bb309f74f0df687c56353cf9@styx>
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52ab96b6-ead9-11e9-9d60-3106f5b1d025

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Neat.</div>

<div>Thank&#39;s for the work.</div>

<div>I&#39;ll try it.</div>

<div>
<div>&nbsp;</div>

<div>Sucks less.</div>

<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Dienstag, 12. Mai 2015 um 04:02 Uhr<br/>
<b>Von:</b>&nbsp;mveety@mveety.com<br/>
<b>An:</b>&nbsp;9fans@9fans.net<br/>
<b>Betreff:</b>&nbsp;[9fans] Ports tree for Plan 9</div>

<div name="quoted-content">Hey 9fans,<br/>
I wrote a ports tree for 9front, but it should work fine on<br/>
labs Plan 9. It&#39;s a bit light on software and probably has bugs,<br/>
so I would really love comments on it and mkfiles for new software.<br/>
Take a look at the code, try it out, tell me what you think!<br/>
<br/>
Ports repo: <a href="https://bitbucket.org/mveety/9front-ports" target="_blank">https://bitbucket.org/mveety/9front-ports</a> , install it by<br/>
running install.rc . It installs to /sys/ports/ .<br/>
<br/>
--<br/>
Veety<br/>
&nbsp;</div>
</div>
</div>
</div></div></body></html>



From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <1c66fd9a5499318dfc14634e17ed5aaa@styx>
References: <1c66fd9a5499318dfc14634e17ed5aaa@styx>
Date: Thu, 14 May 2015 09:05:02 +0200
Message-ID: <CAK8RtFp-=_NXOFaD0D-gnM8BTWTMzPy--b0p8mM=jpRXdGxEGw@mail.gmail.com>
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/alternative; boundary=bcaec51a86c2af93f40516055805
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52af7a9c-ead9-11e9-9d60-3106f5b1d025

--bcaec51a86c2af93f40516055805
Content-Type: text/plain; charset=UTF-8

Den 12 maj 2015 07:47 skrev <mveety@mveety.com>:
>
> Thanks Jens!  I can add you to the bitbucket if you wish so you can
> contribute at your leisure. Also, if anyone else wants commit access,
> just ask.  :) (I think bitbucket has some dumb limited commit bit
> thing though.  Hopefully I'll get off it soon.)
>
> --
> Veety
>
>

I just set up a clean 9front VM (vbox, will see if the same issue exists on
qemu/kvm) and I have an issue where tar fails on every archive downloaded
with hget.

Any ideas what the issue may be? Need to get that resolved to validate my
ports before uploading them :)

--bcaec51a86c2af93f40516055805
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
Den 12 maj 2015 07:47 skrev &lt;<a href=3D"mailto:mveety@mveety.com">mveety=
@mveety.com</a>&gt;:<br>
&gt;<br>
&gt; Thanks Jens!=C2=A0 I can add you to the bitbucket if you wish so you c=
an<br>
&gt; contribute at your leisure. Also, if anyone else wants commit access,<=
br>
&gt; just ask.=C2=A0 :) (I think bitbucket has some dumb limited commit bit=
<br>
&gt; thing though.=C2=A0 Hopefully I&#39;ll get off it soon.)<br>
&gt;<br>
&gt; --<br>
&gt; Veety<br>
&gt;<br>
&gt;</p>
<p dir=3D"ltr">I just set up a clean 9front VM (vbox, will see if the same =
issue exists on qemu/kvm) and I have an issue where tar fails on every arch=
ive downloaded with hget.</p>
<p dir=3D"ltr">Any ideas what the issue may be? Need to get that resolved t=
o validate my ports before uploading them :)</p>

--bcaec51a86c2af93f40516055805--



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <52bf8a26466986ba753fe017f28bb9d8@felloff.net>
Date: Thu, 14 May 2015 10:46:20 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <CAK8RtFp-=_NXOFaD0D-gnM8BTWTMzPy--b0p8mM=jpRXdGxEGw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52b3dd8a-ead9-11e9-9d60-3106f5b1d025

could you be more specific what files fail to unpack with tar?

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <52bf8a26466986ba753fe017f28bb9d8@felloff.net>
References: <CAK8RtFp-=_NXOFaD0D-gnM8BTWTMzPy--b0p8mM=jpRXdGxEGw@mail.gmail.com>
	<52bf8a26466986ba753fe017f28bb9d8@felloff.net>
Date: Thu, 14 May 2015 12:42:43 +0200
Message-ID: <CAK8RtFrzhFx5b9VZUHsJNYLeKWmVC3hYqAU8MMofkppQxYz4Ow@mail.gmail.com>
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/alternative; boundary=bcaec51a86c232dc2505160863b6
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52b8160c-ead9-11e9-9d60-3106f5b1d025

--bcaec51a86c232dc2505160863b6
Content-Type: text/plain; charset=UTF-8

Both tar.gz (zlib official site) and tar.bz2 (mksh official site). I just
wonder if they get corrupted during transfer with hget or if there is a
different issue.
Den 14 maj 2015 10:49 skrev <cinap_lenrek@felloff.net>:

> could you be more specific what files fail to unpack with tar?
>
> --
> cinap
>
>

--bcaec51a86c232dc2505160863b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Both tar.gz (zlib official site) and tar.bz2 (mksh official =
site). I just wonder if they get corrupted during transfer with hget or if =
there is a different issue.</p>
<div class=3D"gmail_quote">Den 14 maj 2015 10:49 skrev  &lt;<a href=3D"mail=
to:cinap_lenrek@felloff.net">cinap_lenrek@felloff.net</a>&gt;:<br type=3D"a=
ttribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">could you be more specific what =
files fail to unpack with tar?<br>
<br>
--<br>
cinap<br>
<br>
</blockquote></div>

--bcaec51a86c232dc2505160863b6--



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3ac2ce9e7613f65d027fe974c34ba49a@felloff.net>
Date: Thu, 14 May 2015 12:47:02 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <CAK8RtFrzhFx5b9VZUHsJNYLeKWmVC3hYqAU8MMofkppQxYz4Ow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52bc65ea-ead9-11e9-9d60-3106f5b1d025

why can't you just give a url so someone can try to reproduce it?

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <e11f2baf2dde0a940be64aef68d651b2@felloff.net>
Date: Thu, 14 May 2015 12:52:48 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <CAK8RtFrzhFx5b9VZUHsJNYLeKWmVC3hYqAU8MMofkppQxYz4Ow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52c93a36-ead9-11e9-9d60-3106f5b1d025

i just tried this and it works all fine:

hget http://bitbucket.org/9front/plan9front/get/tip.tar.gz | gunzip | tar t

so please give a example command with a url that gives you issues.

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Thu, 14 May 2015 13:10:20 +0200
Message-ID: <3008924.em7JGlQAbN@krypton>
User-Agent: KMail/4.14.7 (Linux/4.0.2-1-ARCH; KDE/4.14.7; x86_64; ; )
In-Reply-To: <e11f2baf2dde0a940be64aef68d651b2@felloff.net>
References: <e11f2baf2dde0a940be64aef68d651b2@felloff.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52cdaf3a-ead9-11e9-9d60-3106f5b1d025

On Thursday 14 May 2015 12:52:48 cinap_lenrek@felloff.net wrote:
> i just tried this and it works all fine:
>
> hget http://bitbucket.org/9front/plan9front/get/tip.tar.gz | gunzip | tar t
>
> so please give a example command with a url that gives you issues.

Hi
sorry about the lack of details before (I was on my phone so no urls handy)

I tried 2 "low hanging fruit" (=no source changes) packages for the ports -
zlib and mksh.

http://zlib.net/zlib-1.2.8.tar.gz
https://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50f.tgz

I remembered wrong... both were gzipped. I had other archives that were bz2

now when I was at my computer I took the opportunity to compare md5sums
between the archives downloaded on 9front and on Linux and they differed.
Before I just assumed that there was an issue with tar.

 This might be a vbox bug (known for flaky network? I use the recommended
settings from 9front wiki), so I will try in qemu instead.





From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Thu, 14 May 2015 13:49:08 +0200
Message-ID: <2088244.pzeXDVNko2@krypton>
User-Agent: KMail/4.14.7 (Linux/4.0.2-1-ARCH; KDE/4.14.7; x86_64; ; )
In-Reply-To: <3008924.em7JGlQAbN@krypton>
References: <e11f2baf2dde0a940be64aef68d651b2@felloff.net>
	<3008924.em7JGlQAbN@krypton>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52d1de0c-ead9-11e9-9d60-3106f5b1d025

On Thursday 14 May 2015 13:10:20 Jens Staal wrote:
>  This might be a vbox bug (known for flaky network? I use the recommended
> settings from 9front wiki), so I will try in qemu instead.

I just tried with the archives in qemu too and got the same error (and the
same deviant md5sum) - so hget is weird?



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <05640016b2f7b677b54134d515e69f0f@felloff.net>
Date: Thu, 14 May 2015 13:50:33 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <3008924.em7JGlQAbN@krypton>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52d67390-ead9-11e9-9d60-3106f5b1d025

found it. the server sends Content-Encoding header which causes hget
to add a decompression filter, so you get as output a tarball.

<- Content-Type: application/x-gzip
<- Content-Encoding: gzip

from the w3c:

The Content-Encoding entity-header field is used as a modifier to the media-type.
When presented, its value indicates what additional content codings have been applied
to the entity-body, and thus what decoding mechanisms must be applied in order to
obtail the media-type referenced by the Conent-Type header field. Content-Encoding
is primarily used to allow a document to be compressed without losing the
identity of its underlying media type.

this is clearly silly, as the file is already compressed, and decompressing it
will not yield the indicated content-type: application/x-gzip, but a tarball.

maybe the w3c is wrong, or is ignored in practice or we need to handle gzip
specially. the problem is that some webservers compress the data, like you request
a html file and it gives you gzip back, thats why hget uncompresses.

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8264e799db284683e6beb4d3a8486d8c@felloff.net>
Date: Thu, 14 May 2015 13:59:44 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <2088244.pzeXDVNko2@krypton>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52db7e76-ead9-11e9-9d60-3106f5b1d025

haha, this appears to be an apache bug, and mozilla has work arrounds
for this. we might need todo similar thing and check for content type
as well.

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <37ef388344a8837f92481183ad7d2197@felloff.net>
Date: Thu, 14 May 2015 14:13:21 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <2088244.pzeXDVNko2@krypton>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52eb6d4a-ead9-11e9-9d60-3106f5b1d025

commited a work arround for this now.

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <b09750c8c630ed6d8de3727e176ed518@felloff.net>
Date: Thu, 14 May 2015 14:36:11 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <2088244.pzeXDVNko2@krypton>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52f489fc-ead9-11e9-9d60-3106f5b1d025

nope, apache is wired.

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 14 May 2015 15:32:37 +0200
From: Steffen Nurpmeso <sdaoden@yandex.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20150514133237.bKzVgyACWBpdGosFpyEqGg==@yandex.com>
References: <05640016b2f7b677b54134d515e69f0f@felloff.net>
In-Reply-To: <05640016b2f7b677b54134d515e69f0f@felloff.net>
User-Agent: s-nail v14.8.0-16-gb218d6a
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52fcb8c0-ead9-11e9-9d60-3106f5b1d025

cinap_lenrek@felloff.net wrote:
 |found it. the server sends Content-Encoding header which causes hget
 |to add a decompression filter, so you get as output a tarball.
 |
 |<- Content-Type: application/x-gzip
 |<- Content-Encoding: gzip

 |

 |this is clearly silly, as the file is already compressed, \
 |and decompressing it
 |will not yield the indicated content-type: application/x-gzip, \
 |but a tarball.
 |
 |maybe the w3c is wrong, or is ignored in practice or we need to handle gz=
ip
 |specially. the problem is that some webservers compress the \

The problem is that IANA doesn't support a tar-gz MIME type, so
that mime.types(5) (tika [1]=C2=A0for Apache) will return "silly"
values, as in

  application/gzip              tgz gz emz
  application/x-bzip2           bz2 tbz2 boz
  # EXTENSION .tbz
  application/x-xz              xz tbz
  application/x-tar             tar

  [1] http://svn.apache.org/viewvc/tika/trunk/tika-core/src/main/resources/=
org/apache/tika/mime/tika-mimetypes.xml

 |data, like you request
 |a html file and it gives you gzip back, thats why hget uncompresses.

mime.types(5) (re-)evaluating expanded content seems what IANA has
in mind with its decision (it would be all too simple if it would
just work (tm)).

--steffen



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <5a75dd2b6b836e9560f71e07547dde5b@felloff.net>
Date: Thu, 14 May 2015 16:37:05 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <20150514133237.bKzVgyACWBpdGosFpyEqGg==@yandex.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 53052a28-ead9-11e9-9d60-3106f5b1d025

pretty sure this is apache bug/misconfiguration. googled for it
and the issue seems to be known problem.

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Fri, 15 May 2015 06:43:44 +0200
Message-ID: <1457622.JBEUM5jn1y@krypton>
User-Agent: KMail/4.14.7 (Linux/4.0.2-1-ARCH; KDE/4.14.7; x86_64; ; )
In-Reply-To: <5a75dd2b6b836e9560f71e07547dde5b@felloff.net>
References: <5a75dd2b6b836e9560f71e07547dde5b@felloff.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5335cb92-ead9-11e9-9d60-3106f5b1d025

On Thursday 14 May 2015 16:37:05 cinap_lenrek@felloff.net wrote:
> pretty sure this is apache bug/misconfiguration. googled for it
> and the issue seems to be known problem.

The zlib archive works fine now :)
by the way, did you try the mksh archive after hget was fixed? I still get the
same error as before

"gunzip: <stdin>: inflate failed: corrupted data
/bin/tar: EOF reading archive ..."

https://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50f.tgz

but now the md5sums match between the linux-downloaded and the 9front-
downloaded archive.

Also sbase archives (.zip, tar.gz and tar.bz2) suffer from the same issue.
http://git.suckless.org/sbase/snapshot/sbase-master.zip
http://git.suckless.org/sbase/snapshot/sbase-master.tar.gz
http://git.suckless.org/sbase/snapshot/sbase-master.tar.bz2





From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
From: mveety@mveety.com
Date: Fri, 15 May 2015 00:49:15 -0400
Message-ID: <66a08f669d0e873239a642cd292fa71b@styx>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5339d2f0-ead9-11e9-9d60-3106f5b1d025

I tried out the sbase zip on my system. That seems to work fine. Heres the log:

cpu% lc
sbase-master.zip
cpu% unzip -f sbase-master.zip
cpu% lc
sbase-master/		sbase-master.zip
cpu% cd sbase-master/
cpu% lc
LICENSE		comm.1		find.1		md5.h		readlink.c	split.c		uname.c
Makefile	comm.c		find.c		md5sum.1	renice.1	sponge.1	unexpand.1
README		compat.h	fold.1		md5sum.c	renice.c	sponge.c	unexpand.c
TODO		config.mk	fold.c		mkdir.1		rm.1		strings.1	uniq.1
arg.h		cp.1		fs.h		mkdir.c		rm.c		strings.c	uniq.c
basename.1	cp.c		grep.1		mkfifo.1	rmdir.1		sync.1		unlink.1
basename.c	cron.1		grep.c		mkfifo.c	rmdir.c		sync.c		unlink.c
cal.1		cron.c		head.1		mktemp.1	sed.1		tail.1		utf.h
cal.c		crypt.h		head.c		mktemp.c	sed.c		tail.c		util.h
cat.1		cut.1		hostname.1	mv.1		seq.1		tar.1		uudecode.1
cat.c		cut.c		hostname.c	mv.c		seq.c		tar.c		uudecode.c
chgrp.1		date.1		join.1		nice.1		setsid.1	tee.1		uuencode.1
chgrp.c		date.c		join.c		nice.c		setsid.c	tee.c		uuencode.c
chmod.1		dirname.1	kill.1		nl.1		sha1.h		test.1		wc.1
chmod.c		dirname.c	kill.c		nl.c		sha1sum.1	test.c		wc.c
chown.1		du.1		libutf/		nohup.1		sha1sum.c	text.h		which.1
chown.c		du.c		libutil/	nohup.c		sha256.h	time.1		which.c
chroot.1	echo.1		link.1		paste.1		sha256sum.1	time.c		xargs.1
chroot.c	echo.c		link.c		paste.c		sha256sum.c	touch.1		xargs.c
cksum.1		env.1		ln.1		printenv.1	sha512.h	touch.c		yes.1
cksum.c		env.c		ln.c		printenv.c	sha512sum.1	tr.1		yes.c
cmp.1		expand.1	logger.1	printf.1	sha512sum.c	tr.c
cmp.c		expand.c	logger.c	printf.c	sleep.1		true.1
col.1		expr.1		logname.1	pwd.1		sleep.c		true.c
col.c		expr.c		logname.c	pwd.c		sort.1		tty.1
cols.1		false.1		ls.1		queue.h		sort.c		tty.c
cols.c		false.c		ls.c		readlink.1	split.1		uname.1

--
Veety



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <70dc8bc40443b72db8c649644525d3e1@felloff.net>
Date: Fri, 15 May 2015 07:21:02 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <1457622.JBEUM5jn1y@krypton>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 533e983a-ead9-11e9-9d60-3106f5b1d025

the sbase works fine for me, tho i can reproduce the mksh-R50f.tgz gzip
problem.

lemme do some debugging on that.

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <b606f7aa9f0ff2246ef275e9d823e395@felloff.net>
Date: Fri, 15 May 2015 07:53:39 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <1457622.JBEUM5jn1y@krypton>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5343e0d8-ead9-11e9-9d60-3106f5b1d025

fixed, its a bug in gunzip. the extra-len field in the gzip header has two
byte length field instead of one byte.

commited the fix.

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Fri, 15 May 2015 09:08:29 +0200
Message-ID: <4150976.nFeNsMojL7@krypton>
User-Agent: KMail/4.14.7 (Linux/4.0.2-1-ARCH; KDE/4.14.7; x86_64; ; )
In-Reply-To: <b606f7aa9f0ff2246ef275e9d823e395@felloff.net>
References: <b606f7aa9f0ff2246ef275e9d823e395@felloff.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 534e4456-ead9-11e9-9d60-3106f5b1d025

On Friday 15 May 2015 07:53:39 cinap_lenrek@felloff.net wrote:
> fixed, its a bug in gunzip. the extra-len field in the gzip header has two
> byte length field instead of one byte.
>
> commited the fix.

awesome!
now it works



From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Mon, 18 May 2015 17:57:13 +0200
Message-ID: <2252507.vjlYxDeHWB@krypton>
User-Agent: KMail/4.14.8 (Linux/4.0.3-1-ARCH; KDE/4.14.8; x86_64; ; )
In-Reply-To: <b606f7aa9f0ff2246ef275e9d823e395@felloff.net>
References: <b606f7aa9f0ff2246ef275e9d823e395@felloff.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 537a1c02-ead9-11e9-9d60-3106f5b1d025

On Friday 15 May 2015 07:53:39 cinap_lenrek@felloff.net wrote:
> commited the fix.

Playing with the ports has so far uncovered 3 bugs (hget, zip and the one
below) so rather fruitful playing :)

A potential bug in APE sys/wait.h : the header does not make sure that pid_t
has been defined.
Compiling sbase on Plan9/APE ended up in situations where there were lots of
compilation faliures simply because <sys/wait.h> was included without
<sys/types.h> being included before.





From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <5d77545a7c65305168ec9ff261473641@felloff.net>
Date: Wed, 27 May 2015 21:49:10 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <2252507.vjlYxDeHWB@krypton>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56320478-ead9-11e9-9d60-3106f5b1d025

> A potential bug in APE sys/wait.h : the header does not make sure that pid_t
> has been defined.
> Compiling sbase on Plan9/APE ended up in situations where there were lots of
> compilation faliures simply because <sys/wait.h> was included without
> <sys/types.h> being included before.

fixed.

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri, 29 May 2015 14:01:57 -0700
To: 9fans@9fans.net
Message-ID: <0db3bca19b4d5a8674289f5533024e12@lilly.quanstro.net>
In-Reply-To: <5d77545a7c65305168ec9ff261473641@felloff.net>
References: <5d77545a7c65305168ec9ff261473641@felloff.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56399eb8-ead9-11e9-9d60-3106f5b1d025

On Wed May 27 12:51:19 PDT 2015, cinap_lenrek@felloff.net wrote:
> > A potential bug in APE sys/wait.h : the header does not make sure that pid_t
> > has been defined.
> > Compiling sbase on Plan9/APE ended up in situations where there were lots of
> > compilation faliures simply because <sys/wait.h> was included without
> > <sys/types.h> being included before.
>
> fixed.

uh, i just read the open group spec.  i did not see the requirement that wait.h
define pid_t.  if someone could site chapter and verse, i would be happy to add
the include, but it would seem hasty without a standards citation.

- erik



From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 29 May 2015 21:12:48 +0000
Message-ID: <20150529211248.Horde.KX_OffdaJ1iY0Du6zyO7vRu@ssl.eumx.net>
From: Kurt H Maier <khm@sciops.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <5d77545a7c65305168ec9ff261473641@felloff.net>
	<0db3bca19b4d5a8674289f5533024e12@lilly.quanstro.net>
In-Reply-To: <0db3bca19b4d5a8674289f5533024e12@lilly.quanstro.net>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 564fa12c-ead9-11e9-9d60-3106f5b1d025

Quoting erik quanstrom <quanstro@quanstro.net>:

> On Wed May 27 12:51:19 PDT 2015, cinap_lenrek@felloff.net wrote:
>> > A potential bug in APE sys/wait.h : the header does not make sure
>> that pid_t
>> > has been defined.
>> > Compiling sbase on Plan9/APE ended up in situations where there
>> were lots of
>> > compilation faliures simply because <sys/wait.h> was included without
>> > <sys/types.h> being included before.
>>
>> fixed.
>
> uh, i just read the open group spec.  i did not see the requirement
> that wait.h
> define pid_t.  if someone could site chapter and verse, i would be
> happy to add
> the include, but it would seem hasty without a standards citation.
>
> - erik

Which version?

"The id_t and pid_t types shall be defined as described in
<sys/types.h>." in issue 6

"The <sys/wait.h> header shall define the id_t and pid_t types as
described in <sys/types.h>." in issue 7

in the sys/wait.h part of the headers section of base definitions


khm




From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <e54c7e54aa5632fd476235cef94cbf09@felloff.net>
Date: Fri, 29 May 2015 23:25:46 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: <0db3bca19b4d5a8674289f5533024e12@lilly.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 564682a4-ead9-11e9-9d60-3106f5b1d025

i did a google search for it and found this:

http://pubs.opengroup.org/onlinepubs/007904975/basedefs/sys/wait.h.html

which stated:

"The id_t and pid_t types shall be defined as described in <sys/types.h>."

and also looked in openbsd's <sys/wait.h> which did #include <sys/types.h>
which was good enougth for me, tho i'm not a unix expert.

--
cinap



From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri, 29 May 2015 20:02:34 -0700
To: 9fans@9fans.net
Message-ID: <d0a3c80b3fad67900e4626e648159b69@brasstown.quanstro.net>
In-Reply-To: <e54c7e54aa5632fd476235cef94cbf09@felloff.net>
References: <e54c7e54aa5632fd476235cef94cbf09@felloff.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5656bebc-ead9-11e9-9d60-3106f5b1d025

On Fri May 29 14:26:54 PDT 2015, cinap_lenrek@felloff.net wrote:
> i did a google search for it and found this:
>
> http://pubs.opengroup.org/onlinepubs/007904975/basedefs/sys/wait.h.html
>
> which stated:
>
> "The id_t and pid_t types shall be defined as described in <sys/types.h>."
>
> and also looked in openbsd's <sys/wait.h> which did #include <sys/types.h>
> which was good enougth for me, tho i'm not a unix expert.

excellent.  thanks.

- erik



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <fb2ba8d67817c068bd39c14e3919bf50@proxima.alt.za>
To: 9fans@9fans.net
Date: Sat, 30 May 2015 07:11:05 +0200
From: lucio@proxima.alt.za
In-Reply-To: <20150529211248.Horde.KX_OffdaJ1iY0Du6zyO7vRu@ssl.eumx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5663ed58-ead9-11e9-9d60-3106f5b1d025

> Which version?
>
> "The id_t and pid_t types shall be defined as described in
> <sys/types.h>." in issue 6
>
> "The <sys/wait.h> header shall define the id_t and pid_t types as
> described in <sys/types.h>." in issue 7
>
> in the sys/wait.h part of the headers section of base definitions

I haven't looked at cinap's work, but...

It is the Plan 9 Way (TM) to avoid nested inclusion of header files,
although I guess the APE may be exempted.  I also appreciate that
adding conditional definitions of id_t and pid_t in <sys/wait.h> that
match those in <sys/types.h> could lead to eventual inconsistencies,
but I would still prefer to follow the Plan 9 guidelines.

But without a more formal code review structure and the apparent
absence of guidance from Bell Labs, I suppose I'm just farting in the
wind.

Lucio.




From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <fb2ba8d67817c068bd39c14e3919bf50@proxima.alt.za>
References: <20150529211248.Horde.KX_OffdaJ1iY0Du6zyO7vRu@ssl.eumx.net>
	<fb2ba8d67817c068bd39c14e3919bf50@proxima.alt.za>
Date: Sat, 30 May 2015 07:57:44 +0200
Message-ID: <CAHJeKDVQvtQiZG0ZOEACD-1un7E2PFn4P2ZP7tWcAXVA9ZGASA@mail.gmail.com>
From: =?UTF-8?Q?=C3=81lvaro_Jurado?= <elbingmiss@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/alternative; boundary=001a1134cc507ccd590517464577
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5673a4c8-ead9-11e9-9d60-3106f5b1d025

--001a1134cc507ccd590517464577
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> It is the Plan 9 Way (TM) to avoid > nested inclusion of header files,

$ arch/dat.h includes port/portdat.h in kernel. Exempted too?

=C3=81lvaro Jurado Cuevas
http://colmenar.biz.tm
El 30/05/2015 07:11, <lucio@proxima.alt.za> escribi=C3=B3:

> > Which version?
> >
> > "The id_t and pid_t types shall be defined as described in
> > <sys/types.h>." in issue 6
> >
> > "The <sys/wait.h> header shall define the id_t and pid_t types as
> > described in <sys/types.h>." in issue 7
> >
> > in the sys/wait.h part of the headers section of base definitions
>
> I haven't looked at cinap's work, but...
>
> It is the Plan 9 Way (TM) to avoid nested inclusion of header files,
> although I guess the APE may be exempted.  I also appreciate that
> adding conditional definitions of id_t and pid_t in <sys/wait.h> that
> match those in <sys/types.h> could lead to eventual inconsistencies,
> but I would still prefer to follow the Plan 9 guidelines.
>
> But without a more formal code review structure and the apparent
> absence of guidance from Bell Labs, I suppose I'm just farting in the
> wind.
>
> Lucio.
>
>
>

--001a1134cc507ccd590517464577
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">&gt; It is the Plan 9 Way (TM) to avoid &gt; nested inclusio=
n of header files,</p>
<p dir=3D"ltr">$ arch/dat.h includes port/portdat.h in kernel. Exempted too=
?</p>
<p dir=3D"ltr">=C3=81lvaro Jurado Cuevas<br>
<a href=3D"http://colmenar.biz.tm">http://colmenar.biz.tm</a></p>
<div class=3D"gmail_quote">El 30/05/2015 07:11,  &lt;<a href=3D"mailto:luci=
o@proxima.alt.za">lucio@proxima.alt.za</a>&gt; escribi=C3=B3:<br type=3D"at=
tribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">&gt; Which version?<br>
&gt;<br>
&gt; &quot;The id_t and pid_t types shall be defined as described in<br>
&gt; &lt;sys/types.h&gt;.&quot; in issue 6<br>
&gt;<br>
&gt; &quot;The &lt;sys/wait.h&gt; header shall define the id_t and pid_t ty=
pes as<br>
&gt; described in &lt;sys/types.h&gt;.&quot; in issue 7<br>
&gt;<br>
&gt; in the sys/wait.h part of the headers section of base definitions<br>
<br>
I haven&#39;t looked at cinap&#39;s work, but...<br>
<br>
It is the Plan 9 Way (TM) to avoid nested inclusion of header files,<br>
although I guess the APE may be exempted.=C2=A0 I also appreciate that<br>
adding conditional definitions of id_t and pid_t in &lt;sys/wait.h&gt; that=
<br>
match those in &lt;sys/types.h&gt; could lead to eventual inconsistencies,<=
br>
but I would still prefer to follow the Plan 9 guidelines.<br>
<br>
But without a more formal code review structure and the apparent<br>
absence of guidance from Bell Labs, I suppose I&#39;m just farting in the<b=
r>
wind.<br>
<br>
Lucio.<br>
<br>
<br>
</blockquote></div>

--001a1134cc507ccd590517464577--



From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sat, 30 May 2015 06:13:08 +0000
Message-ID: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
From: Kurt H Maier <khm@sciops.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <20150529211248.Horde.KX_OffdaJ1iY0Du6zyO7vRu@ssl.eumx.net>
	<fb2ba8d67817c068bd39c14e3919bf50@proxima.alt.za>
In-Reply-To: <fb2ba8d67817c068bd39c14e3919bf50@proxima.alt.za>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56877052-ead9-11e9-9d60-3106f5b1d025

Quoting lucio@proxima.alt.za:

> It is the Plan 9 Way (TM) to avoid nested inclusion of header files,
> although I guess the APE may be exempted.

while I agree it's not very plan-9-like, the posix standard is horrible and
broken and nobody should be surprised that the easy way to implement it
involves horrible brokenness.

I guess it's implementation-defined whether you prefer to preserve the purity
of essence by redefining the types in wait.h, or join the mutiny of preverts
with a nested include.

Personally, it's just one more reason to reduce our nation's dependence on
foreign code -- does anyone want to help test pap's native awk?

khm




From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <63eb016ed1ac0ade586c2544d55e774a@proxima.alt.za>
To: 9fans@9fans.net
Date: Sat, 30 May 2015 08:36:52 +0200
From: lucio@proxima.alt.za
In-Reply-To: <CAHJeKDVQvtQiZG0ZOEACD-1un7E2PFn4P2ZP7tWcAXVA9ZGASA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 568c7606-ead9-11e9-9d60-3106f5b1d025

>> It is the Plan 9 Way (TM) to avoid > nested inclusion of header files,
>
> $ arch/dat.h includes port/portdat.h in kernel. Exempted too?

That's out of necessity, the alternative(s) would be considerably less
practical.  If memory serves, port/portdat.h is not strictly a header
file in the connventional "C" sense.  If memory serves, it would also
be possible to arrange the 9 kernel sources in a more elegant manner,
but the cost to benefit ratio would be too low to bother.

Note that no one has ever prohibited nesting includes where it could
have been possible to do it in the compiler and pre=processor.  It is
not a crime, it is a bad practice.  I'm of the opinion that it is as
avoidable as the GOTO command in programming languages (I don't use
GOTOs and don't really cope well reading code that does), but there is
enough code out there to suggest my opinion needs a formal proof.

So, yes, I think there are exceptions and the one you quote is not the
only one, mostly for historical reasons; it is also my belief that
such exceptions could be eliminated, but with the advancing of time,
it becomes less and less practical to do so.  Further, I mentioned
exemption for APE because it is an uncomfortable reality we don't need
to encourage: like the kernel stuff that dates back to the 1980s, once
adopted, it becomes very hard to eliminate.

Lucio.




From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
To: 9fans@9fans.net
Date: Sat, 30 May 2015 08:39:46 +0200
From: lucio@proxima.alt.za
In-Reply-To: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 569151da-ead9-11e9-9d60-3106f5b1d025

> does anyone want to help test pap's native awk?

Build it and they'll come :-)

URL?  Is it portable?  How carefully was it ported?

It may be worth twisting Aaron's arm, he may well have a test suite
for GAWK that can be used here?

Lucio.




From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sat, 30 May 2015 06:59:29 +0000
Message-ID: <20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
From: Kurt H Maier <khm@sciops.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
In-Reply-To: <282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56a3367a-ead9-11e9-9d60-3106f5b1d025

Quoting lucio@proxima.alt.za:

>> does anyone want to help test pap's native awk?
>
> Build it and they'll come :-)
>
> URL?  Is it portable?  How carefully was it ported?
>
> It may be worth twisting Aaron's arm, he may well have a test suite
> for GAWK that can be used here?
>
> Lucio.

Paul wrote it from scratch.  I have a copy[1] but I'm unsure it's his
latest version -- he no longer has it, so I guess maybe it is.

Paul also asked bwk for his awk test suite, which is still online[2],
thankfully.

Current status:  the only failures are bizarre corner cases, but
presumably they're in the testsuite for a reason?  Native awk is
slower than APE awk, and Paul mentioned he thinks it's because of the
malloc implementation.

I would very much like to see this fast and conformant, so that APE
awk can be thrown in the trash.

[1] http://code.9front.org/awk
[2] http://www.cs.princeton.edu/~bwk/btl.mirror/awktest.a

khm




From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sat, 30 May 2015 07:04:22 +0000
Message-ID: <20150530070422.Horde.O7OznNVA4M6ly9qaNO4X4s3@ssl.eumx.net>
From: Kurt H Maier <khm@sciops.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
In-Reply-To: <20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56ac6268-ead9-11e9-9d60-3106f5b1d025

Quoting Kurt H Maier <khm@sciops.net>:

> Paul wrote it from scratch.

No he didn't; he started with Boyd's awk.  Been a while since
I looked at the commit history.  Sorry.

khm




From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
Date: Sat, 30 May 2015 09:21:40 +0200
Message-ID: <CAK8RtFrX0J0XRooaRA09H1rSq9kMqy9yzqkhwMdBR3C8wFVLXg@mail.gmail.com>
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/alternative; boundary=20cf307f312eb4928305174771ac
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56b23094-ead9-11e9-9d60-3106f5b1d025

--20cf307f312eb4928305174771ac
Content-Type: text/plain; charset=UTF-8

Den 30 maj 2015 08:41 skrev <lucio@proxima.alt.za>:
>
> > does anyone want to help test pap's native awk?
>
> Build it and they'll come :-)
>
> URL?  Is it portable?  How carefully was it ported?
>
> It may be worth twisting Aaron's arm, he may well have a test suite
> for GAWK that can be used here?
>
> Lucio.
>
>

I was going to attempt a new gawk port sometime later.

I am also interested in seeing how compatible the ported m4 is with GNU m4
if there are good tests. A plan is to attempt bison/flex porting some time.

--20cf307f312eb4928305174771ac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
Den 30 maj 2015 08:41 skrev &lt;<a href=3D"mailto:lucio@proxima.alt.za">luc=
io@proxima.alt.za</a>&gt;:<br>
&gt;<br>
&gt; &gt; does anyone want to help test pap&#39;s native awk?<br>
&gt;<br>
&gt; Build it and they&#39;ll come :-)<br>
&gt;<br>
&gt; URL?=C2=A0 Is it portable?=C2=A0 How carefully was it ported?<br>
&gt;<br>
&gt; It may be worth twisting Aaron&#39;s arm, he may well have a test suit=
e<br>
&gt; for GAWK that can be used here?<br>
&gt;<br>
&gt; Lucio.<br>
&gt;<br>
&gt;</p>
<p dir=3D"ltr">I was going to attempt a new gawk port sometime later. </p>
<p dir=3D"ltr">I am also interested in seeing how compatible the ported m4 =
is with GNU m4 if there are good tests. A plan is to attempt bison/flex por=
ting some time.<br>
</p>

--20cf307f312eb4928305174771ac--



From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <CAK8RtFrX0J0XRooaRA09H1rSq9kMqy9yzqkhwMdBR3C8wFVLXg@mail.gmail.com>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<CAK8RtFrX0J0XRooaRA09H1rSq9kMqy9yzqkhwMdBR3C8wFVLXg@mail.gmail.com>
Date: Sat, 30 May 2015 09:21:45 +0100
Message-ID: <CAOw7k5gLk+Xh1ujFvGwAeG8S1HaymvCdZxm+1kvHYGK0sYuZLA@mail.gmail.com>
From: Charles Forsyth <charles.forsyth@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/alternative; boundary=e89a8f3bae938e6b9305174848c6
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56b748a4-ead9-11e9-9d60-3106f5b1d025

--e89a8f3bae938e6b9305174848c6
Content-Type: text/plain; charset=UTF-8

On 30 May 2015 at 08:21, Jens Staal <staal1978@gmail.com> wrote:

> am also interested in seeing how compatible the ported m4 is with GNU m4
> if there are good tests


GNU m4 is insane, and completely missed the point about GPM (and thus m4).

My m4 port is based on Ritchie's m4, although I might re-do a few things to
make it a Plan 9 program
and account for a few changes in the C environment. You could put gnu m4 in
APE I suppose, but
since it's mainly used for autotools which won't work anyway because they
aren't portable, I'm not sure what's the point.

--e89a8f3bae938e6b9305174848c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 30 May 2015 at 08:21, Jens Staal <span dir=3D"ltr">&lt;<a href=3D"mailto=
:staal1978@gmail.com" target=3D"_blank">staal1978@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"> am also interested in seeing how =
compatible the ported m4 is with GNU m4 if there are good tests</blockquote=
></div><br>GNU m4 is insane, and completely missed the point about GPM (and=
 thus m4).</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra">My m4 port is based on Ritchie&#39;s m4, although I might re-do a few =
things to make it a Plan 9 program</div><div class=3D"gmail_extra">and acco=
unt for a few changes in the C environment. You could put gnu m4 in APE I s=
uppose, but</div><div class=3D"gmail_extra">since it&#39;s mainly used for =
autotools which won&#39;t work anyway because they aren&#39;t portable, I&#=
39;m not sure what&#39;s the point.</div></div>

--e89a8f3bae938e6b9305174848c6--



From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <CAOw7k5gLk+Xh1ujFvGwAeG8S1HaymvCdZxm+1kvHYGK0sYuZLA@mail.gmail.com>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<CAK8RtFrX0J0XRooaRA09H1rSq9kMqy9yzqkhwMdBR3C8wFVLXg@mail.gmail.com>
	<CAOw7k5gLk+Xh1ujFvGwAeG8S1HaymvCdZxm+1kvHYGK0sYuZLA@mail.gmail.com>
Date: Sat, 30 May 2015 10:35:19 +0200
Message-ID: <CAK8RtFqLeqF6PgF2h6hSO6-o4v3AGbEaaDpqZH=c72s3PMiNEQ@mail.gmail.com>
From: Jens Staal <staal1978@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/alternative; boundary=20cf307f3540117dc005174879fc
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56bb7df2-ead9-11e9-9d60-3106f5b1d025

--20cf307f3540117dc005174879fc
Content-Type: text/plain; charset=UTF-8

Den 30 maj 2015 10:23 skrev "Charles Forsyth" <charles.forsyth@gmail.com>:
>
>
> On 30 May 2015 at 08:21, Jens Staal <staal1978@gmail.com> wrote:
>>
>> am also interested in seeing how compatible the ported m4 is with GNU m4
if there are good tests
>
>
> GNU m4 is insane, and completely missed the point about GPM (and thus m4).
>
> My m4 port is based on Ritchie's m4, although I might re-do a few things
to make it a Plan 9 program
> and account for a few changes in the C environment. You could put gnu m4
in APE I suppose, but
> since it's mainly used for autotools which won't work anyway because they
aren't portable, I'm not sure what's the point.

I was talking about "quasar m4" in ports

https://bitbucket.org/mveety/9front-ports/src/devel/m4/

Which apparently is a modified BSD m4 specifically aiming for GNU
compatibility.

I am not saying that they are the ideal or good tools - just that most 3rd
party source expect certain behavior and a "compatibility environment"
(like APE) has as first priority to deal with 3rd party stuff. Enabling as
much as possible without judgement is at least to me desirable.

All the ports are optional so nobody needs to feel "violated" by my heresy
;)

--20cf307f3540117dc005174879fc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
Den 30 maj 2015 10:23 skrev &quot;Charles Forsyth&quot; &lt;<a href=3D"mail=
to:charles.forsyth@gmail.com">charles.forsyth@gmail.com</a>&gt;:<br>
&gt;<br>
&gt;<br>
&gt; On 30 May 2015 at 08:21, Jens Staal &lt;<a href=3D"mailto:staal1978@gm=
ail.com">staal1978@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; am also interested in seeing how compatible the ported m4 is with =
GNU m4 if there are good tests<br>
&gt;<br>
&gt;<br>
&gt; GNU m4 is insane, and completely missed the point about GPM (and thus =
m4).<br>
&gt;<br>
&gt; My m4 port is based on Ritchie&#39;s m4, although I might re-do a few =
things to make it a Plan 9 program<br>
&gt; and account for a few changes in the C environment. You could put gnu =
m4 in APE I suppose, but<br>
&gt; since it&#39;s mainly used for autotools which won&#39;t work anyway b=
ecause they aren&#39;t portable, I&#39;m not sure what&#39;s the point.</p>
<p dir=3D"ltr">I was talking about &quot;quasar m4&quot; in ports</p>
<p dir=3D"ltr"><a href=3D"https://bitbucket.org/mveety/9front-ports/src/dev=
el/m4/">https://bitbucket.org/mveety/9front-ports/src/devel/m4/</a></p>
<p dir=3D"ltr">Which apparently is a modified BSD m4 specifically aiming fo=
r GNU compatibility.</p>
<p dir=3D"ltr">I am not saying that they are the ideal or good tools - just=
 that most 3rd party source expect certain behavior and a &quot;compatibili=
ty environment&quot; (like APE) has as first priority to deal with 3rd part=
y stuff. Enabling as much as possible without judgement is at least to me d=
esirable. </p>
<p dir=3D"ltr">All the ports are optional so nobody needs to feel &quot;vio=
lated&quot; by my heresy ;)</p>

--20cf307f3540117dc005174879fc--



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <96748a714ac262add7bcef5c249dc888@proxima.alt.za>
To: 9fans@9fans.net
Date: Sat, 30 May 2015 10:36:38 +0200
From: lucio@proxima.alt.za
In-Reply-To: <20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56c00cdc-ead9-11e9-9d60-3106f5b1d025

> I would very much like to see this fast and conformant, so that APE
> awk can be thrown in the trash.

In my wild dreams I wish for a native version of ghostscript (the only
justified use of APE, if you believe in fairness (or fairy tales :-)).

But maybe Go will eventually stimulate development of a sane text
processing suite.  One is allowed to dream, isn't one?  Donald, where
are you when one needs you?

Lucio.




From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <2188c557ad2646d89a136afbf78aef52@proxima.alt.za>
To: 9fans@9fans.net
Date: Sat, 30 May 2015 10:41:32 +0200
From: lucio@proxima.alt.za
In-Reply-To: <CAK8RtFqLeqF6PgF2h6hSO6-o4v3AGbEaaDpqZH=c72s3PMiNEQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56c47f10-ead9-11e9-9d60-3106f5b1d025

> I am not saying that they are the ideal or good tools - just that most 3rd
> party source expect certain behavior and a "compatibility environment"
> (like APE) has as first priority to deal with 3rd party stuff. Enabling as
> much as possible without judgement is at least to me desirable.

Remember that APE was developed to determine the portability to Posix of software developed natively for Plan 9.  That it turned on its master and took on a totally different mantle is understandable, but it is also not surprising that some shortcomings may never be uovercome.

Lucio.




From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat, 30 May 2015 08:54:40 -0700
To: 9fans@9fans.net
Message-ID: <9643241aee7d4ffd7efb6765c65c7d0c@brasstown.quanstro.net>
In-Reply-To: <20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56cfc92e-ead9-11e9-9d60-3106f5b1d025

> I would very much like to see this fast and conformant, so that APE
> awk can be thrown in the trash.

i don't understand this.  awk is bwk's ota source, with some minor tweaks to fit the
environment.  it works well, and allows portable awk to be written.  can you
explain what is to be gained by a re do?  i don't think "doesn't use ape" per ce
is a good argument.  it would have to be explained what this enables.  i can't see
that part.

- erik



From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat, 30 May 2015 08:57:49 -0700
To: 9fans@9fans.net
Message-ID: <63615a86029278298a23da441b1573b4@brasstown.quanstro.net>
In-Reply-To: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
References: <20150529211248.Horde.KX_OffdaJ1iY0Du6zyO7vRu@ssl.eumx.net>
	<fb2ba8d67817c068bd39c14e3919bf50@proxima.alt.za>
	<20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56df80d0-ead9-11e9-9d60-3106f5b1d025

> Personally, it's just one more reason to reduce our nation's dependence on
> foreign code -- does anyone want to help test pap's native awk?

pretty difficult to do if there is a desire to use git or hg.

- erik



From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sat, 30 May 2015 16:17:11 +0000
Message-ID: <20150530161711.Horde.Zu3ZjWU4ucBOU87o86BVozY@ssl.eumx.net>
From: Kurt H Maier <khm@sciops.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<9643241aee7d4ffd7efb6765c65c7d0c@brasstown.quanstro.net>
In-Reply-To: <9643241aee7d4ffd7efb6765c65c7d0c@brasstown.quanstro.net>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56f08baa-ead9-11e9-9d60-3106f5b1d025

Quoting erik quanstrom <quanstro@quanstro.net>:

> i don't understand this.

It is a personal preference not rooted in any technological excuses.


> pretty difficult to do if there is a desire to use git or hg.

does hgfs use APE?  I haven't investigated too closely.

khm




From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Jeff Sickel <jas@corpus-callosum.com>
In-Reply-To: <20150530161711.Horde.Zu3ZjWU4ucBOU87o86BVozY@ssl.eumx.net>
Date: Sat, 30 May 2015 11:27:32 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <6A95B96C-1CF5-44E0-9E76-E2C71EA82931@corpus-callosum.com>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<9643241aee7d4ffd7efb6765c65c7d0c@brasstown.quanstro.net>
	<20150530161711.Horde.Zu3ZjWU4ucBOU87o86BVozY@ssl.eumx.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56f5587e-ead9-11e9-9d60-3106f5b1d025


> On May 30, 2015, at 11:17 AM, Kurt H Maier <khm@sciops.net> wrote:
>
>> pretty difficult to do if there is a desire to use git or hg.
>
> does hgfs use APE?  I haven't investigated too closely.

hgfs is a read-only Hg tool written in Limbo.  You still need hg running
on your host to pull/commit/push changes.





From mboxrd@z Thu Jan  1 00:00:00 1970
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<9643241aee7d4ffd7efb6765c65c7d0c@brasstown.quanstro.net>
	<20150530161711.Horde.Zu3ZjWU4ucBOU87o86BVozY@ssl.eumx.net>
	<6A95B96C-1CF5-44E0-9E76-E2C71EA82931@corpus-callosum.com>
From: Stanley Lieber <sl@9front.org>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <6A95B96C-1CF5-44E0-9E76-E2C71EA82931@corpus-callosum.com>
Message-Id: <04075184-1C1C-4B1A-AB35-66E4F5289E59@9front.org>
Date: Sat, 30 May 2015 16:30:52 -0400
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56ff1684-ead9-11e9-9d60-3106f5b1d025


> On May 30, 2015, at 12:27 PM, Jeff Sickel <jas@corpus-callosum.com> wrote:=

>=20
>=20
>>> On May 30, 2015, at 11:17 AM, Kurt H Maier <khm@sciops.net> wrote:
>>>=20
>>> pretty difficult to do if there is a desire to use git or hg.
>>=20
>> does hgfs use APE?  I haven't investigated too closely.
>=20
> hgfs is a read-only Hg tool written in Limbo.  You still need hg running
> on your host to pull/commit/push changes.

he was referring to the c program hgfs that was written for 9front. currentl=
y, yes, it is read-only.

sl




From mboxrd@z Thu Jan  1 00:00:00 1970
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<9643241aee7d4ffd7efb6765c65c7d0c@brasstown.quanstro.net>
From: Stanley Lieber <sl@9front.org>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <9643241aee7d4ffd7efb6765c65c7d0c@brasstown.quanstro.net>
Message-Id: <B62C0337-B26E-48D4-91EA-C23B9E4F8F3A@9front.org>
Date: Sat, 30 May 2015 16:32:57 -0400
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 56fa23cc-ead9-11e9-9d60-3106f5b1d025

On May 30, 2015, at 11:54 AM, erik quanstrom <quanstro@quanstro.net> wrote:

>> I would very much like to see this fast and conformant, so that APE
>> awk can be thrown in the trash.
>=20
> i don't understand this.  awk is bwk's ota source, with some minor tweaks t=
o fit the
> environment.  it works well, and allows portable awk to be written.  can y=
ou
> explain what is to be gained by a re do?  i don't think "doesn't use ape" p=
er ce
> is a good argument.  it would have to be explained what this enables.  i c=
an't see
> that part.
>=20
> - erik

if i understood correctly, the major reasons were better unicode handling an=
d not using sh for system().

sl




From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat, 30 May 2015 17:16:46 -0700
To: 9fans@9fans.net
Message-ID: <b397dca9762cf27974d7b8f46e8d9a1d@brasstown.quanstro.net>
In-Reply-To: <B62C0337-B26E-48D4-91EA-C23B9E4F8F3A@9front.org>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<9643241aee7d4ffd7efb6765c65c7d0c@brasstown.quanstro.net>
	<B62C0337-B26E-48D4-91EA-C23B9E4F8F3A@9front.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5706b16e-ead9-11e9-9d60-3106f5b1d025

On Sat May 30 13:36:14 PDT 2015, sl@9front.org wrote:
> On May 30, 2015, at 11:54 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>
> >> I would very much like to see this fast and conformant, so that APE
> >> awk can be thrown in the trash.
> >
> > i don't understand this.  awk is bwk's ota source, with some minor tweaks to fit the
> > environment.  it works well, and allows portable awk to be written.  can you
> > explain what is to be gained by a re do?  i don't think "doesn't use ape" per ce
> > is a good argument.  it would have to be explained what this enables.  i can't see
> > that part.
> >
> > - erik
>
> if i understood correctly, the major reasons were better unicode handling and not using sh for system().

using rc instead of /bin/ape/sh is a a bind away.  similarly, adding %C to awk is also trivial.
but there are compatability tradeoffs.  (i used rune/uconv (see rune(1),
http://sources.9atom.org/magic/man2html/1/rune)

this doesn't seem like motiviation to rewrite awk.  there must be another reason?

by the way, thinking a bit bigger, what i'd like to see is x, where x is to awk as rc is to the
bourne shell.

- erik



From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sat, 30 May 2015 20:41:30 -0400
From: sl@9front.org
To: 9fans@9fans.net
Message-ID: <d105f271cf632c06608b33ec3dca1a28@u2.inri>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 570f3654-ead9-11e9-9d60-3106f5b1d025

> this doesn't seem like motiviation to rewrite awk.  there must be another reason?

I think "rewrite" is a mischaracterization (nobody is talking about re-
implementing the awk interpreter), so arguing against that seems to be beside
the point. Probably, "port awk to Plan 9 without using APE" is more accurate.

>>From memory, the "awk is not a native Plan 9 program" problem has been discussed
a few times on 9fans. Googling, I found the following message, which describes
some of the issues raised:

	https://www.mail-archive.com/9fans@cse.psu.edu/msg17798.html


> by the way, thinking a bit bigger, what i'd like to see is x, where x is to awk as rc is to the
> bourne shell.

The ssam (stream interface to sam) script from plan9port is heavier than
awk by itself, but can be useful for a lot of the same tasks.

sl



From mboxrd@z Thu Jan  1 00:00:00 1970
From: arnold@skeeve.com
Message-Id: <201505310304.t4V34Zqd013068@freefriends.org>
Date: Sat, 30 May 2015 21:04:35 -0600
To: 9fans@9fans.net
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
In-Reply-To: <20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
User-Agent: Heirloom mailx 12.4 7/29/08
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5716b8d4-ead9-11e9-9d60-3106f5b1d025

lucio@proxima.alt.za:

> It may be worth twisting Aaron's arm, he may well have a test suite
> for GAWK that can be used here?

The gawk test suite is part of the dist. See test/Makefile.am for the
list of tests that are general and those that are gawk specific.
I've tried to keep the separation clean.

Kurt H Maier <khm@sciops.net> wrote:
> Current status:  the only failures are bizarre corner cases, but
> presumably they're in the testsuite for a reason?

Yes - people will do anything they can. Experience has taught me that
even bizarre corner cases need to be handled.

> Native awk is slower than APE awk, and Paul mentioned he thinks it's
> because of the malloc implementation.

BWK has said that malloc affects the performance of his awk; I think
it's in his README file.

> [1] http://code.9front.org/awk

I can't get to this with a browser. How does one get the source?  Is it
intended to run on *nix also? It'd be nice to have since it's always
fun to compare multiple implementations when trying to figure out a
corner case.  Besides BWK's awk, there is mawk, BusyBox awk, and the
MKS awk as found in the various OpenSolaris derivatives.

Thanks,

Arnold



From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sun, 31 May 2015 04:40:47 +0000
Message-ID: <20150531044047.Horde.O6Kyd_W2LFmUu83bds-TlRT@ssl.eumx.net>
From: Kurt H Maier <khm@sciops.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<201505310304.t4V34Zqd013068@freefriends.org>
In-Reply-To: <201505310304.t4V34Zqd013068@freefriends.org>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 571f93a0-ead9-11e9-9d60-3106f5b1d025

Quoting arnold@skeeve.com:

> BWK has said that malloc affects the performance of his awk; I think
> it's in his README file.

Yes, it was explained to me that plan 9 malloc does useful things instead
of just shoving things into the first available hole like APE malloc.

I'm reasonably certain Moore's Law has fixed this issue for all
practical applications, however...

> I can't get to this with a browser. How does one get the source?  Is it
> intended to run on *nix also? It'd be nice to have since it's always
> fun to compare multiple implementations when trying to figure out a
> corner case.  Besides BWK's awk, there is mawk, BusyBox awk, and the
> MKS awk as found in the various OpenSolaris derivatives.

I mangled some webshit earlier today on that server (bad timing I guess).
Correct link to the hg repo is https://code.9front.org/hg/awk

And I think I have a tarball at http://intma.in/downloads/awk.tgz but
that webserver Content-type is broken so you should hget it instead of
using a browser to download.

khm




From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat, 30 May 2015 21:55:09 -0700
To: 9fans@9fans.net
Message-ID: <533debb6d724cf5c9e69764865e4a8e5@brasstown.quanstro.net>
In-Reply-To: <20150531044047.Horde.O6Kyd_W2LFmUu83bds-TlRT@ssl.eumx.net>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<201505310304.t4V34Zqd013068@freefriends.org>
	<20150531044047.Horde.O6Kyd_W2LFmUu83bds-TlRT@ssl.eumx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5725574a-ead9-11e9-9d60-3106f5b1d025

On Sat May 30 21:43:03 PDT 2015, khm@sciops.net wrote:
> Quoting arnold@skeeve.com:
>
> > BWK has said that malloc affects the performance of his awk; I think
> > it's in his README file.
>
> Yes, it was explained to me that plan 9 malloc does useful things instead
> of just shoving things into the first available hole like APE malloc.

instead of guessing, you could see if the pool library's checks are really a bottleneck.
it is straightforward to add header and tail magic and the callerpc stuff to ape
malloc and run the comparsion again.

otherwise, it seems far more likely that the problem is that quicklicks are
faster than tree allocators.

> I'm reasonably certain Moore's Law has fixed this issue for all
> practical applications, however...

i'm resonablly certain that plan 9 malloc's poor performance has cost me quite
a bit of work.

- erik



From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat, 30 May 2015 22:01:03 -0700
To: 9fans@9fans.net
Message-ID: <797a72e55ed5f2429a060097c177ff4c@brasstown.quanstro.net>
In-Reply-To: <533debb6d724cf5c9e69764865e4a8e5@brasstown.quanstro.net>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<201505310304.t4V34Zqd013068@freefriends.org>
	<20150531044047.Horde.O6Kyd_W2LFmUu83bds-TlRT@ssl.eumx.net>
	<533debb6d724cf5c9e69764865e4a8e5@brasstown.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 572afd9e-ead9-11e9-9d60-3106f5b1d025

On Sat May 30 22:02:11 PDT 2015, quanstro@quanstro.net wrote:
> On Sat May 30 21:43:03 PDT 2015, khm@sciops.net wrote:
> > Quoting arnold@skeeve.com:
> >
> > > BWK has said that malloc affects the performance of his awk; I think
> > > it's in his README file.
> >
> > Yes, it was explained to me that plan 9 malloc does useful things instead
> > of just shoving things into the first available hole like APE malloc.
>
> instead of guessing, you could see if the pool library's checks are really a bottleneck.
> it is straightforward to add header and tail magic and the callerpc stuff to ape
> malloc and run the comparsion again.
>
> otherwise, it seems far more likely that the problem is that quicklicks are
> faster than tree allocators.

also, ape %f/%g are much faster than the native version.

- erik



From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <cc57b718a1e4a4c9280561ea5f11f177@proxima.alt.za>
To: 9fans@9fans.net
Date: Sun, 31 May 2015 07:08:36 +0200
From: lucio@proxima.alt.za
In-Reply-To: <201505310304.t4V34Zqd013068@freefriends.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 572fdd14-ead9-11e9-9d60-3106f5b1d025

> and the
> MKS awk as found in the various OpenSolaris derivatives

MKS was my introduction to Unix, I was a PCDOS user back then :-)

It's interesting to hear about that port.  I still tread carefully in
vi because of a minor nit (which my fingers remember better than my
brain) with backspace in replace mode (it will come to me, I seriously
still suffer from it :-).

Have the MKS sources ever been released?

Lucio.




From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sun, 31 May 2015 05:17:09 +0000
Message-ID: <20150531051709.Horde.Soy5PS8ryaL2KRV9GzMoOUP@ssl.eumx.net>
From: Kurt H Maier <khm@sciops.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<201505310304.t4V34Zqd013068@freefriends.org>
	<20150531044047.Horde.O6Kyd_W2LFmUu83bds-TlRT@ssl.eumx.net>
	<533debb6d724cf5c9e69764865e4a8e5@brasstown.quanstro.net>
In-Reply-To: <533debb6d724cf5c9e69764865e4a8e5@brasstown.quanstro.net>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 5734e962-ead9-11e9-9d60-3106f5b1d025

Quoting erik quanstrom <quanstro@quanstro.net>:

> instead of guessing, you could see if the pool library's checks are
> really a bottleneck.
> it is straightforward to add header and tail magic and the callerpc
> stuff to ape
> malloc and run the comparsion again.
>
> otherwise, it seems far more likely that the problem is that quicklicks are
> faster than tree allocators.

I'm not a programmer.

>> I'm reasonably certain Moore's Law has fixed this issue for all
>> practical applications, however...
>
> i'm resonablly certain that plan 9 malloc's poor performance has
> cost me quite
> a bit of work.

I was talking about awk, not malloc in all applications.  Sorry if I was
insufficiently precise.  So far I have not been displeased with the
performance of native awk, but I'd be interested in seeing use cases
where it becomes a real-world problem.

khm





From mboxrd@z Thu Jan  1 00:00:00 1970
From: arnold@skeeve.com
Message-Id: <201505311400.t4VE0icT027926@freefriends.org>
Date: Sun, 31 May 2015 08:00:44 -0600
To: 9fans@9fans.net
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<201505310304.t4V34Zqd013068@freefriends.org>
	<20150531044047.Horde.O6Kyd_W2LFmUu83bds-TlRT@ssl.eumx.net>
In-Reply-To: <20150531044047.Horde.O6Kyd_W2LFmUu83bds-TlRT@ssl.eumx.net>
User-Agent: Heirloom mailx 12.4 7/29/08
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 573e7d38-ead9-11e9-9d60-3106f5b1d025

Kurt H Maier <khm@sciops.net> wrote:

> I mangled some webshit earlier today on that server (bad timing I guess).
> Correct link to the hg repo is https://code.9front.org/hg/awk

This appears to be based on Brian Kernighan's awk from sometime in 1999
and not written from scratch.

There have been many fixes to BWK's code since then. If you're going to
start over, it should be done from his current code, available from
his Princeton home page.

Arnold



From mboxrd@z Thu Jan  1 00:00:00 1970
From: arnold@skeeve.com
Message-Id: <201505311403.t4VE3PGF028282@freefriends.org>
Date: Sun, 31 May 2015 08:03:25 -0600
To: 9fans@9fans.net
References: <cc57b718a1e4a4c9280561ea5f11f177@proxima.alt.za>
In-Reply-To: <cc57b718a1e4a4c9280561ea5f11f177@proxima.alt.za>
User-Agent: Heirloom mailx 12.4 7/29/08
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 574b43c4-ead9-11e9-9d60-3106f5b1d025

> Have the MKS sources ever been released?

I don't believe so. I think they were the basis for z/OS, which is
a POSIX environment on top of IBM's MVS.

The MKS awk made its way out into the world via Solaris, which for some
reason chose that code base, instead of a more recent version of BWK's
awk, for their POSIX awk.  Quite some time ago I ported it to Linux; it
took an hour or so. It'd take more work to make it generally portable, which
I never bothered to do.

Arnold



From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun, 31 May 2015 07:12:25 -0700
To: 9fans@9fans.net
Message-ID: <9fa708897081ac608bfb95e4fcfd0823@brasstown.quanstro.net>
In-Reply-To: <201505311400.t4VE0icT027926@freefriends.org>
References: <20150530061308.Horde.aC_WDskRKnim3lHX6LLxoUF@ssl.eumx.net>
	<282c8157ab32274a7a57bdaf92cfdb09@proxima.alt.za>
	<20150530065929.Horde.QDsqrRMAxzJn6m4W92CoPMS@ssl.eumx.net>
	<201505310304.t4V34Zqd013068@freefriends.org>
	<20150531044047.Horde.O6Kyd_W2LFmUu83bds-TlRT@ssl.eumx.net>
	<201505311400.t4VE0icT027926@freefriends.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 574f8c36-ead9-11e9-9d60-3106f5b1d025

> There have been many fixes to BWK's code since then. If you're going to
> start over, it should be done from his current code, available from
> his Princeton home page.

9atom's awk has been updated with bwk's recent source.  it also has a fix for the problem
sometimes seen with plan 9 installs where a score looks enough like floating point that
awk tries to treat it as such and gets a fp exception in the process.

i would consider adding pure extensions, such as %C, or the ability to deal with hex.

- erik