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

[mcclim-devel] Class precedence error with sheet.lisp and cmucl
by Raymond Toy 09 Feb '06

09 Feb '06

While compiling mcclim from a cvs checkout of 2006-02-08 using the latest cmucl snapshot, I get an error when compiling Backend/Postscript/sheet.lisp. The error message is Error in function PCL::CPL-ERROR: While computing the class precedence list of the class named POSTSCRIPT-STREAM: The class named CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN is a forward referenced class. The class named CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN is a direct superclass of the class named POSTSCRIPT-STREAM.. [Condition of type SIMPLE-ERROR] I guess this might be a bug in cmucl's PCL. Ray

1 0

Re: [mcclim-devel] incremental redisplay slowness and local patches
by pw＠snoopy.mv.com 09 Feb '06

09 Feb '06

> > This, however, uses a scary clim-internals internal symbol. That's > fine up to a point, but it would be better from our point of view if > there were a way of doing this in a documented way; is there a > spec-blessed way of having a custom incremental-redisplay method > called? Alternatively, can climi::window-stream be documented and > exported? Any other ideas? I have not tried this myself, but there is the :record-type keyword to updating-output where you can supply your own class of output-record. Then redisplay-output-record on what that returns should do what you want. No? Paul

2 1

[mcclim-devel] incremental redisplay slowness and local patches
by Christophe Rhodes 08 Feb '06

08 Feb '06

