This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: VisualWorks problems on (some) Linux distros
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
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.