From jdunrue at gmail.com Wed Nov 1 00:47:42 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Tue, 31 Oct 2006 17:47:42 -0700 Subject: [mcclim-devel] xxxx Message-ID: Greetings, I've had a few days now to sort of stumble around in my initial attempts at implementing a new backend[1]. The existing backend code and the spec help a lot, so the stumbling is just me getting familiar with a new codebase which for me is always a challenge. I think various concepts are starting to sink in. Apologies in advance for naive statements in the following and feel free to correct my understanding :-) I've got the general idea that a backend implements a class hierarchy with the responsibility of tying backend-specific constructs (represented by mirrors) to the system-agnostic representation (panes, sheets, and gadgets). The resulting McCLIM object hierarchy needs to shadow the logical structure in the native windowing system (e.g., window parent/child relationships). In McCLIM, one implements specializations of make-pane-1 and realize-mirror to accomplish that. Correct? Looking at the existing backends, it appears to my inexperienced eye that I have considerable latitude in establishing the mapping. That includes making use of various classes, functions, etc whose symbols are in the climi package, as needed. It's nice that there are various sanity checks in place that help catch mistakes. But essentially there are no prohibitions beyond those sanity checks and expected behavior as described by the spec? I haven't yet found any list of "do's and don'ts", e.g. on McCLiki, but hopefully folks will provide review feedback to that effect. At the moment, my event dispatching solution consists of implementing get-next-event for my port, returning the appropriate event type based on my mapping between Windows messages and CLIM events. I'm not sure yet whether I can implement the timeout feature. Anyway, I'm not otherwise touching any of the event queue-related stuff that I see in McCLIM proper, and I'm assuming for the time being that this backend will not enable multi-processing -- if and when SBCL/Win32 gets multi-threading then I'll have to revisit this. I haven't yet delved into mediums and designs, as I'm still trying to get basic window, menu, and gadget construction working correctly. But graphics support is obviously on the near horizon. I'm looking forward to making code available as soon as I'm not completely embarrassed by it :-) -- Jack Unrue [1] for those that haven't heard, I'm working on a Win32 backend via Graphic-Forms, which is my CL library for Windows GUIs. From jdunrue at gmail.com Wed Nov 1 00:52:00 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Tue, 31 Oct 2006 17:52:00 -0700 Subject: [mcclim-devel] introduction, was: xxxx Message-ID: Sorry about the nonsensical subject line. -- Jack Unrue From strandh at labri.fr Wed Nov 1 06:24:54 2006 From: strandh at labri.fr (Robert Strandh) Date: Wed, 1 Nov 2006 07:24:54 +0100 Subject: [mcclim-devel] xxxx In-Reply-To: References: Message-ID: <17736.15798.866598.141250@serveur5.labri.fr> Jack Unrue writes: > > I've got the general idea that a backend implements a class hierarchy > with the responsibility of tying backend-specific constructs (represented > by mirrors) to the system-agnostic representation (panes, sheets, > and gadgets). The resulting McCLIM object hierarchy needs to shadow > the logical structure in the native windowing system (e.g., window > parent/child relationships). In McCLIM, one implements specializations > of make-pane-1 and realize-mirror to accomplish that. Correct? Not quite. As an implementor of backends, you have a choice between which sheets should be mirrored: pretty much every sheet, only the top-level sheet, or any solution in between. For the X11 backend, as many sheets as possible are mirrored, but there are backends (OpenGL?) that do not have a hierarchy of windows, and for such backends, CLIM does implements the parent-child relationship itself. -- 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 athas at sigkill.dk Sat Nov 4 21:55:29 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Sat, 04 Nov 2006 22:55:29 +0100 Subject: [mcclim-devel] Drei - a replacement for Goatee Message-ID: <87velulvvy.fsf@sigkill.dk> For a while, I have been working on something I call Drei (acronym currently ambiguous - I like Drei Replaces EINE's Inheritor personally, but Drei Reimplements Emacs Internals is also nice). It's a CLIM editing component based on Climacs, that I have used to implement a text-editor gadget, text-field gadget and input-editor (input-editing stream) for McCLIM. I would like to commit this to McCLIM, but due to the fairly large amount of code required (about 17.000 lines), I thought I'd post a description here first to allow people to object, if they see a problem. Due to the large number of added lines, and a few new directories, I have a hard time getting CVS to create a patch. Instead, I have created a tarball containing my modified McCLIM (with the Doc and Webpage folders removed to reduce size). It is available here: http://sigkill.dk/code/mcclim-drei.tar.gz Drei is basically Climacs, but everything that assumes it runs in a dedicated editor application (such as buffer-switching functionality) has been removed. Also, only Lisp syntax and Fundamental syntax is included. Apart from this, a programmatic interface to Drei has been created, as well as an implementation of the CLIM input-editing-stream protocol (based on Goatee code, but extensively modified and completely independent of Goatee) and a minor bit of indirection, that makes requests for :text-editor and :text-field gadgets create Drei gadget panes. Drei cannot be run as an independent application, but it has been designed so that it would be easy to base Climacs on Drei. Since Drei requires much of the functionality of ESA, I also intend to add ESA to McCLIM. This has required me to do a bit of hacking around in mcclim.asd because ESA normally requires McCLIM to be loaded, but due to Drei, it is necessary to load ESA before McCLIM has been fully loaded. Of course, a standard esa.asd is also provided, and while the internals of ESA have been rather extensively modified (especially the command processing code), the API should be fully backwards-compatible. Since Goatee deviates slightly from the CLIM spec, especially in the input-editor, I have also patched a few places in McCLIM that rely on internal Goatee implementation details or Goatee assumptions to be more general. I have also added a switch variable clim-internals::*use-goatee* (T by default) that switches between the use of Drei and Goatee. Generally, the number of changes (as opposed to additions) to the McCLIM code is extremely limited, except for the input-editing.lisp file. Here is a probably incomplete executive summary of some Drei/Goatee details: DREI PROS: * Drei has more functionality than Goatee, including a proper buffer protocol and the use of syntaxes (permitting, among other things, syntax-highlighting). * Drei is a better CLIM citizen - Goatee does not use command tables to tie gestures to commands and does not permit the binding of a sequence of gestures (such as C-x C-f) to a command. Drei uses a number of perfectly normal CLIM command tables that the user can freely define his own commands for. This could also be phrased as "Drei is easier to customize". * Drei has more commands than Goatee. * Drei can print information in the minibuffer if one is avaiable. When no minibuffer is available, Drei will attempt to use the *pointer-documentation* stream (doesn't work very well yet, though). * Drei is flexible enough to be used anywhere - if you define an editing command for Drei, it can be used in the input-editor, text-editor gadgets and Climacs. Goatee does not (at the moment) have enough functionality to be used for implementing something like Climacs. * The Drei text-editor gadget supports more options than the Goatee gadget (everything in the CLIM spec I think). * Drei supports arbitrary objects in the buffer. Check my customized accept method for `expression' (the bottom of Drei/input-editor.lisp) to see how this can be exploited. * Drei has `add-input-editor-command'! DREI CONS: * Drei is _vastly_ slower than Goatee and uses way more memory. I think the situation can improve by improving the incremental-redisplay code, but in general, Drei will always be slower because it does so much more (such as presentational output) than Goatee. * Drei is not as well tested as Goatee. * Drei does not support linebreaks in noise-strings. This is fixable with a moderate amount of work (it's related to the way Drei handles redisplay - it gets surly and grumpy if anything but an explicit #\Newline character causes a jump to the next line). * Drei does not support input-editor-typeout (neither does Goatee AFAIK, though). So, what are your thoughts? -- \ Troels "Athas" /\ Henriksen From langstefan at gmx.at Sun Nov 5 16:33:33 2006 From: langstefan at gmx.at (Stefan Lang) Date: Sun, 5 Nov 2006 17:33:33 +0100 Subject: [mcclim-devel] Wrong function name in guided tour Message-ID: <200611051733.33676.langstefan@gmx.at> On page 12 in guided-tour.dvi, the code: (run-top-level-frame ... should read (run-frame-top-level ... Stefan From langstefan at gmx.at Sun Nov 5 16:37:33 2006 From: langstefan at gmx.at (Stefan Lang) Date: Sun, 5 Nov 2006 17:37:33 +0100 Subject: [mcclim-devel] Wrong function name in guided tour In-Reply-To: <200611051733.33676.langstefan@gmx.at> References: <200611051733.33676.langstefan@gmx.at> Message-ID: <200611051737.34030.langstefan@gmx.at> On Sunday 05 November 2006 17:33, Stefan Lang wrote: > On page 12 in guided-tour.dvi, the code: > > (run-top-level-frame ... > > should read > > (run-frame-top-level ... There's another wrong name in the code snippet: 'color-edit should be 'color-editor. Stefan From athas at sigkill.dk Sun Nov 5 16:54:52 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Sun, 05 Nov 2006 17:54:52 +0100 Subject: [mcclim-devel] Wrong function name in guided tour In-Reply-To: <200611051737.34030.langstefan@gmx.at> (Stefan Lang's message of "Sun, 5 Nov 2006 17:37:33 +0100") References: <200611051733.33676.langstefan@gmx.at> <200611051737.34030.langstefan@gmx.at> Message-ID: <87veltn89v.fsf@sigkill.dk> Stefan Lang writes: > There's another wrong name in the code snippet: > 'color-edit should be 'color-editor. Thank you, now fixed. -- \ Troels "Athas" /\ Henriksen From athas at sigkill.dk Wed Nov 8 14:14:35 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 08 Nov 2006 15:14:35 +0100 Subject: [mcclim-devel] Drei - a replacement for Goatee In-Reply-To: <87velulvvy.fsf@sigkill.dk> (Troels Henriksen's message of "Sat, 04 Nov 2006 22:55:29 +0100") References: <87velulvvy.fsf@sigkill.dk> Message-ID: <87lkmmkotw.fsf@sigkill.dk> Last night, I committed Drei to the McCLIM repository. It's still disabled by default, (setf climi::*use-goatee* nil) to enable it. I do not claim that it is perfect, nor bug-free, nor even completely adhering to the CLIM spec, but I believe it's good enough to replace Goatee, at least for machines with sufficient memory. -- \ Troels "Athas" /\ Henriksen From athas at sigkill.dk Wed Nov 8 22:20:15 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 08 Nov 2006 23:20:15 +0100 Subject: [mcclim-devel] Sheet size/redisplay issues Message-ID: <87bqnhlgww.fsf@sigkill.dk> This patch by David Lichteblau (http://common-lisp.net/pipermail/mcclim-cvs/2006-November/000612.html) causes problems in McCLIM with respect to redisplay - sheets are not fully redisplayed, but are cutoff some pixels from the edge, at least with the CLX backend. I don't know enough about how sheets work in McCLIM to feel comfortable fixing this, but I hope this message will catch the eye of some McCLIM hacker who can figure out the right fix. -- \ Troels "Athas" /\ Henriksen From david at lichteblau.com Thu Nov 9 12:05:47 2006 From: david at lichteblau.com (David Lichteblau) Date: Thu, 9 Nov 2006 13:05:47 +0100 Subject: [mcclim-devel] Sheet size/redisplay issues In-Reply-To: <87bqnhlgww.fsf@sigkill.dk> References: <87bqnhlgww.fsf@sigkill.dk> Message-ID: <20061109120547.GA4015@gargravarr.knowledgetools.de> Quoting Troels Henriksen (athas at sigkill.dk): > This patch by David Lichteblau > (http://common-lisp.net/pipermail/mcclim-cvs/2006-November/000612.html) > causes problems in McCLIM with respect to redisplay - sheets are not > fully redisplayed, but are cutoff some pixels from the edge, at least > with the CLX backend. I don't know enough about how sheets work in > McCLIM to feel comfortable fixing this, but I hope this message will > catch the eye of some McCLIM hacker who can figure out the right fix. Okay -- looking at your screenshot (thanks!) that seems just like the similar problem I have with Gtkairo. So although Gtkairo has much more trouble of this sort, it probably indicates that the underlying problem is not in the backend after all. I will either fix or revert this (unless someone else does it first). David From jm at mak.com Sat Nov 11 16:56:53 2006 From: jm at mak.com (John Morrison) Date: Sat, 11 Nov 2006 11:56:53 -0500 Subject: [mcclim-devel] stupid newbie question re: initializing text-field In-Reply-To: <87zmci2qh6.fsf@sigkill.dk> References: <200609291809.37498.jm@mak.com> <200609291907.46134.jm@mak.com> <87zmci2qh6.fsf@sigkill.dk> Message-ID: <200611111156.54695.jm@mak.com> On Friday 29 September 2006 19:38, Troels Henriksen wrote: > The Goatee editable area object, which contains the buffer, is not > initialized until the first redisplay happens, so it is impossible to > access the buffer before then. Hence, you cannot use (setf > gadget-value) on a text-field or text-editor gadget in McCLIM before > your command loop is running and the gadget has been redisplayed at > least once. I'm pretty sure this is a bug in McCLIM (if anyone wants > to fix it, look at the definition of `handle-repaint' for > `text-field-pane' in gadget.lisp line 2542). DREI obviates this problem. So a double "thank you" is owed by me to you. Thanks, doubly! -jm -- ==== John Morrison ==== MAK Technologies Inc. ==== 68 Moulton Street, Cambridge, MA 02138 ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== jm at mak.com From dkixk at earthlink.net Sun Nov 12 09:03:20 2006 From: dkixk at earthlink.net (Damien Kick) Date: Sun, 12 Nov 2006 03:03:20 -0600 Subject: [mcclim-devel] Problems with McClim demo Message-ID: I checked McClim and Flexichain out of CVS, used ASDF to load them, and then tried to run the address-book demo but it did not work for me. I've tried searching the web for a FAQ about this but haven't been able to find anything. I did start looking through the mailing list archives but without a search option I have only found a suggestion to make sure that DISPLAY is set. CLIM-DEMO> (sys:getenv "DISPLAY") ":0.0" CLIM-DEMO> (run-frame-top-level (make-application-frame 'address-book)) ; Evaluation aborted CLIM-DEMO> (lisp-implementation-type) "International Allegro CL Professional Edition" CLIM-DEMO> (lisp-implementation-version) "8.0 [Mac OS X] (Nov 11, 2006 22:53)" CLIM-DEMO> (software-type) "Apple Mac OS X 10.4" CLIM-DEMO> (software-version) "Darwin Damien-Kicks-Computer.local 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/ RELEASE_PPC Power Macintosh powerpc" CLIM-DEMO> And here is the stack trace Connection failure to X11.0 server display 0: No protocol specified [Condition of type XLIB:CONNECTION-FAILURE] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT] Abort entirely from this (lisp) process. Backtrace: 0: (SWANK::DEBUG-IN-EMACS #) 1: (SWANK:SWANK-DEBUGGER-HOOK # #) 2: (ERROR XLIB:CONNECTION-FAILURE :MAJOR-VERSION 11 :MINOR-VERSION 0 :HOST "" :DISPLAY 0 ...) 3: (XLIB::X-ERROR XLIB:CONNECTION-FAILURE :MAJOR-VERSION 11 :MINOR- VERSION 0 :HOST "" :DISPLAY 0 ...) 4: (XLIB::DISPLAY-CONNECT # :AUTHORIZATION- NAME NIL :AUTHORIZATION-DATA NIL) 5: (XLIB:OPEN-DISPLAY "" :DISPLAY 0 :PROTOCOL :LOCAL) 6: ((METHOD CLIM-CLX::INITIALIZE-CLX (CLIM-CLX::CLX-PORT)) #) 7: ((METHOD INITIALIZE-INSTANCE :AFTER (CLIM-CLX::CLX-PORT)) #1=# . #1#) 8: ((:INTERNAL (:EFFECTIVE-METHOD 1 T NIL NIL NIL) 0) #1=# . #1#) 9: ((METHOD MAKE-INSTANCE (CLASS)) # :SERVER-PATH (:CLX :HOST "" :DISPLAY-ID 0 :SCREEN-ID 0 :PROTOCOL :LOCAL)) 10: ((METHOD MAKE-INSTANCE (SYMBOL)) CLIM-CLX::CLX-PORT :SERVER-PATH (:CLX :HOST "" :DISPLAY-ID 0 :SCREEN-ID 0 :PROTOCOL :LOCAL)) 11: (FIND-PORT) 12: (FIND-FRAME-MANAGER) 13: ((METHOD RUN-FRAME-TOP-LEVEL :AROUND (APPLICATION-FRAME)) #) 14: ((:INTERNAL (:EFFECTIVE-METHOD 1 T NIL T T) 0) # . #) 15: (EVAL (RUN-FRAME-TOP-LEVEL (MAKE-APPLICATION-FRAME (QUOTE ADDRESS- BOOK)))) 16: (SWANK::EVAL-REGION "(run-frame-top-level (make-application-frame 'address-book)) " T) 17: ((:INTERNAL SWANK:LISTENER-EVAL 0)) 18: ((METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) #) 19: (SWANK::CALL-WITH-BUFFER-SYNTAX #) 20: (SWANK:LISTENER-EVAL "(run-frame-top-level (make-application- frame 'address-book)) ") 21: (EVAL (SWANK:LISTENER-EVAL "(run-frame-top-level (make- application-frame 'address-book)) ")) 22: ((:INTERNAL SWANK::EVAL-FOR-EMACS 0)) 23: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # #) 24: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(run-frame-top-level (make-application-frame 'address-book)) ") "CLIM-DEMO" 77) 25: (FUNCALL SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(run-frame- top-level (make-application-frame 'address-book)) ") "CLIM-DEMO" 77) 26: (SWANK::READ-FROM-EMACS) 27: ((:INTERNAL SWANK::HANDLE-REQUEST 0)) 28: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # #) 29: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 30: (SWANK::CALL-WITH-REDIRECTED-IO # #) 31: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION # #) 32: (SWANK::CALL-WITH-CONNECTION # #) 33: (SWANK::HANDLE-REQUEST #) 34: ((:INTERNAL SWANK::REPL-LOOP 0)) 35: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # #) 36: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 37: (SWANK::CALL-WITH-REDIRECTED-IO # #) 38: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION # #) 39: (SWANK::CALL-WITH-CONNECTION # #) 40: (SWANK::REPL-LOOP #) 41: ((:INTERNAL (:INTERNAL SWANK::SPAWN-REPL-THREAD 0) 0)) 42: (SWANK::CALL-WITH-BINDINGS NIL #) 43: ((:INTERNAL SWANK::SPAWN-REPL-THREAD 0)) For what it's worth, I get the same error message when attempting to run the demo without SLIME, i.e. just starting Allegro in an xterm. Any ideas as to what is going wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From csr21 at cantab.net Sun Nov 12 09:15:21 2006 From: csr21 at cantab.net (Christophe Rhodes) Date: Sun, 12 Nov 2006 09:15:21 +0000 Subject: [mcclim-devel] Problems with McClim demo In-Reply-To: (Damien Kick's message of "Sun, 12 Nov 2006 03:03:20 -0600") References: Message-ID: <878xihuity.fsf@cantab.net> Damien Kick writes: > For what it's worth, I get the same error message when attempting to > run the demo without SLIME, i.e. just starting Allegro in an xterm.? > Any ideas as to what is going wrong? Based on the fact that you're using Allegro on OS X, there are two simple things that could be wrong, that you should check before going much further: * you may have forgotten to start X11.app; * the CLX implementation provided by Franz may be incompatible with Apple's X11.app (e.g. IPv6 entries in ~/.Xauthority). Make sure that you can connect to your X server: if you can't do that, there's not a lot that any McCLIM code can do about it. Cheers, Christophe From metawilm at gmail.com Sun Nov 12 15:57:58 2006 From: metawilm at gmail.com (Willem Broekema) Date: Sun, 12 Nov 2006 16:57:58 +0100 Subject: [mcclim-devel] Problems with McClim demo In-Reply-To: <878xihuity.fsf@cantab.net> References: <878xihuity.fsf@cantab.net> Message-ID: On 11/12/06, Christophe Rhodes wrote > Make sure that you can connect to your X server: if you can't do that, > there's not a lot that any McCLIM code can do about it. FWIW, I'm on Mac OS X (Intel), and today's CVS code works for me (ACL 8.0). I got rid of the "no protocol specified" error by doing "xhost +". Damien, if after xhost it still does not work: can you start an X app like xcalc in an Emacs shell? (At least that's what I use to determine if the problem is on the X or Lisp side...) - Willem From mikemac at mikemac.com Sun Nov 12 17:37:56 2006 From: mikemac at mikemac.com (Mike McDonald) Date: Sun, 12 Nov 2006 10:37:56 -0700 Subject: [mcclim-devel] Problems with McClim demo In-Reply-To: Your message of "Sun, 12 Nov 2006 16:57:58 +0100." Message-ID: <200611121737.kACHbuu01370@saturn.mikemac.com> >To: mcclim-devel at common-lisp.net >Date: Sun, 12 Nov 2006 16:57:58 +0100 >From: "Willem Broekema" > >On 11/12/06, Christophe Rhodes wrote >> Make sure that you can connect to your X server: if you can't do that, >> there's not a lot that any McCLIM code can do about it. > >FWIW, I'm on Mac OS X (Intel), and today's CVS code works for me (ACL 8.0). >I got rid of the "no protocol specified" error by doing "xhost +". > >Damien, if after xhost it still does not work: can you start an X app >like xcalc in an Emacs shell? (At least that's what I use to determine >if the problem is on the X or Lisp side...) One of the more recent updates to the Intenl version of OSX turns off TCP connections to the X server. You may need to use the command "defaults" to turn it back on. Then use the 'xhost +' command every time you start X and want to run McCLIM. Mike McDonald mikemac at mikemac.com From dkixk at earthlink.net Sun Nov 12 22:05:21 2006 From: dkixk at earthlink.net (Damien Kick) Date: Sun, 12 Nov 2006 16:05:21 -0600 Subject: [mcclim-devel] Problems with McClim demo In-Reply-To: <200611121737.kACHbuu01370@saturn.mikemac.com> References: <200611121737.kACHbuu01370@saturn.mikemac.com> Message-ID: <50DF7B31-E43B-4470-B702-D7594FCBD402@earthlink.net> On Nov 12, 2006, at 11:37, Mike McDonald wrote: > >> To: mcclim-devel at common-lisp.net >> Date: Sun, 12 Nov 2006 16:57:58 +0100 >> From: "Willem Broekema" >> >> FWIW, I'm on Mac OS X (Intel), and today's CVS code works for me >> (ACL 8.0). >> I got rid of the "no protocol specified" error by doing "xhost +". >> >> Damien, if after xhost it still does not work: can you start an X app >> like xcalc in an Emacs shell? (At least that's what I use to >> determine >> if the problem is on the X or Lisp side...) > > One of the more recent updates to the Intenl version of OSX turns > off TCP connections to the X server. You may need to use the command > "defaults" to turn it back on. Then use the 'xhost +' command every > time you start X and want to run McCLIM. I'm running Mac OS on PPC. The 'xhost +' solved the problem with open-display. On to the next problem . Now I can start the address-book demo but when I type 'help' into the frame with 'Command', I do not see 'help' echoed back to me and, as soon as I hit RET, I get the condition and stack trace below, which I also see if I don't run from SLIME but from an xterm. attempt to call `#:STREAM59292' which is an undefined function. [Condition of type UNDEFINED-FUNCTION] Restarts: 0: [TRY-AGAIN] Try calling #:STREAM59292 again. 1: [RETURN-VALUE] Return a value instead of calling #:STREAM59292. 2: [USE-VALUE] Try calling a function other than #:STREAM59292. 3: [STORE-VALUE] Setf the symbol-function of #:STREAM59292 and call it again. 4: [ABORT] Return to application command loop 5: [ABORT-REQUEST] Abort handling SLIME request. 6: [ABORT] Abort entirely from this (lisp) process. Backtrace: 0: (SWANK::DEBUG-IN-EMACS #) 1: (SWANK:SWANK-DEBUGGER-HOOK # #) 2: (ERROR #) 3: (#:STREAM59292) 4: (CLIM-INTERNALS::COM-HELP%PARTIAL%19 # # (CLIM-INTERNALS::COM-HELP #:UNSUPPLIED-ARGUMENT-MARKER486)) 5: (COMMAND-LINE-READ-REMAINING-ARGUMENTS-FOR-PARTIAL-COMMAND # # (CLIM- INTERNALS::COM-HELP #:UNSUPPLIED-ARGUMENT-MARKER486) 1) 6: ((METHOD CLIM-INTERNALS::%ACCEPT (CLIM-INTERNALS::| (presentation-type CLIM::COMMAND)| T T TEXTUAL-VIEW)) # (COMMAND :COMMAND-TABLE #) # #) 7: ((:INTERNAL (:EFFECTIVE-METHOD 4 T T NIL NIL) 0) # (COMMAND :COMMAND-TABLE #) # # :DEFAULT (CLIM- INTERNALS::COM-NULL-COMMAND) :DEFAULT-TYPE CLIM-INTERNALS::NULL-COMMAND) 8: ((FLET (:INTERNAL ACCEPT-1 0) #:INPUT-CONT34099)) 9: (CLIM-INTERNALS::INVOKE-HANDLE-EMPTY-INPUT # # #) 10: ((:INTERNAL ACCEPT-1 0) #) 11: ((METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING (CLIM-STREAM- PANE T T T T)) # # # "" CLIM-INTERNALS::GOATEE-INPUT-EDITING-STREAM) 12: ((METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING :AROUND (T T T T T)) # # # "" CLIM-INTERNALS::GOATEE-INPUT-EDITING-STREAM) 13: ((METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING :AROUND (EXTENDED-OUTPUT-STREAM T T T T)) # # # "" CLIM-INTERNALS::GOATEE-INPUT- EDITING-STREAM) 14: ((:INTERNAL (:EFFECTIVE-METHOD 5 NIL NIL T T) 0) # # # "" CLIM- INTERNALS::GOATEE-INPUT-EDITING-STREAM) 15: (ACCEPT-1 # (COMMAND :COMMAND-TABLE #) :DEFAULT (CLIM-INTERNALS::COM-NULL-COMMAND) :DEFAULT- TYPE CLIM-INTERNALS::NULL-COMMAND :PROMPT NIL) 16: ((METHOD STREAM-ACCEPT (STANDARD-EXTENDED-INPUT-STREAM T)) # (COMMAND :COMMAND-TABLE #)) 17: ((FLET ACCEPT CLIM-INTERNALS::DO-ACCEPT) (:DEFAULT-TYPE CLIM- INTERNALS::NULL-COMMAND :PROMPT NIL :DEFAULT (CLIM-INTERNALS::COM- NULL-COMMAND) :DEFAULT-TYPE CLIM-INTERNALS::NULL-COMMAND)) 18: (ACCEPT (COMMAND :COMMAND-TABLE #) :STREAM # :PROMPT NIL :DEFAULT (CLIM-INTERNALS::COM-NULL- COMMAND) :DEFAULT-TYPE CLIM-INTERNALS::NULL-COMMAND) 19: (READ-COMMAND # :STREAM #) 20: (READ-COMMAND-USING-KEYSTROKES # NIL :STREAM #) 21: (READ-COMMAND # :STREAM # :USE- KEYSTROKES T) 22: ((METHOD READ-FRAME-COMMAND (APPLICATION-FRAME)) # :STREAM #) 23: ((METHOD READ-FRAME-COMMAND :AROUND (APPLICATION-FRAME)) # :STREAM #) 24: ((:INTERNAL (:EFFECTIVE-METHOD 1 T T T T) 0) # :STREAM #) 25: ((METHOD DEFAULT-FRAME-TOP-LEVEL (APPLICATION-FRAME)) #) 26: ((:INTERNAL (:EFFECTIVE-METHOD 1 T T NIL NIL) 0) #) 27: ((:INTERNAL (ACLMOP:CLASS-DEFAULT-INITARGS ADDRESS-BOOK :TOP- LEVEL-LAMBDA) 0) #) 28: ((METHOD RUN-FRAME-TOP-LEVEL (APPLICATION-FRAME)) #) 29: ((METHOD RUN-FRAME-TOP-LEVEL :AROUND (APPLICATION-FRAME)) #) 30: ((:INTERNAL (:EFFECTIVE-METHOD 1 T NIL T T) 0) # . #) 31: (EVAL (RUN-FRAME-TOP-LEVEL (MAKE-APPLICATION-FRAME (QUOTE ADDRESS- BOOK)))) 32: (SWANK::EVAL-REGION "(run-frame-top-level (make-application-frame 'address-book)) " T) 33: ((:INTERNAL SWANK:LISTENER-EVAL 0)) 34: ((METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) #) 35: (SWANK::CALL-WITH-BUFFER-SYNTAX #) 36: (SWANK:LISTENER-EVAL "(run-frame-top-level (make-application- frame 'address-book)) ") 37: (EVAL (SWANK:LISTENER-EVAL "(run-frame-top-level (make- application-frame 'address-book)) ")) 38: ((:INTERNAL SWANK::EVAL-FOR-EMACS 0)) 39: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # #) 40: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(run-frame-top-level (make-application-frame 'address-book)) ") "CLIM-DEMO" 34) 41: (FUNCALL SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(run-frame- top-level (make-application-frame 'address-book)) ") "CLIM-DEMO" 34) 42: (SWANK::READ-FROM-EMACS) 43: ((:INTERNAL SWANK::HANDLE-REQUEST 0)) 44: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # #) 45: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 46: (SWANK::CALL-WITH-REDIRECTED-IO # #) 47: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION # #) 48: (SWANK::CALL-WITH-CONNECTION # #) 49: (SWANK::HANDLE-REQUEST #) 50: ((:INTERNAL SWANK::REPL-LOOP 0)) 51: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # #) 52: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 53: (SWANK::CALL-WITH-REDIRECTED-IO # #) 54: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION # #) 55: (SWANK::CALL-WITH-CONNECTION # #) 56: (SWANK::REPL-LOOP #) 57: ((:INTERNAL (:INTERNAL SWANK::SPAWN-REPL-THREAD 0) 0)) 58: (SWANK::CALL-WITH-BINDINGS NIL #) 59: ((:INTERNAL SWANK::SPAWN-REPL-THREAD 0)) From athas at sigkill.dk Sun Nov 12 22:27:02 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Sun, 12 Nov 2006 23:27:02 +0100 Subject: [mcclim-devel] Problems with McClim demo In-Reply-To: <50DF7B31-E43B-4470-B702-D7594FCBD402@earthlink.net> (Damien Kick's message of "Sun, 12 Nov 2006 16:05:21 -0600") References: <200611121737.kACHbuu01370@saturn.mikemac.com> <50DF7B31-E43B-4470-B702-D7594FCBD402@earthlink.net> Message-ID: <871wo8b8sp.fsf@sigkill.dk> Damien Kick writes: > I'm running Mac OS on PPC. The 'xhost +' solved the problem with > open-display. On to the next problem . Now I can start the > address-book demo but when I type 'help' into the frame with > Command', I do not see 'help' echoed back to me and, as soon as I hit > RET, I get the condition and stack trace below, which I also see if I > don't run from SLIME but from an xterm. I guess this could happen if the "Help" command, which is defined in builtin-commands.lisp, is loaded before `accepting-values' has been defined as a macro. I have changed mcclim.asd to ensure dialog.lisp, which defines `accepting-values', is loaded before builtin-commands.lisp. Does this fix the issue for you? -- \ Troels "Athas" /\ Henriksen From dkixk at earthlink.net Tue Nov 14 02:27:57 2006 From: dkixk at earthlink.net (Damien Kick) Date: Mon, 13 Nov 2006 20:27:57 -0600 Subject: [mcclim-devel] Problems with McClim demo In-Reply-To: <871wo8b8sp.fsf@sigkill.dk> References: <200611121737.kACHbuu01370@saturn.mikemac.com> <50DF7B31-E43B-4470-B702-D7594FCBD402@earthlink.net> <871wo8b8sp.fsf@sigkill.dk> Message-ID: <23B4AC4F-2249-4041-972D-C033A8FF3598@earthlink.net> On Nov 12, 2006, at 16:27, Troels Henriksen wrote: > I guess this could happen if the "Help" command, which is defined in > builtin-commands.lisp, is loaded before `accepting-values' has been > defined as a macro. I have changed mcclim.asd to ensure dialog.lisp, > which defines `accepting-values', is loaded before > builtin-commands.lisp. Does this fix the issue for you? I picked up your change with a "cvs update" and that seems to have fixed the problem with the help command causing a crash. However, I'm still having a problem with what I've typed, i.e. "help", not being echoed. I've put up a screenshot with an address-book right after having typed "help" beside a window running David Trudgett's fractal program . I know that it isn't a comprehensive test of CLX but it does show that the CLX bundled with my Allegro is working for something. From athas at sigkill.dk Tue Nov 14 07:50:45 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 14 Nov 2006 08:50:45 +0100 Subject: [mcclim-devel] Problems with McClim demo In-Reply-To: <23B4AC4F-2249-4041-972D-C033A8FF3598@earthlink.net> (Damien Kick's message of "Mon, 13 Nov 2006 20:27:57 -0600") References: <200611121737.kACHbuu01370@saturn.mikemac.com> <50DF7B31-E43B-4470-B702-D7594FCBD402@earthlink.net> <871wo8b8sp.fsf@sigkill.dk> <23B4AC4F-2249-4041-972D-C033A8FF3598@earthlink.net> Message-ID: <87irhio4a2.fsf@sigkill.dk> Damien Kick writes: > I picked up your change with a "cvs update" and that seems to have > fixed the problem with the help command causing a crash. However, > I'm still having a problem with what I've typed, i.e. "help", not > being echoed. Hmm. Could you try doing a 'cvs update' and using the Drei editor substrate instead of Goatee (just do (setf climi::*use-goatee* nil) before starting the application)? That might give us an idea of where to look. -- \ Troels "Athas" /\ Henriksen From dkixk at earthlink.net Tue Nov 14 10:39:33 2006 From: dkixk at earthlink.net (Damien Kick) Date: Tue, 14 Nov 2006 04:39:33 -0600 Subject: [mcclim-devel] Problems with McClim demo In-Reply-To: <87irhio4a2.fsf@sigkill.dk> References: <200611121737.kACHbuu01370@saturn.mikemac.com> <50DF7B31-E43B-4470-B702-D7594FCBD402@earthlink.net> <871wo8b8sp.fsf@sigkill.dk> <23B4AC4F-2249-4041-972D-C033A8FF3598@earthlink.net> <87irhio4a2.fsf@sigkill.dk> Message-ID: <740FE7DF-7AF7-413A-BE15-5CA690F95D4A@earthlink.net> On Nov 14, 2006, at 1:50, Troels Henriksen wrote: > Hmm. Could you try doing a 'cvs update' and using the Drei editor > substrate instead of Goatee (just do (setf climi::*use-goatee* nil) > before starting the application)? That might give us an idea of where > to look. Still no luck with regards to the echo: . From noreply at common-lisp.net Fri Nov 17 09:04:14 2006 From: noreply at common-lisp.net (Automatic Email Delivery Software) Date: Fri, 17 Nov 2006 18:04:14 +0900 Subject: [mcclim-devel] (no subject) Message-ID: <20061117090337.0709424053@common-lisp.net> The original message was received at Fri, 17 Nov 2006 18:04:14 +0900 from common-lisp.net [139.202.14.112] ----- The following addresses had permanent fatal errors ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: message.zip Type: application/octet-stream Size: 29112 bytes Desc: not available URL: From jdunrue at gmail.com Mon Nov 20 18:47:32 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Mon, 20 Nov 2006 11:47:32 -0700 Subject: [mcclim-devel] small tweak for gtkairo on win32 Message-ID: Backends/gtkairo/ffi.lisp has a defcfun entry for XGetErrorText which as far as I can tell is not exported by any of the Win32 GTK DLLs (that makes sense, although one could imagine it being defined for interoperability reasons). The dribble-x-errors function in Backends/gtkairo/event.lisp uses a conditional to avoid calling XGetErrorText on Win32. I've changed my local copy of ffi.lisp to avoid the defcfun with the same conditional; perhaps the same fix could be checked in? Thanks. -- Jack Unrue From smustudent1 at yahoo.com Mon Nov 20 20:01:20 2006 From: smustudent1 at yahoo.com (C Y) Date: Mon, 20 Nov 2006 12:01:20 -0800 (PST) Subject: [mcclim-devel] small tweak for gtkairo on win32 In-Reply-To: Message-ID: <20061120200120.21266.qmail@web56714.mail.re3.yahoo.com> --- Jack Unrue wrote: > Backends/gtkairo/ffi.lisp has a defcfun entry for XGetErrorText which > as far as I can tell is not exported by any of the Win32 GTK DLLs > (that makes sense, although one could imagine it being defined for > interoperability reasons). The dribble-x-errors function in > Backends/gtkairo/event.lisp uses a conditional to avoid calling > XGetErrorText on Win32. I've changed my local copy of ffi.lisp to > avoid the defcfun with the same conditional; perhaps the same fix > could be checked in? I'm curious - how close is McCLIM to working natively on Windows without needing an X server? Cheers, CY ____________________________________________________________________________________ Sponsored Link Mortgage rates near 39yr lows. $420k for $1,399/mo. Calculate new payment! www.LowerMyBills.com/lre From jdunrue at gmail.com Mon Nov 20 20:37:06 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Mon, 20 Nov 2006 13:37:06 -0700 Subject: [mcclim-devel] small tweak for gtkairo on win32 In-Reply-To: <20061120200120.21266.qmail@web56714.mail.re3.yahoo.com> References: <20061120200120.21266.qmail@web56714.mail.re3.yahoo.com> Message-ID: On 11/20/06, C Y wrote: > > I'm curious - how close is McCLIM to working natively on Windows > without needing an X server? Not close yet, but I'm working on it. My intention is to get it far enough along that at least some of the examples work, then see what else folks would like to have done in order for the code to be imported into CVS -- at that point, it would be fair game for anyone to hack on. -- Jack Unrue From jdunrue at gmail.com Mon Nov 20 20:38:33 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Mon, 20 Nov 2006 13:38:33 -0700 Subject: [mcclim-devel] small tweak for gtkairo on win32 In-Reply-To: References: <20061120200120.21266.qmail@web56714.mail.re3.yahoo.com> Message-ID: On 11/20/06, Jack Unrue wrote: > On 11/20/06, C Y wrote: > > > > I'm curious - how close is McCLIM to working natively on Windows > > without needing an X server? > > Not close yet, but I'm working on it. My intention is to get it far enough along > that at least some of the examples work, then see what else folks would like > to have done in order for the code to be imported into CVS -- at that point, > it would be fair game for anyone to hack on. That's assuming you aren't happy with gtkairo (which doesn't need an X server, either). -- Jack Unrue From jdunrue at gmail.com Mon Nov 20 23:47:22 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Mon, 20 Nov 2006 16:47:22 -0700 Subject: [mcclim-devel] Drei dependency problem on clisp Message-ID: I found a small issue with the :depends-on form for :drei-mcclim when trying to load the latest mcclim on clisp 2.41. Drei uses #. in :depends-on to try to define a dependency on swank if it's loaded. Unfortunately on clisp, this results in nil rather than no value. I'm seeing this error: component NIL not found, required by #1=# [Condition of type ASDF:MISSING-DEPENDENCY] There was discussion on c.l.l. about the behavior of the reader macro function in this regard, see the thread started by Pascal Bourguignon: http://groups.google.com/group/comp.lang.lisp/msg/6d137dca962cfaf4?hl=en& Note that I'm not actually trying to run drei on clisp, just trying to load mcclim.asd. -- Jack Unrue From athas at sigkill.dk Tue Nov 21 11:56:08 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 21 Nov 2006 12:56:08 +0100 Subject: [mcclim-devel] Drei dependency problem on clisp In-Reply-To: (Jack Unrue's message of "Mon, 20 Nov 2006 16:47:22 -0700") References: Message-ID: <87vel9ypwn.fsf@sigkill.dk> "Jack Unrue" writes: > I found a small issue with the :depends-on form for :drei-mcclim > when trying to load the latest mcclim on clisp 2.41. Drei uses #. in > :depends-on to try to define a dependency on swank if it's > loaded. Unfortunately on clisp, this results in nil rather than no > value. I'm seeing this error: Argh, I guess I need to change that to pushing a mcclim.system::use-swank symbol onto *FEATURES*, which is what I was trying to avoid in the first place. Or perhaps the (values) can replaced with something that will be loaded anyway, such as :flexichain? The best solution is, of course, to get Swank (it should work on CLISP). :-) > There was discussion on c.l.l. about the behavior of the reader macro function > in this regard, see the thread started by Pascal Bourguignon: > > http://groups.google.com/group/comp.lang.lisp/msg/6d137dca962cfaf4?hl=en& I think that my interpretation of how #.(values) should be treated is the most useful one, but I acknowledge that it's undefined by the spec, and we thus shouldn't use it. -- \ Troels "Athas" /\ Henriksen From csr21 at cantab.net Tue Nov 21 10:14:43 2006 From: csr21 at cantab.net (Christophe Rhodes) Date: Tue, 21 Nov 2006 10:14:43 +0000 Subject: [mcclim-devel] presenting expressions, nested presentations Message-ID: <87irh92jjg.fsf@cantab.net> Hi, Wouldn't it be cool if, when we presented list data as an expression, the contents were individually presented? Well, consider the code at the end of this mail; it achieves this, but at a price: we no longer respect *print-level*, *print-length* and friends; we don't honour *pprint-dispatch-table* (which might have EQL "methods" on these objects); and there appears not to be a way of finding out what the user would prefer to be the :single-box attribute of the nested presentations. The *print-level*/*print-length* and friends could be worked on with a little bit more code; the *pprint-dispatch-table* issue, however, is rather more fundamental; if it can be handled at all, it would need to be handled on an implementation-level basis (there's no GET-PPRINT-DISPATCH exposed to the user, only SET-PPRINT-DISPATCH). I presume that the :single-box issue we can deal with ourselves by inventing a special variable. Really, what I would like to know is what the requirements for this presentation method are. What do I have to do to honour the ACCEPTABLY keyword? Is managing *print-level* and *print-length* enough (well, presumably there's more work to be done to support *print-array* and so on)? Should we do this for user-defined structures as well, where we can determine that there is no applicable *pprint-dispatch-table* or PRINT-OBJECT method (fortunately, there can be no user PRINT-OBJECT method on conses or vectors). I suppose the inevitable question is: what did the Lisp Machines do...? Answers welcome! Cheers, Christophe (define-presentation-method present (object (type expression) stream (view textual-view) &key acceptably for-context-type) (declare (ignore for-context-type)) (let ((*print-readably* acceptably)) (typecase object (cons (with-output-as-presentation (stream object type :single-box t) (princ #\( stream) (do ((o object (cdr o))) ((null o)) (present (car o) (presentation-type-of (car o)) :stream stream :view view) (cond ((null (cdr o)) (return)) ((listp (cdr o)) (princ #\Space stream)) (t (princ " . " stream) (present (cdr o) (presentation-type-of (cdr o)) :stream stream :view view) (return)))) (princ #\) stream))) (simple-vector (with-output-as-presentation (stream object type :single-box t) (princ "#(" stream) (do ((i 0 (1+ i))) ((>= i (length object))) (present (svref object i) (presentation-type-of (svref object i)) :stream stream :view view) (when (>= i (1- (length object))) (return)) (princ " " stream)) (princ #\) stream))) (t (prin1 object stream))))) From athas at sigkill.dk Tue Nov 21 21:58:53 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 21 Nov 2006 22:58:53 +0100 Subject: [mcclim-devel] presenting expressions, nested presentations In-Reply-To: <87irh92jjg.fsf@cantab.net> (Christophe Rhodes's message of "Tue, 21 Nov 2006 10:14:43 +0000") References: <87irh92jjg.fsf@cantab.net> Message-ID: <87ejrwwjfm.fsf@sigkill.dk> Christophe Rhodes writes: > Wouldn't it be cool if, when we presented list data as an expression, > the contents were individually presented? Yes! > we no longer respect *print-level*, *print-length* and friends; we > don't honour *pprint-dispatch-table* (which might have EQL "methods" > on these objects); Hmm. This is probably not a good idea in a Listener, as it's supposed to be an enhanced REPL - its Lisp behavior should preferable be indentical to the standard TTY REPL. > and there appears not to be a way of finding out what the user would > prefer to be the :single-box attribute of the nested presentations. Your method draws the box around the innermost presentation (or from the beginning parenthesis to the ending parenthesis). Surely this is the resonable choice? Or do I misunderstand? > What do I have to do to honour the ACCEPTABLY keyword? If ACCEPTABLY is true, you just have to make sure whatever you print is valid (textually) input to the corresponding accept method. It has nothing to do with what can be understood by READ (though it's probably a very good idea to also make it readable). > Is managing *print-level* and *print-length* enough (well, > presumably there's more work to be done to support *print-array* and > so on)? I would consider it more important than pretty-printing, at least, because being able to prevent CLIM from drawing too large expressions at the Listener is probably necessary with the current McCLIM drawing performance, while pretty-printing is more of an aesthetic issue. However, should *print-level* and *print-length* also be respected when some arbitrary application presents expressions? That might be a bit nonintuitive. > suppose the inevitable question is: what did the Lisp Machines > do...? We better find McCLIM a corporate sponsor so we can get one and check it out. :-) -- \ Troels "Athas" /\ Henriksen From jdunrue at gmail.com Tue Nov 21 22:38:08 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Tue, 21 Nov 2006 15:38:08 -0700 Subject: [mcclim-devel] more clisp/win32 issues Message-ID: Here are a few more issues I've encountered trying to load McCLIM on CLISP / Win32. There are two places in the .asd file where the :file component :name value is given as a two-part path expression. CLISP complains: MAKE-PATHNAME: illegal :NAME argument "Goatee/presentation-history" [Condition of type SIMPLE-ERROR] and MAKE-PATHNAME: illegal :NAME argument "Looks/pixie" [Condition of type SIMPLE-ERROR] Goatee/goatee-command.lisp fails to compile specifically on CLISP / Win32 because #\Delete is not defined (but it is for CLISP on Unix). The same character value can be obtained with #\Rubout. More info here: http://www.podval.org/~sds/clisp/impnotes/char-platform-dep.html I suppose the next problem is better reported on the flexichain mailing list, but while I've got your attention...flexichain/utilities.lisp has an EVAL-WHEN form that uses :evaluate which is not supported on CLISP: ;; Compiling file C:\projects\third_party\asdf-repo\flexichain\utilities.lisp ... ERROR in lines 66..93 : EVAL-WHEN situation must be :LOAD-TOPLEVEL, :COMPILE-TOPLEVEL or :EXECUTE, but not :EVALUATE The reason why I'm bothering you all with these issues, rather than just using SBCL, is that the combination of SBCL, Slime, and Graphic-Forms is not working due to an as yet unresolved issue with window creation. If you're subscribed to either slime-devel or sbcl-devel then you've seen the problem report. Interestingly, I see the same problem with gtkairo. But CLISP works great for me, so I thought it would be worth some time looking into this stuff. -- Jack Unrue From athas at sigkill.dk Tue Nov 21 22:52:48 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 21 Nov 2006 23:52:48 +0100 Subject: [mcclim-devel] more clisp/win32 issues In-Reply-To: (Jack Unrue's message of "Tue, 21 Nov 2006 15:38:08 -0700") References: Message-ID: <87ac2kwgxr.fsf@sigkill.dk> "Jack Unrue" writes: > MAKE-PATHNAME: illegal :NAME argument "Goatee/presentation-history" > [Condition of type SIMPLE-ERROR] > > and > > MAKE-PATHNAME: illegal :NAME argument "Looks/pixie" > [Condition of type SIMPLE-ERROR] I thought these bugs had been fixed in the most recent ASDF? Perhaps CLISP is shipping an older version? > Goatee/goatee-command.lisp fails to compile specifically on CLISP / > Win32 because > #\Delete is not defined (but it is for CLISP on Unix). The same character value > can be obtained with #\Rubout. More info here: > > http://www.podval.org/~sds/clisp/impnotes/char-platform-dep.html Would adding something like "#+win32 #\Rubout #-win32 #\Delete" work? I'm not very familiar with Windows-Lisps. > I suppose the next problem is better reported on the flexichain mailing list, > but while I've got your attention...flexichain/utilities.lisp has an > EVAL-WHEN form that uses :evaluate which is not supported on CLISP: This bug existed for quite a while, but it has actually been fixed in Flexichain CVS. I think Flexichain should make a "proper" release soon - after all, it's stable and does what it's supposed to do. McCLIM should not rely on unreleased components. > The reason why I'm bothering you all with these issues, rather than > just using SBCL... McCLIM is supposed to be portable, so reporting these issues here is alright. And it's not like mcclim-devel is overcrowded with activity anyway. -- \ Troels "Athas" /\ Henriksen From athas at sigkill.dk Tue Nov 21 23:02:48 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 22 Nov 2006 00:02:48 +0100 Subject: [mcclim-devel] more clisp/win32 issues In-Reply-To: <87ac2kwgxr.fsf@sigkill.dk> (Troels Henriksen's message of "Tue, 21 Nov 2006 23:52:48 +0100") References: <87ac2kwgxr.fsf@sigkill.dk> Message-ID: <8764d8wgh3.fsf@sigkill.dk> Troels Henriksen writes: >> Goatee/goatee-command.lisp fails to compile specifically on CLISP / >> Win32 because >> #\Delete is not defined (but it is for CLISP on Unix). The same character value >> can be obtained with #\Rubout. More info here: >> >> http://www.podval.org/~sds/clisp/impnotes/char-platform-dep.html > > Would adding something like "#+win32 #\Rubout #-win32 #\Delete" work? > I'm not very familiar with Windows-Lisps. Andy Hefner seems to have fixed this now. Thanks! -- \ Troels "Athas" /\ Henriksen From jdunrue at gmail.com Tue Nov 21 23:21:47 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Tue, 21 Nov 2006 16:21:47 -0700 Subject: [mcclim-devel] more clisp/win32 issues In-Reply-To: <87ac2kwgxr.fsf@sigkill.dk> References: <87ac2kwgxr.fsf@sigkill.dk> Message-ID: On 11/21/06, Troels Henriksen wrote: > > I thought these bugs had been fixed in the most recent ASDF? Perhaps > CLISP is shipping an older version? Ah! I was woefully out-of-date, still using revision 1.86. CLISP does not bundle ASDF. > > I suppose the next problem is better reported on the flexichain mailing list, > > but while I've got your attention...flexichain/utilities.lisp has an > > EVAL-WHEN form that uses :evaluate which is not supported on CLISP: > > This bug existed for quite a while, but it has actually been fixed in > Flexichain CVS. I think Flexichain should make a "proper" release soon > - after all, it's stable and does what it's supposed to do. McCLIM > should not rely on unreleased components. Thanks, I'll grab the latest and give that a try. -- Jack Unrue From rpgoldman at real-time.com Tue Nov 21 23:37:58 2006 From: rpgoldman at real-time.com (Robert P. Goldman) Date: Tue, 21 Nov 2006 17:37:58 -0600 Subject: [mcclim-devel] presenting expressions, nested presentations In-Reply-To: <87irh92jjg.fsf@cantab.net> References: <87irh92jjg.fsf@cantab.net> Message-ID: <200611211737.59003.rpgoldman@real-time.com> On Tuesday 21 November 2006 04:14 am, Christophe Rhodes wrote: > Hi, > > Wouldn't it be cool if, when we presented list data as an expression, > the contents were individually presented? Another place this would be nice is in CLIM's DESCRIBE, since it's disappointing to have a tree presented through CLIM's describe, and then be unable to mouse around on its contents... From jdunrue at gmail.com Tue Nov 21 23:26:37 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Tue, 21 Nov 2006 16:26:37 -0700 Subject: [mcclim-devel] more clisp/win32 issues In-Reply-To: <8764d8wgh3.fsf@sigkill.dk> References: <87ac2kwgxr.fsf@sigkill.dk> <8764d8wgh3.fsf@sigkill.dk> Message-ID: On 11/21/06, Troels Henriksen wrote: > Troels Henriksen writes: > > >> Goatee/goatee-command.lisp fails to compile specifically on CLISP / > >> Win32 because > >> #\Delete is not defined (but it is for CLISP on Unix). The same character value > >> can be obtained with #\Rubout. More info here: > >> > >> http://www.podval.org/~sds/clisp/impnotes/char-platform-dep.html > > > > Would adding something like "#+win32 #\Rubout #-win32 #\Delete" work? > > I'm not very familiar with Windows-Lisps. > > Andy Hefner seems to have fixed this now. Thanks! Almost :-) Index: goatee-command.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Goatee/goatee-command.lisp,v retrieving revision 1.23 diff -r1.23 goatee-command.lisp 336c336 < (add-gesture-command-to-table '(#\delete :meta) --- > (add-gesture-command-to-table '(#\rubout :meta) 339c339 < (add-gesture-command-to-table '(#\delete :control) --- > (add-gesture-command-to-table '(#\rubout :control) -- Jack Unrue From ahefner at gmail.com Tue Nov 21 23:59:27 2006 From: ahefner at gmail.com (Andy Hefner) Date: Tue, 21 Nov 2006 18:59:27 -0500 Subject: [mcclim-devel] more clisp/win32 issues In-Reply-To: References: <87ac2kwgxr.fsf@sigkill.dk> <8764d8wgh3.fsf@sigkill.dk> Message-ID: <31ffd3c40611211559q157236e0tbbdfb747591a532d@mail.gmail.com> Oops! On 11/21/06, Jack Unrue wrote: > On 11/21/06, Troels Henriksen wrote: > > Andy Hefner seems to have fixed this now. Thanks! > > Almost :-) > > Index: goatee-command.lisp > =================================================================== > RCS file: /project/mcclim/cvsroot/mcclim/Goatee/goatee-command.lisp,v > retrieving revision 1.23 > diff -r1.23 goatee-command.lisp > 336c336 > < (add-gesture-command-to-table '(#\delete :meta) > --- > > (add-gesture-command-to-table '(#\rubout :meta) > 339c339 > < (add-gesture-command-to-table '(#\delete :control) > --- > > (add-gesture-command-to-table '(#\rubout :control) > > -- > Jack Unrue > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From ahefner at gmail.com Tue Nov 21 23:50:49 2006 From: ahefner at gmail.com (Andy Hefner) Date: Tue, 21 Nov 2006 18:50:49 -0500 Subject: [mcclim-devel] presenting expressions, nested presentations In-Reply-To: <200611211737.59003.rpgoldman@real-time.com> References: <87irh92jjg.fsf@cantab.net> <200611211737.59003.rpgoldman@real-time.com> Message-ID: <31ffd3c40611211550q5dd5bfdfg781e4e16f778c7f4@mail.gmail.com> Alternately, I've been thinking it would be useful to integrate the inspector into the listener, so that you can immediately start clicking your way through returned values. I hadn't considered the interaction with the select gesture (lacking working subform accepting until recently, it wasn't much of an issue). I think this is a cool idea, but requires some decisions be made as to what UI gestures are used. Does anyone else think this is a cool idea? On 11/21/06, Robert P. Goldman wrote: > On Tuesday 21 November 2006 04:14 am, Christophe Rhodes wrote: > > Hi, > > > > Wouldn't it be cool if, when we presented list data as an expression, > > the contents were individually presented? From athas at sigkill.dk Wed Nov 22 01:07:07 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 22 Nov 2006 02:07:07 +0100 Subject: [mcclim-devel] presenting expressions, nested presentations In-Reply-To: <31ffd3c40611211550q5dd5bfdfg781e4e16f778c7f4@mail.gmail.com> (Andy Hefner's message of "Tue, 21 Nov 2006 18:50:49 -0500") References: <87irh92jjg.fsf@cantab.net> <200611211737.59003.rpgoldman@real-time.com> <31ffd3c40611211550q5dd5bfdfg781e4e16f778c7f4@mail.gmail.com> Message-ID: <871wnwwapw.fsf@sigkill.dk> "Andy Hefner" writes: > Alternately, I've been thinking it would be useful to integrate the > inspector into the listener, so that you can immediately start > clicking your way through returned values. By expanding parts of the accept result in-place, as if there was a Clouseau embedded in the pane? That would be useful; in fact, that's half of my Clouseau use cases. Also, it would make for great screenshots! > I hadn't considered the interaction with the select gesture (lacking > working subform accepting until recently, it wasn't much of an > issue). I think this is a cool idea, but requires some decisions be > made as to what UI gestures are used. Why not just use a composite gesture such as M-button1, or perhaps the middle mouse button? Or maybe we could consider inspection a form of a description, and use the :describe gesture. I think I prefer M-button1. > Does anyone else think this is a cool idea? Yes, it's a really great idea! The Listener is an important tool, so it should have as many of these neat features as possible. -- \ Troels "Athas" /\ Henriksen From ahefner at gmail.com Wed Nov 22 01:22:44 2006 From: ahefner at gmail.com (Andy Hefner) Date: Tue, 21 Nov 2006 20:22:44 -0500 Subject: [mcclim-devel] presenting expressions, nested presentations In-Reply-To: <871wnwwapw.fsf@sigkill.dk> References: <87irh92jjg.fsf@cantab.net> <200611211737.59003.rpgoldman@real-time.com> <31ffd3c40611211550q5dd5bfdfg781e4e16f778c7f4@mail.gmail.com> <871wnwwapw.fsf@sigkill.dk> Message-ID: <31ffd3c40611211722l2eae300dla194a225e54c240c@mail.gmail.com> I was imagining just using this on return values and other compatibly presented objects. I suppose the idea applies to accept-results too, but I'm having trouble imagining the purpose (where did the accept-result come from, if not somewhere else in the window where you could inspect in a less confusing fashion?). If you've got some wild ideas for ways to apply Drei, I'd like to hear them. On 11/21/06, Troels Henriksen wrote: > "Andy Hefner" writes: > > > Alternately, I've been thinking it would be useful to integrate the > > inspector into the listener, so that you can immediately start > > clicking your way through returned values. > > By expanding parts of the accept result in-place, as if there was a > Clouseau embedded in the pane? That would be useful; in fact, that's > half of my Clouseau use cases. Also, it would make for great > screenshots! From athas at sigkill.dk Wed Nov 22 01:38:35 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 22 Nov 2006 02:38:35 +0100 Subject: [mcclim-devel] presenting expressions, nested presentations In-Reply-To: <31ffd3c40611211722l2eae300dla194a225e54c240c@mail.gmail.com> (Andy Hefner's message of "Tue, 21 Nov 2006 20:22:44 -0500") References: <87irh92jjg.fsf@cantab.net> <200611211737.59003.rpgoldman@real-time.com> <31ffd3c40611211550q5dd5bfdfg781e4e16f778c7f4@mail.gmail.com> <871wnwwapw.fsf@sigkill.dk> <31ffd3c40611211722l2eae300dla194a225e54c240c@mail.gmail.com> Message-ID: <87wt5ouup0.fsf@sigkill.dk> "Andy Hefner" writes: > I was imagining just using this on return values and other compatibly > presented objects. I suppose the idea applies to accept-results too, Sorry, I guess I hadn't properly swapped out what I was working on before I replied. I meant "return values", not "accept results". > If you've got some wild ideas for ways to apply Drei, I'd like to > hear them. In-buffer inspections of literal buffer objects is a hack that begs to be written, but I'm quite sure this is not in any way useful. Apart from the obvious possibility of inserting objects from the inspector tree into the new input line, I'm not sure how an editor could be (or should be) meaningfully integrated with an inspector. -- \ Troels "Athas" /\ Henriksen From ahefner at gmail.com Wed Nov 22 07:01:03 2006 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 22 Nov 2006 02:01:03 -0500 Subject: Fwd: Re: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: References: <87u08t7j33.fsf@plato.moon.paoloamoroso.it> <878xq536mm.fsf@plato.moon.paoloamoroso.it> Message-ID: <31ffd3c40611212301i5b6a1a88td3ecdd4abb28196e@mail.gmail.com> On 4/16/06, Christophe Rhodes wrote: > Hm. On the one hand, the use of MAP-OVER-OUTPUT-RECORDS is going to > lead to O(N^2) behaviour in %TREE-RECOMPUTE-EXTENT* if one output > record at a time is added to the graph output record. On the other > hand, I think the code for %TREE-RECOMPUTE-EXTENT is completely > unnecessary for TREE-OUTPUT-RECORDs (though not for > SEQUENCE-OUTPUT-RECORDs). On the gripping hand, I no longer really > have much of an idea what's going on at all. You might want to > examine the code that draws the graph, maybe trying to insert a graph > output record instead of a sequence one if that's possible. I've finally gotten around to tearing into this issue, adding code to recompute-extent-for-changed-child to handle this particular degenerate behavior. It is considerably faster for me now, although I it still spends a bit more time drawing the arrows than it ought to. I battled similar issues several years ago looking at the text output speed in the interactor pane. Most of the time here was spent drawing the graph arcs. The trouble here was that edge-output-records are created and added to the output history before the edges have been drawn in them. Information about the attached nodes is added, and some time later the arc-drawer is invoked, with the result added to the (previously empty) edge record. As this begins, I had thousands of output records as the immediate children of the graph output record. For each of these, addition of the output from the arc-drawer forces one or more recompute-extent-for-new-child against the edge, which in turn invokes recompute-extent-for-changed-child against the graph. The existing optimizations in this function were insufficient, forcing the worst case of computing a new bounding rectangle from those of each of the thousands of children. I saw 12,000,000 passes through the inner loop of %tree-recompute-extent* for one rendering of the graph. I've added code to recompute-extent-for-changed-child which handles the case of a previously empty child gaining contents. This differs subtly from the existing case of a child's bounding rectangle growing, because an empty compound-output-record gets a default bounding rectangle of 0,0,0,0 until it gains children, which is obviously bogus, making it look as though the midified child had moved/shrank (these being genuinely painful cases where we do need to examine every child to compute a new bounding rectangle). If this information can fall directly out of the tree, that is great, because the underlying problem with moving/deleting/resizing large numbers of records still persists to bite the unsuspecting CLIM hacker. Lazily computing the bounding rectangles would mostly solve the problem, provided it doesn't violate the spec somehow. From rpgoldman at real-time.com Wed Nov 22 16:20:25 2006 From: rpgoldman at real-time.com (Robert P. Goldman) Date: Wed, 22 Nov 2006 10:20:25 -0600 Subject: [mcclim-devel] presenting expressions, nested presentations In-Reply-To: <31ffd3c40611211550q5dd5bfdfg781e4e16f778c7f4@mail.gmail.com> References: <87irh92jjg.fsf@cantab.net> <200611211737.59003.rpgoldman@real-time.com> <31ffd3c40611211550q5dd5bfdfg781e4e16f778c7f4@mail.gmail.com> Message-ID: <200611221020.25801.rpgoldman@real-time.com> On Tuesday 21 November 2006 05:50 pm, Andy Hefner wrote: > Alternately, I've been thinking it would be useful to integrate the > inspector into the listener, so that you can immediately start > clicking your way through returned values. I hadn't considered the > interaction with the select gesture (lacking working subform accepting > until recently, it wasn't much of an issue). I think this is a cool > idea, but requires some decisions be made as to what UI gestures are > used. > > Does anyone else think this is a cool idea? I do, but note that this is not quite what I was hoping for --- I was hoping for this to be available in the built-in McCLIM describe, which is available to all McCLIM applications, not just the Listener. I like to make an application and have describe available for help with debugging. Perhaps I should just figure out how to make Clouseau available... > > On 11/21/06, Robert P. Goldman wrote: > > On Tuesday 21 November 2006 04:14 am, Christophe Rhodes wrote: > > > Hi, > > > > > > Wouldn't it be cool if, when we presented list data as an expression, > > > the contents were individually presented? > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From thomas at spacecentre.se Thu Nov 23 00:57:58 2006 From: thomas at spacecentre.se (Thomas Persson) Date: Thu, 23 Nov 2006 01:57:58 +0100 Subject: [mcclim-devel] Drei text-field issues Message-ID: <87d57fdlnt.fsf@opinion.spacecentre.se> Hi I noticed two problems with Drei text-fields: * No checking whether a gesture is an activation gesture. * Value-changed-callback doesn't work. From what I can tell, value-gadget should do this for us but it's handled manually in Goatee. The attached patch should fix both problems. / Thomas Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: drei-clim.patch Type: text/x-patch Size: 1455 bytes Desc: not available URL: From athas at sigkill.dk Thu Nov 23 15:50:26 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Thu, 23 Nov 2006 16:50:26 +0100 Subject: [mcclim-devel] Drei text-field issues In-Reply-To: <87d57fdlnt.fsf@opinion.spacecentre.se> (Thomas Persson's message of "Thu, 23 Nov 2006 01:57:58 +0100") References: <87d57fdlnt.fsf@opinion.spacecentre.se> Message-ID: <8764d6mabh.fsf@sigkill.dk> Thomas Persson writes: > The attached patch should fix both problems. Thanks for the patch! I committed a modified version that puts the activation gesture handling in text-editor-gadget.lisp, because I don't want that behavior for standard :drei gadgets. -- \ Troels "Athas" /\ Henriksen From mraspaud at labri.fr Fri Nov 24 15:51:33 2006 From: mraspaud at labri.fr (Martin Raspaud) Date: Fri, 24 Nov 2006 16:51:33 +0100 Subject: [mcclim-devel] Using common-lisp-controller with the Listener Message-ID: <45671505.4030003@labri.fr> Hi all, here is a small patch in order to fix the listener when used with the common-lisp-controller. The patch was suggested by Athas. Martin (aka zorgzorg2) --- mcclim/Apps/Listener/package.lisp 2005-09-29 18:42:36.000000000 +0200 +++ mcclim/Apps/Listener/package.lisp 2006-11-24 14:32:16.000000000 +0100 @@ -9,4 +9,4 @@ (eval-when (:load-toplevel) ; (format t "~&~%!@#%^!@#!@ ... ~A~%~%" *load-truename*) - (defparameter *icon-path* (merge-pathnames #P"icons/" *load-truename*))) + (defparameter *icon-path* (merge-pathnames #P"icons/" (load-time-value (or #.*compile-file-pathname* *load-pathname*))))) -------------- next part -------------- A non-text attachment was scrubbed... Name: mraspaud.vcf Type: text/x-vcard Size: 154 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From thomas at spacecentre.se Wed Nov 29 11:00:02 2006 From: thomas at spacecentre.se (Thomas Persson) Date: Wed, 29 Nov 2006 12:00:02 +0100 Subject: [mcclim-devel] broken Message-ID: <87u00i7c25.fsf@opinion.spacecentre.se> Hi I noticed that the commands and menus in the listener are broken. I don't exactly understand the listener code but trial and error narrowed it down to what ahefner committed on November 21. Reversing some of those changes seems to fix it. -------------- next part -------------- A non-text attachment was scrubbed... Name: listener.patch Type: text/x-patch Size: 3714 bytes Desc: not available URL: From rudi at constantly.at Wed Nov 29 11:13:01 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Wed, 29 Nov 2006 12:13:01 +0100 Subject: [mcclim-devel] broken In-Reply-To: <87u00i7c25.fsf@opinion.spacecentre.se> References: <87u00i7c25.fsf@opinion.spacecentre.se> Message-ID: <99A8E3D2-0D5C-4FFA-BBC3-C8D8F9AC42BB@constantly.at> On 29.11.2006, at 12:00, Thomas Persson wrote: > I noticed that the commands and menus in the listener are broken. I > don't exactly understand the listener code but trial and error > narrowed it down to what ahefner committed on November 21. Reversing > some of those changes seems to fix it. Commands entered at the prompt need to be prefixed by a colon now, i.e. instead of typing show directory type :show directory Menu items are indeed broken, in that selecting a command via the pull-down menu causes an instance of type MENU-ITEM to be presented in the listener instead of a command to be executed. Cheers, Rudi