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

[mcclim-devel] The Manual
by James Ashley 03 Dec '10

03 Dec '10

I realize it's a work in progress, but it really deserves much more credit than it receives on the site. As far as an overview/introduction, it's probably the best I've run across so far. In section 3.7, "Displaying Data Structures," it gets rid of the previous version's :display-time nil parameter to the pane showing the output stream. Using the CVS version of McCLIM (from 2010-10-06) and 64-bit clozure CL release 1.5 (on linux) using the CLX backend, this shows the initial "NIL is not a number," but calling Parity after that doesn't seem to have any affect. I haven't begun to do anywhere near enough digging to really even to begin to guess where to start looking. I don't see anything that resembles this in the past few months worth of archives. Is this known and expected behavior? Can someone clueful point me in the general direction so I can take a stab at fixing the "problem" (maybe just that part of the manual's slightly out of date?) Thanks, James

1 0

[mcclim-devel] Trying to wrap my head around presentations
by James Ashley 03 Dec '10

03 Dec '10

I'm still just toying with ideas, and trying to wrap my brain around the basics. Right this second, just on a whim, I'm thinking of a character-builder for old-school AD&D. Something like a radio-button list where you choose either your race '(human elf half-elf dwarf halfling half-orc) or your class '(fighter magic-user cleric thief monk) and both lists depend on what you've chosen in the other. So you'd be able to select one in the list, and the other would indicate that certain options weren't available. But they aren't actually disabled...just discouraged. Choose a discouraged option, and the other list clears your choice. Maybe some options just aren't available, based on the way you've set your stats. >From what I'm reading so far, this is pretty much the way CLIM was designed. Am I on the right track, or am I still completely missing the point? Thanks, James

1 0

[mcclim-devel] some questions
by Orm Finnendahl 02 Dec '10

02 Dec '10

Hi all, I posted here before quite some time ago but had to interrupt my work. Now I reserved time to be able to concentrate on the implementation in mcclim. I'm trying to program a frontend for the definition of specialized scores of a self-designed system for live-electronics in contemporary music (the backend is done in pure data, but most of the hard work is already getting done in lisp). One part of the frontend is supposed to be similar to a vector graphics program, enabling the creation of straight horizontal colored lines and the nested grouping of those lines. The user should be able to move those lines/groups around, stretch them, clip them and do some other basic editing operations such as copying, insertion and deletion (for an idea, how those graphics look like, you can have a look at: http://icem-www.folkwang-hochschule.de/~finnendahl/download/sandgetriebe-au… ). I used the clim-fig demo application as a point of departure and try to build around this to get a better grasp of the concepts before restarting from scratch. Here are my questions: 1. highlighting: I successfully hooked into the highlighting function. All lines are a presentation using output-recording and highlight on mouse over. I would like to be able to change the highlighting context (with some keystroke) so that e.g. not a single line is highlighted, but all lines of the group, it is contained in. I could do that manually within the highlighting routine by traversing the parent tree of the highlighted object, but I wonder whether it could be possible to hierarchically nest the presentation type classes (and their objects) in a way that the presentations are sensitive to the current context and highlight accordingly without having to replay them on change of context. 2. selection: clicking on a presentation (or a group of presentations) should select that group by displaying a dashed line around the smallest enclosing region of the selected objects and attaching a small square or icon to that square for resizing. If I got the concept correctly, the dashed line plus small square should be displayed as one or more presentations (e.g. of type "region"), which are sensitive to mouse gestures for moving or resizing. Should these presentations get appended to the output record? It seems a little awkward to always replay the whole output record if presentations are deselected. So I wonder how would be the canonical way to do it (I know about incremental redisply, but would it fit here)? 3. I didn't succeed in changing the command invoked on a left mouse-click on a canvas. It is initially defined with "define-presentation-to-command-translator" but I couldn't change the definition to invoke different comands depending on the state of the program. (Like in a drawing programm: when you change the tool in the toolbar, the mouse-click invokes a different command). As far as I understood, the command table is resposible for the bindings, but I didn't find the mechanism for changing the current commmand table. Any help or correction of my assumptions is greatly appreciated! Yours, Orm

1 0

[mcclim-devel] Two problems with McCLIM with gtkairo
by Makarov Alexey 24 Nov '10

24 Nov '10

