Re: [9front] !#&%&^#*@ RIO!!!

Re: [9front] !#&%&^#*@ RIO!!!

[cinap_lenrek]

huh? rio doesnt use event library. it uses mouse(2) instead, which gives
you a Mousectl* that contains a channel. the "mouse" variable of
type Mouse* points into that mousectl which caches the most recent mouse
data read from the channel. it gets updated by readmouse() which is
in libdraw.

here:

int
readmouse(Mousectl *mc)
{
	if(mc->image){
		Display *d = mc->image->display;
		if(d->bufp > d->buf)
			flushimage(d, 1);
	}
	if(recv(mc->c, &mc->Mouse) < 0){
		fprint(2, "readmouse: %r\n");
		return -1;
	}
	return 0;
}

note that mouse == &mc->Mouse because:

	mousectl = initmouse(nil, screen);
	if(mousectl == nil)
		error("can't find mouse");
	mouse = mousectl;

--
cinap

Re: [9front] !#&%&^#*@ RIO!!!

[Ethan Gardener]

On Thu, Dec 13, 2018, at 11:23 AM, cinap_lenrek@felloff.net wrote:
> huh? rio doesnt use event library.

i know.

> it uses mouse(2) instead, which gives
> you a Mousectl* that contains a channel. the "mouse" variable of
> type Mouse* points into that mousectl

^-- This part is completely invisible in the code.  That's my complaint.
It might not be so bad if I lived and breathed Plan 9, I suppose, 
but I don't want to go that far.  Without that level of familiarity, 
the code is as clear as mud.

I suppose I'm complaining about a convenience feature making it 
unclear, but I just got badly stressed over it *again*.  It turns out 
it's not even rio, but a library feature rio makes heavy use of.
It's certainly made me rethink my opinion of convenience features.
If the library didn't provide this, the code which uses it would have 
an indication of where the data is coming from.  
Even if rio assigned the "mouse" variable in exactly the way the 
library presently does, I wouldn't have got stressed trying to find it.

Thank you for your clear explanation, but I don't think I'll pursue 
this further with these libraries.  Various things from /sys/src/libdraw 
have caused me stress, so I've put new libraries on my hobby list. :)
Maybe I'll get them done, or maybe I'll give up on programming 
anything of any depth. I don't know.

Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!)

[magma698hfsp273p9f]

Ethan Gardener <eekee57@fastmail.fm> writes:

>> it uses mouse(2) instead, which gives
>> you a Mousectl* that contains a channel. the "mouse" variable of
>> type Mouse* points into that mousectl
>
> ^-- This part is completely invisible in the code.  That's my complaint.
> It might not be so bad if I lived and breathed Plan 9, I suppose, 
> but I don't want to go that far.  Without that level of familiarity, 
> the code is as clear as mud.

That's why I gave up on using Plan 9 as a production operating system,
too.  Because Plan 9 is a free/open source operating system, in theory,
one should be able to read the code, verify its corectness, make fixes,
add enhancements, etc.  But on Plan 9, the whole system (kernel,
libraries, and application code) is written in old-style C, like UNIX.
It uses lots of variables with inscrutable names like "n", "p", "c", and
"d" and sports few, if any, comments.  I just got tired of trying to
keep track of which variables refer to what, and of deciphering what a
particular loop of code is trying to do.  Just what does "**p" mean,
anyway?  Another difficulty which Plan 9 code shares with UNIX is
keeping track of who owns which data structures in memory.  Who's
calling malloc(), and who (if anyone) is responsible for free()ing that
memory?  Like on UNIX, the Plan 9 manual pages are often silent on this,
and the source code usually doesn't document memory ownership, either.
The Plan 9 man pages use lots of Plan 9 jargon, so they're difficult to
understand unless you already know how the system works.  And, because
Plan 9 source code uses so many external functions, it is often tough to
find the relevant code.  When I started segfaulting applications and
seeing strange forms of corruption, I began looking at the code, and
realized how hard it is to read, debug, fix, enhance, or even verify.
Alas, code which can't be verified isn't reliable, and code which isn't
reliable isn't secure.

