[9fans] drawterm

[9fans] drawterm

[boyd, rounin]

seems it works fine from 160 klicks north of sydney [.au].

Re: [9fans] drawterm

[okamoto]

> seems it works fine from 160 klicks north of sydney [.au].

To Eastern Coast?

Dan is using fossil?

Kenji

Re: [9fans] drawterm

[boyd, rounin]

> To Eastern Coast?

yeah, new york.

> Dan is using fossil?

dunno.

Re: [9fans] drawterm

[Dan Cross]

"boyd, rounin" <boyd@insultant.net> writes:
> > Dan is using fossil?
>
> dunno.

No, I'm still using Ken's file server.  It'll probably stay that way for
another year or so at least, as I'm leaving for 10 months pretty soon, and
don't have time to upgrade it (or move the data!) before I leave....

	- Dan C.

[9fans] drawterm

[Steve Simon]

Maybe this is old news to everyone else but for me the
highlight of dt2k is /dev/secstore which is populated
(assuming you logged in via secstore) and is completely 
cleared if it is written.

This means you can add somthing like this to your 
(in the drawterm clause of the cpu case) profile:

cat /mnt/term/dev/secstore | read -m > /mnt/factotum/ctl
echo > /mnt/term/dev/secstore 

-Steve

[9fans] drawterm

[Russ Cox]

I am almost ready to declare dt2k "stable".

The random lock-ups were due to suspect X11 use
that I cleaned up a few weeks ago.

The fcp bug I mentioned before turns out to be a
problem with Plan 9, not with drawterm.  The bug was
in devssl (or in devmnt, depending on how you look at it),
not in drawterm.  There is a new /sys/src/9/port/devssl.c
and devmnt.c on sources.

There are new drawterm binaries at http://swtch.com/drawterm/

If you build yourself a kernel with the new devssl/devmnt
and are running the latest drawterm and see it crash or
do something else wrong, please let me know.

The latest drawterm has one new feature: if you are running
a plan9port factotum, then drawterm will use it.

Russ

Re: [9fans] drawterm

[Gabriel Diaz]

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

Hi

I just downloaded the windows version and seems that this
new version can't be used with the same params of the old one.

I try to run it without params and with the common /? -h --help,
and i only get a crash. I think it try to open some environment
variables that are missing. (i can send you the complete
dump from windows if needed)

How can be used this new version? are there some env vars I must
use?

Thanks

Gabi


2005/11/4, Russ Cox <rsc@swtch.com>:
>
> I am almost ready to declare dt2k "stable".
>
> The random lock-ups were due to suspect X11 use
> that I cleaned up a few weeks ago.
>
> The fcp bug I mentioned before turns out to be a
> problem with Plan 9, not with drawterm. The bug was
> in devssl (or in devmnt, depending on how you look at it),
> not in drawterm. There is a new /sys/src/9/port/devssl.c
> and devmnt.c on sources.
>
> There are new drawterm binaries at http://swtch.com/drawterm/
>
> If you build yourself a kernel with the new devssl/devmnt
> and are running the latest drawterm and see it crash or
> do something else wrong, please let me know.
>
> The latest drawterm has one new feature: if you are running
> a plan9port factotum, then drawterm will use it.
>
> Russ
>

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

Re: [9fans] drawterm

["Nils O. Selåsdal"]

Gabriel Diaz wrote:
> 
> Hi
> 
> I just downloaded the windows version and seems that this
> new version can't be used with the same params of the old one.
> 
> I try to run it without params and with the common /? -h --help,
> and i only get a crash. I think it try to open some environment
> variables that are missing. (i can send you the complete
> dump from windows if needed)
http://asgaard.homelinux.org/plan9/dt2k-mingw.exe doesn't crash atleast
if given /?, -h or --help

> How can be used this new version? are there some env vars I must
> use?

run it with the flags
-a the.auth.server -c the.cpu.server
(-u user and -s secstore can be specified as well)

