From chandler at unmutual.info Sat Dec 11 23:01:50 2004 From: chandler at unmutual.info (Brian Mastenbrook) Date: Sat, 11 Dec 2004 17:01:50 -0600 Subject: [mcclim-devel] Hello, world Message-ID: It appears that most of the move to the new common-lisp.net hosting is done. I doubt many people have subscribed already, but if you have, this hello world message should kick off the new list. I've reorganized the McCLIM page at http://common-lisp.net/project/mcclim/ . I will also set up a redirect for http://www.mcclim.org/ which is now also our domain. Here's to a productive fresh start on cl.net! -- Brian Mastenbrook http://www.iscblog.info/ http://www.cs.indiana.edu/~bmastenb/ From strandh at labri.fr Mon Dec 13 12:01:08 2004 From: strandh at labri.fr (Robert Strandh) Date: Mon, 13 Dec 2004 13:01:08 +0100 Subject: [mcclim-devel] add-command-to-command-table Message-ID: <16829.33924.109656.467781@serveur5.labri.fr> Hello, add-command-to-command-table is supposed to take a command-table designator as argument, but in fact, this does not work. I suspect that is because in the body of this function `command-table' (the parameter) is used instead of `table' which holds the value after a call to find-command-table. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Mon Dec 13 11:39:39 2004 From: strandh at labri.fr (Robert Strandh) Date: Mon, 13 Dec 2004 12:39:39 +0100 Subject: [mcclim-devel] signature of lookup-keystroke-item Message-ID: <16829.32635.496290.189462@serveur5.labri.fr> Hello, Is there any reason why in the implementation, lookup-keystroke-item has an keyword argument (errorp t), whereas that is not the case in the specification? -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From moore at bricoworks.com Mon Dec 13 12:09:43 2004 From: moore at bricoworks.com (Timothy Moore) Date: Mon, 13 Dec 2004 13:09:43 +0100 Subject: [mcclim-devel] add-command-to-command-table In-Reply-To: <16829.33924.109656.467781@serveur5.labri.fr> References: <16829.33924.109656.467781@serveur5.labri.fr> Message-ID: I'm about to check in a fix to commands.lisp, so I'll take a quick look. Tim On Dec 13, 2004, at 1:01 PM, Robert Strandh wrote: > Hello, > > add-command-to-command-table is supposed to take a command-table > designator as argument, but in fact, this does not work. I suspect > that is because in the body of this function `command-table' (the > parameter) is used instead of `table' which holds the value after a > call to find-command-table. > > > -- > 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. > --------------------------------------------------------------------- > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From frido at q-software-solutions.de Wed Dec 15 11:33:09 2004 From: frido at q-software-solutions.de (Friedrich Dominicus) Date: Wed, 15 Dec 2004 12:33:09 +0100 Subject: [mcclim-devel] Troubles compiling McCLIM with Allegro CL 7.0 Message-ID: <874qinssne.fsf@fbigm.here> Dear Mcclim Developers I encountered the following problem while trying to compile mcclim with Allegro CL 7.0 on a Debian box Warning: Variable DEFAULT-TYPE is never used. ; While compiling COM-QUERY-EXIT%ACCEPTOR%0: Error: We don't yet handle ignore of #'EAT-DELIMITER-OR-ACTIVATOR. [condition type: SIMPLE-ERROR] Restart actions (select using :continue): 0: retry the compilation of /home/frido/tests/mcclim/dialog.lisp 1: continue compiling /home/frido/tests/mcclim/dialog.lisp but generate no output file 2: Retry performing # on #. 3: Continue, treating # on # as having been successful. 4: Return to Debug Level 1 (an "abort" restart). 5: Try calling TOP-LEVEL::CD again. 6: Return a value instead of calling TOP-LEVEL::CD. 7: Try calling a function other than TOP-LEVEL::CD. 8: Setf the symbol-function of TOP-LEVEL::CD and call it again. 9: Return to Top Level (an "abort" restart). 10: Abort entirely from this (lisp) process. [changing package from "COMMON-LISP-USER" to "CLIM-INTERNALS"] [2] CLIMI(11): Does anyone have tried to compile mcclim with Allegro successfully? Regards Friedrich From bruno at clisp.org Sat Dec 18 14:18:53 2004 From: bruno at clisp.org (Bruno Haible) Date: Sat, 18 Dec 2004 15:18:53 +0100 Subject: [mcclim-devel] misc warning fixes Message-ID: <200412181518.53894.bruno@clisp.org> CLISP also gives some warning for unused variables and parameters. Here I fixed the first three warnings, but there are many more of this kind. diff -r -c3 mcclim.orig/Backends/PostScript/font.lisp mcclim/Backends/PostScript/font.lisp *** mcclim.orig/Backends/PostScript/font.lisp 2004-12-03 12:42:43.000000000 +0100 --- mcclim/Backends/PostScript/font.lisp 2004-12-18 02:14:41.000000000 +0100 *************** *** 66,72 **** (unless end (setq end (length string))) (let* ((font-info (or (gethash font-name *font-metrics*) (error "Unknown font ~S." font-name))) - (char-names (font-info-char-names font-info)) (char-metrics (font-info-char-infos font-info)) (scale (/ size 1000)) (width 0) (upper-width 0) --- 66,71 ---- diff -r -c3 mcclim.orig/Doc/manual.tex mcclim/Doc/manual.tex *** mcclim.orig/Doc/manual.tex 2004-12-13 13:18:06.000000000 +0100 --- mcclim/Doc/manual.tex 2004-12-18 01:29:16.000000000 +0100 *************** *** 326,332 **** contains McCLIM. If you use CMUCL or SBCL, you either need a \texttt{core} file that already has McCLIM in it, or else, you have to load the McCLIM compiled files that make up the McCLIM distribution. ! The fist solution is recommended so as to avoid having to load the McCLIM files each time you start your CLIM application. To execute the application, load the file containing your code --- 326,332 ---- contains McCLIM. If you use CMUCL or SBCL, you either need a \texttt{core} file that already has McCLIM in it, or else, you have to load the McCLIM compiled files that make up the McCLIM distribution. ! The first solution is recommended so as to avoid having to load the McCLIM files each time you start your CLIM application. To execute the application, load the file containing your code diff -r -c3 mcclim.orig/input.lisp mcclim/input.lisp *** mcclim.orig/input.lisp 2004-10-31 02:46:31.000000000 +0100 --- mcclim/input.lisp 2004-12-18 01:51:54.000000000 +0100 *************** *** 533,539 **** (:documentation "Returns the number of pixels respresenting a 'line', used to computed distance to scroll in response to mouse wheel events.")) ! (defmethod scroll-quantum (pane) 10) (defmethod dispatch-event :around ((sheet mouse-wheel-scroll-mixin) (event pointer-button-press-event)) --- 533,541 ---- (:documentation "Returns the number of pixels respresenting a 'line', used to computed distance to scroll in response to mouse wheel events.")) ! (defmethod scroll-quantum (pane) ! (declare (ignore pane)) ! 10) (defmethod dispatch-event :around ((sheet mouse-wheel-scroll-mixin) (event pointer-button-press-event)) diff -r -c3 mcclim.orig/presentation-defs.lisp mcclim/presentation-defs.lisp *** mcclim.orig/presentation-defs.lisp 2004-12-05 20:37:52.000000000 +0100 --- mcclim/presentation-defs.lisp 2004-12-18 02:19:26.000000000 +0100 *************** *** 468,474 **** (define-default-presentation-method presentation-type-history-for-stream (type stream) ! (declare (ignore stream)) nil) ;;; method for clim-stream-pane in panes.lisp --- 468,474 ---- (define-default-presentation-method presentation-type-history-for-stream (type stream) ! (declare (ignore type stream)) nil) ;;; method for clim-stream-pane in panes.lisp diff -r -c3 mcclim.orig/text-selection.lisp mcclim/text-selection.lisp *** mcclim.orig/text-selection.lisp 2004-12-07 05:49:51.000000000 +0100 --- mcclim/text-selection.lisp 2004-12-18 02:13:14.000000000 +0100 *************** *** 166,171 **** --- 166,172 ---- (with-sheet-medium (medium pane) (let ((R (region-difference region marked-region))) (with-drawing-options (medium :clipping-region R) + (declare (ignore medium)) (call-next-method pane R)))) (with-sheet-medium (medium pane) (let ((R (region-intersection region marked-region))) From bruno at clisp.org Sat Dec 18 14:16:24 2004 From: bruno at clisp.org (Bruno Haible) Date: Sat, 18 Dec 2004 15:16:24 +0100 Subject: [mcclim-devel] support for clisp (1) Message-ID: <200412181516.24791.bruno@clisp.org> Hi, Appended you find patches for supporting clisp. Part 1 of the patches are the obvious portability things. It should be uncontroversial and adds two files INSTALL.CLISP and Lisp-Dep/fix-clisp.lisp. diff -r -c3 mcclim.orig/Apps/Listener/dev-commands.lisp mcclim/Apps/Listener/dev-commands.lisp *** mcclim.orig/Apps/Listener/dev-commands.lisp 2004-10-18 08:30:37.000000000 +0200 --- mcclim/Apps/Listener/dev-commands.lisp 2004-12-18 02:47:15.000000000 +0100 *************** *** 617,625 **** (defun x-specializer-direct-generic-functions (specializer) ;; FIXME - move to CLIM-MOP #+PCL (pcl::specializer-direct-generic-functions specializer) #+SBCL (sb-pcl::specializer-direct-generic-functions specializer) #+openmcl-partial-mop (openmcl-mop:specializer-direct-generic-functions specializer) ! #-(or PCL SBCL openmcl-partial-mop) (error "Sorry, not supported in your CL implementation. See the function X-SPECIALIZER-DIRECT-GENERIC-FUNCTION if you are interested in fixing this.")) (defun class-funcs (class) --- 617,626 ---- (defun x-specializer-direct-generic-functions (specializer) ;; FIXME - move to CLIM-MOP #+PCL (pcl::specializer-direct-generic-functions specializer) #+SBCL (sb-pcl::specializer-direct-generic-functions specializer) + #+clisp (clos:specializer-direct-generic-functions specializer) #+openmcl-partial-mop (openmcl-mop:specializer-direct-generic-functions specializer) ! #-(or PCL SBCL clisp openmcl-partial-mop) (error "Sorry, not supported in your CL implementation. See the function X-SPECIALIZER-DIRECT-GENERIC-FUNCTION if you are interested in fixing this.")) (defun class-funcs (class) *************** *** 890,896 **** ;; hash table capacity #+cmu (values (lisp::internal-symbol-count package)) #+sbcl (values (sb-int:package-internal-symbol-count package)) ! #-(or cmu sbcl) (portable-internal-symbol-count package)) (defun portable-external-symbol-count (package) (let ((n 0)) --- 891,898 ---- ;; hash table capacity #+cmu (values (lisp::internal-symbol-count package)) #+sbcl (values (sb-int:package-internal-symbol-count package)) ! #+clisp (svref (sys::%record-ref *package* 1) 2) ! #-(or cmu sbcl clisp) (portable-internal-symbol-count package)) (defun portable-external-symbol-count (package) (let ((n 0)) *************** *** 903,909 **** "Return the number of external symbols in PACKAGE." #+cmu (values (lisp::external-symbol-count package)) #+sbcl (values (sb-int:package-external-symbol-count package)) ! #-(or cmu sbcl) (portable-external-symbol-count package)) (defun package-grapher (stream package inferior-fun) "Draw package hierarchy graphs for `Show Package Users' and `Show Used Packages'." --- 905,912 ---- "Return the number of external symbols in PACKAGE." #+cmu (values (lisp::external-symbol-count package)) #+sbcl (values (sb-int:package-external-symbol-count package)) ! #+clisp (svref (sys::%record-ref *package* 0) 2) ! #-(or cmu sbcl clisp) (portable-external-symbol-count package)) (defun package-grapher (stream package inferior-fun) "Draw package hierarchy graphs for `Show Package Users' and `Show Used Packages'." diff -r -c3 mcclim.orig/Apps/Listener/listener.lisp mcclim/Apps/Listener/listener.lisp *** mcclim.orig/Apps/Listener/listener.lisp 2004-11-15 08:07:26.000000000 +0100 --- mcclim/Apps/Listener/listener.lisp 2004-12-18 02:48:55.000000000 +0100 *************** *** 64,70 **** #+sbcl (sb-kernel:dynamic-usage) #+lispworks (getf (system:room-values) :total-allocated) #+openmcl (+ (ccl::%usedbytes) (ccl::%freebytes)) ! #-(or cmu sbcl lispworks openmcl) 0)) (with-text-family (T :serif) (formatting-table (T :x-spacing '(3 :character)) (formatting-row (T) --- 64,71 ---- #+sbcl (sb-kernel:dynamic-usage) #+lispworks (getf (system:room-values) :total-allocated) #+openmcl (+ (ccl::%usedbytes) (ccl::%freebytes)) ! #+clisp (values (sys::%room)) ! #-(or cmu sbcl lispworks openmcl clisp) 0)) (with-text-family (T :serif) (formatting-table (T :x-spacing '(3 :character)) (formatting-row (T) diff -r -c3 mcclim.orig/Apps/Listener/util.lisp mcclim/Apps/Listener/util.lisp *** mcclim.orig/Apps/Listener/util.lisp 2004-07-23 14:36:45.000000000 +0200 --- mcclim/Apps/Listener/util.lisp 2004-12-18 02:54:51.000000000 +0100 *************** *** 64,75 **** --- 64,77 ---- #+sbcl (sb-ext:posix-getenv var) #+lispworks (lw:environment-variable var) #+openmcl (ccl::getenv var) + #+clisp (ext:getenv var) nil)) ;; Need to strip filename/type/version from directory?.. FIXME? (defun change-directory (pathname) "Ensure that the current directory seen by RUN-PROGRAM has changed, and update *default-pathname-defaults*" #+CMU (unix:unix-chdir (namestring pathname)) + #+clisp (ext:cd pathname) ; SBCL FIXME? (setf *default-pathname-defaults* pathname)) *************** *** 154,161 **** :shell-type "/bin/sh" :output-stream output :wait wait) ! #-(or CMU SBCL lispworks) (format T "~&Sorry, don't know how to run programs in your CL.~%")) ;;;; CLIM/UI utilities --- 156,164 ---- :shell-type "/bin/sh" :output-stream output :wait wait) + #+clisp (ext:run-program program :arguments args :wait wait) ! #-(or CMU SBCL lispworks clisp) (format T "~&Sorry, don't know how to run programs in your CL.~%")) ;;;; CLIM/UI utilities diff -r -c3 mcclim.orig/README mcclim/README *** mcclim.orig/README 2003-11-12 00:45:15.000000000 +0100 --- mcclim/README 2004-12-18 01:19:07.000000000 +0100 *************** *** 2,9 **** This is McCLIM, an implementation of the "Common Lisp Interface Manager CLIM II Specification." It currently works on X Windows using ! CLX. It works with CMUCL, SBCL, OpenMCL, Allegro CL and LispWorks. The ! INSTALL files in this directory give instructions for each Lisp implementation. Release notes for each release of McCLIM are in the ReleaseNotes directory. --- 2,9 ---- This is McCLIM, an implementation of the "Common Lisp Interface Manager CLIM II Specification." It currently works on X Windows using ! CLX. It works with CMUCL, SBCL, CLISP, OpenMCL, Allegro CL and LispWorks. ! The INSTALL files in this directory give instructions for each Lisp implementation. Release notes for each release of McCLIM are in the ReleaseNotes directory. diff -r -c3 mcclim.orig/describe.lisp mcclim/describe.lisp *** mcclim.orig/describe.lisp 2004-11-15 05:47:41.000000000 +0100 --- mcclim/describe.lisp 2004-12-18 01:22:07.000000000 +0100 *************** *** 70,76 **** (let ((arglist #+excl (excl:arglist (symbol-function thing)) #+cmu (kernel:%function-arglist (symbol-function thing)) #+sbcl (sb-kernel:%simple-fun-arglist (symbol-function thing)) ! #-(or excl cmu sbcl) "( ??? )")) (when arglist (clim:present arglist (clim:presentation-type-of arglist) --- 70,77 ---- (let ((arglist #+excl (excl:arglist (symbol-function thing)) #+cmu (kernel:%function-arglist (symbol-function thing)) #+sbcl (sb-kernel:%simple-fun-arglist (symbol-function thing)) ! #+clisp (ext:arglist (symbol-function thing)) ! #-(or excl cmu sbcl clisp) "( ??? )")) (when arglist (clim:present arglist (clim:presentation-type-of arglist) diff -r -c3 mcclim.orig/package.lisp mcclim/package.lisp *** mcclim.orig/package.lisp 2004-12-07 05:49:51.000000000 +0100 --- mcclim/package.lisp 2004-12-18 01:40:42.000000000 +0100 *************** *** 185,193 **** #:with-standard-io-syntax #:write #:write-byte #:write-char #:write-line #:write-sequence #:write-string #:write-to-string #:y-or-n-p #:yes-or-no-p #:zerop)) (packages - #+clisp '(:common-lisp :clos) #+gcl '(:lisp :pcl) ! #-(or clisp gcl) '(:common-lisp)) (gray-symbols '(#:fundamental-stream #:fundamental-input-stream --- 185,192 ---- #:with-standard-io-syntax #:write #:write-byte #:write-char #:write-line #:write-sequence #:write-string #:write-to-string #:y-or-n-p #:yes-or-no-p #:zerop)) (packages #+gcl '(:lisp :pcl) ! #-(or gcl) '(:common-lisp)) (gray-symbols '(#:fundamental-stream #:fundamental-input-stream *************** *** 218,224 **** #:stream-read-byte #:stream-write-byte )) (gray-packages ! `(#+clisp ,@'(:lisp) #+cmu ,@'(:ext) #+mcl ,@'(:ccl) #+allegro ,@'(:common-lisp :excl :stream) --- 217,223 ---- #:stream-read-byte #:stream-write-byte )) (gray-packages ! `(#+clisp ,@'(:gray) #+cmu ,@'(:ext) #+mcl ,@'(:ccl) #+allegro ,@'(:common-lisp :excl :stream) diff -r -c3 mcclim.orig/system.lisp mcclim/system.lisp *** mcclim.orig/system.lisp 2004-12-07 05:49:51.000000000 +0100 --- mcclim/system.lisp 2004-12-18 01:36:56.000000000 +0100 *************** *** 81,86 **** --- 81,87 ---- #+sbcl "Lisp-Dep/fix-sbcl" #+openmcl "Lisp-Dep/fix-openmcl" #+lispworks "Lisp-Dep/fix-lispworks" + #+clisp "Lisp-Dep/fix-clisp" "package") (clim-defsystem (:clim-core :depends-on (:clim-lisp)) diff -r -c3 mcclim.orig/utils.lisp mcclim/utils.lisp *** mcclim.orig/utils.lisp 2004-10-06 14:03:56.000000000 +0200 --- mcclim/utils.lisp 2004-12-18 01:46:28.000000000 +0100 *************** *** 22,28 **** (defun get-environment-variable (string) #+excl (sys:getenv string) #+cmu (cdr (assoc string ext:*environment-list* :test #'string=)) ! #+clisp (sys::getenv (string string)) #+sbcl (sb-ext::posix-getenv string) #+openmcl (ccl::getenv string) #+lispworks (lw:environment-variable string) --- 22,28 ---- (defun get-environment-variable (string) #+excl (sys:getenv string) #+cmu (cdr (assoc string ext:*environment-list* :test #'string=)) ! #+clisp (ext:getenv (string string)) #+sbcl (sb-ext::posix-getenv string) #+openmcl (ccl::getenv string) #+lispworks (lw:environment-variable string) *** /dev/null 2003-09-23 19:59:22.000000000 +0200 --- mcclim/INSTALL.CLISP 2004-12-18 11:37:30.000000000 +0100 *************** *** 0 **** --- 1,54 ---- + Install instructions for GNU CLISP + ---------------------------------- + + 1. Get clisp-20041218 or newer. Build it with option --with-module=clx/mit-clx. + + 2. Get a copy of the ASDF package. Compile it: + $ clisp -c $ASDF/asdf.lisp + + 3. Start + $ clisp -K full -i $ASDF/asdf.fas -i system.lisp + + 4. Load the system (which will also compile it): + + > (asdf:operate 'asdf:load-op :clim) ;; Build CLIM + > (asdf:operate 'asdf:load-op :clim-clx) ;; Build a backend + > (asdf:operate 'asdf:load-op :clim-examples) + + The first two steps can be done in one step with the :clim-clx-user target: + (asdf:operate 'asdf:load-op :clim-clx-user) + + 5. At a later date, after everything is compiled, load the compiled system: + + > (asdf:operate 'asdf:load-op :clim) ;; Load CLIM + > (asdf:operate 'asdf:load-op :clim-clx) ;; Load backend + + + Running the demos + ----------------- + + 1. Run the calculator demo + + (clim-demo::calculator) + + This demo is self-explanatory. + + When you get tired of it, hit Ctrl-C in the Lisp listener. + + 2. Run the menu demo + + (menutest::menutest) + + This demo is self-explanatory. + + When you get tired of it, hit Ctrl-C in the Lisp listener. + + 3. Run the slider demo + + (clim-demo::colorslider) + + You should see three sliders on the left and a color area on the right. + Use the three sliders to adjust RGB values to obtain a color. + + When you get tired of it - you know... + *** /dev/null 2003-09-23 19:59:22.000000000 +0200 --- mcclim/Lisp-Dep/fix-clisp.lisp 2004-12-18 02:04:36.000000000 +0100 *************** *** 0 **** --- 1,20 ---- + (defpackage #:clim-mop + (:use #:clos)) + + (eval-when (:compile-toplevel :load-toplevel :execute) + (loop for sym being the symbols of :clim-mop + do (export sym :clim-mop))) + + ;; CLIM expects INPUT-STREAM-P to be a generic function. + (unless (typep #'input-stream-p 'generic-function) + (setf (fdefinition 'gray::original-input-stream-p) #'input-stream-p) + (fmakunbound 'input-stream-p) + (defgeneric input-stream-p (stream) + (:method ((stream stream)) (gray::original-input-stream-p stream)))) + + ;; CLIM expects OUTPUT-STREAM-P to be a generic function. + (unless (typep #'output-stream-p 'generic-function) + (setf (fdefinition 'gray::original-output-stream-p) #'output-stream-p) + (fmakunbound 'output-stream-p) + (defgeneric output-stream-p (stream) + (:method ((stream stream)) (gray::original-output-stream-p stream)))) From bruno at clisp.org Sat Dec 18 14:18:02 2004 From: bruno at clisp.org (Bruno Haible) Date: Sat, 18 Dec 2004 15:18:02 +0100 Subject: [mcclim-devel] support for clisp (2) Message-ID: <200412181518.02066.bruno@clisp.org> Part 2 of the patches are because clisp has UNICODE support but doesn't define an EXTERNAL-FORMAT package. (It has a CHARSET package.) And McCLIM doesn't provide a DEFPACKAGE declaration for the package EXTERNAL-FORMAT. This is a quick hack to get things running with ASCII characters. I'm not in the position of fixing this code because - Fontsets are outdated technology. Modern renderers use libXft. - The ksc5601-code-to-font-index function is incomplete. It lacks not only the arrays ksc5601-uni2indx-page00 etc. It lacks also a notice "Copyright (C) 1999-2002 Free Software Foundation, Inc. This function is taken from the GNU LIBICONV Library." I mean, I recognize code that I have written in 1999 even if it's translated into Lisp in 2004. - Assuming that the only languages of the world are English and Korean is, hmm, not yet realistic. English and Chinese as sole surviving languages is more probable in the long run. diff -r -c3 mcclim.orig/Backends/CLX/medium.lisp mcclim/Backends/CLX/medium.lisp *** mcclim.orig/Backends/CLX/medium.lisp 2004-04-23 21:29:49.000000000 +0200 --- mcclim/Backends/CLX/medium.lisp 2004-12-18 02:40:27.000000000 +0100 *************** *** 39,45 **** :initform nil) (picture :initform nil) ! #+unicode (fontset :initform nil :accessor medium-fontset) --- 39,45 ---- :initform nil) (picture :initform nil) ! #+(and allegro unicode) (fontset :initform nil :accessor medium-fontset) *************** *** 55,61 **** ;;; secondary methods for changing text styles and line styles ! #-unicode (defmethod (setf medium-text-style) :before (text-style (medium clx-medium)) (with-slots (gc) medium (when gc --- 55,61 ---- ;;; secondary methods for changing text styles and line styles ! #-(and allegro unicode) (defmethod (setf medium-text-style) :before (text-style (medium clx-medium)) (with-slots (gc) medium (when gc *************** *** 64,70 **** (setf (xlib:gcontext-font gc) (text-style-to-X-font (port medium) (medium-text-style medium)))))))) ! #+unicode (defmethod (setf medium-text-style) :before (text-style (medium clx-medium)) (with-slots (fontset) medium (let ((old-text-style (medium-text-style medium))) --- 64,70 ---- (setf (xlib:gcontext-font gc) (text-style-to-X-font (port medium) (medium-text-style medium)))))))) ! #+(and allegro unicode) (defmethod (setf medium-text-style) :before (text-style (medium clx-medium)) (with-slots (fontset) medium (let ((old-text-style (medium-text-style medium))) *************** *** 165,173 **** (xlib:gcontext-dashes gc) (if (eq dashes t) 3 dashes))))) (setf (xlib:gcontext-function gc) boole-1) ! #-unicode (setf (xlib:gcontext-font gc) (text-style-to-X-font port (medium-text-style medium))) ! #+unicode (setf (medium-fontset medium) (text-style-to-X-fontset port (medium-text-style medium))) (setf (xlib:gcontext-foreground gc) (X-pixel port ink) (xlib:gcontext-background gc) (X-pixel port (medium-background medium))) --- 165,173 ---- (xlib:gcontext-dashes gc) (if (eq dashes t) 3 dashes))))) (setf (xlib:gcontext-function gc) boole-1) ! #-(and allegro unicode) (setf (xlib:gcontext-font gc) (text-style-to-X-font port (medium-text-style medium))) ! #+(and allegro unicode) (setf (medium-fontset medium) (text-style-to-X-fontset port (medium-text-style medium))) (setf (xlib:gcontext-foreground gc) (X-pixel port ink) (xlib:gcontext-background gc) (X-pixel port (medium-background medium))) *************** *** 344,350 **** (let* ((line-style (medium-line-style ,medium)) (ink (medium-ink ,medium)) (gc (medium-gcontext ,medium ink)) ! #+unicode (*fontset* (or (medium-fontset ,medium) (setf (medium-fontset ,medium) (text-style-to-X-fontset (port ,medium) *default-text-style*))))) --- 344,350 ---- (let* ((line-style (medium-line-style ,medium)) (ink (medium-ink ,medium)) (gc (medium-gcontext ,medium ink)) ! #+(and allegro unicode) (*fontset* (or (medium-fontset ,medium) (setf (medium-fontset ,medium) (text-style-to-X-fontset (port ,medium) *default-text-style*))))) *************** *** 608,655 **** ;;; ;;; Methods for text styles ! #-unicode (defmethod text-style-ascent (text-style (medium clx-medium)) (let ((font (text-style-to-X-font (port medium) text-style))) (xlib:font-ascent font))) ! #+unicode (defmethod text-style-ascent (text-style (medium clx-medium)) (let ((fontset (text-style-to-X-fontset (port medium) text-style))) (fontset-ascent fontset))) ! #-unicode (defmethod text-style-descent (text-style (medium clx-medium)) (let ((font (text-style-to-X-font (port medium) text-style))) (xlib:font-descent font))) ! #+unicode (defmethod text-style-descent (text-style (medium clx-medium)) (let ((fontset (text-style-to-X-fontset (port medium) text-style))) (fontset-descent fontset))) ! #-unicode (defmethod text-style-height (text-style (medium clx-medium)) (let ((font (text-style-to-X-font (port medium) text-style))) (+ (xlib:font-ascent font) (xlib:font-descent font)))) ! #+unicode (defmethod text-style-height (text-style (medium clx-medium)) (let ((fontset (text-style-to-X-fontset (port medium) text-style))) (fontset-height fontset))) ! #-unicode (defmethod text-style-character-width (text-style (medium clx-medium) char) (xlib:char-width (text-style-to-X-font (port medium) text-style) (char-code char))) ! #+unicode (defmethod text-style-character-width (text-style (medium clx-medium) char) (fontset-point-width (char-code char) (text-style-to-X-fontset (port medium) text-style))) (defmethod text-style-width (text-style (medium clx-medium)) (text-style-character-width text-style medium #\m)) ! #-unicode (defun translate (src src-start src-end afont dst dst-start) ;; This is for replacing the clx-translate-default-function ;; who does'nt know about accentated characters because --- 608,655 ---- ;;; ;;; Methods for text styles ! #-(and allegro unicode) (defmethod text-style-ascent (text-style (medium clx-medium)) (let ((font (text-style-to-X-font (port medium) text-style))) (xlib:font-ascent font))) ! #+(and allegro unicode) (defmethod text-style-ascent (text-style (medium clx-medium)) (let ((fontset (text-style-to-X-fontset (port medium) text-style))) (fontset-ascent fontset))) ! #-(and allegro unicode) (defmethod text-style-descent (text-style (medium clx-medium)) (let ((font (text-style-to-X-font (port medium) text-style))) (xlib:font-descent font))) ! #+(and allegro unicode) (defmethod text-style-descent (text-style (medium clx-medium)) (let ((fontset (text-style-to-X-fontset (port medium) text-style))) (fontset-descent fontset))) ! #-(and allegro unicode) (defmethod text-style-height (text-style (medium clx-medium)) (let ((font (text-style-to-X-font (port medium) text-style))) (+ (xlib:font-ascent font) (xlib:font-descent font)))) ! #+(and allegro unicode) (defmethod text-style-height (text-style (medium clx-medium)) (let ((fontset (text-style-to-X-fontset (port medium) text-style))) (fontset-height fontset))) ! #-(and allegro unicode) (defmethod text-style-character-width (text-style (medium clx-medium) char) (xlib:char-width (text-style-to-X-font (port medium) text-style) (char-code char))) ! #+(and allegro unicode) (defmethod text-style-character-width (text-style (medium clx-medium) char) (fontset-point-width (char-code char) (text-style-to-X-fontset (port medium) text-style))) (defmethod text-style-width (text-style (medium clx-medium)) (text-style-character-width text-style medium #\m)) ! #-(and allegro unicode) (defun translate (src src-start src-end afont dst dst-start) ;; This is for replacing the clx-translate-default-function ;; who does'nt know about accentated characters because *************** *** 694,700 **** ; It's just a proof of concept, I'll try not to commit it :] ; If it does get committed, it shouldn't affect anyone much... ! #+unicode (defun translate (source source-start source-end initial-font destination destination-start) ; do the first character especially (let* ((code (char-code (char source source-start))) --- 694,700 ---- ; It's just a proof of concept, I'll try not to commit it :] ; If it does get committed, it shouldn't affect anyone much... ! #+(and allegro unicode) (defun translate (source source-start source-end initial-font destination destination-start) ; do the first character especially (let* ((code (char-code (char source source-start))) *************** *** 724,737 **** (return (values src nil)))))))))) (values source-start nil)))) ! #+unicode (in-package :external-format) ! #+unicode (defun ascii-code-to-font-index (code) (values code (<= #x00 code #x7f))) ! #+unicode (defun ksc5601-code-to-font-index (wc) (labels ((illegal-sequence () (error "ksc5601-wctomb")) --- 724,737 ---- (return (values src nil)))))))))) (values source-start nil)))) ! #+(and allegro unicode) (in-package :external-format) ! #+(and allegro unicode) (defun ascii-code-to-font-index (code) (values code (<= #x00 code #x7f))) ! #+(and allegro unicode) (defun ksc5601-code-to-font-index (wc) (labels ((illegal-sequence () (error "ksc5601-wctomb")) *************** *** 768,777 **** c) (illegal-sequence)))))) ! #+unicode (in-package :clim-clx) ! #-unicode (defmethod text-size ((medium clx-medium) string &key text-style (start 0) end) (when (characterp string) (setf string (make-string 1 :initial-element string))) --- 768,777 ---- c) (illegal-sequence)))))) ! #+(and allegro unicode) (in-package :clim-clx) ! #-(and allegro unicode) (defmethod text-size ((medium clx-medium) string &key text-style (start 0) end) (when (characterp string) (setf string (make-string 1 :initial-element string))) *************** *** 809,815 **** direction first-not-done)) (values width (+ ascent descent) width 0 ascent)) )))))) ) ! #+unicode (defmethod text-size ((medium clx-medium) string &key text-style (start 0) end) (when (characterp string) (setf string (make-string 1 :initial-element string))) --- 809,815 ---- direction first-not-done)) (values width (+ ascent descent) width 0 ascent)) )))))) ) ! #+(and allegro unicode) (defmethod text-size ((medium clx-medium) string &key text-style (start 0) end) (when (characterp string) (setf string (make-string 1 :initial-element string))) *************** *** 850,856 **** direction first-not-done)) (values width (+ ascent descent) width 0 ascent)) )))))) ) ! #-unicode (defmethod medium-draw-text* ((medium clx-medium) string x y start end align-x align-y --- 850,856 ---- direction first-not-done)) (values width (+ ascent descent) width 0 ascent)) )))))) ) ! #-(and allegro unicode) (defmethod medium-draw-text* ((medium clx-medium) string x y start end align-x align-y *************** *** 884,890 **** :start start :end end :translate #'translate))))))) ! #+unicode (defmethod medium-draw-text* ((medium clx-medium) string x y start end align-x align-y --- 884,890 ---- :start start :end end :translate #'translate))))))) ! #+(and allegro unicode) (defmethod medium-draw-text* ((medium clx-medium) string x y start end align-x align-y diff -r -c3 mcclim.orig/Backends/CLX/port.lisp mcclim/Backends/CLX/port.lisp *** mcclim.orig/Backends/CLX/port.lisp 2004-12-11 22:15:22.000000000 +0100 --- mcclim/Backends/CLX/port.lisp 2004-12-18 11:41:47.000000000 +0100 *************** *** 893,899 **** (defvar *fontset* nil) ! #-unicode (defmethod text-style-mapping ((port clx-port) text-style &optional character-set) (declare (ignore character-set)) --- 893,899 ---- (defvar *fontset* nil) ! #-(and allegro unicode) (defmethod text-style-mapping ((port clx-port) text-style &optional character-set) (declare (ignore character-set)) *************** *** 928,934 **** (open-font (clx-port-display port) font-name))) font-name)))))) ! #+unicode (defun build-english-font-name (text-style) (multiple-value-bind (family face size language) (text-style-components text-style) --- 928,934 ---- (open-font (clx-port-display port) font-name))) font-name)))))) ! #+(and allegro unicode) (defun build-english-font-name (text-style) (multiple-value-bind (family face size language) (text-style-components text-style) *************** *** 955,961 **** family-name face-name size-number))) font-name)))) ! #+unicode (defun build-korean-font-name (text-style) (multiple-value-bind (family face size language) (text-style-components text-style) --- 955,961 ---- family-name face-name size-number))) font-name)))) ! #+(and allegro unicode) (defun build-korean-font-name (text-style) (multiple-value-bind (family face size language) (text-style-components text-style) *************** *** 986,992 **** (format nil "-~A-*-*-~D-*-*-*-*-*-ksx1001.1997-*" font size-number)))) ; this needs much refactoring... FIXME ! #+unicode (defmethod text-style-mapping ((port clx-port) text-style &optional character-set) (declare (ignore character-set)) --- 986,992 ---- (format nil "-~A-*-*-~D-*-*-*-*-*-ksx1001.1997-*" font size-number)))) ; this needs much refactoring... FIXME ! #+(and allegro unicode) (defmethod text-style-mapping ((port clx-port) text-style &optional character-set) (declare (ignore character-set)) *************** *** 1026,1059 **** (cons font-name (open-font (clx-port-display port) font-name))) font-name) ! #-unicode (defun text-style-to-X-font (port text-style) (let ((text-style (parse-text-style text-style))) (text-style-mapping port text-style) (cdr (gethash text-style (port-text-style-mappings port))))) ! #+unicode (defun text-style-to-X-fontset (port text-style) (let ((text-style (parse-text-style text-style))) (text-style-mapping port text-style) (cdr (gethash text-style (port-text-style-mappings port))))) ! #-unicode (defmethod port-character-width ((port clx-port) text-style char) (let* ((font (text-style-to-X-font port text-style)) (width (xlib:char-width font (char-code char)))) width)) ! #+unicode (defmethod port-character-width ((port clx-port) text-style char) (fontset-point-width (char-code char) (text-style-to-X-fontset port text-style))) ! #-unicode (defmethod port-string-width ((port clx-port) text-style string &key (start 0) end) (xlib:text-width (text-style-to-X-font port text-style) string :start start :end end)) ! #+unicode ; this requires a translator and so on. (defmethod port-string-width ((port clx-port) text-style string &key (start 0) end) (let ((*fontset* (text-style-to-X-fontset port text-style))) (xlib:text-width nil string :start start :end end :translator #'translate))) --- 1026,1059 ---- (cons font-name (open-font (clx-port-display port) font-name))) font-name) ! #-(and allegro unicode) (defun text-style-to-X-font (port text-style) (let ((text-style (parse-text-style text-style))) (text-style-mapping port text-style) (cdr (gethash text-style (port-text-style-mappings port))))) ! #+(and allegro unicode) (defun text-style-to-X-fontset (port text-style) (let ((text-style (parse-text-style text-style))) (text-style-mapping port text-style) (cdr (gethash text-style (port-text-style-mappings port))))) ! #-(and allegro unicode) (defmethod port-character-width ((port clx-port) text-style char) (let* ((font (text-style-to-X-font port text-style)) (width (xlib:char-width font (char-code char)))) width)) ! #+(and allegro unicode) (defmethod port-character-width ((port clx-port) text-style char) (fontset-point-width (char-code char) (text-style-to-X-fontset port text-style))) ! #-(and allegro unicode) (defmethod port-string-width ((port clx-port) text-style string &key (start 0) end) (xlib:text-width (text-style-to-X-font port text-style) string :start start :end end)) ! #+(and allegro unicode) ; this requires a translator and so on. (defmethod port-string-width ((port clx-port) text-style string &key (start 0) end) (let ((*fontset* (text-style-to-X-fontset port text-style))) (xlib:text-width nil string :start start :end end :translator #'translate))) From chandler at unmutual.info Sat Dec 18 20:53:50 2004 From: chandler at unmutual.info (Brian Mastenbrook) Date: Sat, 18 Dec 2004 14:53:50 -0600 Subject: [mcclim-devel] Write access for Bruno Haible Message-ID: Robert Strandh has suggested that Bruno Haible be given CVS write access so he can commit his clisp patches and otherwise maintain clisp support. Do you all think that's a good idea? If so I'll ask Mario or Dan to add him to the project. -- Brian Mastenbrook http://www.iscblog.info/ http://www.cs.indiana.edu/~bmastenb/ From daly at idsi.net Sun Dec 19 06:59:39 2004 From: daly at idsi.net (root) Date: Sun, 19 Dec 2004 01:59:39 -0500 Subject: [mcclim-devel] GCL and mcclim Message-ID: <200412190659.iBJ6xdh24807@localhost.localdomain> Is there any effort to port mcclim to GCL? Is there any effort to support mcclim on Windows? I ask because I'd like to rewrite the graphics for Axiom (http://axiom.axiom-developer.org) in lisp in a portable way. Tim Daly daly at idsi.net From amoroso at mclink.it Sun Dec 19 10:31:09 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Sun, 19 Dec 2004 11:31:09 +0100 Subject: [mcclim-devel] GCL and mcclim In-Reply-To: <200412190659.iBJ6xdh24807@localhost.localdomain> (daly@idsi.net's message of "Sun, 19 Dec 2004 01:59:39 -0500") References: <200412190659.iBJ6xdh24807@localhost.localdomain> Message-ID: <87d5x6h95e.fsf@plato.moon.paoloamoroso.it> root writes: > Is there any effort to support mcclim on Windows? > > I ask because I'd like to rewrite the graphics for Axiom > (http://axiom.axiom-developer.org) in lisp in a portable way. Brian Mastenbrook has some ideas on how this might be done: McCLIM for CLISP http://www.iscblog.info/blog/display/20 Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From moore at bricoworks.com Sun Dec 19 10:20:59 2004 From: moore at bricoworks.com (Timothy Moore) Date: Sun, 19 Dec 2004 11:20:59 +0100 Subject: [mcclim-devel] Write access for Bruno Haible In-Reply-To: References: Message-ID: It's fine with me. Tim On Dec 18, 2004, at 9:53 PM, Brian Mastenbrook wrote: > Robert Strandh has suggested that Bruno Haible be given CVS write > access so he can commit his clisp patches and otherwise maintain clisp > support. Do you all think that's a good idea? If so I'll ask Mario or > Dan to add him to the project. > -- > Brian Mastenbrook > http://www.iscblog.info/ > http://www.cs.indiana.edu/~bmastenb/ > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From strandh at labri.fr Sun Dec 19 11:13:48 2004 From: strandh at labri.fr (Robert Strandh) Date: Sun, 19 Dec 2004 12:13:48 +0100 Subject: [mcclim-devel] GCL and mcclim In-Reply-To: <200412190659.iBJ6xdh24807@localhost.localdomain> References: <200412190659.iBJ6xdh24807@localhost.localdomain> Message-ID: <16837.25196.306721.607965@serveur5.labri.fr> Hello, root writes: > Is there any effort to port mcclim to GCL? Not that I am aware of. The only potential problem would be how well GCL implements the MOP. Apparently, McCLIM now runs on CLISP since someone recently implemented the lacking MOP features. > Is there any effort to support mcclim on Windows? Again, not that I am aware of. > I ask because I'd like to rewrite the graphics for Axiom > (http://axiom.axiom-developer.org) in lisp in a portable way. McCLIM would be the perfect route for that. But someone would have to be willing to put in the effort to write the back-end for Windows. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Sun Dec 19 12:06:03 2004 From: strandh at labri.fr (Robert Strandh) Date: Sun, 19 Dec 2004 13:06:03 +0100 Subject: [mcclim-devel] support for clisp (1) In-Reply-To: <200412181516.24791.bruno@clisp.org> References: <200412181516.24791.bruno@clisp.org> Message-ID: <16837.28331.961306.287350@serveur5.labri.fr> Bruno, Mario Mommer will give you write access to the McCLIM CVS so that you can check in these modifications and continue to help make McCLIM work with CLISP. Nice work, -- 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 bruno at clisp.org Mon Dec 20 15:54:09 2004 From: bruno at clisp.org (Bruno Haible) Date: Mon, 20 Dec 2004 16:54:09 +0100 Subject: [mcclim-devel] support for clisp (1) In-Reply-To: <16837.28331.961306.287350@serveur5.labri.fr> References: <200412181516.24791.bruno@clisp.org> <16837.28331.961306.287350@serveur5.labri.fr> Message-ID: <200412201654.09586.bruno@clisp.org> Robert Strandh wrote: > Mario Mommer will give you write access to the McCLIM CVS so that you > can check in these modifications and continue to help make McCLIM work > with CLISP. "continue to"? It already works with the two patches I posted! :-) Thanks, I committed the first patch, which was hopefully uncontroversial. About the second one: Could someone please explain what the intent of the package EXTERNAL-FORMAT in McCLIM is? And is it welcome if I send out the interesting warnings that CLISP gives? (Mostly about unused variables and inconsistent class precedence lists.) Bruno From strandh at labri.fr Mon Dec 20 16:15:30 2004 From: strandh at labri.fr (Robert Strandh) Date: Mon, 20 Dec 2004 17:15:30 +0100 Subject: [mcclim-devel] support for clisp (1) In-Reply-To: <200412201654.09586.bruno@clisp.org> References: <200412181516.24791.bruno@clisp.org> <16837.28331.961306.287350@serveur5.labri.fr> <200412201654.09586.bruno@clisp.org> Message-ID: <16838.64162.935622.915967@serveur5.labri.fr> Bruno Haible writes: > Robert Strandh wrote: > > Mario Mommer will give you write access to the McCLIM CVS so that you > > can check in these modifications and continue to help make McCLIM work > > with CLISP. > > "continue to"? It already works with the two patches I posted! :-) Great! But we are likely to break it it the future :-) > About the second one: Could someone please explain what the intent of the > package EXTERNAL-FORMAT in McCLIM is? It looks like it tries to handle functions for translating from some internal format of McCLIM (hopefully Unicode) to X11 font encoding. > And is it welcome if I send out the interesting warnings that CLISP gives? > (Mostly about unused variables and inconsistent class precedence lists.) Nor really. Those warnings are given by other implementations as well. The best thing would be to fix them. :-) -- 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 bruno at clisp.org Mon Dec 20 16:58:16 2004 From: bruno at clisp.org (Bruno Haible) Date: Mon, 20 Dec 2004 17:58:16 +0100 Subject: [mcclim-devel] support for clisp (1) In-Reply-To: <16838.64162.935622.915967@serveur5.labri.fr> References: <200412181516.24791.bruno@clisp.org> <200412201654.09586.bruno@clisp.org> <16838.64162.935622.915967@serveur5.labri.fr> Message-ID: <200412201758.16616.bruno@clisp.org> Robert Strandh wrote: > > About the second one: Could someone please explain what the intent of > > the package EXTERNAL-FORMAT in McCLIM is? > > It looks like it tries to handle functions for translating from some > internal format of McCLIM (hopefully Unicode) to X11 font encoding. OK. Under which conditions should the code which uses and defines external-format::ksc5601-code-to-font-index etc. be defined? - If the Lisp implementation supports Unicode? #+unicode - If CLIM should support Unicode? #+clim-unicode And what shall happen on implementations that don't have an EXTERNAL-FORMAT package? Why is there no (DEFPACKAGE "EXTERNAL-FORMAT" ...) in McCLIM? Bruno From strandh at labri.fr Tue Dec 21 05:27:32 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 21 Dec 2004 06:27:32 +0100 Subject: [mcclim-devel] support for clisp (1) In-Reply-To: <200412201758.16616.bruno@clisp.org> References: <200412181516.24791.bruno@clisp.org> <200412201654.09586.bruno@clisp.org> <16838.64162.935622.915967@serveur5.labri.fr> <200412201758.16616.bruno@clisp.org> Message-ID: <16839.46148.755820.904298@serveur5.labri.fr> Hello, Bruno Haible writes: > Robert Strandh wrote: > > > About the second one: Could someone please explain what the intent of > > > the package EXTERNAL-FORMAT in McCLIM is? > > > > It looks like it tries to handle functions for translating from some > > internal format of McCLIM (hopefully Unicode) to X11 font encoding. > > OK. Under which conditions should the code which uses and defines > external-format::ksc5601-code-to-font-index etc. be defined? > - If the Lisp implementation supports Unicode? > #+unicode > - If CLIM should support Unicode? > #+clim-unicode It looks to me like the functionality in that package should always be there. A McCLIM text style should probably correspond to multiple X fonts possibly each with a different font encoding. The translate function passed to draw-glyphs should be tailored to that font set because it knows about the encoding of each X font and when it would have to switch between fonts. > And what shall happen on implementations that don't have an EXTERNAL-FORMAT > package? Why is there no (DEFPACKAGE "EXTERNAL-FORMAT" ...) in McCLIM? I don't know, because I am not sure who wrote the Korean gadget test. But McCLIM clearly breaks if :unicode is a feature. Again, I don't think that package should be there and that the functionality that it supplies always should. Now the question is: is there a reasonable way that we can hide the complexity of the translate function at the CLIM level. Or should we on the contrary find a way to expose its flexibility to the programmer using CLIM? -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From rpgoldman at real-time.com Thu Dec 23 21:05:46 2004 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Thu, 23 Dec 2004 15:05:46 -0600 Subject: [mcclim-devel] format-graph-from-roots Message-ID: <16843.13098.609289.22413@gargle.gargle.HOWL> I was just reading over the CLIM spec, and apropos of this function, it states that there should be a default to the ARC-DRAWER keyword argument. "If arc-drawer is unsupplied, the default behavior is to draw a thin line from the ``from'' node to the ``to'' node using `=--cldraw-line*." But what's checked into the CVS now doesn't have that, causing crashes if it's omitted. I think some simple default to DRAW-ARROW* should work, but I'm too abysmally ignorant of CLIM to propose a patch myself. Best, Robert From amoroso at mclink.it Fri Dec 24 17:15:32 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 24 Dec 2004 18:15:32 +0100 Subject: [mcclim-devel] format-graph-from-roots In-Reply-To: <16843.13098.609289.22413@gargle.gargle.HOWL> (rpgoldman@real-time.com's message of "Thu, 23 Dec 2004 15:05:46 -0600") References: <16843.13098.609289.22413@gargle.gargle.HOWL> Message-ID: <87ekhfpqh7.fsf@plato.moon.paoloamoroso.it> rpgoldman at real-time.com writes: > I was just reading over the CLIM spec, and apropos of this function, > it states that there should be a default to the ARC-DRAWER keyword > argument. [...] > But what's checked into the CVS now doesn't have that, causing crashes > if it's omitted. I think some simple default to DRAW-ARROW* should Maybe something like this (untested): #'(lambda (stream from to from-x from-y to-x to-y) (declare (ignore from to)) (draw-line* stream from-x from-y to-x to-y)) McCLIM's FORMAT-GRAPH-FROM-ROOTS, like the above function, currently ignores :ARC-DRAWING-OPTIONS. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From rtoy at earthlink.net Fri Dec 24 20:44:58 2004 From: rtoy at earthlink.net (Raymond Toy) Date: Fri, 24 Dec 2004 15:44:58 -0500 Subject: [mcclim-devel] Re: GCL and mcclim In-Reply-To: <16837.25196.306721.607965@serveur5.labri.fr> References: <200412190659.iBJ6xdh24807@localhost.localdomain> <16837.25196.306721.607965@serveur5.labri.fr> Message-ID: <41CC7FCA.7020708@earthlink.net> Robert Strandh wrote: > Hello, > > root writes: > > Is there any effort to port mcclim to GCL? > > Not that I am aware of. The only potential problem would be how well > GCL implements the MOP. Apparently, McCLIM now runs on CLISP since > someone recently implemented the lacking MOP features. I believe GCL uses PCL, so it probably has enough of MOP to run McCLIM. Ray From daly at idsi.net Fri Dec 24 21:53:41 2004 From: daly at idsi.net (root) Date: Fri, 24 Dec 2004 16:53:41 -0500 Subject: [mcclim-devel] Re: GCL and mcclim In-Reply-To: <41CC7FCA.7020708@earthlink.net> (message from Raymond Toy on Fri, 24 Dec 2004 15:44:58 -0500) References: <200412190659.iBJ6xdh24807@localhost.localdomain> <16837.25196.306721.607965@serveur5.labri.fr> <41CC7FCA.7020708@earthlink.net> Message-ID: <200412242153.iBOLrf125920@localhost.localdomain> Ray, Thanks. I'm looking into the issue of porting McClim to GCL. As a test case to ensure I understand the process I've been trying to build mcclim on clisp, so far without results. The effort continues... Tim Daly From rydis at cd.chalmers.se Sun Dec 26 09:14:00 2004 From: rydis at cd.chalmers.se (Martin ``rydis'' Rydstr|m) Date: Sun, 26 Dec 2004 10:14:00 +0100 Subject: [mcclim-devel] Multi-screen displays with differing depth Message-ID: <20041226091400.GB21154@haddock.cd.chalmers.se> ... cause problems with McCLIM, giving wrong colours. Fix: --- Index: port.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/CLX/port.lisp,v retrieving revision 1.100 diff -u -r1.100 port.lisp --- port.lisp 11 Dec 2004 21:15:22 -0000 1.100 +++ port.lisp 26 Dec 2004 09:09:34 -0000 @@ -1063,8 +1063,7 @@ (or (gethash color table) (setf (gethash color table) (multiple-value-bind (r g b) (color-rgb color) - (xlib:alloc-color (xlib:screen-default-colormap - (first (xlib:display-roots (clx-port-display port)))) + (xlib:alloc-color (xlib:screen-default-colormap (clx-port-screen port)) (xlib:make-color :red r :green g :blue b))))))) (defmethod port-mirror-width ((port clx-port) sheet) --- (The problem being that, in my case, :0.0 and :0.1 have different depths, and the colour gets mixed up on :0.1. An example of what it looks like without the fix: ) Regards, 'mr -- [Emacs] is written in Lisp, which is the only computer language that is beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_ From rpgoldman at sift.info Mon Dec 27 15:44:46 2004 From: rpgoldman at sift.info (Robert P. Goldman) Date: Mon, 27 Dec 2004 09:44:46 -0600 Subject: [mcclim-devel] Question about system.lisp and mcclim Message-ID: <16848.11758.298767.346168@gargle.gargle.HOWL> IIUC, the default McCLIM system.lisp file loads into Common-lisp-user, loads mk-defsystem, and then tries to USE the MAKE package. I have been using McCLIM on Allegro CL 6.2, and find that this causes me problems. The problem is that in Allegro, Common-lisp-user by default USEs the EXCL extended common-lisp package. Unfortunately, EXCL imports Allegro's OWN defsystem package, so that when you try to use MK, it causes a clash. I'm always nervous about shadowing something that Allegro wants imported, since it's bitten me before. Fortunately, AFAICT, it's trivial to modify SYSTEM.LISP, so that you DON'T need to import anything from MK --- you can just use the package references w/o much effort. Here's a proposed patch that seems to work just fine for me: --- system.lisp 20 Dec 2004 15:49:49 -0000 1.106 +++ system.lisp 27 Dec 2004 15:43:54 -0000 @@ -43,12 +43,15 @@ (defparameter *clim-directory* (director (pushnew :clim *features*) (pushnew :mcclim *features*) -#+mk-defsystem (use-package "MK") +;;; 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 - (defsystem ,module + (mk:defsystem ,module :source-pathname *clim-directory* :source-extension "lisp" ,@(and depends-on `(:depends-on ,depends-on)) Best, Robert From rpgoldman at real-time.com Mon Dec 27 16:38:29 2004 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Mon, 27 Dec 2004 10:38:29 -0600 Subject: [mcclim-devel] Question about system.lisp and mcclim In-Reply-To: <200412271648.iBRGmaUB024099@saturn.mikemac.com> References: <16848.11758.298767.346168@gargle.gargle.HOWL> <200412271648.iBRGmaUB024099@saturn.mikemac.com> Message-ID: <16848.14981.386362.305357@gargle.gargle.HOWL> >>>>> "mikemac" == mikemac writes: >> To: "mcclim developers' list" >> Date: Mon, 27 Dec 2004 09:44:46 -0600 >> From: "Robert P. Goldman" >> Fortunately, AFAICT, it's trivial to modify SYSTEM.LISP, so that you >> DON'T need to import anything from MK --- you can just use the package >> references w/o much effort. >> -#+mk-defsystem (use-package "MK") mikemac> For some reason, you have the MK-DEFSYSTEM feature mikemac> defined. Under mikemac> Allegro, you should not have that defined. But, although I use Allegro, for portability, I use MK-DEFSYSTEM in preference to Allegro's proprietary defsystem. So it is correct that I have that feature defined, and it will be correct for anyone like me who uses mk-defsystem + Allegro. So I think the patch is still necessary (also the compulsive side of my personality feels that it's laudable to avoid use-package whenever possible). Best, Robert P.S. Sorry about use of wrong email address last time... From mikemac at mikemac.com Mon Dec 27 16:48:36 2004 From: mikemac at mikemac.com (mikemac at mikemac.com) Date: Mon, 27 Dec 2004 10:48:36 -0600 Subject: [mcclim-devel] Question about system.lisp and mcclim In-Reply-To: Your message of "Mon, 27 Dec 2004 09:44:46 CST." <16848.11758.298767.346168@gargle.gargle.HOWL> Message-ID: <200412271648.iBRGmaUB024099@saturn.mikemac.com> >To: "mcclim developers' list" >Date: Mon, 27 Dec 2004 09:44:46 -0600 >From: "Robert P. Goldman" >Fortunately, AFAICT, it's trivial to modify SYSTEM.LISP, so that you >DON'T need to import anything from MK --- you can just use the package >references w/o much effort. >-#+mk-defsystem (use-package "MK") For some reason, you have the MK-DEFSYSTEM feature defined. Under Allegro, you should not have that defined. Mike McDonald mikemac at mikemac.com From smustudent1 at yahoo.com Mon Dec 27 17:44:07 2004 From: smustudent1 at yahoo.com (C Y) Date: Mon, 27 Dec 2004 09:44:07 -0800 (PST) Subject: [mcclim-devel] Re: GCL and mcclim In-Reply-To: <200412242153.iBOLrf125920@localhost.localdomain> Message-ID: <20041227174407.1062.qmail@web12209.mail.yahoo.com> --- root wrote: > Ray, > > Thanks. I'm looking into the issue of porting McClim to GCL. > As a test case to ensure I understand the process I've been > trying to build mcclim on clisp, so far without results. > The effort continues... > > Tim Daly That reminds me - has anybody checked if scigraph works on the clisp port yet? I'm gonna take a wack at clisp+McCLIM myself once I get time (probably late January at this rate :-( ). CY __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 From frido at q-software-solutions.de Tue Dec 28 07:53:18 2004 From: frido at q-software-solutions.de (Friedrich Dominicus) Date: Tue, 28 Dec 2004 08:53:18 +0100 Subject: [mcclim-devel] CVS checkout In-Reply-To: <20041227174407.1062.qmail@web12209.mail.yahoo.com> (C. Y.'s message of "Mon, 27 Dec 2004 09:44:07 -0800 (PST)") References: <20041227174407.1062.qmail@web12209.mail.yahoo.com> Message-ID: <877jn2eu4x.fsf@fbigm.here> according to the docs this should work cvs -d:pserver:anonymous at common-lisp.net:/project/mcclim/cvsroot login that does work now checking out cvs -z3 -d:pserver:anonymous at common-lisp.net:/project/mcclim/cvsroot co mcclim does not work. Message is: cvs [checkout aborted]: could not chdir to mcclim: No such file or directory Well browsing the repository yields: http://common-lisp.net/cgi-bin/viewcvs.cgi/?cvsroot=mcclim#dirlist with mcclim as the only directory there. So why can't one get this stuff? Regards Friedrich From strandh at labri.fr Tue Dec 28 08:29:27 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Dec 2004 09:29:27 +0100 Subject: [mcclim-devel] CVS checkout In-Reply-To: <877jn2eu4x.fsf@fbigm.here> References: <20041227174407.1062.qmail@web12209.mail.yahoo.com> <877jn2eu4x.fsf@fbigm.here> Message-ID: <16849.6503.667007.729114@serveur5.labri.fr> Friedrich Dominicus writes: > according to the docs this should work > cvs -d:pserver:anonymous at common-lisp.net:/project/mcclim/cvsroot login > that does work now > checking out > cvs -z3 -d:pserver:anonymous at common-lisp.net:/project/mcclim/cvsroot co mcclim > > does not work. > Message is: > cvs [checkout aborted]: could not chdir to mcclim: No such file or directory > > Well browsing the repository yields: > http://common-lisp.net/cgi-bin/viewcvs.cgi/?cvsroot=mcclim#dirlist > > with mcclim as the only directory there. So why can't one get this > stuff? I don't know, but perhaps a cl.net administrator could answer. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Tue Dec 28 08:32:58 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Dec 2004 09:32:58 +0100 Subject: [mcclim-devel] Re: GCL and mcclim In-Reply-To: <20041227174407.1062.qmail@web12209.mail.yahoo.com> References: <200412242153.iBOLrf125920@localhost.localdomain> <20041227174407.1062.qmail@web12209.mail.yahoo.com> Message-ID: <16849.6714.756057.919254@serveur5.labri.fr> C Y writes: > > That reminds me - has anybody checked if scigraph works on the clisp > port yet? I'm gonna take a wack at clisp+McCLIM myself once I get time > (probably late January at this rate :-( ). I am not sure Scigraph+McCLIM works properly in any implementation right now. I asked Tim Moore to look into that recently, and he told me that it works well enough for a demo that he is supposed to be giving, but he gave me the distinct impression that it is not yet ready for general consumption. Tim will be back from vacation next week, so you might get a more informed answer to your question then. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Tue Dec 28 10:07:22 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Dec 2004 11:07:22 +0100 Subject: [mcclim-devel] Multi-screen displays with differing depth In-Reply-To: <20041226091400.GB21154@haddock.cd.chalmers.se> References: <20041226091400.GB21154@haddock.cd.chalmers.se> Message-ID: <16849.12378.630773.924387@serveur5.labri.fr> Martin ``rydis'' Rydstr|m writes: > ... cause problems with McCLIM, giving wrong colours. Fix: > [snip] > (The problem being that, in my case, :0.0 and :0.1 have different depths, > and the colour gets mixed up on :0.1. An example of what it looks like > without the fix: > ) patch applied and committed. Thanks. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From amoroso at mclink.it Tue Dec 28 10:17:47 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 28 Dec 2004 11:17:47 +0100 Subject: [mcclim-devel] Re: GCL and mcclim In-Reply-To: <16849.6714.756057.919254@serveur5.labri.fr> (Robert Strandh's message of "Tue, 28 Dec 2004 09:32:58 +0100") References: <200412242153.iBOLrf125920@localhost.localdomain> <20041227174407.1062.qmail@web12209.mail.yahoo.com> <16849.6714.756057.919254@serveur5.labri.fr> Message-ID: <873bxqeng4.fsf@plato.moon.paoloamoroso.it> Robert Strandh writes: > I am not sure Scigraph+McCLIM works properly in any implementation > right now. I asked Tim Moore to look into that recently, and he told See my notes on Scigraph: Scigraph: about, documentation patch http://www.paoloamoroso.it/log/040818.html Fix for Scigraph build error http://www.paoloamoroso.it/log/040903.html There is still some functionality that does not fully work, e.g. some command table issues that prevent access to some commands. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From amoroso at mclink.it Tue Dec 28 11:25:48 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 28 Dec 2004 12:25:48 +0100 Subject: [mcclim-devel] Bug list page at McCLIM CLiki: new resource Message-ID: <87d5wuslz7.fsf@plato.moon.paoloamoroso.it> I have created a simple McCLIM bug list at: http://mcclim.cliki.net/Bug It is meant as a useful, lightweight resource for both users and developers. Usage, as described in the short instructions at the top, should be straightforward. The only non obvious issue is the use of a NAME HTML tag, such as `my-bug', for each entry, This makes it possible to have URLs such as: http://mcclim.cliki.net/Bug#my-bug do the right thing and point the browser to the appropriate entry. Of course, I hope the page will not get long enough to make this feature useful :) Since the mcclim-devel list is archived, I will repost old bug reports of mine, and add links from the bug list, so that they can now be permanently archived. If this is an inconvenience for you, just let me know and I will not do it. Your feedback--better yet, your edits--is welcome. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From strandh at labri.fr Tue Dec 28 11:50:27 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Dec 2004 11:50:27 -0000 Subject: [mcclim-devel] Fix for Scigraph package lock error with CMUCL In-Reply-To: <87oekplvj6.fsf@plato.moon.paoloamoroso.it> References: <87oekplvj6.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > The current CVS sources of Scigraph generate a package lock error > during compilation or load with recent versions of CMUCL, I think the > 19a prerelease and release series. It is caused by a conflict with > the symbol `cl:variable'. The problem can be fixed by changing in > file Apps/Scigraph/scigraph/package.lisp the form: > > (eval-when (compile load eval) > (defpackage GRAPH > #-allegro (:nicknames gr) ; "GR" names something already. > #+allegro (:shadow variable) ; shouldn't be inherited but is > #+MCL (:shadow copy) > (:use dwim-lisp tool statistics))) > > to this, which removes the conditionalization of `variable' shadowing > for allegro: > > (eval-when (compile load eval) > (defpackage GRAPH > #-allegro (:nicknames gr) ; "GR" names something already. > (:shadow variable) ; shouldn't be inherited but is > #+MCL (:shadow copy) > (:use dwim-lisp tool statistics))) Patch applied. Thanks. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Tue Dec 28 12:02:43 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Dec 2004 13:02:43 +0100 Subject: [mcclim-devel] Bug list page at McCLIM CLiki: new resource In-Reply-To: <87d5wuslz7.fsf@plato.moon.paoloamoroso.it> References: <87d5wuslz7.fsf@plato.moon.paoloamoroso.it> Message-ID: <16849.19299.466526.60433@serveur5.labri.fr> Paolo Amoroso writes: > I have created a simple McCLIM bug list at: > > http://mcclim.cliki.net/Bug Great initiative! Thanks! -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From frido at q-software-solutions.de Tue Dec 28 16:15:40 2004 From: frido at q-software-solutions.de (Friedrich Dominicus) Date: Tue, 28 Dec 2004 17:15:40 +0100 Subject: [admin] [mcclim-devel] CVS checkout In-Reply-To: (Mario Mommer's message of "Tue, 28 Dec 2004 16:01:45 +0100") References: <20041227174407.1062.qmail@web12209.mail.yahoo.com> <877jn2eu4x.fsf@fbigm.here> <16849.6503.667007.729114@serveur5.labri.fr> Message-ID: <874qi6v1oz.fsf@fbigm.here> Mario Mommer writes: > Unfortunately, copy and pasting to a terminal here the attempted > commands above (the first two lines beginning with cvs) works without > any problems. I'm running slackware 10.0, which in these regards tends > to be as vanilla as it gets. I thought that this error was on my side this has confirmed that. And indeed the point is that there has existed a dangling link with the name mcclim. Now trying to check out mcclim accessed this dangling link and accessed a non existing target. Very funny and really dump from me. Sorry Friedrich From amoroso at mclink.it Tue Dec 28 17:40:02 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 28 Dec 2004 18:40:02 +0100 Subject: [mcclim-devel] Application pane vertical scrolling does not work with table formatting Message-ID: <878y7i5nkd.fsf@plato.moon.paoloamoroso.it> I have found an annoying problem that severely limits the use of table formatting in application panes. This sample code shows the problem: (in-package :clim-user) (define-application-frame no-scroll () () (:pointer-documentation t) (:panes (app :application :display-time :command-loop :display-function 'display-function :end-of-line-action :wrap :end-of-page-action :scroll :scroll-bars t)) (:layouts (default app))) (defun display-function (frame stream) (declare (ignore frame)) (formatting-table (stream) (dotimes (i 100) (formatting-row (stream) (formatting-cell (stream) (princ i)))))) (define-no-scroll-command (com-quit :menu t) () (frame-exit *application-frame*)) Run it with: (run-frame-top-level (make-application-frame 'no-scroll)) Although the tabular output is longer than the application pane's viewport, it is not possible to vertically scroll it to see the remaining part. The thumb occupies all the scroll bar's area, as if there was no additional output. Is the above code supposed to work? Am I doing anything wrong? Any workarounds? Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From amoroso at mclink.it Tue Dec 28 20:02:33 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 28 Dec 2004 21:02:33 +0100 Subject: [mcclim-devel] Application pane vertical scrolling does not work with table formatting In-Reply-To: <31ffd3c4041228110765b8ca8e@mail.gmail.com> (Andy Hefner's message of "Tue, 28 Dec 2004 14:07:25 -0500") References: <878y7i5nkd.fsf@plato.moon.paoloamoroso.it> <31ffd3c4041228110765b8ca8e@mail.gmail.com> Message-ID: <87fz1qry1y.fsf@plato.moon.paoloamoroso.it> Andy Hefner writes: > The problem is that the space requirements of the application-pane are > not updated to be large enough to contain your output. After > generating your output, this can be done manually as follows: > > (change-space-requirements pane > :width (bounding-rectangle-width > (stream-output-history pane)) > :height (bounding-rectangle-height > (stream-output-history pane)))) This workaround works magnificently. Thanks a quadrillion. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From rpgoldman at real-time.com Tue Dec 28 20:09:30 2004 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 28 Dec 2004 14:09:30 -0600 Subject: [mcclim-devel] Application pane vertical scrolling does not work with table formatting In-Reply-To: <87fz1qry1y.fsf@plato.moon.paoloamoroso.it> References: <878y7i5nkd.fsf@plato.moon.paoloamoroso.it> <31ffd3c4041228110765b8ca8e@mail.gmail.com> <87fz1qry1y.fsf@plato.moon.paoloamoroso.it> Message-ID: <16849.48506.589565.779379@gargle.gargle.HOWL> >>>>> "PA" == Paolo Amoroso writes: PA> Andy Hefner writes: >> The problem is that the space requirements of the application-pane are >> not updated to be large enough to contain your output. After >> generating your output, this can be done manually as follows: >> >> (change-space-requirements pane >> :width (bounding-rectangle-width >> (stream-output-history pane)) >> :height (bounding-rectangle-height >> (stream-output-history pane)))) PA> This workaround works magnificently. Thanks a quadrillion. That's the workaround, but is this still a bug? Surely the space requirements should be automagically updated by formatting-table? I can find the place in the code where the size of the output record is updated, but am too ignorant of the McCLIM internals to propose where the update should be made.... Or, is this not a bug, and is this kind of dimension update the responsibility of anyone who provides a display method? Best, r From rpgoldman at real-time.com Tue Dec 28 20:34:24 2004 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 28 Dec 2004 14:34:24 -0600 Subject: [mcclim-devel] question about display functions and control apps Message-ID: <16849.50000.441579.260315@gargle.gargle.HOWL> The examples I have seen of display functions and McCLIM, it seems like there are two dominant models: one where the user does some commands, and the application pane's display function stays in synch by updating at every command loop (I suppose this is the MVC model); and another where we write code in the commands that directly display stuff (and have to tell the application pane NOT to redisplay itself). Question: what about the case where you want to watch something "out there" that is not under the control of the command loop. I'm thinking in particular about controls applications, where you might want to update a display that shows the current state of the plant. Typically, there will be some process sampling the world at some rate, and wanting to asynchronously update the state display. Has anyone built an application like that using CLIM? Any suggestions for the right model? Thanks! R From amoroso at mclink.it Tue Dec 28 20:57:51 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 28 Dec 2004 21:57:51 +0100 Subject: [mcclim-devel] question about display functions and control apps References: <16849.50000.441579.260315@gargle.gargle.HOWL> Message-ID: <87zmzy6sz4.fsf@plato.moon.paoloamoroso.it> rpgoldman at real-time.com writes: > The examples I have seen of display functions and McCLIM, it seems > like there are two dominant models: one where the user does some > commands, and the application pane's display function stays in synch > by updating at every command loop (I suppose this is the MVC model); Section 7 "CLIM: Presentation Based Interfaces" (page 31) of this paper: New Architectural Models for Visibly Controllable Computing: The Relevance of Dynamic Object Oriented Architectures and Plan Based Computing Models ftp://publications.ai.mit.edu/ai-publications/2004/AIM-2004-005.pdf briefly describes the relations between CLIM and MVC. > Question: what about the case where you want to watch something "out > there" that is not under the control of the command loop. I'm > thinking in particular about controls applications, where you might > want to update a display that shows the current state of the plant. If I understand correctly, in this case you may call REDISPLAY-FRAME-PANE, typically from an application command or some state updating function. A program that uses this approach is: KYTRON on the Moon http://artm-friends.at/rm/kytron/kytron-clim.html Check the CLIM 2 version: http://artm-friends.at/rm/kytron/kytron2.lisp.txt See for example the commands for adding a new element--crater, mountain, ecc.--to the environment. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From amoroso at mclink.it Tue Dec 28 21:25:09 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 28 Dec 2004 22:25:09 +0100 Subject: [mcclim-devel] question about display functions and control apps In-Reply-To: <87zmzy6sz4.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Tue, 28 Dec 2004 21:57:51 +0100") References: <16849.50000.441579.260315@gargle.gargle.HOWL> <87zmzy6sz4.fsf@plato.moon.paoloamoroso.it> Message-ID: <87ekhaw1xm.fsf@plato.moon.paoloamoroso.it> Paolo Amoroso writes: > If I understand correctly, in this case you may call > REDISPLAY-FRAME-PANE, typically from an application command or some > state updating function. A program that uses this approach is: > > KYTRON on the Moon > http://artm-friends.at/rm/kytron/kytron-clim.html > > Check the CLIM 2 version: > > http://artm-friends.at/rm/kytron/kytron2.lisp.txt > > See for example the commands for adding a new element--crater, > mountain, ecc.--to the environment. More precisely, I meant `com-run-simulation' and `com-time-100-steps'. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From rpgoldman at real-time.com Tue Dec 28 21:41:33 2004 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 28 Dec 2004 15:41:33 -0600 Subject: [mcclim-devel] question about display functions and control apps In-Reply-To: <87ekhaw1xm.fsf@plato.moon.paoloamoroso.it> References: <16849.50000.441579.260315@gargle.gargle.HOWL> <87zmzy6sz4.fsf@plato.moon.paoloamoroso.it> <87ekhaw1xm.fsf@plato.moon.paoloamoroso.it> Message-ID: <16849.54029.712269.669272@gargle.gargle.HOWL> >>>>> "Paolo" == Paolo Amoroso writes: Paolo> Paolo Amoroso writes: >> If I understand correctly, in this case you may call >> REDISPLAY-FRAME-PANE, typically from an application command or some >> state updating function. A program that uses this approach is: >> >> KYTRON on the Moon >> http://artm-friends.at/rm/kytron/kytron-clim.html >> >> Check the CLIM 2 version: >> >> http://artm-friends.at/rm/kytron/kytron2.lisp.txt >> >> See for example the commands for adding a new element--crater, >> mountain, ecc.--to the environment. Paolo> More precisely, I meant `com-run-simulation' and Paolo> `com-time-100-steps'. Actually, if I understand Hef's comments correctly (and I haven't misunderstood the kytron code), this isn't really the right model. The problem is that the kytron is still really a synchronously operating simulation: the sim does one step, then you call clim:redisplay-frame-pane, repeat. The problem with control apps, is that there will be a separate thread that will be latching state updates, and will not be working in synch with the UI. So you might get something unpleasant happening if you invoke clim:redisplay-frame-pane from that separate thread (assuming[1] that the clim redisplay function is not thread-safe). Andy suggests weird-irc as another model, but it seems not to be thread-safe. I will look into that further now. I hope that this design question is of sufficient generality to be of wide interest, and that I'm not wasting everyone's time.... Best, r Footnotes: [1] Out of force of habit, I almost typed "without loss of generality" here! :-> From ahefner at gmail.com Tue Dec 28 19:07:25 2004 From: ahefner at gmail.com (Andy Hefner) Date: Tue, 28 Dec 2004 14:07:25 -0500 Subject: [mcclim-devel] Application pane vertical scrolling does not work with table formatting In-Reply-To: <878y7i5nkd.fsf@plato.moon.paoloamoroso.it> References: <878y7i5nkd.fsf@plato.moon.paoloamoroso.it> Message-ID: <31ffd3c4041228110765b8ca8e@mail.gmail.com> This is similar to the problem you reported earlier involving graph formatting in the listener. The problem is that the space requirements of the application-pane are not updated to be large enough to contain your output. After generating your output, this can be done manually as follows: (change-space-requirements pane :width (bounding-rectangle-width (stream-output-history pane)) :height (bounding-rectangle-height (stream-output-history pane)))) Having just looked through the spec, I'm thinking this is a bug rather than a feature (which I was not certain of previously). I'll take another look at fixing this in my next batch of changes. On Tue, 28 Dec 2004 18:40:02 +0100, Paolo Amoroso wrote: > I have found an annoying problem that severely limits the use of table > formatting in application panes. This sample code shows the problem: From pw at snoopy.mv.com Tue Dec 28 21:29:34 2004 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 28 Dec 2004 16:29:34 -0500 Subject: [mcclim-devel] missing doc page Message-ID: <000501c4ed24$53b5b780$0201a8c0@moby> The table of contents page of the CLIM spec is a dead link http://www.stud.uni-karlsuhe.de/~unk6/clim-spec/NIL gets a http 404 file not found error. Paul From pw at snoopy.mv.com Tue Dec 28 21:40:43 2004 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 28 Dec 2004 16:40:43 -0500 Subject: [mcclim-devel] question about display functions and control apps References: <16849.50000.441579.260315@gargle.gargle.HOWL> <87zmzy6sz4.fsf@plato.moon.paoloamoroso.it> Message-ID: <000f01c4ed25$e4d650c0$0201a8c0@moby> | | > Question: what about the case where you want to watch something "out | > there" that is not under the control of the command loop. I'm | > thinking in particular about controls applications, where you might | > want to update a display that shows the current state of the plant. | | If I understand correctly, in this case you may call | REDISPLAY-FRAME-PANE, typically from an application command or some | state updating function. A program that uses this approach is: I do this sort of thing quite a bit and it took some experimentation to get it to work right. At least part of the trick (in LWW CLIM at least) is to do (setf (pane-needs-redisplay pane) t) prior to redisplay-frame-pane. But, to do this, you can't have :display-time :command-loop active. You probably also want to manually manage the output-recording options to avoid a surprise when pane may be re-exposed at a later time. Like this: (setf (pane-needs-redisplay pane) t) (with-output-recording-options (pane :record t) (redisplay-frame-pane frame pane)) Paul From dan at telent.net Tue Dec 28 20:07:03 2004 From: dan at telent.net (Daniel Barlow) Date: Tue, 28 Dec 2004 20:07:03 +0000 Subject: [mcclim-devel] How to resize a pane with scrollbars? Message-ID: <87r7la89w8.fsf@noetbook.telent.net> In the barebones clim app below, using the "Resize Input" command to resize the interactor pane causes the scrollbar thumb to resize so that the new bigger interactor can be scrolled around. This is what I'd expect. Resizing the application pane in similar fashion ("Resize Output") however, has no effect that I can see. I've only been using clim for a few days, so it's not obvious to me that it's supposed to work like this anyway. If it isn't, please feel free to say so. How should I be doing this? (The name of this application is because I initially suspected from TRACEing COMPOSE-SPACE that there was a vrack pane swallowing the space requirement and substituting its own. Now, though, I just believe I don't understand the layout protocol anyway) (clim:define-application-frame vrack-test () () (:pointer-documentation t) (:panes (track :application :scroll-bars :vertical ;:width 600 :height 400 ) (int :interactor :height 120 :width 600)) (:layouts (default (vertically () track int)))) (define-vrack-test-command (com-quit :name "Quit") () (frame-exit *application-frame*)) (define-vrack-test-command (com-resize-out :name "Resize Output") ((size 'number)) (change-space-requirements *standard-output* :width 600 :height size)) (define-vrack-test-command (com-resize-in :name "Resize Input") ((size 'number)) (change-space-requirements *standard-input* :width 600 :height size))) (run-frame-top-level (make-application-frame 'vrack-test)) -- "please make sure that the person is your friend before you confirm" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From moore at bricoworks.com Wed Dec 29 10:37:54 2004 From: moore at bricoworks.com (Timothy Moore) Date: Wed, 29 Dec 2004 11:37:54 +0100 Subject: [mcclim-devel] question about display functions and control apps In-Reply-To: <16849.54029.712269.669272@gargle.gargle.HOWL> References: <16849.50000.441579.260315@gargle.gargle.HOWL> <87zmzy6sz4.fsf@plato.moon.paoloamoroso.it> <87ekhaw1xm.fsf@plato.moon.paoloamoroso.it> <16849.54029.712269.669272@gargle.gargle.HOWL> Message-ID: On Dec 28, 2004, at 10:41 PM, rpgoldman at real-time.com wrote: > Actually, if I understand Hef's comments correctly (and I haven't > misunderstood the kytron code), this isn't really the right model. > The problem is that the kytron is still really a synchronously > operating simulation: the sim does one step, then you call > clim:redisplay-frame-pane, repeat. > > The problem with control apps, is that there will be a separate thread > that will be latching state updates, and will not be working in synch > with the UI. So you might get something unpleasant happening if you > invoke clim:redisplay-frame-pane from that separate thread (assuming[1] > that the clim redisplay function is not thread-safe). > > ... > I hope that this design question is of sufficient generality to be of > wide interest, and that I'm not wasting everyone's time.... > ... Not at all; this is an interesting issue that has occupied a lot of my brain cycles without much success. A further complication is that recording panes are not at all thread safe in McCLIM; I don't know whether they are in Classic CLIM. It would be very nice to have a simulation ---especially in 3D using OpenGL --- running in an application pane while at the same time one could continue to use the interactive command loop with typed commands, sensitive presentations, etc. McCLIM does have some nascent support for timer events, but this is way below the level of command processing. One approach might be to extend this to "throw" a redisplay command when a timer or other update event arrives. Right now that would destroy the state of command line editing in the interactor pane, so some work would have to be done to preserve the state of the input editing stream. Some examples of how to do this are in the accepting-values code in dialog.lisp. The situation is not so dire because the easiest way to write a CLIM application is to follow an MVC approach of update the model, redisplay it, and let CLIM take care of optimizing the redisplay. That means that the redisplay and the command processes --- the interactive command loop, plus whatever else might change the state of the model -- could operate asynchronously from each other as long as they use some kind of mutual exclusion mechanism. An interactive command could cause the pane to be redisplayed, or one might let the next timer event, vertical retrace event or whatever force the redisplay. The remaining complication, then, would be the handling of sensitive presentations and pointer documentation. The CLIM command loop would have to know about the mutex protecting the view and also be alerted that presentations may have moved, appeared, disappeared, etc. None of this is very helpful for an application developer wanting to do something right now, but I hope it is food for thought for McCLIM developers and users alike. Tim From moore at bricoworks.com Wed Dec 29 10:02:24 2004 From: moore at bricoworks.com (Timothy Moore) Date: Wed, 29 Dec 2004 11:02:24 +0100 Subject: [mcclim-devel] Re: GCL and mcclim In-Reply-To: <873bxqeng4.fsf@plato.moon.paoloamoroso.it> References: <200412242153.iBOLrf125920@localhost.localdomain> <20041227174407.1062.qmail@web12209.mail.yahoo.com> <16849.6714.756057.919254@serveur5.labri.fr> <873bxqeng4.fsf@plato.moon.paoloamoroso.it> Message-ID: On Dec 28, 2004, at 11:17 AM, Paolo Amoroso wrote: > Robert Strandh writes: > >> I am not sure Scigraph+McCLIM works properly in any implementation >> right now. I asked Tim Moore to look into that recently, and he told > > See my notes on Scigraph: > > Scigraph: about, documentation patch > http://www.paoloamoroso.it/log/040818.html > > Fix for Scigraph build error > http://www.paoloamoroso.it/log/040903.html > > There is still some functionality that does not fully work, e.g. some > command table issues that prevent access to some commands. > I'd like to hear about those. A while ago (right after the common-lisp.net move) I checked in a fix to command tables that resolved the SciGraph command issues that I knew about. Tim From moore at bricoworks.com Wed Dec 29 10:09:46 2004 From: moore at bricoworks.com (Timothy Moore) Date: Wed, 29 Dec 2004 11:09:46 +0100 Subject: [mcclim-devel] Application pane vertical scrolling does not work with table formatting In-Reply-To: <878y7i5nkd.fsf@plato.moon.paoloamoroso.it> References: <878y7i5nkd.fsf@plato.moon.paoloamoroso.it> Message-ID: On Dec 28, 2004, at 6:40 PM, Paolo Amoroso wrote: > I have found an annoying problem that severely limits the use of table > formatting in application panes. This sample code shows the problem: > ... > Although the tabular output is longer than the application pane's > viewport, it is not possible to vertically scroll it to see the > remaining part. The thumb occupies all the scroll bar's area, as if > there was no additional output. > > Is the above code supposed to work? Am I doing anything wrong? Any > workarounds? > This is probably a bug, or at least could be handled by McCLIM itself. I added this in an application I wrote that displays really big tables: (defclass redisplay-frame-mixin () ()) (defmethod redisplay-frame-pane :after ((frame redisplay-frame-mixin) (pane application-pane) &key force-p) (declare (ignore force-p)) (change-space-requirements pane :height (bounding-rectangle-height (stream-output-history pane)))) (define-application-frame geekbooks (master-frame-mixin redisplay-frame-mixin standard-application-frame) ((current-account :accessor current-account) (reconciling-activity :accessor reconciling-activity)) ...) This could be the default for application panes with scroll bars. Tim From mmommer at common-lisp.net Tue Dec 28 15:01:45 2004 From: mmommer at common-lisp.net (Mario Mommer) Date: Tue, 28 Dec 2004 16:01:45 +0100 Subject: [admin] [mcclim-devel] CVS checkout In-Reply-To: <16849.6503.667007.729114@serveur5.labri.fr> References: <20041227174407.1062.qmail@web12209.mail.yahoo.com> <877jn2eu4x.fsf@fbigm.here> <16849.6503.667007.729114@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Friedrich Dominicus writes: > > according to the docs this should work > > cvs -d:pserver:anonymous at common-lisp.net:/project/mcclim/cvsroot login > > that does work now > > checking out > > cvs -z3 -d:pserver:anonymous at common-lisp.net:/project/mcclim/cvsroot co mcclim > > > > does not work. > > Message is: > > cvs [checkout aborted]: could not chdir to mcclim: No such file or directory > > > > Well browsing the repository yields: > > http://common-lisp.net/cgi-bin/viewcvs.cgi/?cvsroot=mcclim#dirlist > > > > with mcclim as the only directory there. So why can't one get this > > stuff? > > I don't know, but perhaps a cl.net administrator could answer. Unfortunately, copy and pasting to a terminal here the attempted commands above (the first two lines beginning with cvs) works without any problems. I'm running slackware 10.0, which in these regards tends to be as vanilla as it gets. Regards, Mario. From amoroso at mclink.it Wed Dec 29 13:43:54 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Wed, 29 Dec 2004 14:43:54 +0100 Subject: [mcclim-devel] missing doc page In-Reply-To: <000501c4ed24$53b5b780$0201a8c0@moby> (Paul Werkowski's message of "Tue, 28 Dec 2004 16:29:34 -0500") References: <000501c4ed24$53b5b780$0201a8c0@moby> Message-ID: <87hdm543tx.fsf@plato.moon.paoloamoroso.it> "Paul Werkowski" writes: > The table of contents page of the CLIM spec is a dead link > http://www.stud.uni-karlsuhe.de/~unk6/clim-spec/NIL gets a http 404 > file not found error. Some time ago Gilbert Baumann told me that some local changes, not under his control, prevented him from properly maintaining the site, and that he would have moved it elsewhere. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From amoroso at mclink.it Wed Dec 29 14:05:25 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Wed, 29 Dec 2004 15:05:25 +0100 Subject: [mcclim-devel] How to resize a pane with scrollbars? In-Reply-To: <87r7la89w8.fsf@noetbook.telent.net> (Daniel Barlow's message of "Tue, 28 Dec 2004 20:07:03 +0000") References: <87r7la89w8.fsf@noetbook.telent.net> Message-ID: <87fz1p6vyy.fsf@plato.moon.paoloamoroso.it> You problem is probably related to the one described in this thread: http://common-lisp.net/pipermail/mcclim-devel/2004-December/003560.html Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From chandler at unmutual.info Wed Dec 29 13:55:42 2004 From: chandler at unmutual.info (Brian Mastenbrook) Date: Wed, 29 Dec 2004 07:55:42 -0600 Subject: [mcclim-devel] missing doc page In-Reply-To: <87hdm543tx.fsf@plato.moon.paoloamoroso.it> References: <000501c4ed24$53b5b780$0201a8c0@moby> <87hdm543tx.fsf@plato.moon.paoloamoroso.it> Message-ID: <542313AA-59A1-11D9-8661-000D933F67D6@unmutual.info> On Dec 29, 2004, at 7:43 AM, Paolo Amoroso wrote: > Some time ago Gilbert Baumann told me that some local changes, not > under his control, prevented him from properly maintaining the site, > and that he would have moved it elsewhere. Is there any chance of getting this put on common-lisp.net? -- Brian Mastenbrook http://www.iscblog.info/ http://www.cs.indiana.edu/~bmastenb/ From strandh at labri.fr Wed Dec 29 14:05:27 2004 From: strandh at labri.fr (Robert Strandh) Date: Wed, 29 Dec 2004 15:05:27 +0100 Subject: [mcclim-devel] missing doc page In-Reply-To: <87hdm543tx.fsf@plato.moon.paoloamoroso.it> References: <000501c4ed24$53b5b780$0201a8c0@moby> <87hdm543tx.fsf@plato.moon.paoloamoroso.it> Message-ID: <16850.47527.96643.749623@serveur5.labri.fr> Paolo Amoroso writes: > "Paul Werkowski" writes: > > > The table of contents page of the CLIM spec is a dead link > > http://www.stud.uni-karlsuhe.de/~unk6/clim-spec/NIL gets a http 404 > > file not found error. > > Some time ago Gilbert Baumann told me that some local changes, not > under his control, prevented him from properly maintaining the site, > and that he would have moved it elsewhere. It would be desirable to have a more accessible site. I can certainly put any technical stuff on my web site at the university, but sysadmin paranoia implies that the web server mounts the disks read-only. It is therefore impossible for me to provide services like annotation. But common-lisp.net would be an alternative, I guess. It would not be totally wrong to store the "annotatable" CLIM spec there, together with the McCLIM project, if we got the permission. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Wed Dec 29 14:07:17 2004 From: strandh at labri.fr (Robert Strandh) Date: Wed, 29 Dec 2004 15:07:17 +0100 Subject: [mcclim-devel] missing doc page In-Reply-To: <542313AA-59A1-11D9-8661-000D933F67D6@unmutual.info> References: <000501c4ed24$53b5b780$0201a8c0@moby> <87hdm543tx.fsf@plato.moon.paoloamoroso.it> <542313AA-59A1-11D9-8661-000D933F67D6@unmutual.info> Message-ID: <16850.47637.330207.71140@serveur5.labri.fr> Brian Mastenbrook writes: > On Dec 29, 2004, at 7:43 AM, Paolo Amoroso wrote: > > > Some time ago Gilbert Baumann told me that some local changes, not > > under his control, prevented him from properly maintaining the site, > > and that he would have moved it elsewhere. > > Is there any chance of getting this put on common-lisp.net? Good idea :) -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From amoroso at mclink.it Wed Dec 29 14:40:27 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Wed, 29 Dec 2004 15:40:27 +0100 Subject: [mcclim-devel] missing doc page In-Reply-To: <542313AA-59A1-11D9-8661-000D933F67D6@unmutual.info> (Brian Mastenbrook's message of "Wed, 29 Dec 2004 07:55:42 -0600") References: <000501c4ed24$53b5b780$0201a8c0@moby> <87hdm543tx.fsf@plato.moon.paoloamoroso.it> <542313AA-59A1-11D9-8661-000D933F67D6@unmutual.info> Message-ID: <87vfal417o.fsf@plato.moon.paoloamoroso.it> Brian Mastenbrook writes: > On Dec 29, 2004, at 7:43 AM, Paolo Amoroso wrote: > >> Some time ago Gilbert Baumann told me that some local changes, not >> under his control, prevented him from properly maintaining the site, >> and that he would have moved it elsewhere. > > Is there any chance of getting this put on common-lisp.net? Actually, there are good changes: that's exactly where Gilbert told me he would like to move the site :) But he tends to be busy-ish, and I guess he didn't have a chance to work on this yet. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From pdm at zamazal.org Thu Dec 30 11:23:59 2004 From: pdm at zamazal.org (Milan Zamazal) Date: Thu, 30 Dec 2004 12:23:59 +0100 Subject: [mcclim-devel] Springtail 0.0 released Message-ID: <87pt0srpv4.fsf@blackbird.zamazal.org> Springtail 0.0 released ======================= This is the first release of my McCLIM based Common Lisp digital photo collection manager. A simple McCLIM off-line Wikipedia client and a very simple CLX based digital clock able to crash SBCL are also included. Please note this is a tentative release. While I use Springtail regularly and it works quite well for me, it is highly personalized and I don't think it can be used by anyone else out of the box, if at all, in its current state. So why am I releasing it? - I'd like to provide an example of actual use of the McCLIM's image extensions. - I'd like to contribute another example code of a non-trivial McCLIM application, to support McCLIM use and further development. - Well, when it has been already written: Maybe someone else could find a McCLIM based digital photo manager useful. I'm not sure, so I ask about it this way. You can download Springtail 0.0 from http://www.zamazal.org/software/springtail/download/springtail-0.0.tar.gz From chandler at unmutual.info Thu Dec 30 13:45:02 2004 From: chandler at unmutual.info (Brian Mastenbrook) Date: Thu, 30 Dec 2004 07:45:02 -0600 Subject: [mcclim-devel] Springtail 0.0 released In-Reply-To: <87pt0srpv4.fsf@blackbird.zamazal.org> References: <87pt0srpv4.fsf@blackbird.zamazal.org> Message-ID: <015EDCE2-5A69-11D9-8148-000D933F67D6@unmutual.info> On Dec 30, 2004, at 5:23 AM, Milan Zamazal wrote: > Springtail 0.0 released > ======================= > > This is the first release of my McCLIM based Common Lisp digital photo > collection manager. A simple McCLIM off-line Wikipedia client and a > very > simple CLX based digital clock able to crash SBCL are also included. Hi Milan, This is very cool. Can you provide a screenshot for the McCLiki Screenshots page? Also, how does the digitial clock crash SBCL? Do you compile with full safety? Please email a bug report to sbcl-devel. -- Brian Mastenbrook http://www.iscblog.info/ http://www.cs.indiana.edu/~bmastenb/ From strandh at labri.fr Fri Dec 31 06:20:53 2004 From: strandh at labri.fr (Robert Strandh) Date: Fri, 31 Dec 2004 07:20:53 +0100 Subject: [mcclim-devel] stream-unread-gesture possible bug Message-ID: <16852.61381.926325.894770@serveur5.labri.fr> Hello, I suspect stream-unread-gesture does not work. When stream-read-gesture returns a character and that character gets put back in the stream, it looks like event-sheet gets called on the character (perhaps when it is read again). Obviously, event-sheet does not have a method on characters. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Fri Dec 31 06:30:59 2004 From: strandh at labri.fr (Robert Strandh) Date: Fri, 31 Dec 2004 07:30:59 +0100 Subject: [mcclim-devel] read-gesture again Message-ID: <16852.61987.99630.92529@serveur5.labri.fr> Hello again, >From comments in stream-read-gesture, I get the impression that :peek-p is not working currently. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From amoroso at mclink.it Fri Dec 31 20:03:05 2004 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 31 Dec 2004 21:03:05 +0100 Subject: [mcclim-devel] Re: GCL and mcclim In-Reply-To: (Timothy Moore's message of "Wed, 29 Dec 2004 11:02:24 +0100") References: <200412242153.iBOLrf125920@localhost.localdomain> <20041227174407.1062.qmail@web12209.mail.yahoo.com> <16849.6714.756057.919254@serveur5.labri.fr> <873bxqeng4.fsf@plato.moon.paoloamoroso.it> Message-ID: <874qi2p75y.fsf@plato.moon.paoloamoroso.it> Timothy Moore writes: > On Dec 28, 2004, at 11:17 AM, Paolo Amoroso wrote: [...] >> See my notes on Scigraph: [...] >> There is still some functionality that does not fully work, e.g. some >> command table issues that prevent access to some commands. >> > I'd like to hear about those. A while ago (right after the > common-lisp.net move) I checked in a fix to command tables that > resolved the SciGraph command issues that I knew about. It looks like most of the command table issue I previously reported, i.e. the inability to use right-click menus, have been fixed. A quick check shows that I can now use presentation translator menus on graph elements. By the way, what is the name of Scigraph's command table? GRAPH or :GRAPH? Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From strandh at labri.fr Tue Dec 28 11:50:27 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Dec 2004 11:50:27 -0000 Subject: [mcclim-devel] Fix for Scigraph package lock error with CMUCL In-Reply-To: <87oekplvj6.fsf@plato.moon.paoloamoroso.it> References: <87oekplvj6.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > The current CVS sources of Scigraph generate a package lock error > during compilation or load with recent versions of CMUCL, I think the > 19a prerelease and release series. It is caused by a conflict with > the symbol `cl:variable'. The problem can be fixed by changing in > file Apps/Scigraph/scigraph/package.lisp the form: > > (eval-when (compile load eval) > (defpackage GRAPH > #-allegro (:nicknames gr) ; "GR" names something already. > #+allegro (:shadow variable) ; shouldn't be inherited but is > #+MCL (:shadow copy) > (:use dwim-lisp tool statistics))) > > to this, which removes the conditionalization of `variable' shadowing > for allegro: > > (eval-when (compile load eval) > (defpackage GRAPH > #-allegro (:nicknames gr) ; "GR" names something already. > (:shadow variable) ; shouldn't be inherited but is > #+MCL (:shadow copy) > (:use dwim-lisp tool statistics))) Patch applied. Thanks. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Tue Dec 28 11:50:27 2004 From: strandh at labri.fr (Robert Strandh) Date: Tue, 28 Dec 2004 11:50:27 -0000 Subject: [mcclim-devel] Fix for Scigraph package lock error with CMUCL In-Reply-To: <87oekplvj6.fsf@plato.moon.paoloamoroso.it> References: <87oekplvj6.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > The current CVS sources of Scigraph generate a package lock error > during compilation or load with recent versions of CMUCL, I think the > 19a prerelease and release series. It is caused by a conflict with > the symbol `cl:variable'. The problem can be fixed by changing in > file Apps/Scigraph/scigraph/package.lisp the form: > > (eval-when (compile load eval) > (defpackage GRAPH > #-allegro (:nicknames gr) ; "GR" names something already. > #+allegro (:shadow variable) ; shouldn't be inherited but is > #+MCL (:shadow copy) > (:use dwim-lisp tool statistics))) > > to this, which removes the conditionalization of `variable' shadowing > for allegro: > > (eval-when (compile load eval) > (defpackage GRAPH > #-allegro (:nicknames gr) ; "GR" names something already. > (:shadow variable) ; shouldn't be inherited but is > #+MCL (:shadow copy) > (:use dwim-lisp tool statistics))) Patch applied. Thanks. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------