[9fans] Smiley's plan9port mod 1 ver. 1.0 released

[9fans] Smiley's plan9port mod 1 ver. 1.0 released

[smiley]

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|
+---------------------------------------------------------------+

Re: [9fans] Smiley's plan9port mod 1 ver. 1.0 released

[Lucio De Re]

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

I find ^A particularly annoying as a result of the CapsLock key being
mapped to a Ctrl- shift (I don't use ACME under Linux, too much
bother).  I think that particular problem suggests changing the
mapping to nothing at all.  After all, how many of us 9fans actually
use CapsLock as a Ctrl- key?  I know I don't.

++L

Re: [9fans] Smiley's plan9port mod 1 ver. 1.0 released

[Charles Forsyth]

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

I do. It's one of the first things I change on Linux and Windows. HOW MANY
PEOPLE USE CAPS LOCK, I WONDER?

On 23 January 2012 10:02, Lucio De Re <lucio@proxima.alt.za> wrote:

>  After all, how many of us 9fans actually
> use CapsLock as a Ctrl- key?  I know I don't.
>

[-- Attachment #2: Type: text/html, Size: 540 bytes --]

Re: [9fans] Smiley's plan9port mod 1 ver. 1.0 released

[dexen deVries]

On Monday 23 of January 2012 12:52:31 Charles Forsyth wrote:
> I do. It's one of the first things I change on Linux and Windows. HOW MANY
> PEOPLE USE CAPS LOCK, I WONDER?
> 
> On 23 January 2012 10:02, Lucio De Re <lucio@proxima.alt.za> wrote:
> >  After all, how many of us 9fans actually
> > 
> > use CapsLock as a Ctrl- key?  I know I don't.

fwiw, i have Backspace instead of the CapsLock -- thanks to Colemak keyboard 
layout (http://colemak.com/)


-- 
dexen deVries

[[[↓][→]]]

Any sufficiently large fragment of human activity contains an ad hoc, 
informally-specified, bug-ridden, slow attempt at programming.
Corollary: including  programming ;)
((with apologies to Philip Greenspun))

Re: [9fans] Smiley's plan9port mod 1 ver. 1.0 released

[erik quanstrom]

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

what's the practical advantage of having m hardcoded paths rather
than n?  does your sam -d edit complete a few microseconds faster?

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

try "Lenovo Scrollpoint Mouse", 31P7405

although there's sort of a scroll button, in practice the button does not
interfere.  these are the standard mouse at coraid.

- erik

Re: [9fans] Smiley's plan9port mod 1 ver. 1.0 released

[Charles Forsyth]

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

I'm currently using a Sandstrøm Wireless Enhanced Mouse with Acme
(i like the micro-usb connector). it seems to get reasonable battery life.

http://www.sandstromstyle.com/products/type/mice/423677.aspx
On 23 January 2012 15:15, erik quanstrom <quanstro@quanstro.net> wrote:

> although there's sort of a scroll button, in practice the button does not
> interfere.
>

[-- Attachment #2: Type: text/html, Size: 726 bytes --]

Re: [9fans] Smiley's plan9port mod 1 ver. 1.0 released

[Tristan]

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

highlight text in source window. 2-1 cord on Look in the search window.

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

i might use undo and redo, but most of my pasting is better done with the
mouse. mouse-less tag commands i would use, a lot. (maybe enough to
implement it and not just say it).


> I find ^A particularly annoying as a result of the CapsLock key being
> mapped to a Ctrl- shift (I don't use ACME under Linux, too much
> bother).  I think that particular problem suggests changing the
> mapping to nothing at all.  After all, how many of us 9fans actually
> use CapsLock as a Ctrl- key?  I know I don't.

which is presumably why ^A is annoying for you.

-- 
All original matter is hereby placed immediately under the public domain.

Re: [9fans] Smiley's plan9port mod 1 ver. 1.0 released

[Anthony Sorace]

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


On Jan 23, 2012, at 3:58 , smiley@icebubble.org wrote:

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

Early versions of 9p9 had a bunch of 9foo commands, before the addition of
the "9" command. Your change here seems like a step backwards to me, as
it'd require much more editing of various scripts. Set the default $PATH the
way you like it, and if you have something which depends on the differences,
use ". 9" or ". u" to override it.


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

This could be very interesting. My main reason for running venti instead of,
say, cwfs is to dump bits from Unix hosts, so doing this better could be a
significant win.

> Notes on the changes to lib9:



I don't think I really like what you've done with symlinks, but I agree there
isn't really a "right" answer in the face of differing expectations between
the Unix and Plan 9 worlds. It'll be an interesting experiment, at the least.

I'm not sure I see what you mean by suggesting the existing symlink
behavior aims at imitating namespaces.

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

I've sometimes thought I'd like the tag lines and window body to have
different default fonts, to make tag lines easier to hit. Mostly, though, this
comes up when using Acme with something other than a good mouse, and
I've "solved" the problem by only using acme with a good mouse handy.

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

This comes up all the time. You can scan the mailing list archive for
references and discussion if you like, but suffice it to say that this doesn't
impact your actual time spent doing given tasks the way you think it
does, and is largely psychological.

That said, particular things can make it more or less productive. You really
want a good (accurate and responsive) mouse. I liked trackpoints before
I started using Acme regularly, but they're very irritating there. Trackpads
seem okay. I also found Acme a lot more compelling when I started using
keyboards that don't have the extraneous stuff to the right of enter.

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

I don't agree, but if you find it such you might enjoy Russ's " and "" scripts
(/n/sources/contrib/rsc/scripts) or Erik's rc tweak, which includes some
form of history (/n/sources/contrib/quanstro/src/futharc).

> 	* 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?

The short answer is that this isn't Acme's job. There are a number of
solutions to this problem using 3rd party tools, though. I ported
Exuberant Ctags to Plan 9 and added acme-style tag output to make
plumbing things easier; I expect the changes would be easily
backportable to Unix, although I've never tried. Other people have done
other things with code tagging databases.

See my ctags note here: http://9fans.net/archive/2008/02/504

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

For the most part, these are absent as a conscious choice. Some folks
disagree, of course. It hasn't been updated in a while, but Ron has an
acme fork ("smacme"; /n/sources/contrib/rminnich/smacme) which
implements some emacs-style navigation. I'm not sure if it got into
higher-level things like Put, but it generated some discussion at the
time. The archives might be informative, or at least suggest who to ask.

anth


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 210 bytes --]

Re: [9fans] Smiley's plan9port mod 1 ver. 1.0 released

[smiley]

erik quanstrom <quanstro@quanstro.net> writes:

> what's the practical advantage of having m hardcoded paths rather
> than n?  does your sam -d edit complete a few microseconds faster?

The idea is to eventually eliminate all hard-coded paths.  Those files
that still contain them are either in lanugages alien to me (such as
troff), or pertain to platorms with which I am unfamiliar (such as OS
X).  Hopefully, someone who's more familiar with those systems will be
able to snipe off the remaining 5 paths.  Since it's all open source (or
at least well-defined), a hard-coded path count == 0 is theoretically
possible to achieve.

