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
21 matches
Mail list logo