Hello! I have two problems with gtkairo backend. First problem is black application frame while presented information on frame parts is not changed, mouse pointer is not hover on scrollbar or interactor menu doesn't appear on that pane. This appear in Ubuntu Linux 10.04 with SBCL 1.0.40 and GTK 2.20. Second problem is McCLIM with gtkairo backend hangs on Windows XP on SBCL 1.0.43 (https://sites.google.com/site/dmitryvksite/sbcl-distr/sbcl-1.0.43-threads-g…) and GTK 2.22. I try to eval: (run-frame-top-level (make-application-frame 'superapp)) Then application frame is appear but panes not draw on it and frame hang (can't close window). SBCL hang too, but this issue I can avoid: (sb-thread:make-thread (lambda () (run-frame-top-level (make-application-frame 'superapp)))) I run this code: (defpackage "APP" (:use :clim :clim-lisp) (:export "APP-MAIN")) (in-package :app) (define-application-frame superapp () () (:pointer-documentation t) (:panes (app :application :display-time nil :height 400 :width 600) (int :interactor :height 200 :width 600)) (:layouts (default (vertically () app int)))) (defun app-main () (run-frame-top-level (make-application-frame 'superapp))) (define-superapp-command (com-quit :name t) () (frame-exit *application-frame*)) (define-superapp-command (com-parity :name t) ((number 'integer)) (format t "~a is ~a~%" number (if (oddp number) "odd" "even"))) I use quicklisp and mcclim from quicklisp repository. Have your any ideas to solve that problems? -- Makarov Alexey <alexeys9(a)yandex.ru>

2 1

[mcclim-devel] Feasibility Question
by James Ashley 20 Nov '10

20 Nov '10

