mcclim-devel June 2009

mcclim-devel@common-lisp.net

7 participants
9 discussions

Re: [mcclim-devel] mcclim-devel Digest, Vol 39, Issue 6
by Irene DURAND 27 Mar '13

27 Mar '13

Hello, As my paste on irc lisp, did not have any answer, I turning again to this more specialized mailing list. I have this MClim problem. The application runs fine on Linux with SBCL 1.0.13, xorg-x11-server 1.3.0.0-9.fc7, a recent version of MClim. But doesn't on my Mac (Darwin PowerPC) with MacOS 10.5 (leopard), SBCL 1.0.16, cvs version of MClim, Xquartz 2.1.5 - (xorg-server 1.3.0-apple22)(2.1.5). I have tried to create the smallest as possible application where the problems occurs (attached). Just compile the file and launch mini::(start) On Linux, I have the desired behaviour: a circle blinks (red/green/red/...) on the display pane and at the bottom of the window application, the "quit" button is displayed and works. On the Mac, the circle blinks correctly but the "Quit" button never shows up. For a while the application is killable with C-c C-c (under Slime), but after a while there is no way to kill it than to stop Lisp and restart everything (even /the/ <http://www.lispworks.com/reference/HyperSpec/Body/s_the.htm> X server). Note that this application used to work on Mac OS 10.3 (Panther) with older versions of everything. I suspect the X server to behave differently from before. But now I don't see how to make the application work. This is too bad, as I usually use a similar application for my Lisp undergraduate course. If anyone has an idea, it will be welcomed. Irène (defpackage :mini (:use :clim :clim-extensions :clim-lisp)) (in-package :mini) (let ((colors (list +red+ +green+))) (setf colors (nconc colors colors)) (defun display-function (frame pane) (draw-circle* pane 10 10 10 :ink (pop colors)) (sleep 0.5) (redisplay-frame-panes frame))) (defun quit () (frame-exit *application-frame*)) (define-application-frame mini () () (:panes (display :application :display-function 'display-function :incremental-redisplay t) (quit :push-button :label "Quit" :activate-callback (lambda (x) (declare (ignore x)) (quit)))) (:layouts (defaults (vertically () display quit)))) (defun run-test (name) (loop for port in climi::*all-ports* do (destroy-port port)) (setq climi::*all-ports* nil) (let ((frame (make-application-frame name))) (run-frame-top-level frame))) (defun start () (run-test 'mini) 0) (defmethod run-frame-top-level :before ((mini mini) &key) (let* ((frame-manager (frame-manager *application-frame*)) (port (climi::frame-manager-port frame-manager)) (display (clim-clx::clx-port-display port))) (setf (xlib:display-after-function display) g#'xlib:display-force-output)))

4 4

[mcclim-devel] small clim-lisp:defconstant improvement
by Nikodemus Siivola 29 Jun '09

29 Jun '09

I was recently somewhat burned (performance-wise) by clim-lisp:defconstant being really a defvar. Would something like the following be an acceptable substitute? It remains portable, but allows implementations to do a much better job for important cases like numeric constants: (defmacro clim-lisp-patch:defconstant (symbol value &optional docu) (if (typep value '(or number character)) `(cl:defconstant ,symbol ,value ,@(and docu (list docu))) `(defvar ,symbol ,value ,@(and docu (list docu))))) Cheers, -- Nikodemus

1 0

[mcclim-devel] Skinning McCLIM interfaces
by Ram Vedam 25 Jun '09

25 Jun '09

I was curious if there is a possibility that McCLIM user interfaces can be skinned (change visual appearance) to look more "modern"? I haven't seen too much written on this topic and am wondering if it can currently be done, and if so, how? Ram

2 1

[mcclim-devel] [ANNOUNCE] McCLIM RPM available for Fedora
by Robert Uhl 23 Jun '09

23 Jun '09

I've packaged McCLIM for Fedora at: http://yum.octopodial-chrome.com/packages/cl-mcclim Probably the easiest thing to do is to install the octopodial-chrome package and then run 'yum install cl-mcclim.' -- Robert Uhl <http://public.xdi.org/=ruhl> Man, the creature who knows he must die, who has dreams larger than his destiny, who is forever working a confidence trick on himself, needs an ally. Mine has been tobacco. --John Boynton Priestley

1 0

Re: [mcclim-devel] mcclim on windows
by Patrik Magnusson 19 Jun '09

19 Jun '09

Hello again, Sorry but it turns out that an explicit (asdf :clim-clx) was what was missing. I didn't see the Cliki page about asdf-installing until yesterday and I was fooled by the fact that it wasn't necessary on linux. So, now it works. Both with the lispbox version of Clisp (2.37) and the small sourceforge binary (2.47). BR, /Patrik. On Fri, Jun 19, 2009 at 12:49:10AM +0400, Evgeny M. Zubok wrote: > Patrik Magnusson <magnusson.patrik(a)bredband.net> writes: > > > Could someone perhaps tell me the names of some good functions to > > trace, and so see how far the demodemo comes? > > You could try to load only clx (without mcclim) and run the examples > from clx/demo. For example, to load clx/demo/menu.lisp and run > > (xlib::just-say-lisp) > > The connection with X server is established in CLX (open-default-display > funtcion), so if you didn't see the simple menu from this example then > problem, more probably, laying in CLX-Xming interaction, not in McCLIM.

1 0

[mcclim-devel] Error: Class not yet defined: CLIM:INTERACTOR-PANE
by Cyrus Harmon 19 Jun '09

19 Jun '09

I think this is one of those errors that goes away upon zapping fasls, but I also think I've seen it before. Any clues? thanks, cyrus Class not yet defined: CLIM:INTERACTOR-PANE [Condition of type SIMPLE-TYPE-ERROR] Restarts: 0: [TRY-RECOMPILING] Recompile commands and try loading it again 1: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {131F6EF1}> on #<ASDF:CL-SOURCE-FILE "commands" {12811131}>. 2: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {131F6EF1}> on #<ASDF:CL-SOURCE-FILE "commands" {12811131}> as having been successful. 3: [RETRY] Retry SLIME REPL evaluation request. 4: [ABORT] Return to SLIME's top level. 5: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" RUNNING {11A9D949}>) Backtrace: 0: (SB-KERNEL:FIND-CLASSOID-CELL CLIM:INTERACTOR-PANE)[:EXTERNAL] 1: (SB-FASL::FOP-FUNCALL) 2: (SB-FASL::LOAD-FASL-GROUP #<SB-SYS:FD-STREAM for "file /Users/ sly/src/lisp/mcclim/mcclim/sbcl-1.0.29.13-darwin-x86/ commands.fasl" {119F2639}>) 3: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 4: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]291)) 5: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK ..) 6: (SB-FASL::LOAD-AS-FASL #<SB-SYS:FD-STREAM for "file /Users/sly/ src/lisp/mcclim/mcclim/sbcl-1.0.29.13-darwin-x86/ commands.fasl" {119F2639}> NIL #<unavailable argument>) 7: ((FLET SB-FASL::LOAD-STREAM) #<SB-SYS:FD-STREAM for "file /Users/ sly/src/lisp/mcclim/mcclim/sbcl-1.0.29.13-darwin-x86/ commands.fasl" {119F2639}>) 8: (LOAD #P"/Users/sly/src/lisp/mcclim/mcclim/sbcl-1.0.29.13-darwin- x86/commands.fasl")[:EXTERNAL] 9: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:LOAD-OP ASDF:CL-SOURCE- FILE)) #<unavailable argument> #<unavailable argument> #<ASDF:LOAD-OP NIL {131F6EF1}> #<ASDF:CL-SOURCE-FILE "commands" {12811131}>) 10: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) ..) 11: ((SB-PCL::FAST-METHOD ASDF:PERFORM ASDF:AROUND (ASDF:LOAD-OP ASDF:CL-SOURCE-FILE)) ..) 12: ((LAMBDA ())) 13: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK))

1 0

[mcclim-devel] pathname completion on SBCL
by Cyrus Harmon 19 Jun '09

19 Jun '09

On recent SBCLs, at least, (directory "fo*.*") only finds foo if foo is a file, not a directory. Not sure if this is a bug or a feature, but it breaks my understanding of how filename completion should work. The following (slightly ugly) patch fixes things for me: diff --git a/presentation-defs.lisp b/presentation-defs.lisp index 8661046..fb2de97 100644 --- a/presentation-defs.lisp +++ b/presentation-defs.lisp @@ -1629,8 +1629,21 @@ protocol retrieving gestures from a provided string.")) do (replace so-far "\ \*" :start1 occurence) (setf start (+ occurence 2)) finally (return so-far))) + #+sbcl and #+sbcl wildcard-directories #+sbcl = + #+sbcl (format nil "~A*" + (loop for start = 0 ; Replace * -> \* + for occurence = (position #\* so-far :start start) + until (= start (length so-far)) + until (null occurence) + do (replace so-far "\\*" :start1 occurence) + (setf start (+ occurence 2)) + finally (return so-far))) for path in - #+(or sbcl cmu lispworks) (directory wildcard) + #+sbcl (remove-duplicates + (append (directory wildcard) + (directory wildcard-directories)) + :test #'equal) + #+(or cmu lispworks) (directory wildcard) #+openmcl (directory wildcard :directories t) #+allegro (directory wildcard :directories-are-files nil) #+cormanlisp (nconc (directory wildcard) Any suggestions on the best way to handle this? thanks, cyrus

1 1

[mcclim-devel] mcclim on windows
by Patrik Magnusson 17 Jun '09

17 Jun '09

Hello, I am wondering about the current status of mcclim on windows. I cannot myself get it to display anything, after trying a number of approaches. For X, I am using Xming from sourceforge. I can run the demodemo from a linux box and display it on the windows box, so I think X is OK. First try was with sbcl-1.0.29, clx-0.73, flexichain_1.5.1, spatial-trees-0.2 and mcclim from CVS. When I try the demodemo, nothing gets displayed, and if I try to interrupt sbcl it just dies. If I chose to exit Xming, the confirmation box reports that 1 client is attached - so I guess something is happening. I have tried this from emacs/slime and in raw sbcl. Second try was with lispbox from "Practical Common Lisp", which is Clisp-2.37 with libs as above. Again, nothing is displayed, though lisp is running at 100% of the CPU. When I interrupt lisp, I can see from the stack frames that the event loop is running, but Xming reports no clients attached. Third try was with clisp-2.47, the small windows binary from sourceforge (without the new-clx I think). Results were the same as for 2.37. I also tried all the above with clx-0.71, since that is what I have on my linux box (and which is working there), but results were the same. I also tried compiling the source for clisp-2.47 (to make sure new-clx isn't in it), but I was unable to do that in mingw. I can't really capture any other clues, and so I'm stuck. Does anyone have any info, or request for more from me? BR, /Patrik.

2 2

[mcclim-devel] [PATCH] Fix copy-from-pixmap to work inside with-output-to-pixmap
by Evgeny M. Zubok 03 Jun '09

03 Jun '09

The attached patch fixes bug when I'm trying to copy pixmap to medium-var inside the body of with-output-to-pixmap macro. The explanation below. >From CLIM 2.0 (LispWorks) with-output-to-pixmap [Macro] Arguments: (medium-var medium &key width height) &body body Summary: Binds `medium-var' to a "pixmap medium" (that is, a medium that does output to a pixmap with the characteristics appropriate to the medium `medium') and then evaluates body in that context. All the output done to the medium designated by `medium-var' inside of body is drawn on the pixmap stream. The pixmap medium supports the medium output protocol, including all of the graphics functions. `width' and `height' are integers that give the dimensions of the pixmap. If they are omitted, the pixmap will be large enough to contain all the output done by body. `medium-var' must be a symbol; it is not evaluated. The returned value is a pixmap that can be drawn onto medium using copy-from-pixmap. As soon as "The pixmap medium supports the medium output protocol, including all of the graphics functions." then the copy-from-pixmap also has to work inside with-output-to-pixmap macro. I've written simple and quick example (attached) to illustrate this. In the handle-repaint method the temporary pixmap `temp-pixmap' is created with yellow background and filled circle in centre. Then `temp-pixmap' is copied with copy-from-pixmap inside with-output-to-pixmap macro into newly created `target-pixmap' and the second circle is drawn above. Finally the `target-pixmap' is copied to canvas. (copy-from-pixmap-test::run) to run the example.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel June 2009