mcclim-devel April 2005

mcclim-devel@common-lisp.net

25 participants
35 discussions

[mcclim-devel] error on modifying example code
by Jason Wang 16 Apr '05

16 Apr '05

hi, i just got McClim and see how it works.. and got my first attempt in modifying the example code(s) in trying to get a feel how everything works.. though, what seem to be a simple layout edition turned out crashing my program upon start up (note, the example program calculator is working fine before modification).. i modified the following code snippet: (:layouts (default (with-slots (text-field) *application-frame* (vertically (:width 150 :max-width 500) (setf text-field screen) (horizontally (:height 50) ac ce) (tabling (:grid t) (list one two three four) (list five six seven eight) (list nine zero plus dash) (list multiply divide result)))))) (:top-level (calculator-frame-top-level . nil))) the fifth last line to second last line would be the lines of interest.. i just modified some layout component (or i thought to be), and it gave me the following error: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION CLIM:MOVE-SHEET (2)> when called with arguments (NIL 69 99). [Condition of type SIMPLE-ERROR] Backtrace: 0: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unavailable argument> #<unavailable argument> #<STANDARD-GENERIC-FUNCTION CLIM:MOVE-SHEET (2)> (NIL 69 99)) 1: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unavailable argument> #<unavailable argument> #<STANDARD-GENERIC-FUNCTION CLIM:MOVE-SHEET (2)> (NIL 69 99)) 2: ((SB-PCL::FAST-METHOD CLIM:ALLOCATE-SPACE (CLIM:GRID-PANE T T)) (#(NIL 37) . #()) #<unavailable argument> #<CLIM:GRID-PANE "(Unnamed Pane)" {9D40E49}> 92 132) 3: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::BOX-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) #<unavailable argument> #<CLIM:VRACK-PANE "(Unnamed Pane)" {9D49159}> 92 186) 4: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::BOX-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) #<unavailable argument> #<CLIM:VRACK-PANE "(Unnamed Pane)" {9D50D69}> 92 190) 5: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2.)) #<unavailable argument> #<unavailable argument> #<CLIM-INTERNALS::TOP-LEVEL-SHEET-PANE CLIM-INTERNALS::TOP-LEVEL-SHEET {A305B91}> 92 190) 6: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-FRAME-MANAGER {9A226E9}> #<CLIM-DEMO::CALCULATOR {A35C971}>) 7: ((SB-PCL::FAST-METHOD CLIM:ADOPT-FRAME (CLIM:FRAME-MANAGER CLIM:APPLICATION-FRAME)) (#(NIL 1 15 12) . #()) #<unavailable argument> #<CLIM-CLX::CLX-FRAME-MANAGER {9A226E9}> #<CLIM-DEMO::CALCULATOR {A35C971}>) 8: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-FRAME-MANAGER {9A226E9}> #<CLIM-DEMO::CALCULATOR {A35C971}>) 9: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND (CLIM:APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL #)> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<CLIM-DEMO::CALCULATOR {A35C971}> NIL) 10: (CLIM-DEMO::CALCULATOR) 11: (SB-INT:EVAL-IN-LEXENV (CLIM-DEMO::CALCULATOR) #<NULL-LEXENV>) 12: (SWANK::EVAL-REGION "(clim-demo::calculator) " T) 13: ((LAMBDA NIL)) 14: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) #<unused argument> #<unused argument> #<CLOSURE (LAMBDA NIL) {A35C0B5}>) 15: (SWANK:LISTENER-EVAL "(clim-demo::calculator) ") 16: (SB-INT:EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(clim-demo::calculator) ") #<NULL-LEXENV>) 17: ((LAMBDA NIL)) 18: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {A35BF25}>) 19: ((LAMBDA NIL)) 20: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {A4ACDA1}> #<FUNCTION (LAMBDA NIL) {B45C885}>) 21: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {A4ACDA1}>) 22: ((LAMBDA NIL)) 23: ((LAMBDA NIL)) 24: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {A4ACDA1}> #<CLOSURE (LAMBDA NIL) {9070075}>) 25: (SWANK::REPL-LOOP #<SWANK::CONNECTION {A4ACDA1}>) 26: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA NIL) {9070055}>) 27: ((LAMBDA NIL)) 28: ("foreign function: call_into_lisp") 29: ("foreign function: funcall0") anyone know what's wrong? thanks alot :D -- www.programer.name - my own personal blog : )

1 0

[mcclim-devel] question about format-graph-from-roots
by rpgoldman＠real-time.com 13 Apr '05

