Re: [9fans] once more: drawterm osx-x11 on x86-64
On Fri, Feb 27, 2015 at 7:19 PM, Jeff Sickel j...@corpus-callosum.com wrote: The older versions of drawterm just map a large view to fill the whole screen and then clip the view to the window size you’ve selected. When you drag the view it doesn’t resize the internal rio content. That meant that when taking a 1280x1024 window to 2560x1440 everything would stay the same and you’d just see the extra space already allocated. If you draw to the new areas and then resize the window back to the smaller rect you lose easy access to any rio windows created outside of the current clipping rect. The Cocoa version does proper resizing. It’s just a lot of effort to get the same features back into the X11 code base. I might be alone in this, but the resize drives me up the wall. I've had to go out of the way to patch rio to ignore resize updates. I suspect the reason for this is my riostart creates a few windows by default, which end up getting resized when I fullscreen drawterm, throwing everything out of whack. It would be nice if you could add a command line option for this - I started looking at this, but haven't had much time to make a proper patch. Cheers, Steve
Re: [9fans] once more: drawterm osx-x11 on x86-64
On OSX 10.10, X11.app is XQuartz. That said, the changes are all X11 based and if done right should transfer easily to other X11 implementations. -jas On Feb 27, 2015, at 7:09 PM, Sean Hinchee henesy@gmail.com wrote: Is this pure X11.app or XQuartz?
[9fans] noob question: p9 nfs client
On an OSX 10.9.5 host I run Bell Labs Plan 9 in Virtualbox. Both have fixed IP addresses: OSX 192.168.1.152 Plan 9 192.168.1.156 On OSX I have this in /etc/exports: /Users/mva -mapall=501:20 -alldirs I'm trying to access /Users/mva from Plan 9 through NFS: cpu% nfs -v -R -p 666 -s macmini 192.168.1.152 out: xid=0x0 prog 0x186a0 vers 0x2 proc 0x3 [none] [none] PortTGetport [15 3 17 0] send e67c8ecf 3443508661 3443509661 in: xid=0xe67c8ecf status 0x0 [none] low 0x0 high 0x0 in: xid=0xe67c8ecf status 0x0 [none] low 0x0 high 0x0 in: PortRGetport 799 out: xid=0x0 prog 0x186a0 vers 0x2 proc 0x3 [none] [none] PortTGetport [13 3 17 0] send e67c8ed0 3443508930 3443509930 in: xid=0xe67c8ed0 status 0x0 [none] low 0x0 high 0x0 in: xid=0xe67c8ed0 status 0x0 [none] low 0x0 high 0x0 in: PortRGetport 2049 nfs udp!192.168.1.152!799!r udp!192.168.1.152!2049!r out: xid=0x0 prog 0x186a5 vers 0x3 proc 0x0 [none] [none] NfsMount3TNull send 76381d71 3443509217 3443510217 in: xid=0x76381d71 status 0x0 [none] low 0x0 high 0x0 in: xid=0x76381d71 status 0x0 [none] low 0x0 high 0x0 in: NfsMount3RNull out: xid=0x0 prog 0x186a3 vers 0x3 proc 0x0 [none] [none] Nfs3TNull send ac0de7b5 3443509383 3443510383 in: xid=0xac0de7b5 status 0x0 [none] low 0x0 high 0x0 in: xid=0xac0de7b5 status 0x0 [none] low 0x0 high 0x0 in: Nfs3RNull cpu% aux/nfsmount 192.168.1.152 connecting to udp!192.168.1.152!portmap connecting to udp!192.168.1.152!799!r /Users/mva But then this fails: cpu% mkdir mac cpu% mount /srv/macmini mac creds for mva: 000D3139322E3136382E312E313536 00 out: xid=0x0 prog 0x186a5 vers 0x3 proc 0x1 [sys] [none] NfsMount3TMnt path=/ send 76381d72 3443716564 3443717564 in: xid=0x76381d72 status 0x0 [none] low 0x0 high 0x0 in: xid=0x76381d72 status 0x0 [none] low 0x0 high 0x0 in: NfsMount3RMnt status=13 mount: mount mac: access denied I imagine it is a problem with permissions; on the other hand I thought the mapall in the hosts' /etc/exportfs would take care of that. What am I missing? Mark.
Re: [9fans] once more: drawterm osx-x11 on x86-64
Some people prefer the X11 version as the refresh speed may be higher. That’s fine, though I prefer having rio resize working so I can full screen the app on a second display with CONF=osx-cocoa. I reduced the flicker in the drawterm-cocoa osx-cocoa version a while back. The flicker and window edges not meeting during a move is still there and more prevalent on slow connections or a slow cpu. There are a slew of X11 related changes to support rio resize that I’ve been meaning to push out at some point. Since migrating to OSX 10.10 the X11.app is mostly broken, and no longer supported/released by Apple, so my motivation to finish the changes has dwindled significantly. In fact, the latest X11 update doesn’t extract and install cleanly on OS X 10.10, so updates might take a while. -jas On Feb 26, 2015, at 6:00 PM, Mark van Atten vanattenm...@gmail.com wrote: A while ago, I reported on a problem I had with flicker and broken window edges in drawterm-cocoa CONF=osx-x11. See the email copied below. It led to a brief exchange. With my present configuration, that problem remains: OSX 10.9.5 drawterm-cocoa 2014-12-02 However, I just tried rsc's drawterm 2013-07-02, and there the problem is absent. I take it there are not many users of drawterm on OSX, either jas' or rsc's distribution, who use the x11 version -- are there? I'd be interested to compare notes. Best wishes, Mark. From: Mark van Atten vanattenmark@gma... Subject: drawterm osx-x11 on x86_64 Date: Thu, 21 Nov 2013 11:40:14 +0100 For the record---to compile drawterm (http://code.google.com/p/drawterm/) with CONF=osx-x11 on x86_64 (in my case running 10.8.5), just add the required substitution to the makefile: Make.osx-x11 20 - arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/'`; \ 20 + arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/;s/x86_64/amd64/'`; \ For the moment, I prefer this to drawterm-cocoa because there is no flicker, and window borders remain intact when reshaping with B1 or B2. Mark.
Re: [9fans] once more: drawterm osx-x11 on x86-64
On 28 February 2015 at 00:10, Jeff Sickel j...@corpus-callosum.com wrote: Some people prefer the X11 version as the refresh speed may be higher. That’s fine, though I prefer having rio resize working so I can full screen the app on a second display with CONF=osx-cocoa. Would it be possible to get working devwsys[1] in OSX with X11? I have no idea how difficult this would be, probably more or less as difficult as getting Inferno. Has anybody tried that? [1] https://bitbucket.org/yiyus/devwsys-prev -- - yiyus || JGL .
Re: [9fans] once more: drawterm osx-x11 on x86-64
Is this pure X11.app or XQuartz? On 2/27/15 5:10 PM, Jeff Sickel wrote: Some people prefer the X11 version as the refresh speed may be higher. That’s fine, though I prefer having rio resize working so I can full screen the app on a second display with CONF=osx-cocoa. I reduced the flicker in the drawterm-cocoa osx-cocoa version a while back. The flicker and window edges not meeting during a move is still there and more prevalent on slow connections or a slow cpu. There are a slew of X11 related changes to support rio resize that I’ve been meaning to push out at some point. Since migrating to OSX 10.10 the X11.app is mostly broken, and no longer supported/released by Apple, so my motivation to finish the changes has dwindled significantly. In fact, the latest X11 update doesn’t extract and install cleanly on OS X 10.10, so updates might take a while. -jas On Feb 26, 2015, at 6:00 PM, Mark van Atten vanattenm...@gmail.com wrote: A while ago, I reported on a problem I had with flicker and broken window edges in drawterm-cocoa CONF=osx-x11. See the email copied below. It led to a brief exchange. With my present configuration, that problem remains: OSX 10.9.5 drawterm-cocoa 2014-12-02 However, I just tried rsc's drawterm 2013-07-02, and there the problem is absent. I take it there are not many users of drawterm on OSX, either jas' or rsc's distribution, who use the x11 version -- are there? I'd be interested to compare notes. Best wishes, Mark. From: Mark van Atten vanattenmark@gma... Subject: drawterm osx-x11 on x86_64 Date: Thu, 21 Nov 2013 11:40:14 +0100 For the record---to compile drawterm (http://code.google.com/p/drawterm/) with CONF=osx-x11 on x86_64 (in my case running 10.8.5), just add the required substitution to the makefile: Make.osx-x11 20 - arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/'`; \ 20 + arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/;s/x86_64/amd64/'`; \ For the moment, I prefer this to drawterm-cocoa because there is no flicker, and window borders remain intact when reshaping with B1 or B2. Mark.
Re: [9fans] once more: drawterm osx-x11 on x86-64
The older versions of drawterm just map a large view to fill the whole screen and then clip the view to the window size you’ve selected. When you drag the view it doesn’t resize the internal rio content. That meant that when taking a 1280x1024 window to 2560x1440 everything would stay the same and you’d just see the extra space already allocated. If you draw to the new areas and then resize the window back to the smaller rect you lose easy access to any rio windows created outside of the current clipping rect. The Cocoa version does proper resizing. It’s just a lot of effort to get the same features back into the X11 code base. -jas On Feb 27, 2015, at 5:27 PM, Mark van Atten vanattenm...@gmail.com wrote: With the X11 version, drawterm can be resized with B1, and with xshove it can be turned full screen. (On X11, I use p9p's rio as my wm.) I look forward to any changes you may come up with; and many thanks for the work you have done so far! Mark.
Re: [9fans] once more: drawterm osx-x11 on x86-64
Sorry, last night it was getting too late and I confused. It is drawterm-cocoa CONF=osx-cocoa that still shows the flickering and the broken window edges. drawterm-cocoa CONF=osx-x11 works fine (but to be able to build it, I had to copy some header files that were not found (although present in the tree) to ./include. Sorry for the noise. Mark.
Re: [9fans] once more: drawterm osx-x11 on x86-64
With the X11 version, drawterm can be resized with B1, and with xshove it can be turned full screen. (On X11, I use p9p's rio as my wm.) I look forward to any changes you may come up with; and many thanks for the work you have done so far! Mark.
