From mcclim-devel at common-lisp.net Sun Sep 2 18:52:04 2007 From: mcclim-devel at common-lisp.net (McCLIM developers) Date: Sun, 02 Sep 2007 20:52:04 +0200 Subject: [mcclim-devel] McCLIM 0.9.5 "Eastern Orthodox Liturgical New Year" released! Message-ID: <46DB0654.40800@common-lisp.net> The McCLIM developers are happy to release version 0.9.5 of McCLIM, code-named "Eastern Orthodox Liturgical New Year". This release includes many important bug fixes. There have been stability and reliability improvements to the core CLIM implementation, to the backends, and to the editor substrate "Drei", which we introduced in the last release. When testing this release, we found that it works on the following implementations: * SBCL * OpenMCL * CLISP * Allegro Common Lisp 8.0 in ANSI Mode For compatibility with other implementations, please see the attached release notes. Get the tarball at . Alternatively, you can install McCLIM via asdf-install. We are looking forward to your comments and bug reports. Please send them to mcclim-devel at common-lisp.net. The list of currently known bugs can be found at . Have fun using McCLIM, The McCLIM developers. RELEASE NOTES FOR McCLIM 0.9.5, "Eastern Orthodox Liturgical New Year": Compatibility ============= This release was tested and found to work on the following implementations: * SBCL * OpenMCL * CLISP (requires "Telent" CLX) * Allegro Common Lisp 8.0 in ANSI Mode In our tests, this release of McCLIM did not work on the following implementations: * CMUCL (at the time of this release, the released CMUCL has a bug that prevents successful loading of McCLIM; CMUCL 19d + patch 1 and the 2006-12 snapshot or later contain a fix for this problem) Also, McCLIM currently does not support lisps with case-sensitive readers (Allegro CL "modern mode" and lower-case Scieneer CL). Changes in mcclim-0.9.5 "Eastern Orthodox Liturgical New Year" relative to 0.9.4: ============================================================== >From the NEWS file: * Changes in mcclim-0.9.5 relative to 0.9.4: ** Installation: the systems clim-listener, clim-examples, and clouseau can now be loaded without loading the system mcclim first. Users with existing McCLIM installations should use the provided script: ./symlink-asd-files.sh /path/to/asdf-central-registry/ ** New extension: tab-layout. This extension allows keeping a stack of panes whose foreground pane is controlled by a tab bar. This layout can be customized in backends and frame managers. For examples, see the gtkairo backend and the pixie frame manager. ** New extension function: SHEET-RGB-IMAGE: makes a screenshot of a sheet in the CLX backend. (Supported on truecolor visuals only for now.) ** New experimental extension: tree-with-cross-edges are an extension to the graph formatter. ** New experimental backend: clim-graphic-forms: native widgets on Windows. This backend is still very experimental (it doesn't run demos yet). ** New inspector feature: The inspector now displays more useful information about hash tables and generic functions. ** Specification compliance: Various layout panes no longer quite as aggressive at eating the space requirements of their children. ** Specification compliance: There is now a rudimentary implementation of NOTIFY-USER ** Usability: Text editors and text input panes now use click-to-focus. ** Improvement: the ACCEPTING-VALUES command table was renamed to ACCEPT-VALUES (as this is the name that the other clim-2 implementation uses) ** Improvement: the CLX backend should no longer cause focus stealing when an application has text-editor panes. This change comes with a rudimentary click-to-focus-keyboard widget policy. ** Improvement: define-application-frame now allows a :default-initargs option. (This is not exactly a "specification compliance" fix, as d-a-frame is not defined to accept this option.). ** Improvement: menu-choose menus now look a little prettier. ** Improvement: added more styles for bordered-output: :rounded, :ellipse ** Improvement: Toggle button values now default to NIL. ** Improvement: Frame layouts are now inherited from the frame's superclass. ** Improvement: The Lisp Syntax is much improved: now recognizes delimiter characters, and more types of Lambda lists. ** Bug fix: Bezier designs should now draw in the right place in all backends. ** Bug fix: Text in Drei no longer "walks" to the left. ** Bug fix: Drei now has better support for delimiter gestures. ** Bug fix: Partial commands now work better when invoked from the menu. From rpgoldman at real-time.com Tue Sep 4 18:44:39 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Tue, 04 Sep 2007 13:44:39 -0500 Subject: [mcclim-devel] trac credentials Message-ID: <46DDA797.40702@real-time.com> Will someone be so kind as to drop me a line and tell me how to get trac credentials set up? I have found a bug or two that I would like to enter in the database. Speaking of which, would it be appropriate to make it easier to enter tickets? Should we perhaps offer the ability to create a new account while online? Or should we put something on the mcclim trac homepage to explain how one creates an account? Seems like we should be trying to get all the good bug reports we can get our hands on... Best, r From lnp at healy.washington.dc.us Wed Sep 12 18:27:52 2007 From: lnp at healy.washington.dc.us (Liam Healy) Date: Wed, 12 Sep 2007 14:27:52 -0400 Subject: [mcclim-devel] Can't load gtkairo; unknown CFFI type Message-ID: <654935030709121127x39b36c98x7bed871c51d38651@mail.gmail.com> I am trying mcclim and cffi from Debian unstable in SBCL. I cannot load gtkairo CL-USER(1): (require :mcclim) ; loading system definition from /usr/share/common-lisp/systems/flexichain.asd ; into # ; registering # as FLEXICHAIN ; loading system definition from ; /usr/share/common-lisp/systems/spatial-trees.asd into # ; registering # as SPATIAL-TREES ; loading system definition from /usr/share/common-lisp/systems/clx.asd into ; # ; registering # as CLX NIL CL-USER(2): (require :clim-gtkairo) ; compiling file "/usr/share/common-lisp/source/mcclim/Backends/gtkairo/gtk- ffi.lisp" (written 03 MAR 2007 07:09:51 AM): ; compiling (IN-PACKAGE :CLIM-GTKAIRO) ; compiling (CFFI:DEFCTYPE UTF8-STRING ...) debugger invoked on a SIMPLE-ERROR in thread #: Unknown CFFI type: (:STRING :ENCODING :UTF-8). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing # on #. 1: [ACCEPT] Continue, treating # on # as having been successful. 2: [ABORT ] Exit debugger, returning to top level. (CFFI::PARSE-TYPE (:STRING :ENCODING :UTF-8)) 0] ii cl-cffi 20061013-1 The Common Foreign Function Interface for Common Lisp ii cl-mcclim 0.9.5.dfsg.1-1 Common Lisp graphic user interface toolkit Is the CFFI too old here? Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at lichteblau.com Wed Sep 12 19:27:13 2007 From: david at lichteblau.com (David Lichteblau) Date: Wed, 12 Sep 2007 21:27:13 +0200 Subject: [mcclim-devel] Can't load gtkairo; unknown CFFI type In-Reply-To: <654935030709121127x39b36c98x7bed871c51d38651@mail.gmail.com> References: <654935030709121127x39b36c98x7bed871c51d38651@mail.gmail.com> Message-ID: <20070912192713.GE8553@radon> Quoting Liam Healy (lnp at healy.washington.dc.us): > I am trying mcclim and cffi from Debian unstable in SBCL. I cannot load > gtkairo This version of cffi works for me: http://common-lisp.net/~loliveira/soc07/cffi+grovel+babel+stuff/ d. From rpgoldman at real-time.com Sun Sep 16 16:26:47 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Sun, 16 Sep 2007 11:26:47 -0500 Subject: [mcclim-devel] Proposed patch to format-graph-from-roots Message-ID: <46ED5947.6040600@real-time.com> A discussion on #lisp the other day pointed out that destructively modifying &rest argument lists is not kosher. format-graph-from-roots does just that. Would anyone object to me committing the following patch? --- graph-formatting.lisp 4 Mar 2007 22:26:22 -0000 1.20 +++ graph-formatting.lisp 16 Sep 2007 16:25:26 -0000 @@ -115,9 +115,11 @@ (define-graph-type :directed-graph digra (define-graph-type :digraph digraph-graph-output-record) ;;;; Entry +(defun format-graph-from-root (root-object &rest other-args) + (apply #'format-graph-from-roots (list root-object) other-args)) (defun format-graph-from-roots (root-objects object-printer inferior-producer - &rest graph-options + &rest rest-args &key stream orientation cutoff-depth merge-duplicates duplicate-key duplicate-test generation-separation @@ -128,6 +130,9 @@ (defun format-graph-from-roots (root-obj graph-type (move-cursor t) &allow-other-keys) (declare (ignore orientation generation-separation within-generation-separation center-nodes)) + ;; we were destructively modifying the &rest arg, which isn't safe, + ;; so I introduced the copy-list [2007/09/07:rpg] + (let ((graph-options (copy-list rest-args))) ;; Mungle some arguments (check-type cutoff-depth (or null integer)) (check-type root-objects sequence) @@ -184,7 +189,7 @@ (defun format-graph-from-roots (root-obj (setf (stream-cursor-position stream) (values (bounding-rectangle-max-x graph-output-record) (bounding-rectangle-max-y graph-output-record)))) - graph-output-record))) + graph-output-record)))) (defun format-graph-from-root (root &rest rest) (apply #'format-graph-from-roots (list root) rest)) @@ -248,7 +253,7 @@ (defclass standard-graph-node-output-rec (object :initarg :object :reader graph-node-object) - ;; internal slots for the graph layout algorithmn + ;; internal slots for the graph layout algorithm (minor-size :initform nil :accessor graph-node-minor-size Best, R From csr21 at cantab.net Sun Sep 16 17:31:55 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Sun, 16 Sep 2007 18:31:55 +0100 Subject: [mcclim-devel] Proposed patch to format-graph-from-roots In-Reply-To: <46ED5947.6040600@real-time.com> (Robert Goldman's message of "Sun, 16 Sep 2007 11:26:47 -0500") References: <46ED5947.6040600@real-time.com> Message-ID: <877imqtt2s.fsf@cantab.net> Robert Goldman writes: > A discussion on #lisp the other day pointed out that destructively > modifying &rest argument lists is not kosher. format-graph-from-roots > does just that. > > Would anyone object to me committing the following patch? Not I. (Don't feel that you have to comment the change. Also perhaps s/mungle/munge/). Cheers, Christophe From csr21 at cantab.net Tue Sep 18 12:49:09 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Tue, 18 Sep 2007 13:49:09 +0100 Subject: [mcclim-devel] output-record-count and postscript new-page Message-ID: <871wcwqgu2.fsf@cantab.net> Hi, The following code produces an unexpected result in current McCLIM HEAD: (in-package :clim-user) (with-open-file (ps "/tmp/foo.ps" :direction :output :if-exists :supersede) (with-output-to-postscript-stream (s ps) (draw-rectangle* s 10 10 20 20) (new-page s) (draw-rectangle* s 30 30 40 40))) The reason is that the new-page output record is no longer contributing to the bounding rectangle of the stream output history, so that when the history is replayed (to actually write the postscript file) the new-page output records are not replayed. If instead the code is (with-open-file (ps "/tmp/foo.ps" :direction :output :if-exists :supersede) (with-output-to-postscript-stream (s ps) (draw-rectangle* s 10 10 20 20) (new-page s) (draw-rectangle* s 30 30 40 40) (new-page s) (draw-rectangle* s -5 -5 5 5))) You get the expected three pages (rather than the one you get when there is no drawn content around 0,0). This problem can be worked around by defining a method on output-record-count for tree output records which always returns 0: which suggests that the cases testing for output-record-count being eql to 1 (and then doing some optimized path) in recompute-extent-for-{new,changed}-child are optimized to the point of being wrong... Any ideas? Cheers, Christophe From ahefner at gmail.com Thu Sep 20 19:17:16 2007 From: ahefner at gmail.com (Andy Hefner) Date: Thu, 20 Sep 2007 15:17:16 -0400 Subject: [mcclim-devel] output-record-count and postscript new-page In-Reply-To: <871wcwqgu2.fsf@cantab.net> References: <871wcwqgu2.fsf@cantab.net> Message-ID: <31ffd3c40709201217q454ef04u1ce9c975c4c5bbe1@mail.gmail.com> My thoughts, attempting to be brief: 1. The current bounding rectangle behavior is correct and desirable (or if for some reason not correct, desirable anyway). 2. new-page-record is odd in that it exists in the output history but does not represent or contain any geometry. It does not exist in space. The tree output record doesn't really accommodate this, and any current semblance of working is accidental. I don't think the designers of CLIM considered such things either. I'm not sure it's a good idea, as it raises various issues.. 3. Though it doesn't affect this bug, map-over-output-records on tree output records is arguably broken at present. I would expect it to include new-page-records, but currently it does not. The -containing-position and -overlapping-region variants are correct to not include it (as these are spatial queries, and IMHO should not report empty, positionless objects). 4. Considering the above, and that replay uses map-over-output-records-overlapping-region, replay of new-page-records shouldn't be expected to work. Also, the constraints on order are too weak (records are only required by the spec to be reported in order of creation when they overlap - anyone know what our current behavior is here?). There are two ways I can imagine a hardcopy stream with pages working - either have a compound page-output-record class into which drawing for an individual page is contained, or take the approach implied by the CLIM spec, which is to force the generation of postscript when new-page is called, then clear the output history, so only one page at a time exists in the output history at a time. An alternative to using replay would be to traverse the output-record-children list directly, which is guaranteed to be in order. On 9/18/07, Christophe Rhodes wrote: > This problem can be worked around by defining a method on > output-record-count for tree output records which always returns 0: > which suggests that the cases testing for output-record-count being > eql to 1 (and then doing some optimized path) in > recompute-extent-for-{new,changed}-child are optimized to the point of > being wrong... I think the current behavior is correct, and (due to output-record-count lying to us) the previous answer was wrong. I haven't yet worked through exactly what was happening, why it didn't occur more often, and if it is the bug I note in recording.lisp. From asf at boinkor.net Sun Sep 23 00:06:12 2007 From: asf at boinkor.net (Andreas Fuchs) Date: Sun, 23 Sep 2007 02:06:12 +0200 Subject: [mcclim-devel] output-record-count and postscript new-page In-Reply-To: <31ffd3c40709201217q454ef04u1ce9c975c4c5bbe1@mail.gmail.com> References: <871wcwqgu2.fsf@cantab.net> <31ffd3c40709201217q454ef04u1ce9c975c4c5bbe1@mail.gmail.com> Message-ID: <46F5ADF4.4050802@boinkor.net> To get at the promised-by-Krystof beverages tomorrow, I've hacked up a patch for tree ORs that should fix things again. Andy Hefner wrote: > 2. new-page-record is odd in that it exists in the output history but > does not represent or contain any geometry. It does not exist in > space. The tree output record doesn't really accommodate this, and any > current semblance of working is accidental. I don't think the > designers of CLIM considered such things either. I'm not sure it's a > good idea, as it raises various issues.. Agreed. > 3. Though it doesn't affect this bug, map-over-output-records on tree > output records is arguably broken at present. I would expect it to > include new-page-records, but currently it does not. The > -containing-position and -overlapping-region variants are correct to > not include it (as these are spatial queries, and IMHO should not > report empty, positionless objects). Right. > 4. Considering the above, and that replay uses > map-over-output-records-overlapping-region, replay of new-page-records > shouldn't be expected to work. Also, the constraints on order are too > weak (records are only required by the spec to be reported in order of > creation when they overlap - anyone know what our current behavior is > here?). I agree, but to get something working, I've made a compromise: To consider null-BR children when +everywhere+ is queried. That is, to interpret questions about everywhere as questions about nowhere as well. The attached patch implements this, and yields the expected two pages of output from Christophe's first example. It runs the examples, but I can't say anything about its performance (-: > There are two ways I can imagine a hardcopy stream with pages working > - either have a compound page-output-record class into which drawing > for an individual page is contained, or take the approach implied by > the CLIM spec, which is to force the generation of postscript when > new-page is called, then clear the output history, so only one page at > a time exists in the output history at a time. That sounds enormously sensible. I would go with this. Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ,implement-ungeometric-tree-record-children.patch URL: From csr21 at cantab.net Fri Sep 28 09:27:41 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 28 Sep 2007 10:27:41 +0100 Subject: [mcclim-devel] output-record-count and postscript new-page In-Reply-To: <46F5ADF4.4050802@boinkor.net> (Andreas Fuchs's message of "Sun, 23 Sep 2007 02:06:12 +0200") References: <871wcwqgu2.fsf@cantab.net> <31ffd3c40709201217q454ef04u1ce9c975c4c5bbe1@mail.gmail.com> <46F5ADF4.4050802@boinkor.net> Message-ID: <87ps03kulu.fsf@cantab.net> Andreas Fuchs writes: > To get at the promised-by-Krystof beverages tomorrow, I've hacked up a > patch for tree ORs that should fix things again. Andreas and I met up last night, and we agreed that he didn't deserve a beer, because although his patch gets my page postscript test case right, it also causes every clim application we tested to deadlock on startup. Oh well :-) Cheers, Christophe From csr21 at cantab.net Sat Sep 29 09:27:41 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Sat, 29 Sep 2007 10:27:41 +0100 Subject: [mcclim-devel] ESA bug fixes Message-ID: <87d4w1zur6.fsf@cantab.net> Hi, Find attached a patch that fixes two things, I think: * C-h c and C-h w (describe-key-briefly and where-is) should use the command table as returned by find-applicable-command-table, not the one for (car (windows frame)); * In the search for commands matching a keystrokes, a symbol matches a one-element list whose element is that symbol. -------------- next part -------------- A non-text attachment was scrubbed... Name: esa.diff Type: text/x-diff Size: 2995 bytes Desc: esa bug fixes URL: -------------- next part -------------- Does this look right? Cheers, Christophe From jdunrue at gmail.com Sun Sep 30 19:07:41 2007 From: jdunrue at gmail.com (Jack Unrue) Date: Sun, 30 Sep 2007 13:07:41 -0600 Subject: [mcclim-devel] macrorecord-processed-gestures-mixin Message-ID: The above-mentioned class was removed in revision 1.8 of esa.lisp, but it is still listed as a super-class for asynchronous-command-processor. I'd like to check in the trivial cleanup. OK? Index: esa.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/ESA/esa.lisp,v retrieving revision 1.9 diff -r1.9 esa.lisp 471,472c471 < instant-macro-execution-mixin < macrorecord-processed-gestures-mixin) --- > instant-macro-execution-mixin) Index: packages.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/ESA/packages.lisp,v retrieving revision 1.3 diff -r1.3 packages.lisp 58c58 < #:command-processor #:instant-macro-execution-mixin #:macrorecord-processed-gestures-mixin --- > #:command-processor #:instant-macro-execution-mixin -- Jack Unrue From athas at sigkill.dk Sun Sep 30 22:04:28 2007 From: athas at sigkill.dk (Troels Henriksen) Date: Mon, 01 Oct 2007 00:04:28 +0200 Subject: [mcclim-devel] macrorecord-processed-gestures-mixin In-Reply-To: (Jack Unrue's message of "Sun, 30 Sep 2007 13:07:41 -0600") References: Message-ID: <878x6nero3.fsf@lambda.athas.dyndns.dk> "Jack Unrue" writes: > The above-mentioned class was removed in revision 1.8 of esa.lisp, > but it is still listed as a super-class for asynchronous-command-processor. > > I'd like to check in the trivial cleanup. OK? Oh, oops. I checked in a fix for it. -- \ Troels /\ Henriksen