[9fans] success with 9vx from a terminal

[9fans] success with 9vx from a terminal

[Chris Brannon]

Last night I downloaded 9vx.  It works fine from a terminal, using
the following invocation:
../9vx.Linux -g -u glenda
where -g is the option to run sans GUI.
This has one or two complications.  There is no way to interrupt or kill
the foreground process.  Instead, ctrl-c interrupts 9vx itself.
Anyway, I managed to get an emulated Plan 9 system up and running.
Both ed and "sam -d" work well for editing text.

-- Chris

Re: [9fans] success with 9vx from a terminal

[andrey mirtchovski]

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

> This has one or two complications.  There is no way to interrupt or kill
> the foreground process.  Instead, ctrl-c interrupts 9vx itself.

chris,

one of the nice things about the Plan 9 graphics system is that rio is
in no way different than any other graphical program. it reads and
writes files in /dev/wsys and multiplexes them between other
applications. in that sense, you don't need to run rio in order to run
a graphical app. from the 9vx console you can just type 'acme' and
you'll have acme running in full-screen mode. if you know what you
desire in a window manager (perhaps a terminal window in a static
location to which you can always return, or keyboard-driven window
switching) one can be written so that it's used instead of rio.
graphical programs in plan9 are not hard.

in the mean time you wan use acme's terminal (the program is called
'win') to gain a more feature-full environment. i have attached here a
dump file which can be used to start acme in a single-column mode with
a single window running the terminal program. that will give you
interrupt capability. from here you can hopefully explore the system
without having to deal with windows. unfortunately the default for
'win' is to not scroll to the bottom of the window when the text fills
the screen and there is only one way to turn that off: in a terminal
you have to type 'scroll' and middle-click it with the mouse (is there
a way to issue this as a command from the terminal, anybody?). also,
you can backspace over the beginning of the line to the previous row
which can be annoying.

if you think this may be useful and you want to give it a try please
copy the attached acme.dump file somewhere within the 9vx plan9
directory, then start 9vx and in its terminal type "acme -l
/path/to/acme.dump" where /path/to is just the path relative to root.

the screen will have acme's main "menu" (text) as its first row, then
column menu as the second (New Cut Paste, etc) with the terminal
starting on the third row.

hope this gives you a better environment.

andery