13 Apr '05

One suggested patch and one question: 1. Suggested patch: should we modify format-graph-from roots so that the defualt value for :arc-drawer is #'clim-internals::standard-arc-drawer? 2. I have been trying to figure out how to draw a graph that has multiple different kinds of edges. Actually, more specifically, I would like to draw a graph that is "mostly" a tree: it has a tree backbone, and then has some cross-edges. It isn't at all obvious how to do this nicely. There are (at least) two problems: i. I don't see an elegant way to indicate the type of edges. AFAICT, the CLIM spec indicates that we simply generate children, i.e., nodes. We never generate edges, except implicitly. My best guess is that the way to do this is either: a. have the "from" node always have enough information to determine what sort of edge is to be drawn from it to the "to" node. This actually breaks down a little in the case where there can be multiple arcs from one "from" to a single "to." b. create a new data structure (some form of association like a hash table, alist or whatever) that records the type of arc to be drawn, and stuff it into your arc drawer function. ii. More seriously, there doesn't seem any obvious way to say that an arc between "from" and "to" is a cross-edge, and shouldn't increment the depth of "to," rather than being a child edge that DOES increment the depth. Anyone have any suggestions for this? It seems the more difficult problem. Best, R

3 4

[mcclim-devel] typesetting CLIM spec
by rpgoldman＠real-time.com 12 Apr '05

12 Apr '05

Flushed with my success pdf-ulating the manual, I had a run up at the CLIM spec. This seems to work with minimal patching. Simply apply the following, and use pdflatex instead of latex, and you get a version that has bookmarks and hyperlinks in it. One problem: regions.tex seems to require a file named file-normalization.epsi. I was going to translate it into pdf, but found that it's nowhere in the copy of mcclim that I checked out. Is this a bug with the spec LaTex? Best, r Index: clim.tex =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Spec/src/clim.tex,v retrieving revision 1.1 diff -c -r1.1 clim.tex *** clim.tex 11 Dec 2000 06:59:59 -0000 1.1 --- clim.tex 12 Apr 2005 18:54:56 -0000 *************** *** 17,22 **** --- 17,29 ---- {\end{small}\clearpage} \makeatother + %% added to try to make nice bookmarks in PDF... [2005/04/12:rpg] + \ifx\pdfoutput\undefined \csname newcount\endcsname\pdfoutput \fi + \ifcase\pdfoutput \else + \usepackage[pdftex]{hyperref} + \fi + + %\usepackage{times} %% For PDF

1 0

[mcclim-devel] fussy clean-up items
by rpgoldman＠sift.info 07 Apr '05

07 Apr '05

I was just reading over the warnings the ACL compiler gives me, and I noticed that we have three definitions of make-keyword, in presentations.lisp, commands.lisp, and utils.lisp. I don't claim to understand the dueling system definitions (mk-defsystem and asdf) to know which ones should be killed, but any objections to killing a couple? Also, the compiler beefs about double definitions of (METHOD %PRESENTATION-TYPEP (T T T)) and (METHOD %PRESENT (T T T T TEXTUAL-VIEW)) is this due to the eval-when form being evaluated first at compile time, and then at load time? Cheers, r

1 0

[mcclim-devel] question about format-graph-from-roots
by rpgoldman＠sift.info 07 Apr '05

07 Apr '05

