mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[mcclim-devel] presenting expressions, nested presentations
by Christophe Rhodes 22 Nov '06

22 Nov '06

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)))))

4 7

Re: Fwd: Re: [mcclim-devel] Severe performance regression with latest CVS sources?
by Christophe Rhodes 22 Nov '06

22 Nov '06

Paolo Amoroso <amoroso(a)mclink.it> writes: >> twice that many hash tables with (make-hash-table)? The other thing > > CL-USER> (time (dotimes (i (* 2 824)) > (make-hash-table))) > ; Compiling LAMBDA NIL: > ; Compiling Top-Level Form: > > ; Evaluation took: > ; 6,648 CPU cycles It's elided the creation, I'm afraid. Can you do (defvar *foo*) (time (dotimes (i (* 2 824)) (setq *foo* (make-hash-table)))) ? > ; > NIL > CL-USER> > > >> to look at is for collisions in your hash tables; check the EDGES-FROM >> slot of something with a lot of direct subclasses, say STRUCTURE-CLASS >> or CONDITION or NUMBER, and see if all of the entries are in the same >> bucket of the hash table) > > I'm not sure I understand what you mean. I used the SLIME inspector > to inspect the output of, say, (find-class 'structure-class). I > include the output below, which does not seem to have any EDGES-FROM > slot. I think the edges-from should be in the graph node output record. I'm not entirely sure how to get at one of those, but you could start by inspecting clim:*application-frame* from the slime inspector, finding the listener interactor pane, finding its output history, and looking at the output records in there. > 588,259,376 | 1,111 | 15.158 | 0.01364 | 529,486 | CLIM-INTERNALS::LAYOUT-EDGE-1 > 1,111: #<Code Object "LAMBDA (FWRAPPER)" {5A58260F}> > 1,470,608 | 2,222 | 0.056 | 0.00003 | 662 | CLIM-INTERNALS::ENSURE-EDGE-RECORD > 1,111: #<Code Object "DEFUN LAYOUT-EDGE" {59718A4F}> > 1,111: #<Code Object "DEFUN LAYOUT-EDGE-1" {5A75B007}> Well, that's moderately conclusive: the cost seems to be in LAYOUT-EDGE-1, not in ENSURE-EDGE-RECORD. Which is weird, because I can't really see what LAYOUT-EDGE-1 is doing that is so ludicrously expensive. Can you do the same thing, but with the CLIM package profiled additionally? (And then maybe one with CLIM but not CLIM-INTERNALS profiled?) The first 10 or so entries in each profile will probably suffice. (Maybe CLEAR-OUTPUT-RECORD is expensive?) Cheers, Christophe

3 3

[mcclim-devel] more clisp/win32 issues
by Jack Unrue 21 Nov '06

21 Nov '06

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

3 5

[mcclim-devel] Drei dependency problem on clisp
by Jack Unrue 21 Nov '06

21 Nov '06

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=#<SYSTEM "drei-mcclim" #x19F581E9> [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

2 1

[mcclim-devel] small tweak for gtkairo on win32
by Jack Unrue 20 Nov '06

20 Nov '06

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

2 3

[mcclim-devel] (no subject)
by Automatic Email Delivery Software 17 Nov '06

17 Nov '06

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 ----- <mcclim-devel(a)common-lisp.net>

1 0

[mcclim-devel] Problems with McClim demo
by Damien Kick 14 Nov '06