[-- Attachment #2: acme.dump --]
[-- Type: application/octet-stream, Size: 252 bytes --]

/
/lib/font/bit/lucidasans/euro.8.font
/lib/font/bit/lucm/unicode.9.font
          0
e          0           0           0           0           1 
          2          38        6153           0           1 //-vx32 Del Snarf | Look Send Noscroll
/
win

Re: [9fans] success with 9vx from a terminal

[andrey mirtchovski]

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

my previous message was meant to include a small addition which I
omitted by accident and which turned out to be wrong anyway. here is
the rest of the picture.

I presume that there is no program to read the text on the graphical
9vx terminal (which would be required in order to "visualize" rio), so
instead i've made a small addition to the win program that runs inside
'acme' allowing all input and output to be tee-d (logged) to a
separate file somewhere in the plan9 tree. that file can then be then
tail-ed, catted or whatever is needed in order to provide the text of
the acme conversation to a third program.

the changes are rather rude, but i hope they help. here is how to
install them: copy the attached main.c to /acme/bin/source/win (inside
plan9). cd to that directory and run 'mk install' from within 9vx.
then copy the new acme.dump file attached in this email to your home
directory in 9vx (/usr/youruser, it has to be in a home directory
because / is not writeable in 9vx). edit this file. the last line
provides the application to start. the argument to win which we just
added with the new code tells it to dump the conversation to
/usr/andrey/test.txt. change this to point to a file in your home
directory inside 9vx. this is the file which will contain the entire
conversation and update it in real-time. i imagine that whatever
program reads text will be using that file as its source.

start 9vx and acme again inside via "acme -l /path/to/acme.dump" and
it should start in a single-column mode with the new 'win' program
copying its i/o to the file of your choosing.

i admin it's convoluted, but it was a nice exercise in trying to
understand the system from a completely different point of view.

hope it's useful.

andrey

[-- Attachment #2: acme.dump --]
[-- Type: application/octet-stream, Size: 306 bytes --]

/usr/andrey
/lib/font/bit/lucidasans/euro.8.font
/lib/font/bit/lucm/unicode.9.font
          0
e          0           0           0           0           1 
          2          48           2           0           1 /usr/andrey/-vx32 Del Snarf | Look Send Noscroll
/usr/andrey
win -f /usr/andrey/test.txt

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: main.c --]
[-- Type: text/x-csrc; name=main.c, Size: 12767 bytes --]

#include <u.h>
#include <libc.h>
#include <bio.h>
#include <thread.h>
#include <fcall.h>
#include <9p.h>
#include <ctype.h>
#include "dat.h"

void	mainctl(void*);
void	startcmd(char *[], int*);
void	stdout2body(void*);

int	debug;
int	notepg;
int	eraseinput;
int	dirty = 0;
int logfile = -1;

Window *win;		/* the main window */

void
usage(void)
{
	fprint(2, "usage: win [command]\n");
	threadexitsall("usage");
}

void
threadmain(int argc, char *argv[])
{
	int i, j;
	char *dir, *tag, *name;
	char buf[1024], **av, *f;

	quotefmtinstall();
	rfork(RFNAMEG);
	ARGBEGIN{
	case 'd':
		debug = 1;
		chatty9p++;
		break;
	case 'e':
		eraseinput = 1;
		break;
	case 'D':
{extern int _threaddebuglevel;
		_threaddebuglevel = 1<<20;
}
	case 'f':
		f = EARGF(usage);
		logfile=create(f, OWRITE, 0666);
		if(logfile < 0)
			sysfatal("can not open log file %s: %r", f);
	}ARGEND

	if(argc == 0){
		av = emalloc(3*sizeof(char*));
		av[0] = "rc";
		av[1] = "-i";
		name = getenv("sysname");
	}else{
		av = argv;
		name = utfrrune(av[0], '/');
		if(name)
			name++;
		else
			name = av[0];
	}

	if(getwd(buf, sizeof buf) == 0)
		dir = "/";
	else
		dir = buf;
	dir = estrdup(dir);
	tag = estrdup(dir);
	tag = eappend(estrdup(tag), "/-", name);
	win = newwindow();
	snprint(buf, sizeof buf, "%d", win->id);
	putenv("winid", buf);
	winname(win, tag);
	wintagwrite(win, "Send Noscroll", 5+8);
	threadcreate(mainctl, win, STACK);
	mountcons();
	threadcreate(fsloop, nil, STACK);
	startpipe();
	startcmd(av, &notepg);

	strcpy(buf, "win");
	j = 3;
	for(i=0; i<argc && j+1+strlen(argv[i])+1<sizeof buf; i++){
		strcpy(buf+j, " ");
		strcpy(buf+j+1, argv[i]);
		j += 1+strlen(argv[i]);
	}

	ctlprint(win->ctl, "scroll");
	winsetdump(win, dir, buf);
}

int
EQUAL(char *s, char *t)
{
	while(tolower(*s) == tolower(*t++))
		if(*s++ == '\0')
			return 1;
	return 0;
}

int
command(Window *w, char *s)
{
	while(*s==' ' || *s=='\t' || *s=='\n')
		s++;
	if(strcmp(s, "Delete")==0 || strcmp(s, "Del")==0){
		windel(w, 1);
		threadexitsall(nil);
		return 1;
	}
	if(EQUAL(s, "scroll")){
		ctlprint(w->ctl, "scroll\nshow");
		return 1;
	}
	if(EQUAL(s, "noscroll")){
		ctlprint(w->ctl, "noscroll");
		return 1;
	}
	return 0;
}

static long
utfncpy(char *to, char *from, int n)
{
	char *end, *e;

	e = to+n;
	if(to >= e)
		return 0;
	end = memccpy(to, from, '\0', e - to);
	if(end == nil){
		end = e;
		if(end[-1]&0x80){
			if(end-2>=to && (end[-2]&0xE0)==0xC0)
				return end-to;
			if(end-3>=to && (end[-3]&0xF0)==0xE0)
				return end-to;
			while(end>to && (*--end&0xC0)==0x80)
				;
		}
	}else
		end--;
	return end - to;
}

/* sendinput and fsloop run in the same proc (can't interrupt each other). */
static Req *q;
static Req **eq;
static int
__sendinput(Window *w, ulong q0, ulong q1)
{
	char *s, *t;
	int n, nb, eofchar;
	static int partial;
	static char tmp[UTFmax];
	Req *r;
	Rune rune;

	if(!q)
		return 0;

	r = q;
	n = 0;
	if(partial){
	Partial:
		nb = partial;
		if(nb > r->ifcall.count)
			nb = r->ifcall.count;
		memmove(r->ofcall.data, tmp, nb);
		if(nb!=partial)
			memmove(tmp, tmp+nb, partial-nb);
		partial -= nb;
		q = r->aux;
		if(q == nil)
			eq = &q;
		r->aux = nil;
		r->ofcall.count = nb;
		if(debug)
			fprint(2, "satisfy read with partial\n");
		respond(r, nil);
		return n;
	}
	if(q0==q1)
		return 0;
	s = emalloc((q1-q0)*UTFmax+1);
	n = winread(w, q0, q1, s);
	s[n] = '\0';
	t = strpbrk(s, "\n\004");
	if(t == nil){
		free(s);
		return 0;
	}
	r = q;
	eofchar = 0;
	if(*t == '\004'){
		eofchar = 1;
		*t = '\0';
	}else
		*++t = '\0';
	nb = utfncpy((char*)r->ofcall.data, s, r->ifcall.count);
	if(nb==0 && s<t && r->ifcall.count > 0){
		partial = utfncpy(tmp, s, UTFmax);
		assert(partial > 0);
		chartorune(&rune, tmp);
		partial = runelen(rune);
		free(s);
		n = 1;
		goto Partial;
	}
	n = utfnlen(r->ofcall.data, nb);
	if(nb==strlen(s) && eofchar)
		n++;
	r->ofcall.count = nb;
	q = r->aux;
	if(q == nil)
		eq = &q;
	r->aux = nil;
	if(debug)
		fprint(2, "read returns %lud-%lud: %.*q\n", q0, q0+n, n, r->ofcall.data);
	respond(r, nil);
	return n;
}

static int
_sendinput(Window *w, ulong q0, ulong *q1)
{
	char buf[32];
	int n;

	n = __sendinput(w, q0, *q1);
	if(!n || !eraseinput)
		return n;
	/* erase q0 to q0+n */
	sprint(buf, "#%lud,#%lud", q0, q0+n);
	winsetaddr(w, buf, 0);
	write(w->data, buf, 0);
	if(logfile)
		write(logfile, buf, 0);
	*q1 -= n;
	return 0;
}

int
sendinput(Window *w, ulong q0, ulong *q1)
{
	ulong n;
	Req *oq;

	n = 0;
	do {
		oq = q;
		n += _sendinput(w, q0+n, q1);
	} while(q != oq);
	return n;
}

Event esendinput;
void
fsloop(void*)
{
	Fsevent e;
	Req **l, *r;

	eq = &q;
	memset(&esendinput, 0, sizeof esendinput);
	esendinput.c1 = 'C';
	for(;;){
		while(recv(fschan, &e) == -1)
			;
		r = e.r;
		switch(e.type){
		case 'r':
			*eq = r;
			r->aux = nil;
			eq = &r->aux;
			/* call sendinput with hostpt and endpt */
			sendp(win->cevent, &esendinput);
			break;
		case 'f':
			for(l=&q; *l; l=&(*l)->aux){
				if(*l == r->oldreq){
					*l = (*l)->aux;
					if(*l == nil)
						eq = l;
					respond(r->oldreq, "interrupted");
					break;
				}
			}
			respond(r, nil);
			break;
		}
	}
}	

void
sendit(char *s)
{
//	char tmp[32];

	write(win->body, s, strlen(s));
	if(logfile)
		write(logfile, s, strlen(s));
/*
 * RSC: The problem here is that other procs can call sendit,
 * so we lose our single-threadedness if we call sendinput.
 * In fact, we don't even have the right queue memory,
 * I think that we'll get a write event from the body write above,
 * and we can do the sendinput then, from our single thread.
 *
 * I still need to figure out how to test this assertion for
 * programs that use /srv/win*
 *
	winselect(win, "$", 0);
	seek(win->addr, 0UL, 0);
	if(read(win->addr, tmp, 2*12) == 2*12)
		hostpt += sendinput(win, hostpt, atol(tmp), );
 */
}

void
execevent(Window *w, Event *e, int (*command)(Window*, char*))
{
	Event *ea, *e2;
	int n, na, len, needfree;
	char *s, *t;

	ea = nil;
	e2 = nil;
	if(e->flag & 2)
		e2 = recvp(w->cevent);
	if(e->flag & 8){
		ea = recvp(w->cevent);
		na = ea->nb;
		recvp(w->cevent);
	}else
		na = 0;

	needfree = 0;
	s = e->b;
	if(e->nb==0 && (e->flag&2)){
		s = e2->b;
		e->q0 = e2->q0;
		e->q1 = e2->q1;
		e->nb = e2->nb;
	}
	if(e->nb==0 && e->q0<e->q1){
		/* fetch data from window */
		s = emalloc((e->q1-e->q0)*UTFmax+2);
		n = winread(w, e->q0, e->q1, s);
		s[n] = '\0';
		needfree = 1;
	}else 
	if(na){
		t = emalloc(strlen(s)+1+na+2);
		sprint(t, "%s %s", s, ea->b);
		if(needfree)
			free(s);
		s = t;
		needfree = 1;
	}

	/* if it's a known command, do it */
	/* if it's a long message, it can't be for us anyway */
	if(!command(w, s) && s[0]!='\0'){	/* send it as typed text */
		/* if it's a built-in from the tag, send it back */
		if(e->flag & 1)
			fprint(w->event, "%c%c%d %d\n", e->c1, e->c2, e->q0, e->q1);
		else{	/* send text to main window */
			len = strlen(s);
			if(len>0 && s[len-1]!='\n' && s[len-1]!='\004'){
				if(!needfree){
					/* if(needfree), we left room for a newline before */
					t = emalloc(len+2);
					strcpy(t, s);
					s = t;
					needfree = 1;
				}
				s[len++] = '\n';
				s[len] = '\0';
			}
			sendit(s);
		}
	}
	if(needfree)
		free(s);
}

int
hasboundary(Rune *r, int nr)
{
	int i;

	for(i=0; i<nr; i++)
		if(r[i]=='\n' || r[i]=='\004')
			return 1;
	return 0;
}

void
mainctl(void *v)
{
	Window *w;
	Event *e;
	int delta, pendingS, pendingK;
	ulong hostpt, endpt;
	char tmp[32];

	w = v;
	proccreate(wineventproc, w, STACK);

	hostpt = 0;
	endpt = 0;
	winsetaddr(w, "0", 0);
	pendingS = 0;
	pendingK = 0;
	for(;;){
		if(debug)
			fprint(2, "input range %lud-%lud\n", hostpt, endpt);
		e = recvp(w->cevent);
		if(debug)
			fprint(2, "msg: %C %C %d %d %d %d %q\n",
				e->c1 ? e->c1 : ' ', e->c2 ? e->c2 : ' ', e->q0, e->q1, e->flag, e->nb, e->b);
		switch(e->c1){
		default:
		Unknown:
			fprint(2, "unknown message %c%c\n", e->c1, e->c2);
			break;

		case 'C':	/* input needed for /dev/cons */
			if(pendingS)
				pendingK = 1;
			else
				hostpt += sendinput(w, hostpt, &endpt);
			break;

		case 'S':	/* output to stdout */
			sprint(tmp, "#%lud", hostpt);
			winsetaddr(w, tmp, 0);
			write(w->data, e->b, e->nb);
			if(logfile)
				write(logfile, e->b, e->nb);
			pendingS += e->nr;
			break;
	
		case 'E':	/* write to tag or body; body happens due to sendit */
			delta = e->q1-e->q0;
			if(e->c2=='I'){
				endpt += delta;
				if(e->q0 < hostpt)
					hostpt += delta;
				else
					hostpt += sendinput(w, hostpt, &endpt);
				break;
			}
			if(!islower(e->c2))
				fprint(2, "win msg: %C %C %d %d %d %d %q\n",
					e->c1, e->c2, e->q0, e->q1, e->flag, e->nb, e->b);
			break;
	
		case 'F':	/* generated by our actions (specifically case 'S' above) */
			delta = e->q1-e->q0;
			if(e->c2=='D'){
				/* we know about the delete by _sendinput */
				break;
			}
			if(e->c2=='I'){
				pendingS -= e->q1 - e->q0;
				if(pendingS < 0)
					fprint(2, "win: pendingS = %d\n", pendingS);
				if(e->q0 != hostpt)
					fprint(2, "win: insert at %d expected %lud\n", e->q0, hostpt);
				endpt += delta;
				hostpt += delta;
				sendp(writechan, nil);
				if(pendingS == 0 && pendingK){
					pendingK = 0;
					hostpt += sendinput(w, hostpt, &endpt);
				}
				break;
			}
			if(!islower(e->c2))
				fprint(2, "win msg: %C %C %d %d %d %d %q\n",
					e->c1, e->c2, e->q0, e->q1, e->flag, e->nb, e->b);
			break;

		case 'K':
			delta = e->q1-e->q0;
			if(logfile)
				write(logfile, e->b, e->nb);

			switch(e->c2){
			case 'D':
				endpt -= delta;
				if(e->q1 < hostpt)
					hostpt -= delta;
				else if(e->q0 < hostpt)
					hostpt = e->q0;
				break;
			case 'I':
				delta = e->q1 - e->q0;
				endpt += delta;
				if(endpt < e->q1)	/* just in case */
					endpt = e->q1;
				if(e->q0 < hostpt)
					hostpt += delta;
				if(e->nr>0 && e->r[e->nr-1]==0x7F){
					write(notepg, "interrupt", 9);
					hostpt = endpt;
					break;
				}
				if(e->q0 >= hostpt
				&& hasboundary(e->r, e->nr)){
					/*
					 * If we are between the S message (which
					 * we processed by inserting text in the
					 * window) and the F message notifying us
					 * that the text has been inserted, then our
					 * impression of the hostpt and acme's
					 * may be different.  This could be seen if you
					 * hit enter a bunch of times in a con
					 * session.  To work around the unreliability,
					 * only send input if we don't have an S pending.
					 * The same race occurs between when a character
					 * is typed and when we get notice of it, but
					 * since characters tend to be typed at the end
					 * of the buffer, we don't run into it.  There's
					 * no workaround possible for this typing race,
					 * since we can't tell when the user has typed
					 * something but we just haven't been notified.
					 */
					if(pendingS)
						pendingK = 1;
					else
						hostpt += sendinput(w, hostpt, &endpt);
				}
				break;
			}
			break;
	
		case 'M':	/* mouse */
			delta = e->q1-e->q0;
			switch(e->c2){
			case 'x':
			case 'X':
				execevent(w, e, command);
				break;
	
			case 'l':	/* reflect all searches back to acme */
			case 'L':
				if(e->flag & 2)
					recvp(w->cevent);
				winwriteevent(w, e);
				break;
	
			case 'I':
				endpt += delta;
				if(e->q0 < hostpt)
					hostpt += delta;
				else
					hostpt += sendinput(w, hostpt, &endpt);
				break;

			case 'D':
				endpt -= delta;
				if(e->q1 < hostpt)
					hostpt -= delta;
				else if(e->q0 < hostpt)
					hostpt = e->q0;
				break;
			case 'd':	/* modify away; we don't care */
			case 'i':
				break;
	
			default:
				goto Unknown;
			}
		}
	}
}

enum
{
	NARGS		= 100,
	NARGCHAR	= 8*1024,
	EXECSTACK 	= STACK+(NARGS+1)*sizeof(char*)+NARGCHAR
};

struct Exec
{
	char		**argv;
	Channel	*cpid;
};

int
lookinbin(char *s)
{
	if(s[0] == '/')
		return 0;
	if(s[0]=='.' && s[1]=='/')
		return 0;
	if(s[0]=='.' && s[1]=='.' && s[2]=='/')
		return 0;
	return 1;
}

/* adapted from mail.  not entirely free of details from that environment */
void
execproc(void *v)
{
	struct Exec *e;
	char *cmd, **av;
	Channel *cpid;

	e = v;
	rfork(RFCFDG|RFNOTEG);
	av = e->argv;
	close(0);
	open("/dev/cons", OREAD);
	close(1);
	open("/dev/cons", OWRITE);
	dup(1, 2);
	cpid = e->cpid;
	free(e);
	procexec(cpid, av[0], av);
	if(lookinbin(av[0])){
		cmd = estrstrdup("/bin/", av[0]);
		procexec(cpid, cmd, av);
	}
	error("can't exec %s: %r", av[0]);
}

void
startcmd(char *argv[], int *notepg)
{
	struct Exec *e;
	Channel *cpid;
	char buf[64];
	int pid;

	e = emalloc(sizeof(struct Exec));
	e->argv = argv;
	cpid = chancreate(sizeof(ulong), 0);
	e->cpid = cpid;
	sprint(buf, "/mnt/wsys/%d", win->id);
	bind(buf, "/dev/acme", MREPL);
	proccreate(execproc, e, EXECSTACK);
	do
		pid = recvul(cpid);
	while(pid == -1);
	sprint(buf, "/proc/%d/notepg", pid);
	*notepg = open(buf, OWRITE);
}

Re: [9fans] success with 9vx from a terminal

[erik quanstrom]

> you have to type 'scroll' and middle-click it with the mouse (is there
> a way to issue this as a command from the terminal, anybody?). also,

one would think that
	; echo noscroll>/dev/wctl
would work, but it does not.

- erik

Re: [9fans] success with 9vx from a terminal

[andrey mirtchovski]

I was playing around with the modified "win" program and I realized
it's not going to work due to the propensity of acme to redirect
standard error to a separate window. This environment has no way of
notifying anyone that a new window has opened without being requested
except visually.

A better solution would be to display only a single, border-less
terminal window filling the entire screen. Perhaps even multiplexing
between a few full-screen terminal windows similar to the ttys
available on a *bsd or linux console.

Sorry for the noise.

Re: [9fans] success with 9vx from a terminal

[Roman V. Shaposhnik]

On Wed, 2008-10-22 at 10:54 -0600, andrey mirtchovski wrote:
> > This has one or two complications.  There is no way to interrupt or kill
> > the foreground process.  Instead, ctrl-c interrupts 9vx itself.
>
> chris,
>
> one of the nice things about the Plan 9 graphics system is that rio is
> in no way different than any other graphical program. it reads and
> writes files in /dev/wsys and multiplexes them between other
> applications. in that sense, you don't need to run rio in order to run
> a graphical app. from the 9vx console you can just type 'acme' and
> you'll have acme running in full-screen mode. if you know what you
> desire in a window manager (perhaps a terminal window in a static
> location to which you can always return, or keyboard-driven window
> switching) one can be written so that it's used instead of rio.
> graphical programs in plan9 are not hard.
>
> in the mean time you wan use acme's terminal (the program is called
> 'win') to gain a more feature-full environment.