Hi, As some of you know, the tablature application suffers from scaling problems in incremental redisplay because of the precision of the algorithm. While the spatial-trees stuff might solve this in the end, at the moment we are working around it by a conservative incremental-redisplay. In the interest of minimizing divergence from CVS McCLIM, we would like to have that incremental-redisplay as a different method, specialized on an application class. However, our first try (define a new output record type) was a failure, as incremental-redisplay itself is actually called on a stream, not on an output record; we could specialize redisplay, but then we would have to duplicate a whole load of stuff. We do know that the stream we want to call our own method for incremental-redisplay on is one obtained by OPEN-WINDOW-STREAM, and we control the place where this is called. Our current code, then, is (change-class (open-window-stream ...) 'tabcode-window-stream) with (defclass tabcode-window-stream (climi::window-stream) ()) This, however, uses a scary clim-internals internal symbol. That's fine up to a point, but it would be better from our point of view if there were a way of doing this in a documented way; is there a spec-blessed way of having a custom incremental-redisplay method called? Alternatively, can climi::window-stream be documented and exported? Any other ideas? Cheers, Christophe

1 0

[mcclim-devel] Problems getting "format-graph-from-roots" to work...
by Peter Braroe 07 Feb '06

07 Feb '06

Hello all! I have gotten slightly further in my ambition to make a clim program to draw tree diagrams. After looking at various examples I have put together a little program that gives the error below. No matching method for the generic function #<STANDARD-GENERIC-FUNCTION CLIM:LAYOUT-GRAPH-NODES (1) {58CD5C11}>, when called with arguments (#<CLIM-INTERNALS::DIGRAPH-GRAPH-OUTPUT-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 {59D5278D}> #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> NIL NIL). [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR] I am loading CLIM with asdf in my .cmucl-init and doing other stuff such as drawing a lines, rectangles works fine... Is it the code or my environment? I am getting seriously frustrated... Ideas? Also my clim package 0.9.1 does not seem to have "format-graph-from-root" (singular) only the "format-graph-from-roots" is this because the one root only version is not implemented? Does anyone know? Thanks beforehand for any help, /Peter ______________________________________________________________________ draw-tree.cl (defpackage :tree-test (:USE :CLIM :CLIM-EXTENSIONS :CLIM-LISP)) (in-package :tree-test) (defvar *test-frame* nil) (defvar *test-pane* nil) (defun run-tree-test () (let ((*test-frame* (setf *test-frame* (make-application-frame 'tree-test :height 400 :width 700 :doc-title "Tree diagram test")))) (run-frame-top-level *test-frame*) *test-frame*)) (define-application-frame tree-test () () (:menu-bar menubar-command-table) (:panes (screen :application :display-time nil :text-style (make-text-style :sans-serif :roman :normal) ) ) (:layouts (defaults (vertically () screen) ) ) #+nil (:top-level (tree-test-frame-top-level))) (make-command-table 'menubar-command-table :errorp nil :menu '(("Draw Tree" :command com-tree))) (define-tree-test-command com-tree () (draw-tree)) (defun draw-tree () (setq *test-pane* (get-frame-pane *test-frame* 'screen)) (format-graph-from-roots '((a (b (d)) (c (d)))) #'(lambda (x s) (princ (car x) s)) #'cdr :stream *standard-output* :orientation :vertical :merge-duplicates t :duplicate-key #'car)) Note: Have tried both *standard-output* and *test-pane* as :stream ______________________________________________________________________ No matching method for the generic function #<STANDARD-GENERIC-FUNCTION CLIM:LAYOUT-GRAPH-NODES (1) {58CD5C11}>, when called with arguments (#<CLIM-INTERNALS::DIGRAPH-GRAPH-OUTPUT-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 {59D5278D}> #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> NIL NIL). [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR] Restarts: 0: [CONTINUE] Retry call to :FUNCTION. 1: [ABORT] Return to application command loop 2: [ABORT] Abort handling SLIME request. 3: [ABORT] Return to Top-Level. Backtrace: 0: ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<#1=unused-arg> #<#1#> #<STANDARD-GENERIC-FUNCTION CLIM:LAYOUT-GRAPH-NODES (1) {58CD5C11}> (#<CLIM-INTERNALS::DIGRAPH-GRAPH-OUTPUT-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 {59D5278D}> #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> NIL NIL)) 1: ((FLET #:CONTINUATION99 (LABELS CLIM-INTERNALS::CONT CLIM:FORMAT-GRAPH-FROM-ROOTS)) #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}>) 2: ((METHOD CLIM:INVOKE-WITH-OUTPUT-RECORDING-OPTIONS NIL (CLIM:OUTPUT-RECORDING-STREAM T T T)) #<#1=unused-arg> #<#1#> #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> #<Closure Over Function (FLET #:CONTINUATION99 (LABELS CLIM-INTERNALS::CONT CLIM:FORMAT-GRAPH-FROM-ROOTS)) {59D528C1}> ...) 3: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL (CLIM:OUTPUT-RECORDING-STREAM T T NULL)) (#() . #(#)) #<unused-arg> #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> #<Closure Over Function (LABELS CLIM-INTERNALS::CONT CLIM:FORMAT-GRAPH-FROM-ROOTS) {59D51C09}> ...) 4: (CLIM:FORMAT-GRAPH-FROM-ROOTS ((TREE-TEST::A # #)) #<Function "DEFUN DRAW-TREE" {59BEF231}> #<Function CDR {101CF0C9}> :ORIENTATION ...) 5: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME)) (#() . #(# # # # # ...)) #<unused-arg> #<TREE-TEST::TREE-TEST {59BF2A5D}> NIL) 6: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G6356)" #<#1=unused-arg> #<#1#> #<TREE-TEST::TREE-TEST {59BF2A5D}> NIL) 7: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME)) (#(20) . #()) #<#1=unused-arg> #<TREE-TEST::TREE-TEST {59BF2A5D}> #<#1#>) 8: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) #1=(CLIM:APPLICATION-FRAME)) (#(16 15) . #(#)) #S(PCL::FAST-METHOD-CALL :FUNCTION #<Function (METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL #1#) {58C4A031}> :PV-CELL (# . #) :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<TREE-TEST::TREE-TEST {59BF2A5D}> NIL) 9: (TREE-TEST::RUN-TREE-TEST) 10: (SWANK::EVAL-REGION "(tree-test::run-tree-test) " T) 11: ("DEFSLIMEFUN LISTENER-EVAL") 12: (SWANK::CALL-WITH-BUFFER-SYNTAX #<Closure Over Function "DEFSLIMEFUN LISTENER-EVAL" {59BF2261}>) 13: ("DEFUN EVAL-FOR-EMACS") 14: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK NIL (T T)) #<#1=unused-arg> #<#1#> #<Function SWANK:SWANK-DEBUGGER-HOOK {59F4E871}> #<Closure Over Function "DEFUN EVAL-FOR-EMACS" {59BF2189}>) 15: ("DEFUN HANDLE-REQUEST") 16: ("DEFUN CALL-WITH-CONNECTION") 17: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {59F36D15}> #<Closure Over Function "DEFUN CALL-WITH-CONNECTION" {59BF1F09}>) 18: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {59F36D15}> #<Function "DEFUN HANDLE-REQUEST" {5A001911}>) 19: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {59F36D15}>) 20: (SWANK::PROCESS-AVAILABLE-INPUT #<Stream for descriptor 6> #<Closure Over Function "DEFUN INSTALL-SIGIO-HANDLER" {59BF1EF9}>) 21: ((FLET SWANK::HANDLER SWANK::INSTALL-SIGIO-HANDLER)) 22: (SWANK-BACKEND::SIGIO-HANDLER #<#1=unused-arg> #<#1#> #<#1#>) 23: ("call_into_lisp+#x8C [#x80548DC] /usr/bin/cmucl") 24: ("funcall3+#x29 [#x80546E4] /usr/bin/cmucl") 25: ("interrupt_handle_now+#xEF [#x80503A3] /usr/bin/cmucl") 26: ("NIL+#x80507C4 [#x80507C4] /usr/bin/cmucl") 27: ("__kernel_sigreturn+#x0 [#xFFFFE420] ") 28: (SYSTEM:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL) 29: (LISP::DO-INPUT #<Stream for Standard Input>) 30: (LISP::INPUT-CHARACTER #<Stream for Standard Input> NIL (LISP::*EOF*)) 31: (LISP::SYNONYM-IN #<Synonym Stream to SYSTEM:*STDIN*> NIL (LISP::*EOF*)) 32: (LISP::TWO-WAY-IN #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (LISP::*EOF*)) 33: (LISP::SYNONYM-IN #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (LISP::*EOF*)) 34: (READ-CHAR #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (LISP::*EOF*) NIL) 35: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) T) 36: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL) 37: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL 4 #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) ...)[:EXTERNAL] 38: (LISP::READ-INTERNAL #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL) 39: (READ #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL) 40: (LISP::%TOP-LEVEL) 41: ((LABELS LISP::RESTART-LISP SAVE-LISP))

6 7

SV: [mcclim-devel] Problems getting "format-graph-from-roots" to work...
by Robert P. Goldman 07 Feb '06

07 Feb '06

>>>>> "PB" == Peter Braroe <peter.braroe(a)newsmachine.com> writes: PB> Hello again! PB> FIX >> It's a pretty easy fix of just turning a single root >> into a list and then calling format-graph-from-roots, PB> What is the most elegant lispe method for this? Could one make it a macro? PB> Examples? Or would it be better to fix it in the CLIM as a patch? PB> ERROR! PB> Well it sure would help a novice like me with an error! Saves a lot of head PB> scratching... I believe that the following would do the job: (defun format-graph-from-root (root-object &rest other-args) (apply #'format-graph-from-roots (list root-object) other-args)) ...but I confess to not having tested it. I don't have a test case handy. Give it a whirl (note that you'll have to do this in some package where format-graph-from-roots is visible, or modify the above to clim:format-graph-from-roots. If it works properly and I haven't committed some horrible solecism (I didn't look at the standard for the proper definition of format-graph-from-root), then perhaps we could put it into McCLIM. Hope that is helpful, Robert

