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

[mcclim-devel] A question re. (setf bounding-rectangle-m...) methods
by Aleksandar Bakic 02 Apr '05

02 Apr '05

Hi, I am trying to get Scigraph to work with CMUCL. So far I found what I believe is a CMUCL 0305 bug: the third/last multiple-value-setq in function device-draw-line in scigraph/draw.lisp exercises incorrect compilation of the function. I replaced it with an equivalent multiple-value-bind and that fixed the problem. (Both versions of the function worked when interpreted.) Perhaps someone wants to take a look; I'll post to cmucl-devel if I do not get any feedback. Then I encountered a similar problem with (setf bounding-rectangle-min-x) and friends in the same file. The error below is confusing (it occurs when I play with zoom in/zoom out), but I noticed that the compiler complains about missing setf methods when I recompiled the file. Then I looked at regions.lisp and the spec, and I could not find the setf methods implemented or documented. Again, the error is not raised by CMUCL 0305 when I the code in scigraph/draw.lisp is interpreted. Any suggestions are welcome. Alex Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: 10 is not of type (MOD 10) [Condition of type TYPE-ERROR] Restarts: 0: [ABORT] Return to application command loop 1: [SCIGRAPH-TOP-LEVEL] Abort to SCIGRAPH Top Level 2: [DESTROY] Destroy the process Backtrace: 0: (%CLIP-LINE 1083 161 928 341 ...) 1: (DEVICE-DRAW-LINE #<APPLICATION-PANE DISPLAY {5A38C2D5}> 1083 161 928 ...) 2: ("DEFMETHOD DATUM-STYLE-DISPLAYER (GRAPH-DATUM-LINE-SYMBOLOGY-MIXIN T (EQL LINE-SYMBOL))" #<APPLICATION-PANE DISPLAY {5A38C2D5}> 928 341 (1572 5177/5000)) 3: ((METHOD INVOKE-WITH-NEW-OUTPUT-RECORD NIL (OUTPUT-RECORDING-STREAM T T T)) (#() . #(#)) #<unused-arg> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure Over Function (FLET #:CONTINUATION37) {589F3B59}> ...) 4: ("DEFMETHOD DATUM-DISPLAYER AROUND (PRESENTABLE-DATA-MIXIN T)" #<APPLICATION-PANE DISPLAY {5A38C2D5}> 928 341 (1572 5177/5000)) 5: (MAP NIL #<Closure Over Function "DEFMETHOD DISPLAY-DATA (ESSENTIAL-GRAPH-DATA-MAP-MIXIN T T)" {5882E631}> ((2096 261/200) (2095 1317/1000) (2094 13259/10000) (2093 13277/10000) (2092 13463/10000) ...)) 6: ((METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL NIL (MEDIUM T T)) (#(2 5 6 3 2 ...) . #(# #)) #<unused-arg> #1=#<CLIM-CLX::CLX-MEDIUM {5A4A7D45}> #1# ...) 7: ((METHOD GRAPH-DISPLAY-DATA NIL (GRAPH-DATASETS-MIXIN T)) (#(32 33) . #()) #<unused-arg> #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> #<APPLICATION-PANE DISPLAY {5A38C2D5}>) 8: ((METHOD GRAPH-WITH-CLIPPING NIL (BASIC-GRAPH T T T)) #<#1=unused-arg> #<#1#> #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> #<APPLICATION-PANE DISPLAY {5A38C2D5}> ...) 9: ("LAMBDA (G9552 G9553 G9554)" #<#1=unused-arg> #<#1#> #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> #<APPLICATION-PANE DISPLAY {5A38C2D5}>) 10: ((METHOD INVOKE-WITH-NEW-OUTPUT-RECORD NIL (OUTPUT-RECORDING-STREAM T T T)) (#() . #(#)) #<unused-arg> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure Over Function (FLET #:CONTINUATION97 (FLET #:UPDATING-OUTPUT-CONTINUATION6)) {5881ED81}> ...) 11: ((FLET #:UPDATING-OUTPUT-CONTINUATION6) #<APPLICATION-PANE DISPLAY {5A38C2D5}>) 12: ((METHOD INVOKE-WITH-NEW-OUTPUT-RECORD NIL (OUTPUT-RECORDING-STREAM T T T)) (#() . #(#)) #<unused-arg> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure Over Function (FLET #:CONTINUATION14 CLIM-INTERNALS::%INVOKE-UPDATING) {5881E919}> ...) 13: (CLIM-INTERNALS::%INVOKE-UPDATING #<STANDARD-UPDATING-OUTPUT-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> {5881E36D}> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure Over Function (FLET #:UPDATING-OUTPUT-CONTINUATION6) {5881D961}>) 14: ((FLET #:CONTINUATION44) #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<STANDARD-UPDATING-OUTPUT-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> {5881E36D}>) 15: ((METHOD INVOKE-WITH-NEW-OUTPUT-RECORD NIL (OUTPUT-RECORDING-STREAM T T T)) (#() . #(#)) #<unused-arg> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure Over Function (FLET #:CONTINUATION44) {5881D989}> ...) 16: ((METHOD INVOKE-UPDATING-OUTPUT NIL (CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN T T T T ...)) (#(46) . #(#)) #<unused-arg> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure Over Function (FLET #:UPDATING-OUTPUT-CONTINUATION6) {5881D961}> ...) 17: ((METHOD DISPLAY (:AROUND) (PRESENTABLE-GRAPH-MIXIN T)) (#(50 49) . #()) #S(PCL::FAST-METHOD-CALL :FUNCTION #<Closure Over Function "LAMBDA (G9552 G9553 G9554)" {5A002AF9}> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> #<APPLICATION-PANE DISPLAY {5A38C2D5}>) 18: ((METHOD EXECUTE-FRAME-COMMAND (:AROUND) (T T)) #<unused-arg> #S(PCL::FAST-METHOD-CALL :FUNCTION #<Function (METHOD EXECUTE-FRAME-COMMAND NIL #) {58C7E8C1}> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) #<GRAPH-VIEWER {58618B55}> (COM-ZOOM-IN #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> #<APPLICATION-PANE DISPLAY {5A38C2D5}>)) 19: ((METHOD DEFAULT-FRAME-TOP-LEVEL NIL (APPLICATION-FRAME)) (#() . #(# # # # # ...)) #<unused-arg> #<GRAPH-VIEWER {58618B55}> NIL) __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 1