Everything up until this point made total sense to me. But now, that
you've brought acme into discussion -- I'm confused. Granted, I happen
to NOT be an acme user myself so may be that's why I see nothing that
it brings to the table in this particular situation. The previous
suggestion was around rio which, at face value was more than reasonable
especially if one considers rio's desire to stay explicitly out of the
way as far as drawing surfaces multiplexing is concerned:
 From rio(4):
  "Note that the draw(3) device multiplexes itself; rio places windows
   but does not mediate programs' access to the display device."
It seems that all we need from rio(4) in a tty-only scenario is its
ability to multiplex /dev/cons in a way that also interprets particular
sequences of bytes (like Ctrl-C, Ctrl-D, and may be even escape
sequences) and translates those into actions: sending a note to a
process, creating a new window, etc. It almost sounds exactly like
what screen(1) is doing for UNIX ttys. It probably will require
some changes to the existing code for rio. That's what I would call an
internal multiplexing: 9vx is running with its stdin, stdout and
stderr attached to a tty and that's what gets served as '#c/cons'. The
only process that accesses it is rio. The rest of the Plan 9 processes
see /dev/cons served by rio. So far so good, except that 9vx *already*
seems to interpret things like Ctrl-D:
   linux-box$ ./9vx.Linux -g -u glenda
   init: starting /bin/rc
   upas/fs: '/bin/upas/fs' does not exist
   #m/mousectl: rc: can't open: jmk added reentrancy for threads
   init: rc exit status: rc 5: error

   init: starting /bin/rc
   % cat
   \x04%
