Re: [9fans] ugrading edition 2 graphics to edition 3

Re: [9fans] ugrading edition 2 graphics to edition 3

[kim kubik]

-----Original Message-----
From: geoff@x.bell-labs.com <geoff@x.bell-labs.com>
To: 9fans@cse.psu.edu <9fans@cse.psu.edu>
Date: Thursday, August 03, 2000 1:25 PM
Subject: Re: [9fans] ugrading edition 2 graphics to edition 3


>There's reinvention and there's reimplementation, as advocated by
>forsyth in `more taste, less greed: sending Unix to the fat farm'
>(ftp://ftp.cs.york.ac.uk/papers/taste.ps.Z).  If the original wheel
>was square or triangular, it's well worth reimplementing it, and you
>usually learn something along the way.
>

I always assumed that title ("More Taste, Less Greed") was a takeoff
on a 1989 paper/talk by a D. Rosenthal (then at Sun I think) "More
Haste, Less Speed" where he says something like:

 "Six years ago the author was sharing a 1MIPS, 4Meg machine 
  with 60 users. At times it was irritatingly slow. Now he 
  has a 1.5MIPS, 4Meg machine all to himself. At times it is 
  irritatingly slow."

And then he asks "What Happened to All That Extra Power?"

Isn't this one of the basic ideas for p9, to have the terminal
server provide an essentially consistent response to user
interaction and the other processor hogs be 'down the wire'
and out of the way in terms of gobbling cpu cycles, which a
workstation has to juggle, especially when it has to go to
disk to process page faults. 

Re: [9fans] ugrading edition 2 graphics to edition 3

[Boyd Roberts]

From: kim kubik <chaotrope@jps.net>
> 
>  "Six years ago the author was sharing a 1MIPS, 4Meg machine 
>   with 60 users. At times it was irritatingly slow. Now he 
>   has a 1.5MIPS, 4Meg machine all to himself. At times it is 
>   irritatingly slow."
> 
 
15 years ago this author/poster/stirrer/boofhead had a VAX 11/780
[1 mip] with 128 students on it.

yer tell to you kids today...  they never believe you.

those kmc-11's musta took a thrashing.

Re: [9fans] ugrading edition 2 graphics to edition 3

[Andy Newman]

Boyd Roberts wrote:
>15 years ago this author/poster/stirrer/boofhead had a VAX 11/780
>[1 mip] with 128 students on it.

And it was unbearably slow but certainly kept chugging away. I used
to try to use ded on it. Hah!

Re: [9fans] ugrading edition 2 graphics to edition 3

[Boyd Roberts]

> And it was unbearably slow but certainly kept chugging away. I used
> to try to use ded on it. Hah!
> 

the problem was you were using ded.  that thing made vi look good.

the basser vaxen where 30-40% faster than munnari [4BSD].

Re: [9fans] ugrading edition 2 graphics to edition 3

[Boyd Roberts]

From: Andy Newman <atrn@zeta.org.au>

> I'm an editor slut. I'll use anything - ed, vi, sam (i wish 
> samuel had been allowed out), emacs, acme, wily...

i(ve seen samuel [tom kargill?].  it's intresting, but it's too much code.

small, simple, powerful -- that's the deal.

do more, with less.

Re: [9fans] ugrading edition 2 graphics to edition 3

[Alex Danilo]

Boyd Roberts wrote:

> i(ve seen samuel [tom kargill?].  it's intresting, but it's too much code.

Rubbish.  It's bugger all extra code inside sam.  Everything is driven by the
pipes
to cscope, so no overhead unless you activate the extra features.  Similarly
cin
is activated that way.  It was an exercise in building a user environment that
is
modular and works nicer than things like IDEs today.

IMO its the best way to navigate a whole lot of code you've never seen before.

Shame that it was built on an ASCII sam though.

Re: [9fans] ugrading edition 2 graphics to edition 3

[Andy Newman]

Alex Danilo wrote:
>Shame that it was built on an ASCII sam though.

Well cscope is freely available now and sam's there. Got enough
to do at present?

Re: [9fans] ugrading edition 2 graphics to edition 3

[Boyd Roberts]

From: Alex Danilo <alex@nospam.ishtek.com>

> Boyd Roberts wrote:
>
> > i(ve seen samuel [tom kargill?].  it's intresting, but it's too much code.
>
> Rubbish.  It's bugger all extra code inside sam.  Everything is driven by the
> pipes
> to cscope, so no overhead unless you activate the extra features.  Similarly
> cin
> is activated that way.  It was an exercise in building a user environment that
> is
> modular and works nicer than things like IDEs today.
>

ok granted, alex, but it's still a reasonable swag of code in total.
which is what i meant in the first place.

concurr on 100% on your last sentence.

Re: [9fans] ugrading edition 2 graphics to edition 3

[Tom Duff]

> From: Doug Henderson <djhender@telusplanet.net>
> It's about reinventing the wheel.
> "If I have seen furthur it is by standing on the shoulders of giants" -
There's a difference between standing on the shoulders of
giants and standing in the disgorgement of giants.

-- 
Tom Duff.  When your work speaks for itself, don't interrupt.

Re: [9fans] ugrading edition 2 graphics to edition 3

[Douglas A. Gwyn]

nigel@9fs.org wrote:
> Alternatively, you could replace the body with modern materials
> which reduces it's weight.

Sure, if you're in the business of building cars.
But if you just use one incidentally to doing other things,
you don't want to have to build the darn thing; you'd rather
just get a sufficiently usable one from someone who has
already built it, even if it isn't like you'd have built it.

The trick in employing "stovepipe adapters" is to use them
to get something that already exists working well enough to
get on to *new* projects, instead of continually tweaking
what has already been done.  The approach of redesigning
makes sense only when you anticipate that the product will
need substantial maintenance to meet changing requirements.

The vast majority of computer applications have not yet
been invented.

Re: [9fans] ugrading edition 2 graphics to edition 3

[Douglas A. Gwyn]

Matt wrote:
> Take out one file and one bit of script down the list suddenly falls apart
> because it was relying on an include higher up etc.

I'm not sure what you mean, but my guess is that you're saying
that an #include was removed from a source file after all references
to symbols documented as being defined by that header were no
longer referenced in that source file.

> I'm sure this must be true of a big C project too.

Not necessarily.  The last really big C project I was involved in
(MUVES) had everything arranged as "packages", each with its API
defined by a single header, e.g. "Mm.h" for everything in the
Memory-management package.  (All symbols in Mm.h begin with "Mm"
in order to avoid collision with any other package.)  It happened
that the Mm package needed to use some facilities from the Dq
(Doubly-linked queue) package and vice versa.  I forget whether
the "Dq.h" header needed to #include "Mm.h" and/or vice versa,
but if they had, there would be no problem (due to idempotency
locks in each header).  The key to the problem I think you were
mentioning is that *any* user of anything named Dq... was required
to #include "Dq.h" and similarly for any user of Mm...  Removing
the API for a package that became unused through edits to a source
file would have no effect on the remaining package headers.

Just as with the Plan 9 header discipline, if you don't follow
the discipline consistently, it can cause problems.  The rules
we used for the MUVES source were very easy to remember and follow,
and they never caused us any problems.  (Well, there was one
related problem, but it wasn't the fault of the header rules as
such.  MUVES used "unit testing" in its build procedure, to
validate each package's object modules before putting them into
the project library.  The unit testing linked the package test
program with the under-test package modules and the library.  When
first installing on a new platform, Dq and Mm each needed the
other package to have been already put into the library before
the test could be linked.  We devised a simple kludge to work
around this mutual dependency problem.)

Note: I haven't been arguing that the Plan 9 header discipline
is wrong, but rather that not all experiences with headers
including other headers have been negative.  Like many things
in life, nested inclusion itself is not a problem, but rather
how it is *used*.

Re: [9fans] ugrading edition 2 graphics to edition 3

[Anthony Sorace]

//But if I need a tire for my car, telling me that I have
//to build my own rubber factory etc. just because you
//don't like the tread patterns on existing commercial
//products is absurd.

but it makes more sense to build custom tires if none of
the commercial versions fit on my custom car.
: anothy;

Re: [9fans] ugrading edition 2 graphics to edition 3

[geoff]

> But if I need a tire for my car, telling me that I have
> to build my own rubber factory etc. just because you
> don't like the tread patterns on existing commercial
> products is absurd.

It would be, but perhaps the better analogy is that the only available
commercial tires are flat, or at least extremely leaky.

Re: [9fans] ugrading edition 2 graphics to edition 3

[Matt]

> geoff@x.bell-labs.com wrote:
> > If the original wheel was square or triangular,
> > it's well worth reimplementing it, and you
> > usually learn something along the way.
>
> But if I need a tire for my car, telling me that I have
> to build my own rubber factory etc. just because you
> don't like the tread patterns on existing commercial
> products is absurd.

reducto ad absurdium

IIRC

the romans they are leaving their house?

Formula 1 teams don't get their tyres (note spelling) from Kwik-Fit
They hire the manufacturer to make them specialised tyres.

If you are happy with remoulds then put your includes in every file.

If you want to follow the plan9 program put them in main.h

For my money putting them all in one place feels better because I can see
them all at once.

I can see the argument for putting them in modules that require the
particular includes.

As anecdotal evidence I've taken over the maintenance of a big web site
It's in php and this has various includes dribbled throughout the pages.
The code is bad enough anyway but the web of interdependence is horrible.
Take out one file and one bit of script down the list suddenly falls apart
because it was relying on an include higher up etc.

I'm sure this must be true of a big C project too.


If the includes were at the top of the tree you can see what's needed for
stuff to work and also you can prune them a bit easier.

Matt

Re: [9fans] ugrading edition 2 graphics to edition 3

[nigel]

> But if I need a tire for my car, telling me that I have
> to build my own rubber factory etc. just because you
> don't like the tread patterns on existing commercial
> products is absurd.

I don't think anyone would disagree with that, unless it turns
out that the tread pattern is life threatening.

Since we're on car analogies, there are two ways to make
an old, heavy model go faster. You can put in a larger engine,
possibly reshape the front to achieve this, enlarge the fuel
tank to compensate for the loss of range, and replace the shocks.
This usually results in worse handling, and increased running
costs.

Alternatively, you could replace the body with modern materials
which reduces it's weight.

Re: [9fans] ugrading edition 2 graphics to edition 3

[Douglas A. Gwyn]

geoff@x.bell-labs.com wrote:
> If the original wheel was square or triangular,
> it's well worth reimplementing it, and you
> usually learn something along the way.

But if I need a tire for my car, telling me that I have
to build my own rubber factory etc. just because you
don't like the tread patterns on existing commercial
products is absurd.

Re: [9fans] ugrading edition 2 graphics to edition 3

[forsyth]

>>I always assumed that title ("More Taste, Less Greed") was a takeoff
>>on a 1989 paper/talk by a D. Rosenthal (then at Sun I think) "More
>>Haste, Less Speed" where he says something like:

Yes, you're quite right.  I thought there were simpler, more obvious
explanations for the workstation disaster than those mentioned in
Rosenthal's paper.  He included a nod to `Chaos Theory' (as regards
paging).  I suggested instead the application of `Control Theory' (cf.
Maurice Wilkes' elegant paper on paging, inspired by an analysis of
EMAS), `careful design', and `reimplementation' as possible ways to
address the problem, supported by some worked examples.
Of course, the `more taste' aspect was intended
to emphasise that careful design involves careful choice and
composition of primitives and functionality.

The distribution is possibly less important to Plan 9 (for achieving
simplicity and a generally responsive environment) than the use of
name spaces containing file servers which provides structural support
for distribution but much more besides, and keeping the implementation
lean, and reasonable (able to be reasoned about).
It's perhaps a small part, but I'd include avoiding the #ifdef/#include pit in that.

Some people just never learn: special-purpose protocols, perverse
naming schemes, botched file servers, and every program a whole
operating system ... they just keep coming.

Re: [9fans] ugrading edition 2 graphics to edition 3

[forsyth]

>>There's reinvention and there's reimplementation, as advocated by
>>forsyth in `more taste, less greed: sending Unix to the fat farm'

