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

Re: [mcclim-devel] Fwd: Possible bug in non exclusive list pane.
by P C 05 Aug '12

05 Aug '12

Hello, When you click on the list, does it change the value? I am getting this error when I click on an item in the list. debugger invoked on a TYPE-ERROR in thread #<THREAD "Stocks Window" RUNNING {100885EE33}>: The value NIL is not of type (MOD 4611686018427387901). Thanks for testing it out. On 08/04/12 20:30, Mariano Montone wrote: > Hi. > > Your program runs without problems in my computer. > > I'm running SBCL on Ubuntu > > Mariano > > (in-package :climi) > > (define-application-frame stocks-window () > () > (:geometry :width 640 :height 480 :left 64 :top 32) > (:panes > (index-list (make-pane ':list-pane > :id 'index-list > :value '("A" "B") > :items '("A" "B" "C" "D") > :mode ':nonexclusive > :prefer-single-selection t > :test #'string=))) > (:layouts > (default > (clim-tab-layout:with-tab-layout ('tab-page :name 'layout :height > 480) > ("A" > (spacing > (:thickness 8) > (horizontally > (:x-spacing 4 :y-spacing 4) > (labelling (:label "List" :height 128 :width 192) > (scrolling (:scroll-bar t) > (spacing (:thickness 0) > index-list))))))))) > (:menu-bar t)) > > (define-stocks-window-command (com-quit :menu t) () > (frame-exit *application-frame*) > nil) > > (defvar *window-frame* nil) > > (defun window () > (flet ((run () > (let ((frame (make-application-frame 'stocks-window))) > (setf *window-frame* frame) > (run-frame-top-level frame)))) > (sb-thread:make-thread #'run :name "Window"))) > > (window)

2 2

[mcclim-devel] Fwd: Possible bug in non exclusive list pane.
by P C 04 Aug '12

04 Aug '12

---------- Forwarded message ---------- From: P C <psilocidal(a)gmail.com> Date: Sat, Aug 4, 2012 at 7:46 PM Subject: Re: [mcclim-devel] Possible bug in non exclusive list pane. To: Stas Boukarev <stassats(a)gmail.com> On Sat, Aug 4, 2012 at 7:34 PM, Stas Boukarev <stassats(a)gmail.com> wrote: > P C <psilocidal(a)gmail.com> writes: > > > Hello, > > > > When I try my code for a list pane as nonexclusive, I receive an error > > saying value NIL is not of type (mod some-number). I thought this meant > > that it didn't like my values and items as strings so I changed test to > > #'string= not #'eql. I still get this error when I click on the list to > > change the value. > > > > Is this a known bug? Or am I missing something in my code? > It would be helpful if you attached the code in question. > -- > With best regards, Stas. > Sorry for leaving out the code. (define-application-frame stocks-window () () (:geometry :width 640 :height 480 :left 64 :top 32) (:panes (index-list (make-pane ':list-pane :id 'index-list :value '("A" "B") :items '("A" "B" "C" "D") :mode ':nonexclusive :prefer-single-selection t :test #'string=))) (:layouts (default (with-tab-layout ('tab-page :name 'layout :height 480) ("A" (spacing (:thickness 8) (horizontally (:x-spacing 4 :y-spacing 4) (labelling (:label "List" :height 128 :width 192) (scrolling (:scroll-bar t) (spacing (:thickness 0) index-list))))))))) (:menu-bar t)) (define-window-command (com-quit :menu t) () (frame-exit *application-frame*) nil) (defvar *window-frame* nil) (defun window () (flet ((run () (let ((frame (make-application-frame 'window))) (setf *window-frame* frame) (run-frame-top-level frame)))) (make-thread #'run :name "Window"))) (window)

2 1

[mcclim-devel] Possible bug in non exclusive list pane.
by P C 04 Aug '12

04 Aug '12

Hello, When I try my code for a list pane as nonexclusive, I receive an error saying value NIL is not of type (mod some-number). I thought this meant that it didn't like my values and items as strings so I changed test to #'string= not #'eql. I still get this error when I click on the list to change the value. Is this a known bug? Or am I missing something in my code?

2 1

[mcclim-devel] very good CLIM (and Genera) documents
by Timothy Moore 25 Jul '12

25 Jul '12

I just discovered the Symbolics documentation on line at bitsavers.org. http://www.bitsavers.org/pdf/symbolics/software/genera_8/Common_Lisp_Interf… is great; all the other Symbolics documentation will make you cry, in particular the Dynamic Windows stuff :) Tim

1 0

[mcclim-devel] Why is CLIM dead
by Mariano Montone 13 Jul '12

13 Jul '12

Hi. A CLIM/McCLIM newbie here. I've been reading about CLIM and playing a little with McCLIM, and it looks quite good to me. I have been able to prototype some tools very quickly. So I was wondering why CLIM is dead. It looks like it doesn't have any activity at all. And I think it is a pity, because when I first looked at Listener/Climacs/Debugger/Inspector stuff, I thought it would be a very nice replacement for SLIME, for instance. I'm SLIME user, but I think there's lot of room for improvements in the Lisp tools area, and the CLIM tools + usability improvements + possibilities to extend the tools very easily sounds very good to me. Does anyone know why CLIM is not used anymore? Does it have any very bad design decisions? I'm not really sure about output recording/redisplay, etc (I haven't seen theme elsewhere, as if that could be automatically handled in general). Don't know about composability and layout yet (I'm still struggling a bit with that now). And I also see some bugs, like some refreshing problems when scrolling, but bugs should be fixable. I appreciate your feedback. Thanks, Mariano

6 10

[mcclim-devel] access local application-frame in command
by Orm Finnendahl 25 Jun '12

25 Jun '12

Hi, I'm having trouble to find out, how to write a quit command without using a global *application-frame* variable. The idea is to be able to create more than one application frame and to encapsulate everything into the frame, applying menu commands only to the frame in which the command was issued. I looked into the examples but all seem to be happy with a global *application-frame* variable. A similar issue concerns different key-to-command mappings in different panes of the same application. In an editor pane the arrow keys should be used for cursor movement and in other panes they could mean different things. Do I have to move the dispatch into the command invoked by the arrow keys or is there another mechanism built into mcclim which enbales the use of different mappings in different panes? Thanks for any help, Orm ------------------------------------------------------------------ Prof. Orm Finnendahl Komposition Studio für elektronische Musik und Akustik Musikhochschule Freiburg Schwarzwaldstr. 141 79102 Freiburg Tel.: +49-761-31915-167

2 1

[mcclim-devel] double buffering of drawing panes
by Orm Finnendahl 22 Mar '12

22 Mar '12

Hi, in a mcclim application with incremental redisplay and lots of objects there is a noticeable irregular flicker when dragging some objects even for parts of the screen, which aren't invalidated by the dragging. I checked the code and verified that my redraw routine is not doing any redraw on these parts. It seems clim's work behind the scenes replaying output records is responsible for that. Is there a more or less straightforward way to implement double buffering on the pane without taking mcclim apart? Yours, Orm

2 2

[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 01 Sep '11

01 Sep '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