[9fans] struct problems

[9fans] struct problems

[Christopher Nielsen]

I've been working on 48-bit LBA support for ATA, and
I've run into something peculiar. I decided to rewrite
the identify array as a struct of bit fields for better
readability. As it turns out, the struct is 16 bytes
bigger than expected, which is causing all sorts of
trouble with accessing the fields properly. I am pretty
sure I copied all the fields correctly; the struct
should be 512 bytes, but it's 528 bytes. Below is the
struct definition for folks to look at. I am in the
process of rooting out where the extra bytes are
coming from, but if someone can provide some insight,
it would save me some time.


typedef struct Params {
/*000*/	union {
		ushort	config;
		ushort	pktsz:2;	/* packet command size */
		ushort	incomplete:1;
		ushort	:2;
		ushort	drq:2;	/* DRQ type */
		ushort	removable:1;	/* device is removable */
    		ushort	type:5;	/* device type */
    		ushort	:2;
    		ushort	proto:1;	/* command protocol */
	};
/*001*/	ushort	lcyl;	/* logical cylinders */
	ushort	reserved2;
/*003*/	ushort	lhead;	/* logical heads */
	ushort	obsolete4;
	ushort	obsolete5;
/*006*/	ushort	lsec;	/* logical sectors */
	ushort	reserved7;
	ushort	reserved8;
	ushort	retired9;
/*010*/	uchar	serial[20];	/* serial number */
	ushort	retired20;
	ushort	retired21;
	ushort	obsolete22;
/*023*/	uchar	firmware[8];	/* firmware revision */
/*027*/	uchar	model[40];	/* model name */
/*047*/	ushort	maxrwm:8;	/* max. read/write multiple sectors */
	ushort	:8;
	ushort	reserved48;
/*049*/	union {
		ushort	capabilities;
		ushort	retired49:8;
		ushort	dma:1;	/* DMA supported */
		ushort	lba:1;	/* LBA supported */
		ushort	noiordy:1;	/* IORDY may be disabled */
		ushort	iordy:1;	/* IORDY supported */
		ushort	softrst:1;	/* needs soft reset when bsy */
		ushort	stdby:1;	/* standby supported */
		ushort	queueing:1;	/* queueing overlap supported */
		ushort	idma:1;	/* interleaved DMA supported */
	};
/*050*/	ushort	stdbymin:1;
	ushort	:13;
	ushort	cap1:1;
	ushort	cap0:1;
	ushort	retired51;
	ushort	retired52;
/*053*/	ushort	valid;
/*054*/	ushort	ccyl;
/*055*/	ushort	chead;
/*056*/	ushort	csec;
/*057*/	ushort	cap;
	ushort	obsolete58;
/*059*/	ushort	mstc:8;	/* number of sectors ready for transfer */
	ushort	mstvalid:1;	/* multi-sector transfer enabled */
	ushort	:7;
/*060-061*/	ushort	lba0;	/* LBA size */
	ushort	lba1;	/* LBA size */
	ushort	obsolete62;
/*063*/	ushort	mwdma;	/* multiword DMA mode */
/*064*/	ushort	apio;	/* advanced PIO mode */
/*065*/	ushort	minmwdma;	/* min. multiword DMA cycle time */
/*066*/	ushort	recmwdma;	/* rec. multiword DMA cycle time */
/*067*/	ushort	minpio;	/* min. PIO cycle w/o flow control */
/*068*/	ushort	miniordy;	/* min. PIO cycle with IORDY */
	ushort	reserved69;
	ushort	reserved70;
/*071*/	ushort	pktbr;	/* time from PACKET to bus release */
/*072*/	ushort	svcbsy;	/* time for SERVICE to !bsy */
	ushort	reserved73;
	ushort	reserved74;
/*075*/	ushort	qdepth:5;	/* max. queue depth */
	ushort	:11;
	ushort	reserved76;
	ushort	reserved77;
	ushort	reserved78;
	ushort	reserved79;
/*080*/	ushort	major;	/* major version number */
/*081*/	ushort	minor;	/* minor version number */
/*082-084/085-087*/	struct {
		ushort	smart:1;
		ushort	security:1;
		ushort	removable:1;
		ushort	pwrmgmt:1;
		ushort	pkt:1;
		ushort	wcache:1;
		ushort	lookahead:1;
		ushort	relirq:1;
		ushort	svcirq:1;
		ushort	reset:1;
		ushort	protected:1;
		ushort	:1;
		ushort	wbuf:1;
		ushort	rbuf:1;
		ushort	nop:1;
		ushort	:1;

		ushort	microcode:1;
		ushort	queued:1;
		ushort	cfa:1;
		ushort	apm:1;
		ushort	notify:1;
		ushort	standby:1;
		ushort	spinup:1;
		ushort	:1;
		ushort	maxsec:1;
		ushort	autoacoustic:1;
		ushort	addr48:1;
		ushort	devconfov:1;
		ushort	flush:1;
		ushort	flush48:1;
		ushort	support1:1;
		ushort	support0:1;

		ushort	smarterror:1;
		ushort	smartselftest:1;
		ushort	mserial:1;
		ushort	mpassthrough:1;
		ushort	:1;
		ushort	logging:1;
		ushort	:8;
		ushort	supportext1:1;
		ushort	supportext0:1;
	} supported, enabled;
/*088*/	ushort	udma;	/* ultra DMA mode */
/*089*/	ushort	erase;	/* time for security erase */
/*090*/	ushort	eerase;	/* time for enhanced security erase */
/*091*/	ushort	power;	/* current advanced power management */
/*092*/	ushort	mpwrev;	/* master password revision */
/*093*/	ushort	hwres;	/* hardware config test results */
/*094*/	ushort	acoustic;	/* current automatic acoustic management */
	ushort	reserved95;
	ushort	reserved96;
	ushort	reserved97;
	ushort	reserved98;
	ushort	reserved99;
/* 100-103 */	ushort	lbaext0;	/* 48-bit LBA size */
	ushort	lbaext1;	/* 48-bit LBA size */
	ushort	lbaext2;	/* 48-bit LBA size */
	ushort	lbaext3;	/* 48-bit LBA size */
	ushort	reserved104[23];
/*127*/	ushort	remstat;	/* removable media status */
/*128*/	ushort	secstat;	/* security status */
	ushort	reserved129[31];
/*160*/	ushort	cfapwr;	/* CFA power mode */
	ushort	reserved161[14];
/*176*/	ushort	mediaserial[30];	/* current media serial number */
	ushort	reserved206[49];
/*255*/	ushort	chksum;
} Params;