as noted in that paper, i borrowed the distinction
from the EMAS group, particularly their paper
``An Experiment in Doing it Again, But Very Well This Time''
(CSR-18-77 University of Edinburgh):

	By re-implementation, we mean re-programming and altering the
	structure of an existing system where necessary, so as to better implement
	the function of that system.  We distinguish re-implementation from two
	other activities.  These are the transportation of an existing system to
	new hardware, and the design of a new system.  If we transport a system,
	we leave its function and its structure unaltered.  Re-implementation is
	not merely a combination of transportation and re-design, but is a
	unique activity in its own right.  It is doing it again, but very well this time.

Re: [9fans] ugrading edition 2 graphics to edition 3

[geoff]

There's reinvention and there's reimplementation, as advocated by
forsyth in `more taste, less greed: sending Unix to the fat farm'
(ftp://ftp.cs.york.ac.uk/papers/taste.ps.Z).  If the original wheel
was square or triangular, it's well worth reimplementing it, and you
usually learn something along the way.

Re: [9fans] ugrading edition 2 graphics to edition 3

[dhog]

Doug Henderson <djhender@telusplanet.net> writes:
> It's about reinventing the wheel.
> "If I have seen furthur it is by standing on the shoulders of giants" -
> Isaac Newton.
> http://www.newton.org.uk/essays/Giants.html
> 

If I have seen farther than others, it is because I was standing on
the shoulders of giants.  -- Isaac Newton

In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.  -- Gerald Holton

If I have not seen as far as others, it is because giants were
standing on my shoulders.  -- Hal Abelson

In computer science, we stand on each other's feet.  -- Brian K. Reid

Re: [9fans] ugrading edition 2 graphics to edition 3

[Boyd Roberts]

From: Doug Henderson <djhender@telusplanet.net>

> It's about reinventing the wheel.
> "If I have seen furthur it is by standing on the shoulders of giants" -
> Isaac Newton.
> http://www.newton.org.uk/essays/Giants.html
> 

don't i know it (and the quote).

Re: [9fans] ugrading edition 2 graphics to edition 3

[Doug Henderson]

It's about reinventing the wheel.
"If I have seen furthur it is by standing on the shoulders of giants" -
Isaac Newton.
http://www.newton.org.uk/essays/Giants.html

----- Original Message -----
From: "Boyd Roberts" <boyd@noos.fr>
Subject: Re: [9fans] ugrading edition 2 graphics to edition 3


> i understand the objective of ape, but plan 9 is not unix.
> and now what i see is that certain people want to use ape
> to smash plan 9 back into unix.  err...

Re: [9fans] ugrading edition 2 graphics to edition 3

[Boyd Roberts]

i understand the objective of ape, but plan 9 is not unix.
and now what i see is that certain people want to use ape
to smash plan 9 back into unix.  err...

Re: [9fans] ugrading edition 2 graphics to edition 3

[Russ Cox]

The easiest thing at the moment is not to use
the APE -- #include <u.h>, then <libc.h>,
and even <stdio.h> if you want it, and you'll
have a pretty sensible setup.

As far as the panel library goes, there is no
direct replacement.  

As far as converting libg.h to draw.h, the big
difference is that bitblt is replaced by draw, and
while there is some intersection (block copies,
block fills), if you have a program that is heavy
into things like XORing pixels, it will need to be
rethought for the new driver.  There are also
little differences -- add became addpt, etc.

For little graphical programs, there are a 
couple at www.eecs.harvard.edu/~rsc/plan9.html;
look for click.c, bargraph.c, mixer.c, cdplay.tar.gz,
in increasing order of complexity.

As far as file systems, there is a rot13fs.c 
on the same page, which is a 9P filter rather
than a 9P server.  /sys/src/cmd/archfs.c
is a very minimal server but uses a 9P
library to do the dirty work.  /sys/src/cmd/rdbfs.c is a fairly 
simple completely self-contained 9P server.

Russ

Re: [9fans] ugrading edition 2 graphics to edition 3

[Anthony Sorace]

//Is there much 2nd edition stuff you feel needs to be updated?

yeah. /bin/games.
: anothy;

Re: [9fans] ugrading edition 2 graphics to edition 3

[rob pike]

> The <libg.h> looks like it used to be supported in the APE environment (the
> header is still there in 3rd, but it doesn't work - also no libg.a).

APE has been a bit neglected the last year or two.  There should
certainly be an APE version of <draw.h>.  I removed <ape/libg.h>
here; it was a dreg.  Thanks for catching it.

> One of the most valuable aids (for me) to learning a new environment is
> building and experimenting with existing code. So I am lacking some of the
> tools that I can use to figure out how to do these tranforms. Is the 2nd
> edition documentation still available anywhere, for download or browsing? Is
> there a porting guide? A feature comparision?

None of the above, really.  I suppose we could put the old documentation
on line - in fact it's still there, just hidden - but is that actually useful?
Is there much 2nd edition stuff you feel needs to be updated?

-rob

[9fans] ugrading edition 2 graphics to edition 3

[Doug Henderson]

While I looked at Plan9 a number of years back - I downloaded the 3 disk
install set I think, I didn't get seriously involved until 3rd edition, what
with ADSL & cable making 50Meg downloads a practicality for the individual.

A lot of the existing native plan9 source code out there is written for the
2nd edition graphics libraries, with headers like <libg.h>, <panel.h>, and
<layer.h>. I don't have access to the 2nd edition graphics library
documention. I have not seen both versions of any programs which have been
transformed from 2nd to 3rd editions.

One of the most valuable aids (for me) to learning a new environment is
building and experimenting with existing code. So I am lacking some of the
tools that I can use to figure out how to do these tranforms. Is the 2nd
edition documentation still available anywhere, for download or browsing? Is
there a porting guide? A feature comparision?

The <libg.h> looks like it used to be supported in the APE environment (the
header is still there in 3rd, but it doesn't work - also no libg.a). Is the
3rd edition <draw.h> and etc. going to be supported under the 3rd edition?
Anyone working on that? Are there guidelines / suggestions for doing such a
thing? My efforts so far get to the linker where I get a conflict between
the ape atexit and the libc atexit (I think).

Are there any feature test programs available? I mean simple programs
(perhaps used by the developers of the 3rd edition graphics libraries) to
excercise the features of the code. I find these kinds of programs a
valuable starting point for testing out my own pieces of code - the ones
where I find out how to do the basic things I need for a larger project.