From ch-mcclim at bobobeach.com Wed May 3 16:53:02 2006 From: ch-mcclim at bobobeach.com (Cyrus Harmon) Date: Wed, 3 May 2006 09:53:02 -0700 Subject: [mcclim-devel] trivial sbcl/osx gtkairo patch Message-ID: <21D20A00-07B0-4A78-89FF-89B7A4FC92A4@bobobeach.com> The following patch allows me to at least launch climacs w/ gtkairo. It doesn't quite work as the Escape key maps to { instead of Escape for some reason, but it looks pretty. Oh, the /opt/local/lib/ is the darwinports lib location. The CFFI guys probably have a better way to do this. Cyrus Index: Backends/gtkairo/gtk-ffi.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/gtkairo/gtk-ffi.lisp,v retrieving revision 1.5 diff -u -r1.5 gtk-ffi.lisp --- Backends/gtkairo/gtk-ffi.lisp 2 May 2006 13:00:12 -0000 1.5 +++ Backends/gtkairo/gtk-ffi.lisp 3 May 2006 16:44:41 -0000 @@ -19,12 +19,19 @@ (in-package :clim-gtkairo) -#-(or win32 mswindows windows) +#-(or win32 mswindows windows darwin) (eval-when (:compile-toplevel :load-toplevel :execute) (cffi:load-foreign-library "libcairo.so") (cffi:load-foreign-library "libgthread-2.0.so") (cffi:load-foreign-library "libgtk-x11-2.0.so")) +#+darwin +(eval-when (:compile-toplevel :load-toplevel :execute) + (pushnew "/opt/local/lib/" cffi:*foreign-library-directories*) + (cffi:load-foreign-library "libcairo.dylib") + (cffi:load-foreign-library "libgthread-2.0.dylib") + (cffi:load-foreign-library "libgtk-x11-2.0.dylib")) + #+(or win32 mswindows windows) (eval-when (:compile-toplevel :load-toplevel :execute) (cffi:load-foreign-library "libcairo-2.dll") From m.retzlaff at gmx.net Wed May 3 17:11:55 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Wed, 3 May 2006 19:11:55 +0200 Subject: [mcclim-devel] mcclim destorys clx on ACL 6.2 Message-ID: <20060503171155.GA28908@mgr.home> Hi, I've just updated my McCLIM to the lastest CVS version. When I now load McClim into the generic ACL 6.2 image even a simple CLX demo like XLIB::JUST-SAY-LISP doesn't work anymore. (Before the loading of McClim it does). Sadly, my last previous cvs update on this particular machine seems to be as long as five month ago, so it is probably a bit hard to find the particular commit to the CVS.. Are they any other ACL 6.2 users who use CVS McCLIM and who have noticed this problem? Bye, Max -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: Old age and treachery will overcome youth and skill. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rpgoldman at real-time.com Wed May 3 19:18:19 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 3 May 2006 14:18:19 -0500 Subject: [mcclim-devel] mcclim destorys clx on ACL 6.2 In-Reply-To: <20060503171155.GA28908@mgr.home> References: <20060503171155.GA28908@mgr.home> Message-ID: <17497.507.499111.259382@necronomicon.sift.info> >>>>> "Max-Gerd" == Max-Gerd Retzlaff writes: Max-Gerd> Hi, I've just updated my McCLIM to the lastest CVS Max-Gerd> version. When I now load McClim into the generic ACL 6.2 Max-Gerd> image even a simple CLX demo like XLIB::JUST-SAY-LISP Max-Gerd> doesn't work anymore. (Before the loading of McClim it Max-Gerd> does). Max-Gerd> Sadly, my last previous cvs update on this particular Max-Gerd> machine seems to be as long as five month ago, so it is Max-Gerd> probably a bit hard to find the particular commit to the Max-Gerd> CVS.. Max-Gerd> Are they any other ACL 6.2 users who use CVS McCLIM and Max-Gerd> who have noticed this problem? I have moved from ACL 6.2 onto 7.0 and thence to 8. I use CVS McCLIM (but pretty much only for beirc at present). It works fine for me on these more recent ACLs. What symptoms are you having? Best, Robert From m.retzlaff at gmx.net Thu May 4 00:51:07 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 4 May 2006 02:51:07 +0200 Subject: [mcclim-devel] mcclim destorys clx on ACL 6.2 In-Reply-To: <17497.507.499111.259382@necronomicon.sift.info> References: <20060503171155.GA28908@mgr.home> <17497.507.499111.259382@necronomicon.sift.info> Message-ID: <20060504005106.GA31688@mgr.home> Hi On Wed, May 03, 2006 at 02:18:19PM -0500, rpgoldman at real-time.com wrote: > I have moved from ACL 6.2 onto 7.0 and thence to 8. I use CVS McCLIM > (but pretty much only for beirc at present). It works fine for me on > these more recent ACLs. What symptoms are you having? As I have said: When I now load McClim into the generic ACL 6.2 image even a simple CLX demo like XLIB::JUST-SAY-LISP doesn't work anymore. (Before the loading of McClim it does). Bye, Max -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: Linux is obsolete -- Andrew Tanenbaum -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikemac at mikemac.com Thu May 4 03:34:06 2006 From: mikemac at mikemac.com (Mike McDonald) Date: Wed, 03 May 2006 20:34:06 -0700 Subject: [mcclim-devel] mcclim destorys clx on ACL 6.2 In-Reply-To: Your message of "Thu, 04 May 2006 02:51:07 +0200." <20060504005106.GA31688@mgr.home> Message-ID: <200605040334.k443Y6A06092@saturn.mikemac.com> >To: rpgoldman at real-time.com, >To: mcclim-devel at common-lisp.net >Date: Thu, 4 May 2006 02:51:07 +0200 >From: Max-Gerd Retzlaff >As I have said: > >When I now load McClim into the generic ACL 6.2 image even a simple >CLX demo like XLIB::JUST-SAY-LISP doesn't work anymore. (Before the >loading of McClim it does). > >Bye, >Max "Doesn't work" is NOT a very helpful discription! Any error messages? Dumps core? Returns to the prompt without doing anything? Mike McDonald mikemac at mikemac.com From m.retzlaff at gmx.net Thu May 4 09:49:34 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 4 May 2006 11:49:34 +0200 Subject: [mcclim-devel] mcclim destorys clx on ACL 6.2 In-Reply-To: <200605040334.k443Y6A06092@saturn.mikemac.com> References: <20060504005106.GA31688@mgr.home> <200605040334.k443Y6A06092@saturn.mikemac.com> Message-ID: <20060504094934.GA2485@mgr.home> Hello, On Wed, May 03, 2006 at 08:34:06PM -0700, Mike McDonald wrote: > "Doesn't work" is NOT a very helpful discription! Any error > messages? Dumps core? Returns to the prompt without doing anything? Ah, yes, of course. There are no error messages. If I call (xlib::just-say-lisp "") the CLX window is just not displayed. The repl waits as if the application worked as wanted, and after I aborted it I can still use the image. Of course, the same behaviour holds for the mcclim applications: Their window just don't get drawn. I only mention the more simple CLX demo as it works before I load McCLIM (with (asdf:oos 'asdf:load-op :mcclim)), and afterwards it does not. I use the CLX that comes with ACL 6.2. (And this worked until I updated mcclim on yesterday; older lisp images with mcclim still work as desired.) Sorry for my repetition of the not helpful "doesn't work". Bye, Max -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: I give you the man who -- the man who -- uh, I forgets the man who? -- Beauregard Bugleboy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.retzlaff at gmx.net Thu May 4 22:37:54 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 5 May 2006 00:37:54 +0200 Subject: [mcclim-devel] mcclim destorys clx on ACL 6.2 In-Reply-To: <20060504094934.GA2485@mgr.home> References: <20060504005106.GA31688@mgr.home> <200605040334.k443Y6A06092@saturn.mikemac.com> <20060504094934.GA2485@mgr.home> Message-ID: <20060504223754.GA7190@mgr.home> Hello, after having checked out, built and tested cvs mcclim of two months, one months, 45 days, 37 days, and 41 days ago I've found the commit that has caused my CLX breakage: "Fix (temporary hack) to use file sockets in CLX on ACL": http://article.gmane.org/gmane.lisp.mcclim.cvs/418 The comment in this patch says: +;;; XXX CLX in ACL doesn't use local sockets, so here's a fix. This is gross +;;; and should obviously be included in Franz' clx and portable clx, but I +;;; believe that enough users will find that their X servers don't listen for +;;; TCP connections that it is worthwhile to include this code here +;;; temporarily. Of course, it would be nice to not require the X server to run without "--nolisten tcp" but this patch breaks the whole CLX (not only for mcclim) on my system. The function is obviously taken from Franz' version of clx (or both have a common ancestor) and then an if-construct is added that will, under certain circumstances, connect to the X server via the FILE menthod instead of the usual TCP connection. But in the version in acl/contrib/clx/dependent.cl this function is prefixed by an #+(and excl clx-use-allegro-streams) while clx-use-allegro-streams is pushed on the *features* in the Makefile of clx *only on mswindows*. If there is no clx-use-allegro-streams a variant of the function will be taken that uses a file descriptor (see ftp://ftp.franz.com/pub/contrib/clx/dependent.cl). As the new version in mcclim/Backends/CLX/port.lisp is only prefixed by #+allegro it will also replace the latter function, and that is not very nice as the described problems occur. Btw. the "fix" will also not work on mswindows if host is either string= to "" or "unix" as Franz's documentation to make-socket says: "The value of the address-family keyword can't be :file on Windows because Windows does not support it." (See http://www.franz.com/support/documentation/6.2/doc/pages/operators/socket/make-socket.htm or http://www.franz.com/support/documentation/8.0/doc/operators/socket/make-socket.htm) In general it is also all but nice that a function of the package xlib will be changed in the mcclim backend via a (defun xlib::open-x-stream ...). Because of these problems I propose to remove the patch from the mcclim cvs repository again. It would be nice to not require an X server that listens for TCP connections but this code is too buggy and mcclim/Backends/CLX/port.lisp is just not the right place for such an hack. What do you think? Bye, Max -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: In the Spring, I have counted 136 different kinds of weather inside of 24 hours. -- Mark Twain, on New England weather -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikemac at mikemac.com Fri May 5 02:38:49 2006 From: mikemac at mikemac.com (Mike McDonald) Date: Thu, 04 May 2006 19:38:49 -0700 Subject: [mcclim-devel] mcclim destorys clx on ACL 6.2 In-Reply-To: Your message of "Fri, 05 May 2006 00:37:54 +0200." <20060504223754.GA7190@mgr.home> Message-ID: <200605050238.k452cnA08677@saturn.mikemac.com> >To: mcclim-devel at common-lisp.net >Date: Fri, 5 May 2006 00:37:54 +0200 >From: Max-Gerd Retzlaff > > >--===============1053115938== >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" >Content-Disposition: inline > > >--rwEMma7ioTxnRzrJ >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >Hello, > >after having checked out, built and tested cvs mcclim of two months, >one months, 45 days, 37 days, and 41 days ago I've found the commit >that has caused my CLX breakage: "Fix (temporary hack) to use file >sockets in CLX on ACL": http://article.gmane.org/gmane.lisp.mcclim.cvs/418 > >The comment in this patch says: > >+;;; XXX CLX in ACL doesn't use local sockets, so here's a fix. This is gro= >ss >+;;; and should obviously be included in Franz' clx and portable clx, but I >+;;; believe that enough users will find that their X servers don't listen = >for >+;;; TCP connections that it is worthwhile to include this code here >+;;; temporarily. > >Of course, it would be nice to not require the X server to run without >"--nolisten tcp" but this patch breaks the whole CLX (not only for >mcclim) on my system. No, it'd be really nice if psuedo security weenies wouldn't break the standard X configuration!! (Can you tell I have an opinion on this subject?) >Because of these problems I propose to remove the patch from the >mcclim cvs repository again. It would be nice to not require an X >server that listens for TCP connections but this code is too buggy and >mcclim/Backends/CLX/port.lisp is just not the right place for such an >hack. > >What do you think? Remove it!!! Mike McDonald mikemac at mikemac.com From m.retzlaff at gmx.net Fri May 5 08:24:06 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 5 May 2006 10:24:06 +0200 Subject: [mcclim-devel] mcclim destorys clx on ACL 6.2 In-Reply-To: <200605050238.k452cnA08677@saturn.mikemac.com> References: <20060504223754.GA7190@mgr.home> <200605050238.k452cnA08677@saturn.mikemac.com> Message-ID: <20060505082406.GA10734@mgr.home> Hello On Thu, May 04, 2006 at 07:38:49PM -0700, Mike McDonald wrote: > >Of course, it would be nice to not require the X server to run without > >"--nolisten tcp" but this patch breaks the whole CLX (not only for > >mcclim) on my system. > > No, it'd be really nice if psuedo security weenies wouldn't break > the standard X configuration!! (Can you tell I have an opinion on this > subject?) Yes, of course. On every machine I use I have configured (or let configure) X to listen on TCP connection, as I do not only need it for mcclim but in general. It really gets on my nerves that I have to give reasons for the change to each administrator again. Unfortunately, and stupidily, the default for most distributions seems to be "--nolisten tcp" these days. That's the reason why I've said not to require it would be nice; that doesn't mean that I like the decision to use this as the default setting (in the name of an alleged higher security). (If they are so desperate to want to disable "remote X access"[1] they should bind X to localhost / the loopback device but not disable listening for TCP connections in general.) Bye, Max 1) See for example: http://www.debianhelp.co.uk/security.htm http://www.us.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s5.4 -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: Real Programmers don't write in PL/I. PL/I is for programmers who can't decide whether to write in COBOL or FORTRAN. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From moore at bricoworks.com Fri May 5 08:54:58 2006 From: moore at bricoworks.com (Timothy Moore) Date: Fri, 05 May 2006 10:54:58 +0200 Subject: [mcclim-devel] mcclim destorys clx on ACL 6.2 In-Reply-To: <20060505082406.GA10734@mgr.home> References: <20060504223754.GA7190@mgr.home> <200605050238.k452cnA08677@saturn.mikemac.com> <20060505082406.GA10734@mgr.home> Message-ID: <445B12E2.7070608@bricoworks.com> Max-Gerd Retzlaff wrote: > Hello > > On Thu, May 04, 2006 at 07:38:49PM -0700, Mike McDonald wrote: >>> Of course, it would be nice to not require the X server to run without >>> "--nolisten tcp" but this patch breaks the whole CLX (not only for >>> mcclim) on my system. >> No, it'd be really nice if psuedo security weenies wouldn't break >> the standard X configuration!! (Can you tell I have an opinion on this >> subject?) I was pretty upset to discover this behavior, which is why I wrote the patch that is breaking ACL 6.2. I've submitted the patch to Franz, but until it is integrated into their CLX I'd like to keep it in McCLIM. It is the User-Friendly(tm) thing to do. I'll fix up the read-time conditional so that it doesn't break old versions of ACL and on Windows. Tim From david at lichteblau.com Sun May 7 14:44:06 2006 From: david at lichteblau.com (David Lichteblau) Date: Sun, 7 May 2006 16:44:06 +0200 Subject: [mcclim-devel] trivial sbcl/osx gtkairo patch In-Reply-To: <21D20A00-07B0-4A78-89FF-89B7A4FC92A4@bobobeach.com> References: <21D20A00-07B0-4A78-89FF-89B7A4FC92A4@bobobeach.com> Message-ID: <20060507144406.GA9475@gargravarr.knowledgetools.de> Quoting Cyrus Harmon (ch-mcclim at bobobeach.com): > The following patch allows me to at least launch climacs w/ gtkairo. Thank you, checked in (with LET instead of PUSH). > It doesn't quite work as the Escape key maps to { instead of Escape > for some reason, but it looks pretty. Hmm. You reported on IRC that returning #\escape instead of #\{ did not really help. What I have checked in now returns NIL. The key event looks like what CLIM-CLX on SBCL does for me. If it still does not work for you, can you provide more details on what you tried? d. From csr21 at cam.ac.uk Thu May 11 15:09:06 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 11 May 2006 16:09:06 +0100 Subject: [mcclim-devel] scrollbars and :command-loop Message-ID: Hi, I have an application pane with :display-time :command-loop, inside a (scrolling ...) form. For the most part, in this application, it is likely that the contents of this pane after a redisplay are similar to those before: so, I would like to be able to preserve the viewport position across redisplays. I've come up with the following method on redisplay-frame-pane: (defmethod redisplay-frame-pane :around ((frame gsharp) (pane gsharp-pane) &key force-p) (declare (ignore force-p)) (let ((transformation (sheet-transformation pane))) (multiple-value-bind (x y) (window-viewport-position pane) (multiple-value-bind (x1 y1) (untransform-position transformation x y) (call-next-method) (setf (window-viewport-position pane) (values x1 y1)))))) which meets the spec, I suppose -- I don't know how well-defined it is, but it does what I wanted it to in McCLIM. However, it leads to visual artifacts: the call-next-method here eventually calls (window-clear), which resets the space-requirements and the transformation of the sheet, which means the scrollbars change size; then the whole of the redraw takes place, and only then does the viewport's position get reset. My question then is twofold. Firstly, is this a sensible thing to be doing at all, or is there some other mechanism for achieving what I want here? (Incremental redisplay might be it, but that has some other problems in this application). Secondly, is there a way of eliminating these glitches? Cheers, Christophe From ahefner at gmail.com Thu May 11 23:32:38 2006 From: ahefner at gmail.com (Andy Hefner) Date: Thu, 11 May 2006 19:32:38 -0400 Subject: [mcclim-devel] scrollbars and :command-loop In-Reply-To: References: Message-ID: <31ffd3c40605111632t76bb705dofacfc045926f2a56@mail.gmail.com> I struggled with this a while ago and concluded that incremental redisplay is probably the intended solution. From csr21 at cam.ac.uk Fri May 12 09:54:03 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 12 May 2006 10:54:03 +0100 Subject: [mcclim-devel] trac? (other plans?) Message-ID: Hi, Common-lisp.net relatively newly supports trac. Should we take advantage of it for a bug tracker? I suppose we should listen to Paolo in particular, who has heroically been wrestling with his bug list on McCLiki -- Paolo, do you think trac would make that part of it easier? Also, I've heard (and encouraged) mutterings from our intrepid Release Manager about a Pentecost Sunday McCLIM release (that's June 4th this year). Does anyone have half-baked work that they'd like to integrate? (Not that we would necessarily need to to have a nice set of release notes: an even partly-working gtk backend might encourage some interest...) Cheers, Christophe From csr21 at cam.ac.uk Fri May 12 16:58:57 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 12 May 2006 17:58:57 +0100 Subject: [mcclim-devel] scrollbars and :command-loop In-Reply-To: <31ffd3c40605111632t76bb705dofacfc045926f2a56@mail.gmail.com> (Andy Hefner's message of "Thu, 11 May 2006 19:32:38 -0400") References: <31ffd3c40605111632t76bb705dofacfc045926f2a56@mail.gmail.com> Message-ID: [added gsharp-devel, since that's where this patch would end up...] "Andy Hefner" writes: > I struggled with this a while ago and concluded that incremental > redisplay is probably the intended solution. While Andy said this in this forum, he did provide a hint in another... on IRC, he said Xof: have you considered solving your scrolling problem by setting :display-time nil and calling your display function yourself from the top-level loop and using (clear-output-record (stream-output-history foo)) rather than window-clear? And so I tried it, and the attached patch is the result. I don't know if it's climily correct, and it might suffer a bit from suboptimality when loading in new files, but apart from that it does what I think I want it to. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scrolling.diff URL: -------------- next part -------------- So this patch does two things: one, after doing what drawing to the score pane needs to be done, the :height space requirement is changed to whatever it needs to be; two, window-clear calls are intercepted and implemented following Andy's suggestion. Comments? Cheers, Christophe From amoroso at mclink.it Fri May 12 19:48:53 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 12 May 2006 21:48:53 +0200 Subject: [mcclim-devel] trac? (other plans?) In-Reply-To: (Christophe Rhodes's message of "Fri, 12 May 2006 10:54:03 +0100") References: Message-ID: <87ejyzrplm.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > Common-lisp.net relatively newly supports trac. Should we take > advantage of it for a bug tracker? I suppose we should listen to > Paolo in particular, who has heroically been wrestling with his bug > list on McCLiki -- Paolo, do you think trac would make that part of it > easier? I inadvertently sent my reply only to Christophe: any bug tracking tool the McCLIM developers decide to use is fine with me. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From eric.marsden at free.fr Sat May 13 14:32:46 2006 From: eric.marsden at free.fr (Eric Marsden) Date: Sat, 13 May 2006 16:32:46 +0200 Subject: [mcclim-devel] trivial patch to OpenMCL support Message-ID: <87ac9m3shd.fsf@free.fr> Hi, The following trivial patch is required for recent versions of OpenMCL, that have dropped the :mcl *feature*. Index: package.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/package.lisp,v retrieving revision 1.54 diff -u -r1.54 package.lisp --- package.lisp 30 Mar 2006 12:07:59 -0000 1.54 +++ package.lisp 13 May 2006 14:23:46 -0000 @@ -220,7 +220,7 @@ `(#+clisp ,@'(:gray) #+cmu ,@'(:ext) #+scl ,@'(:ext) - #+mcl ,@'(:ccl) + #+(or mcl openmcl) ,@'(:ccl) #+allegro ,@'(:common-lisp :excl :stream) #+harlequin-common-lisp ,@'(:stream) #+sbcl ,@'(:sb-gray))) ) -- Eric Marsden From rpgoldman at real-time.com Mon May 15 16:18:05 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Mon, 15 May 2006 11:18:05 -0500 Subject: [mcclim-devel] McCLIM hint on Paolo's cliki Message-ID: <17512.43453.293372.603014@necronomicon.sift.info> Paolo's cliki has the following McCLIM hint: ---------------------------------------------------------------------- Order of suggestions in completion menus If you pass to complete-from-possibilities a list of suggestions such as '(("First" 1) ("Second" 2) ("Third)), they are displayed in reverse order from top to bottom in completion menus, like this: Third Second First If this is not what you want, pass a list sorted in the opposite order. ---------------------------------------------------------------------- At the expense of causing some minor dislocation, isn't this something we should fix, instead of hacking around? Also, is this a place where the clim specification is deficient? I.e., does it underspecify the behavior? Should it tell us how a list of possibilities will be displayed by default (in absence of specific function arguments)? Thanks, R From idurand at labri.fr Thu May 18 12:51:07 2006 From: idurand at labri.fr (Irene DURAND) Date: Thu, 18 May 2006 14:51:07 +0200 Subject: [mcclim-devel] error in transform-region Message-ID: <446C6DBB.8050400@labri.fr> Hello, I had not updated my mcclim since April 7. I did it today and my software Autowrite doesn't execute anymore. The stack is as below. Has anyone any idea of what can be wrong? Thanks, Ir?ne ---------------------------------------------------------------------------------------------------------------------------------------- The value NIL is not of type (SIMPLE-ARRAY REAL (4)). [Condition of type TYPE-ERROR] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: ((SB-PCL::FAST-METHOD TRANSFORM-REGION (T STANDARD-RECTANGLE)) (#(NIL 0) . #()) # # (#)) 1: (CLIM-INTERNALS::UPDATE-MIRROR-GEOMETRY #) 2: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) # # # #) 3: ((SB-PCL::FAST-METHOD ALLOCATE-SPACE :AROUND (CLIM-INTERNALS::LAYOUT-PROTOCOL-MIXIN T T)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (3)) :ARG-INFO (3)) # 634 150) 4: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) # # 634 550) 5: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/HORIZONTALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 31) . #()) # # 634 550) 6: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) # # 634 550) 7: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/HORIZONTALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 31) . #()) # # 1071 550) 8: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) # # 1071 602) 9: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::RACK-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) # # 1071 606) 10: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2.)) # # # 1071 606) 11: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) # # # #) 12: ((SB-PCL::FAST-METHOD ADOPT-FRAME (FRAME-MANAGER APPLICATION-FRAME)) (#(NIL 1 13 11) . #()) # # #) 13: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) # # # #) 14: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL :AROUND (APPLICATION-FRAME)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # NIL) 15: (INTERFACE) 16: (SB-INT:EVAL-IN-LEXENV (START) #) 17: (SWANK::EVAL-REGION "(start) " T) 18: ((LAMBDA NIL)) 19: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) # # #) 20: (SWANK::CALL-WITH-BUFFER-SYNTAX #) 21: (SB-INT:EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(start) ") #) 22: ((LAMBDA NIL)) 23: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # # # #) 24: ((LAMBDA NIL)) 25: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # # # #) 26: (SWANK::CALL-WITH-REDIRECTED-IO # #) 27: (SWANK::CALL-WITH-CONNECTION # #) 28: (SWANK::HANDLE-REQUEST #) 29: ((LAMBDA NIL)) 30: ((LAMBDA NIL)) 31: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) # # # #) 32: (SWANK::CALL-WITH-REDIRECTED-IO # #) 33: (SWANK::CALL-WITH-CONNECTION # #) 34: (SWANK::CALL-WITH-BINDINGS NIL #) 35: ((LAMBDA NIL)) 36: ("foreign function: call_into_lisp") 37: ("foreign function: funcall0") 38: ("foreign function: new_thread_trampoline") 39: ("foreign function: #x53EB80") -- Ir?ne DURAND http://dept-info.labri.u-bordeaux.fr/~idurand From hocwp at free.fr Sat May 20 21:02:13 2006 From: hocwp at free.fr (Philippe Brochard) Date: Sat, 20 May 2006 23:02:13 +0200 Subject: [mcclim-devel] McCLIM, clisp and minor bug fixes on Win32. Message-ID: <87sln4fm0a.fsf@grigri.elcforest> Hi everybody, First of all, many thanks for your great work! I don't know if this has already been reported and as I read wrongs things about it, I just want to say that McCLIM works perfectly with CLisp [1] under Windows XP (at least) and Xming [2]. I just have to patch Goatee/goatee-command.lisp to have a working Delete key. (patch attached on this mail). Here is what I've done: 1) Install CLisp and Xming. 2) Set the display (in a terminal) $ set display=localhost:0.0 3) Compile clx (I got the source in the clisp source): CLISP> (load "/clisp/source/clx/mit-clx/defsystem.lisp") CLISP> (without-package-lock () (compile-clx)) CLISP> (without-package-lock () (load-clx)) ; not necessarily useful 4) Get a copy of McCLIM and spatial-trees CLISP> (load "mcclim/spatial-trees/spatial-trees.asd") CLISP> (load "mcclim/mcclim.asd") CLISP> (without-package-lock () (asdf:oos 'asdf:load-op :mcclim)) 5) Build the listener CLISP> (asdf:oos 'asdf:load-op :clim-listener) 6) And build a demo CLISP> (load (compile-file "mcclim/Examples/clim-fig.lisp")) CLISP> (clim-demo::clim-fig) and here is the result : http://hocwp.free.fr/temp/clim-fig.png I've also been able to build my main app (cl-wav-synth) and it works like a charm :) http://hocwp.free.fr/temp/cl-wav-synth-win.png http://hocwp.free.fr/temp/cl-wav-synth-win-2.png Hope that can help. Best regards, Philippe [1] http://clisp.cons.org [2] http://freedesktop.org/wiki/Xming -- Philippe Brochard http://hocwp.free.fr -=-= http://www.gnu.org/home.fr.html =-=- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: goatee-command.lisp.diff URL: From gilham at csl.sri.com Tue May 23 01:14:31 2006 From: gilham at csl.sri.com (Fred Gilham) Date: Mon, 22 May 2006 18:14:31 -0700 Subject: [mcclim-devel] Problem with McCLIM Message-ID: <48480.1148346871@snapdragon.csl.sri.com> Using a freshly updated version of McCLIM under CMUCL 19C and FreeBSD I get the following: * (require :clim-examples) Warning: Silly argument for a unix PATHNAME-NAME: "Goatee/presentation-history" Warning: Silly argument for a unix PATHNAME-NAME: "Goatee/presentation-history" Warning: Silly argument for a unix PATHNAME-NAME: "Looks/pixie" Warning: Silly argument for a unix PATHNAME-NAME: "Looks/pixie" Warning: Silly argument for a unix PATHNAME-NAME: "Goatee/presentation-history" Warning: Silly argument for a unix PATHNAME-NAME: "Looks/pixie" ; Loading #P"/usr/local/share/lisp/asdf-packages/spatial-trees-0.1/spatial-tree-viz.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/calculator.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/colorslider.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/menutest.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/address-book.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/traffic-lights.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/clim-fig.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/postscript-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/puzzle.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/transformations-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/demodemo.x86f". ;; try (CLIM-DEMO::DEMODEMO) ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/stream-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/presentation-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/dragndrop.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/gadget-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/accepting-values.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/method-browser.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/dragndrop-translator.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/draggable-graph.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/text-size-test.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Examples/drawing-benchmark.x86f". ; Loading #P"/usr/local/lib/cmucl/mcclim/Goatee/goatee-test.x86f". NIL * (clim-demo::demodemo) (now I click on the "Address Book" button) Error in function KERNEL:CLASS-TYPEP: Class is currently invalid: # [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT ] Return to application command loop 1: Return to application command loop 2: Return to Top-Level. 3: [DESTROY] Destroy the process Debug (type H for help) Here is some of the backtrace: 0: (KERNEL:CLASS-TYPEP # # #) 1: (CLIM-INTERNALS::FIND-OUTPUT-RECORD-SHEET #) 2: ((METHOD CLIM:ADD-OUTPUT-RECORD (:AFTER) (T CLIM-INTERNALS::COMPOUND-OUTPUT-RECORD)) # # # #) 3: ("LAMBDA (G3106 G3107 G3108)" # # # #) 4: ("LAMBDA (G8342 G8343 G8344)" # # #) 5: (FINISH-OUTPUT #) 6: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL (CLIM:OUTPUT-RECORDING-STREAM T T T)) (#() . #(#)) # # # ...) 7: ((METHOD CLIM:STREAM-PRESENT NIL (CLIM:OUTPUT-RECORDING-STREAM T T)) (#() . #(#)) # # # ...) 8: ((FLET #:UPDATING-OUTPUT-CONTINUATION37 ) #) 9: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL (CLIM:OUTPUT-RECORDING-STREAM T T T)) (#() . #(#)) # # # ...) 10: (CLIM-INTERNALS::%INVOKE-UPDATING # {48105185}> # #) -- Fred Gilham gilham at csl.sri.com Behold, how good and pleasant it is when brothers dwell in unity. It is like the precious oil upon the head, running down upon the beard, upon the beard of Aaron, running down on the collar of his robes. It is like the dew of Hermon, which falls on the mountains of Zion. For there the LORD has commanded the blessing, life for evermore. -Ps 133 From rpgoldman at real-time.com Tue May 23 05:50:05 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 23 May 2006 00:50:05 -0500 Subject: [mcclim-devel] making freetype more portable Message-ID: <17522.41613.856547.811785@necronomicon.sift.info> Does anyone have any suggestions about how one might go about making mcclim-freetype portable to other lisps? Seems like right now it's only usable for cmucl and sbcl. I was thinking about either trying to translate the definer macros to acl ffi or, in the hopes of broader portability, to CFFI. But it seems like the defining sublanguage for CMUCL & SBCL is fairly different from CFFI. CFFI-grovel seemed like another alternative. Any suggestions? thanks, R From csr21 at cam.ac.uk Tue May 23 07:16:35 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 23 May 2006 08:16:35 +0100 Subject: [mcclim-devel] Problem with McCLIM In-Reply-To: <48480.1148346871@snapdragon.csl.sri.com> (Fred Gilham's message of "Mon, 22 May 2006 18:14:31 -0700") References: <48480.1148346871@snapdragon.csl.sri.com> Message-ID: Fred Gilham writes: > Using a freshly updated version of McCLIM under CMUCL 19C and FreeBSD I > get the following: > > * (require :clim-examples) > Warning: Silly argument for a unix PATHNAME-NAME: "Goatee/presentation-history" > Warning: Silly argument for a unix PATHNAME-NAME: "Goatee/presentation-history" > Warning: Silly argument for a unix PATHNAME-NAME: "Looks/pixie" > Warning: Silly argument for a unix PATHNAME-NAME: "Looks/pixie" > Warning: Silly argument for a unix PATHNAME-NAME: "Goatee/presentation-history" > Warning: Silly argument for a unix PATHNAME-NAME: "Looks/pixie" These are fixed in a newer version of asdf, but are harmless in any case. > * (clim-demo::demodemo) > > (now I click on the "Address Book" button) > > Error in function KERNEL:CLASS-TYPEP: > Class is currently invalid: # CLIM-INTERNALS::BASIC-OUTPUT-RECORD {29269CB5}> > [Condition of type SIMPLE-ERROR] Unless you have reason to believe otherwise, I think this is a bug in CMUCL. (It's possible to work around bugs in CMUCL, of course, but it would be much better for all concerned to fix the actual bug.) Cheers, Christophe From csr21 at cam.ac.uk Tue May 23 07:20:29 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 23 May 2006 08:20:29 +0100 Subject: [mcclim-devel] making freetype more portable In-Reply-To: <17522.41613.856547.811785@necronomicon.sift.info> (rpgoldman@real-time.com's message of "Tue, 23 May 2006 00:50:05 -0500") References: <17522.41613.856547.811785@necronomicon.sift.info> Message-ID: rpgoldman at real-time.com writes: > Does anyone have any suggestions about how one might go about making > mcclim-freetype portable to other lisps? Seems like right now it's > only usable for cmucl and sbcl. > > I was thinking about either trying to translate the definer macros to > acl ffi or, in the hopes of broader portability, to CFFI. But it > seems like the defining sublanguage for CMUCL & SBCL is fairly > different from CFFI. > > CFFI-grovel seemed like another alternative. > > Any suggestions? I'd suggest not bothering, and spending the time improving the gtkairo backend instead: you get antialiased graphics as well as antialiased text that way. Cheers, Christophe From david at lichteblau.com Tue May 23 12:22:04 2006 From: david at lichteblau.com (David Lichteblau) Date: Tue, 23 May 2006 14:22:04 +0200 Subject: [mcclim-devel] making freetype more portable In-Reply-To: References: <17522.41613.856547.811785@necronomicon.sift.info> Message-ID: <20060523122204.GA21931@gargravarr.knowledgetools.de> Quoting Christophe Rhodes (csr21 at cam.ac.uk): > > I was thinking about either trying to translate the definer macros to > > acl ffi or, in the hopes of broader portability, to CFFI. But it > > seems like the defining sublanguage for CMUCL & SBCL is fairly > > different from CFFI. Translating from alien to cffi is rather easy. It worked well for me with clim-cairo. It is mostly a matter of search&replace. > I'd suggest not bothering, and spending the time improving the gtkairo > backend instead: you get antialiased graphics as well as antialiased > text that way. There might be code and ideas to steal from clim-freetype for gtkairo's benefit. (Warning, I have not actually investigated any of of following issues in detail, but here is my current impression:) If I understand correctly, clim-freetype handles two problems: Selecting fonts through freetype. And actually drawing text. Cairo has its own drawing functions, in two varieties: A "toy API" for text, which gtkairo is currently using. In addition, there is a much more nifty glyph-based API which probably has many advantages, although I am unclear about what those are. If we wanted to do glyph-based drawing, clim-freetype might be a good inspiration for that code. As for selecting fonts, cairo itself gives little control over that, but instead applications can look up fonts through either freetype or Windows APIs and use those with cairo. It would be nice to translate the clim-freetype code for font selection from alien to cffi and adapt it for gtkairo. gtkairo on Windows currently finds only sans-serif fonts. Not sure whether GTK+ on Windows supports freetype fonts or not, but probably either freetype or Windows functions will solve that bug. So it may turn out that a freetypification of gtkairo on Unix happens to fix the Windows problem, too. Finally, if any of you have clim-freetype up and running on SBCL or CMUCL, can you do an experiment for me? Gtkairo's font drawing is currently relatively slow compared to CLX. What I do not know is how it compares to clim-freetype. Could you perhaps benchmark CLX+Freetype for me? You don't need gtkairo for that. Just run clim-demodemo, select the drawing benchmark and run it with the text drawing option. The interesting bit would be to compare the resulting score between CLX with freetype and without. Thanks, David From csr21 at cam.ac.uk Tue May 23 13:15:23 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 23 May 2006 14:15:23 +0100 Subject: [mcclim-devel] making freetype more portable In-Reply-To: <20060523122204.GA21931@gargravarr.knowledgetools.de> (David Lichteblau's message of "Tue, 23 May 2006 14:22:04 +0200") References: <17522.41613.856547.811785@necronomicon.sift.info> <20060523122204.GA21931@gargravarr.knowledgetools.de> Message-ID: David Lichteblau writes: > Finally, if any of you have clim-freetype up and running on SBCL or > CMUCL, can you do an experiment for me? Gtkairo's font drawing is > currently relatively slow compared to CLX. What I do not know is how it > compares to clim-freetype. > > Could you perhaps benchmark CLX+Freetype for me? You don't need gtkairo > for that. Just run clim-demodemo, select the drawing benchmark and run > it with the text drawing option. The interesting bit would be to > compare the resulting score between CLX with freetype and without. Haha. On my x86-64 workstation: CLX: ~ 1000 +/- 30 operations/s CLX+Freetype ~ 50 +/- 2 operations/s Cheers, Christophe From rpgoldman at real-time.com Tue May 23 14:07:36 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 23 May 2006 09:07:36 -0500 Subject: [mcclim-devel] making freetype more portable In-Reply-To: <20060523122204.GA21931@gargravarr.knowledgetools.de> References: <17522.41613.856547.811785@necronomicon.sift.info> <20060523122204.GA21931@gargravarr.knowledgetools.de> Message-ID: <17523.5928.246174.919999@necronomicon.sift.info> >>>>> "DL" == David Lichteblau writes: DL> Quoting Christophe Rhodes (csr21 at cam.ac.uk): >> > I was thinking about either trying to translate the definer >> > macros to acl ffi or, in the hopes of broader portability, to >> > CFFI. But it seems like the defining sublanguage for CMUCL & >> > SBCL is fairly different from CFFI. DL> Translating from alien to cffi is rather easy. It worked well DL> for me with clim-cairo. It is mostly a matter of DL> search&replace. The reason I was worried about doing this was that the file I would search and replace in clearly states that it is auto-generated (sbcl groveler?) and should not be manually edited... I should, of course, have mentioned this in my original email. I take it from the above that I should just ignore that warning and dive in... thanks, R From david at lichteblau.com Tue May 23 14:12:52 2006 From: david at lichteblau.com (David Lichteblau) Date: Tue, 23 May 2006 16:12:52 +0200 Subject: [mcclim-devel] making freetype more portable In-Reply-To: <17523.5928.246174.919999@necronomicon.sift.info> References: <17522.41613.856547.811785@necronomicon.sift.info> <20060523122204.GA21931@gargravarr.knowledgetools.de> <17523.5928.246174.919999@necronomicon.sift.info> Message-ID: <20060523141252.GA24009@gargravarr.knowledgetools.de> Quoting rpgoldman at real-time.com (rpgoldman at real-time.com): > The reason I was worried about doing this was that the file I would > search and replace in clearly states that it is auto-generated (sbcl > groveler?) and should not be manually edited... ;;; automatically generated, hand tweaked, do not regenerate. I read that the other way around. :-) d. From rpgoldman at sift.info Tue May 23 14:20:28 2006 From: rpgoldman at sift.info (Robert P. Goldman) Date: Tue, 23 May 2006 09:20:28 -0500 Subject: [mcclim-devel] making freetype more portable In-Reply-To: <20060523141252.GA24009@gargravarr.knowledgetools.de> References: <17522.41613.856547.811785@necronomicon.sift.info> <20060523122204.GA21931@gargravarr.knowledgetools.de> <17523.5928.246174.919999@necronomicon.sift.info> <20060523141252.GA24009@gargravarr.knowledgetools.de> Message-ID: <17523.6700.270059.430288@necronomicon.sift.info> >>>>> "DL" == David Lichteblau writes: DL> Quoting rpgoldman at real-time.com (rpgoldman at real-time.com): >> The reason I was worried about doing this was that the file I >> would search and replace in clearly states that it is >> auto-generated (sbcl groveler?) and should not be manually >> edited... DL> ;;; automatically generated, hand tweaked, do not regenerate. DL> I read that the other way around. :-) Right you are. I probably lost track. Yesterday I went on a tour through CFFI-grovel, CFFI-Unix, SB-ALIEN, etc., and my head's spinning! R From csr21 at cam.ac.uk Tue May 23 14:36:47 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 23 May 2006 15:36:47 +0100 Subject: [mcclim-devel] McCLIM hint on Paolo's cliki In-Reply-To: <17512.43453.293372.603014@necronomicon.sift.info> (rpgoldman@real-time.com's message of "Mon, 15 May 2006 11:18:05 -0500") References: <17512.43453.293372.603014@necronomicon.sift.info> Message-ID: rpgoldman at real-time.com writes: > Paolo's cliki has the following McCLIM hint: > > ---------------------------------------------------------------------- > > Order of suggestions in completion menus > > If you pass to complete-from-possibilities a list of suggestions such as '(("First" 1) ("Second" 2) ("Third)), they are displayed in reverse order from top to bottom in completion menus, like this: > > Third > Second > First > > If this is not what you want, pass a list sorted in the opposite > order. > > ---------------------------------------------------------------------- > > At the expense of causing some minor dislocation, isn't this something > we should fix, instead of hacking around? It would be nice, except that I think the cliki is out of date and in fact they are presented in alphabetical order. (I consider the presenting in alphabetical order to be more wrong, mind you, because it makes no sense in many contexts and is impossible to override or revert back to the original order.) I tested this with (in the listener) (in-package "CLIMI") (defun foo (input mode) (complete-from-possibilities input '(("First" 1) ("Second" 2) ("Third" 3) ("Fourth" 4)) nil :action mode)) (with-input-editing (*standard-input*) (accept-using-completion 'integer *standard-input* #'foo)) and hitting C-/, which gave me the possibilities (in order) First, Fourth, Second, Third. > Also, is this a place where the clim specification is deficient? > I.e., does it underspecify the behavior? Should it tell us how a list > of possibilities will be displayed by default (in absence of specific > function arguments)? It looks underspecified, yes; what does Classic CLIM do? Cheers, Christophe From csr21 at cam.ac.uk Tue May 23 14:41:44 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 23 May 2006 15:41:44 +0100 Subject: [mcclim-devel] making freetype more portable In-Reply-To: <17523.5928.246174.919999@necronomicon.sift.info> (rpgoldman@real-time.com's message of "Tue, 23 May 2006 09:07:36 -0500") References: <17522.41613.856547.811785@necronomicon.sift.info> <20060523122204.GA21931@gargravarr.knowledgetools.de> <17523.5928.246174.919999@necronomicon.sift.info> Message-ID: rpgoldman at real-time.com writes: > The reason I was worried about doing this was that the file I would > search and replace in clearly states that it is auto-generated (sbcl > groveler?) No, the bindings were generated by Gilbert Baumann by some process I know no details of, but were initially cmucl-only and had nothing to do with the sbcl groveler. > and should not be manually edited... David's already addressed this one ;-) Cheers, Christophe From amoroso at mclink.it Tue May 23 16:13:01 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 23 May 2006 18:13:01 +0200 Subject: [mcclim-devel] McCLIM hint on Paolo's cliki References: <17512.43453.293372.603014@necronomicon.sift.info> Message-ID: <87r72kk9de.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > rpgoldman at real-time.com writes: > >> Paolo's cliki has the following McCLIM hint: [...] >> Order of suggestions in completion menus [...] > It would be nice, except that I think the cliki is out of date and in > fact they are presented in alphabetical order. (I consider the I have removed the relevant section, thanks. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From gilham at csl.sri.com Wed May 24 00:24:09 2006 From: gilham at csl.sri.com (Fred Gilham) Date: Tue, 23 May 2006 17:24:09 -0700 Subject: [mcclim-devel] Problem with McCLIM In-Reply-To: References: <48480.1148346871@snapdragon.csl.sri.com> Message-ID: <72613.1148430249@snapdragon.csl.sri.com> Christophe Rhodes wrote: > Fred Gilham writes: > > > * (clim-demo::demodemo) > > > > (now I click on the "Address Book" button) > > > > Error in function KERNEL:CLASS-TYPEP: > > Class is currently invalid: # > CLIM-INTERNALS::BASIC-OUTPUT-RECORD {29269CB5}> > > [Condition of type SIMPLE-ERROR] > > Unless you have reason to believe otherwise, I think this is a bug in > CMUCL. (It's possible to work around bugs in CMUCL, of course, but it > would be much better for all concerned to fix the actual bug.) I don't know one way or another, but this is new behavior. It would be nice to know at least what caused this behavior. -- Fred Gilham gilham at csl.sri.com In Nashville there ain't no money above the third fret. -- Jay Carlson From csr21 at cam.ac.uk Wed May 24 06:14:29 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 24 May 2006 07:14:29 +0100 Subject: [mcclim-devel] Problem with McCLIM In-Reply-To: <72613.1148430249@snapdragon.csl.sri.com> (Fred Gilham's message of "Tue, 23 May 2006 17:24:09 -0700") References: <48480.1148346871@snapdragon.csl.sri.com> <72613.1148430249@snapdragon.csl.sri.com> Message-ID: Fred Gilham writes: > Christophe Rhodes wrote: > >> Fred Gilham writes: >> >> > * (clim-demo::demodemo) >> > >> > (now I click on the "Address Book" button) >> > >> > Error in function KERNEL:CLASS-TYPEP: >> > Class is currently invalid: #> > CLIM-INTERNALS::BASIC-OUTPUT-RECORD {29269CB5}> >> > [Condition of type SIMPLE-ERROR] >> >> Unless you have reason to believe otherwise, I think this is a bug in >> CMUCL. (It's possible to work around bugs in CMUCL, of course, but it >> would be much better for all concerned to fix the actual bug.) > > I don't know one way or another, but this is new behavior. It would be > nice to know at least what caused this behavior. This can be achieved by some CMUCL 19c user bisecting the McCLIM CVS between the last known working state and HEAD, running the Address Book demo each time. Cheers, Christophe From idurand at labri.fr Wed May 24 07:20:37 2006 From: idurand at labri.fr (Irene DURAND) Date: Wed, 24 May 2006 09:20:37 +0200 Subject: [mcclim-devel] mcclim update Message-ID: <44740945.3050601@labri.fr> With a version of mcclim updated on march 31st Autowrite works fine. With the latest version I get the error below. Could somebody help me please? -- Ir?ne DURAND http://dept-info.labri.u-bordeaux.fr/~idurand The class # is currently invalid. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Return to application command loop 1: [ABORT-REQUEST] Abort handling SLIME request. 2: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: (SB-KERNEL:CLASSOID-TYPEP # {EE7BCB9}> # #) {E50CCF1}>) 1: (CLIM-INTERNALS::FIND-OUTPUT-RECORD-SHEET #) {E50CCF1}>) 2: ((SB-PCL::FAST-METHOD ADD-OUTPUT-RECORD :AFTER (T CLIM-INTERNALS::COMPOUND-OUTPUT-RECORD)) # # # #) {E50CCF1}>) 3: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) # # # #) {E50CCF1}>) 4: ((LAMBDA NIL)) 5: ((FLET #:CONTINUATION1279) # #) 6: ((SB-PCL::FAST-METHOD INVOKE-WITH-NEW-OUTPUT-RECORD (OUTPUT-RECORDING-STREAM T T T)) # # # # # # (:OBJECT (COM-LOAD-SPEC) :TYPE (COMMAND :COMMAND-TABLE #))) 7: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::FINALIZE (GOATEE:GOATEE-INPUT-EDITING-MIXIN T)) # # # #) 8: ((FLET #:CLEANUP-FUN-602)) 9: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING (EXTENDED-INPUT-STREAM T T T T)) # # # # # "" STANDARD-INPUT-EDITING-STREAM) 10: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING :AROUND (EXTENDED-OUTPUT-STREAM T T T T)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (5)) :ARG-INFO (5)) # # # "" STANDARD-INPUT-EDITING-STREAM) 11: (ACCEPT (COMMAND :COMMAND-TABLE #) :STREAM # :PROMPT NIL :DEFAULT (CLIM-INTERNALS::COM-NULL-COMMAND) :DEFAULT-TYPE CLIM-INTERNALS::NULL-COMMAND) 12: (READ-COMMAND # :STREAM # :COMMAND-PARSER NIL :COMMAND-UNPARSER NIL :PARTIAL-COMMAND-PARSER NIL :USE-KEYSTROKES NIL) 13: (READ-COMMAND-USING-KEYSTROKES # NIL :STREAM # :COMMAND-PARSER NIL :COMMAND-UNPARSER NIL :PARTIAL-COMMAND-PARSER NIL) 14: (READ-COMMAND # :STREAM # :COMMAND-PARSER NIL :COMMAND-UNPARSER NIL :PARTIAL-COMMAND-PARSER NIL :USE-KEYSTROKES T) 15: ((SB-PCL::FAST-METHOD READ-FRAME-COMMAND :AROUND (APPLICATION-FRAME)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # (:STREAM #)) 16: ((SB-PCL::FAST-METHOD DEFAULT-FRAME-TOP-LEVEL (APPLICATION-FRAME)) # # # NIL) 17: ((SB-PCL::FAST-METHOD DEFAULT-FRAME-TOP-LEVEL (APPLICATION-FRAME)) # # # NIL) 18: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.DFUN-REST-ARG.)) # # # NIL) 19: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL (APPLICATION-FRAME)) # # # #) --more-- From csr21 at cam.ac.uk Wed May 24 08:27:31 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 24 May 2006 09:27:31 +0100 Subject: [mcclim-devel] mcclim update In-Reply-To: <44740945.3050601@labri.fr> (Irene DURAND's message of "Wed, 24 May 2006 09:20:37 +0200") References: <44740945.3050601@labri.fr> Message-ID: Irene DURAND writes: > With a version of mcclim updated on march 31st Autowrite works fine. > With the latest version I get the error below. > Could somebody help me please? As I said in my reply to Fred Gilham, this is likely a bug in CMUCL 19c; it can probably be worked around, but to do so it would be nice to know what the bug is in the first place so that the CMUCL people can fix it; to achieve this, you can bisect the CVS to find the commit that changed things, then work out which portion of that commit exposes the problem. Cheers, Christophe From david at lichteblau.com Wed May 24 09:52:24 2006 From: david at lichteblau.com (David Lichteblau) Date: Wed, 24 May 2006 11:52:24 +0200 Subject: [mcclim-devel] mcclim update In-Reply-To: References: <44740945.3050601@labri.fr> Message-ID: <20060524095224.GA2887@gargravarr.knowledgetools.de> Quoting Christophe Rhodes (csr21 at cam.ac.uk): > > With a version of mcclim updated on march 31st Autowrite works fine. > > With the latest version I get the error below. > > Could somebody help me please? | The class # | is currently invalid. | [Condition of type SIMPLE-ERROR] > As I said in my reply to Fred Gilham, this is likely a bug in CMUCL > 19c; it can probably be worked around, but to do so it would be nice > to know what the bug is in the first place so that the CMUCL people > can fix it; to achieve this, you can bisect the CVS to find the commit > that changed things, then work out which portion of that commit > exposes the problem. That looks unlikely to be a CMUCL bug to me. :-) It rather seems to be Christophe's removal of compatibility with older SBCL bugs, solved by either upgrading SBCL or reverting Christophe's recent McCLIM patches. d. From csr21 at cam.ac.uk Wed May 24 10:02:59 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 24 May 2006 11:02:59 +0100 Subject: [mcclim-devel] clipping regions, replay, handle-repaint Message-ID: Hi, I think that CLIM underspecifies how clipping regions (and text-styles and line-styles) are handled for output records. For REPLAY-OUTPUT-RECORD, it says "The current user transformation, line style, text style, ink, and clipping region of stream are all ignored during the replay operation. Instead, these are gotten from the output record." which is good, but unfortunately it doesn't specify /how/ they are gotten, which means that implementing one's own output record class is tricky. Why does this matter? In gsharp, we implement sloped beams with our own kind of output record; as of this morning, I taught that output record, and the replay-output-record methods, about the medium clipping region, so that sloped short beams (as in ) survive repainting; previously the output record had no record of the clipping region, and so a repaint would cause the entire width, rather than just the short segment, to be drawn. So this now works acceptably. However, we implement horizontal beams with an ordinary rectangle, and short ones with an ordinary rectangle and clipping region. Before a repaint, this works fine: see . However, obscuring and uncovering the window, triggering a repaint, results in . This happens because the replay-output-record methods for the clim internal graphics things (such as rectangles) set the medium clipping region while they're replaying, but don't set it back; they simply rely on a method on replay. In fact, in McCLIM itself as distributed the set-medium-graphics-state :after method on gs-clip-mixin is essentially disabled, though I'm not entirely sure why; gsharp re-enables it, presumably in an attempt to get some of this working, but disabling it again simply means that replaying horizontal beams (i.e. rectangles) which have been clipped ignores the previous clipping region. What is one to do? Well, I think with the standard as it is there's no way of writing output record classes. However, the case of changing ink can be handled in the spec, as CLIM specifies a function displayed-output-record-ink; using that, dealing with the ink looks like (defmethod replay-output-record :around ((record displayed-output-record) stream ...) (let ((medium (sheet-medium stream))) (with-drawing-options (medium :ink (displayed-output-record-ink record)) (call-next-method)))) and this will work, given that all displayed-output-record objects obey the displayed-output-record protocol. If we were to extend the protocol to require displayed-output-record-clipping-region, displayed-output-record-text-style and displayed-output-record-line-style, then I think this would cover the difficult cases, most of the set-medium-graphics-state methods could go away, and gsharp could have horizontal short beams. Comments? Cheers, Christophe From csr21 at cam.ac.uk Wed May 24 10:12:19 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 24 May 2006 11:12:19 +0100 Subject: [mcclim-devel] mcclim update In-Reply-To: <20060524095224.GA2887@gargravarr.knowledgetools.de> (David Lichteblau's message of "Wed, 24 May 2006 11:52:24 +0200") References: <44740945.3050601@labri.fr> <20060524095224.GA2887@gargravarr.knowledgetools.de> Message-ID: David Lichteblau writes: > Quoting Christophe Rhodes (csr21 at cam.ac.uk): >> > With a version of mcclim updated on march 31st Autowrite works fine. >> > With the latest version I get the error below. >> > Could somebody help me please? > > | The class # > | is currently invalid. > | [Condition of type SIMPLE-ERROR] > >> As I said in my reply to Fred Gilham, this is likely a bug in CMUCL >> 19c; it can probably be worked around, but to do so it would be nice >> to know what the bug is in the first place so that the CMUCL people >> can fix it; to achieve this, you can bisect the CVS to find the commit >> that changed things, then work out which portion of that commit >> exposes the problem. > > That looks unlikely to be a CMUCL bug to me. :-) > > It rather seems to be Christophe's removal of compatibility with older > SBCL bugs, solved by either upgrading SBCL or reverting Christophe's > recent McCLIM patches. Oh, whoops. Yes. Sorry, for two things: firstly, for completely failing to read the message, and secondly, for at one point in this development cycle deciding to remove workarounds for older SBCL bugs. (This looks like the same problem as the 19c thing, in my defence) To see if this is the problem, try moving the (define-protocol-class design ()) in protocol-classes.lisp to above (define-protocol-class region (design)) in the same file. Cheers, Christophe From gilham at csl.sri.com Thu May 25 00:23:46 2006 From: gilham at csl.sri.com (Fred Gilham) Date: Wed, 24 May 2006 17:23:46 -0700 Subject: [mcclim-devel] mcclim update In-Reply-To: References: <44740945.3050601@labri.fr> <20060524095224.GA2887@gargravarr.knowledgetools.de> Message-ID: <54872.1148516626@snapdragon.csl.sri.com> Christophe Rhodes wrote: > To see if this is the problem, try moving the > (define-protocol-class design ()) > in protocol-classes.lisp to above > (define-protocol-class region (design)) > in the same file. Doing this fixes the problem. So I guess it's a problem with forward referenced classes in CMUCL and SBCL. -- Fred Gilham gilham at csl.sri.com Time is nature's way of making sure everything doesn't happen at once. Unfortunately, like most things in nature it doesn't always work. From csr21 at cam.ac.uk Thu May 25 06:11:07 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 25 May 2006 07:11:07 +0100 Subject: [mcclim-devel] mcclim update In-Reply-To: <54872.1148516626@snapdragon.csl.sri.com> (Fred Gilham's message of "Wed, 24 May 2006 17:23:46 -0700") References: <44740945.3050601@labri.fr> <20060524095224.GA2887@gargravarr.knowledgetools.de> <54872.1148516626@snapdragon.csl.sri.com> Message-ID: Fred Gilham writes: > Christophe Rhodes wrote: > >> To see if this is the problem, try moving the >> (define-protocol-class design ()) >> in protocol-classes.lisp to above >> (define-protocol-class region (design)) >> in the same file. > > Doing this fixes the problem. So I guess it's a problem with forward > referenced classes in CMUCL and older versions of > SBCL. Feel free to trawl SBCL CVS to find the patch, and port it to your favourite Lisp implementation. Cheers, Christophe From csr21 at cam.ac.uk Thu May 25 11:52:21 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 25 May 2006 12:52:21 +0100 Subject: [mcclim-devel] execute-frame-command Message-ID: 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 From rpgoldman at real-time.com Thu May 25 15:54:18 2006 From: rpgoldman at real-time.com (Robert P. Goldman) Date: Thu, 25 May 2006 10:54:18 -0500 Subject: [mcclim-devel] freetype-cffi sorta works Message-ID: <4475D32A.8040403@real-time.com> I have the CFFI translation of freetype working at least a little (on ACL). I am certainly NOT confident enough in it to say it ought to replace the old one! But I would like to share the work, and I would like to see it out there on common-lisp.net for people to examine and critique. Here's what I have done: I have created shadows of all the original files. So I have freetype-fonts-cffi.lisp, freetype-cffi.lisp, freetype-package-cffi.lisp and mcclim-freetype-cffi.asd. I would like to check these into the CVS, since they will not break the existing mcclim-freetype. If you'd like to test the CFFI version, just symlink /mcclim-freetype.asd to mcclim-freetype-cffi.asd, then load as per the instructions for ordinary mcclim-freetype.asd. Please let me know if this for some reason would be a bad thing. Otherwise I will make the commit in about 4-6 hours. Thanks! R From csr21 at cam.ac.uk Thu May 25 15:58:34 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 25 May 2006 16:58:34 +0100 Subject: [mcclim-devel] Debugger, ESA, mcclim-freetype Message-ID: Hi, Today I observed a rather nasty interaction that I'm at a loss to explain. If I wrap the CLIM Debugger around an Emacs-Style Application which uses mcclim-freetype, and provoke an entry into that debugger, I get X Length Errors. I think I need all three of those elements: the clim debugger and listener work fine together; gsharp and the clim debugger without freetype work fine; and of course the applications work acceptably using freetype in normal operation and with slime. I am not sure whether this is specific to SBCL; nor am I sure whether it is specific to threaded lisps; I haven't tried it with a non-threaded system. The event queue process has a backtrace that looks like Backtrace: (BACKTRACE-AS-LIST 200) (DEBUGGER-HOOK # #) (INVOKE-DEBUGGER #) (CERROR "Ignore" XLIB:LENGTH-ERROR) (XLIB::X-CERROR "Ignore" XLIB:LENGTH-ERROR :DISPLAY # :ERROR-KEY XLIB:LENGTH-ERROR :ASYNCHRONOUS T :CURRENT-SEQUENCE 1913 :MAJOR 154 :MINOR 25 :SEQUENCE 1563) [...] (XLIB:PROCESS-EVENT # :HANDLER # :TIMEOUT NIL :PEEK-P NIL :DISCARD-P T :FORCE-OUTPUT-P T) ((SB-PCL::FAST-METHOD CLIM-BACKEND:GET-NEXT-EVENT #) # # # (:WAIT-FUNCTION NIL :TIMEOUT NIL)) while the application thread (which /also/ gets a length error) has a backtrace involving HANDLE-REPAINT on the menu-button-pane of the CLIM Debugger, CLIM-CLX::FONT-DRAW-GLYPHS (MCCLIM-FREETYPE::FREETYPE-FACE ...), and a call to XLIB::DRAWABLE-DEPTH and XLIB::READ-REPLY. Any ideas? Can anyone replicate any of this? Is there something in the toplevel loop of ESA (or attendant methods) which could cause this problem? Cheers, Christophe From rpgoldman at real-time.com Thu May 25 15:35:07 2006 From: rpgoldman at real-time.com (Robert P. Goldman) Date: Thu, 25 May 2006 10:35:07 -0500 Subject: [mcclim-devel] Re: Question about freetype translation to CFFI In-Reply-To: <4474A031.9070309@real-time.com> References: <4474A031.9070309@real-time.com> Message-ID: <4475CEAB.1000906@real-time.com> Please disregard this query. I see that I was clueless and apologize. I had forgotten my old C knowledge, and in particular, had forgotten that the desire to have multiple values, combined with call-by-value, means that one often must pass pointers to pointers as arguments, and then to get the pointer, one dereferences.... Never mind! Cheers, R Robert P. Goldman wrote: > I wonder if anyone who's familiar with SBCL aliens can give me some > advice in my ongoing translation of the freetype code into CFFI. IIUC > (I quite possibly don't), a difference between the two is that SBCL > has much more "understanding" of the foreign data structures, and that > it is able to work directly with foreign structures. CFFI works more > with pointers, and requires more explicit reference to the foreign > types when dereferencing. > > I think I have mostly managed to translate the foreign data > structures, and a good bit of the code. However, I am still having > some trouble understanding a bit of the SBCL alien code, particularly > the use of derefs when returning foreign values. For example, here's > one of the original defuns: > > (defun make-concrete-font (vague-font size &key (dpi *dpi*)) > (with-slots (lib filename) vague-font > (let* ((key (cons lib filename)) > (val (gethash key *concrete-font-hash*))) > (unless val > (let ((facef (make-alien freetype:face))) > (declare (type (alien (* freetype:face)) facef)) > (if (zerop (freetype:new-face lib filename 0 facef)) > (setf val (setf (gethash key *concrete-font-hash*) > (deref facef))) > (error "Freetype error in make-concrete-font")))) > (let ((face val)) > (declare (type (alien freetype:face) face)) > (freetype:set-char-size face 0 (round (* size 64)) (round dpi) > (round dpi)) > face)))) > > I'm not at all sure, moving to CFFI, how to translate the DEREF > calls. CFFI is essentially always working with pointers, IIUC, so I'm > wondering if I should just eliminate deref calls like this (i.e., just > set the hash table entry to facef)... > > Any suggestions would be more than welcome. > > > Thanks, > R > > From csr21 at cam.ac.uk Fri May 26 09:58:58 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 26 May 2006 10:58:58 +0100 Subject: [mcclim-devel] Debugger, ESA, mcclim-freetype In-Reply-To: (Christophe Rhodes's message of "Thu, 25 May 2006 16:58:34 +0100") References: Message-ID: Christophe Rhodes writes: > I am not sure whether this is specific to SBCL; nor am I sure whether > it is specific to threaded lisps; I haven't tried it with a > non-threaded system. The event queue process has a backtrace that > looks like The good (?) news is that this also happens in a non-threaded system; that's not really good news, but it does mean that some attempt at understanding this can be made without the added extra confusion of race conditions and threads. I attach a backtrace. Com-error is a command I defined at the M-: climacs "repl" and bound to C-! as follows (climacs-gui::define-climacs-command com-error () (error "foo")) (esa:set-key 'com-error 'clim:global-command-table '((#\! :control))) (esa:set-key 'com-error 'clim:global-command-table '((#\! :control :shift))) I /think/ I have seen this symptom once before, and it had something to do with CLX not being re-entrant: something somewhere was attempting to call a protocol request in the dynamic scope of another one. I can't remember the details: neither how I debugged it nor what I did to fix it :-( -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: back URL: -------------- next part -------------- Any ideas? Cheers, Christophe From csr21 at cam.ac.uk Fri May 26 11:15:06 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 26 May 2006 12:15:06 +0100 Subject: [mcclim-devel] Debugger, ESA, mcclim-freetype In-Reply-To: (Christophe Rhodes's message of "Fri, 26 May 2006 10:58:58 +0100") References: Message-ID: Christophe Rhodes writes: > Any ideas? Moments later, Andreas (our intrepid release manager) provided a hint. It's possible to trigger length errors by typing long (about 200 character) strings at a clim-listener or beirc prompt when using mcclim-freetype. By altering the clim-debugger only to print the first 80 characters of each frame, the length error symptoms go away, so I presume that there is a very long frame in the backtrace of an ESA, where there isn't in the clim-listener. This might point out a need to implement BIG-REQUESTS for CLX... any takers? Cheers, Christophe From david at lichteblau.com Fri May 26 13:46:22 2006 From: david at lichteblau.com (David Lichteblau) Date: Fri, 26 May 2006 15:46:22 +0200 Subject: [mcclim-devel] making freetype more portable In-Reply-To: <20060523122204.GA21931@gargravarr.knowledgetools.de> References: <17522.41613.856547.811785@necronomicon.sift.info> <20060523122204.GA21931@gargravarr.knowledgetools.de> Message-ID: <20060526134622.GA31666@gargravarr.knowledgetools.de> In reply to myself, ... Quoting David Lichteblau (david at lichteblau.com): > If I understand correctly, clim-freetype handles two problems: Selecting > fonts through freetype. And actually drawing text. FWIW, that wasn't entirely correct. Font selection would go through fontconfig, not freetype. clim-freetype doesn't seem to have anything to offer in this regard, it only does some run-shell-command thing to query fontconfig. > It would be nice to translate the clim-freetype code for font selection > from alien to cffi and adapt it for gtkairo. ... so what gtkairo needs, especially for the Windows port, is actually Pango support for font selection. d. From smustudent1 at yahoo.com Fri May 26 15:15:16 2006 From: smustudent1 at yahoo.com (C Y) Date: Fri, 26 May 2006 08:15:16 -0700 (PDT) Subject: [mcclim-devel] Debugger, ESA, mcclim-freetype In-Reply-To: Message-ID: <20060526151516.37575.qmail@web31707.mail.mud.yahoo.com> --- Christophe Rhodes wrote: > > This might point out a need to implement BIG-REQUESTS for CLX... any > takers? You might want to take a look at this: http://article.gmane.org/gmane.lisp.clx.devel/108 Not sure if it is in the current telent-clx or not. Cheers, CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From asf at boinkor.net Fri May 26 21:09:26 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Fri, 26 May 2006 23:09:26 +0200 Subject: [mcclim-devel] Towards a 0.9.3 "Trinity Sunday" release Message-ID: <87psi04ho9.wl%asf@boinkor.net> Hi, this is going to be the first (or third, if you count Laetare Sunday) release in a time-boxed series! The plan is to release on Trinity Sunday, which is on the 11th of June this year. The freeze period will start on June 6, that is the tuesday after Pentecost. Seeing as the last freeze announcement prompted a lot of fixes and patches to come in, I'd like to urge all contributors to send your patches before the start of the freeze period this time. You've got a long weekend to do so, too. (-: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From csr21 at cam.ac.uk Sun May 28 17:54:06 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 28 May 2006 18:54:06 +0100 Subject: [mcclim-devel] clipping regions, replay, handle-repaint In-Reply-To: (Christophe Rhodes's message of "Wed, 24 May 2006 11:02:59 +0100") References: Message-ID: Christophe Rhodes writes: > Comments? Here's an implementation of a more minimal, less invasive change. SET-MEDIUM-GRAPHICS-STATE goes away and is replaced by :AROUND methods on REPLAY-OUTPUT-RECORD the various graphics state mixin types, which use WITH-DRAWING-OPTIONS to bind dynamically the various bits of graphics state that they need. The uses of SET-MEDIUM-GRAPHICS-STATE in incremental-redisplay then boil down to setting the stream cursor position; the uses of MEDIUM-GRAPHICS-STATE there actually should just retrieve the cursor position, but I haven't altered that in the source. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: output-records.diff URL: -------------- next part -------------- Then GSharp, which specializes DISPLAYED-OUTPUT-RECORD (a specified class, unlike STANDARD-DISPLAYED-OUTPUT-RECORD, where all of these changes have been occurring) can itself remember the bits of medium state it needs (ink and clipping-region), and then the effect of the graphics state of each output record is dynamically contained to its own replay, and not any other records'. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: score-pane.diff URL: -------------- next part -------------- And all this lets me put up screenshots like . I have tested a couple of other applications with this (the Address Book still works!) and nothing seems terribly amiss. I'd like a sanity check, though, and maybe consideration of whether having analogues to displayed-output-record-ink would make sense. (I think it would, and in fact I think that with this change the various bits of graphics state /are/ attached to the output record). Cheers, Christophe