> 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
> 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
Kurt H Maier 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
Quoting erik quanstrom :
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 tha
> 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
On Sat May 30 22:02:11 PDT 2015, quans...@quanstro.net wrote:
> On Sat May 30 21:43:03 PDT 2015, k...@sciops.net wrote:
> > Quoting arn...@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
On Sat May 30 21:43:03 PDT 2015, k...@sciops.net wrote:
> Quoting arn...@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
Quoting arn...@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
lu...@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 cl
> 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" i
On Sat May 30 13:36:14 PDT 2015, s...@9front.org wrote:
> On May 30, 2015, at 11:54 AM, erik quanstrom 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
> On May 30, 2015, at 12:27 PM, Jeff Sickel wrote:
>
>
>>> On May 30, 2015, at 11:17 AM, Kurt H Maier 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.
On May 30, 2015, at 11:54 AM, erik quanstrom 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 port
> On May 30, 2015, at 11:17 AM, Kurt H Maier 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.
Quoting erik quanstrom :
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
> 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
> 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
> 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.
Remem
> 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
Den 30 maj 2015 10:23 skrev "Charles Forsyth" :
>
>
> On 30 May 2015 at 08:21, Jens Staal 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
On 30 May 2015 at 08:21, Jens Staal 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
Den 30 maj 2015 08:41 skrev :
>
> > 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 w
Quoting Kurt H Maier :
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
Quoting lu...@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 scr
> 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.
>> 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 conn
Quoting lu...@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
invol
> 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?
Álvaro Jurado Cuevas
http://colmenar.biz.tm
El 30/05/2015 07:11, escribió:
> > Which version?
> >
> > "The id_t and pid_t types shall be defined as described in
> Which version?
>
> "The id_t and pid_t types shall be defined as described in
> ." in issue 6
>
> "The header shall define the id_t and pid_t types as
> described in ." 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.
On Fri May 29 14:26:54 PDT 2015, cinap_len...@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 ."
>
> and also looked in
Quoting erik quanstrom :
On Wed May 27 12:51:19 PDT 2015, cinap_len...@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
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 ."
and also looked in openbsd's which did #include
which was good enougth for me, tho i'm not a unix ex
On Wed May 27 12:51:19 PDT 2015, cinap_len...@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 becaus
> 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 was included without
> being included before.
fixed.
--
cinap
On Friday 15 May 2015 07:53:39 cinap_len...@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.
Compil
On Friday 15 May 2015 07:53:39 cinap_len...@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
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
the sbase works fine for me, tho i can reproduce the mksh-R50f.tgz gzip
problem.
lemme do some debugging on that.
--
cinap
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
sp
On Thursday 14 May 2015 16:37:05 cinap_len...@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 erro
pretty sure this is apache bug/misconfiguration. googled for it
and the issue seems to be known problem.
--
cinap
cinap_len...@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 compresse
nope, apache is wired.
--
cinap
commited a work arround for this now.
--
cinap
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
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
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
On Thursday 14 May 2015 12:52:48 cinap_len...@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 be
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
why can't you just give a url so someone can try to reproduce it?
--
cinap
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 :
> could you be more specific what files fail to unpack with tar?
>
> --
> cinap
>
>
could you be more specific what files fail to unpack with tar?
--
cinap
Den 12 maj 2015 07:47 skrev :
>
> 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.)
>
> --
Neat.
Thank's for the work.
I'll try it.
Sucks less.
Gesendet: Dienstag, 12. Mai 2015 um 04:02 Uhr
Von: mve...@mveety.com
An: 9fans@9fans.net
Betreff: [9fans] Ports tree for Plan 9
Hey 9fans,
I wrote a ports tree for 9front, but it should work fine on
labs Plan 9. It's
On Tuesday 12 May 2015 01:45:13 mve...@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
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 mo
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
Den 12 maj 2015 04:13 skrev :
>
> 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
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://bitbu
59 matches
Mail list logo