Re: [9fans] drawterm

[Gabriel Diaz]

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

Hi

That were the flags i used to use with the old one.
I run it in windows xp.

I tryed the binary Nils put and it run fine..
With env vars and with the usual -a and -c parameters works.
(and -s param too )

thanks

Gabi



2005/11/4, "Nils O. Selåsdal" <noselasd@asgaard.homelinux.org>:
>
> Gabriel Diaz wrote:
> >
> > Hi
> >
> > I just downloaded the windows version and seems that this
> > new version can't be used with the same params of the old one.
> >
> > I try to run it without params and with the common /? -h --help,
> > and i only get a crash. I think it try to open some environment
> > variables that are missing. (i can send you the complete
> > dump from windows if needed)
> http://asgaard.homelinux.org/plan9/dt2k-mingw.exe doesn't crash atleast
> if given /?, -h or --help
>
> > How can be used this new version? are there some env vars I must
> > use?
>
> run it with the flags
> -a the.auth.server -c the.cpu.server
> (-u user and -s secstore can be specified as well)
>

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

Re: [9fans] drawterm

[Russ Cox]

>  I try to run it without params and with the common /? -h --help,
>  and i only get a crash. I think it try to open some environment
>  variables that are missing. (i can send you the complete
>  dump from windows if needed)

When I run from unix with no params, a drawterm window pops up
that says "set $cpu" and sits there.  That's what's supposed to
happen in Windows.  I don't know why it doesn't.

The command line is

  drawterm [-c cpuserver] [-a authserver] [-s secstoreserver]

and some other flags which don't matter much.  If you use -a
but not -s, -s will be filled in with the arg from -a.

If you don't specify -c it uses $cpu.  You have to specify -a unless
you're using factotum (Unix only).

Russ

Re: [9fans] drawterm

[Axel Belinfante]

> There are new drawterm binaries at http://swtch.com/drawterm/

I almost don't dare to ask...
anybody tried to compile it (with success)
for sunos 5.8?

Axel.

Re: [9fans] drawterm

[Axel Belinfante]

> > There are new drawterm binaries at http://swtch.com/drawterm/
> 
> I almost don't dare to ask...
> anybody tried to compile it (with success)
> for sunos 5.8?

To answer my own question: after a little struggle I have a drawterm.

When I start it with my usual -a and -c flags it says:

| cpu: cannot write user/domain choice in p9any:
| '/mnt/factotum/ctl' does not exist
| 
| goodbye

Is this something I missed in the struggle?
Or the effect of a too old p9p installation?
Or?

(running cpu from a plan9 terminal works fine,
 as does old drawterm) 

Axel.

Re: [9fans] drawterm

[Axel Belinfante]

In your message to me you wrote:
In message <200511042214.jA4MEGX17643@demeter.cs.utwente.nl>you write:
> > > There are new drawterm binaries at http://swtch.com/drawterm/
> > 
> > I almost don't dare to ask...
> > anybody tried to compile it (with success)
> > for sunos 5.8?
> 
> To answer my own question: after a little struggle I have a drawterm.
> 
> When I start it with my usual -a and -c flags it says:
> 
> | cpu: cannot write user/domain choice in p9any:
> | '/mnt/factotum/ctl' does not exist
> | 
> | goodbye
> 
> Is this something I missed in the struggle?
> Or the effect of a too old p9p installation?
> Or?
> 
> (running cpu from a plan9 terminal works fine,
>  as does old drawterm) 

commenting out the 'exits' at the end of 'fatal'
and adding some debug prints shows me a bit more.
seems like the '/mnt/factotum/ctl does not exist
somehow is stuck from a previous error and not reset.

