had to upgrade from ghc-5.02.2 to ghc-5.02.3 because of an access violation bug, and ghc upgrades "naturally" mean HOpenGL rebuilds.. 1. there's a slight problem with HOpenGL's configure on cygwin: GreenCard installs (as expected) in c:/Program\ Files/GreenCard/ (note the space), and is found there by configure. By default, however, configure seems to lose the escape for the space in the path, so I explicitly give the path as something like: ./configure -with-green-card=c:/Program\\\ Files/GreenCard/green-card.exe That kind of works, but for the test for GreenCard's comma bug, where the executable isn't found, which configure then misinterprets by setting ..bug="yes", which then leads to errors while GreenCarding in make depend. I used to think I understood shell escapes, but that was long ago, and this one has me baffled for the moment - the value of $green_card in configure seems ok when echoed, and cygwin's bash can find the GreenCard executable with the path echo gives for $green_card, but when configure tries to call $green_card, it fails to find the executable (quite unlike later calls during make depend).. For the moment, I override the result of the GreenCard comma bug test to "no", and things seem to work okay, but there has to be a better way to set this right.. An annoying new feature are lots of warnings whenever I compile any HOpenGL stuff, of the kind: Module `GL_BeginEnd' is located in package `Main' but its interface file claims it is part of package `HOpenGL' This is easily rectified by doing make install, and the ghc package option is really nice, so I won't complain;-) but what about people who don't have permission to install the package by adding to ghc's imports? Is it possible to have local packages with central ghc installations? Apart from that, nice work!-) 2. What, if anything, do we know about the scheduling of the GLUT callbacks? Thanks to GLUT's per-thread system, there seems to be only one OS-thread doing all the GLUT/GLU/GL-code for a given window (?), which translates into a single Haskell thread in ghc's (current) default configuration. Can I assume that callbacks will always run to completion, or could keyboard input or redraws come in during a call to display (and potentially trigger a redisplay before the old one has run through?). What about stuff in idleFunc? Claus