> try "Lenovo Scrollpoint Mouse", 31P7405

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

Re: [9fans] Smiley's plan9port mod 1 ver. 1.0 released

[erik quanstrom]

On Fri Jan 27 20:11:33 EST 2012, smiley@icebubble.org wrote:
> erik quanstrom <quanstro@quanstro.net> writes:
>
> > what's the practical advantage of having m hardcoded paths rather
> > than n?  does your sam -d edit complete a few microseconds faster?
>
> The idea is to eventually eliminate all hard-coded paths.  Those files
> that still contain them are either in lanugages alien to me (such as
> troff), or pertain to platorms with which I am unfamiliar (such as OS
> X).  Hopefully, someone who's more familiar with those systems will be
> able to snipe off the remaining 5 paths.  Since it's all open source (or
> at least well-defined), a hard-coded path count == 0 is theoretically
> possible to achieve.

as you say yourself, that's an idea, the code still does the same thing.

- erik

[9fans] Smiley's plan9port mod 1 ver. 1.1 released (BUGFIX)

[smiley]

smiley@icebubble.org writes:

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

During beta, some bugs were uncovered in ver. 1.0 that make it, well,
unsuitable for use on Real Data(TM).  They've been remedied in ver 1.1:

<magnet:?dn=sp9pm1v1p1.patch&xl=153760&xt=urn:sha1:OLNETULVWDFJYMNRNTFDM6OUDFIBPXJK&xt=urn:md5:8A56596FB8556C305BE5658AE9458D8C&xt=urn:crc32:706490478&as=http%3A%2F%2Fplan9.icebubble.org%2Fplan9port%2Fpatches%2Fsp9pm1v1p1.patch>

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

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