Re: [9fans] X on Plan 9

Re: [9fans] X on Plan 9

[anothy]

//i added 'look' to it, but rob said it made
//the button 2 menu too long.

oo! i've been thinking about giving that a shot in rio. while i can
certainly understand the "keep the menu short" argument, i'd be all
to happy to dump cut, paste, and snarf from my button 2 menu (i use
chording exclusively for that). don't suppose you've given that
change a shot in rio already?

i agree the various chat protocols arn't well documented (and what
documentation there is doesn't often match reality). i'd looked at
just doing my own version for Plan 9, but got quite frustrate with
that fact very quickly. even napster's client had a better defined
protocol - i took a first pass at that, and had something that at
least headed in the right direction.

9wm and 9term are a poor substitute for rio, yes, but i like them
much more than [ftm]*wm and xterm, for example. and they're a lot
closer to their targets than wily is to its.

ideally, i'd get another machine to run Unix locally, and run these
apps on that. but cash is tight right now. dual-booting isn't an
acceptable option as it means taking down Plan 9, where i do the
overwhelming majority of my work/play.
-α.

Re: [9fans] X on Plan 9

[Scott Schwartz]

How about running Plan 9 under vmware?

Re: [9fans] X on Plan 9

[Boyd Roberts]

X: It Takes A Nation Of Millions To Code That Up

with apologies to Public Enemy [... Hold Us Back]:

    http://www.public-enemy.com

Re: [9fans] X on Plan 9

[Boyd Roberts]

> How about running Plan 9 under vmware?

nah, re-implement it in bash.

Re: [9fans] X on Plan 9

[Dan Cross]

In article <20010419221448.19982.qmail@g.bio.cse.psu.edu> you write:
>How about running Plan 9 under vmware?

I don't think it works currently.

	- Dan C.

Re: [9fans] X on Plan 9

[David Rubin]

anothy@cosym.net wrote:
>
> //i added 'look' to it, but rob said it made
> //the button 2 menu too long.
>
> oo! i've been thinking about giving that a shot in rio. while i can
> certainly understand the "keep the menu short" argument, i'd be all
> to happy to dump cut, paste, and snarf from my button 2 menu (i use
> chording exclusively for that). don't suppose you've given that
> change a shot in rio already?

Sorry, but what's "look?" BTW, Boyd, I've been using 9term on Linux for ~6
months now, and it's been good to me.
I did try to add chording to it which was a varied success. I got very very
close, but not quite there. I still have to jiggle the mouse a little to create
a "paste" event if I cut/paste in place. I gave up at that point.


> 9wm and 9term are a poor substitute for rio, yes, but i like them
> much more than [ftm]*wm and xterm, for example. and they're a lot
> closer to their targets than wily is to its.

That's for sure. Sam on Linux (at least) is a lot better than Wily too, mostly
because wily takes ages to search a file loaded over the network. Sam is very
quick in this regard. I do wish there was chording in Sam, but I respect rob's
comment (earlier) that it was hard to integrate into Sam's split architecture.

> ideally, i'd get another machine to run Unix locally, and run these
> apps on that. but cash is tight right now. dual-booting isn't an
> acceptable option as it means taking down Plan 9, where i do the
> overwhelming majority of my work/play.

This just means we have to write more and more usable applications for plan9. No
surprise.

	david

--
FORTRAN was the language of choice
for the same reason that three-legged races are popular.
	-- Ken Thompson, "Reflections on Trusting Trust"

Re: [9fans] X on Plan 9

[Boyd Roberts]

From: "David Rubin" <dlrubin@hotmail.com>
>
> Sorry, but what's "look?" BTW, Boyd, I've been using 9term on Linux for ~6
> months now, and it's been good to me.

just like 'look' in sam.

that code, if it still exists, was written in 1992.
it belonged to Digital and if it still exists somewhere
[at SRC?] it belongs to Compaq.  i could have released
it then, if i wanted to spend weeks getting approval,
and i have no chance of releasing it now.

look is an hour's work.

Re: [9fans] X on Plan 9

[rob pike]

The paper people are referring to was written in 1989 and
was a step on the path to 8½ and rio.

	A Concurrent Window System
	    Rob Pike
	    Computing Systems, Spring 1989
	    Vol 2 #2, pp 133-153
	    http://plan9.bell-labs.com/cm/cs/doc/89/1-a.ps.gz

