Re: [9fans] GNU Make

Re: [9fans] GNU Make

[lucio]

> Messages and Codes was notoriously unhelpful in many cases.

Sure, but was the problem with the concept or with the implementation?
In my particular case, my concern lies largely with system library
functions, a finite error message space.  In fact, given that a
significant portion of the errors are concurrent with 9P, it ought to
be trivial to rationalise at least those error messages into a finite
set.

I'm suggesting that discipline in the use of error messages would be
constructive and that one mechanism to encourage such discipline would
be the use of indexing.  I appreciate that it then becomes difficult
to escape the enforced rigidity, but one can add the escape mechanism
a priori.

I actually fail to see any other disadvantages of a disciplined
approach.  I do see very clearly where the Plan 9 approach becomes a
nightmare.

++L

RE: [9fans] GNU Make

[Trickey, Howard W (Howard)]

> Does anyone else here believe that APE is worth enhancing?
No. Well, hardly anyone.
The Plan 9 user community regards APE as a "failure of vision"
not worth pursuing.

RE: [9fans] GNU Make

[lucio]

Lucio De Re asked:
>> Does anyone else here believe that APE is worth enhancing?

To which Howard Trickey replied:
> No. Well, hardly anyone.
> The Plan 9 user community regards APE as a "failure of vision"
> not worth pursuing.

Is there an alternative?  What about supporting ghostscript and spin?
Moving off APE to GNU is hardly an option, although it certainly is
different.  Rewriting a whole lot of useful software because the
original authors were not blessed with the holy knowledge of the Plan 9
development environment is also somewhat counterproductive.

No, I think your efforts were heroic and deserve to be sustained and
even enhanced :-)

++L

Re: [9fans] GNU Make

[Dan Cross]

"Trickey, Howard W (Howard)" <trickey@lucent.com> writes:
> 
> > Does anyone else here believe that APE is worth enhancing?
> 
> No. Well, hardly anyone.
> The Plan 9 user community regards APE as a "failure of vision"
> not worth pursuing.

I disagree.  I see it as a necessary evil which it would be a mistake
to discard, or, just as bad, allow to decay to the point at which
discarding is necessary.

	- Dan C.

[9fans] GNU Make

[lucio]

I have compiled mkfile and config.h to produce a seemingly
working copy of GNU Make 3.80 under APE.  One small adjustment to
main.c allows #including <fcntl.h> which is necessary for successful
compilation.

As there is a make-3.79 directory in /sys/src/ape/cmd that is
currently underpopulated, I would suggest using the 3.80 version to
fill the gap.  In order not to lose the V10 make currently used by
APE, I would suggest targetting (as I did) /$objtype/bin/ape/gmake and
/sys/src/ape/cmd/gmake for 3.80.

Also, I have deployed the /sys/src/ape/lib/ap/plan9/wait.c that
correctly handles PIDs off a linked list (as correctly as I have been
able to test) and gmake seems to exercise it a little, giving me a
little more confidence that the new wait.c is no worse than the
version it replaces.

Anyone interested, please contact me.

++L

Re: [9fans] GNU Make

[boyd, rounin]

and what was wrong with mk?

Re: [9fans] GNU Make

[ron minnich]

On Tue, 1 Jun 2004, boyd, rounin wrote:

> and what was wrong with mk?

well with gnu make you can image building gcc.

I am wondering if you couldn't build gcc 0.1 or whatever, and once that 
was working, iterate up to later versions by building on the first 
version. My memory from 0.1 was that it was pretty portable.

ron

Re: [9fans] GNU Make

[boyd, rounin]

> I am wondering if you couldn't build gcc 0.1 or whatever, and once that 
> was working, iterate up ...

yeah, i was thinking of stepwise iteration.

Re: [9fans] GNU Make

[Russ Cox]

> I am wondering if you couldn't build gcc 0.1 or whatever, and once that
> was working, iterate up to later versions by building on the first
> version. My memory from 0.1 was that it was pretty portable.

