- mcclim-devel - mailman3.common-lisp.net

[mcclim-devel] patch: use synchronized hash-tables on SBCL
by Nikodemus Siivola 10 Nov '11

10 Nov '11

SBCL hash tables are not thread safe by default, and reportedly McCLIM does parallel accesses to its tables. I haven't actually verified that this patch covers all the cases in McCLIM, but it should pave the way for someone to do that. Cheers, -- Nikodemus

1 0

[mcclim-devel] declare dynamic extent macro call errors in source
by billpeople＠mindspring.com 31 Aug '11

31 Aug '11

Here's a "patch", but fixing the sources is better, Richard Billington ---------------------------8< snip >8--------------------------- (in-package :clim-internals) ;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; patch for recording.lisp - need to redefine define-invoke-with, and then recompile two calls to it. ;;;;;;;;;;;;;;;;;;;;;;;;;;; (defmacro define-invoke-with (macro-name func-name record-type doc-string) `(defmacro ,macro-name ((stream &optional (record-type '',record-type) (record (gensym)) &rest initargs) &body body) ,doc-string (setq stream (stream-designator-symbol stream '*standard-output*)) (with-gensyms (constructor continuation) (multiple-value-bind (bindings m-i-args) (rebind-arguments initargs) `(let ,bindings (flet ((,constructor () (make-instance ,record-type ,@m-i-args)) (,continuation (,stream ,record) ,(declare-ignorable-form* stream record) ,@body)) #+BUGGY (declare (dynamic-extent #'constructor #'continuation)) #-BUGGY (declare (dynamic-extent #',constructor #',continuation)) (,',func-name ,stream #',continuation ,record-type #',constructor ,@m-i-args))))))) (define-invoke-with with-new-output-record invoke-with-new-output-record standard-sequence-output-record "Creates a new output record of type RECORD-TYPE and then captures the output of BODY into the new output record, and inserts the new record into the current \"open\" output record assotiated with STREAM. If RECORD is supplied, it is the name of a variable that will be lexically bound to the new output record inside the body. INITARGS are CLOS initargs that are passed to MAKE-INSTANCE when the new output record is created. It returns the created output record. The STREAM argument is a symbol that is bound to an output recording stream. If it is T, *STANDARD-OUTPUT* is used.") (define-invoke-with with-output-to-output-record invoke-with-output-to-output-record standard-sequence-output-record "Creates a new output record of type RECORD-TYPE and then captures the output of BODY into the new output record. The cursor position of STREAM is initially bound to (0,0) If RECORD is supplied, it is the name of a variable that will be lexically bound to the new output record inside the body. INITARGS are CLOS initargs that are passed to MAKE-INSTANCE when the new output record is created. It returns the created output record. The STREAM argument is a symbol that is bound to an output recording stream. If it is T, *STANDARD-OUTPUT* is used.") ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; patch for presentations.lisp ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defmacro with-output-as-presentation ((stream object type &rest key-args &key modifier single-box (allow-sensitive-inferiors t) parent (record-type ''standard-presentation) &allow-other-keys) &body body) (declare (ignore parent single-box modifier)) (setq stream (stream-designator-symbol stream '*standard-output*)) (multiple-value-bind (decls with-body) (get-body-declarations body) (with-gensyms (record-arg continuation) (with-keywords-removed (key-args (:record-type :allow-sensitive-inferiors)) `(flet ((,continuation () ,@decls ,@with-body)) #+BUGGY (declare (dynamic-extent #'continuation)) #-BUGGY (declare (dynamic-extent #',continuation)) (if (and (output-recording-stream-p ,stream) *allow-sensitive-inferiors*) (with-new-output-record (,stream ,record-type ,record-arg :object ,object :type (expand-presentation-type-abbreviation ,type) ,@key-args) (let ((*allow-sensitive-inferiors* ,allow-sensitive-inferiors)) (,continuation))) (,continuation)))))))

1 0

[mcclim-devel] mcclim-{true|free}type autoconfigure
by David Lewis 31 Aug '11

31 Aug '11

While packaging up a mcclim application using sbcl's save-lisp-and-die, I've noticed an issue with font location handling. I think that the original intention was that the font functions in xrender-fonts.lisp merge the relative paths retrieved from *FAMILIES/FACES* with the user-supplied font-path variables at runtime. This works fine in the case of a system compiled on one system and running on another, since the path can be changed for the client user's system. However, a load-op :after method in the .asd files tries to configure the pathnames automatically for a user's system -- and in the process turns the paths in *FAMILIES/FACES* to absolute ones, with the effect that font-path variables are ignored. The automatic configuration is probably fine (and extremely useful) for the majority of cases, but it might be an idea either to make it optional (other than commenting it out) or to fall back on trying a font-path variable if/when the MISSING-FONT error is raised. For my purposes, #+nil solves the problem for now, and I'm not sure when I might have time to try to come up with a patch, but does anyone have an opinion on the best approach to this? Thanks, David Lewis

1 0

[mcclim-devel] mcclim dialogs
by Paul Bowyer 15 Jun '11

15 Jun '11

Hello mcclim developers: I'm in the throws of learning common lisp and mcclim and I've been able to piece together some working code that functions fairly well by reading from various mcclim specification documents, brief tutorials, and by looking at the various examples that come with mcclim. I have a question regarding the proper way to set up a simple dialog for entering values using mcclim. I've tried using the "accepting-values" macro directly, but I haven't been able to control the position or the size of the dialog when it appears, although I do get usable information from it. From reading the specifications, I've tried using the various position control parameters, but they seem to have no affect. I've tried defining an application frame with a pane derived from "accept-values" but I haven't been successful getting that to run. Does someone have a simple example of either, or both, of these methods of setting up a dialog with mcclim that they would be willing to share? I'm using SBCL-1.0.48 with slime, if that has any importance. Thanks, Paul

1 0

[mcclim-devel] BUG in RECORDING.LISP > DEFINE-INVOKE-WITH
by Richard and/or Dorrit 10 Jun '11

10 Jun '11

When compiling with SBCL 1.0.49, discovered the dynamic-extent declaration at the end of this has two typos, where the dynamic extent is declared for #'continuation and #'constructor, rather than for the gensym'd names for them. So the second version of this code is with this issue fixed. (defmacro define-invoke-with (macro-name func-name record-type doc-string) `(defmacro ,macro-name ((stream &optional (record-type '',record-type) (record (gensym)) &rest initargs) &body body) ,doc-string (setq stream (stream-designator-symbol stream '*standard-output*)) (with-gensyms (constructor continuation) (multiple-value-bind (bindings m-i-args) (rebind-arguments initargs) `(let ,bindings (flet ((,constructor () (make-instance ,record-type ,@m-i-args)) (,continuation (,stream ,record) ,(declare-ignorable-form* stream record) ,@body)) (declare (dynamic-extent #'constructor #'continuation)) (,',func-name ,stream #',continuation ,record-type #',constructor ,@m-i-args))))))) ;;; here's the versioned with the repaired dynamic-extent declaration: (defmacro define-invoke-with (macro-name func-name record-type doc-string) `(defmacro ,macro-name ((stream &optional (record-type '',record-type) (record (gensym)) &rest initargs) &body body) ,doc-string (setq stream (stream-designator-symbol stream '*standard-output*)) (with-gensyms (constructor continuation) (multiple-value-bind (bindings m-i-args) (rebind-arguments initargs) `(let ,bindings (flet ((,constructor () (make-instance ,record-type ,@m-i-args)) (,continuation (,stream ,record) ,(declare-ignorable-form* stream record) ,@body)) (declare (dynamic-extent #',constructor #',continuation)) (,',func-name ,stream #',continuation ,record-type #',constructor ,@m-i-args)))))))

1 0

[mcclim-devel] Scigraph patches for SBCL
by John Morrison 17 May '11

17 May '11

Hi; For what it's worth, I managed to get Scigraph's demos to run under SBCL. There are still bugs (when you click on certain elements of the graphs, they keel over dead), but at least it is something. Please find attached a "cvs diff" listing. If this is not sufficient, of if the patches are not up to the usual McCLIM standards of excellence, please advise, and I will be more than happy to try and do better. Thanks for the software, -jm -- --- John Morrison --- john.nmi.morrison(a)gmail.com

1 0

[mcclim-devel] Re-implementation opportunity in mcclim.asd ??
by Richard and/or Dorrit 12 May '11

12 May '11

Hi - thanks for keeping CLIM alive. Using ASDF-INSTALL 0.2 ASDF 2.014 in SBCL 1.0.47 The mcclim.asd file has: (:version "flexichain" "1.5.1") which breaks, but this works: (:version :flexichain "1.5.1") Thanks, Richard Billington

1 0

[mcclim-devel] pixie-tab-bar-pane's width is computed out of the screen in pixie/clx-look
by nixie 03 May '11

03 May '11

Hello, I tried pixie/clx-look frame manager with clim-examples' tabdemo. (tested on sbcl 1.0.47 with mcclim from latest quicklisp in linux) The tab bar's width is always computed as a very big numbder 20000001/2. the worse is that the tab layout is always drawn out of screen. (In ubuntu, it causes the screen to flash when tabdemo displays. In gentoo, clx will complain a bad typed 16bit integer error) I find that draw-pixie-tab-bar-bottom function draws two lines with x from 0 to +fill+. The +fill+ is a very big number. I think it should draw the lines with x from 0 to the value of (bounding-rectangle-max-x (sheet-region pane)) rather than +fill+. This solves the problem. ;; The one will cause the pixie-tab-bar-pane has a very big width. (defun draw-pixie-tab-bar-bottom (pane) (let ((y0 (bounding-rectangle-min-y (sheet-region pane))) (y1 (bounding-rectangle-max-y (sheet-region pane)))) (draw-line* pane 0 (- y1 6) +fill+ (- y1 6) :ink *3d-light-color*) (draw-line* pane 0 (- y1 1) +fill+ (- y1 1) :ink *3d-dark-color*) #+NIL (draw-line* pane 0 (1- y1) x1 (1- y1) :ink +gray30+))) ;; I think this is better. And it will solve the problem. (defun draw-pixie-tab-bar-bottom (pane) (let ((y0 (bounding-rectangle-min-y (sheet-region pane))) (y1 (bounding-rectangle-max-y (sheet-region pane))) (x0 (bounding-rectangle-min-x (sheet-region pane))) (x1 (bounding-rectangle-max-x (sheet-region pane)))) (draw-line* pane 0 (- y1 6) x1 (- y1 6) :ink *3d-light-color*) (draw-line* pane 0 (- y1 1) x1 (- y1 1) :ink *3d-dark-color*) #+NIL (draw-line* pane 0 (1- y1) x1 (1- y1) :ink +gray30+))) I've only test it with sbcl in linux. I don't know if other CL implementation also has this problem. Does anybody has any idea on this? BTW, I think tab-layout-pane should have a handle-repaint method which will redraw the tab header, it will be good when User resizes the tab layout pane. ;; Handle resize like this one. (defmethod handle-repaint ((pane pixie-tab-layout-pane) region) (pixie-display-tab-header pane (clim-tab-layout::tab-layout-header-pane pane))) -- nixie <onixie(a)gmail.com>

1 1

[mcclim-devel] Unportable string comparing syntax in Doc/makeimages.sh
by onixie 23 Apr '11

23 Apr '11

Hi, I think there is an unportable string comparing syntax in Doc/makeimages.sh Left: portable, Right: unportble by diff ------------------------------------------------------------- 8c8 < if [ "$1" = "-e" ]; then --- > if [ "$1" == "-e" ]; then 22c22 < if [ "$NOCREATE" = "true" ]; then --- > if [ "$NOCREATE" == "true" ]; then -------------------------------------------------------------- It has expected result in bash, but reports a syntax error (as below) in dash and ash (posix compatible shell). The syntax error reported: -------------------------------------------------------------- [: 15: ==: unexpected operator -------------------------------------------------------------- This is a bug in ubuntu because it defaults to use dash. so I think it should be fixed.

1 0

[mcclim-devel] troubles with accept-popup
by Alexander Ekart 17 Apr '11

17 Apr '11

Hello, I was just trying to test the accept-popup function in the CLIM Listener (accept-popup is defined in accepting-values.lisp which is in the McCLIM Examples directory) but I ran into trouble. Executing (clim-demo::accept-popup '(one two three four)) in the Listener and clicking 'OK' or 'Cancel' in the popup yields an error: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION CLIM-INTERNALS::EDITING-STREAM (1)> when called with arguments (#<CLIM-INTERNALS::AV-POP-UP-MENU-RECORD X 173/2:261/2 Y 798.5d0:822.5d0 "Choose one:" {C2B96E1}>). [Condition of type SIMPLE-ERROR] Does anybody have an idee what the problem could be? Thanks! -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

1 0