* Re: [9front] !#&%&^#*@ RIO!!! @ 2018-12-13 11:23 cinap_lenrek 2018-12-13 13:28 ` Ethan Gardener 0 siblings, 1 reply; 10+ messages in thread From: cinap_lenrek @ 2018-12-13 11:23 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9front] !#&%&^#*@ RIO!!! 2018-12-13 11:23 [9front] !#&%&^#*@ RIO!!! cinap_lenrek @ 2018-12-13 13:28 ` Ethan Gardener 2018-12-18 22:47 ` Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) magma698hfsp273p9f 0 siblings, 1 reply; 10+ messages in thread From: Ethan Gardener @ 2018-12-13 13:28 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) 2018-12-13 13:28 ` Ethan Gardener @ 2018-12-18 22:47 ` magma698hfsp273p9f 2018-12-18 23:41 ` Julius Schmidt 2018-12-21 8:22 ` Reading/understanding OS code -- documentation Ethan Gardener 0 siblings, 2 replies; 10+ messages in thread From: magma698hfsp273p9f @ 2018-12-18 22:47 UTC (permalink / raw) To: 9front 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! ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) 2018-12-18 22:47 ` Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) magma698hfsp273p9f @ 2018-12-18 23:41 ` Julius Schmidt 2018-12-19 7:44 ` Steve Simon ` (2 more replies) 2018-12-21 8:22 ` Reading/understanding OS code -- documentation Ethan Gardener 1 sibling, 3 replies; 10+ messages in thread From: Julius Schmidt @ 2018-12-18 23:41 UTC (permalink / raw) To: 9front > 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.... ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) 2018-12-18 23:41 ` Julius Schmidt @ 2018-12-19 7:44 ` Steve Simon 2018-12-19 8:19 ` hiro 2018-12-19 8:02 ` hiro 2018-12-20 20:12 ` Ethan Gardener 2 siblings, 1 reply; 10+ messages in thread From: Steve Simon @ 2018-12-19 7:44 UTC (permalink / raw) To: 9front 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.... ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) 2018-12-19 7:44 ` Steve Simon @ 2018-12-19 8:19 ` hiro 0 siblings, 0 replies; 10+ messages in thread From: hiro @ 2018-12-19 8:19 UTC (permalink / raw) To: 9front in many situations reading requires more effort than writing. so this thread only makes sense. blame culture. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) 2018-12-18 23:41 ` Julius Schmidt 2018-12-19 7:44 ` Steve Simon @ 2018-12-19 8:02 ` hiro 2018-12-20 20:20 ` Ethan Gardener 2018-12-20 20:12 ` Ethan Gardener 2 siblings, 1 reply; 10+ messages in thread From: hiro @ 2018-12-19 8:02 UTC (permalink / raw) To: 9front please note that there is a whole book of commentery http://lsub.org/who/nemo/9.intro.pdf ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) 2018-12-19 8:02 ` hiro @ 2018-12-20 20:20 ` Ethan Gardener 0 siblings, 0 replies; 10+ messages in thread From: Ethan Gardener @ 2018-12-20 20:20 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) 2018-12-18 23:41 ` Julius Schmidt 2018-12-19 7:44 ` Steve Simon 2018-12-19 8:02 ` hiro @ 2018-12-20 20:12 ` Ethan Gardener 2 siblings, 0 replies; 10+ messages in thread From: Ethan Gardener @ 2018-12-20 20:12 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Reading/understanding OS code -- documentation 2018-12-18 22:47 ` Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) magma698hfsp273p9f 2018-12-18 23:41 ` Julius Schmidt @ 2018-12-21 8:22 ` Ethan Gardener 1 sibling, 0 replies; 10+ messages in thread From: Ethan Gardener @ 2018-12-21 8:22 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-12-21 8:22 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-13 11:23 [9front] !#&%&^#*@ RIO!!! cinap_lenrek 2018-12-13 13:28 ` Ethan Gardener 2018-12-18 22:47 ` Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!) magma698hfsp273p9f 2018-12-18 23:41 ` Julius Schmidt 2018-12-19 7:44 ` Steve Simon 2018-12-19 8:19 ` hiro 2018-12-19 8:02 ` hiro 2018-12-20 20:20 ` Ethan Gardener 2018-12-20 20:12 ` Ethan Gardener 2018-12-21 8:22 ` Reading/understanding OS code -- documentation Ethan Gardener
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).