Seeking a Development Environment (Sun?)

[Robert Reed]

In article <8422 at sun.uucp> guy at sun.uucp (Guy Harris) writes:
>> (UNIX) does not have ... a C compiler which generates error messages
>> incompatible with standard error postprocessing techniques.  These may all
>> be bugs...
>
>What does "standard error postprocessing techniques" mean?

I expressed it that way because I didn't want to get into another vi/emacs
argument.  Vi users use "error" and emacs users (at least gosling/unipress)
use next-error.  In either case, it is an ad hoc standard (it has been
propogated to many machines) and it's one more hurtle to hassle (via a
filter or whatever) when migrating to the machine.

>Frankly, I wish more compilers would produce better error messages than
>PCC's.

This is principally an issue of content, not syntax (though you may argue
that syntax can produce better error messages).  I would like to see a
standard error syntax for all UNIX tools, but that's beside the point.

>> but they are certainly incompatibilities between the expected UNIX
>> environment (BSD in my case) and the reality of the system.
>
>This gives *carte blanche* to users to reject any system as "not UNIX" if
>any data structure, whether intended to be exported to user code or not,
>isn't identical with the system that implements your "expected UNIX
>environment";

Absolute rejection of an environment is one thing--evaluation of the level
of "compliance" (given that there is no objective indicator of that yet) is
another.  My point was NOT that DOMAIN/IX is not UNIX, just that though they
have made great strides towards transparency, that it is still an emulation,
subject to the differences in dark corners that any emulation risks.

>> To some extent the issue is whether /dev/kmem exists, when it restricts the
>> portability of standard UNIX tools.
>
>I presume you mean the lack of "/dev/kmem" restricts the portability of
>standard UNIX tools.  ...
>It might be nice if there were some standard way of getting at information
>about the processes running on the system.

And this is exactly the point.  I may not have a /dev/kmem whose data
structures are *exactly* the same or even nearly the same, but I can deal
with that, given sufficient documentation to make the changes necessary to
port the tools to this new environment.  UNIX environments are essentially
as closed as Apollo in this regard--/dev/kmem is no better documented than
the means by which Apollo's ps command derives its information.  If
Apollo/DOMAIN-IX came with a caveat that /dev/kmem does not exist, but the
information contained within is available through some specified mechanism,
I would be content.  But I have seen no such documentation.  We do have
sources for UNIX, though, so I can get the information I need for that
environment.  
-- 
Robert Reed, Tektronix CAE Systems Division, bobr at zeus.TEK