Re: [9fans] drawterm crash log

[Charles Forsyth]

>> Or even better to forget drawterm and replace it with Inferno.
> 
> inferno also needs to know how to display natively on OSX.

there often are similar problems: exceeding a big stack with X11 locale data 
for instance.

Re: [9fans] drawterm crash log

[Jeff Sickel]

On Feb 4, 2008, at 4:23 PM, andrey mirtchovski wrote:


Or even better to forget drawterm and replace it with Inferno.


inferno also needs to know how to display natively on OSX.


and until the JIT is working in Inferno on OSX, drawterm has
significantly better throughput...  text redisplay in drawterm's
rio windows, full screen mode is great in drawterm, etc...

Don't get me wrong, Inferno is quite nice--I'm considering
using it for another project though getting a stable port on
a modified Solaris 10 x86, AIX, and broken RHEL would be a pain
compared w/ other options.

Re: [9fans] drawterm crash log

[andrey mirtchovski]

> Or even better to forget drawterm and replace it with Inferno.

inferno also needs to know how to display natively on OSX.

Re: [9fans] drawterm crash log

[Uriel]

On Feb 4, 2008 10:19 PM, andrey mirtchovski <[EMAIL PROTECTED]> wrote:
> of course, it's still better to rewrite the whole osx gui code
> directly in Cocoa, which may happen sooner or later :)

Or even better to forget drawterm and replace it with Inferno.

http://www.caerwyn.com/ipn/2007/10/lab-80-drawterm-plugin.html

uriel

Re: [9fans] drawterm crash log

[andrey mirtchovski]

a cursory look through the code indicates that there may indeed be a
bug in the screen management between writing the bits on a bitmap and
the bitmap to the screen. i have different code for osx which is
rearranged to avoid creating a separate thread for handling the
display, but that code is only for p9p and can't be dropped in
drawterm without a bit of work. with that code we can at least be sure
that we have no races and, chance is, you won't get a crash with it.

of course, it's still better to rewrite the whole osx gui code
directly in Cocoa, which may happen sooner or later :)

[9fans] drawterm crash log

[Jeff Sickel]

Wow, drawterm links in a lot of shared libraries on OS X.

I'll see if I can reproduce this crash, but it occurred while running  
Inferno (emu -v -c1 -g1200x900) in Plan 9 hosted in VMware (convoluted  
yes).  This is the first time I've seen drawterm crash in  
CGContextFlush() (an OS X call) in the last two weeks of using it  
heavily, so hopefully it won't be too difficult to track down.  I did  
go into full screen mode and then hit ctrl-opt to enter back into  
windowed mode just before the crash took place...





Process: drawterm [60302]
Path:/usr/local/bin/drawterm
Identifier:  drawterm
Version: ??? (???)
Code Type:   X86 (Native)
Parent Process:  rc [60301]

Date/Time:   2008-02-04 09:08:50.014 -0600
OS Version:  Mac OS X 10.5.1 (9B18)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xc00794af
Crashed Thread:  5

Thread 0:
0   libSystem.B.dylib   0x9234bfae recvfrom$UNIX2003 + 10
1   drawterm0x00015245 ipread + 741 (devip.c:378)
2   drawterm0xa6ea devbread + 122
3   drawterm  	0x0001b51e ensure + 158 (devssl.c: 
432)
4   drawterm  	0x0001cba3 sslbread + 291 (devssl.c: 
580)
5   drawterm  	0x0001d05d sslread + 333 (devssl.c: 
683)
6   drawterm  	0x000242df kread + 287 (sysfile.c: 
408)
7   drawterm  	0x000243c2 _syspread + 66  
(sysfile.c:436)
8   drawterm  	0x000258f6 sysread + 70 (sysfile.c: 
1072)

9   drawterm0x0004d71c readn + 76 (readn.c:14)
10  drawterm  	0x0004d62f read9pmsg + 47  
(read9pmsg.c:15)
11  drawterm  	0x0002a6b6 exportfs + 678  
(exportfs.c:85)

12  drawterm0x2980 cpumain + 848 (cpu.c:209)
13  drawterm0x1e5c main + 396 (main.c:70)
14  drawterm0x1c86 start + 54

Thread 1:
0   com.apple.HIToolbox 0x92d76e42 _MenuIterReset + 20
1   com.apple.HIToolbox   	0x92d7c526  
HIMenuBarView::DrawSelf(short, __HIShape const*, CGContext*) + 706
2   com.apple.HIToolbox   	0x92d7bf81  
HIView::DrawCacheOrSelf(short, __HIShape const*, CGContext*) + 95
3   com.apple.HIToolbox   	0x92d7bd8a HIView::SendDraw(short,  
OpaqueGrafPtr*, __HIShape const*, CGContext*) + 108
4   com.apple.HIToolbox   	0x92d7b9e6  
HIView::RecursiveDrawComposited(__HIShape const*, unsigned long,  
HIView*, CGContext*, unsigned char, float) + 734
5   com.apple.HIToolbox   	0x92d7bb4a  
HIView::RecursiveDrawComposited(__HIShape const*, unsigned long,  
HIView*, CGContext*, unsigned char, float) + 1090
6   com.apple.HIToolbox   	0x92d7ade8  
HIView::DrawComposited(short, OpaqueGrafPtr*, __HIShape const*,  
unsigned long, HIView*, CGContext*) + 668
7   com.apple.HIToolbox   	0x92d7aafb HIView::Draw(short,  
OpaqueGrafPtr*, unsigned long) + 83
8   com.apple.HIToolbox   	0x92d7aa4b HIView::Render(unsigned  
long, CGContext*) + 45
9   com.apple.HIToolbox   	0x92d83617  
FlushWindowObject(WindowData*, void**, unsigned char) + 749

10  com.apple.HIToolbox 0x92d86a74 _FlushWindow + 78
11  com.apple.HIToolbox 0x92d86a20 HIWindowFlush + 34
12  com.apple.HIToolbox 0x92d799b1 MBarDraw() + 41
13  com.apple.QuickTime 0x90feb686 EndFullScreen_priv + 382
14  com.apple.QuickTime 0x90feb4fc EndFullScreen + 29
15  drawterm  	0x00046088 MainWindowEventHandler +  
1960 (screen.c:300)
16  com.apple.HIToolbox   	0x92d59863  
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,  
HandlerCallRec*) + 1181
17  com.apple.HIToolbox   	0x92d58c9d  
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*,  
HandlerCallRec*) + 405
18  com.apple.HIToolbox   	0x92d58b02  
SendEventToEventTargetWithOptions + 58
19  com.apple.HIToolbox   	0x92d87d56  
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*,  
OpaqueEventRef*, void*) + 1694
20  com.apple.HIToolbox   	0x92d59c1c  
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,  
HandlerCallRec*) + 2134
21  com.apple.HIToolbox   	0x92d58c9d  
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*,  
HandlerCallRec*) + 405
22  com.apple.HIToolbox   	0x92d7508e SendEventToEventTarget +  
52
23  com.apple.HIToolbox   	0x92de2444 ToolboxEventDispatcher +  
86
24  com.apple.HIToolbox   	0x92ddec9e RunApplicationEventLoop  
+ 222
25  drawterm  	0x00044e25 winproc + 725 (screen.c: 
208)

26  drawterm0x0002929a tramp + 58 (posix.c:132)
27  libSystem.B.dylib   0x9232d075 _pthread_start + 321
28  lib

Re: [9fans] drawterm authentication failure

[johnny]

yes, it seems factotum (p9p, i haven't had the chance of having two plan9 
machines, which is really sad in itself) needs the authdom domain name to be 
resolvable, I had this problem until I started using the plan9 box as my local 
dns server (which, by the way is really really awesomly easy). an edit in 
/etc/hosts on linux is kindof a hack...doesn't scale, but it helps too.
Cheers

Re: [9fans] drawterm authentication failure

[Tim Wiess]

> * Tim Wiess ([EMAIL PROTECTED]) wrote:
>> for P9P factotum make sure you have the relevant entries
>> in $PLAN9/ndb/local.
> 
> That did it. Mordor worked, obviously, because the entry is already there by
> default. Embarrassing, isn't it?

great.
some of the references in the man page need to be updated to
reflect the P9P environment vs straight Plan 9, but the text for
-a pretty much explains it.

Re: [9fans] drawterm authentication failure

[Martin Neubauer]

* Tim Wiess ([EMAIL PROTECTED]) wrote:
> for P9P factotum make sure you have the relevant entries
> in $PLAN9/ndb/local.

That did it. Mordor worked, obviously, because the entry is already there by
default. Embarrassing, isn't it?

Thank you all,
Martin

Re: [9fans] drawterm authentication failure

[Tim Wiess]

> I'm fairly certain that factotum is only started once. As I wrote before,
> connecting to mordor works, so it seems I'm experiencing some peculiarity of
> my plan 9 server that apparrently exhibits some subtle difference between
> cpu and drawterm. Perhaps I should just step back a little. Not running
> factotum is a workaround, but i have the feeling that ignoring the issue
> will come around some day and bite me.

for P9P factotum make sure you have the relevant entries
in $PLAN9/ndb/local.

Re: [9fans] drawterm authentication failure

[andrey mirtchovski]

> At this point you're best off putting a packet sniffer on the wire
> and taking a look to see what is really happening (or not happening).

...then let us know what happened so we can finally have an answer
when google asks to "please describe a situation in which you used
tcpdump to diagnose and solve a network problem" ;)

Re: [9fans] drawterm authentication failure

[Lyndon Nerenberg]

On 2007-Oct-23, at 01:35 , Martin Neubauer wrote:


I might be missing something obvious, though.


At this point you're best off putting a packet sniffer on the wire  
and taking a look to see what is really happening (or not happening).

Re: [9fans] drawterm authentication failure

[erik quanstrom]

> > check your profile for a path that has two calls to auth/factotum.
> > 
> > - erik
> 
> I'm fairly certain that factotum is only started once. As I wrote before,

by profile, i mean lib/profile on your plan 9 box.  sorry for being unclear
generally, there is a different path through lib/profile for drawterm calls.

this is part of my lib/profile from home

