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

[mcclim-devel] question about curves and formatting graphs
by rpgoldman＠real-time.com 10 Apr '06

10 Apr '06

If one wanted to draw curvy lines in McCLIM, is there any way of doing this? I had assumed, foolish me, that this could be done using Bezier curves, but now I see that those were an Allegro extension to the standard, and not part of CLIM 2.0.... I'm not much of a graphics person, and don't understand X very well, so I was wondering --- is there anything about X itself that makes drawing curved lines particularly difficult? Also, has anyone been thinking about the possibility of dynamic graphs? I.e., graphs where one might want to enter leaves? Or the possibility of having a fixed graph where a user might move the nodes around to make the graph more readable. CLIM doesn't have any sort of "smart link" object that would support this, does it? Thanks, Robert

4 11

[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] 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

[mcclim-devel] patch for graph-formatting.lisp
by rpgoldman＠real-time.com 13 May '05

13 May '05

I believe that there is a bug in graph-formatting.lisp where a graph, if it gets > 10 deep, will cause adjust-array to be called to create new array entries initialized to nil instead of to zero, meaning that comparisons cause a crash. Here's a patch. Will someone familiar with this code please vet it and apply it if appropriate? Thanks, Robert Index: graph-formatting.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/graph-formatting.lisp,v retrieving revision 1.14 diff -u -F^(def -r1.14 graph-formatting.lisp --- graph-formatting.lisp 23 Apr 2005 20:02:01 -0000 1.14 +++ graph-formatting.lisp 13 May 2005 02:33:33 -0000 @@ -312,7 +312,7 @@ (defmethod layout-graph-nodes ((graph-ou (walk (node depth) (unless (graph-node-minor-size node) (when (>= depth (length generation-sizes)) - (setf generation-sizes (adjust-array generation-sizes (ceiling (* depth 1.2))))) + (setf generation-sizes (adjust-array generation-sizes (ceiling (* depth 1.2) :initial-element 0)))) (setf (aref generation-sizes depth) (max (aref generation-sizes depth) (node-major-dimension node))) (setf (graph-node-minor-size node) 0)

1 0

[mcclim-devel] question about layout-graph-nodes
by rpgoldman＠real-time.com 13 May '05

13 May '05

