The Artima Developer Community
Sponsored Link

Agile Buzz Forum
VisualWorks problems on (some) Linux distros

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
James Robertson

Posts: 29924
Nickname: jarober61
Registered: Jun, 2003

David Buck, Smalltalker at large
VisualWorks problems on (some) Linux distros Posted: Apr 7, 2006 5:35 AM
Reply to this message Reply

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.
Latest Agile Buzz Posts
Latest Agile Buzz Posts by James Robertson
Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Advertisement

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.

Read: VisualWorks problems on (some) Linux distros

Topic: Agile is Based on Communication and Feedback Previous Topic   Next Topic Topic: Video industry to consumers: drop dead

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use