9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] Installing the updates
@ 2000-08-01 16:26 rob pike
  2000-08-02 21:49 ` Steve Simon
  0 siblings, 1 reply; 33+ messages in thread
From: rob pike @ 2000-08-01 16:26 UTC (permalink / raw)
  To: 9fans


> It would be nice if Pike could present a compelling argument.  His web
> page states only:

[The `web page' is just a very old class handout that propagated
far beyond its intended audience.]

My long note earlier today was supposed to explain better.

Here's a short version:
	Avoid complexity.
Flat structures are simpler than nested ones: simpler to write
and, more important, simpler to maintain.

If that doesn't compel you, I have nothing more to say.

As I said, in our world, our rules work well.  We cope with
outside software by following outside rules.  I do not expect
the world to switch to our way of handling #includes; I merely
ask that people writing code for Plan 9 try the Plan 9 way.

-rob



^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-08-02  9:47 forsyth
  2000-08-02  9:52 ` Boyd Roberts
  0 siblings, 1 reply; 33+ messages in thread
From: forsyth @ 2000-08-02  9:47 UTC (permalink / raw)
  To: 9fans

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

>>We already know that it is non-trivial to port much
>>non-Plan9 code to Plan9-native and vice versa.

i have found porting well written Unix
code to native plan 9 (libc.h, 8[cl] etc)
to be straightforward.  the main exceptions
are socket calls but since those involve deleting
lots of ugly lines of code, it's satisfying, and since
they mainly involve call setup with the I/O the
same read/write after that, it's not too hard.
the compilers sometimes pick up
old problems that were lurking though.


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

To: cse.psu.edu!9fans
Subject: Re: [9fans] Installing the updates
Date: Wed, 2 Aug 2000 09:11:37 GMT
Message-ID: <3987E345.4B8F3643@home.com>

> The APE headers do indeed conform.

Okay, problem solved.  The Plan9 native headers can
certainly do whatever Rob and crew think is best.
We already know that it is non-trivial to port much
non-Plan9 code to Plan9-native and vice versa.

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-08-01 17:06 Russ Cox
  2000-08-02  8:32 ` Bruce G. Stewart
  0 siblings, 1 reply; 33+ messages in thread