-rob

Re: [9fans] X on Plan 9

[okamoto]

>I am confused on this issue. Plan9 generally makes claims along the lines of
>"easier to reason about..." and "[cleaner/simpler] programming style"

If you are serious, you can read many papers comming with Plan 9 distribution,
I suppose.   On the event-driven issue, I think there is a Rob's paper in his
web page (sorry, I looked around my computer, but I have only printed one now).
The point is how we can make it real, not rather than whether we can do or not.
If the programming style to practice it is simpler, we will get many goods from it.
I think this was said here by Rob before...

Kenji

Re: [9fans] X on Plan 9

[Scott Schwartz]

| On the event-driven issue, I think there is a Rob's paper in his
| web page (sorry, I looked around my computer, but I have only printed one now).

One of the nice features of Alef, Limbo, Erlang, etc, is that you get
nice syntax for concurrency, in addition to nice semantics.  That can't
help but be significant, I think.

Re: [9fans] X on Plan 9

[Douglas A. Gwyn]

> >I am confused on this issue. Plan9 generally makes claims along the lines of
> >"easier to reason about..." and "[cleaner/simpler] programming style"
okamoto@granite.cias.osakafu-u.ac.jp wrote:
> If you are serious, you can read many papers comming with Plan 9 distribution,

Or some of the classic papers in computer science, such as Hoare's
"Communicating Sequential Processes".

Re: [9fans] X on Plan 9

[forsyth]

>>What do you mean by "non event-driven?"

i supposed he meant `not using callbacks' (ie, quasi-interrupts on each
event) to drive the computation, but instead using communicating
sequential processes to express the interaction of computer and
events in the environment, allowing the use
of a more reasonable programming style (in the sense that you can
reason about them and the effects on data structures and values).
i've found callback-based programs typically shrink when converted, but i
suppose that's not necessarily true.

Re: [9fans] X on Plan 9

[David Rubin]

forsyth@vitanuova.com wrote:
>
> >>What do you mean by "non event-driven?"
>
> i supposed he meant `not using callbacks' (ie, quasi-interrupts on each
> event) to drive the computation, but instead using communicating
> sequential processes to express the interaction of computer and
> events in the environment, allowing the use
> of a more reasonable programming style (in the sense that you can
> reason about them and the effects on data structures and values).
> i've found callback-based programs typically shrink when converted, but i
> suppose that's not necessarily true.

So basically the claim is that reading a ctl or data channel for "events" or
commands is better than reading events from an event queue because in the "non
event-driven" method the OS does is not as involved since it does not have to
generate and post events?

I am confused on this issue. Plan9 generally makes claims along the lines of
"easier to reason about..." and "[cleaner/simpler] programming style" to support
its approach to distributed communication. Can you give a little more detail
about why this is so?

For example, I am programming in a VxWorks environment now, and we have
communicating tasks which post events to each other. The events might signal
various timeouts or "enqueued data" events. In the case of an "enqueued data"
event, the receiving task then reads a message from a queue. This is basically
my impression of how an event-driven gui would work as well. How would a
non-event driven model of inter-task communication make such programs simpler to
write and easier to reason about?

Please correct me if I am mixing terms...Thanks.

	david

--
If 91 were prime, it would be a counterexample to your conjecture.
    -- Bruce Wheeler

Re: [9fans] X on Plan 9

[Boyd Roberts]

event driven programming is fraught with peril;  you have to
maintain state and interpret/modify it based on events that
arrive at some of the worst possible times.

eg. winsock 1 would sometimes send you write true messages
    before connect true.  so you'd add all these extra 'states'
    to your switch statement.  some winsock apps would loop
    on write true rather than connect true.  <despair>

    #define makestate(s, e)    ((long)((s) << 16 | (e)))

    saves you from '14 page switch statements'.

kernel hacks are a bit thin on the ground now, and the kernel
is one of the worst things to debug.  the number of vax la-120
stack backtraces and adb's on the kernel crash dumps i've analysed
is more than i'd like to remember.

