From m.retzlaff at gmx.net Fri Sep 2 01:36:54 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 2 Sep 2005 03:36:54 +0200 Subject: [mcclim-devel] ideas on presentation methods for pathnames (was: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick) In-Reply-To: <17175.21377.616882.907672@serveur5.labri.fr> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> <20050901021529.GB14365@mgr.home> <4316A42C.2070801@yahoo.com> <20050901170854.GA26901@mgr.home> <17175.21377.616882.907672@serveur5.labri.fr> Message-ID: <20050902013654.GA30336@mgr.home> Hello, this thread actually started on climacs-devel. As the discussion has become more McCLIM than Climacs specific (at least in this sub-thread), I'll send this answer to mcclim-devel. If you're not subscribed to climacs-devel, refer to the following links for the context: http://article.gmane.org/gmane.lisp.climacs.devel/275 http://article.gmane.org/gmane.lisp.climacs.devel/276 On Thu, Sep 01, 2005 at 09:16:17PM +0200, Robert Strandh wrote: > Max-Gerd Retzlaff writes: > > I propose that COM-SHOW-DIRECTORY should become a general PRESENT method > > for a presentation LIST OF PATHNAMES, as well as the construct > > > > (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)) > > > > should be CLIM's general PRESENT method for PATHNAME in TEXTUAL-DIALOG-VIEW. > > (The latter is already defined in file-selector.lisp.) > > This code has a problem (aside from the very unfortunate indentation), Sorry, I had copied it from the Emacs on my other machine via the mouse and the other Emacs didn't know about proper Lisp indentation, as it was in the Fundamental mode. > [This code has a problem ] namely that it assumes that the listener > is present. At the moment, I do not think that is a good idea. > > This is going to be a general problem for other applications as well. > We are often going to want code that means "if this package exists and > this symbol has a function definition in that package, then call the > function with the following arguments" . Perhaps a macro > FUNCALL-IN-PACKAGE like this: > > (funcall-in-package :clim-listener (#:icon-of pathname) > (message "sorry...")) I don't think that this is a good idea. We have ASDF to load all required packages. Already we have to insert #-/#+ constructs to do things that depend on implementation features. We shouldn't do the equivalent for packages. And regarding COM-SHOW-DIRECTORY (as PRESENT LIST-OF-PATHNAMES, or something like that), ICON-OF, DRAW-ICON, etc.: I think they should become part of McCLIM together with the FILE-SELECTOR and ACCEPT and PRESENT methods for the GADGET-VIEW class or subclasses thereof. Perhaps in the files mcclim/gadget-pathname.lisp and gadget-pathname-utilities.lisp; at least as an extension of McCLIM. ICON-OF, DRAW-ICON and so on should only be used in the presentation methods (or in functions that are only called from these methods). That is the actual applications only call PRESENT and ACCEPT directly. And if the extension of the "nicer" pathname presentation methods (if it will be an extension) is not loaded, the current (more general) presentation methods will be used. No problem there. (That could even work for the PRESENT LIST-OF-PATHNAMES method, if it will be implemented as proposed and if it will be included in the file presentation-defs.lisp (and not in the assumed extension package), as it would also use the current general presentation methods, if the extension package is not loaded.) But I really think that an extension package is the wrong thing, as the specification defines a PATHNAME presentation type and also the standard views. I couldn't find it stated but the spec surely arranges for presentations methods for the standard presentation types and views. Dialog.lisp actually states: ;;; Hack until more views / dialog gadgets are defined. Moving the presentation methods from the Clim-Listener to McCLIM (or an extension of it) is a good idea in my opinion, as these methods are right now not only used by the Listener itself anymore but also by the file-selector, and you can surely think of other application that could make use of more intuitive and simply nicer presentation methods for the GADGET-VIEW class and/or subclasses of it. For example the file-manger and the Dired-like application that John Splittist has suggested. Hm, I think I'll accept the challenge and try to write a simple file-manager. Once there are the presentation methods it shouldn't be really that hard thanks to CLIM: Two panes (perhaps based on ESA) for directory listings (PRESENT LIST-OF-PATHNAMES), some presentation-to-command translators, some accepting-values dialogs (for renaming, etc), some drag and drop translators.. And you have it. --- Of course, it will nevertheless take quite some time as the supposedly simple things are always much harder to achieve than expected. :) At least the result will likely be not very long. Well, just let me some time and I'll try to reorganise the existing methods and write the proposed ones. And if they are indeed as nice as I hope we can think about including them into McCLIM, then. (Be prepared that it'll take some weeks as I have not much time during the next weeks. But I don't think that's a problem. Perhaps it's not to bad to think about it for some time.) Ah, actually I just noted that there is the sequence presentation type with one parameter "type": "The [presentation] type that represents a sequence of elements of type type. So "my" LIST-OF-PATHNAMES presentation type will just be the type SEQUENCE (of) PATHNAME. Very nice. Regards, Max -- Max-Gerd Retzlaff For your amusement: Make it idiot-proof, and someone will breed a better idiot. -- Oliver Elphick -------------- 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 Sep 2 02:20:31 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 2 Sep 2005 04:20:31 +0200 Subject: [mcclim-devel] Re: ideas on presentation methods for pathnames / mime-types, extension In-Reply-To: <20050902013654.GA30336@mgr.home> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> <20050901021529.GB14365@mgr.home> <4316A42C.2070801@yahoo.com> <20050901170854.GA26901@mgr.home> <17175.21377.616882.907672@serveur5.labri.fr> <20050902013654.GA30336@mgr.home> Message-ID: <20050902022031.GA2383@mgr.home> Hi On Fri, Sep 02, 2005 at 03:36:54AM +0200, Max-Gerd Retzlaff wrote: > But I really think that an extension package is the wrong thing, as > the specification defines a PATHNAME presentation type and also the > standard views. I couldn't find it stated but the spec surely arranges > for presentations methods for the standard presentation types and views. > Dialog.lisp actually states: > ;;; Hack until more views / dialog gadgets are defined. Okay, displaying the apt icon depending on the file-extension (pathname-type) works with help of the mime.types file. This should probably be put into an extension. (If the extension is not loaded the default icon (*document-icon* right now) is shown for all pathnames.) What do you think? Asks, Max -- Max-Gerd Retzlaff For your amusement: Love is the delusion that one woman differs from another. -- H.L. Mencken -------------- 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 Fri Sep 2 08:56:40 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 02 Sep 2005 09:56:40 +0100 Subject: [mcclim-devel] abort-gesture, again Message-ID: Hi, Regarding the following patch, of August 25th: Modified Files: presentation-defs.lisp Log Message: This patch HANDLER-BINDs the ABORT-GESTURE condition to #'abort for the function ACCEPT in presentation-defs.lisp. I believe this has had the side effect of making C-g in climacs, while in the process of typing an extended command (e.g. com-find-file, started by C-x C-f) abort the entire application rather than just the command input -- as the ESA-TOP-LEVEL does not provide an ABORT restart -- instead, it tries to handle abort-gesture itself, but the control is never passed to that handler because the inner handler in ACCEPT unconditionally handles the gesture. What was the intent of all of this? How is it meant to behave? Cheers, Christophe From m.retzlaff at gmx.net Fri Sep 2 11:34:24 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 2 Sep 2005 13:34:24 +0200 Subject: [mcclim-devel] abort-gesture, again In-Reply-To: References: Message-ID: <20050902113424.GA9279@mgr.home> Hi On Fri, Sep 02, 2005 at 09:56:40AM +0100, Christophe Rhodes wrote: > Regarding the following patch, of August 25th: > > Modified Files: > presentation-defs.lisp > Log Message: > This patch HANDLER-BINDs the ABORT-GESTURE condition to #'abort > for the function ACCEPT in presentation-defs.lisp. > > I believe this has had the side effect of making C-g in climacs, while > in the process of typing an extended command (e.g. com-find-file, > started by C-x C-f) abort the entire application rather than just the > command input -- as the ESA-TOP-LEVEL does not provide an ABORT > restart -- instead, it tries to handle abort-gesture itself, but the > control is never passed to that handler because the inner handler in > ACCEPT unconditionally handles the gesture. > > What was the intent of all of this? How is it meant to behave? I just commited a patch for this that was suggested by Christophe Rhodes. See: http://article.gmane.org/gmane.lisp.mcclim.cvs/285 We reSIGNAL the condition now before the call to ABORT, to give outer handlers a chance to say "I know how to handle this" (as Christophe Rhodes has put it). I did some quick tests: A simple (accept 'integer) is still abortable via the abort-gesture and it does not break Climacs, so I commited it right away, as it is in any case better than the previous version. Bye, Max -- Max-Gerd Retzlaff For your amusement: Style may not be the answer, but at least it's a workable alternative. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rudi at constantly.at Fri Sep 2 12:42:40 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Fri, 2 Sep 2005 14:42:40 +0200 Subject: [mcclim-devel] [patch] with-output-to-pixmap without sizes given Message-ID: <2F966FCC-CAE2-47D5-87BC-BACD0FC2CDE0@constantly.at> Hi, I hacked with-output-to-pixmap so :width and :height need not be given. I'm generally confused about various aspects of [Mc]CLIM, but the following code (adapted from Franz's CLIM manual) was observed to paint a something at mouse click position, so it might just work. Patch is attached. (define-test-command (test-pixmaps :menu t) () (let* ((stream (get-frame-pane *application-frame* 'display)) (medium (clim:sheet-medium stream))) (let ((pixmap (clim:with-output-to-pixmap (mv stream) (with-drawing-options (mv :ink +red+) (clim:draw-circle* mv 50 50 20 :filled t) (clim:draw-rectangle* mv 0 0 90 90 :filled nil))))) (multiple-value-bind (x y) (block get-position (clim:tracking-pointer (stream) (:pointer-button-press (x y) (return-from get-position (values x y))))) (clim:copy-from-pixmap pixmap 0 0 (clim:pixmap-width pixmap) (clim:pixmap-height pixmap) medium x y))))) Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: w-o-t-p.patch Type: application/octet-stream Size: 2154 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From frido at q-software-solutions.de Sat Sep 3 06:59:26 2005 From: frido at q-software-solutions.de (Friedrich Dominicus) Date: Sat, 03 Sep 2005 08:59:26 +0200 Subject: [mcclim-devel] multithreaded SBCL and mcclim Message-ID: <87aciutz5d.fsf@flarge.here> May I ask if there are any known issues about this combination on a 64-bit processor? I'm wondering because everything gets compiled find but while starting an mcclim applicatoin nothing happens. Well in fact a thread start but not output can be seen have I overread something in the manual? Regards Friedrich From csr21 at cam.ac.uk Sat Sep 3 07:15:23 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sat, 03 Sep 2005 08:15:23 +0100 Subject: [mcclim-devel] multithreaded SBCL and mcclim In-Reply-To: <87aciutz5d.fsf@flarge.here> (Friedrich Dominicus's message of "Sat, 03 Sep 2005 08:59:26 +0200") References: <87aciutz5d.fsf@flarge.here> Message-ID: Friedrich Dominicus writes: > May I ask if there are any known issues about this combination on a > 64-bit processor? It works fine here. Cheers, Christophe From gilbert at base-engineering.com Sat Sep 3 14:01:00 2005 From: gilbert at base-engineering.com (Gilbert Baumann) Date: Sat, 3 Sep 2005 16:01:00 +0200 Subject: [mcclim-devel] Displayed Output Records Proposal Message-ID: <17177.44188.526746.118589@nx01.base> Hi there, i am working on a Cairo[1] backend for mcclim. While doing so i noticed two issues with the current implementation of displayed-output-records: a) displayed-output-records want to store transformed graphics. It however is not always possible to fully transform a graphics request. This most notably is the case with DRAW-TEXT* while :transform-glyphs is non-NIL. Also line styles are hard to transform. I recognize that that storing transformed graphics request seems easier from the perspective of the CLX backend, since CLX itself can't do transformations; so you need to transform the graphics request anyway before hitting the backend. This however looks different from the perspective of the Cairo backend (and also of the PS backend and a possible OpenGL), as these graphics systems can perfectly well transform graphics requests. [In case of OpenGL they perhaps can do this even faster than we will ever be due to HW acceleration]. b) the bounding boxes are not always quite correct. Which I believe is because of anti-aliasing, since some pixels at the border of a shape spill over. PROPOSAL I propose that we open an opportunity for the backend to implement its own output recording classes. Which would have the following benefits: - bounding boxes are likely to be correct (E.g. the Cairo backend can tell me the bounding box of graphics requests). - the backend can decide if it is more economic to store transformed or untransformed coordinates. - the backend perhaps has a faster way to capture, save and restore the drawing options of a medium than we can have sticking to the medium protocol. - the backend can decide on the representation of the graphics request. E.g. it might want to save the fully tessellated representation of a shape, it might want to keep references to rasterizied ink in case of drawing with patterns, it might construct display lists. etc. PROTOCOL We could specify MEDIUM-RECORD-xyz* methods to complement MEDIUM-DRAW-xyz, like this: MEDIUM-RECORD-LINE* medium x1 y1 x2 y2 drawp recordp [Generic Function] If /drawp/ is non-NIL, behave as MEDIUM-DRAW-LINE*. If /recordp/ is non-NIL, return a displayed output record which, when replayed has the effect or MEDIUM-DRAW-LINE* with the given arguments and the current drawing options installed in /medium/. Since some work to be done on recording and drawing perhaps is similar, i chose to go with this combined record and/or draw protocol function. We could specify that an implementation of MEDIUM-RECORD-LINE* for a medium is optional and that a default implementation is provided by CLIM. So the implementation of MEDIUM-DRAW-LINE* on output recording streams would look like this: (defmethod medium-draw-line* ((stream output-record-stream) x1 y1 x2 y2) (let ((record (medium-record-line* stream x1 y1 x2 y2 (stream-drawing-p stream) (stream-recording-p stream)))) (when (stream-recording-p stream) (stream-add-output-record stream record)))) Before heading to implement this, i wanted to gather some comments on this. -- Gilbert Baumann [1] for those that are not familiar with Cairo: It is a graphics API which somewhat resembles Postscript; based on fills and strokes. Additionally an alpha channel is supported and so it does anti-aliasing. Also every graphics request is transformed by an affine transformation. See From strandh at labri.fr Sat Sep 3 21:18:11 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 3 Sep 2005 23:18:11 +0200 Subject: [mcclim-devel] Displayed Output Records Proposal In-Reply-To: <17177.44188.526746.118589@nx01.base> References: <17177.44188.526746.118589@nx01.base> Message-ID: <17178.4883.17882.568356@serveur5.labri.fr> Hello, Just some immediate comments: Gilbert Baumann writes: > PROPOSAL > > I propose that we open an opportunity for the backend to implement its > own output recording classes The question is when the specific subclass of output-record is then determined. The output record is created by an :around method that specializes on the stream, but the stream is not backend-specific AFAIK; the medium is. > PROTOCOL > > We could specify MEDIUM-RECORD-xyz* methods to complement > MEDIUM-DRAW-xyz, like this: > > MEDIUM-RECORD-LINE* medium x1 y1 x2 y2 drawp recordp [Generic Function] > > If /drawp/ is non-NIL, behave as MEDIUM-DRAW-LINE*. > > If /recordp/ is non-NIL, return a displayed output record which, > when replayed has the effect or MEDIUM-DRAW-LINE* with the given > arguments and the current drawing options installed in /medium/. This in itself looks OK to me, but I have a problem with the way it is used below. > We could specify that an implementation of MEDIUM-RECORD-LINE* for a > medium is optional and that a default implementation is provided by > CLIM. OK > So the implementation of MEDIUM-DRAW-LINE* on output recording streams > would look like this: > > (defmethod medium-draw-line* ((stream output-record-stream) x1 y1 x2 y2) > (let ((record > (medium-record-line* stream x1 y1 x2 y2 > (stream-drawing-p stream) > (stream-recording-p stream)))) > (when (stream-recording-p stream) > (stream-add-output-record stream record)))) I don't see how this can work. According to the spec, the output record is created by the :around method on medium-draw-line* specialized on the stream. The main method has no business creating output records, if I read the spec right. It looks to me like you would have to do: (defmethod medium-draw-line* :around ((stream output-recording-stream) x1 y1 x2 y2) (when (stream-recording-p stream) (let ((record (medium-record-line* (sheet-medium stream) x1 y1 x2 y2 nil t))) (stream-add-output-record stream record))) (when (stream-drawing-p stream) (medium-record-line* (sheet-medium stream) x1 y1 x2 y2 t nil))) which somewhat defeats the purpose of having a single medium-record-line, since you can replace the last call with one to medium-draw-line and skip the {recording,drawing}-p arguments to medium-record-line*. But you can still have medium-specific output records, and a medium-specific medium-record-line*. Also, we must not forget that the spec allows the user to define his or her own output record subclasses. This must be possible to do without taking into account the backend. There are already too many places in McCLIM where the implementation makes too many assumptions about the superclasses of certain classes, and by doing so makes it impossible for client code to extend it by using the documented protocols. We must therefore be careful and make sure that any subclass of output-record continue to work properly and independently of the backend. -- 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 Wed Sep 7 08:15:38 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 07 Sep 2005 09:15:38 +0100 Subject: [mcclim-devel] Re: [climacs-devel] Small patch to commands.lisp In-Reply-To: <431E9D14.8080008@yahoo.com> (John Q. Splittist's message of "Wed, 07 Sep 2005 08:56:04 +0100") References: <431E9D14.8080008@yahoo.com> Message-ID: John Q Splittist writes: > Attached is a small patch I needed to make mapping over > commands/keystrokes work correctly. Aha, a victim! I wonder if it would be possible to add a test case for the failure you've seen in the Tests/ directory? Not that they're run automatically as yet, but it's a good way both to document the previous problem and to ensure that it doesn't recur... Cheers, Christophe From rudi at constantly.at Fri Sep 9 11:53:17 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Fri, 9 Sep 2005 13:53:17 +0200 Subject: [mcclim-devel] CVS commit problems Message-ID: <15B866A0-D0C3-46E6-AF43-615B554AE70F@constantly.at> Hello, I can checkout mcclim via -d:ext:rschlatte at ... but trying to commit gives the following message: cvs [server aborted]: could not open lock file `/project/mcclim/ cvsroot/mcclim/,graphics.lisp,': Permission denied Does anyone know of a fix? Many thanks, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From tl at di.fc.ul.pt Fri Sep 9 13:53:44 2005 From: tl at di.fc.ul.pt (Thibault Langlois) Date: Fri, 9 Sep 2005 13:53:44 +0000 (UTC) Subject: [mcclim-devel] calling display function on resize Message-ID: Hello, Does anybody knows how to call a application pane's display-function when the user resizes the window with the mouse ? I have found some old messages on a clim-list about this subject but it does not seem to work with McCLIM. http://openmap.bbn.com/hypermail/clim/0323.html There must be a way. Thanks. Thibault From rudi at constantly.at Fri Sep 9 22:08:40 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Sat, 10 Sep 2005 00:08:40 +0200 Subject: [mcclim-devel] Re: [clo-devel] CVS commit problems In-Reply-To: References: <15B866A0-D0C3-46E6-AF43-615B554AE70F@constantly.at> Message-ID: On 9. Sep 2005, at 17:08, Marco Baringer wrote: > i know who you are, but you can still get a mcclim commiter to send me > an email requesting write privs to mcclim? > > p.s. - this may be one of those things which were lost in the june > debian-update mess. did you ever have commit access? I hadn't committed anything to date, but rstrandh said in private mail that he remembers sneakily adding me as a mcclim developer, perhaps during the move to common-lisp.net. Robert, can you confirm? Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From strandh at labri.fr Sat Sep 10 06:43:09 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 10 Sep 2005 08:43:09 +0200 Subject: [mcclim-devel] Re: [clo-devel] CVS commit problems In-Reply-To: References: <15B866A0-D0C3-46E6-AF43-615B554AE70F@constantly.at> Message-ID: <17186.32893.968113.748762@serveur5.labri.fr> Rudi Schlatte writes: > > I hadn't committed anything to date, but rstrandh said in private > mail that he remembers sneakily adding me as a mcclim developer, > perhaps during the move to common-lisp.net. Robert, can you confirm? I can confirm that this is my memory of it, but then, my memory is not that good; never has been. In any case, I think you should have commit privileges. -- 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 Sep 15 20:08:28 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 15 Sep 2005 22:08:28 +0200 Subject: [mcclim-devel] arglist, tester-arglist, and doc-arglist for presentation translators Message-ID: <20050915200827.GA611@mgr.home> Hello, please have a look at 23.7.1 of the CLIM 2.0 specification. In the section about DEFINE-PRESENTATION-TRANSLATOR it says: "arglist, tester-arglist, and doc-arglist are each an argument list that must "match" the following "canonical" argument list. (object &key presentation context-type frame event window x y) In order to "match" the canonical argument list, there must be a single positional argument that corresponds to the presentation's object, and several named arguments that must match the canonical names above (using string-equal to do the comparison)." They are defined in the same way for DEFINE-PRESENTATION-TO-COMMAND-TRANSLATOR, DEFINE-PRESENTATION-ACTION, and DEFINE-DRAG-AND-DROP-TRANSLATOR, with the only exception that the doc-arglist "includes a named (keyword) stream argument as well". If my interpretation is correct, you have not only to use theses names *literally* (because of the STRING-EQUAL requirement), but also the empty list is not allowed and the first argument is always required and has to be (STRING-EQUAL to) OBJECT. I added an ASSERT to beginning of CLIMI::MAKE-TRANSLATOR-LL because I've made the error earlier to try to bind the object to a symbol non-equal to OBJECT, and I've seen that there are presentation translators in beirc that just try to bind PRESENTATION. The ASSERT is: (assert (string-equal (car translator-args) "object") () "The first parameter of the presentation translator's argument list~%has to be STRING-EQUAL to OBJECT. (See 23.7.1)") Well, afterwards McCLIM doesn't compile anymore. There are two presentation to command translators in dialog.lisp: COM-EXIT-BUTTON and COM-ABORT-BUTTON. After I allowed also the empty arglist it still did not compile because (at least) the presentation to command translator COM-DESCRIBE-PRESENTATION-TRANSLATOR has the list (presentation) as its arglist as well as its tester-arglist. Personally I think the requirement that the arglists have always to be at least the list (object) (if I interpret the spec correctly) is quite odd. There are perfectly reasonable cases to have an empty list: E.g. COM-EXIT-BUTTON doesn't need the object itself. And likewise COM-DESCRIBE-PRESENTATION-TRANSLATOR doesn't need the object but only the presentation. Why should OBJECT be bound if it isn't used at all? The way DEFINE-PRESENTATION-TRANSLATOR and its friends are specified you cannot insert a DECLARE IGNORE (or IGNORABLE), and that means you would always get style warnings on SBCL in these cases. The "canonical" argument list should be the following in my opinion: (&key object presentation context-type frame event window x y) And also the empty list should be considered to match it. What do you think? Should we just CLIMI::MAKE-TRANSLATOR-LL leave as it is, and add this to a list of known but wanted nonconformances to the CLIM specification? Bye, Max -- Max-Gerd Retzlaff For your amusement: People who claim they don't let little things bother them have never slept in a room with a single mosquito. -------------- 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 Sep 15 20:43:47 2005 From: moore at bricoworks.com (Timothy Moore) Date: Thu, 15 Sep 2005 22:43:47 +0200 Subject: [mcclim-devel] arglist, tester-arglist, and doc-arglist for presentation translators In-Reply-To: <20050915200827.GA611@mgr.home> References: <20050915200827.GA611@mgr.home> Message-ID: <396e1129cbad358c664a66839db9ccb1@bricoworks.com> On Sep 15, 2005, at 10:08 PM, Max-Gerd Retzlaff wrote: > Hello, > > please have a look at 23.7.1 of the CLIM 2.0 specification. In the > section > about DEFINE-PRESENTATION-TRANSLATOR it says: > ... > If my interpretation is correct, you have not only to use theses names > *literally* (because of the STRING-EQUAL requirement), but also the > empty list is not allowed and the first argument is always required > and has to be (STRING-EQUAL to) OBJECT. > > > I added an ASSERT to beginning of CLIMI::MAKE-TRANSLATOR-LL because > I've made the error earlier to try to bind the object to a symbol > non-equal to OBJECT, and I've seen that there are presentation > translators in beirc that just try to bind PRESENTATION. The ASSERT is: > ... > Well, afterwards McCLIM doesn't compile anymore. There are two > presentation to command translators in dialog.lisp: COM-EXIT-BUTTON > and COM-ABORT-BUTTON. > ... > Personally I think the requirement that the arglists have always to be > at least the list (object) (if I interpret the spec correctly) is > ... > The "canonical" argument list should be the following in my opinion: > (&key object presentation context-type frame event window x y) > And also the empty list should be considered to match it. > > > What do you think? Should we just CLIMI::MAKE-TRANSLATOR-LL leave as > it is, and add this to a list of known but wanted nonconformances to > the CLIM specification? > I believe the code implements the description of translator arglists on page 156 of the Franz CLIM User's guide, which is the closest thing to a reasonable revision of the spec: "An argument list that must be a subset (using STRING-EQUAL ...) of the canonical argument list: (object presentation context-type frame event window x y)" In other words, nothing is special about object. Code written to the older definition in the Spec should be compatible with this too. Tim From m.retzlaff at gmx.net Thu Sep 15 21:16:40 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 15 Sep 2005 23:16:40 +0200 Subject: [mcclim-devel] arglist, tester-arglist, and doc-arglist for presentation translators In-Reply-To: <396e1129cbad358c664a66839db9ccb1@bricoworks.com> References: <20050915200827.GA611@mgr.home> <396e1129cbad358c664a66839db9ccb1@bricoworks.com> Message-ID: <20050915211640.GA1453@mgr.home> On Thu, Sep 15, 2005 at 10:43:47PM +0200, Timothy Moore wrote: > > On Sep 15, 2005, at 10:08 PM, Max-Gerd Retzlaff wrote: > >Personally I think the requirement that the arglists have always to be > >at least the list (object) (if I interpret the spec correctly) is > > > ... > >The "canonical" argument list should be the following in my opinion: > > (&key object presentation context-type frame event window x y) > >And also the empty list should be considered to match it. > > > > > >What do you think? Should we just CLIMI::MAKE-TRANSLATOR-LL leave as > >it is, and add this to a list of known but wanted nonconformances to > >the CLIM specification? > > > > I believe the code implements the description of translator arglists on > page 156 of the Franz CLIM User's guide, which is the closest thing to > a reasonable revision of the spec: > > "An argument list that must be a subset (using STRING-EQUAL ...) of the > canonical argument list: (object presentation context-type frame event > window x y)" > > In other words, nothing is special about object. Code written to the > older definition in the Spec should be compatible with this too. Yes, exactly. I think it would be rather stupid to enforce the exact behaviour the specification prescribes in this case. I've also had a look at Franz' CLIM 2 User Guide earlier, as in several cases it has more reasonable definitions. Especially in this case as conforming code to the original specification still works without a problem. Perhaps we should add an annotation to Gilbert's version of the spec that McCLIM actually implements what Franz proposes. Regards, Max -- Max-Gerd Retzlaff For your amusement: A successful [software] tool is one that was used to do something undreamed of by its author. -- S. C. Johnson -------------- 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 Sep 16 11:25:27 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 16 Sep 2005 13:25:27 +0200 Subject: [mcclim-devel] arglist, tester-arglist, and doc-arglist for presentation translators In-Reply-To: <20050915211640.GA1453@mgr.home> (Max-Gerd Retzlaff's message of "Thu, 15 Sep 2005 23:16:40 +0200") References: <20050915200827.GA611@mgr.home> <396e1129cbad358c664a66839db9ccb1@bricoworks.com> <20050915211640.GA1453@mgr.home> Message-ID: <87d5n91cgo.fsf@plato.moon.paoloamoroso.it> Max-Gerd Retzlaff writes: > Perhaps we should add an annotation to Gilbert's version of the spec > that McCLIM actually implements what Franz proposes. And/or maybe here: http://mcclim.cliki.net/Compliance Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From rpgoldman at real-time.com Fri Sep 16 21:39:00 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Fri, 16 Sep 2005 16:39:00 -0500 Subject: [mcclim-devel] file-selector problem Message-ID: <17195.15220.839531.341577@gargle.gargle.HOWL> [SELECT-FILE crashes under ACL if called with no arguments.] OK, seems like one problem for me is that the file-selector is not happy when given a pathname argument (or a default) that has no :name component. In that case it crashes (at least for me). I haven't identified why. So (select-file) crashes but (select-file :pathname (parse-namestring "/home/rpg/lisp/mcclim/file-selector.lisp")) is fine.[1] Here are my *default-pathname-defaults*: CL-USER(11): *default-pathname-defaults* #p"/home/rpg/lisp/mcclim/" CL-USER(12): (describe *) #p"/home/rpg/lisp/mcclim/" is a structure of type PATHNAME. It has these slots: HOST NIL DEVICE :UNSPECIFIC DIRECTORY (:ABSOLUTE "home" "rpg" "lisp" "mcclim") NAME NIL TYPE NIL VERSION :UNSPECIFIC NAMESTRING "/home/rpg/lisp/mcclim/" HASH NIL DIR-NAMESTRING "/home/rpg/lisp/mcclim/" PLIST NIL ... I don't know if these are odd... gen-wild-pathname gives the following: CL-USER(13): (clim-listener::gen-wild-pathname *default-pathname-defaults*) #p"/home/rpg/lisp/mcclim/*.*" CL-USER(14): (describe (clim-listener::gen-wild-pathname *default-pathname-defaults*)) #p"/home/rpg/lisp/mcclim/*.*" is a structure of type PATHNAME. It has these slots: HOST NIL DEVICE :UNSPECIFIC DIRECTORY (:ABSOLUTE "home" "rpg" "lisp" "mcclim") NAME :WILD TYPE :WILD VERSION :UNSPECIFIC NAMESTRING NIL HASH NIL DIR-NAMESTRING NIL PLIST NIL Aha! If I change the default pathname argument to be the following: (pathname (clim-listener::gen-wild-pathname *default-pathname-defaults*)) instead of just *default-pathname-defaults*, that seems to fix things by changind NIL to :WILD for NAME. A couple of remaning problems: 1. running select-file makes the size of the clim-listener window go crazy. First, it shrinks to fit only the accepting-values (I'm not sure I have the right term here), and leaves the directory listing pane out of the window. Then, after I select a file, it leaves only the 2. Unless I press return after entering a string in the filename textbox, that input is simply discarded when I press Exit for the file-selector as a whole. This is probably McCLIM's fault as a whole, rather than yours, right? But it's quite annoying. The user has the right to expect that what's on the screen is what is going to be accepted. Adding an extra requirement for a "Simon Says" gesture [2] is really a Bad Thing. Footnotes: [1] Ouch! I wish I could cut and paste out of the clim-listener! :-/ [2] This is an American (poss British, too?) children's game, where one player tries to trick the other into doing an action without explicit permission being given. From amoroso at mclink.it Sat Sep 17 11:55:10 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Sat, 17 Sep 2005 13:55:10 +0200 Subject: [mcclim-devel] file-selector problem In-Reply-To: <17195.15220.839531.341577@gargle.gargle.HOWL> (rpgoldman@real-time.com's message of "Fri, 16 Sep 2005 16:39:00 -0500") References: <17195.15220.839531.341577@gargle.gargle.HOWL> Message-ID: <87oe6rj4dd.fsf@plato.moon.paoloamoroso.it> rpgoldman at real-time.com writes: > [1] Ouch! I wish I could cut and paste out of the clim-listener! > :-/ Isn't SHIFT + left-click-swipe supposed to select, and SHIFT + middle-click to paste? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From rpgoldman at real-time.com Sat Sep 17 19:37:01 2005 From: rpgoldman at real-time.com (Robert P. Goldman) Date: Sat, 17 Sep 2005 14:37:01 -0500 Subject: [mcclim-devel] file-selector problem In-Reply-To: <87oe6rj4dd.fsf@plato.moon.paoloamoroso.it> References: <17195.15220.839531.341577@gargle.gargle.HOWL> <87oe6rj4dd.fsf@plato.moon.paoloamoroso.it> Message-ID: <432C705D.1080405@real-time.com> Paolo Amoroso wrote: > rpgoldman at real-time.com writes: > > >>[1] Ouch! I wish I could cut and paste out of the clim-listener! >>:-/ > > > Isn't SHIFT + left-click-swipe supposed to select, and SHIFT + > middle-click to paste? > > > Paolo Thank you Paolo. I did not know this! Speaking of which, is there a reference somewhere that lists the definitions of all of the standard gestures for McCLIM? If not, perhaps I should troll around the source code and try to assemble one. From csr21 at cam.ac.uk Sun Sep 18 07:50:30 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 18 Sep 2005 08:50:30 +0100 Subject: [mcclim-devel] file-selector problem In-Reply-To: <432C705D.1080405@real-time.com> (Robert P. Goldman's message of "Sat, 17 Sep 2005 14:37:01 -0500") References: <17195.15220.839531.341577@gargle.gargle.HOWL> <87oe6rj4dd.fsf@plato.moon.paoloamoroso.it> <432C705D.1080405@real-time.com> Message-ID: "Robert P. Goldman" writes: > Paolo Amoroso wrote: > >> rpgoldman at real-time.com writes: >> >>>[1] Ouch! I wish I could cut and paste out of the clim-listener! >>>:-/ >> Isn't SHIFT + left-click-swipe supposed to select, and SHIFT + >> middle-click to paste? >> Paolo > Thank you Paolo. I did not know this! Incidentally, someone with a little bit of time here might be interested in allowing this to work for selecting input as well as output. IIRC (I don't have a listener booted right now) the cut and paste support allows you to select text from output records but not from text that has been entered at the command loop. A fix for this would be cool :-) (A different problem would be making select and paste work with climacs -- there, the mcclim-provided support isn't right, and instead the climacs buffer contents should be inspected...) Cheers, Christophe From amoroso at mclink.it Sun Sep 18 09:34:12 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Sun, 18 Sep 2005 11:34:12 +0200 Subject: [mcclim-devel] file-selector problem References: <17195.15220.839531.341577@gargle.gargle.HOWL> <87oe6rj4dd.fsf@plato.moon.paoloamoroso.it> <432C705D.1080405@real-time.com> Message-ID: <87k6he67or.fsf@plato.moon.paoloamoroso.it> "Robert P. Goldman" writes: > Speaking of which, is there a reference somewhere that lists the > definitions of all of the standard gestures for McCLIM? If not, Here are the standard CLIM gesture names: 22.3.1 Standard Gesture Names http://www.mikemac.com/mikemac/clim/extended-input.html#22.3.1 24.1.2 Suggestions for Input Editing Commands http://www.mikemac.com/mikemac/clim/input-editing.html#24.1.2 Some additional McCLIM-specific info in section "Super key" of: Tip http://mcclim.cliki.net/Tip Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Tue Sep 20 16:09:27 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 20 Sep 2005 17:09:27 +0100 Subject: [mcclim-devel] trivial fix for line-style-equalp Message-ID: Hi, There's a cut-and-pasteo in line-style-equalp, which the attached patch fixes. Could someone with a non-mutant mcclim tree please apply it? (my medium.lisp contains a completely broken text-style refactoring, which I don't think it would be wise to inflict on the world). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: foo.diff URL: -------------- next part -------------- Cheers, Christophe From rudi at constantly.at Sat Sep 24 12:46:35 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Sat, 24 Sep 2005 14:46:35 +0200 Subject: [mcclim-devel] [PATCH] Space layout calculation: make user-supplied options take precedence Message-ID: Hello, I noticed that a text-field created with an explicit :width option nevertheless had a width calculated from its initial contents. Fixed by the attached patch, which also introduces a fast path for the common case of no user-supplied options. There's still work to be done in the layout code, e.g. the following code creates a frame 100px wide (I'd expect 500): (define-application-frame textedit-frame () () (:panes (edit :text-field :value "edit" :width 500)) (:layouts (:default (vertically (:min-width 1 :width 100 :max-width +fill+) edit)))) Nevertheless, it's better than what's there currently, so I'll commit it shortly if there are no objections. Cheers, Rudi Index: panes.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/panes.lisp,v retrieving revision 1.155 diff -u -r1.155 panes.lisp --- panes.lisp 29 Aug 2005 22:39:31 -0000 1.155 +++ panes.lisp 24 Sep 2005 12:37:08 -0000 @@ -538,63 +538,48 @@ (defun merge-one-option (pane foo user-foo user-min-foo user-max-foo min-foo max-foo) - + ;; Some of the hair in the code below is because the user-supplied + ;; values need not be given in device units - ;; NOTE: The defaulting for :min-foo and :max-foo is different from MAKE-SPACE-REQUIREMENT. - ;; MAKE-SPACE-REQUIREMENT has kind of &key foo (min-foo 0) (max-foo +fill+) - ;; While user space requirements has &key foo (min-foo foo) (max-foo foo). - ;; I as a user would pretty much expect the same behavior, therefore I'll take the - ;; following route: - ;; When the :foo option is given, I'll let MAKE-SPACE- REQUIREMENT decide. - ;; - ;; old code: - ;; - ;; ;; Then we resolve defaulting. sec 29.3.1 says: - ;; ;; | If either of the :max-width or :min-width options is not - ;; ;; | supplied, it defaults to the value of the :width option. If - ;; ;; | either of the :max-height or :min-height options is not - ;; ;; | supplied, it defaults to the value of the :height option. - ;; (setf user-max-foo (or user-max-foo user-foo) - ;; user-min-foo (or user-min-foo user-foo)) - ;; --GB 2003-01-23 + (cond + ((not (or user-min-foo user-max-foo user-foo)) + ;; fast path + (values foo min-foo max-foo)) + (t + ;; sec 29.3.1 says: + ;; | If either of the :max-width or :min-width options is not + ;; | supplied, it defaults to the value of the :width option. If + ;; | either of the :max-height or :min-height options is not + ;; | supplied, it defaults to the value of the :height option. + (setf user-min-foo (or user-min-foo user-foo min-foo) + user-max-foo (or user-max-foo user-foo max-foo)) - (when (and (null user-max-foo) (not (null user-foo))) - (setf user-max-foo (space-requirement-max-width - (make-space-requirement - :width (spacing-value-to-device-units pane foo))))) - (when (and (null user-min-foo) (not (null user-foo))) - (setf user-min-foo (space-requirement-min-width - (make-space-requirement - :width (spacing-value-to-device-units pane foo))))) - - ;; when the user has no idea about the preferred size just take the - ;; panes preferred size. - (setf user-foo (or user-foo foo)) - (setf user-foo (spacing-value-to-device-units pane user-foo)) + ;; when the user has no idea about the preferred size just take + ;; the panes preferred size. + (setf user-foo (or user-foo foo)) + (setf user-foo (spacing-value-to-device-units pane user-foo)) - ;; dito for min/max - (setf user-min-foo (or user-min-foo min-foo) - user-max-foo (or user-max-foo max-foo)) - - ;; | :max-width, :min-width, :max-height, and :min-height can - ;; | also be specified as a relative size by supplying a list of - ;; | the form (number :relative). In this case, the number - ;; | indicates the number of device units that the pane is - ;; | willing to stretch or shrink. - (labels ((resolve-relative (dimension sign base) - (if (and (consp dimension) (eq (car dimension) :relative)) - (+ base (* sign (cadr dimension))) - (spacing-value-to-device-units pane dimension)))) - (setf user-min-foo (and user-min-foo - (resolve-relative user-min-foo -1 user-foo)) - user-max-foo (and user-max-foo - (resolve-relative user-max-foo +1 user-foo)))) - - ;; Now we have two space requirements which need to be 'merged'. - (setf min-foo (clamp user-min-foo min-foo max-foo) - max-foo (clamp user-max-foo min-foo max-foo) - foo (clamp user-foo min-foo max-foo)) - (values foo min-foo max-foo)) + ;; | :max-width, :min-width, :max-height, and :min-height can + ;; | also be specified as a relative size by supplying a list of + ;; | the form (number :relative). In this case, the number + ;; | indicates the number of device units that the pane is + ;; | willing to stretch or shrink. + (labels ((resolve-relative (dimension sign base) + (if (and (consp dimension) (eq (car dimension) :relative)) + (+ base (* sign (cadr dimension))) + (spacing-value-to-device-units pane dimension)))) + (setf user-min-foo (resolve-relative user-min-foo -1 user-foo) + user-max-foo (resolve-relative user-max-foo +1 user- foo))) + + ;; again, user options take precedence + (setf min-foo (min min-foo user-min-foo) + max-foo (max max-foo user-max-foo)) + + ;; Now we have two space requirements which need to be 'merged'. + (setf min-foo (clamp user-min-foo min-foo max-foo) + max-foo (clamp user-max-foo min-foo max-foo) + foo (clamp user-foo min-foo max-foo)) + (values foo min-foo max-foo)))) (defmethod merge-user-specified-options ((pane space-requirement- options-mixin) sr) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From rudi at constantly.at Sat Sep 24 14:31:06 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Sat, 24 Sep 2005 16:31:06 +0200 Subject: [mcclim-devel] [PATCH] hollow cursors for unfocused text-fields Message-ID: <2E2567AA-FF0B-4320-B9BE-166DE4F1DD70@constantly.at> Hi, Another one I'm not quite sure of ... displaying of hollow/filled cursor upon mouse enter/exit seems to work ok, and it's nice to see where a keystroke will end up ... The only drawback is that the user can't change cursor visibility in :armed-callback / :disarmed- callback functions. Nevertheless, I think I'll check this in after a few days if there are no objections. Cheers, Rudi Index: gadgets.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/gadgets.lisp,v retrieving revision 1.90 diff -u -r1.90 gadgets.lisp --- gadgets.lisp 23 May 2005 12:43:34 -0000 1.90 +++ gadgets.lisp 24 Sep 2005 14:27:03 -0000 @@ -2642,6 +2642,33 @@ (setf (port-keyboard-input-focus port) (previous-focus gadget)) (setf (previous-focus gadget) nil))) + +;;; also, hack the full/hollow cursor displaying -- don't leave +;;; artifacts when the value of the gadget is called during arm/disarm +;;; events (otherwise, a hollow cursor is "erased" with a full one and +;;; vice versa). +;;; BUG (rudi 2005-09-24): this code overwrites changes to cursor +;;; visibility within a user-supplied armed-callback / +;;; disarmed-callback, though ... + +(defmethod handle-event :around ((pane text-field-pane) + (event pointer-enter-event)) + (let* ((area (area pane)) + (cursor-p (cursor-visibility area))) + (when cursor-p (setf (cursor-visibility area) nil)) + (call-next-method) + (when (and cursor-p (not (cursor-visibility area))) + (setf (cursor-visibility area) cursor-p)))) + +(defmethod handle-event :around ((pane text-field-pane) + (event pointer-exit-event)) + (let* ((area (area pane)) + (cursor-p (cursor-visibility area))) + (when cursor-p (setf (cursor-visibility area) nil)) + (call-next-method) + (when (and cursor-p (not (cursor-visibility area))) + (setf (cursor-visibility area) cursor-p)))) + (defmethod handle-event ((gadget text-field-pane) (event key-press- event)) (let ((gesture (convert-to-gesture event)) (*activation-gestures* (activation-gestures gadget))) Index: stream-output.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/stream-output.lisp,v retrieving revision 1.56 diff -u -r1.56 stream-output.lisp --- stream-output.lisp 13 Aug 2005 14:28:20 -0000 1.56 +++ stream-output.lisp 24 Sep 2005 14:27:07 -0000 @@ -142,7 +142,7 @@ (draw-rectangle* (sheet-medium (cursor-sheet cursor)) x y (+ x width) (+ y height) - :filled t + :filled (slot-value (cursor-sheet cursor) 'armed) :ink +flipping-ink+))))) (defmethod display-cursor ((cursor cursor-mixin) state) @@ -154,7 +154,7 @@ (:draw (draw-rectangle* (sheet-medium (cursor-sheet cursor)) x y (+ x width) (+ y height) - :filled t + :filled (slot-value (cursor-sheet cursor) 'armed) :ink +foreground-ink+ )) (:erase @@ -168,7 +168,7 @@ (draw-rectangle* (sheet-medium (cursor-sheet cursor)) x y (+ x width) (+ y height) - :filled t + :filled (slot-value (cursor-sheet cursor) 'armed) :ink +background-ink+)))))) ;;; Standard-Text-Cursor class -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From idurand at labri.fr Thu Sep 29 12:29:19 2005 From: idurand at labri.fr (Irene DURAND) Date: Thu, 29 Sep 2005 14:29:19 +0200 Subject: [mcclim-devel] mcclim + sbcl Message-ID: <433BDE1F.5080404@labri.fr> Hello, Back in Bordeaux after one year in Germany I am trying to setup things here. Formerly I used CMUCL but Robert Strandh told me that I should use rather SBCL. So I would like to have sbcl + mcclim + slime. I have read that there are problems with certain combinations of versions. So my question is which combination of version number should work. Right now I have SBCL 0.9.5 with CLX clx_0.7.1 and the latest version of MCCLIM and I fail compiling MCCLIM. I plan to use MCCLIM with my students and I am desesperate to have something running. Can anyone help me? -- Ir?ne DURAND http://dept-info.labri.u-bordeaux.fr/~idurand This is SBCL 0.9.5, 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. * (require 'asdf) ("ASDF") * (require 'clx) ; loading system definition from ; /usr/labri/idurand/Common-Lisp/sbcl/lib/sbcl/systems/sb-bsd-sockets.asd into ; # ; registering # as SB-BSD-SOCKETS ; registering # as SB-BSD-SOCKETS-TESTS ("SB-GROVEL" "SB-BSD-SOCKETS") * (load "/usr/labri/idurand/Common-Lisp/mcclim/system.lisp") ; in: LAMBDA NIL ; (OR "Lisp-Dep/mp-nil") ; ==> ; "Lisp-Dep/mp-nil" ; ; note: deleting unreachable code ; ; compilation unit finished ; printed 1 note debugger invoked on a ASDF:DUPLICATE-NAMES in thread #: Condition ASDF:DUPLICATE-NAMES was signalled. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (ASDF::PARSE-COMPONENT-FORM NIL (:MODULE "scigraph" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/" :DEPENDS-ON (:CLIM :CLIM-LOOKS) :SERIAL T :COMPONENTS ((:FILE "package" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/package.lisp") (:FILE "feature-case" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/feature-case.lisp") (:FILE "macros" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/macros.lisp") (:FILE "tv" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/tv.lisp") (:FILE "draw" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/draw.lisp") (:FILE "present" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/present.lisp") (:FILE "extensions" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/extensions.lisp") (:FILE "wholine" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/wholine.lisp") (:FILE "export" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/export.lisp") (:FILE "package" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/scigraph/package.lisp") (:FILE "copy" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/scigraph/copy.lisp") (:FILE "dump" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/scigraph/dump.lisp") ...))) 0] -------------- next part -------------- An HTML attachment was scrubbed... URL: From amoroso at mclink.it Thu Sep 29 16:03:12 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Thu, 29 Sep 2005 18:03:12 +0200 Subject: [mcclim-devel] mcclim + sbcl References: <433BDE1F.5080404@labri.fr> Message-ID: <87oe6bsvy7.fsf@plato.moon.paoloamoroso.it> Irene DURAND writes: > I have read that there are problems with certain combinations of versions. > So my question is which combination of version number should work. Well, probably CVS McCLIM and CVS SBCL :) > Right now I have SBCL 0.9.5 with CLX clx_0.7.1 and the latest version > of MCCLIM > and I fail compiling MCCLIM. [...] > * (load "/usr/labri/idurand/Common-Lisp/mcclim/system.lisp") > ; in: LAMBDA NIL > ; (OR "Lisp-Dep/mp-nil") > ; ==> > ; "Lisp-Dep/mp-nil" > ; ; note: deleting unreachable code > ; ; compilation unit finished > ; printed 1 note > > debugger invoked on a ASDF:DUPLICATE-NAMES in thread # thread" {90033C9}>: > Condition ASDF:DUPLICATE-NAMES was signalled. Try this: (push "/usr/labri/idurand/Common-Lisp/mcclim/" asdf:*central-registry*) (asdf:operate 'asdf:load-op :mcclim) Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Fri Sep 30 16:03:15 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 30 Sep 2005 17:03:15 +0100 Subject: [mcclim-devel] Re: [climacs-devel] Small patch to commands.lisp In-Reply-To: <431F0EC6.5060505@yahoo.com> (John Q. Splittist's message of "Wed, 07 Sep 2005 17:01:10 +0100") References: <431E9D14.8080008@yahoo.com> <431F0EC6.5060505@yahoo.com> Message-ID: John Q Splittist writes: > Christophe Rhodes wrote: > >> I wonder if it would be possible to add a test case for the failure >> you've seen in the Tests/ directory? > > I'm not sure whether this fits the bill, but here is an attempt. > Corrections, suggestions etc. welcome. I guess three weeks is an adequate timescale for corrections and suggestions for a one-line patch with tests, so I've merged your patch and test file (adding a completely untested extra test). Thanks. Cheers, Christophe