My upgrade to Snow Leopard has been pretty smooth sailing bar one annoying hitch. After the upgrade MacVim stopped scrolling properly.
When you scroll down only the last few lines on the screen update and scrolling up only the first few lines. This requires you CTRL-L to redraw the window every time you've finished scrolling.
Yuck!
Looks like this is caused by MacVim's support for ATSUI which has been deprecated in favour of Core Text in Snow Leopard.
If you are experiencing this you can simply turn the ATSUI renderer off by unchecking MacVim -> Preferences -> Advanced -> Use ATSUI renderer.
This is switched off by default so most people won't be affected by this. At the time of this post there was no real indication from the MacVim project if they'd be switching to Core Text in the future in addition to using the ATSUI renderer.
Tuesday, September 22, 2009
Sunday, September 13, 2009
iTerm, X11.app and the case of the missing DISPLAY
If you're running X11.app as your X server on OS X you generally need to use the xterm window it launches for you as part of the system or your specific xinitrc to connect to remote hosts via SSH when you want to enable X11 forwarding (and the propagation of your DISPLAY variable).
I prefer iTerm and luckily the solutions to switch to using it instead of the xterm launched by X11 is pretty easy to implement.
The first option is to make a user specific copy of xinitrc and modify the line that launches xterm to rather launch iTerm. If you don't have a user specific xinitrc (~/.xinitrc) you can grab a copy from /etc/X11/xinit/xinitrc or /usr/X11R6/lib/X11/xinit/xinitrc.
Near the bottom of the xinitrc you'll see a few lines that reference xterm that you can comment our and substitute with:
If you access remote X applications very infrequently it may simply be easier to ensure that X11 is running and then export your DISPLAY variable manually in iTerm:
The final solution is to make all terms aware of your DISPLAY variable by editing your local environment plist (~/.MacOSX/environment.plist):
This will open the plist in the Property List Editor where you can add a new child (DISPLAY) under the root node with a value of ':0'. For this to take effect you need to log out/in. You could also have dropped 'export DISPLAY=:0' into your local ~/.bash_profile to achieve the same results.
I prefer iTerm and luckily the solutions to switch to using it instead of the xterm launched by X11 is pretty easy to implement.
The first option is to make a user specific copy of xinitrc and modify the line that launches xterm to rather launch iTerm. If you don't have a user specific xinitrc (~/.xinitrc) you can grab a copy from /etc/X11/xinit/xinitrc or /usr/X11R6/lib/X11/xinit/xinitrc.
Near the bottom of the xinitrc you'll see a few lines that reference xterm that you can comment our and substitute with:
/usr/bin/open /Applications/iTerm.app
If you access remote X applications very infrequently it may simply be easier to ensure that X11 is running and then export your DISPLAY variable manually in iTerm:
$ export DISPLAY=:0
The final solution is to make all terms aware of your DISPLAY variable by editing your local environment plist (~/.MacOSX/environment.plist):
$ open ~/.MacOSX/environment.plist
This will open the plist in the Property List Editor where you can add a new child (DISPLAY) under the root node with a value of ':0'. For this to take effect you need to log out/in. You could also have dropped 'export DISPLAY=:0' into your local ~/.bash_profile to achieve the same results.
Untrusted SSH clients or Gdk-WARNING **: Connection to display localhost:10.0 appears to be untrusted
While connecting to a local RH system via 'ssh -X' I was seeing errors like:
OpenSSH implements the X11 SECURITY extension that provides two clients types: trusted & untrusted.
Trusted clients can do anything with the display while untrusted clients cannot inject synthetic events (mouse movement, keypresses, etc.) or read data from other windows (e.g. take screenshots).
In theory you should be able to run most applications via the untrusted category but it seems that a fair amount of client apps still do not implement this correctly so YMMV.
If you want to initialize a SSH connection with X11 forwarding support and using the trusted security type you simply replace -X with -Y:
TIP: Add a '-C' to your ssh connections to speed things up. Nothings for free but I am sure the CPU/speed trade-off will suit most users.
Connection to display localhost:10.0 appears to be untrusted. Pointer and
keyboard grabs and inter-client communication may not work as expected.
OpenSSH implements the X11 SECURITY extension that provides two clients types: trusted & untrusted.
Trusted clients can do anything with the display while untrusted clients cannot inject synthetic events (mouse movement, keypresses, etc.) or read data from other windows (e.g. take screenshots).
In theory you should be able to run most applications via the untrusted category but it seems that a fair amount of client apps still do not implement this correctly so YMMV.
If you want to initialize a SSH connection with X11 forwarding support and using the trusted security type you simply replace -X with -Y:
$ ssh -Y USER@HOST
TIP: Add a '-C' to your ssh connections to speed things up. Nothings for free but I am sure the CPU/speed trade-off will suit most users.
Friday, September 11, 2009
Installing ghc on OS X and getting "./configure: line 11082: syntax error: unexpected end of file"
While trying to install ghc from MacPorts I kept getting this:
Turns out there's some old cruft in the ghc autoconf macros that were causing the break. The fix was a simple:
You can see the filed bug and changeset at MacPorts for more information.
[...]
---> Fetching ghc
---> Attempting to fetch ghc-6.10.3-src.tar.bz2 from
http://distfiles.macports.org/ghc
---> Attempting to fetch ghc-6.10.3-src-extralibs.tar.bz2 from
http://distfiles.macports.org/ghc
---> Attempting to fetch testsuite-6.10.3.tar.bz2 from
http://distfiles.macports.org/ghc
---> Attempting to fetch ghc-6.8.2-darwin-i386-leopard-bootstrap.tar.bz2 from
http://distfiles.macports.org/ghc
---> Verifying checksum(s) for ghc
---> Extracting ghc
---> Applying patches to ghc
---> Configuring ghc
Error: Target org.macports.configure returned: configure failure: shell command
" cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.
macports.org_release_ports_lang_ghc/work/ghc-6.10.3" && ./configure
--prefix=/opt/local
--prefix=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.
macports.org_release_ports_lang_ghc/work/destroot/opt/local
--datadir=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.
macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ghc-6.10.3
--with-gmp-includes=/opt/local/include --with-gmp-libraries=/opt/local/lib
--with-ghc='/opt/local/var/macports/build/
_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/
work/ghc-bootstrap/bin/ghc' --with-gcc=/usr/bin/gcc-4.0 " returned error 2
Command output: checking build system type... i386-apple-darwin9.7.0
checking host system type... i386-apple-darwin9.7.0
checking target system type... i386-apple-darwin9.7.0
Canonicalised to: i386-apple-darwin
checking version of ghc... 6.8.2
checking for nhc... no
checking for nhc98... no
checking for hbc... no
checking for ld... /usr/bin/ld
./configure: line 11082: syntax error: unexpected end of file
Turns out there's some old cruft in the ghc autoconf macros that were causing the break. The fix was a simple:
$ sudo port selfupdate && sudo port clean ghc && sudo port install ghc
You can see the filed bug and changeset at MacPorts for more information.
Tuesday, September 1, 2009
Update: Home made nginx + phusion passenger OS X port
The new v2.2.5 version of Phusion Passenger has been released.
If you want to roll this into OS X without having to use their installer you can simply follow the previous article to get this done.
Important things to note is that wherever you used /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.4* you would now use /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.5* (the Portfile and the nginx.conf come to mind).
If you want to roll this into OS X without having to use their installer you can simply follow the previous article to get this done.
Important things to note is that wherever you used /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.4* you would now use /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.5* (the Portfile and the nginx.conf come to mind).
Subscribe to:
Posts (Atom)
About Me
- Charl
- I love solving real-world problems with code and systems (web apps, distributed systems and all the bits and pieces in-between).