--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] struct problems

[Christopher Nielsen]

I forgot to add that my guess as to what is happening
is due to alignment issues.

On Tue, May 06, 2003 at 09:36:33PM -0700, Christopher Nielsen wrote:
> I've been working on 48-bit LBA support for ATA, and
> I've run into something peculiar. I decided to rewrite
> the identify array as a struct of bit fields for better
> readability. As it turns out, the struct is 16 bytes
> bigger than expected, which is causing all sorts of
> trouble with accessing the fields properly. I am pretty
> sure I copied all the fields correctly; the struct
> should be 512 bytes, but it's 528 bytes. Below is the
> struct definition for folks to look at. I am in the
> process of rooting out where the extra bytes are
> coming from, but if someone can provide some insight,
> it would save me some time.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

RE: [9fans] struct problems

[Nigel Roles]

structs and unions are aligned on 4 byte boundaries.
bit fields are never portable. are you sure they will
work on any Plan 9 platform (not just x86)?

> -----Original Message-----
> From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu]On Behalf
> Of Christopher Nielsen
> Sent: 07 May 2003 06:34
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] struct problems
>
>
> I forgot to add that my guess as to what is happening
> is due to alignment issues.
>
> On Tue, May 06, 2003 at 09:36:33PM -0700, Christopher Nielsen wrote:
> > I've been working on 48-bit LBA support for ATA, and
> > I've run into something peculiar. I decided to rewrite
> > the identify array as a struct of bit fields for better
> > readability. As it turns out, the struct is 16 bytes
> > bigger than expected, which is causing all sorts of
> > trouble with accessing the fields properly. I am pretty
> > sure I copied all the fields correctly; the struct
> > should be 512 bytes, but it's 528 bytes. Below is the
> > struct definition for folks to look at. I am in the
> > process of rooting out where the extra bytes are
> > coming from, but if someone can provide some insight,
> > it would save me some time.
>
> --
> Christopher Nielsen
> "They who can give up essential liberty for temporary
> safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] struct problems

[Christopher Nielsen]

Doh! I should know that bit fields aren't portable.
No, I'm not sure; in fact, I'm pretty sure they won't
work across platforms. I didn't think about that. I'll
come up with a different method that _is_ portable.
Thanks.