why bother?  gcc3 is already ported.

Re: [9fans] GNU Make

[ron minnich]

On Tue, 1 Jun 2004, Russ Cox wrote:

> > I am wondering if you couldn't build gcc 0.1 or whatever, and once that
> > was working, iterate up to later versions by building on the first
> > version. My memory from 0.1 was that it was pretty portable.
> 
> why bother?  gcc3 is already ported.

because the last word I had was that it was very painful for the person
who did the port, said person is (sadly) no longer with us, and the work
could not be repeated by others. The last item is the one of most concern. 

ron

Re: [9fans] GNU Make

[Russ Cox]

> because the last word I had was that it was very painful for the person
> who did the port, said person is (sadly) no longer with us, and the work
> could not be repeated by others. The last item is the one of most concern.

surely if it were time to repeat the work,
starting with gcc3 would be a lot less
painful than starting with gcc 0.1.

Re: [9fans] GNU Make

[boyd, rounin]

one word:  native

Re: [9fans] GNU Make

[lucio]

> well with gnu make you can image building gcc.
> 
> I am wondering if you couldn't build gcc 0.1 or whatever, and once that 
> was working, iterate up to later versions by building on the first 
> version. My memory from 0.1 was that it was pretty portable.

I can only presume that dhog was under pressure to build GCC (how
could he not be?) and that it was simpler to bootstrap it using GCC
itself.  As far as I understand, both GCC and the binutils are fairly
portable, there ought to be a way to port GCC using the native
compiler in its APE impersonation.

Binutils 2.15 have just been released, with a minor glitch I was
hoping would be corrected immediately, but not serious enough to
interfere with building them under APE.  But it will take me some
time and effort.

Once I have gas and ld, GCC 3.5 ought to be released (if it isn't
already) and then whether I use dhog's 3.0 or try to bring the lot
under APE will be an informed decision to be made at the time.  The
crucial thing will be to leave a structure in place so that the
porting efforts are not lost.

As an aside, dhog seemingly needed m4 as well as gmake, I have made
both of these APE-compliant.  Whether we now place them in
/sys/src/ape/cmd or the main /sys/src/cmd (as was done with CVS)
depends on the wishes of the authorities.  Frankly, my opinion is that
they ought to be in an area of their own so that new releases can more
easily be tracked.  CVS and ghostscript might need to move there as
well.

Lastly, APE attempts to compute errno by searching a list of error
strings to find a match.  Would it be out of the question to enhance
all Plan 9 software to use a library of error messages that also
includes a numeric code?  I appreciate it is a tall order, but even if
it needed to be released as 5th Edition I believe it would be a
significant improvement.  I'm willing to do it, but I'm sure I could
use all the advice this list is capable of.

++L

Re: [9fans] GNU Make

[Charles Forsyth]

>>all Plan 9 software to use a library of error messages that also
>>includes a numeric code?

Numeric codes are a bad idea, that plan 9 was well rid of from unix.
they do not scale well in a distributed system with distributed development.

even the internet protocols that use them tend to degenerate into `good, bad, ugly'
based on the first digit (0, 4, 5 say).

it's just one reason that NFS had terrible trouble across systems with
different errno values.  precise diagnostics ended up being mapped into EIO,
which wasn't always the right answer, just because there was no portable
way to convert an arbitrary code from one system to an arbitrary code in another.
n*m indeed.  of course, you could have MegaErrnoInc act as a global
registry of mappings, as Sun tried with Sun RPC, but for this application it doesn't
work well.

some uniformity in the error strings would be desirable,
but numeric codes should not be used.

Re: [9fans] GNU Make

[John Murdie]

On Wed, 2004-06-02 at 08:36, Charles Forsyth wrote:
> >>all Plan 9 software to use a library of error messages that also
> >>includes a numeric code?
> 
> Numeric codes are a bad idea, that plan 9 was well rid of from unix.
> they do not scale well in a distributed system with distributed development.
> 
> even the internet protocols that use them tend to degenerate into `good, bad, ugly'
> based on the first digit (0, 4, 5 say).
> 
> it's just one reason that NFS had terrible trouble across systems with
> different errno values.  precise diagnostics ended up being mapped into EIO,
> which wasn't always the right answer, just because there was no portable
> way to convert an arbitrary code from one system to an arbitrary code in another.
> n*m indeed.  of course, you could have MegaErrnoInc act as a global
> registry of mappings, as Sun tried with Sun RPC, but for this application it doesn't
> work well.
> 
> some uniformity in the error strings would be desirable,
> but numeric codes should not be used.

