From csr21 at cam.ac.uk Mon Aug 1 18:36:58 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 01 Aug 2005 19:36:58 +0100 Subject: [mcclim-devel] Re: international text-style support In-Reply-To: <15759.14785.256158.689994@rubin.local> (Gilbert Baumann's message of "Mon, 23 Sep 2002 17:56:49 +0200") References: <3D8857C0.3090901@designix.com.au> <15759.14785.256158.689994@rubin.local> Message-ID: [ a very long time ago, in the context of supporting complicated international scripts ] Gilbert Baumann writes: > Brian Spilsbury writes: > > I have implement (somewhat primitive) international text-style support. > > [...] > > This sounds like a somewhat reasonable design to me, although I would > very much prefer if we could move the fontset logic into the frontend > by coming up with a sort of font protocol. So, now, we (at Goldsmiths) have a need for a specific font. At the moment, we have hacked in support to our application using MAKE-DEVICE-FONT-TEXT-STYLE and some extreme hackiness in CLIM-CLX::TEXT-STYLE-TO-X-FONT; the device-font-text-style support in current CVS is ... not extensive, which is not really surprising given that the spec is approximately equally non-extensive. It tickled my memory, though, and I dug up this proposal: > Something like this: > > A font is a mapping from glyph names (indicies) to glyphs. Fonts > have additional attributes like name, weight, an encoding, a > language and so on. Glyphs have metrics and are drawable to > individual media. > > FONT protocol class > > FONT-NAME font method > FONT-WEIGHT font method > FONT-SLANT font method > FONT-... font method > > The individual typographical properties of the font. > > SCALE-FONT font size -> font method > > Scales the font to a new size. > [Q1: Unit for size?] > [Q2: Should this affect metrics?] > > FONT-SIZE font method > > Returns the size of the font. > > TRANSFORM-FONT font transformation -> font method > > Applies a affine transformation to the font. Each glyph drawn with > the returned font are then drawn under the transformation. This > does not affect the individual glyph metrics. > > FONT-TRANSFORMATION font -> transformation method > > Returns the transformation of the font font. > > FONT-GLYPH-METRICS font glyph method > -> width ascent descent left-bearing right-bearing > > Returns the fonts glyph metrics. To calculate the metrics of > glyphs as drawn my draw-glyph the transformation of the font has > to be applied to the returned values. > > [This is to keep the glyph-metrics as scalars instead of making > each metric into a vector]. > > width should not be negative in case of RTL script, since > typesetting from right to left is consided to be a property of a > text-style; likewise left-bearing bearing on the left hand side > as right bearing is bearing on the right hand size. > > Q4: Is there something like top-bearing, bottom-bearing for fonts > designed towards top-to-bottom scripts? > > > FONT-KERNING font glyph-1 glyph-2 method > > Returns the kerning to be applied when typesetting glyph-1 left of > glyph-2. > > DRAW-GLYPH medium font glyph x y method > > [Q3: Interaction with general designs? Ideally we would make glyphs > into designs itself]. > > A text-style is a mapping of chracter sequences to font, glyph, > position triples for drawing. A text-style then might refer to > multiple fonts thus forming a fontset. > > Each medium then knows its available fonts. These can be queried by > the frontend and combined into a text style. > > As you can see there are some questions and I am not entirely sure how > things should really look like. Nor am I. I don't suppose anyone else has had thoughts in the last three years? We need: a way of specifying that we want to draw text using a specific font (in our case, a FreeType font for tablature) at a specific size. If that's not a DEVICE-FONT-TEXT-STYLE, I don't know where else it should go, but it does imply that a DEVICE-FONT has size. I'm away from my workstation, but tomorrow I'll send patches showing what we're currently doing. Cheers, Christophe From csr21 at cam.ac.uk Tue Aug 2 08:49:41 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 02 Aug 2005 09:49:41 +0100 Subject: [mcclim-devel] Re: international text-style support In-Reply-To: (Christophe Rhodes's message of "Mon, 01 Aug 2005 19:36:58 +0100") References: <3D8857C0.3090901@designix.com.au> <15759.14785.256158.689994@rubin.local> Message-ID: Christophe Rhodes writes: > I'm away from my workstation, but tomorrow I'll send patches showing > what we're currently doing. As promised: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: medium.diff URL: -------------- next part -------------- This patch implements a bit more of device-font-text-style, while ignoring the spec's requirement that they behave, apart from merging, like normal text styles -- that is, that they have a family, size and face. (The requirements for family and face are pretty nonsensical, but it is clear that a device font needs to acquire size information at some point). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freetype-fonts.diff URL: -------------- next part -------------- This patch allows use of device-font-text-style in the experimental freetype backend; with it, you can do (with-text-style (medium (make-device-font-text-style (port *application-frame*) "/Fonts/tabcode.ttf")) ...) and have that font active for draw-text for the dynamic extent. If anyone has any ideas about how to make this better or more generalizeable, that would be great -- particularly since we're also going to want Postscript support for this... Cheers, Christophe From raymond.toy at ericsson.com Wed Aug 3 14:36:55 2005 From: raymond.toy at ericsson.com (Raymond Toy) Date: Wed, 03 Aug 2005 10:36:55 -0400 Subject: [mcclim-devel] Re: [Sbcl-devel] Would McCLIM benefit from this pretty printer patch for CMUCL/SBCL? In-Reply-To: (Matthias Koeppe's message of "Fri, 29 Jul 2005 00:12:27 +0200") References: Message-ID: >>>>> "Matthias" == Matthias Koeppe writes: Matthias> I have now taken a look at Gilbert Baumann's pretty printer patch Matthias> (http://bauhh.dyndns.org:8000/mcclim/pprint/) that Paolo pointed out. Matthias> As far as I can see, the changes there could be easily re-implemented Matthias> in terms of the more general "annotations" feature implemented in my Matthias> patch. That's encouraging. Matthias> The only thing that is not covered by my patch is the hooks into Matthias> START-LOGICAL-BLOCK, END-LOGICAL-BLOCK, PPRINT-LOGICAL-BLOCK. These Matthias> changes are independent of my patch. Do you think the missing parts could be added? Matthias> (I am including below a new version of the patch for CMUCL that includes Matthias> docstrings.) Thanks for the new patch. Just a couple of questions. You mentioned that you use this with slime presentations. What does these annotations do for slime presentations? Could you describe what happens? I'm trying to understand exactly what new capabilities you would get with these annotations. And a way to test the result after I've patched cmucl with these changes. :-) Ray From mkoeppe+slime at mail.math.uni-magdeburg.de Wed Aug 3 21:07:19 2005 From: mkoeppe+slime at mail.math.uni-magdeburg.de (Matthias Koeppe) Date: Wed, 03 Aug 2005 23:07:19 +0200 Subject: [mcclim-devel] Re: [Sbcl-devel] Would McCLIM benefit from this pretty printer patch for CMUCL/SBCL? In-Reply-To: (Raymond Toy's message of "Wed, 03 Aug 2005 10:36:55 -0400") References: Message-ID: Raymond Toy writes: >>>>>> "Matthias" == Matthias Koeppe writes: > Matthias> The only thing that is not covered by my patch is the hooks into > Matthias> START-LOGICAL-BLOCK, END-LOGICAL-BLOCK, PPRINT-LOGICAL-BLOCK. These > Matthias> changes are independent of my patch. > > Do you think the missing parts could be added? I think we would need a general system of hooks that hook into both the pretty printer and various functions of the ugly printer. As an example, SLIME currently only hooks into the printer functions LISP::%PRINT-PATHNAME and LISP::%PRINT-UNREADABLE-OBJECT: (fwrappers:define-fwrapper presenting-unreadable-wrapper (object stream type identity body) (presenting-object object stream (fwrappers:call-next-function))) (fwrappers:define-fwrapper presenting-pathname-wrapper (pathname stream depth) (presenting-object pathname stream (fwrappers:call-next-function))) (fwrappers::fwrap 'lisp::%print-pathname #'presenting-pathname-wrapper) (fwrappers::fwrap 'lisp::%print-unreadable-object #'presenting-unreadable-wrapper) I would be willing to work on a system of printer hooks that is suitable for the purposes of SLIME and of McCLIM. I see this as a second step, though; for the current purposes of SLIME, it would be sufficient to get the annotations support merged; as the above hooks into the printer are rather unobtrusive, they would be easily maintainable in SLIME itself. It is also not clear at the moment whether a more complete presentation support (covering nested lists) is desired for SLIME. > You mentioned that you use this with slime presentations. What does > these annotations do for slime presentations? Could you describe > what happens? I'm trying to understand exactly what new > capabilities you would get with these annotations. And a way to > test the result after I've patched cmucl with these changes. :-) You can test with CVS SLIME plus my SLIME patch below. In SLIME, it is possible to refer to old REPL results (even # ones) simply by copying their textual representation within Emacs. This does not require any printer patches. Moreover, after the file present.lisp is loaded, it is also possible to refer to (unreadable) objects that were only printed (as a side effect of the computation). Try (DESCRIBE 'STANDARD-OBJECT) and then copy one of the highlighted # objects as new REPL input. The mechanism is that %PRINT-UNREADABLE-OBJECT (via PRESENTING-OBJECT) stores the object in a hash table and sends a unique id to Emacs. So if we want to print (A B C # D E F), Emacs sees the SLIME protocol messages (:READ-OUTPUT "(A B C ") (:START-PRESENTATION 17) (:READ-OUTPUT "#") (:END-PRESENTATION 17) (:READ-OUTPUT " D E F") No annotations needed so far. The stream connected to *STANDARD-OUTPUT* is a Gray stream that takes care of directing ordinary character output to Emacs. When a presentation needs to be started or ended, I flush the stream, which yields a :READ-OUTPUT message; then I send the :START-PRESENTATION or :END-PRESENTATION message. The problem arises when we are not printing directly to a SLIME stream but through a pretty printing stream. Such a stream buffers the ordinary character output until layout decisions can be taken; only then it forwards them to the target stream (in our case, a SLIME stream). In order to send the :START-PRESENTATION and :END-PRESENTATION messages at the right positions, they must be buffered as well in the pretty printing stream. This is what annotations implement. Cheers, Matthias -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.515 diff -u -p -r1.515 slime.el --- slime.el 29 Jul 2005 12:37:24 -0000 1.515 +++ slime.el 3 Aug 2005 20:24:02 -0000 @@ -868,15 +868,13 @@ This list of flushed between commands.") "Execute all functions in `slime-pre-command-actions', then NIL it." (dolist (undo-fn slime-pre-command-actions) (ignore-errors (funcall undo-fn))) - (setq slime-pre-command-actions nil) - (slime-presentation-command-hook)) + (setq slime-pre-command-actions nil)) (defun slime-post-command-hook () (when (and slime-mode (slime-connected-p)) (slime-process-available-input)) (when (null pre-command-hook) ; sometimes this is lost - (add-hook 'pre-command-hook 'slime-pre-command-hook)) - (slime-presentation-post-command-hook) ) + (add-hook 'pre-command-hook 'slime-pre-command-hook))) (defun slime-setup-command-hooks () "Setup a buffer-local `pre-command-h'ook' to call `slime-pre-command-hook'." @@ -884,7 +882,8 @@ This list of flushed between commands.") (make-local-hook 'post-command-hook) ;; alanr: need local t (add-hook 'pre-command-hook 'slime-pre-command-hook nil t) - (add-hook 'post-command-hook 'slime-post-command-hook nil t)) + (add-hook 'post-command-hook 'slime-post-command-hook nil t) + (add-hook 'after-change-functions 'slime-after-change-function nil t)) ;(add-hook 'slime-mode-hook 'slime-setup-command-hooks) ;(setq post-command-hook nil) @@ -2285,6 +2284,10 @@ slime-repl-insert-prompt.") (destructure-case event ((:read-output output) (slime-output-string output)) + ((:presentation-start id) + (slime-mark-presentation-start id)) + ((:presentation-end id) + (slime-mark-presentation-end id)) ;; ((:emacs-rex form package thread continuation) (slime-set-state "|eval...") @@ -2566,40 +2569,85 @@ update window-point afterwards. If poin (when (boundp 'text-property-default-nonsticky) (pushnew '(slime-repl-old-output . t) text-property-default-nonsticky :test 'equal) + (pushnew '(slime-repl-presentation . t) text-property-default-nonsticky + :test 'equal) (pushnew '(slime-repl-result-face . t) text-property-default-nonsticky :test 'equal))) (make-variable-buffer-local (defvar slime-presentation-start-to-point (make-hash-table))) -(defun slime-mark-presentation-start (process string) +(defun slime-mark-presentation-start (id) + (setf (gethash id slime-presentation-start-to-point) + (with-current-buffer (slime-output-buffer) + (marker-position (symbol-value 'slime-output-end))))) + +(defun slime-mark-presentation-start-handler (process string) (if (and string (string-match "<\$[0-9]+\$" string)) - (progn - (let* ((match (substring string (match-beginning 1) (match-end 1))) - (id (car (read-from-string match)))) - (setf (gethash id slime-presentation-start-to-point) - (with-current-buffer (slime-output-buffer) - (marker-position (symbol-value 'slime-output-end)))))))) + (let* ((match (substring string (match-beginning 1) (match-end 1))) + (id (car (read-from-string match)))) + (slime-mark-presentation-start id)))) + +(defun slime-mark-presentation-end (id) + (let ((start (gethash id slime-presentation-start-to-point))) + (setf (gethash id slime-presentation-start-to-point) nil) + (when start + (with-current-buffer (slime-output-buffer) + (slime-add-presentation-properties start (symbol-value 'slime-output-end) + id nil))))) -(defun slime-mark-presentation-end (process string) +(defun slime-mark-presentation-end-handler (process string) (if (and string (string-match ">\$[0-9]+\$" string)) - (progn - (let* ((match (substring string (match-beginning 1) (match-end 1))) - (id (car (read-from-string match)))) - (let ((start (gethash id slime-presentation-start-to-point))) - (setf (gethash id slime-presentation-start-to-point) nil) - (when start - (with-current-buffer (slime-output-buffer) - (add-text-properties - start (symbol-value 'slime-output-end) - `(face slime-repl-result-face - slime-repl-old-output ,id - mouse-face slime-repl-output-mouseover-face - keymap ,slime-presentation-map - rear-nonsticky (slime-repl-old-output - slime-repl-result-face - slime-repl-output-mouseover-face)))))))))) + (let* ((match (substring string (match-beginning 1) (match-end 1))) + (id (car (read-from-string match)))) + (slime-mark-presentation-end id)))) + +(defstruct (slime-presentation) + (text) + (id) + (start-p) + (stop-p)) + +(defun slime-add-presentation-properties (start end id result-p) + "Make the text between START and END a presentation with ID. +RESULT-P decides whether a face for a return value or output text is used." + (add-text-properties start end + `(face slime-repl-inputed-output-face + slime-repl-old-output ,id + mouse-face slime-repl-output-mouseover-face + keymap ,slime-presentation-map + rear-nonsticky (slime-repl-old-output + slime-repl-presentation + face mouse-face))) + (let ((text (buffer-substring-no-properties start end))) + (case (- end start) + (0) + (1 + (add-text-properties start end + `(slime-repl-presentation + ,(make-slime-presentation :text text :id id + :start-p t :stop-p t)))) + (t + (let ((inhibit-modification-hooks t)) + (add-text-properties start (1+ start) + `(slime-repl-presentation + ,(make-slime-presentation :text text :id id + :start-p t :stop-p nil))) + (when (> (- end start) 2) + (add-text-properties (1+ start) (1- end) + `(slime-repl-presentation + ,(make-slime-presentation :text text :id id + :start-p nil :stop-p nil)))) + (add-text-properties (1- end) end + `(slime-repl-presentation + ,(make-slime-presentation :text text :id id + :start-p nil :stop-p t)))))))) +(defun slime-insert-presentation (result output-id) + (let ((start (point))) + (insert result) + (slime-add-presentation-properties start (point) output-id t))) + (defun slime-open-stream-to-lisp (port) (let ((stream (open-network-stream "*lisp-output-stream*" (slime-with-connection-buffer () @@ -2615,8 +2663,8 @@ update window-point afterwards. If poin (install-bridge) (setq bridge-destination-insert nil) (setq bridge-source-insert nil) - (setq bridge-handlers (list* '("<" . slime-mark-presentation-start) - '(">" . slime-mark-presentation-end) + (setq bridge-handlers (list* '("<" . slime-mark-presentation-start-handler) + '(">" . slime-mark-presentation-end-handler) bridge-handlers)) (set-process-coding-system stream slime-net-coding-system @@ -2752,61 +2800,105 @@ joined together.")) (slime-setup-command-hooks) (run-hooks 'slime-repl-mode-hook)) -(defvar slime-not-copying-whole-presentation nil) - -;; alanr -(defun slime-presentation-command-hook () - (let* ((props-here (text-properties-at (point))) - (props-before (and (not (= (point) (point-min))) - (text-properties-at (1- (point))))) - (inside (and (getf props-here 'slime-repl-old-output))) - (at-beginning (and inside - (not (getf props-before 'slime-repl-old-output)))) - (at-end (and (or (= (point) (point-max)) - (not (getf props-here 'slime-repl-old-output))) - (getf props-before 'slime-repl-old-output))) - (start (cond (at-beginning (point)) - (inside (previous-single-property-change - (point) 'slime-repl-old-output)) - (at-end (previous-single-property-change - (1- (point)) 'slime-repl-old-output)))) - (end (cond (at-beginning (or (next-single-property-change - (point) 'slime-repl-old-output) - (point-max))) - (inside (or (next-single-property-change (point) 'slime-repl-old-output) - (point-max))) - (at-end (point))))) - ; (setq message (format "%s %s %s %s %s" at-beginning inside at-end start end)) - (when (and (or inside at-end) start end (> end start)) - (let ((kind (get this-command 'action-type))) - ; (message (format "%s %s %s %s" at-beginning inside at-end kind)) - (cond ((and (eq kind 'inserts) inside (not at-beginning)) - (setq this-command 'ignore)) - ((and (eq kind 'deletes-forward) inside (not at-end)) - (kill-region start end) - (setq this-command 'ignore)) - ((and (eq kind 'deletes-backward) (or inside at-end) (not at-beginning)) - (kill-region start end) - (setq this-command 'ignore)) - ((eq kind 'copies) - (multiple-value-bind (start end) (slime-property-bounds 'slime-repl-old-input) - (setq slime-not-copying-whole-presentation - (not (or (and at-beginning (>= (mark) end)) - (and at-end (<= (mark) start))))))) - ;(message (format "%s %s" length (abs (- (point) (mark)))))))) - ))))) - -;; if we did not copy the whole presentation, then remove the text properties from the -;; top of the kill ring - -(defun slime-presentation-post-command-hook () - (when (eq (get this-command 'action-type) 'copies) - (when slime-not-copying-whole-presentation - (remove-text-properties 0 (length (car kill-ring)) - '(slime-repl-old-output t mouse-face t rear-nonsticky t) - (car kill-ring)))) - (setq slime-not-copying-whole-presentation nil) - ) +(defun slime-presentation-whole-p (start end) + (let ((presentation (get-text-property start 'slime-repl-presentation))) + (and presentation + (string= (buffer-substring-no-properties start end) + (slime-presentation-text presentation))))) + +(defun slime-same-presentation-p (a b) + (and (string= (slime-presentation-text a) (slime-presentation-text b)) + (equal (slime-presentation-id a) (slime-presentation-id b)))) + +(defun* slime-presentation-start () + "Find start of presentation at point. Return buffer index and + whether a start-tag was found. When there is no presentation at + point, return nil and nil." + (let* ((presentation (get-text-property (point) 'slime-repl-presentation)) + (this-presentation presentation)) + (unless presentation + (return-from slime-presentation-start + (values nil nil))) + (save-excursion + (while (not (slime-presentation-start-p this-presentation)) + (let ((change-point (previous-single-property-change (point) 'slime-repl-presentation))) + (unless change-point + (return-from slime-presentation-start + (values (point-min) nil))) + (setq this-presentation (get-text-property change-point 'slime-repl-presentation)) + (unless (and this-presentation + (slime-same-presentation-p presentation this-presentation)) + (return-from slime-presentation-start + (values (point) nil))) + (goto-char change-point))) + (values (point) t)))) + +(defun* slime-presentation-end () + "Find end of presentation at point. Return buffer index (after last + character of the presentation) and whether an end-tag was found." + (let* ((presentation (get-text-property (point) 'slime-repl-presentation)) + (this-presentation presentation)) + (unless presentation + (return-from slime-presentation-end + (values nil nil))) + (save-excursion + (while (and this-presentation + (slime-same-presentation-p presentation this-presentation) + (not (slime-presentation-stop-p this-presentation))) + (let ((change-point (next-single-property-change (point) 'slime-repl-presentation))) + (unless change-point + (return-from slime-presentation-end + (values (point-max) nil))) + (goto-char change-point) + (setq this-presentation (get-text-property (point) 'slime-repl-presentation)))) + (if (and this-presentation + (slime-same-presentation-p presentation this-presentation)) + (let ((after-end (next-single-property-change (point) 'slime-repl-presentation))) + (if (not after-end) + (values (point-max) t) + (values after-end t))) + (values (point) nil))))) + +(defun slime-presentation-around-point () + "Return start index, end index, and whether the presentation is complete." + (multiple-value-bind (start good-start) + (slime-presentation-start) + (multiple-value-bind (end good-end) + (slime-presentation-end) + (values start end + (and good-start good-end + (slime-presentation-whole-p start end)))))) + +(defun slime-after-change-function (start end old-len) + "Check all presentations within and adjacent to the change. When a + presentation has been altered, change it to plain text." + (unless undo-in-progress + (let ((real-start (max (point-min) (1- start))) + (real-end (min (point-max) (1+ end))) + (any-change nil)) + ;; positions around the change + (save-excursion + (goto-char real-start) + (while (< (point) real-end) + (let ((presentation (get-text-property (point) 'slime-repl-presentation))) + (when presentation + (multiple-value-bind (from to whole) + (slime-presentation-around-point) + ;;(message "presentation %s whole-p %s" (buffer-substring from to) whole) + (unless whole + (setq any-change t) + (remove-text-properties from to + '(slime-repl-old-output t + slime-repl-inputed-output-face t + face t mouse-face t rear-nonsticky t + slime-repl-presentation t)))))) + (let ((next-change + (next-single-property-change (point) 'slime-repl-presentation nil + real-end))) + (if next-change + (goto-char next-change) + (undo-boundary) + (return)))))))) (defun slime-copy-presentation-at-point (event) (interactive "e") @@ -2830,20 +2922,6 @@ joined together.")) (goto-char (point-max)) (do-insertion))))))) -(put 'self-insert-command 'action-type 'inserts) -(put 'self-insert-command-1 'action-type 'inserts) -(put 'yank 'action-type 'inserts) -(put 'kill-word 'action-type 'deletes-forward) -(put 'delete-char 'action-type 'deletes-forward) -(put 'kill-sexp 'action-type 'deletes-forward) -(put 'backward-kill-sexp 'action-type 'deletes-backward) -(put 'backward-delete-char 'action-type 'deletes-backward) -(put 'delete-backward-char 'action-type 'deletes-backward) -(put 'backward-kill-word 'action-type 'deletes-backward) -(put 'backward-delete-char-untabify 'action-type 'deletes-backward) -(put 'slime-repl-newline-and-indent 'action-type 'inserts) -(put 'kill-ring-save 'action-type 'copies) - (defvar slime-presentation-map (make-sparse-keymap)) (define-key slime-presentation-map [mouse-2] 'slime-copy-presentation-at-point) @@ -2887,36 +2965,42 @@ joined together.")) (defun slime-repl-insert-prompt (result &optional time) "Goto to point max, insert RESULT and the prompt. Set slime-output-end to start of the inserted text slime-input-start to -end end." +end end. If RESULT is not a string, it must be a list of +result strings, each of which is marked-up as a presentation." (slime-flush-output) (goto-char (point-max)) (let ((start (point))) (unless (bolp) (insert "\n")) - (unless (string= "" result) - (slime-propertize-region `(face slime-repl-result-face) - (slime-propertize-region - (and slime-repl-enable-presentations - `(face slime-repl-result-face - slime-repl-old-output ,(- slime-current-output-id) - mouse-face slime-repl-output-mouseover-face - keymap ,slime-presentation-map)) - (insert result))) - (unless (bolp) (insert "\n")) - (let ((inhibit-read-only t)) - (put-text-property (- (point) 2) (point) - 'rear-nonsticky - '(slime-repl-old-output face read-only)))) + (flet ((insert-result (result id) + (if (and slime-repl-enable-presentations id) + (slime-insert-presentation result id) + (slime-propertize-region `(face slime-repl-result-face) + (insert result))) + (unless (bolp) (insert "\n")) + (let ((inhibit-read-only t)) + (put-text-property (- (point) 2) (point) + 'rear-nonsticky + '(slime-repl-old-output slime-repl-presentation face read-only))))) + (etypecase result + (list + (loop + for res in result + for index from 0 + do (insert-result res (cons (- slime-current-output-id) index)))) + (string + (unless (string= result "") + (insert-result result nil))))) (let ((prompt-start (point)) (prompt (format "%s> " (slime-lisp-package-prompt-string)))) (slime-propertize-region '(face slime-repl-prompt-face - read-only t - intangible t - slime-repl-prompt t - ;; emacs stuff - rear-nonsticky (slime-repl-prompt read-only face intangible) - ;; xemacs stuff - start-open t end-open t) + read-only t + intangible t + slime-repl-prompt t + ;; emacs stuff + rear-nonsticky (slime-repl-prompt read-only face intangible) + ;; xemacs stuff + start-open t end-open t) (insert prompt)) ;; FIXME: we could also set beginning-of-defun-function (setq defun-prompt-regexp (concat "^" prompt)) @@ -2969,7 +3053,11 @@ buffer. Presentations of old results are (concat (substring str-no-props 0 pos) ;; Eval in the reader so that we play nice with quote. ;; -luke (19/May/2005) - "#." (slime-prin1-to-string `(swank:get-repl-result ,id)) + "#." (slime-prin1-to-string + (if (consp id) + `(cl:nth ,(cdr id) + (swank:get-repl-result ,(car id))) + `(swank:get-repl-result ,id))) (reify-old-output (substring str-props end-pos) (substring str-no-props end-pos))))))) @@ -3023,8 +3111,11 @@ buffer. Presentations of old results are (set-marker slime-output-end position))) (defun slime-mark-output-end () + ;; Don't put slime-repl-output-face again; it would remove the + ;; special presentation face, for instance in the SBCL inspector. (add-text-properties slime-output-start slime-output-end - '(face slime-repl-output-face rear-nonsticky (face)))) + '(;;face slime-repl-output-face + rear-nonsticky (face)))) (defun slime-repl-bol () "Go to the beginning of line or the prompt." Index: present.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/present.lisp,v retrieving revision 1.4 diff -u -p -r1.4 present.lisp --- present.lisp 24 May 2005 02:42:01 -0000 1.4 +++ present.lisp 3 Aug 2005 20:24:03 -0000 @@ -15,9 +15,6 @@ ;; ultimately prints to a slime stream. ;; Control -(defvar *can-print-presentation* nil - "set this to t in contexts where it is ok to print presentations at all") - (defvar *enable-presenting-readable-objects* t "set this to enable automatically printing presentations for some subset of readable objects, such as pathnames." ) @@ -82,8 +79,18 @@ don't want to present anything" ;(slime-stream-p (ccl::xp-base-stream (slot-value stream 'ccl::xp-structure))) (slime-stream-p (ccl::%svref (slot-value stream 'ccl::xp-structure) 1))) #+cmu - (and (typep stream 'pretty-print::pretty-stream) - (slime-stream-p (pretty-print::pretty-stream-target stream))) + (or (and (typep stream 'lisp::indenting-stream) + (slime-stream-p (lisp::indenting-stream-stream stream))) + (and (typep stream 'pretty-print::pretty-stream) + (slime-stream-p (pretty-print::pretty-stream-target stream)))) + #+sbcl + (or (and (typep stream 'sb-impl::indenting-stream) + (slime-stream-p (sb-impl::indenting-stream-stream stream))) + (and (typep stream 'sb-pretty::pretty-stream) + (slime-stream-p (sb-pretty::pretty-stream-target stream)))) + #+allegro + (and (typep stream 'excl:xp-simple-stream) + (slime-stream-p (excl::stream-output-handle stream))) (loop for connection in *connections* thereis (or (eq stream (connection.dedicated-output connection)) (eq stream (connection.socket-io connection)) @@ -94,43 +101,91 @@ don't want to present anything" (declare (ignore stream)) *enable-presenting-readable-objects*) +;;; Get pretty printer patches for CMUCL +#+cmu +(eval-when (:compile-toplevel :load-toplevel :execute) + (handler-bind ((simple-error + (lambda (c) + (let ((clobber-it (find-restart 'kernel::clobber-it))) + (when clobber-it (invoke-restart clobber-it)))))) + (ext:without-package-locks (load "cmucl-pprint-patch.lisp")))) +#+sbcl +(eval-when (:compile-toplevel :load-toplevel :execute) + (handler-bind ((simple-error + (lambda (c) + (let ((clobber-it (find-restart 'sb-kernel::clobber-it))) + (when clobber-it (invoke-restart clobber-it)))))) + (sb-ext:without-package-locks + (swank-backend::with-debootstrapping (load "sbcl-pprint-patch.lisp"))))) + +;; If we are printing to an XP (pretty printing) stream, printing the +;; escape sequences directly would mess up the layout because column +;; counting is disturbed. Use "annotations" instead. +#+allegro +(defun write-annotation (stream function arg) + (if (typep stream 'excl:xp-simple-stream) + (excl::schedule-annotation stream function arg) + (funcall function arg stream nil))) +#+cmu +(defun write-annotation (stream function arg) + (if (typep stream 'pp:pretty-stream) + (pp::enqueue-annotation stream function arg) + (funcall function arg stream nil))) +#+sbcl +(defun write-annotation (stream function arg) + (if (typep stream 'sb-pretty::pretty-stream) + (sb-pretty::enqueue-annotation stream function arg) + (funcall function arg stream nil))) +#-(or allegro cmu sbcl) +(defun write-annotation (stream function arg) + (funcall function arg stream nil)) + +(defstruct presentation-record + (id) + (printed-p)) + +(defun presentation-start (record stream truncatep) + (unless truncatep + ;; Don't start new presentations when nothing is going to be + ;; printed due to *print-lines*. + (let ((pid (presentation-record-id record))) + (cond (*use-dedicated-output-stream* + (write-string "<" stream) + (prin1 pid stream) + (write-string "" stream)) + (t + (force-output stream) + (send-to-emacs `(:presentation-start ,pid))))) + (setf (presentation-record-printed-p record) t))) + +(defun presentation-end (record stream truncatep) + (declare (ignore truncatep)) + ;; Always end old presentations that were started. + (when (presentation-record-printed-p record) + (let ((pid (presentation-record-id record))) + (cond (*use-dedicated-output-stream* + (write-string ">" stream) + (prin1 pid stream) + (write-string "" stream)) + (t + (force-output stream) + (send-to-emacs `(:presentation-end ,pid))))))) + (defun presenting-object-1 (object stream continue) "Uses the bridge mechanism with two messages >id and " stream) - (prin1 pid stream) - (write-string "" stream))) + (write-annotation stream #'presentation-end record))) (funcall continue))) ;; enable presentations inside listener eval, when compiling, when evaluating -(defslimefun listener-eval (string) - (clear-user-input) - (with-buffer-syntax () - (let ((*slime-repl-suppress-output* :unset) - (*slime-repl-advance-history* :unset)) - (multiple-value-bind (values last-form) - (let ((*can-print-presentation* t)) - (eval-region string t)) - (unless (or (and (eq values nil) (eq last-form nil)) - (eq *slime-repl-advance-history* nil)) - (setq *** ** ** * * (car values) - /// // // / / values) - (when *record-repl-results* - (add-repl-result *current-id* *))) - (setq +++ ++ ++ + + last-form) - (if (eq *slime-repl-suppress-output* t) - "" - (cond ((null values) "; No value") - (t - (format nil "~{~S~^~%~}" values)))))))) + (defslimefun compile-string-for-emacs (string buffer position directory) "Compile STRING (exerpted from BUFFER at POSITION). @@ -371,3 +426,29 @@ I is an integer describing and FRAME a s (fwrappers::fwrap 'lisp::%print-pathname #'presenting-pathname-wrapper) (fwrappers::fwrap 'lisp::%print-unreadable-object #'presenting-unreadable-wrapper) ) + +#+sbcl +(progn + (defvar *saved-%print-unreadable-object* + (fdefinition 'sb-impl::%print-unreadable-object)) + (sb-ext:without-package-locks + (setf (fdefinition 'sb-impl::%print-unreadable-object) + (lambda (object stream type identity body) + (presenting-object object stream + (funcall *saved-%print-unreadable-object* + object stream type identity body)))) + (defmethod print-object :around ((object pathname) stream) + (presenting-object object stream + (call-next-method))))) + +#+allegro +(progn + (excl:def-fwrapper presenting-unreadable-wrapper (object stream type identity continuation) + (swank::presenting-object object stream (excl:call-next-fwrapper))) + (excl:def-fwrapper presenting-pathname-wrapper (pathname stream depth) + (presenting-object-if (can-present-readable-objects stream) pathname stream + (excl:call-next-fwrapper))) + (excl:fwrap 'excl::print-unreadable-object-1 + 'print-unreadable-present 'presenting-unreadable-wrapper) + (excl:fwrap 'excl::pathname-printer + 'print-pathname-present 'presenting-pathname-wrapper)) Index: swank.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank.lisp,v retrieving revision 1.313 diff -u -p -r1.313 swank.lisp --- swank.lisp 29 Jul 2005 12:38:21 -0000 1.313 +++ swank.lisp 3 Aug 2005 20:24:05 -0000 @@ -329,7 +329,7 @@ Useful for low level debugging." ;;;; TCP Server -(defvar *use-dedicated-output-stream* t +(defvar *use-dedicated-output-stream* nil "When T swank will attempt to create a second connection to Emacs which is used just to send output.") (defvar *dedicated-output-stream-port* 0 @@ -599,7 +599,8 @@ of the toplevel restart." (encode-message `(:eval ,(thread-id thread) , at args) socket-io)) ((:emacs-return thread-id tag value) (send (find-thread thread-id) `(take-input ,tag ,value))) - (((:read-output :new-package :new-features :ed :%apply :indentation-update + (((:read-output :presentation-start :presentation-end + :new-package :new-features :ed :%apply :indentation-update :eval-no-wait) &rest _) (declare (ignore _)) @@ -719,6 +720,7 @@ of the toplevel restart." (declare (ignore thread)) (send `(:return , at args))) (((:read-output :new-package :new-features :debug-condition + :presentation-start :presentation-end :indentation-update :ed :%apply :eval-no-wait) &rest _) (declare (ignore _)) @@ -915,7 +917,7 @@ NIL if streams are not globally redirect (out (connection.user-output connection)) (*standard-output* out) (*error-output* out) - (*trace-output* out) + ;;(*trace-output* out) (*debug-io* io) (*query-io* io) (*standard-input* in) @@ -973,7 +975,8 @@ If a protocol error occurs then a SLIME- (let* ((string (prin1-to-string-for-emacs message)) (length (1+ (length string)))) (log-event "WRITE: ~A~%" string) - (format stream "~6,'0x" length) + (let ((*print-pretty* nil)) + (format stream "~6,'0x" length)) (write-string string stream) (terpri stream) (force-output stream))) @@ -1839,24 +1842,29 @@ Return its name and the string to use in (defparameter *repl-results* '() "Association list of old repl results.") +(defvar *can-print-presentation* nil + "set this to t in contexts where it is ok to print presentations at all") + (defslimefun listener-eval (string) (clear-user-input) (with-buffer-syntax () (let ((*slime-repl-suppress-output* :unset) (*slime-repl-advance-history* :unset)) - (multiple-value-bind (values last-form) (eval-region string t) + (multiple-value-bind (values last-form) + (let ((*can-print-presentation* t)) + (eval-region string t)) (unless (or (and (eq values nil) (eq last-form nil)) (eq *slime-repl-advance-history* nil)) (setq *** ** ** * * (car values) /// // // / / values) (when *record-repl-results* - (add-repl-result *current-id* *))) + (add-repl-result *current-id* values))) (setq +++ ++ ++ + + last-form) (if (eq *slime-repl-suppress-output* t) "" (cond ((null values) "; No value") (t - (format nil "~{~S~^~%~}" values)))))))) + (mapcar #'prin1-to-string values)))))))) (defun add-repl-result (id val) (push (cons id val) *repl-results*) From rpgoldman at real-time.com Wed Aug 3 23:40:15 2005 From: rpgoldman at real-time.com (Robert P. Goldman) Date: Wed, 03 Aug 2005 18:40:15 -0500 Subject: [mcclim-devel] McCLIM's dialog.lisp and ACL 7.0 Message-ID: <42F155DF.7010202@real-time.com> When I tried to recompile McCLIM on ACL 7.0 it crashed because there were some ignorable declarations applied to functions. These are specifically permitted by the ANSI spec. I was a little surprised by this --- I haven't before seen a case where ACL's conformance has degraded with a new version. Any one else seen this? Thanks, R From raymond.toy at ericsson.com Thu Aug 4 16:45:16 2005 From: raymond.toy at ericsson.com (Raymond Toy) Date: Thu, 04 Aug 2005 12:45:16 -0400 Subject: [mcclim-devel] Re: [Sbcl-devel] Would McCLIM benefit from this pretty printer patch for CMUCL/SBCL? In-Reply-To: (Matthias Koeppe's message of "Wed, 03 Aug 2005 23:07:19 +0200") References: Message-ID: >>>>> "Matthias" == Matthias Koeppe writes: Matthias> I would be willing to work on a system of printer hooks that is Matthias> suitable for the purposes of SLIME and of McCLIM. I see this as a It would be very nice if you could do this. Matthias> You can test with CVS SLIME plus my SLIME patch below. Matthias> In SLIME, it is possible to refer to old REPL results (even Matthias> # ones) simply by copying their textual representation Matthias> within Emacs. This does not require any printer patches. Matthias> Moreover, after the file present.lisp is loaded, it is also possible Matthias> to refer to (unreadable) objects that were only printed (as a side Matthias> effect of the computation). Try (DESCRIBE 'STANDARD-OBJECT) and then Matthias> copy one of the highlighted # objects as new REPL input. I tried out your patch and present.lisp (after removing the load of cmucl-pprint-patch) using a cmucl built with your pretty-stream annotations. Despite some bugs in slime (possibly because I'm using XEmacs and not Emacs), this looks really cool! The unreadable objects are clickable now, just like the regular output presentations. And since it's hooked into the pretty printer, I see that if I C-c C-k a file, the slime repl buffer has the pathname of the file highlighted and clickabe as well. This didn't happen before. This patch will be in the next snapshot of cmucl. Thanks for the patch! Ray From csr21 at cam.ac.uk Thu Aug 4 16:45:31 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 04 Aug 2005 17:45:31 +0100 Subject: [mcclim-devel] StudlyCaps directories Message-ID: Um, how come no-one's noticed this before? With a case-insensitive filesystem (such as is found, I believe, on at least some PowerPCs that seem absurdly popular these days), odd things happen to the CVS repository. I see, in the McCLIM directory, lisp-dep/ and Lisp-Dep/ looks/ and Looks/ examples/ and Examples/ Backends/postscript and Backends/PostScript and this has just caused real problems over here, as we attempted to extract diffs for Backends/PostScript/ whereas we had the CVS/Entries file for Backends/postscript... Is it possible to remove these duplicatedly-named directories? Cheers, Christophe From strandh at labri.fr Fri Aug 5 02:56:21 2005 From: strandh at labri.fr (Robert Strandh) Date: Fri, 5 Aug 2005 04:56:21 +0200 Subject: [mcclim-devel] StudlyCaps directories In-Reply-To: References: Message-ID: <17138.54613.87722.973517@serveur5.labri.fr> Christophe Rhodes writes: > Um, how come no-one's noticed this before? As i recall, the all-lower-case names are the old ones, and should no longer be used. -- 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. --------------------------------------------------------------------- From asf at boinkor.net Fri Aug 5 07:25:36 2005 From: asf at boinkor.net (Andreas Fuchs) Date: Fri, 05 Aug 2005 09:25:36 +0200 Subject: [mcclim-devel] StudlyCaps directories In-Reply-To: References: Message-ID: <87wtn0x2tr.wl%asf@boinkor.net> On 2005-08-04, Christophe Rhodes wrote: > Um, how come no-one's noticed this before? I think what you see depends on what you have in your ~/.cvsrc. If there's the line "up -Pd" (or just "up -P") in it, or if you use -P for updates and checkouts, you won't even see the lower-case directories, because they're pruned. > Is it possible to remove these duplicatedly-named directories? With CVS, it's possible to prevent empty directories from being created only by passing the -P switch on updates and checkouts, or by rm'ing them in the repository, losing history in these directories. Ugh. -- Andreas Fuchs, , asf at jabber.at, antifuchs From brian at mastenbrook.net Fri Aug 5 11:46:16 2005 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Fri, 5 Aug 2005 06:46:16 -0500 Subject: [mcclim-devel] StudlyCaps directories In-Reply-To: References: Message-ID: <61AC0FB3-852F-4419-A7B3-E8535661B44B@mastenbrook.net> On Aug 4, 2005, at 11:45 AM, Christophe Rhodes wrote: > Um, how come no-one's noticed this before? > > With a case-insensitive filesystem (such as is found, I believe, on at > least some PowerPCs that seem absurdly popular these days), odd things > happen to the CVS repository. > > I see, in the McCLIM directory, > lisp-dep/ and Lisp-Dep/ > looks/ and Looks/ > examples/ and Examples/ > Backends/postscript and Backends/PostScript > > and this has just caused real problems over here, as we attempted to > extract diffs for Backends/PostScript/ whereas we had the CVS/Entries > file for Backends/postscript... > > Is it possible to remove these duplicatedly-named directories? I think if you check out with cvs update -dP then those directories would get pruned. IIRC there's not much you can do about directories in CVS short of repository surgery. If somebody knows how and can explain how to do that without mucking up the repository I'd be glad to give it a go. -- Brian Mastenbrook brian at mastenbrook.net http://www.iscblog.info/ From csr21 at cam.ac.uk Mon Aug 8 17:11:16 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 08 Aug 2005 18:11:16 +0100 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <42E79BE1.6010606@cpmg.tv> (David Murray's message of "Wed, 27 Jul 2005 15:36:17 +0100") References: <42E79BE1.6010606@cpmg.tv> Message-ID: David Murray writes: > [resent to the correct address - I hope...] > > I was wondering why the :highlight option to :single-box wasn't working > as I thought it should. Turns out there was a wee typo. Patch attached. Thanks, I've applied this patch. (Whether it should take two weeks to apply a one-line patch, I don't know; you be the judge...) Is there any code in Examples/ or Apps/ which exercises this code path? If not, it might be worth including some -- if we can't have an automatic regression test suite, then we might as well have a manual one. Cheers, Christophe From moore at bricoworks.com Mon Aug 8 21:23:12 2005 From: moore at bricoworks.com (Timothy Moore) Date: Mon, 8 Aug 2005 17:23:12 -0400 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: References: <42E79BE1.6010606@cpmg.tv> Message-ID: <19078b56a3f8c97844458797e119c671@bricoworks.com> On Aug 8, 2005, at 1:11 PM, Christophe Rhodes wrote: > David Murray writes: > >> [resent to the correct address - I hope...] >> >> I was wondering why the :highlight option to :single-box wasn't >> working >> as I thought it should. Turns out there was a wee typo. Patch >> attached. > > Thanks, I've applied this patch. (Whether it should take two weeks to > apply a one-line patch, I don't know; you be the judge...) > No, it shouldn't. In my lame defense, I'm traveling and not paying much attention :) Thanks, Christophe. Tim From strandh at labri.fr Mon Aug 8 23:38:21 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 9 Aug 2005 01:38:21 +0200 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <19078b56a3f8c97844458797e119c671@bricoworks.com> References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> Message-ID: <17143.60653.163657.513946@serveur5.labri.fr> Timothy Moore writes: > > No, it shouldn't. In my lame defense, I'm traveling and not paying much > attention :) Thanks, Christophe. Perhaps you can make up for it by making incremental redisplay respect the output recording protocol, and not count on there being a slot called coordinates? :-) -- 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. --------------------------------------------------------------------- From csr21 at cam.ac.uk Tue Aug 9 09:54:33 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 09 Aug 2005 10:54:33 +0100 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <19078b56a3f8c97844458797e119c671@bricoworks.com> (Timothy Moore's message of "Mon, 8 Aug 2005 17:23:12 -0400") References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> Message-ID: Timothy Moore writes: > On Aug 8, 2005, at 1:11 PM, Christophe Rhodes wrote: >> Thanks, I've applied this patch. (Whether it should take two weeks to >> apply a one-line patch, I don't know; you be the judge...) >> > No, it shouldn't. In my lame defense, I'm traveling and not paying much > attention :) Thanks, Christophe. I was going to start this message by saying "I wasn't trying to apportion blame", but then I realised that that would be a slightly disingenuous response. I was not and am not trying to apportion blame, but it was a pointed message nonetheless, and for the pointiness I apologise. It does raise at least one question, though: who "owns" the McCLIM code, where by "owns" I actually mean "feels that he has ownership of"? Perhaps more to the point, who "owns" the development process? It's obviously harder to provide timely responses at present, when no-one can devote even a substantial portion of their time to McCLIM development, than it has been in the past, when students both feckless and directed have had as part of their tasks to work on it: now many of those students are Real People, with jobs and so on to sap their time and energy... Now, we at work are using McCLIM as a substrate for our research and library work, but we seem to be diverging (not too rapidly yet, thankfully) in our local tree despite my having write access, simply because I cannot afford the time to take "ownership" (responsibility, if you will) of the various problems we encounter and work around -- such as the incremental-redisplay performance issues I've mentioned before, the status of arbitrary output-recording streams as candidates for updating-output, and suchlike -- we think we have another problem with freetype fonts (but the report for that might well be stuck in the mailing list moderation queue...), and so on, and so on. I hope I'm not coming on too strong -- I certainly don't expect the world to arrange itself for my convenience, so that I can have what I want, right now -- but I think that we as a time-poor developer community need to think how best to manage going forward with McCLIM, now that a sufficient base of functionality has been built. We don't have the luxury of commercial resources being thrown at us, and I suspect that this isn't going to change in the near term. Sadly, nor do I see much in the way of research funding in this area; these things are always possible -- I will try to sneak in requests for some time to work on the stack of lisp code that we use in future grant applications, for instance -- but the timescale and the odds are unfavourable. We even managed to avoid the shower of money (which, as Einstein proved, is equivalent to time) thrown at the Lisp community by Google -- the project I proposed to integrate R-trees into output-recording was not funded... I suppose this boils down to two questions. Firstly, how do we best manage the development resources that we currently have? Some of this is a social problem, but the good news is that it's mostly technical: experience tells me that we're much better at solving technical problems than social ones. My own feelings on CLiki-as-bugtracker are known, I think, but Paolo is a perfectly acceptable User Interface from my point of view, so while he remains willing to serve like that, it's fine. What we lack is any kind of automatic regression testing to give confidence that bugs remain fixed; lacking a wide userbase as we do, we can't depend on timely notification of regressions from users. I have some of a Null backend for McCLIM which could be used, if completed, as a means of testing even the graphical output protocols; somewhat inevitably, though, I don't have time to advance on it at more than a snail's pace... Secondly, how do we cause the available development resources to grow? Absent sources of funding, this means finding people to work for free... never a great prospect on its own. Killer apps and a certain amount of "evangelism" help; whether a text editor and a score editor are sexy enough for that, I don't know -- is anyone else working on anything exciting? (People here may not know that the closure web browser is at least partially revived: it is known to run in McCLIM using the X backend and recent CMUCL or SBCL releases; on the other hand, there's no way that a web browser is going to be a killer application in today's world...) I'm afraid I don't have any easy answers -- and I know that these things take time. On the other hand, it's possible that a little thought now would reduce the time it takes for the situation with regards to active development to improve... If you've made it down to here, congratulations, and thank you for reading :-). Any thoughts? Cheers, Christophe From amoroso at mclink.it Tue Aug 9 10:49:41 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 09 Aug 2005 12:49:41 +0200 Subject: [mcclim-devel] One char patch to presentation-defs References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> Message-ID: <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > problems than social ones. My own feelings on CLiki-as-bugtracker are > known, I think, but Paolo is a perfectly acceptable User Interface > from my point of view, so while he remains willing to serve like that, > it's fine. What we lack is any kind of automatic regression testing > to give confidence that bugs remain fixed; lacking a wide userbase as Yes, I am still willing to maintain the bug list. Any feedback on that page after using it for some time? Is the page easy to browse? Any redundant information? What about moving the closed bugs section to a different page? As for testing, each time I update my working copy of the CVS repository, I also rebuild the CLIM Listener and play a bit with it. Occasionally, I also do this with the demos. It's not formal testing, but does provide a quick opportunity to see whether anything is obviously broken. > Secondly, how do we cause the available development resources to grow? [...] > anything exciting? (People here may not know that the closure web > browser is at least partially revived: it is known to run in McCLIM > using the X backend and recent CMUCL or SBCL releases; on the other > hand, there's no way that a web browser is going to be a killer > application in today's world...) A web browser application probably not, but a comfortably hackable browser may have some appeal. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From rpgoldman at real-time.com Tue Aug 9 13:18:40 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 9 Aug 2005 08:18:40 -0500 Subject: [mcclim-devel] question about error message Message-ID: <17144.44336.582246.635790@gargle.gargle.HOWL> I run my mcclim application in a separate process under Allegro CL 6.2. Periodically I get the following kind of oddity appearing in my main REPL window (not one of the McCLIM windows): # # # Any idea what this might mean? Am I worried? R From rpgoldman at real-time.com Tue Aug 9 13:29:09 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 9 Aug 2005 08:29:09 -0500 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> Message-ID: <17144.44965.276825.611896@gargle.gargle.HOWL> >>>>> "PA" == Paolo Amoroso writes: PA> Christophe Rhodes writes: >> problems than social ones. My own feelings on CLiki-as-bugtracker are >> known, I think, but Paolo is a perfectly acceptable User Interface >> from my point of view, so while he remains willing to serve like that, >> it's fine. What we lack is any kind of automatic regression testing >> to give confidence that bugs remain fixed; lacking a wide userbase as PA> Yes, I am still willing to maintain the bug list. Any feedback on PA> that page after using it for some time? Is the page easy to browse? PA> Any redundant information? What about moving the closed bugs section PA> to a different page? Is there some reason to do this instead of a Bugzilla? Is the latter just too much of a pain to maintain? PA> As for testing, each time I update my working copy of the CVS PA> repository, I also rebuild the CLIM Listener and play a bit with it. PA> Occasionally, I also do this with the demos. It's not formal testing, PA> but does provide a quick opportunity to see whether anything is PA> obviously broken. Would you consider writing up a McCLIM cliki page describing what you do when you play with the lisp listener? This is the only application beside my own (that I know of) that uses format-graph-from-roots. I'd love to have a quick list of things to try before committing a patch. >> Secondly, how do we cause the available development resources to grow? PA> [...] >> anything exciting? (People here may not know that the closure web >> browser is at least partially revived: it is known to run in McCLIM >> using the X backend and recent CMUCL or SBCL releases; on the other >> hand, there's no way that a web browser is going to be a killer >> application in today's world...) PA> A web browser application probably not, but a comfortably hackable PA> browser may have some appeal. How about a front-end for some of the MP3 stuff in Practical Common Lisp? How about configuration consoles for some of the CL applications out there. E.g., I've just discovered that Albert has a ton of configuration options.... Just a thought.... As an aside, can anyone point me to a sample application that has some pane devoted to displaying information about the state of the application (e.g., a filename that is the current document, mode of interaction, etc.)? I'm a little hazy on how to manage the use of labels, etc. Thanks! R From amoroso at mclink.it Tue Aug 9 14:24:33 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 09 Aug 2005 16:24:33 +0200 Subject: [mcclim-devel] One char patch to presentation-defs References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> <17144.44965.276825.611896@gargle.gargle.HOWL> Message-ID: <87r7d3gpcu.fsf@plato.moon.paoloamoroso.it> rpgoldman at real-time.com writes: > Is there some reason to do this instead of a Bugzilla? Is the latter > just too much of a pain to maintain? This was discussed here in the past, but I don't have links handy. I seem to remember that this is because such tools make reporting bugs too much a hassle. > Would you consider writing up a McCLIM cliki page describing what you > do when you play with the lisp listener? This is the only application I execute this command, which shakes the Listener a bit: Show Class Subclasses (class) t Then I walk the file system a bit by clicking on pathnames. > As an aside, can anyone point me to a sample application that has some > pane devoted to displaying information about the state of the > application (e.g., a filename that is the current document, mode of Do you mean something like a status bar? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From rpgoldman at real-time.com Tue Aug 9 14:53:46 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 9 Aug 2005 09:53:46 -0500 Subject: [mcclim-devel] One char patch to presentation-defs [Lisp listener problems] In-Reply-To: <87r7d3gpcu.fsf@plato.moon.paoloamoroso.it> References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> <17144.44965.276825.611896@gargle.gargle.HOWL> <87r7d3gpcu.fsf@plato.moon.paoloamoroso.it> Message-ID: <17144.50042.147909.136949@gargle.gargle.HOWL> >>>>> "PA" == Paolo Amoroso writes: PA> rpgoldman at real-time.com writes: >> Is there some reason to do this instead of a Bugzilla? Is the latter >> just too much of a pain to maintain? PA> This was discussed here in the past, but I don't have links handy. I PA> seem to remember that this is because such tools make reporting bugs PA> too much a hassle. >> Would you consider writing up a McCLIM cliki page describing what you >> do when you play with the lisp listener? This is the only application PA> I execute this command, which shakes the Listener a bit: PA> Show Class Subclasses (class) t PA> Then I walk the file system a bit by clicking on pathnames. OK, that crashes for me! The problem is that it tries to use a TREE style graph formatting while also setting the merge-duplicates argument to true. When I patched the code to allow actual duplicate merging (AFAICT, this was just ignored before), I made it a violation to have :tree layout and :merge-duplicates = t. When the lisp-listener crashed, I was wondering if this was The Right Thing or not. Alas, the CLIM specification seems unhelpful and possibly even garbled on this point: "If the boolean merge-duplicates is true, then duplicate objects in the graph will share the same node in the display of the graph. That is, when merge-duplicates is true, THE RESULTING GRAPH WILL BE A TREE [emphasis added -rpg]. If merge-duplicates is false (the default), then duplicate objects will be displayed in separate nodes. duplicate-key is a function of one argument that is used to extract the node object component used for duplicate comparison; the default is identity. duplicate-test is a function of two arguments that is used to compare two objects to see if they are duplicates; the default is eql. duplicate-key and duplicate-test have dynamic extent." The material in all caps above seems to be a flat-out mistake --- if you merge duplicates, you can introduce cycles. So it is specifically if merge-duplicates is FALSE that you get a tree, right? I tried temporarily changing :merge-duplicates to NIL Any reason not to do that? As far as I can tell Then when I clicked on an item, the listener crashed for me: Error: Class # is not yet finalized. [condition type: PROGRAM-ERROR] in COM-SHOW-CLASS-SLOTS... I get a number of meta-object related bugs when I do this. Seems like perhaps ACL's MOP implementation is not particularly happy with the class browser. :-( I probably don't have too much time to spend on that, alas. >> As an aside, can anyone point me to a sample application that has some >> pane devoted to displaying information about the state of the >> application (e.g., a filename that is the current document, mode of PA> Do you mean something like a status bar? Yes, that sort of thing. Probably one in CLIMACS, I figure. Seems to be one in the clim-listener I could probably copy. There are two interesting things about the clim-listener "wholine" statusbar: 1. CLIM's layout algorithm seems inadequate --- it seems to require special help to manage the wholine, since there needs to be special compose-space and allocate-space methods. Anyone have any idea why that is? Does this reflect problems with CLIM? 2. Doesn't use incremental redisplay. I would have thought that the wholine, for example, would be a good application for this, since most of the time the user ID won't change, and even the package name is probably pretty stable. Is this because of problems with incremental redisplay? Or is it just that rendering the wholine is so cheap it's not worth the trouble? Thanks, R From amoroso at mclink.it Tue Aug 9 15:29:32 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 09 Aug 2005 17:29:32 +0200 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <87r7d3gpcu.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Tue, 09 Aug 2005 16:24:33 +0200") References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> <17144.44965.276825.611896@gargle.gargle.HOWL> <87r7d3gpcu.fsf@plato.moon.paoloamoroso.it> Message-ID: <87u0hzf7s3.fsf@plato.moon.paoloamoroso.it> Paolo Amoroso writes: > rpgoldman at real-time.com writes: > >> Is there some reason to do this instead of a Bugzilla? Is the latter >> just too much of a pain to maintain? > > This was discussed here in the past, but I don't have links handy. I I do have such a link now: http://www.paoloamoroso.it/log/050227.html But, unfortunately, the links to individual mcclim-devel messages in the archive are stale. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From amoroso at mclink.it Tue Aug 9 15:35:08 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 09 Aug 2005 17:35:08 +0200 Subject: [mcclim-devel] One char patch to presentation-defs [Lisp listener problems] In-Reply-To: <17144.50042.147909.136949@gargle.gargle.HOWL> (rpgoldman@real-time.com's message of "Tue, 9 Aug 2005 09:53:46 -0500") References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> <17144.44965.276825.611896@gargle.gargle.HOWL> <87r7d3gpcu.fsf@plato.moon.paoloamoroso.it> <17144.50042.147909.136949@gargle.gargle.HOWL> Message-ID: <87pssnf7ir.fsf@plato.moon.paoloamoroso.it> rpgoldman at real-time.com writes: > Then when I clicked on an item, the listener crashed for me: [...] > I get a number of meta-object related bugs when I do this. Seems like I use CMUCL, and class browsing commands seem to work fine. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From ahefner at gmail.com Tue Aug 9 15:42:07 2005 From: ahefner at gmail.com (Andy Hefner) Date: Tue, 9 Aug 2005 11:42:07 -0400 Subject: [mcclim-devel] One char patch to presentation-defs [Lisp listener problems] In-Reply-To: <17144.50042.147909.136949@gargle.gargle.HOWL> References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> <17144.44965.276825.611896@gargle.gargle.HOWL> <87r7d3gpcu.fsf@plato.moon.paoloamoroso.it> <17144.50042.147909.136949@gargle.gargle.HOWL> Message-ID: <31ffd3c405080908424aa25ccf@mail.gmail.com> On 8/9/05, rpgoldman at real-time.com wrote: > There are two interesting things about the clim-listener "wholine" > statusbar: > > 1. CLIM's layout algorithm seems inadequate --- it seems to require > special help to manage the wholine, since there needs to be > special compose-space and allocate-space methods. Anyone have any > idea why that is? Does this reflect problems with CLIM? The compose-space method is only there because I'm picky about the size and appearance of the wholine. I'm doing something unusual in the wholine, drawing the beveled decoration behind the text in the handle-repaint method (with output recording off) before replaying the recorded output. This way the decoration does not pollute the output history, and I can redraw the decoration without recomputing the contents of the pane. If the size of the pane changes, the bevel should adjust to fill it. The allocate-space method is there to make this happen (repaint the window when the size changes). A simpler approach might have been to use some kind of border pane around a vanilla application-pane. Still, I think it's good to know how to do this. > 2. Doesn't use incremental redisplay. I would have thought that the > wholine, for example, would be a good application for this, since > most of the time the user ID won't change, and even the package > name is probably pretty stable. Is this because of problems with > incremental redisplay? Or is it just that rendering the wholine > is so cheap it's not worth the trouble? I expect that rendering the wholine is very cheap. From amoroso at mclink.it Tue Aug 9 19:56:25 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 09 Aug 2005 21:56:25 +0200 Subject: [mcclim-devel] Broken links to mcclim-devel message archive Message-ID: <877jeu995i.fsf@plato.moon.paoloamoroso.it> It looks like links established in the past to messages in the mcclim-devel mailing list are now broken. Any changes to the list archive? McCLIM users maintain a wiki-based bug list at: http://mcclim.cliki.net/Bug Each entry has links to relevant messages in mcclim-devel. But such links are now essentially lost. I also have many such links in my blog, where I periodically report about McCLIM development. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From strandh at labri.fr Tue Aug 9 20:58:24 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 9 Aug 2005 22:58:24 +0200 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> Message-ID: <17145.6384.405257.868055@serveur5.labri.fr> Christophe Rhodes writes: > It does raise at least one question, though: who "owns" the McCLIM > code, where by "owns" I actually mean "feels that he has ownership > of"? It would be hard to come up with such a person, I think. > Perhaps more to the point, who "owns" the development process? That's a more reasonable question to ask. I think it would have to be a very active current developer, but I don't see one like that at the moment. Probably Tim Moore would be the one that comes closest. > It's obviously harder to provide timely responses at present, when > no-one can devote even a substantial portion of their time to McCLIM > development, than it has been in the past, when students both feckless > and directed have had as part of their tasks to work on it: now many > of those students are Real People, with jobs and so on to sap their > time and energy... True, and I do think McCLIM needs such an owner (I have called that person a Newman-type person for McCLIM). I am afraid there are no candidates at the moment. And Tim now has a real job, so we can expect even less work on McCLIM from him. > Now, we at work are using McCLIM as a substrate for our research and > library work, but we seem to be diverging (not too rapidly yet, > thankfully) in our local tree despite my having write access, simply > because I cannot afford the time to take "ownership" (responsibility, > if you will) of the various problems we encounter and work around -- > such as the incremental-redisplay performance issues I've mentioned > before, the status of arbitrary output-recording streams as candidates > for updating-output, and suchlike -- we think we have another problem > with freetype fonts (but the report for that might well be stuck in > the mailing list moderation queue...), and so on, and so on. There are indeed many such problems that need to be addressed. While technically speaking I have the time over the next year to take on this ownership, I do not think I will, because I have at least two more large-ish programming projects to take care of. Though I guess if Dave Murray takes care of Climacs, and someone else of Gsharp, I could work on McCLIM :-) Also, like I have said many times, McCLIM needs a near-total overhaul in terms of code maintainability and compliance with the standard. So if I were to take ownership, I would not start by fixing immediate problems, but by improving the code in order to make such fixes easier. We are talking at least a few months of work I would think. > I hope I'm not coming on too strong -- I certainly don't expect the > world to arrange itself for my convenience, so that I can have what I > want, right now -- but I think that we as a time-poor developer > community need to think how best to manage going forward with McCLIM, > now that a sufficient base of functionality has been built. Sure. > I suppose this boils down to two questions. Firstly, how do we best > manage the development resources that we currently have? I think this will be hard unless there is at least one person willing to invest time in understanding the spec and the code. Only someone with a relatively global view of both would be able to determine whether a suggested patch for a problem will break something else. Now, with a bit of luck, that person would not have to actually do that much coding, but could rely on others to actually suggest patches. > What we lack is any kind of automatic regression testing > to give confidence that bugs remain fixed; lacking a wide userbase as > we do, we can't depend on timely notification of regressions from > users. I have some of a Null backend for McCLIM which could be used, > if completed, as a means of testing even the graphical output > protocols; somewhat inevitably, though, I don't have time to advance > on it at more than a snail's pace... Automatic regression testing would be very nice, but it is a huge task in itself. It requires, it seems to me, having understood the spec, which we know is both ambiguous, self contradictory, and incomplete. > Secondly, how do we cause the available development resources to grow? > Absent sources of funding, this means finding people to work for > free... never a great prospect on its own. Killer apps and a certain > amount of "evangelism" help; whether a text editor and a score editor > are sexy enough for that, I don't know -- A score editor certainly has some limited audience, but it could be a killer app to its particular audience. For that, it needs to work properly, which is why I was planning to work on it a bit more this year. A text editor could be a killer app when it acquires functionality comparable to SLIME, and even better in some areas. Implementing most of SLIME in Climacs probably requires a lot of work, but I am guessing that the existence of features unique to Climacs would attract more developers willing to put into it what is currently in SLIME. Though, that will not help McCLIM very much. > is anyone else working on > anything exciting? (People here may not know that the closure web > browser is at least partially revived: it is known to run in McCLIM > using the X backend and recent CMUCL or SBCL releases; on the other > hand, there's no way that a web browser is going to be a killer > application in today's world...) There are two different meanings here to "killer app". The first meaning is an application that is interesting to the general public and that provides functionality that existing applications do not have. Gsharp could become such an application, but it would attract very few, if any, developers. The second meaning is an application that is uniquely hackable because it is written in CL and would therefore attract CL developers who would be willing to put up with fewer features than what some similar existing application have, in return for easily being able to add their own features. Closure and Climacs are such applications. I think the second type of applications would be more suited to attract new developers for McCLIM. And to answer your question, no I am not personally working on anything else, exciting or not. > I'm afraid I don't have any easy answers -- and I know that these > things take time. On the other hand, it's possible that a little > thought now would reduce the time it takes for the situation with > regards to active development to improve... Definitely. > If you've made it down to here, congratulations, and thank you for > reading :-). Any thoughts? I really do think that someone would have to sacrifice the better part of a few months to fully read and understand the spec and the code. It would be easier for someone who has already read and understood the spec, of course. -- 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. --------------------------------------------------------------------- From strandh at labri.fr Tue Aug 9 21:01:28 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 9 Aug 2005 23:01:28 +0200 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <17144.44965.276825.611896@gargle.gargle.HOWL> References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> <17144.44965.276825.611896@gargle.gargle.HOWL> Message-ID: <17145.6568.137728.643938@serveur5.labri.fr> rpgoldman at real-time.com writes: > As an aside, can anyone point me to a sample application that has some > pane devoted to displaying information about the state of the > application (e.g., a filename that is the current document, mode of > interaction, etc.)? I'm a little hazy on how to manage the use of > labels, etc. The only thing I can think about is the info pane in Climacs which provides functionality equivalent to the Emacs mode line. -- 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. --------------------------------------------------------------------- From rpgoldman at real-time.com Tue Aug 9 21:14:19 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 9 Aug 2005 16:14:19 -0500 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <17145.6384.405257.868055@serveur5.labri.fr> References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <17145.6384.405257.868055@serveur5.labri.fr> Message-ID: <17145.7339.717425.934530@gargle.gargle.HOWL> >>>>> "RS" == Robert Strandh writes: RS> Christophe Rhodes writes: [...snip...] RS> Also, like I have said many times, McCLIM needs a near-total overhaul RS> in terms of code maintainability and compliance with the standard. So RS> if I were to take ownership, I would not start by fixing immediate RS> problems, but by improving the code in order to make such fixes RS> easier. We are talking at least a few months of work I would RS> think. Suggestion: if we decide to do such a thing, would it be possible to do another code freeze and "stable" release in the meantime? Esp. if we'd like to get more users, it might be nice for us to have a version that was easy to grab (asdf-install?), and about which programmers could develop an oral tradition involving limitations, workarounds, etc. >> What we lack is any kind of automatic regression testing >> to give confidence that bugs remain fixed; lacking a wide userbase as >> we do, we can't depend on timely notification of regressions from >> users. I have some of a Null backend for McCLIM which could be used, >> if completed, as a means of testing even the graphical output >> protocols; somewhat inevitably, though, I don't have time to advance >> on it at more than a snail's pace... RS> Automatic regression testing would be very nice, but it is a huge task RS> in itself. It requires, it seems to me, having understood the spec, RS> which we know is both ambiguous, self contradictory, and RS> incomplete. I have found that generating tests that exercise a patch every time I generate a patch helps grow a population of regression tests. I see two additional challenges, however: 1. inadequacy of existing regression/unit testing frameworks. I've actually been working on an extension of Waters' RT system for my own projects to meet some of these needs. I found that Waters' system doesn't scale that well --- one needs a notion of test groups and one needs setup and tear-downs. But other frameworks that offered these facilities seemed either to be orphaned (sometimes in a half-finished state) and/or intertwined with large numbers of other libraries. 2. Difficulty of non-graphically testing a graphical framework like McCLIM. RS> The second meaning is an application that is uniquely hackable because RS> it is written in CL and would therefore attract CL developers who RS> would be willing to put up with fewer features than what some similar RS> existing application have, in return for easily being able to add RS> their own features. Closure and Climacs are such RS> applications. I don't mean to carp, but it's hard to see Climacs as such an application because Emacs (resp Xemacs) are already so extensible and they suck up much of the available extension energy. I'm not at all sure that Closure will be such, either, since Firefox is so popular, despite its use of (ugh) JavaScript. What about IRC clients? This seems to have an audience that likes to hack, and the existing ones all seem to have at least one glaring hole... From strandh at labri.fr Tue Aug 9 21:36:40 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 9 Aug 2005 23:36:40 +0200 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <17145.7339.717425.934530@gargle.gargle.HOWL> References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <17145.6384.405257.868055@serveur5.labri.fr> <17145.7339.717425.934530@gargle.gargle.HOWL> Message-ID: <17145.8680.535565.567396@serveur5.labri.fr> rpgoldman at real-time.com writes: > RS> Also, like I have said many times, McCLIM needs a near-total overhaul > RS> in terms of code maintainability and compliance with the standard. So > RS> if I were to take ownership, I would not start by fixing immediate > RS> problems, but by improving the code in order to make such fixes > RS> easier. We are talking at least a few months of work I would > RS> think. > > Suggestion: if we decide to do such a thing, would it be possible to > do another code freeze and "stable" release in the meantime? > > Esp. if we'd like to get more users, it might be nice for us to have a > version that was easy to grab (asdf-install?), and about which > programmers could develop an oral tradition involving limitations, > workarounds, etc. I guess so. Though, a "near-total overhaul" could still be incremental, or that's the way I would do it anyway. > RS> The second meaning is an application that is uniquely hackable because > RS> it is written in CL and would therefore attract CL developers who > RS> would be willing to put up with fewer features than what some similar > RS> existing application have, in return for easily being able to add > RS> their own features. Closure and Climacs are such > RS> applications. > > I don't mean to carp, but it's hard to see Climacs as such an > application because Emacs (resp Xemacs) are already so extensible and I might be wrong of course, but my bet is that when it comes to CL development, extending Emacs or Xemacs will be much harder because of the need to communicate with CL over byte streams. > they suck up much of the available extension energy. perhaps this is a sign that they are not easy enough to extend :-) -- 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. --------------------------------------------------------------------- From smustudent1 at yahoo.com Wed Aug 10 00:36:55 2005 From: smustudent1 at yahoo.com (C Y) Date: Tue, 9 Aug 2005 17:36:55 -0700 (PDT) Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <17145.6384.405257.868055@serveur5.labri.fr> Message-ID: <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> --- Robert Strandh wrote: > There are indeed many such problems that need to be addressed. While > technically speaking I have the time over the next year to take on > this ownership, I do not think I will, because I have at least two > more large-ish programming projects to take care of. Though I guess > if Dave Murray takes care of Climacs, and someone else of Gsharp, I > could work on McCLIM :-) Perhaps you could consider your work on McCLIM to be the necessary preliminary work for Climacs/Gsharp? ;-) > Also, like I have said many times, McCLIM needs a near-total overhaul > in terms of code maintainability and compliance with the standard. > So if I were to take ownership, I would not start by fixing immediate > problems, but by improving the code in order to make such fixes > easier. We are talking at least a few months of work I would think. Personally I give such a goal three cheers! There are not enough major apps/users to cause a severe upset if this is done right now, so now is an excellent time. Indeed, we might regret it if we don't - maintainable code is a MUST in my book. > Automatic regression testing would be very nice, but it is a huge > task in itself. It requires, it seems to me, having understood the > spec, which we know is both ambiguous, self contradictory, and > incomplete. Then we should make this goal part of the overhaul - indeed, I see no other viable way to approach it. Perhaps the spec should merge with the McCLIM code and become a literate document - the code in essence being the fully specific expression of the spec? Perhaps the Axiom philosophy is infecting me but it would seem to be an almost ideal arrangement - use Albert or some such to produce a nice, formatted version of the spec from the source code, and maintain spec and code as one document. > A score editor certainly has some limited audience, but it could be a > killer app to its particular audience. For that, it needs to work > properly, which is why I was planning to work on it a bit more this > year. But CAN it work properly without a revamped and robust McCLIM? > There are two different meanings here to "killer app". The first > meaning is an application that is interesting to the general public > and that provides functionality that existing applications do not > have. Gsharp could become such an application, but it would attract > very few, if any, developers. In open source terms, I still think the ideal "killer app" would be an advanced mathematical document interface. However, that's non-trivial in virtually every way imaginable, and would only attract a few developers. rtoy has broken the ice with a basic interface to Maxima, but a "killer app" level interface would be months and months of work, some of it extremely involved. > The second meaning is an application that is uniquely hackable > because it is written in CL and would therefore attract CL > developers who would be willing to put up with fewer features than > what some similar existing application have, in return for easily > being able to add their own features. Closure and Climacs are such > applications. A math interface would definitely not meet this criteria - too specialized. > I really do think that someone would have to sacrifice the better > part of a few months to fully read and understand the spec and the > code. It would be easier for someone who has already read and > understood the spec, of course. I like your refactoring idea - for McCLIM to take off it should be sufficiently robust to not cause new users any major frustrations beyond learning it in the first place. I personally think the next step should be taken - integrate the spec with the code itself, and iron out any bugs/limitations in the spec that present themselves. Not that I rate an opinion, of course - actual code trumps mere ideas ;-). Cheers, CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From strandh at labri.fr Wed Aug 10 00:55:16 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 10 Aug 2005 02:55:16 +0200 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> Message-ID: <17145.20596.736961.29393@serveur5.labri.fr> C Y writes: > Perhaps you could consider your work on McCLIM to be the necessary > preliminary work for Climacs/Gsharp? ;-) Nice try :-) > > A score editor certainly has some limited audience, but it could be a > > killer app to its particular audience. For that, it needs to work > > properly, which is why I was planning to work on it a bit more this > > year. > > But CAN it work properly without a revamped and robust McCLIM? Yes, I think so. I mean, McCLIM is quite stable (in the sense that it is not crashing) and usable. The main problem for Gsharp is that I have had to write more code than I would have wanted to get around current problems with McCLIM. Of course, at some point, it becomes more advantageous to fix McCLIM than to write workarounds. > In open source terms, I still think the ideal "killer app" would be an > advanced mathematical document interface. However, that's non-trivial > in virtually every way imaginable, and would only attract a few > developers. rtoy has broken the ice with a basic interface to Maxima, > but a "killer app" level interface would be months and months of work, > some of it extremely involved. Nice project, definitely. > for McCLIM to take off it should be > sufficiently robust to not cause new users any major frustrations > beyond learning it in the first place. I personally think the next > step should be taken - integrate the spec with the code itself, and > iron out any bugs/limitations in the spec that present themselves. There are of course many ways of integrating the code and the spec. There are places in the current code with references to the spec, but I am guessing you want to go further than that. I am not sure I see how such integration would have a major impact on the maintainability of the code, though. -- 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. --------------------------------------------------------------------- From rpgoldman at real-time.com Wed Aug 10 01:28:45 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 9 Aug 2005 20:28:45 -0500 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <17145.20596.736961.29393@serveur5.labri.fr> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> Message-ID: <17145.22605.625503.992209@gargle.gargle.HOWL> >>>>> "RS" == Robert Strandh writes: [...snip...] >> But CAN it work properly without a revamped and robust McCLIM? RS> Yes, I think so. I mean, McCLIM is quite stable (in the sense that it RS> is not crashing) and usable. The main problem for Gsharp is that I RS> have had to write more code than I would have wanted to get around RS> current problems with McCLIM. Of course, at some point, it becomes RS> more advantageous to fix McCLIM than to write workarounds. I'm afraid that hasn't really been my experience. I can often crash McCLIM when I do something that upsets its processing of ACCEPT, in particular, and updating output seems to work very, very badly with scrolling panes, so badly that I can't think of a single interaction which hasn't required me to iconify and de-iconify the frame to make it repaint reasonably. And usually I have to resize the frame by hand in the process. This seems to me to be pretty far from usable. This isn't meant to be whining --- I'm working to help improve the situation. But I'm not as sanguine about the current status. As I mention below, I think we need a bunch more gadgets. >> In open source terms, I still think the ideal "killer app" would be an >> advanced mathematical document interface. However, that's non-trivial >> in virtually every way imaginable, and would only attract a few >> developers. rtoy has broken the ice with a basic interface to Maxima, >> but a "killer app" level interface would be months and months of work, >> some of it extremely involved. RS> Nice project, definitely. One could imagine biting off a smaller piece --- perhaps something involving MathML? But typesetting math is not that easy! It took even Knuth a bunch of years! >> for McCLIM to take off it should be >> sufficiently robust to not cause new users any major frustrations >> beyond learning it in the first place. I think it should also be enhanced to be able to generate interfaces that don't cause their users (as opposed to their programmers) cognitive upset. So there ought to be file-choosers that look mostly like other file-choosers, etc. Unfortunately, that's a lot of gadgetage to be written. For me, McCLIM is useful because it lets me build UIs that are good for me to use, which mostly means for debugging --- the objects are very "apparent" and I can grab them and wrestle with them in the REPL. To be honest, if I wanted to just write a user interface for real users (FSVO "real"), I'd be inclined to just bolt something onto a lisp server using a more conventional framework, and a different programming language. >> I personally think the next step should be taken - integrate >> the spec with the code itself, and iron out any >> bugs/limitations in the spec that present themselves. RS> There are of course many ways of integrating the code and the spec. RS> There are places in the current code with references to the spec, but RS> I am guessing you want to go further than that. I am not sure I see RS> how such integration would have a major impact on the maintainability RS> of the code, though. A simple step that could be taken would be to put bits of the spec into the documentation strings. I don't have the appetite for that level of cut-and-paste drudgery, though :-/ As far as ironing out bugs and limitations in the spec, we probably need to have a real project owner to make that feasible. Which takes us back to Christophe's original question. ;-) R From rpgoldman at real-time.com Wed Aug 10 01:31:07 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 9 Aug 2005 20:31:07 -0500 Subject: [mcclim-devel] One char patch to presentation-defs [Lisp listener problems] In-Reply-To: <87pssnf7ir.fsf@plato.moon.paoloamoroso.it> References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> <17144.44965.276825.611896@gargle.gargle.HOWL> <87r7d3gpcu.fsf@plato.moon.paoloamoroso.it> <17144.50042.147909.136949@gargle.gargle.HOWL> <87pssnf7ir.fsf@plato.moon.paoloamoroso.it> Message-ID: <17145.22747.114485.487221@gargle.gargle.HOWL> >>>>> "PA" == Paolo Amoroso writes: PA> rpgoldman at real-time.com writes: >> Then when I clicked on an item, the listener crashed for me: PA> [...] >> I get a number of meta-object related bugs when I do this. Seems like PA> I use CMUCL, and class browsing commands seem to work fine. They're badly busted for me. This seems like a morass of ACL MOP tweaking, alas. So this probably won't be a good way for me to evaluate graph-formatting patches. :-( R From smustudent1 at yahoo.com Wed Aug 10 01:27:26 2005 From: smustudent1 at yahoo.com (C Y) Date: Tue, 9 Aug 2005 18:27:26 -0700 (PDT) Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <17145.20596.736961.29393@serveur5.labri.fr> Message-ID: <20050810012727.96523.qmail@web31702.mail.mud.yahoo.com> --- Robert Strandh wrote: > C Y writes: > > Perhaps you could consider your work on McCLIM to be the necessary > > preliminary work for Climacs/Gsharp? ;-) > > Nice try :-) It was worth a shot :-P > Yes, I think so. I mean, McCLIM is quite stable (in the sense that > it is not crashing) and usable. The main problem for Gsharp is that > I have had to write more code than I would have wanted to get around > current problems with McCLIM. Of course, at some point, it becomes > more advantageous to fix McCLIM than to write workarounds. Ah, OK. > There are of course many ways of integrating the code and the spec. > There are places in the current code with references to the spec, but > I am guessing you want to go further than that. I am not sure I see > how such integration would have a major impact on the maintainability > of the code, though. Well, it's more a case of convenience, but the psychology is good too - when you write a piece of code the text describing the purpose of the code is right there for reference/documentation, and if you need to update the spec due to code enhancements it's again right there. It's the whole "literate programming" thing. I know actions speak louder than words on such things though :-/. Cheers, CY ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From strandh at labri.fr Wed Aug 10 01:48:53 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 10 Aug 2005 03:48:53 +0200 Subject: [mcclim-devel] One char patch to presentation-defs In-Reply-To: <20050810012727.96523.qmail@web31702.mail.mud.yahoo.com> References: <17145.20596.736961.29393@serveur5.labri.fr> <20050810012727.96523.qmail@web31702.mail.mud.yahoo.com> Message-ID: <17145.23813.922418.78811@serveur5.labri.fr> C Y writes: > Well, it's more a case of convenience, but the psychology is good too - > when you write a piece of code the text describing the purpose of the > code is right there for reference/documentation, and if you need to > update the spec due to code enhancements it's again right there. It's > the whole "literate programming" thing. I know actions speak louder > than words on such things though :-/. I know only very little about literate programming, but it seems to me hard to obtain in an advanced programming language like CL, where the actual implementation of some functionality could be spread out over several files, so that you could not naturally get a textual association between the code and the spec. Also, there is obviously a lot of code that corresponds to nothing at all in the spec, but which should be documented nevertheless. It looks to me like an integrated documentation system like Concordia would be more appropriate. Luckily, McCLIM would be ideal for implementing such a system. Now, we just have to find someone to do that. -- 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. --------------------------------------------------------------------- From strandh at labri.fr Wed Aug 10 01:59:34 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 10 Aug 2005 03:59:34 +0200 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <17145.22605.625503.992209@gargle.gargle.HOWL> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> Message-ID: <17145.24454.602591.361477@serveur5.labri.fr> rpgoldman at real-time.com writes: > I'm afraid that hasn't really been my experience. I can often crash > McCLIM when I do something that upsets its processing of ACCEPT, in > particular, and updating output seems to work very, very badly with > scrolling panes, so badly that I can't think of a single interaction > which hasn't required me to iconify and de-iconify the frame to make > it repaint reasonably. And usually I have to resize the frame by hand > in the process. This seems to me to be pretty far from usable. OK. I guess I just haven't had to use those parts of McCLIM. > This isn't meant to be whining --- I'm working to help improve the > situation. But I'm not as sanguine about the current status. As I > mention below, I think we need a bunch more gadgets. Well, yes, sort of. I mean, since CLIM is so stratified, it is *possible* though not necessarily *desirable* for an application to implement the gadgets it needs. This fact makes it less urgent to add more functionality to McCLIM. I do think stability and compliance are higher up on the list. > One could imagine biting off a smaller piece --- perhaps something > involving MathML? But typesetting math is not that easy! It took > even Knuth a bunch of years! TeXmacs does a fairly good job, it seems. Now if we could only convince Joris to use CL and McCLIM... > I think it should also be enhanced to be able to generate interfaces > that don't cause their users (as opposed to their programmers) > cognitive upset. So there ought to be file-choosers that look mostly > like other file-choosers, etc. > > Unfortunately, that's a lot of gadgetage to be written. Yeah, but that's the fairly easy part. Anyone who has a week or so of time to spend could do that. > A simple step that could be taken would be to put bits of the spec > into the documentation strings. I don't have the appetite for that > level of cut-and-paste drudgery, though :-/ Also, see my previous message. Sometimes there is not a very immediate association between code and spec text. > As far as ironing out bugs and limitations in the spec, we probably > need to have a real project owner to make that feasible. Which takes > us back to Christophe's original question. ;-) It is a totally different project in my opinion. To improve the current code, the owner needs to know both the spec and the code. To improve the spec, only a limited amount of knowledge of the code is required. -- 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. --------------------------------------------------------------------- From moore at bricoworks.com Wed Aug 10 03:49:51 2005 From: moore at bricoworks.com (Timothy Moore) Date: Tue, 9 Aug 2005 23:49:51 -0400 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <17145.22605.625503.992209@gargle.gargle.HOWL> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> Message-ID: <4b3329def8aba5fcaac94236be8f55ae@bricoworks.com> On Aug 9, 2005, at 9:28 PM, rpgoldman at real-time.com wrote: > I'm afraid that hasn't really been my experience. I can often crash > McCLIM when I do something that upsets its processing of ACCEPT, in > particular, and updating output seems to work very, very badly with > scrolling panes, so badly that I can't think of a single interaction > which hasn't required me to iconify and de-iconify the frame to make > it repaint reasonably. And usually I have to resize the frame by hand > in the process. This seems to me to be pretty far from usable. I'm not necessarily disagreeing about the state of accept (more accurately input editing) and incremental redisplay, but I'm having some trouble searching through the mail archives for specific complaints. In particular I have not noticed problems with scrolling and updating-output in my use of it. Do you mind (re)posting some specific bugs? Thanks a lot, Tim From mmommer at common-lisp.net Wed Aug 10 08:18:46 2005 From: mmommer at common-lisp.net (Mario Mommer) Date: Wed, 10 Aug 2005 10:18:46 +0200 Subject: [mcclim-devel] Re: [admin] Broken links to mcclim-devel message archive In-Reply-To: <877jeu995i.fsf@plato.moon.paoloamoroso.it> References: <877jeu995i.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > It looks like links established in the past to messages in the > mcclim-devel mailing list are now broken. Any changes to the list > archive? I foolishly trusted apt-get dist-upgrade to do the right thing a few weeks ago. If it did something thoroughly, it was making a mess of things. We have been cleaning up the radioactive fallout for weeks now, and I presume you are getting your share of it :-| Are the messages still there? If not, I can rebuild the archive etc. Regards, Mario. From amoroso at mclink.it Wed Aug 10 11:06:46 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Wed, 10 Aug 2005 13:06:46 +0200 Subject: [mcclim-devel] One char patch to presentation-defs [Lisp listener problems] In-Reply-To: <17145.22747.114485.487221@gargle.gargle.HOWL> (rpgoldman@real-time.com's message of "Tue, 9 Aug 2005 20:31:07 -0500") References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> <17144.44965.276825.611896@gargle.gargle.HOWL> <87r7d3gpcu.fsf@plato.moon.paoloamoroso.it> <17144.50042.147909.136949@gargle.gargle.HOWL> <87pssnf7ir.fsf@plato.moon.paoloamoroso.it> <17145.22747.114485.487221@gargle.gargle.HOWL> Message-ID: <87fytioxtl.fsf@plato.moon.paoloamoroso.it> rpgoldman at real-time.com writes: > They're badly busted for me. This seems like a morass of ACL MOP > tweaking, alas. So this probably won't be a good way for me to What about Closer (Closer to MOP in particular)? http://common-lisp.net/project/closer Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From rpgoldman at real-time.com Wed Aug 10 14:57:17 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 10 Aug 2005 09:57:17 -0500 Subject: [mcclim-devel] pathname and accept Message-ID: <17146.5581.230583.547775@gargle.gargle.HOWL> [Apologies if this is a dumb question...] AFAICT there's no way for me to try to ACCEPT a pathname that is constrained to refer to a file that already exists. Is this true? I could imagine trying to create a new presentation subtype of pathname that would meet this constraint. But doesn't it seem that it would have been reasonable to make a pathname a compound type that would allow for constraints? Also, I have been looking at the Allegro CLIM UG and the CLIM 2 spec, and I have not been able to determine what sort of guarantees ACCEPT provides. When it reads one of my previously-existing pathnames, for example, will it be obligated to run presentation-typep at some point to check that the filename is actually previously-extant? Or is it allowed to just hope that the user has typed in a string that refers to a previously-existing filename, instead of the name of his grandmother's dog? I don't know exactly how to test this, but my rudimentary tests with trace seem to indicate that ACCEPT isn't doing any verification. Is that right? If so, and I want to enforce this constraint, should I be making an :around method for accept that will check the constraint and either return if it's satisfied, or invoke call-next-method if it's violated? I would have thought that there would have been some protocol for bad input (e.g., raise a particular exceptionq), but my cursory examination of the spec doesn't reveal any such. Thanks, Robert From moore at bricoworks.com Wed Aug 10 15:31:39 2005 From: moore at bricoworks.com (Timothy Moore) Date: Wed, 10 Aug 2005 11:31:39 -0400 Subject: [mcclim-devel] pathname and accept In-Reply-To: <17146.5581.230583.547775@gargle.gargle.HOWL> References: <17146.5581.230583.547775@gargle.gargle.HOWL> Message-ID: <334c9974b086af655626e25e74acd085@bricoworks.com> On Aug 10, 2005, at 10:57 AM, rpgoldman at real-time.com wrote: > > [Apologies if this is a dumb question...] > > AFAICT there's no way for me to try to ACCEPT a pathname that is > constrained to refer to a file that already exists. Is this true? Yes. > I could imagine trying to create a new presentation subtype of > pathname that would meet this constraint. Yes. > > But doesn't it seem that it would have been reasonable to make a > pathname a compound type that would allow for constraints? Maybe, but the CLIM presentation types are close analogues to the Common Lisp types. > > Also, I have been looking at the Allegro CLIM UG and the CLIM 2 spec, > and I have not been able to determine what sort of guarantees ACCEPT > provides. When it reads one of my previously-existing pathnames, for > example, will it be obligated to run presentation-typep at some point > to check that the filename is actually previously-extant? Or is it > allowed to just hope that the user has typed in a string that refers > to a previously-existing filename, instead of the name of his > grandmother's dog? I believe that the user (programmer) has the freedom to pair any object with any presentation type in a presentation; if that breaks other code, then that's his problem. If an application needs a strong guarantee that the user (user) enters a valid object for a presentation type then the accept method should check that before returning. > I don't know exactly how to test this, but my rudimentary tests with > trace seem to indicate that ACCEPT isn't doing any verification. Is > that right? Yes. > > If so, and I want to enforce this constraint, should I be making an > :around method for accept that will check the constraint and either > return if it's satisfied, or invoke call-next-method if it's violated? > That's one way to do it. Be sure to return all the values returned by the primary presentation method. You could also call accept recursively from the accept method for your type. > I would have thought that there would have been some protocol for bad > input (e.g., raise a particular exceptionq), but my cursory examination > of the spec doesn't reveal any such. > See 24.3 in the Input Editing chapter which describes the conditions SIMPLE-PARSE-ERROR and INPUT-NOT-OF-REQUIRED-TYPE. Tim From moore at bricoworks.com Wed Aug 10 15:53:34 2005 From: moore at bricoworks.com (Timothy Moore) Date: Wed, 10 Aug 2005 11:53:34 -0400 Subject: [mcclim-devel] pathname and accept In-Reply-To: <334c9974b086af655626e25e74acd085@bricoworks.com> References: <17146.5581.230583.547775@gargle.gargle.HOWL> <334c9974b086af655626e25e74acd085@bricoworks.com> Message-ID: <506d92f175ae0efeda97bc820d06f69f@bricoworks.com> On Aug 10, 2005, at 11:31 AM, Timothy Moore wrote: >> I would have thought that there would have been some protocol for bad >> input (e.g., raise a particular exceptionq), but my cursory >> examination >> of the spec doesn't reveal any such. >> > See 24.3 in the Input Editing chapter which describes the conditions > SIMPLE-PARSE-ERROR and INPUT-NOT-OF-REQUIRED-TYPE. > > Tim I should mention that this section is erroneously called "Signaling Errors inside present methods." This errors are designed to be signaled inside of accept methods! Tim From rpgoldman at real-time.com Wed Aug 10 16:01:03 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 10 Aug 2005 11:01:03 -0500 Subject: [mcclim-devel] pathname and accept In-Reply-To: <334c9974b086af655626e25e74acd085@bricoworks.com> References: <17146.5581.230583.547775@gargle.gargle.HOWL> <334c9974b086af655626e25e74acd085@bricoworks.com> Message-ID: <17146.9407.628088.525483@gargle.gargle.HOWL> >>>>> "TM" == Timothy Moore writes: TM> On Aug 10, 2005, at 10:57 AM, rpgoldman at real-time.com wrote: >> >> [Apologies if this is a dumb question...] >> >> AFAICT there's no way for me to try to ACCEPT a pathname that is >> constrained to refer to a file that already exists. Is this true? TM> Yes. >> I could imagine trying to create a new presentation subtype of >> pathname that would meet this constraint. TM> Yes. >> >> But doesn't it seem that it would have been reasonable to make a >> pathname a compound type that would allow for constraints? TM> Maybe, but the CLIM presentation types are close analogues to the TM> Common Lisp types. >> >> Also, I have been looking at the Allegro CLIM UG and the CLIM 2 spec, >> and I have not been able to determine what sort of guarantees ACCEPT >> provides. When it reads one of my previously-existing pathnames, for >> example, will it be obligated to run presentation-typep at some point >> to check that the filename is actually previously-extant? Or is it >> allowed to just hope that the user has typed in a string that refers >> to a previously-existing filename, instead of the name of his >> grandmother's dog? TM> I believe that the user (programmer) has the freedom to pair TM> any object with any presentation type in a presentation; if TM> that breaks other code, then that's his problem. If an TM> application needs a strong guarantee that the user (user) TM> enters a valid object for a presentation type then the accept TM> method should check that before returning. [...snip...] >> >> If so, and I want to enforce this constraint, should I be making an >> :around method for accept that will check the constraint and either >> return if it's satisfied, or invoke call-next-method if it's violated? >> TM> That's one way to do it. Be sure to return all the values TM> returned by the primary presentation method. You could also TM> call accept recursively from the accept method for your type. Thanks, I thought CALL-NEXT-METHOD would be the most convenient way to do this, since it frees me from worrying about how to pass in the boatload of keyword arguments! >> I would have thought that there would have been some protocol for bad >> input (e.g., raise a particular exceptionq), but my cursory examination >> of the spec doesn't reveal any such. >> TM> See 24.3 in the Input Editing chapter which describes the conditions TM> SIMPLE-PARSE-ERROR and INPUT-NOT-OF-REQUIRED-TYPE. Thanks. I did look at those. The problem is that if I hoist an INPUT-NOT-OF-REQUIRED-TYPE error, it's just that --- an error. There is no automagical trapping to reprompt to get good input. We just throw an error at the user, which doesn't seem like a very nice thing to do... This seems particularly bad if one has a complex command with multiple arguments. Then you go to a lot of trouble to fill out five arguments, only to find that the first one was garbage. :-( R From moore at bricoworks.com Wed Aug 10 17:47:57 2005 From: moore at bricoworks.com (Timothy Moore) Date: Wed, 10 Aug 2005 13:47:57 -0400 Subject: [mcclim-devel] pathname and accept In-Reply-To: <17146.9407.628088.525483@gargle.gargle.HOWL> References: <17146.5581.230583.547775@gargle.gargle.HOWL> <334c9974b086af655626e25e74acd085@bricoworks.com> <17146.9407.628088.525483@gargle.gargle.HOWL> Message-ID: On Aug 10, 2005, at 12:01 PM, rpgoldman at real-time.com wrote: >>>>>> "TM" == Timothy Moore writes: > TM> See 24.3 in the Input Editing chapter which describes the > conditions > TM> SIMPLE-PARSE-ERROR and INPUT-NOT-OF-REQUIRED-TYPE. > > Thanks. I did look at those. The problem is that if I hoist an > INPUT-NOT-OF-REQUIRED-TYPE error, it's just that --- an error. There > is no automagical trapping to reprompt to get good input. We just > throw an error at the user, which doesn't seem like a very nice thing > to do... Ah, but that's a quality of implementation issue. I think it would be completely reasonable for the command reader to do something friendly with these errors. The accepting-values code does try to something reasonable with any error that results from accept. > This seems particularly bad if one has a complex command with multiple > arguments. Then you go to a lot of trouble to fill out five > arguments, only to find that the first one was garbage. :-( > Yup. Tim From mmommer at common-lisp.net Wed Aug 10 18:23:44 2005 From: mmommer at common-lisp.net (Mario Mommer) Date: Wed, 10 Aug 2005 20:23:44 +0200 Subject: [mcclim-devel] Re: [admin] Broken links to mcclim-devel message archive In-Reply-To: <877jeu995i.fsf@plato.moon.paoloamoroso.it> References: <877jeu995i.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > It looks like links established in the past to messages in the > mcclim-devel mailing list are now broken. Any changes to the list > archive? > > McCLIM users maintain a wiki-based bug list at: > > http://mcclim.cliki.net/Bug > > Each entry has links to relevant messages in mcclim-devel. But such > links are now essentially lost. I also have many such links in my > blog, where I periodically report about McCLIM development. All but the first link on that page (the one from june 2005) seem to be working now. I presume that this particular message has a much higher number now that the old messages (1999 - dez. 2004) reappeared. If you have any further problems with this, let me know. Sorry for this. Regards, Mario. From amoroso at mclink.it Wed Aug 10 18:31:39 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Wed, 10 Aug 2005 20:31:39 +0200 Subject: [mcclim-devel] Re: [admin] Broken links to mcclim-devel message archive In-Reply-To: (Mario Mommer's message of "Wed, 10 Aug 2005 20:23:44 +0200") References: <877jeu995i.fsf@plato.moon.paoloamoroso.it> Message-ID: <87k6itmyno.fsf@plato.moon.paoloamoroso.it> Mario Mommer writes: > Paolo Amoroso writes: [...] >> http://mcclim.cliki.net/Bug [...] > All but the first link on that page (the one from june 2005) seem to > be working now. I presume that this particular message has a much I think I have fixed this, and everything else looks good. Thanks, Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From rpgoldman at sift.info Wed Aug 10 19:05:20 2005 From: rpgoldman at sift.info (Robert P. Goldman) Date: Wed, 10 Aug 2005 14:05:20 -0500 Subject: [mcclim-devel] pathname and accept In-Reply-To: References: <17146.5581.230583.547775@gargle.gargle.HOWL> <334c9974b086af655626e25e74acd085@bricoworks.com> <17146.9407.628088.525483@gargle.gargle.HOWL> Message-ID: <17146.20464.395412.686332@gargle.gargle.HOWL> >>>>> "TM" == Timothy Moore writes: TM> On Aug 10, 2005, at 12:01 PM, rpgoldman at real-time.com wrote: >>>>>>> "TM" == Timothy Moore writes: TM> See 24.3 in the Input Editing chapter which describes the >> conditions TM> SIMPLE-PARSE-ERROR and INPUT-NOT-OF-REQUIRED-TYPE. >> >> Thanks. I did look at those. The problem is that if I hoist an >> INPUT-NOT-OF-REQUIRED-TYPE error, it's just that --- an error. There >> is no automagical trapping to reprompt to get good input. We just >> throw an error at the user, which doesn't seem like a very nice thing >> to do... TM> Ah, but that's a quality of implementation issue. I think it would be TM> completely reasonable for the command reader to do something friendly TM> with these errors. The accepting-values code does try to something TM> reasonable with any error that results from accept. A related problem is that when I tried to set up accept to do the reprompting along the lines that I had mentioned in my earlier email, I found that it turned the pane whence command argument values were being read into gobbledygook --- my format string, that was supposed to tell the user s/he had done something wrong, got echoed all over the form for inputting values, making it unusable. :-( I.e., modifying the ACCEPT method for this purpose seems inappropriate, since you don't have enough control over the context within which ACCEPT will be invoked. This seems to suggest that one might need to modify STREAM-ACCEPT instead. But that seems like a bit of a Catch-22. That option seems pretty much open to you only if (a) you provide a completely new method for stream-accept or (b) you have access to the source code to modify. So does this mean that we have, in McCLIM, a version of ACCEPT that doesn't provide enough of a stable context for us to extend built-in methods? Is the spec insufficiently strong to allow us to extend the ACCEPT protocol without risk of breaking things? Or have I overlooked something (quite likely, alas)? Best, R From rpgoldman at real-time.com Wed Aug 10 21:54:29 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 10 Aug 2005 16:54:29 -0500 Subject: [mcclim-devel] pathname and accept In-Reply-To: <992ebe178875c785495d16ebfc6d880a@bricoworks.com> References: <17146.5581.230583.547775@gargle.gargle.HOWL> <334c9974b086af655626e25e74acd085@bricoworks.com> <17146.9407.628088.525483@gargle.gargle.HOWL> <17146.20464.395412.686332@gargle.gargle.HOWL> <992ebe178875c785495d16ebfc6d880a@bricoworks.com> Message-ID: <17146.30613.412192.78422@gargle.gargle.HOWL> Sorry. Let me be more clear (or at least more specific). I have an application that is an MDP (Markov Decision Problem) solver. I have a command that loads a file with an MDP description in it. So I want to ACCEPT a pathname that corresponds to an existing MDP description file. So I want ACCEPT to reject any pathname that doesn't (at least) correspond to a file that really exists. It's a bit of a nuisance, when I use the current UI (which doesn't enforce file existence), to type in a filename, find out that I mistyped, and then have to start over. I would prefer to have ACCEPT help me out by rejecting my input and allowing me to revise it. Does that help? The best test example I could find was the following: (in-package :CLIM-USER) ;;; this stuff doesn't work as well as I would like, unfortunately. [2005/08/10:rpg] (define-presentation-type extant-pathname () :inherit-from 'pathname) (define-presentation-method presentation-typep (object (type extant-pathname)) (and (presentation-typep object 'pathname) (probe-file object))) (define-presentation-method accept ((type extant-pathname) stream view &rest args &key) (let ((raw-value (call-next-method))) (when (probe-file raw-value) (return-from accept (values raw-value 'extant-pathname))) (format stream "~&No directory entry for ~A ~%" raw-value) (apply #'accept type :stream stream :view view args))) But when I try to do this, and type in a pathname that does not correspond to an extant file, it seems to return some odd default. McCLIM correctly rejects the bad value, and prints my format string, but instead of giving me a chance to enter a good value, it just returns the current working directory! (I'd show the results, but I tested in the clim-listener, whence I cannot cut-and-paste :-/). I'm hoping that I've just done something dopey here, and that's why this doesn't work. [BTW, I was poking around at the CLIMACS code base to see if I could pull out a completing-pathname type, but I thought I would see if I could get the existence constraint to work first...] From rpgoldman at sift.info Wed Aug 10 22:02:08 2005 From: rpgoldman at sift.info (Robert P. Goldman) Date: Wed, 10 Aug 2005 17:02:08 -0500 Subject: [mcclim-devel] patch for CLIM-LISTENER on Allegro Message-ID: <17146.31072.582211.632931@gargle.gargle.HOWL> I was just looking over the clim-listener to see how the wholine worked, and in passing found that its recipe for getting a user id doesn't work on Allegro. Here's a quick patch. As an aside, I couldn't find anything that would provide a description of mem usage that would fit the one-liner in here for other lisps. All I could find was ROOM, which seemed to give too much information.... Finally, is there any reason we shouldn't all set ;; Set this to true if you want the listener to bind *debug-io* to the ;; listener window. (defparameter *listener-use-debug-io* #+hefner t #-hefner nil) to T instead of NIL? For me, at least on Allegro, the utility of the system is vitiated by having it lock up and dump the debug output into my emacs window. But perhaps there's a downside to this that I don't know about.... Best, R Index: listener.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Apps/Listener/listener.lisp,v retrieving revision 1.21 diff -u -F^(def -r1.21 listener.lisp --- listener.lisp 11 Jan 2005 05:26:26 -0000 1.21 +++ listener.lisp 10 Aug 2005 21:56:46 -0000 @@ -72,7 +72,8 @@ (defun generate-wholine-contents (frame (declare (ignore frame)) (let* ((*standard-output* pane) (username (or #+cmu (cdr (assoc :user ext:*environment-list*)) - #-cmu (getenv "USER") + #+allegro (sys:getenv "USER") + #-(or allegro cmu) (getenv "USER") "luser")) ; sorry.. (sitename (machine-instance)) (memusage #+cmu (lisp::dynamic-usage) From rpgoldman at real-time.com Thu Aug 11 02:33:23 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 10 Aug 2005 21:33:23 -0500 Subject: [mcclim-devel] One char patch to presentation-defs [Lisp listener problems] In-Reply-To: <87fytioxtl.fsf@plato.moon.paoloamoroso.it> References: <42E79BE1.6010606@cpmg.tv> <19078b56a3f8c97844458797e119c671@bricoworks.com> <87d5onjsfu.fsf@plato.moon.paoloamoroso.it> <17144.44965.276825.611896@gargle.gargle.HOWL> <87r7d3gpcu.fsf@plato.moon.paoloamoroso.it> <17144.50042.147909.136949@gargle.gargle.HOWL> <87pssnf7ir.fsf@plato.moon.paoloamoroso.it> <17145.22747.114485.487221@gargle.gargle.HOWL> <87fytioxtl.fsf@plato.moon.paoloamoroso.it> Message-ID: <17146.47347.652615.708698@gargle.gargle.HOWL> >>>>> "PA" == Paolo Amoroso writes: PA> rpgoldman at real-time.com writes: >> They're badly busted for me. This seems like a morass of ACL MOP >> tweaking, alas. So this probably won't be a good way for me to PA> What about Closer (Closer to MOP in particular)? PA> http://common-lisp.net/project/closer Thanks, but I'm primarily interested in the CLIM listener as a way to test my graph-drawing patches. I don't want to bite off another chunk of McCLIM to work on, just yet! :-) Best, R From rpgoldman at real-time.com Thu Aug 11 02:37:07 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 10 Aug 2005 21:37:07 -0500 Subject: [mcclim-devel] question about CLIM listener and FORMAT-GRAPH-FROM-ROOTS Message-ID: <17146.47571.704406.624241@gargle.gargle.HOWL> I found that the clim-listener calls format-graph-from-roots with :tree as the graph type, but :merge-duplicates=t. The spec sorta ambiguously suggests that these aren't compatible. Is there any reason why you did this? Of course, it's possible that this was because formerly there was no layout method for :dag or :digraph, and :merge-duplicates=t would force the choice of one of those methods.... But I had thought about sending a warning if one made this choice, and turning off :merge-duplicates in that case. So I would like to make sure this wouldn't be a problem. Would you mind having to change to :tree and :merge-duplicates=nil? Best, R From ahefner at gmail.com Thu Aug 11 03:19:35 2005 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 10 Aug 2005 23:19:35 -0400 Subject: [mcclim-devel] Re: question about CLIM listener and FORMAT-GRAPH-FROM-ROOTS In-Reply-To: <17146.47571.704406.624241@gargle.gargle.HOWL> References: <17146.47571.704406.624241@gargle.gargle.HOWL> Message-ID: <31ffd3c4050810201957b3f57a@mail.gmail.com> As you guessed, I did that because there was no :dag or :digraph, and because it worked. On 8/10/05, rpgoldman at real-time.com wrote: > > I found that the clim-listener calls format-graph-from-roots with > :tree as the graph type, but :merge-duplicates=t. The spec sorta > ambiguously suggests that these aren't compatible. Is there any > reason why you did this? > > Of course, it's possible that this was because formerly there was no > layout method for :dag or :digraph, and :merge-duplicates=t would > force the choice of one of those methods.... > > But I had thought about sending a warning if one made this choice, and > turning off :merge-duplicates in that case. So I would like to make > sure this wouldn't be a problem. > > Would you mind having to change to :tree and :merge-duplicates=nil? > > Best, > R > From csr21 at cam.ac.uk Thu Aug 11 14:38:56 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 11 Aug 2005 15:38:56 +0100 Subject: [mcclim-devel] text with negative x-offsets Message-ID: [ to the real mcclim-devel address, this time ] Hi, Find attached a preliminary patch to deal with the fact that, in general, glyphs from fonts are not constrained to draw only to the right of the cursor position. This patch does not correct any of the assumptions about horizontal left-to-right rendering or single-line rendering. However, it attempts to cater for all cases which are currently functional, for the CLX backend (both with ordinary X fonts and with the experimental Freetype bindings). It is probably fairly tricky to trigger problems without this patch using the ordinary X fonts, but using the Bitstream Vera family of fonts in climacs for a little while tends to degrade the display as incremental-redisplay fails to erase the entirety of glyphs (because the bounding rectangle is wrong). It works by introducing a new internal function, TEXT-BOUNDING-RECTANGLE*, which is somewhat analogous to TEXT-SIZE and STREAM-STRING-WIDTH, only capable of dealing with non-zero offsets. TEXT-BOUNDING-RECTANGLE* returns the coordinates of a bounding rectangle that would bound the output of DRAW-TEXT* at position 0 0 and with :ALIGN-X and ALIGN-Y taking their default values. It is entirely possible that I have miscalculated some of the other cases in DEF-GRECORDING DRAW-TEXT: caveat user. With this patch, I was no longer able to trigger disastrous redraw effects on simple climacs editing operations; previously, entering " ___" on a line, putting point at the start of the line and then hitting the space bar a few times would leave a trail of pixels as the output records for almost all the text would move (on my display here, with my freetype options, the #\_ character has an active pixel at -1). The real test case for this is the tablature editor, which is using a font designed such that the centres of characters are at (0,0); unfortunately, I'm not in a position to run it right now, but with luck we'll be able to test this tomorrow (and extend this work to the Postscript backend: maintainers of other backends should chime in at this point to indicate whether this solution is acceptable and implementable :-). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: text-output-records.diff URL: -------------- next part -------------- Cheers, Christophe From rpgoldman at real-time.com Fri Aug 12 02:37:28 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Thu, 11 Aug 2005 21:37:28 -0500 Subject: [mcclim-devel] two fixes for graph formatting Message-ID: <17148.2920.117037.111673@gargle.gargle.HOWL> Previously format-graph-from-roots would crash if given a :duplicate-test argument that wasn't one of the equality predicates accepted by make-hash-table. Previously format-graph-from-roots would crash if asked to format a :dag. This is fixed. Sorta. I'm not bragging about the dag layout method --- it really needs a nice layering, but doesn't have one yet. But I hope it's better than crashing! Note that it will /still/ crash if asked to format a general :digraph. When I was testing this, I discovered that FORMAT-GRAPH-FROM-ROOT, the singleton wrapper, wasn't exported from the CLIM package. Since it's required by the spec, I added the export, and committed package.lisp. My first commit. Hope I haven't gaffed anything! Seems like the clim-listener still works, and that's really my only test case... Cheers, R From rpgoldman at real-time.com Fri Aug 12 02:41:31 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Thu, 11 Aug 2005 21:41:31 -0500 Subject: [mcclim-devel] bug list on mcclim cliki Message-ID: <17148.3163.255245.760669@gargle.gargle.HOWL> Alas, while the links to the mail archive no longer dangle, they don't work, either. I was looking at some of the links in the bug list, and they are garbled and point to the wrong thing. E.g., the link for "Graph nodes are incorrectly placed when scale factor <> 1" now points to this email: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole Paolo Amoroso amoroso at mclink.it Tue Mar 22 17:11:24 CET 2005 * Previous message: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole * Next message: [mcclim-devel] more beagle stuff * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Christophe Rhodes writes: > Right. Reading around the web indicates that Klipper is not > completely alone in its strategy of polling the selection owner for > the timestamp of its selection ownership to see if anything has > changed. > > I've therefore committed more-or-less what I sent, along with > something which disables logging these events to the console. I hope > that I haven't broken anything in the process. Text paste seems to be working fine with Klipper now. Paolo From kr at n-a-n-o.com Fri Aug 12 06:37:12 2005 From: kr at n-a-n-o.com (kr) Date: Thu, 11 Aug 2005 23:37:12 -0700 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <17145.24454.602591.361477@serveur5.labri.fr> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> <17145.24454.602591.361477@serveur5.labri.fr> Message-ID: <17148.17304.352348.43065@firebird.n-a-n-o.com> Robert Strandh writes: > It is a totally different project in my opinion. To improve the > current code, the owner needs to know both the spec and the code. To > improve the spec, only a limited amount of knowledge of the code is > required. could you please say more about which particular aspects of mcclim need to be improved in what ways ? what is the list of the current 5 top problems that would benefit from large architectural changes ? (i've only started listening in on this mailing list recently...) -- regards markus krummenacker From amoroso at mclink.it Fri Aug 12 08:57:13 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 12 Aug 2005 10:57:13 +0200 Subject: [mcclim-devel] Re: [admin] Broken links to mcclim-devel message archive In-Reply-To: <87k6itmyno.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Wed, 10 Aug 2005 20:31:39 +0200") References: <877jeu995i.fsf@plato.moon.paoloamoroso.it> <87k6itmyno.fsf@plato.moon.paoloamoroso.it> Message-ID: <877jerttw6.fsf@plato.moon.paoloamoroso.it> Paolo Amoroso writes: > Mario Mommer writes: > >> Paolo Amoroso writes: > [...] >>> http://mcclim.cliki.net/Bug > [...] >> All but the first link on that page (the one from june 2005) seem to >> be working now. I presume that this particular message has a much > > I think I have fixed this, and everything else looks good. Thanks, I spoke too early: http://thread.gmane.org/gmane.lisp.mcclim.devel/657 The links point to different, unrelated messages. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From amoroso at mclink.it Fri Aug 12 09:07:04 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 12 Aug 2005 11:07:04 +0200 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> <17145.24454.602591.361477@serveur5.labri.fr> <17148.17304.352348.43065@firebird.n-a-n-o.com> Message-ID: <87y877sevb.fsf@plato.moon.paoloamoroso.it> kr writes: > Robert Strandh writes: > > It is a totally different project in my opinion. To improve the > > current code, the owner needs to know both the spec and the code. To > > improve the spec, only a limited amount of knowledge of the code is > > required. > > could you please say more about which particular aspects of mcclim > need to be improved in what ways ? I am not a McCLIM implementor and I don't know the details of architectural changes. As a user, I would like a fully working ACCEPTING-VALUES, with real gadget views and :OWN-WINDOW t (i.e. for creating dialogs). I would also appreciate improvements to the PostScript backend, more specifically better management of page margins (in most cases the output is cropped at the margins). Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From mmommer at common-lisp.net Fri Aug 12 09:32:38 2005 From: mmommer at common-lisp.net (Mario Mommer) Date: Fri, 12 Aug 2005 11:32:38 +0200 Subject: [mcclim-devel] Re: [admin] Broken links to mcclim-devel message archive In-Reply-To: <877jerttw6.fsf@plato.moon.paoloamoroso.it> References: <877jeu995i.fsf@plato.moon.paoloamoroso.it> <87k6itmyno.fsf@plato.moon.paoloamoroso.it> <877jerttw6.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > I spoke too early: > > http://thread.gmane.org/gmane.lisp.mcclim.devel/657 > > The links point to different, unrelated messages. Is this a problem with common-lisp.net or with gmane? Personally, I find it a design flaw of the archiver that it indexes depending on message number rather than on message id. The latter one exist for a reason while the former might be incidental (watching the mailman arch tool grind on mailboxes gives the impression that it builds hash tables and then traverses them when writing output, so there may be a nondeterministic element in this.) Regards, Mario. From amoroso at mclink.it Fri Aug 12 10:43:44 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 12 Aug 2005 12:43:44 +0200 Subject: [mcclim-devel] Re: [admin] Broken links to mcclim-devel message archive In-Reply-To: (Mario Mommer's message of "Fri, 12 Aug 2005 11:32:38 +0200") References: <877jeu995i.fsf@plato.moon.paoloamoroso.it> <87k6itmyno.fsf@plato.moon.paoloamoroso.it> <877jerttw6.fsf@plato.moon.paoloamoroso.it> Message-ID: <87irybl9jz.fsf@plato.moon.paoloamoroso.it> Mario Mommer writes: > Paolo Amoroso writes: >> I spoke too early: >> >> http://thread.gmane.org/gmane.lisp.mcclim.devel/657 >> >> The links point to different, unrelated messages. > > Is this a problem with common-lisp.net or with gmane? I think it's related to Common-Lisp.net. I have provided the above link to a mcclim-devel message by Robert Goldman that explains the problem. But I have used a Gmane link just for redundancy, not because Gmane is involved. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From mmommer at common-lisp.net Fri Aug 12 11:00:48 2005 From: mmommer at common-lisp.net (Mario Mommer) Date: Fri, 12 Aug 2005 13:00:48 +0200 Subject: [mcclim-devel] Re: [admin] Broken links to mcclim-devel message archive In-Reply-To: <87irybl9jz.fsf@plato.moon.paoloamoroso.it> References: <877jeu995i.fsf@plato.moon.paoloamoroso.it> <87k6itmyno.fsf@plato.moon.paoloamoroso.it> <877jerttw6.fsf@plato.moon.paoloamoroso.it> <87irybl9jz.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > I think it's related to Common-Lisp.net. I have provided the above > link to a mcclim-devel message by Robert Goldman that explains the > problem. But I have used a Gmane link just for redundancy, not > because Gmane is involved. Ah ok :-) Well, I don't really know what to do. I'll investigate later today or tomorrow. If anyone has an idea, please let me know. Regards, Mario. From csr21 at cam.ac.uk Fri Aug 12 11:15:10 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 12 Aug 2005 12:15:10 +0100 Subject: [mcclim-devel] text with negative x-offsets In-Reply-To: (Christophe Rhodes's message of "Thu, 11 Aug 2005 15:38:56 +0100") References: Message-ID: Christophe Rhodes writes: > Find attached a preliminary patch to deal with the fact that, in > general, glyphs from fonts are not constrained to draw only to the > right of the cursor position. A revised patch is attached, which is still not commit-worthy but fixes the opposite-problem as well: glyphs which draw beyond their advance width. (Thanks to Dave Murray aka JQS for testing). The current plan is for us here at Goldsmiths to perform a little more testing and extend it to the PostScript backend. I suppose that the logical thing to do is to call TEXT-BOUNDING-RECTANGLE* a backend function and require backends to implement it for their backend-medium. This imposes a maintenance burden on those interested in the OpenGL and beagle backends, but I hope not a terrible one. I note, from the screenshot at http://www.bloodandcoffee.net/campbell/climacs-beagle-porn.png for example, that there seem to be similar redraw artifacts in the beagle backend in any case, so it could well be that an implementation of text-bounding-rectangle* there clears those up. (Is anyone out there using the OpenGL backend?) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: text-output-records-3.diff URL: -------------- next part -------------- Cheers, Christophe From amoroso at mclink.it Fri Aug 12 12:56:23 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 12 Aug 2005 14:56:23 +0200 Subject: [mcclim-devel] two fixes for graph formatting In-Reply-To: <17148.2920.117037.111673@gargle.gargle.HOWL> (rpgoldman@real-time.com's message of "Thu, 11 Aug 2005 21:37:28 -0500") References: <17148.2920.117037.111673@gargle.gargle.HOWL> Message-ID: <874q9vfh54.fsf@plato.moon.paoloamoroso.it> rpgoldman at real-time.com writes: > My first commit. Hope I haven't gaffed anything! Seems like the > clim-listener still works, and that's really my only test case... Your changes seem to work fine. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From duncan at robotcat.demon.co.uk Fri Aug 12 18:29:20 2005 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Fri, 12 Aug 2005 19:29:20 +0100 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <17148.17304.352348.43065@firebird.n-a-n-o.com> Message-ID: On Friday, August 12, 2005, at 07:37 am, kr wrote: > Robert Strandh writes: >> It is a totally different project in my opinion. To improve the >> current code, the owner needs to know both the spec and the code. To >> improve the spec, only a limited amount of knowledge of the code is >> required. > > could you please say more about which particular aspects of mcclim > need to be improved in what ways ? > In terms of documentation I think deviations (which probably are _not_ gratuitous!) from the spec, fixes for vendor compatability and general documentation of extensions / extensions wanted would be useful. > what is the list of the current 5 top problems that would benefit from > large architectural changes ? Personally I'd like to see more structure in the organisation of the code (though this is quite superficial). I'd like to see a directory hierarchy for the code, many source files split apart (I hate long source files but maybe that's just me). I'd also like to see finer-grained packages (e.g. geometry functionality defined in :mcclim-geometry, drawing functionality in :mcclim-graphics, etc. etc.). These changes are pretty trivial. I'd like to revisit the silica functionality; in particular, setting up transformations for sheets with a vertical dimension > 2^16 (which currently seems written specifically for CLX). I'd like some of the X restrictions removed from the code (I forget even where they are now, but I'm pretty sure there's code in the 'core' of McCLIM to restrict ellipses to rectilinear transforms only, for example). I'm pretty sure there's a threading bug somewhere which doesn't show up under CLX due to (I think) the asynchronous nature of the X protocol (though this is perhaps more likely to be specific to Beagle - I need to do more investigation). Of course, if CLX isn't asynchronous I'm deluding myself... I'd like to see a 'proper' test suite, just in case. I'd like to see the menu code use CLIM menus (menu-choose-from-drawer etc.) which I don't think they do at the moment. On the whole, I don't think many 'large architectural changes' are necessary. Most functionality seems to be present but there are corner cases that need to be investigated. Of course, more back ends might be good, along with extensions (going back to an earlier discussion regarding bezier path rendering, there's an implementation of this in the DUIM sources which looks like it would be quite straightforward to port into McCLIM). Output to PDF would be more useful to me than output to PostScript. There's probably a bunch of performance improvements that could be made (spatial-tree based output records spring to mind). I think generally the code just needs some polish and a LOT of documentation. Somebody maybe wants to pick up the QA task in earnest (I always planned to do this but don't really have time at the moment; anyway, Beagle is far from finished). At the moment I'm looking at porting DUIM from Dylan to CL so if that goes anywhere there's likely to be opportunities for cross-pollination between McCLIM and DUIM (though how much overlap there will be in reality is not clear; probably not that much). Just my tuppenny worth; all of which are on my todo-list, time permitting. -Duncan > > (i've only started listening in on this mailing list recently...) > > -- > regards > markus krummenacker > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From amoroso at mclink.it Fri Aug 12 19:31:22 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 12 Aug 2005 21:31:22 +0200 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: (Duncan Rose's message of "Fri, 12 Aug 2005 19:29:20 +0100") References: Message-ID: <874q9veyut.fsf@plato.moon.paoloamoroso.it> Duncan Rose writes: > I'd like to see a 'proper' test suite, just in case. By the what, what does a GUI test suite look like? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From smustudent1 at yahoo.com Fri Aug 12 20:05:04 2005 From: smustudent1 at yahoo.com (C Y) Date: Fri, 12 Aug 2005 13:05:04 -0700 (PDT) Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <874q9veyut.fsf@plato.moon.paoloamoroso.it> Message-ID: <20050812200504.3475.qmail@web31709.mail.mud.yahoo.com> --- Paolo Amoroso wrote: > > By the what, what does a GUI test suite look like? Hmm, interesting question actually! The only ones I can recall seeing usually seem to test if something is displayed properly by running through a bunch of "test" applications and watching for errors reported, or don't do anything automatically but consist of demo programs which are intended to exercise parts of the code. More interesting might be to store pixmaps or vector descriptions of correctly rendered test windows/apps, compare internally an internally rendered bitmap to the stored "correct" version, and see if there is any difference. Advantages: doesn't need to display anything onscreen, and thus doesn't need a graphical desktop to do "real" testing. Disadvantages: space intensive and rather difficult to code. Much of the code could probably use ordinary unit testing, the challenge would be ones where the output of interest is graphical. Nifty to think about. Cheers, CY ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From duncan at robotcat.demon.co.uk Fri Aug 12 20:32:48 2005 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Fri, 12 Aug 2005 21:32:48 +0100 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <874q9veyut.fsf@plato.moon.paoloamoroso.it> Message-ID: <3EF16272-0B70-11DA-95A7-000A9577B8A2@robotcat.demon.co.uk> On Friday, August 12, 2005, at 08:31 pm, Paolo Amoroso wrote: > Duncan Rose writes: > >> I'd like to see a 'proper' test suite, just in case. > > By the what, what does a GUI test suite look like? > This is what the Functional Developer DUIM one looks like: http://www.gwydiondylan.org/images/duim-gui-tests-hd12.png This isn't a million miles away from what we have for McCLIM already, but is more complete. Note that the DUIM source tree also contains 'unit' tests, which include (as far as I know, I will investigate further) examples where specific windowing calls are redefined so that at least it's possible to say 'up to this point the functionality is correct' even though that might not lead directly to fully-working code. Testing GUI apps is always a pain; there are testing utilities available (generally they record input events, then replay them as necessary and compare the results) but I haven't seen a good general purpose cross-platform one. -Duncan > > Paolo > -- > Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From campbell at bloodandcoffee.net Fri Aug 12 21:05:39 2005 From: campbell at bloodandcoffee.net (Taylor Campbell) Date: Fri, 12 Aug 2005 14:05:39 -0700 (PDT) Subject: [mcclim-devel] bug in incremental redisplay with OUTPUT-RECORD-HASH Message-ID: When redrawing a Climacs screen, either by hitting C-l or just moving the screen around, I consistently got an error about OUTPUT-RECORD-HASH having no applicable methods for STANDARD-BOUNDING-RECTANGLE. After a little analysis of incremental-redisplay.lisp, it looks like the first method of OUTPUT-RECORD-HASH defined in incremental-redisplay.lisp should be specialized on STANDARD-RECTANGLE, or at the very least STANDARD-BOUNDING-RECTANGLE, instead of BASIC-OUTPUT-RECORD, because it will at some point get a STANDARD-BOUNDING-RECORD that is not also a BASIC-OUTPUT-RECORD: The OLD-BOUNDS slot of UPDATING-OUTPUT-RECORD-MIXIN has an initform of a call to MAKE-BOUNDING-RECTANGLE, which returns an instance of STANDARD-BOUNDING-RECTANGLE. COMPUTE-DIFFERENCE-SET (which is where the error was signalled when Climacs borked) collects the values of OLD-BOUNDS slots into a list and then puts elements of that list as keys into a table, using OUTPUT-RECORD-HASH to convert them into keys. Unless the OLD-BOUNDS slot is meant to be a BASIC-OUTPUT-RECORD instance more specifically than a STANDARD-BOUNDING-RECORD, the method isn't specific enough to handle this. (The COORDINATES slot is defined in the STANDARD-RECTANGLE class, which is why I suggested it as the least specific possible class to specialize the OUTPUT-RECORD-HASH method on, which just returns the value of that slot.) I'm no McCLIM expert, so the solution of specializing the method differently may be the wrong thing, and the right thing may be to fix the value of the OLD-BOUNDS slot, but changing the specializer seems to work here, and I don't have any specific suggestions on fixing it the other way (changing the value of the OLD-BOUNDS slot). Can anyone else comment on this fix or, if it is the right thing, commit it? (I'm told that it's Tim Moore's code.) From strandh at labri.fr Sat Aug 13 04:02:47 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 13 Aug 2005 06:02:47 +0200 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <17148.17304.352348.43065@firebird.n-a-n-o.com> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> <17145.24454.602591.361477@serveur5.labri.fr> <17148.17304.352348.43065@firebird.n-a-n-o.com> Message-ID: <17149.28903.479387.436455@serveur5.labri.fr> kr writes: > Robert Strandh writes: > > It is a totally different project in my opinion. To improve the > > current code, the owner needs to know both the spec and the code. To > > improve the spec, only a limited amount of knowledge of the code is > > required. > > could you please say more about which particular aspects of mcclim > need to be improved in what ways ? > > what is the list of the current 5 top problems that would benefit from > large architectural changes ? > > (i've only started listening in on this mailing list recently...) That list is going to have to be fairly vague at the moment, because I haven't figured out in detail what the problem is: * in several places, implementation of some part of the spec uses internal classes and/or methods that are not part of the spec in such a way that it is impossible for the user to create a spec-conforming extension that will work with this implementation. An example (until Tim Moore fixed it, though the fix seems to have some problems) was the fact the output recording protocol required a particular slot in the output record, that is not part of the spec. Thus writing your own output record was impossible. * I have reasons to believe that the space-requirement protocol is wrong in places, but this is admittedly vague. * there are definitely some problems with sheet transformations in combination with output recording. If you have a sheet transformation in place then the output records will end up in the wrong place. * output recording, despite improvements by Gilbert Baumann and Tim Moore is still not good enough with respect to performance. A tree-structured output record is necessary. That's only four points, but the first one is probably true in several different parts of McCLIM. Hope this helps. -- 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. --------------------------------------------------------------------- From strandh at labri.fr Sat Aug 13 04:04:40 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 13 Aug 2005 06:04:40 +0200 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <17148.17304.352348.43065@firebird.n-a-n-o.com> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> <17145.24454.602591.361477@serveur5.labri.fr> <17148.17304.352348.43065@firebird.n-a-n-o.com> Message-ID: <17149.29016.628216.809555@serveur5.labri.fr> kr writes: > could you please say more about which particular aspects of mcclim > need to be improved in what ways ? > > what is the list of the current 5 top problems that would benefit from > large architectural changes ? > > (i've only started listening in on this mailing list recently...) If you are thinking of taking on a chunk of McCLIM please let us know, and we will be happy to give you advice and encouragement. -- 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. --------------------------------------------------------------------- From csr21 at cam.ac.uk Sat Aug 13 14:28:29 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sat, 13 Aug 2005 15:28:29 +0100 Subject: [mcclim-devel] text with negative x-offsets In-Reply-To: (Christophe Rhodes's message of "Fri, 12 Aug 2005 12:15:10 +0100") References: Message-ID: Christophe Rhodes writes: > Christophe Rhodes writes: > >> Find attached a preliminary patch to deal with the fact that, in >> general, glyphs from fonts are not constrained to draw only to the >> right of the cursor position. > > A revised patch is attached, which is still not commit-worthy but > fixes the opposite-problem as well: glyphs which draw beyond their > advance width. (Thanks to Dave Murray aka JQS for testing). > > The current plan is for us here at Goldsmiths to perform a little more > testing and extend it to the PostScript backend. I suppose that the > logical thing to do is to call TEXT-BOUNDING-RECTANGLE* a backend > function and require backends to implement it for their backend-medium. Well, for what it's worth, we did this, I performed some light testing (using clim-demo::postscript-test), and I've committed our work so far. > This imposes a maintenance burden on those interested in the OpenGL > and beagle backends, but I hope not a terrible one. I note, from the > screenshot at > http://www.bloodandcoffee.net/campbell/climacs-beagle-porn.png for > example, that there seem to be similar redraw artifacts in the beagle > backend in any case, so it could well be that an implementation of > text-bounding-rectangle* there clears those up. (Is anyone out there > using the OpenGL backend?) This remains true: the beagle, OpenGL (and CLX with #+unicode, if that's not dead code) backends are currently broken. Sorry. To fix them, the function climi::text-bounding-rectangle* needs to be implemented, which should return the bounding-rectangle of a draw-text command at 0,0 with :x-align :left and :y-align :baseline. (If all else fails, this can be faked with a call to TEXT-SIZE, with the caveat that then redraw artifacts as in the above screenshot will remain.) Cheers, Christophe From metch at daimi.au.dk Sun Aug 14 12:26:06 2005 From: metch at daimi.au.dk (Peter Mechlenborg) Date: Sun, 14 Aug 2005 14:26:06 +0200 Subject: [mcclim-devel] text with negative x-offsets In-Reply-To: References: Message-ID: <42FF385E.6080306@daimi.au.dk> Christophe Rhodes wrote: [snip] > Well, for what it's worth, we did this, I performed some light testing > (using clim-demo::postscript-test), and I've committed our work so > far. > When i update, I don't get the new changes to Backends/CLX/medium.lisp. The other files in the patch seems ok, just missing medium.lisp. [goblin:~/lisp/libraries/mcclim/Backends/CLX]$cvs upd ? clim-extensions.fasl ? frame-manager.fasl ? graft.fasl ? image.fasl ? keysymdef.fasl ? keysyms-common.fasl ? keysyms.fasl ? medium.fasl ? package.fasl ? port.fasl cvs server: Updating . [goblin:~/lisp/libraries/mcclim/Backends/CLX]$cvs status medium.lisp =================================================================== File: medium.lisp Status: Up-to-date Working revision: 1.66 Repository revision: 1.66 /project/mcclim/cvsroot/mcclim/Backends/CLX/medium.lisp,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) [goblin:~/lisp/libraries/mcclim/Backends/CLX]$grep "text-bounding-rec" * [goblin:~/lisp/libraries/mcclim/Backends/CLX]$ From csr21 at cam.ac.uk Sun Aug 14 12:41:48 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 14 Aug 2005 13:41:48 +0100 Subject: [mcclim-devel] text with negative x-offsets In-Reply-To: <42FF385E.6080306@daimi.au.dk> (Peter Mechlenborg's message of "Sun, 14 Aug 2005 14:26:06 +0200") References: <42FF385E.6080306@daimi.au.dk> Message-ID: Peter Mechlenborg writes: > Christophe Rhodes wrote: > > [snip] > >> Well, for what it's worth, we did this, I performed some light testing >> (using clim-demo::postscript-test), and I've committed our work so >> far. >> > > When i update, I don't get the new changes to Backends/CLX/medium.lisp. > > The other files in the patch seems ok, just missing medium.lisp. Whoops. I've committed it now. Sorry. Cheers, Christophe From strandh at labri.fr Mon Aug 15 23:58:06 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 16 Aug 2005 01:58:06 +0200 Subject: [mcclim-devel] another incremental redisplay problem Message-ID: <17153.11278.552997.560951@serveur5.labri.fr> Hello, Incremental redisplay uses objects of type output-record to determine what to redisplay. Output records are subclasses of bounding-rectangle. But bounding-rectangle is not a subclass of region, so one cannot use region-intersects-region-p to check whether two output records overlap. But this is in fact the case in the current incremental redisplay code. -- 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. --------------------------------------------------------------------- From strandh at labri.fr Tue Aug 16 01:24:11 2005 From: strandh at labri.fr (Robert Strandh) Date: Tue, 16 Aug 2005 03:24:11 +0200 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <17149.28903.479387.436455@serveur5.labri.fr> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> <17145.24454.602591.361477@serveur5.labri.fr> <17148.17304.352348.43065@firebird.n-a-n-o.com> <17149.28903.479387.436455@serveur5.labri.fr> Message-ID: <17153.16443.103091.6569@serveur5.labri.fr> Robert Strandh writes: > kr writes: > > could you please say more about which particular aspects of mcclim > > need to be improved in what ways ? > > > > what is the list of the current 5 top problems that would benefit from > > large architectural changes ? > > > > (i've only started listening in on this mailing list recently...) > > That list is going to have to be fairly vague at the moment, because I > haven't figured out in detail what the problem is: > > * in several places, implementation of some part of the spec > uses internal classes and/or methods that are not part of the > spec in such a way that it is impossible for the user to create a > spec-conforming extension that will work with this > implementation. As a very typical example, see my previous message where the implementation of incremental redisplay assumes that output records are regions, which is not the case according to the spec, although it is the case with the McCLIM built-in output records. So, things work as long as only the built-in output record classes are used, but no longer do when client code defines new output records that are not regions. -- 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. --------------------------------------------------------------------- From rpgoldman at real-time.com Tue Aug 16 01:52:28 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Mon, 15 Aug 2005 20:52:28 -0500 Subject: [mcclim-devel] minor bug in CLIM-LISTENER or in FORMAT-GRAPH-FROM-ROOTS Message-ID: <17153.18140.739315.895480@gargle.gargle.HOWL> Often, I find when graphing classes in the CLIM-LISTENER, that I will run off the window size. The reason is that neither the class-grapher, which invokes format-graph-from-roots, nor format-graph-from-roots, calls change-space-requirement on its stream. I'm not at all sure what's the proper fix. It seems to me that Format-graph-from-roots should call change-space-requirements, because I can't imagine a case where one wouldn't want to after drawing a graph. But I recall raising this issue on #lisp one day, and having people argue that they preferred NOT to have anything automatically call change-space-requirements, that this should be left to the programmer, in the interests of efficiency, so that that programmer could bundle up a large number of window writes before updating the space requirements. So, what's the consensus of the group? Where should this be fixed? Robert From rpgoldman at real-time.com Wed Aug 17 19:55:10 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 17 Aug 2005 14:55:10 -0500 Subject: [mcclim-devel] frames with multiple layouts Message-ID: <17155.38430.63777.837749@gargle.gargle.HOWL> I've used multiple layouts to give me a kind of modal UI. It seemed easier to have multiple, simple diplay functions instead of a single complex one. All well and good, but now I find that when I change layouts, the size of the frame changes. This is annoyingly distracting, especially since it happens in an odd way: 1. go to layout 1. 2. Maximize the window. 3. Go to layout 2. Window shrinks. 4. Return to layout 1. Window has shrinky size of layout 2. Is there some relatively easy way to make CLIM assign the frame a size that is the MAX of all of the sizes of the individual layouts? Thanks, R From m.retzlaff at gmx.net Thu Aug 18 01:03:00 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 18 Aug 2005 03:03:00 +0200 Subject: [mcclim-devel] some patches: accepting-values and partial-commands Message-ID: <20050818010300.GA8688@mgr.home> Hi, I've found some problems in McClim yesterday and written some patches (for three of the four problems). Regards, Max-Gerd Retzlaff ======================================================================== - The example in section 10.2.1 of the clim spec v2.2: (define-editor-command (com-save-file :menu t :keystroke (:s :control)) () ...) is either an error and :keystroke (#\s :control) was meant, or it suggests that it should be possible to first define a keystroke :s like for example: (define-gesture-name :s :keyboard (#\s)) and add modifiers later. The latter does not work in McClim; modifiers that are only specified in the :keystroke argument to a define-command are simply ignored. Patch: - none - ======================================================================== - accepting-dialog should behave as if the argument align-prompts had the value :right if it is specified as T (clim spec v2.2, 13.3); only the values nil, :left, :right, and t are possible. Patch to dialog.lisp: -- zipp -- @@ -167,7 +183,10 @@ (frame-class 'accept-values)) (declare (ignore own-window exit-boxes modify-initial-query resize-frame label scroll-bars x-position y-position - width height frame-class)) + width height frame-class)) + (when (and align-prompts ;; t means the same as :right + (not (eq align-prompts :left))) + (setf align-prompts :right)) (multiple-value-bind (cx cy) (stream-cursor-position stream) (let* ((*accepting-values-stream* (make-instance 'accepting-values-stream -- zapp -- ======================================================================== - accepting-values for partial-commands The generated accepting-values shouldn't allow to be exited (via "OK") as long as decent values (i.e. matching the specified presentation type) are supplied for the required arguments of the command. Note: This is a personal taste, I haven't found anything in the clim-spec that requires such a behaviour. Proposed patch (a hack): Apply the following patch to commands.lisp: -- zipp -- --- commands.lisp.~1.53.~ 2005-06-28 06:32:46.000000000 +0200 +++ commands.lisp 2005-08-18 02:05:11.975682512 +0200 @@ -746,6 +746,7 @@ ;; We don't need fresh gensyms of these variables for each accept form. (with-gensyms (value ptype changedp) `(defun ,name (,command-table ,stream ,partial-command) + (do ((still-missing nil t)) (nil) (destructuring-bind (,command-name , at original-args) ,partial-command (let ((,command-line-name (command-line-name-for-command @@ -755,7 +756,7 @@ ,@(mapcar #'list required-arg-names original-args)) (accepting-values (,stream) (format ,stream - "You are being prompted for arguments to ~S~%" + "You are being prompted for arguments to ~S~%~%" ,command-line-name) ,@(loop for var in required-arg-names @@ -767,9 +768,16 @@ (declare (ignore ,ptype)) (terpri ,stream) (when ,changedp - (setq ,var ,value)))))) - (list ,command-name , at required-arg-names)))))))) - + (setq ,var ,value))))) + (when still-missing + (format ,stream + "~&Please supply all arguments."))) + (setf ,partial-command (list ,command-name , at required-arg-names)) + (unless (partial-command-p ,partial-command) + (return ,partial-command)))))))))) ;;; XXX What do to about :acceptably? Probably need to wait for Goatee "buffer ;;; streams" so we can insert an accept-result-extent in the buffer for -- zapp -- ======================================================================== - exit-boxes of accepting-values; 13.3 of the clim spec v2.2 says: -- zipp -- exit-boxes [...] The default behavior is as though you specified the following: '((:exit "OK") (:abort "Cancel")) -- zapp -- The default behavior of McClim correspondends to '((:exit "Exit") (:abort "Abort")) at the moment. Patch: Replace the strings "Exit" and "Abort" in #'display-exit-boxes of dialog.lisp by "Exit" and "Abort", respectively. Patch to dialog.lisp: -- zipp -- --- dialog.lisp.~1.19.~ 2005-02-27 21:52:49.000000000 +0100 +++ dialog.lisp 2005-08-17 08:43:20.000000000 +0200 @@ -224,11 +243,11 @@ (fresh-line stream) (with-output-as-presentation (stream nil 'exit-button) - (format stream "Exit")) + (format stream "OK")) (write-char #\space stream) (with-output-as-presentation (stream nil 'abort-button) - (format stream "Abort")) + (format stream "Cancel")) (terpri stream))) (defmethod stream-accept ((stream accepting-values-stream) type -- zapp -- ======================================================================== -- Max-Gerd Retzlaff For your amusement: The human brain is a wonderful thing. It starts working the moment you are born, and never stops until you stand up to speak in public. -- Sir George Jessel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From strandh at labri.fr Thu Aug 18 01:37:22 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 18 Aug 2005 03:37:22 +0200 Subject: [mcclim-devel] trying to clean up incremental-redisplay.lisp Message-ID: <17155.58962.780076.780460@serveur5.labri.fr> Hello, I am trying to clean up in incremental-redisplay.lisp. Here is what I suggest for now. If someone has objections, let me know: * get rid of *enable-updating-output*. It is initialized to t in incremental-redisplay.lisp and used there as well as in frames.lisp, but it is never set or bound. I suppose it was meant to be some kind of debugging tool, * get rid of redisplay-add-output-record and redisplay-delete-output-record which are never called, * get rid of clear-moved-record which is never called. What do you think? -- 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. --------------------------------------------------------------------- From m.retzlaff at gmx.net Thu Aug 18 01:53:47 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 18 Aug 2005 03:53:47 +0200 Subject: [mcclim-devel] tow more patches Message-ID: <20050818015347.GA9416@mgr.home> Hi, here are two additional patches. Bye, Max ======================================================================== - :own-window of accepting-values is not implemented I've made a patch based on clim:open-window-stream. Consider it to be a quick and *dirty* hack. Look at the sleep.. -- zipp -- --- dialog.lisp.~1.19.~ 2005-02-27 21:52:49.000000000 +0100 +++ dialog.lisp 2005-08-18 03:21:37.284609600 +0200 @@ -136,6 +136,30 @@ (defvar *accepting-values-stream* nil) +(defmacro with-stream-in-own-window ((&optional (stream '*query-io*) + &rest further-streams) + &rest body) + `(let* ((,stream (open-window-stream)) + ,@(mapcar (lambda (a-stream) + (list a-stream stream)) + further-streams)) + (sleep 0.1) ;; hackhack.. some delay to "ensure" that the window-stream ist opened + (unwind-protect + (progn + , at body) + (close ,stream)))) + (defmacro accepting-values ((&optional (stream t) &rest args @@ -144,17 +168,22 @@ align-prompts label scroll-bars x-position y-position width height command-table frame-class) &body body) - (declare (ignorable own-window exit-boxes initially-select-query-identifier + (declare (ignorable exit-boxes initially-select-query-identifier modify-initial-query resynchronize-every-pass resize-frame align-prompts label scroll-bars x-position y-position width height command-table frame-class)) (setq stream (stream-designator-symbol stream '*standard-input*)) (with-gensyms (accepting-values-continuation) + (let ((return-form `(flet ((,accepting-values-continuation (,stream) , at body)) (invoke-accepting-values ,stream #',accepting-values-continuation - , at args)))) + , at args)) + )) + (if own-window + `(with-stream-in-own-window (,stream *standard-input* *standard-output*) ,return-form) + return-form)))) (defun invoke-accepting-values (stream body -- zapp -- ======================================================================== - A patch to open-window-stream to be able to do modify the display-function of the created window-stream afterwards, as in: (let ((stream (open-window-stream))) (setf (slot-value stream 'climi::display-function) (lambda (frame pane) (declare (ignore frame)) (write-string "foo" pane))) stream) and not having to explicitly call (redisplay-frame-panes (pane-frame *) :force-p t) after changing the display function. The standalone-event-loop for open-window-stream is quite Spartan. The default-frame-top-level includes a call to redisplay-frame-panes with force (only for the first time) before calling simple-event-loop as well. I conclude that calling redisplay-frame-panes in open-window-stream is the right thing to do. By the way, standard-event-loop is complete copy of simple-event-loop aside from two lines of code to handle FRAME-EXIT. Not very nice. Patch to panes.lisp - zipp - --- panes.lisp.~1.153.~ 2005-06-24 01:12:42.000000000 +0200 +++ panes.lisp 2005-08-18 03:48:55.298593624 +0200 @@ -2591,6 +2596,8 @@ #+clim-mp (unless input-buffer (clim-sys:make-process (lambda () (let ((*application-frame* frame)) + (redisplay-frame-panes frame :force-p t) (standalone-event-loop))))) (slot-value frame 'stream))) - zapp - ======================================================================== -- Max-Gerd Retzlaff For your amusement: My brother sent me a postcard the other day with this big satellite photo of the entire earth on it. On the back it said: "Wish you were here". -- Steven Wright -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.retzlaff at gmx.net Thu Aug 18 02:27:30 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 18 Aug 2005 04:27:30 +0200 Subject: [mcclim-devel] A new example application for CLIM (town-example.lisp) Message-ID: <20050818022730.GA9551@mgr.home> And again.. I had quite a productive day regarding clim programming yesterday; one of the outcomes is the following example for CLIM programming. It tries to demonstrate the following topics: custom view classes, different present presentation methods for different views, completion for accept presentation methods, accepting-values dialogues, presentation to command translators, partial commands in menus, automatically generated menus, and keystroke gestures for commands. At the same time I tried to make the application as simple as possible. As in: Not doing fancy stuff to make the application less senseless (as an application) or more visually appealing. You'll find a screenshot at: http://bl0rg.net/~mgr/flux/town-example.png The code is located at http://bl0rg.net/~mgr/flux/town-example.lisp and also attached to this email. Any comments and proposals for changes are welcome! Did I do something that would better have been done in a different way? Then, please, enlighten me! I currently think about expanding it to a real tutorial with some explanations. But I don't know whether I'll have the time to do it. Regards, Max -- Max-Gerd Retzlaff For your amusement: aphorism, n.: A concise, clever statement. afterism, n.: A concise, clever statement you don't think of until too late. -- James Alexander Thom -------------- next part -------------- ;;; -*- Mode: Lisp; Syntax: Common-Lisp; Package: TOWN-EXAMPLE; -*- ;;; --------------------------------------------------------------------------- ;;; Title: Example CLIM Application: Large Cities of Germany ;;; Topics: custom view classes, different present presentation methods for ;;; different views, completion for accept presentation methods, ;;; accepting-values dialogues, presentation to command translators, ;;; partial commands in menus, automatically generated menus, ;;; and keystroke gestures for commands. ;;; Usage: Compile and load the file and call (town-example:run) afterwards. ;;; Created: 2005-08-17, Version 1.3 (same date) ;;; Author: Max-Gerd Retzlaff , http://bl0rg.net/~mgr ;;; --------------------------------------------------------------------------- ;;; (c) copyright 2005 by Max-Gerd Retzlaff ;;; define the package (in-package :cl-user) (defpackage :town-example (:use :clim :clim-lisp) (:export :run)) (in-package :town-example) ;;; view class for graphical presentations (defclass graphical-view (view) ()) (defparameter +graphical-view+ (make-instance 'graphical-view)) ;;; an application frame consistiong of one pane (define-application-frame town-example () () (:panes (map :application :height 500 :width 500 :scroll-bars nil :background +dark-blue+ :display-function #'draw-map :default-view +graphical-view+) (pointer-doc :pointer-documentation) (interactor :interactor :height 163 ;; 130 105 95 :scroll-bars nil)) (:layouts (default (vertically () map interactor pointer-doc))) (:top-level (default-frame-top-level :prompt #'town-example-prompt))) (defun town-example-prompt (pane frame) (declare (ignore frame)) (window-clear pane) (with-text-face (pane :roman) (write-string "> " pane))) (defun draw-map (frame pane) "Draws a stylized map of Germany" (declare (ignore frame)) (draw-polygon* pane '(172 22 228 40 227 59 264 60 256 80 277 88 319 54 336 58 345 43 353 55 345 71 370 86 384 124 375 141 393 159 398 208 416 237 410 258 397 252 314 302 333 351 380 389 341 426 350 461 324 452 280 471 252 462 240 474 172 448 166 460 132 457 140 410 160 378 116 368 92 346 79 307 94 295 82 252 90 229 84 204 113 201 112 162 129 142 130 104 157 102 174 118 182 96 204 96 186 58 196 50) :ink +dark-green+) ;; present all towns (later..) (com-present-towns)) ;;; a function to start the demonstration (defun run () (run-frame-top-level (make-application-frame 'town-example))) ;;; a command to quit the program (define-town-example-command (com-quit :name t :menu t ;; show in menu :keystroke (#\q :meta)) ;; a keystroke () (frame-exit *application-frame*)) ;;; a class for towns (defclass town () ((name :initarg :name :accessor town-name) (coordinates :initarg :coordinates :accessor town-coordinates :initform (make-point 156 68)) ;; Helogoland.. (population :initarg :population :accessor town-population :initform nil))) ;;; a hash to store the towns (defvar *towns* (make-hash-table :test #'equal)) ;;; slightly nicer function to create new town instances (defun make-town (name x y &optional population) (let ((town (make-instance 'town :name name :coordinates (make-point x y)))) (when population (setf (town-population town) population)) town)) ;;; clos magic to automatically store all created towns in the hash (defmethod initialize-instance :after ((town town) &key) (setf (gethash (town-name town) *towns*) town)) ;;; function to find a town (defun find-town (name &optional (errorp t)) (or (gethash name *towns*) ;; not the best style.. (and errorp (error "~&No town named ~S in the database." name)))) ;;; printer method for town instances (defun slot-value-or-something (object &key (slot 'name) (something "without name")) (if (slot-boundp object slot) (slot-value object slot) something)) (defmethod print-object ((town town) stream) (print-unreadable-object (town stream :type t) (write-string (slot-value-or-something town) stream))) ;;; create some towns.. (21th biggest cities of Germany on 12-31-2003) (make-town "Berlin" 353 166 3390000) (make-town "Hamburg" 229 106 1730000) (make-town "Munich" 292 427 1250000) (make-town "Cologne" 116 260 970000) (make-town "Frankfurt" 179 310 640000) (make-town "Dortmund" 136 226 590000) (make-town "Essen" 120 228 590000) (make-town "Stuttgart" 196 392 590000) (make-town "Duesseldorf" 110 242 570000) (make-town "Bremen" 187 134 540000) (make-town "Hanover" 222 177 520000) (make-town "Duisburg" 108 231 510000) (make-town "Leipzig" 318 238 500000) (make-town "Nuremberg" 272 352 490000) (make-town "Dresden" 370 252 480000) (make-town "Bochum" 130 228 390000) (make-town "Wuppertal" 130 238 360000) (make-town "Bielefeld" 176 198 330000) (make-town "Bonn" 120 276 310000) (make-town "Mannheim" 172 349 310000) (make-town "Karlsruhe" 168 377 280000) ;;; a presantation type for town would look like this: ;;; ;;; (clim:define-presentation-type town ()) ;;; ;;; But we don't have to specify it as clim-spec 8.6.2 says: ;;; "If your presentation type has the same name as a class, doesn't ;;; have any parameters or options, doesn't have a history, and ;;; doesn't need a special description, you do not need to call ;;; define-presentation-type." ;;; accept method for a town presentation (in any view mode): (define-presentation-method accept ((type town) stream view &key) (values ;suppress values after the first ;; provide completion over the names of the towns (completing-from-suggestions (Stream :partial-completers '(#\Space)) (maphash #'suggest *towns*)))) ;;; how to present a town in CLIM in text-mode: (define-presentation-method present (town (type town) stream (view textual-view) &key) (write-string (town-name town) stream)) ;;; .. and graphically: (defparameter *population->town-circle-factor* 20000 "Towns are graphically represented as circles. Factor to reduce the size of the circles") (defun population->town-circle-diameter (town) "Towns are graphically represented as circles." ;;;; first version: diameter is linearly proportional to the population ;;; (round (/ (or (town-population town) 150000) ;;; *population->town-circle-factor*))) ;; 100000 ;;; ;;;; second version: area of the circle is linearly proportional to the population ;;; (round (sqrt (/ (or (town-population town) 15000) ;;; *population->town-circle-factor* ;; 8000 ;;; pi)))) ;;; ;;;; third version: produces pleasant proportions (round (expt (/ (or (town-population town) 150000) *population->town-circle-factor* ;; 20000 pi) 3/4))) (define-presentation-method present (town (type town) stream (view graphical-view) &key) (clim:draw-circle stream (town-coordinates town) (population->town-circle-diameter town) :ink +dark-red+)) ;;; command that presents all towns (used in #'draw-map) ;;; This could be a normal function instead, just replace the first line by: ;;; (defun com-present-towns (define-town-example-command (com-present-towns) () (maphash (lambda (key value) (declare (ignore key)) (clim:present value 'town)) *towns*)) ;;; accepting-values macro with a nice text-style (defmacro accepting-values-with-style-and-title ((stream) title &rest body) `(let ((,stream *query-io*)) (window-clear ,stream) (accepting-values (,stream :initially-select-query-identifier 'tag); :own-window t) (with-text-style (,stream '(:sans-serif :bold 20)) ,title) (with-text-style (,stream '(:serif :roman 15)) , at body)))) ;;; show info about a town (using a pop-up window or embedded in the interactor-pane) (define-town-example-command (com-show-town-info :name t :menu t :keystroke (#\i :meta)) ((town 'town :prompt " Which town? ")) ;; (present town 'town :view +textual-view+) (accepting-values-with-style-and-title (stream) (format stream "~&Information on ~a~%" (town-name town)) (format stream "~%~A has ~:d inhabitants.~%~%" (town-name town) (or (town-population town) "some")))) ;;; show info on town :select gesture (left click) (define-presentation-to-command-translator info-for-town (town com-show-town-info town-example :gesture :select :documentation "Show info for this town.") (object) (list object)) ;;; get distance between two towns (defun get-distance-between-points (a b) "Ask Pythagoras or Euclid." (round (sqrt (+ (expt (- (point-x a) (point-x b)) 2) (expt (- (point-y a) (point-y b)) 2))))) (define-town-example-command (com-get-distance :name t :menu t :keystroke (#\d :meta)) ((town-a 'town :prompt "Town a") (town-b 'town :prompt "Town b")) (accepting-values-with-style-and-title (stream) (format stream "~&Distance~%") (format stream "~%It's ~d pixels from ~a to ~a.~%~%" (get-distance-between-points (town-coordinates town-a) (town-coordinates town-b)) (town-name town-a) (town-name town-b)))) ;;; get distance on :describe gesture (middle click) ;;; (ask via accept for the second town) ;;; Defunct and not really nice. Note that the version below is simpler, ;;; working, more elegant, and more intuitive, as the user sees the same ;;; as if he had entered the com-get-distance command via the keyboard. ;;; ;;; (define-presentation-to-command-translator distance-between-two-towns ;;; (town com-get-distance town-example ;;; :gesture :describe ;;; :documentation "Get distance from this town to another.") ;;; (object) ;;; (list object ;;; (let (town-b) ;;; (accepting-values-with-style-and-title (stream) ;;; (format stream "~&Get distance~%") ;;; (format stream "~%From ~a to: " (town-name object)) ;;; (setf town-b (accept 'town :prompt nil :stream stream :query-identifier 'tag))) ;;; town-b))) (define-presentation-to-command-translator distance-between-two-towns (town com-get-distance town-example :gesture :describe :documentation "Get distance from this town to another.") (object) (list object (let ((stream *query-io*)) (format stream " Get distance (Town a) ~a (Town b) " (town-name object)) (accept 'town :prompt nil :stream stream :query-identifier 'tag)))) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From moore at bricoworks.com Thu Aug 18 02:21:22 2005 From: moore at bricoworks.com (Timothy Moore) Date: Wed, 17 Aug 2005 19:21:22 -0700 Subject: [mcclim-devel] trying to clean up incremental-redisplay.lisp In-Reply-To: <17155.58962.780076.780460@serveur5.labri.fr> References: <17155.58962.780076.780460@serveur5.labri.fr> Message-ID: <07474aa5b5080dd15f5bcec20b196c44@bricoworks.com> On Aug 17, 2005, at 6:37 PM, Robert Strandh wrote: > Hello, > > I am trying to clean up in incremental-redisplay.lisp. Here is what I > suggest for now. If someone has objections, let me know: > > * get rid of *enable-updating-output*. It is initialized to t in > incremental-redisplay.lisp and used there as well as in > frames.lisp, but it is never set or bound. I suppose it was meant > to be some kind of debugging tool, Yeah. I suppose it has outlived its usefulness. > > * get rid of redisplay-add-output-record and > redisplay-delete-output-record which are never called, > > * get rid of clear-moved-record which is never called. > > What do you think? Go for it. Tim From m.retzlaff at gmx.net Thu Aug 18 02:52:03 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 18 Aug 2005 04:52:03 +0200 Subject: [mcclim-devel] problem with the webarchive of this mailinglist Message-ID: <20050818025203.GA9979@mgr.home> Hi, who maintains the web archive? Have a look at: http://common-lisp.net/pipermail/mcclim-devel/2005-August/004217.html What's the problem? Bye, Max -- Max-Gerd Retzlaff For your amusement: Text processing has made it possible to right-justify any idea, even one which cannot be justified on any other grounds. -- J. Finnegan, USC. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From strandh at labri.fr Thu Aug 18 03:02:02 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 18 Aug 2005 05:02:02 +0200 Subject: [mcclim-devel] some patches: accepting-values and partial-commands In-Reply-To: <20050818010300.GA8688@mgr.home> References: <20050818010300.GA8688@mgr.home> Message-ID: <17155.64042.589622.652144@serveur5.labri.fr> Hello, Max-Gerd Retzlaff writes: > > - The example in section 10.2.1 of the clim spec v2.2: > > (define-editor-command (com-save-file :menu t > :keystroke (:s :control)) > () > ...) > > is either an error and :keystroke (#\s :control) was meant, or it suggests > that it should be possible to first define a keystroke :s like for example: > > (define-gesture-name :s :keyboard (#\s)) > > and add modifiers later. The latter does not work in McClim; modifiers > that are only specified in the :keystroke argument to a define-command > are simply ignored. Right, this is actually not in the spec, but in Franz' User's Guide. It looks like a typo to me. Take care, -- 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. --------------------------------------------------------------------- From strandh at labri.fr Thu Aug 18 03:02:40 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 18 Aug 2005 05:02:40 +0200 Subject: [mcclim-devel] trying to clean up incremental-redisplay.lisp In-Reply-To: <07474aa5b5080dd15f5bcec20b196c44@bricoworks.com> References: <17155.58962.780076.780460@serveur5.labri.fr> <07474aa5b5080dd15f5bcec20b196c44@bricoworks.com> Message-ID: <17155.64080.918473.514356@serveur5.labri.fr> Timothy Moore writes: > Go for it. Thanks! -- 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. --------------------------------------------------------------------- From strandh at labri.fr Thu Aug 18 03:19:57 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 18 Aug 2005 05:19:57 +0200 Subject: [mcclim-devel] problem with the webarchive of this mailinglist In-Reply-To: <20050818025203.GA9979@mgr.home> References: <20050818025203.GA9979@mgr.home> Message-ID: <17155.65117.504660.167369@serveur5.labri.fr> Max-Gerd Retzlaff writes: > > who maintains the web archive? Have a look at: > http://common-lisp.net/pipermail/mcclim-devel/2005-August/004217.html > What's the problem? I am not sure what I am supposed to see. -- 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. --------------------------------------------------------------------- From amoroso at mclink.it Thu Aug 18 10:29:56 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Thu, 18 Aug 2005 12:29:56 +0200 Subject: [mcclim-devel] problem with the webarchive of this mailinglist In-Reply-To: <17155.65117.504660.167369@serveur5.labri.fr> (Robert Strandh's message of "Thu, 18 Aug 2005 05:19:57 +0200") References: <20050818025203.GA9979@mgr.home> <17155.65117.504660.167369@serveur5.labri.fr> Message-ID: <87mznfy1uj.fsf@plato.moon.paoloamoroso.it> Robert Strandh writes: > Max-Gerd Retzlaff writes: > > > > who maintains the web archive? Have a look at: > > http://common-lisp.net/pipermail/mcclim-devel/2005-August/004217.html > > What's the problem? > > I am not sure what I am supposed to see. The message from Max-Gerd should contain both a text part and an attachment, but the archive only shows the latter. Max-Gerd: a recent system upgrade at Common-Lisp.net had some unexpected consequences on the mcclim-devel list archive, including a reindexing of the archive. The problem you mention may be related. I suggest that you notify the Common-Lisp.net maintainers. Thanks for your McCLIM goodies! Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From rpgoldman at real-time.com Thu Aug 18 22:33:03 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Thu, 18 Aug 2005 17:33:03 -0500 Subject: [mcclim-devel] question about abort and accept Message-ID: <17157.3231.498874.283146@gargle.gargle.HOWL> IIUC, the abort gesture is defined to be control-C. (define-gesture-name :abort :keyboard (#\c :control)) So, I was surprised to find when I had mistyped an argument, and pressed control-c, it did not abort the interaction. Is this a bug? I rooted around in the code, and I'm afraid I wasn't sufficiently savvy to guess where the abort gesture should be trapped. I would have guessed, though, that unless it was trapped, it would toss an error. So is there something wrong about accept in an interactor window that is keeping abort from being signalled? thanks, r From mikemac at mikemac.com Fri Aug 19 04:03:40 2005 From: mikemac at mikemac.com (Mike McDonald) Date: Thu, 18 Aug 2005 21:03:40 -0700 Subject: [mcclim-devel] mcclim-0.9.1:system.lisp Message-ID: <200508190403.j7J43e411521@saturn.mikemac.com> Something looks a bit fishy. (pushnew :clim *features*) (pushnew :mcclim *features*) +;;; I really didn't have good luck with this on Allegro, because +;;; Allegro's CL-USER package uses it's EXCL stuff, which has its own +;;; DEFSYSTEM. [2004/12/21:rpg] +;;;#+mk-defsystem (use-package "MK") (defmacro clim-defsystem ((module &key depends-on) &rest components) `(progn #+mk-defsystem Mike McDonald mikemac at mikemac.com From mikemac at mikemac.com Fri Aug 19 04:06:07 2005 From: mikemac at mikemac.com (Mike McDonald) Date: Thu, 18 Aug 2005 21:06:07 -0700 Subject: [mcclim-devel] tar file of nightly "sources" Message-ID: <200508190406.j7J467411532@saturn.mikemac.com> Quoting the web page: Releases A compressed tar file of the sources is made nightly. Except it's not the sources. It's the whole CVS repository! Mike McDonald mikemac at mikemac.com From rpgoldman at real-time.com Fri Aug 19 03:46:05 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Thu, 18 Aug 2005 22:46:05 -0500 Subject: [mcclim-devel] mcclim-0.9.1:system.lisp In-Reply-To: <200508190403.j7J43e411521@saturn.mikemac.com> References: <200508190403.j7J43e411521@saturn.mikemac.com> Message-ID: <17157.22013.930097.580920@gargle.gargle.HOWL> I did that. You can't very well :USE MK into CL-USER on Allegro, because Allegro's CL-USER :USEs their :EXCL package, and their :EXCL package contains their own DEFSYSTEM. So using both makes a big mess. When I looked into this, I found that it was really painless, for the few places where the MK-DEFSYSTEM stuff *was* used, to just turn FOO into MK:FOO. At the cost of a few extra characters, we avoid a gross effect on the CL-USER package. Seemed like a good tradeoff to me. BTW, I'm pretty sure that this was earlier discussed on the mcclim-devel list, since I have only recently acquired commit permission. So I managed to persuade the community at large that this would be at least an OK Thing To Do. Best, R From mikemac at mikemac.com Fri Aug 19 04:22:05 2005 From: mikemac at mikemac.com (Mike McDonald) Date: Thu, 18 Aug 2005 21:22:05 -0700 Subject: [mcclim-devel] mcclim-0.9.1:system.lisp In-Reply-To: Your message of "Thu, 18 Aug 2005 22:46:05 EST." <17157.22013.930097.580920@gargle.gargle.HOWL> Message-ID: <200508190422.j7J4M5411573@saturn.mikemac.com> >To: Mike McDonald >Date: Thu, 18 Aug 2005 22:46:05 -0500 >From: rpgoldman at real-time.com > > >I did that. You can't very well :USE MK into CL-USER on Allegro, >because Allegro's CL-USER :USEs their :EXCL package, and their :EXCL >package contains their own DEFSYSTEM. So using both makes a big >mess. > >When I looked into this, I found that it was really painless, for the >few places where the MK-DEFSYSTEM stuff *was* used, to just turn FOO >into MK:FOO. > >At the cost of a few extra characters, we avoid a gross effect on the >CL-USER package. Seemed like a good tradeoff to me. > >BTW, I'm pretty sure that this was earlier discussed on the >mcclim-devel list, since I have only recently acquired commit >permission. So I managed to persuade the community at large that this >would be at least an OK Thing To Do. > >Best, >R I was refering to all of the lines that start with a +! Mike McDonald mikemac at mikemac.com From rpgoldman at real-time.com Fri Aug 19 04:36:36 2005 From: rpgoldman at real-time.com (Robert P. Goldman) Date: Thu, 18 Aug 2005 23:36:36 -0500 Subject: [mcclim-devel] mcclim-0.9.1:system.lisp In-Reply-To: <200508190422.j7J4M5411573@saturn.mikemac.com> References: <200508190422.j7J4M5411573@saturn.mikemac.com> Message-ID: <430561D4.2010208@real-time.com> Mike McDonald wrote: >>To: Mike McDonald >>Date: Thu, 18 Aug 2005 22:46:05 -0500 >>From: rpgoldman at real-time.com >> >> >>I did that. You can't very well :USE MK into CL-USER on Allegro, >>because Allegro's CL-USER :USEs their :EXCL package, and their :EXCL >>package contains their own DEFSYSTEM. So using both makes a big >>mess. >> >>When I looked into this, I found that it was really painless, for the >>few places where the MK-DEFSYSTEM stuff *was* used, to just turn FOO >>into MK:FOO. >> >>At the cost of a few extra characters, we avoid a gross effect on the >>CL-USER package. Seemed like a good tradeoff to me. >> >>BTW, I'm pretty sure that this was earlier discussed on the >>mcclim-devel list, since I have only recently acquired commit >>permission. So I managed to persuade the community at large that this >>would be at least an OK Thing To Do. >> >>Best, >>R > > > I was refering to all of the lines that start with a +! > Whoops. OK, I don't think I know about that. Perhaps there was a confusion with applying my patch? Unix is funny about hash marks.... Maybe they somehow got stripped off the #+'s? Best, Robert From duncan at robotcat.demon.co.uk Fri Aug 19 09:06:25 2005 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Fri, 19 Aug 2005 10:06:25 +0100 Subject: [mcclim-devel] mcclim-0.9.1:system.lisp In-Reply-To: <430561D4.2010208@real-time.com> Message-ID: <84D9F874-1090-11DA-B790-000A9577B8A2@robotcat.demon.co.uk> About the same time that the mail archive got mixed up, I had a couple of problematic commits with common-lisp.net complaining about #s. I was under the impression that this affected only the mcclim-cvs automatic mailing, but maybe it was a more fundamental problem. It was resolved in a couple of days IIRC (by the c-l.net admins). Perhaps this error was introduced by unlucky timing... -Duncan On Friday, August 19, 2005, at 05:36 am, Robert P. Goldman wrote: > Mike McDonald wrote: > >>> To: Mike McDonald >>> Date: Thu, 18 Aug 2005 22:46:05 -0500 >>> From: rpgoldman at real-time.com >>> >>> >>> I did that. You can't very well :USE MK into CL-USER on Allegro, >>> because Allegro's CL-USER :USEs their :EXCL package, and their :EXCL >>> package contains their own DEFSYSTEM. So using both makes a big >>> mess. >>> >>> When I looked into this, I found that it was really painless, for the >>> few places where the MK-DEFSYSTEM stuff *was* used, to just turn FOO >>> into MK:FOO. >>> >>> At the cost of a few extra characters, we avoid a gross effect on the >>> CL-USER package. Seemed like a good tradeoff to me. >>> BTW, I'm pretty sure that this was earlier discussed on the >>> mcclim-devel list, since I have only recently acquired commit >>> permission. So I managed to persuade the community at large that >>> this >>> would be at least an OK Thing To Do. >>> >>> Best, >>> R >> I was refering to all of the lines that start with a +! > > Whoops. OK, I don't think I know about that. Perhaps there was a > confusion with applying my patch? Unix is funny about hash marks.... > Maybe they somehow got stripped off the #+'s? > > Best, > Robert > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From chri0665 at uidaho.edu Sat Aug 20 09:00:41 2005 From: chri0665 at uidaho.edu (David Christiansen) Date: Sat, 20 Aug 2005 11:00:41 +0200 Subject: [mcclim-devel] A mcclim app which could possibly be used as a demo Message-ID: <218A2BD0-F9C1-4B90-8906-A5E023ABAB61@uidaho.edu> Hello, For my AI class at the University of Idaho, I wrote a program that will play Connect 4 against you. I used McCLIM, and just tested it against the CVS version. It demonstrates drawing, presentation-to- command translators, and a few other things. I've also commented it a great deal, as Lisp was not the first language of the TA who graded my work. The file is attached to this email, in case you'd like to use it as example code for McCLIM. I'm fairly new to Lisp, so parts may be sub-optimal. If they are, please let me know and I'll improve them. -David Christiansen -------------- next part -------------- A non-text attachment was scrubbed... Name: connect4.lisp Type: application/octet-stream Size: 24090 bytes Desc: not available URL: -------------- next part -------------- From csr21 at cam.ac.uk Sat Aug 20 10:21:55 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sat, 20 Aug 2005 11:21:55 +0100 Subject: [mcclim-devel] A mcclim app which could possibly be used as a demo In-Reply-To: <218A2BD0-F9C1-4B90-8906-A5E023ABAB61@uidaho.edu> (David Christiansen's message of "Sat, 20 Aug 2005 11:00:41 +0200") References: <218A2BD0-F9C1-4B90-8906-A5E023ABAB61@uidaho.edu> Message-ID: David Christiansen writes: > For my AI class at the University of Idaho, I wrote a program that > will play Connect 4 against you. I used McCLIM, and just tested it > against the CVS version. It demonstrates drawing, presentation-to- > command translators, and a few other things. I've also commented it > a great deal, as Lisp was not the first language of the TA who graded > my work. The file is attached to this email, in case you'd like to > use it as example code for McCLIM. I'm fairly new to Lisp, so parts > may be sub-optimal. If they are, please let me know and I'll improve > them. This is cool. I'll comment a little bit on small elements of Lisp style below (without having run the program yet, which is a bit dangerous :-), but before I do that I'd quite like to draw your attention to which is mostly a discussion about how to subvert online tournaments, but also contains some discussion about the "closed-form" solution of Connect 4 and a reference to the solution by Allis. > ;;;; Connect 4 game by David Christiansen > (defpackage connect4 > (:nicknames :connect4) > (:use :common-lisp-user :clim :clim-lisp) ^^^^^^^^^^^^^^^^^ I can conceive no world where this is a good idea. The contents of CL-USER are completely undefined in general. > (:export run-connect4)) > > (in-package :connect4) > > ;;; Establish various options prior to evaluating forms that depend on > ;;; them. Think of this section as being analogous to a C program's > ;;; config.h file. > (eval-when (:compile-toplevel :load-toplevel :execute) > [...] > (proclaim '(type (integer 0 30) *rows* *cols* *default-depth*)) > (proclaim '(type (integer 0 50) *piece-radius*))) You would avoid the eval-when completely by changing the two PROCLAIMs here to DECLAIM: (declaim (type (integer 0 30) *rows* *cols* *default-depth*)) and (declaim (type (integer 0 50) *piece-radius*)) as then all of these operators (DEFPARAMETER, DEFCONSTANT, DECLAIM) are defined to have enough compile-time effect to ensure correct compilation of the rest of the file. > ;;; Convenience function to make later code more readable. > (declaim (inline col-top)) > (defun col-top (board col) > "Return the index of the top piece in a column." > (aref (board-tops board) col)) One more subjective point: there are many ways of abbreviating things, but only one of spelling it out in full... col-top might be better as column-top. (Depending on your use of it, it might be more "natural" in lisp to use column-height instead, returning the index of the first free space: Lisp is 0-based inclusive at the start of sequences and exclusive at the end. This does depend on use, though. Do you use -1 for empty columns?) > ;;; causes the loop to terminate and return the current score. THIS > ;;; MACRO IS NOT GENERAL UTILITY! EXPANSIONS CONTAIN NASTY FREE > ;;; VARIABLES! > (defmacro goodness-loop ((&rest loop-keywords-for-init) > current-form > &optional bail-form) One way of expressing the lack of general-purpose of a macro such as this, which depends on various variable names being bound, is to make it a local macro. You could place it in a macrolet in DEFUN GOODNESS, and then no-one would ever be tempted to use it elsewhere. These comments aside, good stuff! :-) Cheers, Christophe From rpgoldman at sift.info Mon Aug 22 17:10:45 2005 From: rpgoldman at sift.info (Robert P. Goldman) Date: Mon, 22 Aug 2005 12:10:45 -0500 Subject: [mcclim-devel] One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <4b3329def8aba5fcaac94236be8f55ae@bricoworks.com> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> <4b3329def8aba5fcaac94236be8f55ae@bricoworks.com> Message-ID: <17162.1813.313566.222140@gargle.gargle.HOWL> >>>>> "TM" == Timothy Moore writes: TM> On Aug 9, 2005, at 9:28 PM, rpgoldman at real-time.com wrote: >> I'm afraid that hasn't really been my experience. I can often crash >> McCLIM when I do something that upsets its processing of ACCEPT, in >> particular, and updating output seems to work very, very badly with >> scrolling panes, so badly that I can't think of a single interaction >> which hasn't required me to iconify and de-iconify the frame to make >> it repaint reasonably. And usually I have to resize the frame by hand >> in the process. This seems to me to be pretty far from usable. TM> I'm not necessarily disagreeing about the state of accept (more TM> accurately input editing) and incremental redisplay, but I'm having TM> some trouble searching through the mail archives for specific TM> complaints. In particular I have not noticed problems with scrolling TM> and updating-output in my use of it. Do you mind (re)posting some TM> specific bugs? Tim, sorry to have taken so long to get back to you. Rereading your email, I see that I have misled you. I was referring above to two *separate* problems. I.e., (1) I have found it very easy to toss my McCLIM app into the debugger by typing a bad character in the middle of ACCEPTing arguments and (2) I have frequently had trouble with updating output that has left me with a small subset of a scrolling window redrawn, and with the rest of that window a blank, gray area. I'm not sure that (1) is a bug, per se. It's not that ACCEPT ever returns a bad value, it's just that it is not robust to getting bad input. I would have thought that ACCEPT should by default trap the INPUT-NOT-OF-REQUIRED-TYPE. As a programmer, I don't see how I can do this, if ACCEPT doesn't. I.e., when I write a define--command form, it's internal CLIM stuff that handles getting the arguments for me, and if I type something wrong, I'd rather not have the application dumped into the debugger. So shouldn't that command processing exit somewhat gracefully by default? Similarly, as I mentioned earlier, it would be nice if one could use the ABORT gesture in the middle of ACCEPT and have something good happen. Seems like if I type something bad and can't fix it in input-editing, I'm just doomed to complete the interaction, and then have the command fail into the debugger. I looked into this a little, and it seemed like there was no place in the %ACCEPT code that looked for an ABORT gesture, but the bottom layers of McCLIM are pretty mysterious to me. Is this a GOATEE thing, or should it be handle by %ACCEPT or ACCEPT-FROM-STREAM? If you can give me a pointer, I'd be happy to try to fix it myself. Best, R From m.retzlaff at gmx.net Mon Aug 22 18:34:56 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Mon, 22 Aug 2005 20:34:56 +0200 Subject: [mcclim-devel] ABORT gesture for ACCEPT (was: One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <17162.1813.313566.222140@gargle.gargle.HOWL> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> <4b3329def8aba5fcaac94236be8f55ae@bricoworks.com> <17162.1813.313566.222140@gargle.gargle.HOWL> Message-ID: <20050822183456.GA23661@mgr.home> Hi On Mon, Aug 22, 2005 at 12:10:45PM -0500, Robert P. Goldman wrote: > Similarly, as I mentioned earlier, it would be nice if one could use > the ABORT gesture in the middle of ACCEPT and have something good > happen. Seems like if I type something bad and can't fix it in > input-editing, I'm just doomed to complete the interaction, and then > have the command fail into the debugger. I looked into this a little, > and it seemed like there was no place in the %ACCEPT code that looked > for an ABORT gesture, but the bottom layers of McCLIM are pretty > mysterious to me. Is this a GOATEE thing, or should it be handle by > %ACCEPT or ACCEPT-FROM-STREAM? If you can give me a pointer, I'd be > happy to try to fix it myself. Some minutes after you seemed to have left the channel I posted a patch for you. Basically it is just adding (handler-bind ((abort-gesture #'abort)) in the beginning of ACCEPT in presentation-defs.lisp. That seems to be okay. ABORT-GESTURE is the condition that is signaled when any of the gestures in *ABORT-GESTURES* is read (in STREAM-READ-GESTURE). Right now *ABORT-GESTURES* contains only :abort on mcclim, which is a the keyboard gesture (#\c :control) (on Genera it contains #\Abort, the ABORT-key). I do not find explicitly in the clim specification that an accept should be aborted on any abort-gesture, but it seems to be the right thing. I did short tests with ACCEPTING-VALUES and it seems to behave correctly with this patch, i.e. the whole dialog will be aborted. Or would it be better if only the editing of the single input-gadget is aborted? Also Genera CLIM and Dynamic Windows behave in the same way, although one gets thrown into the debugger if one presses ABORT during editing a text-field of an CLIM:ACCEPTING-VALUES dialog... This does not happen with McCLIM and this patch. If noone complains I'll apply it to the repository. Regards, Max -- Max-Gerd Retzlaff For your amusement: Stay away from hurricanes for a while. -------------- next part -------------- --- presentation-defs.lisp.~1.44.~ 2005-06-24 01:12:42.000000000 +0200 +++ presentation-defs.lisp 2005-08-22 19:31:42.024459480 +0200 @@ -664,71 +664,72 @@ display-default query-identifier activation-gestures additional-activation-gestures delimiter-gestures additional-delimiter-gestures)) - (let* ((real-type (expand-presentation-type-abbreviation type)) - (real-default-type (cond (default-type-p - (expand-presentation-type-abbreviation - default-type)) - ((or defaultp provide-default) - real-type) - (t nil))) - (real-history-type (cond ((null historyp) real-type) - ((null history) nil) - (t (expand-presentation-type-abbreviation - history)))) - (*recursive-accept-p* *recursive-accept-1-p*) - (*recursive-accept-1-p* t)) - (with-keywords-removed (rest-args (:stream)) - (when (or default-type-p defaultp) - (setf rest-args - (list* :default-type real-default-type rest-args))) - (when historyp - (setf rest-args (list* :history real-history-type rest-args))) - (cond ((and viewp (symbolp view)) - (setf rest-args - (list* :view (funcall #'make-instance view) rest-args))) - ((consp view) - (setf rest-args - (list* :view (apply #'make-instance view) rest-args)))) - ;; Presentation type history interaction. According to the spec, - ;; if provide-default is true, we take the default from the - ;; presentation history. In addition, we'll implement the Genera - ;; behavior of temporarily putting the default on the history - ;; stack so the user can conveniently suck it in. - (flet ((do-accept (args) - (apply #'stream-accept stream real-type args)) - (get-history () - (when real-history-type - (funcall-presentation-generic-function - presentation-type-history-for-stream - real-history-type stream)))) - (let* ((default-from-history (and (not defaultp) provide-default)) - (history (get-history)) - (results - (multiple-value-list - (if history - (let ((*active-history-type* real-history-type)) - (cond (defaultp - (with-object-on-history - (history default real-default-type) - (do-accept rest-args))) - (default-from-history - (multiple-value-bind - (history-default history-type) - (presentation-history-head history - real-default-type) - (do-accept (if history-type - (list* :default history-default - :default-type history-type - rest-args) - rest-args)))) - (t (do-accept rest-args)))) - (do-accept rest-args)))) - (results-history (get-history))) - (when results-history - (presentation-history-add results-history - (car results) - (cadr results))) - (values-list results)))))) + (handler-bind ((abort-gesture #'abort)) + (let* ((real-type (expand-presentation-type-abbreviation type)) + (real-default-type (cond (default-type-p + (expand-presentation-type-abbreviation + default-type)) + ((or defaultp provide-default) + real-type) + (t nil))) + (real-history-type (cond ((null historyp) real-type) + ((null history) nil) + (t (expand-presentation-type-abbreviation + history)))) + (*recursive-accept-p* *recursive-accept-1-p*) + (*recursive-accept-1-p* t)) + (with-keywords-removed (rest-args (:stream)) + (when (or default-type-p defaultp) + (setf rest-args + (list* :default-type real-default-type rest-args))) + (when historyp + (setf rest-args (list* :history real-history-type rest-args))) + (cond ((and viewp (symbolp view)) + (setf rest-args + (list* :view (funcall #'make-instance view) rest-args))) + ((consp view) + (setf rest-args + (list* :view (apply #'make-instance view) rest-args)))) + ;; Presentation type history interaction. According to the spec, + ;; if provide-default is true, we take the default from the + ;; presentation history. In addition, we'll implement the Genera + ;; behavior of temporarily putting the default on the history + ;; stack so the user can conveniently suck it in. + (flet ((do-accept (args) + (apply #'stream-accept stream real-type args)) + (get-history () + (when real-history-type + (funcall-presentation-generic-function + presentation-type-history-for-stream + real-history-type stream)))) + (let* ((default-from-history (and (not defaultp) provide-default)) + (history (get-history)) + (results + (multiple-value-list + (if history + (let ((*active-history-type* real-history-type)) + (cond (defaultp + (with-object-on-history + (history default real-default-type) + (do-accept rest-args))) + (default-from-history + (multiple-value-bind + (history-default history-type) + (presentation-history-head history + real-default-type) + (do-accept (if history-type + (list* :default history-default + :default-type history-type + rest-args) + rest-args)))) + (t (do-accept rest-args)))) + (do-accept rest-args)))) + (results-history (get-history))) + (when results-history + (presentation-history-add results-history + (car results) + (cadr results))) + (values-list results))))))) (defgeneric stream-accept (stream type &key -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rpgoldman at sift.info Tue Aug 23 14:27:23 2005 From: rpgoldman at sift.info (Robert P. Goldman) Date: Tue, 23 Aug 2005 09:27:23 -0500 Subject: [mcclim-devel] CLIM-LISTENER and the MOP Message-ID: <17163.12875.135595.286065@gargle.gargle.HOWL> Recently, I was playing with the CLIM-LISTENER (thanks to Paolo's suggestion that it would provide good exercise for the graph-rendering code), and found that it often crashed under Allegro CL, with MOP errors. I'm no MOP authority, so I dropped a line to Franz to ask them why this was happening. Steve Haflich kindly filled me in on why, and offered some comments on the use of the MOP to interrogate the class hierarchy in the CLIM listener. With his permission, here's some of what he said: From: rpgoldman at sift.info I have been trying to use a portable class browser for class hierarchies with ACL 6.2, and have been getting frequent errors like this: CL-USER(8): (aclmop:class-slots (find-class 'clim::application-frame)) Error: Class # is not yet finalized. [condition type: PROGRAM-ERROR] Restart actions (select using :continue): 0: Return to Top Level (an "abort" restart). 1: Abort entirely from this process. [1] CL-USER(9): [note: this is with the open McCLIM clim implementation, not ACL CLIM.] I'm confused by this error, since it seems to contradict the documentation I have, which states: "Class finalization is the process of computing the information a class inherits from its superclasses and preparing to actually allocate instances of the class. ... To support forward-referenced superclasses, and to account for the fact that not all classes are actually instantiated, class finalization is not done as part of the initialization of the class metaobject. Instead, finalization is done as a separate protocol, invoked by calling the generic function finalize-inheritance. The exact point at which finalize-inheritance is called depends on the class of the class metaobject; for standard-class it is called sometime after all the classes superclasses are defined, but no later than when the first instance of the class is allocated (by allocate-instance)." But I have an instance of this class that the MOP seems to be telling me is not finalized: GRAPH-MDP(77): (class-of *frame*) # GRAPH-MDP(78): (aclmop:class-direct-superclasses (class-of *frame*)) (#) (aclmop:class-direct-superclasses (first (aclmop:class-direct-superclasses (class-of *frame*)))) (# #) Based on the above, shouldn't APPLICATION-FRAME have been finalized? Or is it not finalized because it doesn't have any DIRECT instances? SMH> Your suggested analysis is correct: A class is only required to be SMH> finalized when it is directly instantiated. (See the term "direct SMH> instance" in the ANS Glossary.) There is no need to finialize SMH> superclasses. In fact, there is good reason not to do so, even beyond SMH> the fact that it is a waste of time and storage: SMH> If one has a collection of mixin classes, sometimes the oeration of SMH> one mixin might depend on functionality, perhaps a method, provided by SMH> a different mixin. If one instantiates a class that doesn't have a SMH> complete set of these interrelated mixins, an error can be signalled SMH> at execution time. It is sometime done that a mixin will implement SMH> checking for other necessary classes and/or method. It can do this in SMH> various ways, such as by defining :after methods on SMH> finalize-inheritance. The idea is that it is much better to signal SMH> error for some inconsistency earlier rather than later. Steve went on to directly comment on the class browsing in CLIM-LISTENER: SMH> .... We agreed in the last round that a class does not _have_ a SMH> class-slots property until it is finalized, and not all classes are SMH> always finalized. Further, it's even worse, because some classes SMH> cannot even be finalized. As I suggested before, a mixin class might SMH> have code to guarantee it is not finalized (or instantiated) unless SMH> certain conditions are met. And of course finalization is impossible SMH> if a class' superclasses include a forward-reference-class. SMH> So ideas like trying to force all classes to be finalized or to SMH> trigger class finalization when inspected probably aren't good ones. SMH> I don't know if it is possible for you to suggest McCLIM be fixed SMH> (which would be best) or whether you have to try to patch this locally SMH> in your copy. But you might investigate what the McCLIM inspector SMH> itself does in the situation that a class still has forward SMH> references. SMH> class-slots is defined to return a list of SMH> effective-slot-definition-objects, which cannot exist until SMH> finalization. Depending on the needs of the browser, it is SMH> straightforward to write a class walker that computes a partial list SMH> of known slots by walking the portions of the superclass tree that are SMH> defined (i.e. stopping on forward-reference-classes). But that would SMH> compute a set of direct-slot-definition-objects (possibly multiple SMH> dsd's per slot) instead of esd's, so the browser would need to be SMH> modified to accept this. As I said, I'm no expert on the MOP, or the internals of the CLIM-LISTENER, so I'm not sure how feasible/desirable such a rewrite would be. For that matter, I'm not sure why the CLIM-LISTENER works on CMUCL and SBCL... I'd be willing to rally round to help fix this if anyone wants to take charge, especially to conduct tests on ACL 6.2 and 7.0. But I'm not qualified to be more than a foot-soldier in that effort.... Cheers, R From rpgoldman at real-time.com Thu Aug 25 14:47:35 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Thu, 25 Aug 2005 09:47:35 -0500 Subject: [mcclim-devel] ABORT gesture for ACCEPT (was: One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <20050822183456.GA23661@mgr.home> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> <4b3329def8aba5fcaac94236be8f55ae@bricoworks.com> <17162.1813.313566.222140@gargle.gargle.HOWL> <20050822183456.GA23661@mgr.home> Message-ID: <17165.55815.109581.725090@gargle.gargle.HOWL> MGR> Hi MGR> On Mon, Aug 22, 2005 at 12:10:45PM -0500, Robert P. Goldman wrote: >> Similarly, as I mentioned earlier, it would be nice if one could use >> the ABORT gesture in the middle of ACCEPT and have something good >> happen. Seems like if I type something bad and can't fix it in >> input-editing, I'm just doomed to complete the interaction, and then >> have the command fail into the debugger. [...snip...] MGR> Some minutes after you seemed to have left the channel I MGR> posted a patch for you. Basically it is just adding MGR> (handler-bind ((abort-gesture #'abort)) in the beginning of MGR> ACCEPT in presentation-defs.lisp. That seems to be okay. MGR> ABORT-GESTURE is the condition that is signaled when any of the MGR> gestures in *ABORT-GESTURES* is read (in STREAM-READ-GESTURE). Right MGR> now *ABORT-GESTURES* contains only :abort on mcclim, which is a the MGR> keyboard gesture (#\c :control) (on Genera it contains #\Abort, the MGR> ABORT-key). MGR> I do not find explicitly in the clim specification that an MGR> accept should be aborted on any abort-gesture, but it seems MGR> to be the right thing. MGR> I did short tests with ACCEPTING-VALUES and it seems to MGR> behave correctly with this patch, i.e. the whole dialog will MGR> be aborted. Or would it be better if only the editing of the MGR> single input-gadget is aborted? MGR> Also Genera CLIM and Dynamic Windows behave in the same way, although MGR> one gets thrown into the debugger if one presses ABORT during editing MGR> a text-field of an CLIM:ACCEPTING-VALUES dialog... This does not MGR> happen with McCLIM and this patch. MGR> If noone complains I'll apply it to the repository. Has anyone squawked? If not, how please do apply it. Best, R From m.retzlaff at gmx.net Thu Aug 25 20:23:38 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 25 Aug 2005 22:23:38 +0200 Subject: [mcclim-devel] ABORT gesture for ACCEPT (was: One char patch to presentation-defs [really future of McCLIM] In-Reply-To: <17165.55815.109581.725090@gargle.gargle.HOWL> References: <17145.6384.405257.868055@serveur5.labri.fr> <20050810003655.89401.qmail@web31701.mail.mud.yahoo.com> <17145.20596.736961.29393@serveur5.labri.fr> <17145.22605.625503.992209@gargle.gargle.HOWL> <4b3329def8aba5fcaac94236be8f55ae@bricoworks.com> <17162.1813.313566.222140@gargle.gargle.HOWL> <20050822183456.GA23661@mgr.home> <17165.55815.109581.725090@gargle.gargle.HOWL> Message-ID: <20050825202338.GA8749@mgr.home> Hello On Thu, Aug 25, 2005 at 09:47:35AM -0500, rpgoldman at real-time.com wrote: > MGR> Basically it is just adding > MGR> (handler-bind ((abort-gesture #'abort)) in the beginning of > MGR> ACCEPT in presentation-defs.lisp. That seems to be okay. > MGR> If noone complains I'll apply it to the repository. > > Has anyone squawked? If not, how please do apply it. I've just done that. See: http://common-lisp.net/pipermail/mcclim-cvs/2005-August/000297.html Sorry for the delay, at least everybody have had some time to complain or improve the patch already. :) Bye, Max -- Max-Gerd Retzlaff For your amusement: 22:50 < stesch> ouch: "Today is the car of the cdr of your life." -- on Wednesday, 8-17-2005 in #lisp -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ahefner at gmail.com Thu Aug 25 21:48:37 2005 From: ahefner at gmail.com (Andy Hefner) Date: Thu, 25 Aug 2005 17:48:37 -0400 Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp In-Reply-To: <20050825204846.5C821880DA@common-lisp.net> References: <20050825204846.5C821880DA@common-lisp.net> Message-ID: <31ffd3c4050825144834381cdd@mail.gmail.com> On 8/25/05, Max-Gerd Retzlaff wrote: > (Broken because OPEN-WINDOW-STREAM doesn't really work yet. I think > there has to be a (redisplay-frame-panes frame) or something like that > in its event-loop (that is the function STANDALONE-EVENT-LOOP).) Why do you think that? From m.retzlaff at gmx.net Thu Aug 25 22:40:12 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 26 Aug 2005 00:40:12 +0200 Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp In-Reply-To: <31ffd3c4050825144834381cdd@mail.gmail.com> References: <20050825204846.5C821880DA@common-lisp.net> <31ffd3c4050825144834381cdd@mail.gmail.com> Message-ID: <20050825224012.GA10416@mgr.home> Good evening. On Thu, Aug 25, 2005 at 05:48:37PM -0400, Andy Hefner wrote: > On 8/25/05, Max-Gerd Retzlaff wrote: > > > > (Broken because OPEN-WINDOW-STREAM doesn't really work yet. I think > > there has to be a (redisplay-frame-panes frame) or something like that > > in its event-loop (that is the function STANDALONE-EVENT-LOOP).) > > Why do you think that? In my hack of WITH-STREAM-IN-OWN-WINDOW I called OPEN-WINDOW-STREAM without specifying any parameters, in particular without specifying :INPUT-BUFFER. If that is done (or if :INPUT-BUFFER is set to nil) a separate process is made for the application frame of the opened window stream and (basically) STANDALONE-EVENT-LOOP is specified as the process's function. The problem was that inside the opened windows only about every forth or fifth mouse click or keystroke had effects. Calling REDISPLAY-FRAME-PANES inside STANDALONE-EVENT-LOOP did change this, (altough I was worried that calling REDISPLAY-FRAME-PANES in every iteration of the loop has been quite expensive). But there has been a short discussion in #lisp after Christophe mentioned that they use OPEN-WINDOW-STREAM in the Tablature Editor without problems: 23:30 < Xophe> mgr: we don't have any of those problems; on the other hand, we share an input buffer I replaced the aforementioned call in WITH-STREAM-IN-OWN-WINDOW by: (open-window-stream :label ,label :input-buffer (climi::frame-event-queue *application-frame*)) This is very nice as a) it works without the reaction problems and b) I could get rid of the ugly, ugly (delay 0.1) that "ensured" that the new-process has been created before the stream was used. Without this I consider WITH-STREAM-IN-OWN-WINDOW much less a hack. At first I was a tad unsure about using :input-buffer as Franz' CLIM 2 User Guide says on ACCEPTING-VALUES: "The remaining keyword arguments [:input-buffers being one of them] are internal and should not be used." But the CLIM II Specification just says: If input-buffer is supplied, it is an input buffer or event queue to use for the resulting window. Programmers will generally supply this when they want the new window to share its input buffer with an existing application. The default is to create a new input buffer. STANDALONE-EVENT-LOOP or the part inside of (unless input-buffer ...) of OPEN-WINDOW-STREAM should perhaps still be changed, though. And the McCLIM user's manuel should contain in its (not yet existing) paragraph on OPEN-WINDOW-STREAM saying that one probably wants to call OPEN-WINDOW-STREAM with :input-buffer as (climi::frame-event-queue *application-frame*).. Bye, Max PS: I'll apply the patch to CLIMI::WITH-STREAM-IN-OWN-WINDOW soon. Comments are welcome. -- Max-Gerd Retzlaff For your amusement: My apologies if I sound angry. I feel like I'm talking to a void. -- Avery Pennarun -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rpgoldman at real-time.com Thu Aug 25 23:53:49 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Thu, 25 Aug 2005 18:53:49 -0500 Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp In-Reply-To: <20050825224012.GA10416@mgr.home> References: <20050825204846.5C821880DA@common-lisp.net> <31ffd3c4050825144834381cdd@mail.gmail.com> <20050825224012.GA10416@mgr.home> Message-ID: <17166.23053.507924.526008@gargle.gargle.HOWL> >>>>> "mgr" == Max-Gerd Retzlaff writes: mgr> And the McCLIM user's manuel should contain in its (not yet existing) mgr> paragraph on OPEN-WINDOW-STREAM saying that one probably wants to call mgr> OPEN-WINDOW-STREAM with :input-buffer as (climi::frame-event-queue mgr> *application-frame*).. This raises the obvious question of whether this should somehow be made the default value of that argument. Something like (when (boundp '*application-frame*) (climi::frame-event-queue *application-frame*)) perhaps? R From m.retzlaff at gmx.net Fri Aug 26 02:26:13 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 26 Aug 2005 04:26:13 +0200 Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp In-Reply-To: <17166.23053.507924.526008@gargle.gargle.HOWL> References: <20050825204846.5C821880DA@common-lisp.net> <31ffd3c4050825144834381cdd@mail.gmail.com> <20050825224012.GA10416@mgr.home> <17166.23053.507924.526008@gargle.gargle.HOWL> Message-ID: <20050826022613.GB11635@mgr.home> Hello On Thu, Aug 25, 2005 at 06:53:49PM -0500, rpgoldman at real-time.com wrote: > >>>>> "mgr" == Max-Gerd Retzlaff writes: > > mgr> And the McCLIM user's manuel should contain in its (not yet existing) > mgr> paragraph on OPEN-WINDOW-STREAM saying that one probably wants to call > mgr> OPEN-WINDOW-STREAM with :input-buffer as (climi::frame-event-queue > mgr> *application-frame*).. > > This raises the obvious question of whether this should somehow be > made the default value of that argument. Something like Well, that would be against the CLIM II specification. As already quoted in my last mail it says: If input-buffer is supplied, it is an input buffer or event queue to use for the resulting window. Programmers will generally supply this when they want the new window to share its input buffer with an existing application. The default is to create a new input buffer. Bye, Max -- Max-Gerd Retzlaff For your amusement: Elliptic paraboloids for sale. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rpgoldman at real-time.com Fri Aug 26 03:52:19 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Thu, 25 Aug 2005 22:52:19 -0500 Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp In-Reply-To: <20050826022613.GB11635@mgr.home> References: <20050825204846.5C821880DA@common-lisp.net> <31ffd3c4050825144834381cdd@mail.gmail.com> <20050825224012.GA10416@mgr.home> <17166.23053.507924.526008@gargle.gargle.HOWL> <20050826022613.GB11635@mgr.home> Message-ID: <17166.37363.978182.963662@gargle.gargle.HOWL> >>>>> "mgr" == Max-Gerd Retzlaff writes: mgr> Hello mgr> On Thu, Aug 25, 2005 at 06:53:49PM -0500, rpgoldman at real-time.com wrote: >> >>>>> "mgr" == Max-Gerd Retzlaff writes: >> mgr> And the McCLIM user's manuel should contain in its (not yet existing) mgr> paragraph on OPEN-WINDOW-STREAM saying that one probably wants to call mgr> OPEN-WINDOW-STREAM with :input-buffer as (climi::frame-event-queue mgr> *application-frame*).. >> >> This raises the obvious question of whether this should somehow be >> made the default value of that argument. Something like mgr> Well, that would be against the CLIM II specification. As already mgr> quoted in my last mail it says: mgr> If input-buffer is supplied, it is an input buffer or mgr> event queue to use for the resulting window. Programmers mgr> will generally supply this when they want the new window mgr> to share its input buffer with an existing mgr> application. The default is to create a new input buffer. Um... but I thought that your earlier message said that the default behavior dictated by the spec didn't work. Maybe I didn't fully understand. I guess I had thought a spec violation was better than a spec-obeying busted behavior... If the spec-dictated behavior really *is* busted, would it be reasonable to hoist an error on defaulting the argument, and suggest that the user do the spec-defying but workable thing? Best, R From m.retzlaff at gmx.net Fri Aug 26 13:13:15 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 26 Aug 2005 15:13:15 +0200 Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp In-Reply-To: <8764ts5342.fsf@plato.moon.paoloamoroso.it> References: <20050826003258.9D6348855C@common-lisp.net> <8764ts5342.fsf@plato.moon.paoloamoroso.it> Message-ID: <20050826131315.GA20514@mgr.home> Hello On Fri, Aug 26, 2005 at 01:50:21PM +0200, Paolo Amoroso wrote: > mretzlaff at common-lisp.net (Max-Gerd Retzlaff) writes: > > > Modified Files: > > dialog.lisp > > Log Message: > > (climi::frame-event-queue *application-frame*) as argument :INPUT-BUFFER > > to the call of OPEN-WINDOW-STREAM in WITH-STREAM-IN-OWN-WINDOW (was not > > specified previously). > > I still don't get separate windows in dialogs of town-example.lisp > that have :own-window t. The accepting-values dialogs still appear in > the interactor. I use the latest McCLIM CVS sources. Did you change the call TO ACCEPTING-VALUES in the macro ACCEPTING-VALUES-WITH-STYLE-AND-TITLE (and a recompile of the whole file)? ACCEPTING-VALUES-WITH-STYLE-AND-TITLE is only used for the *output* of the commands COM-SHOW-TOWN-INFO and COM-GET-DISTANCE. And that did not work for you? I just grabbed a fresh cvs checkout and it worked for me. If you want the accepting-values dialogs of the partial-command-parser (i.e. if you click in the menu on "Show Town Info" or "Get Distance") to appear in a new window, you have to change the :own-window argument of that call. It is burried in MAKE-PARTIAL-PARSER-FUN in mcclim/commands.lisp, try this patch: -- zipp -- --- commands.lisp_old 2005-08-26 15:06:27.370372680 +0200 +++ commands.lisp 2005-08-26 15:06:29.218091784 +0200 @@ -755,7 +755,7 @@ ,command-table :errorp nil)) ,@(mapcar #'list required-arg-names original-args)) - (accepting-values (,stream) + (accepting-values (,stream :own-window t) (format ,stream "You are being prompted for arguments to ~S~%~%" ,command-line-name) -- zapp -- There seems to be no simple way to just change the default for a single application frame. The right way seems to be to modify the application-frame's top-level with something like (:top-level (default-frame-top-level :partial-command-parser ..) in one's DEFINE-APPLICATION-FRAME. But that seems to be a lot of work as the default, COMMAND-LINE-READ-REMAINING-ARGUMENTS-FOR-PARTIAL-COMMAND, calls the partial-command-parsers that are created via mentioned MAKE-PARTIAL-PARSER-FUN when the commands of the application are defined (DEFINE-..-COMMAND -> DEFINE-COMMAND -> %DEFINE-COMMAND).. Bye, Max -- Max-Gerd Retzlaff For your amusement: Scientists will study your brain to learn more about your distant cousin, Man. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From amoroso at mclink.it Fri Aug 26 14:51:32 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 26 Aug 2005 16:51:32 +0200 Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp References: <20050826003258.9D6348855C@common-lisp.net> <8764ts5342.fsf@plato.moon.paoloamoroso.it> <20050826131315.GA20514@mgr.home> Message-ID: <87hddckayz.fsf@plato.moon.paoloamoroso.it> Max-Gerd Retzlaff writes: > Did you change the call TO ACCEPTING-VALUES in the macro > ACCEPTING-VALUES-WITH-STYLE-AND-TITLE (and a recompile of the whole file)? Doh, I din't notice it was commented out. Now it works, but when I execute the command: > Show Town Info ( Which town? ) Berlin the dialog does appear in a different window. But when I dismiss it with OK or Cancel, I get this error: In method #: No next method for arguments (# NIL). [Condition of type PCL::NO-NEXT-METHOD-ERROR] Restarts: 0: [CONTINUE] Try again. 1: [ABORT ] Return to application command loop 2: Return to Top-Level. Debug (type H for help) ("DEFMETHOD NO-NEXT-METHOD (STANDARD-GENERIC-FUNCTION STANDARD-METHOD)" # # # # ...) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:pcl/braid.lisp. 0] backtrace 0: ("DEFMETHOD NO-NEXT-METHOD (STANDARD-GENERIC-FUNCTION STANDARD-METHOD)" # # # # ...) 1: ((FLET #:G19 TOWN-EXAMPLE::COM-SHOW-TOWN-INFO))[:CLEANUP] 2: (TOWN-EXAMPLE::COM-SHOW-TOWN-INFO #) 3: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME)) (#() . #(# # # # # ...)) # # (:PROMPT #)) 4: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G4395)" # # # (:PROMPT #)) 5: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME)) (#(20) . #()) # # #) 6: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) (CLIM:APPLICATION-FRAME)) (#(16 15) . #(#)) #S(PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL (# . #) :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # NIL) 7: (INTERACTIVE-EVAL (TOWN-EXAMPLE:RUN)) 8: (LISP::%TOP-LEVEL) 9: ((LABELS LISP::RESTART-LISP SAVE-LISP)) 0] I am using CMUCL Snapshot 2005-08 (19B) with the latest McCLIM CVS sources. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From m.retzlaff at gmx.net Fri Aug 26 15:41:23 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 26 Aug 2005 17:41:23 +0200 Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp In-Reply-To: <87hddckayz.fsf@plato.moon.paoloamoroso.it> References: <20050826003258.9D6348855C@common-lisp.net> <8764ts5342.fsf@plato.moon.paoloamoroso.it> <20050826131315.GA20514@mgr.home> <87hddckayz.fsf@plato.moon.paoloamoroso.it> Message-ID: <20050826154123.GA22105@mgr.home> Hello On Fri, Aug 26, 2005 at 04:51:32PM +0200, Paolo Amoroso wrote: > > Show Town Info ( Which town? ) Berlin > > the dialog does appear in a different window. But when I dismiss it > with OK or Cancel, I get this error: > > In method > #: > No next method for arguments > (# NIL). > [Condition of type PCL::NO-NEXT-METHOD-ERROR] That does not happen on sbcl. The last line of climi::close in panes.lisp, the call (call-next-method) is the problem, as currently there is no such next method. The following patch helps but I'll not commit it as there might be such a method in the future. See http://meme.b9.com/~1a49f9d55ce30a6e18177a45~/cview.html?channel=lisp&date=050826#hour16 (The relevant part starts at 16:21:44 (17:21 in my timezone).) -- zipp -- --- panes.lisp.~1.154.~ 2005-08-25 23:22:10.000000000 +0200 +++ panes.lisp 2005-08-26 17:36:44.597545784 +0200 @@ -2520,8 +2520,7 @@ (declare (ignore abort)) (let ((frame (pane-frame stream))) (when frame - (disown-frame (frame-manager frame) frame))) - (call-next-method)) + (disown-frame (frame-manager frame) frame)))) (define-application-frame a-window-stream (standard-encapsulating-stream standard-extended-input-stream -- zapp -- Bye, Max -- Max-Gerd Retzlaff For your amusement: If you wish to live wisely, ignore sayings -- including this one. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.retzlaff at gmx.net Fri Aug 26 18:50:37 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 26 Aug 2005 20:50:37 +0200 Subject: [mcclim-devel] with-output-as-gadget, again Message-ID: <20050826185037.GB21737@mgr.home> Hello, I've tried to get with-output-as-gadget working but I was not successful. The problem being that I have not understood recording and several further parts of CLIM, yet. In this mail I want to present my observation about the problem, in the hope that someone with more experience and knowledge might see a solution. I would really like to have it working for a file selector that I need for several projects. Christophe reported the problem already in July: http://common-lisp.net/pipermail/mcclim-devel/2005-July/004100.html You might want to read that mail first. Basically the panes of the whole gadget are only adopted to the stream's sheet (stream being the stream that is given as an argument to the call of WITH-OUTPUT-AS-GADGET) when the output-record of the sheet is replayed (or what is the right term?). The adoption happens via note-output-record-got-sheet method calls that are made when output-records about "parent/child-relationships" are processed; there is specialization on (record gadget-output-record) for that method, in which the adoption takes place. The problem is that the output methods of the clx-backend (window-clear-area (called from window-clear), medium-draw-text* (called from write-string), .. ) try to access the native-transformation (and later native-region) of the gadget's panes quite early, and that does not work if the panes are not yet adopted. Either the adoption has to happen earlier, or the clx output method have to be delayed via output-records as well. I suspect that the clx backend needs an general overhaul to make it be (more) "output-recording aware". But perhaps a single, deliberately inserted line would work a miracle.. Consider Christophe's example: (clim:with-output-as-gadget (*standard-output*) (clim:with-look-and-feel-realization ((clim:frame-manager clim:*application-frame*) clim:*application-frame*) (clim:labelling (:label "Hello") (clim:make-pane 'clim:text-field :activate-callback (lambda (g) (princ (clim:gadget-value g))))))) The flow to the error NO-APPLICABLE-METHOD on sheet-native-transformation when called with an argument of NIL is: In WITH-OUTPUT-AS-GADGET a instance of 'GADGET-OUTPUT-TYPE is created (with the evaluated body of the call as its :child argument). There is a initialize-instance :after method for instances of this class, in which ALLOCATE-SPACE for the child (the label-pane) is called. ALLOCATE-SPACE calls MOVE-SHEET for the first child of the label-pane (the text-field-pane). MOVE-SHEET SETFs the SHEET-TRANSFORMATION of the text-field-pane. There is a method (setf sheet-transformation) :after (transformation (sheet basic-sheet)). It calls (note-sheet-transformation-changed sheet), which calls UPDATE-MIRROR-GEOMETRY. Inside UPDATE-MIRROR-GEOMETRY (sheet-native-transformation (sheet-parent sheet)) is called, but as the sheet is not adopted yet, that gives nil and sheet-native-transformation is not defined for nil. => NO-APPLICABLE-METHOD on sheet-native-transformation when called with an argument of NIL It is quite the same for simpler examples where the WRITE-STRING is called with a pane of the gadget as output stream. There it is: WRITE-STRING -> %WRITE-STRING -> .. -> MEDIUM-DRAW-TEXT* -> (sheet-native-transformation (medium-sheet medium)) Inside sheet-native-transformation the same function is called again for the sheet-parent. As the sheet is not adopted yet, that gives nil and sheet-native-transformation is not defined for nil. Naively, I tried something like: (let ((my-stream (find-pane-named *application-frame* 'clim-listener::interactor))) (replay (STREAM-CURRENT-OUTPUT-RECORD my-stream) my-stream)) right after WITH-OUTPUT-AS-GADGET and before the WRITE-STRING, in the hope that this would force recorded adoption records to take place earlier. Is this completely wrong, should it have been replay-output-record instead? Well, it would only be an ugly workaround at it doesn't help against the problems with labelling and scrolling. I could confirm my assumption that the delayed adoption is the problem as with neatly placed calls to SHEET-ADOPT-CHILD and SHEET-DISOWN-CHILD I got my file-selector kind of running (only the first ACCEPTING-VALUES iteration draws correctly and there is no scrolling for the embedded pane: http://bl0rg.net/~mgr/flux/file-selector-dialog.png (In the end it should become a accept method for pathname presentations in gadget-dialog-view.) There are additional problem when the stream for WITH-OUTPUT-AS-GADGET is an ACCEPTING-VALUES-STREAM: When attempting to read the slot's value (slot-value), the slot CLIM-INTERNALS::HEIGHT is missing from the object #. [Condition of type SIMPLE-ERROR] It would be especially nice to get this running as well.. Regards, Max -- Max-Gerd Retzlaff For your amusement: I don't make the rules, Gil, I only play the game. -- Cash McCall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.retzlaff at gmx.net Mon Aug 29 21:28:50 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Mon, 29 Aug 2005 23:28:50 +0200 Subject: [mcclim-devel] Drawing xpm-icons to an accepting-values-steram Message-ID: <20050829212850.GA11859@mgr.home> Hello, This: (defun test (&key (stream *query-io*)) (accepting-values (stream) (clim-listener::draw-icon stream (clim-listener::icon-of #p"/non-existing")))) does not work. It only draws a black box in the size of the icon. Any ideas? Regards, Max -- Max-Gerd Retzlaff For your amusement: The perversity of nature is nowhere better demonstrated by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.retzlaff at gmx.net Tue Aug 30 00:26:01 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Tue, 30 Aug 2005 02:26:01 +0200 Subject: [mcclim-devel] current CVS McCLIM broken? Message-ID: <20050830002601.GA13988@mgr.home> Hello, I've just got a fresh CVS checkout und built a new sbcl core with mcclim, mcclim-freetype, mcclim-examples, clouseau, clim-listener, swank-loader, and the clim-debugger. Sadly, if I start sbcl with this core and call the clim-listener I get: -- zipp -- $ sbcl --core new-sbcl-asdf-install-clim-listener-clouseau-slime-swank-clim-debugger.core This is SBCL 0.9.1.65, an implementation of ANSI Common Lisp. More information about SBCL is available at . SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (clim-listener::run-listener) debugger invoked on a TYPE-ERROR in thread 3085365376: The value # is not of type (OR XLIB:FONT XLIB:GCONTEXT). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT ] Return to application command loop 1: [RETURN-TO-LISTENER] Return to listener. 2: Exit debugger, returning to top level. (XLIB:TEXT-EXTENTS # "mgr") 0] -- zapp -- Note that my SBCL is about two months old but that was no problem until recently (my last test was slightly more than one week ago). Bye, Max PS: If you want to know, I usually build new cores with this command: sbcl --core /usr/local/lib/sbcl/sbcl.core_org --userinit ~/.sbclrc_core-dumping --eval '(progn (require :mcclim) (require :mcclim-freetype) (require :clim-examples) (require :clouseau) (require :clim-listener) (load #p"lispdir:slime;swank-loader") (load (merge-pathnames "Apps/Debugger/clim-debugger" (truename #p"lispdir:site;mcclim"))) (save-lisp-and-die "new-sbcl-asdf-install-clim-listener-clouseau-slime-swank-clim-debugger.core"))' ~/.sbclrc_core-dumping is the following; it sets up my ASDF: -- zipp -- ;;; -*- Mode: LISP -*- (setf (logical-pathname-translations "coding") '(("**;*.*.*" #P"/home/mgr/daten/coding/lisp/**/*.*"))) (setf (logical-pathname-translations "sbcldir") '(("**;*.*.*" #P"/usr/src/lisp/sbcl/**/*.*"))) (setf (logical-pathname-translations "lispdir") '(("**;*.*.*" #P"/usr/src/lisp/**/*.*"))) ;; (setf (logical-pathname-translations "lispdir") ;; `(("lispdir:**;*.*.*" ;; ,(make-pathname :directory ;; '(:absolute "usr" "src" "lisp" :wild-inferiors) ;; :name :wild :type :wild :version :wild)))) (require 'asdf) (push #p"lispdir:systems;" asdf:*central-registry*) (push #p"sbcldir:systems;" asdf:*central-registry*) (push #p"coding:systems;" asdf:*central-registry*) (require 'asdf-install) (setf ASDF-INSTALL:*LOCATIONS* '((#p"coding:site;" #p"coding:systems;" "coding ASDF directory") (#p"lispdir:site;" #p"lispdir:systems;" "shared ASDF directory") (#p"sbcldir:site;" #p"sbcldir:systems;" "SBCL ASDF directory"))) -- zapp -- -- Max-Gerd Retzlaff For your amusement: I will make you shorter by the head. -- Elizabeth I -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.retzlaff at gmx.net Tue Aug 30 02:38:13 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Tue, 30 Aug 2005 04:38:13 +0200 Subject: [mcclim-devel] a new File Selector, patches for the CLIM-Listener, and a general problem with ACCEPT Message-ID: <20050830023813.GA15020@mgr.home> Hello, My File Selector is completed. The source code is attached. New versions will be available at http://bl0rg.net/~mgr/flux/file-selector.lisp You'll *have* to apply the also the following patch for the CLIM-Listener (attached and at http://bl0rg.net/~mgr/flux/CLIM-Listener.patch ). This patch mandatory as the File Selector will not work correctly without it. (More below.) Also you'll need a quite new CVS version of McCLIM. That is after 00:39:32 CEST of today... Screenshots: http://bl0rg.net/~mgr/flux/File-Selector-in-its-own-window-1.0.png and http://bl0rg.net/~mgr/flux/File-Selector-embedded-into-the-Clim-Listener-1.0.png (Note in the second screenshot that, although only "syntax" is specified as Filename, "syntax.fasl" is selected (i.e. will be returned if one clicks on OK). This is because "fasl" is the current Filetype and there is no file "syntax" (without the extension). I hope I've got other minor details right, as well.) Problem with ACCEPT: There is a general problem regarding ACCEPT and its parameter :DEFAULT. The clim 2.0 spec says in the section about ACCEPT-1: If default is supplied, then it and default-type are returned as values from accept-1 when the input is empty. In McCLIM there is currently no way to specify "" in an ACCEPT with :DEFAULT (that is non-equal to ""), as "" is considered to be "empty". (If you enter nothing or explicitely "" to a promt of an ACCEPT outside an ACCEPTING-VALUES the default value will be returned; inside an ACCEPTING-VALUES dialog a text-field will be displayed in which "" is normally not displayed, unnecessary to say that in that case the specified default is also returned.) Even worse, there is *no way* to distinguish between the cases that the user left the default untouched and he or she removed the content of the field completely. No third return value for that. Quite inconvenient! It would also be inconvenient to have to enter "" for the empty string. There is no keyword :ONLY-INSERT-DEFAULT. That would be the behaviour that I want: The default is only inserted into the field but whatever is there after the user edited the field will be the return value of the ACCEPT call, *untouched*. The clim 2.0 specification seems to supply no way to do this! As a workaround I can only think of a button "empty the field" right next to each accept text-field. I really hope I missed something. This means for the File Selector that you cannot empty a formerly speciefied Filename of Filetype again *by editing the text-field*. To empty those textfields just left-click on a directory for the Filename, and middle-click for the Filetype. The "Parent Directory" and the pathname in the title of the directory listing always work for this. It would be very nice if somebody had a closer look at CLIMI::HANDLE-EMPTY-INPUT, CLIMI::INVOKE-HANDLE-EMPTY-INPUT, and friends. More information on the patch to the CLIM-Listener I hope Andy Hefner likes the patch. It adds : - sort-by for filenames to COM-SHOW-DIRECTORY, - an icon and a cond-clause in ICON-OF for wild pathnames, - a wrapper for LIST-DIRECTORY (that NCONCs the subdirectories of the directory to the output of LIST-DIRECTORY if it is called with a wild pathname), - and does some minor changes to COM-SHOW-DIRECTORY. Also it removes the SB-POSIX LIST-DIRECTORY for SBCL as that one completely ignores the pathname-name and -type, which renders it quite useless for :wild searches (pune or play on words intended). Comments are welcome, of course. Hope you like it, Max -- Max-Gerd Retzlaff For your amusement: Chance is perhaps the work of God when He did not want to sign. -- Anatole France -------------- next part -------------- diff -Naur Listener_org/dev-commands.lisp Listener_mgr/dev-commands.lisp --- Listener_org/dev-commands.lisp 2005-04-21 05:41:24.000000000 +0200 +++ Listener_mgr/dev-commands.lisp 2005-08-30 01:41:33.895740000 +0200 @@ -1028,7 +1028,9 @@ (terpri stream)) (defun sort-pathnames (list sort-by) - list) ; <--- FIXME + (case sort-by ; <--- FIXME + ('name (sort list #'string-lessp :key #'file-namestring)) + (t list))) (defun split-sort-pathnames (list group-dirs sort-by) (mapcar (lambda (x) (sort-pathnames x sort-by)) @@ -1064,7 +1066,7 @@ :provide-output-destination-keyword t) ((pathname 'pathname #+nil(or 'string 'pathname) :prompt "pathname") &key - #+NIL (sort-by '(member name size modify none) :default 'name) + (sort-by '(member name size modify none) :default 'name) (show-hidden 'boolean :default nil :prompt "show hidden") (hide-garbage 'boolean :default T :prompt "hide garbage") (show-all 'boolean :default nil :prompt "show all") @@ -1075,20 +1077,22 @@ (let* ((pathname (if (wild-pathname-p pathname) ; Forgot why I did this.. (merge-pathnames pathname) pathname)) - (dir (list-directory (gen-wild-pathname pathname)))) + (dir (list-directory-with-all-subdirectories (gen-wild-pathname pathname)))) (with-text-family (T :sans-serif) (invoke-as-heading (lambda () (format T "Directory contents of ") - (present pathname))) + (present (directory-namestring pathname) 'pathname) + (when (pathname-type pathname) + (format T " (only files of type ~a)" (pathname-type pathname))))) (when (parent-directory pathname) - (with-output-as-presentation (T (parent-directory pathname) 'clim:pathname) + (with-output-as-presentation (T (strip-filespec (parent-directory pathname)) 'clim:pathname) (draw-icon T (standard-icon "up-folder.xpm") :extra-spacing 3) (format T "Parent Directory~%"))) - (dolist (group (split-sort-pathnames dir group-directories :none #+NIL sort-by)) + (dolist (group (split-sort-pathnames dir group-directories sort-by)) (unless show-all (setf group (filter-garbage-pathnames group show-hidden hide-garbage))) (ecase style @@ -1105,7 +1109,8 @@ (goatee::reposition-stream-cursor *standard-output*) (vertical-gap T)) (list (dolist (ent group) - (let ((ent (merge-pathnames ent pathname))) ; This is for CMUCL, see above. (fixme!) + (let ((ent (merge-pathnames ent pathname))) ;; This is for CMUCL, see above. (fixme!) + ;; And breaks some things for SBCL.. (mgr) (pretty-pretty-pathname ent *standard-output* :long-name full-names))))))))) #+nil ; OBSOLETE diff -Naur Listener_org/file-types.lisp Listener_mgr/file-types.lisp --- Listener_org/file-types.lisp 2003-11-09 22:12:05.000000000 +0100 +++ Listener_mgr/file-types.lisp 2005-08-29 19:27:12.374781000 +0200 @@ -133,7 +133,8 @@ ;; ICON-OF is measurably slow here in CMUCL. Interesting.. (defmethod icon-of ((pathname pathname)) - (cond ((not (probe-file pathname)) (standard-icon "invalid.xpm")) + (cond ((wild-pathname-p pathname) (standard-icon "wild.xpm")) + ((not (probe-file pathname)) (standard-icon "invalid.xpm")) ((directoryp pathname) *folder-icon*) ;; FIXME: use inode mime types (T (let ((mime-class (find-class (pathname-mime-type pathname) nil))) (if mime-class diff -Naur Listener_org/icons/CVS/Root Listener_mgr/icons/CVS/Root --- Listener_org/icons/CVS/Root 2005-08-30 00:19:14.250680000 +0200 +++ Listener_mgr/icons/CVS/Root 2005-01-12 17:54:07.000000000 +0100 @@ -1 +1 @@ -:ext:mretzlaff at common-lisp.net:/project/mcclim/cvsroot +:pserver:anonymous at common-lisp.net:/project/mcclim/cvsroot diff -Naur Listener_org/icons/wild.xpm Listener_mgr/icons/wild.xpm --- Listener_org/icons/wild.xpm 1970-01-01 01:00:00.000000000 +0100 +++ Listener_mgr/icons/wild.xpm 2005-08-29 16:50:18.287100000 +0200 @@ -0,0 +1,114 @@ +/* XPM */ +static char * wild_xpm[] = { +"16 16 95 2", +" c None", +". c #484848", +"+ c #4A4A4A", +"@ c #494949", +"# c #474747", +"$ c #4B4B4B", +"% c #E1E1E1", +"& c #E9E9E9", +"* c #E7E7E7", +"= c #DFDFDF", +"- c #D5D5D5", +"; c #505050", +"> c #707070", +", c #D4D4D4", +"' c #E3E3E3", +") c #F0F0F0", +"! c #F2F2F2", +"~ c #F1F1F1", +"{ c #EBEBEB", +"] c #D3D3D3", +"^ c #B1B1B1", +"/ c #5D5D5D", +"( c #D6D6D6", +"_ c #DBDBDB", +": c #EEEEEE", +"< c #F0EDED", +"[ c #F2D7D7", +"} c #EDEDED", +"| c #C0C0C0", +"1 c #A1A1A1", +"2 c #565656", +"3 c #E4E4E4", +"4 c #FBF4F4", +"5 c #FEFEFE", +"6 c #FEE5E5", +"7 c #FF3D3D", +"8 c #FFFFFF", +"9 c #FDFAFA", +"0 c #D0D0D0", +"a c #B5B5B5", +"b c #9D9D9D", +"c c #E5E5E5", +"d c #EFEFEF", +"e c #FE7A7A", +"f c #FFB8B8", +"g c #FFE5E5", +"h c #FF7A7A", +"i c #C3C3C3", +"j c #A4A4A4", +"k c #F1EFEF", +"l c #FEADAD", +"m c #FF5050", +"n c #FF5757", +"o c #FDADAD", +"p c #E5E3E3", +"q c #C9C9C9", +"r c #ABABAB", +"s c #FAFAFA", +"t c #FECCCC", +"u c #FF4646", +"v c #FDFDFD", +"w c #ACACAC", +"x c #E0E0E0", +"y c #EDEAEA", +"z c #FE7979", +"A c #FE4444", +"B c #FF8787", +"C c #FF4444", +"D c #DFDDDD", +"E c #C5C5C5", +"F c #D7D7D7", +"G c #FFE9E9", +"H c #FFEAEA", +"I c #FEB0B0", +"J c #BEBEBE", +"K c #A7A7A7", +"L c #DCDCDC", +"M c #FBFBFB", +"N c #FDE9E9", +"O c #FE5D5D", +"P c #FAE6E6", +"Q c #F9F9F9", +"R c #CACACA", +"S c #B3B3B3", +"T c #A0A0A0", +"U c #B2B2B2", +"V c #E8E8E8", +"W c #B9B9B9", +"X c #A3A3A3", +"Y c #BABABA", +"Z c #CBCBCB", +"` c #D2D2D2", +" . c #C8C8C8", +".. c #B8B8B8", +"+. c #A9A9A9", +" . + + @ + + @ ", +" # $ % & & & * = - ; # ", +" # > , ' ) ! ! ~ { ] ^ / + ", +" @ ( _ { : < [ < } = | 1 2 ", +"# 3 3 & 4 5 6 7 6 8 9 0 a b @ ", +"+ c ! d e f g 7 g f h _ i j + ", +"+ c ! k l m n 7 n m o p q r + ", +"+ ' ! ) s t u 7 u t v 3 q w + ", +"# x : y z A B 7 B C z D E w + ", +"$ F & * o G 6 7 6 H I ( J K + ", +". , 0 L : M N O P Q { R S T + ", +" + U i ( = V * 3 L 0 W X 2 ", +" + / X Y Z ` , ` ...j / + ", +" + + T +.^ S ^ r 1 + + ", +" + + + + + + + ", +" "}; diff -Naur Listener_org/util.lisp Listener_mgr/util.lisp --- Listener_org/util.lisp 2005-02-22 04:10:27.000000000 +0100 +++ Listener_mgr/util.lisp 2005-08-30 01:43:56.829011000 +0200 @@ -118,6 +118,8 @@ #+SBCL (defun list-directory (pathname) + (directory pathname) + #+nil ;; ugh. is too ughy. (mgr) (let* ((pathname (strip-filespec pathname)) ;; ugh. (dir (sb-posix:opendir pathname)) (list nil)) @@ -141,6 +143,19 @@ (defun list-directory (pathname) (directory pathname)) +;;; Calls LIST-DIRECTORY and appends the subdirectories of the directory +;;; PATHNAME to the output of LIST-DIRECTORY if PATHNAME is a wild pathname. + +(defun list-directory-with-all-subdirectories (pathname) + (let ((file-list (list-directory pathname))) + (if (wild-pathname-p pathname) + (nconc file-list + (delete-if (lambda (directory) + (member directory file-list :test #'equal)) + (delete-if-not #'directoryp + (list-directory (gen-wild-pathname + (strip-filespec pathname)))))) + file-list))) ;;; A farce of a "portable" run-program, which grows as I need options from ;;; the CMUCL run-program. -------------- next part -------------- ;;; -*- Mode: Lisp; Syntax: Common-Lisp; Package: FILE-SELECTOR; -*- ;;; --------------------------------------------------------------------------- ;;; Title: A File Selector for the Common Lisp Interface Manager ;;; Comment: Written for the CLIM implementation McCLIM and uses some ;;; at least one function that is not in the CLIM 2.0 specification. ;;; Needs the CLIM Listener by Andy Hefner (included in McCLIM ;;; and :com.gigamonkeys.pathnames by Peter Seibel ;;; Usage: Compile and load the file, and call (file-selector:select-file). ;;; Created: 2005-08-30, Version 1.0 (same date) ;;; Author: Max-Gerd Retzlaff , http://bl0rg.net/~mgr ;;; --------------------------------------------------------------------------- ;;; (c) copyright 2005 by Max-Gerd Retzlaff (in-package :cl-user) (eval-when (:load-toplevel :compile-toplevel :execute) (asdf:oos 'asdf:load-op :pathnames)) (defpackage :file-selector (:use :clim :clim-lisp) (:import-from :clim-listener :com-show-directory :draw-icon :icon-of :pathname-printing-name) (:import-from :com.gigamonkeys.pathnames :pathname-as-directory) ;; :pathname-as-file :list-directory) (:export :select-file)) (in-package :climi) ;;; This is rather ugly. But right now named panes are pushed onto the slot ;;; FRAME-NAMED-PANES of the frame (in an :around method to make-pane-1 in frames.lisp) ;;; and *never* removed. Not nice, as the File Selector makes temporary panes that are ;;; nevertheless named. Even more ugly as they get the same name on every call of the ;;; File Selector. Apart from the accumulation of unused panes, which pane will be ;;; returned if I call (find-pane-named *application-frame* 'files) and there are ;;; several panes with this name? Therefore the panes are right now manually removed ;;; by the following function. (defun forget-named-pane (pane &optional (frame *application-frame*)) (setf (frame-named-panes frame) (delete pane (frame-named-panes frame)))) (in-package :file-selector) (defparameter *the-pathname* nil) (defparameter *the-pathname-type* nil) ;;; custom command-table for the accepting-values dialog (define-command-table file-selector-commands :inherit-from (climi::accepting-values) );; :inherit-menu t) ;;; present an pathname in textual-dialog-view (define-presentation-method present (object (type pathname) stream (view textual-dialog-view) &key acceptably for-context-type) (declare (ignore acceptably for-context-type)) (let ((pathname object) (long-name t)) (let ((icon (clim-listener::icon-of pathname))) (when icon (clim-listener::draw-icon stream icon :extra-spacing 30))) (princ (clim-listener::pathname-printing-name pathname long-name) stream))) ;;;; completion does not work as desired, therefore this isn't used anymore ;;; ;;; (clim:define-presentation-type file-namestring ()) ;;; ;;; (define-presentation-method present (object (type file-namestring) stream view &key) ;;; (write-string object stream)) ;;; ;;; (define-presentation-method accept ((type file-namestring) stream view &key) ;;; (values ;suppress values after the first ;;; (multiple-value-bind (object success string) ;;; (completing-from-suggestions (Stream :partial-completers '(#\- #\. #\Space #\_) :allow-any-input t) ;;; (mapcar (lambda (args) ;;; (apply #'suggest args)) ;;; (mapcar (lambda (pathname) ;;; (let ((pathname (com.gigamonkeys.pathnames::pathname-as-file pathname))) ;;; (list ;;; (file-namestring pathname) ;;; (file-namestring pathname)))) ;;; (com.gigamonkeys.pathnames::list-directory *the-pathname*)))) ;;; (declare (ignore success object)) ;;; string))) ;;; ;;; (define-presentation-translator pathname-to-file-namestring-translator ;;; (pathname file-namestring file-selector-commands ;;; :gesture :describe) ;;; (object) ;;; (file-namestring object)) ;;; :select gesture (left-click) selects a pathname (define-presentation-to-command-translator select-pathname-command-translator (pathname climi::com-deselect-query file-selector-commands :gesture :select :documentation "Select this as pathname" :pointer-documentation "Select this as pathname") (object) (setf *the-pathname* object) nil) ;;; :describe gesture (middle-click) sets a pathname-type filter (define-presentation-to-command-translator select-pathname-type-command-translator (pathname climi::com-deselect-query file-selector-commands :gesture :describe :documentation ((object stream) (let ((type (pathname-type object))) (if type (format stream "Show only files with type ~a" type) (format stream "Show files of any type")))) :pointer-documentation ((object stream) (let ((type (pathname-type object))) (if type (format stream "Show only files with type ~a" type) (format stream "Show files of any type"))))) (object) (setf *the-pathname-type* (pathname-type object)) nil) ;;;; garbage that I don't want to dispose yet ;;; ;;; (clim:define-presentation-type file-type () :inherit-from 'define) ;;; ;;; (string-presentation-translator pathname-to-file-type-translator ;;; (pathname file-type file-selector-commands ;;; :gesture :describe) ;;; (object) ;;; (pathname-type object)) ;;; ;;; ;;; (define-presentation-method accept ((type pathname) stream (view textua-dialog-view) &key) ;;; (values ;suppress values after the first ;;; ;;; provide completion over the names of the towns ;;; (completing-from-suggestions (Stream :partial-completers '(#\- #\. #\Space)) ;;; (mapcar (lambda (args) ;;; (apply #'suggest args)) ;;; (mapcar (lambda (pathname) ;;; (list (let ((pathname (com.gigamonkeys.pathnames::pathname-as-file pathname))) ;;; (file-namestring pathname)) ;;; pathname)) ;;; (com.gigamonkeys.pathnames::list-directory *default-pathname-defaults*)))))) ;;; MAIN FUNCTION ;;; ;;; You can append parameters for the call to CLIM-LISTENER::COM-SHOW-DIRECTORY, as in: ;;; (file-selector:select-file :own-window t :pathname-type "lisp" :style 'list) (defun select-file (&rest args-for-com-show-directory ;; Don't forget to update own-args-of-select-file! &key (stream *query-io*) (own-window nil) (pathname *default-pathname-defaults*) pathname-type return-even-a-directory &allow-other-keys) (let ((own-args-of-select-file '(:stream :own-window :pathname :pathname-type :return-even-a-directory)) parent children typed-pathname (*pointer-documentation-output* *pointer-documentation-output*) old-wild-directory) (setf *the-pathname* pathname *the-pathname-type* pathname-type) (unwind-protect (accepting-values (stream :initially-select-query-identifier 'tag :own-window own-window :command-table 'file-selector-commands :label "File Selector" :resynchronize-every-pass t) ;; get the gloval values (that might be changed by the presentation to command translators) (setf pathname *the-pathname* pathname-type *the-pathname-type*) (unless children ;; determine the parent sheet (setf parent (sheet-parent (if own-window stream (let ((scroller-pane (pane-scroller (climi::encapsulating-stream-stream stream)))) ;; if parent is a scroller-pane return the scroller-pane (if scroller-pane ;; if parent is a border-pane return the border-pane (or (climi::pane-border scroller-pane) scroller-pane) stream))))) ;; remember children (setf children (sheet-children parent)) ;; ... and disown them (dolist (child children) (sheet-disown-child parent child)) ;; construct new pane hierarchy (let ((fm (frame-manager *application-frame*))) (with-look-and-feel-realization (fm *application-frame*) (sheet-adopt-child parent (make-pane 'vrack-pane :name 'main-container :contents (append (list `(+fill+ ,(make-clim-application-pane ;; :scroll-bars :both :NAME 'files :HEIGHT 150)) (make-pane 'vrack-pane :name 'children-container :contents children :height 200)) (when own-window ;; pointer-doc only in own-window (list (make-pane 'pointer-documentation-pane :name 'pointer-doc)))))))) ;; capture *pointer-documentation-output* (when own-window (setf *pointer-documentation-output* (find-pane-named *application-frame* 'pointer-doc))) (change-space-requirements parent)) ;; add pathname-type as type to the pathname if appropriate (setf typed-pathname (if (and (not (and (not (wild-pathname-p pathname)) (probe-file pathname))) (pathname-name pathname) (not (pathname-type pathname))) (make-pathname :type pathname-type :defaults pathname) pathname)) ;; show listing of the directory in the files pane (let* ((*standard-output* (find-pane-named *application-frame* 'files)) (directory (directory-namestring pathname)) (wild-directory (if pathname-type (make-pathname :name :wild :type pathname-type :defaults (directory-namestring pathname)) (pathname directory)))) (unless (equal old-wild-directory wild-directory) ;; reprint necessary? (window-clear *standard-output*) (if (probe-file directory) (let ((args-for-com-show-directory (climi::remove-keywords args-for-com-show-directory own-args-of-select-file))) (apply #'clim-listener::com-show-directory wild-directory args-for-com-show-directory)) (progn (format t "~&The directory ") (present directory 'pathname) (format t " does not exist."))) (change-space-requirements *standard-output*)) (setf old-wild-directory wild-directory)) ;; present the currently selected pathname (format stream "~%Currently selected: ") ;; (present typed-pathname 'pathname :stream stream) ;; doesn't work for an accepting-values stream :( (present (namestring typed-pathname) 'pathname :stream stream :view +textual-view+) (princ #\newline stream) (princ #\newline stream) ;; accept text-field for the pathname components (setf ;; pathname ;; (accept '((pathname) :default-type pathname-type) :default pathname :stream stream ;; :query-identifier 'tag) pathname (let ((file-namestring (parse-namestring (accept 'string #+nil 'file-namestring :default (file-namestring pathname) :prompt "Filename" :stream stream :query-identifier 'tag)))) (make-pathname :name (pathname-name file-namestring) ;; merge-pathnames wouldn't work for "" :type (pathname-type file-namestring) :defaults pathname)) pathname (let ((difference-pathname (com.gigamonkeys.pathnames:pathname-as-directory (accept 'string :default (directory-namestring pathname) :prompt "Directory" :stream stream)))) (if (equal #p"" difference-pathname) #p"" (merge-pathnames difference-pathname pathname))) pathname-type (let ((type (accept 'string :default (or pathname-type "") :stream stream :prompt "Filetype"))) (if (string= type "") nil type))) (setf *the-pathname* pathname *the-pathname-type* pathname-type) ) ;; of ACCEPTING-VALUES ;; reconstruct original pane hierarchy (only if embedded) (unless own-window ;; disown children (dolist (child (sheet-children (find-pane-named *application-frame* 'children-container))) (sheet-disown-child (find-pane-named *application-frame* 'children-container) child)) ;; disown the main container of the File Selector (sheet-disown-child parent (find-pane-named *application-frame* 'main-container)) ;; adopt remembered children to their former parent (let ((fm (frame-manager *application-frame*))) (with-look-and-feel-realization (fm *application-frame*) (dolist (child children) (sheet-adopt-child parent child)))) (change-space-requirements parent)) ;; forget the temporery but nevertheless named panes (argh) (climi::forget-named-pane (find-pane-named *application-frame* 'children-container)) (climi::forget-named-pane (find-pane-named *application-frame* 'files)) (climi::forget-named-pane (find-pane-named *application-frame* 'main-container)) (when own-window (climi::forget-named-pane (find-pane-named *application-frame* 'pointer-doc))) ) ;; of UNWIND-PROTECT ;; return the selected file (if (or (pathname-name pathname) return-even-a-directory) typed-pathname (abort)))) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.retzlaff at gmx.net Tue Aug 30 02:53:57 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Tue, 30 Aug 2005 04:53:57 +0200 Subject: [mcclim-devel] Re: a new File Selector.. In-Reply-To: <20050830023813.GA15020@mgr.home> References: <20050830023813.GA15020@mgr.home> Message-ID: <20050830025357.GB15020@mgr.home> On Tue, Aug 30, 2005 at 04:38:13AM +0200, Max-Gerd Retzlaff wrote: > Hello, > > My File Selector is completed. Oh, I've forgotten to mention that it is no real gadget that will be called when there is an (ACCEPT 'PATHNAME) in the +gadget-dialog-view+ (or other gadget-views). For that WITH-OUTPUT-AS-GADGET would have to work (compare my earlier mail about that). But it is a normal ACCEPTING-VALUES dialog that can be displayed in a seperate, new window or "embedded" into a pane of the host application. Actually it is quite uncomplicated in its use, I think. Right now it inserts a VRACK-PANE in the children slot of the parent's parent and adopts the former children into another VRACK-PANE that is a child of the other VRACK-PANE. (If the parent is embedded into a SCROLLER-PANE it gets the SCROLLER-PANEs parent, if that's again embedded into a BORDER-PANE it gets its parant.) Afterwards, if it was embedded into another pane, the original pane hierarchy is reconstruced. And the temporary panes are forgotten. Apropos forgotton, please have a look at the function FORGET-NAMED-PANE and its comment in the beginning of file-selector.lisp: (in-package :climi) ;;; This is rather ugly. But right now named panes are pushed onto the ;;; slot FRAME-NAMED-PANES of the frame (in an :around method to ;;; make-pane-1 in frames.lisp) and *never* removed. Not nice, as the ;;; File Selector makes temporary panes that are nevertheless named. ;;; Even more ugly as they get the same name on every call of the File ;;; Selector. Apart from the accumulation of unused panes, which pane ;;; will be returned if I call (find-pane-named *application-frame* ;;; 'files) and there are several panes with this name? Therefore the ;;; panes are right now manually removed by the following function. (defun forget-named-pane (pane &optional (frame *application-frame*)) (setf (frame-named-panes frame) (delete pane (frame-named-panes frame)))) Yeah. Regards, Max -- Max-Gerd Retzlaff For your amusement: By protracting life, we do not deduct one jot from the duration of death. -- Titus Lucretius Carus -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From csr21 at cam.ac.uk Tue Aug 30 08:22:01 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 30 Aug 2005 09:22:01 +0100 Subject: [mcclim-devel] current CVS McCLIM broken? In-Reply-To: <20050830002601.GA13988@mgr.home> (Max-Gerd Retzlaff's message of "Tue, 30 Aug 2005 02:26:01 +0200") References: <20050830002601.GA13988@mgr.home> Message-ID: Max-Gerd Retzlaff writes: > sbcl --core /usr/local/lib/sbcl/sbcl.core_org --userinit ~/.sbclrc_core-dumping --eval '(progn (require :mcclim) (require :mcclim-freetype) (require :clim-examples) (require :clouseau) (require :clim-listener) (load #p"lispdir:slime;swank-loader") (load (merge-pathnames "Apps/Debugger/clim-debugger" (truename #p"lispdir:site;mcclim"))) (save-lisp-and-die "new-sbcl-asdf-install-clim-listener-clouseau-slime-swank-clim-debugger.core"))' Can you try making (require :mcclim-freetype) the last thing you do before SAVE-LISP-AND-DIE? At the moment, mcclim-freetype has to redefine various methods in the CLX backend -- and it's possible that the way you're loading it is causing those methods to be redefined back. Certainly your error message is from running the wrong :before method on SETF MEDIUM-TEXT-STYLE, I believe -- compare the version from Backends/CLX/medium.lisp and Experimental/freetype/freetype-fonts.lisp. (Fixing this false dichotomy is high on the list of priorities...) (I have to say also that I can't reproduce what you're seeing on my system) Cheers, Christophe From m.retzlaff at gmx.net Tue Aug 30 11:03:21 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Tue, 30 Aug 2005 13:03:21 +0200 Subject: [mcclim-devel] current CVS McCLIM not broken In-Reply-To: References: <20050830002601.GA13988@mgr.home> Message-ID: <20050830110321.GA21916@mgr.home> Hello On Tue, Aug 30, 2005 at 09:22:01AM +0100, Christophe Rhodes wrote: > Max-Gerd Retzlaff writes: > > > sbcl --core /usr/local/lib/sbcl/sbcl.core_org --userinit ~/.sbclrc_core-dumping --eval '(progn (require :mcclim) (require :mcclim-freetype) (require :clim-examples) (require :clouseau) (require :clim-listener) (load #p"lispdir:slime;swank-loader") (load (merge-pathnames "Apps/Debugger/clim-debugger" (truename #p"lispdir:site;mcclim"))) (save-lisp-and-die "new-sbcl-asdf-install-clim-listener-clouseau-slime-swank-clim-debugger.core"))' > > Can you try making (require :mcclim-freetype) the last thing you do > before SAVE-LISP-AND-DIE? At the moment, mcclim-freetype has to > redefine various methods in the CLX backend -- and it's possible that > the way you're loading it is causing those methods to be redefined > back. Arr, sorry, my fault. I've had a symlink in my asdf:*central-registry* that pointed to the mcclim-freetype.asd of an older mcclim checkout... Sorry for bothering you. Bye, Max -- Max-Gerd Retzlaff For your amusement: Unless you love someone, nothing else makes any sense. -- e.e. cummings -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rpgoldman at real-time.com Tue Aug 30 17:39:00 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 30 Aug 2005 13:39:00 -0400 Subject: [mcclim-devel] ACL70 bug: Ignorable in argument acceptor functions for define-command Message-ID: <17172.39348.550068.474704@lips3.ece.utexas.edu> I find that with allegro version 7.0, McCLIM crashes while compiling. The problem first crops up compiling (define-command (com-query-exit :command-table accepting-values :name nil :provide-output-destination-keyword nil) () (signal 'av-exit)) which macroexpands to: (PROGN (DEFUN COM-QUERY-EXIT () (SIGNAL 'AV-EXIT)) (ADD-COMMAND-TO-COMMAND-TABLE 'COM-QUERY-EXIT 'ACCEPTING-VALUES :NAME NIL :MENU 'NIL :KEYSTROKE 'NIL :ERRORP NIL) (DEFUN COM-QUERY-EXIT%ACCEPTOR%9 (#:STREAM61697) (LET ((#:KEY-RESULTS61698 NIL)) (BLOCK ACTIVATED (FLET ((EAT-DELIMITER-OR-ACTIVATOR NIL (LET ((GESTURE (READ-GESTURE :STREAM #:STREAM61697))) (WHEN (OR (NULL GESTURE) (ACTIVATION-GESTURE-P GESTURE)) (RETURN-FROM ACTIVATED NIL)) (UNLESS (DELIMITER-GESTURE-P GESTURE) (UNREAD-GESTURE GESTURE :STREAM #:STREAM61697))))) (DECLARE (IGNORABLE #'EAT-DELIMITER-OR-ACTIVATOR)) (LET ((GESTURE (READ-GESTURE :STREAM #:STREAM61697 :TIMEOUT 0 :PEEK-P T))) (COND ((AND GESTURE (ACTIVATION-GESTURE-P GESTURE)) (RETURN-FROM ACTIVATED NIL))) NIL))) (LIST* #:KEY-RESULTS61698))) (DEFUN COM-QUERY-EXIT%PARTIAL%8 (#:COMMAND-TABLE61699 #:STREAM61700 #:PARTIAL-COMMAND61701) (DESTRUCTURING-BIND (#:COMMAND-NAME61702) #:PARTIAL-COMMAND61701 (LET ((#:COMMAND-LINE-NAME61703 (COMMAND-LINE-NAME-FOR-COMMAND #:COMMAND-NAME61702 #:COMMAND-TABLE61699 :ERRORP NIL))) (ACCEPTING-VALUES (#:STREAM61700) (FORMAT #:STREAM61700 "You are being prompted for arguments to ~S~%" #:COMMAND-LINE-NAME61703)) (LIST #:COMMAND-NAME61702)))) (DEFUN |COM-QUERY-EXIT%unparser%9| (#:COMMAND61707 #:STREAM61709) (DECLARE (IGNORABLE #:STREAM61709)) (LET* ((#:SEPERATOR61712 #\Space) (#:COMMAND-ARGS61708 (CDR #:COMMAND61707))) (DECLARE (IGNORABLE #:SEPERATOR61712 #:COMMAND-ARGS61708)))) NIL (SETF (GETHASH 'COM-QUERY-EXIT *COMMAND-PARSER-TABLE*) (MAKE-INSTANCE 'COMMAND-PARSERS :PARSER #'COM-QUERY-EXIT%ACCEPTOR%9 :PARTIAL-PARSER #'COM-QUERY-EXIT%PARTIAL%8 :REQUIRED-ARGS 'NIL :KEYWORD-ARGS 'NIL :ARGUMENT-UNPARSER #'|COM-QUERY-EXIT%unparser%9|)) 'COM-QUERY-EXIT) Allegro v 7.0 chokes on (DECLARE (IGNORABLE #'EAT-DELIMITER-OR-ACTIVATOR)) AFAICT, Allegro 7.0 can't compile ignorable declarations applied to constant functions like this. I believe this is an allegro bug, as is suggested by the error message: ; While compiling COM-QUERY-EXIT%ACCEPTOR%0: Error: We don't yet handle ignore of #'EAT-DELIMITER-OR-ACTIVATOR. For now, I was just going to put the following conditional compilation directive in commands.lisp: #-ALLEGRO-V7.0 (declare (ignorable (function eat-delimiter-or-activator))) Any reason not to commit this change? Actually, I'm on vacation, and it may be difficult for me to make this commit for a week or so, so if anyone else would like to, that would be great! R From david at lichteblau.com Tue Aug 30 19:26:12 2005 From: david at lichteblau.com (David Lichteblau) Date: Tue, 30 Aug 2005 21:26:12 +0200 Subject: [mcclim-devel] ACL70 bug: Ignorable in argument acceptor functions for define-command In-Reply-To: <17172.39348.550068.474704@lips3.ece.utexas.edu> References: <17172.39348.550068.474704@lips3.ece.utexas.edu> Message-ID: <20050830192612.GA21309@gargravarr.knowledgetools.de> Quoting rpgoldman at real-time.com (rpgoldman at real-time.com): > AFAICT, Allegro 7.0 can't compile ignorable declarations applied to > constant functions like this. Franz has already fixed that bug in ACL 7.0. (update/pab012.001) d. From csr21 at cam.ac.uk Wed Aug 31 20:34:13 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 31 Aug 2005 21:34:13 +0100 Subject: [mcclim-devel] EPS output Message-ID: Hi, I need EPS output (as opposed to postscript destined for some paper size). I think the attached patch implements this, by using output recording to measure the bounding box of the output. (Though I can imagine that I've got the linesize stuff wrong and am out by 0.5 or something). I'm not happy with the way that I'm handling the transformation (in particular, the hack in obtaining the bounding box, where I've used knowledge of the transformation to reorder the coordinates), nor am I happy with the fact that this breaks in the presence of (newpage) commands, though since that doesn't make sense for EPS output, that might not be so big a deal. I think this works (unlike my previous attempt, which I was equally convinced worked, but failed to draw anything at all). I attach in addition a couple of test forms to try at the REPL, and also a file which could live as Tests/postscript.lisp. (McCLIM with this patch applied passes the tests, though they're by no means exhaustive). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: eps.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: foo.lisp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: postscript.lisp URL: -------------- next part -------------- Comments? Is anyone else using Postscript output? Cheers, Christophe