It looks like when I pressed Ctrl-D that got interpreted as an EOF
coming from '#c/cons' right? In that same spirit, interpreting DEL
as a character that triggers a note to be sent should also be quite
doable within the #c driver. The only question is -- where such a note
is supposed to be sent to?

Can someone, please, educate me on the moral equivalent of process
groups, sessions and their relationships with #c/cons ?

Thanks,
Roman.

Re: [9fans] success with 9vx from a terminal

[sqweek]

On Thu, Oct 23, 2008 at 8:43 AM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> The only question is -- where such a note
> is supposed to be sent to?
>
> Can someone, please, educate me on the moral equivalent of process
> groups, sessions and their relationships with #c/cons ?

 Maybe you worked this one out already, but It depends on how they
were forked. I don't think I can explain it better than rfork(2) - the
bit about RFNOTEG is particularly relevant. I'm not aware of any
relationship between #c/cons and notes, but I'm not really sure what
magic is involved in the DEL interrupt.
-sqweek

Re: [9fans] success with 9vx from a terminal

[Charles Forsyth]

>I'm not really sure what magic is involved in the DEL interrupt.

rio (or ip/telnetd, or ... some other user program).

Re: [9fans] success with 9vx from a terminal

[Roman V. Shaposhnik]

On Mon, 2008-11-10 at 01:55 +0900, sqweek wrote:
> On Thu, Oct 23, 2008 at 8:43 AM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> > The only question is -- where such a note
> > is supposed to be sent to?
> >
> > Can someone, please, educate me on the moral equivalent of process
> > groups, sessions and their relationships with #c/cons ?
>
>  Maybe you worked this one out already,

Well, sort of -- yes. But thanks for chiming in anyway.

> I'm not aware of any relationship between #c/cons and notes,
> but I'm not really sure what magic is involved in the DEL interrupt.

At least in case of cpu(1) the magic is a bit perverse and quite
unlike the rest of the system. The way notes are managed make
a local end of a cpu(1) jump through considerable hoops in order
for the notes to be properly delivered. That was a sad discovery.

Another discovery was that devcons.c could have made DEL work
but decided not to :-(

Thanks,
Roman.

Re: [9fans] success with 9vx from a terminal

[ron minnich]

On Mon, Nov 10, 2008 at 2:24 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:

> At least in case of cpu(1) the magic is a bit perverse and quite
> unlike the rest of the system. The way notes are managed make
> a local end of a cpu(1) jump through considerable hoops in order
> for the notes to be properly delivered. That was a sad discovery.


CPU is really worth reading and understanding. It uses a lot of neat
tricks. Recommended.

ron

Re: [9fans] success with 9vx from a terminal

[Roman V. Shaposhnik]

On Mon, 2008-11-10 at 14:49 -0800, ron minnich wrote:
> On Mon, Nov 10, 2008 at 2:24 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
>
> > At least in case of cpu(1) the magic is a bit perverse and quite
> > unlike the rest of the system. The way notes are managed make
> > a local end of a cpu(1) jump through considerable hoops in order
> > for the notes to be properly delivered. That was a sad discovery.
>
>
> CPU is really worth reading and understanding.

100% agreed. But...

>  It uses a lot of neat tricks.

... would you really honestly say that rolling out your
own notes forwarder is a *neat* trick? As opposed to
be able to use basic system's FS functionality?

This not a jab at cpu(1) rather at the design of notes.
My personal feeling when going over that bit was: well,
that's how UNIX people do signal forwarding (we do
something similar for the remote debugging sessions)
am I reading the right source file?!?!

