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

[mcclim-devel] broken
by Thomas Persson 29 Nov '06

29 Nov '06

Hi I noticed that the commands and menus in the listener are broken. I don't exactly understand the listener code but trial and error narrowed it down to what ahefner committed on November 21. Reversing some of those changes seems to fix it.

2 1

[mcclim-devel] Using common-lisp-controller with the Listener
by Martin Raspaud 24 Nov '06

24 Nov '06

Hi all, here is a small patch in order to fix the listener when used with the common-lisp-controller. The patch was suggested by Athas. Martin (aka zorgzorg2) --- mcclim/Apps/Listener/package.lisp 2005-09-29 18:42:36.000000000 +0200 +++ mcclim/Apps/Listener/package.lisp 2006-11-24 14:32:16.000000000 +0100 @@ -9,4 +9,4 @@ (eval-when (:load-toplevel) ; (format t "~&~%!@#%^!@#!@ ... ~A~%~%" *load-truename*) - (defparameter *icon-path* (merge-pathnames #P"icons/" *load-truename*))) + (defparameter *icon-path* (merge-pathnames #P"icons/" (load-time-value (or #.*compile-file-pathname* *load-pathname*)))))

1 0

[mcclim-devel] Drei text-field issues
by Thomas Persson 23 Nov '06

23 Nov '06

Hi I noticed two problems with Drei text-fields: * No checking whether a gesture is an activation gesture. * Value-changed-callback doesn't work. From what I can tell, value-gadget should do this for us but it's handled manually in Goatee. The attached patch should fix both problems. / Thomas Persson

2 1

[mcclim-devel] presenting expressions, nested presentations
by Christophe Rhodes 22 Nov '06

22 Nov '06

Hi, Wouldn't it be cool if, when we presented list data as an expression, the contents were individually presented? Well, consider the code at the end of this mail; it achieves this, but at a price: we no longer respect *print-level*, *print-length* and friends; we don't honour *pprint-dispatch-table* (which might have EQL "methods" on these objects); and there appears not to be a way of finding out what the user would prefer to be the :single-box attribute of the nested presentations. The *print-level*/*print-length* and friends could be worked on with a little bit more code; the *pprint-dispatch-table* issue, however, is rather more fundamental; if it can be handled at all, it would need to be handled on an implementation-level basis (there's no GET-PPRINT-DISPATCH exposed to the user, only SET-PPRINT-DISPATCH). I presume that the :single-box issue we can deal with ourselves by inventing a special variable. Really, what I would like to know is what the requirements for this presentation method are. What do I have to do to honour the ACCEPTABLY keyword? Is managing *print-level* and *print-length* enough (well, presumably there's more work to be done to support *print-array* and so on)? Should we do this for user-defined structures as well, where we can determine that there is no applicable *pprint-dispatch-table* or PRINT-OBJECT method (fortunately, there can be no user PRINT-OBJECT method on conses or vectors). I suppose the inevitable question is: what did the Lisp Machines do...? Answers welcome! Cheers, Christophe (define-presentation-method present (object (type expression) stream (view textual-view) &key acceptably for-context-type) (declare (ignore for-context-type)) (let ((*print-readably* acceptably)) (typecase object (cons (with-output-as-presentation (stream object type :single-box t) (princ #\( stream) (do ((o object (cdr o))) ((null o)) (present (car o) (presentation-type-of (car o)) :stream stream :view view) (cond ((null (cdr o)) (return)) ((listp (cdr o)) (princ #\Space stream)) (t (princ " . " stream) (present (cdr o) (presentation-type-of (cdr o)) :stream stream :view view) (return)))) (princ #\) stream))) (simple-vector (with-output-as-presentation (stream object type :single-box t) (princ "#(" stream) (do ((i 0 (1+ i))) ((>= i (length object))) (present (svref object i) (presentation-type-of (svref object i)) :stream stream :view view) (when (>= i (1- (length object))) (return)) (princ " " stream)) (princ #\) stream))) (t (prin1 object stream)))))

4 7

Re: Fwd: Re: [mcclim-devel] Severe performance regression with latest CVS sources?
by Christophe Rhodes 22 Nov '06

22 Nov '06

Paolo Amoroso <amoroso(a)mclink.it> writes: >> twice that many hash tables with (make-hash-table)? The other thing > > CL-USER> (time (dotimes (i (* 2 824)) > (make-hash-table))) > ; Compiling LAMBDA NIL: > ; Compiling Top-Level Form: > > ; Evaluation took: > ; 6,648 CPU cycles It's elided the creation, I'm afraid. Can you do (defvar *foo*) (time (dotimes (i (* 2 824)) (setq *foo* (make-hash-table)))) ? > ; > NIL > CL-USER> > > >> to look at is for collisions in your hash tables; check the EDGES-FROM >> slot of something with a lot of direct subclasses, say STRUCTURE-CLASS >> or CONDITION or NUMBER, and see if all of the entries are in the same >> bucket of the hash table) > > I'm not sure I understand what you mean. I used the SLIME inspector > to inspect the output of, say, (find-class 'structure-class). I > include the output below, which does not seem to have any EDGES-FROM > slot. I think the edges-from should be in the graph node output record. I'm not entirely sure how to get at one of those, but you could start by inspecting clim:*application-frame* from the slime inspector, finding the listener interactor pane, finding its output history, and looking at the output records in there. > 588,259,376 | 1,111 | 15.158 | 0.01364 | 529,486 | CLIM-INTERNALS::LAYOUT-EDGE-1 > 1,111: #<Code Object "LAMBDA (FWRAPPER)" {5A58260F}> > 1,470,608 | 2,222 | 0.056 | 0.00003 | 662 | CLIM-INTERNALS::ENSURE-EDGE-RECORD > 1,111: #<Code Object "DEFUN LAYOUT-EDGE" {59718A4F}> > 1,111: #<Code Object "DEFUN LAYOUT-EDGE-1" {5A75B007}> Well, that's moderately conclusive: the cost seems to be in LAYOUT-EDGE-1, not in ENSURE-EDGE-RECORD. Which is weird, because I can't really see what LAYOUT-EDGE-1 is doing that is so ludicrously expensive. Can you do the same thing, but with the CLIM package profiled additionally? (And then maybe one with CLIM but not CLIM-INTERNALS profiled?) The first 10 or so entries in each profile will probably suffice. (Maybe CLEAR-OUTPUT-RECORD is expensive?) Cheers, Christophe

3 3

[mcclim-devel] more clisp/win32 issues
by Jack Unrue 21 Nov '06

21 Nov '06

Here are a few more issues I've encountered trying to load McCLIM on CLISP / Win32. There are two places in the .asd file where the :file component :name value is given as a two-part path expression. CLISP complains: MAKE-PATHNAME: illegal :NAME argument "Goatee/presentation-history" [Condition of type SIMPLE-ERROR] and MAKE-PATHNAME: illegal :NAME argument "Looks/pixie" [Condition of type SIMPLE-ERROR] Goatee/goatee-command.lisp fails to compile specifically on CLISP / Win32 because #\Delete is not defined (but it is for CLISP on Unix). The same character value can be obtained with #\Rubout. More info here: http://www.podval.org/~sds/clisp/impnotes/char-platform-dep.html I suppose the next problem is better reported on the flexichain mailing list, but while I've got your attention...flexichain/utilities.lisp has an EVAL-WHEN form that uses :evaluate which is not supported on CLISP: ;; Compiling file C:\projects\third_party\asdf-repo\flexichain\utilities.lisp ... ERROR in lines 66..93 : EVAL-WHEN situation must be :LOAD-TOPLEVEL, :COMPILE-TOPLEVEL or :EXECUTE, but not :EVALUATE The reason why I'm bothering you all with these issues, rather than just using SBCL, is that the combination of SBCL, Slime, and Graphic-Forms is not working due to an as yet unresolved issue with window creation. If you're subscribed to either slime-devel or sbcl-devel then you've seen the problem report. Interestingly, I see the same problem with gtkairo. But CLISP works great for me, so I thought it would be worth some time looking into this stuff. -- Jack Unrue

3 5

[mcclim-devel] Drei dependency problem on clisp
by Jack Unrue 21 Nov '06

21 Nov '06

I found a small issue with the :depends-on form for :drei-mcclim when trying to load the latest mcclim on clisp 2.41. Drei uses #. in :depends-on to try to define a dependency on swank if it's loaded. Unfortunately on clisp, this results in nil rather than no value. I'm seeing this error: component NIL not found, required by #1=#<SYSTEM "drei-mcclim" #x19F581E9> [Condition of type ASDF:MISSING-DEPENDENCY] There was discussion on c.l.l. about the behavior of the reader macro function in this regard, see the thread started by Pascal Bourguignon: http://groups.google.com/group/comp.lang.lisp/msg/6d137dca962cfaf4?hl=en& Note that I'm not actually trying to run drei on clisp, just trying to load mcclim.asd. -- Jack Unrue

2 1

[mcclim-devel] small tweak for gtkairo on win32
by Jack Unrue 20 Nov '06

20 Nov '06

Backends/gtkairo/ffi.lisp has a defcfun entry for XGetErrorText which as far as I can tell is not exported by any of the Win32 GTK DLLs (that makes sense, although one could imagine it being defined for interoperability reasons). The dribble-x-errors function in Backends/gtkairo/event.lisp uses a conditional to avoid calling XGetErrorText on Win32. I've changed my local copy of ffi.lisp to avoid the defcfun with the same conditional; perhaps the same fix could be checked in? Thanks. -- Jack Unrue

2 3

[mcclim-devel] (no subject)
by Automatic Email Delivery Software 17 Nov '06

17 Nov '06

The original message was received at Fri, 17 Nov 2006 18:04:14 +0900 from common-lisp.net [139.202.14.112] ----- The following addresses had permanent fatal errors ----- <mcclim-devel(a)common-lisp.net>

1 0

[mcclim-devel] Problems with McClim demo
by Damien Kick 14 Nov '06

14 Nov '06

I checked McClim and Flexichain out of CVS, used ASDF to load them, and then tried to run the address-book demo but it did not work for me. I've tried searching the web for a FAQ about this but haven't been able to find anything. I did start looking through the mailing list archives but without a search option I have only found a suggestion to make sure that DISPLAY is set. CLIM-DEMO> (sys:getenv "DISPLAY") ":0.0" CLIM-DEMO> (run-frame-top-level (make-application-frame 'address-book)) ; Evaluation aborted CLIM-DEMO> (lisp-implementation-type) "International Allegro CL Professional Edition" CLIM-DEMO> (lisp-implementation-version) "8.0 [Mac OS X] (Nov 11, 2006 22:53)" CLIM-DEMO> (software-type) "Apple Mac OS X 10.4" CLIM-DEMO> (software-version) "Darwin Damien-Kicks-Computer.local 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/ RELEASE_PPC Power Macintosh powerpc" CLIM-DEMO> And here is the stack trace Connection failure to X11.0 server display 0: No protocol specified [Condition of type XLIB:CONNECTION-FAILURE] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT] Abort entirely from this (lisp) process. Backtrace: 0: (SWANK::DEBUG-IN-EMACS #<XLIB:CONNECTION-FAILURE @ #x11accd5a>) 1: (SWANK:SWANK-DEBUGGER-HOOK #<XLIB:CONNECTION-FAILURE @ #x11accd5a> #<Function SWANK-DEBUGGER-HOOK>) 2: (ERROR XLIB:CONNECTION-FAILURE :MAJOR-VERSION 11 :MINOR-VERSION 0 :HOST "" :DISPLAY 0 ...) 3: (XLIB::X-ERROR XLIB:CONNECTION-FAILURE :MAJOR-VERSION 11 :MINOR- VERSION 0 :HOST "" :DISPLAY 0 ...) 4: (XLIB::DISPLAY-CONNECT #<XLIB:DISPLAY :0 ( R0)> :AUTHORIZATION- NAME NIL :AUTHORIZATION-DATA NIL) 5: (XLIB:OPEN-DISPLAY "" :DISPLAY 0 :PROTOCOL :LOCAL) 6: ((METHOD CLIM-CLX::INITIALIZE-CLX (CLIM-CLX::CLX-PORT)) #<CLIM- CLX::CLX-PORT @ #x11ac3b6a>) 7: ((METHOD INITIALIZE-INSTANCE :AFTER (CLIM-CLX::CLX-PORT)) #1=#<CLIM-CLX::CLX-PORT @ #x11ac3b6a> . #1#) 8: ((:INTERNAL (:EFFECTIVE-METHOD 1 T NIL NIL NIL) 0) #1=#<CLIM- CLX::CLX-PORT @ #x11ac3b6a> . #1#) 9: ((METHOD MAKE-INSTANCE (CLASS)) #<STANDARD-CLASS CLIM-CLX::CLX- PORT> :SERVER-PATH (:CLX :HOST "" :DISPLAY-ID 0 :SCREEN-ID 0 :PROTOCOL :LOCAL)) 10: ((METHOD MAKE-INSTANCE (SYMBOL)) CLIM-CLX::CLX-PORT :SERVER-PATH (:CLX :HOST "" :DISPLAY-ID 0 :SCREEN-ID 0 :PROTOCOL :LOCAL)) 11: (FIND-PORT) 12: (FIND-FRAME-MANAGER) 13: ((METHOD RUN-FRAME-TOP-LEVEL :AROUND (APPLICATION-FRAME)) #<ADDRESS-BOOK @ #x11ac356a>) 14: ((:INTERNAL (:EFFECTIVE-METHOD 1 T NIL T T) 0) #<ADDRESS-BOOK @ #x11ac356a> . #<non-lisp object @ #x1>) 15: (EVAL (RUN-FRAME-TOP-LEVEL (MAKE-APPLICATION-FRAME (QUOTE ADDRESS- BOOK)))) 16: (SWANK::EVAL-REGION "(run-frame-top-level (make-application-frame 'address-book)) " T) 17: ((:INTERNAL SWANK:LISTENER-EVAL 0)) 18: ((METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) #<Closure (:INTERNAL SWANK:LISTENER-EVAL 0) @ #x11ac344a>) 19: (SWANK::CALL-WITH-BUFFER-SYNTAX #<Closure (:INTERNAL SWANK:LISTENER-EVAL 0) @ #x11ac344a>) 20: (SWANK:LISTENER-EVAL "(run-frame-top-level (make-application- frame 'address-book)) ") 21: (EVAL (SWANK:LISTENER-EVAL "(run-frame-top-level (make- application-frame 'address-book)) ")) 22: ((:INTERNAL SWANK::EVAL-FOR-EMACS 0)) 23: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK::EVAL-FOR-EMACS 0) @ #x11ac342a>) 24: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(run-frame-top-level (make-application-frame 'address-book)) ") "CLIM-DEMO" 77) 25: (FUNCALL SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(run-frame- top-level (make-application-frame 'address-book)) ") "CLIM-DEMO" 77) 26: (SWANK::READ-FROM-EMACS) 27: ((:INTERNAL SWANK::HANDLE-REQUEST 0)) 28: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<Function SWANK-DEBUGGER-HOOK> #<Function (:INTERNAL SWANK::HANDLE-REQUEST 0)>) 29: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 30: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION @ #x107142ca> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x11ac27ca>) 31: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION #<SWANK::CONNECTION @ #x107142ca> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x11ac27ca>) 32: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION @ #x107142ca> #<Function (:INTERNAL SWANK::HANDLE-REQUEST 0)>) 33: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION @ #x107142ca>) 34: ((:INTERNAL SWANK::REPL-LOOP 0)) 35: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<Function SWANK-DEBUGGER-HOOK @ #x106bd8d2> #<Closure (:INTERNAL SWANK::REPL- LOOP 0) @ #x10715332>) 36: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 37: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION @ #x107142ca> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x10715352>) 38: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION #<SWANK::CONNECTION @ #x107142ca> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x10715352>) 39: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION @ #x107142ca> #<Closure (:INTERNAL SWANK::REPL-LOOP 0) @ #x10715332>) 40: (SWANK::REPL-LOOP #<SWANK::CONNECTION @ #x107142ca>) 41: ((:INTERNAL (:INTERNAL SWANK::SPAWN-REPL-THREAD 0) 0)) 42: (SWANK::CALL-WITH-BINDINGS NIL #<Closure (:INTERNAL (:INTERNAL SWANK::SPAWN-REPL-THREAD 0) 0) @ #x1071538a>) 43: ((:INTERNAL SWANK::SPAWN-REPL-THREAD 0)) For what it's worth, I get the same error message when attempting to run the demo without SLIME, i.e. just starting Allegro in an xterm. Any ideas as to what is going wrong?

5 8