I, too, dislike numeric error codes, but how do you think multiple
natural languages should be accommodated? I've no experience of this
with Plan 9. Does it cope well?

John A. Murdie
Department of Computer Science
University of York

Re: [9fans] GNU Make

[Charles Forsyth]

>>but how do you think natural languages should be accommodated?

that's a reasonable question.

as it happens, the %r messages are typically the least of your worries, and indeed if
you've got real end-users (ie, non-programmers) are
often best regarded as internal error diagnostics for implementors,
and left as-is so that those implementor will recognise them.
it's hard enough debugging programs as it is, without the Chinese Whispers effect
compounded by language changes within.

for user interfaces we've found historically that the use of a hashed map string -> string works well
(it's rather more than that, because there can be pre- and post-processing,
but that gives the idea), and any or all %r messages that need to escape
can go through that.  that overall approach worked well on a big commercial
system that supported all the major Western European languages, including dialects.
it was much easier to manage than the contemporary msgcat scheme (i think that was it).
you need extra things to do sorting, and comparison, and more; and perhaps most
of all you need good translators.  the scheme allowed annotations for strings, so that
one could distinguish `the times' from `The Times', the latter not to be translated, or
depending on context(!) to be translated to some local equivalent (eg, `USA Today'),
although as that last example shows it's often quite a loose translation.

Re: [9fans] GNU Make

[ron minnich]

On Wed, 2 Jun 2004, Charles Forsyth wrote:

> Numeric codes are a bad idea, that plan 9 was well rid of from unix.
> they do not scale well in a distributed system with distributed
> development.

I agree with everything you're saying. But if you're going to 
interoperate with Unix systems, there aren't a lot of options. 

After all, strcmp() on a table of error strings is hardly an improvement 
over numeric codes.

ron

Re: [9fans] GNU Make

[lucio]

Ron Minnich wrote:

> On Wed, 2 Jun 2004, Charles Forsyth wrote:
> 
>> Numeric codes are a bad idea, that plan 9 was well rid of from unix.
>> they do not scale well in a distributed system with distributed
>> development.
> 
> I agree with everything you're saying. But if you're going to 
> interoperate with Unix systems, there aren't a lot of options. 

Wait a moment, maybe there are options?

Hm, maybe not, but perhaps somebody can sanity check me here.  It
seems to me that the crucial factor lies with the return codes from
the Plan 9 system calls when used by APE simulation procedures.
Perhaps we can arrange the core system calls to return error
identification "codes" that are then readily translated both in APE
and in P9 to the results required in that environment.

Would the cost be excessive?  Somehow, considering that this happens
only on error conditions, I should think not.

Would it be difficult to do?  Others here are better qualified to
judge.  In particular, those very authorities are best qualified to
recommend how to approach this.

++L

Re: [9fans] GNU Make

[ron minnich]

On Wed, 2 Jun 2004 lucio@proxima.alt.za wrote:

> Hm, maybe not, but perhaps somebody can sanity check me here.  It
> seems to me that the crucial factor lies with the return codes from
> the Plan 9 system calls when used by APE simulation procedures.

or: 
- 9p server on Plan 9 to Unix/Linux client (they want errno)
- u9fs server on Unix to Unix client

Still, it is hard to argue with the proposition that propagating errno is 
propagating braindamage. Maybe we'd better just drop this :-)

ron

Re: [9fans] GNU Make

[boyd, rounin]

error strings to codes or another language is a nightmare.

so is:

  echo us centric string > /dev/foo/ctl

Re: [9fans] GNU Make

[lucio]

> error strings to codes or another language is a nightmare.
> 
> so is:
> 
>   echo us centric string > /dev/foo/ctl

The former is a continuing "failure of vision" that will eventually be
resolved out of necessity.  The latter may be solved with the former
if everyone gets to speak English (not out of the question, either,
although we may not recognise it as English), alternatively, one can
provide translation shims everywhere.  At least the target strings are
documented and usually concise.  It's really not much worse than
programming with "if" and "while".

++L

Re: [9fans] GNU Make

[Charles Forsyth]

>>The former is a continuing "failure of vision" that will eventually be
>>resolved out of necessity.  The latter may be solved with the former

i wonder if a message got lost.  in another commercial product a group
of us years ago handled messages in many natural languages in programs without fuss,
in a serious commercial product that was, and i believe still is,
widely used with many Western European languages.  it did not need the
use of message codes.  strings worked well.
the text of the message in the program was its own `index'.  still seems
straightforward to me.  the strings are anyway the subject
of translation by the translators!  you can't get away from them.
all those strcmps?  hash.  works for messages in files, too,
though there are other searching techniques.  more recently, an even
simpler scheme for messages was successfully used in Limbo applications.
i used a hash table, but as it happens, i accidentally produced
a degenerate one.  i still didn't notice for two years, even with profiling;
it's just not that much of a bottleneck in many cases.

it's the least of your worries as i said before: working out how to arrange
the strings to cope with the differing requirements of various natural languages
for word order, or `dictionary order' (which can vary across dialects of the
same language), and several other things, all require extra mechanisms.
for each string in a program, one needs to decide whether the text is essentially
`program' or whether it's `speech'.
it's helpful to have a conventional form for the text of such messages so
they can be extracted automatically for translation (assuming the compiler can't assist).

in many cases, system diagnostics
should not be translated (or indeed must not be translated) because they are input
to other programs, or internal diagnostics that should remain as-is.
actually, given the extent of program tools when scripting, it's probably
true that most existing messages wouldn't be translated anyway.
one of the nice things about the change to largely GUI-oriented interfaces
is that it's more obvious which bits of text are intended to be understood
by users of an application.  most output of programs such as sed, file, etc.
would not be seen directly (by a `real' end user).

the failure of vision here is to think that just using integers will solve anything.
first, it complicates distributed development (who assigns the integers?
shall we have the usual hack of a `user-defined range'?  what happens when
i federate two systems?), as the varying assignment
within Unix systems shows, and they were dealing with a largely fixed set of
system calls and outcomes (so in principal one could enumerate most of
the possibilities).  even then, quite a few things settle for EIO.
that's a great help.

to get round the problem of differing errno assignments in Unix, one could
use EAGAIN (or is it EWOULDBLOCK?), ENOENT, etc. but hang on: that's
just a string and you'll still need to put it through a map.  EBAHGUM.

more important, with user-level file servers
the set of possible diagnostics is unbounded, because the range of application
is not limited as it was (at least until recently) in Unix.

there is a smaller `failure of vision' though: Lucio is right that a little
more discipline in forming the text of the strings might help.
file servers that really do serve up real files could use the same text
for the same errors.  it's a rather tedious job to go round the source to do it,
but it's no more tedious than collecting messages for translation in any case.

Re: [9fans] GNU Make

[boyd, rounin]

you could do %r as a cryptographic hash for translation.

you return the %r chunk and then hash it into an associative array of translated messages, indexed by hash.

Re: [9fans] GNU Make

[lucio]

> you could do %r as a cryptographic hash for translation.

How about %#r returns a 32-bit binary, none too involved, hash?

++L

Re: [9fans] GNU Make

[Rob Pike]

> How about %#r returns a 32-bit binary, none too involved, hash?

i am confused.  what about all that information you can have
because it's a string, things that very from invocation to
invocation?  unix says 'bus error'; plan 9 tells you the pc of
the fault, or in other cases the file name that failed, the
fp trap condition, and so on and so on. it's not some
set of 23 errors; it's a huge informative space. why give that
up?

-rob

Re: [9fans] GNU Make

[boyd, rounin]

> unix says 'bus error'; plan 9 tells you the pc of
> the fault, or in other cases the file name that failed, the
> fp trap condition, and so on and so on. it's not some
> set of 23 errors; it's a huge informative space. why give that
> up?

i wasn't advocating that.  the core messages such as 'bus error'
(or whatever) can be translated.  the pc or fp error codes are
gonna be a) not useful to translate or b) impossible to translate.

i 'spose you could return numeric info in roman numerals, but ... ;)

Re: [9fans] GNU Make

[lucio]

> i am confused.  what about all that information you can have
> because it's a string, things that very from invocation to
> invocation?  unix says 'bus error'; plan 9 tells you the pc of
> the fault, or in other cases the file name that failed, the
> fp trap condition, and so on and so on. it's not some
> set of 23 errors; it's a huge informative space. why give that
> up?

Because there is madness at the end of that road, too?

Yes, that is all extremely human-friendly, but one can't invest
infinite amounts of computing power in interpreting error messages
that do not reach the user.  Or that the user is going to ignore
anyway.

I guess my faith in artificial intelligence is not sufficient and my
impression is that computing devices are beginning to communicate with
each other and don't cope well with fuzzy completion messages.

Once again, my opinion is that errors ought to be reported as
concisely as possible within ambiguity constrains and that it ought to
be possible to request the additional details separately.  But I seem
to be in a minority.

++L

Re: [9fans] GNU Make

[Rob Pike]

> Because there is madness at the end of that road, too?

why?

> Yes, that is all extremely human-friendly, but one can't invest
> infinite amounts of computing power in interpreting error messages
> that do not reach the user.  Or that the user is going to ignore
> anyway.

what are you talking about?
 
> Once again, my opinion is that errors ought to be reported as
> concisely as possible within ambiguity constrains and that it ought to
> be possible to request the additional details separately.  But I seem
> to be in a minority.

as concisely as possible is '23'.  are you advocating that?
the errors are there *for the user*, not for programs.
corrupting a system that works hard -- and mostly
successfully -- to deliver clear, helpful, detailed error
messages, in order to make some bastard subsystem
spend less CPU time *for users accustomed to unhelpful
messages* (for such is unix's lot) is perverse.

APE can go jump in a lake.  

-rob

Re: [9fans] GNU Make

[rog]

> the errors are there *for the user*, not for programs.

IMO it is useful, occasionally, for a program to be able
to distinguish between classes of error.

but perhaps you disagree?

Re: [9fans] GNU Make

[boyd, rounin]

> but perhaps you disagree?

perhaps the should only return BROKEN and tell the user instead of the ECALLBACKINAWHILEIFYOURFEELINGLUCKYPUNK ... ?

Re: [9fans] GNU Make

[lucio]

> perhaps the should only return BROKEN and tell the user instead of the ECALLBACKINAWHILEIFYOURFEELINGLUCKYPUNK ... ?

They _do_ return BROKEN, that's what the "error" condition conveys.
Now we need to discuss how to represent the particular error condition
involved and to what extent.

In my opinion, it is desirable to be able to express the details in
more than one language, one of the languages being that understood by
Unix.  To this end, my preference is for a documented, disciplined
message format.  Such a message format would make it possible to
express all available details _and_ still provide a more general (the
class that rog mentions) index for circumstances when the details are
not important.  The APE simplification then falls out automatically.

++L

Re: [9fans] GNU Make

[lucio]

>> Because there is madness at the end of that road, too?
> 
> why?
> 
Well, not all error conditions require an unfamiliar user to attend to
them in great detail.  In particular, by making each error message
extremely "clear, helpful and detailed" one is targeting an audience
that may be thoroughly disinterested.

>> Yes, that is all extremely human-friendly, but one can't invest
>> infinite amounts of computing power in interpreting error messages
>> that do not reach the user.  Or that the user is going to ignore
>> anyway.
> 
> what are you talking about?
>  
There are very few instances where MS Windows error pop-ups actually
say "Press RESET".  Some of them suggest it indirectly.  Yet, largely,
pressing the RESET button is in my experience what the user does in
response to error message with the slightest technological slant.

>> Once again, my opinion is that errors ought to be reported as
>> concisely as possible within ambiguity constrains and that it ought to
>> be possible to request the additional details separately.  But I seem
>> to be in a minority.
> 
> as concisely as possible is '23'.  are you advocating that?

I would be, if it wasn't already taken.  What I don't want is a
message that requires me to use the google search engine (yes, I know
it's a cheap shot) to locate the knowledge base information that tells
me there is a bug in the program I'm using.  I'm suggesting that a
help system that can explain, on demand, what might have triggered an
error condition may be preferable to being offered two paragraphs of
explanations that I have little use or understanding for.  But
providing such a help system is very difficult if each error return is
subtly differently worded from its immediate neighbour that attempts
to convey the same information.

> the errors are there *for the user*, not for programs.
> corrupting a system that works hard -- and mostly
> successfully -- to deliver clear, helpful, detailed error
> messages, in order to make some bastard subsystem
> spend less CPU time *for users accustomed to unhelpful
> messages* (for such is unix's lot) is perverse.
> 
Oh, I have no doubt I'm perverse.  But that does not mean that there
aren't different ways to see this issue, depending on what one's
objectives and possibly principles are.

> APE can go jump in a lake.  
> 
It's a stepping stone, dropping it in depths of the lake is not going
to help in crossing the lake without getting wet (facetious reference
to ability to walk on water omitted).

++L

Re: [9fans] GNU Make

[boyd, rounin]

> Numeric codes are a bad idea, that plan 9 was well rid of from unix.
> they do not scale well in a distributed system with distributed development.

agreed.

Re: [9fans] GNU Make

[Richard Miller]

> Would it be out of the question to enhance
> all Plan 9 software to use a library of error messages that also
> includes a numeric code?

You mean like
  IEF450I JOBXXX STEPA - ABEND=S0C4 REASON=00000010

Yes, those were the good old days.

Re: [9fans] GNU Make

[lucio]

> You mean like
>   IEF450I JOBXXX STEPA - ABEND=S0C4 REASON=00000010
> 
> Yes, those were the good old days.

Computers weren't commodities, then.  Was that any worse than a pop-up
window that describes everything except what the error is really about
and gives no pointers to additional information?  At least with the
IBM manuals, it was possible to find out where the above originated
and to establish an apporximation to the cause.

All I'm after is a somewhat less expensive approach to translating an
error message to its nearest Unix errno.  This is no more demanding
than providing for multilanguage error messages, something Plan 9 will
no doubt have to do before too long.

++L

Re: [9fans] GNU Make

[Charles Forsyth]

>>and gives no pointers to additional information?  At least with the
>>IBM manuals, it was possible to find out where the above originated
>>and to establish an apporximation to the cause.

Messages and Codes was notoriously unhelpful in many cases.
often the diagnosis and suggested resolution was infuriatingly
similar to the answer to the joke
``Doctor!  It hurts when I do this.''.

Re: [9fans] GNU Make

[ron minnich]

On Wed, 2 Jun 2004 lucio@proxima.alt.za wrote:

> > You mean like
> >   IEF450I JOBXXX STEPA - ABEND=S0C4 REASON=00000010
> > 
> > Yes, those were the good old days.
> 
> Computers weren't commodities, then.  Was that any worse than a pop-up
> window that describes everything except what the error is really about
> and gives no pointers to additional information?  At least with the
> IBM manuals, it was possible to find out where the above originated
> and to establish an apporximation to the cause.

I don't get it, you think 'phase error' is not a useful error message :-)

ron

Re: [9fans] GNU Make

[Steve Simon]

> All I'm after is a somewhat less expensive approach to translating an
> error message to its nearest Unix errno.

Expense is related to how common an occurance the event is. Errors are
(hopefully) rare so their expense in supporting imported (IE ape)
software is not so unreasonable.

I thing texture error messares are one pf plan9's great streangths.

I have had sam give "/n/netware/a/b/xxx.c cannot open - file locked" 
on occasion. File locking is an alien concept to plan9 but I still
get the correct and informative error from the imported netware filesystem.

-Steve

Re: [9fans] GNU Make

[lucio]

> I have had sam give "/n/netware/a/b/xxx.c cannot open - file locked" 
> on occasion. File locking is an alien concept to plan9 but I still
> get the correct and informative error from the imported netware filesystem.

Maybe I'm harping, feel free to tell me.  However, the utility that
reports an error merely passes to the caller a pointer to a character
string.  That very pointer could be used as a message identifier if
used in such fashion.  So why not return an index?  So you may need a
lookup function that traps accesses beyond the table boundaries and
reports them as erroneous together with, if possible, the source and
location of the problem.  How hard is that going to be?

As for the efficiencies involved, it is not only performance that's
involved, it's also scalability: use a slightly different format for
your error message (a tab turned to a space) and the mapping fails.

Not that I know the answer, I'm just stirring the pond, hoping some
new ideas pop up.

++L

Re: [9fans] GNU Make

[ron minnich]

On Wed, 2 Jun 2004 lucio@proxima.alt.za wrote:

> I can only presume that dhog was under pressure to build GCC (how could
> he not be?) and that it was simpler to bootstrap it using GCC itself.  
> As far as I understand, both GCC and the binutils are fairly portable,
> there ought to be a way to port GCC using the native compiler in its APE
> impersonation.

yes, but I was hoping the iterative process from 0.x would get us native,
i.e.  skip APE. In the early days gcc was very portable, and would compile
under just about any C compiler. Nowadays, what with all the lovely
extras, I'm not sure it compiles well under non-gcc-compatible compilers.

> Lastly, APE attempts to compute errno by searching a list of error
> strings to find a match.  Would it be out of the question to enhance
> all Plan 9 software to use a library of error messages that also
> includes a numeric code?  

I did this on v9fs in the early days: error messages in my 9p looked 
like this:
xxxx You screwed up

xxxx was the error code. You screwed up was an error message. On systems
without errstr, you returned xxxx as a number, otherwise, you return the
message. So you had an errno and errstr compatible TERRROR message at the
protocol level. 

I proposed this a while back to some folks but got a negative response.

I still find that doing strcmp() on a set of error strings to produce
errno is both gross and non-portable due to subtle variations in error
strings between different Unixes.


ron

Re: [9fans] GNU Make

[C H Forsyth]

>>I still find that doing strcmp() on a set of error strings to produce
>>errno is both gross and non-portable due to subtle variations in error
>>strings between different Unixes.

i thought ape was doing strcmp on a set of Plan 9 error strings to
produce unix errno.

the errno values aren't portable either.  i suppose you could use
ENAME but you'd still need a table, and the set of names is still open-ended.
with errno, you can't just index into a table
to remap things because even the range isn't predictable.
i've seen variations even within one manufacturer.

i think it might, however, be useful to have more predictable strings
(is it `directory entry not found' or `file not found')

Re: [9fans] GNU Make

[Charles Forsyth]

>>(is it `directory entry not found' or `file not found')

of course i meant: or `file does not exist' ...

Re: [9fans] GNU Make

[Charles Forsyth]

>>yes, but I was hoping the iterative process from 0.x would get us native,
>>i.e.  skip APE. In the early days gcc was very portable, and would compile
>>under just about any C compiler. Nowadays, what with all the lovely
>>extras, I'm not sure it compiles well under non-gcc-compatible compilers.

it seems to assume sys/types.h and (funnily enough) errno.h, amongst others,
so it's mildly APE; many of the others are included only if many things are #defined
so might not matter.  the assumed library is essentially APE

system.h (644 lines) has many things like this:
	/* 1 if we have C99 designated initializers.  */
	#if !defined(HAVE_DESIGNATED_INITIALIZERS)
	#define HAVE_DESIGNATED_INITIALIZERS \
	  ((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L))
	#endif

	/* 1 if we have _Bool.  */
	#ifndef HAVE__BOOL
	# define HAVE__BOOL \
	   ((GCC_VERSION >= 3000) || (__STDC_VERSION__ >= 199901L))
	#endif

	/* Test if something is a socket.  */
	#ifndef S_ISSOCK
	# ifdef S_IFSOCK
	#   define S_ISSOCK(m) (((m) & S_IFMT) == S_IFSOCK)
	# else
	#   define S_ISSOCK(m) 0
	# endif
	#endif

	/* Test if something is a FIFO.  */
	#ifndef S_ISFIFO
	# ifdef S_IFIFO
	#  define S_ISFIFO(m) (((m) & S_IFMT) == S_IFIFO)
	# else
	#  define S_ISFIFO(m) 0
	# endif
	#endif

but then i can't find them used.

Re: [9fans] GNU Make

[lucio]

> but then i can't find them used.

Well, yes, what does a compiler need to know about sockets?

Unfortunately, it takes a lot more effort to lose bloat than to put it
on.

++L

Re: [9fans] GNU Make

[lucio]

> it seems to assume sys/types.h and (funnily enough) errno.h, amongst others,
> so it's mildly APE; many of the others are included only if many things are #defined
> so might not matter.  the assumed library is essentially APE

Does anyone else here believe that APE is worth enhancing?  I'm no fan
of glibc, but I do believe that efforts towards adding Posix
capabilities to Plan 9, clearly labelled as "use is detrimental to
sanity", are not wasted.

Still, my objective is to remove the dependence of the GNU development
tools from GCC as far as that will go.  I don't object to the GNU/APE
separation, but I find the duplication of tools hard to maintain and
the problem with GNU tools - like with Microsoft software - is that
you can't afford to lag too far behind the current release.

Right now, I'm battling to get APE wait4() to approximate the spec
more closely.  That will be followed by select(), I suppose.

And while I'm at it, has anyone figured out why even with the actual
object macros, I can't get Plan 9 troff (or nroff?) to present the
NetBSD man pages anywhere near readably?  Suggestions on how to get
this fixed will be gratefully accepted.  Rewriting the man pages is
not much of an option, of course.

++L

Re: [9fans] GNU Make

[Joel Salomon]

lucio@proxima.alt.za said:
> And while I'm at it, has anyone figured out why even with the actual
> object macros, I can't get Plan 9 troff (or nroff?) to present the
> NetBSD man pages anywhere near readably?  Suggestions on how to get
> this fixed will be gratefully accepted.  Rewriting the man pages is
> not much of an option, of course.
>

Differences between plan9's -man and groff's -man, or is netbsd using
another macro set? Just a guess.

I have run into minor incompatibilities typesetting plan9's /sys/doc with
groff, though I'm think that it's utf in the files that's causing the
confusion.

--Joel

Re: [9fans] GNU Make

[a]

// Does anyone else here believe that APE is worth enhancing? 

i do, for what that's worth. posix is awful, but i'd rather see APE brought
up to par than put the work into the GNU stuff. i think rsc had talked
about it at some point (or i read it on one of his pages somewhere), too.

i'd rather everything was written nativly, of course. but it's not. and
we've all got better things to do that rewrite ghostscript.

Re: [9fans] GNU Make

[Kenji Okamoto]

> we've all got better things to do that rewrite ghostscript.

I believe the problem between ghostscript and Plan 9 lies in the
fact that each uses different character code set, CID-keyed and
UTF-8. ☺

Kenji