On Wed, May 07, 2003 at 06:36:51AM +0100, Nigel Roles wrote:
> structs and unions are aligned on 4 byte boundaries.
> bit fields are never portable. are you sure they will
> work on any Plan 9 platform (not just x86)?

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] struct problems

[boyd, rounin]

Christopher Nielsen" <cnielsen@pobox.com>
> Doh! I should know that bit fields aren't portable.

it's worse than that, a 32 bit int access on a 16 bit device register _may_
get 'optimised' into an 'extract field' instruction which then causes a kernel
mode fault.  iirc the 8th Ed TU16 driver ... 750/780 porting issue.
--
The Beretta 92FS -- don't leave home without it ...

Re: [9fans] struct problems

[ron minnich]

On Thu, 8 May 2003, boyd, rounin wrote:

> it's worse than that, a 32 bit int access on a 16 bit device register _may_
> get 'optimised' into an 'extract field' instruction which then causes a kernel
> mode fault.  iirc the 8th Ed TU16 driver ... 750/780 porting issue.

yes, the whole bitfield thing is a total botch when it cames to real
hardware. Truly bad things happen.

ron

Re: [9fans] struct problems

[Geoff Collyer]

These two are from memory, since grep hasn't turned up the sources
(it's time to fully index all my files, I guess) and neither one is in
the fortunes file:

	Bit-fields are a botch and a blemish. - Dennis Ritchie
		(possibly from a Usenix conference)

	Only children and idiots use bit-fields. - Rob Pike

Re: [9fans] struct problems

[Scott Schwartz]

| These two are from memory, since grep hasn't turned up the sources
| (it's time to fully index all my files, I guess) and neither one is in
| the fortunes file:

The best one was something like:
	I'll use bit-fields before I use Plan 9!  - Brian Kernighan

Re: [9fans] struct problems

[boyd, rounin]

From: "ron minnich" <rminnich@lanl.gov>
> yes, the whole bitfield thing is a total botch when it cames to real
> hardware. Truly bad things happen.

they did; john mackin & i fixed 'em [sending the fixes to 1127] -- ugly ...

extract field instructions just didn't work on the 780's 16 bit UBA device
registers.

don't even get me started on the 'bitmap of free/used ram' on 32V ...

bonus points: what (and how much) did the 780 set to zero on boot?

Re: [9fans] struct problems

[northern snowfall]

>
>
>they did; john mackin & i fixed 'em [sending the fixes to 1127] -- ugly ...
>
1127. thats too weird.

Re: [9fans] struct problems

[boyd, rounin]

From: "northern snowfall" <dbailey27@ameritech.net>
> 1127. thats too weird.

11271

Re: [9fans] struct problems

[Douglas A. Gwyn]

ron minnich wrote:
> yes, the whole bitfield thing is a total botch when it cames to real
> hardware. Truly bad things happen.

Bad things sometimes happen even with access of memory-
mapped device registers via ordinary integer types.

Re: [9fans] struct problems

[boyd, rounin]

> Bad things sometimes happen even with access of memory-
> mapped device registers via ordinary integer types.

'780 extract field on a 16 bit UBA device register ....

Re: [9fans] struct problems

[northern snowfall]

Structures are aligned to the underlying platform's
specifications which may cause problems if you
expect raw data to align to your C structure bit-
for-bit: it won't happen. IIRC, this is the reason
why plan9 code uses the convX2Y() functions,
making sure data represented in a struct is
represented properly by the underlying architecture.
Some people go the B route and use uchar[] for
every structure member, which causes more CPU
cycles later when analyzing data. In my experience
it's just better to parse the raw data into the specific
structure using a conversion routine, possibly
inlined. Bitfields will only augment this issue in
your code and decrease portability.
Don

Re: [9fans] struct problems

[Bruce Ellis]

what other justification for #pragma hjdicks
can you think of?

----- Original Message -----
From: "northern snowfall" <dbailey27@ameritech.net>
To: <9fans@cse.psu.edu>
Sent: Wednesday, May 07, 2003 5:32 PM
Subject: Re: [9fans] struct problems


> Structures are aligned to the underlying platform's
> specifications which may cause problems if you

Re: [9fans] struct problems

[northern snowfall]

Bruce Ellis wrote:

>what other justification for #pragma hjdicks
>can you think of?
>
Extreme intoxication?

>

Re: [9fans] struct problems

[Bruce Ellis]

pragmatism and a silly discussion over dinner.
hj were dicks for assuming that they could
lay out structs in an architecture independant way.
we had to live with it.

----- Original Message -----
From: "northern snowfall" <dbailey27@ameritech.net>
To: <9fans@cse.psu.edu>
Sent: Wednesday, May 07, 2003 11:06 PM
Subject: Re: [9fans] struct problems

> Bruce Ellis wrote:
>
> >what other justification for #pragma hjdicks
> >can you think of?
> >
> Extreme intoxication?

Re: [9fans] struct problems

[northern snowfall]

Bruce Ellis wrote:

>pragmatism and a silly discussion over dinner.
>hj were dicks for assuming that they could
>lay out structs in an architecture independant way.
>we had to live with it.
>
Hey, I never said I *liked* the idea... :) but, thats how
it is...

>

[9fans] snapshots -> archives

[rog]

i'm using venti on my laptop and haven't done snap -a very often (it
needs to be done manually if the machine's not on all the time).

i do however have lots of snapshots taken over the last month or so.

question: is it possible to convert some of these snapshots to entries
in archive.  it would mean that i wouldn't lose all that history,
which currently i will.

the only other alternative that i can see is to vac the snapshots and
store the scores somewhere, but that wouldn't give nearly such a
seamless result.

if there's no current way to do it, is there some fundamental reason
why i won't be able to hack fossil to be able to do it?

  cheers,
    rog.

Re: [9fans] snapshots -> archives

[Russ Cox]

> i'm using venti on my laptop and haven't done snap -a very often (it
> needs to be done manually if the machine's not on all the time).
>
> i do however have lots of snapshots taken over the last month or so.
>
> question: is it possible to convert some of these snapshots to entries
> in archive.  it would mean that i wouldn't lose all that history,
> which currently i will.
>
> the only other alternative that i can see is to vac the snapshots and
> store the scores somewhere, but that wouldn't give nearly such a
> seamless result.
>
> if there's no current way to do it, is there some fundamental reason
> why i won't be able to hack fossil to be able to do it?

there's no current way to do it.  it should be easy enough.
you need to move the snapshots into the /archive tree
(some coding required) and then just run snap -a.

[9fans] acme/sam problem

[ron minnich]

another newbie question:

cpu% src date
B: can't find sam server file
cpu%

What should I start looking for to find out what's up?

Also, on drawterm, I am getting rio and acme windows with text which is
not visible. I can type, cursor moves, you just don't see anything. Is
there some place I should start looking for why this is happening?

thanks

ron

Re: [9fans] acme/sam problem

[Russ Cox]

You're not running a plumber, so src falls
back on trying to find an instance of sam
posted in /srv.  Start a plumber before you
start rio.  Presumably this is in a drawterm
session.

Re: [9fans] acme/sam problem

[ron minnich]

On Wed, 7 May 2003, Russ Cox wrote:

> You're not running a plumber, so src falls
> back on trying to find an instance of sam
> posted in /srv.  Start a plumber before you
> start rio.  Presumably this is in a drawterm
> session.


yes, silly of me to even ask that, I just had to do a ps and notice ... no
plumber. arg.

ron

Re: [9fans] acme/sam problem

[andrey mirtchovski]

> Also, on drawterm, I am getting rio and acme windows with text which is
> not visible. I can type, cursor moves, you just don't see anything. Is
> there some place I should start looking for why this is happening?
>

I know now! This is the same laptop I had (and reported exactly the same
issue some time ago). Now that you have it you're experiencing the same
problem. The difference now is that you're running RedHat (I had FreeBSD
installed) and drawterm-linux (I had drawterm-freebsd).. What's the same
is XFree86 and the video hardware -- S3.

I believe it was assumed to be a race in XFillRectangle somewhere...

So we blame XF86 and S3 for it -- I haven't had any problems running
drawterm with either Radeon 7500 or NVidia TNT2...

andrey

Re: [9fans] struct problems

[David Presotto]

>From: Scott Schwartz <schwartz@bio.cse.psu.edu>
>The best one was something like:
>	I'll use bit-fields before I use Plan 9!  - Brian Kernighan

Trust in the grep Scott:

	% grep bit /sys/games/lib/fortunes|grep field
	I'd use plan 9 before i'd use bitfields -- pjw

Re: [9fans] struct problems

[Scott Schwartz]

| Trust in the grep Scott:

Oops.  Sorry for the misquote.

Re: [9fans] struct problems

[Skip Tavakkolian]

> 	I'd use plan 9 before i'd use bitfields -- pjw

Is this why Plan9 uses pjw as the catchall glyph?

Re: [9fans] struct problems

[boyd, rounin]

> Is this why Plan9 uses pjw as the catchall glyph?

those who forget their history are doomed to repeat it ...

ever seen the pjw labs management hierarchy diagram?

or the t-shirt, or the tower, or the stolen tower template, or the thief, or the
accused thief?

Re: [9fans] struct problems

[Skip Tavakkolian]

> those who forget their history are doomed to repeat it ...

This reminds me, was there or is there a Bell-Labs historian?  I would
think some of the stories would make an interesting history book.  The
exciting ones, of course, not the belly-button-lint-picking ones ☺

Re: [9fans] struct problems

[boyd, rounin]

> This reminds me, was there or is there a Bell-Labs historian?

talk to jmk ...

Re: [9fans] struct problems

[Dennis Ritchie]

>> Is this why Plan9 uses pjw as the catchall glyph?

> those who forget their history are doomed to repeat it ...

> ever seen the pjw labs management hierarchy diagram?

> or the t-shirt, or the tower, or the stolen tower template, or the thief, or the
> accused thief?

 cf. http://spinroot.com/pico/pjw.html

	Dennis

Re: [9fans] struct problems

[matt]

> > cf. http://spinroot.com/pico/pjw.html


what a lovely story

with one slightly disturbing aspect :

"Peter agreed to let us take a plaster cast of his faces."

I hope it's a consonant added rather than a missing vowel.

Curious that the plan9 glyph isn't mentioned.

m

Re: [9fans] struct problems

[boyd, rounin]

somewhere i have the 'white shirt'.

Re: [9fans] struct problems

[boyd, rounin]

i'll have the QAB shirt in a few days

Re: [9fans] struct problems

[northern snowfall]

>
>
>i'll have the QAB shirt in a few days
>
That'd be a pretty sweet tshirt:
    Font:
        Image of the plan9 pjw glyph
    Back:
        "I always wondered what that font glyph meant..."
                             plan9 by Bell Labs
Don

Re: [9fans] struct problems

[boyd, rounin]

i could post a cropped copy of the back of it.

Re: [9fans] struct problems

[boyd, rounin]

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

goto [label that got deleted];



[-- Attachment #2: qab.jpg --]
[-- Type: image/jpeg, Size: 106910 bytes --]

Re: [9fans] struct problems

[jmk]

On Sat May 10 03:12:21 EDT 2003, dmr@plan9.bell-labs.com wrote:
> ...
>  cf. http://spinroot.com/pico/pjw.html
> ...

The above reference is not accurate regarding the versions of the
T-shirts. The original white with blue logo and the pale blue with
black logo shown in http://spinroot.com/pico/pjw_shirt_front.jpg
used a version of Duff's log with fewer lines. The second version,
done by Paul Glick, was a brighter (but still pale) blue with a
blocky 'pixelated' version of PJW's face, not the 'death-star' style
of the first.

As far as I remember, the original white was a small run of no more
than a dozen or so, done in a Portland, OR shop during a break at the
USENIX conference.

Re: [9fans] struct problems

[boyd, rounin]

> As far as I remember, the original white was a small run of no more
> than a dozen or so, done in a Portland, OR shop during a break at the
> USENIX conference.

not sure where mine is.  i was wearing at CRL one day and the lab director
was very curious about how i'd got it ...

the story i heard is that he declined the expense claim for the paint.

Re: [9fans] struct problems

[rob pike, esq.]

> the story i heard is that he declined the expense claim for the paint.

Different 'he'.  The decliner was Vic Vyssotsky.

-rob

Re: [9fans] struct problems

[boyd, rounin]

> Different 'he'.  The decliner was Vic Vyssotsky.

stranger and stranger, but you [i] learn something every day ...

    June 10-14, 1985, there were 1,730 attendees at the Portland,
    OR, meeting. Vic Vyssotsky was the keynote speaker. Other speakers
    were Gordon Bell, Eric Allman, Bjarne Stroustrup, Rob Pike, Dave Presotto,
    Andy Koenig, Tom Ferrin, Dave Yost, Dennis Ritchie, Don Libes, Mike Hawley,
    Ed Gould, Sam Leffler, Dave Korn, Kirk McKusick, Mike Karels, Brian Redman,
and . . .

http://www.usenix.org/publications/login/2000-8/usenixnews.html

hang on, google vet allt ...

    Victor Vyssotsky gave us the freedom to experiment carefully with the
    Internetgateway at Digital's Cambridge ResearchLab. NeilFishman and
   TedWojcikassisted withourexperiments at CRL's gateway.

http://www.usenix.org/publications/library/proceedings/cinci93/full_papers/treese.txt

Re: [9fans] struct problems

[Dennis Ritchie]

Boyd said,

 > not sure where [my t-shirt]  is.  i was wearing at CRL one day and the lab director
 > was very curious about how i'd got it ...

 > the story i heard is that he declined the expense claim for the paint.

Rob demurred,

 > Different 'he'.  The decliner was Vic Vyssotsky.

Assuming CRL was Digital's Cambridge (MA) research
lab, they were presumably the same person--Vic moved
there.  The story of the paint voucher can be expanded.
It was submitted to Vyssotsky, signed indeed by
G. R. Emlin (in a handwriting a graphologist would
have little trouble with).  It came back with a note
from Vic, saying approximately:

	Unfortunately I do not have authorization under
	the G.E.I. to approve real estate improvements.
	If Ms [then perhaps Mr] Emlin wishes to arrange
	a transfer to the Buildings and Grounds group, I
	will help to facilitate this.

Vic also let it be quietly known that the envelope had
been pushed to its very limit.

	Dennis

Re: [9fans] struct problems

[boyd, rounin]

From: "Dennis Ritchie" <dmr@plan9.bell-labs.com>
> Vic also let it be quietly known that the envelope had
> been pushed to its very limit.

iirc he took a short stroll to collect his thoughts on the matter.

Re: [9fans] struct problems

[boyd, rounin]

> As far as I remember, the original white was a small run of no more
> than a dozen or so, done in a Portland, OR shop during a break at the
> USENIX conference.

this sounds right;  piers, maltby and brucee were there

Re: [9fans] struct problems

[rob pike, esq.]

> As far as I remember, the original white was a small run of no more
> than a dozen or so, done in a Portland, OR shop during a break at the
> USENIX conference.

That is correct.  I think Joe Buhler had a friend who made t-shirts and
we used him.  Later, back in NJ, we took the same pattern to a shop
and made a bunch more.  The originals were polyester/cotton blend
and kinda flimsy; the later set were pure cotton and a darker (less
close to AT&T) blue.  Glick's version was much later.

-rob

Re: [9fans] struct problems

[Skip Tavakkolian]

>>> Is this why Plan9 uses pjw as the catchall glyph?
>
>> those who forget their history are doomed to repeat it ...
>
>> ever seen the pjw labs management hierarchy diagram?
>
>> or the t-shirt, or the tower, or the stolen tower template, or the thief, or the
>> accused thief?
>
>  cf. http://spinroot.com/pico/pjw.html

Thanks, now I remember.  I did read about it in the Digital Darkroom book.
But like a good story, it is fun to hear it again.

Maybe a deeper question is, why did Pike and Holzmann do it?  Was
it an inspiration that then snowballed, or was there a deeper
motivation?  The campaign to distribute it in so many forms, certainly
has a fanatical feel to it.

Re: [9fans] struct problems

[rob pike, esq.]

> why did Pike and Holzmann do it?

An imponderable.

-rob

Re: [9fans] struct problems

[boyd, rounin]

how was the 'face the nation' pjw icon encoded in troff, circa 1984?

knowing it's 'size' is trivial, but getting troff to render it, well ... think
of berkeley

Re: [9fans] struct problems

[rob pike, esq.]

> how was the 'face the nation' pjw icon encoded in troff, circa 1984?

Helvetica periods.

-rob

Re: [9fans] struct problems

[boyd, rounin]

> Helvetica periods.

nice use of the 48x48x1 and troff.

Re: [9fans] struct problems

[Anthony Mandic]

"boyd, rounin" wrote:
>
> > Is this why Plan9 uses pjw as the catchall glyph?
>
> those who forget their history are doomed to repeat it ...
>
> ever seen the pjw labs management hierarchy diagram?

	No, never.

> or the t-shirt, or the tower, or the stolen tower template, or the thief, or the
> accused thief?

	Can you be less obscure and elaborate?

-am	� 2003

Re: [9fans] struct problems

[boyd, rounin]

> Can you be less obscure and elaborate?

never ask a question you don't know the answer to :)

there are always 3 responses.