gmane.lisp.steel-bank.devel

test failure: Unhandled memory fault :FELL-THROUGH,SCBL 1.0.19 on Mac 10.5.4

Jason Addison — 2008-08-30T08:18:28

reporting test failure as instructed by test failure: Mac OS X 10.5.4 Installed scbl 1.0.19 binary and asdf'd hunchentoot realized I wanted threaded build downloaded scbl 1.0.19 source and built ran tests, failure typed (SB-EXT:QUIT) as instructed at ldb> prompt, hung in terminal last of testing output: ... [saving current Lisp image into /Users/jra/usr/src/src/sbcl-1.0.19/tests/foreign-test-72435/foreign-test.fast.core: scanning space for lutexes... writing 3576 bytes from the read-only space at 0x04000000 scanning space for lutexes... writing 2160 bytes from the static space at 0x04100000 scanning space for lutexes... writing 23969792 bytes from the dynamic space at 0x10000000 writing 11 lutexes to the core... done] test save fast ok (successful save) testing start fast This is SBCL 1.0.19, an implementation of ANSI Common Lisp. More information about SBCL is available at . SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Unhandled memory fault at #x-5EE0080E. :FELL-THROUGH Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. (no restarts: If you didn't do this on purpose, please report it as a bug.) fatal error encountered in SBCL pid 72505(tid 2953318400): vm_region (VM_REGION_BASIC_INFO) failed failed 1 Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

WITH-ALIEN leaks stack on x86-oids with non-SBCL xchosts

Josh Elsasser — 2008-08-30T06:49:13

