9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Smiley's plan9port mod 1 ver. 1.0 released
@ 2012-01-23  8:58 smiley
  2012-01-23 10:02 ` Lucio De Re
                   ` (3 more replies)
  0 siblings, 4 replies; 11+ messages in thread
From: smiley @ 2012-01-23  8:58 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Hello, 9fans!

:)y's plan9port mod 1 version 1.0 is now out.

<magnet:?dn=sp9pm1v1p0.patch&xl=153045&xt=urn:sha1:DN75FAYWWBS54C3TL2DE7DTFMICT2GFX&xt=urn:md5:8B486B050E4FC7E054156CBB6194348C&xt=urn:crc32:909347387&as=http%3A%2F%2Fplan9.icebubble.org%2Fplan9port%2Fpatches%2Fsp9pm1v1p0.patch>

<http://plan9.icebubble.org/plan9port/patches/sp9pm1v1p0.patch>

Among its features:

	* The ./INSTALL script has been enhanced, to improve detection
	of failed compiles/installs by returning a non-zero exit code.
	This makes it easier for build scripts to detect incomplete
	builds, and to detect complete builds with fewer false
	positives.

	* Finally! A sane solution to the problem of hard-coded paths
	in the plan9port tree: Most of them have been removed, in
	favor of a "#!/usr/bin/env 9rc" approach (which execs "9 rc").
	The "9" script has been updated with "intelligence" to detect
	and set $PLAN9 from miscellaneous clues in its environment.
	(Exec is used throughout, so no memory penalty is incurred.)
	Just a few hard-coded paths remain. One of them is in the "9"
	script, itself. The others (5, at last count) can be found in
	lib/moveplan9.files. OS X users should develop a habit (like
	Linux users) of setting their $PATH variables to include
	$PLAN9/bin, so some of the remaining hard-coded paths can be
	eliminated.

	* To facilitate the "9rc" mechanism, a few additional scripts
	have been added. "9awk" execs "9 awk", "9sed" execs "9 sed",
	etc. There's even a 9bash to make it easy to run bash scripts
	with $PLAN9 set to an appropriate value. There's also a "9fmt"
	to make it easier to run "|fmt" (which would otherwise have to
	be run as "|9 fmt") in Acme on plan9port.

	* Updates to documentation, including the install(1) page,
	install.txt, README, (9P) manual, and a number of other man
	pages. Documentation of more current command-line options,
	more gooder grammar, and clearer explanations.

	* vac and vacfs now support symbolic links, block and
	character devices, named pipes, Unix domain sockets, and inode
	change times (ctime), as well as set-user-id, set-group-id,
	and sticky bits. In theory, they also support append-only
	(DMAPPEND), exclusive-use (DMEXCL), and temporary (DMTMP)
	bits. However, due to lack of a native Plan 9 system, support
	for DMAPPEND, DMEXCL, and DMTMP has not been tested.
	Preliminary support in unvac for these file types and mode
	bits exists, but is still incomplete. 9pfuse has been updated
	to support those of the above attributes which can be exposed
	by 9P2000. So now you can have, for example, block devices and
	Unix domain sockets appear in your 9pfuse file systems.

	* Note: A number of changes were made to lib9, so almost all
	of p9p will need to be recompiled.

Thanks to:

	* David du Colombier for showing me how to implement symbolic
	links.

	* rsc for creating the bowl of spaghetti which has been so
	much fun swimming in. ;)

Notes on the changes to lib9:

	A ctime member was added to the Dir struct, so a file's citme
	can be passed around with the rest of the file's metadata on
	p9p systems. This changes sizeof(Dir), which is used by many
	programs, so programs relying on the old sizeof(Dir) have to
	be recompiled.

	The most significant change to lib9 is in the way the dirstat,
	dirread, and dirreadall functions handle symbolic links.
	Previously, symbolic links were dereferenced immediately upon
	being statted. However, this functionality was not implemented
	correctly. Although other file attributes correctly reflected
	the referent of the link, the file size was left as the size
	of the link (the number that a call to readlink would return),
	and the DMSYMLINK bit was left set in the file mode. I'm
	guessing that this was an early attempt to emulate Plan 9's
	namespace mechanism using symbolic links. The new approach is
	to NOT dereference symbolic links in dirstat and dirread[all], but
	to return stat data for the symbolic link itself. Since other
	functions, such as open, remove, etc., use the native library
	calls, which handle symbolic links according to Unix
	semantics, they still behave correctly. Since a walk through a
	symbolic link involves opening its referent and reading
	directory entries, walking through symlinked directories still
	works. The advantage of the new approach is that symlink
	metadata is now accessible in p9p's stat structure. Access to
	this metadata is necessary for vac(1) to store the correct
	atime, mtime, and ctime for a symlink in a vac archive.

	The potential drawback to this new way of handling symlinks is
	that programs which descend file heirarchies by checking only
	DMDIR will not follow symlinks automatically. (The du(1)
	command is a good example.) On Unix, this is typically the
	correct behavior. On Plan 9, recursive descent conventionally
	traverses namespace boundaries. But plan9port has one foot in
	the world of Unix and the other foot in the world of Plan 9,
	so it's hard to say which behavior is "correct" for plan9port.
	In general, I think plan9port programs should be prepared to
	encounter files of types other than ordinary files and
	directories (such as FIFOs, sockets, and symlinks). In du.c,
	for example, a simple dirfstat is all that's needed:

		if(followsymlinksoption && dir->qid.type&QTSYMLINK)
			dir = dirfstat(fd);

	Nevertheless, there is still merit to the idea of using
	symlinks to emulate Plan 9-style name spaces. So that
	functionality has also been implemented (correctly, this time,
	I think). You can choose which symlink paradigm a particular
	program should use by setting the variable $PLAN9_DEREF in its
	environment to one of the following values:

		PLAN9_DEREF="dirs"	# deref only links to directories
		PLAN9_DEREF="nondirs"	# deref links to all but directories
		PLAN9_DEREF="both"	# deref all symlinks
		PLAN9_DEREF="none"	# stat symlinks as symlinks

	If $PLAN9_DEREF is unset, null, or set to any other value,
	dirstat, dirread, and dirreadall will behave as if
	PLAN9_DEREF="none". Note that this setting controls only the
	behavior of the functions dirstat, dirread, and dirreadall,
	not other functions like open or remove, which continue to
	operate as they always have: a successful open still always
	dereferences symbolic links, and remove still never does.

