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

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] follow-up about format-graph-from-roots question
by rpgoldman＠real-time.com 26 Jun '06

26 Jun '06

Seems like this may be more a problem with scrolling panes than with format-graph-from-roots. Previously, I incorrectly reported that I was having trouble with the built-in graph types, but not with my own. That was wrong --- it seemed to be true only because my graphs were smaller. So it now seems that the problem arises with any graph that is installed inside an application pane with :scroll-bars :both. Has anyone else seen problems with scrolling application panes, either especially with graphs in them or just in general? I am starting to suspect that my change-space-requirements fu is weak.... thanks, R

1 0

[mcclim-devel] for bears of very little brain (pathname accepter w/ completion)
by rpgoldman＠real-time.com 26 Jun '06

26 Jun '06

Is there anywhere a completing read for pathnames, possibly with type defaults? I know that mgr has a nice file-selector-gadget, but I'm a little reluctant to use it, since it's still not fused with McCLIM proper (unless that's changed?). I think also that there's something inside CLIMACS, but it hasn't been freed up for more generic McCLIM use (or has it?). Thanks, R

1 0

[mcclim-devel] questions about space requirements and graph layout
by rpgoldman＠real-time.com 26 Jun '06

26 Jun '06

I was careless and did not check up on my application that used graph layout while a couple of rounds of changes were made. Now I find that my application is all stuffed up, and I was hoping that someone could make some suggestions. In particular: 1. My old code would draw graphs, and at the end of each graph-drawing function would invoke: (change-space-requirements stream :min-width (bounding-rectangle-width rect) :min-height (bounding-rectangle-height rect)) In the past this seemed to Do The Right Thing: the application pane (at the top, over an interactor pane) would get larger, and scroll bars would appear as needed. Now, however, something that seems very wrong to me happens, viz: a. I stretch the frame larger than its original size. b. I invoke a graph drawer. c. The frame resizes itself to its original size. My conjecture is that the effect of changing space requirements may have changed. Weirdly, the space requirement is now: [1i] GRAPH-MDP(74): :i 22 A NEW CLIMI::STANDARD-SPACE-REQUIREMENT @ #x881c250a = #<CLIMI::STANDARD-SPACE-REQUIREMENT width: 0.0d0 [0.0d0,100000000] height: 0.0d0 [0.0d0,100000000]> 0 Class --------> #<STANDARD-CLASS CLIMI::STANDARD-SPACE-REQUIREMENT> 1 WIDTH --------> double-float = 0.0d0 [#x00000000 00000000] 2 MAX-WIDTH ----> fixnum 100000000 [#x17d78400] 3 MIN-WIDTH ----> double-float = 0.0d0 [#x00000000 00000000] 4 HEIGHT -------> double-float = 0.0d0 [#x00000000 00000000] 5 MAX-HEIGHT ---> fixnum 100000000 [#x17d78400] 6 MIN-HEIGHT ---> double-float = 0.0d0 [#x00000000 00000000] although the current-width is 6952.0 and the current-height is 4261.5. I was considering that perhaps I should have been changing the width and height slots of the space-requirement instead of min- values, but (a) this used to work and (b) it seems like none of my changed space requirements are "taking." Here's what happens when I trace change-space-requirements: 0[9]: (CLIM:CHANGE-SPACE-REQUIREMENTS #<CLIM:APPLICATION-PANE SIFT.MDP:MDP @ #x72d0bc22> :WIDTH 6952.0 :HEIGHT 4261.5 :MIN-WIDTH 6952.0 :MIN-HEIGHT 4261.5) 0* (CALL-METHOD #<STANDARD-METHOD CLIM:CHANGE-SPACE-REQUIREMENTS :AROUND (CLIM:CLIM-STREAM-PANE)> ((MULTIPLE-VALUE-PROG1 (PROGN #<STANDARD-METHOD CLIM:CHANGE-SPACE-REQUIREMENTS :BEFORE (CLIM-INTERNALS::SPACE-REQUIREMENT-OPTIONS-MIXIN)> #<STANDARD-METHOD CLIM:CHANGE-SPACE-REQUIREMENTS :BEFORE (CLIM-INTERNALS::LAYOUT-PROTOCOL-MIXIN)> #<STANDARD-METHOD CLIM:CHANGE-SPACE-REQUIREMENTS (CLIM-INTERNALS::LAYOUT-PROTOCOL-MIXIN)>) #<STANDARD-METHOD CLIM:CHANGE-SPACE-REQUIREMENTS :AFTER (CLIM-INTERNALS::LAYOUT-PROTOCOL-MIXIN)>))) 1[9]: (CLIM:CHANGE-SPACE-REQUIREMENTS #<CLIM-EXTENSIONS:VIEWPORT-PANE "(Unnamed Pane)" @ #x72d0c35a> :RESIZE-FRAME NIL) 1* (MULTIPLE-VALUE-PROG1 (PROGN #<STANDARD-METHOD CLIM:CHANGE-SPACE-REQUIREMENTS :BEFORE (CLIM-INTERNALS::SPACE-REQUIREMENT-OPTIONS-MIXIN)> #<STANDARD-METHOD CLIM:CHANGE-SPACE-REQUIREMENTS :BEFORE (CLIM-INTERNALS::LAYOUT-PROTOCOL-MIXIN)> #<STANDARD-METHOD CLIM:CHANGE-SPACE-REQUIREMENTS (CLIM-EXTENSIONS:VIEWPORT-PANE)>) #<STANDARD-METHOD CLIM:CHANGE-SPACE-REQUIREMENTS :AFTER (CLIM-INTERNALS::LAYOUT-PROTOCOL-MIXIN)>) 1[9]: returned NIL 0[9]: returned NIL Possibly the information about the space requirements is not properly percolating up from the application-pane to its enclosing viewport-pane? [1i] GRAPH-MDP(85): :i A TENURED CLIM-EXTENSIONS:VIEWPORT-PANE @ #x72d0c35a = #<CLIM-EXTENSIONS:VIEWPORT-PANE "(Unnamed Pane)" @ #x72d0c35a> 0 Class --------> #<STANDARD-CLASS CLIM-EXTENSIONS:VIEWPORT-PANE> 1 REGION -------> #<STANDARD-BOUNDING-RECTANGLE X 0:646.0d0 Y 0:590 @ #x735b3e8a> 2 NATIVE-TRANSFORMATION -> #<CLIMI::STANDARD-IDENTITY-TRANSFORMATION 1 0 0 1 0 0> 3 NATIVE-REGION -> #<STANDARD-RECTANGLE X 0:646.0d0 Y 0:590 @ #x735b3e9a> 4 DEVICE-TRANSFORMATION -> The symbol NIL 5 DEVICE-REGION -> The symbol NIL 6 POINTER-CURSOR -> The symbol :DEFAULT 7 ENABLED-P ----> The symbol T 8 CURRENT-WIDTH -> The symbol NIL 9 CURRENT-HEIGHT -> The symbol NIL 10 TRANSFORMATION -> #<CLIMI::STANDARD-TRANSLATION 1 0 0 1 4 4> 11 QUEUE --------> #<CLIMI::PORT-EVENT-QUEUE @ #x72d06c52> 12 NAME ---------> A simple-string (14) "(Unnamed Pane)" 13 MANAGER ------> #<CLIM-CLX::CLX-FRAME-MANAGER @ #x72c0b642> 14 FRAME --------> #<TAEMS-MDP-APP @ #x72ceb5b2> 15 ENABLEDP -----> The symbol NIL 16 SPACE-REQUIREMENT -> The symbol NIL 17 NEW-WIDTH ----> The symbol NIL 18 NEW-HEIGHT ---> The symbol NIL 19 REDISPLAY-NEEDED -> The symbol NIL 20 PORT ---------> #<CLIM-CLX::CLX-PORT :HOST "" :DISPLAY-ID 0 @ #x72c02ada> 21 MIRROR-TRANSFORMATION -> #<CLIMI::STANDARD-TRANSLATION 1 0 0 1 4 4> 22 MIRROR-REGION -> #<STANDARD-RECTANGLE X 0:646 Y 0:590 @ #x735b3eca> 23 PARENT -------> #<SCROLLER-PANE "(Unnamed Pane)" @ #x72d0c7aa> 24 USER-WIDTH ---> The symbol NIL 25 USER-MIN-WIDTH -> The symbol NIL 26 USER-MAX-WIDTH -> The symbol NIL 27 USER-HEIGHT --> The symbol NIL 28 USER-MIN-HEIGHT -> The symbol NIL 29 USER-MAX-HEIGHT -> The symbol NIL 30 X-SPACING ----> fixnum 0 [#x00000000] 31 Y-SPACING ----> fixnum 0 [#x00000000] 32 FOREGROUND ---> #<CLIMI::NAMED-COLOR "black"> 33 BACKGROUND ---> #<CLIMI::NAMED-COLOR "gray84"> 34 TEXT-STYLE ---> #<STANDARD-TEXT-STYLE :FIX :ROMAN :NORMAL> 35 ALIGN-X ------> The symbol :LEFT 36 ALIGN-Y ------> The symbol :TOP 37 CHILD --------> #<APPLICATION-PANE MDP @ #x72d0bc22> [1i] GRAPH-MDP(86): :i 37 A TENURED APPLICATION-PANE @ #x72d0bc22 = #<APPLICATION-PANE MDP @ #x72d0bc22> 0 Class --------> #<STANDARD-CLASS APPLICATION-PANE> 1 MARKINGS -----> The symbol NIL 2 POINT-1-X ----> The symbol NIL 3 POINT-1-Y ----> The symbol NIL 4 POINT-2-X ----> The symbol NIL 5 POINT-2-Y ----> The symbol NIL 6 DRAGGING-P ---> The symbol NIL 7 REGION -------> #<STANDARD-BOUNDING-RECTANGLE X 0:6952.0 Y 0:4261.5 @ #x87f3415a> 8 NATIVE-TRANSFORMATION -> #<CLIMI::STANDARD-IDENTITY-TRANSFORMATION 1 0 0 1 0 0> 9 NATIVE-REGION -> #<STANDARD-RECTANGLE X 0:646.0d0 Y 0:590 @ #x87f34172> 10 DEVICE-TRANSFORMATION -> The symbol NIL 11 DEVICE-REGION -> #<STANDARD-RECTANGLE X 0:646.0d0 Y 0:590 @ #x87f34172> 12 POINTER-CURSOR -> The symbol :DEFAULT 13 ENABLED-P ----> The symbol T 14 CURRENT-WIDTH -> single-float = 6952.0 [#x45d94000] 15 CURRENT-HEIGHT -> single-float = 4261.5 [#x45852c00] 16 TRANSFORMATION -> #<CLIMI::STANDARD-IDENTITY-TRANSFORMATION 1 0 0 1 0 0> 17 QUEUE --------> #<CLIMI::PORT-EVENT-QUEUE @ #x72d06c52> 18 NAME ---------> The symbol MDP 19 MANAGER ------> #<CLIM-CLX::CLX-FRAME-MANAGER @ #x72c0b642> 20 FRAME --------> #<TAEMS-MDP-APP @ #x72ceb5b2> 21 ENABLEDP -----> The symbol NIL 22 SPACE-REQUIREMENT -> #<CLIMI::STANDARD-SPACE-REQUIREMENT width: 0.0d0 [0.0d0,100000000] height: 0.0d0 [0.0d0,100000000]> 23 NEW-WIDTH ----> The symbol NIL 24 NEW-HEIGHT ---> The symbol NIL 25 PORT ---------> #<CLIM-CLX::CLX-PORT :HOST "" :DISPLAY-ID 0 @ #x72c02ada> 26 MIRROR-TRANSFORMATION -> #<CLIMI::STANDARD-IDENTITY-TRANSFORMATION 1 0 0 1 0 0> 27 MIRROR-REGION -> #<STANDARD-RECTANGLE X 0:3799 Y 0:2425 @ #x87f341c2> 28 PARENT -------> #<CLIM-EXTENSIONS:VIEWPORT-PANE "(Unnamed Pane)" @ #x72d0c35a> 29 X-SPACING ----> fixnum 0 [#x00000000] 30 Y-SPACING ----> fixnum 0 [#x00000000] 31 ALIGN-X ------> The symbol :LEFT 32 ALIGN-Y ------> The symbol :TOP 33 CHILDREN -----> The symbol NIL 34 RECORDING-P --> The symbol T 35 DRAWING-P ----> The symbol T 36 OUTPUT-HISTORY -> #<STANDARD-TREE-OUTPUT-HISTORY X 0.0d0:6952.0 Y 0.0d0:4261.5 @ #x72d0c36a> 37 CURRENT-OUTPUT-RECORD -> #<STANDARD-TREE-OUTPUT-HISTORY X 0.0d0:6952.0 Y 0.0d0:4261.5 @ #x72d0c36a> 38 CURRENT-TEXT-OUTPUT-RECORD -> The symbol NIL 39 LOCAL-RECORD-P -> The symbol T ... 123 (MISC C APPLICATION-PANE) -> #<Function STM-FUNDAMENTAL-MISC> 2. I have three flavors of layouts, two use the built in graph types, and one uses my own, experimental tree-with-cross-edges graph subtype. Previously they all three worked (for some definition of "worked," that does not extend to "lays out graphs in an aesthetically-pleasing way :->). Now only my own tree-with-cross-edges works; the other two seem to display nothing, although I can see a traced call to format-graph-from-roots, I find reasonable bounds (which *should* trigger the addition of scroll bars, AFAICT), and if I take a long and laborious trip down into the guts of the pane's output record, I find a CLIMI::DAG-GRAPH-OUTPUT-RECORD inside a STANDARD-SEQUENCE-OUTPUT-RECORD inside a STANDARD-UPDATING-OUTPUT-RECORD. As I said, this used to work, but alas, that was even before the addition of spatial-trees, so I'm not sure where this went south. Any suggestions about how I might figure out why this is not showing up? Actually, it might be as simple as the graph being so large that none of it actually appears in the part of the pane that is actually displayed... So perhaps the answer to this question reduces to answering question 1...

1 0

[mcclim-devel] interactive-stream-p
by Christophe Rhodes 23 Jun '06

23 Jun '06

Hi, The Gray stream function interactive-stream-p is "specified" in CLIM. Would it be reasonable to make it return T for most of the extended streams that CLIM provides and NIL for postscript streams (and potentially other batched output streams such as pdf, when a backend for that shows up)? At present I believe it returns NIL for everything. The use case I have is being able to use the same drawing routine for screen and print, customizing behaviour based on the value of (interactive-stream-p stream). Cheers, Christophe

2 1

[mcclim-devel] Loading CLX for McCLIM
by Christopher Johnson 20 Jun '06

20 Jun '06

One more thing. How do I load a backend or frame manager for McCLIM? Hello-world now errors with: No CLIM backends have been loaded! [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (CLIM-INTERNALS::FIND-DEFAULT-SERVER-PATH) 1: (FIND-PORT :SERVER-PATH NIL) 2: (FIND-FRAME-MANAGER) 3: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL I'm very new to lisp and clim, and I really appreciate your help. -- Chris Johnson Christopher.A.Johnson(a)gmail.com

2 1

[mcclim-devel] McCLIM/CLX on MacOS X
by Christopher Johnson 18 Jun '06

18 Jun '06

Working through the hello-world example in "A guided tour of CLIM 2006", I get an error. I think I need to do more CLX setup for MacOS X, but I'm unsure how to proceed. The error is below. Any help would be appreciated. The value NIL is not of type NUMBER. [Condition of type TYPE-ERROR] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (CLIM-CLX::PARSE-CLX-SERVER-PATH #<unavailable argument>) 1: (FIND-PORT :SERVER-PATH NIL) 2: (FIND-FRAME-MANAGER) 3: ((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)) #<HELLO-WORLD {1387D819}> NIL) 4: (SB-INT:EVAL-IN-LEXENV (RUN-FRAME-TOP-LEVEL (MAKE-APPLICATION-FRAME (QUOTE HELLO-WORLD))) -- Chris Johnson Christopher.A.Johnson(a)gmail.com

4 3

[mcclim-devel] pointer-butt missing (mcclim 0.9.2)
by Eric Y. Kow 09 Jun '06

09 Jun '06

Dear McClim developers, While trying to install McClim on clisp/Mac OS X, I get two errors which might interest you. I send you this bug report upon #lisp/antifuchs' advice. Thanks! Summary ------- package gray is locked DEFMETHOD POINTER-BUTT: missing lambda list Context ------- I'm just a user, really. All I want to do is run the software KPML (http://www.purl.org/net/kpml) which claims to want a CLIM. Attached -------- my .clisprc the error log Platform -------- Mac OS X 10.4.6 (powerpc) clisp 2.38 asdf revision 1.98 spatial-trees 0.2 mcclim 0.9.2 My (darwinports) CLISP ---------------------- GNU CLISP 2.38 (2006-01-24) (built 3358753487) (memory 3358754081) Software: GNU C 4.0.0 20041026 (Apple Computer, Inc. build 4061) gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -DUNIX_BINARY_DISTRIB -DUNICODE -I. -L/opt/local/lib -L/opt/local/lib -x none -lintl -liconv -lc -Wl,-framework -Wl,CoreFoundation libcharset.a -lreadline -lncurses -liconv -L/opt/local/lib -lsigsegv -lc -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES STANDARD_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY libiconv 1.10 libreadline 5.0 Features: (REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER UNIX MACOS) C Modules: (clisp i18n syscalls regexp) Installation directory: /opt/local/lib/clisp/ User language: ENGLISH Machine: POWER MACINTOSH (POWER MACINTOSH) -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français.

2 1

[mcclim-devel] coordinate-epsilon defined twice
by Robert Strandh 07 Jun '06

07 Jun '06

Hello, In coordinates.lisp, the function coordinate-epsilon is first defined to return a value greater than 0, and then redefined to return 0 (and to be inlined). Having that function return 0 causes a lot of problem in my Bezier region code, and it is surely not what was intended. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------

1 0

[mcclim-devel] "bug" report: old style eval-when causes warnings in SBCL
by Robert Strandh 07 Jun '06

07 Jun '06

Hello, I have found two occurrences in McCLIM of old-style EVAL-WHEN: 1. In graphics.lisp, line 871 in a macro body, which means that everyone using that macro will get the warning message 2. In design.lisp, line 274 in a format control string, which I guess is less serious. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------

1 0