From ahefner at gmail.com  Tue Jan  1 00:39:03 2008
From: ahefner at gmail.com (Andy Hefner)
Date: Mon, 31 Dec 2007 19:39:03 -0500
Subject: [mcclim-devel] Re: [mcclim-cvs] CVS mcclim/Apps/Listener
In-Reply-To: <20071231233453.5E4912826D@common-lisp.net>
References: <20071231233453.5E4912826D@common-lisp.net>
Message-ID: <31ffd3c40712311639j6101509amca4ff21152861517@mail.gmail.com>

On Dec 31, 2007 6:34 PM, ahefner <ahefner at 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.


From dmurray at jsbsystems.com  Thu Jan  3 03:28:05 2008
From: dmurray at jsbsystems.com (David N Murray)
Date: Wed, 02 Jan 2008 22:28:05 -0500 (EST)
Subject: [mcclim-devel] McCLIM 0.9.5 and sbcl 1.0.13
Message-ID: <Pine.LNX.4.55.0801022225170.20570@nazgul.jsbsystems.com>

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_002dmutex-430

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



From dmurray at jsbsystems.com  Thu Jan  3 04:22:21 2008
From: dmurray at jsbsystems.com (David N Murray)
Date: Wed, 02 Jan 2008 23:22:21 -0500 (EST)
Subject: [mcclim-devel] McCLIM 0.9.5 and sbcl 1.0.13
In-Reply-To: <Pine.LNX.4.55.0801022225170.20570@nazgul.jsbsystems.com>
References: <Pine.LNX.4.55.0801022225170.20570@nazgul.jsbsystems.com>
Message-ID: <Pine.LNX.4.55.0801022316390.20570@nazgul.jsbsystems.com>

(pardon the reply to my own post)

On Jan 2, David N Murray scribed:

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

I found a message in the November archives where this was fixed in the cvs
version and made the same change to my 0.9.5 source.  Maybe I should just
use the cvs version.  Sorry for not going back far enough when I first
looked for this.

[snip]

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

I replaced the line raising the error to call sb-kernel::reader-error
since reader-package-error was just a wrapper around reader-error and the
:: got me around the not-exported error.  Not pretty, but functional.

That got the build to finish.  These look like they may cause problems,
though:

; caught WARNING:
;   These variables are undefined:
;     CLIM-CLX::*CLX-PORT* CLIM-CLX::*FONTSET*
CLIM-INTERNALS::*SYS-%READ-LIST-EXPRESSION*
DREI-LISP-SYNTAX::+CL-GARBAGE-KEYWORDS+ DREI-LISP-SYNTAX::|initial-state |

I haven't investigated them yet, though.  I'll just wait for the runtime
error.

Thanks,
Dave



From athas at sigkill.dk  Thu Jan  3 13:29:50 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 03 Jan 2008 14:29:50 +0100
Subject: [mcclim-devel] The new Drei redisplay engine
Message-ID: <87d4sj9gvl.fsf@lambda.athas.dyndns.dk>


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


