Tuesday, July 01, 2008

PLT Scheme on Vista

First off, I'd like to thank Eli Barzilay from the PLT team for helping track down these Vista 'features' that, together with a PLaneT 'feature', are causing my PLT Scheme problems on Vista. We also found the reason for long PLaneT download times on PLT Scheme V4.0 in the process.

This particular problem started when I tried to upgrade to PLT Scheme V4.0.1. After uninstalling PLT Scheme V4.0 (and making sure the uninstall completely removed the C:\Program Files\PLT directory) and installing V4.0.1, I would get the error "collects\srfi\compiled\provider_ss.zo::0: read (compiled): code compiled for version 4.0, not 4.0.1". I reported this on the bug tracker (http://bugs.plt-scheme.org/query/?cmd=view&pr=9554) where you can read the e-mail thread on the problem.

The Vista 'feature' that is biting us is called "UAC virtualization services" and is described in this article on the National Instruments Developer Site. (I'm sure there are many other such explainations that could be referenced.) It's a good read and goes into details that I will only summarize here. In short, if a user application attempts to modify protected portions of the file system (like C:\Program Files), the UAC virtualization service silently redirects the access to an unprotected, site-specific area (like C:\Users\doug\AppData\Local\VirtualStore\Program Files). Subsequent reads of affected files will use the copy in the virtual store. The problem is that install and uninstall (and probably some other application specific programs) don't know about the virtual store and files stay persistant across uninstall/install boundaries.

This was coupled with the current PLaneT 'feature' (http://bugs.plt-scheme.org/query/gnatsweb.pl?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=9555) that compiles PLaneT packages with errortrace (i.e., debugging) when the initial require is from within DrScheme - it doesn't seem to happen from within MzScheme. In my case, when I would require the science collection (for example) from within DrScheme, it would download the collection and compile it and all referenced collections with errortrace turned on. This would recompile the referenced PLT Scheme collections (in C:\Program Files\PLT\collects) and the compiled files were put in the virtual store. This works okay until the uninstall of V4.0 and install of V4.0.1 where the compiled files in the virtual store (from V4.0) were seen instead of the newly installed files (from V4.0.1).

In any case, you can read the e-mail thread in the bug list for the details of how we finally tracked the problem down.

There are some work arounds that can be used until the PLT Scheme team figures out the best way to 'play nice' with Vista - although it would be nice if Vista played nice with legacy applications, but don't hold your breath for that.
  1. When you do an uninstall, check to see if C:\Users\<user>\AppData\Local\VirtualStore\PLT exists. If it does, delete it also. This will remove the user modified files that might exist - even if they didn't realize they had modified any. [Note that the location of the virtual store may be different, so you might want to do a search for 'PLT' and include system and hidden files in the search. Also, if there are multiple users, they may be multiple virtual stores.]
  2. For the initial load of PLaneT collections where you don't want errortrace turned on, do the initial require from MzScheme. For example, start up MzScheme from the command prompt and type "(require (planet "science.ss" ("williams" "science.plt")))" to load the science collection. This should work for any collection.
I will be 'upgrading' by laptop from Vista to XP and at least the first problem will go away. I would still recommend doing the initial require for PLaneT packages from MzScheme. I still have my Vista machine at home and will be dealing with some of these issues in an on-going basis.



Post a Comment

<< Home