> 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

> 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

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.

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

On Thu, Oct 23, 2008 at 8:43 AM, Roman V. Shaposhnik 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

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

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

On Mon, 2008-11-10 at 01:55 +0900, sqweek wrote:
> On Thu, Oct 23, 2008 at 8:43 AM, Roman V. Shaposhnik 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.

On Mon, Nov 10, 2008 at 2:24 PM, Roman V. Shaposhnik 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

On Mon, 2008-11-10 at 14:49 -0800, ron minnich wrote:
> On Mon, Nov 10, 2008 at 2:24 PM, Roman V. Shaposhnik 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.

cpu is just great tutorial.

notes forwarder, well, I am stil unsure.

ron

> 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

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

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.

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

On Mon, Nov 10, 2008 at 5:04 PM, andrey mirtchovski
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