Testing for features in the cross compiler instead of the host would be a good idea here: --- src/code/target-alieneval.lisp +++ src/code/target-alieneval.lisp < at >< at > -180,10 +180,10 < at >< at > `(symbol-macrolet ((&auxiliary-type-definitions& ,(append *new-auxiliary-types* (auxiliary-type-definitions env)))) - #+(or x86 x86-64) + #!+(or x86 x86-64) (let ((sb!vm::*alien-stack* sb!vm::*alien-stack*)) ,< at >body) - #-(or x86 x86-64) + #!-(or x86 x86-64) ,< at >body))) ;;;; runtime C values that don't correspond directly to Lisp types ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Simplifying the EBX patch (and x86 backend ingeneral)

Elliott Slaughter — 2008-08-30T03:34:30

On Fri, Aug 29, 2008 at 1:42 PM, Matthew D. Swank gmail.com> wrote: What target features did you build with? This is only a patch for reserving the EBX register (and using EBX threads on linux), it does not contain the changes necessary to compile with sb-thread on win32. -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Simplifying the EBX patch (and x86 backend ingeneral)

Matthew D. Swank — 2008-08-29T20:42:37

combined.patch I applied the second patch to the current cvs and tried to compile on win32 using cygwin. Is there another directory I need to include to get the headers right? Here are the errors: beginning GENESIS, creating headers in "src/runtime/genesis" NIL * real 3m0.661s user 0m0.061s sys 0m0.092s //entering make-target-1.sh //building runtime system and symbol table file make: Entering directory `/usr/local/src/sbcl-dev/sbcl-build-threads/src/runtime' rm -f *.[do] sbcl.exe sbcl.nm sbcl.h core *.tmp make: Leaving directory `/usr/local/src/sbcl-dev/sbcl-build-threads /src/runtime' make: Entering directory `/usr/local/src/sbcl-dev/sbcl-build-threads/src/runtime' echo '#include "genesis/config.h"' >sbcl.h echo '#include "genesis/constants.h"' >>sbcl.h x86-assem.S:278:2: #error "need to save BSP here, but don't know how yet." win32-os.c:57:19: excpt.h: No such file or directory make: Leaving directory `/usr/local/src/sbcl-dev/sbcl-build-threads /src/runtime' make: Entering directory `/usr/local/src/sbcl-dev/sbcl-build-threads/src/runtime' gcc -g -Wall -O3 -mno-cygwin -I. -c -o alloc.o alloc.c In file included from alloc.c:21: runtime.h:65:21: pthread.h: No such file or directory In file included from alloc.c:21: runtime.h:66: error: parse error before "os_thread_t" runtime.h:66: warning: type defaults to `int' in declaration of `os_thread_t' runtime.h:66: warning: data definition has no type or storage class In file included from alloc.c:24: globals.h:46: error: parse error before "specials" globals.h:46: warning: type defaults to `int' in declaration of `specials' globals.h:46: warning: data definition has no type or storage class In file included from thread.h:19, from alloc.c:26: genesis/thread.h:19: warning: type defaults to `int' in declaration of `os_thread_t' genesis/thread.h:19: warning: no semicolon at end of struct or union genesis/thread.h:19: error: parse error before "os_thread" genesis/thread.h:21: error: parse error before '*' token genesis/thread.h:21: warning: type defaults to `int' in declaration of `os_attr' genesis/thread.h:21: warning: data definition has no type or storage class genesis/thread.h:38: error: parse error before '}' token In file included from alloc.c:26: thread.h:30: error: field `thread' has incomplete type thread.h: In function `get_interrupt_context_for_thread': thread.h:125: error: dereferencing pointer to incomplete type thread.h: In function `arch_os_get_current_thread': thread.h:176: warning: implicit declaration of function `pthread_getspecific' thread.h:176: warning: return makes pointer from integer without a cast thread.h: At top level: thread.h:204: error: parse error before "os_thread" make: *** [alloc.o] Error 1 make: Leaving directory `/usr/local/src/sbcl-dev/sbcl-build-threads/src /runtime' ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[slime-devel] Threading warnings on SBCL 1.0.19 Darwinx86

Scott Bell — 2008-08-29T19:50:59

Apologies folks for the cross-threading, this is related to the issue many have experienced running SLIME on a threaded SBCL under Darwin x86. On 29-Aug-08, at 3:22 AM, Nikodemus Siivola wrote: No, sorry for my bogus knowledge. Last time I checked, which was probably during 10.4, the only timed wait I found was the IIRC SemaphoreWait or similar which did not like SBCL at all. (Mysterious messages to terminal is not usually a good sign...) Support for a timeout value appears to be there for futexes, and I think all of the lutex platforms support pthread_cond_timedwait. It should be fairly simple to support a :TIMEOUT optional parameter in CONDITION-WAIT. To address the issue, are there any major concerns with the following approach? Index: src/code/target-thread.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/target-thread.lisp,v retrieving revision 1.93 diff -r1.93 target-thread.lisp 393,398c393,399 < (progn < ;; FIXME: This doesn't look interrupt safe! < (setf (mutex-%owner mutex) nil) < (with-lutex-address (queue-lutex-address (waitqueue-lutex queue)) < (with-lutex-address (mutex-lutex-address (mutex-lutex mutex)) < (%lutex-wait queue-lutex-address mutex-lutex-address))) --- Regards, - Scott Bell ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Compile on Linux (Ubuntu Gutsy)

Christophe Rhodes — 2008-08-27T16:24:08

I don't think anyone would use it for Real Work, other than perhaps Peter himself, but since I believe one of his regression tests is whether or not it can compile sbcl successfully, it would seem to be a reasonable thing to use to compile sbcl. Yeah, and you can probably successfully use clisp 2.33.2 to compile sbcl 0.8.13... 1.0.xx might be a different matter. (In that sense, the information on the website is indeed very outdated :-) Cheers, Christophe ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sbcl-devel mailing list Sbcl-devel< at >lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Compile on Linux (Ubuntu Gutsy)

Claudius Hamlet — 2008-08-27T13:19:55

True... The issue is probably resolved in upstream Xen versions, but it is our otherwise rock-solid production server with half a dozen virtual machines in continuous operation, so to update Xen + all kernels to deploy a new application is not a thing to undertake lightly. Is XCL (with which I have no previous experience) supported and straightforward to deploy? Version 0.0.0.0 doesn't inspire a lot of confidence... well, the http://www.sbcl.info/getting.html is quite specific: "SBCL can be compiled from source code using another ANSI-compliant Common Lisp implementation. As of SBCL 0.8.13, the following compilers are known to work: * SBCL itself * CMU Common Lisp, tested with 18e and 19a * OpenMCL 0.14.1 * CLISP 2.33.2""are known to work" really means to me "you're on the safe side if you go for one of these" – especially since the version given is so very specific. Nevertheless, if the self-compiled version is likely to be as problematic as the binary one, this may very well be a non-issue, at least for me... Best regards and many thanks, Claud __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sbcl-devel mailing list Sbcl-devel< at >lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Compile on Linux (Ubuntu Gutsy)

Christophe Rhodes — 2008-08-27T09:35:09

This, surely, needs to be reported to Xen developers? A userspace program shouldn't be able to panic the kernel. What is the actual aim (because "build from CLISP" is a little bit esoteric)? To bootstrap all the way from gcc? If so, I'd try Peter Graves' XCL instead, because it is (or was) at least tested occasionally by Peter himself. No, it isn't really outdated. The problem seems to be that using clisp as a bootstrap host is extremely sensitive, even to things such as the exact filepath of the sbcl source tree. My suspicion is that this is due to bugs in the clisp pretty-printer tickling the clisp garbage collector, but until I finish my work to make the contents of cross-built fasl files completely deterministic I can't prove this suspicion. The reason I say it's not outdated is that for some people on some platforms, some version of clisp works fine; on the other hand, I agree that it's not supported (and in fact the INSTALL file in the sbcl source distribution does not mention CLISP as a supported build host.) Best, Christophe ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Compile on Linux (Ubuntu Gutsy)

Nikodemus Siivola — 2008-08-27T09:20:42

Certain (older?) versions of Xen are reputed to be troublesome with SBCL, but I don't have any further details, unfortunately. The problem is, however, almost certainly independent of the way SBCL was built. Clisp is also known to be an unreliable build host (sometimes our fault, sometimes a Clisp issue). There is likely to be an earlier error (or a full WARNING) somewhere, though, in this case. Possibly some of the recentish defstruct changes go against the grain for Clisp (I vaguely recall an earlier time when a similar error was due to problematic defstruct code.) Cheers, -- Nikodemus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Compile on Linux (Ubuntu Gutsy)

Claudius Hamlet — 2008-08-27T08:22:25

Von: Aleksej Saushev inbox.ru> An: Claudius Hamlet yahoo.de> CC: sbcl-devel< at >lists.sourceforge.net Gesendet: Mittwoch, den 27. August 2008, 09:52:19 Uhr Betreff: Re: [Sbcl-devel] Compile on Linux (Ubuntu Gutsy) Claudius Hamlet yahoo.de> writes: Thank you for this information! That is good to know, especially since, http://www.sbcl.info/getting.html still lists clisp 2.33.2 (in that particular version) as one of the permissable ways to bootstrap sbcl. That information is then obviously outdated. Incidentally, the compilation of 1.0.15 dies with exactly the same error... Best regards, Claud __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Compile on Linux (Ubuntu Gutsy)

Claudius Hamlet — 2008-08-27T07:41:31

Hi! When trying to compile sbcl 1.0.19 on a x86-Ubuntu machine (Gutsy) using clisp 2.33.2 as the bootstrap system I run into problems. The binary sbcl version in Ubuntu itself causes our underlying Xen kernel to panick. My hope was that a self-compiled version might do better. Unfortunately, the build fails with the following stack trace: *************** 498 837 962 976 977 981 982 1008 1009 1012 1013 7835 8126 8486 8490 8491 7897 ** - Continuable Error EVAL: undefined function HOST-CLOAD-STEM Retry ** - Continuable Error EVAL: undefined function SB!VM:GENESIS Retry deleted #P"/tmp/sbcl-1.0.19/obj/from-host/src/code/defstruct.lisp-obj-tmp" Bye. 26.07user 1.52system 0:27.96elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+157794minor)pagefaults 0swaps //entering make-target-1.sh //building runtime system and symbol table file make: Entering directory `/tmp/sbcl-1.0.19/src/runtime' GNUmakefile:31: genesis/Makefile.features: No such file or directory make: *** No rule to make target `genesis/Makefile.features'. Stop. make: Leaving directory `/tmp/sbcl-1.0.19/src/runtime' Command exited with non-zero status 2 ******************* Similar stack traces are reported a number of times on the web, but without any suggestion as to its resolution.I'd be grateful for any hint. Best regards, Claud __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: FSet bug/question

Daniel Herring — 2008-08-26T23:59:29

This was answered to my satisfaction on sbcl-help. Thanks to everyone for looking at it. - Daniel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: FSet bug/question

Scott L. Burson — 2008-08-26T22:34:20

Quoting Paul Khuong gmail.com>: Could cause a cache miss, though. Does it really matter? Probably not. But I don't understand why you seem to think this is an important issue. What's wrong with the way I've done it? I'm not getting your point. If FSet did not shadow CL:LENGTH, either DEFUN or DEFMACRO would have gotten an error.

Re: FSet bug/question

Paul Khuong — 2008-08-26T22:05:37

Testing that a vector's length is zero should be pretty fast too, on any implementation that actually cares about execution speed. Especially these days, I'm fairly certain it's *at best* not a pessimisation to have a distinguished value instead of zero-length vectors. You're adding an, a priori, ill-predictable branch (unlike the type checks) to save a minuscule (nil?) amount of time. The important point is to use a function, not a macro. If FSet did not shadow CL:LENGTH, asdf would have logged an ERROR, not a WARNING. Paul Khuong ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: FSet bug/question

Scott L. Burson — 2008-08-26T21:34:17

Quoting Paul Khuong gmail.com>: Agreed. It doesn't save space, but comparing against NIL is very fast in all implementations of which I am aware. Dereferencing a special is not, on the other hand, always fast. FSet does in fact shadow CL:LENGTH, as Daniel said ("Where LENGTH has been shadowed as ..."). Whatever it is, I'm not seeing it in 1.0.15. Odd.

Re: FSet bug/question

Tobias C. Rittweiler — 2008-08-26T17:00:16

FWIW, I sometimes wish that NIL was not only the empty list, but also the empty sequence. This would enable you to write code similiarly to the Maybe Monad on more occasions. -T. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: FSet bug/question

Paul Khuong — 2008-08-26T16:55:34

That sounds like a topic for sbcl-help. The actual warning earlier in the compilation log. That's just ASDF telling you there was a warning, which isn't very useful to figure out *what* went wrong. This isn't a redefinition. Attempting to redefine CL:LENGTH would signal a package lock error. And CL:LENGTH still doesn't do that FSET:LENGTH does. If we inline this type dispatch, where does it stop? We only have three sorts of sequences: vectors, lists and the new generic sequences. More inlining is mostly useful when it opens up new optimisations that hopefully bring the code size back down. Code bloat never is, and I'm not sure this particular case is very common. Moreover, the normal out of line definition doesn't do much more work than that. So inlining that test is mostly useful to save a call. Even if, for FSET, this does provide a sensible improvement, I'm not sure that's true for most code (that passes (or null vector) values around) out there. Either way, is it so hard to (defvar *empty-vector* #())? I don't see the point of using NIL instead of an empty vector; it doesn't even save space! I believe that special case is better asked for explicitly. The proper way to achieve the desired effect would be to shadow CL:LENGTH and define a new LENGTH *function* and declaim it inline or define a compiler macro. It's just a warning, although without the warning itself it's hard to tell how serious it is. Maybe the author just ignored it. Again the actual warning would be useful. Paul Khuong ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: FSet bug/question

Richard M Kreuter — 2008-08-26T13:30:48

You didn't show the actual warning, only that a warning occurred. What warning did COMPILE-FILE detect? Without seeing the warning, it's not clear if you're debugging the right thing. (ISTM this is probably a question for sbcl-help, too, since it's not clear that whatever's going on here is a bug in SBCL.) -- Richard ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

FSet bug/question

Daniel Herring — 2008-08-26T06:51:28

I'm having trouble getting FSet to run on SBCL. http://common-lisp.net/project/fset/ * (require :fset) ... WARNING: COMPILE-FILE warned while performing # on #. debugger invoked on a ASDF:COMPILE-FAILED in thread #: erred while invoking # on # ... This originates in the following code snippet: <<<<< (defvar Tuple-Keys (vector K0 K1 K2 K3 K4 K5 K6 K7 K8 K9)) (defun Test-Tuple-Operations (i) (let ((tup (tuple)) (m (map)) (typ (type-of Tuple-Keys)) (nkeys (length Tuple-Keys))) ;; <- HERE (print typ) (dotimes (j 100) (let ((key (svref Tuple-Keys (random nkeys))) (val (Make-My-Integer (random 8)))) (setq tup (with tup key val)) (setq m (with m key val)) (unless (equal? m (convert 'map tup)) (error "Tuple `with' failed on iteration ~D" i)) (do-map (k v m) (unless (equal? v (lookup tup k)) (error "Tuple `lookup' failed on iteration ~D" i))))))) Where LENGTH has been shadowed as <<<<< ;;; This little oddity exists because of a limitation in Python (that's the ;;; CMUCL compiler). Given a call to `length' on type `(or null simple-vector)', ;;; Python isn't quite smart enough to optimize the call unless we do the case ;;; breakdown for it like this. #+(or cmu scl) (defmacro length (x) (ext:once-only ((x x)) `(if (null ,x) 0 (cl:length ,x)))) #+sbcl (defmacro length (x) (sb-ext::once-only ((x x)) `(if (null ,x) 0 (cl:length ,x)))) Questions: - Is this redefined LENGTH still necessary in SBCL? - Why did this pass for the author in SBCL 1.0.3 and 1.0.5, but not for me in 1.0.3, 1.0.5, 1.0.15, or 1.0.19.26 (x86-64) ? - Why does this go away (all versions?) if I insert (declare (optimize (debug 3))) as the first statement in Test-Tuple-Operations ? Any clues would be appreciated. Thanks, Daniel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Test on Win32 trying to access symbols n/a in sb-posix

Matthew D. Swank — 2008-08-25T16:39:45

Here's the relevent output: // Running C:\cygwin\usr\local\src\sbcl-dev\sbcl-build\tests \run-program.impure.lisp ; loading system definition from ; C:\cygwin\usr\local\src\sbcl-dev\sbcl-build\contrib\sb-grovel \sb-grovel.asd ; into # ; registering # as SB-GROVEL debugger invoked on a SB-C::INPUT-ERROR-IN-COMPILE-FILE: READ failure in COMPILE-FILE: SB-INT:SIMPLE-READER-PACKAGE-ERROR at 1418 (line 40, column 46) on #: Symbol "PIPE" not found in the SB-POSIX package. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [SKIP-FILE] RUN-TESTS::SKIP-FILE 1: [CONTINUE ] Ignore and continue with next --eval option. 2: [ABORT ] Skip rest of --eval options. 3: Skip to toplevel READ/EVAL/PRINT loop. 4: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). (SB-C::READ-FOR-COMPILE-FILE # 1351) 0] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: breaking the clx xid cache

Christophe Rhodes — 2008-08-24T17:44:30

I've merged a different patch, explicitly restricting the cache to only those resources which the clx client controls. I hope that it works for you. Best, Christophe ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/