Thanks,
Roman.

Re: [9fans] success with 9vx from a terminal

[ron minnich]

cpu is just great tutorial.

notes forwarder, well, I am stil unsure.

ron

Re: [9fans] success with 9vx from a terminal

[andrey mirtchovski]

> ... would you really honestly say that rolling out your
> own notes forwarder is a *neat* trick? As opposed to
> be able to use basic system's FS functionality?

ok, how would you implement it, then? how would you deliver a note to
a process that's running on a remote machine? would you be introducing
"distributed" notes in which you can specify a target machine as well
as a target process? with special agents on the local host which can
"dial" the remote machine to send it the note, and kernel daemon note
forwarders which can accept notes from remote machines destined for
local processes and... and..

you run up the list of necessary (and required) services as quickly as
portmap, rpc.idmapd and friends from nfs-land :)

rmnoteproc() as implemented in cpu.c is just about the simplest way to
do such a thing. it only requires one thing: the remote tree mounted
in /mnt/term (which really is the clever bit). unfortunately we've
been dealing with complexity in the non-plan9 world for so long that
we are unable to appreciate anything unless it requires a huge deal of
effort to comprehend :)

Re: [9fans] success with 9vx from a terminal

[Roman V. Shaposhnik]

On Mon, 2008-11-10 at 16:42 -0700, andrey mirtchovski wrote:
> > ... would you really honestly say that rolling out your
> > own notes forwarder is a *neat* trick? As opposed to
> > be able to use basic system's FS functionality?
>
> ok, how would you implement it, then? how would you deliver a note to
> a process that's running on a remote machine?