[mcclim-devel] problem with format-graph-from-roots, ACL 6.2
by rpgoldman＠sift.info 01 Apr '05

01 Apr '05

I took some code invoking format-graph-from-roots from before the mothering release and was trying to run it, and got a crash. I traced fairly far down the stack and found something anomalous that I was hoping someone could help me with. In the course of drawing one of my graph-nodes, I get to this point in the stack: [1c] GRAPH-MDP(108): :fr ((METHOD INVOKE-WITH-DRAWING-OPTIONS (SHEET T)) #<APPLICATION-PANE APP @ #x72139792> #<Closure (FLET DRAW-TAEMS-NODE #:G7069) @ #xbfff547a> :INK #.+FOREGROUND-INK+ :TEXT-STYLE #<STANDARD-TEXT-STYLE :FIX :ROMAN :NORMAL>) Now what's odd in that is that I seem to be using the method for the case where the first parameter is of unrestricted type (T). But there is ANOTHER (better?) definition for the case where the first argument is a SHEET. As far as I can tell, the second argument IS a sheet: [1c] GRAPH-MDP(111): (setf foo (second *)) #<APPLICATION-PANE APP @ #x72139792> [1c] GRAPH-MDP(112): (clim::sheetp foo) T [1c] GRAPH-MDP(113): (typep foo 'clim::sheet) T I think the upshot of this is that the extra arguments (the drawing options) are tossed away, instead of being passed on to the closure. At the end of the day, this means that we try to call invoke-with-sheet-medium-bound with the arguments: CLOSURE NIL CLIM-CLX::CLX-MEDIUM whereas that generic function seems to expect CLOSURE MEDIUM-OR-NIL SHEET Thanks, R

1 0

[mcclim-devel] sb-bsd-sockets
by Boris Tschirschwitz 31 Mar '05

31 Mar '05

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.

5 4

[mcclim-devel] Image drawing
by Milan Zamazal 30 Mar '05

30 Mar '05

Since image drawing (in clim-extensions.lisp) was excluded in McCLIM 0.9.1, I've implemented my (very primitive for now) own code for that in Springtail (http://www.zamazal.org/software/springtail/index.html) This is just to let you know that if anybody wanted to add image drawing support to McCLIM again, I'd like to cooperate. Regards, Milan Zamazal -- _/_\_/_ o _\_/_\_ o _/_\_/_ o _\_/_\_ o BEWARE! -<_|_|_|_><-- -<_|_|_|_><-- -<_|_|_|_><-- -<_|_|_|_><-- *Bugs* are / \ / o \ / \ o / \ / o \ / \ o approaching!

1 0

[mcclim-devel] Sample code
by David Christiansen 27 Mar '05

27 Mar '05

I've written a Connect Four game that uses McCLIM, complete with a computer player, and I think that it might be a nice little inclusion into the sample code section of McCLIM (i.e., the clim-demos package). How can I go about submitting it? ;;--------------------------------------------------------------- ;; -David Christiansen ;;

1 0

[mcclim-devel] Flipping sheet coords
by Duncan Rose 25 Mar '05

25 Mar '05

This is probably rather Cocoa-centric, so I'll probably be boring anybody that doesn't know any of Apple's frameworks with the following... I've been looking at the Beagle back end again recently looking to complete the remaining functionality and speed it up somewhat. One of the things I want to do to hopefully speed things up is move to a delayed drawing implementation (which is the way Apple recommend doing things anyway; all drawing is done in a 'drawRect' method which is invoked as part of the main event loop by the underlying windowing system). In order to make this work I've migrated the text drawing to append glyphs to an NSBezierPath subclass; in order to implement the delayed drawing I just stack all bezier path objects up in an array and stroke or fill them at the appropriate time. The problem I have is that Cocoa and McCLIM have different coordinate systems (the y-axes are reversed) by 'default'. Previously I dealt with this by setting the view up to be 'flipped' which is standard Cocoa functionality. This works in general but text is rendered upside down. What I'd *like* to do is to be able to set a transform which would automatically take care of this within McCLIM (rather than within Cocoa). What I'm hoping is that there's an easy solution to this (such as applying an inverting transform the the graft and having this by default apply to anything grafted onto it). So my question boils down to "does using a :graphics oriented graft rather than a :default orientation make any difference at all to anything attached to that graft"? An additional question might be "if not, should it?" (I'd like to have a CLIM solution to this but if there appears not to be one I'll hack something into the back end to do it via Cocoa - it seems to me that if I apply the appropriate transform to the graft things should 'just work' but maybe I'm misunderstanding how things fit together). Also, who do I need to see to get CVS commit privs again or should I just be submitting patches? Thanks, -Duncan

1 0

[mcclim-devel] Freetype bindings
by Christophe Rhodes 23 Mar '05

23 Mar '05

Hi, I've been playing with the bindings to freetype in Experimental/freetype, with a view to using them in one of my apps -- there is a font which I need to use which is available to me in truetype format (and, in addition, it makes the Climacs window look pretty). I've run into multiple problems, most of which I've worked around in some way or other. One which is definitely not this list's problem is the fact that sbcl miscompiles freetype-ffi.lisp; it gets confused over some forward declarations, and subsequently refuses to do anything with certain foreign structures. I believe the sbcl experts are working on this problem; however, there is a simple workaround, which is to load the freetype-ffi.lisp file as source. A more serious problem lies in the fact that the ffi bindings are very definitely 32-bit centric; certain things are defined as (signed 32) or (unsigned 32) when they should be long or unsigned-long. (This causes segmentation faults on 64-bit platforms). I have manually corrected the bindings, but I think the right answer is to generate the bindings themselves as part of the compilation process: in other words, do something similar to sbcl's sb-grovel, and ask the C compiler on the host system to emit suitable Lisp code, using sizeof, offsetof, and the C preprocessor itself. One word of warning at this point: it is easy to crash your lisp if you're not careful, because the bindings are not fully type-declared, so sbcl spews compiler diagnostics to *standard-output* when calling the freetype functions. This is bad if the freetype functions are being called in order to emit characters to a clim pane bound to *standard-output*... I've been using (handler-bind ((compiler-note #'muffle-warning)) (climacs-gui::climacs)) or similar to work around this. The remaining glitch -- one that I have not managed to solve, is that there are visual artifacts with the bindings. A full redraw usually solves any such artifacts, but during the course of interaction, characters are often misplaced. A chance mention on IRC suggests that this might be caused by insufficient display-finish-outputs; does anyone have any suggestions as to where to look for these? A screenshot, for the interested: <http://www-jcsu.jesus.cam.ac.uk/~csr21/tabcode-font.png>. Cheers, Christophe