case cpu
if (test -e /mnt/term/mnt/wsys) {
# rio already running
wsys = /mnt/term^`{cat /mnt/term/env/wsys}
bind -a /mnt/term/mnt/wsys /dev
if(test -f /mnt/term/dev/label)
echo -n $sysname > /mnt/term/dev/label
}
bind /mnt/term/dev/cons /dev/cons
bind /mnt/term/dev/consctl /dev/consctl
bind -a /mnt/term/dev /dev
prompt=('; ' '  ')
fn cpu%{ $* }
news
if (! test -e /mnt/term/mnt/wsys) {
# cpu call from drawterm
plumber
auth/factotum
upas/fs -lb >$home/log/upasfs.log>[2=1]
exec rio
}

- erik

Re: [9fans] drawterm authentication failure

[Martin Neubauer]

* erik quanstrom ([EMAIL PROTECTED]) wrote:
> i think there's something else going on.  on the home machine i run p9p on,
> i do run factotum with drawterm.
> 
>   ; ps auxwww|grep factotum
>   quanstro  4972  0.0  0.1  43648   360 ?Sl   Sep13   0:00 
> factotum
>   quanstro  4975  0.0  0.0  67880   204 ?Sl   Sep13   0:03 
> 9pserve -u unix!/tmp/ns.quanstro.:0/factotum
>   quanstro  2202  0.0  0.2   1676   536 pts/9S+   09:26   0:00 grep 
> factotum
> 
> check your profile for a path that has two calls to auth/factotum.
> 
> - erik

I'm fairly certain that factotum is only started once. As I wrote before,
connecting to mordor works, so it seems I'm experiencing some peculiarity of
my plan 9 server that apparrently exhibits some subtle difference between
cpu and drawterm. Perhaps I should just step back a little. Not running
factotum is a workaround, but i have the feeling that ignoring the issue
will come around some day and bite me.

Thanks anyway,
Martin

Re: [9fans] drawterm authentication failure

[erik quanstrom]

> I had indeed factotum running. after killing the process I could connect to
> the plan 9 server. Looks like I've implemented some authentication self hate
> on my network.
> 
> Some further digging and a peek at the archives showed that upon connecting
> the following lines get appended to /mnt/factotum/log:
> 
> 287: no key matches proto=9psk1 role=server dom?
> 287: failure no key matches proto=9psk1 role=server dom?
> 
> Also, whenever I use drawterm without factotum (which succeeds) I get
> prompted for the secstore key twice. That seems a little odd to me.

i think there's something else going on.  on the home machine i run p9p on,
i do run factotum with drawterm.

; ps auxwww|grep factotum
quanstro  4972  0.0  0.1  43648   360 ?Sl   Sep13   0:00 
factotum
quanstro  4975  0.0  0.0  67880   204 ?Sl   Sep13   0:03 
9pserve -u unix!/tmp/ns.quanstro.:0/factotum
quanstro  2202  0.0  0.2   1676   536 pts/9S+   09:26   0:00 grep 
factotum

check your profile for a path that has two calls to auth/factotum.

- erik

Re: [9fans] drawterm authentication failure

[Martin Neubauer]

* sqweek ([EMAIL PROTECTED]) wrote:
>  I only ever muddled about with auth when I was getting my plan9 box
> up so I may be misremembering, but isn't gettickets related to
> factotum?
>  Is there a factotum running on the host you're drawterming from or
> are you just relying on what drawterm provides in that respect? Might
> be worth a try.
> -sqweek

I had indeed factotum running. after killing the process I could connect to
the plan 9 server. Looks like I've implemented some authentication self hate
on my network.

Some further digging and a peek at the archives showed that upon connecting
the following lines get appended to /mnt/factotum/log:

287: no key matches proto=9psk1 role=server dom?
287: failure no key matches proto=9psk1 role=server dom?

Also, whenever I use drawterm without factotum (which succeeds) I get
prompted for the secstore key twice. That seems a little odd to me.

Martin

Re: [9fans] drawterm authentication failure

[erik quanstrom]

> I'm not sure that's the issue. The host names are mutually known (as of last
> night, admittedly) and cpu with mutually unknown host names succeeds.
> 
> I might be missing something obvious, though.
> 
>   Martin

snoopy is your friend!  

- erik

Re: [9fans] drawterm authentication failure

[sqweek]

On 10/23/07, Martin Neubauer <[EMAIL PROTECTED]> wrote:
> I've set up a new auth/cpu/fossil server via maht's make_cpuauth warlock.
> Things went smoothly for the most part, but if I try to connect to it
> drawterm does nothing for quite some time and finally prints:
>
> cpu: can't authenticate: plan9host: auth_proxy rpc: p9any client get tickets: 
> p9sk1: gettickets: Operation timed out

 I only ever muddled about with auth when I was getting my plan9 box
up so I may be misremembering, but isn't gettickets related to
factotum?
 Is there a factotum running on the host you're drawterming from or
are you just relying on what drawterm provides in that respect? Might
be worth a try.
-sqweek

Re: [9fans] drawterm authentication failure

[Martin Neubauer]

* erik quanstrom ([EMAIL PROTECTED]) wrote:
> > I did specify the authserver (it's the same machine). Nat shouldn't be a
> > problem, because all machines in question are connected through a single
> > hub. It's just that cpu works, drawterm from the system next to it doesn't.
> > Conversely, drawterm to mordor, which lies behind a NAT'ing router, gives no
> > trouble.
> > 
> 
> sounds like a name resolution problem.
> 
> - erik

I'm not sure that's the issue. The host names are mutually known (as of last
night, admittedly) and cpu with mutually unknown host names succeeds.

I might be missing something obvious, though.

Martin

Re: [9fans] drawterm authentication failure

[erik quanstrom]

> I did specify the authserver (it's the same machine). Nat shouldn't be a
> problem, because all machines in question are connected through a single
> hub. It's just that cpu works, drawterm from the system next to it doesn't.
> Conversely, drawterm to mordor, which lies behind a NAT'ing router, gives no
> trouble.
> 

sounds like a name resolution problem.

- erik

Re: [9fans] drawterm authentication failure

[Martin Neubauer]

* andrey mirtchovski ([EMAIL PROTECTED]) wrote:
> looks like your drawterm can't connect to the authentication server's
> port. are you specifying '-a' on the command line? do you have
> anything filtering port 567? are you behind a nat and have to forward
> it?

I did specify the authserver (it's the same machine). Nat shouldn't be a
problem, because all machines in question are connected through a single
hub. It's just that cpu works, drawterm from the system next to it doesn't.
Conversely, drawterm to mordor, which lies behind a NAT'ing router, gives no
trouble.

Re: [9fans] drawterm authentication failure

[andrey mirtchovski]

looks like your drawterm can't connect to the authentication server's
port. are you specifying '-a' on the command line? do you have
anything filtering port 567? are you behind a nat and have to forward
it?

On 10/22/07, Martin Neubauer <[EMAIL PROTECTED]> wrote:
> I've set up a new auth/cpu/fossil server via maht's make_cpuauth warlock.
> Things went smoothly for the most part, but if I try to connect to it
> drawterm does nothing for quite some time and finally prints:
>
> cpu: can't authenticate: plan9host: auth_proxy rpc: p9any client get tickets: 
> p9sk1: gettickets: Operation timed out
>
> I don't quite have a clue what's going on (or, rather, not going on), but as
> I can boot terminals off the system and cpu in from other plan 9 hosts it
> seems that drawterm expects some network service cpu doesn't. Also, I dont
> think my drawterm is broken. I can connect to mordor just fine, for example.
>
> Baffled,
> Martin
>
>

[9fans] drawterm authentication failure

[Martin Neubauer]

I've set up a new auth/cpu/fossil server via maht's make_cpuauth warlock.
Things went smoothly for the most part, but if I try to connect to it
drawterm does nothing for quite some time and finally prints:

cpu: can't authenticate: plan9host: auth_proxy rpc: p9any client get tickets: 
p9sk1: gettickets: Operation timed out

I don't quite have a clue what's going on (or, rather, not going on), but as
I can boot terminals off the system and cpu in from other plan 9 hosts it
seems that drawterm expects some network service cpu doesn't. Also, I dont
think my drawterm is broken. I can connect to mordor just fine, for example.

Baffled,
Martin

Re: [9fans] drawterm segfault

[johnny]

I'm really sorry about the 40+ megabyte attachment the I guess finally passed 
through!
I've recompiled drawterm from a pretty recent cvs for the debugging symbols and 
it doesn't happen, so I guess something in X might not be compatible or hell 
knows.
though I'll get to the sunos later this week, remains that one.
Cheers

Re: [9fans] drawterm segfault

[johnny]

That worked. thanks.
The core file is huge, I've put out a bzipped version of it on 
http://sorosj.hd.free.fr/drawterm.core.bz2 .
Cheers!

Re: [9fans] drawterm segfault

[Sander van Dijk]

On 10/14/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I would like to be able to say something about this core file everyone seems 
> to deem more reliable in debugging than gdb, but I don't really know how I 
> can obtain it. I'm running ubuntu 7.10 (gutsy).

Run "ulimit -c unlimited" in your shell before running drawterm, or
put it somewhere in your profile. See bash(1) for details.

Greetings, Sander.

Re: [9fans] drawterm segfault

[johnny]

you were right, that was just one thread.
Now I used thread apply all bt command to get the backtrace.
Here is what I got:

= Begin gdb output =
$ gdb
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
(gdb) attach 13176
Attaching to process 13176
Reading symbols from /usr/bin/drawterm...(no debugging symbols found)...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Reading symbols from /usr/lib/libX11.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libX11.so.6
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...(no debugging symbols 
found)...done.
[Thread debugging using libthread_db enabled]
[New Thread -1210783072 (LWP 13176)]
[New Thread -1250116720 (LWP 13183)]
[New Thread -1241724016 (LWP 13182)]
[New Thread -121312 (LWP 13179)]
[New Thread -1224938608 (LWP 13178)]
[New Thread -1216283760 (LWP 13177)]
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /usr/lib/libXau.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXau.so.6
Reading symbols from /usr/lib/libXdmcp.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libXdmcp.so.6
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_compat.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_compat.so.2
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
Reading symbols from /lib/tls/i686/cmov/libnss_nis.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_nis.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_files.so.2...(no debugging 
symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_files.so.2
Reading symbols from /usr/lib/libXcursor.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXcursor.so.1
Reading symbols from /usr/lib/libXrender.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libXrender.so.1
Reading symbols from /usr/lib/libXfixes.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libXfixes.so.3
(no debugging symbols found)
0xe410 in __kernel_vsyscall ()
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1224938608 (LWP 13178)]
0x08086210 in ?? ()
(gdb) thread apply all bt

Thread 6 (Thread -1216283760 (LWP 13177)):
#0  0xe410 in __kernel_vsyscall ()
#1  0xb7e24647 in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7efb839 in ?? () from /usr/lib/libX11.so.6
#3  0x080e1178 in ?? ()
#4  0x0001 in ?? ()
#5  0x in ?? ()
#6  0xb7fabb2c in ?? () from /usr/lib/libX11.so.6
#7  0x080e0b60 in ?? ()
#8  0xb7fabb2c in ?? () from /usr/lib/libX11.so.6
#9  0x080e0b60 in ?? ()
#10 0x in ?? ()

Thread 5 (Thread -1224938608 (LWP 13178)):
#0  0x08086210 in ?? ()
#1  0x in ?? ()

Thread 4 (Thread -121312 (LWP 13179)):
#0  0xe410 in __kernel_vsyscall ()
#1  0xb7eaf676 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/tls/i686/cmov/libpthread.so.0
#2  0x0805d8fc in ?? ()
#3  0x08107420 in ?? ()
#4  0x08107408 in ?? ()
#5  0xb67ccd48 in ?? ()
#6  0x081065dc in ?? ()
#7  0x in ?? ()

Thread 3 (Thread -1241724016 (LWP 13182)):
#0  0xe410 in __kernel_vsyscall ()
#1  0xb7eaf676 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/tls/i686/cmov/libpthread.so.0
#2  0x0805d8fc in ?? ()
#3  0x0810e8f0 in ?? ()
#4  0x0810e8d8 in ?? ()
#5  0xb5fcbce8 in ?? ()
#6  0x080d2ec4 in ?? ()
#7  0x080d2e80 in ?? ()
---Type  to continue, or q  to quit---
#8  0x0805b710 in ?? ()
#9  0xb5fcbd18 in ?? ()
#10 0x08058f10 in ?? ()
#11 0x080d2ec4 in ?? ()
#12 0x2e60 in ?? ()
#13 0xb5fcbd08 in ?? ()
#14 0x0808de51 in ?? ()
#15 0x080d2e80 in ?? ()
#16 0x0014 in ?? ()
#17 0x in ?? ()

Thread 2 (Thread -1250116720 (LWP 13183)):
#0  0xe410 in __kernel_vsyscall ()
#1  0xb7eaf676 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/tls/i686/cmov/libpthread.so.0
#2  0x0805d8fc in ?? ()
#3  0x08111f88 in ?? ()
#4  0x08111f70 in ?? ()
#5  0xb57cae28 in ?? ()
#6  0x080bcf58 in ?? ()
#7  0x in ?? ()

Thread 1 (Thread -1210783072 (LWP 13176)):
#0  0xe410 in __kernel_vsyscall

Re: [9fans] drawterm segfault

[erik quanstrom]

> Continuing.
> [New Thread -1250161776 (LWP 9379)]
> [New Thread -1261585520 (LWP 9380)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1261585520 (LWP 9380)]
> 0x08086210 in ?? ()
> (gdb) bt
> #0  0x08086210 in ?? ()
> #1  0x in ?? ()

you may be debugging the wrong thread.  it's been a while
since i've fired up gdb, but i think the command is "thread."
you'll need to do a backtrace in each thread.  alternatively,
if you have a core file, p9p core may give better output.

- erik

Re: [9fans] drawterm segfault

[johnny]

Continuing.
[New Thread -1250161776 (LWP 9379)]
[New Thread -1261585520 (LWP 9380)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1261585520 (LWP 9380)]
0x08086210 in ?? ()
(gdb) bt
#0  0x08086210 in ?? ()
#1  0x in ?? ()

= end gdb output =

I hope this helps. Thanks.

Re: [9fans] drawterm segfault

[andrey mirtchovski]

does it happen when you open this specific file, or any other file
from src/johnny? if it's only wc.c that kills it, does it kill it when
you open the file directly (acme wc.c)? if it's wc.c, then is there
something special that you have in that file, special french
characters, perhaps? can we see wc.c?

does it happen when you start acme with a single column (acme -c1)?

i just tried with /sys/src/cmd/wc.c copied in $home/src/johnny and it
doesn't crash for me under X11 and OSX, but that doesn't mean much :)

Re: [9fans] drawterm segfault

[Skip Tavakkolian]

> sorry for my ignorance, but how do I compile drawterm with debug symbols?
> Thank you for the help.

Make.unix shows that -g is already supplied to gcc for linux. what
does gdb show for backtrace?

Re: [9fans] drawterm segfault

[cinap_lenrek]

passing -g option to gcc? edit makefile or CFLAGS="-g" i guess.

cinap
--- Begin Message ---
sorry for my ignorance, but how do I compile drawterm with debug symbols?
Thank you for the help.--- End Message ---

Re: [9fans] drawterm segfault

[johnny]

sorry for my ignorance, but how do I compile drawterm with debug symbols?
Thank you for the help.

Re: [9fans] drawterm segfault

[cinap_lenrek]

could you make a stacktrace with gdb please? 

% gdb drawterm drawterm.core
(gdb) bt
...

drawterm should have been compiled with  debug
symbols.

cinap
--- Begin Message ---
Hi!
I've had a strange segfault with drawterm lately. This is with the latest 
binaries from swtch.com/drawterm.
I have both tried it on sunos and linux, and have the same segfault happen.
The segfault occurs when I'm using acme. I open 3 new windows, and boom, 
drawterm vanishes. The reammy strange part in it is that it only happens when I 
open three specific windows in a specific order.
1, start drawterm, using my auth+cpu+fs server at home
2, open an acme window in $home
2, enter directories src/johnny with right-click with mouse, then open file 
wc.c with right-click, at this point my drawterm window disappears and all I 
see in the terminal I started drawterm from is: Segmentation fault.
This strangely doesn't happen when I open any other directories, only if i open 
these in the specified order, when acme starts.
Cheers!
Johnny--- End Message ---

[9fans] drawterm segfault

[johnny]

Hi!
I've had a strange segfault with drawterm lately. This is with the latest 
binaries from swtch.com/drawterm.
I have both tried it on sunos and linux, and have the same segfault happen.
The segfault occurs when I'm using acme. I open 3 new windows, and boom, 
drawterm vanishes. The reammy strange part in it is that it only happens when I 
open three specific windows in a specific order.
1, start drawterm, using my auth+cpu+fs server at home
2, open an acme window in $home
2, enter directories src/johnny with right-click with mouse, then open file 
wc.c with right-click, at this point my drawterm window disappears and all I 
see in the terminal I started drawterm from is: Segmentation fault.
This strangely doesn't happen when I open any other directories, only if i open 
these in the specified order, when acme starts.
Cheers!
Johnny

Re: [9fans] drawterm for macos

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Control and clover give you 2 more buttons, although I have my  
version hacked to use F1-F3 as mouse buttons on my macbook pro.  I've  
not had any problems with cut-and-paste.
My biggest problem with it is that it doesn't do window-on-top focus  
control quite right.  I'd love for some mac programmer to fix my bad  
code.


Paul

On 23-Jun-07, at 6:57 AM, Steve Simon wrote:


I have lost track of the development of drawterm for macos,
the x11 based drawterm was a bit clunky but did support
3 button mouse emulation and cut and paste between the mac's
snarf buffer and drawterms.

The native draterm is much snappier but the copy I needs an
external mouse to get three buttons (we have a powerbook pro)
and cannot cut and paste.

Anyone working on this / already made these changes? (asks  
hopfully :-)

if so where do I get a binary? The mac I have is my wifes
work machine, used for DTP box (I.E. no c compilers).

-Steve


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGfTnmpJeHo/Fbu1wRAuX/AKDK3QgC6VMJGOx+TqjxAuJRVYrDDQCfZrxT
9kpKgz473IHQ0X1rsHd4jHw=
=WJMJ
-END PGP SIGNATURE-

[9fans] drawterm for macos

[Steve Simon]

I have lost track of the development of drawterm for macos,
the x11 based drawterm was a bit clunky but did support
3 button mouse emulation and cut and paste between the mac's
snarf buffer and drawterms.

The native draterm is much snappier but the copy I needs an
external mouse to get three buttons (we have a powerbook pro)
and cannot cut and paste.

Anyone working on this / already made these changes? (asks hopfully :-)
if so where do I get a binary? The mac I have is my wifes
work machine, used for DTP box (I.E. no c compilers).

-Steve

Re: [9fans] drawterm sigsegv on linux 2.6.18

[Russ Cox]

> When I do a "du -a /" on a plan9 cpu server via drawterm,  drawterm
> gets a sigsegv after a while.  Gdb  reports that the sigsegv arrived
> when tas.c:9 (inline assembler code to do test and set) is called.  I
> cannot see anything wrong with the tas code though.

The problem isn't in tas but its caller -- note that tas
is being passed a null pointer.  Thanks for the gdb 
stack trace, which was very helpful.

The fix this change to kern/devfs-posix.c (a similar
change applies to kern/devfs-win32.c too):

cname = addelem(cname, name[i]);
wq->qid[i] = nc->qid;
}
-   nc->name = nil;
-   cnameclose(cname);
+   nc->name = cname;
if(i != nname){
cclose(nc);
wq->clone = nil;

The bug is only triggered when traversing paths 
more than 16 levels deep on the local machine.

Russ

[9fans] drawterm sigsegv on linux 2.6.18

[onyx.peridot]

Hi 9fans,

When I do a "du -a /" on a plan9 cpu server via drawterm,  drawterm
gets a sigsegv after a while.  Gdb  reports that the sigsegv arrived
when tas.c:9 (inline assembler code to do test and set) is called.  I
cannot see anything wrong with the tas code though.

The following is what gdb reports:

(gdb) run
Starting program: /home/mbc/bin/drawterm -u mbc -a bootes -c bootes
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1211438592 (LWP 14554)]
[New Thread -1216996432 (LWP 14557)]
[New Thread -1225864272 (LWP 14558)]
[New Thread -1236272208 (LWP 14559)]
[New Thread -1244660816 (LWP 14560)]
[New Thread -1253049424 (LWP 14561)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211438592 (LWP 14554)]
0x08091dae in tas (x=0x0) at tas.c:9
9   __asm__("movl   $1, %%eax\n\t"
(gdb) bt
#0  0x08091dae in tas (x=0x0) at tas.c:9
#1  0x0808c741 in canlock (lk=0x0) at lock.c:7
#2  0x0808c764 in lock (lk=0x0) at lock.c:16
#3  0x0804f007 in incref (r=0x0) at chan.c:100
#4  0x080645b6 in fswalk (c=0x812b078, nc=0x812af68, name=0x8124ce8,
nname=1) at devfs-posix.c:152
#5  0x0804fa13 in walk (cp=0xbffe3850, names=0x8124ca8, nnames=17,
nomount=0, nerror=0xbffe3854) at chan.c:798
#6  0x08050367 in namec (
aname=0x81262d8 "./sys/block/sdb/sdb1/subsystem/sdb/sdb1/subsystem/
sdb/sdb1/subsystem/sdb/sdb1/subsystem/sdb/queue/iosched", amode=0,
omode=0, perm=0) at chan.c:1145
#7  0x08059034 in _sysstat (
name=0x81262d8 "./sys/block/sdb/sdb1/subsystem/sdb/sdb1/subsystem/
sdb/sdb1/subsystem/sdb/sdb1/subsystem/sdb/queue/iosched",
buf=0x812aabc, n=115) at sysfile.c:614
#8  0x080590d6 in sysstat (
name=0x81262d8 "./sys/block/sdb/sdb1/subsystem/sdb/sdb1/subsystem/
sdb/sdb1/subsystem/sdb/sdb1/subsystem/sdb/queue/iosched",
buf=0x812aabc "queue", n=115) at sysfile.c:1113
#9  0x080898ff in dirstat (
name=0x81262d8 "./sys/block/sdb/sdb1/subsystem/sdb/sdb1/subsystem/
sdb/sdb1/subsystem/sdb/sdb1/subsystem/sdb/queue/iosched") at dirstat.c:
23
#10 0x0806d422 in file (parent=0x81268c0, name=0x80ff2a2 "iosched") at
exportfs.c:287
#11 0x0806ed28 in Xwalk (t=0x80ed8a0) at exportsrv.c:204
#12 0x0806dc9c in exportfs (fd=7, msgsz=8240) at exportfs.c:102
#13 0x0804bd34 in cpumain (argc=7, argv=0xbffe40a4) at cpu.c:208
#14 0x0804a867 in main (argc=7, argv=0xbffe40a4) at main.c:68
(gdb)

Re: [9fans] drawterm under linux keyboard settings

[Gabriel Diaz]

hello

thanks it's working now,

slds

gabi


On 3/17/07, Felipe Bichued <[EMAIL PROTECTED]> wrote:

Hello Gabriel,

I had the same problem, but hopefully I fixed it a couple months ago.
It was just a matter of remapping the dead keys back do the Latin-1
character space.

Try compiling drawterm (works for Inferno and p9p too) with the new
keysym2ucs-x11.c that I've attached. It looks a bit hackish though.

Regards.

On 3/17/07, Gabriel Diaz <[EMAIL PROTECTED]> wrote:
> Hello
>
> I'm trying to type spanish chars using drawterm-linux, but i'm unable to do 
it.
>
> All linux programs work as expected, i can type ó,í and the like, but
> plan9ports and drawterm doesn't work. (alt+`+o or ` alone doesn't
> work)
>
> Running drawterm-windows under wine emulator works, i can type á
> without using the alt-key.
>
> Driver "keyboard"
> Option  "CoreKeyboard"
> Option"XkbRules"  "xorg"
> Option"XkbModel"  "pc105"
> Option"XkbLayout" "es,en"
> Option "XkbVariant"  ",nodeadkeys,"
>
> i tried with kdb driver and with more options combinations like
>
> Driver "kbd"
> Option "Xkblayout "es"
>
> this is the X-window version:
> X Window System Version 7.1.99.903 (7.2.0 RC 3)
>
> thanks all,
>
> gabi
>


--
Felipe

[9fans] drawterm under linux keyboard settings

[Gabriel Diaz]

Hello

I'm trying to type spanish chars using drawterm-linux, but i'm unable to do it.

All linux programs work as expected, i can type ó,í and the like, but
plan9ports and drawterm doesn't work. (alt+`+o or ` alone doesn't
work)

Running drawterm-windows under wine emulator works, i can type á
without using the alt-key.

Driver "keyboard"
Option  "CoreKeyboard"
Option"XkbRules"  "xorg"
Option"XkbModel"  "pc105"
Option"XkbLayout" "es,en"
Option "XkbVariant"  ",nodeadkeys,"

i tried with kdb driver and with more options combinations like

Driver "kbd"
Option "Xkblayout "es"

this is the X-window version:
X Window System Version 7.1.99.903 (7.2.0 RC 3)

thanks all,

gabi

Re: [9fans] drawterm-osx-intel cut/paste bug

[Russ Cox]

Looks like drawterm leaves stuff in the cut buffer.
Go to terminal or Firefox and cut a dozen lines.
Go to drawterm and paste.
Go back to terminal or Firefox and cut one line.
Go back to drawterm and paste and see the new bit
overlayed with the old stuff.  Looks like someones
forgot to check a lenght and is instead reading
until it finds a newline.  Don't really have any
experience with the mac window stuff, but that's
what it smells like me.


Fixed in CVS, thanks to Andrey.

Russ

[9fans] drawterm-osx-intel cut/paste bug

[Brantley Coile]

Looks like drawterm leaves stuff in the cut buffer.
Go to terminal or Firefox and cut a dozen lines.
Go to drawterm and paste.
Go back to terminal or Firefox and cut one line.
Go back to drawterm and paste and see the new bit
overlayed with the old stuff.  Looks like someones
forgot to check a lenght and is instead reading
until it finds a newline.  Don't really have any
experience with the mac window stuff, but that's
what it smells like me.

Look at all those gotos.  Must be the FORTRAN version of the email.

 BC
 

[9fans] drawterm/gui-osx/screen.c--new mouse problems

[Gregory Pavelcak]

I saw some changes to this file when I did cvs co today so I
rebuilt drawterm.  With the latest drawterm, I can get
unicode characters with the Alt key; I couldn't before.
Unfortunately, however, I can no longer select ranges of
text in Acme by holding down B1 and moving the mouse, nor
can I select an entry from rio menus—the menu disappears
when the pointer moves.

This is happening on a powerpc mac mini with OSX 10.4 and a
usb Logitech Trackball.

Greg

Re: [9fans] drawterm cpunote

[Russ Cox]

this code in kern/devcons.c

case Qcpunote:
sleep(&up->sleep, return0, nil);

does it hang a blockingslave in exportfs, pending a read?
for drawterm, the net effect is that rmtnoteproc in
cpu.c gets an error when drawterm goes away which
then kills rc. correct?


sounds right to me, though i'm not 100%
sure that the failed read on cpunote is what
kills everything off.

in plan 9 the cpu client relays notes via that
file, but since drawterm doesn't have notes
to relay, it just makes the reads block until it exits.

russ

[9fans] drawterm cpunote

[Skip Tavakkolian]

this code in kern/devcons.c 

case Qcpunote:
sleep(&up->sleep, return0, nil);

does it hang a blockingslave in exportfs, pending a read?
for drawterm, the net effect is that rmtnoteproc in
cpu.c gets an error when drawterm goes away which
then kills rc. correct?

Re: Re: [9fans] drawterm errors mac os x

[David Leimbach]

On 8/23/06, Russ Cox <[EMAIL PROTECTED]> wrote:

Are the window borders green or blue when you resize them?





They are green.


On 8/23/06, David Leimbach <[EMAIL PROTECTED]> wrote:
> Was just trying to run a few programs and got
>
> X error: error code=255, request_code=255, minor=255
>
> over and over again, now my session has gone unresponsive.
>
> Also still looking for a way to make the default windows white instead
> of yellow.  Not sure if that's easy or not though.
>
>

Re: [9fans] drawterm errors mac os x

[Russ Cox]

Are the window borders green or blue when you resize them?



On 8/23/06, David Leimbach <[EMAIL PROTECTED]> wrote:

Was just trying to run a few programs and got

X error: error code=255, request_code=255, minor=255

over and over again, now my session has gone unresponsive.

Also still looking for a way to make the default windows white instead
of yellow.  Not sure if that's easy or not though.

[9fans] drawterm errors mac os x

[David Leimbach]

Was just trying to run a few programs and got

X error: error code=255, request_code=255, minor=255

over and over again, now my session has gone unresponsive.

Also still looking for a way to make the default windows white instead
of yellow.  Not sure if that's easy or not though.

[9fans] drawterm on freebsd

[Zoran Kolic]

Hi all!
I would like to connect plan9
server via drawterm on freebsd
6.1 amd box.
Does someone on the list knows
how to compile the source to
build correctly? On this 64 bit
system it goes with error. Some
drawterm-freebsd file doesn't
work neither.
I could provide error message, if
needed for debuging.
For case that amd64 is lost for
drawterm, will be nice to hear
exact steps for i386 port.
I read digest, so sorry for delay.
Best regards

 Zoran

Re: [9fans] Drawterm and Ubuntu

[lucio]

> run /sys/lib/newuser to get a real profile.

Not a bad idea, a ten year old profile could probably benefit from
refreshing :-)

++L

Re: [9fans] Drawterm and Ubuntu

[lucio]

>   rio: can't open display: initdisplay: /dev/draw/new: unknown device in 
> # filename

That slipped past my fingers.  I think the answer lurks in my
bin/rc/riostart or similar, although I have not identified it yet.
Sorry about the noise.

++L

Re: [9fans] Drawterm and Ubuntu

[Russ Cox]

I get:

rio: can't open display: initdisplay: /dev/draw/new: unknown device in 
# filename

Is this expected?  Is there a cure?


run /sys/lib/newuser to get a real profile.

[9fans] Drawterm and Ubuntu

[lucio]

I get: 

rio: can't open display: initdisplay: /dev/draw/new: unknown device in 
# filename

Is this expected?  Is there a cure?

This is Ubuntu 6.06, drawterm-linux, from swtch.com, is invoked with
-c and -a options (only).


++L

Re: [9fans] drawterm configuration

[Rodolfo (kix)]

Thanks ron.

Now all is ok.2006/6/12, Ronald G Minnich :
Francisco J Ballesteros wrote:> can´t you run cmd and then drawterm from there?>> On 6/11/06, Rodolfo (kix) <[EMAIL PROTECTED]> wrote:>
>> Hi!  where is the drawterm configuration in windows? I am connecting to a new>> server but the drawterm continues conecting to the old server and I>> need to>> use -c / -a options
 -->> Rodolfo García "kix"I make a shortcut on the desktop and put the parameters in there.ron-- Rodolfo García "kix"

Re: [9fans] drawterm configuration

[Ronald G Minnich]

Francisco J Ballesteros wrote:

can´t you run cmd and then drawterm from there?

On 6/11/06, Rodolfo (kix) <[EMAIL PROTECTED]> wrote:


Hi!

 where is the drawterm configuration in windows? I am connecting to a new
server but the drawterm continues conecting to the old server and I 
need to

use -c / -a options

--
Rodolfo García "kix"


I make a shortcut on the desktop and put the parameters in there.

ron

Re: [9fans] drawterm configuration

[Rodolfo (kix)]

2006/6/11, Skip Tavakkolian <[EMAIL PROTECTED]>:
> but if I make double> click to drawterm I "drawterm" to my oldnode.change your drawterm shortcut to include the -a and -c flags in thethe "target" field.
I am doing double click in the application, not in a shortcut ;-)

And the drawterm.exe connects with my app  um X

c:\> nslookup www
www.thekix.com

The "problem" is the DNS, is appending my domain name. Then drawterm connects to my old machine.

Sorry for the inconvenience.

Thanks.
> I cannot find the word in the windows registry, in configuration files, ...
drawterm doesn't use windows registry.-- Rodolfo García "kix"

Re: [9fans] drawterm configuration

[Skip Tavakkolian]

> but if I make double
> click to drawterm I "drawterm" to my oldnode.

change your drawterm shortcut to include the -a and -c flags in the
the "target" field.

> I cannot find the word in the windows registry, in configuration files, ...

drawterm doesn't use windows registry.  

Re: [9fans] drawterm configuration

[Rodolfo (kix)]

Yes,

I can run cmd and then "drawterm.exe -a mynewnode" but if I make double click to drawterm I "drawterm" to my oldnode.

I am looking for the "oldnode" to change it to "mynewnode".

I cannot find the word in the windows registry, in configuration files, ...

2006/6/11, Francisco J Ballesteros <[EMAIL PROTECTED]>:
can´t you run cmd and then drawterm from there?On 6/11/06, Rodolfo (kix) <[EMAIL PROTECTED]> wrote:> Hi!>>  where is the drawterm configuration in windows? I am connecting to a new
> server but the drawterm continues conecting to the old server and I need to> use -c / -a options>> --> Rodolfo García "kix"-- 
Rodolfo García "kix"

Re: [9fans] drawterm configuration

[Skip Tavakkolian]

> can´t you run cmd and then drawterm from there?
> 
> On 6/11/06, Rodolfo (kix) <[EMAIL PROTECTED]> wrote:
>> Hi!
>>
>>  where is the drawterm configuration in windows? I am connecting to a new
>> server but the drawterm continues conecting to the old server and I need to
>> use -c / -a options

Also you can build a shortcut and set the -a and -c args there.

Re: [9fans] drawterm configuration

[Francisco J Ballesteros]

can´t you run cmd and then drawterm from there?

On 6/11/06, Rodolfo (kix) <[EMAIL PROTECTED]> wrote:

Hi!

 where is the drawterm configuration in windows? I am connecting to a new
server but the drawterm continues conecting to the old server and I need to
use -c / -a options

--
Rodolfo García "kix"

[9fans] drawterm configuration

[Rodolfo (kix)]

Hi!

where is the drawterm configuration in windows? I am connecting to a
new server but the drawterm continues conecting to the old server and I
need to use -c / -a options-- Rodolfo García "kix"

Re: [9fans] Drawterm Solaris 8.5 (long)

[Noah Evans]

That binary made my day. Thanks. NoahOn 4/29/06, Axel Belinfante <[EMAIL PROTECTED]
> wrote:I wrote:> I've just checked out the latest drawterm from cvs,
> I have gotten it to compile (and so far it seems to run) on> SunOS zamenhof 5.8 Generic_117350-22 sun4u sparc SUNW,Sun-Blade-100The (gzip-ed) executable can be found at  
http://plan9.cs.utwente.nl/dt2k-sunos5_8.gzAxel.

Re: [9fans] Drawterm Solaris 8.5 (long)

[Axel Belinfante]

I wrote:
> I've just checked out the latest drawterm from cvs,
> I have gotten it to compile (and so far it seems to run) on
> SunOS zamenhof 5.8 Generic_117350-22 sun4u sparc SUNW,Sun-Blade-100

The (gzip-ed) executable can be found at
  http://plan9.cs.utwente.nl/dt2k-sunos5_8.gz

Axel.

[9fans] Drawterm Solaris 8.5 (long)

[Axel Belinfante]

> yeah, blah... the version I had on my old sun has got the blues too.
> 
> h... compile the latest version with CONF=unix make
> gives the following errors:
> 
> gcc: unrecognized option `-pthread'
> In file included from ./include/u.h:1,
>  from main.c:1:
> ./include/dtos.h:10:3: #error "Define an OS"
> In file included from main.c:2:
[...]

I've just checked out the latest drawterm from cvs,
and out-od-the-box I see the same errors.

I have gotten it to compile (and so far it seems to run) on
SunOS zamenhof 5.8 Generic_117350-22 sun4u sparc SUNW,Sun-Blade-100

I have compiled using sun cc: Sun WorkShop 6 2000/04/07 C 5.1
and gnu make (3.79)
I compiled (from es) using:  make 'CONF=unix' 'AUDIO=none'

I made a few changes to make it compile,
and added a new directory posix-sun4u
populated with stuff elsewhere from drawterm or maybe p9p
(I populated it in nov 2005; did not look back where I got stuff)

I did not make changes to shut up compiler warnings;
I've attached a 'typescript' showing them in case someone
wants to look at them.

I also attach a diff and, one by one, the files from posix-sun4u :

posix-sun4u/Makefile
posix-sun4u/getcallerpc.c
posix-sun4u/md5block.c
posix-sun4u/os.h
posix-sun4u/sha1block.c
posix-sun4u/tas.s

I did not look at the audio stuff; I guess it should be possible
to add something sun specific.
In the past I used the trick described in
 http://plan9.cs.utwente.nl/audio-sun-drawterm/
(the code linked from there is awful but got the job done)

Hope this helps,
Axel.
Index: Make.unix
===
RCS file: /cvs/drawterm/Make.unix,v
retrieving revision 1.11
diff -b -u -w -r1.11 Make.unix
--- Make.unix   8 Mar 2006 04:24:23 -   1.11
+++ Make.unix   28 Apr 2006 20:26:22 -
@@ -6,12 +6,15 @@
 RANLIB=ranlib
 X11=/usr/X11R6
 CC=gcc
+CC=cc -xCC
 CFLAGS=-Wall -Wno-missing-braces -ggdb -I$(ROOT) -I$(ROOT)/include 
-I$(ROOT)/kern -c -I$(X11)/include -D_THREAD_SAFE $(PTHREAD) -O2
+CFLAGS=-I$(ROOT) -I$(ROOT)/include -I$(ROOT)/kern  -c -g -D_THREAD_SAFE
 O=o
 OS=posix
 GUI=x11
 LDADD=-L$(X11)/lib -lX11 -ggdb
-LDFLAGS=$(PTHREAD)
+LDADD=-L/usr/X11R6/lib -lX11 -lrt -lpthread -lsocket -lnsl
+# LDFLAGS=$(PTHREAD)
 TARG=drawterm
 # AUDIO=none
 AUDIO=unix
Index: README
===
RCS file: /cvs/drawterm/README,v
retrieving revision 1.6
diff -b -u -w -r1.6 README
--- README  17 Jan 2006 12:47:53 -  1.6
+++ README  28 Apr 2006 20:26:22 -
@@ -2,6 +2,11 @@
 --
 To build on Unix, run CONF=unix make.
 
+On solaris 8.5,
+using sun cc: Sun WorkShop 6 2000/04/07 C 5.1
+and gnu make 3.79.1, runmake 'CONF=unix' 'AUDIO=none'
+
+
 To build on Windows, you need Mingw.  See http://www.mingw.org.
 Edit Make.config to uncomment the Windows section
 and comment out the rest.  Then run CONF=windows make.
Index: include/auth.h
===
RCS file: /cvs/drawterm/include/auth.h,v
retrieving revision 1.2
diff -b -u -w -r1.2 auth.h
--- include/auth.h  7 Nov 2005 17:13:38 -   1.2
+++ include/auth.h  28 Apr 2006 20:26:23 -
@@ -17,7 +17,9 @@
 enum
 {
MAXCHLEN=   256,/* max challenge length */
+#ifndef MAXNAMELEN
MAXNAMELEN= 256,/* maximum name length */
+#endif
MD5LEN= 16,
 
ARok = 0,   /* rpc return values */
Index: include/dtos.h
===
RCS file: /cvs/drawterm/include/dtos.h,v
retrieving revision 1.5
diff -b -u -w -r1.5 dtos.h
--- include/dtos.h  29 Dec 2005 23:41:14 -  1.5
+++ include/dtos.h  28 Apr 2006 20:26:23 -
@@ -1,4 +1,4 @@
-#if defined(linux) || defined(IRIX) || defined(SOLARIS) || defined(OSF1) || 
defined(__FreeBSD__) || defined(__APPLE__) || defined(__NetBSD__)
+#if defined(linux) || defined(IRIX) || defined(__sun) || defined(OSF1) || 
defined(__FreeBSD__) || defined(__APPLE__) || defined(__NetBSD__)
 #  include "unix.h"
 #  ifdef __APPLE__
 #  define panic dt_panic
Index: kern/devaudio.c
===
RCS file: /cvs/drawterm/kern/devaudio.c,v
retrieving revision 1.1
diff -b -u -w -r1.1 devaudio.c
--- kern/devaudio.c 8 Mar 2006 04:24:23 -   1.1
+++ kern/devaudio.c 28 Apr 2006 20:26:23 -
@@ -45,17 +45,17 @@
int irval;
 } volumes[] =
 {
-[Vaudio]   "audio",Fout,   50, 50,
-[Vsynth]   "synth",Fin|Fout,   0,  0,
-[Vcd]  "cd",   Fin|Fout,   0,  0,
-[Vline]"line", Fin|Fout,   0,  0,
-[Vmic] "mic",  Fin|Fout|Fmono, 0,  0,
-[Vspeaker] "speaker",  Fout|Fmono, 0,  0,
+/*[Vaudio]*/   "audio",Fout,   50, 50,
+/*[Vsynth]*/   "synth"

Re: [9fans] Drawterm Solaris

[Axel Belinfante]

around nov 9 2005 I seem to have spent some time to make dt2k
compile on sparc solaris 8, using the sun c compiler.

I thought I had reported that either here or to russ,
and mentioned or forwarded the changes... maybe not?

If there is real interest I could find time to
have a look at this again.

Axel.

Re: [9fans] Drawterm Solaris

[Noah Evans]

yeah, blah... the version I had on my old sun has got the blues too. h... compile the latest version with CONF=unix make gives the following errors:gcc: unrecognized option `-pthread'In file included from ./include/u.h:1,
 from main.c:1:./include/dtos.h:10:3: #error "Define an OS"In file included from main.c:2:./include/lib.h:138: error: syntax error before "p9_uvlong"./include/lib.h:138: warning: no semicolon at end of struct or union
./include/lib.h:141: error: syntax error before '}' token./include/lib.h:141: warning: type defaults to `int' in declaration of `Qid'./include/lib.h:141: warning: data definition has no type or storage class
./include/lib.h:149: error: syntax error before "Qid"./include/lib.h:149: warning: no semicolon at end of struct or union./include/lib.h:153: error: syntax error before "length"./include/lib.h:153: warning: type defaults to `int' in declaration of `length'
./include/lib.h:153: warning: data definition has no type or storage class./include/lib.h:158: error: syntax error before '}' token./include/lib.h:158: warning: type defaults to `int' in declaration of `Dir'
./include/lib.h:158: warning: data definition has no type or storage class./include/lib.h:180: error: syntax error before "va_list"./include/lib.h:180: warning: no semicolon at end of struct or union
./include/lib.h:185: error: syntax error before '}' token./include/lib.h:208: error: syntax error before "va_list"./include/lib.h:210: error: syntax error before "va_list"
On 4/28/06, andrey mirtchovski <[EMAIL PROTECTED]> wrote:
i believe the binary you downloaded exhibits the bug, but i can'tverify under which conditions... I tried compiling a new binary on anold solaris 8 machine but couldn't -- the new drawterm code has nosolaris hooks and the machine is too far away (and too busy) for me to
try to import the relevant bits from the old code, even though aperfunctory look indicates it to be more than trivial (getcallerpc isthere, but there's a non-posix solaris-specific thread implementation)i may try still.
i compiled the old code and ran a test (both the binary from the weband the newly compiled one): despite being painfully slow, displayingon an X running under PowerPC (OSX) did not show color problems,
however in both cases drawterm crashed with some X error or other.i apologize for being useless :(On 4/27/06, Noah Evans <[EMAIL PROTECTED]> wrote:> Hey Andrey,
>> This is actually using the solaris drawterm binary from your website. Does> it have the RGB/BGR bug? Could be I'm just using an ancient version. I> compiled a newer binary late last night, but I won't have a chance to test
> it for a while.>> Noah

Re: [9fans] Drawterm Solaris

[andrey mirtchovski]

i believe the binary you downloaded exhibits the bug, but i can't
verify under which conditions... I tried compiling a new binary on an
old solaris 8 machine but couldn't -- the new drawterm code has no
solaris hooks and the machine is too far away (and too busy) for me to
try to import the relevant bits from the old code, even though a
perfunctory look indicates it to be more than trivial (getcallerpc is
there, but there's a non-posix solaris-specific thread implementation)
i may try still.

i compiled the old code and ran a test (both the binary from the web
and the newly compiled one): despite being painfully slow, displaying
on an X running under PowerPC (OSX) did not show color problems,
however in both cases drawterm crashed with some X error or other.

i apologize for being useless :(

On 4/27/06, Noah Evans <[EMAIL PROTECTED]> wrote:

Hey Andrey,

This is actually using the solaris drawterm binary from your website. Does
it have the RGB/BGR bug? Could be I'm just using an ancient version. I
compiled a newer binary late last night, but I won't have a chance to test
it for a while.

Noah

Re: [9fans] Drawterm Solaris

[Noah Evans]

Hey Andrey,This is actually using the solaris drawterm binary from your website. Does it have the RGB/BGR bug? Could be I'm just using an ancient version. I compiled a newer binary late last night, but I won't have a chance to test it for a while.
NoahOn 4/28/06, andrey mirtchovski <[EMAIL PROTECTED]> wrote:
>> isn't that the same RGB vs BGR bug in old drawterms?to make myself clearer, the background is gray, text is black and therio windows are white (but borders aren't), so you won't see adifference until you get a colored window up or display an image.
i used to see the wrong colors when running a binary on solaris,displaying on a remote X running on x86andrey

Re: [9fans] Drawterm Solaris

[Noah Evans]

p9p acme works fine, I'm going to compile the latest drawterm on a system with a more sane environment and see how that works out.Thanks for your help,NoahOn 4/28/06, 
Russ Cox <[EMAIL PROTECTED]> wrote:
> It could be the bizarre settings on our sun ray servers(they won't even let> you change from csh :o ). The colors are fine until you open acme or any> colored window then you get powder blue instead of acme's normal yellow. I
> have access to another sun machine and just compiled a copy of another> source I had lying around. I'll try it out when I have direct access to a> sun terminal and get back to you.it'd be interesting to know if the ported acme (or just colors)
did the right thing.russ

Re: [9fans] Drawterm Solaris

[andrey mirtchovski]

isn't that the same RGB vs BGR bug in old drawterms?


to make myself clearer, the background is gray, text is black and the  
rio windows are white (but borders aren't), so you won't see a  
difference until you get a colored window up or display an image.


i used to see the wrong colors when running a binary on solaris,  
displaying on a remote X running on x86


andrey

Re: [9fans] Drawterm Solaris

[andrey mirtchovski]

On Apr 27, 2006, at 10:47 AM, Russ Cox wrote:

It could be the bizarre settings on our sun ray servers(they won't  
even let
you change from csh :o ). The colors are fine until you open acme  
or any
colored window then you get powder blue instead of acme's normal  
yellow. I
have access to another sun machine and just compiled a copy of  
another
source I had lying around. I'll try it out when I have direct  
access to a

sun terminal and get back to you.


it'd be interesting to know if the ported acme (or just colors)
did the right thing.

russ




isn't that the same RGB vs BGR bug in old drawterms?

Re: [9fans] Drawterm Solaris

[Russ Cox]

> It could be the bizarre settings on our sun ray servers(they won't even let
> you change from csh :o ). The colors are fine until you open acme or any
> colored window then you get powder blue instead of acme's normal yellow. I
> have access to another sun machine and just compiled a copy of another
> source I had lying around. I'll try it out when I have direct access to a
> sun terminal and get back to you.

it'd be interesting to know if the ported acme (or just colors)
did the right thing.

russ
 

Re: [9fans] Drawterm Solaris

[Noah Evans]

It could be the bizarre settings on our sun ray servers(they won't even let you change from csh :o ). The colors are fine until you open acme or any colored window then you get powder blue instead of acme's normal yellow. I have access to another sun machine and just compiled a copy of another source I had lying around. I'll try it out when I have direct access to a sun terminal and get back to you. 
Thanks for your help.NoahOn 4/27/06, Russ Cox <[EMAIL PROTECTED]> wrote:
> Does the current drawterm compile on solaris? Couldn't find a makefile for> it. I grabbed andrey's old solaris binary but I'm still having the blue> background problem. Any fixes for that? We're running on sun rays and I
> don't have access to the rayserv.make -f Make.unix is supposed to work on Solaris.I'm not entirely sure what you mean by the blue backgroundproblem.  The background is supposed to be blue until
you start rio!Russ

Re: [9fans] Drawterm Solaris

[Russ Cox]

> Does the current drawterm compile on solaris? Couldn't find a makefile for
> it. I grabbed andrey's old solaris binary but I'm still having the blue
> background problem. Any fixes for that? We're running on sun rays and I
> don't have access to the rayserv.

make -f Make.unix is supposed to work on Solaris.
I'm not entirely sure what you mean by the blue background
problem.  The background is supposed to be blue until
you start rio!

Russ

[9fans] Drawterm Solaris

[Noah Evans]

Hey,Does the current drawterm compile on solaris? Couldn't find a makefile for it. I grabbed andrey's old solaris binary but I'm still having the blue background problem. Any fixes for that? We're running on sun rays and I don't have access to the rayserv.
Thanks,Noah

Re: [9fans] drawterm screen size

[Gabriel Diaz]

HelloAfter a windows blue screen now drawterm use all the screen,if it crash again i will take notes to be sure drawterm has no relationwith the error.thank you very muchgabi
On 4/20/06, Russ Cox <[EMAIL PROTECTED]> wrote:
> A new monitor arrived today, and for the first time the drawterm defaut> screen size become smaller than> the monitor i have.>> I'm running at 1920x1440.>> where can i change drawterm to allow that size? (if it is trivial to do. .
> .)drawterm asks the underlying graphics system(ms windows or x windows) what the size of thescreen is and uses that as the maximum size.the code is in gui-win32/screen.c or gui-x11/screen.c.
look for screeninit.russ

Re: [9fans] drawterm screen size

[Russ Cox]

> A new monitor arrived today, and for the first time the drawterm defaut
> screen size become smaller than
> the monitor i have.
> 
> I'm running at 1920x1440.
> 
> where can i change drawterm to allow that size? (if it is trivial to do. .
> .)

drawterm asks the underlying graphics system
(ms windows or x windows) what the size of the
screen is and uses that as the maximum size.
the code is in gui-win32/screen.c or gui-x11/screen.c.
look for screeninit.

russ

[9fans] drawterm screen size

[Gabriel Diaz]

HelloA new monitor arrived today, and for the first time the drawterm defaut screen size become smaller thanthe monitor i have.I'm running at 1920x1440.where can i change drawterm to allow that size? (if it is trivial to do. . .)
thanksgabi

Re: [9fans] drawterm kprint

[Russ Cox]

> but i'm not sure why i can't interrupt cat.  deleting the
> window keeps the device busy. is this expected?

probably the drawterm exportfs does not 
implement flush.  normally it is implemented
with postnote, but there is no postnote
in drawterm.

russ

[9fans] drawterm kprint

[Skip Tavakkolian]

i was surprised that drawterm provides kprint and it works. 

cpu% cat /mnt/term/dev/kprint
dir: bad path c:/Documents and Settings/fst/My Documents/My Music/Fats€Domino
dir: bad path c:/Documents and Settings/fst/My Documents/My Music/Fiona€Apple
dir: bad path c:/Documents and Settings/fst/My Documents/My 
Music/John€Lee€Hooker
dir: bad path c:/Documents and Settings/fst/My Documents/My Music/Muddy€Waters

but i'm not sure why i can't interrupt cat.  deleting the
window keeps the device busy. is this expected?

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Sven Moritz Hallberg]

Skip Tavakkolian schrieb:
>>gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
>>-I/usr/X11R6/include -D_THREAD_SAFE -pthread -O2 tas.c
>>/tmp/cc4SeP4G.s: Assembler messages:
> 
> 
> what's $arch set to? was G4 support added recently?

My PowerBook (also with Ubuntu Linux) sets it to "ppc", via uname -m, as
per Make.unix. For MacOS X, $arch is appearently set to "power", so as a
quick work-around to the assembly problems, I copied posix-power to
posix-ppc and changed tas.c as attached. The only problem seems to be a
slight disagreement in assembly syntax between MacOS and Linux. *shrug*

Regards,
Sven Moritz

PS. In fact, the only thing different on Linux is that register names
are not profixed with 'r', so, for example, instead of "li r0,0" on
MacOS, it's just "li 0,0" on Linux...

PPS. Do I hear the #ifdef's calling? *duck* No! No! No!
#include "u.h"
#include "libc.h"

/*
 * first argument (l) is in r3 at entry.
 * r3 contains return value upon return.
 */
int
tas(long *x)
{
	int v;
	/*
	 * this __asm__ works with gcc 2.95.2 (mac os x 10.1).
	 * this assembly language destroys r0 (0), some other register (v),
	 * r4 (x) and r5 (temp).
	 */
	__asm__("\n	sync\n"
	"	li	0,0\n"
	"	mr	4,%1		/* &l->val */\n"
	"	lis	5,0xdead	/* assemble constant 0xdeaddead */\n"
	"	ori	5,5,0xdead	/* \" */\n"
	"tas1:\n"
	"	dcbf	4,0	/* cache flush; \"fix for 603x bug\" */\n"
	"	lwarx	%0,4,0	/* v = l->val with reservation */\n"
	"	cmp	cr0,0,%0,0	/* v == 0 */\n"
	"	bne	tas0\n"
	"	stwcx.	5,4,0   /* if (l->val same) l->val = 0xdeaddead */\n"
	"	bne	tas1\n"
	"tas0:\n"
	"	sync\n"
	"	isync\n"
	: "=r" (v)
	: "r"  (x)
	: "cc", "memory", "r0", "r4", "r5"
	);
	switch(v) {
	case 0:		return 0;
	case 0xdeaddead: return 1;
	default:	print("tas: corrupted 0x%lux\n", v);
	}
	return 0;
}


signature.asc
Description: OpenPGP digital signature

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Charles Forsyth]

> it makes me feel like I can help in some small way at least by testing these
> things out.

that's not a small way of helping, especially if you're patient
(and of course if you're not patient, eventually you'll destroy your machine
and be unable to send complaints, so i suppose it works out)

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Gregory Pavelcak]

I was about to try that when I got your mail. Maybe those error
messages aren't that cryptic after all. Just a little intimidating
for the clueless, like me.

Anyway, it works!! I'm responding via acme from drawterm now.

No need to apologize. I'm grateful for the help, and it makes me
feel like I can help in some small way at least by testing these
things out.

Thanks.

Greg

> okay, now replace _tas in the first two lines
> of the assembly file with plain tas (no underscore).
> sorry for the runaround -- gcc can't make up its mind
> from version to version.
> 
> russ

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Russ Cox]

okay, now replace _tas in the first two lines
of the assembly file with plain tas (no underscore).
sorry for the runaround -- gcc can't make up its mind
from version to version.

russ

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Gregory Pavelcak]

OK. Cut-n-pasted what you wrote into tas.s and got farther

make[1]: Leaving directory `/home/gp/drawterm/posix-power'
gcc -pthread -o drawterm main.o cpu.o readcons.o secstore.o latin1.o
posix-factotum.o  kern/libkern.a exportfs/libexportfs.a
libauth/libauth.a libauthsrv/libauthsrv.a libsec/libsec.a libmp/libmp.a
libmemdraw/libmemdraw.a libmemlayer/libmemlayer.a libdraw/libdraw.a
gui-x11/libgui.a libc/libc.a  kern/libkern.a exportfs/libexportfs.a
libauth/libauth.a libauthsrv/libauthsrv.a libsec/libsec.a libmp/libmp.a
libmemdraw/libmemdraw.a libmemlayer/libmemlayer.a libdraw/libdraw.a
gui-x11/libgui.a libc/libc.a  kern/libkern.a exportfs/libexportfs.a
libauth/libauth.a libauthsrv/libauthsrv.a libsec/libsec.a libmp/libmp.a
libmemdraw/libmemdraw.a libmemlayer/libmemlayer.a libdraw/libdraw.a
gui-x11/libgui.a libc/libc.a  libmachdep.a -L/usr/X11R6/lib -lX11 -ggdb
kern/libkern.a(devcons.o): In function `consopen':
/home/gp/drawterm/kern/devcons.c:585: undefined reference to `tas'
libc/libc.a(lock.o): In function `canlock':
/home/gp/drawterm/libc/lock.c:7: undefined reference to `tas'
collect2: ld returned 1 exit status
make: *** [drawterm] Error 1

On Tue, 2006-01-17 at 16:40 -0500, Russ Cox wrote:
> Try removing tas.c from drawterm/posix-power and create tas.s
> instead:
> 
>   .globl  _tas
> _tas:
>   li  %r0, 0
>   mr  %r4, %r3
>   lis %r5, 0xcafe
>   ori %r5, %r5, 0xbabe
> 1:
>   lwarx   %r3, %r0, %r4
>   cmpwi   %r3, 0
>   bne 2f
>   stwcx.  %r5, %r0, %r4
>   bne-1b
> 2:
>   sync
>   blr
> 
> Russ

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Skip Tavakkolian]

>> gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
>> -I/usr/X11R6/include -D_THREAD_SAFE -pthread -O2 tas.c
>> /tmp/cc4SeP4G.s: Assembler messages:
> 
> what's $arch set to? was G4 support added recently?

never mind. i see it's "power", and posix-power/tas.c is the
same as what used to be in gccpower/ directory.

i'm glad to be of no help at all.

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Gregory Pavelcak]

In my attempt arch=power. I had to do that by hand. Maybe I made the
wrong choice. In Make.unix arch comes from uname -m, which in my case is
just 'ppc'

On Tue, 2006-01-17 at 14:33 -0800, Skip Tavakkolian wrote:
> > gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
> > -I/usr/X11R6/include -D_THREAD_SAFE -pthread -O2 tas.c
> > /tmp/cc4SeP4G.s: Assembler messages:
> 
> what's $arch set to? was G4 support added recently?
> 

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Russ Cox]

Try removing tas.c from drawterm/posix-power and create tas.s
instead:

.globl  _tas
_tas:
li  %r0, 0
mr  %r4, %r3
lis %r5, 0xcafe
ori %r5, %r5, 0xbabe
1:
lwarx   %r3, %r0, %r4
cmpwi   %r3, 0
bne 2f
stwcx.  %r5, %r0, %r4
bne-1b
2:
sync
blr

Russ

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Skip Tavakkolian]

> gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
> -I/usr/X11R6/include -D_THREAD_SAFE -pthread -O2 tas.c
> /tmp/cc4SeP4G.s: Assembler messages:

what's $arch set to? was G4 support added recently?

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Gregory Pavelcak]

OK, I can almost taste it now.
As Homer says: "Mmmm Draaawwterrrmmm, arggghh."
Any advice appreciated.

Greg


(cd posix-$arch &&  make)
make[1]: Entering directory `/home/gp/drawterm/posix-power'
gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
-I/usr/X11R6/include -D_THREAD_SAFE -pthread -O2 getcallerpc.c
gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
-I/usr/X11R6/include -D_THREAD_SAFE -pthread -O2 md5block.c
gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
-I/usr/X11R6/include -D_THREAD_SAFE -pthread -O2 sha1block.c
gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
-I/usr/X11R6/include -D_THREAD_SAFE -pthread -O2 tas.c
/tmp/cc4SeP4G.s: Assembler messages:
/tmp/cc4SeP4G.s:39: Error: unsupported relocation against r0
/tmp/cc4SeP4G.s:40: Error: unsupported relocation against r4
/tmp/cc4SeP4G.s:41: Error: unsupported relocation against r5
/tmp/cc4SeP4G.s:42: Error: unsupported relocation against r5
/tmp/cc4SeP4G.s:42: Error: unsupported relocation against r5
/tmp/cc4SeP4G.s:44: Error: unsupported relocation against r4
/tmp/cc4SeP4G.s:44: Error: unsupported relocation against r0
/tmp/cc4SeP4G.s:45: Error: unsupported relocation against r4
/tmp/cc4SeP4G.s:45: Error: unsupported relocation against r0
/tmp/cc4SeP4G.s:46: Error: unsupported relocation against r0
/tmp/cc4SeP4G.s:48: Error: unsupported relocation against r5
/tmp/cc4SeP4G.s:48: Error: unsupported relocation against r4
/tmp/cc4SeP4G.s:48: Error: unsupported relocation against r0
make[1]: *** [tas.o] Error 1
make[1]: Leaving directory `/home/gp/drawterm/posix-power'
make: *** [libmachdep.a] Error 2

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[erik quanstrom]

with va_copy: e.g.:

int
fmtprint(Fmt *f, char *fmt, ...)
{
va_list va;
int n;

f->flags = 0;
f->width = 0;
f->prec = 0;
va_copy(va, f->args);
va_end(f->args);
va_start(f->args, fmt);
n = dofmt(f, fmt);
va_end(f->args);
f->flags = 0;
f->width = 0;
f->prec = 0;
va_copy(f->args,va);
va_end(va);
if(n >= 0)
return 0;
return n;
}

Gregory Pavelcak <[EMAIL PROTECTED]> writes

| 
| On Mon, 2006-01-16 at 20:19 -0500, Russ Cox wrote:
| > > The subject line pretty much says it. I installed Ubuntu Linux on my Mac
| > > Mini for the heck of it. I mainly use the Mini to drawterm to Plan 9.
| > > So, the question is which drawterm, assuming that there is an
| > > appropriate one, should I use? drawterm-linux and drawterm-osx both give
| > > me `cannot execute binary file'. I also downloaded the sources from
| > > Andrey's collection, but need to find out how to get mk installed on
| > > Ubuntu. Is the build likely to work? If you know that it won't, you
| > > could save me some trouble by filling me in :-)
| > 
| > Use the sources referenced by http://swtch.com/drawterm/.
| > You'll only need make.
| > 
| > Russ
| 
| Thanks for the help. I seem to be getting close.
| 
| But, how to fix this?
| 
| make[1]: Leaving directory `/home/gp/bin/drawterm/gui-x11'
| (cd libc; make)
| make[1]: Entering directory `/home/gp/bin/drawterm/libc'
| gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
| -I/usr/include/X11-D_THREAD_SAFE -pthread -O2 fmtprint.c
| fmtprint.c: In function ‘fmtprint’:
| fmtprint.c:20: error: incompatible types in assignment
| fmtprint.c:27: error: incompatible types in assignment
| make[1]: *** [fmtprint.o] Error 1
| make[1]: Leaving directory `/home/gp/bin/drawterm/libc'
| make: *** [libc/libc.a] Error 2
| 
| Greg

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Gregory Pavelcak]

On Mon, 2006-01-16 at 20:19 -0500, Russ Cox wrote:
> > The subject line pretty much says it. I installed Ubuntu Linux on my Mac
> > Mini for the heck of it. I mainly use the Mini to drawterm to Plan 9.
> > So, the question is which drawterm, assuming that there is an
> > appropriate one, should I use? drawterm-linux and drawterm-osx both give
> > me `cannot execute binary file'. I also downloaded the sources from
> > Andrey's collection, but need to find out how to get mk installed on
> > Ubuntu. Is the build likely to work? If you know that it won't, you
> > could save me some trouble by filling me in :-)
> 
> Use the sources referenced by http://swtch.com/drawterm/.
> You'll only need make.
> 
> Russ

