May 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] 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