From: Russ Cox @ 2000-08-01 17:06 UTC (permalink / raw)
  To: 9fans

	Where's the horror here?  Computers are fast.  Pushing extra work on
	programmers and creating an unnecessary portability issue is a high
	cost.  Reading a header file five or more times during compilation is
	a low cost (and one which can be optimized away for ifdef-protected
	headers; I'm told gcc does so).

While it may be simpler when it works, when
it fails it does so in mysterious ways.  I don't know 
how many times I've tried to figure out why 
some header file I wanted wasn't getting included,
only to find that it had _already_ been included,
by someone else, with different things #defined,
so the definition or prototype_I_ wanted wasn't
there.

I'd much rather have the compiler barf on a 
#define or something like that, than hop over
the whole file as though it weren't there.

Russ



^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-08-01 16:27 rob pike
  2000-08-02 10:53 ` Ralph Corderoy
  0 siblings, 1 reply; 33+ messages in thread
From: rob pike @ 2000-08-01 16:27 UTC (permalink / raw)
  To: 9fans

> I think he's heard the argument but doesn't agree.
> 
>     "Simple rule: include files should never include include files."
>         -- http://www.lysator.liu.se/c/pikestyle.html
> 

Yup.  That little note, written for a CS class in 1987, has been
expanded into a book, published last year, called The Practice
of Programming.

-rob



^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-08-01 13:35 rob pike
  2000-08-01 18:34 ` Greg Hudson
  2000-08-02  9:53 ` Douglas A. Gwyn
  0 siblings, 2 replies; 33+ messages in thread
From: rob pike @ 2000-08-01 13:35 UTC (permalink / raw)
  To: 9fans

Perhaps I should explain better.

The only tenable argument in favor of allowing #include files to
include #include files is that a lot of software does that, so
permitting it makes software easy to port.  That is, I'm sure, why the
ANSI C committee accepted it: it's standard practice.

Nonetheless, it's a cop-out.  It's a terrible practice that leads to
n-squared inclusion of files, painful overwork by the C preprocessor,
and a bad name for the idea of #include files in the first place.

When designing the Plan 9 environment, we started with ANSI C for the
language.  Other than a couple of extensions to the language proper,
we took ANSI C at face value.  The library was also accepted pretty
much as is, with a few minor differences.  However, the C preprocessor
was unacceptable to us because a) it was very complex; b) it had lots
of new stuff designed by committee, a recipe for disaster; and c) most
of the new stuff encouraged conditional compilation and other horrors
we were trying to get away from.

Our idea was to build a portable system, one whose software could be
compiled without change - and that means without conditional
compilation, since you always have to change the #ifdefs when you
port; that is the very definition of config - as we changed
architectures.  Just architectures, not operating systems: we did not
expect Plan 9 programs to be compilable on Unix systems, but we did
expect a Plan 9 program that runs on a 386 to work on a SPARC, say,
without change, just by compiling it.

To meet that goal, we had to break with the ANSI include rules.

To import external code, we (well, Howard) built a fairly strict ANSI
C/POSIX environment that follows all the rules, including getting the
libraries and C preprocessors to have standard behavior.  If you want
to import code, that's the minimum effort path.

But if you want to build Plan 9 code, part of the environment is that
#include files don't #include each other.  That is just the way it
works, like not running X or using mk instead of make or setting
objtype=mips to build for the Mips.

In short, the argument that existing software #includes like that so
Plan 9 should is bogus, *because Plan 9 software does not*.

Plan 9 is a different environment, but it's different for a reason.
In the case of #include files, it's to make software easier to port
and simpler to maintain.  Within its own, admittedly smaller, world,
it succeeds.  Show me another system that builds all its software on
multiple architectures without #ifdefs or config.  Show me another
system where I can compile on a SPARC, link on a 386, and run on a
Mips.  Show me another system where I can update an application for
every architecture by typing the equivalent of
	mk installall
I'd love to hear of it!  But in this #ifdef, config-riddled world I
don't think it exists.

-rob



^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-08-01 13:06 rob pike
  2000-08-01 13:10 ` Lucio De Re
  0 siblings, 1 reply; 33+ messages in thread
From: rob pike @ 2000-08-01 13:06 UTC (permalink / raw)
  To: 9fans

	A user could have the distribution source on a CDROM and view it via a
	cache file
	server. This would store only the files that have changed - using copy
	on write.
	I suspose this could be extended to storing only the blocks that have
	changed, or
	even file diff(1) output, or wrap(8) file even...
	
	I'am not sure if this is interesting or hedious :-)

This is the essence of what BSD calls union directories.

-rob



^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-08-01 12:55 rob pike
  2000-08-02  9:39 ` Douglas A. Gwyn
  0 siblings, 1 reply; 33+ messages in thread
From: rob pike @ 2000-08-01 12:55 UTC (permalink / raw)
  To: 9fans

> Since the C standard definitely requires idempotency for the
> standard headers (except <assert.h>), at least the APE headers
> ought to conform, to ease the burden of importing non-native code.

Yes, and our APE headers do conform.  But ANSI C made a blunder
on this one, I think. They should at least have deprecated the practice.

But for the native environment, we corrected the error and did it right.

Plan 9 is non-standard and proud of it.

-rob



^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-08-01  6:04 Russ Cox
  0 siblings, 0 replies; 33+ messages in thread
From: Russ Cox @ 2000-08-01  6:04 UTC (permalink / raw)
  To: 9fans

[didn't mean to send that first one -- misclicked]

	A user could have the distribution source on a CDROM and view it via a
	cache file
	server. This would store only the files that have changed - using copy
	on write.
	I suspose this could be extended to storing only the blocks that have
	changed, or
	even file diff(1) output, or wrap(8) file even...
	
	I'am not sure if this is interesting or hedious :-)

I think it's interesting, at least until you
start talking about saving individual blocks
or diff output, at which point it gets complicated
enough to perhaps qualify as hideous.
Especially since with the exception of log files
and the fortune database, files tend to be rewritten
completely when they change.

I've thought about writing such a thing a number
of times, but been scared away both by not having
a name for it and by the complexity of the state
machine you'd need to use only a constant number of
processes.

I've since come up with a name -- stitch -- and
I think that you can use libthread to great advantage
to manage the complexity, but I haven't tried it.

If you had such a thing, you could try out
new wrap updates by doing

	gunzip < /tmp/new.9gz >/tmp/new.9
	archfs /tmp/new.9
	stitch -b /tmp/new.9 /

which would be neat.

Russ



^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-08-01  5:42 Russ Cox
  0 siblings, 0 replies; 33+ messages in thread
From: Russ Cox @ 2000-08-01  5:42 UTC (permalink / raw)
  To: 9fans

	A user could have the distribution source on a CDROM and view it via a
	cache file
	server. This would store only the files that have changed - using copy
	on write.
	I suspose this could be extended to storing only the blocks that have
	changed, or
	even file diff(1) output, or wrap(8) file even...
	
	I'am not sure if this is interesting or hedious :-)

I think it's interesting, at least until you
start talking about saving individual blocks
or diff output, at which point it gets complicated
enough to perhaps qualify as hideous.
Especially given that binaries don't change much.




^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-07-31 17:09 Russ Cox
  0 siblings, 0 replies; 33+ messages in thread
From: Russ Cox @ 2000-07-31 17:09 UTC (permalink / raw)
  To: 9fans, djhender

	How do I list the contents of a wrap archive?

gunzip < arch.9gz | disk/mkext -h

	How do I list the conflicts between a wrap archive and the current versions
	(without actually installing anything)?

wrap/inst -x arch.9gz
will print what it would do, without actually doing anything.

wrap/wdiff -l arch.9gz
may be worth trying as well.

Russ



^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-07-31 15:57 jmk
  0 siblings, 0 replies; 33+ messages in thread
From: jmk @ 2000-07-31 15:57 UTC (permalink / raw)
  To: 9fans

Doug Henderson <djhender@telusplanet.net>:
	And I messed around with the ethernet driver code for my card (RealTeck
	8029AS) trying to find out why it didn't work. Etc, etc.

I have an ether8029.c, it's really just a front end to the 8390 code
that autoconfigures. Yours if you want it.

--jim


^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: [9fans] Installing the updates
@ 2000-07-31 15:15 rob pike
  2000-08-01  8:53 ` Douglas A. Gwyn
  0 siblings, 1 reply; 33+ messages in thread
From: rob pike @ 2000-07-31 15:15 UTC (permalink / raw)
  To: 9fans


> In one of my porting project, <stdio.h> is included twice.

Pardon me for doing a boyd here, but you only need to include
it once - you get everything defined the first time.

Seriously, we deliberately refused to buy into that multiple
inclusion dance, which is a hideous non-solution for the problem
of undefined dependency order on #includes.  Why not use the
occasion to clean up the code so you only include <stdio.h> once?

I'll let Russ answer your wrap questions; he's the author.

-rob



^ permalink raw reply	[flat|nested] 33+ messages in thread
[parent not found: <djhender@telusplanet.net>]

end of thread, other threads:[~2000-08-03 14:51 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-08-01 16:26 [9fans] Installing the updates rob pike
2000-08-02 21:49 ` Steve Simon
  -- strict thread matches above, loose matches on Subject: below --
2000-08-02  9:47 forsyth
2000-08-02  9:52 ` Boyd Roberts
2000-08-01 17:06 Russ Cox
2000-08-02  8:32 ` Bruce G. Stewart
2000-08-01 16:27 rob pike
2000-08-02 10:53 ` Ralph Corderoy
2000-08-01 13:35 rob pike
2000-08-01 18:34 ` Greg Hudson
2000-08-02  9:53 ` Douglas A. Gwyn
2000-08-01 13:06 rob pike
2000-08-01 13:10 ` Lucio De Re
2000-08-01 12:55 rob pike
2000-08-02  9:39 ` Douglas A. Gwyn
2000-08-01  6:04 Russ Cox
2000-08-01  5:42 Russ Cox
2000-07-31 17:09 Russ Cox
2000-07-31 15:57 jmk
2000-07-31 15:15 rob pike
2000-08-01  8:53 ` Douglas A. Gwyn
2000-08-01 12:12   ` Howard Trickey
2000-08-02  9:11     ` Douglas A. Gwyn
2000-08-01 14:31   ` Ralph Corderoy
2000-08-01 16:03     ` Greg Hudson
2000-08-01 16:32       ` James A. Robinson
2000-08-01 17:05         ` James A. Robinson
2000-08-02  9:39       ` Douglas A. Gwyn
2000-08-02  9:11     ` Douglas A. Gwyn
2000-08-03 14:51     ` ozan s. yigit
     [not found] <djhender@telusplanet.net>
2000-07-31 14:53 ` Doug Henderson
2000-07-31 17:38   ` Scott Schwartz
2000-07-31 20:10     ` Steve Simon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).