Thanks for the help. I seem to be getting close.

But, how to fix this?

make[1]: Leaving directory `/home/gp/bin/drawterm/gui-x11'
(cd libc; make)
make[1]: Entering directory `/home/gp/bin/drawterm/libc'
gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
-I/usr/include/X11-D_THREAD_SAFE -pthread -O2 fmtprint.c
fmtprint.c: In function ‘fmtprint’:
fmtprint.c:20: error: incompatible types in assignment
fmtprint.c:27: error: incompatible types in assignment
make[1]: *** [fmtprint.o] Error 1
make[1]: Leaving directory `/home/gp/bin/drawterm/libc'
make: *** [libc/libc.a] Error 2

Greg

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[andrey mirtchovski]

get the sources from Russ' swtch.com as they are the latest. i should
remove the sources .tgz from my website anyways to avoid confusion.

if you get plan9port installed on the box it will compile mk for you,
else you can get it from:

http://www.cminusminus.org/code.html#mk

andrey

On 1/16/06, Gregory Pavelcak <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> The subject line pretty much says it. I installed Ubuntu Linux on my Mac
> Mini for the heck of it. I mainly use the Mini to drawterm to Plan 9.
> So, the question is which drawterm, assuming that there is an
> appropriate one, should I use? drawterm-linux and drawterm-osx both give
> me `cannot execute binary file'. I also downloaded the sources from
> Andrey's collection, but need to find out how to get mk installed on
> Ubuntu. Is the build likely to work? If you know that it won't, you
> could save me some trouble by filling me in :-)
>
> Thanks a lot.
>
> Belated Happy Holidays to all.
>
> Greg
>
>

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Federico G. Benavento]