As it happens, many of these problems are solved (either wholly or at
least partially) by the Inferno operating system (which is based on, and
incorporates many of the features of, Plan 9).  The architecture of Dis,
the virtual machine used by Inferno, makes it unnecessary to keep track
of most memory allocation/deallocation.  The system programming
language, Limbo, is much easier to read and write in than C, and
Inferno's module system makes it easy to see where data and code reside.
Inferno's man pages are also much easier to read (perhaps because they
were written with Plan 9 in hindsight).  In all fairness, though,
Inferno's documentation isn't perfect.  Some of the documentation's file
names are a bit obscure.  For example, an overview of Inferno can be
found in /doc/bltj.pdf.  (What does "bltj" stand for?  "Bacon, lettuce,
tomato, and jelly," perhaps?)  The informal specification of the Dis
virtual machine (in /doc/dis.pdf) contains a number of ambiguitities and
obvious errors.  And the man pages for the Tk widgets canvas(9) and
text(9) make for long, painful reading.  But, in broad terms, one can
gain an understanding of the system, easily enough, by reading the
documentation under the /doc and /man directories.  One of the
disadvantages of Inferno, however, is that several of its core modules
(such as its impelmentation of Tk) are hard-coded into the Inferno
kernel in---you guessed it---C.  Nevertheless, the C code is easier to
read than on Plan 9, and the clean separation between the C, Dis, Limbo,
and sh "layers" of the operating system makes it much easier to
understand.  This makes those couple thousand lines of C code much
easier to swallow.  Another weakness of Inferno, however, is its
application support.  Although someone has made Limbo ports of acme(1)
and charon(1), there isn't any Limbo port of fossil, and the Limbo port
of factotum(4) supports only a bare minimum of authentication protocols.
Fortunately, Inferno is compatible with Plan 9, and can share resources
with (import from/export to) Plan 9.

In all likelihood, I'll probably end up running Inferno hosted on an
underlying system like Plan 9 or GNU+plan9port.  But, if someone could
just figure out how I could avoid having to upgrade my version of
Firefox every three months, THAT would be my operating system of choice!

Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!)

[Julius Schmidt]

> That's why I gave up on using Plan 9 as a production operating system,
> too.  Because Plan 9 is a free/open source operating system, in theory,
> one should be able to read the code, verify its corectness, make fixes,
> add enhancements, etc.  But on Plan 9, the whole system (kernel,
> libraries, and application code) is written in old-style C, like UNIX.
> It uses lots of variables with inscrutable names like "n", "p", "c", and
> "d" and sports few, if any, comments.  I just got tired of trying to
> keep track of which variables refer to what, and of deciphering what a
> particular loop of code is trying to do.  Just what does "**p" mean,
> anyway?  Another difficulty which Plan 9 code shares with UNIX is
> keeping track of who owns which data structures in memory.  Who's
> calling malloc(), and who (if anyone) is responsible for free()ing that
> memory?  Like on UNIX, the Plan 9 manual pages are often silent on this,
> and the source code usually doesn't document memory ownership, either.
> The Plan 9 man pages use lots of Plan 9 jargon, so they're difficult to
> understand unless you already know how the system works.  And, because
> Plan 9 source code uses so many external functions, it is often tough to
> find the relevant code.  When I started segfaulting applications and
> seeing strange forms of corruption, I began looking at the code, and
> realized how hard it is to read, debug, fix, enhance, or even verify.
> Alas, code which can't be verified isn't reliable, and code which isn't
> reliable isn't secure.

The funny thing is, I always found Plan 9 source to be remarkably clear
compared to what other code I've seen.
Things are generally clear enough on the macro-level that you can figure
out what's going on the micro-level without too much trouble.

I wouldn't mind some more comments, particularly on assumptions, but I'm
also bad at writing comments....

Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!)

[Steve Simon]

i can inly disagree. find plan9 code very, very clear and easy to read.

bstj == bell labs technical journal.

-Steve


On 18 Dec 2018, at 11:41 pm, Julius Schmidt <aiju@phicode.de> wrote:

>> That's why I gave up on using Plan 9 as a production operating system,
>> too.  Because Plan 9 is a free/open source operating system, in theory,
>> one should be able to read the code, verify its corectness, make fixes,
>> add enhancements, etc.  But on Plan 9, the whole system (kernel,
>> libraries, and application code) is written in old-style C, like UNIX.
>> It uses lots of variables with inscrutable names like "n", "p", "c", and
>> "d" and sports few, if any, comments.  I just got tired of trying to
>> keep track of which variables refer to what, and of deciphering what a
>> particular loop of code is trying to do.  Just what does "**p" mean,
>> anyway?  Another difficulty which Plan 9 code shares with UNIX is
>> keeping track of who owns which data structures in memory.  Who's
>> calling malloc(), and who (if anyone) is responsible for free()ing that
>> memory?  Like on UNIX, the Plan 9 manual pages are often silent on this,
>> and the source code usually doesn't document memory ownership, either.
>> The Plan 9 man pages use lots of Plan 9 jargon, so they're difficult to
>> understand unless you already know how the system works.  And, because
>> Plan 9 source code uses so many external functions, it is often tough to
>> find the relevant code.  When I started segfaulting applications and
>> seeing strange forms of corruption, I began looking at the code, and
>> realized how hard it is to read, debug, fix, enhance, or even verify.
>> Alas, code which can't be verified isn't reliable, and code which isn't
>> reliable isn't secure.
> 
> The funny thing is, I always found Plan 9 source to be remarkably clear
> compared to what other code I've seen.
> Things are generally clear enough on the macro-level that you can figure
> out what's going on the micro-level without too much trouble.
> 
> I wouldn't mind some more comments, particularly on assumptions, but I'm
> also bad at writing comments....

Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!)

[hiro]

in many situations reading requires more effort than writing. so this
thread only makes sense.
blame culture.

Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!)

[hiro]

please note that there is a whole book of commentery
http://lsub.org/who/nemo/9.intro.pdf

Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!)

[Ethan Gardener]

