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

[mcclim-devel] May/June 2005 messages missing from mcclim-devel archive
by Paolo Amoroso 10 Jun '05

10 Jun '05

It looks like the archive of the mcclim-devel mailing list: http://common-lisp.net/pipermail/mcclim-devel/ is missing all May 2005 messages and part of the June ones. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

3 2

[mcclim-devel] Beagle backend requirements?
by Brian Mastenbrook 09 Jun '05

09 Jun '05

Hi Duncan, What version of OpenMCL is required for running the Beagle backend? Right now current CVS won't run on 0.14.3 with an error about ObjC ARRAY. Should I get bleeding edge or current 0.14 CVS? Thanks! -- Brian Mastenbrook http://www.iscblog.info/ http://www.cs.indiana.edu/~bmastenb/

2 2

[mcclim-devel] Freetype for SBCL
by Brian Mastenbrook 09 Jun '05

09 Jun '05

Hello, Since I'm under the impression that code in the Experimental directory is, well, experimental, I've committed a version of the experimental freetype bindings which works on SBCL. I've optimized away the %SAP-ALIEN problems, and the end product is reasonably usable. It's a bit laggy until the glyph cache warms up, but after that it's just fine. Here's a gratuitous screenshot: http://www.unmutual.info/images/slidemacs-big.png I'm pretty sure that this doesn't work on CMUCL anymore, as CMUCL has slightly different names (DEF-ALIEN-TYPE and -ROUTINE), but a little macrology should restore CMUCL workingness if anybody's interested in giving it a try. In order to use this under SBCL, you must use the .asd file, as there's a little ASDF muckery in there to work around the fact that compiling the freetype-ffi file currently stuffs up in SBCL. After the rest of the code finishes compiling, you should see a message about setting mcclim-freetype:*freetype-font-path* - set this to a directory containing the Bitstream Vera fonts, and don't forget the final / on the pathname or else merge-pathnames is not going to be happy. Comments and patches welcome, especially from CMUCL users. -- Brian Mastenbrook "God made the natural numbers; http://www.iscblog.info/ all else is the work of man." chandler(a)unmutual.info -- Leopold Kroneker

3 2

[mcclim-devel] First native pane type in Beagle
by Duncan Rose 05 Jun '05

05 Jun '05

For anybody interested I've put a couple of screen shots of the Listener with a first-pass at native scroll bars up on my webspace: http://www.robotcat.demon.co.uk/ I realize there are few people able to run Beagle at the moment unfortunately :-( As an aside, if anybody can give me a couple of pointers as to how exactly the 'scroller-pane' decides whether to lay the vertical scroll bar out on the left side or the right side I'd be grateful. I can't see anything that obviously controls this. On a final note, does McCLIM take any notice of key event object's :key-name as opposed to :key-character? Is there a way to set up a command (for Goatee, say) that makes :LEFT behave the same as ctrl-b? Thanks, -Duncan

1 0

[mcclim-devel] New fixes for package lock errors in listener compilation/load with CMUCL 19
by Paolo Amoroso 05 Jun '05

05 Jun '05

The fix I suggested for this resolved CLIM Listener bug: Package lock errors when compiling/loading with CMUCL 19 or later http://mcclim.cliki.net/Bug#listener-cmucl-package-lock was shortsighted. I conditionalized package locking on feature cmu19a: #+cmu19a (progn (setf (ext:package-definition-lock (find-package "DEBUG")) nil) (setf (ext:package-definition-lock (find-package "COMMON-LISP")) nil) (setf (ext:package-definition-lock (find-package "EXT")) nil)) But compilation and loading of the Listener fail again with CMUCL Snapshot (19B) 2005-06, which is the first in the 19b series. A short term fix may be to conditionalize on just cmu19. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

1 1

[mcclim-devel] ASDF building problems on CMUCL
by Christian Lynbech 05 Jun '05

05 Jun '05