1 0

[mcclim-devel] Copying text to clipboard loops displaying messages to Konsole
by Paolo Amoroso 22 Mar '05

22 Mar '05

When I copy some text with Shift-left-click from the CLIM Listener for later copying somewhere else, I get an infinite loop that displays messages (all identical) like this to the KDE Konsole from which I have started the Listener: #<CLIM-CLX::CLX-SELECTION-REQUEST-EVENT {5850A54D}> is an instance of type CLX-SELECTION-REQUEST-EVENT it has the following slots: TIMESTAMP: 5010524 SHEET: #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {58B8A0CD}> REGION: <unbound> SELECTION: :PRIMARY REQUESTOR: #<XLIB:WINDOW :0 31457298> TARGET: :COMPOUND_TEXT PROPERTY: :_QT_SELECTION If I later paste with Shift-middle-click the clipboard selection to another Konsole pane, I get a garbled string similar to that described here: http://common-lisp.net/pipermail/mcclim-devel/2004-December/002731.html I have to quit the Listener in order to stop the infinite loop. I use CMUCL Snapshot 2005-02 with the latest McCLIM CVS sources under Slackware Linux 10.0, with a 2.6.10 kernel. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

4 16

[mcclim-devel] Gadgets in accepting-values (again)
by Anthony Juckel 22 Mar '05