14 Nov '06

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 #<XLIB:CONNECTION-FAILURE @ #x11accd5a>) 1: (SWANK:SWANK-DEBUGGER-HOOK #<XLIB:CONNECTION-FAILURE @ #x11accd5a> #<Function 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 #<XLIB:DISPLAY :0 ( R0)> :AUTHORIZATION- NAME NIL :AUTHORIZATION-DATA NIL) 5: (XLIB:OPEN-DISPLAY "" :DISPLAY 0 :PROTOCOL :LOCAL) 6: ((METHOD CLIM-CLX::INITIALIZE-CLX (CLIM-CLX::CLX-PORT)) #<CLIM- CLX::CLX-PORT @ #x11ac3b6a>) 7: ((METHOD INITIALIZE-INSTANCE :AFTER (CLIM-CLX::CLX-PORT)) #1=#<CLIM-CLX::CLX-PORT @ #x11ac3b6a> . #1#) 8: ((:INTERNAL (:EFFECTIVE-METHOD 1 T NIL NIL NIL) 0) #1=#<CLIM- CLX::CLX-PORT @ #x11ac3b6a> . #1#) 9: ((METHOD MAKE-INSTANCE (CLASS)) #<STANDARD-CLASS CLIM-CLX::CLX- PORT> :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)) #<ADDRESS-BOOK @ #x11ac356a>) 14: ((:INTERNAL (:EFFECTIVE-METHOD 1 T NIL T T) 0) #<ADDRESS-BOOK @ #x11ac356a> . #<non-lisp object @ #x1>) 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)) #<Closure (:INTERNAL SWANK:LISTENER-EVAL 0) @ #x11ac344a>) 19: (SWANK::CALL-WITH-BUFFER-SYNTAX #<Closure (:INTERNAL SWANK:LISTENER-EVAL 0) @ #x11ac344a>) 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)) #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK::EVAL-FOR-EMACS 0) @ #x11ac342a>) 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)) #<Function SWANK-DEBUGGER-HOOK> #<Function (:INTERNAL SWANK::HANDLE-REQUEST 0)>) 29: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 30: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION @ #x107142ca> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x11ac27ca>) 31: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION #<SWANK::CONNECTION @ #x107142ca> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x11ac27ca>) 32: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION @ #x107142ca> #<Function (:INTERNAL SWANK::HANDLE-REQUEST 0)>) 33: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION @ #x107142ca>) 34: ((:INTERNAL SWANK::REPL-LOOP 0)) 35: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<Function SWANK-DEBUGGER-HOOK @ #x106bd8d2> #<Closure (:INTERNAL SWANK::REPL- LOOP 0) @ #x10715332>) 36: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 37: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION @ #x107142ca> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x10715352>) 38: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION #<SWANK::CONNECTION @ #x107142ca> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x10715352>) 39: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION @ #x107142ca> #<Closure (:INTERNAL SWANK::REPL-LOOP 0) @ #x10715332>) 40: (SWANK::REPL-LOOP #<SWANK::CONNECTION @ #x107142ca>) 41: ((:INTERNAL (:INTERNAL SWANK::SPAWN-REPL-THREAD 0) 0)) 42: (SWANK::CALL-WITH-BINDINGS NIL #<Closure (:INTERNAL (:INTERNAL SWANK::SPAWN-REPL-THREAD 0) 0) @ #x1071538a>) 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?

5 8

[mcclim-devel] stupid newbie question re: initializing text-field
by John Morrison 11 Nov '06

11 Nov '06

Sorry for what might be either a Stupid Newbie Question or Pilot Error: I am trying to implement a frame that allows "form-like" pop-editing of a CL data structure which include strings. How can I initialize the text fields and text editors? If I do what seems like the recommended thing according to the Harlequin CLIM manual -- a :before method on run-frame-top-level, it seems like maybe some goatee buffer pointer is not initialized until after the primary run-frame-top-level method gets called. (I made my own :around run-frame-top-level method, and the setf gadget-value, in fact, succeeds after the (call-next-method) has run -- but of course that's a little late for me.) The attached lisp program seems to exhibit the symptoms: the "test1" command works as expected and sets the value, but the :before method does not seem to. I only tried this under Linux (CentOS 4.4) on a relatively recent SBCL (0.9.14 RPM), using a relatively recent McCLIM (CVS updated approx Sept 15th). If anybody would please suggest further experiments, I would carry them out post-haste. Sorry if this is a stupid mechanical question: also, is there a stylistically better way to do this? Thanks, -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(a)mak.com

4 5

[mcclim-devel] Sheet size/redisplay issues
by Troels Henriksen 09 Nov '06

09 Nov '06

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

2 1

[mcclim-devel] Drei - a replacement for Goatee
by Troels Henriksen 08 Nov '06

08 Nov '06

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

1 1

← Newer
1
...
36
37
38
39
40
41
42
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel