[9fans] GNU Make

[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.

Error reporting (Was: [9fans] GNU Make)

[lucio]

> 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.

Yes, it would simplify the APE translation as well.  And the
associative array of translated messages may as well contain the
English version, anyway.

I think I was missing something: I now understand that numeric error
codes are bound to collide whereas if natural language messages happen
to collide - already a much less likely scenario - chances are
extremely good that it doesn't matter.  In fact, one could declare it
not to matter.

That was one point I did not quite grasp until now.  I think that
Boyd's and forsyth's suggestions should be implemented.  I'll revise
my data processing textbooks and see if I can come up with a
reasonable hashing algorithm and improve APE's message lookup
algorithm.  I have a feeling that it is not going to end there.

++L

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

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

no you couldn't, 'cos the kernel adds a filename for some error messages.

was there a good reason why the filename was put in front of the error
message rather than vice versa?  it seems odd - it means you have to
parse the error message, rather than just doing a strncmp, and you
don't have to worry too much about the filename being truncated at the
end.

Re: Error reporting (Was: [9fans] GNU Make)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 53 bytes --]

i assume because it reads better, in english anyway

[-- Attachment #2: Type: message/rfc822, Size: 2587 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: Error reporting (Was: [9fans] GNU Make)
Date: Thu, 3 Jun 2004 15:01:47 +0100
Message-ID: <4a8f5dee0a8d8ba7be23785692dd2317@vitanuova.com>

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

no you couldn't, 'cos the kernel adds a filename for some error messages.

was there a good reason why the filename was put in front of the error
message rather than vice versa?  it seems odd - it means you have to
parse the error message, rather than just doing a strncmp, and you
don't have to worry too much about the filename being truncated at the
end.

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

> i assume because it reads better, in english anyway

this is a pity.
i think something like:

	file does not exist: '/usr/rog/dvfgfdds'

is just as readable, and adheres to the usual convention
for cascading of error messages (most to least recent;
truncation can occur at the end if necessary).

it is sometimes necessary to have a program distinguish
between error messages, and the way i've seen some
programs deal with the current convention:

	n = sizeof " does not exist" - 1;
	if(strlen(e) > n && strcmp(strlen(e)-n, " does not exist")){
		/* file does not exist */
	}

is just wrong.

[-- Attachment #2: Type: message/rfc822, Size: 5122 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 53 bytes --]

i assume because it reads better, in english anyway

[-- Attachment #2.1.2: Type: message/rfc822, Size: 2587 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: Error reporting (Was: [9fans] GNU Make)
Date: Thu, 3 Jun 2004 15:01:47 +0100
Message-ID: <4a8f5dee0a8d8ba7be23785692dd2317@vitanuova.com>

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

no you couldn't, 'cos the kernel adds a filename for some error messages.

was there a good reason why the filename was put in front of the error
message rather than vice versa?  it seems odd - it means you have to
parse the error message, rather than just doing a strncmp, and you
don't have to worry too much about the filename being truncated at the
end.

Re: Error reporting (Was: [9fans] GNU Make)

[boyd, rounin]

> is just wrong.

apart from the potential right-to-left and Rune problems.

Re: Error reporting (Was: [9fans] GNU Make)

[lucio]

> apart from the potential right-to-left and Rune problems.

I'd expect rtl to be represented start-to-end rather than mirror image
as you imply.  I never thought about it before.  As for runes, if you
know what you're looking for, all you want is identity.  But it
doesn't scale to generic message checking.

++L

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

> > is just wrong.
>
> apart from the potential right-to-left and Rune problems.

i don't think there are any Rune problems with that code.
it will correctly match any string ending in " does not exist"
(unless i got off-by-one, which is entirely possible).

Re: Error reporting (Was: [9fans] GNU Make)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

i think i might have used strstr.
ok, i suppose you might have a file with 'does not exist' in its name,
but i can't say i lose much sleep over it.  could use strqstr to look outside quotes i suppose.

also, in

term% ls /sys/src/cm/db
ls: /sys/src/cm/db: '/sys/src/cm/db' does not exist

if it were

ls: /sys/src/cm/db: file does not exist: '/sys/src/cm/db' 

i'd find it a little odd to read, myself, although again i can't get too worked up about it.

in APE's case i suspect i'd settle for putting the most common error
strings at the front, on the grounds that most applications stop processing
once an error occurs anyhow, except for access/open/exec/stat when
used to search for something.  (so do the check for `does not exist' or
`no permission' early.)

is this worry the result of having profiled something important?
i vaguely remember from my time fighting it that gcc's cpp
causes the computer to wade through
pages of filth to get anywhere when doing the search lists for #include
but there's much more to slow you down in that thing.
perhaps like Linus's scheduler someone has finally done the decent thing?
anyhow: IS there a real cause to worry about APE's string -> errno
translation speed based on (say) a profile of an application, or is
it conjecture?

[-- Attachment #2: Type: message/rfc822, Size: 8170 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 615 bytes --]

> i assume because it reads better, in english anyway

this is a pity.
i think something like:

	file does not exist: '/usr/rog/dvfgfdds'

is just as readable, and adheres to the usual convention
for cascading of error messages (most to least recent;
truncation can occur at the end if necessary).

it is sometimes necessary to have a program distinguish
between error messages, and the way i've seen some
programs deal with the current convention:

	n = sizeof " does not exist" - 1;
	if(strlen(e) > n && strcmp(strlen(e)-n, " does not exist")){
		/* file does not exist */
	}

is just wrong.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 5122 bytes --]

[-- Attachment #2.1.2.1.1: Type: text/plain, Size: 53 bytes --]

i assume because it reads better, in english anyway

[-- Attachment #2.1.2.1.2: Type: message/rfc822, Size: 2587 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: Error reporting (Was: [9fans] GNU Make)
Date: Thu, 3 Jun 2004 15:01:47 +0100
Message-ID: <4a8f5dee0a8d8ba7be23785692dd2317@vitanuova.com>

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

no you couldn't, 'cos the kernel adds a filename for some error messages.

was there a good reason why the filename was put in front of the error
message rather than vice versa?  it seems odd - it means you have to
parse the error message, rather than just doing a strncmp, and you
don't have to worry too much about the filename being truncated at the
end.

Re: Error reporting (Was: [9fans] GNU Make)

[lucio]

> anyhow: IS there a real cause to worry about APE's string -> errno
> translation speed based on (say) a profile of an application, or is
> it conjecture?

Well, the particular instance that raised it was tmpnam() where
access() is being used to determine whether a filename is already in
use.  access() spends an inordinate amount of time trying to return an
error code that is never going to be used.  That bothered me.

The other place is the return code in wait() which seems very
important to Tcl.  Here, I'm trying to reduce the number of test
failures, specially when they don't seem unavoidable, at first at
least.

My current problem is only tangentially related to error codes, as I
can't seem to get waitpid() to behave closely enough to its Unix
equivalent.

++L

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

> i think i might have used strstr.
> ok, i suppose you might have a file with 'does not exist' in its name,

it's not this.

it's when you have error messages that contain other
error messages, e.g.

cannot allocate resource: '/x/y' does not exist

here the relevant error message is "cannot allocate resource".
the rest is useful for tracking down the problem (and hence
is worth including), but isn't directly relevant to a program
interested in finding out the primary meaning of the error message.

Re: Error reporting (Was: [9fans] GNU Make)

[C H Forsyth]

>>cannot allocate resource: '/x/y' does not exist

i'm not sure that was a good example.

especially in the APE context, and perhaps not just there,
i'd have said that ENOENT was fine.  that's why it ultimately
couldn't allocate the resource, and being the underlying error,
could be regarded as the more important aspect or at least equally important
in this case.

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

> >>cannot allocate resource: '/x/y' does not exist
> 
> i'm not sure that was a good example.
> 
> especially in the APE context, and perhaps not just there,
> i'd have said that ENOENT was fine.  that's why it ultimately
> couldn't allocate the resource, and being the underlying error,
> could be regarded as the more important aspect or at least equally important
> in this case.

i was imagining this might happen when opening a "clone"
file for example. the error is not that the file itself does not
exist (it does) but that the thing serving the file encountered
an error when trying to open it. the text after the colon
describes the reason for that error (which happened to involve
another file '/x/y').

it would be misleading for APE to report ENOENT in this
case, i think.

Re: Error reporting (Was: [9fans] GNU Make)

[Charles Forsyth]

i think you need to look at /sys/include/ape/errno.h and
/sys/src/ape/lib/ap/stdio/strerror.c
to see just how limited your choice will be!   there are a few other than
EIO you might pick but as it happens, programs that check for
them will have a more precise cause in mind, and the corresponding
strings would be much more misleading than plain ENOENT.

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

EIO might be better for unknown error codes than ENOENT.

as far as i remember, most error codes in unix were
either EINVAL or EIO...

a brief glance at the read(2) man page under bsd:

[EINVAL]		The pointer associated with d was negative.
[EINVAL]		Iovcnt was less than or equal to 0, or greater than 16.
[EINVAL]		One of the iov_len values in the iov array was negative.
[EINVAL]		The sum of the iov_len values in the iov array overflowed a 32-bit integer.
[EINVAL]		The specified file offset is invalid.

oh joy.

Re: Error reporting (Was: [9fans] GNU Make)

[C H Forsyth]

>>EIO might be better for unknown error codes than ENOENT.

     [EIO]              An I/O error occurred while making the directory entry
                        or allocating the inode for O_CREAT.

not really, since EIO would tend to suggest suggest (almost certainly
to a unix man and perhaps even me as well if i were to read it)
an actual error on a device (eg, bad block on drive), not an inability
to open an underlying file, and any programs that checked for it
would probably place that interpretation on it too.
at least ENOENT is honest when a file somewhere can't be accessed.
you'd be better off with EGREG (``something has happened that our little APE
can't communicate''), except that's not portable.

at any rate, it should be easier to see now why trying hard to change
things to make APE happy is not likely to produce the hoped-for joy and contentment.

it's not that there aren't enough integers in the world, more that
only a tiny subset is available as E numbers.  even with the extended
non-portable set in real Unix kernels the
E choice is pathetic for the things drivers might like to say.
of course, that does indeed lead to much tugging on hair and chins,
whilst trying to work out why a particular call failed.

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

> at any rate, it should be easier to see now why trying hard to change
> things to make APE happy is not likely to produce the hoped-for joy and contentment.

to be honest i wasn't really thinking about the APE world.  i was
thinking about how programs in the plan 9/inferno world might find out
about particular classes of error that they care about.

this:

nonexistent(e: string): int
{
	errs := array[] of {"does not exist", "directory entry not found"};
	for (i := 0; i < len errs; i++){
		j := len errs[i];
		if (j <= len e && e[len e-j:] == errs[i])
			return 1;
	}
	return 0;
}

is not good enough.

Re: Error reporting (Was: [9fans] GNU Make)

[C H Forsyth]

>>[nonexistent(e)] is not good enough.

for the particular error you described: a clone file can't be opened
because an underlying file didn't exist (that was what the message said),
i'd have said it was as good as any.

things like nonexistent tend to be used by programs searching
for files, so i don't see the problem in that application.
even if they are hunting for clone files, it would work, because
the name mumble/clone will exist; it will fail on open.

all i said was your example didn't seem a good one.
i didn't say you couldn't produce a better one, just that you hadn't yet.

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

> things like nonexistent tend to be used by programs searching
> for files, so i don't see the problem in that application.
> even if they are hunting for clone files, it would work, because
> the name mumble/clone will exist; it will fail on open.

the problem comes when it does something inappropriate based on the
judgement it's just made.

in the program from which that fragment came, it does:

	rfd = sys->open(path, omode);
	err = sprint("%r");
	if (rfd == nil && nonexistent(err)) {
		rfd = sys->create(path, omode, 8r666);
		err = nil;
	}

which might give surprising behaviour, given the error message in
question.

then again, maybe it's wrong for it to be trying to make
that judgement at all.

Re: Error reporting (Was: [9fans] GNU Make)

[boyd, rounin]

> is not good enough.

nah, linear search.

Re: Error reporting (Was: [9fans] GNU Make)

[boyd, rounin]

> as far as i remember, most error codes in unix were
> either EINVAL or EIO...

bzzzzt!  no

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

> > as far as i remember, most error codes in unix were
> > either EINVAL or EIO...
>
> bzzzzt!  no

well, i might have exaggerated a little, but a quick poke around the
bsd man pages gives me the following percentages (of all error codes
mentioned, 1129 total):

13.55 EINVAL
 10.36 EFAULT
  7.09 EIO
  6.82 EACCES
  6.64 EPERM
  5.49 EBADF
  4.87 ENOENT
  4.51 ENOTDIR
  4.25 ELOOP
  4.25 ENAMETOOLONG
  3.37 EROFS
  2.39 EAGAIN
  [...]

so EINVAL and EIO are definitely up there.  EFAULT pretty much always
means the same thing, so it doesn't count.

Re: Error reporting (Was: [9fans] GNU Make)

[boyd, rounin]

> > bzzzzt!  no
> 
> well, i might have exaggerated a little, but a quick poke around the
> bsd man pages gives me the following percentages (of all error codes
> mentioned, 1129 total):

checking my _physical_ 9th Ed manual there are/were 37 [EGREG].  8/9th Ed was based on 4.1BSD, for the record.

> so EINVAL and EIO are definitely up there.

former yes, but it means BUGGERED.  latter, as forsyth said,
can mean many things (i think its intention was to indicate a
physical i/o error).  i think probably dennis is the best reference,
to clear up this stupid ephemera.

> EFAULT pretty much always means the same thing, so it doesn't count.

it does count.  it means BUGGERED.

it's a good one; it means you fucked up and there is NO recovery
(unless you loop over user mode addresses until you smash
somewhere with something).  you get EFAULT?  you have a bug.

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

> > so EINVAL and EIO are definitely up there.
> 
> former yes, but it means BUGGERED.

nope, it means all sorts of things, as documented in the man pages
(but not expressed in the errno).

that's precisely where the open-ended plan 9 scheme wins out, and why
it was so annoying developing in a unix environment where all the info
you got when you did something wrong was "invalid argument" without
any indication as to what you'd done wrong.

this applied particularly to the sockets stuff.  i can't believe that
dross is still around.

Re: Error reporting (Was: [9fans] GNU Make)

[Charles Forsyth]

>>i can't believe that dross is still around.

``no dear, this is the dream.  you're still back in the cell.''

Re: Error reporting (Was: [9fans] GNU Make)

[Bruce Ellis]

I can't believe there are so many messages about this.
Plan9 error messages should be as informative, precise,
and *user readable* as possible without being too chatty.
The "bind" example is a good one and made me smile when
I first encountered the new one.  The kernel and most
filesystems do this well - and where they don't they
should be fixed.

I have no problems with someone spending a lot of time
coercing APE into behaving in a way they consider "more
correct" - it doesn't effect me.  I won't change all my
error messages to make this endless tweaking easier.

And rog's code has a race that has been known for at
least 25 years.

As for internationalization a simple library function
that smashes the %r message at the ":"s (observing
quoting) and "tries" to map the phrases would produce
satisfactory results in most cases, and when it can't
then the error message is buggered or unknown and
either the originator of the message or the mapper
should be fixed.

By "simple" I don't mean "not labourious"; consider

% ls -l /tmp/pus $home/pus
ls: /tmp/pus: '/tmp/pus' directory entry not found
ls: /usr/brucee/pus: '/usr/brucee/pus' does not exist

(/tmp is kfs, /usr/brucee is fossil)

Enough, I should be writing code.

brucee

Charles Forsyth wrote:

>>>i can't believe that dross is still around.
> 
> 
> ``no dear, this is the dream.  you're still back in the cell.''

Re: Error reporting (Was: [9fans] GNU Make)

[Scott Schwartz]

| % ls -l /tmp/pus $home/pus
| ls: /tmp/pus: '/tmp/pus' directory entry not found
| ls: /usr/brucee/pus: '/usr/brucee/pus' does not exist
 
My pet peeve: the message should say which path component drew
the error.  Is it pus or brucee or usr that does not exist?

Re: Error reporting (Was: [9fans] GNU Make)

[Bruce Ellis]

someone's broken something.  it used to report the
path component.

% ls -l /tmp/pus /tmp/pus/pus
ls: /usr/brucee/pus: '/usr/brucee/pus' does not exist
ls: /usr/brucee/pus/pus: '/usr/brucee/pus/pus' does not exist

i'm sure the second used to say:

ls: /usr/brucee/pus/pus: '/usr/brucee/pus' not a directory

brucee

Scott Schwartz wrote:

> | % ls -l /tmp/pus $home/pus
> | ls: /tmp/pus: '/tmp/pus' directory entry not found
> | ls: /usr/brucee/pus: '/usr/brucee/pus' does not exist
>  
> My pet peeve: the message should say which path component drew
> the error.  Is it pus or brucee or usr that does not exist?

Re: Error reporting (Was: [9fans] GNU Make)

[Russ Cox]

> someone's broken something.  it used to report the
> path component.

i noticed this a year ago but haven't tracked it down.
when we first put the long errors in, this was perhaps
the best new use.

russ

Re: Error reporting (Was: [9fans] GNU Make)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

sorry, i did know the source of that bug but hadn't fixed it.

removal of a goto considered harmful:
the original code at label NameError: used len = prefix+e.off[npath]
but the replacement nameerror() uses len = strlen(name), and indeed i don't think
Elemlist.off is used at all now.  nameerror() probably
needs an extra parameter or two to give it the right len
(and suitable changes to the code).

[-- Attachment #2: Type: message/rfc822, Size: 3254 bytes --]

From: Bruce Ellis <brucee@chunder.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: Error reporting (Was: [9fans] GNU Make)
Date: Fri, 04 Jun 2004 12:10:14 +1000
Message-ID: <40BFDA06.3000907@chunder.com>

someone's broken something.  it used to report the
path component.

% ls -l /tmp/pus /tmp/pus/pus
ls: /usr/brucee/pus: '/usr/brucee/pus' does not exist
ls: /usr/brucee/pus/pus: '/usr/brucee/pus/pus' does not exist

i'm sure the second used to say:

ls: /usr/brucee/pus/pus: '/usr/brucee/pus' not a directory

brucee

Scott Schwartz wrote:

> | % ls -l /tmp/pus $home/pus
> | ls: /tmp/pus: '/tmp/pus' directory entry not found
> | ls: /usr/brucee/pus: '/usr/brucee/pus' does not exist
>  
> My pet peeve: the message should say which path component drew
> the error.  Is it pus or brucee or usr that does not exist?

Re: Error reporting (Was: [9fans] GNU Make)

[Bruce Ellis]

well it'a done. had a word with boyd and wrote a
bit of code (1 hour) and we got this ... just
go lang=fr boydo.

en:
ls pus
ls: pus: 'pus' file does not exist
ls a
ls: a: permission denied
fr:
ls pus
ls: pus: 'pus' fichier n'existe pas
ls a
ls: a: permission refusée
nz:
ls pus
ls: pus: 'pus' where da file bro?
ls a
ls: a: not for you, bro

if you can write maps like this ...

err="permission denied" map="permission refusée"

then stick them in /lib/errs/your_lang.

brucee

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

brucee:
> And rog's code has a race that has been known for at
> least 25 years.

unfortunately this was unavoidable in the situation it was being used.
rc has exactly the same race.

> As for internationalization a simple library function
> that smashes the %r message at the ":"s (observing
> quoting)

this is ok...  it just seems a pity that one has to put that unquoting
state machine where if one only put the filename at the end, a simple
strchr() would suffice.

Re: Error reporting (Was: [9fans] GNU Make)

[boyd, rounin]

> > you return the %r chunk and then hash it into an associative array of translated messages, indexed by hash.
> 
> no you couldn't, 'cos the kernel adds a filename for some error messages.

err, so change it.

Re: Error reporting (Was: [9fans] GNU Make)

[rog]

> > no you couldn't, 'cos the kernel adds a filename for some error messages.
>
> err, so change it.

it's good that it does add a filename, because otherwise you
don't know where the problem is, particularly when you've
got a system call (e.g. bind) which has two filename parameters.

perhaps the convention could be "hash everything up to the first colon".
that way you can include more detailed error reporting without
sacrificing programmability.

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

[9fans] internationalised error messages

[boyd, rounin]

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

no, rob is right. _core_ textual error messages are extensable
and loss of information is unacceptable.  send along the, say
english, text and crytpographically hash it and then look up
the hash in your table for whatever the language is you
wanna translate it into.

if you get a miss, examine the english text and add in
a new message (by hand).

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

[9fans] troff and 4.4BSD man pages

[Lyndon Nerenberg]

--On 2004-6-2 3:28 PM -0400 Joel Salomon <salomo3@cooper.edu> wrote:

> 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.

4.4BSD introduced the 'doc' macro package. It's a more structured 
variant of the 'an' macro package. All the 4.4BSD man pages were 
changed over to use -mdoc.

Writing a Plan9 native set of 'doc' macros is on my todo list, but it's 
not going to happen any time soon. (Although if a working troff pops up 
in the ports CVS tree, this will become a much higher priority for me.)

--lyndon

Re: [9fans] troff and 4.4BSD man pages

[Taj Khattra]

> (Although if a working troff pops up in the ports CVS tree,

the current ports version has some issues (#9 prefixes
are busted in a few spots), but the tarball i posted a
while ago works for me.

Re: [9fans] troff and 4.4BSD man pages

[boyd, rounin]

i think we [Christophe ?] and i found that the registers could
be now named with multi char names, yesterday.  iirc:

    .nr foo 1 1

    ...

    \([foo]

now, that is not troff.

Re: [9fans] troff and 4.4BSD man pages

[Douglas A. Gwyn]

boyd, rounin wrote:
> i think we [Christophe ?] and i found that the registers could
> be now named with multi char names, yesterday.  iirc:
>     .nr foo 1 1
>     ...
>     \([foo]
> now, that is not troff.

What is especially unfortunate is that SoftQuad did a
better job of designing such extensions to troff, but
whoever did the above came up with an incompatible
scheme.

Re: [9fans] troff and 4.4BSD man pages

[Jon Snader]

On Mon, Jun 07, 2004 at 08:55:11AM +0000, Douglas A. Gwyn wrote:
> boyd, rounin wrote:
> >i think we [Christophe ?] and i found that the registers could
> >be now named with multi char names, yesterday.  iirc:
> >    .nr foo 1 1
> >    ...
> >    \([foo]
> >now, that is not troff.
> 
> What is especially unfortunate is that SoftQuad did a
> better job of designing such extensions to troff, but
> whoever did the above came up with an incompatible
> scheme.

What's unfortunate is that we are spending more and more of our
time on this list bashing Unix/Linux/Gnu, instead of addressing
the advantages and problems with Plan 9.  It's always fun to stick
a finger in the eye of a competitor, of course, but providing a
vehicle for this pleasure is not my understanding of what Plan 9
is all about.

What's unfortunate is that our bashing is often misinformed, both
in spirit and in detail.  The above comments are a case in point.
Is there anyone here who really maintains that the two character
name space in [nt]roff is not a disadvantage?  Why should we
complain that groff has removed this disadvantage?  Why should we
not remove it from [nt]roff?  The answer given above is that the
extension is incompatible, but that is incorrect.  The groff
rules for using registers are the same as for [nt]roff except
that register names greater than 3 characters use brackets
*instead* of the opening parenthesis:

    \n[foo]  (NOT \([foo])
    \*[bar]
    etc.

Since I have personally typeset many of the Version 7 papers with
groff, I can attest to its compatibility with [nt]roff.

What's unfortunate is that many of us here act as if no one else has
anything to teach us.  Plan 9 is great software and a shining
example of excellence in design, but just maybe it isn't the
final answer on all questions.

jcs

Re: [9fans] troff and 4.4BSD man pages

[Aharon Robbins]

In article <z4udnTOQMJVTdlndRVn-jg@comcast.com> Doug Gwynn wrote:
>Jon Snader wrote:
> > What's unfortunate is that our bashing is often misinformed, both
> > in spirit and in detail.  The above comments are a case in point.
> > Is there anyone here who really maintains that the two character
> > name space in [nt]roff is not a disadvantage?  Why should we
> > complain that groff has removed this disadvantage?  Why should we
> > not remove it from [nt]roff?  The answer given above is that the
> > extension is incompatible, but that is incorrect.  The groff
> > rules for using registers are the same as for [nt]roff except ...
>
>Too bad you didn't bother to understand the comment to which
>you replied.  The incompatibility I mentioned was between
>groff and SoftQuad's prior extension of the register names.
>Now there are multiple formats for extended troff source
>documents, something that could easily have been avoided.

SoftQuad's troff is pretty much dead, and has been that way for quite
a while. You can't find it on their web site and I wonder who is still
using it?  O'Reilly used it for some of their books, but they switched
to using GNU Troff for their formatting a large number of years ago,
keeping SQtroff only for reprints of the books done with it.

(FWIW, even they have moved off troff to other technologies.)

In terms of sheer numbers, SQtroff can't hold a candle to
Groff, and I'd be curious to know how many people are still
using SQtroff at all.

As also mentioned, Groff is an *excellent* troff implementation.
With the compatibility flag, I have successfully printed Unix
documentation from 1980 with zero problems.  (The System III
doc for the MM macros, using the System III tmac.m file!)

I have even had groff diagnose mistakes in my input files that
Unix troff just silently accepted!

> > What's unfortunate is that many of us here act as if no one else has
> > anything to teach us.
>
>The GNU developers seem to provide support for that.

I beg your pardon?  I, at least, as a GNU developer, am well aware of
what there is to learn from others.  Other GNU developers are no more
subjective about their work than many of the people here are.  Which was
the original poster's point, methinks.

Two more cents out of pocket,

Arnold

Re: [9fans] troff and 4.4BSD man pages

[rog]

> I have even had groff diagnose mistakes in my input files that
> Unix troff just silently accepted!

unix/plan9 troff silently accepts most mistakes, in my experience...

Re: [9fans] troff and 4.4BSD man pages

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
>>I have even had groff diagnose mistakes in my input files that
>>Unix troff just silently accepted!
> unix/plan9 troff silently accepts most mistakes, in my experience...

In fact the troff input language definition requires
that such things as uninitialized variables not be
diagnosed.  It's a feature, not a bug.

Re: [9fans] troff and 4.4BSD man pages

[Bruce Ellis]

ummm, excuse me - but troff was the perhaps the
best supported program at the labs.  if groff works
with <random input> and troff doesn't well
guess which one is wrong.  when in doubt avoid
programs that start with 'g' ... except grep.
and why isn't there a ggrep.  that would get
100 morons typing straight away.

brucee

Lyndon Nerenberg wrote:
> 4.4BSD introduced the 'doc' macro package. It's a more structured 
> variant of the 'an' macro package. All the 4.4BSD man pages were changed 
> over to use -mdoc.
> 
> Writing a Plan9 native set of 'doc' macros is on my todo list, but it's 
> not going to happen any time soon. (Although if a working troff pops up 
> in the ports CVS tree, this will become a much higher priority for me.)
> 
> --lyndon

Re: [9fans] troff and 4.4BSD man pages

[boyd, rounin]

> when in doubt avoid programs that start with 'g' ... except grep.

i'm trying to think of a use for a GNU command that's called:

    gawd

Re: [9fans] troff and 4.4BSD man pages

[lucio]

> i'm trying to think of a use for a GNU command that's called:

None, of course.

++L

Re: [9fans] troff and 4.4BSD man pages

[Bruce Ellis]

rue st gmartin, or grue st martin?

boyd, rounin wrote:

>>when in doubt avoid programs that start with 'g' ... except grep.
> 
> i'm trying to think of a use for a GNU command that's called:
> 
>     gawd

Re: [9fans] troff and 4.4BSD man pages

[boyd, rounin]

> rue st gmartin, or grue st martin?

    grue

could be some meta GPS mapping glop.  damn, another one:

    glop

Re: [9fans] troff and 4.4BSD man pages

[Bruce Ellis]

lets get real and write "goo", oh that's gcc.
(object oriented, works on some playforms with
maximal pain.)

boyd, rounin wrote:

>>rue st gmartin, or grue st martin?
> 
>     grue
> 
> could be some meta GPS mapping glop.  damn, another one:
> 
>     glop

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