mcclim-devel May 2006

mcclim-devel@common-lisp.net

16 participants
18 discussions

Re: Fwd: Re: [mcclim-devel] Severe performance regression with latest CVS sources?
by Christophe Rhodes 22 Nov '06

22 Nov '06

Paolo Amoroso <amoroso(a)mclink.it> writes: >> twice that many hash tables with (make-hash-table)? The other thing > > CL-USER> (time (dotimes (i (* 2 824)) > (make-hash-table))) > ; Compiling LAMBDA NIL: > ; Compiling Top-Level Form: > > ; Evaluation took: > ; 6,648 CPU cycles It's elided the creation, I'm afraid. Can you do (defvar *foo*) (time (dotimes (i (* 2 824)) (setq *foo* (make-hash-table)))) ? > ; > NIL > CL-USER> > > >> to look at is for collisions in your hash tables; check the EDGES-FROM >> slot of something with a lot of direct subclasses, say STRUCTURE-CLASS >> or CONDITION or NUMBER, and see if all of the entries are in the same >> bucket of the hash table) > > I'm not sure I understand what you mean. I used the SLIME inspector > to inspect the output of, say, (find-class 'structure-class). I > include the output below, which does not seem to have any EDGES-FROM > slot. I think the edges-from should be in the graph node output record. I'm not entirely sure how to get at one of those, but you could start by inspecting clim:*application-frame* from the slime inspector, finding the listener interactor pane, finding its output history, and looking at the output records in there. > 588,259,376 | 1,111 | 15.158 | 0.01364 | 529,486 | CLIM-INTERNALS::LAYOUT-EDGE-1 > 1,111: #<Code Object "LAMBDA (FWRAPPER)" {5A58260F}> > 1,470,608 | 2,222 | 0.056 | 0.00003 | 662 | CLIM-INTERNALS::ENSURE-EDGE-RECORD > 1,111: #<Code Object "DEFUN LAYOUT-EDGE" {59718A4F}> > 1,111: #<Code Object "DEFUN LAYOUT-EDGE-1" {5A75B007}> Well, that's moderately conclusive: the cost seems to be in LAYOUT-EDGE-1, not in ENSURE-EDGE-RECORD. Which is weird, because I can't really see what LAYOUT-EDGE-1 is doing that is so ludicrously expensive. Can you do the same thing, but with the CLIM package profiled additionally? (And then maybe one with CLIM but not CLIM-INTERNALS profiled?) The first 10 or so entries in each profile will probably suffice. (Maybe CLEAR-OUTPUT-RECORD is expensive?) Cheers, Christophe

3 3

[mcclim-devel] execute-frame-command
by Christophe Rhodes 02 Jun '06

02 Jun '06