reading p9any negotiation: p9sk1@cs.utwente.nl
cpu: cannot write user/domain choice in p9any: 11 != 20: p9sk1 cs.utwente.nl
cpu: cannot write p9sk1 challenge: (factotum ctl err msg)
user@cs.utwente.nl password:
cpu: cannot send ticket and authenticator back in p9sk1: cs gave empty translation list
cpu: can't authenticate slurp: cs gave empty translation list
cpu: wrting network: dir: fd out of range or not open
cpu: wanting for FS: fd out of range or not open: fd out of range or not open
remote cpu:
goodbye


Axel.

Re: [9fans] drawterm

[Brantley Coile]

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

i just downloaded it.  ran it under fc4 and it drops core.
now, if i can just find out where they put the core file!!

 bc

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

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] drawterm
Date: Fri, 04 Nov 2005 23:14:16 +0100
Message-ID: <200511042214.jA4MEGX17643@demeter.cs.utwente.nl>

> > There are new drawterm binaries at http://swtch.com/drawterm/
> 
> I almost don't dare to ask...
> anybody tried to compile it (with success)
> for sunos 5.8?

To answer my own question: after a little struggle I have a drawterm.

When I start it with my usual -a and -c flags it says:

| cpu: cannot write user/domain choice in p9any:
| '/mnt/factotum/ctl' does not exist
| 
| goodbye

Is this something I missed in the struggle?
Or the effect of a too old p9p installation?
Or?

(running cpu from a plan9 terminal works fine,
 as does old drawterm) 

Axel.

Re: [9fans] drawterm

[andrey mirtchovski]

run 'ulimit -c unlimited' on the shell and you'll get core files.

i just compiled it on fc4 and got a segfault:

#0  0x0804c934 in secdial (secstore=0x0) at secstore.c:35
35              if(*p == 0)       /* else use the authserver */


On Fri, 4 Nov 2005, Brantley Coile wrote:

> i just downloaded it.  ran it under fc4 and it drops core.
> now, if i can just find out where they put the core file!!
>
> bc
>

Re: [9fans] drawterm

[Brantley Coile]

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

i did the ulimit thing.  i just forgot what the core file was named.
i see core.<pid> now.

thanks.

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

From: andrey mirtchovski <andrey@lanl.gov>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] drawterm
Date: Fri, 4 Nov 2005 16:01:45 -0700 (MST)
Message-ID: <Pine.LNX.4.64.0511041600510.23854@mtdew.lanl.gov>

run 'ulimit -c unlimited' on the shell and you'll get core files.

i just compiled it on fc4 and got a segfault:

#0  0x0804c934 in secdial (secstore=0x0) at secstore.c:35
35              if(*p == 0)       /* else use the authserver */


On Fri, 4 Nov 2005, Brantley Coile wrote:

> i just downloaded it.  ran it under fc4 and it drops core.
> now, if i can just find out where they put the core file!!
>
> bc
>

Re: [9fans] drawterm

[Tim Wiess]

> i just downloaded it.  ran it under fc4 and it drops core.
> now, if i can just find out where they put the core file!!

I noticed that it seg faults when you don't specify an auth server. Due
to a null dereference in netmkaddr(authserver, "tcp", "567") from
authdial().

I added the patch below to fix it as well as provide support for $auth.


Index: cpu.c
===================================================================
RCS file: /cvs/drawterm/cpu.c,v
retrieving revision 1.3
diff -u -r1.3 cpu.c
--- cpu.c	4 Nov 2005 17:06:57 -0000	1.3
+++ cpu.c	4 Nov 2005 22:59:48 -0000
@@ -181,6 +181,12 @@
 			fatal(0, "set $cpu");
 		system = p;
 	}
+	if(authserver == nil) {
+		p = getenv("auth");
+		if(p == 0)
+			fatal(0, "set $auth");
+		authserver = p;
+	}
 
 	if(err = rexcall(&data, system, srvname))
 		fatal(1, "%s: %s", err, system);

Re: [9fans] drawterm

[andrey mirtchovski]

it looks like it has always been there. i triggered it only when i ran
drawterm with bogus parameters.