Hi, all. I've been programming for close to 30 years now, and I've been trying to find a good excuse to really learn common lisp (as opposed to just dabbling) for the past 3 or so. I think I've finally come across a project that feels like the right "fit." The basic idea is a collaborative 3-d client-side application server with a built-in IDE that persists the state off all its applications between all its program runs. This is total vaporware at the moment...I'm just trying to do some basic research and pick the right tools. I've been involved in way too many where we started out in one environment, got a proof of concept, then realized there were some fundamental limitations that kept us from moving forward, so we essentially had to start over from scratch (or wound up layering ever-more-unmaintainable pieces on top of an unsustainable architecture). Right now, I'm thinking off "applications" being developed on at least 4 different levels. One would be raw common lisp, that interacts directly with the "interpreter." Another would really be creating custom frame managers (I think...I'm just scratching CLIM's surface) to provide eye candy effects (since I'm planning on targeting the masses, I've learned that it's pretty much all about the eye candy). Yet another would be something like the HTML/CSS/Javascript paradigm to create 2-d "applications." And the last would be the actual 3-d world where the users interact. A combination of Open Cobalt and World Forge seemed like the "proper" mix at first. But, the more I dug into smalltalk, the less impressed I was. I kept thinking "If only I could write a macro to do all this..." The more I dug into it, the more I realized just how big and ambitious this project is. If I'm going to be dedicating 10 years (or more) to something, and forcing my users to download some obscure runtime anyway...why not go with a language that left my jaw on the floor and my head spinning? I realize common lisp isn't perfect, but what is? (Clojure's tempting. I downloaded it, spent about 20 minutes to get a REPL, and finally gave up. It may be mature and "ready for the big leagues" before this project is, but...common lisp's there now. Racket's similarly tempting, but I just don't seem to fit with the Scheme community). The ideas behind McClim seem to feel like it's the right "fit" for the GUI part of the project. Not all the eye-candy pieces, of course. Just...conceptually. I've been digging my way through the old mailing list archives (the check-in comments are a lot more educational than I realized at first. I'm glad they got archived that way), and I see that there's been speculation about an OpenGL backend for ages now (and at least an experimental stab at writing one). Conventional wisdom seems to dictate using something like one of the GTK bindings for the UI. But it seems to me that, if I started there, I'd just wind up re-implementing tons of CLIM to get to an abstraction level where I could forget about that and get down to real work. It seems to me that my time would be better spent helping get the GTKairo working solidly. Either way, I'll wind up duplicating the work to switch to some crazy gadget set built entirely on some 3-d engine or other. I see one of the fundamental programs being a traditional "form builder" kind of drag-and-drop thing along the lines of VB. Probably with some kind of tree view (or maybe boxes) to hide the fact that the code's actually being written in lisp. Am I barking up the wrong tree? Like I said...I've been going through the old mailing list archives. I've normally have wrapped that up and at least gotten more than a passing acquaintance with actually writing McCLIM code (at this point, I'm just digesting that ancient CLIM "walk-through" referenced first on the home page) before de-lurking. But I ran across someone else today who seems to be thinking on at least vaguely parallel lines to mine, and I figured this was the best place to check before I wasted his time with my ideas. Thanks, James

3 3

[mcclim-devel] Drei reposition
by Manuel Giraud 27 Sep '10

27 Sep '10

Hi, here's a patch to correct the behaviour of the "C-l" gesture in Climacs to be more like the Emacs one. Index: drei-redisplay.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Drei/drei-redisplay.lisp,v retrieving revision 1.71 diff -u -r1.71 drei-redisplay.lisp --- drei-redisplay.lisp 3 May 2008 07:47:17 -0000 1.71 +++ drei-redisplay.lisp 27 Sep 2010 15:01:16 -0000 @@ -1090,6 +1090,12 @@ (declare (ignore y1)) (- x2 x1))) +(defmethod bounding-rectangle-height ((view drei-buffer-view)) + (multiple-value-bind (x1 y1 x2 y2) + (bounding-rectangle* view) + (declare (ignore x1 x2)) + (- y2 y1))) + (defun drei-bounding-rectangle* (drei-instance) "Return the bounding rectangle of the visual appearance of `drei-instance' as four values, just as `bounding-rectangle*'." @@ -1172,15 +1178,22 @@ "Try to put point close to the middle of the pane by moving top half a pane-size up." (let* ((view (view drei-pane)) - (nb-lines-in-pane (number-of-lines-in-region (top view) (bot view)))) - (with-accessors ((top top) (point point)) view - (setf (offset top) (offset point)) - (beginning-of-line top) - (loop do (beginning-of-line top) - repeat (floor nb-lines-in-pane 2) - until (beginning-of-buffer-p top) - do (decf (offset top)) - (beginning-of-line top)) + (buffer (buffer view)) + (line-and-space-height (+ (text-style-height (medium-merged-text-style + (sheet-medium drei-pane)) drei-pane) + (stream-vertical-spacing drei-pane))) + (nb-lines-in-pane (floor (bounding-rectangle-height drei-pane) + line-and-space-height)) + (nb-lines-in-buffer (number-of-lines buffer))) + (when (> nb-lines-in-buffer nb-lines-in-pane) + (with-accessors ((top top) (point point)) view + (setf (offset top) (offset point)) + (beginning-of-line top) + (loop do (beginning-of-line top) + repeat (floor nb-lines-in-pane 2) + until (beginning-of-buffer-p top) + do (decf (offset top)) + (beginning-of-line top))) (invalidate-all-strokes view :modified t)))) (defun adjust-pane (drei-pane) -- Manuel Giraud

1 0

[mcclim-devel] some (perhaps minor) problems compiling McCLIM on MAC OS/X 10.6.4
by Kevin Smith 10 Aug '10

10 Aug '10

Just compiled McCLIM (and all of it's dependencies) on Mac OS X (version 10.6.4 - Snow Leopard) and got the following undefined variable warnings after compiling (warnings, but no errors). I am compiling on SBCL 1.0.39 +threads and using clx-0.7.4 Are these warnings important ? Most of the example/demo applications from the button menu seem to work with exception of drag and drop example. I can provide any additional information as needed. ; file: /Users/kevinsmith/sbcl-lisp/mcclim-0.9.6/bordered-output.lisp ; in: CLIM:DEFINE-BORDER-TYPE :INSET ; (LET ((CLIM-INTERNALS::DARK CLIM-INTERNALS::*3D-DARK-COLOR*) ; (CLIM-INTERNALS::LIGHT CLIM-INTERNALS::*3D-LIGHT-COLOR*)) ; (FLET ((CLIM-INTERNALS::DRAW ; (CLIM-INTERNALS::LEFT-EDGE CLIM-INTERNALS::RIGHT-EDGE ; CLIM-INTERNALS::BOTTOM-EDGE CLIM-INTERNALS::TOP-EDGE ; CLIM-INTERNALS::LIGHT CLIM-INTERNALS::DARK) ; (CLIM:DRAW-LINE* STREAM CLIM-INTERNALS::LEFT-EDGE ; CLIM-INTERNALS::BOTTOM-EDGE ; CLIM-INTERNALS::LEFT-EDGE ; CLIM-INTERNALS::TOP-EDGE :INK ; CLIM-INTERNALS::DARK) ; (CLIM:DRAW-LINE* STREAM CLIM-INTERNALS::LEFT-EDGE ; CLIM-INTERNALS::TOP-EDGE ; CLIM-INTERNALS::RIGHT-EDGE ; CLIM-INTERNALS::TOP-EDGE :INK ; CLIM-INTERNALS::DARK) ; (CLIM:DRAW-LINE* STREAM CLIM-INTERNALS::RIGHT-EDGE ; CLIM-INTERNALS::BOTTOM-EDGE ; CLIM-INTERNALS::RIGHT-EDGE ; CLIM-INTERNALS::TOP-EDGE :INK ; CLIM-INTERNALS::LIGHT) ; (CLIM:DRAW-LINE* STREAM CLIM-INTERNALS::LEFT-EDGE ; CLIM-INTERNALS::BOTTOM-EDGE ; CLIM-INTERNALS::RIGHT-EDGE ; CLIM-INTERNALS::BOTTOM-EDGE :INK ; CLIM-INTERNALS::LIGHT))) ; (CLIM-INTERNALS::DRAW CLIM-INTERNALS::LEFT CLIM-INTERNALS::RIGHT ; CLIM-INTERNALS::BOTTOM CLIM-INTERNALS::TOP CLIM-INTERNALS::LIGHT ; CLIM-INTERNALS::DARK) ; (CLIM-INTERNALS::DRAW (1+ CLIM-INTERNALS::LEFT) ; (1- CLIM-INTERNALS::RIGHT) (1- CLIM-INTERNALS::BOTTOM) ; (1+ CLIM-INTERNALS::TOP) CLIM-INTERNALS::LIGHT CLIM-INTERNALS::DARK))) ; ; caught WARNING: ; undefined variable: CLIM-INTERNALS::*3D-DARK-COLOR* ; ; caught WARNING: ; undefined variable: CLIM-INTERNALS::*3D-LIGHT-COLOR* ; file: /Users/kevinsmith/sbcl-lisp/mcclim-0.9.6/Goatee/presentation-history.lisp ; in: DEFUN GOATEE::CMD-HISTORY-YANK-PREVIOUS ; (LET* ((GOATEE::ACCEPTING-TYPE CLIM-INTERNALS::*ACTIVE-HISTORY-TYPE*) ; (GOATEE::HISTORY ; (AND GOATEE::ACCEPTING-TYPE ; (CLIM:PRESENTATION-TYPE-HISTORY GOATEE::ACCEPTING-TYPE)))) ; (WHEN GOATEE::HISTORY ; (MULTIPLE-VALUE-BIND (GOATEE::OBJECT TYPE) ; (CLIM-INTERNALS::PRESENTATION-HISTORY-PREVIOUS GOATEE::HISTORY ; GOATEE::ACCEPTING-TYPE) ; (WHEN TYPE ; (GOATEE::CLEAR-BUFFER GOATEE::*BUFFER*) ; (GOATEE::INSERT-PTYPE-HISTORY GOATEE::OBJECT TYPE))))) ; ; caught WARNING: ; undefined variable: CLIM-INTERNALS::*ACTIVE-HISTORY-TYPE* ; in: DEFUN GOATEE::CMD-HISTORY-YANK-NEXT ; (LET* ((GOATEE::ACCEPTING-TYPE CLIM-INTERNALS::*ACTIVE-HISTORY-TYPE*) ; (GOATEE::HISTORY ; (AND GOATEE::ACCEPTING-TYPE ; (CLIM:PRESENTATION-TYPE-HISTORY GOATEE::ACCEPTING-TYPE)))) ; (WHEN GOATEE::HISTORY ; (MULTIPLE-VALUE-BIND (GOATEE::OBJECT TYPE) ; (CLIM-INTERNALS::PRESENTATION-HISTORY-NEXT GOATEE::HISTORY ; GOATEE::ACCEPTING-TYPE) ; (WHEN TYPE ; (GOATEE::CLEAR-BUFFER GOATEE::*BUFFER*) ; (GOATEE::INSERT-PTYPE-HISTORY GOATEE::OBJECT TYPE))))) ; ; caught WARNING: ; undefined variable: CLIM-INTERNALS::*ACTIVE-HISTORY-TYPE* ; file: /Users/kevinsmith/sbcl-lisp/mcclim-0.9.6/frames.lisp ; in: ; DEFMETHOD CLIM-INTERNALS::FRAME-PRINT-POINTER-DOCUMENTATION (CLIM:STANDARD-APPLICATION-FRAME ; T T T T) ; (+ (CLIM-INTERNALS::BACKGROUND-MESSAGE-TIME CLIM-INTERNALS::PSTREAM) ; CLIM-INTERNALS::*BACKGROUND-MESSAGE-MINIMUM-LIFETIME*) ; ; caught WARNING: ; undefined variable: CLIM-INTERNALS::*BACKGROUND-MESSAGE-MINIMUM-LIFETIME* ; file: /Users/kevinsmith/sbcl-lisp/mcclim-0.9.6/commands.lisp ; in: DEFUN CLIM-INTERNALS::PARTIAL-COMMAND-FROM-NAME ; (GETHASH CLIM:COMMAND-NAME CLIM-INTERNALS::*COMMAND-PARSER-TABLE*) ; ==> ; (SB-IMPL::GETHASH3 CLIM:COMMAND-NAME CLIM-INTERNALS::*COMMAND-PARSER-TABLE* ; NIL) ; ; caught WARNING: ; undefined variable: CLIM-INTERNALS::*COMMAND-PARSER-TABLE* ; file: /Users/kevinsmith/sbcl-lisp/mcclim-0.9.6/Drei/views.lisp ; in: DEFUN DREI::GET-CHUNK ; (+ DREI:*MAXIMUM-CHUNK-SIZE* DREI::CHUNK-START-OFFSET) ; ; caught WARNING: ; undefined variable: DREI:*MAXIMUM-CHUNK-SIZE* ; file: /Users/kevinsmith/sbcl-lisp/mcclim-0.9.6/presentations.lisp ; in: DEFUN CLIM:CALL-PRESENTATION-MENU ; (CLIM:MENU-CHOOSE CLIM-INTERNALS::ITEMS :LABEL CLIM-INTERNALS::LABEL ; :ASSOCIATED-WINDOW CLIM-INTERNALS::WINDOW :PRINTER ; #'(LAMBDA (CLIM-INTERNALS::ITEM STREAM) ; (LET ((CLIM-INTERNALS::OBJECT #)) ; (CLIM:DOCUMENT-PRESENTATION-TRANSLATOR ; (CLIM-INTERNALS::PRESENTATION-TRANSLATOR-MENU-ITEM-TRANSLATOR ; CLIM-INTERNALS::OBJECT) ; (CLIM-INTERNALS::PRESENTATION-TRANSLATOR-MENU-ITEM-PRESENTATION ; CLIM-INTERNALS::OBJECT) ; (CLIM-INTERNALS::PRESENTATION-TRANSLATOR-MENU-ITEM-CONTEXT ; CLIM-INTERNALS::OBJECT) ; CLIM-INTERNALS::FRAME NIL CLIM-INTERNALS::WINDOW CLIM-INTERNALS::X ; CLIM-INTERNALS::Y :STREAM STREAM))) ; :LABEL CLIM-INTERNALS::LABEL :POINTER-DOCUMENTATION ; CLIM:*POINTER-DOCUMENTATION-OUTPUT*) ; ; caught WARNING: ; undefined variable: CLIM:*POINTER-DOCUMENTATION-OUTPUT* ; file: /Users/kevinsmith/sbcl-lisp/mcclim-0.9.6/Backends/PostScript/graphics.lisp ; in: DEFUN CLIM-POSTSCRIPT::WRITE-COORDINATES ; (CLIM-INTERNALS::WITH-TRANSFORMED-POSITION (CLIM-POSTSCRIPT::*TRANSFORMATION* ; CLIM-POSTSCRIPT::X ; CLIM-POSTSCRIPT::Y) ; (CLIM-POSTSCRIPT::WRITE-NUMBER STREAM CLIM-POSTSCRIPT::X) ; (CLIM-POSTSCRIPT::WRITE-NUMBER STREAM CLIM-POSTSCRIPT::Y)) ; --> MULTIPLE-VALUE-BIND MULTIPLE-VALUE-CALL ; ==> ; (CLIM:TRANSFORM-POSITION CLIM-POSTSCRIPT::*TRANSFORMATION* CLIM-POSTSCRIPT::X ; CLIM-POSTSCRIPT::Y) ; ; caught WARNING: ; undefined variable: CLIM-POSTSCRIPT::*TRANSFORMATION* ; file: /Users/kevinsmith/sbcl-lisp/mcclim-0.9.6/commands.lisp ; in: DEFUN CLIM-INTERNALS::PARTIAL-COMMAND-FROM-NAME ; #'(LAMBDA (CLIM-INTERNALS::FOO) ; (DECLARE (IGNORE CLIM-INTERNALS::FOO)) ; CLIM:*UNSUPPLIED-ARGUMENT-MARKER*) ; ; caught WARNING: ; undefined variable: CLIM:*UNSUPPLIED-ARGUMENT-MARKER* ; file: /Users/kevinsmith/sbcl-lisp/mcclim-0.9.6/design.lisp ; in: DEFUN CLIM:MAKE-OPACITY ; (COND ((= CLIM-INTERNALS::VALUE 0) CLIM:+TRANSPARENT-INK+) ; ((= CLIM-INTERNALS::VALUE 1) CLIM:+EVERYWHERE+) ; (T ; (MAKE-INSTANCE 'CLIM-INTERNALS::STANDARD-OPACITY :VALUE ; CLIM-INTERNALS::VALUE))) ; --> IF COND IF ; ==> ; (PROGN CLIM:+EVERYWHERE+) ; ; caught WARNING: ; undefined variable: CLIM:+EVERYWHERE+ ; in: DEFMETHOD CLIM:COMPOSE-OUT (CLIM:DESIGN CLIM:COLOR) ; (DEFMETHOD CLIM:COMPOSE-OUT ; ((CLIM:DESIGN CLIM:DESIGN) (CLIM-INTERNALS::MASK CLIM:COLOR)) ; (DECLARE (IGNORE CLIM:DESIGN CLIM-INTERNALS::MASK)) ; CLIM:+NOWHERE+) ; --> PROGN EVAL-WHEN SB-PCL::%DEFMETHOD-EXPANDER PROGN SB-PCL::LOAD-DEFMETHOD ; --> SYMBOL-MACROLET SB-PCL::FAST-LEXICAL-METHOD-FUNCTIONS ; --> SB-PCL::BIND-FAST-LEXICAL-METHOD-FUNCTIONS LOCALLY SB-PCL::BIND-ARGS LET* ; --> LOCALLY SYMBOL-MACROLET ; ==> ; (BLOCK CLIM:COMPOSE-OUT CLIM:+NOWHERE+) ; ; caught WARNING: ; undefined variable: CLIM:+NOWHERE+ ; in: ; DEFMETHOD CLIM:COMPOSE-OUT (CLIM:DESIGN CLIM-INTERNALS::EVERYWHERE-MIXIN) ; (DEFMETHOD CLIM:COMPOSE-OUT ; ((CLIM:DESIGN CLIM:DESIGN) ; (CLIM-INTERNALS::MASK CLIM-INTERNALS::EVERYWHERE-MIXIN)) ; (DECLARE (IGNORE CLIM:DESIGN CLIM-INTERNALS::MASK)) ; CLIM:+NOWHERE+) ; --> PROGN EVAL-WHEN SB-PCL::%DEFMETHOD-EXPANDER PROGN SB-PCL::LOAD-DEFMETHOD ; --> SYMBOL-MACROLET SB-PCL::FAST-LEXICAL-METHOD-FUNCTIONS ; --> SB-PCL::BIND-FAST-LEXICAL-METHOD-FUNCTIONS LOCALLY SB-PCL::BIND-ARGS LET* ; --> LOCALLY SYMBOL-MACROLET ; ==> ; (BLOCK CLIM:COMPOSE-OUT CLIM:+NOWHERE+) ; ; caught WARNING: ; undefined variable: CLIM:+NOWHERE+ ; in: ; DEFMETHOD CLIM:COMPOSE-IN (CLIM:DESIGN CLIM-INTERNALS::NOWHERE-MIXIN) ; (DEFMETHOD CLIM:COMPOSE-IN ; ((CLIM:DESIGN CLIM:DESIGN) ; (CLIM-INTERNALS::MASK CLIM-INTERNALS::NOWHERE-MIXIN)) ; (DECLARE (IGNORE CLIM:DESIGN CLIM-INTERNALS::MASK)) ; CLIM:+NOWHERE+) ; --> PROGN EVAL-WHEN SB-PCL::%DEFMETHOD-EXPANDER PROGN SB-PCL::LOAD-DEFMETHOD ; --> SYMBOL-MACROLET SB-PCL::FAST-LEXICAL-METHOD-FUNCTIONS ; --> SB-PCL::BIND-FAST-LEXICAL-METHOD-FUNCTIONS LOCALLY SB-PCL::BIND-ARGS LET* ; --> LOCALLY SYMBOL-MACROLET ; ==> ; (BLOCK CLIM:COMPOSE-IN CLIM:+NOWHERE+) ; ; caught WARNING: ; undefined variable: CLIM:+NOWHERE+ ; file: /Users/kevinsmith/sbcl-lisp/mcclim-0.9.6/Drei/lisp-syntax.lisp ; in: DREI-SYNTAX:DEFINE-SYNTAX DREI-LISP-SYNTAX:LISP-SYNTAX ; (DREI-SYNTAX:DEFINE-SYNTAX DREI-LISP-SYNTAX:LISP-SYNTAX ; (DREI-LR-SYNTAX:LR-SYNTAX-MIXIN ; DREI-FUNDAMENTAL-SYNTAX:FUNDAMENTAL-SYNTAX) ; ((DREI-LISP-SYNTAX::%PACKAGE-LIST :ACCESSOR ; DREI-LISP-SYNTAX::PACKAGE-LIST :DOCUMENTATION ; "An alist mapping the end offset ; of (in-package) forms to a string of the package designator in ; the form. The list is sorted with the earliest (in-package) forms ; last (descending offset).") ; (DREI-LISP-SYNTAX::%BASE :INITFORM NIL ; :DOCUMENTATION ; "The base which numbers in the buffer are ; expected to be in. If the provided value is NIL, the value of ; `*read-base*' will be used." ; :TYPE (OR NULL (INTEGER 2 36))) ; (DREI-LISP-SYNTAX::%OPTION-SPECIFIED-PACKAGE ; :ACCESSOR ; DREI-LISP-SYNTAX::OPTION-SPECIFIED-PACKAGE ; :INITFORM NIL :DOCUMENTATION "The package ; specified in the attribute line (may be overridden ; by (in-package) forms). This may be either a string (the name of ; the intended package) or a package object.") ; (DREI-LISP-SYNTAX::%IMAGE :ACCESSOR ; DREI-LISP-SYNTAX::IMAGE :INITFORM NIL ; :DOCUMENTATION "An image object (or NIL) that ; determines where and how Lisp code in the buffer of the ; syntax should be run.") ; (DREI-LISP-SYNTAX::%FORM-BEFORE-CACHE :ACCESSOR ; DREI-LISP-SYNTAX::FORM-BEFORE-CACHE :INITFORM ; (MAKE-HASH-TABLE :TEST #'EQUAL)) ; (DREI-LISP-SYNTAX::%FORM-AFTER-CACHE :ACCESSOR ; DREI-LISP-SYNTAX::FORM-AFTER-CACHE :INITFORM ; (MAKE-HASH-TABLE :TEST #'EQUAL)) ; (DREI-LISP-SYNTAX::%FORM-AROUND-CACHE :ACCESSOR ; DREI-LISP-SYNTAX::FORM-AROUND-CACHE :INITFORM ; (MAKE-HASH-TABLE :TEST #'EQUAL))) ; (:NAME "Lisp") (:PATHNAME-TYPES "lisp" "lsp" "cl") ; (:COMMAND-TABLE DREI-LISP-SYNTAX:LISP-TABLE) ; (:DEFAULT-INITARGS :INITIAL-STATE ; DREI-LISP-SYNTAX::|initial-state |)) ; --> PROGN CLIM-LISP-PATCH:DEFCLASS PROGN DEFCLASS PROGN EVAL-WHEN LET LET ; ==> ; #'(LAMBDA () ; (DECLARE (OPTIMIZE (SB-C:STORE-COVERAGE-DATA 0))) ; DREI-LISP-SYNTAX::|initial-state |) ; ; caught WARNING: ; undefined variable: DREI-LISP-SYNTAX::|initial-state | ; ; compilation unit finished ; Undefined functions: ; DREI-SYNTAX::LOW-MARK CLIM:MEDIUM CLIM-INTERNALS::WITH-MEDIUM-OPTIONS ; Undefined variables: ; CLIM-INTERNALS::*3D-DARK-COLOR* CLIM-INTERNALS::*3D-LIGHT-COLOR* CLIM-INTERNALS::*ACTIVE-HISTORY-TYPE* CLIM-INTERNALS::*BACKGROUND-MESSAGE-MINIMUM-LIFETIME* CLIM-INTERNALS::*COMMAND-PARSER-TABLE* DREI:*MAXIMUM-CHUNK-SIZE* CLIM:*POINTER-DOCUMENTATION-OUTPUT* CLIM-POSTSCRIPT::*TRANSFORMATION* CLIM:*UNSUPPLIED-ARGUMENT-MARKER* CLIM:+EVERYWHERE+ CLIM:+NOWHERE+ DREI-LISP-SYNTAX::|initial-state | ; caught 15 WARNING conditions ; printed 951 notes ("SB-GROVEL" "SB-BSD-SOCKETS")

1 0

[mcclim-devel] Push or Pull data in application
by Oliver Uvman 14 Jul '10

14 Jul '10

Hello! I'm now beginning to write my first GUI with McClim, and there seem to be an abundance of interface-building resources, so I'll be able to keep going for a while without help. I am writing this as an additional user interface to our backend program. The backend is a calendar program used at my university (Linköping University) to teach abstraction. The idea is that either manual interaction with the backend or interaction via the Clim frontend can be used, at the same time or separately. Anything done in one should be observable in the other. The problem I know I will eventually run into is updating the Clim interface when changes to data have been made through manual interaction with the backend. The solutions are either push or pull based, I guess. Push based is not really prefered, because the backend would have to keep track of the gui so it can send messages to it. We need to keep the backend as simple and clean as possible, because it is to be modified by the students. Thus I would rather prefer a pull-based approach where, every 80-90ms or so the application itself requests up-to-date data from the backend and redraws if necessary. Is there a standard way to go about this? It seems like it is a problem that would appear in almost any application. Regards, Oliver Uvman

3 3

[mcclim-devel] Errors installing McClim
by Oliver Uvman 13 Jul '10

13 Jul '10

Hello! I'm trying to follow the guide on http://mcclim.cliki.net/McCLIM%2BSBCL for installing McClim, but when I do (asdf-install:install :mcclim) I get an error, which I tried to accept and continue the install from, but the errors just keep coming after that so I thought I'd ask. The error I'm getting is: ; compilation aborted because of fatal error: ; SB-INT:SIMPLE-READER-PACKAGE-ERROR at 5151 (line 128, column 45) on #<SB-SYS:FD-STREAM ; for "file /usr/share/common-lisp/source/slime/swank-loader.lisp" ; {BF565E1}>: ; package "CLC" not found ; ; compilation aborted after 0:00:00.063 debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {A9F5811}>: The value NIL is not of type (OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME STREAM). I tried (asdf-install:install :clc) but there doesn't seem to be a package with that name. I know it stands for common-lisp-controller, and I have it apt-getted on my system (Ubuntu Lucid x86). Anybody know what the problem is? Regards, Oliver Uvman

7 15

Re: [mcclim-devel] Push or Pull data in application
by matthieu.villeneuve＠free.fr 13 Jul '10

13 Jul '10

----- "Oliver Uvman" <oliver.uvman(a)gmail.com> a écrit : > Matthieu: Yes, that would be the push-type mechanism. The problem > about it then is that the backend would have to know when a gui is > running or not, and be able to send messages to that gui (keeping > some > address reference to it or whatever). I'd rather not touch the > backend > code at all, as that would muddy the waters for the people who are > looking at the first large lisp app in their lives. The thing is, even if the :after methods I was talking about are "attached" to backend generic functions, I consider that they belong to the GUI code, so the backend code doesn't have to maintain information about the GUI. Something like this: (in-package :app-gui) (defun draw-foo (object) ...) (defmethod app-backend:set-coords :after ((object foo) x y) (when *application-frame* (draw-foo object))) That way, the backend code doesn't depend on the GUI code. If you group those :after methods in a separate file, you could even choose to load it or not, depending on whether you want to allow direct modifications of backend data (which should be reflected in the GUI). > Maybe I should also note that this is the first time the students > meet > layered abstraction, so the app so far has a strict top-down > dependency model. Code in one layer may not depend on code in a layer > above it. Preferably I'd like to keep the gui in a layer of its own, > above all other layers. This would keep things simple for the > students, they'd never need to look in the gui code (if they don't > want to). > > /Oliver > > On Tue, Jul 13, 2010 at 16:01, <matthieu.villeneuve(a)free.fr> wrote: > > Hello, > > > > ----- "Oliver Uvman" <oliver.uvman(a)gmail.com> a écrit : > >> The problem I know I will eventually run into is updating the Clim > >> interface when changes to data have been made through manual > >> interaction with the backend. The solutions are either push or > pull > >> based, I guess. Push based is not really prefered, because the > backend > >> would have to keep track of the gui so it can send messages to it. > > > > [Disclaimer: I don't remember much about GUIs and CLIM...] > > > > Couldn't you define, as part of your GUI code, and for every > "relevant" > > backend method that updates the application data, an :after method > that > > updates or refreshes the interface contents? -- Matthieu Villeneuve

2 1