I would like to be able to import the /proc (or similar) filesystem from
the remote machine and bind it over the files that my local kernel uses
to send notes to the proxy process. That's how my "ideal world" model
would work. Observe how that was also the first suggestion on the "notes
thief" thread. Do you think it is a coincidence?

> would you be introducing "distributed" notes in which you can specify a
> target machine as well as a target process?

Of course not! But I still would like *not* to be forced to invent
a covert channel for things that really seem to belong to a devproc.c.

Look, seriously, when cpu(1) is run inside a rio window the only reason
it has to jump through these hoops is because rio sends notes using a
notepg file located in a completely unrelated subdirectory in /proc.

I'm not saying I know of a better way as of right now, all I'm saying
is that notes and how the group of processes is handled by the Plan9
kernel feels much less elegant than the rest of the system.

> rmnoteproc() as implemented in cpu.c is just about the simplest way to
> do such a thing.

Given the constraints that I now understand notes require -- yes. But,
honestly, don't you feel weird that /dev/cons gets proxied by a simple
bind operation and notes are *the only* part of the system that need
special handling?

> it only requires one thing: the remote tree mounted in /mnt/term (which really
>  is the clever bit).

Well it is the kind of cleverness that 9fans tend to dislike in other
systems.

Thanks,
Roman.

Re: [9fans] success with 9vx from a terminal

[andrey mirtchovski]

> I would like to be able to import the /proc (or similar) filesystem from
> the remote machine and bind it over the files that my local kernel uses
> to send notes to the proxy process. That's how my "ideal world" model
> would work. Observe how that was also the first suggestion on the "notes
> thief" thread. Do you think it is a coincidence?

if /proc is your only concern ask Jim or somebody else at BL to
release the description of the original (plan9-only) cut of XCPU by
Vic Zandy. I can't find my copy of it anymore and I don't remember if
that information was releasable or not, but in short it was a modified
p9 kernel that allowed you to start and control processes on multiple
cpu servers at the same time.

I don't remember if the solution for note sending across machines was
novel. I seem to remember that in this case processes were addressed
by node/pid.

Re: [9fans] success with 9vx from a terminal

[ron minnich]

On Mon, Nov 10, 2008 at 5:04 PM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:

> I don't remember if the solution for note sending across machines was
> novel. I seem to remember that in this case processes were addressed
> by node/pid.
>
>

I've got it somewhere, will rummage around.

ron

Re: [9fans] success with 9vx from a terminal

[erik quanstrom]

