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

[mcclim-devel] freeze period for Trinity Sunday mcclim starts now.
by Andreas Fuchs 06 Jun '06

06 Jun '06

Hi, This mail marks the start of the freeze period for the Trinity Sunday release. Please test things (freetype-cffi comes to mind), and report any bugs that you find. As always, improvements to documentations and fixes for reported bugs are very welcome; I ask you to hold off other commits until after the release on next sunday. Let's make this as good as the last release (: -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

1 0

[mcclim-devel] reminder: freeze period starts tomorrow!
by Andreas Fuchs 06 Jun '06

06 Jun '06

Hi there, just thought it would be good to post a little reminder: if you want to get any patches in before the release next sunday, you should post your patch to this list. The freeze period starts tomorrow evening (CEST), so you have a bit more than 24 hours. Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

2 1

[mcclim-devel] execute-frame-command
by Christophe Rhodes 02 Jun '06

02 Jun '06

Hi, Is (defun foo () (let ((frame (make-application-frame 'climacs))) (clim-sys:make-process (lambda () (run-frame-top-level frame))) (execute-frame-command frame `(com-find-file "/tmp/foo.txt")))) expected to be "safe"? At present, this is subject to a race condition, because the frame need not have been adopted properly by the time the execute-frame-command runs, and so it need not have a top-level sheet. Would it be reasonable to guard against this in the branch of execute-frame-command, and if so, how? There's a symmetric case (which is probably less common) where the frame command is executed just after the top-level sheet is disowned. Any ideas? It would be nice to support something along the lines of my FOO function above -- it seems like a natural expression of a response to user action. Cheers, Christophe

2 1