From athas at sigkill.dk  Thu Jan  3 14:11:48 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 03 Jan 2008 15:11:48 +0100
Subject: [mcclim-devel] IN-PACKAGE not defined in CLIM package
In-Reply-To: <Pine.LNX.4.64.0801030455050.24485@Psilocybe.Update.UU.SE>
	(Andreas Davour's message of "Thu, 3 Jan 2008 05:04:31 +0100 (CET)")
References: <Pine.LNX.4.64.0801030455050.24485@Psilocybe.Update.UU.SE>
Message-ID: <871w8z9exn.fsf@lambda.athas.dyndns.dk>

Andreas Davour <ante at 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


From athas at sigkill.dk  Fri Jan  4 07:38:35 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 04 Jan 2008 08:38:35 +0100
Subject: [mcclim-devel] IN-PACKAGE not defined in CLIM package
In-Reply-To: <Pine.LNX.4.64.0801040605470.24485@Psilocybe.Update.UU.SE>
	(Andreas Davour's message of "Fri, 4 Jan 2008 06:08:13 +0100 (CET)")
References: <Pine.LNX.4.64.0801030455050.24485@Psilocybe.Update.UU.SE>
	<871w8z9exn.fsf@lambda.athas.dyndns.dk>
	<Pine.LNX.4.64.0801040605470.24485@Psilocybe.Update.UU.SE>
Message-ID: <87tzlu82h0.fsf@lambda.athas.dyndns.dk>

Andreas Davour <ante at 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


From athas at sigkill.dk  Sat Jan  5 21:32:13 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 05 Jan 2008 22:32:13 +0100
Subject: [mcclim-devel] Image-reading in McCLIM
Message-ID: <877iio2c2q.fsf@lambda.athas.dyndns.dk>


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


From david at lichteblau.com  Sat Jan  5 22:17:35 2008
From: david at lichteblau.com (David Lichteblau)
Date: Sat, 5 Jan 2008 23:17:35 +0100
Subject: [mcclim-devel] Image-reading in McCLIM
In-Reply-To: <877iio2c2q.fsf@lambda.athas.dyndns.dk>
References: <877iio2c2q.fsf@lambda.athas.dyndns.dk>
Message-ID: <20080105221735.GB8921@radon>

Quoting Troels Henriksen (athas at sigkill.dk):
> To rectify this, I think we should bundle some simple library with

Good idea.

I wonder whether that library could be external to McCLIM, so that other
applications could also use it.  As long as it just returns arrays of
colors in the format CLIM wants, it would plug right into our image
drawing routines and still not have to depend on CLIM internals itself.

> McCLIM for converting image files to CLIM patterns, just like
> CLIM-INTERNALS::XPM-PARSE-FILE does.

The indexed pattern code would be used for images with a palette, like
GIF and XPM.

> (I see something called rgb-image.lisp in mcclim/Extensions, what is
> it used for?)

That's the second image format we would want to support, for 24 bit RGB
colors (plus alpha channel), originally from Closure.

RGB-IMAGE is the right class to return when parsing JPEG or one of the
formats that might or might not have a palette (PNG, BMP).

The format-specific image library could just return the (unsigned-byte
32) array as needed for RGB-IMAGE, with the latter being wrapped around
it by CLIM code.


d.


From athas at sigkill.dk  Sat Jan  5 22:41:27 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 05 Jan 2008 23:41:27 +0100
Subject: [mcclim-devel] Image-reading in McCLIM
In-Reply-To: <20080105221735.GB8921@radon> (David Lichteblau's message of
	"Sat, 5 Jan 2008 23:17:35 +0100")
References: <877iio2c2q.fsf@lambda.athas.dyndns.dk>
	<20080105221735.GB8921@radon>
Message-ID: <87wsqn28vc.fsf@lambda.athas.dyndns.dk>

David Lichteblau <david at lichteblau.com> writes:

> I wonder whether that library could be external to McCLIM, so that
> other applications could also use it.  As long as it just returns
> arrays of colors in the format CLIM wants, it would plug right into
> our image drawing routines and still not have to depend on CLIM
> internals itself.

I don't see much point in making it completely CLIM-independent, you
can't use the loaded images for anything but displaying them.

> The indexed pattern code would be used for images with a palette,
> like GIF and XPM.

>> (I see something called rgb-image.lisp in mcclim/Extensions, what is
>> it used for?)
>
> That's the second image format we would want to support, for 24 bit RGB
> colors (plus alpha channel), originally from Closure.

Ah, so we have two image-like things, CLIM patterns and RGB images? I
guess the LOAD-IMAGE function would then be specified as returning a
design object, with the actual implementation for each image type
deciding upon what is most convenient. Perhaps it could even be
checked dynamically - a JPEG image that is mostly monochrome might be
efficiently represented as an indexed image.

-- 
\  Troels
/\ Henriksen


From ch-mcclim at bobobeach.com  Sat Jan  5 22:42:23 2008
From: ch-mcclim at bobobeach.com (Cyrus Harmon)
Date: Sat, 5 Jan 2008 14:42:23 -0800
Subject: [mcclim-devel] Image-reading in McCLIM
In-Reply-To: <20080105221735.GB8921@radon>
References: <877iio2c2q.fsf@lambda.athas.dyndns.dk>
	<20080105221735.GB8921@radon>
Message-ID: <1B29BAC1-5FF6-476D-A7AA-3E05F7CE8BD8@bobobeach.com>

At a minimum, it would be nice if closure and other McCLIM apps could  
use the same libraries.

Cyrus

On Jan 5, 2008, at 2:17 PM, David Lichteblau wrote:

> Quoting Troels Henriksen (athas at sigkill.dk):
>> To rectify this, I think we should bundle some simple library with
>
> Good idea.
>
> I wonder whether that library could be external to McCLIM, so that  
> other
> applications could also use it.  As long as it just returns arrays of
> colors in the format CLIM wants, it would plug right into our image
> drawing routines and still not have to depend on CLIM internals  
> itself.
>
>> McCLIM for converting image files to CLIM patterns, just like
>> CLIM-INTERNALS::XPM-PARSE-FILE does.
>
> The indexed pattern code would be used for images with a palette, like
> GIF and XPM.
>
>> (I see something called rgb-image.lisp in mcclim/Extensions, what is
>> it used for?)
>
> That's the second image format we would want to support, for 24 bit  
> RGB
> colors (plus alpha channel), originally from Closure.
>
> RGB-IMAGE is the right class to return when parsing JPEG or one of the
> formats that might or might not have a palette (PNG, BMP).
>
> The format-specific image library could just return the (unsigned-byte
> 32) array as needed for RGB-IMAGE, with the latter being wrapped  
> around
> it by CLIM code.
>
>
> d.
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel



From athas at sigkill.dk  Sat Jan  5 22:56:18 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 05 Jan 2008 23:56:18 +0100
Subject: [mcclim-devel] Image-reading in McCLIM
In-Reply-To: <1B29BAC1-5FF6-476D-A7AA-3E05F7CE8BD8@bobobeach.com> (Cyrus
	Harmon's message of "Sat, 5 Jan 2008 14:42:23 -0800")
References: <877iio2c2q.fsf@lambda.athas.dyndns.dk>
	<20080105221735.GB8921@radon>
	<1B29BAC1-5FF6-476D-A7AA-3E05F7CE8BD8@bobobeach.com>
Message-ID: <87r6gv286l.fsf@lambda.athas.dyndns.dk>

Cyrus Harmon <ch-mcclim at bobobeach.com> writes:

> At a minimum, it would be nice if closure and other McCLIM apps could
> use the same libraries.

It would be exported McCLIM functionality, any McCLIM application
would be able to call LOAD-IMAGE.

-- 
\  Troels
/\ Henriksen


From athas at sigkill.dk  Fri Jan 11 18:09:19 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 11 Jan 2008 19:09:19 +0100
Subject: [mcclim-devel] IN-PACKAGE not defined in CLIM package
In-Reply-To: <Pine.LNX.4.64.0801111836070.26992@Psilocybe.Update.UU.SE>
	(Andreas Davour's message of "Fri, 11 Jan 2008 18:39:37 +0100 (CET)")
References: <Pine.LNX.4.64.0801030455050.24485@Psilocybe.Update.UU.SE>
	<871w8z9exn.fsf@lambda.athas.dyndns.dk>
	<Pine.LNX.4.64.0801040605470.24485@Psilocybe.Update.UU.SE>
	<87tzlu82h0.fsf@lambda.athas.dyndns.dk>
	<Pine.LNX.4.64.0801111836070.26992@Psilocybe.Update.UU.SE>
Message-ID: <87k5mgutdc.fsf@lambda.athas.dyndns.dk>

Andreas Davour <ante at 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


From athas at sigkill.dk  Fri Jan 11 18:21:49 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 11 Jan 2008 19:21:49 +0100
Subject: [mcclim-devel] IN-PACKAGE not defined in CLIM package
In-Reply-To: <Pine.LNX.4.64.0801111910190.26992@Psilocybe.Update.UU.SE>
	(Andreas Davour's message of "Fri, 11 Jan 2008 19:12:39 +0100 (CET)")
References: <Pine.LNX.4.64.0801030455050.24485@Psilocybe.Update.UU.SE>
	<871w8z9exn.fsf@lambda.athas.dyndns.dk>
	<Pine.LNX.4.64.0801040605470.24485@Psilocybe.Update.UU.SE>
	<87tzlu82h0.fsf@lambda.athas.dyndns.dk>
	<Pine.LNX.4.64.0801111836070.26992@Psilocybe.Update.UU.SE>
	<87k5mgutdc.fsf@lambda.athas.dyndns.dk>
	<Pine.LNX.4.64.0801111910190.26992@Psilocybe.Update.UU.SE>
Message-ID: <87ejcoussi.fsf@lambda.athas.dyndns.dk>

Andreas Davour <ante at 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


From jan.brosius at skynet.be  Sat Jan 12 23:18:18 2008
From: jan.brosius at skynet.be (Jan Brosius)
Date: Sun, 13 Jan 2008 00:18:18 +0100
Subject: [mcclim-devel] status of mcclim
Message-ID: <47894ABA.9030100@skynet.be>

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




From smustudent1 at yahoo.com  Sun Jan 13 04:47:15 2008
From: smustudent1 at yahoo.com (C Y)
Date: Sat, 12 Jan 2008 20:47:15 -0800 (PST)
Subject: [mcclim-devel] status of mcclim
In-Reply-To: <47894ABA.9030100@skynet.be>
Message-ID: <734371.58039.qm@web56707.mail.re3.yahoo.com>

--- Jan Brosius <jan.brosius at skynet.be> wrote:

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

The primary backend is CLX.

> Is there a gtk backend for clx (other than motif)?

Um.  I think there is come confusion here.  CLX IS a backend for McCLIM
(or it can be used directly if you want to work at that level.)  There
is a backend for McCLIM that uses (in part) GTK named gtkairo.

> Is mcclim in alpha stage?

Debatable.  Certainly applications use it (see Gsharp).  That one is
probably best answered by the devs.

CY


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping


From athas at sigkill.dk  Sun Jan 13 08:58:13 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Sun, 13 Jan 2008 09:58:13 +0100
Subject: [mcclim-devel] status of mcclim
In-Reply-To: <47894ABA.9030100@skynet.be> (Jan Brosius's message of "Sun, 13
	Jan 2008 00:18:18 +0100")
References: <47894ABA.9030100@skynet.be>
Message-ID: <87fxx29k62.fsf@lambda.athas.dyndns.dk>

Jan Brosius <jan.brosius at skynet.be> writes:

> Is mcclim built entirely on top of CLX?

No, McCLIM (and CLIM in general) is completely
device-independent. Currently, the default and best backend for McCLIM
is indeed based on CLX, but this is merely because that backend is the
oldest, and the one that has received the most work.

> Is there a gtk backend for clx (other than motif)?

"Gtk backend for CLX" does not make much sense (and McCLIM does not
have a Motif backend at all, though the commercial CLIMs do). There is
an experimental backend named "Gtkairo" that blends use of Gtk and
Cairo, but it is not yet as stable or full-featured as the CLX
backend. It may work for your programs, depending on what you want to
do. In general, the drawing primitives work very well with it, but the
more obscure CLIM facilities are less well supported.

> Is mcclim in alpha stage?

There is no defined stage. Strictly, it is not feature-complete as a
CLIM implementation (but pretty close), so it would not be appropriate
to call it a beta. On the other hand, while McCLIM is no rock pillar
of stability, it is certainly not as unstable as "alpha" might imply.


-- 
\  Troels
/\ Henriksen


From jan.brosius at skynet.be  Sun Jan 13 15:02:17 2008
From: jan.brosius at skynet.be (Jan Brosius)
Date: Sun, 13 Jan 2008 16:02:17 +0100
Subject: [mcclim-devel] status of mcclim
In-Reply-To: <87fxx29k62.fsf@lambda.athas.dyndns.dk>
References: <47894ABA.9030100@skynet.be>
	<87fxx29k62.fsf@lambda.athas.dyndns.dk>
Message-ID: <478A27F9.4040502@skynet.be>

Troels Henriksen wrote:
> "Gtk backend for CLX" does not make much sense (and McCLIM does not
> have a Motif backend at all, though the commercial CLIMs do). There is
> an experimental backend named "Gtkairo" that blends use of Gtk and
> Cairo, but it is not yet as stable or full-featured as the CLX
> backend. It may work for your programs, depending on what you want to
> do. In general, the drawing primitives work very well with it, but the
> more obscure CLIM facilities are less well supported.
>
>   
If there is a Gtkairo backend for mcclim than I would expect that mcclim 
uses an ffi e.g. cffi.
If so I would like to have some working knowledge of how it is done and 
what C library one uses.
I mean wxcl uses wxWidgets (written in C++), swig to "translate it to 
cffi and also cffi.
But I couldn't find a folder like cffi in the mcclim distribution.


From athas at sigkill.dk  Sun Jan 13 14:11:28 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Sun, 13 Jan 2008 15:11:28 +0100
Subject: [mcclim-devel] status of mcclim
In-Reply-To: <478A27F9.4040502@skynet.be> (Jan Brosius's message of "Sun, 13
	Jan 2008 16:02:17 +0100")
References: <47894ABA.9030100@skynet.be>
	<87fxx29k62.fsf@lambda.athas.dyndns.dk> <478A27F9.4040502@skynet.be>
Message-ID: <87zlv995nz.fsf@lambda.athas.dyndns.dk>

Jan Brosius <jan.brosius at skynet.be> writes:

> If there is a Gtkairo backend for mcclim than I would expect that
> mcclim uses an ffi e.g. cffi.
> If so I would like to have some working knowledge of how it is done
> and what C library one uses.

Yes, Gtkairo uses CFFI. Other backends can use whatever FFI they want
(the Beagle backend uses some OpenMCL-specific FFI as far as I
know). The Gtkairo backend uses various GTK and Cairo libraries, but I
admit that I do not fully know which ones.

> I mean wxcl uses wxWidgets (written in C++), swig to "translate it to
> cffi and also cffi.
> But I couldn't find a folder like cffi in the mcclim distribution.

No, that's because McCLIM as a whole does not mandate any specific FFI
- McCLIM is device-independent, and does not necessarily require the
use of FFIs, so any backend that needs to talk to C code needs to do
the FFI work itself.

-- 
\  Troels
/\ Henriksen


From david at lichteblau.com  Sun Jan 13 14:15:06 2008
From: david at lichteblau.com (David Lichteblau)
Date: Sun, 13 Jan 2008 15:15:06 +0100
Subject: [mcclim-devel] status of mcclim
In-Reply-To: <478A27F9.4040502@skynet.be>
References: <47894ABA.9030100@skynet.be>
	<87fxx29k62.fsf@lambda.athas.dyndns.dk>
	<478A27F9.4040502@skynet.be>
Message-ID: <20080113141506.GD8921@radon>

Quoting Jan Brosius (jan.brosius at skynet.be):
> If there is a Gtkairo backend for mcclim than I would expect that
> mcclim uses an ffi e.g. cffi.  If so I would like to have some working
> knowledge of how it is done and what C library one uses.  I mean wxcl
> uses wxWidgets (written in C++), swig to "translate it to cffi and
> also cffi.  But I couldn't find a folder like cffi in the mcclim
> distribution.

Gtkairo uses CFFI to call GTK+ functions.

The FFI definitions for that are partly hard-written (gtk-ffi.lisp,
cairo-ffi.lisp), partly auto-generated (ffi.lisp), and can be found in
mcclim/Backends/gtkairo/.

Users are not meant to call those FFI functions directly, and only a
small part of GTK+ functionality is used.

If you are looking for complete GTK+ bindings, consider CLG or one of
all the other GTK+ bindings available for Common Lisp.


d.


From rpgoldman at real-time.com  Sun Jan 13 16:35:26 2008
From: rpgoldman at real-time.com (Robert Goldman)
Date: Sun, 13 Jan 2008 10:35:26 -0600
Subject: [mcclim-devel] status of mcclim
In-Reply-To: <87fxx29k62.fsf@lambda.athas.dyndns.dk>
References: <47894ABA.9030100@skynet.be>
	<87fxx29k62.fsf@lambda.athas.dyndns.dk>
Message-ID: <478A3DCE.6040003@real-time.com>

Troels Henriksen wrote:
> Jan Brosius <jan.brosius at skynet.be> writes:
> 
[...]

>> Is there a gtk backend for clx (other than motif)?
> 
> "Gtk backend for CLX" does not make much sense (and McCLIM does not
> have a Motif backend at all, though the commercial CLIMs do). There is
> an experimental backend named "Gtkairo" that blends use of Gtk and
> Cairo, but it is not yet as stable or full-featured as the CLX
> backend. It may work for your programs, depending on what you want to
> do. In general, the drawing primitives work very well with it, but the
> more obscure CLIM facilities are less well supported.
> 
>> Is mcclim in alpha stage?
> 
> There is no defined stage. Strictly, it is not feature-complete as a
> CLIM implementation (but pretty close), so it would not be appropriate
> to call it a beta. On the other hand, while McCLIM is no rock pillar
> of stability, it is certainly not as unstable as "alpha" might imply.
> 
> 

I think it's difficult to answer this because there is a wide variation
in how solid different parts of the system might be.  If you use parts
of the system that you see in use in existing McCLIM applications, you
may find it very solid.  However, if you unwittingly start using a
feature of CLIM that is not used so much in these areas, you may find it
incomplete or buggy.  To my great sorrow, the last time I was using
McCLIM much, I seemed to have a perfect gift for finding the parts of
the spec that were not much exercised.  At that time, for example,
format-graph-from-roots was really only working for trees, and there
were serious problems with accepting values for commands with multiple
arguments.  I have not had an opportunity to use McCLIM in the
intervening time, so I don't know the extent to which these areas have
improved...

I think that Troels' response wrt gtkairo shows the same dynamic.

I am sorry not to be more helpful,


r


From splittist at gmail.com  Sun Jan 13 17:13:59 2008
From: splittist at gmail.com (John Q. Splittist)
Date: Sun, 13 Jan 2008 18:13:59 +0100
Subject: [mcclim-devel] status of mcclim
In-Reply-To: <478A3DCE.6040003@real-time.com>
References: <47894ABA.9030100@skynet.be>
	<87fxx29k62.fsf@lambda.athas.dyndns.dk>
	<478A3DCE.6040003@real-time.com>
Message-ID: <7928a3a10801130913x318aa294rde9cd6bdfaa4623@mail.gmail.com>

On Jan 13, 2008 5:35 PM, Robert Goldman <rpgoldman at real-time.com> wrote:
> Troels Henriksen wrote:
> > Jan Brosius <jan.brosius at skynet.be> writes:
...
> >> Is mcclim in alpha stage?
> >
> > There is no defined stage.
...
> I think it's difficult to answer this because there is a wide variation
> in how solid different parts of the system might be.

So, if you use the bits people use, you have a better chance of using
something solid than if you use the bits people don't use. Of course,
if everyone does this progress isn't made, so I urge you to use any
part of McClim that appeals to you, and fix the bits that don't
measure up (:

JQS


From ahefner at gmail.com  Tue Jan 15 16:00:23 2008
From: ahefner at gmail.com (Andy Hefner)
Date: Tue, 15 Jan 2008 11:00:23 -0500
Subject: [mcclim-devel] Re: [mcclim-cvs] CVS mcclim
In-Reply-To: <20080115154517.4B9E96913C@common-lisp.net>
References: <20080115154517.4B9E96913C@common-lisp.net>
Message-ID: <31ffd3c40801150800p2666f0a9i728be376d160225e@mail.gmail.com>

On Jan 15, 2008 10:45 AM, crhodes <crhodes at 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.


From athas at sigkill.dk  Tue Jan 15 22:28:25 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Tue, 15 Jan 2008 23:28:25 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
Message-ID: <87k5maiv06.fsf@lambda.athas.dyndns.dk>


So, McCLIM is already pretty old, and while I can't claim to have
worked on it for more than a year and a half, I feel like I have a
pretty good grasp of what it does, and how well it does it. Perhaps we
should start wondering about releasing a "stable" McCLIM, that is, one
that is feature complete (with relation to the CLIM spec) and more
tested than out usual releases. I'm not saying we should slap a stable
version number on the 0.9.6 release, just that I think it would be a
good, and achievable, goal to release a stable version this year. What
would need to be done to make this happen? Here's a preliminary list,
if you feel it is incomplete, please add to it:

     * First, implement all the reasonable parts of the CLIM 2 spec,
       with the exception of things that are unimplementable,
       underspecified or just really hard to do properly (fully
       generic designs, alpha blending and all, falls in this last
       category, I think). Things that are underspecified should
       probably be implemented by looking at later CLIM specs, as well
       as classic CLIM behaviour. We are already mostly there. Does
       anyone know exactly what is missing?

     * Create a better test suite, at least something that can
       actually be called a test suite, though it may not fully test
       the entire system. This is probably a must if a "stable"
       release is to have any meaning at all, and fortunately, many of
       the tricky aspects of CLIM do not actually need a graphical
       interface, and the Null backend may suffice for the majority of
       the rest. I would prefer using an actual regression testing
       library (such as FiveAM) compared to files filled with asserts.

     * Select a number of extensions (not necessarily all of them) and
       make sure they're as well tested as the core CLIM
       functionality. These extensions should also be documented.

     * Have at least one backend without major flaws. I think the CLX
       backend is good enough, apart from some suboptimal
       performance. Gtkairo may not reach that level this year.

     * Insert docstrings for all exported functionality. If I recall
       correctly, Robert Strandh spoke with one of the original CLIM
       spec authors and was told not to worry about copyright issues,
       so we could just copy from there.

The following is what is NOT necessary for a McCLIM 2.0 release:

     * Support for LispWorks and Allegro CLIM extensions.

     * Fully working and tested extensions. We only need to select
       those that are feasible to bring up to a sufficiently high
       level of stability and performance (does this leave out
       mcclim-freetype?). Of course, we should document which ones.

     * More than one fully working backend.

     * Documentation covering CLIM itself. The spec will have to do
       for now.

Finally: when you saw this email, none of you thought "I wonder what
insightful observations this thoughtful engineer has about a stable
release", you thought "why is this crazy hacker talking about a 2.0
version, we're still pre-1.0!". My idea is to make the McCLIM version
number follow the CLIM spec version number. While this is not terribly
useful for a 2.0 release in isolation, it makes it easier to design
similar 2.1 and 2.2 releases for the LispWorks and Allegro extensions,
as well as the hypothetical future CLIM 2.3 spec that will fix all the
ambiguous and underspecified details and bring CLIM into the 90's.

What are your thoughts?

-- 
\  Troels
/\ Henriksen - who's quite sleep-deprived


From joswig at lisp.de  Wed Jan 16 03:18:11 2008
From: joswig at lisp.de (Rainer Joswig)
Date: Wed, 16 Jan 2008 04:18:11 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
Message-ID: <58FECDDE-0AD4-4925-B479-AA531170DFE7@lisp.de>

I think one also should look whether the implemented facilities are  
usable (look and feel also) and correctly drawn.

Are the implemented gadgets working?

How about menus, choices, accepting values dialogs, etc?

Is incremental updating working?

Is there enough error checking and reporting in define-application- 
frame? This macro created great frustrations among CLIM users (buggy,  
poor error checking, non-obvious effects, poor overall robustness).  
Make mistake and you had to restart the App, or the whole Lisp. I'm  
not saying that McCLIN has these problems, but it should checked.





Am 15.01.2008 um 23:28 schrieb Troels Henriksen <athas at sigkill.dk>:

>
> So, McCLIM is already pretty old, and while I can't claim to have
> worked on it for more than a year and a half, I feel like I have a
> pretty good grasp of what it does, and how well it does it. Perhaps we
> should start wondering about releasing a "stable" McCLIM, that is, one
> that is feature complete (with relation to the CLIM spec) and more
> tested than out usual releases. I'm not saying we should slap a stable
> version number on the 0.9.6 release, just that I think it would be a
> good, and achievable, goal to release a stable version this year. What
> would need to be done to make this happen? Here's a preliminary list,
> if you feel it is incomplete, please add to it:
>
>     * First, implement all the reasonable parts of the CLIM 2 spec,
>       with the exception of things that are unimplementable,
>       underspecified or just really hard to do properly (fully
>       generic designs, alpha blending and all, falls in this last
>       category, I think). Things that are underspecified should
>       probably be implemented by looking at later CLIM specs, as well
>       as classic CLIM behaviour. We are already mostly there. Does
>       anyone know exactly what is missing?
>
>     * Create a better test suite, at least something that can
>       actually be called a test suite, though it may not fully test
>       the entire system. This is probably a must if a "stable"
>       release is to have any meaning at all, and fortunately, many of
>       the tricky aspects of CLIM do not actually need a graphical
>       interface, and the Null backend may suffice for the majority of
>       the rest. I would prefer using an actual regression testing
>       library (such as FiveAM) compared to files filled with asserts.
>
>     * Select a number of extensions (not necessarily all of them) and
>       make sure they're as well tested as the core CLIM
>       functionality. These extensions should also be documented.
>
>     * Have at least one backend without major flaws. I think the CLX
>       backend is good enough, apart from some suboptimal
>       performance. Gtkairo may not reach that level this year.
>
>     * Insert docstrings for all exported functionality. If I recall
>       correctly, Robert Strandh spoke with one of the original CLIM
>       spec authors and was told not to worry about copyright issues,
>       so we could just copy from there.
>
> The following is what is NOT necessary for a McCLIM 2.0 release:
>
>     * Support for LispWorks and Allegro CLIM extensions.
>
>     * Fully working and tested extensions. We only need to select
>       those that are feasible to bring up to a sufficiently high
>       level of stability and performance (does this leave out
>       mcclim-freetype?). Of course, we should document which ones.
>
>     * More than one fully working backend.
>
>     * Documentation covering CLIM itself. The spec will have to do
>       for now.
>
> Finally: when you saw this email, none of you thought "I wonder what
> insightful observations this thoughtful engineer has about a stable
> release", you thought "why is this crazy hacker talking about a 2.0
> version, we're still pre-1.0!". My idea is to make the McCLIM version
> number follow the CLIM spec version number. While this is not terribly
> useful for a 2.0 release in isolation, it makes it easier to design
> similar 2.1 and 2.2 releases for the LispWorks and Allegro extensions,
> as well as the hypothetical future CLIM 2.3 spec that will fix all the
> ambiguous and underspecified details and bring CLIM into the 90's.
>
> What are your thoughts?
>
> -- 
> \  Troels
> /\ Henriksen - who's quite sleep-deprived
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel


From athas at sigkill.dk  Wed Jan 16 07:44:25 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Wed, 16 Jan 2008 08:44:25 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <58FECDDE-0AD4-4925-B479-AA531170DFE7@lisp.de> (Rainer Joswig's
	message of "Wed, 16 Jan 2008 04:18:11 +0100")
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
	<58FECDDE-0AD4-4925-B479-AA531170DFE7@lisp.de>
Message-ID: <874pdekyee.fsf@lambda.athas.dyndns.dk>

Rainer Joswig <joswig at lisp.de> writes:

> I think one also should look whether the implemented facilities are
> usable (look and feel also) and correctly drawn.

While look & feel is obviously important for a GUI programming
toolkit, I think the focus for a 2.0 release should be on spec
compliance, with look & feel being a secondary goal to be worked on
once it's clear that a full spec implementation has been reached (or
is close).

> Are the implemented gadgets working?
>
> How about menus, choices, accepting values dialogs, etc?
>
> Is incremental updating working?

These are all instances of "do we implement the spec?" (The answer is
no for some of those.) I've heard that incremental output, as
described in the spec, is not feasible to implement, does anyone have
knowledge about that? Otherwise, my experience is that it works pretty
well.

> Is there enough error checking and reporting in define-application-
> frame? This macro created great frustrations among CLIM users (buggy,
> poor error checking, non-obvious effects, poor overall robustness).
> Make mistake and you had to restart the App, or the whole Lisp. I'm
> not saying that McCLIN has these problems, but it should checked.

The biggest problem with define-application-frame is that it has
confusing semantics and a lot of different ways to express similar
things. We can't really change this, as it's demanded by the spec
(right?), but perhaps we could emit some warnings for common
errors. In any case, that is secondary to making sure it works as
specified.

-- 
\  Troels
/\ Henriksen


From rpgoldman at real-time.com  Wed Jan 16 13:33:46 2008
From: rpgoldman at real-time.com (Robert Goldman)
Date: Wed, 16 Jan 2008 07:33:46 -0600
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <874pdekyee.fsf@lambda.athas.dyndns.dk>
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>	<58FECDDE-0AD4-4925-B479-AA531170DFE7@lisp.de>
	<874pdekyee.fsf@lambda.athas.dyndns.dk>
Message-ID: <478E07BA.8000708@real-time.com>

Troels Henriksen wrote:
> Rainer Joswig <joswig at lisp.de> writes:
> 
>> I think one also should look whether the implemented facilities are
>> usable (look and feel also) and correctly drawn.
> 
> While look & feel is obviously important for a GUI programming
> toolkit, I think the focus for a 2.0 release should be on spec
> compliance, with look & feel being a secondary goal to be worked on
> once it's clear that a full spec implementation has been reached (or
> is close).
> 
>> Are the implemented gadgets working?
>>
>> How about menus, choices, accepting values dialogs, etc?
>>
>> Is incremental updating working?
> 
> These are all instances of "do we implement the spec?" (The answer is
> no for some of those.) I've heard that incremental output, as
> described in the spec, is not feasible to implement, does anyone have
> knowledge about that? Otherwise, my experience is that it works pretty
> well.

Does accepting-values and input editing work now?  The last time I 
checked, it didn't work for commands that took multiple arguments.  If I 
remember correctly, when I changed only one value from the default, it 
looked like McCLIM would cycle through all of the other fields, and I 
could never get the process to terminate correctly.  I encountered this 
building a GUI for a program that takes a very large number of keyword 
arguments to tailor its behavior.  I will try to test this again, but 
fear that because of other commitments, won't be able to do it until 
after the end of January.  Does anyone else have a McCLIM program with 
commands with several arguments?

I will try to see if I still have a copy of a program that used this --- 
I may have ripped it all out and done some messy kludge of n commands to 
replace it....



From strandh at labri.fr  Thu Jan 17 07:27:25 2008
From: strandh at labri.fr (Robert Strandh)
Date: Thu, 17 Jan 2008 08:27:25 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
Message-ID: <18319.861.732761.381842@serveur5.labri.fr>

Troels Henriksen writes:
 > 
 > So, McCLIM is already pretty old, and while I can't claim to have
 > worked on it for more than a year and a half, I feel like I have a
 > pretty good grasp of what it does, and how well it does it. Perhaps we
 > should start wondering about releasing a "stable" McCLIM, that is, one
 > that is feature complete (with relation to the CLIM spec) and more
 > tested than out usual releases.

I think this is a laudable goal, and even if it doesn't happen, having
this goal might make progress faster in 2008.  

 > I'm not saying we should slap a stable
 > version number on the 0.9.6 release, just that I think it would be a
 > good, and achievable, goal to release a stable version this year. What
 > would need to be done to make this happen? Here's a preliminary list,
 > if you feel it is incomplete, please add to it:

The more general problem I see is that whenever I feel like working on
some feature of McCLIM, I feel stymied because of the lack of
maintainability of McCLIM.  

For that reason, I think an effort like this should start with some
preventive maintenance activities such as:

  * Remove commented-out code, or uncomment it.

  * Add signed-and-dated comments to difficult passages whenever
    reasonable.
  
  * Make sure McCLIM compiles with as few warnings as possible

  * Add references to the spec for code that implements some required
    functionality.

  * [and probably some more things that I can't think of right now]

 >      * First, implement all the reasonable parts of the CLIM 2 spec,
 >        with the exception of things that are unimplementable,
 >        underspecified or just really hard to do properly (fully
 >        generic designs, alpha blending and all, falls in this last
 >        category, I think). Things that are underspecified should
 >        probably be implemented by looking at later CLIM specs, as well
 >        as classic CLIM behaviour. We are already mostly there. Does
 >        anyone know exactly what is missing?

It is hard to tell what is missing because some parts of the spec are
optional, such as color blending for instance.

Also, color blending would be easy to implement if we had a backend
such as the one I started a while back that would use a single CLX
window as a frame buffer. 

But it might not be highest priority to implement all of the spec.  I
would say it is more urgent to make the parts that are currently
implemented work according to the spec.  I am thinking of
things like output-record inheriting from standard-rectangle and then
assuming all output records do so.  

 >      * Create a better test suite, at least something that can
 >        actually be called a test suite, though it may not fully test
 >        the entire system. This is probably a must if a "stable"
 >        release is to have any meaning at all, and fortunately, many of
 >        the tricky aspects of CLIM do not actually need a graphical
 >        interface, and the Null backend may suffice for the majority of
 >        the rest. I would prefer using an actual regression testing
 >        library (such as FiveAM) compared to files filled with asserts.

Sounds good.

 >      * Select a number of extensions (not necessarily all of them) and
 >        make sure they're as well tested as the core CLIM
 >        functionality. These extensions should also be documented.

Again, this sounds good, but that's partly because whether this is
reasonable or not depends on what (if any) such extensions are
selected. 

 >      * Have at least one backend without major flaws. I think the CLX
 >        backend is good enough, apart from some suboptimal
 >        performance. Gtkairo may not reach that level this year.

I think we should have at least one backend that uses a single
mirrored sheet (the graft, I suppose), so that we can test unusual
sheet transformations and such.  The X-window-as-frame-buffer backend
I suggested above would do that, but perhaps Gtkairo will as well. 

 >      * Insert docstrings for all exported functionality. If I recall
 >        correctly, Robert Strandh spoke with one of the original CLIM
 >        spec authors and was told not to worry about copyright issues,
 >        so we could just copy from there.

I am starting to think that docstrings are evil (because they are
mostly noise to the person reading the code).  I would like to discuss
the possibility of using (SETF DOCUMENTATION) instead. 

 > The following is what is NOT necessary for a McCLIM 2.0 release:
 > 
 >      * More than one fully working backend.

See above.  The CLX backend might not be good enough for testing
everything we would like.  

 >      * Documentation covering CLIM itself. The spec will have to do
 >        for now.

What do you mean by this?

 > Finally: when you saw this email, none of you thought "I wonder what
 > insightful observations this thoughtful engineer has about a stable
 > release", you thought "why is this crazy hacker talking about a 2.0
 > version, we're still pre-1.0!". My idea is to make the McCLIM version
 > number follow the CLIM spec version number. While this is not terribly
 > useful for a 2.0 release in isolation, it makes it easier to design
 > similar 2.1 and 2.2 releases for the LispWorks and Allegro extensions,
 > as well as the hypothetical future CLIM 2.3 spec that will fix all the
 > ambiguous and underspecified details and bring CLIM into the 90's.

Sounds like a good suggestion to me.  

-- 
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  Thu Jan 17 07:52:59 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 17 Jan 2008 08:52:59 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <18319.861.732761.381842@serveur5.labri.fr> (Robert Strandh's
	message of "Thu, 17 Jan 2008 08:27:25 +0100")
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
	<18319.861.732761.381842@serveur5.labri.fr>
Message-ID: <87tzlckhwk.fsf@lambda.athas.dyndns.dk>

Robert Strandh <strandh at labri.fr> writes:

>  > I'm not saying we should slap a stable
>  > version number on the 0.9.6 release, just that I think it would be a
>  > good, and achievable, goal to release a stable version this year. What
>  > would need to be done to make this happen? Here's a preliminary list,
>  > if you feel it is incomplete, please add to it:
>
> The more general problem I see is that whenever I feel like working on
> some feature of McCLIM, I feel stymied because of the lack of
> maintainability of McCLIM.  

I don't think it's that bad, to be honest. McCLIM doesn't do too many
obscure things, except that a newcomer may be confused about where
exactly events are read (I certainly was).

>   * Remove commented-out code, or uncomment it.

Definitely, I heavily dislike commented-out code.

>   * Add signed-and-dated comments to difficult passages whenever
>     reasonable.

I'm not sure I like this. I much prefer relying on the version control
system to provide me with this kind of information.

>   * Make sure McCLIM compiles with as few warnings as possible

This is a no-brainer, and I already did some work on it back in
November, I think. Most of the remaining warnings are missing
defgenerics, which is a lot of work, but not hard at all.

>   * Add references to the spec for code that implements some required
>     functionality.

Isn't this reference just the name of the function in question?

> It is hard to tell what is missing because some parts of the spec are
> optional, such as color blending for instance.

I don't think it is necessary for us to implement all optional parts
before a stable release.

> But it might not be highest priority to implement all of the spec.  I
> would say it is more urgent to make the parts that are currently
> implemented work according to the spec.  I am thinking of
> things like output-record inheriting from standard-rectangle and then
> assuming all output records do so.  

I think it's very important to have a full implementation of the
non-optional parts of the spec in a stable release, otherwise it has
no meaning.

> Again, this sounds good, but that's partly because whether this is
> reasonable or not depends on what (if any) such extensions are
> selected. 

I think MCCLIM-IMAGES should at least be selected, because it's useful
and somewhat simple. I don't know what else. Perhaps Freetype should
stop being Experimental and become an Extension?

> I think we should have at least one backend that uses a single
> mirrored sheet (the graft, I suppose), so that we can test unusual
> sheet transformations and such.  The X-window-as-frame-buffer backend
> I suggested above would do that, but perhaps Gtkairo will as well. 

This is mostly related to testing, not to actual use. Thus, while it
would be useful, I don't think it is critically important to a stable
McCLIM release.

>  >      * Insert docstrings for all exported functionality. If I recall
>  >        correctly, Robert Strandh spoke with one of the original CLIM
>  >        spec authors and was told not to worry about copyright issues,
>  >        so we could just copy from there.
>
> I am starting to think that docstrings are evil (because they are
> mostly noise to the person reading the code).  I would like to discuss
> the possibility of using (SETF DOCUMENTATION) instead. 

I think they are just as useful as comments to the person reading the
code. I'm not a fan of (SETF DOCUMENTATION), as it separates the
documentation from the code, making it easier for the two to get out
of sync.

>  >      * Documentation covering CLIM itself. The spec will have to do
>  >        for now.
>
> What do you mean by this?

I don't like the CLIM spec too much, and I would like to revise it
into something that is more usable. This would probably involve more
examples and descriptions of how the functions actually behave in
McCLIM (the spec is sometimes unclear or nonsensical).

-- 
\  Troels
/\ Henriksen


From tcr at freebits.de  Thu Jan 17 09:38:04 2008
From: tcr at freebits.de (Tobias C. Rittweiler)
Date: Thu, 17 Jan 2008 10:38:04 +0100
Subject: [mcclim-devel] Re: McCLIM 2.0 in 2008
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
	<18319.861.732761.381842@serveur5.labri.fr>
	<87tzlckhwk.fsf@lambda.athas.dyndns.dk>
Message-ID: <87ve5s4wsj.fsf@freebits.de>

Troels Henriksen <athas at sigkill.dk> writes:

> Robert Strandh <strandh at labri.fr> writes:
>
> > I am starting to think that docstrings are evil (because they are
> > mostly noise to the person reading the code).  I would like to discuss
> > the possibility of using (SETF DOCUMENTATION) instead. 
>
> I think they are just as useful as comments to the person reading the
> code. I'm not a fan of (SETF DOCUMENTATION), as it separates the
> documentation from the code, making it easier for the two to get out
> of sync.

Optimally, documentation and test cases should be coupled to catch
against this. It's on my todo list of Editor-hints to think and
experiment in this area. 

(If a reader of this list has got some ideas he'd like to share, I'd
like to ask him to subscribe to gmane.lisp.editors.hints.devel, or the
respective common-lisp.net mailinglist such that his opinions get
archived at the right place.)

  -T.



From rpgoldman at sift.info  Thu Jan 17 13:43:59 2008
From: rpgoldman at sift.info (Robert Goldman)
Date: Thu, 17 Jan 2008 07:43:59 -0600
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <87tzlckhwk.fsf@lambda.athas.dyndns.dk>
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>	<18319.861.732761.381842@serveur5.labri.fr>
	<87tzlckhwk.fsf@lambda.athas.dyndns.dk>
Message-ID: <478F5B9F.1070704@sift.info>

Troels Henriksen wrote:
> Robert Strandh <strandh at labri.fr> writes:
> 

> 
>>  >      * Insert docstrings for all exported functionality. If I recall
>>  >        correctly, Robert Strandh spoke with one of the original CLIM
>>  >        spec authors and was told not to worry about copyright issues,
>>  >        so we could just copy from there.
>>
>> I am starting to think that docstrings are evil (because they are
>> mostly noise to the person reading the code).  I would like to discuss
>> the possibility of using (SETF DOCUMENTATION) instead. 
> 
> I think they are just as useful as comments to the person reading the
> code. I'm not a fan of (SETF DOCUMENTATION), as it separates the
> documentation from the code, making it easier for the two to get out
> of sync.

I'd suggest that having docstrings in defgenerics is benign, because
they don't push meaningful code off the screen (assuming one doesn't use
:method).  That would tend to confine the objections to documentation
strings to ones that attach to method definitions and function
definitions.  In that case, one could put a (setf documentation) right
after the definition in question, so that they wouldn't float away from
the code, but wouldn't push the lambda list away from the body of the
definition.  I assume that, the way they are placed, below the slot
definitions, documentation strings for defclass are benign.

Would that be a reasonable compromise?


From athas at sigkill.dk  Thu Jan 17 13:47:54 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 17 Jan 2008 14:47:54 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <478F5B9F.1070704@sift.info> (Robert Goldman's message of "Thu,
	17 Jan 2008 07:43:59 -0600")
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
	<18319.861.732761.381842@serveur5.labri.fr>
	<87tzlckhwk.fsf@lambda.athas.dyndns.dk> <478F5B9F.1070704@sift.info>
Message-ID: <8763xspnqt.fsf@lambda.athas.dyndns.dk>

Robert Goldman <rpgoldman at sift.info> writes:

> I'd suggest that having docstrings in defgenerics is benign, because
> they don't push meaningful code off the screen (assuming one doesn't use
> :method).  That would tend to confine the objections to documentation
> strings to ones that attach to method definitions and function
> definitions.  In that case, one could put a (setf documentation) right
> after the definition in question, so that they wouldn't float away from
> the code, but wouldn't push the lambda list away from the body of the
> definition.  I assume that, the way they are placed, below the slot
> definitions, documentation strings for defclass are benign.
>
> Would that be a reasonable compromise?

I could live with that. Also because the majority of the interesting
docstrings live in defgenerics and defclasses, anyway.

-- 
\  Troels
/\ Henriksen


From strandh at labri.fr  Thu Jan 17 13:59:15 2008
From: strandh at labri.fr (Robert Strandh)
Date: Thu, 17 Jan 2008 14:59:15 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <87tzlckhwk.fsf@lambda.athas.dyndns.dk>
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
	<18319.861.732761.381842@serveur5.labri.fr>
	<87tzlckhwk.fsf@lambda.athas.dyndns.dk>
Message-ID: <18319.24371.556386.110425@serveur5.labri.fr>

Troels Henriksen writes:
 > >   * Add signed-and-dated comments to difficult passages whenever
 > >     reasonable.
 > 
 > I'm not sure I like this. I much prefer relying on the version control
 > system to provide me with this kind of information.

Although I agree that the information about who wrote a comment and
when is indeed available through the version control system, it is not
necessarily very convenient to get to.  Either way, my remark was more
about the comment itself than about the signature and date.


 > >   * Add references to the spec for code that implements some required
 > >     functionality.
 > 
 > Isn't this reference just the name of the function in question?

No, because unless you know all functions in the spec by heart, you
cannot know whether some code is intended to implement such a
function, or whether it is a function specific to the way it was
implemented.  The reference to the spec could take the form of a
section number.  There is something like that in regions.lisp. 

 > > It is hard to tell what is missing because some parts of the spec are
 > > optional, such as color blending for instance.
 > 
 > I don't think it is necessary for us to implement all optional parts
 > before a stable release.

I agree, but we must decide what optional parts should be included.

 > > But it might not be highest priority to implement all of the spec.  I
 > > would say it is more urgent to make the parts that are currently
 > > implemented work according to the spec.  I am thinking of
 > > things like output-record inheriting from standard-rectangle and then
 > > assuming all output records do so.  
 > 
 > I think it's very important to have a full implementation of the
 > non-optional parts of the spec in a stable release, otherwise it has
 > no meaning.

Of course, but I think the easiest way to get there is to make sure
the parts we have work first of all. 

-- 
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 strandh at labri.fr  Thu Jan 17 14:04:34 2008
From: strandh at labri.fr (Robert Strandh)
Date: Thu, 17 Jan 2008 15:04:34 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <87tzlckhwk.fsf@lambda.athas.dyndns.dk>
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
	<18319.861.732761.381842@serveur5.labri.fr>
	<87tzlckhwk.fsf@lambda.athas.dyndns.dk>
Message-ID: <18319.24690.268421.843139@serveur5.labri.fr>

Troels Henriksen writes:
 >
 > I think they are just as useful as comments to the person reading the
 > code. I'm not a fan of (SETF DOCUMENTATION), as it separates the
 > documentation from the code, making it easier for the two to get out
 > of sync.

I would agree for projects where the spec evolves rapidly and the code
with it.  For projects with a relatively stable spec like CLIM or CL
itself, I find the docstrings distracting.  I mean, if you read the
code for CAR, do you really find it useful to see the docstring?

-- 
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  Thu Jan 17 14:06:18 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 17 Jan 2008 15:06:18 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <18319.24371.556386.110425@serveur5.labri.fr> (Robert Strandh's
	message of "Thu, 17 Jan 2008 14:59:15 +0100")
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
	<18319.861.732761.381842@serveur5.labri.fr>
	<87tzlckhwk.fsf@lambda.athas.dyndns.dk>
	<18319.24371.556386.110425@serveur5.labri.fr>
Message-ID: <87y7aoo8bp.fsf@lambda.athas.dyndns.dk>

Robert Strandh <strandh at labri.fr> writes:

> No, because unless you know all functions in the spec by heart, you
> cannot know whether some code is intended to implement such a
> function, or whether it is a function specific to the way it was
> implemented.  The reference to the spec could take the form of a
> section number.  There is something like that in regions.lisp. 

Yes, I see how this would be useful.

> I agree, but we must decide what optional parts should be included.

How about anything that is currently implemented? Which parts of the
spec are optional? I know about general designs, but what else?

> Of course, but I think the easiest way to get there is to make sure
> the parts we have work first of all.

Fortunately, I think most of them do. McCLIM isn't as bad as its
reputation with respect to stability and compliance, the issues I know
of are certainly fairly obscure.

-- 
\  Troels
/\ Henriksen


From athas at sigkill.dk  Thu Jan 17 14:37:20 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 17 Jan 2008 15:37:20 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <18319.24690.268421.843139@serveur5.labri.fr> (Robert Strandh's
	message of "Thu, 17 Jan 2008 15:04:34 +0100")
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
	<18319.861.732761.381842@serveur5.labri.fr>
	<87tzlckhwk.fsf@lambda.athas.dyndns.dk>
	<18319.24690.268421.843139@serveur5.labri.fr>
Message-ID: <87sl0wo6vz.fsf@lambda.athas.dyndns.dk>

Robert Strandh <strandh at labri.fr> writes:

> I mean, if you read the code for CAR, do you really find it useful
> to see the docstring?

No, but it is useful for, say, CLIM:ACCEPT with its seventeen keyword
parameters, or the insanely complex CLIM:DEFINE-APPLICATION-FRAME
macro that seemingly no-one fully understands.

-- 
\  Troels
/\ Henriksen


From splittist at gmail.com  Thu Jan 17 15:36:38 2008
From: splittist at gmail.com (John Q. Splittist)
Date: Thu, 17 Jan 2008 16:36:38 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <87sl0wo6vz.fsf@lambda.athas.dyndns.dk>
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
	<18319.861.732761.381842@serveur5.labri.fr>
	<87tzlckhwk.fsf@lambda.athas.dyndns.dk>
	<18319.24690.268421.843139@serveur5.labri.fr>
	<87sl0wo6vz.fsf@lambda.athas.dyndns.dk>
Message-ID: <7928a3a10801170736y6da0ce6s910af67b853766ef@mail.gmail.com>

On Jan 17, 2008 3:37 PM, Troels Henriksen <athas at sigkill.dk> wrote:
> Robert Strandh <strandh at labri.fr> writes:
>
> > I mean, if you read the code for CAR, do you really find it useful
> > to see the docstring?
>
> No, but it is useful for, say, CLIM:ACCEPT with its seventeen keyword
> parameters, or the insanely complex CLIM:DEFINE-APPLICATION-FRAME
> macro that seemingly no-one fully understands.

How about someone putting together a quick hide/show-docstring[s]
command. That way the comments are physically attached but need not
take up screen space.

JQS


From joswig at lisp.de  Thu Jan 17 18:04:16 2008
From: joswig at lisp.de (Rainer Joswig)
Date: Thu, 17 Jan 2008 19:04:16 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <18319.861.732761.381842@serveur5.labri.fr>
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
	<18319.861.732761.381842@serveur5.labri.fr>
Message-ID: <FC450846-0612-4C64-BA3B-531B177F1A49@lisp.de>


Am 17.01.2008 um 08:27 schrieb Robert Strandh:

> I am starting to think that docstrings are evil (because they are
> mostly noise to the person reading the code).  I would like to discuss
> the possibility of using (SETF DOCUMENTATION) instead.
>

Doc strings are for users of those functions/macros. It helps me to  
understand
what the function does, how I call it, what results I get back and so  
on.
I really like that feature.

If for some code the documentation string gets in he way,
using (SETF DOCUMENTATION) is absolutely fine.




From nikodemus at random-state.net  Sun Jan 20 19:55:17 2008
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Sun, 20 Jan 2008 21:55:17 +0200
Subject: [mcclim-devel] [patch] two defvars
Message-ID: <633d72b0801201155o14440381hbe550e5e3f9edb49@mail.gmail.com>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: two-defvars.patch
Type: application/octet-stream
Size: 1722 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20080120/c6a54ac7/attachment.obj>

From nikodemus at random-state.net  Sun Jan 20 21:26:14 2008
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Sun, 20 Jan 2008 23:26:14 +0200
Subject: [mcclim-devel] display glitch in interactor / accept
Message-ID: <633d72b0801201326v5f6238eeke1c9d20fe5957f84@mail.gmail.com>

The glitch is visible in the screenshot:

  http://random-state.net/tmp/display-glitch-in-accept.png

(see the vertical bar before xyz.)

To reproduce, load the following code, and type "Test<enter>xyz" in the
interactor. This is using Christophe's CLX from darcs, and CVS McCLIM,
on:

Darwin manic.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10
18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386

and SBCL 1.0.13.45.

Cheers,

 -- Nikodemus

(require :mcclim)

(defpackage "TEST-GUI"
  (:use "CLIM-LISP" "CLIM"))

(in-package "TEST-GUI")

(define-application-frame test-frame ()
  ()
  (:panes
   (canvas :application :display-time nil :height 400 :width 600)
   (repl :interactor))
  (:layouts
   (default (vertically (:width 600 :height 600)
              canvas
              (:fill repl)))))

(defmethod frame-standard-output ((frame test-frame))
  (find-pane-named frame 'repl))

(define-test-frame-command (com-test :name t)
    ()
  (let ((name (accept 'string :prompt "Foo")))
    (format t "Foo ~A!" name)))

(run-frame-top-level (make-application-frame 'test-frame))Te


From athas at sigkill.dk  Sun Jan 20 22:12:16 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Sun, 20 Jan 2008 23:12:16 +0100
Subject: [mcclim-devel] display glitch in interactor / accept
In-Reply-To: <633d72b0801201326v5f6238eeke1c9d20fe5957f84@mail.gmail.com>
	(Nikodemus Siivola's message of "Sun, 20 Jan 2008 23:26:14 +0200")
References: <633d72b0801201326v5f6238eeke1c9d20fe5957f84@mail.gmail.com>
Message-ID: <87r6gcywn3.fsf@lambda.athas.dyndns.dk>

"Nikodemus Siivola" <nikodemus at random-state.net> writes:

> The glitch is visible in the screenshot:
>
>   http://random-state.net/tmp/display-glitch-in-accept.png
>
> (see the vertical bar before xyz.)

Yes, that's the remnant of the cursor; I thought it would be safe to
start the clearing of previous output a pixel more to the right than I
used to (it wasn't). I should have fixed this in CVS a few hours ago.

-- 
\  Troels
/\ Henriksen


From nikodemus at random-state.net  Mon Jan 21 00:12:23 2008
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Mon, 21 Jan 2008 02:12:23 +0200
Subject: [mcclim-devel] [bug] Asynchronous ID-CHOICE-ERROR -- CLX or McCLIM?
Message-ID: <633d72b0801201612g192bd6f9t49124e6f14caae9f@mail.gmail.com>

This may be a CLX issue, or a problem in the CLX backend -- I would not
know, but the test-case is pure CLIM. After the error future attempts to
RUN-FRAME-TOP-LEVEL result in similar errors.

Backtrace follows, self contained test-case attached
(RUN-FRAME-TOP-LEVEL, then "Stress" -- it may take a while, but
eventually it breaks for me.)

This is CVS McCLIM, Christophe's CLX, and SBCL 1.0.13.45, on a MacBook
running Tiger.

$ uname -a
Darwin manic.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10
18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386

X is the Apple packaged one: X11 1.1.3 - XFree86 4.4.0

Cheers,

 -- Nikodemus

Asynchronous ID-CHOICE-ERROR in request 10265 (last request was 10266)
 Code 55.0 [CreateGC] ID #x600002
   [Condition of type XLIB:ID-CHOICE-ERROR]

Restarts:
 0: [CONTINUE] Ignore
 1: [ABORT] Return to application command loop
 2: [ABORT] Return to SLIME's top level.
 3: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: (XLIB::X-CERROR "Ignore" XLIB:ID-CHOICE-ERROR)
  1: (XLIB:DEFAULT-ERROR-HANDLER #<XLIB:DISPLAY :0 (The XFree86
Project, Inc R40400000)> XLIB:ID-CHOICE-ERROR)
  2: (XLIB::REPORT-ERROR #<XLIB:DISPLAY :0 (The XFree86 Project, Inc
R40400000)> 14 XLIB:ID-CHOICE-ERROR)
  3: (XLIB::READ-ERROR-INPUT #<XLIB:DISPLAY :0 (The XFree86 Project,
Inc R40400000)> 10265 #S(XLIB::REPLY-BUFFER :SIZE 32 :IBUF8 #(0 14 25
40 2 0 ...) :NEXT NIL :DATA-SIZE 32) #<SB-THREAD:THREAD "initial
thread" {116920A9}>)
  4: (XLIB::READ-INPUT #<XLIB:DISPLAY :0 (The XFree86 Project, Inc
R40400000)> NIL NIL #<FUNCTION (LAMBDA (XLIB::PENDING-COMMAND))
{13969ECD}>)
  5: (XLIB::READ-REPLY #<unavailable argument> #<unavailable argument>)
  6: (XLIB:ALLOC-COLOR #<XLIB:COLORMAP TRUE-COLOR :0 32> #<XLIB:COLOR
0.641639 0.52443945 0.84608877>)
  7: ((SB-PCL::FAST-METHOD CLIM-CLX::X-PIXEL (CLIM-CLX::CLX-PORT T))
#(17 NIL) #<unavailable argument> #<CLIM-CLX::CLX-PORT :HOST ""
:DISPLAY-ID 0 {122D0AC1}> #<CLIM-INTERNALS::NAMED-COLOR "Unnamed
color">)
  8: ((SB-PCL::FAST-METHOD CLIM-CLX::MEDIUM-GCONTEXT
(CLIM-CLX::CLX-MEDIUM COLOR)) #(9 NIL) #<unused argument>
#<CLIM-CLX::CLX-MEDIUM {13F67CE1}> #<CLIM-INTERNALS::NAMED-COLOR
"Unnamed color">)
  9: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument>
#<CLIM-CLX::CLX-MEDIUM {13F67CE1}> #<CLIM-INTERNALS::NAMED-COLOR
"Unnamed color">)
 10: ((SB-PCL::FAST-METHOD MEDIUM-DRAW-POINT* (CLIM-CLX::CLX-MEDIUM T
T)) #<unavailable argument> #<unavailable argument>
#<CLIM-CLX::CLX-MEDIUM {13F67CE1}> 290 142)
 11: ((SB-PCL::FAST-METHOD
CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL (MEDIUM T T))
#<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-MEDIUM
{13F67CE1}> #<CLIM-CLX::CLX-MEDIUM {13F67CE1}> #<CLOSURE (FLET
CLIM-INTERNALS::GRAPHICS-OP) {13F67CC5}>)
 12: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS
(CLIM-INTERNALS::PIXMAP T)) #<unavailable argument> #<unavailable
argument> #<CLIM-INTERNALS::MIRRORED-PIXMAP {117385F9}> #<CLOSURE
(FLET CLIM-INTERNALS::GRAPHICS-OP) {13F67CC5}>)
 13: ((LAMBDA (COLOR X Y)) #(0.641639 0.52443945 0.84608877) 290 142)
 14: (RANDOM-RENDER 400 300 #<CLOSURE (LAMBDA (COLOR X Y)) {11738895}>)
 15: (RENDER-SCENE #<APPLICATION-PANE CANVAS {11F91F99}>)
 16: (COM-STRESS)
 17: ((SB-PCL::FAST-METHOD DEFAULT-FRAME-TOP-LEVEL
(APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument>
#<TEST-FRAME {1381E9F1}>)
 18: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL (APPLICATION-FRAME))
#<unavailable argument> #<unavailable argument> #<TEST-FRAME
{1381E9F1}>)
 19: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL :AROUND
(APPLICATION-FRAME)) #<unavailable argument>
#S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION
(SB-C::&OPTIONAL-DISPATCH #) {131373FD}> :PV NIL :NEXT-METHOD-CALL NIL
:ARG-INFO (1 . T)) #<TEST-FRAME {1381E9F1}>)
 20: (SB-INT:SIMPLE-EVAL-IN-LEXENV (RUN-FRAME-TOP-LEVEL
(MAKE-APPLICATION-FRAME (QUOTE TEST-FRAME))) #<NULL-LEXENV>)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-gui.lisp
Type: application/octet-stream
Size: 1915 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20080121/45d28a37/attachment.obj>

From nikodemus at random-state.net  Mon Jan 21 18:34:22 2008
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Mon, 21 Jan 2008 20:34:22 +0200
Subject: [mcclim-devel] [PATCH] fix undefined-variable warnings in
	commands.lisp
Message-ID: <1200940462999-git-send-email-nikodemus@random-state.net>

 ...for once, these are mostly really undefined variables,
 left over from some refactoring or another...
---
 commands.lisp |   16 ++++++++--------
 frames.lisp   |    7 ++++---
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/commands.lisp b/commands.lisp
index 66db758..5d163a9 100644
--- a/commands.lisp
+++ b/commands.lisp
@@ -332,7 +332,7 @@
 	 (command-name-from-symbol command-name))
 	(errorp
 	 (error 'command-not-accessible :command-table-name
-                (command-table-designator-as-name table)))
+                (command-table-designator-as-name command-table)))
 	(t nil)))
 
 (defun find-menu-item (menu-name command-table &key (errorp t))
@@ -436,7 +436,7 @@
            (in-table (position gesture keystroke-accelerators :test #'equal)))
       (when (and in-table errorp)
         (error 'command-already-present :command-table-name
-               (command-table-designator-as-name table)))
+               (command-table-designator-as-name command-table)))
       (if in-table
 	  (setf (nth in-table keystroke-items) item)
 	  (progn
@@ -474,7 +474,7 @@
 		  (setf (cdr items-tail) (cddr items-tail))))
 	    (when errorp
 	      (error 'command-not-present :command-table-name
-                     (command-table-designator-as-name table)))))))
+                     (command-table-designator-as-name command-table)))))))
   nil)
 
 (defun map-over-command-table-keystrokes (function command-table)
@@ -499,7 +499,7 @@
 	  do (return-from find-keystroke-item (values item command-table)))
     (if errorp
 	(error 'command-not-present :command-table-name
-               (command-table-designator-as-name table))
+               (command-table-designator-as-name command-table))
 	nil)))
 
 (defun lookup-keystroke-item (gesture command-table
@@ -522,11 +522,11 @@
 		   (values sub-item sub-command-table))))))
        command-table))))
 