obviously i don't make a good tester as i switched to it exclusively
several months ago :)

[9fans] drawterm

[Russ Cox]

I made some changes to drawterm yesterday that fix some
of the snarf problems and might even fix the random crashes
that some have seen (and others have not).  I also replaced
my pipe-based pseudo-locks with real pthreads locks, so if it
seemed slow before, maybe it will be better now.

Best of all, I have a test case that reliably crashes drawterm.
If you connect to somewhere and then run
    fcp /mnt/term/some/big/file /dev/null
then eventually drawterm or the remote kernel or both get
confused about what's going on on the wire and someone
hangs up.  It never gets through more than a couple megabytes
before this happens.

Drawterm gets a read error from "bad digest", and the
kernel sometimes sees unexpected rpc messages, usually
Rreads to Treads that it is trying to flush (but the Rflush is
sent only after the Rread, so the Rread is legitimate).

I'm out of ideas at the moment.  If someone else wants to debug,
please do so.

   cvs -d :pserver:anonymous@cvs.pdos.csail.mit.edu:/cvs co drawterm

Russ

[9fans] drawterm

[Andrew Simmons]

 >You're growing into Boyd's shoes quite well -- lots of whining,
 >hardly any actual contribution, and convenient memory loss
 >to reinforce your desired view of the world.

Oh for fuck's sake. Perhaps you're justified in feeling peevish towards 
Uriel, but I don't care. Was it really necessary to take a gratuitously 
nasty swipe at some one who is no longer here to answer back? Even if 
you didn't care for Boyd's posts - and I personally, along with many 
others, found them unfailingly entertaining, and think the list is a 
good deal poorer for his absence -  at least you could be accurate in 
your criticism. "Lots of whining"? I don't recall Boyd ever whining. 
"Hardly any actual contribution"? In terms of code, no doubt accurate, 
but in terms of entertainment and general good cheer, his contribution 
was considerable. "Memory loss"? I don't recall any memory loss on 
Boyd's part - no doubt due to convenient memory loss on my part -  but 
if there was one, I imagine it was down to the Jack Daniels , not 
because of any attempt to reinforce his desired view of the world. For 
fuck's sake.

Re: [9fans] drawterm

[Dave Lukes]

Andrew Simmons wrote:

> >You're growing into Boyd's shoes quite well -- lots of whining,
> >hardly any actual contribution, and convenient memory loss
> >to reinforce your desired view of the world.
>
> Oh for fuck's sake.

Calm down Andrew: feel sympathy for the poor man.
It's obvious what's happened:
An OpenBSD developer must have died overnight and Russ is involuntarily 
channelling him.


    DaveL (channelling Gilbert Harding).

Re: [9fans] drawterm

[Vester Thacker]

I'm not advocating hero worship, but Boyd was a terrific guy. I
believe that he thought he could make a greater difference by helping
others. He helped a small number of us on #plan9 and even on a few
other channels. I greatly appreciated his help, his stories and most
importantly his friendship.

Here are some excerpts of Boyd's from #plan9 (sorry, of course,
they're out of context):

"And my orders are to weed out all non-hackers who do not pack
the gear to serve in my beloved Corps!"

"anyone with doubts on my 'credentials' can mail ken, dennis,
rob, whoever ..."

"uriel yer a utopian nihilist" ...."well uriel is a tough fucker"

"drunken australians, with 9mm pistols wandering into a nick,
 without a permit, who belongs to the federal cops gun range --
 it's a bit implausible"

"while they flounder around, no-one should help 'em
so they die -- natural selection
9p has been around for ages and these fools have picked up every
damn stupid f/s known to man, 'cept 9p"

"see glenda
  see glenda run
  run glenda, run
  seen glenda"

"Unfortunately John Mackin, whose reality I have backed up on
a 9 track, in tar format, is no longer around to tell the old
stories, but he was certainly involved in them. I remember the
time we fixed a broken 32V file-system's /etc with a screwdriver,
sticky tape, adb, dd and a magtape."