On Wed, Dec 19, 2018, at 8:02 AM, hiro wrote:
> please note that there is a whole book of commentery
> http://lsub.org/who/nemo/9.intro.pdf

9.intro.pdf contains:
> It is important to note that this book is not a reference for using an
> operating system nor a reference for Plan 9 from Bell Labs.  The
> user’s manual that comes installed within the system is the proper
> reference to use.  These lecture notes just shows you how things work,
> by using them.  Once you have gone through the course, you are
> expected to search and use the user’s manual as a reference.

I ran into trouble when I needed a quick, authoritative reminder, 
not 400 pages of lecture notes.

-- 
Progress might have been all right once, but it has gone on too long -- Ogden Nash

Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!)

[Ethan Gardener]

On Tue, Dec 18, 2018, at 11:41 PM, Julius Schmidt wrote:
> > That's why I gave up on using Plan 9 as a production operating system,
> > too.  Because Plan 9 is a free/open source operating system, in theory,
> > one should be able to read the code, verify its corectness, make fixes,
> > add enhancements, etc.  But on Plan 9, the whole system (kernel,
> > libraries, and application code) is written in old-style C, like UNIX.
> > It uses lots of variables with inscrutable names like "n", "p", "c", and
> > "d" and sports few, if any, comments.  I just got tired of trying to
> > keep track of which variables refer to what, and of deciphering what a
> > particular loop of code is trying to do.  Just what does "**p" mean,
> > anyway? 

Literally, it's a pointer to a pointer to something.  
Indirection makes my head hurt, which is a shame because it's 
extremely useful.  Oh wait... I had no problem with indirection 
in rc ($$foo). hmm..

> > Another difficulty which Plan 9 code shares with UNIX is
> > keeping track of who owns which data structures in memory.  Who's
> > calling malloc(), and who (if anyone) is responsible for free()ing that
> > memory?  Like on UNIX, the Plan 9 manual pages are often silent on this,
> > and the source code usually doesn't document memory ownership, either.
> > The Plan 9 man pages use lots of Plan 9 jargon, so they're difficult to
> > understand unless you already know how the system works.  And, because
> > Plan 9 source code uses so many external functions, it is often tough to
> > find the relevant code.  When I started segfaulting applications and
> > seeing strange forms of corruption, I began looking at the code, and
> > realized how hard it is to read, debug, fix, enhance, or even verify.
> > Alas, code which can't be verified isn't reliable, and code which isn't
> > reliable isn't secure.
> 
> The funny thing is, I always found Plan 9 source to be remarkably clear
> compared to what other code I've seen.
> Things are generally clear enough on the macro-level that you can figure
> out what's going on the micro-level without too much trouble.

I wish I could understand how you can understand it! lol~  
My best guess is, "It's how much you can keep track of at once." 
Perhaps if that ability is below a certain threshold, it's hard.
I would like that to be untrue, but it probably is in my case.  
I have to admit I have a lot of trouble keeping track of 
surprisingly trivial details in everyday life.  

You know, I'm starting to think I might get better as I resolve 
issues from my past.  I hope I will, of course, but it could 
take a long time.

> I wouldn't mind some more comments, particularly on assumptions, but I'm
> also bad at writing comments....

Good to know I'm better at *something.* ;)

-- 
Progress might have been all right once, but it has gone on too long -- Ogden Nash

Re: Reading/understanding OS code -- documentation

[Ethan Gardener]

On Tue, Dec 18, 2018, at 10:47 PM, magma698hfsp273p9f@icebubble.org wrote:
> 
> And the man pages for the Tk widgets canvas(9) and
> text(9) make for long, painful reading. 

This is what I found when I tried to learn Tk in the 90s.  
(They're probably the very same pages. :)
I found it easier when I tried again last year, 
but I think it's because my brain has improved, 
not so much the software or documentation.  
The latter two have improved a bit, 
but there's not very much change.

I've heard a lot of praise for Tk's ease of use, but honestly, 
other things are far easier still.  I took up APL, using the now-free APLX. 
APL is not typically used by full-time programmers, 
so there's economic pressure to keep the interfaces simple and 
sufficiently-documented.  An example is the edit widget.  
The whole text is available as a variable; a string.  So is the selection.  
Either may be read or set.  Simple!
Granted, this isn't entirely obvious from the manual, 
but there is an example which shows assignment to myEdit.text.
It's not possible to make a C interface quite that simple, 
but it could be very close, with functions to read and set the strings.

IMO, examples are worth a thousand words of documentation.
In Plan 9, example code is available in the form of the system source, 
but relevant examples are not usually referenced in the manual, 
leaving the user to blunder about trying to find something 
which is both relevant and comprehensible.

Hmm...
APLX has brief documentation with examples.
Plan 9's manual pages are relatively verbose and lack examples.
...
Almost everything I've ever successfully learned in programming 
has been documented with examples and just enough text.

Skipping back a sentence:
> The informal specification of the Dis
> virtual machine (in /doc/dis.pdf) contains a number of ambiguitities and
> obvious errors. 

Documentation always contains errors.  
That's another reason to keep it as short as possible.

-- 
Progress might have been all right once, but it has gone on too long -- Ogden Nash