Al Hoang » osx

Getting Ruby 1.9.1p243 to work on OS X 10.5.8 with Japanese input support on irb

hoanga — Tue, 08 Sep 2009 08:47:13 +0000

Awhile back I installed Ruby 1.9.1 in such a way as to co-exist with my current Ruby installation [1], [2] (I should use rvm [3] these days…)

However, one issue that cropped up during an IRB session was I could not copy and paste Japanese characters into the IRB repl. This is very very painful for my day to day use with Ruby (Imagine not being able to use the ‘|’ character while writing UNIX pipelines).

Below is an example of me trying to enter the character あ into IRB and watching it fail.

$ irb
irb(main):001:0> ab = "?"    <---- Tried entering the character あ
SyntaxError: (irb):1: invalid multibyte char (UTF-8)
(irb):1: unterminated string meets end of file
from /usr/local/bin/irb19:12:in `'

After a lot of head scritching I was able to narrow it down to something with readline:

$ irb --noreadline
irb(main):002:0> ab = "あ"
=> "あ"
irb(main):003:0>

After some more digging into the issue. The root cause seems to be the lack of GNU readline. By default, Ruby will link in the system installed readline library on OS X which is called editline [4]. Unfortunately, editline does not support UTF8 or multi-byte character sets which makes this a no-go for daily usage.

Most of the other references suggest downloading readline from source and installing into /usr/local however I believe this defeats the purpose of using something like MacPorts. After a bit of finagling I found that this is the invocation to get things working.

wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/rub...
tar xvzf ruby-1.9.1-p243.tar.gz
cd ruby-1.9.1-p243
# Don't trust MacPorts version of autoconf because it somehow nuked the
# --with-readline-dir option
/usr/bin/autoconf
./configure --with-readline-dir=/opt/local --enable-shared --program-suffix=19 --enable-pthread
make
sudo make install

I have it wrapped up in a script which you can see here.

References

[1] http://wonko.com/post/how-to-compile-rub…
[2] http://frozenplague.net/2009/01/ruby-191…
[3] http://rvm.beginrescueend.com/
[4] http://thrysoee.dk/editline/

OpenMac, yes, me wants one

hoanga — Mon, 14 Apr 2008 15:15:35 +0000

From their website

OpenMac: The Smart Alternative to an Apple

The Psystar OpenMac works just like an Apple Macintosh

Yes, very desirable. However, we’ll see if Apple lets them continue with it…

Hope they don’t get sued out of existence

OS X 10.4.11 update, you suck

hoanga — Mon, 14 Apr 2008 15:10:33 +0000

After a long time of not updating my trusty old iLamp iMac, I finally updated it to 10.4.11 over the weekend and let it lie. Later on I hear a report that Safari won’t start up.

That’s odd, I’ve never heard of Safari having launch problems before. I check the log and I see something like the following:

Date/Time:      2008-04-14 22:06:45.474 +0900
OS Version:     10.4.11 (Build 8S165)
Report Version: 4

Command: Safari
Path:    /Applications/Safari.app/Contents/MacOS/Safari
Parent:  WindowServer [86]

Version: 3.1 (4525.13)

PID:    20987
Thread: Unknown

Link (dyld) error:

Symbol not found: _WebDatabaseDirectoryDefaultsKey
  Referenced from: /Applications/Safari.app/Contents/MacOS/Safari
  Expected in: /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit

Those type of messages go on and on in Console.app. My first round of Googling brought me to a Macrumors thread that recommended deleting the history.plist and other parts from ~/Library/Safari. I tried removing various files from that directory to no effect and finally just removing the directory altogether. Nada.

Troubleshooting a PC WITHOUT a web browser really sucks. I suggest everyone try it once in awhile to see just how much the nature of debugging IT problems has changed when you are deprived of a very powerful tool. Luckily, this Mac had a very crufty version of IE lurking so the first thing I tried was a download of Firefox. However, the disk image refused to be mounted! Seems this is also tied in with the security update. So basically, I’m left with using IE as my main tool for debugging on this Mac.

After a bit of googling, it seems that the fix is tied requiring the latest OS X security update (Available at the Support Download page). For OS X 10.4.x users you can find a link to the latest Universal here.

However, there is a catch. The security update is only available from that page as a Disk Image. Guess what you can’t open it up under the affected Mac. At this point you’re left with 2 options:

Burn the Disk Image to a CD-R/DVD-R and use it that way
Transfer the disk image to another Mac and unarchive it then push it back

I decided on the latter option since I hate wasting a CD-R if I don’t have to. After applying the Security Update and rebooting, Safari boots up and things seem chipper again but that was a serious side trip on something I’ve rarely seen Apple ever mess up. Anti-kudos to Apple for making this update on your ‘legacy’ OS really sucky.

Fixing that really irritating perl: warning: Setting locale failed. on OS X leopard

hoanga — Thu, 10 Apr 2008 14:19:16 +0000

Anytime I’ve been running a perl based script on my leopard box I got this really irritating output with whatever else I was expecting:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
     LC_ALL = "En_US",
     LANG = (unset)
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

With a quick Google search I found an answer in this Rubify post. Basically the solution / fix is to make sure the following is set in either your ~/.profile or ~/.bashrc or ~/.cshrc

# This setting is for the new UTF-8 terminal support
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8

Getting erlang to build on MacPorts with an installed iPhone Open SDK

hoanga — Fri, 21 Mar 2008 14:48:35 +0000

I had some serious unexpected fun trying to install erlang on my OS X box using MacPorts. In general it’s usually a no brainer you usually type sudo port install and you have a new package installed without that much fuss. However here is the partial log of trying to install erlang and it blowing up…

$ sudo port install icu erlang
... ICU installs without a problem ...
--->  Fetching tcl
--->  Attempting to fetch tcl8.5.1-src.tar.gz from http://downloads.sourceforge.net/tcl
--->  Verifying checksum(s) for tcl
--->  Extracting tcl
--->  Configuring tcl
--->  Building tcl with target all
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix" && make all " returned error 2
Command output: /usr/bin/gcc-4.0 -c -Os -O2 -pipe    -Wall -Wno-implicit-int -fno-common -I. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../generic -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../libtommath -DPACKAGE_NAME=\"tcl\" -
...
...
...
_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c
In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c:62:
/usr/local/include/mach-o/arch.h:35: error: nested redefinition of 'enum NXByteOrder'
/usr/local/include/mach-o/arch.h:35: error: redeclaration of 'enum NXByteOrder'
/usr/local/include/mach-o/arch.h:36: error: redeclaration of enumerator 'NX_UnknownByteOrder'
/usr/include/architecture/byte_order.h:137: error: previous definition of 'NX_UnknownByteOrder' was here
/usr/local/include/mach-o/arch.h:37: error: redeclaration of enumerator 'NX_LittleEndian'
/usr/include/architecture/byte_order.h:138: error: previous definition of 'NX_LittleEndian' was here
/usr/local/include/mach-o/arch.h:39: error: redeclaration of enumerator 'NX_BigEndian'
/usr/include/architecture/byte_order.h:140: error: previous definition of 'NX_BigEndian' was here
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c: In function 'TclpFindSymbol':
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c:382: warning: 'NSLookupSymbolInImage' is deprecated (declared at /usr/include/mach-o/dyld.h:182)
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c:415: warning: 'NSLinkEditError' is deprecated (declared at /usr/include/mach-o/dyld.h:217)
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c:419: warning: 'NSLookupSymbolInModule' is deprecated (declared at /usr/include/mach-o/dyld.h:181)
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c:428: warning: 'NSAddressOfSymbol' is deprecated (declared at /usr/include/mach-o/dyld.h:188)
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c: In function 'TclpUnloadFile':
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c:493: warning: 'NSUnLinkModule' is deprecated (declared at /usr/include/mach-o/dyld.h:169)
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c: In function 'TclpLoadMemory':
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c:697: warning: 'NSCreateObjectFileImageFromMemory' is deprecated (declared at /usr/include/mach-o/dyld.h:146)
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c:730: warning: 'NSLinkModule' is deprecated (declared at /usr/include/mach-o/dyld.h:161)
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c:732: warning: 'NSDestroyObjectFileImage' is deprecated (declared at /usr/include/mach-o/dyld.h:147)
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_tcl/work/tcl8.5.1/unix/../unix/tclLoadDyld.c:740: warning: 'NSLinkEditError' is deprecated (declared at /usr/include/mach-o/dyld.h:217)
make: *** [tclLoadDyld.o] Error 1

Error: The following dependencies failed to build: tk tcl
Error: Status 1 encountered during processing.

Pretty sucky, huh? My first lazy thought was, “I thought the point of a package manager was to avoid all these problems.”

After a little bit of thinking and staring at the error message, I did the workaround and moved the /usr/local/include directory away and tried rebuilding which made things much happier. Check the log below…

$ cd /usr/local
l$ ls
arm-apple-darwin	include			man
bin			info			share
docs			lib
etc			libexec
$ sudo mv include include.ignore
l$ sudo port install icu erlang
Skipping org.macports.activate (icu ) since this port is already active
--->  Cleaning icu
--->  Building tcl with target all
--->  Staging tcl into destroot
--->  Installing tcl 8.5.1_0
--->  Activating tcl 8.5.1_0

Voila. A working erlang install. Don’t forget to move back the include directory back to its old place.

Latest rev of Macbooks and keyboard conking out after sleep

hoanga — Sun, 02 Dec 2007 20:30:49 +0000

So I’ve been slowly re-initiating myself into the Church of Mac with a new Macbook however not all is well in Mac-land…

It seems the Macbook can have an unresponsive keyboard if you sleep it and wake it up (Also here).

Needless to say I find this bug extremely irritating and it really hurts the one of the primary raisons d’etre for owning a Mac (ultra-slick Sleep functionality that still is pretty rotten in Linux and Windows imo)

p.s. One workaround is to jam a key for 10 seconds or more when the unresponsiveness is happening. Just make sure you don’t jam something that can alter data badly like the… delete button?

References

Finally a gem release of ruby-opengl

hoanga — Thu, 22 Feb 2007 01:05:29 +0000

Just wanted to let folks know that I’ve finally figured out how to get the build system in place for ruby-opengl to:

Gemify itself
Build native extensions during Gem installation using mkrf

Which means (I hope) that there should be an easier way to get OpenGL working with Ruby. Currently it should support installing in Linux and OS X. Installation should be as difficult as:

gem install -y ruby-opengl

Deinstallation should be similar.

For win32 users, I’d suggest using the old bindings provided with the all-in-one installer although I’d like to get a gem built for win32 so hopefully it can get included in the all-in-one installer.

References

Excceelleent – KDE/Mac makes more progress

hoanga — Tue, 30 Dec 2003 17:45:06 +0000

Tales of the Racoon Fink is a very cool site if you’re interested in fink development and KDE porting to OS X. Personally, I’m psyched over KDE compatibility coming to OS X. That means piles and piles of applications that I’ve liked under Linux/BSD/UNIX will run natively in OS X. But it’s still making progress and is not ready for prime time. But every little step counts.

Here Ranger Rick shows Konqueror running:

Link to Post

Correction on Viewing Microsoft Compiled Help Files on OS X (You don’t need X11)

hoanga — Sun, 28 Dec 2003 11:16:55 +0000

Ted Leung was kind enough to point out to me on an earlier post I made on viewing CHM files on OS X. YOU DO NOT NEED X11 to view CHM files. xchm uses wxWindows as its backend which has a native OS X port. Definite bonus in my book!

My Old incorrect post

Ted’s Original Post on viewing CHM files under OS X

Viewing Microsoft Compiled HTML Files (CHM) in OS X

hoanga — Thu, 25 Dec 2003 18:15:26 +0000

Ted Leung describes how he built xchm which is a X11 app that lets you view Microsoft Compiled Help Files (CHM). THis is really handy although needing X11 is a semi bummer but a liveable one

Obligatory Excerpt:

I got xchm to build on Mac OS X. This is an open source view for compiled HTML help (CHM) files that are mostly used on Windows. The reason that I wanted xchm is that the Python docs are available in CHM format. The advantage of CHM is that its highly searchable (and you can search when you have no network connectivity). So this is a great way to get goo d access to documentation for Python, which I still need at this point.

CHM files are quite handy under Windows I must admit so it’s good to see a tool to let you view it on OS X

Link to Ted Leung’s Post

Rhino JavaScripting on OS X

hoanga — Thu, 25 Dec 2003 16:55:18 +0000

From Ranchero’s Weblog I saw this Weblog Entry on getting the Rhino JavaScript engine setup in OS X. This is pretty neat especially for people who are heavy into ECMA/JavaScript hacking as it allows them to leverage all of their sensibilities of JavaScript for doing scripting tasks.

The breakdown of tasks you need to do are:

Grab the Rhino Tarball from the Mozilla site
Then do some customizations to your shell environment to be able to run it easily

One thing to note is that Rhino relies on a Java VM to be installed as it is basically a JAR file with a bunch of extra functionality. One bonus for OS X is that Java is already installed with OS X (isn’t it nice not having to go hunting around Sun’s website looking for a bloody JVM then waiting for some huuuuge download to finish?). However a detractor is that it’s Java. I’ve tried writing some command line tools using Java and I find them clunky as you have to do lots of annoying contortions to just run it correctly at the command line. For a seasoned Java programmer it’s probably business as usual…

However, I already know my way around Ruby, Python, and am fluent enough in plain Bourne SHell syntax that I don’t see the point of adding yet another tool to compete with my CLI tasks. Right now, I’ve truly decided on Ruby as my scripting language once it gets outside of the realm of too much difficult logic in Bourne Shell (I still use this when the needs are simple). I like Python but it sucks trying to get Python working properly in a command pipeline. But if you do the normal, write a file, then run it in the interpreter it won’t make a big difference. OR if you use some fancy IDE.

But either way, choice is good and I’m sure JavaScript fans will be able to benefit most from this

Link to getting JavaScript up on OS X

Getting 802.11g working on older PowerBooks preview

hoanga — Tue, 23 Dec 2003 04:41:29 +0000

I got 802.11g working on an older PowerBook (NOT with an Airport Extreme card but a normal CardBus one). I’ll document more of my the experiences I had with going with what I thought ‘would just work’ in a later blog.

Some OS X Panther CLI Goodies

hoanga — Wed, 03 Dec 2003 06:16:37 +0000

Seems Panther keeps surprising me (or I just don’t check the CLI commands enough) but it seems that the Net SNMP Libraries are included with Panther along with Netcat. These are powerful network utilities I use a lot in UNIX land. I’m glad they’ve been included in Panther (perhaps earlier? Anyone know?).

As with all powerful tools, use them responsibly. If you’re curious about them just do a man on them.

Notes from a Mac in Windoze land

hoanga — Tue, 18 Nov 2003 11:05:54 +0000

The Harvard Business School requires that its students use an IBM ThinkPad if they wish to be enrolled at the business school. That’s REQUIREMENT not RECOMMENDATION. Seems one of the business school students decided a little differently and setup a weblog documenting his experiences walking in a Windoze universe with a Mac. So far it seems he’s been doing well and continuously questions the need for a Windoze laptop rather than a very strong recommendation. I wish you luck in turning the tide, sir!

Link to Weblog

Adding scriptable items in OS X Address Book

hoanga — Sun, 16 Nov 2003 10:35:19 +0000

This is really neat and I didn’t even know about it. Kudos to Mac OS X Hints for publishing this one. Mac OS X Hints is a great place to find information on Mac OS X.

Phoby the wonder slide show app for OS X

hoanga — Sat, 08 Nov 2003 16:38:42 +0000

Stumbled across this one reading the Squeak Japanese Mailing List and checking out YFB’s Blog

What is it you ask? A slide show application that supports transparency and can always stay in front so you can have a transculent slide show going on while doing other stuff. Talk about an utterly gratuitous way to use Quart Extreme! And coolest of all, the app is GPL’ed.

Link to App

Linux NFS Stupidity

hoanga — Sat, 08 Nov 2003 09:59:21 +0000

There’s a story on Mac OS X Hints about people who NFS mount their home directories are having problems in Panther if they use a Linux NFS Server (must… control… stuck… up… snicker… argh… who am I kidding). Anyways there’s a link to the NFS Source code with a patch for fixing this problem in Linux. You can look at that here.
Looking through the patch is rather educational in seeing how things are fixed. But looking at this particular code fragment (the comments in particular) just made me laugh.


 /*
- *	NLM cookies. Technically they can be 1K, Nobody uses over 8 bytes
- *	however.
+ *	NLM cookies. Technically they can be 1K, Few people use over 8 bytes,
+ *	FreeBSD uses 16, Apple Mac OS-X 10.3 uses 20.
  */

 struct nlm_cookie
 {
-	unsigned char data[8];
 	unsigned int len;
+#define NLM_MAXCOOKIELEN    	32
+	unsigned char data[NLM_MAXCOOKIELEN];
 };

I can understand at one point the person that implemented the NFS Server probably thought no one else used more than 8 bytes for passing these things known as MLN cookies. I bet he never really bothered to look at BSD code until this Panther problem came up rather recently. But it’s nice that they got around to fixing it. The summary of the fix is to fix up the cookie declaration to use up to 32 bytes (and hope that’s large enough for all implementations) as shown above
And also change accesses to a cookie data with a function accessor rather than pulling it directly from the pointer (ick). Here’s a small code snippet to show the differences:


-				*(unsigned int*)(block->b_call.a_args.cookie.data));
+				nlmdbg_cookie2a(&block->b_call.a_args.cookie));

Hopefully the patch will make it upstream to prevent all the other poor Linux server users who use OS X as clients from continuously suffering. However, on reflection as an ordinary user I wouldn’t be flipping through all the NFS code in the Linux kernel JUST to find out compatibility issues like this nor even would I know where to start looking (unless there was a nice document with a comparison chart for all of this) so I’d probably assume things are okay and just go ahead and try it. But when people ask why I use FreeBSD over Linux it’s exactly for stuff like this that I worry about. Insidious evil interaction problems that would be really hard to catch unless you put it through certain circumstances. Or the simpler solution is just run one platform (but that’s boring).

You didn’t backup did you?

hoanga — Sat, 08 Nov 2003 06:27:19 +0000

Oh crap. The Archive and Install option in Panther nuked all of the customizations I had put into the Apache CGI Directory!

Worry worry worry…
Oh yes…
Fire up Terminal:

cd /
ls /
Hmmm, hey I see /Previous Systems
cd /Previous Systems/Previous System 1/Library/WebServer/CGI-Executables
ls

Dear sweet sweet day. It’s still there!!!!

BottomFeeder for OS X Mini-Review

hoanga — Mon, 27 Oct 2003 10:32:39 +0000

I downloaded BottomFeeder, a SmallTalk powered blogging tool. I was really overjoyed to see it being a cross-platform piece of software with OS X support. So I glady downloaded it and started looking through it. Here is what I found…

First off, the manual didn’t have any explanation besides the bare minimum for how to get this running in OS X. Plenty of instructions for Windoze users. How the hell is this supposed to work? How am I supposed to install it? Okay whatever I can figure this out…
When I uncompressed it I just found a directory full of files. There wasn’t an Application Bundle that I could just drag around and start up. It seems there was some file called bottomFeeder. What’s that? Is that the executable? Clicking on it in the Finder didn’t do squat. How am I supposed to make this run anything?
A little thought I drop into the Terminal then try typing ./bottomFeeder. Now a window pops up that says ‘Open’. What the heck is that for? Oh I get… it’s a SmallTalk program looking for an image. Okay…. I’m supposed to find the image file. Just look for the large file sitting around.
Next I try, ./bottomFeeder bottomFeeder.im
I start looking through the menus. Hmmm doesn’t look that bad. I want to import all my NetNewsWire subscriptions into it. I just need to use the Import subscriptions. Hey… wait where’s the .opml import? I try loading All Files and then loading it in, no go. I wanna quit… Cmd-q. No?
Ugh, this is the last straw. BottomFeeder for Windows might work quite well and integrate well with the Windows GUI however for OS X it’s an embarassment. Nothing in the DOck, nothing in the Finder Bar on top, no instructions on how to get started. And the last straw… how come it can import piles of different file types but NOT the one I need to use??? Geez

Score: 1/10
At least the thing runs and does stuff but I can’t do any blogging in this thing. Back to the drawing board. If this is supposed to show SmallTalk’s power I’m not convinced. I want to be a believer but not with a demonstration like that.

More Panther goodness

hoanga — Sun, 26 Oct 2003 17:46:43 +0000

I’ve been getting acquainted with Panther’s new features. So far I find the UI snappier than Jaguar which is a good thing since I want my UI to wait for me and NOT the other way around.
But here’s some very cool stuff:

man sendmail

SENDMAIL(1) SENDMAIL(1) NAME sendmail - Postfix to Sendmail compatibility interface

man vi

VIM(1) VIM(1) NAME vim - Vi IMproved, a programmers text editor

Apple’s been doing some cleanup under the hood of the UNIX layer underneath. Now that’s service! One other nice thing I’ve noticed is they’ve been going through cleanups of the UI for various programs and making sure that Cmd-, actually means bring up the Preferences. Beforehand programs like Mail.app DID NOT respect this convention and it made it a pain to memorize which particular programs adhered to the new set of keybindings and which ones didn’t but I’m very glad Apple has been going around fixing these warts that have made daily usage a pain.