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

[mcclim-devel] Unsupported implementations
by Richard Lewis 13 Aug '12

13 Aug '12

Hi there, Out of interest (I have no particular application for this) I tried installing McCLIM with ECL just now using QuickLisp and got nowhere. The mcclim.asd has a defsystem form, :clim-lisp, which adds a file component depending on the implementation. However, it has no fall-back for unsupported implementations meaning that the error I get if I try to compile with ECL is "Too few arguments supplied to a macro or a destructuring-bind form" where "unsupported implementation" would be better. I tried adding a fall-back to that defsystem just to see what would happen: (defsystem :clim-lisp :components (;; First possible patches (:file "patch") (:module "Lisp-Dep" :depends-on ("patch") :components ((:file #+cmu "fix-cmu" #+scl "fix-scl" #+excl "fix-acl" #+sbcl "fix-sbcl" #+openmcl "fix-openmcl" #+lispworks "fix-lispworks" #+clisp "fix-clisp" #| other |# "fix-nil"))) (:file "package" :depends-on ("Lisp-Dep" "patch")))) fix-nil.lisp was just an empty file. It compiled a little bit but eventually failed saying "Cannot find symbol "FUNDAMENTAL-BINARY-INPUT-STREAM" in package #<"CLIM-LISP" package>". But that's not really the point. I don't know what is the idiomatic way of making a system fail based on implementation, but it might be good to do something like that in McCLIM. Richard

1 0

[mcclim-devel] Is list-pane not fully implemented?
by P C 08 Aug '12

08 Aug '12

Hello, I've been trying to get my list-panes fully operational, but it seems as I take one step forward, something else seems to push me back two steps. It is frustrating, but I am more grateful to be learning these tools, because this is really the only way I will be exposed to CL. It seems that at first, my lists didn't seem to want to be nonexclusive. I found out that the problem with that was my McCLIM directory in quicklisp had about half of the files missing (?). I don't know how that happened. Then after I figured that out, when I try to update the items of the list using (setf (list-pane-items pane) new-items), it says there is no generic function to handle this. Maybe my problem comes from my work around. This is what I did. (with-slots (pane) *application-frame* (with-slots (items) pane (setf (climi::list-pane-items (find-pane-named *application-frame* 'pane)) new-items-list))) Is all of this necessary? It seems the second (with-slots ...) is not necessary. I've read through the gadgets.lisp and it seems that the defgeneric and defmethods are defined appropriately, but (setf list-pane-items) or (setf climi::list-pane-items) errors out as no generic function. Is there a way better than what I did? After I use this to update my list, it redisplays with only half of the items; 1500 instead of 3000. Is this a limit of the size that a list-pane can handle; or is this from my work around? Also I would like to mention, :scroll-bars and :visible-items keys don't work for me. Are these known bugs? When I had :scroll-bars t and tried to update my list, the whole screen became transparent except for around the borders where it was refracted. P C

2 5

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