mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[mcclim-devel] [patch] two defvars
by Nikodemus Siivola 20 Jan '08

20 Jan '08

Backends/CLX/port.lisp uses *FONTSET* and *CLX-PORT* before the corresponding defvars -- well, there is no defvar at all for the latter. The attached patch addresses this, eliminating the WARNINGs this may cause. Cheers, -- Nikodemus

1 0

[mcclim-devel] Re: [mcclim-cvs] CVS mcclim
by Andy Hefner 15 Jan '08

15 Jan '08

On Jan 15, 2008 10:45 AM, crhodes <crhodes(a)common-lisp.net> wrote: > Update of /project/mcclim/cvsroot/mcclim > In directory clnet:/tmp/cvs-serv8335 > > Modified Files: > regions.lisp > Log Message: > Frob standard-ellipse and standard-elliptical-arc superclasses > > (Otherwise, methods on clim:design are more specific than methods on > climi::elliptical-thing, which means that everything goes haywire.) Interesting. I guess this is what that comment from Gilbert, which I deleted, was about.

1 0

[mcclim-devel] status of mcclim
by Jan Brosius 13 Jan '08

13 Jan '08

Hi, I would like to use mcclim for making applications (exercises in Common Lisp) with sbcl. I looked around on the website. But some things are still not clear to me. So I have some questions about mcclim's status. Is mcclim built entirely on top of CLX? Is there a gtk backend for clx (other than motif)? Is mcclim in alpha stage? Thanks for any clarification Jan Brosius

6 7

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

11 Jan '08

Andreas Davour <ante(a)Update.UU.SE> writes: > Since it USE's COMMON-LISP and it's the package SBCL puts me in with > the REPL I kind of figured it was the most appropriate choice to use > in my own packages. I wonder if it used to work in some other > implementation. CL-USER is a package that USEs COMMON-LISP, not a package that exports the symbols of COMMON-LISP. I don't think CL demands that CL-USER doesn't export any symbols, so it's possible some implementations decide to make it export interesting things. > BTW, this would be a good thing to note in a tutorial or best > prectices for package management, if someone is about to write > one... Here's another good thing to know, in case you want to write CLIM applications: don't USE the COMMON-LISP package, USE the CLIM-LISP package instead. You still have to USE the CLIM package and anything else you're interested in. -- \ Troels /\ Henriksen

1 0

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

11 Jan '08

Andreas Davour <ante(a)Update.UU.SE> writes: > I have also noted when I create packaged that :USE "CL-USER" I seem to > loosem, while :USE "COMMON-LISP" works fine. I'm not sure I understand > why, and if that's how it always worked. Anyway, CLIM works fine > again. That's because CL-USER doesn't export many symbols, if any at all. -- \ Troels /\ Henriksen

1 0

[mcclim-devel] Image-reading in McCLIM
by Troels Henriksen 05 Jan '08

05 Jan '08

Currently, there is no obvious way to read images from a file and display them on a pane in McCLIM. If you know the secret rites, you can use CLIM-INTERNALS::XPM-PARSE-FILE, but: 1) It is limited to XPM files. 2) It is internal and looks scary. To rectify this, I think we should bundle some simple library with McCLIM for converting image files to CLIM patterns, just like CLIM-INTERNALS::XPM-PARSE-FILE does. (I see something called rgb-image.lisp in mcclim/Extensions, what is it used for?) It would not be loaded by default, but applications could depend on a MCCLIM-IMAGES ASDF system that would define a package, load some simple scaffolding code and export a symbol, LOAD-IMAGE, from its package. The MCCLIM-IMAGES system would not actually support any image formats, and thus not have any dependencies, and applications with specific needs could thus depend on systems like MCCLIM-IMAGES-XPM, MCCLIM-IMAGES-GIF, etc., all of which depend on MCCLIM-IMAGES and whatever libraries necessary to read the specific image file format. These format-support-systems would define a method on LOAD-IMAGE for the specific image format(s) handled by them. This way, an application that needs to read JPEG files would not have to drag in a library for reading, say, GIF files, and at the same time, the same well-defined function interface would be used for all image reading. Since image formats are different, and may have unique options for controlling exactly how they are loaded, the LOAD-IMAGE function would probably take an unspecified set of keywords, permitting each image format to define their own keywords semantics. Writing such a library would probably be extremely simple, if we are willing to use external libraries for most of the actual image reading. For example, here is how to turn the first image of a GIF file into a CLIM pattern using the Skippy library: (defun gif-to-pattern (pathname) (let* ((data-stream (skippy:load-data-stream pathname)) (first-image (aref (skippy:images data-stream) 0)) (pattern-array (make-array (list (skippy:height first-image) (skippy:width first-image)))) (designs (coerce (loop with color-table = (skippy:color-table data-stream) for i below 255 collecting (multiple-value-bind (r g b) (skippy:color-rgb (skippy:color-table-entry color-table i)) (make-rgb-color (/ r 255) (/ g 255) (/ b 255)))) 'vector))) (dotimes (y (skippy:height first-image)) (dotimes (x (skippy:width first-image)) (setf (aref pattern-array y x) (skippy:pixel-ref first-image x y)))) (make-pattern pattern-array designs))) -- \ Troels /\ Henriksen

3 4

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

04 Jan '08

Andreas Davour <ante(a)Update.UU.SE> writes: > I guess so, but it felt like it shouldn't be needed. Symbols should > have been exported and USE'ed I thought. Well, since you can't > reproduce it I think it might be some thing I have overlooked. But > what? Well, this problem isn't actually totally obscure. If *package* is bound to a package that does not contain CL:IN-PACKAGE when the file is read, the in-package form will not work. The odd thing is, of course, that CLIM really should contain that symbol. Is the problem reproducible? -- \ Troels /\ Henriksen

1 0

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

← Newer
1
...
24
25
26
27
28
29
30
...
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