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

[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

[mcclim-devel] A tough day for me and McCLIM
by rpgoldman＠sift.info 03 Apr '05

03 Apr '05

I was just testing out the inspector, and was able to reliably cause it to blow up. CL-USER(168): (clouseau:inspector *taems-model* :new-process t) #<MULTIPROCESSING:PROCESS Inspector Clouseau: #<TAEMS-MODEL @ #x72023142> @ #x72f7cd42> ...crashes with the followign error: Error: Attempt to access the plist field of #<TAEMS-MODEL @ #x72023142> which is not a symbol. [condition type: SIMPLE-ERROR] Restart actions (select using :continue): 0: Return to application command loop 1: Abort entirely from this process. [Current process: Inspector Clouseau: *TAEMS-MODEL*] [1] CL-USER(1): CL-USER(169): (clouseau:inspector '*taems-model* :new-process t) #<MULTIPROCESSING:PROCESS Inspector Clouseau: *TAEMS-MODEL* @ #x728a4da2> This works ok (presumably because it's a symbol it has a property list?), but when I click on the value cell of the *taems-model* variable, Clouseau blows up with the same error. The proximate cause seems to be PRINT-DOCUMENTATION, which pulls the documentation and then tries to print it, as can be seen in this error: CL-USER(171): (documentation *taems-model* t) Error: Attempt to access the plist field of #<TAEMS-MODEL @ #x72023142> which is not a symbol. [condition type: SIMPLE-ERROR] Restart actions (select using :continue): 0: Return to Top Level (an "abort" restart). 1: Abort entirely from this process. Does this mean that ACL is not doing the Right Thing with the documentation function? Or is CLOUSEAU wrong to assume that everything will have documentation? Seems like documentation might not be defined on objects, if I read the CLHS correctly. The following change to PRINT-DOCUMENTATION seems to fix my problem. Not sure how right it is, though. (defun print-documentation (object pane) "Print OBJECT's documentation, if any, to PANE" (when (catch 'no-docs (handler-bind ((warning #'muffle-warning) (error #'(lambda (c) (declare (ignore c)) (throw 'no-docs nil)))) (documentation object t))) (with-heading-style (pane) (format pane "~&Documentation: ")) (princ (documentation object t) pane)))

2 3

Re: [mcclim-devel] sb-bsd-sockets
by Boris Tschirschwitz 03 Apr '05

03 Apr '05

Hi. Thanks for all the help. It turns out that Brian's suggestion to modify mcclim.asd takes care of getting rid of clx. Boris. PS: Of course, climacs still depends on clx Brian Mastenbrook wrote: > > On Mar 30, 2005, at 2:10 PM, Boris Tschirschwitz wrote: > >> Hi. >> >> I am trying to use McCLIM with openmcl. >> When compiling the beagle backend I get the error message that >> sb-bsd-sockets can't be found, apparently clx depends on it and >> mcclim depends on clx, even with beagle. >> Making sb-bsd-sockets from sbcl-contrib known to asdf helps until >> sb-bsd-sockets wants sb-grovel and eventually sb-ext. This one I >> can't find on sbcl. >> >> Am I really supposed to use all these SBCL packages? >> If so, where do I get the sb-ext? >> >> Thanks, >> Boris. >> > > Hi Boris, > > You should edit the file mcclim.asd in the root of the McCLIM source > tree to use the beagle backend instead of the CLX backend. By default > only the CLX backend is enabled because the beagle backend is still a > bit buggy. Search for clim-looks in the file and comment out the line > that sets up the clx backend as a dependancy, and uncomment the one > which sets up the beagle backend. > -- > Brian Mastenbrook > brian(a)mastenbrook.net > http://www.iscblog.info/ > > >

2 2

[mcclim-devel] Better defaults for CLX backend
by Christophe Rhodes 02 Apr '05

02 Apr '05

Hi, Attached are a diff and a new file to implement better defaults for the clx server path: parsing $DISPLAY as a Unix user might expect. Behaviour should be unchanged in the case that the $DISPLAY environment variable is unreadable. The immediate effect of this patch is that clim over ssh will work. That said, I have completely failed to test this patch even to the point of compiling it, as locally both my sbcl and my clx are broken. If someone could test this and report back (or commit it themselves), that would be good. Cheers, Christophe

1 1