From jdunrue at gmail.com Wed Nov 1 22:54:56 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Wed, 1 Nov 2006 15:54:56 -0700 Subject: [graphic-forms-devel] fixes for the config and loading process Message-ID: Mea culpa. I have not been adequately testing the configuration and loading process documented in the top-level README, and have found to my chagrin that it was badly broken. I will stop using my private build.lisp to help make sure this doesn't happen in the future. Please find attached replacements for files in the Graphic-Forms source distribution. The procedure documented in the README is still valid. My apologies to anyone that has tried to experiment with GF and been stymied by these mistakes. Thanks to Mark Haniford for his problem reports. -- Jack Unrue -------------- next part -------------- A non-text attachment was scrubbed... Name: graphic-forms-tests.asd Type: application/octet-stream Size: 3893 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tests.lisp Type: application/octet-stream Size: 2527 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.lisp Type: application/octet-stream Size: 2778 bytes Desc: not available URL: From jdunrue at gmail.com Sun Nov 5 21:05:18 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Sun, 5 Nov 2006 14:05:18 -0700 Subject: [graphic-forms-devel] updated fixes for loading the system Message-ID: Please find attached an updated set of fixes for loading the library and the test programs. I've fixed some confusion in the initialization of the gfsys::*gf-tests-dir* variable. I've verified (again) that the procedure documented in the top-level readme works. Also, the file extensions may be getting munged for these attachments. The files are: graphic-forms-tests.asd config.lisp tests.lisp all of which go in the top of the installation directory. -- Jack Unrue -------------- next part -------------- A non-text attachment was scrubbed... Name: graphic-forms-tests.asd Type: application/octet-stream Size: 3893 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.lisp Type: application/octet-stream Size: 2846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tests.lisp Type: application/octet-stream Size: 2541 bytes Desc: not available URL: From jdunrue at gmail.com Sun Nov 5 21:18:36 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Sun, 5 Nov 2006 14:18:36 -0700 Subject: [graphic-forms-devel] SLIME and SBCL issues Message-ID: I've been investigating a problem where starting a Graphic-Forms app from within SLIME using the SBCL backend results in seemingly nothing but a hang. What appears to be happening is that the message loop in GF is not even getting past the first call to the Windows get-message function. I fired up Winspector Spy, which is a utility for inspecting the window hierarchy, and saw that application windows are getting created. But since no messages are getting processed (except for maybe the very initial WM_NCCREATE or WM_NCCSIZE), the windows don't appear and obviously are non-functional. This problem has something to do with the combination of SLIME and SBCL, since CLISP and SLIME work together ok as fas as GF is concerned. Also, running SBCL from a command prompt works, albeit that's not nearly as nice an environment. So there are a couple workarounds right now (both assuming that you want to use SLIME, rather than the LispWorks IDE). The first is to switch to CLISP at least for the time being, as this is a configuration that works fine. The second is to run SBCL from a command prompt. It's important to keep in mind that SBCL/Win32 is currently still a single-threaded Lisp like CLISP is, so in both cases, the SLIME REPL would be queueing requests until the message loop exits. When we see multi-threading support appear in those Lisps, then hopefully we can get back our REPL while our GF apps are running. I've sent a query to the slime-devel list in the hopes of getting some pointers to possible solutions, and I will continue to investigate this problem myself as time allows. -- Jack Unrue