http://swtch.com/drawterm/
--- Begin Message ---
Hello all,

The subject line pretty much says it. I installed Ubuntu Linux on my Mac
Mini for the heck of it. I mainly use the Mini to drawterm to Plan 9.
So, the question is which drawterm, assuming that there is an
appropriate one, should I use? drawterm-linux and drawterm-osx both give
me `cannot execute binary file'. I also downloaded the sources from
Andrey's collection, but need to find out how to get mk installed on
Ubuntu. Is the build likely to work? If you know that it won't, you
could save me some trouble by filling me in :-)

Thanks a lot.

Belated Happy Holidays to all.

Greg
--- End Message ---

Re: [9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Russ Cox]

> The subject line pretty much says it. I installed Ubuntu Linux on my Mac
> Mini for the heck of it. I mainly use the Mini to drawterm to Plan 9.
> So, the question is which drawterm, assuming that there is an
> appropriate one, should I use? drawterm-linux and drawterm-osx both give
> me `cannot execute binary file'. I also downloaded the sources from
> Andrey's collection, but need to find out how to get mk installed on
> Ubuntu. Is the build likely to work? If you know that it won't, you
> could save me some trouble by filling me in :-)

Use the sources referenced by http://swtch.com/drawterm/.
You'll only need make.

Russ