Notes on developing in Acme:

	This is the first project I've done in Acme. Some of my
	impressions of the experience follow.

	* Click-to-focus is just as annoying today as it was in 1995.
	Point-to-focus is cumbersome when used by small windows, such
	as Acme window tag lines. For tag lines, "sloppy" focus might
	be better, although it's unclear how sloppy focus and
	point-to-focus could be made to co-exist peacefully.

	* The ability to click and grab, or drag and grab, text
	(chording) is very useful.

	* Acme very frequently places new windows where I least want
	them, and with inconvenient sizes. This gets to be quite
	annoying after a while, encouraging workarounds that require
	extraneous clicking.

	* Having to switch a hand back and forth between the keyboard
	and mouse (or typing with one hand, while mousing with the
	other) is an annoyance. I suspect you really need three arms
	to use Acme efficiently. (For the record, I'm a touch-typist.)

	* Per recommendations from the Plan 9 community, I ordered an
	HP DY651A three-button USB optical mouse with no scroll wheel.
	(The actual mouse I received is labeled M-U0013-O, which I'm
	guessing is a synonymous part number.) This mouse is
	significantly smaller than my hand, and the middle button is
	not haptically distinguishable from the others. This means
	that chording requires fine motor skill, which is tedious
	pretty much from the get go. The other mouse recommended by
	the Plan 9 community, the IBM 40K9201, appears to have been
	discontinued and could not be found for purchase, even on the
	Internet. No three-button optical USB mice (ZERO! NONE!)
	without scroll wheels could be found in local computer shops
	or retail stores.

	* It's not easy to search one Acme window for a search string
	in another Acme window.

	* "New" and "win" are not in the default tag line for
	directory windows, but they should be. It would also be useful
	if the default tag line in "New" windows contained that
	directory name, as well as the text "Get".

	* Recalling/editing previous commands in "win" windows is
	tedious.

	* It's difficult to open files with odd characters in their
	names, such as '"' (double quote). The name has to be
	explicitly entered into a tag line; sweeping it with button 3
	treats it as a search string, without first checking if it's
	the name of a file.

	* It's difficult to find the header/source file in which a
	particular function, variable, or macro is defined. Why can't
	Acme cross-reference such things, like other IDEs do?

	* Where did all my keyboard accelerators go?  Acme could use
	Put, Undo, and Paste accelerators, at a minimum.  Keystrokes
	for forward/backward word would be great, and a keystroke to
	warp the pointer to the end of the tag line would be really
	nice, too.

	* What command did I just run? When text is executed
	erroneously with button 2, Acme will show the error output,
	but not the command that was run. This can happen, for
	example, if the mouse moves unintentionally when you release
	button 2, while clicking or dragging text you want to execute.

--
+---------------------------------------------------------------+
|Smiley       <smiley@icebubble.org>    PGP key ID:    BC549F8B |
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+



^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-02-04  1:27 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-23  8:58 [9fans] Smiley's plan9port mod 1 ver. 1.0 released smiley
2012-01-23 10:02 ` Lucio De Re
2012-01-23 11:52   ` Charles Forsyth
2012-01-23 11:59     ` dexen deVries
2012-01-23 17:03   ` Tristan
2012-01-23 15:15 ` erik quanstrom
2012-01-23 15:26   ` Charles Forsyth
2012-01-28  0:52   ` smiley
2012-01-28  1:45     ` erik quanstrom
2012-01-23 17:48 ` Anthony Sorace
2012-02-04  1:27 ` [9fans] Smiley's plan9port mod 1 ver. 1.1 released (BUGFIX) smiley

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).