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

[mcclim-devel] ACL70 bug: Ignorable in argument acceptor functions for define-command
by rpgoldman＠real-time.com 30 Aug '05

30 Aug '05

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

2 1

[mcclim-devel] current CVS McCLIM broken?
by Max-Gerd Retzlaff 30 Aug '05

30 Aug '05

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 <http://www.sbcl.org/>. 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 #<MCCLIM-FREETYPE::FREETYPE-FACE {94F0DD1}> 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 #<MCCLIM-FREETYPE::FREETYPE-FACE {94F0DD1}> "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 <m.retzlaff(a)gmx.net> For your amusement: I will make you shorter by the head. -- Elizabeth I

2 2

[mcclim-devel] a new File Selector, patches for the CLIM-Listener, and a general problem with ACCEPT
by Max-Gerd Retzlaff 30 Aug '05

30 Aug '05

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.… (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 <m.retzlaff(a)gmx.net> For your amusement: Chance is perhaps the work of God when He did not want to sign. -- Anatole France

1 1

[mcclim-devel] Drawing xpm-icons to an accepting-values-steram
by Max-Gerd Retzlaff 29 Aug '05

29 Aug '05

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

1 0

[mcclim-devel] with-output-as-gadget, again
by Max-Gerd Retzlaff 26 Aug '05

26 Aug '05

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 #<CLIM-INTERNALS::ACCEPTING-VALUES-STREAM {92BF441}>. [Condition of type SIMPLE-ERROR] It would be especially nice to get this running as well.. Regards, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: I don't make the rules, Gil, I only play the game. -- Cash McCall

1 0

[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp
by Max-Gerd Retzlaff 26 Aug '05

26 Aug '05

Hello On Fri, Aug 26, 2005 at 01:50:21PM +0200, Paolo Amoroso wrote: > mretzlaff(a)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 <m.retzlaff(a)gmx.net> For your amusement: Scientists will study your brain to learn more about your distant cousin, Man.

2 2

[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp
by Andy Hefner 26 Aug '05

26 Aug '05

On 8/25/05, Max-Gerd Retzlaff <mretzlaff(a)common-lisp.net> 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?

3 4

[mcclim-devel] One char patch to presentation-defs
by David Murray 25 Aug '05

25 Aug '05

[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. JQS Index: presentation-defs.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/presentation-defs.lisp,v retrieving revision 1.44 diff -u -r1.44 presentation-defs.lisp --- presentation-defs.lisp 22 Jun 2005 09:49:15 -0000 1.44 +++ presentation-defs.lisp 25 Jul 2005 13:05:48 -0000 @@ -993,7 +993,7 @@ (multiple-value-bind (min-x min-y max-x max-y) (output-record-hit-detection-rectangle* record) (if (and (<= min-x x max-x) (<= min-y y max-y)) - (if (or (null single-box) (eq single-box :higlighting)) + (if (or (null single-box) (eq single-box :highlighting)) (funcall-presentation-generic-function presentation-refined-position-test (presentation-type record) record x y)

10 34

[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