[9fans] Drawterm on Mac Mini w/Ubuntu Linux

[Gregory Pavelcak]

Hello all,

The subject line pretty much says it. I installed Ubuntu Linux on my Mac
Mini for the heck of it. I mainly use the Mini to drawterm to Plan 9.
So, the question is which drawterm, assuming that there is an
appropriate one, should I use? drawterm-linux and drawterm-osx both give
me `cannot execute binary file'. I also downloaded the sources from
Andrey's collection, but need to find out how to get mk installed on
Ubuntu. Is the build likely to work? If you know that it won't, you
could save me some trouble by filling me in :-)

Thanks a lot.

Belated Happy Holidays to all.

Greg

Re: [9fans] Drawterm on Linux/PowerPC

[C H Forsyth]

>Hah, I'm such an idiot, overlooked va_copy although it's right in the

you're not an idiot.  it's a late addition, very late (and i'm not so sure 
about the people
that forced it to be added).

Re: [9fans] Drawterm on Linux/PowerPC

[Sven Moritz Hallberg]

Eric Van Hensbergen schrieb:
> Essentially you were on the right path, but the wrong solution.
> man va_copy and look at the plan9ports fmtprint code for how to do
> this right on ppc/linux.

Hah, I'm such an idiot, overlooked va_copy although it's right in the
manpage. Anyway, I've replace the assignments with va_copy/va_end pairs,
as in plan9ports and drawterm seems to work! At least it compiles,
starts, and complains that I didn't tell it any server... :)

Attached is the output of cvs diff.


Thanks alot for the pointer,

Sven Moritz
Index: libc/fmtprint.c
===
RCS file: /cvs/drawterm/libc/fmtprint.c,v
retrieving revision 1.1
diff -r1.1 fmtprint.c
20c20,21
< 	va = f->args;
---
> 	va_copy(va, f->args);
> 	va_end(f->args);
27c28,29
< 	f->args = va;
---
> 	va_copy(f->args, va);
> 	va_end(va);
Index: libc/fmtvprint.c
===
RCS file: /cvs/drawterm/libc/fmtvprint.c,v
retrieving revision 1.1
diff -r1.1 fmtvprint.c
20,21c20,23
< 	va = f->args;
< 	f->args = args;
---
> 	va_copy(va, f->args);
> 	va_end(f->args);
> 	va_copy(f->args, args);
> 	va_end(args);
26c28,29
< 	f->args = va;
---
> 	va_copy(f->args, va);
> 	va_end(va);
Index: libc/runevseprint.c
===
RCS file: /cvs/drawterm/libc/runevseprint.c,v
retrieving revision 1.1
diff -r1.1 runevseprint.c
18c18,19
< 	f.args = args;
---
> 	va_copy(f.args, args);
> 	va_end(args);
Index: libc/runevsmprint.c
===
RCS file: /cvs/drawterm/libc/runevsmprint.c,v
retrieving revision 1.1
diff -r1.1 runevsmprint.c
60c60,61
< 	f.args = args;
---
> 	va_copy(f.args, args);
> 	va_end(args);
Index: libc/runevsnprint.c
===
RCS file: /cvs/drawterm/libc/runevsnprint.c,v
retrieving revision 1.1
diff -r1.1 runevsnprint.c
18c18,19
< 	f.args = args;
---
> 	va_copy(f.args, args);
> 	va_end(args);
Index: libc/vfprint.c
===
RCS file: /cvs/drawterm/libc/vfprint.c,v
retrieving revision 1.1
diff -r1.1 vfprint.c
29c29,30
< 	f.args = args;
---
> 	va_copy(f.args, args);
> 	va_end(args);
Index: libc/vseprint.c
===
RCS file: /cvs/drawterm/libc/vseprint.c,v
retrieving revision 1.1
diff -r1.1 vseprint.c
18c18,19
< 	f.args = args;
---
> 	va_copy(f.args, args);
> 	va_end(args);
Index: libc/vsmprint.c
===
RCS file: /cvs/drawterm/libc/vsmprint.c,v
retrieving revision 1.1
diff -r1.1 vsmprint.c
60c60,61
< 	f.args = args;
---
> 	va_copy(f.args, args);
> 	va_end(args);
Index: libc/vsnprint.c
===
RCS file: /cvs/drawterm/libc/vsnprint.c,v
retrieving revision 1.1
diff -r1.1 vsnprint.c
18c18,19
< 	f.args = args;
---
> 	va_copy(f.args, args);
> 	va_end(args);


signature.asc
Description: OpenPGP digital signature

[9fans] Drawterm on Linux/PowerPC

[erik quanstrom]

Sven Moritz Hallberg <[EMAIL PROTECTED]> writes

[...]
| gcc -Wall -Wno-missing-braces -ggdb -I.. -I../include -I../kern -c
| -I/usr/X11R6/include -D_THREAD_SAFE -pthread -O2 fmtprint.c
| fmtprint.c: In function 'fmtprint':
| fmtprint.c:20: error: incompatible types in assignment
| 
| I tried to replace all the offending assignments with calls to memcpy:
| 
| /*  va = f->args; */
| memcpy(&va, &(f->args), sizeof(va_list));

try: (from plan9port)

int
fmtprint(Fmt *f, char *fmt, ...)
{
va_list va;
int n;

f->flags = 0;
f->width = 0;
f->prec = 0;
va_copy(va, f->args);
va_end(f->args);
va_start(f->args, fmt);
n = dofmt(f, fmt);
va_end(f->args);
f->flags = 0;
f->width = 0;
f->prec = 0;
va_copy(f->args,va);
va_end(va);
if(n >= 0)
return 0;
return n;
}

- erik