the 11/780 had an interesting property; the first 64Kb of
ram was zeroed on boot.  this was all very fine until the
text pushed the reiser? written bitmap of free pages above
the first 64kb.  the bitmap was never zeroed and you'd get
dup frees and all sorts of horrible stuff.

that was hard.  two weeks of crash dump analysis and all nighters
to fix it.  finally, movc5 city on some weird area mapped by the SPT.

motto: keep the kernel small and make it possible to do all the
       'kernel' stuff in user mode.

a crash can leave you with virtually nothing; smashed file-systems,
pissed off users, backup scrambles -- ouch.  one of the reasons i had a
bottle of [kernel hacker's] jack daniels on top of my viewpoint vp90
terminal.  take a slug, wander the corridors [with bottle] and think
about the problem.

--
Boyd Roberts                                          boyd@planete.net

  [trouble] seems to know pretty much where I am, most of the time.

    -- Riggs

Re: [9fans] X on Plan 9

[geoff.9fans]

Russ's Palm file servers are definitely preferable to what I've got.
I ported the pilot-xfer stuff (v0.9.3 or 0.9.4) using APE but it
was flakey due to the use of alarm signals to implement protocol time-outs
and possibly due to problems in APE (e.g., select() poisons fds so
that they can't be dupped).  I then ported it to native Plan 9,
cleaning it up in the process.  I think I'd deleted over 35% of the
source by line count when I last looked but more code deserves to be
deleted; there was silly stuff like an emulation of BSD sockets in it.

There are a few remaining embarrassments: my protocol time-out code
consumes processes at a rate that seems excessive to me, and there
remains a window in which a full packet may have been read and yet
it will be discarded if a time-out occurs; the thoughput on the serial
line is lower than seems reasonable, though I haven't compared it with
the Windows Palm desktop hot sync; and the program leaves processes
behind when it exits, which inteferes with later uses of the program.
This last looks like some form of memory corruption that I fear was
in the code when I got it.  I haven't had much time to spend on this
lately; the obvious next step is to try the various debugging hooks
in malloc.

So what I have works, for small values of ``work''.  It's sufficient
for dumping and restoring Palm files (``databases''), so I no longer
need to use Windows nor Linux for those tasks, and that's gratifying.

Re: [9fans] X on Plan 9

[forsyth]

>>One app I use vnc for these days is xfig.
>>For me it's easier to draw figures using the mouse
>>than it is using a language.

yes, i find drawing programs to be useful time-savers.
after spending a good while trying to draw things
using the mouse i typically realise that what i'm doing is
much more efficiently automated by a language,
at which point i get my work done with time to spare.
not enough time, but that's a different problem.

Re: [9fans] X on Plan 9

[nemo]

One app I use vnc for these days is xfig.
For me it's easier to draw figures using the mouse
than it is using a language.

But I prefer to get one done following the design guidelines
of Plan 9 than get a port done. One of my students is
implementing a `kind of xfig' that reads commands from
stdin and mix that w/ mouse events to let you draw stuff.
It will probably write figures to disk using pic.

Re: [9fans] X on Plan 9

[anothy]

//geoff collyer ported the unix tools for palm...

yes, i've seen them, but to the best of my knowledge (and i
could well be wrong here, and would be happy to find i am),
that doesn't allow for importing and exporting to arbitrary
text files. as near as i can tell, that still involves some
sort of "conduit" into some host app like Outlook™.

i saw the tools you'd been working on, and they looked quite
promising. i think that would be my prefered option here.
i'd be interested in helping improve that.

i'd also used your icq client (and helped fix a bug with
status reporting or something), but - much to my dismay - the
most popular one of these clients among my target audience is
AIM. for that, last i checked only one of their two protocols
was published, and they were phasing out support for that, as
well as engaging in various other checks to inhibit 3rd party
clients from connecting.
-α.

Re: [9fans] X on Plan 9

[anothy]

//How about running Plan 9 under vmware?

questions about whether that currently _works_ or not
aside, that seems kinda backwards. what i care most
about is Plan 9 - that's what i enjoy using, that's
what i find most productive, that's the environment i
want to code and design for. it seems silly to put it
under emulation (as good as vmware may be, i refuse
to believe it's as good as raw hardware) under
something else i see as an "extra".
-α.

Re: [9fans] X on Plan 9

[Russ Cox]

geoff collyer ported the unix tools for palm communication.
perhaps he'll pipe up about posting them.

i have a native set (that presents the whole thing as a file
system) that has serial communication and database
manipulation dead on but i got into trouble keeping various
views of the data consistent when one changed.  i know
how to do it, just haven't finished it.

similarly, i have a messaging-only icq client i wrote
three years ago.  i have enough documentation about
the icq spec, and the aim spec is public anyway.  i think
it would be a great demonstration of the plan 9 approach
to tool building to make an underlying file server and
then build an acme interface (and perhaps others, like
a text one) on top of that.

if anyone wants to hack on either of these i'd be happy
to give them out, lend advice, etc.  i just don't have time
to write side programs anymore.  i'm hopeful that will change
a little in the fall, as i'm finishing many long-running (multiple
year) projects this spring.

russ

Re: [9fans] X on Plan 9

[okamoto]

>what are those applications?  just curious.

In my case, those are ISIS, GRASS etc.

Kenji

Re: [9fans] X on Plan 9

[forsyth]

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

>>	Palm emulator
>>at least until i figure out how to import/export from/to
>>regular text files. painful remotely, since i have to dump
>>the Palm's memory, move it over my slow modem, use vnc over
>>that same slow modem to use the (slow) emulator, and move
>>stuff back.

i have got something but i haven't completely converted it back from Alef yet.
i need it soon to sync my wife's replacement handspring.


[-- Attachment #2: Type: message/rfc822, Size: 2854 bytes --]

From: anothy@cosym.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] X on Plan 9
Date: Thu, 19 Apr 2001 15:03:58 -0400
Message-ID: <20010419190406.44567199E3@mail.cse.psu.edu>

okay, here goes: X apps i care about, and breifly why:
	Netscape
no, i don't plan on porting this locally, but i find Charon
to be great for ~95% of the web pages i look at. one notable
exception is my bank; when i need to get there, i use vnc.
	Everybuddy
an ICQ/AIM/etc. client. i know it's juvenile, but i work
with high school kids alot, and this is huge with them. i'd
been using this via vnc.
	Palm emulator
at least until i figure out how to import/export from/to
regular text files. painful remotely, since i have to dump
the Palm's memory, move it over my slow modem, use vnc over
that same slow modem to use the (slow) emulator, and move
stuff back.
	xpic
which, incidently, i've already seen ported to Plan 9. i'd
been using this via vnc (but not much).
	xv
only because most of (all?) the tools in 2nd edition's 9.1
are missing in 3rd edition. i've been using this via vnc.
	some mp3 player
which was just a wrapper to mpg123, which's already been
ported. this was why, a while ago, i asked about the Labs
folk releasing their audio players, even without the PAC
bits - it'd be easy enough to plug mpg123 into them. and i
really like agui. i've been doing without this, since
playing audio over a remote box's speaker isn't useful.
	9wm and 9term
only because i have to use X at all. i used to also use
framemaker and staroffice, but i havn't had any reason to
for over a year. i think that's it. when i had a Unix box,
there were a few games, too, but i don't remember which.
-.

Re: [9fans] X on Plan 9

[anothy]

okay, here goes: X apps i care about, and breifly why:
	Netscape
no, i don't plan on porting this locally, but i find Charon
to be great for ~95% of the web pages i look at. one notable
exception is my bank; when i need to get there, i use vnc.
	Everybuddy
an ICQ/AIM/etc. client. i know it's juvenile, but i work
with high school kids alot, and this is huge with them. i'd
been using this via vnc.
	Palm emulator
at least until i figure out how to import/export from/to
regular text files. painful remotely, since i have to dump
the Palm's memory, move it over my slow modem, use vnc over
that same slow modem to use the (slow) emulator, and move
stuff back.
	xpic
which, incidently, i've already seen ported to Plan 9. i'd
been using this via vnc (but not much).
	xv
only because most of (all?) the tools in 2nd edition's 9.1
are missing in 3rd edition. i've been using this via vnc.
	some mp3 player
which was just a wrapper to mpg123, which's already been
ported. this was why, a while ago, i asked about the Labs
folk releasing their audio players, even without the PAC
bits - it'd be easy enough to plug mpg123 into them. and i
really like agui. i've been doing without this, since
playing audio over a remote box's speaker isn't useful.
	9wm and 9term
only because i have to use X at all. i used to also use
framemaker and staroffice, but i havn't had any reason to
for over a year. i think that's it. when i had a Unix box,
there were a few games, too, but i don't remember which.
-α.

Re: [9fans] X on Plan 9

[Boyd Roberts]

From: <anothy@cosym.net>
> okay, here goes: X apps i care about, and breifly why:
> Netscape
> no, i don't plan on porting this locally, but i find Charon
> to be great for ~95% of the web pages i look at. one notable
> exception is my bank; when i need to get there, i use vnc.

i like charon for it's simplicity, but you need an army to implement
that mess which is HTTP/HTML/SSL/...

IIRC charon doesn't do proxy auth.  the structure of the thing is weird.

> an ICQ/AIM/etc. client. i know it's juvenile, but i work

ICQ?  the protocol isn't even specified:

    http://www.rfc-editor.org/rfc/rfc2812.txt

    Network Working Group                                            C. Kalt
    Request for Comments: 2812                                    April 2000
    Updates: 1459
    Category: Informational


                       Internet Relay Chat: Client Protocol

Informational = moving target.

> 9wm and 9term

rio?

9term!  don't get me started on 9term.  i wasted hours in '92 to try
and beat it into shape.  luckily i found the ULTRIX pty driver source.
it had some interesting undocumented features, that avoided 3000
ioctl's per character.  i was a Digital employee at the time.  i added
'look' to it, but rob said it made the button 2 menu too long.  go figure.

for it to be usable it was too ULTRIX specific, so the work is either
lost or is somewhere within SRC/CRL.

i got the credit for B, but that's not strictly true.  rob saw this thing
called 'e' IIRC which acted like B, but used X nonsense.  he
mentioned that sam should read commands out of a named
pipe, hence B.  anyway the code i submitted got re-written
for 'style' reasons i guess.

    john mackin's 'e' -> rob/me/bobf? 'B' -> plumbing

> only because i have to use X at all. i used to also use
> framemaker and staroffice, but i havn't had any reason to
> for over a year. i think that's it. when i had a Unix box,
> there were a few games, too, but i don't remember which.

if you want X get another m/c or dual boot.

personally i think inferno on windows on my 2nd lapdog will do just fine for me.

btw: the first one 'died' so i upgraded.  before taking it apart, 'cos sony vaio
support
    suck etc, i tried to boot it one more time.  it booted.  that explained
everything;
    it had 'died' because of an over temp condition somewhere and after a week?
    it had cooled down and boots fine.  it has plan 9 on it, but i can't type on
the
    keyboard.  anyway, i want to write limbo.  before that i shall prototype
with
    the inferno shell's loadable tk module.

    i have a mail user agent in mind.

Re: [9fans] X on Plan 9

[Ronald G Minnich]

I think the cool thing would be to come up with a 'porting guide' from X
to plan 9. The thought of contaminating plan 9 with X11 makes my teeth
hurt.

Probably a good standard app as the first cut would be xcalc. What has to
change, how do you change it, etc.

Of course, this will take a much better graphics guy than I'll ever be to
do.

ron

Re: [9fans] X on Plan 9

[Douglas A. Gwyn]

Ronald G Minnich wrote:
> I think the cool thing would be to come up with a 'porting guide' from X
> to plan 9. ...
> Probably a good standard app as the first cut would be xcalc. ...

The point of X11 is that it is a standard.
Plan 9 isn't.
Therefore, it is not *cost effective* to continually try to get apps
ported from the portable platform, X11, to the parochial platform,
Plan 9.
There should be an X11 server for Plan 9 for the same reasons that
there should be an APE.

Re: [9fans] X on Plan 9

[Boyd Roberts]

From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
> There should be an X11 server for Plan 9 for the same reasons that
> there should be an APE.

i agree, but ouch!

Re: [9fans] X on Plan 9

[forsyth]

what are those applications?  just curious.

Re: [9fans] X on Plan 9

[okamoto]

I understand your point, because we are running useful X applications
here too, which is the very reason why we still have several linux machines.
Those applications are, unfortunately, fairly large usually.  ^_^

This is a very difficult point where I have no conclusion, especially after
I saw control library, which encourages us one step ahead to non
event-driven GUI programming environment...

Kenji

Re: [9fans] X on Plan 9

[David Rubin]

okamoto@granite.cias.osakafu-u.ac.jp wrote:

> This is a very difficult point where I have no conclusion, especially after
> I saw control library, which encourages us one step ahead to non
> event-driven GUI programming environment...

What do you mean by "non event-driven?"

	david

--
FORTRAN was the language of choice
for the same reason that three-legged races are popular.
	-- Ken Thompson, "Reflections on Trusting Trust"

Re: [9fans] X on Plan 9

[Boyd Roberts]

From: "David Rubin" <dlrubin@hotmail.com>
>
> What do you mean by "non event-driven?"
>

easy to code.

Re: [9fans] X on Plan 9

[anothy]

because, as i said, i have about a half-dozen X apps
that i use (or do without their functionality). the
quality/enjoyability of my computing time would be
greatly increased if i could use these locally. now,
i use most on a remote Solaris box using vnc, but
that's painful from home, over my 56K modem (to far
for DSL; no cable modem in my town). were i far more
daring, i'd look at porting them to /dev/draw, but
that's an even more daunting task - even the few of
these programs that were written with any sort of
portability in mind wern't written with _that_ kind
of portability in mind.
-α.

Re: [9fans] X on Plan 9

[Russ Cox]

> Going the other way round might be interesting - X client running on
> UNIX box and acting as 9P server. I.e. exporting an equivalent of
> /dev/cons, /dev/consctl, vga(3), mouse(3) and draw(3). For one thing,

Umm, this is drawterm by another name, no?

Russ

Re: [9fans] X on Plan 9

[Alexander Viro]

On Wed, 18 Apr 2001, Russ Cox wrote:

> > Going the other way round might be interesting - X client running on
> > UNIX box and acting as 9P server. I.e. exporting an equivalent of
> > /dev/cons, /dev/consctl, vga(3), mouse(3) and draw(3). For one thing,
>
> Umm, this is drawterm by another name, no?

Hmm... Aside of the access to local fs it's pretty much close. I've
never tried to install CPU server on a headless box, but this combination
sounds like a good idea. Thanks...

Re: [9fans] X on Plan 9

[Boyd Roberts]

why bother?

[9fans] X on Plan 9

[anothy]

the APE paper (i think) mentions that APE has been used to
build X11 on Plan 9, but that it's not included in the
distribution because it's too much work to maintain. i
imagine the presence of the very good vnc client also helps
negate the need for X for most people.

however, shame me as it does to admit it, i'd still find a
local X server very useful. there are about a half-dozen X
programs i find useful, and i'm not up to porting them all
the Plan 9's /dev/draw.

so... understanding that it's totally unsupported... can
whoever did the work in the Labs either share whatever
changes were made? i assume that, at least, X had to be told
how to talk to /dev/draw. i suspect various things also
needed to be done to convince it to 'configure' properly.

if nobody has any info, i'm going to give it a shot myself,
but X is an intimidating (read: freakin' huge!) body of
crap^Wcode, and i'd rather not duplicate work someone else's
already done.
-α.

Re: [9fans] X on Plan 9

[Andrey A Mirtchovski]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1501 bytes --]

hi, 

i'm not posting this to the list, since i'm not sure how many people need to
know about this, but something called x.tar.gz (or a variation thereof) was
located on the plan9.bell-labs.com ftp site at least in january this year..
i think it was the infamous X port.. 

i don't remember the exact location, though... i remember downloading and
unzipping it, but that was all..

hope this helps in any way :)

On Wed, 18 Apr 2001 anothy@cosym.net wrote:

> the APE paper (i think) mentions that APE has been used to
> build X11 on Plan 9, but that it's not included in the
> distribution because it's too much work to maintain. i
> imagine the presence of the very good vnc client also helps
> negate the need for X for most people.
> 
> however, shame me as it does to admit it, i'd still find a
> local X server very useful. there are about a half-dozen X
> programs i find useful, and i'm not up to porting them all
> the Plan 9's /dev/draw.
> 
> so... understanding that it's totally unsupported... can
> whoever did the work in the Labs either share whatever
> changes were made? i assume that, at least, X had to be told
> how to talk to /dev/draw. i suspect various things also
> needed to be done to convince it to 'configure' properly.
> 
> if nobody has any info, i'm going to give it a shot myself,
> but X is an intimidating (read: freakin' huge!) body of
> crap^Wcode, and i'd rather not duplicate work someone else's
> already done.
> -α.
> 

Re: [9fans] X on Plan 9

[Andrey A Mirtchovski]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1647 bytes --]

damit :)

On Wed, 18 Apr 2001, Andrey A Mirtchovski wrote:

> hi, 
> 
> i'm not posting this to the list, since i'm not sure how many people need to
> know about this, but something called x.tar.gz (or a variation thereof) was
> located on the plan9.bell-labs.com ftp site at least in january this year..
> i think it was the infamous X port.. 
> 
> i don't remember the exact location, though... i remember downloading and
> unzipping it, but that was all..
> 
> hope this helps in any way :)
> 
> On Wed, 18 Apr 2001 anothy@cosym.net wrote:
> 
> > the APE paper (i think) mentions that APE has been used to
> > build X11 on Plan 9, but that it's not included in the
> > distribution because it's too much work to maintain. i
> > imagine the presence of the very good vnc client also helps
> > negate the need for X for most people.
> > 
> > however, shame me as it does to admit it, i'd still find a
> > local X server very useful. there are about a half-dozen X
> > programs i find useful, and i'm not up to porting them all
> > the Plan 9's /dev/draw.
> > 
> > so... understanding that it's totally unsupported... can
> > whoever did the work in the Labs either share whatever
> > changes were made? i assume that, at least, X had to be told
> > how to talk to /dev/draw. i suspect various things also
> > needed to be done to convince it to 'configure' properly.
> > 
> > if nobody has any info, i'm going to give it a shot myself,
> > but X is an intimidating (read: freakin' huge!) body of
> > crap^Wcode, and i'd rather not duplicate work someone else's
> > already done.
> > -α.
> > 
> 
> 

Re: [9fans] X on Plan 9

[Alexander Viro]

On Wed, 18 Apr 2001 anothy@cosym.net wrote:

> if nobody has any info, i'm going to give it a shot myself,
> but X is an intimidating (read: freakin' huge!) body of
> crap^Wcode, and i'd rather not duplicate work someone else's
> already done.

Going the other way round might be interesting - X client running on
UNIX box and acting as 9P server. I.e. exporting an equivalent of
/dev/cons, /dev/consctl, vga(3), mouse(3) and draw(3). For one thing,
it gives convenient way of dealing with boxen that have unsupported
video cards, for another - helps with debugging support for such cards
(boot, import that animal from a UNIX box, union-mount it in the beginning
of /dev and let rio run as usual; then you can create a new namespace
group, mount #v and #i there and do whatever testing you want - stuff
in that group will talk to real hardware).

Had anyone done that? I will play with that if/when I'll get some
spare time - I've got a box with unsupported card and a bunch of UNIX
boxen on the same (moderately loaded) ethernet segment, so unless there's
a better way to do that...

Re: [9fans] X on Plan 9

[bob]

Is it possible to put inferno's GUI into Plan9 intead of using X. I would
love to see windows created limbo
it is so cool. Plan9 +limbo = superb. just like sun solaris with java and
stuffs like that..

<anothy@cosym.net> wrote in message
news:20010418225620.CE096199C0@mail.cse.psu.edu...
> the APE paper (i think) mentions that APE has been used to
> build X11 on Plan 9, but that it's not included in the
> distribution because it's too much work to maintain. i
> imagine the presence of the very good vnc client also helps
> negate the need for X for most people.
>
> however, shame me as it does to admit it, i'd still find a
> local X server very useful. there are about a half-dozen X
> programs i find useful, and i'm not up to porting them all
> the Plan 9's /dev/draw.
>
> so... understanding that it's totally unsupported... can
> whoever did the work in the Labs either share whatever
> changes were made? i assume that, at least, X had to be told
> how to talk to /dev/draw. i suspect various things also
> needed to be done to convince it to 'configure' properly.
>
> if nobody has any info, i'm going to give it a shot myself,
> but X is an intimidating (read: freakin' huge!) body of
> crap^Wcode, and i'd rather not duplicate work someone else's
> already done.
> -.