-(defun partial-command-from-name (command-name)
+(defun partial-command-from-name (command-name command-table)
   (let ((parser (gethash command-name *command-parser-table*)))
     (if (null parser)
         (error 'command-not-present :command-table-name
-               (command-table-designator-as-name table))
+               (command-table-designator-as-name command-table))
         (cons command-name
               (mapcar #'(lambda (foo)
                           (declare (ignore foo))
@@ -549,7 +549,7 @@
     (if item
 	(let* ((value (command-menu-item-value item))
 	       (command (case (command-menu-item-type item)
-			 (:command
+                          (:command
 			  value)
 			 (:function
 			  (funcall value gesture numeric-arg))
@@ -558,7 +558,7 @@
 	  (if command
               ; Return a literal command, or create a partial command from a command-name
 	      (substitute-numeric-argument-marker (if (symbolp command)
-                                                      (partial-command-from-name command)
+                                                      (partial-command-from-name command command-table)
                                                       command)
                                                   numeric-arg)
 	      gesture))
diff --git a/frames.lisp b/frames.lisp
index 92376d3..ce7a551 100644
--- a/frames.lisp
+++ b/frames.lisp
@@ -521,13 +521,14 @@ documentation produced by presentations.")
       (object)
       (call-next-method)
     (menu-item
-     (let ((command (command-menu-item-value object)))
+     (let ((command (command-menu-item-value object))
+           (table (frame-command-table frame)))
        (unless (listp command)
-	 (setq command (partial-command-from-name command)))
+	 (setq command (partial-command-from-name command table)))
        (if (and (typep stream 'interactor-pane)
 		(partial-command-p command))
 	   (command-line-read-remaining-arguments-for-partial-command
-	    (frame-command-table frame) stream command 0)
+	    table stream command 0)
 	   command)))))
 
 (defmethod read-frame-command ((frame application-frame)
-- 
1.5.3.1-dirty



From nikodemus at random-state.net  Mon Jan 21 18:38:16 2008
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Mon, 21 Jan 2008 20:38:16 +0200
Subject: [mcclim-devel] [PATCH] one more undefined variable
Message-ID: <12009406961168-git-send-email-nikodemus@random-state.net>

 * Looks like a simple typo.
---
 recording.lisp |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/recording.lisp b/recording.lisp
index b113b1c..8bb234a 100644
--- a/recording.lisp
+++ b/recording.lisp
@@ -1730,7 +1730,7 @@ were added."
        (:bottom (incf top (- point-y descent))
                 (incf bottom (- point-y descent)))
        (:center (incf top (+ point-y (ceiling (- ascent descent) 2)))
-                (incf bottom (+ point-xy (ceiling (- ascent descent) 2)))))
+                (incf bottom (+ point-y (ceiling (- ascent descent) 2)))))
      (values left top right bottom))))
 
 (defmethod* (setf output-record-position) :around
-- 
1.5.3.1-dirty



From dherring at tentpost.com  Tue Jan 22 03:24:17 2008
From: dherring at tentpost.com (Daniel Herring)
Date: Mon, 21 Jan 2008 22:24:17 -0500 (EST)
Subject: [mcclim-devel] Bugs
Message-ID: <alpine.LNX.0.9999.0801212159190.2802@strider1.home.net>

Hi,

I've just started playing with McCLIM.

Below are some issues for McCLIM CVS on SBCL 1.0.12.17.

Please treat this as a bug report or tell me what I'm doing wrong (e.g. if 
CVS is known to be unstable).

Thanks,
Daniel



(clim-demo::run-test 'clim-demo::demodemo)


CLIM-Fig:

Selecting "ellipse" and then clicking on the canvas results in
"Attempt to invert the probably singular transformation 
#<CLIM-INTERNALS::STANDARD-HAIRY-TRANSFORMATION 0 0 0 0 266 185>.
    [Condition of type CLIM:SINGULAR-TRANSFORMATION]"

Bezier curves are very difficult to draw (lots of errors).


Calculator:

The buttons frequently don't respond.  Also, most calculators start a new 
number when a number is entered following; this calculator appends to the 
current result.

For example, the keys "3*4=5" generally show "3", "4", "7", and "5".  But 
I'm seeing "3", "4", "7", and "75".


Draggable Graph:

If I resize the window (usually a single maximize works) and then click a 
node, it disappears and SBCL says
"There is no applicable method for the generic function
   #<STANDARD-GENERIC-FUNCTION CLIM:SHEET-NATIVE-TRANSFORMATION (6)>
when called with arguments
   (NIL).
    [Condition of type SIMPLE-ERROR]"

The node disappears for good (can't select it) even though its connections 
refresh when connected nodes are dragged.  Only the first dragged node 
after the resize is affected (unless I select several nodes before 
acknowledging the error; then all selected nodes disappear).


Misc tests: Empty Records 3

The circle is in the same location as for Empty Records 1 & 2.  The bottom 
and right of the box are close to the circle as before.  However, the top 
left corner is now 2 diameters from the circle.


From ahefner at gmail.com  Tue Jan 22 07:44:21 2008
From: ahefner at gmail.com (Andy Hefner)
Date: Tue, 22 Jan 2008 02:44:21 -0500
Subject: [mcclim-devel] [PATCH] fix undefined-variable warnings in
	commands.lisp
In-Reply-To: <1200940462999-git-send-email-nikodemus@random-state.net>
References: <1200940462999-git-send-email-nikodemus@random-state.net>
Message-ID: <31ffd3c40801212344t153561fbm9341a87cbf6a7cc1@mail.gmail.com>

Sorry, gmail doesn't seem to agree with inline patches; could someone
else commit this one?

Thanks.


From athas at sigkill.dk  Tue Jan 22 08:56:39 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Tue, 22 Jan 2008 09:56:39 +0100
Subject: [mcclim-devel] Bugs
In-Reply-To: <alpine.LNX.0.9999.0801212159190.2802@strider1.home.net> (Daniel
	Herring's message of "Mon, 21 Jan 2008 22:24:17 -0500 (EST)")
References: <alpine.LNX.0.9999.0801212159190.2802@strider1.home.net>
Message-ID: <87fxwqtf08.fsf@lambda.athas.dyndns.dk>

Daniel Herring <dherring at tentpost.com> writes:

> Please treat this as a bug report or tell me what I'm doing wrong
> (e.g. if CVS is known to be unstable).

It's not, but I think most of the bugs you report (certainly the
Calculator one, and probably also the CLIM-FIG one) are bugs in the
demo applications, not McCLIM itself. Thus, while they should probably
be fixed, they don't have highest priority. But thanks for the bug
reports anyway, I don't think many McCLIM hackers spend a lot of time
running the demo programs, so bugs in them can often go unnoticed.

-- 
\  Troels
/\ Henriksen


From athas at sigkill.dk  Tue Jan 22 15:23:09 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Tue, 22 Jan 2008 16:23:09 +0100
Subject: [mcclim-devel] Bugs
In-Reply-To: <87fxwqtf08.fsf@lambda.athas.dyndns.dk> (Troels Henriksen's
	message of "Tue, 22 Jan 2008 09:56:39 +0100")
References: <alpine.LNX.0.9999.0801212159190.2802@strider1.home.net>
	<87fxwqtf08.fsf@lambda.athas.dyndns.dk>
Message-ID: <87myqx28bm.fsf@lambda.athas.dyndns.dk>

Troels Henriksen <athas at sigkill.dk> writes:

>
> It's not, but I think most of the bugs you report (certainly the
> Calculator one, and probably also the CLIM-FIG one) are bugs in the
> demo applications, not McCLIM itself.

So yeah, of course I immediately find a redisplay bug that affected
the calculator.

-- 
\  Troels
/\ Henriksen


From ahefner at gmail.com  Tue Jan 22 15:54:49 2008
From: ahefner at gmail.com (Andy Hefner)
Date: Tue, 22 Jan 2008 10:54:49 -0500
Subject: [mcclim-devel] Bugs
In-Reply-To: <alpine.LNX.0.9999.0801212159190.2802@strider1.home.net>
References: <alpine.LNX.0.9999.0801212159190.2802@strider1.home.net>
Message-ID: <31ffd3c40801220754x45ddad04gc3cfcca7ac9cc887@mail.gmail.com>

On Jan 21, 2008 10:24 PM, Daniel Herring <dherring at tentpost.com> wrote:

> Misc tests: Empty Records 3
>
> The circle is in the same location as for Empty Records 1 & 2.  The bottom
> and right of the box are close to the circle as before.  However, the top
> left corner is now 2 diameters from the circle.

This one is a known failure which I've meant to fix for some time.


From nikodemus at random-state.net  Tue Jan 22 23:28:38 2008
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Wed, 23 Jan 2008 01:28:38 +0200
Subject: [mcclim-devel] how to do pixel-by-pixel output?
Message-ID: <633d72b0801221528o71463964v8a5a8a843ce58f20@mail.gmail.com>

I realize this may be a case of "Doctor, it hurts when I do this..", but
I'm hoping there is some medicine to be had.

I'm displaying images from my raytracer on a canvas as they are being rendered.
I don't require per pixel updating -- any buffering scheme that updates the
screen "every once in a while" is fine by me.

Below is what I have now, and it sucks royally: DRAW-PIXEL* calls take ~8
seconds on a 400*600 region, and everything else takes < 1 second... (on CLX
backend.)

(defun render-scene (scene medium)
  (let* ((pixmap nil)
         (region (sheet-region medium))
         (width (bounding-rectangle-width region))
         (height (bounding-rectangle-height region))
         (end (- width 1)))
    (unwind-protect
         (progn
           (setf pixmap (allocate-pixmap medium width height))
           (raylisp::render scene (raylisp::scene-default-camera scene)
                            width height
                            (lambda (color x y)
                              (declare (type (simple-array
single-float (3)) color)
                                       (type fixnum x y))
                              (progn
                                (draw-point* pixmap x y :ink
(make-rgb-color (aref color 0) (aref color 1) (aref color 2)))
                                (when (= x end)
                                  (copy-from-pixmap pixmap 0 y width 1
medium 0 y))))
                            :normalize-camera t))
      (when pixmap (deallocate-pixmap pixmap)))))

What I would like (and what the above tries to do, but fails) is to get hold of
a some sort of object onto which I can efficiently blast colors pixel
by pixel, and
then update the screen using a convenient-for-me interval.

Cheers,

 -- Nikodemus


From nikodemus at random-state.net  Wed Jan 23 04:32:34 2008
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Wed, 23 Jan 2008 06:32:34 +0200
Subject: [mcclim-devel] how to do pixel-by-pixel output?
In-Reply-To: <31ffd3c40801221738h70fd025ap221f4c9f9a1a25dd@mail.gmail.com>
References: <633d72b0801221528o71463964v8a5a8a843ce58f20@mail.gmail.com>
	<31ffd3c40801221738h70fd025ap221f4c9f9a1a25dd@mail.gmail.com>
Message-ID: <633d72b0801222032v795b36bdp2f913b50080aec07@mail.gmail.com>

On 1/23/08, Andy Hefner <ahefner at gmail.com> wrote:
> On Jan 22, 2008 6:28 PM, Nikodemus Siivola <nikodemus at random-state.net> wrote:
>
> > Below is what I have now, and it sucks royally: DRAW-PIXEL* calls take ~8
> > seconds on a 400*600 region, and everything else takes < 1 second... (on CLX
> > backend.)
>
> Switching from draw-point* to medium-draw-point* with (setf
> medium-ink) is likely to be a little faster, but still pretty
> hopeless.
>
> > What I would like (and what the above tries to do, but fails) is to get hold of
> > a some sort of object onto which I can efficiently blast colors pixel
> > by pixel, and then update the screen using a convenient-for-me interval.
>
> The existing McCLIM image facilities can (I presume) efficiently
> transfer RGB images, but not in the incremental manner you require.
> Something analogous to xlib:put-image or xlib:put-raw-image seems
> ideal for filling stripes of your pixmap. As a quick and dirty
> solution, I have some old code at
> http://vintage-digital.com/hefner/mcclim/medium-draw-pixels.lisp which
> is a thin wrapper around xlib:put-image and will (probably) work with
> your pixmap, taking a two-dimensional '(unsigned-byte 32) array of
> packed RGB values as input. X11 being what it is, you might have to
> twiddle the :bits-per-pixel (some machines want 32, others 24).

Perfect -- this runs in < 1 second.

(defun render-scene (scene sheet)
  (let* ((region (sheet-region sheet))
         (width (bounding-rectangle-width region))
         (height (bounding-rectangle-height region))
         (end (- width 1))
         (image (make-array (list 1 width) :element-type '(unsigned-byte 32))))
    (raylisp::render scene (raylisp::scene-default-camera scene)
                     width height
                     (lambda (color x y)
                       (declare (type (simple-array single-float (3)) color)
                                (type fixnum x y))
                       ;; FIXME: Gamma...
                       (let ((r (floor (* 255 (aref color 0))))
                             (g (floor (* 255 (aref color 1))))
                             (b (floor (* 255 (aref color 2)))))
                         (setf (aref image 0 x) (logior (ash r 16) (ash g 8) b))
                         (when (= x end)
                           (with-sheet-medium (medium sheet)
                             (medium-draw-pixels* medium image 0 y)))))
                     :normalize-camera t)))

Apropos: while figuring out how use your code I came across
RGB-IMAGE-DESIGN, and managed to make it work for usable well as well
-- code below runs in < 2 seconds.

(defun render-scene (scene medium)
  (let* ((region (sheet-region medium))
         (width (bounding-rectangle-width region))
         (height (bounding-rectangle-height region))
         (end (- width 1))
         (data (make-array (list 1 width) :element-type '(unsigned-byte 32))))
    (raylisp::render scene (raylisp::scene-default-camera scene)
                     width height
                     (lambda (color x y)
                       (declare (type (simple-array single-float (3)) color)
                                (type fixnum x y))
                       ;; FIXME: Gamma...
                       (let ((r (floor (* 255 (aref color 0))))
                             (g (floor (* 255 (aref color 1))))
                             (b (floor (* 255 (aref color 2)))))
                         (setf (aref data 0 x) (logior (ash b 16) (ash g 8) r))
                         (when (= x end)
                           (let (design)
                             (unwind-protect
                                  (progn
                                    (setf design (climi::make-rgb-image-design
                                                  (make-instance
'climi::rgb-image
                                                                 :width width
                                                                 :height 1
                                                                 :data data)))
                                    (draw-design medium design :y y))
                               (climi::free-image-design design))))))
                     :normalize-camera t)))

I can live with CLIMI:: prefixes, etc... but is either of these
expected to land in CLIM-EXTENSIONS anytime soon?

> If you can live without the incremental display, you could display the
> entire image using make-image and draw-image.

...unfortunately incremental display is the only real of having a GUI
on this thing -- it doesn't matter for images that render fast, but
ones that take longer I want to see in progress, so I can abort if
there's something wrong without waiting the whole thing out.


From athas at sigkill.dk  Wed Jan 23 22:19:46 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Wed, 23 Jan 2008 23:19:46 +0100
Subject: [mcclim-devel] Bugs
In-Reply-To: <alpine.LNX.0.9999.0801212159190.2802@strider1.home.net> (Daniel
	Herring's message of "Mon, 21 Jan 2008 22:24:17 -0500 (EST)")
References: <alpine.LNX.0.9999.0801212159190.2802@strider1.home.net>
Message-ID: <87ejc8mbgd.fsf@lambda.athas.dyndns.dk>

Daniel Herring <dherring at tentpost.com> writes:

> Bezier curves are very difficult to draw (lots of errors).

The main error I encountered (really, the only one, disregarding
redisplay-flickering) was how ease it was to end up with "null size
beziers", which McCLIM really doesn't like. I made CLIM-FIG not
attempt to draw these, which should make bezier drawing easier, but I
don't know whether this is the right thing.

-- 
\  Troels
/\ Henriksen


From athas at sigkill.dk  Wed Jan 23 22:38:22 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Wed, 23 Jan 2008 23:38:22 +0100
Subject: [mcclim-devel] Bugs
In-Reply-To: <alpine.LNX.0.9999.0801212159190.2802@strider1.home.net> (Daniel
	Herring's message of "Mon, 21 Jan 2008 22:24:17 -0500 (EST)")
References: <alpine.LNX.0.9999.0801212159190.2802@strider1.home.net>
Message-ID: <878x2gmald.fsf@lambda.athas.dyndns.dk>

Daniel Herring <dherring at tentpost.com> writes:

> Selecting "ellipse" and then clicking on the canvas results in
> "Attempt to invert the probably singular transformation
> #<CLIM-INTERNALS::STANDARD-HAIRY-TRANSFORMATION 0 0 0 0 266 185>.
>    [Condition of type CLIM:SINGULAR-TRANSFORMATION]"

Your problem was trying to draw zero-radius ellipses. I fixed this so
it's now possible (though they obviously aren't visible).

-- 
\  Troels
/\ Henriksen


From ch-mcclim at bobobeach.com  Sun Jan 27 03:05:22 2008
From: ch-mcclim at bobobeach.com (Cyrus Harmon)
Date: Sat, 26 Jan 2008 19:05:22 -0800
Subject: [mcclim-devel] mcclim debugger patch
Message-ID: <C4A471FF-9FF4-42D1-B24D-1F574396BB44@bobobeach.com>

the following patch fixes the mcclim debugger to work with swank. The  
condition-references slot is now gone, although there is some remnant  
of this in the 'compiler-condition and in the condition-extras. I  
think the right thing to do is to remove the slot from 'debugger-info,  
BICBW.

Thanks,

Cyrus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcclim-debugger-fix.patch
Type: application/octet-stream
Size: 1663 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20080126/bd9258e8/attachment.obj>
-------------- next part --------------


From david at lichteblau.com  Tue Jan 29 21:12:48 2008
From: david at lichteblau.com (David Lichteblau)
Date: Tue, 29 Jan 2008 22:12:48 +0100
Subject: [mcclim-devel] mcclim-images.asd
Message-ID: <20080129211248.GF16179@radon>

Hi,

can you please move mcclim-images into its own system file mcclim.asd,
and mcclim-images-FOO into their own files mcclim-images-FOO.asd?

Right now, it's not possible to load the clim-listener system without
having loaded the mcclim system manually before.

(It would be possible to change the order of the dependencies in
clim-listener.asd so that this problem is avoided, but ISTR that older
versions of ASDF expected the opposite order, and when we discussed this
on #lisp, the consensus was that any system that user code would depend
on needs its own .asd file.)


Thanks,
David


From david at lichteblau.com  Tue Jan 29 21:16:05 2008
From: david at lichteblau.com (David Lichteblau)
Date: Tue, 29 Jan 2008 22:16:05 +0100
Subject: [mcclim-devel] Building on OpenMCL
Message-ID: <20080129211605.GG16179@radon>

Hi,

McCLIM currently has trouble building on OpenMCL.  Do you have a fix for
that?


Thanks,
David

----------------------------------------------------------------------
No MAKE-LOAD-FORM method is defined for #S(DREI:FACE :INK #.CLIM:+FOREGROUND-INK+
                                                     :STYLE #<STANDARD-TEXT-STYLE NIL :ROMAN NIL>)
   [Condition of type SIMPLE-ERROR]

Restarts:
 0: [RETRY-COMPILE-FILE] Retry compiling #P"/home/david/clbuild/source/mcclim/Drei/drawing-options.lisp"
 1: [SKIP-COMPILE-FILE] Skip compiling #P"/home/david/clbuild/source/mcclim/Drei/drawing-options.lisp"
 2: [RETRY] Retry performing #<COMPILE-OP NIL #x3000410B90ED> on #<CL-SOURCE-FILE "drawing-options" #x30004105FDED>.
 3: [ACCEPT] Continue, treating #<COMPILE-OP NIL #x3000410B90ED> on #<CL-SOURCE-FILE "drawing-options" #x30004105FDED> as having been successful.
 4: [ABORT] Abort SLIME compilation.
 5: [ABORT] Return to SLIME's top level.
 6: [ABORT-BREAK] Reset this process
 7: [ABORT] Kill this process

Backtrace:
  0: (CCL::NO-MAKE-LOAD-FORM-FOR #S(DREI:FACE :INK #.CLIM:+FOREGROUND-INK+
                  :STYLE #<STANDARD-TEXT-STYLE NIL :ROMAN NIL>))
  1: (CCL::FASL-SCAN-USER-FORM #S(DREI:FACE :INK #.CLIM:+FOREGROUND-INK+
                  :STYLE #<STANDARD-TEXT-STYLE NIL :ROMAN NIL>))
  2: (CCL::FASL-SCAN-CLFUN #<Anonymous Function #x300041F0E08F>)
  3: (CCL::FASL-SCAN '((23 81)
       (47
        "home:clbuild;source;mcclim;Drei;drawing-options.lisp.newest")
       (4 #<Anonymous Function #x300041EF043F>)
       (4 #<Anonymous Function #x300041EE843F>)
       (4 #<Anonymous Function #x300041EE170F>)
       (4 #<Anonymous Function #x300041F1A9EF>)
       (4 #<Anonymous Function #x300041F13D7F>)
       (4 #<Anonymous Function #x300041F0E08F>)
       (4 #<Anonymous Function #x300041F0839F>) ..))))
  4: (CCL::FASL-SCAN-FORMS-AND-DUMP-FILE '((23 81)
       (47
        "home:clbuild;source;mcclim;Drei;drawing-options.lisp.newest")
       (4 #<Anonymous Function #x300041EF043F>)
       (4 #<Anonymous Function #x300041EE843F>)
       (4 #<Anonymous Function #x300041EE170F>)
       (4 #<Anonymous Function #x300041F1A9EF>)
       (4 #<Anonymous Function #x300041F13D7F>)
       (4 #<Anonymous Function #x300041F0E08F>)
       (4 #<Anonymous Function #x300041F0839F>) ..))) "/home/david/clbuild/source/mcclim/Drei/drawing-options.lx64fsl" #<LEXICAL-ENVIRONMENT  #x300041EF663D>)
  5: (CCL::%COMPILE-FILE "/home/david/clbuild/source/mcclim/Drei/drawing-options.lisp" "/home/david/clbuild/source/mcclim/Drei/drawing-options.lx64fsl" 'NIL 'NIL 'NIL 'NIL 'T 'T 'NIL 'NIL #<BACKEND LINUXX8664 #x3000407892CD> ':DEFAULT)
  6: (COMPILE-FILE #P"/home/david/clbuild/source/mcclim/Drei/drawing-options.lisp" ':OUTPUT-FILE #P"/home/david/clbuild/source/mcclim/Drei/drawing-options.lx64fsl" ':VERBOSE 'NIL ':PRINT 'NIL ':LOAD 'NIL ':FEATURES 'NIL ':TARGET ':LINUXX8664 ':SAVE-LOCAL-SYMBOLS 'NIL ':SAVE-DOC-STRINGS 'T ':SAVE-DEFINITIONS 'T ':EXTERNAL-FORMAT 'NIL ':FORCE ':DEFAULT)
  7: (#<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP
                                     ASDF:CL-SOURCE-FILE)> #<COMPILE-OP NIL #x3000410B90ED> #<CL-SOURCE-FILE "drawing-options" #x30004105FDED>)
  8: (CCL::%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE '(NIL
       #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP
                                       ASDF:CL-SOURCE-FILE)>
       . 5864064454365))
  9: (CCL::%CALL-NEXT-METHOD '(NIL
       #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP
                                       ASDF:CL-SOURCE-FILE)>
       . 5864064454365))
 10: (#<STANDARD-METHOD ASDF:PERFORM :AROUND (T T)> '(NIL
       #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP
                                       ASDF:CL-SOURCE-FILE)>
       . 5864064454365) #<COMPILE-OP NIL #x3000410B90ED>)
 11: (CCL::%%STANDARD-COMBINED-METHOD-DCODE '(#<STANDARD-METHOD ASDF:PERFORM :AROUND (T T)>
       (#<STANDARD-METHOD ASDF:PERFORM :BEFORE #>)
       (#<STANDARD-METHOD ASDF:PERFORM :AFTER #>)
       #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP
                                       ASDF:CL-SOURCE-FILE)>) 5864064454365)
 12: (ASDF:OPERATE 'ASDF:LOAD-OP "mcclim")
 13: (#<Anonymous Function #x300040FE12BF>)
 14: (#<Anonymous Function #x300040E70BFF> #<COMPILED-LEXICAL-CLOSURE #x3000410176FF>)
 15: (SWANK-BACKEND:CALL-WITH-COMPILATION-HOOKS #<COMPILED-LEXICAL-CLOSURE #x3000410176FF>)
 16: (SWANK::OPERATE-ON-SYSTEM "mcclim" "LOAD-OP")
 17: (#<Anonymous Function #x300040FE1A5F>)
 18: (SWANK::MEASURE-TIME-INTERVAL #<COMPILED-LEXICAL-CLOSURE #x30004101774F>)
 19: (SWANK::SWANK-COMPILER #<COMPILED-LEXICAL-CLOSURE #x30004101774F>)
 20: (SWANK:OPERATE-ON-SYSTEM-FOR-EMACS "mcclim" "LOAD-OP")
 21: (CCL::CALL-CHECK-REGS 'SWANK:OPERATE-ON-SYSTEM-FOR-EMACS "mcclim" "LOAD-OP")
 22: (#<Anonymous Function #x300040F344EF>)
 23: (#<Anonymous Function #x300040E0C16F> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x300040F2BF6F> #<COMPILED-LEXICAL-CLOSURE #x3000410177AF>)
 24: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x300040F2BF6F> #<COMPILED-LEXICAL-CLOSURE #x3000410177AF>)
 25: (SWANK::EVAL-FOR-EMACS '(SWANK:OPERATE-ON-SYSTEM-FOR-EMACS "mcclim" "LOAD-OP") "COMMON-LISP-USER" 12)
 26: (FUNCALL 'SWANK::EVAL-FOR-EMACS '(SWANK:OPERATE-ON-SYSTEM-FOR-EMACS "mcclim" "LOAD-OP") "COMMON-LISP-USER" 12)
 27: (SWANK::READ-FROM-EMACS)
 28: (#<Anonymous Function #x300040EBA10F>)
 29: (#<Anonymous Function #x300040E0C16F> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x300040F2BF6F> #<Anonymous Function #x300040EBA10F>)
 30: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x300040F2BF6F> #<Anonymous Function #x300040EBA10F>)
 31: (#<Anonymous Function #x300040EA63AF>)
 32: (SWANK::CALL-WITH-REDIRECTED-IO #<CONNECTION  #x300040F7163D> #<COMPILED-LEXICAL-CLOSURE #x3000410177FF>)
 33: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION #<CONNECTION  #x300040F7163D> #<COMPILED-LEXICAL-CLOSURE #x3000410177FF>)
 34: (SWANK::CALL-WITH-CONNECTION #<CONNECTION  #x300040F7163D> #<Anonymous Function #x300040EBA10F>)
 35: (SWANK::HANDLE-REQUEST #<CONNECTION  #x300040F7163D>)
 36: (SWANK::REPL-LOOP #<CONNECTION  #x300040F7163D>)
 37: (#<Anonymous Function #x300040EB4DFF>)
 38: (SWANK::CALL-WITH-BINDINGS 'NIL #<COMPILED-LEXICAL-CLOSURE #x300040F882DF>)
 39: (#<Anonymous Function #x300040EB4E7F>)
 40: (CCL::RUN-PROCESS-INITIAL-FORM #<PROCESS repl-thread(5) [Active] #x300040F7312D> '(#<COMPILED-LEXICAL-CLOSURE #x300040F7309F>))
 41: (#<Anonymous Function #x30004045DE7F> #<PROCESS repl-thread(5) [Active] #x300040F7312D> '(#<COMPILED-LEXICAL-CLOSURE #x300040F7309F>))
 42: (#<Anonymous Function #x30004043CF1F>)


From ahefner at gmail.com  Tue Jan 29 21:15:21 2008
From: ahefner at gmail.com (Andy Hefner)
Date: Tue, 29 Jan 2008 16:15:21 -0500
Subject: [mcclim-devel] mcclim-images.asd
In-Reply-To: <20080129211248.GF16179@radon>
References: <20080129211248.GF16179@radon>
Message-ID: <31ffd3c40801291315p4b889ab0uebb44ee95d3d6c03@mail.gmail.com>

Incidentally, I still don't grok the added value of the mcclim-images
wrapper (other than as a single interface for loading multiple file
types) versus having the load functions return CLIM designs correctly.
Further, the interface is broken. I favor the nuclear option.


From david at lichteblau.com  Tue Jan 29 21:26:54 2008
From: david at lichteblau.com (David Lichteblau)
Date: Tue, 29 Jan 2008 22:26:54 +0100
Subject: [mcclim-devel] mcclim-images.asd
In-Reply-To: <31ffd3c40801291315p4b889ab0uebb44ee95d3d6c03@mail.gmail.com>
References: <20080129211248.GF16179@radon>
	<31ffd3c40801291315p4b889ab0uebb44ee95d3d6c03@mail.gmail.com>
Message-ID: <20080129212654.GH16179@radon>

Quoting Andy Hefner (ahefner at gmail.com):
> Further, the interface is broken.

I think that most code in mcclim-images is valuable, assuming the system
definition issues can be sorted out.  The image loading API also seems
nice, but admittedly the drawing API needs to be worked on.

If you don't like the currently proposed functions, would you accept a
version of rgb-images that use draw-image (again), but this time with
correct handling of transformed designs?

It's really just a question of getting the output recording right.

> I favor the nuclear option.

... because we must not allow an output recording gap?


d.


From athas at sigkill.dk  Tue Jan 29 21:49:28 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Tue, 29 Jan 2008 22:49:28 +0100
Subject: [mcclim-devel] mcclim-images.asd
In-Reply-To: <31ffd3c40801291315p4b889ab0uebb44ee95d3d6c03@mail.gmail.com>
	(Andy Hefner's message of "Tue, 29 Jan 2008 16:15:21 -0500")
References: <20080129211248.GF16179@radon>
	<31ffd3c40801291315p4b889ab0uebb44ee95d3d6c03@mail.gmail.com>
Message-ID: <87r6g0cnfb.fsf@lambda.athas.dyndns.dk>

"Andy Hefner" <ahefner at gmail.com> writes:

> Incidentally, I still don't grok the added value of the mcclim-images
> wrapper (other than as a single interface for loading multiple file
> types) versus having the load functions return CLIM designs correctly.
> Further, the interface is broken. I favor the nuclear option.

I have come to favor the proposed bitmap extension in CLIM 2.0, which
seems to be actually implemented in CLIM 2.2. I would support an
obliteration of MCCLIM-IMAGES and an implementation of the
bitmap-pattern protocol, but not one without the other.

-- 
\  Troels
/\ Henriksen


From athas at sigkill.dk  Tue Jan 29 21:50:29 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Tue, 29 Jan 2008 22:50:29 +0100
Subject: [mcclim-devel] Re: Building on OpenMCL
In-Reply-To: <20080129211605.GG16179@radon> (David Lichteblau's message of
	"Tue, 29 Jan 2008 22:16:05 +0100")
References: <20080129211605.GG16179@radon>
Message-ID: <87lk68cndm.fsf@lambda.athas.dyndns.dk>

David Lichteblau <david at lichteblau.com> writes:

> Hi,
>
> McCLIM currently has trouble building on OpenMCL.  Do you have a fix for
> that?

I do not understand that error, or why it
happens. Drawing-options.lisp is very simple.

-- 
\  Troels
/\ Henriksen


From david at lichteblau.com  Wed Jan 30 12:29:33 2008
From: david at lichteblau.com (David Lichteblau)
Date: Wed, 30 Jan 2008 13:29:33 +0100
Subject: [mcclim-devel] Re: Building on OpenMCL
In-Reply-To: <87lk68cndm.fsf@lambda.athas.dyndns.dk>
References: <20080129211605.GG16179@radon>
	<87lk68cndm.fsf@lambda.athas.dyndns.dk>
Message-ID: <20080130122932.GA4080@radon>

Quoting Troels Henriksen (athas at sigkill.dk):
> I do not understand that error, or why it
> happens. Drawing-options.lisp is very simple.

Simple on SBCL, where clim-lisp:defconstant is actually defvar, but
perhaps not on Lisps where cl:defconstant is being used?

Changing fix-openmcl.lisp to use defvar for defconstant fixes the
problem, but is that the right solution?  Is there perhaps a
make-load-form missing somewhere?


d.


From david at lichteblau.com  Wed Jan 30 12:30:46 2008
From: david at lichteblau.com (David Lichteblau)
Date: Wed, 30 Jan 2008 13:30:46 +0100
Subject: [mcclim-devel] ESA-UTILS:VALUES-MAX-MIN
Message-ID: <20080130123046.GB4080@radon>

To whom it may concern:

compilation aborted because of fatal error:
;   READ failure in COMPILE-FILE:
;     SB-INT:SIMPLE-READER-PACKAGE-ERROR at 46165 (line 1135, column 49)
on #<SB-SYS:FD-STREAM for "file
/home/david/clbuild/source/climacs/prolog-syntax.lisp" {1002556561}>:
;       Symbol "VALUES-MAX-MIN" not found in the ESA-UTILS package.


From athas at sigkill.dk  Wed Jan 30 12:38:57 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Wed, 30 Jan 2008 13:38:57 +0100
Subject: [mcclim-devel] ESA-UTILS:VALUES-MAX-MIN
In-Reply-To: <20080130123046.GB4080@radon> (David Lichteblau's message of
	"Wed, 30 Jan 2008 13:30:46 +0100")
References: <20080130123046.GB4080@radon>
Message-ID: <87myqnbi8u.fsf@lambda.athas.dyndns.dk>

David Lichteblau <david at lichteblau.com> writes:

> compilation aborted because of fatal error:
> ;   READ failure in COMPILE-FILE:
> ;     SB-INT:SIMPLE-READER-PACKAGE-ERROR at 46165 (line 1135, column 49)
> on #<SB-SYS:FD-STREAM for "file
> /home/david/clbuild/source/climacs/prolog-syntax.lisp" {1002556561}>:
> ;       Symbol "VALUES-MAX-MIN" not found in the ESA-UTILS package.

I don't understand this error either, VALUES-MAX-MIN is properly
exported from ESA-UTILS AFAICS.

-- 
\  Troels
/\ Henriksen


From athas at sigkill.dk  Wed Jan 30 12:46:28 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Wed, 30 Jan 2008 13:46:28 +0100
Subject: [mcclim-devel] Re: Building on OpenMCL
In-Reply-To: <20080130122932.GA4080@radon> (David Lichteblau's message of
	"Wed, 30 Jan 2008 13:29:33 +0100")
References: <20080129211605.GG16179@radon>
	<87lk68cndm.fsf@lambda.athas.dyndns.dk> <20080130122932.GA4080@radon>
Message-ID: <87fxwfbhwb.fsf@lambda.athas.dyndns.dk>

David Lichteblau <david at lichteblau.com> writes:

> Simple on SBCL, where clim-lisp:defconstant is actually defvar, but
> perhaps not on Lisps where cl:defconstant is being used?
>
> Changing fix-openmcl.lisp to use defvar for defconstant fixes the
> problem, but is that the right solution?  Is there perhaps a
> make-load-form missing somewhere?

I got an email from Fred Gilham suggesting that the error is the use
of the functions that are automatically created by DEFSTRUCT. These
functions are not guaranteed to be available at compile-time. I
committed his proposed fix, which was to wrap the defstruct forms in
eval-when. Does this fix it?

-- 
\  Troels
/\ Henriksen


From david at lichteblau.com  Wed Jan 30 12:51:08 2008
From: david at lichteblau.com (David Lichteblau)
Date: Wed, 30 Jan 2008 13:51:08 +0100
Subject: [mcclim-devel] ESA-UTILS:VALUES-MAX-MIN
In-Reply-To: <87myqnbi8u.fsf@lambda.athas.dyndns.dk>
References: <20080130123046.GB4080@radon>
	<87myqnbi8u.fsf@lambda.athas.dyndns.dk>
Message-ID: <20080130125108.GI16179@radon>

Quoting Troels Henriksen (athas at sigkill.dk):
> I don't understand this error either, VALUES-MAX-MIN is properly
> exported from ESA-UTILS AFAICS.

Oh.  Sorry, I take that one back.  Lost in a maze of different clbuilds
and sticky CVS tags, all alike.


d.


From david at lichteblau.com  Wed Jan 30 13:08:35 2008
From: david at lichteblau.com (David Lichteblau)
Date: Wed, 30 Jan 2008 14:08:35 +0100
Subject: [mcclim-devel] Re: Building on OpenMCL
In-Reply-To: <87fxwfbhwb.fsf@lambda.athas.dyndns.dk>
References: <20080129211605.GG16179@radon>
	<87lk68cndm.fsf@lambda.athas.dyndns.dk>
	<20080130122932.GA4080@radon>
	<87fxwfbhwb.fsf@lambda.athas.dyndns.dk>
Message-ID: <20080130130835.GJ16179@radon>

Quoting Troels Henriksen (athas at sigkill.dk):
> I got an email from Fred Gilham suggesting that the error is the use
> of the functions that are automatically created by DEFSTRUCT. These
> functions are not guaranteed to be available at compile-time. I
> committed his proposed fix, which was to wrap the defstruct forms in
> eval-when. Does this fix it?

No.

Defining MAKE-LOAD-FORM methods for those defstructs helps fix this
problem, although it ends up requiring even more MAKE-LOAD-FORM methods
on other stuff like %FOREGROUND ink.

Then it fails recompilation because OpenMCL goes all SBCL and complains
that +default-stroke-drawer-dispatcher+ is being redefined to a non-EQL
value.

I'd think the better solution is to take all DEFCONSTANT uses in Drei
and replace them with DEFVAR.


d.


From athas at sigkill.dk  Wed Jan 30 13:19:50 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Wed, 30 Jan 2008 14:19:50 +0100
Subject: [mcclim-devel] Re: Building on OpenMCL
In-Reply-To: <20080130130835.GJ16179@radon> (David Lichteblau's message of
	"Wed, 30 Jan 2008 14:08:35 +0100")
References: <20080129211605.GG16179@radon>
	<87lk68cndm.fsf@lambda.athas.dyndns.dk> <20080130122932.GA4080@radon>
	<87fxwfbhwb.fsf@lambda.athas.dyndns.dk> <20080130130835.GJ16179@radon>
Message-ID: <87abmnbgcp.fsf@lambda.athas.dyndns.dk>

David Lichteblau <david at lichteblau.com> writes:

> Defining MAKE-LOAD-FORM methods for those defstructs helps fix this
> problem, although it ends up requiring even more MAKE-LOAD-FORM methods
> on other stuff like %FOREGROUND ink.

I don't understand this problem at all. Why aren't the
defstruct-defined functions accessible when drawing-options.lisp is
being compiled?

-- 
\  Troels
/\ Henriksen


From athas at sigkill.dk  Wed Jan 30 23:56:14 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 31 Jan 2008 00:56:14 +0100
Subject: [mcclim-devel] McCLIM 2.0 in 2008
In-Reply-To: <87k5maiv06.fsf@lambda.athas.dyndns.dk> (Troels Henriksen's
	message of "Tue, 15 Jan 2008 23:28:25 +0100")
References: <87k5maiv06.fsf@lambda.athas.dyndns.dk>
Message-ID: <873asec1gh.fsf@lambda.athas.dyndns.dk>

Troels Henriksen <athas at sigkill.dk> writes:

>      * First, implement all the reasonable parts of the CLIM 2 spec,
>        with the exception of things that are unimplementable,
>        underspecified or just really hard to do properly (fully
>        generic designs, alpha blending and all, falls in this last
>        category, I think). Things that are underspecified should
>        probably be implemented by looking at later CLIM specs, as well
>        as classic CLIM behaviour. We are already mostly there. Does
>        anyone know exactly what is missing?

I added a page on the McCLIM Wiki -
http://mcclim.cliki.net/Implementation%20Status - listing the
implementation status for the various parts of the spec. If you *know*
that we implement some part of the spec (and you're *really* sure),
please update that page. Alternatively, pick a spec section and
rigorously check that we implement every function, macro and keyword,
or at least have made a conscious decision not to. There used to be an
implementation status list bundled with the older release
announcements, but I know of several errors in them for the spec
sections I'm familiar with, so I'd rather not base this attempt on
them.

-- 
\  Troels
/\ Henriksen


From ahefner at gmail.com  Thu Jan 31 09:04:18 2008
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 31 Jan 2008 04:04:18 -0500
Subject: [mcclim-devel] Fwd: Your message to mcclim-cvs awaits moderator
	approval
In-Reply-To: <mailman.4853.1201769902.10711.mcclim-cvs@common-lisp.net>
References: <mailman.4853.1201769902.10711.mcclim-cvs@common-lisp.net>
Message-ID: <31ffd3c40801310104u54bae6c0y2968f43286d7f39e@mail.gmail.com>

Imagine a batch of commits to freetype here. =/


---------- Forwarded message ----------
From:  <mcclim-cvs-bounces at common-lisp.net>
Date: Jan 31, 2008 3:58 AM
Subject: Your message to mcclim-cvs awaits moderator approval
To: ahefner at common-lisp.net


Your mail to 'mcclim-cvs' with the subject

    CVS mcclim/Experimental/freetype

Is being held until the list moderator can review it for approval.

We're sorry, due to the volume of spam we receive most mailinglists
require you to subscribe before posting.  You may cancel this post (at
the URL below) or waiting for the moderator to approve it. Thanks and
sorry for the inconvenience.


The reason it is being held:

    Message body is too big: 44477 bytes with a limit of 40 KB

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:


From evgeny.zubok at tochka.ru  Thu Jan 31 20:56:09 2008
From: evgeny.zubok at tochka.ru (Evgeny M. Zubok)
Date: Thu, 31 Jan 2008 23:56:09 +0300
Subject: [mcclim-devel] DREI: delete-elements* isn't defined
Message-ID: <871w7xhfyu.fsf@tochka.ru>


The method/function (delete-elements*...) isn't defined but used in
buffer.lisp.

McCLIM is running on CLISP 2.41.



From ch-mcclim at bobobeach.com  Thu Jan 31 22:15:15 2008
From: ch-mcclim at bobobeach.com (Cyrus Harmon)
Date: Thu, 31 Jan 2008 14:15:15 -0800
Subject: [mcclim-devel] DREI: delete-elements* isn't defined
In-Reply-To: <871w7xhfyu.fsf@tochka.ru>
References: <871w7xhfyu.fsf@tochka.ru>
Message-ID: <737609B2-4E4B-4423-9E31-38AF6CC87971@bobobeach.com>

You need to update to the latest flexichain from CVS.

Cyrus

On Jan 31, 2008, at 12:56 PM, Evgeny M. Zubok wrote:

>
> The method/function (delete-elements*...) isn't defined but used in
> buffer.lisp.
>
> McCLIM is running on CLISP 2.41.
>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel