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

Re: [mcclim-devel] IN-PACKAGE not defined in CLIM package
by Troels Henriksen 03 Jan '08

03 Jan '08

Andreas Davour <ante(a)Update.UU.SE> writes: > I just tried cvs mcclim with sbcl-1.0.10 and while mcclim loads fine > clim-examples does not. CLIM::IN-PACKAGE is undefined, which I guess > is a mistake of some sort. I don't understand why this happens, and it certainly doesn't happen here. You could probably fix it by replacing in-package with cl:in-package. -- \ Troels /\ Henriksen

1 0

[mcclim-devel] The new Drei redisplay engine
by Troels Henriksen 03 Jan '08

03 Jan '08

Pretty much since the beginning, Climacs redisplay has been quite slow, and this trait was unfortunately ported over when Drei was created. Over the last few days I've been committing my work on a new redisplay engine, one that is much faster and more powerful than the old one. The old redisplay engine was never much of an actual engine, every syntax had to implement its own redisplay code from the bottom up, and these syntaxes just walked across their parse tree, calling CLIM drawing functions and using incremental output for performance. Sometimes, they would call a function (the infamous `handle-whitespace') to move the cursor as demanded by newlines or space characters, and at various points ugly kludges were added to this function to try to record at least a little of the display structure, such as where lines started and ended on the screen. But in general, everything was pretty much a jungle, and it wasn't all that fast, partially because McCLIM implementation of incremental-redisplay is admittedly not optimal, and partially because I severely doubt CLIM incremental-redisplay is even meant to be used for the kind of real-time performance needed in an editor. The new redisplay engine was developed based on a key assumption: output records are nice, flexible and useful, but they are too slow and heavy. Hence, the new redisplay engine does not use output records, except for handling cursors and some other exotic cases. Instead, it divides the visible region of the buffer into "strokes". A stroke is a buffer region that can be drawn in a single operation with a single set of drawing options, and that does not cross lines. Put another way, a stroke is a sequence of characters in a line with the same colour and font (strokes can also cover non-characters, but let's ignore that for now). The new redisplay algorithm thus works by fetching strokes from the buffer, starting at the top of the display, and drawing them to the screen until we reach either the end of the buffer or the bottom of the visible part of the output sheet. When strokes are drawn, we remember the location and size of their output. Due to the constraint that strokes cannot cross lines, we can trivially organise strokes into lines and just check for whether a stroke directly precedes a #\Newline character to figure out when we should go to the next line, and when we do this, look at the strokes of the line and figure out the dimension of the line. Stroke objects are kept across display, and are mutated by the stroke pump (see below), so we can easily check whether a stroke has changed (we mark it as "dirty" and "modified") since the last redisplay, simply by having the pump check whether it is going store already-existing data in the stroke object. If a stroke is obscured for some reason (for example due to a moving window, or part of the cursor being drawn over it), we also mark it as dirty. Taken together, this gives us incremental redisplay. The interesting problem is now how to generate strokes for the redisplay engine. This is done through two generic functions, `pump-state-for-offset' and `stroke-pump', that are used to "pump" stroke data into an already existing stroke object. This is both to implement incremental redisplay, as mentioned above, and to avoid consing (if you read the code, you'll notice that I've been obsessed with minimising consing in general, perhaps this was not always necessary). For the most common case, these functions just relay to the syntax of the view, which results in either the simple stroke pumping defined in fundamental-syntax.lisp, or the terrifying horrors of lr-syntax.lisp. There is nothing special about stroke pumping, except that it has to be really fast as it is done in full for every redisplay. All the clever caching and "only handle that which has actually changed"-stuff is done at the higher level by looking at the dirtiness of strokes, and at the lower level by the incremental syntax parsers. The stroke pump just has to be fast (and fortunately, it is for the most part). When the view is a pure buffer-view (that is, has no syntax) there is a simple pump defined in drei-redisplay.lisp that just turns each line into a stroke (possibly chopping it up if it's very long), it's not fast, but it's simple, and you can look at it to get a general idea of how it works. The major performance issue right now is that a stroke is only considered unmodified when neither its drawing-options (colours, etc) nor its start/end-offsets have been modified. This is suboptimal, because the offsets of subsequent strokes will change when you insert or remove something from a buffer, so every time you insert a character, the buffer from point till the end of the display will be redrawn, while it is most likely not strictly necessary for anything but the current line (unless you significantly modified the syntax parse tree by your change, of course). Anyway, the new engine is not horribly buggy, though it is obviously new and untested, and it's quite fast on my machine. Not Emacs-speed, but significantly faster than the old one, and significantly easier to optimise further. Oh yeah, and a final note: implemented and tested with McCLIM-Freetype, has bugs without Freetype, and has never been run on a non-CLX backend. -- \ Troels /\ Henriksen

1 0

[mcclim-devel] McCLIM 0.9.5 and sbcl 1.0.13
by David N Murray 03 Jan '08

03 Jan '08

Hi all, I'm having trouble installing McCLIM 0.9.5 using sbcl 1.0.13: * (asdf::oos 'asdf:load-op :mcclim) ; loading system definition from /home/dnm/.sbcl/systems/mcclim.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM :CLIM-LISP {B09B461}> as CLIM-LISP [snip registering stuff that already compiled cleanly] ; registering #<SYSTEM CLX {B152BD1}> as CLX debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" {A712661}>: The value :LOCKED is not of type (OR NULL SB-THREAD:THREAD). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {A8C9A89}> on #<ASDF:CL-SOURCE-FILE "mp-sbcl" {A8C9A99}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {A8C9A89}> on #<ASDF:CL-SOURCE-FILE "mp-sbcl" {A8C9A99}> as having been successful. 2: [ABORT ] Exit debugger, returning to top level. (SB-THREAD:GET-MUTEX #<unavailable argument> #<unavailable argument> #<unavailable argument>) 0] source code causing the error: mp-sbcl.lisp:63 (defvar *permanent-queue* (sb-thread:make-mutex :name "Lock for disabled threads")) (unless (sb-thread:mutex-value *permanent-queue*) (sb-thread:get-mutex *permanent-queue* :locked nil)) Current sbcl docs (1.0.12.36): http://www.sbcl.org/manual/Mutex-Support.html#index-sb_002dthread_003aget_0… -- Function: sb-thread:get-mutex mutex &optional new-owner waitp Acquire mutex for new-owner, which must be a thread or nil. If new-owner is nil, it defaults to the current thread. If waitp is non-NIL and the mutex is in use, sleep until it is available. and the sbcl source: target-thread.lisp:231: (defun get-mutex (mutex &optional (new-owner *current-thread*) (waitp t)) Am I missing something? I don't see a :LOCKED parameter there. I'm not sure how to fix it, since I don't know what the :LOCKED parameter was supposed to do. I checked the 1.0.4 sources and this function hasn't changed it's signature. If I just blow through that (0 in the debugger), the next one I see is: ; READ failure in COMPILE-FILE: ; SB-INT:SIMPLE-READER-PACKAGE-ERROR at 14454 (line 380, column 62) on #<SB-SYS:FD-STREAM for "file /home/dnm/.sbcl/site/mcclim-0.9.5/builtin-commands.lisp" {B4AEA89}>: ; Symbol "READER-PACKAGE-ERROR" not found in the SB-KERNEL package. ; compilation aborted after 0:00:01 and the line that causes the error in builtin-commands.lisp is trying to call SB-KERNEL:READER-PACKAGE-ERROR. I can't even find any docs on the SB-KERNEL package. I did, however, find a define-condition for simpler-reader-package-error in conditions.lisp that looks close. I did find a define-condition for reader-package-error in sbcl 1.0.4 (I don't have any other versions of sbcl source handy). I tried to change the builtin-commands.lisp source to try reader-error, simple-reader-package-error, and simple-reader-error but sbcl complains that all of them are not external to the sb-kernel package. Thoughts? TIA, Dave

1 1

[mcclim-devel] Re: [mcclim-cvs] CVS mcclim/Apps/Listener
by Andy Hefner 01 Jan '08

01 Jan '08

On Dec 31, 2007 6:34 PM, ahefner <ahefner(a)common-lisp.net> wrote: > - (flet ((run () (run-frame-top-level frame))) > + (flet ((run () > + (unwind-protect (run-frame-top-level frame) > + (disown-frame fm frame)))) > (if new-process > (values (clim-sys:make-process #'run :name process-name) > frame) In case this bug has propagated into the run-<program> functions of any other apps, it is necessary to call disown-frame yourself if you pass a frame manager to make-application-frame. Since I've also fixed the buffering problem with disable-frame, you won't notice that you failed to, but the unmapped window will linger instead of being destroyed.

1 0

[mcclim-devel] gadget-value
by Thomas Persson 23 Dec '07

23 Dec '07

Hi Here is a fix for making gadget-value work for text-fields again.

2 1

[mcclim-devel] beagle-by-default
by Greg Pfeil 18 Dec '07

18 Dec '07

This is a patch that sets up beagle to be loaded as the default backend on OpenMCL. I'm not recommending that it get added to the repo, becuase beagle is definitely not stable yet. However, it's useful for anyone else trying to use beagle in the meantime. With this patch, (asdf:oos 'asdf:load-op :mcclim) should load beagle by default on OpenMCL.

2 1

[mcclim-devel] patch for beagle
by Greg Pfeil 17 Dec '07

17 Dec '07

This is the first in hopefully a series of patches to get beagle working again. These changes take beagle from not loading, all the way to being able to perform a couple clicks before a lockFocus assertion fails.

2 2

[mcclim-devel] Cannot install mcclim
by Deepankar Sharma 12 Dec '07

12 Dec '07

I recently tried installing mcclim and it seems that the site that hosts spatial-trees is down currently. Anyone has a workaround ? Regards, Deepankar

2 1

[mcclim-devel] another beagle patch
by Greg Pfeil 12 Dec '07

12 Dec '07

This one fixes an issue tickled by Climacs. END is sometimes explicitly passed as NIL, which breaks (>= start end). Changed this to match the way CLX handles it.

1 0

[mcclim-devel] can't load latest mcclim (with latest sbcl)
by petdog 29 Nov '07

29 Nov '07

I think line 66 of mcclim/Lisp-Dep/mp-sbcl.lisp should be changed from (sb-thread:get-mutex *permanent-queue* :locked nil)) to (sb-thread:get-mutex *permanent-queue* nil)). Or, at least, that's how I got it to load. Thanks to all for the great work.

3 2