"well i do
but my stories can be negated by any of the 3rd parties
i was lucky -- that's all
i'd prefer to share what i know"


Perhaps these aren't the best of his comments, but I find it difficult
to go through his comments after his death.

--vester thacker
  aka "Gunney"

Re: [9fans] drawterm

[Brantley Coile]

i don't think you're growing into Boyd's shoes.  he wouldn't
have written that long of a message.  (i also don't think he
would have fussed about the description.)  i still think boyd
was a service.  even when we ran him off for a month or so.

  Brantley


Andrew Simmons wrote:
>  >You're growing into Boyd's shoes quite well -- lots of whining,
>  >hardly any actual contribution, and convenient memory loss
>  >to reinforce your desired view of the world.
> 
> Oh for fuck's sake. Perhaps you're justified in feeling peevish towards 
> Uriel, but I don't care. Was it really necessary to take a gratuitously 
> nasty swipe at some one who is no longer here to answer back? Even if 
> you didn't care for Boyd's posts - and I personally, along with many 
> others, found them unfailingly entertaining, and think the list is a 
> good deal poorer for his absence -  at least you could be accurate in 
> your criticism. "Lots of whining"? I don't recall Boyd ever whining. 
> "Hardly any actual contribution"? In terms of code, no doubt accurate, 
> but in terms of entertainment and general good cheer, his contribution 
> was considerable. "Memory loss"? I don't recall any memory loss on 
> Boyd's part - no doubt due to convenient memory loss on my part -  but 
> if there was one, I imagine it was down to the Jack Daniels , not 
> because of any attempt to reinforce his desired view of the world. For 
> fuck's sake.
> 

Re: [9fans] drawterm

[Russ Cox]

I am sure Boyd was a wonderful person to those who knew him well,
and my comment was not intended to diminish that.  I apologize if
it seemed to.

Russ

[9fans] drawterm

[Russ Cox]

> Release early, release often, and if you don't like it, look at Google.

Not sure what you mean about Google, but I don't care.

Release often implies that you have the time and inclination to work
on the project, so that there are often new changes to release.
For dt2k, I have neither.  Drawterm is a giant crock.  It duplicates tons
of code, it's hard to debug, it doesn't do half the things I wish it would,
and unfortunately it's really really useful to a lot of people, myself included.