Hi, Is (defun foo () (let ((frame (make-application-frame 'climacs))) (clim-sys:make-process (lambda () (run-frame-top-level frame))) (execute-frame-command frame `(com-find-file "/tmp/foo.txt")))) expected to be "safe"? At present, this is subject to a race condition, because the frame need not have been adopted properly by the time the execute-frame-command runs, and so it need not have a top-level sheet. Would it be reasonable to guard against this in the branch of execute-frame-command, and if so, how? There's a symmetric case (which is probably less common) where the frame command is executed just after the top-level sheet is disowned. Any ideas? It would be nice to support something along the lines of my FOO function above -- it seems like a natural expression of a response to user action. Cheers, Christophe

2 1

[mcclim-devel] clipping regions, replay, handle-repaint
by Christophe Rhodes 28 May '06

28 May '06

Hi, I think that CLIM underspecifies how clipping regions (and text-styles and line-styles) are handled for output records. For REPLAY-OUTPUT-RECORD, it says "The current user transformation, line style, text style, ink, and clipping region of stream are all ignored during the replay operation. Instead, these are gotten from the output record." which is good, but unfortunately it doesn't specify /how/ they are gotten, which means that implementing one's own output record class is tricky. Why does this matter? In gsharp, we implement sloped beams with our own kind of output record; as of this morning, I taught that output record, and the replay-output-record methods, about the medium clipping region, so that sloped short beams (as in <http://www-jcsu.jesus.cam.ac.uk/~csr21/sloped-short-beams.png>) survive repainting; previously the output record had no record of the clipping region, and so a repaint would cause the entire width, rather than just the short segment, to be drawn. So this now works acceptably. However, we implement horizontal beams with an ordinary rectangle, and short ones with an ordinary rectangle and clipping region. Before a repaint, this works fine: see <http://www-jcsu.jesus.cam.ac.uk/~csr21/horizontal-beams.png>. However, obscuring and uncovering the window, triggering a repaint, results in <http://www-jcsu.jesus.cam.ac.uk/~csr21/horizontal-beams-after-repaint.png>. This happens because the replay-output-record methods for the clim internal graphics things (such as rectangles) set the medium clipping region while they're replaying, but don't set it back; they simply rely on a method on replay. In fact, in McCLIM itself as distributed the set-medium-graphics-state :after method on gs-clip-mixin is essentially disabled, though I'm not entirely sure why; gsharp re-enables it, presumably in an attempt to get some of this working, but disabling it again simply means that replaying horizontal beams (i.e. rectangles) which have been clipped ignores the previous clipping region. What is one to do? Well, I think with the standard as it is there's no way of writing output record classes. However, the case of changing ink can be handled in the spec, as CLIM specifies a function displayed-output-record-ink; using that, dealing with the ink looks like (defmethod replay-output-record :around ((record displayed-output-record) stream ...) (let ((medium (sheet-medium stream))) (with-drawing-options (medium :ink (displayed-output-record-ink record)) (call-next-method)))) and this will work, given that all displayed-output-record objects obey the displayed-output-record protocol. If we were to extend the protocol to require displayed-output-record-clipping-region, displayed-output-record-text-style and displayed-output-record-line-style, then I think this would cover the difficult cases, most of the set-medium-graphics-state methods could go away, and gsharp could have horizontal short beams. Comments? Cheers, Christophe

1 1

[mcclim-devel] Towards a 0.9.3 "Trinity Sunday" release
by Andreas Fuchs 26 May '06

26 May '06

Hi, this is going to be the first (or third, if you count Laetare Sunday) release in a time-boxed series! The plan is to release on Trinity Sunday, which is on the 11th of June this year. The freeze period will start on June 6, that is the tuesday after Pentecost. Seeing as the last freeze announcement prompted a lot of fixes and patches to come in, I'd like to urge all contributors to send your patches before the start of the freeze period this time. You've got a long weekend to do so, too. (-: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

1 0

[mcclim-devel] Debugger, ESA, mcclim-freetype
by Christophe Rhodes 26 May '06

26 May '06

Hi, Today I observed a rather nasty interaction that I'm at a loss to explain. If I wrap the CLIM Debugger around an Emacs-Style Application which uses mcclim-freetype, and provoke an entry into that debugger, I get X Length Errors. I think I need all three of those elements: the clim debugger and listener work fine together; gsharp and the clim debugger without freetype work fine; and of course the applications work acceptably using freetype in normal operation and with slime. I am not sure whether this is specific to SBCL; nor am I sure whether it is specific to threaded lisps; I haven't tried it with a non-threaded system. The event queue process has a backtrace that looks like Backtrace: (BACKTRACE-AS-LIST 200) (DEBUGGER-HOOK #<XLIB:LENGTH-ERROR {10060EA641}> #) (INVOKE-DEBUGGER #<XLIB:LENGTH-ERROR {10060EA641}>) (CERROR "Ignore" XLIB:LENGTH-ERROR) (XLIB::X-CERROR "Ignore" XLIB:LENGTH-ERROR :DISPLAY #<XLIB:DISPLAY :0 (The X.Org Foundation R60802000)> :ERROR-KEY XLIB:LENGTH-ERROR :ASYNCHRONOUS T :CURRENT-SEQUENCE 1913 :MAJOR 154 :MINOR 25 :SEQUENCE 1563) [...] (XLIB:PROCESS-EVENT #<XLIB:DISPLAY :0 (The X.Org Foundation R60802000)> :HANDLER # :TIMEOUT NIL :PEEK-P NIL :DISCARD-P T :FORCE-OUTPUT-P T) ((SB-PCL::FAST-METHOD CLIM-BACKEND:GET-NEXT-EVENT #) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-PORT :HOST "" :DISPLAY-ID 0 {10059661F1}> (:WAIT-FUNCTION NIL :TIMEOUT NIL)) while the application thread (which /also/ gets a length error) has a backtrace involving HANDLE-REPAINT on the menu-button-pane of the CLIM Debugger, CLIM-CLX::FONT-DRAW-GLYPHS (MCCLIM-FREETYPE::FREETYPE-FACE ...), and a call to XLIB::DRAWABLE-DEPTH and XLIB::READ-REPLY. Any ideas? Can anyone replicate any of this? Is there something in the toplevel loop of ESA (or attendant methods) which could cause this problem? Cheers, Christophe

2 3

[mcclim-devel] making freetype more portable
by rpgoldman＠real-time.com 26 May '06

26 May '06

Does anyone have any suggestions about how one might go about making mcclim-freetype portable to other lisps? Seems like right now it's only usable for cmucl and sbcl. I was thinking about either trying to translate the definer macros to acl ffi or, in the hopes of broader portability, to CFFI. But it seems like the defining sublanguage for CMUCL & SBCL is fairly different from CFFI. CFFI-grovel seemed like another alternative. Any suggestions? thanks, R

4 8

[mcclim-devel] freetype-cffi sorta works
by Robert P. Goldman 25 May '06

25 May '06

I have the CFFI translation of freetype working at least a little (on ACL). I am certainly NOT confident enough in it to say it ought to replace the old one! But I would like to share the work, and I would like to see it out there on common-lisp.net for people to examine and critique. Here's what I have done: I have created shadows of all the original files. So I have freetype-fonts-cffi.lisp, freetype-cffi.lisp, freetype-package-cffi.lisp and mcclim-freetype-cffi.asd. I would like to check these into the CVS, since they will not break the existing mcclim-freetype. If you'd like to test the CFFI version, just symlink <asdf-system-dir>/mcclim-freetype.asd to mcclim-freetype-cffi.asd, then load as per the instructions for ordinary mcclim-freetype.asd. Please let me know if this for some reason would be a bad thing. Otherwise I will make the commit in about 4-6 hours. Thanks! R

1 0

[mcclim-devel] Re: Question about freetype translation to CFFI
by Robert P. Goldman 25 May '06

25 May '06

Please disregard this query. I see that I was clueless and apologize. I had forgotten my old C knowledge, and in particular, had forgotten that the desire to have multiple values, combined with call-by-value, means that one often must pass pointers to pointers as arguments, and then to get the pointer, one dereferences.... Never mind! Cheers, R Robert P. Goldman wrote: > I wonder if anyone who's familiar with SBCL aliens can give me some > advice in my ongoing translation of the freetype code into CFFI. IIUC > (I quite possibly don't), a difference between the two is that SBCL > has much more "understanding" of the foreign data structures, and that > it is able to work directly with foreign structures. CFFI works more > with pointers, and requires more explicit reference to the foreign > types when dereferencing. > > I think I have mostly managed to translate the foreign data > structures, and a good bit of the code. However, I am still having > some trouble understanding a bit of the SBCL alien code, particularly > the use of derefs when returning foreign values. For example, here's > one of the original defuns: > > (defun make-concrete-font (vague-font size &key (dpi *dpi*)) > (with-slots (lib filename) vague-font > (let* ((key (cons lib filename)) > (val (gethash key *concrete-font-hash*))) > (unless val > (let ((facef (make-alien freetype:face))) > (declare (type (alien (* freetype:face)) facef)) > (if (zerop (freetype:new-face lib filename 0 facef)) > (setf val (setf (gethash key *concrete-font-hash*) > (deref facef))) > (error "Freetype error in make-concrete-font")))) > (let ((face val)) > (declare (type (alien freetype:face) face)) > (freetype:set-char-size face 0 (round (* size 64)) (round dpi) > (round dpi)) > face)))) > > I'm not at all sure, moving to CFFI, how to translate the DEREF > calls. CFFI is essentially always working with pointers, IIUC, so I'm > wondering if I should just eliminate deref calls like this (i.e., just > set the hash table entry to facef)... > > Any suggestions would be more than welcome. > > > Thanks, > R > >

1 0

[mcclim-devel] mcclim update
by Irene DURAND 25 May '06

25 May '06

With a version of mcclim updated on march 31st Autowrite works fine. With the latest version I get the error below. Could somebody help me please? -- Irène DURAND http://dept-info.labri.u-bordeaux.fr/~idurand The class #<SB-KERNEL:STANDARD-CLASSOID CLIM-INTERNALS::BASIC-OUTPUT-RECORD> is currently invalid. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Return to application command loop 1: [ABORT-REQUEST] Abort handling SLIME request. 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B3F9909}>) Backtrace: 0: (SB-KERNEL:CLASSOID-TYPEP #<SB-PCL::WRAPPER #<STANDARD-CLASS STANDARD-PRESENTATION> {EE7BCB9}> #<SB-KERNEL:STANDARD-CLASSOID CLIM-INTERNALS::BASIC-OUTPUT-RECORD> #<STANDARD-PRESENTATION 81:162,0:15 (COMMAND :COMMAND-TABLE #<STANDARD-COMMAND-TABLE VISU-AW {A986D91}>) {E50CCF1}>) 1: (CLIM-INTERNALS::FIND-OUTPUT-RECORD-SHEET #<STANDARD-PRESENTATION 81:162,0:15 (COMMAND :COMMAND-TABLE #<STANDARD-COMMAND-TABLE VISU-AW {A986D91}>) {E50CCF1}>) 2: ((SB-PCL::FAST-METHOD ADD-OUTPUT-RECORD :AFTER (T CLIM-INTERNALS::COMPOUND-OUTPUT-RECORD)) #<unavailable argument> #<unavailable argument> #<GOATEE:SIMPLE-SCREEN-AREA X 81:162 Y 0:15 {EF225B1}> #<STANDARD-PRESENTATION 81:162,0:15 (COMMAND :COMMAND-TABLE #<STANDARD-COMMAND-TABLE VISU-AW {A986D91}>) {E50CCF1}>) 3: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<GOATEE:SIMPLE-SCREEN-AREA X 81:162 Y 0:15 {EF225B1}> #<STANDARD-PRESENTATION 81:162,0:15 (COMMAND :COMMAND-TABLE #<STANDARD-COMMAND-TABLE VISU-AW {A986D91}>) {E50CCF1}>) 4: ((LAMBDA NIL)) 5: ((FLET #:CONTINUATION1279) #<unavailable argument> #<unavailable argument>) 6: ((SB-PCL::FAST-METHOD INVOKE-WITH-NEW-OUTPUT-RECORD (OUTPUT-RECORDING-STREAM T T T)) #<unavailable argument> #<unavailable argument> #<INTERACTOR-PANE INTERACTOR-PANE {AAD8021}> #<CLOSURE (FLET #:CONTINUATION1279) {DCD80A5}> #<unavailable argument> #<CLOSURE (FLET #:CONSTRUCTOR1278) {DCD808D}> (:OBJECT (COM-LOAD-SPEC) :TYPE (COMMAND :COMMAND-TABLE #<STANDARD-COMMAND-TABLE VISU-AW {A986D91}>))) 7: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::FINALIZE (GOATEE:GOATEE-INPUT-EDITING-MIXIN T)) #<unavailable argument> #<unavailable argument> #<STANDARD-INPUT-EDITING-STREAM {DD94461}> #<CLOSURE (LAMBDA (STREAM CLIM-INTERNALS::CONT)) {DCCD7BD}>) 8: ((FLET #:CLEANUP-FUN-602)) 9: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING (EXTENDED-INPUT-STREAM T T T T)) #<unavailable argument> #<unavailable argument> #<INTERACTOR-PANE INTERACTOR-PANE {AAD8021}> #<CLOSURE (LAMBDA (STREAM)) {DCCD76D}> #<CLOSURE (LAMBDA (STREAM CLIM-INTERNALS::CONT)) {DCCD7BD}> "" STANDARD-INPUT-EDITING-STREAM) 10: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING :AROUND (EXTENDED-OUTPUT-STREAM T T T T)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING #)> :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (5)) :ARG-INFO (5)) #<INTERACTOR-PANE INTERACTOR-PANE {AAD8021}> #<CLOSURE (LAMBDA (STREAM)) {DCCD76D}> #<CLOSURE (LAMBDA (STREAM CLIM-INTERNALS::CONT)) {DCCD7BD}> "" STANDARD-INPUT-EDITING-STREAM) 11: (ACCEPT (COMMAND :COMMAND-TABLE #<STANDARD-COMMAND-TABLE VISU-AW {A986D91}>) :STREAM #<INTERACTOR-PANE INTERACTOR-PANE {AAD8021}> :PROMPT NIL :DEFAULT (CLIM-INTERNALS::COM-NULL-COMMAND) :DEFAULT-TYPE CLIM-INTERNALS::NULL-COMMAND) 12: (READ-COMMAND #<STANDARD-COMMAND-TABLE VISU-AW {A986D91}> :STREAM #<INTERACTOR-PANE INTERACTOR-PANE {AAD8021}> :COMMAND-PARSER NIL :COMMAND-UNPARSER NIL :PARTIAL-COMMAND-PARSER NIL :USE-KEYSTROKES NIL) 13: (READ-COMMAND-USING-KEYSTROKES #<STANDARD-COMMAND-TABLE VISU-AW {A986D91}> NIL :STREAM #<INTERACTOR-PANE INTERACTOR-PANE {AAD8021}> :COMMAND-PARSER NIL :COMMAND-UNPARSER NIL :PARTIAL-COMMAND-PARSER NIL) 14: (READ-COMMAND #<STANDARD-COMMAND-TABLE VISU-AW {A986D91}> :STREAM #<INTERACTOR-PANE INTERACTOR-PANE {AAD8021}> :COMMAND-PARSER NIL :COMMAND-UNPARSER NIL :PARTIAL-COMMAND-PARSER NIL :USE-KEYSTROKES T) 15: ((SB-PCL::FAST-METHOD READ-FRAME-COMMAND :AROUND (APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD READ-FRAME-COMMAND #)> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<VISU-AW {B26C2B9}> (:STREAM #<INTERACTOR-PANE INTERACTOR-PANE {AAD8021}>)) 16: ((SB-PCL::FAST-METHOD DEFAULT-FRAME-TOP-LEVEL (APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<VISU-AW {B26C2B9}> NIL) 17: ((SB-PCL::FAST-METHOD DEFAULT-FRAME-TOP-LEVEL (APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<VISU-AW {B26C2B9}> NIL) 18: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.DFUN-REST-ARG.)) #<unavailable argument> #<unavailable argument> #<VISU-AW {B26C2B9}> NIL) 19: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL (APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<VISU-AW {B26C2B9}> #<unavailable argument>) --more--

4 5

[mcclim-devel] Problem with McCLIM
by Fred Gilham 24 May '06

24 May '06

Using a freshly updated version of McCLIM under CMUCL 19C and FreeBSD I get the following: * (require :clim-examples) Warning: Silly argument for a unix PATHNAME-NAME: "Goatee/presentation-history" Warning: Silly argument for a unix PATHNAME-NAME: "Goatee/presentation-history" Warning: Silly argument for a unix PATHNAME-NAME: "Looks/pixie" Warning: Silly argument for a unix PATHNAME-NAME: "Looks/pixie" Warning: Silly argument for a unix PATHNAME-NAME: "Goatee/presentation-history" Warning: Silly argument for a unix PATHNAME-NAME: "Looks/pixie" ; Loading #P"/usr/local/share/lisp/asdf-packages/spatial-trees-0.1/spatial-tree-viz.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/calculator.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/colorslider.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/menutest.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/address-book.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/traffic-lights.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/clim-fig.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/postscript-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/puzzle.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/transformations-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/demodemo.x86f". ;; try (CLIM-DEMO::DEMODEMO) ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/stream-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/presentation-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/dragndrop.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/gadget-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/accepting-values.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/method-browser.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/dragndrop-translator.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/draggable-graph.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/text-size-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/drawing-benchmark.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Goatee/goatee-test.x86f". NIL * (clim-demo::demodemo) (now I click on the "Address Book" button) Error in function KERNEL:CLASS-TYPEP: Class is currently invalid: #<KERNEL::STANDARD-CLASS CLIM-INTERNALS::BASIC-OUTPUT-RECORD {29269CB5}> [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT ] Return to application command loop 1: Return to application command loop 2: Return to Top-Level. 3: [DESTROY] Destroy the process Debug (type H for help) Here is some of the backtrace: 0: (KERNEL:CLASS-TYPEP #<unavailable-arg> #<unavailable-arg> #<unavailable-arg>) 1: (CLIM-INTERNALS::FIND-OUTPUT-RECORD-SHEET #<CLIM:STANDARD-PRESENTATION 0:99,0:14 CLIM-DEMO::ADDRESS {48109D8D}>) 2: ((METHOD CLIM:ADD-OUTPUT-RECORD (:AFTER) (T CLIM-INTERNALS::COMPOUND-OUTPUT-RECORD)) #<unused-arg> #<unused-arg> #<CLIM-INTERNALS::STANDARD-TEXT-DISPLAYED-OUTPUT-RECORD 0,0 ("Scott McKay") {483D8C4D}> #<CLIM:STANDARD-PRESENTATION 0:99,0:14 CLIM-DEMO::ADDRESS {48109D8D}>) 3: ("LAMBDA (G3106 G3107 G3108)" #<unused-arg> #<unused-arg> #<CLIM-INTERNALS::STANDARD-TEXT-DISPLAYED-OUTPUT-RECORD 0,0 ("Scott McKay") {483D8C4D}> #<CLIM:STANDARD-PRESENTATION 0:99,0:14 CLIM-DEMO::ADDRESS {48109D8D}>) 4: ("LAMBDA (G8342 G8343 G8344)" #<unused-arg> #<unused-arg> #<CLIM:APPLICATION-PANE CLIM-DEMO::NAMES {4955927D}>) 5: (FINISH-OUTPUT #<CLIM:APPLICATION-PANE CLIM-DEMO::NAMES {4955927D}>) 6: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL (CLIM:OUTPUT-RECORDING-STREAM T T T)) (#() . #(#)) #<unused-arg> #<CLIM:APPLICATION-PANE CLIM-DEMO::NAMES {4955927D}> #<Closure Over Function (FLET #:CONTINUATION38 ) {48109749}> ...) 7: ((METHOD CLIM:STREAM-PRESENT NIL (CLIM:OUTPUT-RECORDING-STREAM T T)) (#() . #(#)) #<unused-arg> #<CLIM:APPLICATION-PANE CLIM-DEMO::NAMES {4955927D}> #<CLIM-DEMO::ADDRESS {499AC1F5}> ...) 8: ((FLET #:UPDATING-OUTPUT-CONTINUATION37 ) #<CLIM:APPLICATION-PANE CLIM-DEMO::NAMES {4955927D}>) 9: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL (CLIM:OUTPUT-RECORDING-STREAM T T T)) (#() . #(#)) #<unused-arg> #<CLIM:APPLICATION-PANE CLIM-DEMO::NAMES {4955927D}> #<Closure Over Function (FLET #:CONTINUATION14 CLIM-INTERNALS::%INVOKE-UPDATING) {48107FC1}> ...) 10: (CLIM-INTERNALS::%INVOKE-UPDATING #<CLIM:STANDARD-UPDATING-OUTPUT-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 #<CLIM-DEMO::ADDRESS {499AC1F5}> {48105185}> #<CLIM:APPLICATION-PANE CLIM-DEMO::NAMES {4955927D}> #<Closure Over Function (FLET #:UPDATING-OUTPUT-CONTINUATION37 ) {48103A39}>) -- Fred Gilham gilham(a)csl.sri.com Behold, how good and pleasant it is when brothers dwell in unity. It is like the precious oil upon the head, running down upon the beard, upon the beard of Aaron, running down on the collar of his robes. It is like the dew of Hermon, which falls on the mountains of Zion. For there the LORD has commanded the blessing, life for evermore. -Ps 133

2 3

[mcclim-devel] McCLIM hint on Paolo's cliki
by rpgoldman＠real-time.com 23 May '06

23 May '06

Paolo's cliki has the following McCLIM hint: ---------------------------------------------------------------------- Order of suggestions in completion menus If you pass to complete-from-possibilities a list of suggestions such as '(("First" 1) ("Second" 2) ("Third)), they are displayed in reverse order from top to bottom in completion menus, like this: Third Second First If this is not what you want, pass a list sorted in the opposite order. ---------------------------------------------------------------------- At the expense of causing some minor dislocation, isn't this something we should fix, instead of hacking around? Also, is this a place where the clim specification is deficient? I.e., does it underspecify the behavior? Should it tell us how a list of possibilities will be displayed by default (in absence of specific function arguments)? Thanks, R

3 2

[mcclim-devel] McCLIM, clisp and minor bug fixes on Win32.
by Philippe Brochard 20 May '06

20 May '06

Hi everybody, First of all, many thanks for your great work! I don't know if this has already been reported and as I read wrongs things about it, I just want to say that McCLIM works perfectly with CLisp [1] under Windows XP (at least) and Xming [2]. I just have to patch Goatee/goatee-command.lisp to have a working Delete key. (patch attached on this mail). Here is what I've done: 1) Install CLisp and Xming. 2) Set the display (in a terminal) $ set display=localhost:0.0 3) Compile clx (I got the source in the clisp source): CLISP> (load "/clisp/source/clx/mit-clx/defsystem.lisp") CLISP> (without-package-lock () (compile-clx)) CLISP> (without-package-lock () (load-clx)) ; not necessarily useful 4) Get a copy of McCLIM and spatial-trees CLISP> (load "mcclim/spatial-trees/spatial-trees.asd") CLISP> (load "mcclim/mcclim.asd") CLISP> (without-package-lock () (asdf:oos 'asdf:load-op :mcclim)) 5) Build the listener CLISP> (asdf:oos 'asdf:load-op :clim-listener) 6) And build a demo CLISP> (load (compile-file "mcclim/Examples/clim-fig.lisp")) CLISP> (clim-demo::clim-fig) and here is the result : http://hocwp.free.fr/temp/clim-fig.png I've also been able to build my main app (cl-wav-synth) and it works like a charm :) http://hocwp.free.fr/temp/cl-wav-synth-win.png http://hocwp.free.fr/temp/cl-wav-synth-win-2.png Hope that can help. Best regards, Philippe [1] http://clisp.cons.org [2] http://freedesktop.org/wiki/Xming -- Philippe Brochard <hocwp(a)free.fr> http://hocwp.free.fr -=-= http://www.gnu.org/home.fr.html =-=- 291c291,293 < (add-gesture-command-to-table '(#-openmcl #\Delete #+openmcl #\DEL) --- > (add-gesture-command-to-table '(#-(or openmcl (and clisp win32)) #\Delete > #+openmcl #\DEL > #+(and clisp win32) #\Rubout) 339c341,343 < (add-gesture-command-to-table '(#\delete :meta) --- > > (add-gesture-command-to-table '(#-(and clisp win32) #\delete > #+(and clisp win32) #\rubout :meta) 342c346,348 < (add-gesture-command-to-table '(#\delete :control) --- > > (add-gesture-command-to-table '(#-(and clisp win32) #\delete > #+(and clisp win32) #\rubout :control)

1 0

[mcclim-devel] error in transform-region
by Irene DURAND 18 May '06

18 May '06

Hello, I had not updated my mcclim since April 7. I did it today and my software Autowrite doesn't execute anymore. The stack is as below. Has anyone any idea of what can be wrong? Thanks, Irène ---------------------------------------------------------------------------------------------------------------------------------------- The value NIL is not of type (SIMPLE-ARRAY REAL (4)). [Condition of type TYPE-ERROR] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B3F9909}>) Backtrace: 0: ((SB-PCL::FAST-METHOD TRANSFORM-REGION (T STANDARD-RECTANGLE)) (#(NIL 0) . #()) #<unavailable argument> #<CLIM-INTERNALS::STANDARD-TRANSLATION 1 0 0 1 0 250> (#<STANDARD-BOUNDING-RECTANGLE X 0:634 Y 0:150 {BA8A089}>)) 1: (CLIM-INTERNALS::UPDATE-MIRROR-GEOMETRY #<HRACK-PANE "(Unnamed Pane)" {C394211}>) 2: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<STANDARD-BOUNDING-RECTANGLE X 0:634 Y 0:150 {BA8A089}> #<HRACK-PANE "(Unnamed Pane)" {C394211}>) 3: ((SB-PCL::FAST-METHOD ALLOCATE-SPACE :AROUND (CLIM-INTERNALS::LAYOUT-PROTOCOL-MIXIN T T)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD ALLOCATE-SPACE #)> :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (3)) :ARG-INFO (3)) #<HRACK-PANE "(Unnamed Pane)" {C394211}> 634 150) 4: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) #<unavailable argument> #<VRACK-PANE "(Unnamed Pane)" {C2F1521}> 634 550) 5: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/HORIZONTALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 31) . #()) #<unavailable argument> #<HRACK-PANE "(Unnamed Pane)" {C2F1789}> 634 550) 6: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) #<unavailable argument> #<VRACK-PANE "(Unnamed Pane)" {C0CE1D1}> 634 550) 7: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/HORIZONTALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 31) . #()) #<unavailable argument> #<HRACK-PANE "(Unnamed Pane)" {C2F1779}> 1071 550) 8: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) #<unavailable argument> #<VRACK-PANE "(Unnamed Pane)" {C2F1239}> 1071 602) 9: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) #<unavailable argument> #<VRACK-PANE "(Unnamed Pane)" {C0EA699}> 1071 606) 10: ((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 {B713969}> 1071 606) 11: ((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 {C14CF61}> #<VISU-AW {BCDDE09}>) 12: ((SB-PCL::FAST-METHOD ADOPT-FRAME (FRAME-MANAGER APPLICATION-FRAME)) (#(NIL 1 13 11) . #()) #<unavailable argument> #<CLIM-CLX::CLX-FRAME-MANAGER {C14CF61}> #<VISU-AW {BCDDE09}>) 13: ((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 {C14CF61}> #<VISU-AW {BCDDE09}>) 14: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL :AROUND (APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL #)> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<VISU-AW {BCDDE09}> NIL) 15: (INTERFACE) 16: (SB-INT:EVAL-IN-LEXENV (START) #<NULL-LEXENV>) 17: (SWANK::EVAL-REGION "(start) " T) 18: ((LAMBDA NIL)) 19: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) #<unused argument> #<unused argument> #<CLOSURE (LAMBDA NIL) {B846B9D}>) 20: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA NIL) {B846B9D}>) 21: (SB-INT:EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(start) ") #<NULL-LEXENV>) 22: ((LAMBDA NIL)) 23: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {B846395}>) 24: ((LAMBDA NIL)) 25: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL) {AC8E40D}>) 26: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {B2759C9}> #<CLOSURE (LAMBDA NIL) {B846245}>) 27: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {B2759C9}> #<FUNCTION (LAMBDA NIL) {AC8E40D}>) 28: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {B2759C9}>) 29: ((LAMBDA NIL)) 30: ((LAMBDA NIL)) 31: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {B40C0B5}>) 32: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {B2759C9}> #<CLOSURE (LAMBDA NIL) {B40C0C5}>) 33: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {B2759C9}> #<CLOSURE (LAMBDA NIL) {B40C0B5}>) 34: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA NIL) {B40C095}>) 35: ((LAMBDA NIL)) 36: ("foreign function: call_into_lisp") 37: ("foreign function: funcall0") 38: ("foreign function: new_thread_trampoline") 39: ("foreign function: #x53EB80") -- Irène DURAND http://dept-info.labri.u-bordeaux.fr/~idurand

1 0

[mcclim-devel] trivial patch to OpenMCL support
by Eric Marsden 13 May '06

13 May '06

Hi, The following trivial patch is required for recent versions of OpenMCL, that have dropped the :mcl *feature*. Index: package.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/package.lisp,v retrieving revision 1.54 diff -u -r1.54 package.lisp --- package.lisp 30 Mar 2006 12:07:59 -0000 1.54 +++ package.lisp 13 May 2006 14:23:46 -0000 @@ -220,7 +220,7 @@ `(#+clisp ,@'(:gray) #+cmu ,@'(:ext) #+scl ,@'(:ext) - #+mcl ,@'(:ccl) + #+(or mcl openmcl) ,@'(:ccl) #+allegro ,@'(:common-lisp :excl :stream) #+harlequin-common-lisp ,@'(:stream) #+sbcl ,@'(:sb-gray))) ) -- Eric Marsden

1 0

[mcclim-devel] trac? (other plans?)
by Christophe Rhodes 12 May '06

12 May '06

Hi, Common-lisp.net relatively newly supports trac. Should we take advantage of it for a bug tracker? I suppose we should listen to Paolo in particular, who has heroically been wrestling with his bug list on McCLiki -- Paolo, do you think trac would make that part of it easier? Also, I've heard (and encouraged) mutterings from our intrepid Release Manager about a Pentecost Sunday McCLIM release (that's June 4th this year). Does anyone have half-baked work that they'd like to integrate? (Not that we would necessarily need to to have a nice set of release notes: an even partly-working gtk backend might encourage some interest...) Cheers, Christophe

2 1

[mcclim-devel] scrollbars and :command-loop
by Christophe Rhodes 12 May '06

12 May '06

Hi, I have an application pane with :display-time :command-loop, inside a (scrolling ...) form. For the most part, in this application, it is likely that the contents of this pane after a redisplay are similar to those before: so, I would like to be able to preserve the viewport position across redisplays. I've come up with the following method on redisplay-frame-pane: (defmethod redisplay-frame-pane :around ((frame gsharp) (pane gsharp-pane) &key force-p) (declare (ignore force-p)) (let ((transformation (sheet-transformation pane))) (multiple-value-bind (x y) (window-viewport-position pane) (multiple-value-bind (x1 y1) (untransform-position transformation x y) (call-next-method) (setf (window-viewport-position pane) (values x1 y1)))))) which meets the spec, I suppose -- I don't know how well-defined it is, but it does what I wanted it to in McCLIM. However, it leads to visual artifacts: the call-next-method here eventually calls (window-clear), which resets the space-requirements and the transformation of the sheet, which means the scrollbars change size; then the whole of the redraw takes place, and only then does the viewport's position get reset. My question then is twofold. Firstly, is this a sensible thing to be doing at all, or is there some other mechanism for achieving what I want here? (Incremental redisplay might be it, but that has some other problems in this application). Secondly, is there a way of eliminating these glitches? Cheers, Christophe

2 2

[mcclim-devel] trivial sbcl/osx gtkairo patch
by Cyrus Harmon 07 May '06

07 May '06

The following patch allows me to at least launch climacs w/ gtkairo. It doesn't quite work as the Escape key maps to { instead of Escape for some reason, but it looks pretty. Oh, the /opt/local/lib/ is the darwinports lib location. The CFFI guys probably have a better way to do this. Cyrus Index: Backends/gtkairo/gtk-ffi.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/gtkairo/gtk-ffi.lisp,v retrieving revision 1.5 diff -u -r1.5 gtk-ffi.lisp --- Backends/gtkairo/gtk-ffi.lisp 2 May 2006 13:00:12 -0000 1.5 +++ Backends/gtkairo/gtk-ffi.lisp 3 May 2006 16:44:41 -0000 @@ -19,12 +19,19 @@ (in-package :clim-gtkairo) -#-(or win32 mswindows windows) +#-(or win32 mswindows windows darwin) (eval-when (:compile-toplevel :load-toplevel :execute) (cffi:load-foreign-library "libcairo.so") (cffi:load-foreign-library "libgthread-2.0.so") (cffi:load-foreign-library "libgtk-x11-2.0.so")) +#+darwin +(eval-when (:compile-toplevel :load-toplevel :execute) + (pushnew "/opt/local/lib/" cffi:*foreign-library-directories*) + (cffi:load-foreign-library "libcairo.dylib") + (cffi:load-foreign-library "libgthread-2.0.dylib") + (cffi:load-foreign-library "libgtk-x11-2.0.dylib")) + #+(or win32 mswindows windows) (eval-when (:compile-toplevel :load-toplevel :execute) (cffi:load-foreign-library "libcairo-2.dll")

2 1

[mcclim-devel] mcclim destorys clx on ACL 6.2
by Max-Gerd Retzlaff 05 May '06

05 May '06

Hi, I've just updated my McCLIM to the lastest CVS version. When I now load McClim into the generic ACL 6.2 image even a simple CLX demo like XLIB::JUST-SAY-LISP doesn't work anymore. (Before the loading of McClim it does). Sadly, my last previous cvs update on this particular machine seems to be as long as five month ago, so it is probably a bit hard to find the particular commit to the CVS.. Are they any other ACL 6.2 users who use CVS McCLIM and who have noticed this problem? Bye, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> http://blog.matroid.org For your amusement: Old age and treachery will overcome youth and skill.

4 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel May 2006