mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[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

[mcclim-devel] commit privs
by duncan＠robotcat.demon.co.uk 16 May '05

16 May '05

I have a number of changes to Beagle to commit; who assigns commit privs for the mcclim repository? -Duncan

3 2

[mcclim-devel] Debugger take III
by Peter Mechlenborg 16 May '05

16 May '05

Hi I have made some new adjustments to the debugger. I would like to get commit access, but until I've been granted that, you can get the modified debugger the usual place: www.daimi.au.dk/~metch/lisp/ Changes: - Added a packages.lisp file for the package. - Added an asd file. You should note that that it currently doesn't depend on swank because I had some troubles making it work. Therefore you have load Slime manually. - Keyboard shortcuts: 0 - 9 chooses the current restart (like Slime). Up and down moves the pointer between the stack frames and local variables. Space opens a stack frame (enter in Slime). Enter starts Clouseau (I finally get the name :-)) on a local variable. The biggest problem now, is that it is slow. I normally use sbcl, but I tried Mcclim on cmucl and it seemed that it was quite a bit faster. I think this has something to do with garbage collection, but that could be way off. Do any of you know what causes the big differences between sbcl cmucl? Bye, and remember to have fun! -- Peter

3 2

[mcclim-devel] Context menu
by Duncan Rose 15 May '05

15 May '05

I think I'm missing something to do with defining commands, and right-click context menus. I have process objects that are presented and a number of commands defined for this type. I assumed (presumably wrongly :-) that these commands would be displayed automatically when the presentation is right-clicked over. An example command definition follows: (define-glimpse-command (com-kill-process :name t :menu nil) ((obj 'ccl::process ; need to generalize this... :prompt "process" :gesture nil)) (clim-sys:destroy-process obj) (com-show-processes)) [aside; I suspect it could be useful to define a PROCESS type in CLIM-SYS] Do commands need to have a specific ':menu' entry to appear? -Duncan

2 1

[mcclim-devel] pathology in updating output with format-graph-from-roots
by rpgoldman＠real-time.com 13 May '05

13 May '05

[discussed on #lisp, to no avail...] If you look at http://rpgoldman.real-time.com/goofy-clim.png you will see what happens when one of my panes runs a display-function that calls format-graph-from-roots inside updating-output. The display does not all get updated, leaving funny gray borders around the active area of two panes. What's interesting is that this pathology affects the interactor pane at the bottom of the layout, as well as the application pane at the top. Before I made the display function for the top pane, the interactor pane used to function correctly. Now it erases its contents after every command, and has the gray border problem. I almost wonder if my adding :incremental-redisplay t to the application frames could have somehow bled over into the options used in initializing the interactor pane.... Finally, even with updating-output, using format-graph-from-roots does not correctly relize that it needs a horizontal scrollbar as well as a vertical one, when it gets a new graph in it. Some partial solutions: 1. Make application-panes with :scrollbars :both. I think this is actually a McCLIM bug. The spec states that the default value for application panes should be T (and it is), but also that T should be the same as :both (which doesn't seem to be an available option, according to the spec). So, somewhere we're treating :both and t differently, but I think they should be the same. 2. Use the bounding rectangle for the graph-output-record that format-graph-from-roots returns to set the :min-height and :min-width of the enclosing window, for example: (defun graph-mdp (stream &optional (mdp (taems-mdp *application-frame*))) (when mdp (let ((normal-ink +foreground-ink+) (arrow-ink *graph-edge-ink*) (text-style *graph-text-style*)) (declare (special normal-ink arrow-ink text-style)) (let* ((graph-output-record (with-drawing-options (stream :text-style text-style) (format-graph-from-roots (list (taems:initial-state mdp)) ;; printer #'draw-mdp-node ;; inferior-producer #'taems:mdp-successors :stream stream :arc-drawer #'clim-internals::arrow-arc-drawer ))) (rect (bounding-rectangle graph-output-record))) (change-space-requirements stream :min-width (bounding-rectangle-width rect) :min-height (bounding-rectangle-height rect)) graph-output-record)))) [this function will be invoked wrapped in updating-output.] That seems to get the scrollbars to be oriented to the right height and width. I know that Andy has said that he doesn't like the idea of having format-graph-from-roots automagically call change-space-requirements, for the reason that it could cause too much wasted computation. As a programmer, though, having a function that is this high-level, but then requires low-level messing with output records and the fairly cryptic and ill-documented change-space-requirements seems very odd. I suspect that my use of change-space-requirements is just plain wrong. My case up above is trivial, because my pane will ONLY have the graph in it; heaven help me if I ever want to stick a graph onto a scrolling output history pane or something... There ought to be (and probably is) some way of saying to the pane "hey, please make room for this big bolus of fresh, piping-hot pixels," but I don't understand the protocol well enough to say what it is... But neither of the above fixes the weird gray stuff, which seems to be some flavor of updating error, and likely too deep in the guts of the system for the likes of me. Any suggestions for how I should start?

2 1

← Newer
1
...
64
65
66
67
68
69
70
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel