Re: [9fans] Ports tree for Plan 9
On May 30, 2015, at 11:17 AM, Kurt H Maier k...@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.
Re: [9fans] Ports tree for Plan 9
On May 30, 2015, at 12:27 PM, Jeff Sickel j...@corpus-callosum.com wrote: On May 30, 2015, at 11:17 AM, Kurt H Maier k...@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. he was referring to the c program hgfs that was written for 9front. currently, yes, it is read-only. sl
Re: [9fans] Ports tree for Plan 9
On May 30, 2015, at 11:54 AM, erik quanstrom quans...@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(). sl
Re: [9fans] Ports tree for Plan 9
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 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
Re: [9fans] Ports tree for Plan 9
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
Re: [9fans] Ports tree for Plan 9
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 clean. Kurt H Maier k...@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
Re: [9fans] Ports tree for Plan 9
On Sat May 30 13:36:14 PDT 2015, s...@9front.org wrote: On May 30, 2015, at 11:54 AM, erik quanstrom quans...@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
Re: [9fans] Ports tree for Plan 9
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 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
Re: [9fans] Ports tree for Plan 9
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'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
Re: [9fans] Ports tree for Plan 9
Quoting erik quanstrom quans...@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
Re: [9fans] Ports tree for Plan 9
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 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
Re: [9fans] Ports tree for Plan 9
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.
Re: [9fans] Ports tree for Plan 9
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.
Re: [9fans] Ports tree for Plan 9
Quoting Kurt H Maier k...@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
Re: [9fans] Ports tree for Plan 9
Den 30 maj 2015 08:41 skrev 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. 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.
Re: [9fans] Ports tree for Plan 9
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 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
Re: [9fans] Ports tree for Plan 9
On 30 May 2015 at 08:21, Jens Staal staal1...@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.
Re: [9fans] Ports tree for Plan 9
Den 30 maj 2015 10:23 skrev Charles Forsyth charles.fors...@gmail.com: On 30 May 2015 at 08:21, Jens Staal staal1...@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 ;)
Re: [9fans] Ports tree for Plan 9
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.
Re: [9fans] Ports tree for Plan 9
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.
Re: [9fans] Ports tree for Plan 9
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.
Re: [9fans] Ports tree for Plan 9
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
Re: [9fans] Ports tree for Plan 9
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
Re: [9fans] Ports tree for Plan 9
Quoting erik quanstrom quans...@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