Some time ago, Paolo (IIRC) posted a suggested patch to format-graph-from-roots to supply a default for the arc-drawer keyword argument. Again, IIRC, the CLIM spec requires that there be such a default. I was just updating this morning, and noticed that the patch has never been applied. Would someone please apply it (unless there's something wrong with it)? One possible problem is that it ignores the arc-drawing-options keyword, but it still seems better than not having a default at all. Here's the patch: Index: graph-formatting.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/graph-formatting.lisp,v retrieving revision 1.11 diff -u -F^(def -r1.11 graph-formatting.lisp --- graph-formatting.lisp 5 Dec 2004 19:37:52 -0000 1.11 +++ graph-formatting.lisp 7 Apr 2005 14:18:17 -0000 @@ -120,14 +120,20 @@ (define-graph-type :digraph digraph-grap ;;;; Entry (defun format-graph-from-roots (root-objects object-printer inferior-producer - &rest graph-options - &key stream orientation cutoff-depth - merge-duplicates duplicate-key duplicate-test - generation-separation - within-generation-separation - center-nodes arc-drawer arc-drawing-options - graph-type (move-cursor t) - &allow-other-keys) + &rest graph-options + &key stream orientation cutoff-depth + merge-duplicates duplicate-key duplicate-test + generation-separation + within-generation-separation + center-nodes + (arc-drawer + #'(lambda (stream from to from-x from-y to-x to-y) + (declare (ignore from to)) + (draw-line* stream from-x from-y to-x to-y))) + + arc-drawing-options + graph-type (move-cursor t) + &allow-other-keys) (declare (ignore orientation generation-separation within-generation-separation center-nodes)) ;; Mungle some arguments (check-type cutoff-depth (or null integer))

1 0

[mcclim-devel] manual
by rpgoldman＠sift.info 07 Apr '05

07 Apr '05

I wanted to be able to navigate the manual better, so was playing with formats. First I tried latex2html, but found that it doesn't deal well with the new macros for all the definitions (e.g., \defmacro). I wrestled with this for a while, but had no luck. Then I tried pdflatex with the hyperref package. This lets us generate pdf with the bookmarks pane of acrobat accessible, which makes it much easier to mouse around the document. The only problem is that you can't include ps files into pdflatex; you must translate them into pdf first. If that doesn't bother anyone, I could provide patches. For the moment, I'll put the new pdf up on my website for people to look at. http://rpgoldman.real-time.com/papers/mcclim-manual.pdf Cheers, R

4 5

Re: [mcclim-devel] question about behavior of describe
by pw＠snoopy.mv.com 05 Apr '05

05 Apr '05

> > RS> The previous default behavior was removed because not every > RS> application wanted it (it was a rather implementation-oriented > RS> feature). > > Thanks. I understand and sympathize. But is there some easy recipe > to get this behavior back? Either to get it for a whole application > (my biggest use for McCLIM was for debugging tools), or for particular > objects? > You could have your presentation types subclass a presentation type for which you have a command, say com-describe-object, and then have a presentation translator (DEFINE-PRESENTATION-TO-COMMAND-TRANSLATOR) on the superclass and middle button (:describe gesture) to invoke it. Paul

4 3

[mcclim-devel] question about behavior of describe
by rpgoldman＠sift.info 05 Apr '05

05 Apr '05

In the old days, I was able to click on an object that I had displayed in a McCLIM application frame and describe it (using "describe presentation"?). Now this isn't available any more. Now when I use the right mouse menu, I see "Describe," but I have not been able to persuade it to describe the things I have presented. For that matter, it doesn't really do anything even on numbers. I realize that this is probably a very dumb question, but is there some primer somewhere on how to make this do something nice with my presentations? Thanks, R

2 2

[mcclim-devel] demos problem
by George Tourtellot 04 Apr '05

04 Apr '05

Hello, I'm just starting out with McCLIM. I have CMUCL 19a installed, and ASDF installed, and have followed instructions (using ASDF commands) in file INSTALL.CMU. All seems to be working properly until I actually try running a demo. For example, I do/get: ------------------- (clim-demo::run-test 'goatee::goatee-test) Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: NIL is not of type (MOD 536870911) Error flushed ... (menutest::menutest) Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: NIL is not of type (MOD 536870911) Error flushed ... ------------------ do you know why this happens? how can I get demos to work? thanks a lot, George __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

[mcclim-devel] How to open a frame opened with OPEN-WINDOW-STREAM
by Paolo Amoroso 03 Apr '05

03 Apr '05

I would like to simulate a modal dialog, contained in its own window, via an ACCEPTING-VALUES inside a frame opened with OPEN-WINDOW-STREAM. I use code like this: (in-package :clim-user) (define-application-frame window-stream () () (:menu-bar t) (:panes (commands :interactor)) (:layouts (default commands))) (defun show-dialog (stream) (let (integer string) (restart-case (accepting-values (stream) (setq integer (accept 'integer :stream stream :prompt "Gimme an integer ")) (terpri stream) (setq string (accept 'string :stream stream :prompt "Gimme a string ")) (terpri stream)) (abort () nil)) (values integer string))) (define-window-stream-command (com-dialog :menu t :name t) () (let ((stream (open-window-stream))) (unwind-protect (multiple-value-bind (integer string) (show-dialog stream) (format t "~&You entered ~D and ~A~%" integer string)) (when (open-stream-p stream) (frame-exit (pane-frame stream)) (close stream))))) (define-window-stream-command (com-quit :menu t :name t) () (frame-exit *application-frame*)) This mostly works, but the CLIM frame opened with OPEN-WINDOW-STREAM is not closed. I tried using only CLOSE in COM-DIALOG, but without success. How can I close that window? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel April 2005