VisualWorks problems on (some) Linux distros
Some people have reported problems running VW on Linux - various distros, with the common denominator being a failure to start up. We've identified the problem, but are still working on the best approach to fixing it. Here's the description that comes from our internal bug tracking system:
Logging in using the default window manager (or any WM that launches the Gnome suite of applications) and session causes a program named 'gnome-settings-daemon' to start. Part of the initialization of this process involves creating the directories ~/.gnome2/share/cursor-fonts and ~/.gnome2/share/fonts that are prepended and appended, respectively, to the X server's font path. Unless the user has installed any fonts under these directories, they are both considered to be "invalid" by the X server since the fonts.dir file in both will not contain any font data. This causes the XSetFontPath() request (sent by gnome-settings-daemon) to fail. Internally, the first action taken by XSetFontPath() is to clear out a static variable named FontFileBitmapSources that contains data about each of the configured directories in the X server's font path. Each directory in the argument to XSetFontPath() is processed sequentially and data is added to FontFileBitmapSources at the successfull completion of adding the directory. If one of the directories should fail the initialization process (e.g., it doesn't exist, isn't readable, or doesn't contain any fonts), then any directories in the path that come after the failed directory are ignored. On encountering an invalid directory, XSetFontPath() returns and the server sends a BadValue error to the client. gnome-settings-daemon discards the error. The behavior of XSetFontPath() described above can be seen on any official version of X11R6.
There's more, but here's the bottom line - in trying to get a font match, the font logic in the VM fails because of the empty pre-pended font directory. So we've diagnosed the problem; the fix will likely involve surfacing some of the font logic out of the VM and up to the Smalltalk level, where it can be handled more easily.
Comments
[Tom Sattler] April 7, 2006 8:17:08.085
I use KDE on Fedora, and I've never seen this.
Workaround
[ Alan Knight] April 7, 2006 9:47:55.032
Comment by Alan Knight
A couple of thing to note with this.
One is that if this is the problem you're experiencing, then you can work around it fairly easily by running
before running VisualWorks. However, there's another unrelated issue on some Linux distributions with failing to set the locale, which requires a code change. That second issue affects, e.g. my Ubuntu system, but appears to not affect Gentoo, although it's hard to tell with Gentoo, because it's so variable. The font issue, being based on the gnome daemon obviously doesn't affect installations using KDE.Ubuntu locale problem
[Jeff Hallman] April 8, 2006 22:09:33.187
Alan, I've been waiting for a fix for this for months. Is it going to happen? When?
Ubuntu locale problem
[ Alan Knight] April 11, 2006 22:02:53.917
Comment by Alan Knight
The apr06.2 build should have a "fix" for the Ubuntu locale problem. The reason I put quotes around it is that all it does is print an error message that it wasn't able to set the locale properly, and proceed as normal. The proper fix is at the Ubuntu level. If you don't care about getting the error message, then you can just put an exception handler around the call to primSetLocale, and ignore the error. The easiest way to do that is to do it on some other system.