From csr21 at cam.ac.uk Sat Apr 1 21:11:10 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sat, 01 Apr 2006 22:11:10 +0100 Subject: [mcclim-devel] eps bug In-Reply-To: (David Lewis's message of "Thu, 30 Mar 2006 14:30:10 +0100") References: Message-ID: David Lewis writes: > If this was me, I apologise now, but somehow eps output from > invoke-with-output-to-postscript-stream now always gives a bounding > box with 0 width. So it does. > This should fix it: Merged, thanks; now Tests/postscript.lisp passes again... I suppose that means we managed to release 0.9.2 failing its own test suite (which given the small number of tests in the suite is quite an achievement!) Cheers, Christophe From csr21 at cam.ac.uk Sat Apr 1 22:22:32 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sat, 01 Apr 2006 23:22:32 +0100 Subject: [mcclim-devel] define-presentation-type Message-ID: Hi, I think I just got bitten by the (specified) restriction that one can't inherit-from OR presentation types in define-presentation-type. It would have saved me some time if McCLIM had detected my erroneous code earlier -- is that possible? Cheers, Christophe From frido at q-software-solutions.de Sun Apr 2 12:42:34 2006 From: frido at q-software-solutions.de (Friedrich Dominicus) Date: Sun, 02 Apr 2006 14:42:34 +0200 Subject: [mcclim-devel] mouse actions ignored? In-Reply-To: (Christophe Rhodes's message of "Sat, 01 Apr 2006 23:22:32 +0100") References: Message-ID: <87psk0qhc5.fsf@flarge.here> I wonder if someone else has encountered the following While running a current mcclim example my mouse is completely ignored. E.g in closeau nothing happens on any mouse click and using the mouse int the listenter just works to choose something from a menu. System: Debian 2.6.10 AMD64 SBCL 9.10.x mcclim: what can be found in the CVS tree from today. Regards Friedrich From rpgoldman at real-time.com Tue Apr 4 19:59:37 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 4 Apr 2006 14:59:37 -0500 Subject: [mcclim-devel] issues (bug?) with with-tab-layout in beirc Message-ID: <17458.53289.211228.309489@necronomicon.sift.info> I was trying to debug a space requirement issue in beirc, so I wanted to grab hold of its tab-layout-pane (which is named 'query). Oddly, I find that (get-frame-pane 'query) returns nil. I managed to use a back door to find the pane, and it *does* have a name: BEIRC(31): (slot-value tab-pane 'climi::name) QUERY It was defined as follows: (:layouts (default (vertically () (with-tab-layout ('receiver-pane :name 'query) ("*Not Connected*" server 'receiver-pane)) ;; (68 io) ;; no drop-shadow prompt (make-pane 'clim-extensions:box-adjuster-gadget) io (20 pointer-doc) (20 ;<-- Sigh! Bitrot! status-bar)))) The with-tab-layout does have the :name option, and it invokes make-pane. AFAICT, make-pane should stuff *application-frame* into an arglist and invoke make-pane-1, which should stash this pane away in the named-panes slot of the *application-frame*. But this is evidently not happening (or, I suppose, that slot could be overwritten). Alternatively, I suppose that *application-frame* might be unbound at the time this with-tab-layout gets evaluated? I'm pretty sure that this is a bug, and that the tab-layout pane IS intended to be exposed to get-frame-pane. But I'm not sure how to fix it, myself. Thanks, R From pw at snoopy.mv.com Tue Apr 4 21:53:15 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 4 Apr 2006 17:53:15 -0400 Subject: [mcclim-devel] issues (bug?) with with-tab-layout in beirc References: <17458.53289.211228.309489@necronomicon.sift.info> Message-ID: <000b01c65832$2d390b00$0201a8c0@moby> | I'm pretty sure that this is a bug, and that the tab-layout pane IS | intended to be exposed to get-frame-pane. But I'm not sure how to fix | it, myself. Nope, Check out the difference between GET-FRAME-PANE and FIND-PANE-NAMED. Paul From rpgoldman at real-time.com Tue Apr 4 23:46:20 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 4 Apr 2006 18:46:20 -0500 Subject: [mcclim-devel] issues (bug?) with with-tab-layout in beirc In-Reply-To: <000b01c65832$2d390b00$0201a8c0@moby> References: <17458.53289.211228.309489@necronomicon.sift.info> <000b01c65832$2d390b00$0201a8c0@moby> Message-ID: <17459.1356.229190.20712@necronomicon.sift.info> >>>>> "PW" == Paul Werkowski writes: PW> | I'm pretty sure that this is a bug, and that the tab-layout PW> pane IS | intended to be exposed to get-frame-pane. But I'm PW> not sure how to fix | it, myself. PW> Nope, PW> Check out the difference between GET-FRAME-PANE and PW> FIND-PANE-NAMED. OK, I'm quite willing to believe I'm wrong about this, but would it be possible to amplify on your response a little? Is it because the tab-layout-pane is not a clim-stream-pane? R From pw at snoopy.mv.com Wed Apr 5 00:10:21 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 4 Apr 2006 20:10:21 -0400 Subject: [mcclim-devel] issues (bug?) with with-tab-layout in beirc References: <17458.53289.211228.309489@necronomicon.sift.info><000b01c65832$2d390b00$0201a8c0@moby> <17459.1356.229190.20712@necronomicon.sift.info> Message-ID: <000501c65845$543a6a60$0201a8c0@moby> | | PW> Check out the difference between GET-FRAME-PANE and | PW> FIND-PANE-NAMED. | | OK, I'm quite willing to believe I'm wrong about this, but would it be | possible to amplify on your response a little? Is it because the | tab-layout-pane is not a clim-stream-pane? | I don't know what the tab-layout-pane is, not part of CLIM AFAIK, but it is most likely not. You probably can find out by using find-class and inspect to find out. Paul From ahefner at gmail.com Tue Apr 4 20:44:13 2006 From: ahefner at gmail.com (Andy Hefner) Date: Tue, 4 Apr 2006 16:44:13 -0400 Subject: [mcclim-devel] issues (bug?) with with-tab-layout in beirc In-Reply-To: <17458.53289.211228.309489@necronomicon.sift.info> References: <17458.53289.211228.309489@necronomicon.sift.info> Message-ID: <31ffd3c40604041344oa478055wec0ee78409fa14be@mail.gmail.com> "It's not a bug, it's a feature." You want to use 'find-pane-named' rather than 'get-frame-pane'. Per the CLIM spec, get-frame-pane only searches for stream panes, whereas find-pane-named will search all panes, including gadgets. (I personally disagree with this design, but I didn't write the spec.) I took a quick look at how the tab-layout-pane is implemented. It is comprised of two pieces: a stream pane implementing the tabs themselves (the 'tab-bar-pane'), and a layout pane derived from vrack-pane (a gadget) containing the tab-bar-pane and the panes being managed. The with-tab-layout macro assigns the name to the layout pane rather than the tab-bar-pane (rightly, since we want to name the highest member of the hierarchy), so get-frame-pane ignores it. This is certainly the correct behavior, but the behavior of get-frame-pane is unfortunate. On 4/4/06, rpgoldman at real-time.com wrote: > I'm pretty sure that this is a bug, and that the tab-layout pane IS > intended to be exposed to get-frame-pane. But I'm not sure how to fix > it, myself. From m.retzlaff at gmx.net Wed Apr 5 01:57:11 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Wed, 5 Apr 2006 03:57:11 +0200 Subject: the Tab Layout Pane (Re: [mcclim-devel] issues (bug?) with with-tab-layout in beirc) In-Reply-To: <000501c65845$543a6a60$0201a8c0@moby> References: <17459.1356.229190.20712@necronomicon.sift.info> <000501c65845$543a6a60$0201a8c0@moby> Message-ID: <20060405015711.GA2631@mgr.home> Hello On Tue, Apr 04, 2006 at 08:10:21PM -0400, Paul Werkowski wrote: > I don't know what the tab-layout-pane is, not part of CLIM AFAIK, > but it is most likely not. You're right. I've written it, and it's based on my radio-layout-pane that again bases on the stack-layout-pane that's originally been written by Gilbert Baumann (see http://bauhh.dyndns.org:8000/flux/stack-layout.lisp). All the necessary files---including asdf-files and examples---can be found in this archive: http://matroid.org/flux/tab-layout_2005-09-19_17-19+0200.tar.bz2 (Or extracted at http://matroid.org/flux/tab-layout_2005-09-19_17-19+0200/ ) I hope to be soon able to merge antifuchs' drag and drop translator, and finally add it to the mcclim repository as an Extension (probably after some additional changes). The whole things looks like this: http://matroid.org/flux/tabbed-radio-pane-presentation.png Or used by Beirc (probably not the most recent version of Beirc): http://common-lisp.net/project/beirc/images/beirc.png Hmm, it seems that I haven't mentioned it on this list before. I've thought I had.. Bye, Max -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: When I woke up this morning, my girlfriend asked if I had slept well. I said, "No, I made a few mistakes." -- Steven Wright -------------- 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 Wed Apr 5 02:08:19 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Wed, 5 Apr 2006 04:08:19 +0200 Subject: [mcclim-devel] issues (bug?) with with-tab-layout in beirc In-Reply-To: <31ffd3c40604041344oa478055wec0ee78409fa14be@mail.gmail.com> References: <17458.53289.211228.309489@necronomicon.sift.info> <31ffd3c40604041344oa478055wec0ee78409fa14be@mail.gmail.com> Message-ID: <20060405020819.GB2631@mgr.home> Hello On Tue, Apr 04, 2006 at 04:44:13PM -0400, Andy Hefner wrote: > The with-tab-layout macro assigns the name to the layout pane > rather than the tab-bar-pane (rightly, since we want to name the > highest member of the hierarchy), so get-frame-pane ignores it. There's the accessor tab-layout::tab-bar-pane-of-tab-layout to get the tab-bar-pane of a tab-layout-pane (hey, who would have thought?), but it's not exported as I can't think why one would want to mess around with this internal stuff from the outside. Bye, Max -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: Shah, shah! Ayatollah you so! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From idurand at labri.fr Fri Apr 7 13:46:24 2006 From: idurand at labri.fr (Irene DURAND) Date: Fri, 07 Apr 2006 15:46:24 +0200 Subject: [mcclim-devel] scroll Message-ID: <44366D30.5010704@labri.fr> Hello, With the latest version of mcclim, my application Autowrite has a problem that wasn't there before. When I scroll up a scrolling pane the top of the pane is empty and I cannot see anymore what was at the top of the pane. -- Ir?ne DURAND http://dept-info.labri.u-bordeaux.fr/~idurand From idurand at labri.fr Fri Apr 7 14:24:51 2006 From: idurand at labri.fr (Irene DURAND) Date: Fri, 07 Apr 2006 16:24:51 +0200 Subject: [mcclim-devel] Re: scroll In-Reply-To: <44366D30.5010704@labri.fr> References: <44366D30.5010704@labri.fr> Message-ID: <44367633.9020106@labri.fr> Irene DURAND wrote: > Hello, > With the latest version of mcclim, my application Autowrite has a > problem that wasn't there before. > When I scroll up a scrolling pane the top of the pane is empty and I > cannot see anymore what was > at the top of the pane. > Sorry but after complete recompilation the problem is gone. -- Ir?ne From rpgoldman at real-time.com Fri Apr 7 19:05:56 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Fri, 7 Apr 2006 14:05:56 -0500 Subject: [mcclim-devel] patch for possbility sorting Message-ID: <17462.47124.835083.682833@necronomicon.sift.info> In BEIRC, one can end up with an enormously long list of candidate possibilities for completing a command, because IRC has so many commands. The possibilities are not ordered at all, so the list is pretty much useless. The following patch to input-editing would fix this problem by sorting the set of possibilities alphabetically. I realize that this may not be optimal, because it's a "one size fits all" solution. OTOH, it's clearly better than just getting an arbitrarily permuted list, so I suggest that it be adopted. I have commit privs, but have mostly used them for documentation and Allegro-specific compatibility fixes, so I'd love some validation (or reasoned rejection) before committing. Thanks all, R P.S. It occurs to me that we could avoid pointlessly sorting length 1 lists by dumping the call to sort inside the VALUES call in the ELSE branch of the final if of complete-from-generator-possibilies. But that shouldn't change the question of whether this is a good idea or not... --- input-editing.lisp 10 Mar 2006 21:58:13 -0000 1.49 +++ input-editing.lisp 7 Apr 2006 19:00:18 -0000 @@ -781,6 +781,9 @@ (defun complete-from-generator-possibili (incf nmatches) (push (cons str obj) possibilities)))) (funcall generator initial-string #'suggester) + ;; attempting to get the list of candidates sorted [2006/04/07:rpg] + (setf possibilities + (sort possibilities #'string-lessp :key #'car)) (if (and (eql nmatches 1) (string-equal initial-string (caar possibilities))) (values (caar possibilities) From amoroso at mclink.it Fri Apr 7 19:14:58 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 07 Apr 2006 21:14:58 +0200 Subject: [mcclim-devel] patch for possbility sorting In-Reply-To: <17462.47124.835083.682833@necronomicon.sift.info> (rpgoldman@real-time.com's message of "Fri, 7 Apr 2006 14:05:56 -0500") References: <17462.47124.835083.682833@necronomicon.sift.info> Message-ID: <877j61rydp.fsf@plato.moon.paoloamoroso.it> rpgoldman at real-time.com writes: > In BEIRC, one can end up with an enormously long list of candidate > possibilities for completing a command, because IRC has so many > commands. The possibilities are not ordered at all, so the list is > pretty much useless. > > The following patch to input-editing would fix this problem by sorting > the set of possibilities alphabetically. I deal with this by providing functions such as COMPLETE-FROM-POSSIBILITIES with presorted lists of possibilities. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From rpgoldman at real-time.com Fri Apr 7 19:30:35 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Fri, 7 Apr 2006 14:30:35 -0500 Subject: [mcclim-devel] patch for possbility sorting In-Reply-To: <877j61rydp.fsf@plato.moon.paoloamoroso.it> References: <17462.47124.835083.682833@necronomicon.sift.info> <877j61rydp.fsf@plato.moon.paoloamoroso.it> Message-ID: <17462.48603.427077.379696@necronomicon.sift.info> >>>>> "PA" == Paolo Amoroso writes: PA> rpgoldman at real-time.com writes: >> In BEIRC, one can end up with an enormously long list of >> candidate possibilities for completing a command, because IRC >> has so many commands. The possibilities are not ordered at >> all, so the list is pretty much useless. >> >> The following patch to input-editing would fix this problem by >> sorting the set of possibilities alphabetically. PA> I deal with this by providing functions such as PA> COMPLETE-FROM-POSSIBILITIES with presorted lists of PA> possibilities. OK. The alternative solution would involve modifying the ACCEPT presentation method for COMMAND-NAME in commands.lisp. The problem is that this would now involve a bunch of consing, because I'd have to enumerate all the commands, sort them, and then call the suggester on them. But perhaps that's a better choice. Follow-up question: This is being done by complete-from-generator, rather than complete-from-possibilities. So I don't explicitly create the list of possibilities; instead I have a loop that does a bunch of calls to SUGGEST. A skim of the spec doesn't seem to show any guarantee that the possibilities you get will appear in the same order they were added by suggest. So does your solution work in this location? Note that this patch (I believe) only applies to complete-from-generator, which doesn't have an obvoiusly good alternative (unless we have the suggest guarantee I refer to above). Any suggestions? thanks, r From rpgoldman at real-time.com Fri Apr 7 19:38:32 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Fri, 7 Apr 2006 14:38:32 -0500 Subject: [mcclim-devel] patch for possbility sorting In-Reply-To: <17462.48603.427077.379696@necronomicon.sift.info> References: <17462.47124.835083.682833@necronomicon.sift.info> <877j61rydp.fsf@plato.moon.paoloamoroso.it> <17462.48603.427077.379696@necronomicon.sift.info> Message-ID: <17462.49080.938526.872294@necronomicon.sift.info> >>>>> "PA" == rpgoldman writes: >>>>> "PA" == Paolo Amoroso writes: PA> rpgoldman at real-time.com writes: >>> In BEIRC, one can end up with an enormously long list of >>> candidate possibilities for completing a command, because IRC >>> has so many commands. The possibilities are not ordered at >>> all, so the list is pretty much useless. >>> >>> The following patch to input-editing would fix this problem by >>> sorting the set of possibilities alphabetically. PA> I deal with this by providing functions such as PA> COMPLETE-FROM-POSSIBILITIES with presorted lists of PA> possibilities. PA> OK. The alternative solution would involve modifying the PA> ACCEPT presentation method for COMMAND-NAME in commands.lisp. PA> The problem is that this would now involve a bunch of consing, PA> because I'd have to enumerate all the commands, sort them, and PA> then call the suggester on them. But perhaps that's a better PA> choice. PA> Follow-up question: This is being done by PA> complete-from-generator, rather than PA> complete-from-possibilities. So I don't explicitly create the PA> list of possibilities; instead I have a loop that does a bunch PA> of calls to SUGGEST. PA> A skim of the spec doesn't seem to show any guarantee that the PA> possibilities you get will appear in the same order they were PA> added by suggest. So does your solution work in this PA> location? PA> Note that this patch (I believe) only applies to PA> complete-from-generator, which doesn't have an obvoiusly good PA> alternative (unless we have the suggest guarantee I refer to PA> above). To be more clear, I believe that the above entails "this patch would not goof up your ability to send complete-from-possibilities a list sorted however you like it." Indeed, my solution is almost an instance of yours. R From david at lichteblau.com Sun Apr 9 17:03:34 2006 From: david at lichteblau.com (David Lichteblau) Date: Sun, 9 Apr 2006 19:03:34 +0200 Subject: [mcclim-devel] gtkairo Message-ID: <20060409170334.GA22760@gargravarr.knowledgetools.de> Hi, here's a somewhat functional GTK+ backend, using CFFI to interface with the C libraries. For drawing operations I have borrowed Gilbert Baumann's cairo medium (search&replaced to use cffi instead of alien and with minor updates for cairo 1.0), hence the name Gtkairo for the new backend. I probably don't have to explain why a GTK backend is interesting, but since using cairo means to interface with C anyway, it seems logical to go the full way to a native backend, eliminating the synchronization issues between the two parallel server connections (CLX and Xlib) present in Gilbert's original work. As a proof-of-concept, sliders, buttons, option- and check boxes are implemented as native widgets. As you can see in the screenshot below[1], scroll bars and menus are not done natively yet. Be warned that a lot of rough edges remain. * Display glitches. Notice how some weird bars drawn in what I think are background colors sometimes appear in the address book example. In the same example, the input cursor when typing and erasing characters is not getting removed properly, leaving a trace. Interestingly, when enabling antialiasing, the cursor is drawn blurry, which might indicate that non-integer coordinates are being used. Also, the presentation highlighting rectangle leaves traces if antialiasing is enabled (which is while I have disabled it for now). * The text cursor does not show the correct horizontal position in climacs. * Menus appear but do not really work. Worth fixing, even though we would rather want native menus in the long term. * The gadgets are only a quick hack. Colored buttons (clim-fig) are missing, the slider is not quite right. Inheriting from the standard gadget panes is bogus anyway, we should build them from scratch. * Should work on Windows but does not. Using the installer from gimp-win.sf.net I see an address book window, but there are cairo font warnings in the background and moving the mouse gives an error. Although the hordes of sbcl/win32 hackers might contribute a native Windows backend sooner or later, it would be nice to get Gtkairo working on Windows, too. * ... To install Gtkairo, extract the tarball[2] into your Backend directory and apply the trivial patch[3]. GTK+ 2.8 is required for the Cairo integration. Please test and improve ;-), David [1] http://www.lichteblau.com/blubba/gtkairo.png [2] http://www.lichteblau.com/blubba/gtkairo.tgz [3] http://www.lichteblau.com/blubba/gtkairo.diff From david at lichteblau.com Sun Apr 9 17:03:34 2006 From: david at lichteblau.com (David Lichteblau) Date: Sun, 9 Apr 2006 19:03:34 +0200 Subject: [mcclim-devel] gtkairo Message-ID: <20060409170334.GA22760@gargravarr.knowledgetools.de> Hi, here's a somewhat functional GTK+ backend, using CFFI to interface with the C libraries. For drawing operations I have borrowed Gilbert Baumann's cairo medium (search&replaced to use cffi instead of alien and with minor updates for cairo 1.0), hence the name Gtkairo for the new backend. I probably don't have to explain why a GTK backend is interesting, but since using cairo means to interface with C anyway, it seems logical to go the full way to a native backend, eliminating the synchronization issues between the two parallel server connections (CLX and Xlib) present in Gilbert's original work. As a proof-of-concept, sliders, buttons, option- and check boxes are implemented as native widgets. As you can see in the screenshot below[1], scroll bars and menus are not done natively yet. Be warned that a lot of rough edges remain. * Display glitches. Notice how some weird bars drawn in what I think are background colors sometimes appear in the address book example. In the same example, the input cursor when typing and erasing characters is not getting removed properly, leaving a trace. Interestingly, when enabling antialiasing, the cursor is drawn blurry, which might indicate that non-integer coordinates are being used. Also, the presentation highlighting rectangle leaves traces if antialiasing is enabled (which is while I have disabled it for now). * The text cursor does not show the correct horizontal position in climacs. * Menus appear but do not really work. Worth fixing, even though we would rather want native menus in the long term. * The gadgets are only a quick hack. Colored buttons (clim-fig) are missing, the slider is not quite right. Inheriting from the standard gadget panes is bogus anyway, we should build them from scratch. * Should work on Windows but does not. Using the installer from gimp-win.sf.net I see an address book window, but there are cairo font warnings in the background and moving the mouse gives an error. Although the hordes of sbcl/win32 hackers might contribute a native Windows backend sooner or later, it would be nice to get Gtkairo working on Windows, too. * ... To install Gtkairo, extract the tarball[2] into your Backend directory and apply the trivial patch[3]. GTK+ 2.8 is required for the Cairo integration. Please test and improve ;-), David [1] http://www.lichteblau.com/blubba/gtkairo.png [2] http://www.lichteblau.com/blubba/gtkairo.tgz [3] http://www.lichteblau.com/blubba/gtkairo.diff From csr21 at cam.ac.uk Mon Apr 10 09:54:50 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 10 Apr 2006 10:54:50 +0100 Subject: [mcclim-devel] question about curves and formatting graphs In-Reply-To: <31ffd3c405052417213200fe22@mail.gmail.com> (Andy Hefner's message of "Tue, 24 May 2005 20:21:26 -0400") References: <17036.59711.134835.283860@gargle.gargle.HOWL> <31ffd3c405052417213200fe22@mail.gmail.com> Message-ID: Andy Hefner writes: > To remedy this, I've attached an experimental patch which refactors > graph edge layout and incorporates the needed bookkeeping to associate > a graph node with its edges. This allowed my second attempt, also > attached, to drag graph nodes around, updating the edges correctly. > > Perhaps this is of some interest. I've been running with this for so long that I thought I would commit it; it seems to do no harm, and it was the last diff I had with HEAD. Andy: I've slapped on the traditional LGPL licence on your demo code; I hope that's alright. Cheers, Christophe From amoroso at mclink.it Mon Apr 10 12:17:42 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 14:17:42 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? Message-ID: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> When I update my working copy of McCLIM's CVS sources, I do a quick test to check that things still work fine. I run the CLIM Listener and evaluate a form that draws a monster graph: (time (clim-listener::com-show-class-subclasses t)) Until a few weeks ago, I got run times under 1 s (I seem to remember about 0.7-0.8 s) with CMUCL under Slackware Linux 10.0. With the latest McCLIM CVS sources and CMUCL Snapshot 2006-02 (19C), I now get times over 15 s, no matter whether I initialize multiprocessing with (mp::startup-idle-and-top-level-loops) or not. Can anybody confirm this? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From amoroso at mclink.it Mon Apr 10 12:21:57 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 14:21:57 +0200 Subject: [mcclim-devel] question about curves and formatting graphs References: <17036.59711.134835.283860@gargle.gargle.HOWL> <31ffd3c405052417213200fe22@mail.gmail.com> Message-ID: <87odz94o4a.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > Andy Hefner writes: > >> To remedy this, I've attached an experimental patch which refactors >> graph edge layout and incorporates the needed bookkeeping to associate >> a graph node with its edges. This allowed my second attempt, also >> attached, to drag graph nodes around, updating the edges correctly. [...] > I've been running with this for so long that I thought I would commit > it; it seems to do no harm, and it was the last diff I had with HEAD. Way cool. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From amoroso at mclink.it Mon Apr 10 12:28:18 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 14:28:18 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 10 Apr 2006 14:17:42 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> Message-ID: <87ek053999.fsf@plato.moon.paoloamoroso.it> Paolo Amoroso writes: > test to check that things still work fine. I run the CLIM Listener > and evaluate a form that draws a monster graph: > > (time (clim-listener::com-show-class-subclasses t)) > > Until a few weeks ago, I got run times under 1 s (I seem to remember > about 0.7-0.8 s) with CMUCL under Slackware Linux 10.0. With the This refers to a 2.8 GHz Pentium IV machine with 2 GB of RAM. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From athas at sigkill.dk Mon Apr 10 13:46:56 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Mon, 10 Apr 2006 15:46:56 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 10 Apr 2006 14:17:42 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> Message-ID: <87mzetwnjj.fsf@sigkill.dk> Paolo Amoroso writes: > Can anybody confirm this? On my 1100MHz Athlon with 512MiB of RAM, that operation gives the following timing output: Evaluation took: 5.514 seconds of real time 5.418177 seconds of user run time 0.094985 seconds of system run time 0 page faults and 61,853,896 bytes consed. This is with CLIM-desktop and some minor stuff loaded. Are you sure you are not running with more loaded classes now than the last time you ran the test? -- \ Troels "Athas" Henriksen /\ - Insert witty signature From smustudent1 at yahoo.com Mon Apr 10 17:44:07 2006 From: smustudent1 at yahoo.com (C Y) Date: Mon, 10 Apr 2006 10:44:07 -0700 (PDT) Subject: [mcclim-devel] gtkairo In-Reply-To: <20060409170334.GA22760@gargravarr.knowledgetools.de> Message-ID: <20060410174407.59328.qmail@web31707.mail.mud.yahoo.com> --- David Lichteblau wrote: > Hi, > > here's a somewhat functional GTK+ backend, using CFFI to interface > with the C libraries. Coool! Are there any specific versions of CFFI, and specific lisps that are needed, or should it work wherever CFFI does? Cheers, CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From david at lichteblau.com Mon Apr 10 18:02:33 2006 From: david at lichteblau.com (David Lichteblau) Date: Mon, 10 Apr 2006 20:02:33 +0200 Subject: [mcclim-devel] gtkairo In-Reply-To: <20060410174407.59328.qmail@web31707.mail.mud.yahoo.com> References: <20060409170334.GA22760@gargravarr.knowledgetools.de> <20060410174407.59328.qmail@web31707.mail.mud.yahoo.com> Message-ID: <20060410180233.GA29395@gargravarr.knowledgetools.de> Quoting C Y (smustudent1 at yahoo.com): > Coool! Are there any specific versions of CFFI, and specific lisps > that are needed, or should it work wherever CFFI does? Tested only on SBCL, but no inherent portability issues. One exception perhaps: If you are using one of the Lisps with userland threads that do not like blocking in native code, look for the the call to sb-sys:wait-until-fd-usable in event.lisp and find a replacement. And the other big problem was pointed out by Christophe: The original tarball is not 64 bit clean. The attached patch fixes that (tested briefly on SBCL/x86-64). David -------------- next part -------------- diff -ur gtkairo/event.lisp gtkairo-64bitclean/event.lisp --- gtkairo/event.lisp 2006-04-09 18:38:05.000000000 +0200 +++ gtkairo-64bitclean/event.lisp 2006-04-10 19:56:35.000000000 +0200 @@ -40,9 +40,8 @@ GDK_ENTER_NOTIFY_MASK GDK_LEAVE_NOTIFY_MASK #+nil GDK_STRUCTURE_MASK)) - (setf (cffi:foreign-slot-value widget 'gtkwidget 'flags) - (logior (cffi:foreign-slot-value widget 'gtkwidget 'flags) - GTK_CAN_FOCUS)) + (setf (gtkwidget-flags widget) + (logior (gtkwidget-flags widget) GTK_CAN_FOCUS)) (connect-signal widget "expose-event" 'expose-handler) (connect-signal widget "motion-notify-event" 'motion-notify-handler) (connect-signal widget "button-press-event" 'button-handler) diff -ur gtkairo/gtk-ffi.lisp gtkairo-64bitclean/gtk-ffi.lisp --- gtkairo/gtk-ffi.lisp 2006-04-09 18:38:05.000000000 +0200 +++ gtkairo-64bitclean/gtk-ffi.lisp 2006-04-10 19:56:35.000000000 +0200 @@ -112,14 +112,20 @@ (gdk_threads_leave))))) -;; GROVELME +;;; GROVELME -(cffi:defcstruct gtkwidget +;; must be a separate structure definition in order for padding on AMD64 +;; to work properly. +(cffi:defcstruct gtkobject (gtype :unsigned-long) ;GTypeInstance (ref_count :unsigned-int) ;GObject (qdata :pointer) ; -"- (flags :uint32) ;GtkObject - (private_flags :uint16) ;von hier an endlich GtkWidget + ) + +(cffi:defcstruct gtkwidget + (header gtkobject) + (private_flags :uint16) (state :uint8) (saved_state :uint8) (name :pointer) @@ -133,6 +139,16 @@ (gdkwindow :pointer) (parent :pointer)) +(defun gtkwidget-header (widget) + (cffi:foreign-slot-value widget 'gtkwidget 'header)) + +(defun gtkwidget-flags (widget) + (cffi:foreign-slot-value (gtkwidget-header widget) 'gtkobject 'flags)) + +(defun (setf gtkwidget-flags) (newval widget) + (setf (cffi:foreign-slot-value (gtkwidget-header widget) 'gtkobject 'flags) + newval)) + (cffi:defcstruct gdkeventexpose (type :int) (gdkwindow :pointer) From amoroso at mclink.it Mon Apr 10 18:38:19 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 20:38:19 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <87mzetwnjj.fsf@sigkill.dk> (Troels Henriksen's message of "Mon, 10 Apr 2006 15:46:56 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <87mzetwnjj.fsf@sigkill.dk> Message-ID: <874q11nun8.fsf@plato.moon.paoloamoroso.it> Troels Henriksen writes: > This is with CLIM-desktop and some minor stuff loaded. Are you sure > you are not running with more loaded classes now than the last time > you ran the test? For such tests I use a freshly loaded CLIM Listener, with nothing else. Can the additional classes justify an order of magnitude difference in performance? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From strandh at labri.fr Mon Apr 10 18:13:51 2006 From: strandh at labri.fr (Robert Strandh) Date: Mon, 10 Apr 2006 20:13:51 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> Message-ID: <17466.41055.313537.718150@serveur5.labri.fr> Hello, Paolo Amoroso writes: > When I update my working copy of McCLIM's CVS sources, I do a quick > test to check that things still work fine. I run the CLIM Listener > and evaluate a form that draws a monster graph: > > (time (clim-listener::com-show-class-subclasses t)) > > Until a few weeks ago, I got run times under 1 s (I seem to remember > about 0.7-0.8 s) with CMUCL under Slackware Linux 10.0. With the > latest McCLIM CVS sources and CMUCL Snapshot 2006-02 (19C), I now get > times over 15 s, no matter whether I initialize multiprocessing with > (mp::startup-idle-and-top-level-loops) or not. > > Can anybody confirm this? Most likely you have run into the same problem I did with Gsharp, namely that output-record creation is now slower with tree-structured output records. You should be able to ask for a sequence output record, or you can do what I did with Gsharp, namely organize the output records into smaller hierarchical units. Take care, -- 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 csr21 at cam.ac.uk Mon Apr 10 18:39:54 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 10 Apr 2006 19:39:54 +0100 Subject: [mcclim-devel] gtkairo In-Reply-To: <20060410180233.GA29395@gargravarr.knowledgetools.de> (David Lichteblau's message of "Mon, 10 Apr 2006 20:02:33 +0200") References: <20060409170334.GA22760@gargravarr.knowledgetools.de> <20060410174407.59328.qmail@web31707.mail.mud.yahoo.com> <20060410180233.GA29395@gargravarr.knowledgetools.de> Message-ID: David Lichteblau writes: > And the other big problem was pointed out by Christophe: The original > tarball is not 64 bit clean. The attached patch fixes that (tested > briefly on SBCL/x86-64). Excellent. (might fixing the (gtype :unsigned-long) in gtkobject, making it a pointer, fix the problem with windows?) In any case, I suggest you go ahead and check this in; this will make a nice headline to the next McCLIM release :-) Cheers, Christophe From amoroso at mclink.it Mon Apr 10 18:44:41 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 20:44:41 +0200 Subject: [mcclim-devel] gtkairo In-Reply-To: <20060410180233.GA29395@gargravarr.knowledgetools.de> (David Lichteblau's message of "Mon, 10 Apr 2006 20:02:33 +0200") References: <20060409170334.GA22760@gargravarr.knowledgetools.de> <20060410174407.59328.qmail@web31707.mail.mud.yahoo.com> <20060410180233.GA29395@gargravarr.knowledgetools.de> Message-ID: <87fyklmfs6.fsf@plato.moon.paoloamoroso.it> David Lichteblau writes: > Tested only on SBCL, but no inherent portability issues. What's the minimum version of GTK+ required? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Mon Apr 10 18:46:50 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 10 Apr 2006 19:46:50 +0100 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <17466.41055.313537.718150@serveur5.labri.fr> (Robert Strandh's message of "Mon, 10 Apr 2006 20:13:51 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Hello, > > Paolo Amoroso writes: > > When I update my working copy of McCLIM's CVS sources, I do a quick > > test to check that things still work fine. I run the CLIM Listener > > and evaluate a form that draws a monster graph: > > > > (time (clim-listener::com-show-class-subclasses t)) > > > > Until a few weeks ago, I got run times under 1 s (I seem to remember > > about 0.7-0.8 s) with CMUCL under Slackware Linux 10.0. With the > > latest McCLIM CVS sources and CMUCL Snapshot 2006-02 (19C), I now get > > times over 15 s, no matter whether I initialize multiprocessing with > > (mp::startup-idle-and-top-level-loops) or not. > > > > Can anybody confirm this? > > Most likely you have run into the same problem I did with Gsharp, > namely that output-record creation is now slower with tree-structured > output records. You should be able to ask for a sequence output > record, or you can do what I did with Gsharp, namely organize the > output records into smaller hierarchical units. I would be surprised to find this kind of performance regression for such a simple test (which, furthermore, is probably dominated by the cost of computing the graph layout); I think that Andy and Andreas measured the slowdown from inserting tree output records as a relatively small multiple for about 10000 output records -- not a factor of 20. Admittedly I still haven't optimized the spatial trees for two-dimensions, nor even removed the debugging ordering-constraint-checking code. Be that as it may, rather than speculating further I would suggest to Paolo that he try with the mcclim sources of "a few weeks ago" in the same lisp and compares the results. If there is a difference, then bisecting the cvs checkins should find the offending commit in a small amount of time. Cheers, Christophe From amoroso at mclink.it Mon Apr 10 19:00:23 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 21:00:23 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: (Christophe Rhodes's message of "Mon, 10 Apr 2006 19:46:50 +0100") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> Message-ID: <87bqv9mf20.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > Be that as it may, rather than speculating further I would suggest to > Paolo that he try with the mcclim sources of "a few weeks ago" in the > same lisp and compares the results. If there is a difference, then Which CVS tag can I use for accessing such sources? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From amoroso at mclink.it Mon Apr 10 19:16:26 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 21:16:26 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <31ffd3c40604101212q1eb98821odad0a22e62a6fb0e@mail.gmail.com> (Andy Hefner's message of "Mon, 10 Apr 2006 15:12:20 -0400") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <87mzetwnjj.fsf@sigkill.dk> <874q11nun8.fsf@plato.moon.paoloamoroso.it> <31ffd3c40604101212q1eb98821odad0a22e62a6fb0e@mail.gmail.com> Message-ID: <87lkudkzqt.fsf@plato.moon.paoloamoroso.it> "Andy Hefner" writes: > Is this with or without Christophe's commit from today of my graph > edge patch? I've never looked at the performance impact of that on I have updated my working copy of the CVS sources about 7-8 hours ago. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From ahefner at gmail.com Mon Apr 10 19:12:20 2006 From: ahefner at gmail.com (Andy Hefner) Date: Mon, 10 Apr 2006 15:12:20 -0400 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <874q11nun8.fsf@plato.moon.paoloamoroso.it> References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <87mzetwnjj.fsf@sigkill.dk> <874q11nun8.fsf@plato.moon.paoloamoroso.it> Message-ID: <31ffd3c40604101212q1eb98821odad0a22e62a6fb0e@mail.gmail.com> Is this with or without Christophe's commit from today of my graph edge patch? I've never looked at the performance impact of that on large graphs. On 4/10/06, Paolo Amoroso wrote: > Troels Henriksen writes: > > > This is with CLIM-desktop and some minor stuff loaded. Are you sure > > you are not running with more loaded classes now than the last time > > you ran the test? > > For such tests I use a freshly loaded CLIM Listener, with nothing > else. Can the additional classes justify an order of magnitude > difference in performance? > > > Paolo > -- > Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From amoroso at mclink.it Mon Apr 10 19:37:03 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 21:37:03 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> Message-ID: <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > Be that as it may, rather than speculating further I would suggest to > Paolo that he try with the mcclim sources of "a few weeks ago" in the > same lisp and compares the results. If there is a difference, then I have checked out a fresh copy of McCLIM's CVS sources with: cvs co -D 2006-03-25 mcclim The test: (time (clim-listener::com-show-class-subclasses t)) takes about 0.92 s on the same system, i.e. a 2.8 GHz Pentium IV machine running Slackware Linux 10.0 and CMUCL Snapshot 2006-02 (19C). Compilation with CMUCL remained broken for about a month before late March 2006. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Mon Apr 10 19:40:52 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 10 Apr 2006 20:40:52 +0100 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <87bqv9mf20.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 10 Apr 2006 21:00:23 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> <87bqv9mf20.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Christophe Rhodes writes: > >> Be that as it may, rather than speculating further I would suggest to >> Paolo that he try with the mcclim sources of "a few weeks ago" in the >> same lisp and compares the results. If there is a difference, then > > Which CVS tag can I use for accessing such sources? You can use -D'2006-04-01 23:59 UTC' to access the code present in the repository at, well, 23:59 UTC on the first of April. Generalise to taste :-) Cheers, Christophe From csr21 at cam.ac.uk Mon Apr 10 19:47:44 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 10 Apr 2006 20:47:44 +0100 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 10 Apr 2006 21:37:03 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Christophe Rhodes writes: > >> Be that as it may, rather than speculating further I would suggest to >> Paolo that he try with the mcclim sources of "a few weeks ago" in the >> same lisp and compares the results. If there is a difference, then > > I have checked out a fresh copy of McCLIM's CVS sources with: > > cvs co -D 2006-03-25 mcclim > > The test: > > (time (clim-listener::com-show-class-subclasses t)) > > takes about 0.92 s on the same system, i.e. a 2.8 GHz Pentium IV > machine running Slackware Linux 10.0 and CMUCL Snapshot 2006-02 > (19C). > > Compilation with CMUCL remained broken for about a month before late > March 2006. But that's OK, because your timing means that any performance regression happened /after/ the 25th of March. So you can track down any change between the 25th and now on your system to identify the regressing commit. Cheers, Christophe From amoroso at mclink.it Mon Apr 10 20:05:42 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 22:05:42 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 10 Apr 2006 21:37:03 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> Message-ID: <878xqdi4bt.fsf@plato.moon.paoloamoroso.it> Paolo Amoroso writes: > I have checked out a fresh copy of McCLIM's CVS sources with: > > cvs co -D 2006-03-25 mcclim > > The test: > > (time (clim-listener::com-show-class-subclasses t)) > > takes about 0.92 s on the same system, i.e. a 2.8 GHz Pentium IV With sources checked out with the -D 2006-04-05 option, I get times around 0.9 s. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From amoroso at mclink.it Mon Apr 10 20:13:15 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 22:13:15 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <878xqdi4bt.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 10 Apr 2006 22:05:42 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> <878xqdi4bt.fsf@plato.moon.paoloamoroso.it> Message-ID: <871ww5i3z8.fsf@plato.moon.paoloamoroso.it> Paolo Amoroso writes: > With sources checked out with the -D 2006-04-05 option, I get times > around 0.9 s. I get as less as 0.83 s with 2006-04-08. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Mon Apr 10 20:14:21 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 10 Apr 2006 21:14:21 +0100 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <878xqdi4bt.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 10 Apr 2006 22:05:42 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> <878xqdi4bt.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Paolo Amoroso writes: > >> I have checked out a fresh copy of McCLIM's CVS sources with: >> >> cvs co -D 2006-03-25 mcclim >> >> The test: >> >> (time (clim-listener::com-show-class-subclasses t)) >> >> takes about 0.92 s on the same system, i.e. a 2.8 GHz Pentium IV > > With sources checked out with the -D 2006-04-05 option, I get times > around 0.9 s. Bother. So if you do get times of 15s from HEAD, then it is Andy's bookkeeping / graph edge stuff. Darn. Christophe From amoroso at mclink.it Mon Apr 10 20:21:30 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 22:21:30 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> <878xqdi4bt.fsf@plato.moon.paoloamoroso.it> <871ww5i3z8.fsf@plato.moon.paoloamoroso.it> Message-ID: <87odz9gp11.fsf@plato.moon.paoloamoroso.it> Paolo Amoroso writes: > I get as less as 0.83 s with 2006-04-08. Less than 0.9 s with 2006-04-10. I think there is enough information to identify the relevant changes. Do you need more tests? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From amoroso at mclink.it Mon Apr 10 20:28:01 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 10 Apr 2006 22:28:01 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <87odz9gp11.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 10 Apr 2006 22:21:30 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> <878xqdi4bt.fsf@plato.moon.paoloamoroso.it> <871ww5i3z8.fsf@plato.moon.paoloamoroso.it> <87odz9gp11.fsf@plato.moon.paoloamoroso.it> Message-ID: <874q11goq6.fsf@plato.moon.paoloamoroso.it> Paolo Amoroso writes: > Less than 0.9 s with 2006-04-10. I think there is enough information > to identify the relevant changes. Do you need more tests? More precisely, as low as 0.75 s (2006-04-10). Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From pw at snoopy.mv.com Tue Apr 11 13:46:17 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 11 Apr 2006 09:46:17 -0400 Subject: [mcclim-devel] accept-values-pane and views Message-ID: <20060411134617.5023.qmail@copper.mv.net> I have a mostly portable implementation of ACCEPT-VALUES-PANE running in Lispworks CLIM. For those that don't know, the accept-values-pane is a gadget based non modal dialog. A display function for an accept-values-pane might contain code like this: (with-slots (some-value) pane (setq some-value (accept '(member A B C) :stream pane :default some-value :view '(radio-box-view :orientation :vertical) :prompt "Pick one"))) ACCEPT is supposed to do apply MAKE-INSTANCE to the CAR and CDR of the :view parameter and the stuff in the cdr is passed on to the gadget. In this example the presentation method ACCEPT-PRESENT-DEFAULT calls (apply 'MAKE-PANE 'RADIO-BOX-PANE VIEW-OPTIONS). But, there is no defined way to get the supplied values. Lispworks CLIM has an internal function named CLIM-INTERNALS::VIEW-GADGET-INITARGS that retrieves them. It seems that the VIEW class has only two functions. The first is to be a class so generic functions can specialize on subclasses of it, and the second is to pass gadget options via the :view keyword to ACCEPT. This functionality is pretty important for usable gadget based dialogs so I hope the McCLIM architects can consider how this can be added to the code base. Paul From moore at bricoworks.com Tue Apr 11 14:50:07 2006 From: moore at bricoworks.com (Timothy Moore) Date: Tue, 11 Apr 2006 16:50:07 +0200 Subject: [mcclim-devel] accept-values-pane and views In-Reply-To: <20060411134617.5023.qmail@copper.mv.net> References: <20060411134617.5023.qmail@copper.mv.net> Message-ID: <443BC21F.7080608@bricoworks.com> Paul Werkowski wrote: > I have a mostly portable implementation of ACCEPT-VALUES-PANE > running in Lispworks CLIM. For those that don't know, > the accept-values-pane is a gadget based non modal dialog. > ... > This functionality is pretty important for usable > gadget based dialogs so I hope the McCLIM architects > can consider how this can be added to the code base. > > Paul I don't quite understand. Do you have an implementation of accept values panes that you'd like to share, or you're using it in CLIM and would like to use it in McCLIM too? This is an important project that shouldn't be too hard to knock off, given the structure of the current accepting-values code, command table, etc. We would have to understand / solve keyboard focus issues. As for view object values, there is code in classic CLIM to pass on the "init args" passed to a view object as extra arguments to make-pane; it is probably worthwhile to do that in McCLIM too. Tim From pw at snoopy.mv.com Tue Apr 11 15:20:27 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 11 Apr 2006 11:20:27 -0400 Subject: [mcclim-devel] accept-values-pane and views Message-ID: <20060411152027.17222.qmail@copper.mv.net> > I don't quite understand. Do you have an implementation of accept values > panes that you'd like to share, or you're using it in CLIM and would > like to use it in McCLIM too? This is an important project that Well, I've been using accept-values-pane and accepting-values :own-window t in CLIM for a few years now (never used interactor at all) and got to wondering what the magic was. So I played around a bit and found that accept-values-pane was very simple to implement with most of the hair in converting to/from completion ptypes. I think that is mostly solved now as well. Now that with-output-as-gadget has a chance of working in McCLIM, this mostly portable code could be messaged into a McCLIM accept-values-pane. McCLIM's accepting-values mechanism was not up to handling with-output-as-gadget when I last checked in December. I can send you what I have if you are interested. It may be of some help. > As for view object values, there is code in classic CLIM to pass on the > "init args" passed to a view object as extra arguments to make-pane; it > is probably worthwhile to do that in McCLIM too. I guess I missed that in the spec. Can you give me a pointer? Paul > From pw at snoopy.mv.com Thu Apr 13 17:27:13 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Thu, 13 Apr 2006 13:27:13 -0400 Subject: [mcclim-devel] radio-box gadget Message-ID: <20060413172714.27200.qmail@copper.mv.net> FYI Seems that CLIM (lispworks at least) implements the :name-key and :value-key options (found in the documentation for list-pane and option-pane) for radio-box and check-box as well. This either an undocumented extension or an omission from the spec. Having that available aids handling presentation-types like member-alist and subset-alist. With these types, the gadget gets a :choices list like ((:a . 1)(:b 2)) and wants to show check-boxes with names A and B. Selecting one/some of these results in a gadget value that is made up from the :choices list. For radio-box the gadget-value might be (:a . 1) while the check-box form would yield ((:a . 1)). The way the spec is written, those conversions have to be done outside the gadget itself. Does anyone know if other CLIM implementations do this too? Should McCLIM? Paul From johnc at yagc.ndo.co.uk Fri Apr 14 10:04:10 2006 From: johnc at yagc.ndo.co.uk (John Connors) Date: Fri, 14 Apr 2006 11:04:10 +0100 Subject: [mcclim-devel] clim-extensions.lisp Message-ID: <443F739A.40803@yagc.ndo.co.uk> I note that clim-extensions.lisp isn't in the clim-clx asdf defsystem form despite being defined in that package; is there a reason for this? -- +--------------------------------------------------------+ |Cyborg Animation Programmer | johnc at yagc.ndo.co.uk| |http://badbyteblues.blogspot.com -----------------------| +--------------------------------------------------------+ From csr21 at cam.ac.uk Sun Apr 16 11:56:18 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 16 Apr 2006 12:56:18 +0100 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <87odz9gp11.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 10 Apr 2006 22:21:30 +0200") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> <878xqdi4bt.fsf@plato.moon.paoloamoroso.it> <871ww5i3z8.fsf@plato.moon.paoloamoroso.it> <87odz9gp11.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Paolo Amoroso writes: > >> I get as less as 0.83 s with 2006-04-08. > > Less than 0.9 s with 2006-04-10. I think there is enough information > to identify the relevant changes. Do you need more tests? Well, now we do know what the change was. I can't honestly see why it should slow everything down so much, though; could you profile the CLIMI package and post the top few results? A statistical profile would also be useful if you could get one. (I wonder if the problem is as simple as creating two hash tables per node... surely that can't be such a bottleneck. Could you also find out how many nodes there are in your graph, and time the creation of twice that many hash tables with (make-hash-table)? The other thing to look at is for collisions in your hash tables; check the EDGES-FROM slot of something with a lot of direct subclasses, say STRUCTURE-CLASS or CONDITION or NUMBER, and see if all of the entries are in the same bucket of the hash table) Cheers, Christophe From amoroso at mclink.it Sun Apr 16 13:20:12 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Sun, 16 Apr 2006 15:20:12 +0200 Subject: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: (Christophe Rhodes's message of "Sun, 16 Apr 2006 12:56:18 +0100") References: <87wtdx4obd.fsf@plato.moon.paoloamoroso.it> <17466.41055.313537.718150@serveur5.labri.fr> <87wtdxjk80.fsf@plato.moon.paoloamoroso.it> <878xqdi4bt.fsf@plato.moon.paoloamoroso.it> <871ww5i3z8.fsf@plato.moon.paoloamoroso.it> <87odz9gp11.fsf@plato.moon.paoloamoroso.it> Message-ID: <87y7y57j3n.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > should slow everything down so much, though; could you profile the > CLIMI package and post the top few results? A statistical profile [...] The message I sent you with this information is awaiting moderator approval because it is about 60 KB long, which is above the allowed size of 40 KB. In the meantime, I'm going to forward it to you offlist. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Sun Apr 16 13:49:30 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 16 Apr 2006 14:49:30 +0100 Subject: Fwd: Re: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <87u08t7j33.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Sun, 16 Apr 2006 15:20:32 +0200") References: <87u08t7j33.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: >> twice that many hash tables with (make-hash-table)? The other thing > > CL-USER> (time (dotimes (i (* 2 824)) > (make-hash-table))) > ; Compiling LAMBDA NIL: > ; Compiling Top-Level Form: > > ; Evaluation took: > ; 6,648 CPU cycles It's elided the creation, I'm afraid. Can you do (defvar *foo*) (time (dotimes (i (* 2 824)) (setq *foo* (make-hash-table)))) ? > ; > NIL > CL-USER> > > >> to look at is for collisions in your hash tables; check the EDGES-FROM >> slot of something with a lot of direct subclasses, say STRUCTURE-CLASS >> or CONDITION or NUMBER, and see if all of the entries are in the same >> bucket of the hash table) > > I'm not sure I understand what you mean. I used the SLIME inspector > to inspect the output of, say, (find-class 'structure-class). I > include the output below, which does not seem to have any EDGES-FROM > slot. I think the edges-from should be in the graph node output record. I'm not entirely sure how to get at one of those, but you could start by inspecting clim:*application-frame* from the slime inspector, finding the listener interactor pane, finding its output history, and looking at the output records in there. > 588,259,376 | 1,111 | 15.158 | 0.01364 | 529,486 | CLIM-INTERNALS::LAYOUT-EDGE-1 > 1,111: # > 1,470,608 | 2,222 | 0.056 | 0.00003 | 662 | CLIM-INTERNALS::ENSURE-EDGE-RECORD > 1,111: # > 1,111: # Well, that's moderately conclusive: the cost seems to be in LAYOUT-EDGE-1, not in ENSURE-EDGE-RECORD. Which is weird, because I can't really see what LAYOUT-EDGE-1 is doing that is so ludicrously expensive. Can you do the same thing, but with the CLIM package profiled additionally? (And then maybe one with CLIM but not CLIM-INTERNALS profiled?) The first 10 or so entries in each profile will probably suffice. (Maybe CLEAR-OUTPUT-RECORD is expensive?) Cheers, Christophe From amoroso at mclink.it Sun Apr 16 15:03:13 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Sun, 16 Apr 2006 17:03:13 +0200 Subject: Fwd: Re: [mcclim-devel] Severe performance regression with latest CVS sources? References: <87u08t7j33.fsf@plato.moon.paoloamoroso.it> Message-ID: <878xq536mm.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > It's elided the creation, I'm afraid. Can you do > (defvar *foo*) > (time (dotimes (i (* 2 824)) (setq *foo* (make-hash-table)))) > ? Doh... CL-USER> (defvar *foo*) *FOO* CL-USER> (time (dotimes (i (* 2 824)) (setq *foo* (make-hash-table)))) ; Compiling LAMBDA NIL: ; Compiling Top-Level Form: ; Evaluation took: ; 0.01 seconds of real time ; 0.004 seconds of user run time ; 0.002999 seconds of system run time ; 20,036,532 CPU cycles ; 0 page faults and ; 2,386,304 bytes consed. ; NIL CL-USER> > I think the edges-from should be in the graph node output record. I'm > not entirely sure how to get at one of those, but you could start by > inspecting clim:*application-frame* from the slime inspector, finding > the listener interactor pane, finding its output history, and looking > at the output records in there. Here is the interactor's output history just after generating the graph: An object. [type: CLIM:STANDARD-TREE-OUTPUT-HISTORY] -------------------- Class: # Slots: STREAM = #3=# COORDINATES = #(0 0 4950 12357) PARENT = NIL X = 0 Y = 0 IN-MOVING-P = NIL CHILDREN = # :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(81,12339) - (724,12357)> :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(0,24679/2) - (81,24709/2)> :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(0,17) - (4950,24645/2)> :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(81,0) - (360,15)> :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(81,0) - (724,17)> :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(0,0) - (81,15)> :DATUM #))>> CHILDREN-HASH = #5=# LAST-INSERTION-NR = 13 Where should I look further? > expensive. Can you do the same thing, but with the CLIM package > profiled additionally? (And then maybe one with CLIM but not > CLIM-INTERNALS profiled?) The first 10 or so entries in each profile > will probably suffice. (Maybe CLEAR-OUTPUT-RECORD is expensive?) I include the results below. Note, however, that I couldn't answer yes to SLIME's question on whether to also profile methods, because otherwise I get this error when issuing the `M-x slime-profile-report' command: Error in function PROFILE::PI-OR-LOSE: No profile info for (PCL:FAST-METHOD CLIM:PROCESS-NEXT-EVENT (CLIM:BASIC-PORT)) [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT] Return to Top-Level. Backtrace: 0: (PROFILE::PI-OR-LOSE (PCL:FAST-METHOD CLIM:PROCESS-NEXT-EVENT (CLIM:BASIC-PORT))) 1: (PROFILE::%REPORT-TIMES ((PCL:FAST-METHOD CLIM-INTERNALS::DEFAULT-COMPLETION-NAME-KEY #) (PCL:FAST-METHOD CLIM-INTERNALS::DEFAULT-COMPLETION-NAME-KEY #) (PCL:FAST-METHOD CLIM-INTERNALS::DEFAULT-COMPLETION-NAME-KEY #) (PCL:FAST-METHOD CLIM-INTERNALS::DEFAULT-COMPLETION-NAME-KEY #) (PCL:FAST-METHOD CLIM-INTERNALS::DEFAULT-COMPLETION-NAME-KEY #) ...) :PRINTFUNCTION NIL) 2: ("DEFUN EVAL-FOR-EMACS") 3: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK NIL (T T)) #<#1=unused-arg> #<#1#> # #) 4: ("DEFUN HANDLE-REQUEST") 5: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK NIL (T T)) #<#1=unused-arg> #<#1#> # #) --more-- Paolo ======================================================================== PROFILED PACKAGES: CLIMI; CLIM (no methods) Consed | Calls | Secs | Sec/Call | Bytes/C. | Name: ----------------------------------------------------------------------- 609,294,888 | 2,021 | 17.476 | 0.00865 | 301,482 | CLIM:MAP-OVER-OUTPUT-RECORDS 1,132: # 828: # 12: # 12: # 11: # 136,259,960 | 290 | 4.179 | 0.01441 | 469,862 | CLIM-INTERNALS::MAP-OVER-TREE-OUTPUT-RECORDS 268: # 13: # 9: # 208,200 | 7 | 2.430 | 0.34714 | 29,743 | (PCL:FAST-METHOD CLIM-INTERNALS::EVENT-QUEUE-LISTEN-OR-WAIT (CLIM-INTERNALS::STANDARD-EVENT-QUEUE)) 7: # 2,142,376 | 3,881 | 0.312 | 0.00008 | 552 | CLIM:MAKE-BOUNDING-RECTANGLE 3,869: # 12: # 1,092,544 | 7,586 | 0.175 | 0.00002 | 144 | CLIM:MERGE-TEXT-STYLES 5,926: # 827: # 827: # 3: # 3: # 2,167,264 | 1,246 | 0.108 | 0.00009 | 1,739 | CLIM:MEDIUM-DRAW-POLYGON* 1,217: # 29: # 1,530,936 | 1,109 | 0.098 | 0.00009 | 1,380 | CLIM:DRAW-ARROW* 1,109: # 907,424 | 1,109 | 0.098 | 0.00009 | 818 | CLIM:MAKE-ROTATION-TRANSFORMATION* 1,109: # 2,407,712 | 1,158 | 0.098 | 0.00008 | 2,079 | CLIM:MEDIUM-DRAW-LINE* 1,109: # 49: # [...] ------------------------------------------------------------------- 782,665,592 | 2,348,996 | 26.619 | | | Total 1465 functions were not called. See profile::*no-calls* for a list ======================================================================== PROFILED PACKAGES: CLIM (no methods) Consed | Calls | Secs | Sec/Call | Bytes/C. | Name: ----------------------------------------------------------------------- 609,332,232 | 2,653 | 17.739 | 0.00669 | 229,677 | CLIM:MAP-OVER-OUTPUT-RECORDS 1,353: # 828: # 148: # 148: # 137: # 1,546,512 | 144 | 12.439 | 0.08638 | 10,740 | CLIM:STREAM-INPUT-WAIT 144: # 11,474,312 | 1 | 12.200 | 12.20000 | 11,474,312 | CLIM:COMMAND-LINE-READ-REMAINING-ARGUMENTS-FOR-PARTIAL-COMMAND 1: # 145,076,320 | 3,567 | 4.686 | 0.00131 | 40,672 | CLIM:MAP-OVER-OUTPUT-RECORDS-CONTAINING-POSITION 3,564: # 3: # 1,034,544 | 145 | 0.319 | 0.00220 | 7,135 | CLIM:HIGHLIGHT-APPLICABLE-PRESENTATION 145: # 3,077,808 | 7 | 0.190 | 0.02714 | 439,687 | CLIM:STREAM-ACCEPT 6: # 1: # 5,562,064 | 823 | 0.187 | 0.00023 | 6,758 | CLIM:INVOKE-WITH-OUTPUT-TO-OUTPUT-RECORD 822: # 1: # 4,623,008 | 1,246 | 0.165 | 0.00013 | 3,710 | CLIM:MEDIUM-DRAW-POLYGON* 1,217: # 29: # 1,698,080 | 1,109 | 0.156 | 0.00014 | 1,531 | CLIM:DRAW-ARROW* 1,109: # 2,442,360 | 1,183 | 0.115 | 0.00010 | 2,065 | CLIM:MEDIUM-DRAW-LINE* 1,117: # 66: # 411,032 | 1 | 0.100 | 0.10000 | 411,032 | CLIM:LAYOUT-GRAPH-NODES 1: # 1,687,088 | 1 | 0.090 | 0.09000 | 1,687,088 | CLIM:LAYOUT-GRAPH-EDGES 1: # [...] ------------------------------------------------------------------- 813,068,904 | 2,535,994 | 49.557 | | | Total 498 functions were not called. See profile::*no-calls* for a list ======================================================================== -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Sun Apr 16 20:42:11 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 16 Apr 2006 21:42:11 +0100 Subject: Fwd: Re: [mcclim-devel] Severe performance regression with latest CVS sources? In-Reply-To: <878xq536mm.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Sun, 16 Apr 2006 17:03:13 +0200") References: <87u08t7j33.fsf@plato.moon.paoloamoroso.it> <878xq536mm.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Christophe Rhodes writes: >> I think the edges-from should be in the graph node output record. I'm >> not entirely sure how to get at one of those, but you could start by >> inspecting clim:*application-frame* from the slime inspector, finding >> the listener interactor pane, finding its output history, and looking >> at the output records in there. > > Here is the interactor's output history just after generating the > graph: > > An object. > [type: CLIM:STANDARD-TREE-OUTPUT-HISTORY] > -------------------- > Class: # > Slots: > STREAM = #3=# > COORDINATES = #(0 0 4950 12357) > PARENT = NIL > X = 0 > Y = 0 > IN-MOVING-P = NIL > CHILDREN = # :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(81,12339) - (724,12357)> :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(0,24679/2) - (81,24709/2)> :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(0,17) - (4950,24645/2)> :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(81,0) - (360,15)> :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(81,0) - (724,17)> :DATUM #) #S(SPATIAL-TREES-IMPL::LEAF-NODE-ENTRY :RECTANGLE #<(0,0) - (81,15)> :DATUM #))>> > CHILDREN-HASH = #5=# > LAST-INSERTION-NR = 13 > > Where should I look further? Somewhere in the CHILDREN slot. I can't be much more specific, I'm afraid. > Consed | Calls | Secs | Sec/Call | Bytes/C. | Name: > ----------------------------------------------------------------------- > 609,294,888 | 2,021 | 17.476 | 0.00865 | 301,482 | CLIM:MAP-OVER-OUTPUT-RECORDS > 1,132: # {58EB3847}> > 828: # {58C0AF87}> > 12: # {58BA4677}> > 12: # > 11: # {58BA1007}> Hm. On the one hand, the use of MAP-OVER-OUTPUT-RECORDS is going to lead to O(N^2) behaviour in %TREE-RECOMPUTE-EXTENT* if one output record at a time is added to the graph output record. On the other hand, I think the code for %TREE-RECOMPUTE-EXTENT is completely unnecessary for TREE-OUTPUT-RECORDs (though not for SEQUENCE-OUTPUT-RECORDs). On the gripping hand, I no longer really have much of an idea what's going on at all. You might want to examine the code that draws the graph, maybe trying to insert a graph output record instead of a sequence one if that's possible. If possible, it would also be good to find out whether %TREE-RECOMPUTE-EXTENT* or (SETF OUTPUT-RECORD-POSITION) is responsible for the majority of the time. Cheers, Christophe From pw at snoopy.mv.com Tue Apr 18 15:00:26 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 18 Apr 2006 11:00:26 -0400 Subject: [mcclim-devel] bug: with-presentation-type-xxx Message-ID: <20060418150026.10083.qmail@copper.mv.net> In LispWorks CLIM CLIM-USER> (with-presentation-type-parameters (completion '(completion (a b c))) value-key) CLIM-USER> IDENTITY In McCLIM, an error The variable VALUE-KEY is unbound. With-presentation-type-parameters and with-presentation-type-options are afflicted this way. Paul From johnc at yagc.ndo.co.uk Tue Apr 18 22:51:59 2006 From: johnc at yagc.ndo.co.uk (John Connors) Date: Tue, 18 Apr 2006 23:51:59 +0100 Subject: [mcclim-devel] clim-extensions.lisp In-Reply-To: <443F739A.40803@yagc.ndo.co.uk> References: <443F739A.40803@yagc.ndo.co.uk> Message-ID: <44456D8F.2030001@yagc.ndo.co.uk> John Connors wrote: > > I note that clim-extensions.lisp isn't in the clim-clx asdf defsystem > form despite being defined in that package; is there a reason for this? > And while I'm asking silly questions, I'll observe that : (defun force-preview-repaint () (let ((pane (find-pane-named *application-frame* 'perlin::preview))) (repaint-sheet pane (sheet-region pane)))) ..was needed to force an image pane to redisplay instantly. Is that how it is supposed to work? -- +--------------------------------------------------------+ |Cyborg Animation Programmer | johnc at yagc.ndo.co.uk| |http://badbyteblues.blogspot.com -----------------------| +--------------------------------------------------------+ From csr21 at cam.ac.uk Wed Apr 19 10:28:29 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 19 Apr 2006 11:28:29 +0100 Subject: [mcclim-devel] fonts, bounding-rectangles on beagle Message-ID: Hi all, JWZ's blog might be of interest for those wondering about implementing TEXT-BOUNDING-RECTANGLE* on beagle: it looks like he has exactly the same problem at . (Something similar might be needed for the gtk and/or cairo backends, who knows?) Cheers, Christophe From csr21 at cam.ac.uk Wed Apr 19 11:08:22 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 19 Apr 2006 12:08:22 +0100 Subject: [mcclim-devel] spatial-trees Message-ID: Hi, I've uploaded a new version of spatial-trees to cclan, with two fixes: * conditionalize (on #+slow :-) the code checking that all the coordinates are in the right order in MAKE-RECTANGLE * make spatial-tree-viz a static-file, so that if a user installs spatial-trees systemwide and then someone else installs clim, you don't get write errors. Cheers, Christophe From rpgoldman at real-time.com Wed Apr 19 14:52:10 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 19 Apr 2006 09:52:10 -0500 Subject: [mcclim-devel] question about on-line spec Message-ID: <17478.20122.888682.129764@necronomicon.sift.info> The annotatable on-line CLIM spec seems no longer to be fully functional. At Karlsruhe, it is not annotatable, and the search function doesn't work. Is there any chance of moving this to a happier home? Best, R From david at lichteblau.com Wed Apr 19 14:58:15 2006 From: david at lichteblau.com (David Lichteblau) Date: Wed, 19 Apr 2006 16:58:15 +0200 Subject: [mcclim-devel] question about on-line spec In-Reply-To: <17478.20122.888682.129764@necronomicon.sift.info> References: <17478.20122.888682.129764@necronomicon.sift.info> Message-ID: <20060419145814.GA15617@gargravarr.knowledgetools.de> Quoting rpgoldman at real-time.com (rpgoldman at real-time.com): > The annotatable on-line CLIM spec seems no longer to be fully > functional. At Karlsruhe, it is not annotatable, and the search > function doesn't work. http://bauhh.dyndns.org:8000/clim-spec/index.html d. From rpgoldman at real-time.com Wed Apr 19 15:02:23 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 19 Apr 2006 10:02:23 -0500 Subject: [mcclim-devel] question about on-line spec In-Reply-To: <20060419145814.GA15617@gargravarr.knowledgetools.de> References: <17478.20122.888682.129764@necronomicon.sift.info> <20060419145814.GA15617@gargravarr.knowledgetools.de> Message-ID: <17478.20735.511554.494696@necronomicon.sift.info> >>>>> "David" == David Lichteblau writes: David> Quoting rpgoldman at real-time.com (rpgoldman at real-time.com): >> The annotatable on-line CLIM spec seems no longer to be fully >> functional. At Karlsruhe, it is not annotatable, and the >> search function doesn't work. David> http://bauhh.dyndns.org:8000/clim-spec/index.html I thought there were concerns about this host not always being up, so that the specbot uses Karlsruhe instead? Ideally, I think we'd have a site that's annotatable and searchable, and that's accessible with the specbot. Best, r From athas at sigkill.dk Wed Apr 19 15:33:08 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 19 Apr 2006 17:33:08 +0200 Subject: [mcclim-devel] question about on-line spec In-Reply-To: <17478.20735.511554.494696@necronomicon.sift.info> (rpgoldman@real-time.com's message of "Wed, 19 Apr 2006 10:02:23 -0500") References: <17478.20122.888682.129764@necronomicon.sift.info> <20060419145814.GA15617@gargravarr.knowledgetools.de> <17478.20735.511554.494696@necronomicon.sift.info> Message-ID: <87odyx4m2z.fsf@sigkill.dk> rpgoldman at real-time.com writes: > Ideally, I think we'd have a site that's annotatable and searchable, > and that's accessible with the specbot. Couldn't the spec just be moved to the common-lisp.net server? That would be appropriate I think. -- \ Troels "Athas" Henriksen /\ - Insert witty signature From strandh at labri.fr Wed Apr 19 17:34:21 2006 From: strandh at labri.fr (Robert Strandh) Date: Wed, 19 Apr 2006 19:34:21 +0200 Subject: [mcclim-devel] question about on-line spec In-Reply-To: <87odyx4m2z.fsf@sigkill.dk> References: <17478.20122.888682.129764@necronomicon.sift.info> <20060419145814.GA15617@gargravarr.knowledgetools.de> <17478.20735.511554.494696@necronomicon.sift.info> <87odyx4m2z.fsf@sigkill.dk> Message-ID: <17478.29853.466532.725869@serveur5.labri.fr> Troels Henriksen writes: > rpgoldman at real-time.com writes: > > > Ideally, I think we'd have a site that's annotatable and searchable, > > and that's accessible with the specbot. > > Couldn't the spec just be moved to the common-lisp.net server? That > would be appropriate I think. According to Gilbert Baumann, he fully intends to keep the bauhh server up an running, and he does not particularly want to move the annotatable spec to somewhere else, like cl.net. I suggest we just accept this and make the specbot point to bauhh. -- 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 rpgoldman at sift.info Wed Apr 19 17:39:04 2006 From: rpgoldman at sift.info (Robert P. Goldman) Date: Wed, 19 Apr 2006 12:39:04 -0500 Subject: [mcclim-devel] question about on-line spec In-Reply-To: <17478.29853.466532.725869@serveur5.labri.fr> References: <17478.20122.888682.129764@necronomicon.sift.info> <20060419145814.GA15617@gargravarr.knowledgetools.de> <17478.20735.511554.494696@necronomicon.sift.info> <87odyx4m2z.fsf@sigkill.dk> <17478.29853.466532.725869@serveur5.labri.fr> Message-ID: <17478.30136.301481.53935@necronomicon.sift.info> >>>>> "RS" == Robert Strandh writes: RS> Troels Henriksen writes: >> rpgoldman at real-time.com writes: >> >> > Ideally, I think we'd have a site that's annotatable and >> > searchable, and that's accessible with the specbot. >> >> Couldn't the spec just be moved to the common-lisp.net server? >> That would be appropriate I think. RS> According to Gilbert Baumann, he fully intends to keep the RS> bauhh server up an running, and he does not particularly want RS> to move the annotatable spec to somewhere else, like cl.net. RS> I suggest we just accept this and make the specbot point to RS> bauhh. If that's what Gilbert wants, then certainly we should comply with his wishes; we owe him a vote of thanks for translating and hosting! R From pw at snoopy.mv.com Wed Apr 19 18:47:55 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Wed, 19 Apr 2006 14:47:55 -0400 Subject: [mcclim-devel] accept-values-pane Message-ID: <000b01c663e1$c529f310$0201a8c0@moby> For those interested, I have a mostly portable version of accept-values-pane running on lispworks CLIM and today I have it semi-working on McCLIM. Here is the patch file I load to supply missing parts of McCLIM. It would be cool if someone could add this functionality to the code base. I plan to post my code in a few days once I figure out how to handle radio-box. The spec and McCLIM have radio-box :choices and :current-selection as toggle-button objects. CLIM makes things a bit easier so I want to make a wrapper around the button-object constraint. What's really missing in McCLIM are list-pane and option-pane gadgets. Another thing. CLIM puts with-look-and-feel-realization in the expansion of with-output-to-gadget. It would be good if McCLIM did as well. I don't think the spec forbids that. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ;;; -*- Package: clim-internals -*- (in-package :clim-internals) ;;; Add missing view classes and +xxx-view+ objects. (macrolet ((frob (name) (let ((sym (intern (string name) :clim-internals)) (par (intern (concatenate 'string "+" (string name) "+") :clim-internals))) `(progn (defclass ,sym (clim:gadget-view)()) (import '(,sym ,par) :clim) (export '(,sym ,par) :clim) (defparameter ,par (make-instance ',sym)))))) (frob toggle-button-view) (frob push-button-view) (frob radio-box-view) (frob check-box-view) (frob slider-view) ;(frob text-field-view) (frob text-editor-view) (frob list-pane-view) (frob option-pane-view) ) (import '(name-key value-key test documentation-key) :clim) (export '(name-key value-key test documentation-key) :clim) (defun accept-present-default (type stream view default default-supplied-p present-p query-identifier) (funcall-presentation-generic-function accept-present-default type stream view default default-supplied-p present-p query-identifier)) (defmethod pane-frame ((pane standard-encapsulating-stream)) (pane-frame (encapsulating-stream-stream pane))) (defmethod invoke-with-sheet-medium-bound (continuation (medium null) (sheet standard-encapsulating-stream)) (invoke-with-sheet-medium-bound continuation medium (encapsulating-stream-stream sheet))) From ahefner at gmail.com Wed Apr 19 23:36:37 2006 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 19 Apr 2006 19:36:37 -0400 Subject: [mcclim-devel] accept-values-pane In-Reply-To: <000b01c663e1$c529f310$0201a8c0@moby> References: <000b01c663e1$c529f310$0201a8c0@moby> Message-ID: <31ffd3c40604191636k5c431ef9j37d6ce8cc39c1a90@mail.gmail.com> In what way is McCLIM is missing list and option pane gadgets? I implemented them over a year ago. On 4/19/06, Paul Werkowski wrote: > For those interested, I have a mostly portable version of accept-values-pane > running on lispworks CLIM and today I have it semi-working on McCLIM. > Here is the patch file I load to supply missing parts of McCLIM. It would be > cool > if someone could add this functionality to the code base. > > I plan to post my code in a few days once I figure out how to handle radio-box. > The spec and McCLIM have radio-box :choices and :current-selection as > toggle-button > objects. CLIM makes things a bit easier so I want to make a wrapper around the > button-object constraint. > > What's really missing in McCLIM are list-pane and option-pane gadgets. > > Another thing. CLIM puts with-look-and-feel-realization in the expansion of > with-output-to-gadget. It would be good if McCLIM did as well. I don't think > the spec forbids that. > > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ;;; -*- Package: clim-internals -*- > > (in-package :clim-internals) > > ;;; Add missing view classes and +xxx-view+ objects. > (macrolet ((frob (name) > (let ((sym (intern (string name) :clim-internals)) > (par (intern (concatenate 'string "+" (string name) "+") > :clim-internals))) > `(progn > (defclass ,sym (clim:gadget-view)()) > (import '(,sym ,par) :clim) > (export '(,sym ,par) :clim) > (defparameter ,par (make-instance ',sym)))))) > (frob toggle-button-view) > (frob push-button-view) > (frob radio-box-view) > (frob check-box-view) > (frob slider-view) > ;(frob text-field-view) > (frob text-editor-view) > (frob list-pane-view) > (frob option-pane-view) > ) > > (import '(name-key value-key test documentation-key) :clim) > (export '(name-key value-key test documentation-key) :clim) > > (defun accept-present-default > (type stream view default default-supplied-p present-p query-identifier) > (funcall-presentation-generic-function accept-present-default > type stream view default default-supplied-p present-p query-identifier)) > > (defmethod pane-frame ((pane standard-encapsulating-stream)) > (pane-frame (encapsulating-stream-stream pane))) > > (defmethod invoke-with-sheet-medium-bound > (continuation (medium null) (sheet standard-encapsulating-stream)) > (invoke-with-sheet-medium-bound continuation medium > (encapsulating-stream-stream sheet))) > > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From johnc at yagc.ndo.co.uk Thu Apr 20 23:05:37 2006 From: johnc at yagc.ndo.co.uk (John Connors) Date: Fri, 21 Apr 2006 00:05:37 +0100 Subject: [mcclim-devel] Patchlet In-Reply-To: <44456D8F.2030001@yagc.ndo.co.uk> References: <443F739A.40803@yagc.ndo.co.uk> <44456D8F.2030001@yagc.ndo.co.uk> Message-ID: <444813C1.4060701@yagc.ndo.co.uk> Redefines the setf method for the pixels of the image class to the correct order, and also re-defines coordinate as a single-float. Both work for me and have been used with the examples with no observed ill - effects. Tested with recent cmucl (19c) -- +--------------------------------------------------------+ |Cyborg Animation Programmer | johnc at yagc.ndo.co.uk| |http://badbyteblues.blogspot.com -----------------------| +--------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: mcclim-single-float.patch Type: text/x-patch Size: 9431 bytes Desc: not available URL: From csr21 at cam.ac.uk Fri Apr 21 12:03:03 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 21 Apr 2006 13:03:03 +0100 Subject: [mcclim-devel] question about on-line spec In-Reply-To: <17478.29853.466532.725869@serveur5.labri.fr> (Robert Strandh's message of "Wed, 19 Apr 2006 19:34:21 +0200") References: <17478.20122.888682.129764@necronomicon.sift.info> <20060419145814.GA15617@gargravarr.knowledgetools.de> <17478.20735.511554.494696@necronomicon.sift.info> <87odyx4m2z.fsf@sigkill.dk> <17478.29853.466532.725869@serveur5.labri.fr> Message-ID: Robert Strandh writes: > According to Gilbert Baumann, he fully intends to keep the bauhh > server up an running, and he does not particularly want to move the > annotatable spec to somewhere else, like cl.net. I suggest we just > accept this and make the specbot point to bauhh. Done (thanks to Alastair Bridgewater). Please annotate away! Cheers, Christophe From csr21 at cam.ac.uk Fri Apr 21 14:21:34 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 21 Apr 2006 15:21:34 +0100 Subject: [mcclim-devel] specialized command-parsers Message-ID: Hi, I'm trying to write a specialized command parser for use in Emacs-Style Applications, where the input pane is a one-line minibuffer. Given this constraint, the default partial-command-parser (which constructs an accepting-values dialog) is undesireable, as is the rightwards march for multiple arguments. At present, ESA implements the desired behaviour by having no commands with arguments at all, instead using calls to ACCEPT within the bodies of its commands to get arguments. This is unacceptable (haha) in my view because it does not allow for scriptability: the ability of other applications to call (execute-frame-command *climacs-frame* `(climacs-gui::com-find-file "/tmp/foo")) is potentially one of the selling points of the as-yet mythical CLIM environment. My current attempt at writing a command parser (no attempt at partial parsing or unparsing yet) is (defun esa-command-parser (command-table stream) (let ((command-name nil) (command-args nil)) (with-delimiter-gestures (*command-name-delimiters* :override t) ;; While reading the command name we want use the history of the ;; (accept 'command ...) that's calling this function. (setq command-name (accept `(command-name :command-table ,command-table) :stream stream :prompt nil :history nil)) (let ((delimiter (read-gesture :stream stream :peek-p t))) ;; Let argument parsing function see activation gestures. (when (and delimiter (delimiter-gesture-p delimiter)) (read-gesture :stream stream)))) (with-delimiter-gestures (*command-argument-delimiters* :override t) (let* ((info (gethash command-name climi::*command-parser-table*)) (required-args (climi::required-args info)) (keyword-args (climi::keyword-args info))) (let (result) ;; only required args for now. (dolist (arg required-args (cons command-name (nreverse result))) (destructuring-bind (name ptype &rest args) arg (declare (ignore name)) ;; clear the stream somehow #+nil (setf (stream-cursor-position stream) (values 0 0)) #+nil (replace-input stream "") (push (apply #'accept (eval ptype) :stream stream ;; FIXME: probably wrong evaluation for ARGS args) result)))))))) Quite apart from the apparent impossibility of writing a command parser portable across CLIM implementations, this doesn't work in several ways. It doesn't handle keyword arguments, the evaluation of the arguments in the call to ACCEPT for arguments is wrong (see the spec for DEFINE-COMMAND for the evaluation rules...), and, most importantly, I find myself unable to clear the stream. Setting the stream cursor position doesn't work, because stream is an input stream; I don't know why REPLACE-INPUT doesn't work, but it gives me an error. ERASE-INPUT-BUFFER is unimplemented. The pieces of the implementation of this behaviour in ESA, currently, include a method on STREAM-ACCEPT: (defmethod stream-accept :before ((pane minibuffer-pane) type &rest args) (declare (ignore type args)) (window-clear pane)) which clears the minibuffer window at every call to ACCEPT, which is what we want. However, inside my ESA-COMMAND-PARSER, ACCEPT is called on an input-editing-stream, not a minibuffer-pane. How am I meant to do this? Any ideas? Cheers, Christophe From csr21 at cam.ac.uk Fri Apr 21 14:53:36 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 21 Apr 2006 15:53:36 +0100 Subject: [mcclim-devel] command name completion Message-ID: Hi, Forgive me for the somewhat vague bug report; I hope this is enough to pin down the problem. The accept completion for command names seems to have a problem when the disambiguation character is a space. I defined a climacs command com-new-find-file, but am unable to type it at the M-x prompt because there is a com-newline-and-indent; typing N e w SPC does not lead to a space being inserted. Using C-/ lets me click on the New Find File command, so it's definitely there. Cheers, Christophe From csr21 at cam.ac.uk Fri Apr 21 16:25:38 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 21 Apr 2006 17:25:38 +0100 Subject: [mcclim-devel] specialized command-parsers In-Reply-To: (Christophe Rhodes's message of "Fri, 21 Apr 2006 15:21:34 +0100") References: Message-ID: Christophe Rhodes writes: > My current attempt at writing a command parser (no attempt at partial > parsing or unparsing yet) is > > (defun esa-command-parser (command-table stream) > (let ((command-name nil) > (command-args nil)) > (with-delimiter-gestures (*command-name-delimiters* :override t) > ;; While reading the command name we want use the history of the > ;; (accept 'command ...) that's calling this function. > (setq command-name (accept `(command-name :command-table ,command-table) > :stream stream :prompt nil :history nil)) > (let ((delimiter (read-gesture :stream stream :peek-p t))) > ;; Let argument parsing function see activation gestures. > (when (and delimiter (delimiter-gesture-p delimiter)) > (read-gesture :stream stream)))) > (with-delimiter-gestures (*command-argument-delimiters* :override t) > (let* ((info (gethash command-name climi::*command-parser-table*)) > (required-args (climi::required-args info)) > (keyword-args (climi::keyword-args info))) > (let (result) > ;; only required args for now. > (dolist (arg required-args (cons command-name (nreverse result))) > (destructuring-bind (name ptype &rest args) arg > (declare (ignore name)) > ;; clear the stream somehow > #+nil > (setf (stream-cursor-position stream) (values 0 0)) > #+nil > (replace-input stream "") > (push (apply #'accept > (eval ptype) :stream stream > ;; FIXME: probably wrong evaluation for ARGS > args) > result)))))))) > > Quite apart from the apparent impossibility of writing a command > parser portable across CLIM implementations, this doesn't work in > several ways. It doesn't handle keyword arguments, the evaluation of > the arguments in the call to ACCEPT for arguments is wrong (see the > spec for DEFINE-COMMAND for the evaluation rules...), and, most > importantly, I find myself unable to clear the stream. Setting the > stream cursor position doesn't work, because stream is an input > stream; I don't know why REPLACE-INPUT doesn't work, but it gives me > an error. ERASE-INPUT-BUFFER is unimplemented. My current version, which I've built up by trial and error, almost works (I've appended it below). In fact it basically works except when the user types SPC at a point where (I think) there is more than one possibility, but only if the user has previously pressed backspace; in those conditions, the "Extended Command: " prompt from below is deleted. That is, in my example where I have com-new-find-file and com-newline-and-indent, the sequence M-x N e SPC works as I want it to, while M-x N e DEL e SPC causes the prompt to disappear. I'm mystified by this. (defun esa-command-parser (command-table stream) (let ((command-name nil) (command-args nil)) (with-delimiter-gestures (*command-name-delimiters* :override t) ;; While reading the command name we want use the history of the ;; (accept 'command ...) that's calling this function. (setq command-name (accept `(command-name :command-table ,command-table) :stream stream :prompt "Extended Command: " :prompt-mode :raw :history nil)) (let ((delimiter (read-gesture :stream stream :peek-p t))) ;; Let argument parsing function see activation gestures. (when (and delimiter (delimiter-gesture-p delimiter)) (read-gesture :stream stream)))) (with-delimiter-gestures (*command-argument-delimiters* :override t) (let* ((info (gethash command-name climi::*command-parser-table*)) (required-args (climi::required-args info)) (keyword-args (climi::keyword-args info))) (let (result) ;; only required args for now. (dolist (arg required-args (cons command-name (nreverse result))) (destructuring-bind (name ptype &rest args) arg (declare (ignore name)) ;; clear the stream somehow (replace-input stream "" :rescan nil) #+nil (reset-scan-pointer stream) #+nil (window-clear (encapsulating-stream-stream stream)) #+nil (setf (stream-insertion-pointer stream) 0) #+nil (setf (stream-scan-pointer stream) 0) #+nil (replace-input stream "") #+nil (reset-scan-pointer stream) (push (apply #'accept (eval ptype) :stream stream ;; FIXME: probably wrong evaluation for ARGS args) result)))))))) Cheers, Christophe From pw at snoopy.mv.com Sat Apr 22 13:05:42 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Sat, 22 Apr 2006 09:05:42 -0400 Subject: [mcclim-devel] bug: text-field gadget Message-ID: <000701c6660d$7658fff0$0201a8c0@moby> In gadgets.lisp there is this comment: ;; Is there really a benefit to waiting until the first painting to ;; create the goatee instance? Why not use INITIALIZE-INSTANCE? (defmethod handle-repaint :before ((pane text-field-pane) region) <...> and this method: (defmethod (setf gadget-value) :after (new-value (gadget text-field-pane) &key invoke-callback) (declare (ignore invoke-callback)) (let* ((area (area gadget)) ;;;<<<< NIL (buffer (goatee::buffer area)) (start (goatee::buffer-start buffer)) (end (goatee::buffer-end buffer))) (goatee::delete-region buffer start end) (goatee::insert buffer new-value :position start) (goatee::redisplay-area area))) which fails when (setf gadget-value) is called before the text-field is displayed on screen. Result is dreaded NO-APPLICABLE-METHOD signal. The work around is obvious. I'll get the gadgetmeisters figure out the correct solution. A test case is below. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (in-package :clim-user) (define-application-frame testme () ((tfg)) (:panes (p0 :application :display-function (lambda (f p) (with-slots (tfg) f (with-output-as-gadget (p :cache-value t) (with-look-and-feel-realization ((frame-manager f) f) (setq tfg (make-pane 'text-field :width 40)))) (setf (gadget-value tfg) "XXX"))))) (:layouts (default p0))) (defun testme () (run-frame-top-level (make-application-frame 'testme))) From pw at snoopy.mv.com Sat Apr 22 13:41:15 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Sat, 22 Apr 2006 09:41:15 -0400 Subject: [mcclim-devel] radio-box-selections check-box-selections Message-ID: <000501c66612$6d2d07f0$0201a8c0@moby> radio-box-selections is supposed to return a list of *all* the toggle-button gadgets. Currently it is implemented as (defmethod radio-box-selections ((pane radio-box)) (let ((v (radio-box-current-selection pane))) (and v (list v)))) check-box-selections is similar, but is not implemented at all. Paul From pw at snoopy.mv.com Sun Apr 23 13:48:42 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Sun, 23 Apr 2006 09:48:42 -0400 Subject: [mcclim-devel] accept-values-pane Message-ID: <000801c666dc$a2374fd0$0201a8c0@moby> Well, here it is, a user-land implementation of ACCEPT-VALUES-PANE. CLIM programmers can use this if their implementation doesn't provide one, or would like to customize one for some reason. It is in package #:PAVP and the pane type and command-table is AV-PANE. You need to load the patch-mcclim.lisp before loading avp.lisp. Running the example code, (pavp::doit), you will see first an application-pane that is gratuitously needed to provide frame-standard-input. Below that are four gadgets, but only the first toggle-button is visable (on my system at least). The others don't appear until the toggle-button is unchecked. This is not a clever feature of the example code! Here is some info from the top of avp.lisp ;;; ;;; By Paul Werkowski, April-2006 and placed into the public domain. ;;; This code was written from the viewpoint of a CLIM user and demonstrates ;;; how ACCEPT-VALUE-PANE could (not should) be implemented. A not quite ;;; achived goal was to use only documented CLIM features. ;;; A CLIM implementer might spot some obvious problems. ;;; ;;; Just wondering how ACCEPT-VALUES-PANE can be implemented and came up ;;; with some code that should be portable across CLIM 2.0 systems ;;; (but tested only on LispWorks for Windows 4.4.6). The only non-documented ;;; exceptions is VIEW-INITARGS and FOCUS-OUT-CALLBACK below. ;;; ;;; Accept-values-pane is probably easier to implement than accepting-values ;;; because it only uses gadgets (true?), does not block, and has no exit boxes. ;;; ;;; The basics: ;;; ;;; Local things ;;; class av-query ;;; class av-stream ;;; class av-pane ] like clim:accept-values-pane ;;; command-table av-pane] ;;; command com-av-update-query ;;; event av-query-update-event ;;; ;;; CLIM things ;;; GF accept-present-default ] specialized on av-stream and views ;;; GF stream-accept ] ;;; GF value-changed-callback] ;;; ;;; CLIM magic ;;; Gadget value-changed-callback queues an event containing query and new ;;; value. Event handler invokes presentation system to pass value to ;;; command com-update-query. Top-level-loop calls display function, ;;; stream-accept returns values found in associated query object. ;;; ;;; ;;; Results: ;;; ;;; With 'Real' CLIM: ;;; Pretty close match to clim:accept-values-pane mechanism. ;;; Noticable are: ;;; * Some difference in font style in gadget labels. ;;; ;;; * Slight screen flash on redisplay not noticable in CLIM version. ;;; Some doc (LW?) says that redisplay is handled differently ;;; for efficiency. I'd like to know how. I've seen this before when ;;; I've used with-output-to-gadget but have not figured out the cause. ;;; ;;; With McCLIM ;;; * Works only when FRAME-STANDARD-INPUT returns the right thing such as ;;; when there is an application-pane or interactor-pane in the frame. ;;; READ-COMMAND must call (ACCEPT 'COMMAND ...) as noted in the spec. ;;; FWIW CLIM calls READ-COMMAND with STREAM parameter bound to ;;; the frame's TOP-LEVEL-SHEET in gadget-only frame. ;;; ;;; * CLIM ACCEPT does not pass NIL view to STREAM-ACCEPT. Instead it ;;; passes one of +RADIO-BOX-VIEW+ +CHECK-BOX-VIEW+ or +TOGGLE-BUTTON-VIEW+, ;;; probably by noticing GADGET-DIALOG-VIEW in STREAM-DEFAULT-VIEW. ;;; I special case STREAM-ACCEPT to do that for McCLIM. ;;; ;;; * Exposes problems in gadget layout, maybe do to playing poorly with ;;; vbox-pane? Trace ALLOCATE-SPACE to see some strange stuff. ;;; Good luck! Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-mcclim.lisp Type: application/octet-stream Size: 1955 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: avp.lisp Type: application/octet-stream Size: 23867 bytes Desc: not available URL: From christopher.laux at web.de Tue Apr 25 19:14:21 2006 From: christopher.laux at web.de (Christopher Laux) Date: Tue, 25 Apr 2006 21:14:21 +0200 Subject: [mcclim-devel] bug(?) in text-editor-pane / Goatee Message-ID: <444E750D.6040807@web.de> Hi all, I've given up looking for this one for now, maybe people familiar with the code in question know what's going on. If you simply set the gadget-value of a text-editor-pane to a string with a newline in it (I assume that's how you set up multiline text, right?) and then set a new value, moving the cursor (home key in this example) can yield the following error: > (setf (gadget-value *edit*) (format nil "test~%test")) > (setf (gadget-value *edit*) "test") The value -1 is not of type (MOD 536870911). [Condition of type TYPE-ERROR] Restarts: 0: [ABORT] Return to application command loop 1: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: ((SB-PCL::FAST-METHOD GOATEE::BUFFER-STRING (GOATEE::BASIC-BUFFER)) # # # NIL) 1: ((SB-PCL::FAST-METHOD HANDLE-EVENT (TEXT-FIELD-PANE KEY-PRESS-EVENT)) (#(NIL 65) . #()) # # #) 2: (CLIM-INTERNALS::HANDLE-NON-STREAM-EVENT #) 3: ((SB-PCL::FAST-METHOD STREAM-INPUT-WAIT [ ... ] The value doesn't have to be -1 btw... If I'm not mistaken, the problem is that additional undefined characters are inserted mistakenly (visible cues too). The size of the editable-buffer is not correspondingly updated, so after deletion there's a negative size value. Thanks in advance for any help, Chris From asf at boinkor.net Wed Apr 26 18:21:23 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Wed, 26 Apr 2006 20:21:23 +0200 Subject: [mcclim-devel] incremental-redisplay cons cell memory leak Message-ID: <874q0gmc4c.wl%asf@boinkor.net> Hi all, a long time ago, I discovered that beirc crashes after 3 or 4 days of running. Now I managed to narrow it down to the incremental redisplay code. It seems that the children-updating-output slot of updating output records has duplicate ORs (68 unique ORs vs. 1765 non-unique) added, which makes sbcl go boom pretty soon. This patch fixes it, but I'm not sure if I'm solving the root of the problem. Tim should maybe have a look at it (: Index: incremental-redisplay.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/incremental-redisplay.lisp,v retrieving revision 1.60 diff -u -r1.60 incremental-redisplay.lisp --- incremental-redisplay.lisp 22 Apr 2006 15:31:27 -0000 1.60 +++ incremental-redisplay.lisp 26 Apr 2006 18:12:40 -0000 @@ -442,7 +442,7 @@ ((child updating-output-record-mixin) record) (declare (ignore record)) (if (parent-updating-output child) - (push child (children-updating-output (parent-updating-output child))) + (pushnew child (children-updating-output (parent-updating-output child))) nil)) (oh, and things seem a bit snappier with it, obviously (-:) Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From asf at boinkor.net Wed Apr 26 18:36:34 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Wed, 26 Apr 2006 20:36:34 +0200 Subject: [mcclim-devel] incremental-redisplay cons cell memory leak In-Reply-To: <874q0gmc4c.wl%asf@boinkor.net> References: <874q0gmc4c.wl%asf@boinkor.net> Message-ID: <873bg0mbf1.wl%asf@boinkor.net> Today, Andreas Fuchs wrote: > This patch fixes it, but I'm not sure if I'm solving the root of the > problem. Tim should maybe have a look at it (: I looked (grepped, in fact) some more, and it seems that children-updating-output is not used anywhere in all of mcclim. Maybe we can just kill that slot, and the book keeping code with it. Thoughts?, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From athas at sigkill.dk Wed Apr 26 18:52:46 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 26 Apr 2006 20:52:46 +0200 Subject: [mcclim-devel] incremental-redisplay cons cell memory leak In-Reply-To: <874q0gmc4c.wl%asf@boinkor.net> (Andreas Fuchs's message of "Wed, 26 Apr 2006 20:21:23 +0200") References: <874q0gmc4c.wl%asf@boinkor.net> Message-ID: <87k69cdv9d.fsf@sigkill.dk> Andreas Fuchs writes: > It seems that the children-updating-output slot of updating output > records has duplicate ORs (68 unique ORs vs. 1765 non-unique) added, > which makes sbcl go boom pretty soon. FWIW, this may also be why I experience memory leaks in Climacs (and eventually, end up in SBCL's low-level debugger with complaints about no more memory). -- \ Troels "Athas" Henriksen /\ - Insert witty signature From athas at sigkill.dk Fri Apr 28 14:49:33 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 28 Apr 2006 16:49:33 +0200 Subject: [mcclim-devel] (Patch) Keyboard support and (too) trivial `eval-in-frame' for the McCLIM debugger Message-ID: <87slnxsqki.fsf@sigkill.dk> Attached to this post is a patch to the debugger in Apps/Debugger/clim-debugger.lisp. It adds keyboard support and a simple-minded (and almost useless) `eval-in-frame' command. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clim-debugger-improvements.diff URL: -------------- next part -------------- -- \ Troels "Athas" Henriksen /\ - Insert witty signature