August 2005 - mcclim-devel - mailman3.common-lisp.net

[mcclim-devel] CLIM-LISTENER and the MOP
by Robert P. Goldman 23 Aug '05

23 Aug '05

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(a)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 #<STANDARD-CLASS CLIM:APPLICATION-FRAME> 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*) #<STANDARD-CLASS TAEMS-MDP-APP> GRAPH-MDP(78): (aclmop:class-direct-superclasses (class-of *frame*)) (#<STANDARD-CLASS STANDARD-APPLICATION-FRAME>) (aclmop:class-direct-superclasses (first (aclmop:class-direct-superclasses (class-of *frame*)))) (#<STANDARD-CLASS APPLICATION-FRAME> #<STANDARD-CLASS CLIM-INTERNALS::PRESENTATION-HISTORY-MIXIN>) 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

1 0

[mcclim-devel] A mcclim app which could possibly be used as a demo
by David Christiansen 20 Aug '05

20 Aug '05

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

2 1

[mcclim-devel] mcclim-0.9.1:system.lisp
by Mike McDonald 19 Aug '05

19 Aug '05

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(a)mikemac.com

4 4

[mcclim-devel] tar file of nightly "sources"
by Mike McDonald 19 Aug '05

19 Aug '05

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(a)mikemac.com

1 0

[mcclim-devel] question about abort and accept
by rpgoldman＠real-time.com 18 Aug '05

18 Aug '05

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

1 0

[mcclim-devel] problem with the webarchive of this mailinglist
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

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 <m.retzlaff(a)gmx.net> 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.

3 2

[mcclim-devel] trying to clean up incremental-redisplay.lisp
by Robert Strandh 18 Aug '05

18 Aug '05

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. ---------------------------------------------------------------------

2 2

[mcclim-devel] some patches: accepting-values and partial-commands
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

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 ,@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 ,@required-arg-names)))))))) - + (setq ,var ,value))))) + (when still-missing + (format ,stream + "~&Please supply all arguments."))) + (setf ,partial-command (list ,command-name ,@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 <m.retzlaff(a)gmx.net> 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

2 1

[mcclim-devel] A new example application for CLIM (town-example.lisp)
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

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 <m.retzlaff(a)gmx.net> 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

1 0

[mcclim-devel] tow more patches
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

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 + ,@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) ,@body)) (invoke-accepting-values ,stream #',accepting-values-continuation - ,@args)))) + ,@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 <m.retzlaff(a)gmx.net> 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

1 0