I managed to persuade format-graph-from-roots to crash, and it did so inside the WALK local function in layout-graph-nodes. Alas, this isn't too easy to debug, even with my beloved Allegro, because of all of the closures.... But I was wondering about the following piece of layout-graph-nodes. Perhaps I'm missing something, but there seems to be a call to MAX whose return is never harvested. (labels (... (walk (node depth) (unless (graph-node-minor-size node) (when (>= depth (length generation-sizes)) (setf generation-sizes (adjust-array generation-sizes (ceiling (* depth 1.2))))) (setf (aref generation-sizes depth) (max (aref generation-sizes depth) (node-major-dimension node))) (setf (graph-node-minor-size node) 0) ** (max (node-minor-dimension node) (setf (graph-node-minor-size node) (let ((sum 0) (n 0)) (map nil (lambda (child) (let ((x (walk child (+ depth 1)))) (when x (incf sum x) (incf n)))) (graph-node-children node)) (+ sum (* (max 0 (- n 1)) within-generation-separation)))))))) (map nil #'(lambda (x) (walk x 0)) root-nodes) ...) I confess that I am not a big user of MAP, nor do I fully grok what's going on here, but it seems like the MAX on the starred line does not serve any purpose. That suggests to me that the code mgiht be garbled somehow.... Any suggestions? For reference, I attach the full defmethod at the end of the message. BTW, the error occurring somehwere in here is a 'NIL' is not of expected type REAL error, which suggests to me that one of the comparisons has gone bad... I think it's because at generation 10, the array gets resized, and the initial value is NIL instead of 0... Thanks, R (defmethod layout-graph-nodes ((graph-output-record tree-graph-output-record) stream arc-drawer arc-drawing-options) ;; work in progress! --GB 2002-08-14 (declare (ignore arc-drawer arc-drawing-options)) (with-slots (orientation center-nodes generation-separation within-generation-separation root-nodes) graph-output-record (check-type orientation (member :horizontal :vertical)) ;xxx move to init.-inst. ;; here major dimension is the dimension in which we grow the ;; tree. (let ((within-generation-separation (parse-space stream within-generation-separation (case orientation (:horizontal :vertical) (:vertical :horizontal)))) (generation-separation (parse-space stream generation-separation orientation))) (let ((generation-sizes (make-array 10 :adjustable t :initial-element 0))) (labels ((node-major-dimension (node) (if (eq orientation :vertical) (bounding-rectangle-height node) (bounding-rectangle-width node))) (node-minor-dimension (node) (if (eq orientation :vertical) (bounding-rectangle-width node) (bounding-rectangle-height node))) (walk (node depth) (unless (graph-node-minor-size node) (when (>= depth (length generation-sizes)) (setf generation-sizes (adjust-array generation-sizes (ceiling (* depth 1.2))))) (setf (aref generation-sizes depth) (max (aref generation-sizes depth) (node-major-dimension node))) (setf (graph-node-minor-size node) 0) (max (node-minor-dimension node) (setf (graph-node-minor-size node) (let ((sum 0) (n 0)) (map nil (lambda (child) (let ((x (walk child (+ depth 1)))) (when x (incf sum x) (incf n)))) (graph-node-children node)) (+ sum (* (max 0 (- n 1)) within-generation-separation)))))))) (map nil #'(lambda (x) (walk x 0)) root-nodes) (let ((hash (make-hash-table :test #'eq))) (labels ((foo (node majors u0 v0) (cond ((gethash node hash) v0) (t (setf (gethash node hash) t) (let ((d (- (node-minor-dimension node) (graph-node-minor-size node)))) (let ((v (+ v0 (/ (min 0 d) -2)))) (setf (output-record-position node) (if (eq orientation :vertical) (transform-position (medium-transformation stream) v u0) (transform-position (medium-transformation stream) u0 v))) (add-output-record node graph-output-record)) ;; (let ((u (+ u0 (car majors))) (v (+ v0 (max 0 (/ d 2)))) (firstp t)) (map nil (lambda (q) (unless (gethash q hash) (if firstp (setf firstp nil) (incf v within-generation-separation)) (setf v (foo q (cdr majors) u v)))) (graph-node-children node))) ;; (+ v0 (max (node-minor-dimension node) (graph-node-minor-size node)))))))) ;; (let ((majors (mapcar (lambda (x) (+ x generation-separation)) (coerce generation-sizes 'list)))) (let ((u (+ 0 (car majors))) (v 0)) (maplist (lambda (rest) (setf v (foo (car rest) majors u v)) (unless (null rest) (incf v within-generation-separation))) (graph-root-nodes graph-output-record)))))))))))

1 0

Re: [mcclim-devel] question about CLIM spec
by C Y 11 May '05

11 May '05

Should we at least keep a backup in case something unforseen happens to his machine? CY --- Robert Strandh <strandh(a)labri.fr> wrote: > C Y writes: > > > > Wasn't the plan to move the annotated spec to common-lisp.net? Or > did > > I miss an update on that? > > I discussed that with Gilbert a few days ago, and now it seems that > he > prefers keeping it on his home machine. > > -- > Robert Strandh > > --------------------------------------------------------------------- > Greenspun's Tenth Rule of Programming: any sufficiently complicated C > or Fortran program contains an ad hoc informally-specified bug-ridden > slow implementation of half of Common Lisp. > --------------------------------------------------------------------- > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

2 1

Re: [mcclim-devel] question about CLIM spec
by C Y 11 May '05

11 May '05

Wasn't the plan to move the annotated spec to common-lisp.net? Or did I miss an update on that? CY --- "Robert P. Goldman" <rpgoldman(a)sift.info> wrote: > >>>>> "RS" == Robert Strandh <strandh(a)labri.fr> writes: > > RS> rpgoldman(a)real-time.com writes: > >> > >> Question: have I misread the specification, or is this a > deficiency > >> in it? > > RS> The latter is very likely. You can do us a favor and go to > the > RS> annotatable spec at > > RS> http://bauhh.dyndns.org:8000/clim-spec/index.html > > RS> and enter your comments at the appropriate place. > > OK, I had a preliminary whack at it. I hope the comments are useful. > I am hardly an expert on this subject! > > R > _______________________________________________ > mcclim-devel mailing list > mcclim-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

2 1

[mcclim-devel] question about CLIM spec
by rpgoldman＠real-time.com 11 May '05

11 May '05

I was looking over Christophe's dendrogram sample code, and was surprised to find the following in the comments: "...this one is technically non-conforming, in that FORMAT-GRAPH-FROM-ROOTS isn't specified as &KEY &ALLOW-OTHER-KEYS" I went back to the spec and yes, AFAICT, the format-graph-from-roots function is specified as NOT being extendible with new keyword arguments. With all due respect, this seems kooky, since FORMAT-GRAPH-FROM-ROOTS' interface seems poorly structured to do much of anything beyond trees or graphs that are essentially tree-like. The interface seems poor if you want to have edges of different flavors, if you want to control the assignment of depths, etc. Now, of course, you can do a pretty arbitrary amount of customization by developing new graph-output-records. BUT... the spec as written (to the best of my understanding) doesn't provide any way to customize these new output record classes with initargs. Not only doesn't format-graph-from-roots as specified allow for extending its argument set, it also doesn't specify (again, as far as I can tell), how to pass initargs to the new class. The McCLIM implementation takes what seems to me to be a very sensible approach of passing extra keyword arguments from format-graph-from-roots into the make-instance for the GRAPH-OUTPUT-RECORD, but this is an extension to the specification. Question: have I misread the specification, or is this a deficiency in it? Cheers, Robert

4 4

[mcclim-devel] possible buglet in highlighting shapes
by rpgoldman＠real-time.com 10 May '05

10 May '05

I have built a grapher-based tool, that allows me to distinguish between multiple types of node by using shapes. When I highlight rectangular nodes, all is well. But I have "roundtangle" nodes, and when I pass the mouse over them, instead of seeing a box around them, or a highlight outline around the roundtangle, McCLIM gives me THREE rectangles, one around the body of the node, and one each around the semi-circles on the end. Actually, even the rectangle highlighting seems to me a little odd, since the highlight outline is drawn INSIDE the node, instead of around its outline. Here's the code that draws the nodes: (defun draw-taems-node (object stream) (declare (special normal-ink text-style)) (with-drawing-options (stream :ink normal-ink :text-style text-style) (with-output-as-presentation (stream object 'taems-node) (if (typep object 'taems:tmethod) (surrounding-output-with-border (stream :shape :rectangle) (format stream "~D: ~A" (musliner:name object) (taems:taems-name object))) (surrounding-output-with-border (stream :shape :oval) (format stream "~D: ~A" (musliner:name object) (taems:taems-name object))))))) Alas, I am too stupid to figure out how to grab a screendump from X to illustrate this; any suggestions? I wasn't sure how to get xwd to wait until I had a node highlighted before writing its output.... Thanks, R

12 38

[mcclim-devel] new graph type: first drawf
by rpgoldman＠real-time.com 06 May '05

06 May '05

I have developed a tentative first version of a new graph type, which is a tree with cross-edges. I.e., you have a graph which is basically a tree, but where you are allowed to have cross edges. The cross edges are NOT the same as graph edges, and in particular, don't cause additions to the PARENT/CHILD relationships, nor (for this reason) do they cause depths to be incremented. Note that these cross-edges do NOT have to be only one one level of the tree --- they can cross levels. To build such a graph you need to add two more arguments to format-graph-from-roots: :CROSS-ARC-DRAWER a function that takes all the arguments accepted by a normal arc-drawer, but also an edge-type keyword argument, which it is free to ignore. :CROSS-ARC-PRODUCER a function that takes a graph-node as argument, like inferior-producer, but that returns two values: a list of destination nodes and (optionally) a list of type-designators, that can be passed to the cross-arc-drawer, as the value of the :edge-type keyword argument. I have posted the source for this to the following URL, hoping that it will attract comments and suggestions: http://rpgoldman.real-time.com/lisp/tree-with-cross-edges.lisp I'd love to see this integrated into McCLIM some day! KNOWN BUGS: 1. Currently only works on :horizontal orientation (I don't have the arc routing for vertical yet). 2. Only draws straight lines for cross edges. It would be nice if the cross edges would swoop around intervening nodes, but I haven't read enough of the CLIM spec to figure out how to do this yet. 3. If you have a depth-bounded tree, probably something very ugly will happen! I'll try to assemble some screendumps and post them, but for now it's weekend... Best, R

1 0

[mcclim-devel] Problems in reading with :timeout
by Tomi K Neste 06 May '05

06 May '05

Oops.. accidently sent this to rpgoldman only :-| Just tried on SBCL with recent McCLIM and :timeout 0 works fine >0 values still seem to be blocking forever. Looks like clim-internals:stream-input-wait keeps continuously calling clim-internals:event-queue-listen-or-wait with wrong TIMEOUT. Or maybe not, it's all (still) bit over my head The :timeout 0 => NIL still seems to a problem on CMUCL, but that's on a few months old version of McCLIM, so maybe it's fixed and irrelevant by now anyway. I really should update my CMUCL stuff on that laptop... I'm trying to figure out how to do some simple animation, like a clock or process browser that should keep on updating every few seconds. So I thought the way to go would be specializing the READ-COMMAND or READ-FRAME-COMMAND and use the :timeout where approriate. I also thought about using different thread for the pane updating, but I'm not sure if that would be a smart thing to do. So I'm wondering if there's a canonical way to accomplish something like that, some sources perhaps? BTW, big thanks to all McCLIM developers, fascinating stuff :-)

2 2

Re: [mcclim-devel] resizeable panes
by Andy Hefner 04 May '05

04 May '05

Off the top of my head, something like this within your layout should world: (vertically () top-pane (make-pane 'clim-extensions:box-adjuster-gadget) bottom-pane) The idea is that you insert it a layout between the panes you want it to resize. This should work fine for a horizontal layout also, the box-adjuster-gadget takes its orientation from its parent. On 5/1/05, rpgoldman(a)real-time.com <rpgoldman(a)real-time.com> wrote: > Is there an example of the use of the box-adjuster-gadget anywhere? > Sorry to be lame. I couldn't find one anywhere in the stuff that > comes with McCLIM (or I did something wrong with find...). > > Thanks, > R >

1 0

[mcclim-devel] Problems in reading with :timeout
by Tomi K Neste 04 May '05

04 May '05

I'm having some newb confusion about the timeout value in stream input functions, (read-gesture ...) etc. (read-gesture :timeout 0) always just returns NIL, while timeout values >0 don't seem to have any effect at all. For example, in the Listener (read-gesture :timeout 1) keeps blocking until some gesture is given. Another source of confusion is the :input-wait-handler. From reading the spec I got the idea that it should be called "continously" when there isn't any input in the given stream, but it looks like the function is never executed. Are these real problems or am I just missing something obvious?

4 3

[mcclim-devel] re: Black art
by C Y 03 May '05

03 May '05

>> And a graphical CLIM interface builder could possibly go >> a long way towards helping people create "correct" code or at >> least avoid errors. > > I built one of these more than 10 years ago. I'll dust off the > code and post it to the list in the next few days. (It probably > needs updating since I haven't looked at it in at least 5 years.) In case I forgot to say it elsewhere, drool... :-) CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [mcclim-devel] function undefined when trying to access the example page?
by Jason Wang 02 May '05

02 May '05

i'm sorry.. i sent to the wrong mailing-list :|.. i'll be careful from now on :D -- www.programer.name - my own personal blog : )

1 0

Re: [mcclim-devel] Scigraph
by C Y 02 May '05

02 May '05

--- Duncan Rose <duncan(a)robotcat.demon.co.uk> wrote: > > It builds fine for me under OpenMCL. Can you be more specific > regarding the errors you're seeing? > > The only external dependency I can think of in the build is CLX. Do > you have it installed (this shouldn't matter for building most of > McCLIM, only when building the back end I think). Here we go (core with McCLIM built and loaded): CMU Common Lisp 19a, running on gentoo With core: /usr/local/lib/cmucl/lib/lisp.core Dumped on: Sun, 2005-05-01 22:50:16-04:00 on gentoo See <http://www.cons.org/cmucl/> for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 CLX X Library MIT R5.02 Gray Streams Protocol Support * (asdf:oos 'asdf:load-op :scigraph) [snip] ; Compiling DEFMETHOD ZOOM-OUT (GRAPH-ZOOM-MIXIN T): ; Byte Compiling Top-Level Form: ; /home/user/mcclimtoplevel/mcclim/Apps/Scigraph/scigraph/moving-object.x86f written. ; Compilation finished in 0:00:04. ; Loading #p"/home/user/mcclimtoplevel/mcclim/Apps/Scigraph/scigraph/moving-object.x86f". ; [GC threshold exceeded with 63,889,944 bytes in use. Commencing GC.] ; [GC completed with 56,906,880 bytes retained and 6,983,064 bytes freed.] ; [GC will next occur when at least 68,906,880 bytes are in use.] Condition COMMAND-TABLE-NOT-FOUND was signalled. [Condition of type COMMAND-TABLE-NOT-FOUND] Restarts: 0: [CONTINUE] Return NIL from load of #p"/home/user/mcclimtoplevel/mcclim/Apps/Scigraph/scigraph/moving-object.x86f". 1: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {5A60D8FD}> on #<ASDF:CL-SOURCE-FILE "moving-object" {285FCC25}>. 2: [ACCEPT ] Continue, treating #<ASDF:LOAD-OP NIL {5A60D8FD}> on #<ASDF:CL-SOURCE-FILE "moving-object" {285FCC25}> as having been successful. 3: [ABORT ] Return to Top-Level. Debug (type H for help) ; [GC threshold exceeded with 68,917,416 bytes in use. Commencing GC.] ; [GC completed with 55,934,776 bytes retained and 12,982,640 bytes freed.] ; [GC will next occur when at least 67,934,776 bytes are in use.] (CLIM:FIND-COMMAND-TABLE :GRAPH :ERRORP T) Source: ; File: /home/user/mcclimtoplevel/mcclim/commands.lisp (ERROR 'COMMAND-TABLE-NOT-FOUND) 0] __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

[mcclim-devel] Scigraph
by C Y 02 May '05

02 May '05

Hi all. I've just been trying to build scigraph with the latest cvs McCLIM and cmucl 19a, and I've been hitting a variety of problems. Has anybody else seen any trouble with recent cvs McCLIM? CY __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

3 2

[mcclim-devel] interactor-pane scrolls off the bottom
by tim＠tenkan.org 02 May '05

02 May '05

If you say (define-application-frame foo () () (:pane (make-pane 'interactor-pane :width 400 :height 300))) (clim:run-frame-top-level (clim:make-application-frame 'foo)) You get a window. Hit RET a few times in that window, and the prompt will scroll off the bottom of it, never to return. Is it meant to work that way? -- -Tim

4 6

Re: [mcclim-devel] Axiom
by C Y 02 May '05

02 May '05

Here is a screenshot: http://mathshield.sourceforge.net/axiomstartuppage.png I'm guessing this is well withing McCLIM's abilities, at least to build a mockup of. I believe bold text and buttons are clickable. CY P.S. - sorry if this is a dupe, I don't think my other response made it. On Thursday 28 April 2005 03:03 pm, Andy Hefner wrote: > What kind of browser? > > On 4/28/05, C Y <smustudent1(a)yahoo.com> wrote: > > "I've looked at McClim which is a path I'd dearly love to take > > but so far I've not gotten it to work. If someone could > > reproduce the first page of the browser (a few buttons, an > > image) in McClim that might be enough to get me over the > > hurdle. A pure lisp solution is preferred." __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

[mcclim-devel] Command translator question
by Duncan Rose 01 May '05

01 May '05

I'm trying to define a presentation command translator which will invoke 'describe presentation' on specific types. Unfortunately it doesn't work (or at least, works in a way that I'm not expecting so if it's working it's not doing what I want ;-) Looking at the translators defined in the Listener and in builtin-commands.lisp hasn't helped. Here's the translator: (define-presentation-to-command-translator port-select-to-command ; name (t ; from-type com-describe ; command-name - maybe com-describe-presentation? global-command-table ; command table containing command :gesture :select ; activate on :select (left-button click) ;; :tester ... :documentation "Invoke the 'describe presentation' command on the selected presentation" :pointer-documentation ((object stream) (format stream "Describe ~A" object)) :menu t ; command should appear in popped-up menus ;; :priority ... :echo nil) ; don't echo the command when it is invoked ;; arglist must be a subset (using string-equal) of: ;; (object presentation context-type frame event window x y) (object) ;; body of translator; returns a list of the arguments to the command ;; named by command-name. (list object)) In case I was providing the wrong 'from-type' I changed it to T (all types, I hope). I've written this using the Beagle back end but it doesn't work for me when run under CLX either... Any suggestions would be appreciated, I'm obviously missing something... I've attached the complete code for context in case it's helpful. -Duncan

6 11