It seems as if there are some problems with ASDF module specification for scigraph in current versions of McCLIM CVS. When I try to build as per the instructions (using cmucl), the build stalls after loading the module specs and it does not matter whether I load system.lisp or mcclim.asd. A stacktrace is show below. Outcommenting the definition of the scigraph system removes the problem and McCLIM builds and runs without problems. It would thus appear that the scigraph system triggers an infinite loop somewhere in ASDF. The problem appears with todays CVS and the version labelled as McCLIM-0-9-1; it appears that the version McCLIM-0-9 only works with mkdefsystem enabled lisps. I am running on a Debian system with the following versions: ii common-lisp-controller 4.14 ii cmucl 19a-release-20040728-11 ii cl-asdf 1.86-4 0] backtrace 0: (ASDF::PARSE-COMPONENT-FORM NIL (:MODULE "scigraph" :PATHNAME #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/" :DEPENDS-ON ...)) 1: (ASDF::PARSE-COMPONENT-FORM 2 NIL (:MODULE "scigraph" :PATHNAME #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/" :DEPENDS-ON ...))[:EXTERNAL] 2: (LISP::SLOLOAD #<Stream for file "/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/mcclim.asd">) 3: (LISP::INTERNAL-LOAD #p"mcclim.asd" #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/mcclim.asd" :ERROR :SOURCE) 4: (LISP::INTERNAL-LOAD #p"mcclim.asd" #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/mcclim.asd" :ERROR NIL) 5: (LOAD "mcclim.asd" :VERBOSE NIL :PRINT ...) 6: (EXTENSIONS:INTERACTIVE-EVAL (LOAD "mcclim.asd")) 7: (LISP::%TOP-LEVEL) 8: ((LABELS LISP::RESTART-LISP EXTENSIONS:SAVE-LISP)) ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic(a)hal.com (Michael A. Petonic)

5 5

[mcclim-devel] cvs access
by idurand＠labri.fr 05 Jun '05

05 Jun '05

Trying to get a cvs version of mcclim I get Ordinateur-de-IRENE-DURAND:~ idurand$ cvs -z3 -d :pserver:anonymous:anonymous@common-lisp.net:/project/mcclim/cvsroot co mcclim ? mcclim/cvsroot ? mcclim/Backends/CLX/clim-extensions.dfsl ? mcclim/Backends/CLX/frame-manager.dfsl ? mcclim/Backends/CLX/graft.dfsl ? mcclim/Backends/CLX/image.dfsl ? mcclim/Backends/CLX/keysymdef.dfsl ? mcclim/Backends/CLX/keysyms-common.dfsl ? mcclim/Backends/CLX/keysyms.dfsl ? mcclim/Backends/CLX/medium.dfsl ? mcclim/Backends/CLX/package.dfsl ? mcclim/Backends/CLX/port.dfsl ? mcclim/examples/franz ? mcclim/looks/pixie.dfsl cvs server: existing repository /project/mcclim/cvsroot/McCLIM does not match /project/mcclim/cvsroot/mcclim cvs server: ignoring module mcclim What am I doing wrong? Irene ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

1 2

[mcclim-devel] Re: Bug#310640: cl-asdf: cl-mcclim package made unusable by the latest asdf package
by Peter Van Eynde 04 Jun '05

04 Jun '05

Milan Zamazal wrote: > It seems the bug is still present in cl-asdf 1.86-5: ... It seems the problem is McClim (!) > debugger invoked on a DUPLICATE-NAMES in thread 31186: > Condition DUPLICATE-NAMES was signalled. ... > (:MODULE "scigraph" If you reproduce the problem and do: 0] (loop for (a name c d) in (nth 9 (SB-DEBUG:ARG 1)) do (format t "~&~A~%" name)) package <- NAME package feature-case macros tv draw present extensions wholine export package <- NAME package AGAIN! copy dump duplicate random menu-tools basic-classes draw mouse color basic-graph graph-mixins axis moving-object symbol graph-data legend graph-classes present annotations annotated-graph contour equation popup-accept popup-accept-methods duplicate-methods frame export demo-frame So the problem is with McCLIM, or better with the defsystem macro in McCLIM that defines system with duplicate names: 0] (in-package :mcclim.system) #<PACKAGE "MCCLIM.SYSTEM"> 0] (cl:macroexpand '(clim-defsystem (:scigraph :depends-on (:clim :clim-looks)) ;; The DWIM part of SCIGRAPH "Apps/Scigraph/dwim/package" "Apps/Scigraph/scigraph/package" )) (PROGN (DEFSYSTEM :SCIGRAPH :DEPENDS-ON (:CLIM :CLIM-LOOKS) :SERIAL T :COMPONENTS ((:FILE "package" :PATHNAME #P"/home/pvaneynd/fakeroot/McCLIM/Apps/Scigraph/dwim/package.lisp") (:FILE "package" :PATHNAME #P"/home/pvaneynd/fakeroot/McCLIM/Apps/Scigraph/scigraph/package.lisp")))) T As asdf refers internally to subsystems only by name this is "a bad thing" (TM). Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|

1 0

[mcclim-devel] DESCRIBE-OBJECT methods
by rpgoldman＠real-time.com 02 Jun '05

02 Jun '05

One thing that's made the built-in describe less useful for me than it might be is that it seems to bottom out at CONSes. So if I have data structures that contain a CONS (e.g., a list-valued slot), I get tantalizingly close to seeing what I want to see, but then can't drill down any further. [I suppose I could try invoking Clouseau...] I believe it would be relatively straightforward to add a new describe-object method that would look at the contents of a CONS, but I'm concerned that this might be risky in the case of objects that are very large. PPRINT, of course, gets around this by using *print-length*, and I suppose I could also, but that seems like an abuse of a built in. For lack of a better, here's what I came up with (inserted into DESCRIBE.LISP): (defmethod describe-object ((thing list) stream) (format stream "~S is a list~%" thing) (loop for x in thing for i from 0 until (and *print-length* (= i *print-length*)) do (describe-object x stream) (terpri stream) finally (when (< (1+ i) (length thing)) (format stream "...~%")))) I don't think that the above is really right, but perhaps it's a step in the right direction? Can anyone refine it? Also, when I was editing describe.lisp, it confused my emacs interface a bunch, because the mode line lists specifies COMMON-LISP as the package, but the in-package form says CLIM-LISP. The Allegro Emacs-lisp interface ignores the latter in favor of the former! Best, R

3 4

[mcclim-devel] compose-space question
by Robert P. Goldman 20 May '05

20 May '05

I have been finding that my application-panes look to be off in width by the width of their scroll-bars. When I look at the COMPOSE-SPACE definitions (these are a little overwhelming for a novice like me) it looks like the effective method for compose-space for an application-pane is this one: (defmethod compose-space ((pane clim-stream-pane) &key width height) (let ((w (bounding-rectangle-width (stream-output-history pane))) (h (bounding-rectangle-height (stream-output-history pane)))) (make-space-requirement :width w :min-width w :max-width +fill+ :height h :min-height h :max-height +fill+))) This one doesn't have the potential for adding the width of scrollbars. Does this look like the right fix? (defmethod compose-space :around ((pane clim-stream-pane) &key width height) (let ((inner-width (call-next-method))) (with-slots (scroll-bars) pane (cond ((null scroll-bars) inner-width) ((eq scroll-bars :vertical) (space-requirement+ inner-width (compose-space (slot-value (pane-scroller pane) 'vscrollbar)))) ((eq scroll-bars :horizontal) (space-requirement+ inner-width (compose-space (slot-value (pane-scroller pane) 'hscrollbar)))) (t (space-requirement+ inner-width (space-requirement+ (compose-space (slot-value (pane-scroller pane) 'vscrollbar)) (compose-space (slot-value (pane-scroller pane) 'hscrollbar)))))))))

4 3