22 Mar '05

With the latest McCLIM CVS, displaying a gadget within accepting-values seems to work quite well now. Unfortunately, I feel that I'm doing something wrong with the functionality. At first, I tried to simply call throw-object-ptype from my gadget's value-changed-callback (it inherits from value-gadget), but that seemed to have no effect. The function was called, but I'm unsure how that thrown value was supposed to propogate. Who is supposed to "catch" it? I finally settled on the following to get my value properly propogated: :value-changed-callback #'(lambda (gadget value) (declare (ignore gadget)) (let ((query (find query-identifier (climi::queries climi::*accepting-values-stream*) :key #'climi::query-identifier :test #'equal))) (setf (climi::value query) value) (setf (climi::changedp query) t)) (climi::throw-object-ptype value `(trait-rating ,max)) (debug-msg "Gadget value changed to: ~A" value)) The throw-object-ptype at near the bottom of the callback remains, but doesn't appear to do anything. This method strikes me as quite unclean for a few reasons, not the least of which is relying on a few unexported symbols from clim-internals. One other thing: com-select-query is not called during the operation of my gadget. Looking at the behavior of the popup menu, I see that it is displayed as a simple value until the query is selected, at which point select-query blocks waiting for the user to make a choice from the newly-drawn popup menu. I'm not sure how to do functionality similar to that in my case. The user may at any time click my gadget to change its value, and I am unsure how to tie in select-query for two reasons: 1) I still don't quite get presentation-to-command-translators, so I don't know how I can make any click on my gadget also translate into com-select-query, as well as having the click register with my gadget to properly change its value. 2) Even if I get com-select-query to be called, I'm unsure how I would block within select-query until the user selects a value in the query. Could anyone help me shed some light on these issues? Anthony W. Juckel

1 0

[mcclim-devel] Possible bug
by David Christiansen 21 Mar '05

21 Mar '05

Hello all, I'm new to the list. I've been writing a little Connect 4 clone with McClim and I think I found a place where the implementation diverges from the standard. I'm using the Mothering Sunday release. When I try to (make-pane 'option-pane :value "foo" :mode :exclusive :items '("foo" "bar")), I get an error saying that :exclusive is not a member of type (or :some-of :one-of). It looks to me as though the spec says that those options should be called :exclusive or :nonexclusive, though :one-of and :some-of seem to work just fine to me. The relevant section of the spec (chapter 30) can be seen at: http://www.mikemac.com/mikemac/clim/gadgets.html Am I reading it correctly? If so, I'll try to grab a recent CVS and work up a patch later this week (though, being a newbie, I'd want someone to see it). It seems localized enough that I should be able to figure it out. Thank you all for this handy library! ;;------------------------------------------------------------------ ;; -David Christiansen ;;

2 3