From chris_melen at yahoo.com Thu Aug 7 17:36:16 2008 From: chris_melen at yahoo.com (christopher melen) Date: Thu, 7 Aug 2008 10:36:16 -0700 (PDT) Subject: [mcclim-devel] Retaining pane view on resize Message-ID: <225949.97873.qm@web54306.mail.re2.yahoo.com> Hi, Is there a way of ensuring that the bottom of a pane remains visible as the parent frame is resized? What I mean is when the frame is resized from the bottom the lower edge of the pane retains its relative position. I am thinking of something equivalent to ACL Common Graphics :bottom-attachment option. Many thanks __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html From wilde at sha-bang.de Mon Aug 11 09:19:43 2008 From: wilde at sha-bang.de (Sascha Wilde) Date: Mon, 11 Aug 2008 11:19:43 +0200 Subject: [mcclim-devel] Redisplay and pixmaps Message-ID: Hi *, I'm new to CLIM and currently looking for a good (and simple) way to redisplay a rendered picture (my toy program is an mandelbrot generator). My problem is, that the :display-function which in my case simply copies a pixmap to the application pane is less often called than actual redisplay is needed. Given the following simple example code: --8<---------------cut here---------------start------------->8--- (in-package :common-lisp-user) (defpackage "APP" (:use :clim :clim-lisp) (:export "APP-MAIN")) (in-package :app) (define-application-frame superapp () ((gfx :initform nil :accessor gfx) (redisplay-counter :initform 0 :accessor redisplaynr)) (:pointer-documentation t) (:panes (app :application :display-function #'redraw-gfx :height 400 :width 600) (int :interactor :height 400 :width 600)) (:layouts (default (vertically () app int)))) (define-superapp-command (com-draw :name t) () (setf (gfx *application-frame*) (allocate-pixmap (frame-standard-output *application-frame*) 600 400)) (draw-line* (gfx *application-frame*) 0 0 599 399 :ink +red+)) (defun redraw-gfx (frame pane) (if (gfx frame) (progn (copy-from-pixmap (gfx frame) 0 0 600 400 pane 10 10) (format pane "Redisplay #~a" (incf (redisplaynr frame)))) (format pane "No pic yet..."))) (defun app-main () (run-frame-top-level (make-application-frame 'superapp))) --8<---------------cut here---------------end--------------->8--- Run and issue the command "Draw", ok now the pixmap is displayed. But when a part of the frame is obscured by another window after getting the CLIM frame back to front the redisplay function is _not_ called. (Can be seen, both, by not refreshing the pixmap and not incrementing the redisplay-counter). BUT: The string "Redisplay #1" _is_ redrawn, so some more low level part of CLIM knows that a redraw is needed and does that for the text send to the standard output stream. So two questions: 1. What do I have to do, so that the -- Sascha Wilde : "Ist es nicht schon schlimm genug, dass ICH hier rumtrolle?" : (Henning Leise in d.o.c.) From wilde at sha-bang.de Mon Aug 11 09:24:19 2008 From: wilde at sha-bang.de (Sascha Wilde) Date: Mon, 11 Aug 2008 11:24:19 +0200 Subject: [mcclim-devel] Re: Redisplay and pixmaps In-Reply-To: (Sascha Wilde's message of "Mon, 11 Aug 2008 11:19:43 +0200") References: Message-ID: Sascha Wilde wrote: Sorry, send the last message to early per accident, here are the missing questions: > BUT: The string "Redisplay #1" _is_ redrawn, so some more low level part > of CLIM knows that a redraw is needed and does that for the text send to > the standard output stream. > > So two questions: 1. What do I have to do, so that the display-function is called _every time_ a redisplay is needed? 2. Is there a better way to ensure that the picture is redisplayed whenever needed, maybe even that magical es done with the text? I know that this happens with graphics directly drawn to the pane, but as I want to draw rendered images, which basically consist of hundreds of thousands of draw-point operations this is way to slow... cheers sascha -- Sascha Wilde : The most exciting phrase to hear in science, the one : that heralds new discoveries, is not "Eureka!" (I found : it!) but "That's funny ..." -- Isaac Asimov From kalyanov.dmitry at gmail.com Mon Aug 11 15:48:49 2008 From: kalyanov.dmitry at gmail.com (=?utf-8?b?0JrQsNC70YzRj9C90L7QsiDQlNC80LjRgtGA0LjQuQ==?=) Date: Mon, 11 Aug 2008 19:48:49 +0400 Subject: [mcclim-devel] Re: Redisplay and pixmaps In-Reply-To: References:

Message-ID: <200808111948.55347.Kalyanov.Dmitry@gmail.com> ? ????????? ?? Monday 11 August 2008 13:24:19 Sascha Wilde ???????(?): > Sascha Wilde wrote: > > Sorry, send the last message to early per accident, here are the missing > > questions: > > BUT: The string "Redisplay #1" _is_ redrawn, so some more low level part > > of CLIM knows that a redraw is needed and does that for the text send to > > the standard output stream. > > > > So two questions: > > 1. What do I have to do, so that the display-function is called _every > time_ a redisplay is needed? > > 2. Is there a better way to ensure that the picture is redisplayed > whenever needed, maybe even that magical es done with the text? > There is a :display-time initarg for panes. It controls when the :display-function is called. But, there is a handle-repaint method (which is a part of Sheet Repaint Protocol) that does the repaint. As I understand, :display-function is a more high-level (it's defined for stream panes), and it outputs not pixels on screen (which is a job for handle-repaint), but outputs objects onto pane. (I myself do not have a good knowledge of CLIM, so whatever I say might be wrong). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From wilde at sha-bang.de Tue Aug 12 11:08:21 2008 From: wilde at sha-bang.de (Sascha Wilde) Date: Tue, 12 Aug 2008 13:08:21 +0200 Subject: [mcclim-devel] Re: Redisplay and pixmaps In-Reply-To: <200808111948.55347.Kalyanov.Dmitry@gmail.com> (=?gb2312?B?Iqesp9Gn3afup/Gn36fgp9MJp6Wn3qfap+Sn4qfap9siJ3M=?= message of "Mon, 11 Aug 2008 19:48:49 +0400") References:

<200808111948.55347.Kalyanov.Dmitry@gmail.com> Message-ID: ???????? ??????? wrote: > ? ????????? ?? Monday 11 August 2008 13:24:19 Sascha Wilde ???????(?): >> Sascha Wilde wrote: >> >> Sorry, send the last message to early per accident, here are the missing >> >> questions: >> > BUT: The string "Redisplay #1" _is_ redrawn, so some more low level part >> > of CLIM knows that a redraw is needed and does that for the text send to >> > the standard output stream. >> > >> > So two questions: >> >> 1. What do I have to do, so that the display-function is called _every >> time_ a redisplay is needed? >> >> 2. Is there a better way to ensure that the picture is redisplayed >> whenever needed, maybe even that magical es done with the text? >> > > There is a :display-time initarg for panes. It controls when > the :display-function is called. I know, but I didn't find an arg to :display-time which did what I wanted (actually I had a hard time finding any useful documentation at the possible values). > But, there is a handle-repaint method (which is a part of Sheet Repaint > Protocol) that does the repaint. Indeed, (defmethod handle-repaint ((pane application-pane) region) (redraw-gfx *application-frame* pane)) does what I want. Thanks for pushing me into the right direction! cheers sascha -- Sascha Wilde "There is no reason why anyone would want a computer in their home" Ken Olson, DEC, 1977 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From kalyanov.dmitry at gmail.com Wed Aug 13 08:45:54 2008 From: kalyanov.dmitry at gmail.com (Kalyanov Dmitry) Date: Wed, 13 Aug 2008 12:45:54 +0400 Subject: [mcclim-devel] Crude multilingual input: CLX meets XKB's body parts. In-Reply-To: <874p7kacey.fsf@cantab.net> References: <20080623.013125.39169049._deepfire@feelingofgreen.ru> <874p7kacey.fsf@cantab.net> Message-ID: <200808131246.01252.Kalyanov.Dmitry@gmail.com> ? ????????? ?? Monday 23 June 2008 10:33:09 Christophe Rhodes ???????(?): > Samium Gromoff <_deepfire at feelingofgreen.ru> writes: > > Of course I'm sending the CLX part to a wrong list. > > That's OK :-) > > > What it does? > > > > 1. CLX part > > > > First, it tells CLX to ask the X server to enable XKEYBOARD. > > This part wants to be performed conditionally, depending on the > > extension's existence, obviously, which I skipped. > > > > Next, it defines keysym -> CL character mappings for the > > Cyrillic part of Unicode. > > OK, this looks cool. (The conditional bit shouldn't be hard; take a > look a the BIG-REQUESTS bit.) > > My understanding about XKEYBOARD is that a stylish CLX implementation > of it would hook into a few more things than just keycode->keysym. I > have read the XKEYBOARD spec several times, and each time I seem to > forget almost instantly the details :-/ Is there any work being done on those pathces to include them in mcclim? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From _deepfire at feelingofgreen.ru Wed Aug 13 05:59:18 2008 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Wed, 13 Aug 2008 09:59:18 +0400 (MSD) Subject: [mcclim-devel] Crude multilingual input: CLX meets XKB's body parts. In-Reply-To: <200808131246.01252.Kalyanov.Dmitry@gmail.com> References: <20080623.013125.39169049._deepfire@feelingofgreen.ru> <874p7kacey.fsf@cantab.net> <200808131246.01252.Kalyanov.Dmitry@gmail.com> Message-ID: <20080813.095918.90807193._deepfire@feelingofgreen.ru> From: Kalyanov Dmitry > ? ????????? ?? Monday 23 June 2008 10:33:09 Christophe Rhodes ???????(?): > > Samium Gromoff <_deepfire at feelingofgreen.ru> writes: > > > What it does? > > > > > > 1. CLX part > > > > > > First, it tells CLX to ask the X server to enable XKEYBOARD. > > > This part wants to be performed conditionally, depending on the > > > extension's existence, obviously, which I skipped. > > > > > > Next, it defines keysym -> CL character mappings for the > > > Cyrillic part of Unicode. > > > > OK, this looks cool. (The conditional bit shouldn't be hard; take a > > look a the BIG-REQUESTS bit.) > > > > My understanding about XKEYBOARD is that a stylish CLX implementation > > of it would hook into a few more things than just keycode->keysym. I > > have read the XKEYBOARD spec several times, and each time I seem to > > forget almost instantly the details :-/ > > Is there any work being done on those pathces to include them in mcclim? Not by me -- despite the obvious part of it being trivial, I've had, and am continuing to have, an extremely busy period in my life. It's not that this guarantees no work being done on my part, just the uncertainty of when it happens. Nice to have a reminder, though, I've had it preempted out of my head.. regards, Samium Gromoff From _deepfire at feelingofgreen.ru Thu Aug 21 15:02:38 2008 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Thu, 21 Aug 2008 19:02:38 +0400 (MSD) Subject: [mcclim-devel] Crude multilingual input: CLX meets XKB's body parts. In-Reply-To: <874p7kacey.fsf@cantab.net> References: <20080623.013125.39169049._deepfire@feelingofgreen.ru> <874p7kacey.fsf@cantab.net> Message-ID: <20080821.190238.209986406._deepfire@feelingofgreen.ru> From: Christophe Rhodes > Samium Gromoff <_deepfire at feelingofgreen.ru> writes: > > > Of course I'm sending the CLX part to a wrong list. > > That's OK :-) > > > What it does? > > > > 1. CLX part > > > > First, it tells CLX to ask the X server to enable XKEYBOARD. > > This part wants to be performed conditionally, depending on the > > extension's existence, obviously, which I skipped. > > > > Next, it defines keysym -> CL character mappings for the > > Cyrillic part of Unicode. > > OK, this looks cool. (The conditional bit shouldn't be hard; take a > look a the BIG-REQUESTS bit.) Ok, I've done the conditional bit by generalising it somewhat, and factoring in BIG-REQUESTS. The only changes are against CLX. Perhaps "auto-init-fn" is a stupid name for that keyword parameter, but I couldn't come up with anything better. regards, Samium Gromoff diff --git a/big-requests.lisp b/big-requests.lisp --- a/big-requests.lisp +++ b/big-requests.lisp @@ -19,7 +19,8 @@ ;;; ;;; The name of this extension is "BIG-REQUESTS" (Big Requests ;;; Extension, section 4) -(define-extension "BIG-REQUESTS") +(define-extension "BIG-REQUESTS" + :auto-init-fn enable-big-requests) (defun enable-big-requests (display) (declare (type display display)) diff --git a/clx.asd b/clx.asd --- a/clx.asd +++ b/clx.asd @@ -70,6 +70,7 @@ ((:file "shape") (:file "big-requests") (:file "xvidmode") + (:file "xkeyboard") (:xrender-source-file "xrender") (:file "glx") (:file "gl" :depends-on ("glx")) diff --git a/display.lisp b/display.lisp --- a/display.lisp +++ b/display.lisp @@ -392,9 +392,10 @@ gethostname(3) - is used instead." (initialize-resource-allocator disp) (initialize-predefined-atoms disp) (initialize-extensions disp) - (when (assoc "BIG-REQUESTS" (display-extension-alist disp) - :test #'string=) - (enable-big-requests disp)) + (loop :for (name event-list errors auto-init-fn) :in *extensions* :do + (when (and (assoc (symbol-name name) (display-extension-alist disp) :test #'string=) + auto-init-fn) + (funcall auto-init-fn disp))) (setq ok-p t)) (unless ok-p (close-display disp :abort t))) disp)) diff --git a/input.lisp b/input.lisp --- a/input.lisp +++ b/input.lisp @@ -83,7 +83,7 @@ (defvar *extensions* nil) ;; alist of (extension-name-symbol events errors) -(defmacro define-extension (name &key events errors) +(defmacro define-extension (name &key events errors auto-init-fn) ;; Define extension NAME with EVENTS and ERRORS. ;; Note: The case of NAME is important. ;; To define the request, Use: @@ -96,7 +96,7 @@ (let ((name-symbol (kintern name)) ;; Intern name in the keyword package (event-list (mapcar #'canonicalize-event-name events))) `(eval-when (:compile-toplevel :load-toplevel :execute) - (setq *extensions* (cons (list ',name-symbol ',event-list ',errors) + (setq *extensions* (cons (list ',name-symbol ',event-list ',errors ',auto-init-fn) (delete ',name-symbol *extensions* :key #'car)))))) (eval-when (:compile-toplevel :load-toplevel :execute) diff --git a/keysyms.lisp b/keysyms.lisp --- a/keysyms.lisp +++ b/keysyms.lisp @@ -157,6 +157,100 @@ (define-keysym #\} 125) (define-keysym #\~ 126) +;; (define-keysym #\SERBIAN_dje (keysym 6 #xa1)) +;; (define-keysym #\MACEDONIA_gje (keysym 6 #xa2)) +(define-keysym #\CYRILLIC_small_letter_io (keysym 6 #xa3)) +;; (define-keysym #\UKRAINIAN_ie (keysym 6 #xa4)) +;; (define-keysym #\MACEDONIA_dse (keysym 6 #xa5)) +;; (define-keysym #\UKRAINIAN_i (keysym 6 #xa6)) +;; (define-keysym #\UKRAINIAN_yi (keysym 6 #xa7)) +(define-keysym #\CYRILLIC_small_letter_je (keysym 6 #xa8)) +(define-keysym #\CYRILLIC_small_letter_lje (keysym 6 #xa9)) +(define-keysym #\CYRILLIC_small_letter_nje (keysym 6 #xaa)) +;; (define-keysym #\SERBIAN_tshe (keysym 6 #xab)) +;; (define-keysym #\MACEDONIA_kje (keysym 6 #xac)) +;; (define-keysym #\BYELORUSSIAN_shortu (keysym 6 #xae)) +(define-keysym #\CYRILLIC_small_letter_dzhe (keysym 6 #xaf)) +;; (define-keysym #\NUMEROSIGN (keysym 6 #xb0)) +;; (define-keysym #\SERBIAN_DJE (keysym 6 #xb1)) +;; (define-keysym #\MACEDONIA_GJE (keysym 6 #xb2)) +(define-keysym #\CYRILLIC_CAPITAL_LETTER_IO (keysym 6 #xb3)) +;; (define-keysym #\UKRAINIAN_IE (keysym 6 #xb4)) +;; (define-keysym #\MACEDONIA_DSE (keysym 6 #xb5)) +;; (define-keysym #\UKRAINIAN_I (keysym 6 #xb6)) +;; (define-keysym #\UKRAINIAN_YI (keysym 6 #xb7)) +(define-keysym #\CYRILLIC_CAPITAL_LETTER_JE (keysym 6 #xb8)) +(define-keysym #\CYRILLIC_CAPITAL_LETTER_LJE (keysym 6 #xb9)) +(define-keysym #\CYRILLIC_CAPITAL_LETTER_NJE (keysym 6 #xba)) +;; (define-keysym #\SERBIAN_TSHE (keysym 6 #xbb)) +;; (define-keysym #\MACEDONIA_KJE (keysym 6 #xbc)) +;; (define-keysym #\BYELORUSSIAN_SHORTU (keysym 6 #xbe)) +(define-keysym #\CYRILLIC_CAPITAL_LETTER_DZHE (keysym 6 #xbf)) +(define-keysym #\CYRILLIC_small_letter_yu (keysym 6 #xc0)) +(define-keysym #\CYRILLIC_small_letter_a (keysym 6 #xc1)) +(define-keysym #\CYRILLIC_small_letter_be (keysym 6 #xc2)) +(define-keysym #\CYRILLIC_small_letter_tse (keysym 6 #xc3)) +(define-keysym #\CYRILLIC_small_letter_de (keysym 6 #xc4)) +(define-keysym #\CYRILLIC_small_letter_ie (keysym 6 #xc5)) +(define-keysym #\CYRILLIC_small_letter_ef (keysym 6 #xc6)) +(define-keysym #\CYRILLIC_small_letter_ghe (keysym 6 #xc7)) +(define-keysym #\CYRILLIC_small_letter_ha (keysym 6 #xc8)) +(define-keysym #\CYRILLIC_small_letter_i (keysym 6 #xc9)) +(define-keysym #\CYRILLIC_small_letter_short_i (keysym 6 #xca)) +(define-keysym #\CYRILLIC_small_letter_ka (keysym 6 #xcb)) +(define-keysym #\CYRILLIC_small_letter_el (keysym 6 #xcc)) +(define-keysym #\CYRILLIC_small_letter_em (keysym 6 #xcd)) +(define-keysym #\CYRILLIC_small_letter_en (keysym 6 #xce)) +(define-keysym #\CYRILLIC_small_letter_o (keysym 6 #xcf)) +(define-keysym #\CYRILLIC_small_letter_pe (keysym 6 #xd0)) +(define-keysym #\CYRILLIC_small_letter_ya (keysym 6 #xd1)) +(define-keysym #\CYRILLIC_small_letter_er (keysym 6 #xd2)) +(define-keysym #\CYRILLIC_small_letter_es (keysym 6 #xd3)) +(define-keysym #\CYRILLIC_small_letter_te (keysym 6 #xd4)) +(define-keysym #\CYRILLIC_small_letter_u (keysym 6 #xd5)) +(define-keysym #\CYRILLIC_small_letter_zhe (keysym 6 #xd6)) +(define-keysym #\CYRILLIC_small_letter_ve (keysym 6 #xd7)) +(define-keysym #\CYRILLIC_small_letter_soft_sign (keysym 6 #xd8)) +(define-keysym #\CYRILLIC_small_letter_yeru (keysym 6 #xd9)) +(define-keysym #\CYRILLIC_small_letter_ze (keysym 6 #xda)) +(define-keysym #\CYRILLIC_small_letter_sha (keysym 6 #xdb)) +(define-keysym #\CYRILLIC_small_letter_e (keysym 6 #xdc)) +(define-keysym #\CYRILLIC_small_letter_shcha (keysym 6 #xdd)) +(define-keysym #\CYRILLIC_small_letter_che (keysym 6 #xde)) +(define-keysym #\CYRILLIC_small_letter_hard_sign (keysym 6 #xdf)) +(define-keysym #\CYRILLIC_capital_letter_YU (keysym 6 #xe0)) +(define-keysym #\CYRILLIC_capital_letter_A (keysym 6 #xe1)) +(define-keysym #\CYRILLIC_capital_letter_BE (keysym 6 #xe2)) +(define-keysym #\CYRILLIC_capital_letter_TSE (keysym 6 #xe3)) +(define-keysym #\CYRILLIC_capital_letter_DE (keysym 6 #xe4)) +(define-keysym #\CYRILLIC_capital_letter_IE (keysym 6 #xe5)) +(define-keysym #\CYRILLIC_capital_letter_EF (keysym 6 #xe6)) +(define-keysym #\CYRILLIC_capital_letter_GHE (keysym 6 #xe7)) +(define-keysym #\CYRILLIC_capital_letter_HA (keysym 6 #xe8)) +(define-keysym #\CYRILLIC_capital_letter_I (keysym 6 #xe9)) +(define-keysym #\CYRILLIC_capital_letter_SHORT_I (keysym 6 #xea)) +(define-keysym #\CYRILLIC_capital_letter_KA (keysym 6 #xeb)) +(define-keysym #\CYRILLIC_capital_letter_EL (keysym 6 #xec)) +(define-keysym #\CYRILLIC_capital_letter_EM (keysym 6 #xed)) +(define-keysym #\CYRILLIC_capital_letter_EN (keysym 6 #xee)) +(define-keysym #\CYRILLIC_capital_letter_O (keysym 6 #xef)) +(define-keysym #\CYRILLIC_capital_letter_PE (keysym 6 #xf0)) +(define-keysym #\CYRILLIC_capital_letter_YA (keysym 6 #xf1)) +(define-keysym #\CYRILLIC_capital_letter_ER (keysym 6 #xf2)) +(define-keysym #\CYRILLIC_capital_letter_ES (keysym 6 #xf3)) +(define-keysym #\CYRILLIC_capital_letter_TE (keysym 6 #xf4)) +(define-keysym #\CYRILLIC_capital_letter_U (keysym 6 #xf5)) +(define-keysym #\CYRILLIC_capital_letter_ZHE (keysym 6 #xf6)) +(define-keysym #\CYRILLIC_capital_letter_VE (keysym 6 #xf7)) +(define-keysym #\CYRILLIC_capital_letter_SOFT_SIGN (keysym 6 #xf8)) +(define-keysym #\CYRILLIC_capital_letter_YERU (keysym 6 #xf9)) +(define-keysym #\CYRILLIC_capital_letter_ZE (keysym 6 #xfa)) +(define-keysym #\CYRILLIC_capital_letter_SHA (keysym 6 #xfb)) +(define-keysym #\CYRILLIC_capital_letter_E (keysym 6 #xfc)) +(define-keysym #\CYRILLIC_capital_letter_SHCHA (keysym 6 #xfd)) +(define-keysym #\CYRILLIC_capital_letter_CHE (keysym 6 #xfe)) +(define-keysym #\CYRILLIC_capital_letter_HARD_SIGN (keysym 6 #xff)) + (progn ;; Semi-standard characters (define-keysym #\rubout (keysym 255 255)) ; :tty (define-keysym #\tab (keysym 255 009)) ; :tty diff --git a/translate.lisp b/translate.lisp --- a/translate.lisp +++ b/translate.lisp @@ -290,11 +290,11 @@ ;; entry for keysym-index zero set to the uppercase keysym ;; (this is normally where the lowercase keysym goes), and the ;; entry for keysym-index one is zero. - (cond ((zerop keysym-index) ; Lowercase alphabetic keysyms - (keysym-downcase keysym)) - ((and (zerop keysym) (plusp keysym-index)) ; Get the uppercase keysym - (aref mapping keycode 0)) - (t keysym)))) + (cond ((zerop keysym-index) ; Lowercase alphabetic keysyms + (keysym-downcase keysym)) + ((and (zerop keysym) (plusp keysym-index)) ; Get the uppercase keysym + (aref mapping keycode 0)) + (t keysym)))) (defun keysym->character (display keysym &optional (state 0)) ;; Find the character associated with a keysym. diff --git a/xkeyboard.lisp b/xkeyboard.lisp --- /dev/null +++ b/xkeyboard.lisp @@ -0,0 +1,20 @@ +(in-package :xlib) + +(define-extension "XKEYBOARD" + :events () + :errors (xf86-xkeyboard-keyboard) + :auto-init-fn xkb-enable) + +(define-condition xf86-xkeyboard-keyboard (request-error) ()) + +(define-error xf86-xkeyboard-keyboard decode-core-error) + +(defconstant +xkb-enable+ 0) + +(defun xkb-enable (display) + (declare (type display display)) + (with-buffer-request-and-reply (display (extension-opcode display "XKEYBOARD") nil :sizes (8 16)) + ((data +xkb-enable+) + (card16 1) + (card16 0)) + (values (boolean-get 8)))) From ahefner at gmail.com Fri Aug 22 03:06:37 2008 From: ahefner at gmail.com (Andy Hefner) Date: Thu, 21 Aug 2008 23:06:37 -0400 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> Message-ID: <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> I just encountered the "Asynchronous ID-CHOICE-ERROR" myself tonight, in my case when multiple mcclim applications (in multiple threads) on one screen race to repaint. I don't know if it's related to Nikodemus' test case, which doesn't make any use of threads (excluding the omnipresent CLX event dispatching thread), but at least it's the same error. Attached is a patch to CLX intending to address a race condition when multiple threads attempt to allocate a resource ID - DISPLAY-RESOURCE-ID-COUNT is incremented, but there is no locking to protect the slot, resulting in intermittent duplicate IDs and subsequent ID-CHOICE-ERROR. I've wrapped the allocation in a with-display, and done the same to the nearby deallocate-resource-id-internal for good measure. This should protect the incf in resourcealloc, the (setf gethash) in save-id, and the remhash in deallocate-resource-id-internal. --- old-clx/display.lisp 2008-08-21 23:27:35.000000000 -0400 +++ new-clx/display.lisp 2008-08-21 23:27:35.000000000 -0400 @@ -155,11 +155,12 @@ (defmacro allocate-resource-id (display object type) ;; Allocate a resource-id for OBJECT in DISPLAY - (if (member (eval type) +clx-cached-types+) - `(let ((id (funcall (display-xid ,display) ,display))) - (save-id ,display id ,object) - id) - `(funcall (display-xid ,display) ,display))) + `(with-display (,display) + ,(if (member (eval type) +clx-cached-types+) + `(let ((id (funcall (display-xid ,display) ,display))) + (save-id ,display id ,object) + id) + `(funcall (display-xid ,display) ,display)))) (defmacro deallocate-resource-id (display id type) ;; Deallocate a resource-id for OBJECT in DISPLAY @@ -167,7 +168,8 @@ `(deallocate-resource-id-internal ,display ,id))) (defun deallocate-resource-id-internal (display id) - (remhash id (display-resource-id-map display))) + (with-display (display) + (remhash id (display-resource-id-map display)))) (defun lookup-resource-id (display id) ;; Find the object associated with resource ID -------------- next part -------------- A non-text attachment was scrubbed... Name: id-alloc.patch Type: text/x-patch Size: 1177 bytes Desc: not available URL: From csr21 at cantab.net Fri Aug 22 06:02:29 2008 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 22 Aug 2008 07:02:29 +0100 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> (Andy Hefner's message of "Thu, 21 Aug 2008 23:06:37 -0400") References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> Message-ID: <87zln5bn9m.fsf@cantab.net> "Andy Hefner" writes: > Attached is a patch to CLX intending to address a race condition when > multiple threads attempt to allocate a resource ID - > DISPLAY-RESOURCE-ID-COUNT is incremented, but there is no locking to > protect the slot, resulting in intermittent duplicate IDs and > subsequent ID-CHOICE-ERROR. I've wrapped the allocation in a > with-display, and done the same to the nearby > deallocate-resource-id-internal for good measure. This should protect > the incf in resourcealloc, the (setf gethash) in save-id, and the > remhash in deallocate-resource-id-internal. Thanks, pushed. Best, Christophe From nikodemus at random-state.net Fri Aug 22 09:15:58 2008 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Fri, 22 Aug 2008 12:15:58 +0300 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> Message-ID: <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> On Fri, Aug 22, 2008 at 6:06 AM, Andy Hefner wrote: > I just encountered the "Asynchronous ID-CHOICE-ERROR" myself tonight, > in my case when multiple mcclim applications (in multiple threads) on > one screen race to repaint. I don't know if it's related to Nikodemus' > test case, which doesn't make any use of threads (excluding the > omnipresent CLX event dispatching thread), but at least it's the same > error. I don't remember offhand for sure, but I think that was actually on a single-threaded SBCL -- so there would perforce be only one thread in Lisp Land. Since it seems to be in danger of falling through the cracks, here is a (possibly related) report from sbcl-devel. Cheers, -- Nikodemus ---------- Forwarded message ---------- From: Shawn Date: Sat, Jul 12, 2008 at 5:27 AM Subject: Re: [Sbcl-devel] breaking the clx xid cache To: sbcl-devel at lists.sf.net Hi folks, It looks like the portable-clx mailing list is down so I'm sending this here. In stumpwm I've been getting more and more error reports where the :window slot for events is a pixmap instead of a window. I've tracked it to a problem with the xid cache in clx. X appears to be recycling XIDs which confuses clx. Here's a function that exposes the bug: (defun break-display-xid-cache () (labels ((make-win (dpy) (xlib:create-window :parent (xlib:screen-root (first (xlib:display-roots dpy))) :x 0 :y 0 :width 50 :height 50)) (make-pixmap (window) (xlib:create-pixmap :width (random 100) :height (random 100) :depth 8 :drawable window)) (first-pass (dpy) ;; Open a fresh connection. Create a window and a pixmap. (let* ((dpy2 (xlib:open-default-display)) (window (make-win dpy2)) (pixmap (make-pixmap window))) ;; make the pixmap the window's icon pixmap hint. (setf (xlib:wm-hints window) (xlib:make-wm-hints :icon-pixmap pixmap)) (format t "Window ID: ~s pixmap ID: ~s~%" (xlib:window-id window) (xlib:pixmap-id pixmap)) (xlib:display-finish-output dpy2) ;; On the old connection, list the root window children ;; and the icon pixmap hint to cache their XIDs. (loop for w in (xlib:query-tree (xlib:screen-root (first (xlib:display-roots dpy)))) for hints = (xlib:wm-hints w) when hints do (format t "top level window id: ~s | icon pixmap hint: ~s~%" (xlib:window-id w) (xlib:wm-hints-icon-pixmap hints))) (xlib:close-display dpy2))) (second-pass (dpy) ;; Open a fresh connection and create 2 windows. (let* ((dpy2 (xlib:open-default-display)) (window1 (make-win dpy2)) (window2 (make-win dpy2))) (format t "Window#1 ID: ~s Window#2 ID: ~s~%" (xlib:window-id window1) (xlib:window-id window2)) (xlib:display-finish-output dpy2) ;; On the old connection, list the root window children ;; and note the second window is erroneously a pixmap ;; due to too agressive caching in clx. (loop for w in (xlib:query-tree (xlib:screen-root (first (xlib:display-roots dpy)))) do (format t "window: ~s~%" w)) (xlib:close-display dpy2)))) (let ((dpy (xlib:open-default-display))) (first-pass dpy) (second-pass dpy) (xlib:close-display dpy)))) Note that the last window in the window list printed at the end is a pixmap and not a window! Here's the relevant output when i run it: * (break-display-xid-cache) Window ID: 14680065 pixmap ID: 14680066 top level window id: 14680065 | icon pixmap hint: # Window#1 ID: 14680065 Window#2 ID: 14680066 window: # window: # NIL * I propose the following patch. Since a cache error isn't the sign of a bug, I don't think checking the type should depend +type-check?+ constant. In the event of a lookup error, I've added two restarts for invalidating the cache and creating fresh XID cache entries. This is how it has been addressed in new-clx. --- display.lisp 2005-08-26 03:13:28.000000000 -0700 +++ display.lisp 2008-07-11 17:22:39.000000000 -0700 @@ -199,17 +199,21 @@ :display display :id id)) (save-id display id ,type)) ;; Found. Check the type - ,(cond ((null +type-check?+) - `(t ,type)) - ((member type '(window pixmap)) - `((type? ,type 'drawable) ,type)) - (t `((type? ,type ',type) ,type))) - ,@(when +type-check?+ - `((t (x-error 'lookup-error - :id id - :display display - :type ',type - :object ,type)))))) + ((type? ,type ',type) ,type) + (t + (restart-case + (x-error 'lookup-error + :id id + :display display + :type ',type + :object ,type) + (one () + :report "Invalidate this cache entry" + (save-id display id (,(xintern 'make- type) :display display :id id))) + (all () + :report "Invalidate all display cache" + (clrhash (display-resource-id-map display)) + (save-id display id (,(xintern 'make- type) :display display :id id))))))) ;; Not being cached. Create a new one each time. `(,(xintern 'make- type) :display display :id id)))) -Shawn From csr21 at cantab.net Fri Aug 22 10:16:01 2008 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 22 Aug 2008 11:16:01 +0100 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> (Nikodemus Siivola's message of "Fri, 22 Aug 2008 12:15:58 +0300") References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> Message-ID: <874p5dcq3i.fsf@cantab.net> "Nikodemus Siivola" writes: > On Fri, Aug 22, 2008 at 6:06 AM, Andy Hefner wrote: >> I just encountered the "Asynchronous ID-CHOICE-ERROR" myself tonight, >> in my case when multiple mcclim applications (in multiple threads) on >> one screen race to repaint. I don't know if it's related to Nikodemus' >> test case, which doesn't make any use of threads (excluding the >> omnipresent CLX event dispatching thread), but at least it's the same >> error. > > I don't remember offhand for sure, but I think that was actually on a > single-threaded SBCL -- so there would perforce be only one thread in > Lisp Land. > > Since it seems to be in danger of falling through the cracks, here is > a (possibly related) report from sbcl-devel. I don't think this is related, but I have been investigating that one this morning anyway, while waiting for your test case to break. (It's been about an hour so far; is that normal? I can suggest diagnostics to run on your system if not.) Because your resource ID was suspicious (had a large number of 0s in it: #x600002 or so) I would tend to suspect either a bug in the resource ID logic in clx, or a bug in the X server (this is Apple, after all...) I think that the fix to Shawn's problem is to teach clx to cache only its own client resource IDs, and not anyone else's. Before installing that fix, I want to read xlib or xcb sources, and possibly a window manager's, to check that that's sane. (If someone else wants to read xlib/xcb sources instead, please be my guest!) Best, Christophe From nikodemus at random-state.net Fri Aug 22 12:09:55 2008 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Fri, 22 Aug 2008 15:09:55 +0300 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <874p5dcq3i.fsf@cantab.net> References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> <874p5dcq3i.fsf@cantab.net> Message-ID: <633d72b0808220509n4fd0e43fjeac8b5f8a7048bc8@mail.gmail.com> On Fri, Aug 22, 2008 at 1:16 PM, Christophe Rhodes wrote: > "Nikodemus Siivola" writes: > I don't think this is related, but I have been investigating that one > this morning anyway, while waiting for your test case to break. (It's > been about an hour so far; is that normal? I can suggest diagnostics > to run on your system if not.) IIRC it used to break in less then five minutes. I'll try to reproduce again before updating CLX. Cheers, -- Nikodemus From csr21 at cantab.net Fri Aug 22 12:20:25 2008 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 22 Aug 2008 13:20:25 +0100 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <633d72b0808220509n4fd0e43fjeac8b5f8a7048bc8@mail.gmail.com> (Nikodemus Siivola's message of "Fri, 22 Aug 2008 15:09:55 +0300") References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> <874p5dcq3i.fsf@cantab.net> <633d72b0808220509n4fd0e43fjeac8b5f8a7048bc8@mail.gmail.com> Message-ID: <87vdxtb5rq.fsf@cantab.net> "Nikodemus Siivola" writes: > On Fri, Aug 22, 2008 at 1:16 PM, Christophe Rhodes wrote: >> "Nikodemus Siivola" writes: > >> I don't think this is related, but I have been investigating that one >> this morning anyway, while waiting for your test case to break. (It's >> been about an hour so far; is that normal? I can suggest diagnostics >> to run on your system if not.) > > IIRC it used to break in less then five minutes. I'll try to reproduce > again before updating CLX. It's still going here, about 4 hours later. Can you run (let ((display (xlib:open-default-display))) (values (xlib::display-resource-id-mask display) (xlib::display-resource-id-base display))) against your X server? Thanks, Christophe From nikodemus at random-state.net Fri Aug 22 12:50:44 2008 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Fri, 22 Aug 2008 15:50:44 +0300 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <87vdxtb5rq.fsf@cantab.net> References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> <874p5dcq3i.fsf@cantab.net> <633d72b0808220509n4fd0e43fjeac8b5f8a7048bc8@mail.gmail.com> <87vdxtb5rq.fsf@cantab.net> Message-ID: <633d72b0808220550y3b888b80pe86236be051bacab@mail.gmail.com> On Fri, Aug 22, 2008 at 3:20 PM, Christophe Rhodes wrote: > "Nikodemus Siivola" writes: > >> On Fri, Aug 22, 2008 at 1:16 PM, Christophe Rhodes wrote: >>> "Nikodemus Siivola" writes: >> >>> I don't think this is related, but I have been investigating that one >>> this morning anyway, while waiting for your test case to break. (It's >>> been about an hour so far; is that normal? I can suggest diagnostics >>> to run on your system if not.) >> >> IIRC it used to break in less then five minutes. I'll try to reproduce >> again before updating CLX. > > It's still going here, about 4 hours later. Was able to reproduce here, though it took something like 30 minutes. > Can you run > > (let ((display (xlib:open-default-display))) > (values (xlib::display-resource-id-mask display) > (xlib::display-resource-id-base display))) In the image where I had just duplicated the error, while in the debugger: 2097151 10485760 In a clean image with just CLX loaded: 2097151 8388608 Cheers, -- Nikodemus From csr21 at cantab.net Fri Aug 22 15:30:52 2008 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 22 Aug 2008 16:30:52 +0100 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <633d72b0808220550y3b888b80pe86236be051bacab@mail.gmail.com> (Nikodemus Siivola's message of "Fri, 22 Aug 2008 15:50:44 +0300") References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> <874p5dcq3i.fsf@cantab.net> <633d72b0808220509n4fd0e43fjeac8b5f8a7048bc8@mail.gmail.com> <87vdxtb5rq.fsf@cantab.net> <633d72b0808220550y3b888b80pe86236be051bacab@mail.gmail.com> Message-ID: <87sksxhxsj.fsf@cantab.net> "Nikodemus Siivola" writes: > Was able to reproduce here, though it took something like 30 minutes. > >> Can you run >> >> (let ((display (xlib:open-default-display))) >> (values (xlib::display-resource-id-mask display) >> (xlib::display-resource-id-base display))) > > In the image where I had just duplicated the error, while in the debugger: > > 2097151 > 10485760 Please tell me you saved the exact error message and can now add that piece of information... in particular, I'm interested in the hex number that is reported as part of the id-choice error. C. From nikodemus at random-state.net Fri Aug 22 16:32:56 2008 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Fri, 22 Aug 2008 19:32:56 +0300 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <87sksxhxsj.fsf@cantab.net> References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> <874p5dcq3i.fsf@cantab.net> <633d72b0808220509n4fd0e43fjeac8b5f8a7048bc8@mail.gmail.com> <87vdxtb5rq.fsf@cantab.net> <633d72b0808220550y3b888b80pe86236be051bacab@mail.gmail.com> <87sksxhxsj.fsf@cantab.net> Message-ID: <633d72b0808220932w30ce56c7s9f5d39b59640fd7b@mail.gmail.com> On Fri, Aug 22, 2008 at 6:30 PM, Christophe Rhodes wrote: > "Nikodemus Siivola" writes: > >> Was able to reproduce here, though it took something like 30 minutes. >> >>> Can you run >>> >>> (let ((display (xlib:open-default-display))) >>> (values (xlib::display-resource-id-mask display) >>> (xlib::display-resource-id-base display))) >> >> In the image where I had just duplicated the error, while in the debugger: >> >> 2097151 >> 10485760 > > Please tell me you saved the exact error message and can now add that > piece of information... in particular, I'm interested in the hex > number that is reported as part of the id-choice error. I did not, but here are the results from a new run: Received CLX ID-CHOICE-ERROR in process NIL debugger invoked on a XLIB:ID-CHOICE-ERROR: Asynchronous ID-CHOICE-ERROR in request 10247 (last request was 10248) Code 55.0 [CreateGC] ID #x800002 Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE ] Ignore 1: [TRY-AGAIN] Try executing the command COM-STRESS again 2: [ABORT ] Return to application command loop 3: Exit debugger, returning to top level. (XLIB::X-CERROR "Ignore" XLIB:ID-CHOICE-ERROR)[:EXTERNAL] 0] (let ((display (xlib:open-default-display))) (values (xlib:display-resource-id-mask display) (xlib:display-resource-id-base display))) 2097151 10485760 0] I'm keeping the session alive, so let me know if you need anything else. Cheers, -- Nikodemus From ahefner at gmail.com Fri Aug 22 17:40:55 2008 From: ahefner at gmail.com (Andy Hefner) Date: Fri, 22 Aug 2008 13:40:55 -0400 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <633d72b0808220932w30ce56c7s9f5d39b59640fd7b@mail.gmail.com> References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> <874p5dcq3i.fsf@cantab.net> <633d72b0808220509n4fd0e43fjeac8b5f8a7048bc8@mail.gmail.com> <87vdxtb5rq.fsf@cantab.net> <633d72b0808220550y3b888b80pe86236be051bacab@mail.gmail.com> <87sksxhxsj.fsf@cantab.net> <633d72b0808220932w30ce56c7s9f5d39b59640fd7b@mail.gmail.com> Message-ID: <31ffd3c40808221040o474800caj5a4b70977090d6ba@mail.gmail.com> I think there are two bugs at play here - first, that CLX makes no attempt to avoid reusing IDs that are still in use once the count wraps around, and second that in this instance mcclim creates millions of gcontexts without freeing them. I've hacked resourcealloc in CLX to check against the id cache, skipping IDs which are still in use, but this runs into the problem that not all types (in particular, graphics contexts) are stored in the cache. There's some comment about this not being useful and wasting space in depdefs.lisp next to defconstant +clx-cached-types+, and without considering the performance implications I've worked around it by setting the hash table entry to T at the point the ID is allocated, so that (I hope) every allocated resource is now there. To do this correctly also requirse that the deallocate-resource-id be changed to unconditionally invoke deallocate-resource-id-internal (thereby making the macro useless), which I've neglected to do. With that in mind, here's a version of resourcealloc with the changes described: (defun resourcealloc (display) ;; Allocate a resource-id for in DISPLAY (declare (type display display)) (declare (clx-values resource-id)) (loop for next-count upfrom (1+ (display-resource-id-count display)) repeat (1+ (display-resource-id-mask display)) as id = (dpb next-count (display-resource-id-byte display) (display-resource-id-base display)) do (when (nth-value 1 (gethash id (display-resource-id-map display))) #+NIL (format *trace-output* "~&Skipping ~X (~A)~%" id (gethash id (display-resource-id-map display)))) (when (zerop (random 10000)) (format *trace-output* "~&~X~%" id)) (unless (nth-value 1 (gethash id (display-resource-id-map display))) (setf (display-resource-id-count display) next-count) #+NIL (format *trace-output* "~&Allocating ~X (~A IDs in use)~%" id (hash-table-count (display-resource-id-map display))) (setf (gethash id (display-resource-id-map display)) t) (when (= id #x2A00027) (break "Hi there.")) (return-from resourcealloc id))) (assert (= (hash-table-count (display-resource-id-map display)) (1+ (display-resource-id-mask display)))) (error "Available X resource IDs have been exhausted.")) Fixing this allocation issue doesn't solve the underlying problem that this test causes mcclim to exhaust the available space of resource-ids by never freeing these gcontexts. From csr21 at cantab.net Sat Aug 23 13:31:54 2008 From: csr21 at cantab.net (Christophe Rhodes) Date: Sat, 23 Aug 2008 14:31:54 +0100 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <31ffd3c40808221040o474800caj5a4b70977090d6ba@mail.gmail.com> (Andy Hefner's message of "Fri, 22 Aug 2008 13:40:55 -0400") References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <31ffd3c40808212006r1e9aef33v5bc2814438a0de83@mail.gmail.com> <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> <874p5dcq3i.fsf@cantab.net> <633d72b0808220509n4fd0e43fjeac8b5f8a7048bc8@mail.gmail.com> <87vdxtb5rq.fsf@cantab.net> <633d72b0808220550y3b888b80pe86236be051bacab@mail.gmail.com> <87sksxhxsj.fsf@cantab.net> <633d72b0808220932w30ce56c7s9f5d39b59640fd7b@mail.gmail.com> <31ffd3c40808221040o474800caj5a4b70977090d6ba@mail.gmail.com> Message-ID: <87d4jzkgc5.fsf@cantab.net> "Andy Hefner" writes: > Fixing this allocation issue doesn't solve the underlying problem that > this test causes mcclim to exhaust the available space of resource-ids > by never freeing these gcontexts. I attach a patch for consideration against mcclim (yeah, I know, I have commit access, but I'm rusty) which seems to fix the leaky gcontext problem in the CLX backend. There may well be an analogous problem in other backends (except the Null backend :-); I haven't investigated. -------------- next part -------------- A non-text attachment was scrubbed... Name: pixmap-gcontext.diff Type: text/x-diff Size: 4534 bytes Desc: mcclim putative fix URL: -------------- next part -------------- I've also got something like Andy's resourcealloc patch in my clx (not pushed yet), along with a fix for Shawn's resource ID issue. Wow, it's almost like being up to date... Best, Christophe From ahefner at gmail.com Sat Aug 23 16:05:45 2008 From: ahefner at gmail.com (Andy Hefner) Date: Sat, 23 Aug 2008 12:05:45 -0400 Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM? In-Reply-To: <87d4jzkgc5.fsf@cantab.net> References: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com> <633d72b0808220215h5428295fk62a6c1a806ed1e3@mail.gmail.com> <874p5dcq3i.fsf@cantab.net> <633d72b0808220509n4fd0e43fjeac8b5f8a7048bc8@mail.gmail.com> <87vdxtb5rq.fsf@cantab.net> <633d72b0808220550y3b888b80pe86236be051bacab@mail.gmail.com> <87sksxhxsj.fsf@cantab.net> <633d72b0808220932w30ce56c7s9f5d39b59640fd7b@mail.gmail.com> <31ffd3c40808221040o474800caj5a4b70977090d6ba@mail.gmail.com> <87d4jzkgc5.fsf@cantab.net> Message-ID: <31ffd3c40808230905w9b83621r9ce2753daa83e298@mail.gmail.com> (defmethod port-deallocate-pixmap ((port clx-port) pixmap) + (let ((medium (climi::pixmap-medium pixmap))) + (when medium + (with-slots (gc) medium + (when gc + (xlib:free-gcontext gc))))) (when (port-lookup-mirror port pixmap) (destroy-mirror port pixmap))) Would it be more appropriate to move the subform starting with (with-slots (gc) ..) to deallocate-medium (or possibly degraft-medium), and one of those instead? Not a big deal, given virtually nothing else in mcclim calls these when it probably should.