1 0

Re: SV: SV: [mcclim-devel] Problems getting "format-graph-from-roots"towork...
by Paolo Amoroso 07 Feb '06

07 Feb '06

"Peter Braroe" <peter.braroe(a)newsmachine.com> writes: > Tried it but didnt seem to work... :-( I will mail you a screenshot direct [...] > "Peter Braroe" <peter.braroe(a)newsmachine.com> writes: > >> Now all I need to do is to figure out how to get it to draw in color... > does >> anyone know if that is supported with :ink or some other method? > > Try wrapping the drawing operations into a WITH-DRAWING-OPTIONS form. I have received your screen shot. If you want colored arcs, you may use the :ARC-DRAWING-OPTIONS of FORMAT-GRAPH-FROM-ROOTS. If you are instead interested in colored nodes, try something like this for :OBJECT-PRINTER (untested): #'(lambda (x s) (with-drawing-options (*test-frame* :ink +red+) (princ (car x) s))) Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

1 0

Re: SV: [mcclim-devel] Problems getting "format-graph-from-roots" towork...
by Paolo Amoroso 07 Feb '06

07 Feb '06

"Peter Braroe" <peter.braroe(a)newsmachine.com> writes: > Now all I need to do is to figure out how to get it to draw in color... does > anyone know if that is supported with :ink or some other method? Try wrapping the drawing operations into a WITH-DRAWING-OPTIONS form. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

2 1

[mcclim-devel] postscript streams
by Christophe Rhodes 06 Feb '06

06 Feb '06

Hi, I'm in the process of attempting to merge our local divergences into mcclim's CVS, and I have a question about one of them (see below): is it reasonable to add updating-output-stream-mixin to the postscript-stream class? Though memory grows dim, I think we use this to allow the same drawing routines (which use updating-output) to draw both to screen and to postscript; we don't actually call incremental-redisplay on a postscript stream. Thanks, Christophe Index: Backends/PostScript/class.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/PostScript/class.lisp,v retrieving revision 1.7 diff -u -r1.7 class.lisp --- Backends/PostScript/class.lisp 31 Oct 2005 10:21:14 -0000 1.7 +++ Backends/PostScript/class.lisp 6 Feb 2006 12:30:36 -0000 @@ -61,6 +61,7 @@ permanent-medium-sheet-output-mixin sheet-mute-repainting-mixin mirrored-sheet-mixin ; ? + climi::updating-output-stream-mixin ; ?? standard-extended-output-stream standard-output-recording-stream) ((file-stream :initarg :file-stream :reader postscript-stream-file-stream)

2 2

[mcclim-devel] CLX translate function
by Christophe Rhodes 06 Feb '06

06 Feb '06

Hi, Another divergence minimization patch for review, this time slightly more involved. It is to do with the translation function for the CLX backend, and while it doesn't intend to introduce any functionality (or lack of it) that there was before, I'd feel happier to know that someone other than me understood my comment. Cheers, Christophe

1 0

[mcclim-devel] Proper naming of threads under SBCL (patch)
by Troels Henriksen 04 Feb '06

04 Feb '06

Attached is a patch which will pass the names of threads created with `make-process' properly on to `sb-thread:make-thread' under SBCL. Without this patch, the specified names of threads will not show up when doing a thread listing with `sb-thread:list-all-threads'. It's an extremely simple patch and it hasn't caused any problems for me. -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish)

1 0