I've actually written three attempts at 9P2000 drawterms.  Each time
I've ended up with a big program with some subtle bugs in threading
or X11 or god-only-knows, and the whole thing crashes after a few
hours or whenever you do something complicated like resize acme.
(Come to think of it, the current one frequently crashes when I resize
acme.  So I don't resize acme much.)

Release early, release often assumes you have a working program
that people will find useful enough to change.  Apparently dt2k was
useful enough to change, but I wouldn't have characterized the early
versions as useful.  I only grudingly started using it instead of the old
drawterm when Bell Labs forced us to turn off the old unencrypted
services.

Apparently my sin was that back in 2003 when I first posted to 9fans
I should have posted a URL for the tar file instead of asking people
to mail me (at the time, the tar file wasn't on the web or I would have).
But at least a dozen people have asked for and gotten the source,
and most I never heard from again.

I'm very happy that Skip, Brucee, Geoff, and Andrey have made
dt2k better.  Many thanks to them.  You haven't, and yet you've
known, since at least as far back as April 12 (see THM log), that
there was a copy on Andrey's U.Calgary site.  You were reminded
again on June 23.  Claiming that it has been locked in a vault is just
plain wrong.

You're growing into Boyd's shoes quite well -- lots of whining,
hardly any actual contribution, and convenient memory loss
to reinforce your desired view of the world.

For what it's worth, I just diffed the source Andrey posted in the THM
against the current CVS.  Hardly anything has changed: there is support
for buttons 4 and 5 and slightly better keysym handling.  Anyone who
made changes to the April 12 version would have been doing useful work.
The status hasn't changed since April 12 either: it's still unstable,
it needs work before it can go into the distribution, and I am happy to
accept contributions from other pepople.

Russ


http://plan9.bell-labs.com/wiki/plan9/thm_2005-04-12_Log/
http://plan9.bell-labs.com/wiki/plan9/thm_2005-06-23_Log/

[9fans] drawterm

[boyd, rounin]

who, perchance, wrote it?
--
MGRS 31U DQ 52572 12604

Re: [9fans] drawterm

[Russ Cox]

seanq wrote the first one about
the same time as the original 9pm,
for windows only.

i updated it for the new devdraw, and then
a few months later rob convinced me to
do the unix port, producing what you see
in /sys/src/cmd/unix/drawterm.

in essence it's just a ported plan 9 kernel
so the authorship really goes back a bunch
further.  the 9p1 version is based on a quite
old (now) kernel, while the dt2k one is based
on a newer version.

russ

Re: [9fans] drawterm

[boyd, rounin]

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

> From: "Russ Cox" <russcox@gmail.com>

thanks for the clarification, but PING is not an
acceptable error message should you have a
routing/ISP/firewall problem ...

cut to monty python's _the meaning of life_:

    have we got the machine that goes BING?

btw: nor is 'postnote 2'.

bbtw: even ralph tries to get things right.

[-- Attachment #2: ralph.c --]
[-- Type: application/octet-stream, Size: 1339 bytes --]

#include <u.h>
#include <libc.h>
#include <bio.h>
#include <ctype.h>

/*
 * ralph
 *
 * A filter to read stdin and write latin-1 diacriticals as
 * quasi troff to stdout.
 *
 * © Boyd Roberts 2004
 */

/* map latin-1 to troff diacriticals */
static Rune	*tab[256]	=
{
	[0xe0] L"`a", L"'a", L"^a", 0, 0, 0,     0, L"ç",
	[0xe8] L"`e", L"'e", L"^e", 0, 0, 0, L"^i",    0,
	[0xf0]     0,     0,     0, 0, 0, 0, L":o",    0,
};

/* troff string [diacritical] prefix */
char		*tp		= "\\*";

void
main(int argc, char *argv[])
{
	Biobuf	bin;
	Biobuf	bout;
	Biobuf	*in;
	Biobuf	*out;
	int	c;
	int	e;

	USED(argc);
	USED(argv);

	Binit(in = &bin, 0, OREAD);
	Binit(out = &bout, 1, OWRITE);
	e = 0;

	while ((c = Bgetc(in)) >= 0) {
		Rune	*r;

		if (isascii(c)) {
			/* damn windows' CRs */
			if (c != '\r' && Bputc(out, c) < 0) {
				e = 1;
				break;
			}

			continue;
		}

		if ((r = tab[c]) == 0) {
			fprint(2, "ralph: unknown latin-1 0x%02x\n", c);
			exits("update latin-1 table");
		}

		/* single Rune or troff diacritical */
		if (runestrlen(r) == 1) {
			if (Bprint(out, "%C", *r) == Beof)
				e = 1;
		}
		else if (Bprint(out, "%s%S", tp, r) == Beof)
				e = 1;

		if (e)
			break;
	}

	if (!e && Bflush(out) < 0)
		e = 1;

	exits(e ? "i/o error" : "");
}

[9fans] drawterm

[David Presotto]

I was looking back in the archives and can't find the messages.
Did someone recently say they've got a compilable drawterm
that they're working on?

Re: [9fans] drawterm

[mirtchov]

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

i did..  i've made some small changes to get it to compile on Solaris,
Linux and FreeBSD.  i've also forced the TCP_NODELAY option which was
missing from the distribution one (or so I thought at the time)...

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

From: David Presotto <presotto@closedmind.org>
To: 9fans@cse.psu.edu
Subject: [9fans] drawterm
Date: Wed, 10 Sep 2003 10:38:37 -0400
Message-ID: <47014a671bc8fbbe7504f363f1632f02@plan9.bell-labs.com>

I was looking back in the archives and can't find the messages.
Did someone recently say they've got a compilable drawterm
that they're working on?

Re: [9fans] drawterm

[andrey mirtchovski]

On Wed, 10 Sep 2003 mirtchov@cpsc.ucalgary.ca wrote:

> i did..  i've made some small changes to get it to compile on Solaris,
> Linux and FreeBSD.  i've also forced the TCP_NODELAY option which was
> missing from the distribution one (or so I thought at the time)...


here's the situation with drawterm, as much as i could gather in 1/2 hour:

    Linux/gcc           -- compiles with modifications, works
    FreeBSD/gcc         -- compiles with modifications, works
    SunOS 5.8/sparc/cc  -- compiles, works with a strange palette
    SunOS 5.8/sparc/gcc -- compiles with extensive modifications to mkfile
                        -- but fails with:
                error: Error 0
                ./drawterm: thr_create failed: -1 0 -1 Error 0
                abort 26810
    Tru64/cc            -- compiles with small modifications to the mkfile
                        -- and tons of warnings. shows login correctly, but
                        -- a black screen afterwards
    Tru64/gcc           -- compiles with small modifications to the mkfile
                        -- and tons of warnings. shows black screen when ran

    Irix 6.5/cc         -- compiles, untested
    Irix 6.5/gcc        -- untested


the strange colours and black screens could be due to the fact that all of
them were displayed remotely on an X11 running on linux.

the Tru64's report as OSF1/5.1

andrey

Re: [9fans] drawterm

[Atanas Bachvaroff]

[-- Attachment #1: Type: TEXT/plain, Size: 585 bytes --]

On 10 Sep, andrey mirtchovski wrote:
>     Irix 6.5/cc         -- compiles, untested

Hello
Andrey and I got drawterm to compile and work on IRIX 6.5 with
MIPSpro 7.3. You may download it from http://SIGBUS.nove.bg/drawterm/ .
I have got no gcc on the workstation to try compiling drawterm with.
There are problems with the colormap as expected - right click draws
blue menu. I believe the same thing causes problems on the SunOS/sparc
and shall try to fix it when I have some spare time.
Greetings.

--
BEATVSHOMOQVIINVENITSAPIENTIAMETQVIAFFLVITPRVDENTIALIVRILVCIFERIVS

[-- Attachment #2: Type: APPLICATION/pgp-signature, Size: 256 bytes --]

Re: [9fans] drawterm

[Geoff Collyer]

gcc takes greater liberties when optimising than Ken's compilers do,
and most Plan 9 code doesn't use `volatile', so I use a wrapper (agcc)
to disable some optimisations, and set CC=agcc in my [Mm]a?ke?files on
Unix.

cpu% cat openbsd/bin/sh/agcc
#!/bin/sh
# agcc - invoke gcc in ANSI mode with less-aggressive optimisation.
# --writable-strings is a concession to pre-ansi programs like pre-plan-9 mk.
exec gcc -ansi -pipe -fvolatile -fvolatile-global --writable-strings "$@"

If your gcc implements it (e.g. on MacOS 10.2), add
`-fvolatile-static'.

It's probably best to start with no -O options and see if the
resulting binary works correctly before trying to add -O options.

Re: [9fans] drawterm

[okamoto]

> On Wed, 10 Sep 2003 mirtchov@cpsc.ucalgary.ca wrote:
> the strange colours and black screens could be due to the fact that all of
> them were displayed remotely on an X11 running on linux.

I happen to use drawterm resides on /sys/src/cmd/unix/drawterm/bin
with my redhat 8.0 today.   I have no color problem on it.
I'm much confused...

The darkest point here is that I cannot enter Japanese from drawterm.
However, this may help me to do my job in this autumn, teaching something
Windows to our 40 newbies.   Now, I can show them what is Plan 9 from
Win2k at that 'computer' room.

I got netkey for Linux/Windows from Emirtchov, thanks a lot.

Kenji

Re: [9fans] drawterm

[mirtchov]

> I happen to use drawterm resides on /sys/src/cmd/unix/drawterm/bin
> with my redhat 8.0 today.   I have no color problem on it.
> I'm much confused...
>

displaying from linux to linux is fine, but from a proprietary UNIX
(like solaris) to linux it is not.  colormaps are the suspect, but i
haven't investigated :)

andrey

Re: [9fans] drawterm

[okamoto]

> displaying from linux to linux is fine, but from a proprietary UNIX
> (like solaris) to linux it is not.  colormaps are the suspect, but i
> haven't investigated :)

I checked it at home from Win98SE to my home Plan 9 system
using the Windows version under /sys/src/cmd/unix/drawterm/bin,
and found I have no problem other than that I must use three button
emulation. ☺

Kenji

Re: [9fans] drawterm

[Axel Belinfante]

>     SunOS 5.8/sparc/cc  -- compiles, works with a strange palette
>     SunOS 5.8/sparc/gcc -- compiles with extensive modifications to mkfile
>                         -- but fails with:
>                 error: Error 0
>                 ./drawterm: thr_create failed: -1 0 -1 Error 0
>                 abort 26810

> the strange colours and black screens could be due to the fact that all of
> them were displayed remotely on an X11 running on linux.

I'm using on sunos 5.8 a drawterm that I compiled in july 2002;
I made minor modifications: I'm using it in 8bit color mode,
to avoid the strange palette problem I get when running in
24bit colors. I also recall that without modifying, it aborts
when it fails to find the endianness of the X server.

Axel.

Re: [9fans] drawterm

[okamoto]

> I'm using on sunos 5.8 a drawterm that I compiled in july 2002;
> I made minor modifications: I'm using it in 8bit color mode,
> to avoid the strange palette problem I get when running in
> 24bit colors. I also recall that without modifying, it aborts
> when it fails to find the endianness of the X server.

It may be worth to mention that I used 24bpp for RedHat8.0 and 16bpp
for Win98SE.

Kenji

Re: [9fans] drawterm

[boyd, rounin]

> I was looking back in the archives and can't find the messages.
> Did someone recently say they've got a compilable drawterm
> that they're working on?

well i got a windows '98 drawterm paris/ny to work fine.

not that i'm hacking drawterm.

Re: [9fans] drawterm

[Skip Tavakkolian]

> I was looking back in the archives and can't find the messages.
> Did someone recently say they've got a compilable drawterm
> that they're working on?

I think my last update from the sources was about a month ago
and I've built drawterm since then (Win2K/VC 6) without any problems.

Re: [9fans] drawterm

[rob pike, esq.]

> Do we have a drawterm for linux and if so can someone send me
> the source (or a URL to it)?

/sys/src/cmd/unix/drawterm

-rob

[9fans] drawterm

[Sam]

Do we have a drawterm for linux and if so can someone send me
the source (or a URL to it)?

Sam

Re: [9fans] drawterm

[Sam]

nm that.  I should have thought to check the man pages.  I didn't have
a terminal up and for some reason using the cpu server escaped me.

Long days will do that to you, I suppose.

Sam


On Wed, 17 Jul
2002, Sam wrote:

> Do we have a drawterm for linux and if so can someone send me
> the source (or a URL to it)?
>
> Sam
>

[9fans] drawterm

[Russ Cox]

for anyone compiling on solaris, jean mehat
notes that you need to use 
	gcc -lpthread
to link the final result if you use gcc instead
of the sun compilers (in which case you need cc -mt).
apparently without -lpthread, gcc will silently
produce a bogus binary.