> At least in case of cpu(1) the magic is a bit perverse and quite
> unlike the rest of the system. The way notes are managed make
> a local end of a cpu(1) jump through considerable hoops in order
> for the notes to be properly delivered. That was a sad discovery.
>
> Another discovery was that devcons.c could have made DEL work
> but decided not to :-(

talking about it is the easy part.  why don't you code something up?

- erik

Re: [9fans] success with 9vx from a terminal

[Roman Shaposhnik]

On Nov 10, 2008, at 3:27 PM, erik quanstrom wrote:
>> At least in case of cpu(1) the magic is a bit perverse and quite
>> unlike the rest of the system. The way notes are managed make
>> a local end of a cpu(1) jump through considerable hoops in order
>> for the notes to be properly delivered. That was a sad discovery.
>>
>> Another discovery was that devcons.c could have made DEL work
>> but decided not to :-(
>
> talking about it is the easy part.  why don't you code something up?


Good question. I guess the easiest way to explain would be that
I am not actually using Plan9 for anything as a standalone system,
but rather as a source of inspiration (yeah, may be it is lame to say
something like that -- but here I'm saying it anyway). Everytime I
have to implement something for Solaris/Linux I usually take
a look (unless I remember) at how similar things were handled
by Plan9. Most of the things I've looked at are true gems in terms of
ideas and coding. Really, really elegant stuff.

A small number of things, however, make me go "Huh?". Which is,
usually, a sign of me not being smart enough to instantly recognize
the constraints these things are dealing with. But how am I to know
for certain that they are not the rarest case of an oversight?

One way would be, as you suggested, to start hacking things up
and coming up with better solution. I suspect that in 90% of the
cases I would end up fully appreciating why it was coded the
way it was. That would be the .u way ;-) Very rewarding, but also
quite time consuming.

Another way (which I try NOT to abuse) is to talk about it here.
In the hopes that even if I'm making a total fool out of myself there
will be somebody idle enough to quickly enlighten me.

Does that sound fair to you?

Thanks,
Roman.

P.S. I would love to have any project related to Plan9/Inferno proper
as my day job, but right now I'm reduced to UNIX and 9P
at best :-(

Re: [9fans] success with 9vx from a terminal

[gdiaz]

Hello,

Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X.

gabi


-- cmbrannon@cox.net wrote:
>
>Last night I downloaded 9vx. It works fine from a terminal, using
>the following invocation:
>../9vx.Linux -g -u glenda
>where -g is the option to run sans GUI.
>This has one or two complications. There is no way to interrupt or kill
>the foreground process. Instead, ctrl-c interrupts 9vx itself.
>Anyway, I managed to get an emulated Plan 9 system up and running.
>Both ed and "sam -d" work well for editing text.
>
>-- Chris
>
>

Re: [9fans] success with 9vx from a terminal

[Christian Kellermann]

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

* gdiaz@9grid.es <gdiaz@9grid.es> [081022 11:16]:
> Hello,
> 
> Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X.

Why not write a simple 'shell' shell (heh) that cooks input and just runs rc? Then you would have the del key and others again.

Cheers,

Christian

-- 
You may use my gpg key for replies:
pub  1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

[-- Attachment #2: Type: application/pgp-signature, Size: 202 bytes --]

Re: [9fans] success with 9vx from a terminal

[erik quanstrom]

> * gdiaz@9grid.es <gdiaz@9grid.es> [081022 11:16]:
> > Hello,
> >
> > Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X.
>
> Why not write a simple 'shell' shell (heh) that cooks input and just runs rc? Then you would have the del key and others again.

you mean like, uh, rio or acme? ☺

- erik

Re: [9fans] success with 9vx from a terminal

[roger peppe]

On Wed, Oct 22, 2008 at 12:42 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> you mean like, uh, rio or acme? ☺

i can't see why it would be a bad idea to do something like
this for text-only mode. it'd be a nice exercise, if nothing else.
it should be possible to do without writing a file server, too,
which is always a bonus.

there's one thing: i think you'd need either to use a different key
for interrupt,
or have a wrapper outside of 9vx to prevent the usual key for interrupt
just killing 9vx as usual.

Re: [9fans] success with 9vx from a terminal

[john]

>> * gdiaz@9grid.es <gdiaz@9grid.es> [081022 11:16]:
>> > Hello,
>> >
>> > Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X.
>>
>> Why not write a simple 'shell' shell (heh) that cooks input and just runs rc? Then you would have the del key and others again.
>
> you mean like, uh, rio or acme? ☺
>
> - erik

This whole "Writing anything new is a terrible idea!" attitude is
getting old.  Why does acme exist?  Thank god you weren't around the
Unix Room when that got started, or you would have just said, "Isn't
sam good enough for you?" If somebody feels the need for a functional
text-mode interface, he should write it.  I've felt a need for such a
thing myself while fiddling with kernels that don't have video
support.  Believe it or not, there *is* room in Plan 9 for additions
and improvements.



John "Denial ain't just a river" Floren

Re: [9fans] success with 9vx from a terminal

[erik quanstrom]

> >> > Hello,
> >> >
> >> > Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X.
> >>
> >> Why not write a simple 'shell' shell (heh) that cooks input and just runs rc? Then you would have the del key and others again.
> >
> > you mean like, uh, rio or acme? ☺
> >
> > - erik
>
> This whole "Writing anything new is a terrible idea!" attitude is
> getting old.  Why does acme exist?  Thank god you weren't around the
> Unix Room when that got started, or you would have just said, "Isn't
> sam good enough for you?" If somebody feels the need for a functional
> text-mode interface, he should write it.  I've felt a need for such a
> thing myself while fiddling with kernels that don't have video
> support.  Believe it or not, there *is* room in Plan 9 for additions
> and improvements.

i thought "☺" was the international symbol for tongue-in-cheek.
could you please let me know what the iso approved symbol is?

by the way, in case you haven't noticed, i have contributed a number
of new things.  not all of them are worth incorporating.  i would hope
that standards for plan 9 remain high and we don't just shovel everything
in.

rio does provide most everything one would need for a "text-mode"
interface.  unfortunately, you can't currently "tail -f" /dev/text.  perhaps
such a change would be easier and more general than writing something
completely seperate?

- erik

Re: [9fans] success with 9vx from a terminal

[Roman V. Shaposhnik]

On Wed, 2008-10-22 at 12:28 -0400, erik quanstrom wrote:
> rio does provide most everything one would need for a "text-mode"
> interface.  unfortunately, you can't currently "tail -f" /dev/text.  perhaps
> such a change would be easier and more general

That's a very good point! It hadn't occurred to me either, but now
that you've mentioned it -- makes total sense. I have the same issue
with browsers on UNIX -- why is Firefox not capable of rendering
on non-X11 surfaces? Why do I have to use a separate thing called
lynx?

Thanks,
Roman.

Re: [9fans] success with 9vx from a terminal

[Christian Kellermann]

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

* erik quanstrom <quanstro@quanstro.net> [081022 13:51]:
> > * gdiaz@9grid.es <gdiaz@9grid.es> [081022 11:16]:
> > > Hello,
> > > 
> > > Rio is the responsible for killing a process using the Del key, AFAIK there is no way to terminate a program running in console. May be with some magic combination of the keys ctrl-t ctrl-t X.
> > 
> > Why not write a simple 'shell' shell (heh) that cooks input and just runs rc? Then you would have the del key and others again.
> 
> you mean like, uh, rio or acme? ???

Yes, the requirements have been laid out as non graphical, so acme and rio are out...
-- 
You may use my gpg key for replies:
pub  1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

[-- Attachment #2: Type: application/pgp-signature, Size: 202 bytes --]