From athas at sigkill.dk Sun Mar 5 10:42:31 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Sun, 05 Mar 2006 11:42:31 +0100 Subject: [mcclim-devel] Scrollbar/text-editor-bug in McCLIM? Message-ID: <87acc59nqg.fsf@sigkill.dk> Observe the behavior of this simple application: (define-application-frame buggy-editor () () (:panes (text-edit :text-editor) (interactor :interactor :scroll-bars nil)) (:layouts (default (vertically () (scrolling (:scroll-bars t) text-edit) (scrolling (:scroll-bars t) interactor))))) If a line wider than the pane is written to the text-editor pane, it will correctly update the scroll-bars and the pane size to allow one to navigate through the entire line. This does not happen when more lines are inserted than it is possible to display in the pane, though: in that case, the horizontal scrollbars will not be adjusted, thus rendering it impossible to see the surplus lines. Is this behavior a bug in my application or in McCLIM? -- \ Troels "Athas" Henriksen /\ sigkill.dk - KILL -9 From asf at boinkor.net Tue Mar 7 11:12:51 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Tue, 07 Mar 2006 12:12:51 +0100 Subject: [mcclim-devel] Plans for McCLIM 0.9.2 "Laetare Sunday" release Message-ID: <87wtf6h5jg.wl%asf@boinkor.net> hi all, I (and a few others, hi Clemens and Christophe) would like to see a new McCLIM release. As Mothering Sunday is on the 26th of March, and we wanted to do time-slot releases anyway ((-;), I suggest we go for that date. Proposed schedule: * Heavy McCLIM hacking until 19th March. Then, freeze. * test test test, * Release McCLIM 0.9.2, "Laetare Sunday" on Sunday, 26th March (-: Is everybody happy with that? I'll take silence (until say, the 12th) as a "yes" (-: -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From csr21 at cam.ac.uk Tue Mar 7 12:09:59 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 07 Mar 2006 12:09:59 +0000 Subject: [mcclim-devel] Infinite loop in McCLIM In-Reply-To: <000501c5fcd5$e0173ca0$0201a8c0@moby> (Paul Werkowski's message of "Fri, 9 Dec 2005 10:33:16 -0500") References: <000501c5fcd5$e0173ca0$0201a8c0@moby> Message-ID: "Paul Werkowski" writes: > The attached program works the same in McCLIM and Lispworks CLIM, > except McCLIM gets into an infinite loop (CMUCL latest) unless > incremental-redisplay > is enabled. [ Belatedly ] Um, I didn't see an attachment to your original mail... did you forget to attach it? Is this still a problem? Cheers, Christophe From peter.braroe at newsmachine.com Tue Mar 7 13:06:45 2006 From: peter.braroe at newsmachine.com (Peter Braroe) Date: Tue, 7 Mar 2006 14:06:45 +0100 Subject: SV: [mcclim-devel] Plans for McCLIM 0.9.2 "Laetare Sunday" release In-Reply-To: <87wtf6h5jg.wl%asf@boinkor.net> Message-ID: <20060307131231.EDC2F14005@common-lisp.net> Hello! I will be happy to test - please signal when to get a CVS version to try and what to test! I use x86/Debian and CMUCL and also intend to install the same on an older SPARC Sun machine soon (ultra 5), and possibly also a Mac OSX 10.4 machine (with X) so I could test there too if needed. Does anyone know if the current CVS version works? I believe Paolo reported it broken - is it still? Does anyone know what version the Debian package is? When 0.9.2 is done it would be nice with a new version of that. Who usually does that? Slightly off - is the exit-boxes fixed? I would like to do something like: (clim:accepting-values | (pstream | :own-window T :exit-boxes '((:exit "OK") (:abort "Cancel")) ... | ) On my version I get Exit and Abort no matter what. I have 0.9.1... Also own window does not work though I understand that it is fixed now? Oh, and also it would be cool if we could put the fixes for "Non-ASCII input" and such in the release as seen on http://mcclim.cliki.net/Tip at least the translate function could be added. I use that code to fix Swedish characters and it seems to work fine for me! Over 'n out! / Peter --------------------------------------------------------------------------- -----Ursprungligt meddelande----- Fr?n: mcclim-devel-bounces at common-lisp.net [mailto:mcclim-devel-bounces at common-lisp.net] F?r Andreas Fuchs Skickat: den 7 mars 2006 12:13 Till: mcclim-devel at common-lisp.net ?mne: [mcclim-devel] Plans for McCLIM 0.9.2 "Laetare Sunday" release hi all, I (and a few others, hi Clemens and Christophe) would like to see a new McCLIM release. As Mothering Sunday is on the 26th of March, and we wanted to do time-slot releases anyway ((-;), I suggest we go for that date. Proposed schedule: * Heavy McCLIM hacking until 19th March. Then, freeze. * test test test, * Release McCLIM 0.9.2, "Laetare Sunday" on Sunday, 26th March (-: Is everybody happy with that? I'll take silence (until say, the 12th) as a "yes" (-: -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs _______________________________________________ mcclim-devel mailing list mcclim-devel at common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From pw at snoopy.mv.com Tue Mar 7 14:01:47 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 7 Mar 2006 09:01:47 -0500 Subject: [mcclim-devel] Infinite loop in McCLIM Message-ID: <20060307140147.11240.qmail@copper.mv.net> > "Paul Werkowski" writes: > > > The attached program works the same in McCLIM and Lispworks CLIM, > > except McCLIM gets into an infinite loop (CMUCL latest) unless > > incremental-redisplay > > is enabled. > > [ Belatedly ] Um, I didn't see an attachment to your original > mail... did you forget to attach it? Is this still a problem? > > Cheers, > > Christophe > > I think that problem went away - probably some cockpit trouble in my environment. Paul From rpgoldman at real-time.com Tue Mar 7 14:05:36 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 7 Mar 2006 08:05:36 -0600 Subject: SV: [mcclim-devel] Plans for McCLIM 0.9.2 "Laetare Sunday" release In-Reply-To: <20060307131231.EDC2F14005@common-lisp.net> References: <87wtf6h5jg.wl%asf@boinkor.net> <20060307131231.EDC2F14005@common-lisp.net> Message-ID: <17421.37680.262054.758269@necronomicon.sift.info> I'll try and do some experiments with Allegro Common Lisp, if that's helpful. Do you have a recipe for things that should be tested. Hmm.... I've been dying to try beirc.... R From csr21 at cam.ac.uk Wed Mar 8 12:29:32 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 08 Mar 2006 12:29:32 +0000 Subject: [mcclim-devel] standard-tree-output-records using spatial-trees In-Reply-To: <8764n08yvk.wl%asf@boinkor.net> (Andreas Fuchs's message of "Mon, 27 Feb 2006 19:01:19 +0100") References: <873bixkfdr.wl%asf@boinkor.net> <87wtg9iflm.wl%asf@boinkor.net> <87y805jbq1.wl%asf@boinkor.net> <8764n08yvk.wl%asf@boinkor.net> Message-ID: Andreas Fuchs writes: > On 2006-02-21, Andreas Fuchs wrote: >> * map-over-* didn't check if the child truly intersects the region / >> contains the point; this is enough only for ORs and regions that >> are equal to their bounding rectangle. > > Thanks to Robert's tests with gsharp yesterday, we found out that this > code wrongly assumes that output records are regions. ORs are just > bounding rectangles, which means the code shouldn't call > bounding-rectangle on any OR; also, we shouldn't use the ORs in region > comparisons directly. So the spatial trees code is now in CVS. I'm mailing here so that we don't lose sight of various observations. Firstly, Robert Strandh has observed that the new code makes gsharp slower, and indeed I can confirm this: loading Scores/rapsoden-sjunger.gsh on my workstation and hitting C-f and C-b has noticeable lag, where it didn't before. (It has always had noticeable lag on my laptop, I should say; I would imagine that it's now unbearable :-). Secondly, Andy Hefner did some simple benchmarking of constructing the output record; the code and some results are at . I believe that this benchmark measures the construction of the output record (and not any subsequent interactions). In fact, both Robert's and Andy's observations are largely to do with constructing the output record, rather than subsequent use; I believe that gsharp redraws everything after each command, and so does not reuse an output record that has been constructed. Note that one might expect a slowdown in this case, because constructing a tree is probably O(N logN) as opposed to O(N) for a sequence; however, looking for bottlenecks in constructing the spatial trees reveals some low-hanging fruit. Firstly, there is some error checking in spatial-trees:make-rectangle which should be elided for McCLIM's use of it; it verifies that the bounds are in numerical order. Eliding that error check appears to reduce the spatial tree overhead by about 30% (again, looking at Andy's benchmark results) and makes MAKE-RECTANGLE no longer be the bottleneck. The top three entries in the profile are then seconds | consed | calls | sec/call | name -------------------------------------------------------------- 0.591 | 0 | 3,788,832 | 0.0000002 | SPATIAL-TREES-IMPL::MBR 0.414 | 226,208,568 | 1,347,295 | 0.0000003 | RECTANGLES:MINIMUM-BOUND 0.394 | 0 | 2,313,343 | 0.0000002 | RECTANGLES:AREA MBR is quite hard to optimize, I think, in that it is basically slot lookups. It's possible that the CLOS dispatch is the bottleneck; something to be tried is to despecialize the second argument in both of the methods, from (defmethod mbr ((n spatial-tree-node) (tree spatial-tree)) (defmethod mbr ((o leaf-node-entry) (tree spatial-tree)) to (defmethod mbr ((n spatial-tree-node) tree) (defmethod mbr ((o leaf-node-entry) tree) as at least SBCL's clos can then further optimize the dispatch, as it no longer needs to compute the class of the second argument. I don't know if this is actually the bottleneck, though. RECTANGLES:MINIMUM-BOUND and RECTANGLES:AREA could be further optimized, however, given that in McCLIM we know that we are dealing with two-dimensional rectangles (while the spatial-trees library is for general dimensionality). I don't yet have a clear idea of how to allow this specialization for particular uses while maintaining a general-purpose fallback (without introducing more dispatch code which will likely clobber any gains we make from the specialization). Ideas? (There are a couple of other minor problems: the spatial-trees asd can in some circumstances cause ordinary users to trip after root has installed it, as spatial-tree-viz is conditionally compiled; also, delete-output-record on tree-output-records does not remove the entry from the children cache hash table, which then grows without bound...) Cheers, Christophe From csr21 at cam.ac.uk Wed Mar 8 18:05:39 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 08 Mar 2006 18:05:39 +0000 Subject: [mcclim-devel] device font text styles Message-ID: Hi, I attach a patch for discussion and review, reworking the support for device fonts; in particular, one can do things like (with-text-style (s (make-device-font-text-style port (make-postscript-device-font-name :font-file "Dingbats.pfb" :metrics-file "Dingbats.afm" :size 14))) (write-line "Hello, World!" s)) We use this patch to draw lute tablature, using home-designed fonts for the tab glyphs, in both TrueType and Postscript formats (TrueType for display, Postscript for printing). I don't know whether this patch breaks the ordinary CLX backend's support for device fonts; is anyone in a position to test this? I also suspect that there are bits and pieces of the postscript code which are not entirely right, though I can say that Examples/postscript-test.lisp seems to be about right. This bit of CLIM is almost completely unspecified; all that we know about MAKE-DEVICE-FONT-TEXT-STYLE is that it takes a port and a "font name" and returns some kind of TEXT-STYLE object. The reasoning I've applied in this implementation is that since device-font-text-styles are defined not to merge (in the MERGE-TEXT-STYLE sense) with any other text style, a device-font-text-style-name needs to have all the information required to identify uniquely a font that we can use in the backend. Under X, calling this a "name" makes a certain amount of sense, because X fonts are in fact uniquely identified by their X name: something like "-adobe-courier-medium-r-normal-and-so-on-". I don't think this is true for any other backend :-) so I think it's reasonable to define names as structures, rather than attempting to parse some ad-hoc string representation. I also don't want to present this patch as a final interface; it is fairly ugly to have to specify the port type when making a name. Ultimately, we may want to move back to string names: something like (define-font "Varietie3" :freetype (:font-file "fonts/Varietie3.ttf" :size 14) :postscript (:font-file "fonts/Varietie3.pfa" :metrics-file "fonts/Varietie3.afm" :size 12)) but I certainly think that designing something like that is out of scope in the next three weeks... Anyway, with all that, the patch (which is by far the majority of my diff with HEAD) attached. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: device-font-text-style.diff URL: -------------- next part -------------- Cheers, Christophe From pdm at zamazal.org Sat Mar 11 18:57:12 2006 From: pdm at zamazal.org (Milan Zamazal) Date: Sat, 11 Mar 2006 19:57:12 +0100 Subject: [mcclim-devel] Re: SV: Plans for McCLIM 0.9.2 "Laetare Sunday" release References: <87wtf6h5jg.wl%asf@boinkor.net> <20060307131231.EDC2F14005@common-lisp.net> Message-ID: <87veukajxz.fsf@blackbird.zamazal.org> >>>>> "PB" == Peter Braroe writes: PB> Does anyone know what version the Debian package is? If the package version says it is 0.9.1, then yes, it is really 0.9.1 :-). Only fixes necessary to make it run on current Debian were additionally applied. PB> When 0.9.2 is done it would be nice with a new version of PB> that. Who usually does that? The Debian package maintainer, of course :-). Don't worry, I watch this list and will package McCLIM 0.9.2 once it is released. PB> Oh, and also it would be cool if we could put the fixes for PB> "Non-ASCII input" and such in the release as seen on PB> http://mcclim.cliki.net/Tip at least the translate function PB> could be added. AOL! Regards, Milan Zamazal -- http://www.zamazal.org From athas at sigkill.dk Sun Mar 12 21:34:54 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Sun, 12 Mar 2006 22:34:54 +0100 Subject: [mcclim-devel] Patch for CLX backend `medium-draw-ellipse*'-bug Message-ID: <87hd63uz29.fsf@sigkill.dk> This email relates to the bug described in: http://common-lisp.net/pipermail/mcclim-devel/2005-December/004334.html I believe I have located the bug in Backends/CLX/medium.lisp, in the method `medium-draw-ellipse*'. Basically, the method assumes that if `end-angle' is negative, it will be necessary to add 2pi radians to the arc angle to make sure the arc will be drawn counter-clockwise (as the CLIM spec specifies), but this is not the case if start-angle is negative or 0 as well. The attached patch fixes this issue, but it does not make McCLIM do as the bug reporter expects. The arc is vertically mirrored with respect to the expected location, but as far as I can see from the spec, this is actually where it should be placed, due to the negative scale-y argument to `with-scaling' - could this be a bug in the LispWorks implementation? In any case, erroneous positioning of the arc is probably not related to to the function I have patched, so it should be safe to commit. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: medium.lisp.diff URL: -------------- next part -------------- -- \ Troels "Athas" Henriksen /\ - Insert witty signature From asf at boinkor.net Sun Mar 12 21:55:19 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Sun, 12 Mar 2006 22:55:19 +0100 Subject: [mcclim-devel] Freeze period start for McCLIM 0.9.2 Message-ID: <87ek17gwfs.wl%asf@boinkor.net> Hi all, This mail marks the start of the freeze period for McCLIM 0.9.2. As you know, the plan is to release 0.9.2 on the next Sunday, the March 19th. In the meantime, please test on as many platforms and lisp implementations as possible. Post results, both negative and positive, to mcclim-devel. Also, I encourage you all to fix bugs and post fixes to mcclim-devel for review. Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From pw at snoopy.mv.com Sun Mar 12 23:04:49 2006 From: pw at snoopy.mv.com (Paul Werkowski) Date: Sun, 12 Mar 2006 18:04:49 -0500 Subject: [mcclim-devel] patch for gadget.lisp Message-ID: <001001c64629$5d950ad0$6401a8c0@moby> This was sent late last year, but it seems the patch got stripped by some helpful agent. I hope this one gets through. Please let me know otherwise. Paul ~~~~~~~~~~~~~~~~~~~~ Here is an improved patch that fixes problems in an earlier post with incorrect cursor position when incremental redisplay was active. It is still required that calls to with-output-as-gadget be wrapped in (updating-output ( ... :cache-value )) to avoid problems if the output-record is ever erased. ~~~~~~~~~~~~~~~ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gadget-patch.txt URL: From asf at boinkor.net Sun Mar 12 23:27:19 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Mon, 13 Mar 2006 00:27:19 +0100 Subject: [mcclim-devel] Freeze period start for McCLIM 0.9.2 In-Reply-To: <87ek17gwfs.wl%asf@boinkor.net> References: <87ek17gwfs.wl%asf@boinkor.net> Message-ID: <87d5grgs6g.wl%asf@boinkor.net> On 2006-03-12, Andreas Fuchs wrote: > This mail marks the start of the freeze period for McCLIM 0.9.2. Erm, not quite. Last-minute feature greediness on my part (and Tim's promise to get drag & drop of presentations to work and to not break anything) have made me reconsider starting the freeze today. An updated and final freeze mark mail will go out within 24 hours, when (hopefully) Tim has gotten presentation drag translators to work or when we backed out the change. Thanks for your patience, (: -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From csr21 at cam.ac.uk Mon Mar 13 11:58:14 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 13 Mar 2006 11:58:14 +0000 Subject: [mcclim-devel] [CfP] 3rd European Lisp Workshop Message-ID: [ Apologies for the circular; no doubt most people have already seen this -- though note that this Call for Papers contains important information about a financial incentive! With nothing to do for now but test and fix bugs, there should be loads of spare energy for writing papers... ] +----------------------------------------------------------------------+ | 3rd European Lisp Workshop | | July 3 & 4 - Nantes, Frances - co-located with ECOOP 2006 | | Supported by ALU and Ravenbrook Limited | +----------------------------------------------------------------------+ Important News * Nick Levine will be giving a keynote presentation at the workshop. He has been a professional Lisp consultant for over two decades and is the organizer of the upcoming International Lisp Conference in Cambridge, UK. We are grateful to Ravenbrook Limited for sponsoring the keynote presentation. * The Association of Lisp Users has kindly sponsored a $500 prize fund for exceptional papers submitted to this year's workshop. Both the ALU and the workshop organizers are looking forward to your submissions. Important Dates Submission deadline (papers & breakout groups): April 1, 2006 Notification of acceptance: May 1, 2006 ECOOP early registration deadline: May 23, 2006 For more information visit http://lisp-ecoop06.bknr.net/ Contact: Pascal Costanza, pc at p-cos.net Organizers ********** Pascal Costanza, Programming Technology Lab, Vrije Universiteit Brussel Theo D'Hondt, Programming Technology Lab, Vrije Universiteit Brussel Arthur Lemmens, Independent Consultant, Amsterdam Christophe Rhodes, Goldsmiths College, University of London Overview ******** "...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." -- Kent Pitman Lisp is one of the oldest computer languages still in use today. In the decades of its existence, Lisp has been a fruitful basis for language design experiments as well as the preferred implementation language for applications in diverse fields. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Common Lisp, with the Common Lisp Object System (CLOS), was the first object-oriented programming language to receive an ANSI standard and retains the most complete and advanced object system of any programming language, while influencing many other object-oriented programming languages that followed. It is clear that Lisp is gaining momentum: there is a steadily growing interest in Lisp itself, with numerous user groups in existence worldwide, and in Lisp's metaprogramming notions which are being transferred to other languages, as for example in Aspect-Oriented Programming, support for Domain-Specific Languages, and so on. This two-day workshop will address the near-future role of Lisp-based languages in research, industry and education. We solicit papers and suggestions for breakout groups that discuss the opportunities Lisp provides to capture and enhance the possibilities in software engineering. We want to promote lively discussion between researchers proposing new approaches and practitioners reporting on their experience with the strengths and limitations of current Lisp technologies. The workshop will have two components on separate days; there will be a day for formally-presented talks, and a day for breakout groups discussing or working on particular topics. Additionally, there will be opportunities for short, informal talks and demonstrations on experience reports, underappreciated results, software under development, or other topics of interest. Papers ****** Formal presentations in the workshop should take between 20 minutes and half an hour; additional time will be given for questions and answers. We encourage that papers be published on the website in order to provide background information in advance. Suggested Topics New language features or abstractions Experience reports or case studies Protocol Metaprogramming and Libraries Educational approaches Software Evolution Development Aids Persistent Systems Dynamic Optimization Implementation techniques Innovative Applications Hardware Support for Lisp systems Macro-, reflective-, meta- and/or rule-based development approaches Aspect-Oriented, Domain-Oriented and Generative Programming Breakout Groups *************** The workshop will provide for the opportunity to meet face to face and work on focused topics. We will organize these breakout groups and provide for rooms and infrastructure. Suggested Topics for Breakout Groups Lisp Infrastructure Development and Distribution Language Features (e.g. Predicate Dispatching) Environments for creating web applications Brainstorming sessions for new or existing open source projects Persistence Systems Compiler technology Lisp on bare metal / Lisp hardware / Lisp operating systems Compare and enhance curricula for computer science education Submission Guidelines ********************* Potential attendees are encouraged to submit * a long paper (10 pages) presenting scientific and/or empirical results about Lisp-based uses or new approaches for software engineering purposes; * a short essay (5 pages) defending a position about where research, practice or education based on Lisp should be heading in the near future; * a proposal for a breakout group (1-2 pages) describing the theme, an agenda and/or expected results. Submissions should be mailed as PDF to Pascal Costanza (pc at p-cos.net) before the submission deadline. From clemens at endorphin.org Mon Mar 13 15:44:06 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Mon, 13 Mar 2006 16:44:06 +0100 Subject: [mcclim-devel] Scigraph's DWIM layer Message-ID: <20060313155510.965D93C392@irulan.endorphin.org> I'm interested in using Scigraph for generating histograms, but atm scigraph isn't in a good shape. The compatiblity layer for DWIM generates about 5-8 compile warnings (depends whether one is compiling to a fresh image or an image already containing dwim). I would like to ask what's the future of the compatiblity layer. We have a lot read-time conditionals for genera or clim 0.9/1 in the dwim files. I'm pondering to remove these conditionals, as mcclim isn't clim-0.9 nor clim-1. Also there are some hacks for non-ansi CL environments. I'm temped to remove them too as I would have to wrap those things in #-ansi-cl. But that's not really useful anyway, as mcclim is ansi-cl. So what about that: DWIM as contained in the mcclim repository is a compatiblity layer for running dynamic window code on mcclim (and only on mcclim) in an ANSI CL environment. With a definition as above I could kick out ~25% of the DWIM code. Opinions? -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap at endorphin.org From moore at bricoworks.com Mon Mar 13 22:45:56 2006 From: moore at bricoworks.com (Timothy Moore) Date: Mon, 13 Mar 2006 23:45:56 +0100 Subject: [mcclim-devel] Freeze period start for McCLIM 0.9.2 In-Reply-To: <87d5grgs6g.wl%asf@boinkor.net> References: <87ek17gwfs.wl%asf@boinkor.net> <87d5grgs6g.wl%asf@boinkor.net> Message-ID: <4415F624.1020500@bricoworks.com> Andreas Fuchs wrote: > On 2006-03-12, Andreas Fuchs wrote: >> This mail marks the start of the freeze period for McCLIM 0.9.2. > > Erm, not quite. Last-minute feature greediness on my part (and Tim's > promise to get drag & drop of presentations to work and to not break > anything) have made me reconsider starting the freeze today. > > An updated and final freeze mark mail will go out within 24 hours, > when (hopefully) Tim has gotten presentation drag translators to work > or when we backed out the change. > > Thanks for your patience, (: I want to thank the release engineer's indulgence, however selfish his motivations :) I think drag-and-drop is in good enough shape to be labeled as "experimental" and not disrupt the rest of the system. I may try to sneak in a fix or two for the highlighting in drag-and-drop, but I promise that nothing will be major. One thing I think worth hacking on even during the freeze is the Beagle back end, which doesn't work right now due to bit rot. A couple of methods need to be implemented to at least get the address book demo working again. It would be really nice to ship the release with the Beagle back end at least limping along. We don't have a good bug data base other than Paolo's wiki page at http://mcclim.cliki.net/Bug. This is unfortunate and should be addressed after the release in order to get ready for the next one (in a couple of months, right Andreas?), but it's all we've got for now. I'm going to add another one soon. We should take a look and see if any can be fixed easily now and which ones should be a priority for next release. Tim From moore at bricoworks.com Mon Mar 13 22:23:37 2006 From: moore at bricoworks.com (Timothy Moore) Date: Mon, 13 Mar 2006 23:23:37 +0100 Subject: [mcclim-devel] Scigraph's DWIM layer In-Reply-To: <20060313155510.965D93C392@irulan.endorphin.org> References: <20060313155510.965D93C392@irulan.endorphin.org> Message-ID: <4415F0E9.4010406@bricoworks.com> Clemens Fruhwirth wrote: > I'm interested in using Scigraph for generating histograms, but atm > scigraph isn't in a good shape. The compatiblity layer for DWIM > generates about 5-8 compile warnings (depends whether one is compiling > to a fresh image or an image already containing dwim). > > I would like to ask what's the future of the compatiblity layer. We have > a lot read-time conditionals for genera or clim 0.9/1 in the dwim > files. I'm pondering to remove these conditionals, as mcclim isn't > clim-0.9 nor clim-1. Also there are some hacks for non-ansi CL > environments. I'm temped to remove them too as I would have to wrap > those things in #-ansi-cl. But that's not really useful anyway, as > mcclim is ansi-cl. What, and get rid of #FEATURE-CASE? :) > > So what about that: DWIM as contained in the mcclim repository is a > compatiblity layer for running dynamic window code on mcclim (and only > on mcclim) in an ANSI CL environment. > > With a definition as above I could kick out ~25% of the DWIM > code. Opinions? Although I found the Dynamic Windows code in DWIM interesting from a historical perspective, I think it's fine to strip it down to code that only supports McCLIM. I believe there are a couple of functions that are disabled in McCLIM; it would be worthwhile to investigate those and fix the problems in McCLIM. Tim From asf at boinkor.net Mon Mar 13 23:24:16 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Tue, 14 Mar 2006 00:24:16 +0100 Subject: [mcclim-devel] Truly freezing now (was: Freeze period start for McCLIM 0.9.2) In-Reply-To: <87d5grgs6g.wl%asf@boinkor.net> References: <87ek17gwfs.wl%asf@boinkor.net> <87d5grgs6g.wl%asf@boinkor.net> Message-ID: <8764migc7z.wl%asf@boinkor.net> Today, Andreas Fuchs wrote: > On 2006-03-12, Andreas Fuchs wrote: >> This mail marks the start of the freeze period for McCLIM 0.9.2. > > An updated and final freeze mark mail will go out within 24 hours, > when (hopefully) Tim has gotten presentation drag translators to > work or when we backed out the change. So we now have experimental drag & drop presentation translator support. This mail marks the real start of the freeze period for 0.9.2. Please be conservative in choosing what you commit, and aggressive in choosing what you test. As per Tim's suggestion, the Beagle backend is fair game, as are bugs on the mcclim.cliki.net/Bug page. Also, feel free to read through the new documentation in Doc/Guided-Tour/ and post suggestion and corrections here. In fact, corrections and suggestions are always welcome here, especially in the form of unified diff patches. (-: Thanks, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From dtc at scieneer.com Tue Mar 14 02:38:18 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Tue, 14 Mar 2006 13:38:18 +1100 Subject: [mcclim-devel] Patch: Define x-lisp-fasl extensions for CMUCL and SCL. Message-ID: <44162C9A.5050009@scieneer.com> * Apps/Listener/file-types.lisp: Define x-lisp-fasl extensions for CMUCL and SCL. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mcclim-patch-fasl-types URL: From dtc at scieneer.com Tue Mar 14 02:45:32 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Tue, 14 Mar 2006 13:45:32 +1100 Subject: [mcclim-devel] Patch: freetype support for SCL and CMUCL. Message-ID: <44162E4C.7000503@scieneer.com> * Experimental/freetype/: Add support for the Scieneer CL, and also attempt to support CMUCL. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mcclim-patch-freetype URL: From dtc at scieneer.com Tue Mar 14 02:47:18 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Tue, 14 Mar 2006 13:47:18 +1100 Subject: [mcclim-devel] Patch: Support for the Scieneer CL. Message-ID: <44162EB6.80708@scieneer.com> The attached patches, and the files Lisp-Dep/fix-scl.lisp and Lisp-Dep/mp-scl.lisp, add support for the Scieneer CL implementation. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mcclim-patch-scl URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mp-scl.lisp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-scl.lisp URL: From dtc at scieneer.com Tue Mar 14 02:30:44 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Tue, 14 Mar 2006 13:30:44 +1100 Subject: [mcclim-devel] Patch: Printing port objects with a 'nil display. Message-ID: <44162AD4.3070500@scieneer.com> * Backends/CLX/port.lisp, print-object (clx-port): handle the 'display slot being 'nil. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mcclim-patch-port-display URL: From dtc at scieneer.com Tue Mar 14 02:35:09 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Tue, 14 Mar 2006 13:35:09 +1100 Subject: [mcclim-devel] Patch: add 'stream-clear-input methods. Message-ID: <44162BDD.5050202@scieneer.com> * stream-input.lisp: add 'stream-clear-input methods for 'standard-input-stream, and 'standard-extended-input-stream. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mcclim-patch-stream-input URL: From athas at sigkill.dk Tue Mar 14 09:19:13 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 14 Mar 2006 10:19:13 +0100 Subject: [mcclim-devel] Patch for CLX backend `medium-draw-ellipse*'-bug In-Reply-To: <87hd63uz29.fsf@sigkill.dk> (Troels Henriksen's message of "Sun, 12 Mar 2006 22:34:54 +0100") References: <87hd63uz29.fsf@sigkill.dk> Message-ID: <87acbt1izy.fsf@sigkill.dk> Troels Henriksen writes: > The attached patch fixes this issue I should learn to test things better. The attached patch fixes this properly (and I'm reasonably sure that the bug reporters intended behavior is a bug in LispWorks). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: medium.lisp.diff URL: -------------- next part -------------- -- \ Troels "Athas" Henriksen /\ - Insert witty signature From csr21 at cam.ac.uk Tue Mar 14 11:38:35 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 14 Mar 2006 11:38:35 +0000 Subject: [mcclim-devel] latin1ization of goatee Message-ID: Hi, The attached patch implements latin1 character commands for Goatee, running under SBCL and a bleeding-edge CLX. It should cause no harm for any other environment. May I check it in, Mr Release Manager? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: latin1.diff URL: -------------- next part -------------- demonstrates the patch in action. Cheers, Christophe From clemens at endorphin.org Tue Mar 14 15:27:21 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Tue, 14 Mar 2006 16:27:21 +0100 Subject: [mcclim-devel] mcclim-freetype CCL fix Message-ID: <20060314153834.6F3823C392@irulan.endorphin.org> mcclim-freetype.asd uses a custom asdf class, namely uncompiled-cl-source to enforce that "freetype-ffi.lisp" is loaded as source. I'm not sure what are the technical reasons for this but replacing uncompiled-cl-source with a regular :file gives a lot of errors. The uncompiled-cl-source workaround does not work with CCL as it expects output to the derived output files. I fixed the workaround (that's all I can do given my insight into compiled FFI fasls) by checking whether input or output are equal. If they are not, copy input-file to output-file. Here is the beauty-below-average patch. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freetype-ccl-fix.diff URL: -------------- next part -------------- -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap at endorphin.org From amoroso at mclink.it Tue Mar 14 16:01:19 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 14 Mar 2006 17:01:19 +0100 Subject: [mcclim-devel] Where is the code for spatial trees? Message-ID: <873bhlqals.fsf@plato.moon.paoloamoroso.it> The code for spatial trees has recently been committed to the CVS repository, but I can't find it in a freshly checked out working copy of McCLIM. Where is it supposed to be? Is it a separate CVS module? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Tue Mar 14 16:13:10 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 14 Mar 2006 16:13:10 +0000 Subject: [mcclim-devel] Where is the code for spatial trees? In-Reply-To: <873bhlqals.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Tue, 14 Mar 2006 17:01:19 +0100") References: <873bhlqals.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > The code for spatial trees has recently been committed to the CVS > repository, but I can't find it in a freshly checked out working > copy of McCLIM. Where is it supposed to be? Is it a separate CVS > module? Cheers, Christophe From csr21 at cam.ac.uk Tue Mar 14 15:43:31 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 14 Mar 2006 15:43:31 +0000 Subject: [mcclim-devel] mcclim-freetype CCL fix In-Reply-To: <20060314153834.6F3823C392@irulan.endorphin.org> (Clemens Fruhwirth's message of "Tue, 14 Mar 2006 16:27:21 +0100") References: <20060314153834.6F3823C392@irulan.endorphin.org> Message-ID: Clemens Fruhwirth writes: > The uncompiled-cl-source workaround does not work with CCL as it expects > output to the derived output files. What is CCL? > I fixed the workaround (that's all I > can do given my insight into compiled FFI fasls) by checking whether > input or output are equal. If they are not, copy input-file to > output-file. > > Here is the beauty-below-average patch. Can you see if, instead of this patch, making uncompiled-cl-source-file just inherit from source-file works? (The technical reason for loading this file as source is that there is an apparently long-standing SBCL bug which causes it to miscompile some of the slot accesses in there if it's compiled, but not if it's loaded as source. This is strongly suboptimal.) Cheers, Christophe From clemens at endorphin.org Tue Mar 14 16:45:24 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Tue, 14 Mar 2006 17:45:24 +0100 Subject: [mcclim-devel] mcclim-freetype CCL fix In-Reply-To: References: <20060314153834.6F3823C392@irulan.endorphin.org> Message-ID: <20060314165636.D36B73C392@irulan.endorphin.org> Christophe Rhodes wrote: > Clemens Fruhwirth writes: > > > The uncompiled-cl-source workaround does not work with CCL as it expects > > output to the derived output files. > > What is CCL? Sorry, I meant CLC, common-lisp-controller. > > I fixed the workaround (that's all I > > can do given my insight into compiled FFI fasls) by checking whether > > input or output are equal. If they are not, copy input-file to > > output-file. > > > > Here is the beauty-below-average patch. > > Can you see if, instead of this patch, making > uncompiled-cl-source-file just inherit from source-file works? uncompiled-cl-source-file already inherits from source-file via its cl-source-file superclass. In case you meant that this should be changed, the result is an error There is no applicable method for the generic function # when called with arguments (# #). -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap at endorphin.org From amoroso at mclink.it Tue Mar 14 16:51:20 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 14 Mar 2006 17:51:20 +0100 Subject: [mcclim-devel] Truly freezing now (was: Freeze period start for McCLIM 0.9.2) References: <87ek17gwfs.wl%asf@boinkor.net> <87d5grgs6g.wl%asf@boinkor.net> <8764migc7z.wl%asf@boinkor.net> Message-ID: <87d5gpotpz.fsf@plato.moon.paoloamoroso.it> Andreas Fuchs writes: > This mail marks the real start of the freeze period for 0.9.2. Please > be conservative in choosing what you commit, and aggressive in > choosing what you test. Well, you asked for it. I have tried building a freshly checked out copy of McCLIM's CVS repository with CMUCL Snapshot 2005-11 (19C) under Slackware Linux 10.0. Compilation aborts with this error: [...] ; /home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f written. ; Compilation finished in 0:00:00. ; Loading #P"/home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f". ; Loading #P"/home/paolo/src/dev/mcclim/Backends/PostScript/sheet.x86f". Execution of a form compiled with errors: (DEFMETHOD SHEET-DIRECT-MIRROR ((SHEET POSTSCRIPT-STREAM)) (POSTSCRIPT-STREAM-FILE-STREAM SHEET)) [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] Restarts: 0: [CONTINUE] Return NIL from load of #P"/home/paolo/src/dev/mcclim/Backends/PostScript/sheet.x86f". 1: [RETRY ] Retry performing # on #. 2: [ACCEPT ] Continue, treating # on # as having been successful. 3: [ABORT ] Return to Top-Level. Debug (type H for help) (C::DO-CALL # 78 79 4 ...) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/byte-interp.lisp. 0] Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Tue Mar 14 17:18:17 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 14 Mar 2006 17:18:17 +0000 Subject: [mcclim-devel] mcclim-freetype CCL fix In-Reply-To: <20060314165636.D36B73C392@irulan.endorphin.org> (Clemens Fruhwirth's message of "Tue, 14 Mar 2006 17:45:24 +0100") References: <20060314153834.6F3823C392@irulan.endorphin.org> <20060314165636.D36B73C392@irulan.endorphin.org> Message-ID: Clemens Fruhwirth writes: > Christophe Rhodes wrote: > >> Clemens Fruhwirth writes: >> >> > The uncompiled-cl-source workaround does not work with CCL as it expects >> > output to the derived output files. >> >> What is CCL? > > Sorry, I meant CLC, common-lisp-controller. Ah, I see; the issue is in the clc around method. >> Can you see if, instead of this patch, making >> uncompiled-cl-source-file just inherit from source-file works? > > uncompiled-cl-source-file already inherits from source-file via its > cl-source-file superclass. In case you meant that this should be > changed, the result is an error > > There is no applicable method for the generic function > # > when called with arguments > (# > #). Please try the attached patch, which might be a little bit more asdfly correct. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ft.asd.diff URL: -------------- next part -------------- Cheers, Christophe From rpgoldman at real-time.com Tue Mar 14 19:47:28 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 14 Mar 2006 13:47:28 -0600 Subject: [mcclim-devel] diff for guided-tour.tex Message-ID: <17431.7632.25804.111807@necronomicon.sift.info> Almost all of the changes in the following are simple tweaks to fix grammatical nits. However, there were a few places where I inserted comments (invisible to the reader of the formatted documents) suggesting amplifications that I didn't feel qualified to write myself. For example, there is a very helpful discussion about the notion of protocol that is found in a footnote; I think that this should be pulled out of the footnote and moved to the introduction, because it helps the reader understand the whole discussion. Such comments are marked with a date stamp with my initials. I only managed to get up to the end of section 4 (before the start of "Simple Applications." I'll try to do more as time permits. Unless I hear a squawk pretty soon (24 hours?), I'll commit the changes. They're really pretty minor. Index: guided-tour.tex =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Doc/Guided-Tour/guided-tour.tex,v retrieving revision 1.2 diff -c -r1.2 guided-tour.tex *** guided-tour.tex 9 Feb 2006 13:20:38 -0000 1.2 --- guided-tour.tex 14 Mar 2006 19:41:16 -0000 *************** *** 89,98 **** The Common Lisp Interface Manager addresses this problem by specifying an interface to a broad range of services necessary or useful for developing graphical user interfaces. These services include low level ! facilities like geometry, graphics, event-oriented input, and ! windowing; intermediate level facilities like support for Common Lisp stream operations, output recording, and advanced output formatting; ! and high level facilities like context sensitive input, an adaptive toolkit, and an application building framework. \CLIM{} implementations will eventually support a large number of window environments --- 89,98 ---- The Common Lisp Interface Manager addresses this problem by specifying an interface to a broad range of services necessary or useful for developing graphical user interfaces. These services include low level ! facilities such as geometry, graphics, event-oriented input, and ! windowing; intermediate level facilities such as support for Common Lisp stream operations, output recording, and advanced output formatting; ! and high level facilities such as context sensitive input, an adaptive toolkit, and an application building framework. \CLIM{} implementations will eventually support a large number of window environments *************** *** 101,110 **** to the degree that it makes sense. For example, \CLIM{} top level windows are typically mapped onto host windows, and input and output operations are ultimately performed by host window system ! code. Another example is that \CLIM{} supports the incorporation of toolkits written in other languages. A uniform interface provided by \CLIM{} allows Lisp application programmers to deal only with Lisp ! objects and functions regardless of their operating platform. An important goal that has guided the design of \CLIM{} was to layer the specification into a number of distinct --- 101,110 ---- to the degree that it makes sense. For example, \CLIM{} top level windows are typically mapped onto host windows, and input and output operations are ultimately performed by host window system ! code. \CLIM{} supports the incorporation of toolkits written in other languages. A uniform interface provided by \CLIM{} allows Lisp application programmers to deal only with Lisp ! objects and functions regardless of the operating platform. An important goal that has guided the design of \CLIM{} was to layer the specification into a number of distinct *************** *** 127,136 **** For example, \CLIM{}'s application framework and adaptive toolkit allow programmers to develop applications that automatically adopt the look ! and feel of the host's environment. (We often call this ``adaptiveness,'' ``look and feel independence,'' or occasionally more ! picturesquely, ``chameleon look and feel''.) However, many users may ! need or want to define a particular look and feel that stays constant across all host environments (we call this ``portable look and feel''). Such users can circumvent the look and feel adaptiveness provided by \CLIM{}, while still using most of the application --- 127,136 ---- For example, \CLIM{}'s application framework and adaptive toolkit allow programmers to develop applications that automatically adopt the look ! and feel of the host's environment. We often call this ``adaptiveness,'' ``look and feel independence,'' or occasionally more ! picturesquely, ``chameleon look and feel''. However, many users may ! need or want to define a particular look and feel that is constant across all host environments (we call this ``portable look and feel''). Such users can circumvent the look and feel adaptiveness provided by \CLIM{}, while still using most of the application *************** *** 168,174 **** \caption{An Overview of \CLIM{} facilities}\label{clim-facilities} \end{figure*} ! \paragraph*{Graphic substrate} \CLIM{} provides a portable interface to a broad set of graphics functions for drawing complex geometric shapes. --- 168,174 ---- \caption{An Overview of \CLIM{} facilities}\label{clim-facilities} \end{figure*} ! \paragraph*{Graphics substrate} \CLIM{} provides a portable interface to a broad set of graphics functions for drawing complex geometric shapes. *************** *** 177,183 **** \paragraph*{Extended Streams} \CLIM{} integrates the Common Lisp Stream I/O functionality with the \CLIM{} graphics, windowing, and ! panes facilities. Next to ordinary text, the programmer can send a button, a picture or any other arbitrary widget to a \CLIM{} output stream and \CLIM{} will display the widget in the sheet associated with the output stream. --- 177,185 ---- \paragraph*{Extended Streams} \CLIM{} integrates the Common Lisp Stream I/O functionality with the \CLIM{} graphics, windowing, and ! panes facilities. ! % I believe that this was what was intended [2006/03/14:rpg] ! In addition to ordinary text, the programmer can send a button, a picture or any other arbitrary widget to a \CLIM{} output stream and \CLIM{} will display the widget in the sheet associated with the output stream. *************** *** 189,202 **** \paragraph*{Formatted Output} \CLIM{} provides a set of high-level macros that enable programs to produce neatly formatted tabular and graphical displays easily.\footnote{This also includes Graph ! Formatting.} \paragraph*{Presentations} \CLIM{} provides the ability to associate semantics with output, such that Lisp objects may be retrieved later via user gestures (e.g.{} mouse clicks) on their displayed representation. This context sensitive input is modularly layered on top of the output recording facility and is integrated with the Common ! Lisp type system. A mechanism for type coercion is also included, providing the basis for powerful user interfaces. \paragraph*{Panes} \CLIM{} provides \concept{panes} that are analogous --- 191,209 ---- \paragraph*{Formatted Output} \CLIM{} provides a set of high-level macros that enable programs to produce neatly formatted tabular and graphical displays easily.\footnote{This also includes Graph ! Formatting. Graph formatting is only partly implemented in McCLIM ! at this date (March 2006).} \paragraph*{Presentations} \CLIM{} provides the ability to associate semantics with output, such that Lisp objects may be retrieved later via user gestures (e.g.{} mouse clicks) on their displayed representation. This context sensitive input is modularly layered on top of the output recording facility and is integrated with the Common ! Lisp type system. ! % I understand this, but I suspect it's not going to be obvious to the ! % ordinary reader why type coercion provides the basis for a user ! % interface... [2006/03/14:rpg] ! A mechanism for type coercion is also included, providing the basis for powerful user interfaces. \paragraph*{Panes} \CLIM{} provides \concept{panes} that are analogous *************** *** 212,220 **** independence by specifying a set of abstract gadget pane protocols. These protocols define a gadget in terms of its function and not in terms of the details of its appearance or ! operation. Application that use these gadget types and related facilities will automatically adapt to use whatever toolkit is ! available and appropriate for the host environment. In addition, portable Lisp-based implementations of the abstract gadget pane protocols are provided.\footnote{\mcclim{} does not support look and feel adaptiveness at the moment except for the experimental beagle backend for Mac --- 219,227 ---- independence by specifying a set of abstract gadget pane protocols. These protocols define a gadget in terms of its function and not in terms of the details of its appearance or ! operation. Applications that use these gadget types and related facilities will automatically adapt to use whatever toolkit is ! available on and appropriate for the host environment. In addition, portable Lisp-based implementations of the abstract gadget pane protocols are provided.\footnote{\mcclim{} does not support look and feel adaptiveness at the moment except for the experimental beagle backend for Mac *************** *** 234,240 **** presentation. Commands can also be invoked explicitly by the programmer. ! \paragraph*{Dialogs and Incremental Update} Incremental Redisplay goes a bit further than Output Recording. With Incremental Redisplay, an output record can not only reproduce content that was written to a stream, the \CLIM{} programmer can also attach the code that generated --- 241,249 ---- presentation. Commands can also be invoked explicitly by the programmer. ! % added ``Redisplay'' below so that the paragraph header harmonizes ! % with the jargon used in the paragraph. ! \paragraph*{Dialogs and Incremental Update/Redisplay} Incremental Redisplay goes a bit further than Output Recording. With Incremental Redisplay, an output record can not only reproduce content that was written to a stream, the \CLIM{} programmer can also attach the code that generated *************** *** 253,262 **** \section{Our first application} ! We will spend a few lines of code for the trivial Hello World example to give the reader a test case to verify his \CLIM{} setup. It also serves as a point of reference from where the reader can start his ! explorations for more challenging \CLIM{} facilities. We do not try to elaborate the \CLIM{} concepts in detail here, but simply use them with a brief discussion. The confused reader may hope for a more in-depth explanation in the following section. Please regard --- 262,271 ---- \section{Our first application} ! We will start with a few lines of code for the trivial Hello World example to give the reader a test case to verify his \CLIM{} setup. It also serves as a point of reference from where the reader can start his ! explorations of more challenging \CLIM{} facilities. We do not try to elaborate the \CLIM{} concepts in detail here, but simply use them with a brief discussion. The confused reader may hope for a more in-depth explanation in the following section. Please regard *************** *** 264,290 **** \concept{sheet hierarchy}, \concept{graft} and \concept{top-level loop} as terms we will discuss later. ! Also, we conduct excessive \CLIM{} specification referencing in footnotes. The motivation for this is to show that all the relevant information can be found in the \CLIM{} 2 specification\cite{clim-spec}. Before a good \CLIM{} programmer can master any \CLIM{} concept, he has to get used to the style of writing ! of the specification first as this is the most relevant work for ! \CLIM{}. The best we can do in this context is to provide pointers and references and hope that the interested reader starts to explore the surrounding text sections on his own. After loading a \CLIM{} implementation, the package \keyword{:clim-user} is available to absorb user code. This package is ! a good start for experimentations and first steps. When proper packaging is required, simply include the packages \keyword{:clim} and ! \keyword{:clim-lisp} in your \keyword{:use} list. The central element of \CLIM{} application programming is the \concept{application-frame}. An application frame is defined via \code{define-application-frame}.\footnote{See Section 28.2 ``Defining ! and Creating Application Frames'' in \cite{clim-spec}.} Here comes ! the application frame for Hello World: \lstset{style=inlinestyle} \lstinputlisting{hello-world-def-app} --- 273,299 ---- \concept{sheet hierarchy}, \concept{graft} and \concept{top-level loop} as terms we will discuss later. ! We provide extensive \CLIM{} specification references in footnotes. The motivation for this is to show that all the relevant information can be found in the \CLIM{} 2 specification\cite{clim-spec}. Before a good \CLIM{} programmer can master any \CLIM{} concept, he has to get used to the style of writing ! of the specification, as this is the most relevant work for ! \CLIM{}. The best we can do in this short paper is provide pointers and references and hope that the interested reader starts to explore the surrounding text sections on his own. After loading a \CLIM{} implementation, the package \keyword{:clim-user} is available to absorb user code. This package is ! a good start for experimentation and first steps. When proper packaging is required, simply include the packages \keyword{:clim} and ! \keyword{:clim-lisp} in your new package's \keyword{:use} list. The central element of \CLIM{} application programming is the \concept{application-frame}. An application frame is defined via \code{define-application-frame}.\footnote{See Section 28.2 ``Defining ! and Creating Application Frames'' in \cite{clim-spec}.} Here is ! the application frame definition for Hello World: \lstset{style=inlinestyle} \lstinputlisting{hello-world-def-app} *************** *** 293,309 **** \lstinputlisting{hello-world-handle-repaint} \caption{\method{handle-repaint} for \class{hello-world-pane}}\label{hello-world-repaint} \end{figure*} ! Its basic syntax is similar to \code{defclass} because \code{define-application-frame} also generates classes. In this case, it creates a frame class \class{hello-world} that has no superclass ! except \class{frame} which is added automatically. With \code{:pane}, we define a \concept{top-level-pane} that becomes ! the content of the fresh window that belongs to an application ! frame. But sometimes, an application frame is swallowed by another ! application and only space in an other existing window is reserved. For instance, a web site management tool might swallow a ! text editor, so the user has the option to edit web sites without switching to another application. % \footnote{The graft is the root of a sheet hierarchy and on most --- 302,319 ---- \lstinputlisting{hello-world-handle-repaint} \caption{\method{handle-repaint} for \class{hello-world-pane}}\label{hello-world-repaint} \end{figure*} ! \code{define-application-frame}'s basic syntax is similar to \code{defclass} because \code{define-application-frame} also generates classes. In this case, it creates a frame class \class{hello-world} that has no superclass ! except \class{frame} (which is added automatically). With \code{:pane}, we define a \concept{top-level-pane} that becomes ! the content of a fresh window that belongs to an application ! frame. Although the usual case is for an application frame to ! correspond to a top level window, sometimes an application frame is swallowed by another ! application and only space in another existing window is reserved. For instance, a web site management tool might swallow a ! text editor, so that the user has the option to edit web sites without switching to another application. % \footnote{The graft is the root of a sheet hierarchy and on most *************** *** 320,339 **** created. We use \method{make-pane} to construct a pane as the top-level-pane for frame instances. \method{make-pane} is a constructor for panes.\footnote{See Section 29.2 ``Basic Pane ! Construction'' in \cite{clim-spec}.} We can treat it as \code{make-instance} especially made for pane classes. Let us have a look at the definition of \class{hello-world-pane}. \lstset{style=inlinestyle} \lstinputlisting{hello-world-defclass} The one and only superclass of \class{hello-world-pane} is ! \class{clim-stream-pane}\footnote{See Section 29.4 ``CLIM Stream ! Panes'' in \cite{clim-spec}.}. As there are no additional slots, an ! experienced \CLOS{} user might guess that we will use \class{hello-world-pane} solely for method specialization. Before doing so, let us have a look what we have actually ! inherited from \class{clim-stream-pane}\footnote{Internal classes ! removed from listing.}: \lstset{style=inlinestyle} \begin{lstlisting} --- 330,349 ---- created. We use \method{make-pane} to construct a pane as the top-level-pane for frame instances. \method{make-pane} is a constructor for panes.\footnote{See Section 29.2 ``Basic Pane ! Construction'' in \cite{clim-spec}.} We can treat it as an analog to \code{make-instance} especially made for pane classes. Let us have a look at the definition of \class{hello-world-pane}. \lstset{style=inlinestyle} \lstinputlisting{hello-world-defclass} The one and only superclass of \class{hello-world-pane} is ! \class{clim-stream-pane}.\footnote{See Section 29.4 ``CLIM Stream ! Panes'' in \cite{clim-spec}.} As there are no additional slots, an ! experienced \CLOS{} programmer might guess that we will use \class{hello-world-pane} solely for method specialization. Before doing so, let us have a look what we have actually ! inherited from \class{clim-stream-pane}:\footnote{Internal classes ! removed from listing.} \lstset{style=inlinestyle} \begin{lstlisting} *************** *** 349,354 **** --- 359,368 ---- BASIC-PANE \end{lstlisting} + % would it be appropriate to define the phrase ``protocol class'' + % here? I'm not sufficiently confident in my CLIM fu to provide a + % definition myself. [2006/03/14:rpg] + \class{basic-pane} is the foundation of all pane classes. It provides reasonable defaults for all protocol methods and inherits from the protocol class \class{pane}. In turn, \class{pane} inherits from *************** *** 399,404 **** --- 413,425 ---- \subsection{Geometry} + % The footnote describing ``protocol'' below seems to give a critical + % insight into the style and functioning of CLIM. It should certainly + % be promoted out of footnote and into body text. I'm inclined to + % think it should be promoted to the introduction. The notion of + % Protocol is alluded to there, but not clearly described. + % [2006/03/14:rpg] + To \CLIM{}, geometry means \concept{regions}. A region is either bound or unbound and has a dimensionality of either zero, one or two. That corresponds to a point, a path or an area respectively. Regions can be *************** *** 421,430 **** transformation is affine when every straight line remains straight after transformation. Transformations can be composed arbitrarily. The programmer can attach transformations to mediums and panes. In layout ! panes, \CLIM{} uses transformation to map the coordinates of children ! panes to the coordinate system of its parents. All drawing settings ! can be changed permanently, or in the context of a ! \macro{with-drawing-options} macro temporarily. \subsection{The Windowing Substrate} --- 442,456 ---- transformation is affine when every straight line remains straight after transformation. Transformations can be composed arbitrarily. The programmer can attach transformations to mediums and panes. In layout ! panes, \CLIM{} uses transformations to map the coordinates of child ! panes to the coordinate system of their parents. ! ! % This was attached to the previous paragraph, but doesn't seem to ! % have anything to do with its topic. I'm inclined to think that this ! % could use some further expansions (have we adequately explained what ! % a drawing setting is?) [2006/03/14:rpg] ! All drawing settings can be changed either permanently, or temporarily ! in the context of the \macro{with-drawing-options} macro. \subsection{The Windowing Substrate} *************** *** 519,525 **** specialization, so the application developer can implement special policies for selected events. For instance, when a sheet notices through a \code{window-configuration-event} that the sheet's size ! changed, it might redo its layout for its children panes. % There are two mixins that specialize on the % \code{window-repaint-event} class as event argument to --- 545,551 ---- specialization, so the application developer can implement special policies for selected events. For instance, when a sheet notices through a \code{window-configuration-event} that the sheet's size ! has changed, it might redo its layout for its children. % There are two mixins that specialize on the % \code{window-repaint-event} class as event argument to *************** *** 561,566 **** --- 587,598 ---- % the sheet's medium. According to the \mcclim{} authors, this is done % for optimization.} + % in the topic sentence here, should it read ``of sheets'' or ``of + % mediums'' (media?). I'm not sure, but if ``sheets'' is meant, we + % should probably have some transition wording here to explain how we + % got from discussing mediums above to discussing sheets here. + % [2006/03/14:rpg] + The graphic output capabilities of sheets range from simple line style and text style customization over rendering various geometrical shapes, a color model capable of doing alpha blending, composable *************** *** 569,577 **** specified briefly in Section 8.3 ``Output Protocol''and more precisely in Chapters 10-14 of \cite{clim-spec}. ! \CLIM{} lives in idealized world in terms of graphics operations. A \CLIM{} programmer can use an infinitely long and wide drawing pane ! with an arbitrarily precise resolution and continuously variable opacity. As rendering devices with these properties are rare, we need to render the idealized graphic description to a device with finite size and a fixed drawing precision. The rendering rules --- 601,609 ---- specified briefly in Section 8.3 ``Output Protocol''and more precisely in Chapters 10-14 of \cite{clim-spec}. ! \CLIM{} lives in an idealized world in terms of graphics operations. A \CLIM{} programmer can use an infinitely long and wide drawing pane ! with arbitrarily precise resolution and continuously variable opacity. As rendering devices with these properties are rare, we need to render the idealized graphic description to a device with finite size and a fixed drawing precision. The rendering rules *************** *** 602,608 **** system window hierarchy) when the frame is adopted. To build a user interface, an application programmer defines one or ! more frames classes. These frame classes define a number of frame properties including application specific state and a hierarchy of panes (i.e.{} user interface gadgets and regions, for interacting with the users). Frame classes also provide hooks for customizing --- 634,640 ---- system window hierarchy) when the frame is adopted. To build a user interface, an application programmer defines one or ! more frame classes. These frame classes define a number of frame properties including application specific state and a hierarchy of panes (i.e.{} user interface gadgets and regions, for interacting with the users). Frame classes also provide hooks for customizing *************** *** 615,621 **** up is usually quite different from the code that is used to generate the content of application frames. This is unusual for a windowing toolkit as most of them unify the generation of dialog content and ! content of other windows types. \CLIM{} generates a dialog with the appropriate input gadget as consequence of a series of input requests. Thanks to the stream --- 647,653 ---- up is usually quite different from the code that is used to generate the content of application frames. This is unusual for a windowing toolkit as most of them unify the generation of dialog content and ! content of other window types. \CLIM{} generates a dialog with the appropriate input gadget as consequence of a series of input requests. Thanks to the stream *************** *** 624,634 **** asynchronously handling confirmation or cancel button clicks. For instance, the programmer requests a string from the user and the user is presented with a prompt, an editable text field, and two buttons ! for confirmation and canceling. Only after the user hits the ! confirmation button, the string requesting function returns; the programmer can directly use the function's return value which is the ! string provided by the user. Clicking the cancel button is dealt with by throwing to an ! \code{abort} tag. From the caller's perspective, an attempt to separate application frames and dialogs could be: a dialog window itself is side-effect --- 656,674 ---- asynchronously handling confirmation or cancel button clicks. For instance, the programmer requests a string from the user and the user is presented with a prompt, an editable text field, and two buttons ! for confirmation and canceling. ! The string requesting function returns only after the user hits the ! confirmation button. The programmer can directly use the function's return value which is the ! string provided by the user. ! % Is the following rewrite correct? Seems like in the actual code an ! % abort-gesture is signaled, but it is handled by invoking an abort, ! % if no abort-gesture handler is found. [2006/03/14:rpg] ! % OLD: ! % Clicking the cancel button is dealt with by throwing to an ! % \code{abort} tag. ! Clicking the cancel button is dealt with by signaling an abort-gesture ! condition. From the caller's perspective, an attempt to separate application frames and dialogs could be: a dialog window itself is side-effect *************** *** 719,727 **** Panes and sheets as defined by the windowing substrate have in common that they are associated with a region on screen, a parent, and optional children. They differ in their usage of the input and output ! capabilities. A sheet is passive and intended for others to be used, ! while a pane already contains this active part. This relationship ! leads that panes are implemented as subclasses of \class{basic-sheet} augmenting the class with an active part. For instance, a button-pane actively draws its own button representation on its allotted screen area and a click on the correct button area triggers a callback for --- 759,769 ---- Panes and sheets as defined by the windowing substrate have in common that they are associated with a region on screen, a parent, and optional children. They differ in their usage of the input and output ! capabilities. A sheet is passive and intended to be used by other, ! active components, ! while a pane already contains this active part. ! For this reason, ! panes are implemented as subclasses of \class{basic-sheet} augmenting the class with an active part. For instance, a button-pane actively draws its own button representation on its allotted screen area and a click on the correct button area triggers a callback for *************** *** 745,759 **** in the case where the programmer needs a lot of buttons with related behavior, creating a subclass for changing a single specific callback is not economical. Hence upon gadget creation, the programmer can ! specify an alternative callback method for all callbacks available. By providing the \keyword{:activate-callback} initarg, the programmer can change the callback to any regular or generic function. By convention, ! all callbacks can be changed by providing an initarg keyword equal to the callback's name. See Chapter 30 in \cite{clim-spec} for a listing and description of available callbacks. \CLIM{} also provides composite and layout panes. These pane types are ! used for aggregating several children panes into a bigger single pane that has a layout according to the requested directives. For example, \CLIM{} provides two pane classes, \class{hbox-pane} and \class{vbox-pane}, that lay out their children in horizontal rows or --- 787,802 ---- in the case where the programmer needs a lot of buttons with related behavior, creating a subclass for changing a single specific callback is not economical. Hence upon gadget creation, the programmer can ! specify an alternative callback method for any callback available. For ! example, by providing the \keyword{:activate-callback} initarg, the programmer can change the callback to any regular or generic function. By convention, ! any callback can be changed by providing an initarg keyword equal to the callback's name. See Chapter 30 in \cite{clim-spec} for a listing and description of available callbacks. \CLIM{} also provides composite and layout panes. These pane types are ! used for aggregating several child panes into a bigger single pane that has a layout according to the requested directives. For example, \CLIM{} provides two pane classes, \class{hbox-pane} and \class{vbox-pane}, that lay out their children in horizontal rows or *************** *** 764,774 **** management via the windowing protocol. He is provided with a set of convenience macros that allows elegant interfaces composed simply by wrapping the respective pane construction code into the convenience ! macros. Application pane classes can be used for subclassing. They can be used to present application specific data -- for instance by specializing ! \method{handle-repaint} -- and manage user interactions -- for instance by specializing \method{handle-event}. \subsection{Commands} --- 807,817 ---- management via the windowing protocol. He is provided with a set of convenience macros that allows elegant interfaces composed simply by wrapping the respective pane construction code into the convenience ! macros. % could we name the convenience macros here? [2006/03/14:rpg] Application pane classes can be used for subclassing. They can be used to present application specific data -- for instance by specializing ! \method{handle-repaint} -- and to manage user interactions -- for instance by specializing \method{handle-event}. \subsection{Commands} *************** *** 784,790 **** choose to export as an explicit user entry point. A command is defined to have a name and a set of zero or more operands, or arguments. These commands can then be invoked using a variety of interaction ! techniques. For example, commands can be invoked from menu, keyboard accelerators, direct typein, mouse clicks on application data, or gadgets. --- 827,833 ---- choose to export as an explicit user entry point. A command is defined to have a name and a set of zero or more operands, or arguments. These commands can then be invoked using a variety of interaction ! techniques. For example, commands can be invoked from menus, keyboard accelerators, direct typein, mouse clicks on application data, or gadgets. From clemens at endorphin.org Wed Mar 15 06:35:59 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Wed, 15 Mar 2006 07:35:59 +0100 Subject: [mcclim-devel] mcclim-freetype CCL fix In-Reply-To: References: <20060314153834.6F3823C392@irulan.endorphin.org> <20060314165636.D36B73C392@irulan.endorphin.org> Message-ID: <20060315064719.2ECA63C392@irulan.endorphin.org> Christophe Rhodes wrote: > Please try the attached patch, which might be a little bit more asdfly > correct. > =================================================================== > RCS file: /project/mcclim/cvsroot/mcclim/Experimental/freetype/mcclim-freetype.asd,v > retrieving revision 1.4 > diff -u -r1.4 mcclim-freetype.asd > --- Experimental/freetype/mcclim-freetype.asd 6 Feb 2006 13:42:09 -0000 1.4 > +++ Experimental/freetype/mcclim-freetype.asd 14 Mar 2006 17:16:14 -0000 Works. Thank you. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap at endorphin.org From clemens at endorphin.org Wed Mar 15 07:32:04 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Wed, 15 Mar 2006 08:32:04 +0100 Subject: [mcclim-devel] another CLC fix: clim-listener Message-ID: <20060315074323.883033C392@irulan.endorphin.org> Another CLC fix: *load-truename* is assumed to point to the source directory that also contains the icons/ directory. In CLC, this isn't the case as all fasl are loaded from /var/cache/common-lisp-controller/. I changed Apps/Listener/package.lisp to also probe in #.*compile-file-truename*, that most likely point to a directory containing the icons too. The problem is that I used cl-fad for directory probing. I personally don't mind to have mcclim use cl-fad, as I have it installed anyway and it's pretty lightweight, but on the other hand that might not be true for the mcclim project as a whole, especially as it needs only a single function. The CLC way of doing things seems a good idea first, but needs to be improved. Probably, CLC should introduce a new asdf class, for instance "auxilary". All files/directories that are tagged as auxilary are symlinked in /var/cache/common-lisp-controller to the original sources. So in the code, we don't have to give up the assumption that *load-truename* contains stuff from the distribution tarball. Or probably CLC shouldn't wait for ":auxilary" and create a mirror of all files in /usr/share/common-lisp/source per default via symlinks. This doesn't seem too costly. Especially when we create symlinks for directories and only when we need to add content these symlinked /var/cache/common-lisp-controller subdirectories turn them into real directories after filling them with the respective symlinks. Kind of lazy symlinking. But err, I'm starting to get off-topic. Here is the patch. If the list objects cl-fad, I'd suggest to copy the respective ~15 lines of code from cl-fad. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clc-fix-for-listeners.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: not available URL: From csr21 at cam.ac.uk Wed Mar 15 11:30:20 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 15 Mar 2006 11:30:20 +0000 Subject: [mcclim-devel] another CLC fix: clim-listener In-Reply-To: <20060315074323.883033C392@irulan.endorphin.org> (Clemens Fruhwirth's message of "Wed, 15 Mar 2006 08:32:04 +0100") References: <20060315074323.883033C392@irulan.endorphin.org> Message-ID: Clemens Fruhwirth writes: > Another CLC fix: Is this a fix for direct users of clc, or is this a fix that is motivated by some future debian packaging? The reason I ask is that I suspect this is the wrong answer, in general, for handling external resources and filesystem-location-independent binaries (which is kind of what we're talking about). Cheers, Christophe From clemens at endorphin.org Wed Mar 15 12:30:15 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Wed, 15 Mar 2006 13:30:15 +0100 Subject: [mcclim-devel] another CLC fix: clim-listener In-Reply-To: References: <20060315074323.883033C392@irulan.endorphin.org> Message-ID: <20060315124139.EC7DE3C392@irulan.endorphin.org> From rpgoldman at real-time.com Wed Mar 15 14:00:38 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 15 Mar 2006 08:00:38 -0600 Subject: [mcclim-devel] another CLC fix: clim-listener In-Reply-To: <20060315074323.883033C392@irulan.endorphin.org> References: <20060315074323.883033C392@irulan.endorphin.org> Message-ID: <17432.7686.482484.33575@necronomicon.sift.info> >>>>> "CF" == Clemens Fruhwirth writes: CF> Another CLC fix: *load-truename* is assumed to point to the CF> source directory that also contains the icons/ directory. In CF> CLC, this isn't the case as all fasl are loaded from CF> /var/cache/common-lisp-controller/. CF> I changed Apps/Listener/package.lisp to also probe in CF> #.*compile-file-truename*, that most likely point to a CF> #directory CF> containing the icons too. CF> The problem is that I used cl-fad for directory probing. I CF> personally don't mind to have mcclim use cl-fad, as I have it CF> installed anyway and it's pretty lightweight, but on the other CF> hand that might not be true for the mcclim project as a whole, CF> especially as it needs only a single function. This suggests a knot of other issues: 1. Having external dependencies is somewhat undesirable in general, but mostly because we don't have clean ways of managing coherent states across multiple systems. E.g., what happens if cl-fad or the spatial-trees systems gets out of synch with McCLIM? As I understand ASDF, you can specify that you need >= a particular dependency system, but you can't specify = or <=. Probably with a little care this can be overcome. More difficult (but possibly conjectural) what happens if *another* system you want loads cl-fad or spatial-trees and the version that other system needs is not congruent with McCLIM's requirements? I know I always get a little nervous when asdf-install loads its private copy of cl-ppcre... Would it be possible to make an internal version of these systems? E.g., would it be possible to load them into alternative packages, so that they can coexist with a different version? E.g., stuff them into clim.cl-fad? That might be the CL equivalent of statically linking against libraries... 2. CL-FAD seems desirable more generally as a component of McCLIM, because McCLIM needs file-managing gadgets, and these probably need more capable ways of getting at the file system than CL provides in its stock form. From jm at mak.com Wed Mar 15 17:01:06 2006 From: jm at mak.com (John Morrison) Date: Wed, 15 Mar 2006 12:01:06 -0500 Subject: [mcclim-devel] another CLC fix: clim-listener In-Reply-To: <17432.7686.482484.33575@necronomicon.sift.info> References: <20060315074323.883033C392@irulan.endorphin.org> <17432.7686.482484.33575@necronomicon.sift.info> Message-ID: <200603151201.06284.jm@mak.com> On Wednesday 15 March 2006 09:00 am, rpgoldman at real-time.com wrote: > More difficult (but possibly conjectural) what happens if > *another* system you want loads cl-fad or spatial-trees and the > version that other system needs is not congruent with McCLIM's > requirements? I know I always get a little nervous when > asdf-install loads its private copy of cl-ppcre... I am using McCLIM to graph cl-graph based graphs, and cl-graph requires cl-fad. So, basically, this problem is not conjectural for me. -jm -- ==== John Morrison ==== MAK Technologies Inc. ==== 68 Moulton Street, Cambridge, MA 02138 ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== jm at mak.com From m.retzlaff at gmx.net Wed Mar 15 17:50:53 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Wed, 15 Mar 2006 18:50:53 +0100 Subject: [mcclim-devel] another CLC fix: clim-listener In-Reply-To: <20060315074323.883033C392@irulan.endorphin.org> References: <20060315074323.883033C392@irulan.endorphin.org> Message-ID: <20060315175053.GA29909@mgr.home> Hello, On Wed, Mar 15, 2006 at 08:32:04AM +0100, Clemens Fruhwirth wrote: > The problem is that I used cl-fad for directory probing. I personally > don't mind to have mcclim use cl-fad, as I have it installed anyway and > it's pretty lightweight, but on the other hand that might not be true > for the mcclim project as a whole, especially as it needs only a single > function. I would like to use cl-fad in mcclim. Right now there is, so to speak, a partial implementation of it included in the Clim Listener; in addition to this my File Selecto [1] depends on the functionality of CL-FAD as well, and I don't quite like to just duplicate the code. As we have now two places where CL-FAD is useful and as we could get rid of some stuff in the Listener I would like to have mcclim use cl-fad; even more as we now have already an external dependency with the spatial-trees package. Btw, I have resisted to include the File Selector in McCLIM as it is not very nice right now, codewise. In the end it should be the default ACCEPT method for files in +gadget-view+ --- this does already partially work (see at the end of file-selector.lisp for the definition) but still the corresponding ACCEPT-PRESENT-DEFAULT method is missing. Also I would much prefor to use WITH-OUTPUT-AS-GADGET in the selector but it is not yet usable for that job in the moment. Bye, Max 1) http://www.matroid.org/flux/file-selector.lisp There are also some screenshots of it in the same directory, see File-Selector-*.png. -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: Hey, father, if god is all powerful can he make a rock so big that can't lift it? -- George Carlin, "Class Clown" (1972) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rpgoldman at real-time.com Wed Mar 15 19:05:31 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Wed, 15 Mar 2006 13:05:31 -0600 Subject: [mcclim-devel] another CLC fix: clim-listener In-Reply-To: <200603151201.06284.jm@mak.com> References: <20060315074323.883033C392@irulan.endorphin.org> <17432.7686.482484.33575@necronomicon.sift.info> <200603151201.06284.jm@mak.com> Message-ID: <17432.25979.757922.864105@necronomicon.sift.info> >>>>> "JM" == John Morrison writes: JM> On Wednesday 15 March 2006 09:00 am, rpgoldman at real-time.com JM> wrote: >> More difficult (but possibly conjectural) what happens if >> *another* system you want loads cl-fad or spatial-trees and the >> version that other system needs is not congruent with McCLIM's >> requirements? I know I always get a little nervous when >> asdf-install loads its private copy of cl-ppcre... JM> I am using McCLIM to graph cl-graph based graphs, and cl-graph JM> requires cl-fad. So, basically, this problem is not JM> conjectural for me. I should have been more clear. The problem is conjectural in the sense that we don't have a case (yet, AFAIK) where version conflict arises. E.g., where someone refactors cl-FAD, changing its API, and cl-graph adopts the bleeding-edge version of cl-fad, but McCLIM stays with cl-fad classic. A counterargument to my claim would be "you should just always use the latest released version." I think in the large this approach is losing. But it's not clear that the CL community IS large enough for it to be a problem. This is a problem that McCLIM experiences, because it uses ASDF, but it's really an ASDF problem, not a McCLIM problem. We (the CL community) are using ASDF as the equivalent of make + a dynamic library loading system + something akin to rpm. It's clearly very good as a make substitute. It's not clear to me that it's all we need for the latter two functions. best, Robert From vincent at arkesteijn.net Wed Mar 15 20:43:52 2006 From: vincent at arkesteijn.net (Vincent Arkesteijn) Date: Wed, 15 Mar 2006 21:43:52 +0100 Subject: [mcclim-devel] fix for remove-command-from-command-table Message-ID: <20060315204352.GA21673@vja> Hi, At present, remove-command-from-command-table doesn't, except for menu-items. The attached patch fixes that. Vincent. -------------- next part -------------- Index: commands.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/commands.lisp,v retrieving revision 1.58 diff -u -F^(def -r1.58 commands.lisp --- commands.lisp 10 Mar 2006 21:58:12 -0000 1.58 +++ commands.lisp 13 Mar 2006 11:34:50 -0000 @@ -203,11 +203,11 @@ (defun remove-command-from-command-table (when (typep item 'menu-item) (remove-menu-item-from-command-table table (command-menu-item-name item) - :errorp nil) - - (when (command-item-name item) - (remhash (command-item-name item) (command-line-names table))) - (remhash command-name (commands table))))))) + :errorp nil)) + + (when (command-item-name item) + (remhash (command-item-name item) (command-line-names table))) + (remhash command-name (commands table)))))) (defun add-command-to-command-table (command-name command-table From moore at bricoworks.com Wed Mar 15 23:00:36 2006 From: moore at bricoworks.com (Timothy Moore) Date: Thu, 16 Mar 2006 00:00:36 +0100 Subject: [mcclim-devel] Patch: Support for the Scieneer CL. In-Reply-To: <44162EB6.80708@scieneer.com> References: <44162EB6.80708@scieneer.com> Message-ID: <44189C94.20009@bricoworks.com> Douglas Crosher wrote: > > The attached patches, and the files Lisp-Dep/fix-scl.lisp and > Lisp-Dep/mp-scl.lisp, > add support for the Scieneer CL implementation. > Douglas, I've committed the patches you sent us. Please verify that the current McCLIM tree works in SCL. Thanks for the patches, Tim From dtc at scieneer.com Thu Mar 16 01:44:13 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Thu, 16 Mar 2006 12:44:13 +1100 Subject: [mcclim-devel] Patch: clim-example system definition Message-ID: <4418C2ED.2080906@scieneer.com> There are a few examples not included in the mcclim.asd system definition but that still run and if still relevent then perhaps these could also be include. * mcclim.asd (defsystem :clim-system): include a few more of the examples. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-mcclim-asd URL: From dtc at scieneer.com Thu Mar 16 01:44:20 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Thu, 16 Mar 2006 12:44:20 +1100 Subject: [mcclim-devel] Patch: xrender request type arguments corrections. Message-ID: <4418C2F4.1000605@scieneer.com> * xrender.lisp (render-composite, render-composite-glyphs-8, %render-composite-glyphs): correct some of the request type arguments: CARD16 to INT16. Fixes types errors when using freetype. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-xrender URL: From dtc at scieneer.com Thu Mar 16 01:56:37 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Thu, 16 Mar 2006 12:56:37 +1100 Subject: [mcclim-devel] Patch: method browser, use clim-mop for portability. Message-ID: <4418C5D5.5010409@scieneer.com> * method-browser (eql-specializer-p, eql-specializer-object): remove these local definitions and use clim-mop:eql-specializer and clim-mop:eql-specializer-object for better portability. * method-browser (classp): special case for the Scieneer CL. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-method-browser URL: From dtc at scieneer.com Thu Mar 16 05:03:06 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Thu, 16 Mar 2006 16:03:06 +1100 Subject: [mcclim-devel] Patch: xrender, define render-op type. Message-ID: <4418F18A.4080000@scieneer.com> * xrender.lisp: Define the 'render-op type. Needed if type checking is enabled. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-xrender-type URL: From clemens at endorphin.org Thu Mar 16 07:14:04 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Thu, 16 Mar 2006 08:14:04 +0100 Subject: [mcclim-devel] scigraph build fixes Message-ID: <20060316072532.0F54F3C38C@irulan.endorphin.org> Build fixes for building scigraph. Tested with sbcl/cmucl. Consisting mostly of: * Replacing (ignore x) with (declare (ignore x)). * Hide custom declarations in defmethod from sbcl/cmu that both choke on these. * Change defconstant on cons into a defvar, for recompilation sake. * Unwrap defpackage from eval-when. * Change the memoize macro to use load-time-value to generate a hash-table. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scigraph-build-fixes.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: not available URL: From rpgoldman at real-time.com Thu Mar 16 15:54:34 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Thu, 16 Mar 2006 09:54:34 -0600 Subject: [mcclim-devel] committed Guided tour patches Message-ID: <17433.35386.539925.458613@necronomicon.sift.info> I have committed in the textual patches I announced earlier, since I had no complaints. I also fixed a number of the bib entries --- these were all in @misc format, so they didn't get displayed correctly. All these changes format fine for me. If I have caused any problems. please drop me a line immediately, and I'll fix them. Consider this a pre-apology if I have! Best, R From csr21 at cam.ac.uk Fri Mar 17 14:23:22 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 17 Mar 2006 14:23:22 +0000 Subject: [mcclim-devel] scigraph and out-of-the-boxness Message-ID: Hi, I attach a patch which lets scigraph build out of the box for me under sbcl. I don't think I'm likely to have broken any other configuration, but maybe someone would like to look at this? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dwim.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Fri Mar 17 14:47:44 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 17 Mar 2006 14:47:44 +0000 Subject: [mcclim-devel] Patch: xrender request type arguments corrections. References: <4418C2F4.1000605@scieneer.com> Message-ID: Douglas Crosher writes: > * xrender.lisp (render-composite, render-composite-glyphs-8, %render-composite-glyphs): correct > some of the request type arguments: CARD16 to INT16. Fixes types errors when using freetype. > > Regards > Douglas Crosher Hi, Douglas. I've forwarded these two patches of yours to the portable-clx mailing list (and applied them to my CLX darcs tree). I'd honestly much rather delete the xrender.lisp and associated files in mcclim -- I don't think anyone other than you is using it -- but if that would be difficult for you I could simply copy over the version from that CLX branch. (Even if I do that, I'm pretty sure that I will remove xrender.lisp from the mcclim repository before the next mcclim release.) Cheers, Christophe From idurand at labri.fr Fri Mar 17 21:35:31 2006 From: idurand at labri.fr (idurand at labri.fr) Date: Fri, 17 Mar 2006 22:35:31 +0100 Subject: [mcclim-devel] SPATIAL-TREES not found Message-ID: <1142631331.441b2ba314c4e@iona.labri.fr> Hi, Tonight, friday March 17th, I tried to recompile my cvs updated version of mcclim and it won't compile. I am using OpenMCL on MACOSX. For now, how can I go back to an older but working version? Ir?ne component :SPATIAL-TREES not found, required by # [Condition of type ASDF:MISSING-DEPENDENCY] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT-BREAK] # 2: [ABORT] # Backtrace: 0: (ASDF::DO-ONE-DEP # # 'ASDF:COMPILE-OP ':SPATIAL-TREES 'NIL) 1: (ASDF::DO-DEP # 'NIL # '(:SPATIAL-TREES :CLIM-LISP) #) 2: (# ':CLIM-CORE 'NIL) 3: (ASDF::DO-DEP # 'NIL # '(:CLIM-CORE) #) 4: (# ':CLIM-POSTSCRIPT '(:GOATEE-CORE :CLIM-CORE)) 5: (ASDF::DO-DEP # 'NIL # '(:CLIM-POSTSCRIPT :GOATEE-CORE :CLIM-CORE) #) 6: (# ':CLIM 'NIL) 7: (ASDF::DO-DEP # '((#1=# . #) (#1# . #) (#1# . #) (#1# . #) (#1# . #) (#1# . #) (#1# . #) (#1# . #) (#1# . #) (#1# . #) ...) # '(:CLX :CLIM) #) 8: (# ':CLIM-CLX '(:CLIM)) 9: (ASDF::DO-DEP # 'NIL # '(:CLIM-CLX :CLIM) #) 10: (# ':CLIM-LOOKS 'NIL) 11: (ASDF::DO-DEP # 'NIL # '(:CLIM-LOOKS) #) 12: (# "mcclim" 'NIL) 13: (ASDF::DO-DEP # 'NIL # '("mcclim") #) 14: (# # #, output # #x64363C6>) 15: (ASDF:OPERATE 'ASDF:LOAD-OP ':MCCLIM) 16: (CCL::CALL-CHECK-REGS 'ASDF:OPERATE) 17: (# "(asdf:operate 'asdf:load-op :mcclim)") 18: (SWANK::CALL-WITH-BUFFER-SYNTAX #) 19: (CCL::CALL-CHECK-REGS 'SWANK:INTERACTIVE-EVAL) 20: (# '(SWANK:INTERACTIVE-EVAL "(asdf:operate 'asdf:load-op :mcclim)") 2 'NIL) 21: (# # #) 22: (FUNCALL 'SWANK::EVAL-FOR-EMACS) 23: (#) 24: (# #) 25: (SWANK::CALL-WITH-REDIRECTED-IO # 'NIL) 26: (SWANK::CALL-WITH-CONNECTION # #) 27: (SWANK::HANDLE-REQUEST #) 28: (SWANK::CALL-WITH-BINDINGS 'NIL #) 29: (CCL::RUN-PROCESS-INITIAL-FORM '(#) #) 30: (# '(#) 0) 31: (# 265728 #) ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From moore at bricoworks.com Fri Mar 17 23:24:13 2006 From: moore at bricoworks.com (Timothy Moore) Date: Sat, 18 Mar 2006 00:24:13 +0100 Subject: [mcclim-devel] SPATIAL-TREES not found In-Reply-To: <1142631331.441b2ba314c4e@iona.labri.fr> References: <1142631331.441b2ba314c4e@iona.labri.fr> Message-ID: <441B451D.90308@bricoworks.com> idurand at labri.fr wrote: > Hi, > Tonight, friday March 17th, I tried to recompile my cvs updated > version of mcclim and it won't compile. > I am using OpenMCL on MACOSX. > > For now, how can I go back to an older but working version? Don't do that :) Download spatial-trees from http://ww.telent.net/cclan/spatial-trees.tar.gz Either load its .asd file manually or create a link to it from a central directory of systems Build McCLIM. Tim > > Ir?ne > > > > component :SPATIAL-TREES not found, required by # > [Condition of type ASDF:MISSING-DEPENDENCY] > > Restarts: > 0: [ABORT-REQUEST] Abort handling SLIME request. > 1: [ABORT-BREAK] # > 2: [ABORT] # > > Backtrace: > 0: (ASDF::DO-ONE-DEP # # #x64418F6> 'ASDF:COMPILE-OP ':SPATIAL-TREES 'NIL) > 1: (ASDF::DO-DEP # 'NIL # #x64418F6> '(:SPATIAL-TREES :CLIM-LISP) #) > 2: (# > ':CLIM-CORE 'NIL) > 3: (ASDF::DO-DEP # 'NIL # #x645B8CE> '(:CLIM-CORE) #) > 4: (# > ':CLIM-POSTSCRIPT '(:GOATEE-CORE :CLIM-CORE)) > 5: (ASDF::DO-DEP # 'NIL # > '(:CLIM-POSTSCRIPT :GOATEE-CORE :CLIM-CORE) #) > 6: (# ':CLIM > 'NIL) > 7: (ASDF::DO-DEP # '((#1=# . > #) (#1# . # #x648B5DE>) (#1# . #) (#1# . # "dep-openmcl" #x648AE26>) (#1# . #) (#1# . > #) (#1# . # #x648A1DE>) (#1# . #) (#1# . > #) (#1# . # #x64894BE>) ...) # '(:CLX :CLIM) # "clim-clx" #x645B12E>) > 8: (# > ':CLIM-CLX '(:CLIM)) > 9: (ASDF::DO-DEP # 'NIL # #x646209E> '(:CLIM-CLX :CLIM) #) > 10: (# > ':CLIM-LOOKS 'NIL) > 11: (ASDF::DO-DEP # 'NIL # > '(:CLIM-LOOKS) #) > 12: (# "mcclim" > 'NIL) > 13: (ASDF::DO-DEP # 'NIL # > '("mcclim") #) > 14: (# > # # #, output # #x6438BC6> #x64363C6>) > 15: (ASDF:OPERATE 'ASDF:LOAD-OP ':MCCLIM) > 16: (CCL::CALL-CHECK-REGS 'ASDF:OPERATE) > 17: (# "(asdf:operate 'asdf:load-op :mcclim)") > 18: (SWANK::CALL-WITH-BUFFER-SYNTAX #) > 19: (CCL::CALL-CHECK-REGS 'SWANK:INTERACTIVE-EVAL) > 20: (# '(SWANK:INTERACTIVE-EVAL "(asdf:operate > 'asdf:load-op :mcclim)") 2 'NIL) > 21: (# > # > #) > 22: (FUNCALL 'SWANK::EVAL-FOR-EMACS) > 23: (#) > 24: (# #) > 25: (SWANK::CALL-WITH-REDIRECTED-IO # 'NIL) > 26: (SWANK::CALL-WITH-CONNECTION # # #x63ECE86>) > 27: (SWANK::HANDLE-REQUEST #) > 28: (SWANK::CALL-WITH-BINDINGS 'NIL #) > 29: (CCL::RUN-PROCESS-INITIAL-FORM '(#) > #) > 30: (# '(#) > 0) > 31: (# 265728 # #x103800] #x64393E6>) > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > _______________________________________________ > 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 Sun Mar 19 10:48:00 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Sun, 19 Mar 2006 11:48:00 +0100 Subject: [mcclim-devel] Truly freezing now (was: Freeze period start for McCLIM 0.9.2) In-Reply-To: <87d5gpotpz.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Tue, 14 Mar 2006 17:51:20 +0100") References: <87ek17gwfs.wl%asf@boinkor.net> <87d5grgs6g.wl%asf@boinkor.net> <8764migc7z.wl%asf@boinkor.net> <87d5gpotpz.fsf@plato.moon.paoloamoroso.it> Message-ID: <871wwyn21r.fsf@plato.moon.paoloamoroso.it> Paolo Amoroso writes: > Well, you asked for it. I have tried building a freshly checked out > copy of McCLIM's CVS repository with CMUCL Snapshot 2005-11 (19C) > under Slackware Linux 10.0. Compilation aborts with this error: > > [...] > ; /home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f written. > ; Compilation finished in 0:00:00. > ; Loading #P"/home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f". > ; Loading #P"/home/paolo/src/dev/mcclim/Backends/PostScript/sheet.x86f". > > Execution of a form compiled with errors: > (DEFMETHOD SHEET-DIRECT-MIRROR ((SHEET POSTSCRIPT-STREAM)) > (POSTSCRIPT-STREAM-FILE-STREAM SHEET)) > [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] I tried to build on the same Linux box the latest McCLIM CVS sources with CMUCL Snapshot 2006-02 (19C), which is the latest available. Snapshot 2006-03 binaries are unavailable for Linux, due to a bug that was still present when the sources on which the snapshots are built were tagged. McCLIM compilation aborts with the same error. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From asf at boinkor.net Sun Mar 19 14:13:26 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Sun, 19 Mar 2006 15:13:26 +0100 Subject: [mcclim-devel] Truly freezing now (was: Freeze period start for McCLIM 0.9.2) In-Reply-To: <871wwyn21r.fsf@plato.moon.paoloamoroso.it> References: <87ek17gwfs.wl%asf@boinkor.net> <87d5grgs6g.wl%asf@boinkor.net> <8764migc7z.wl%asf@boinkor.net> <87d5gpotpz.fsf@plato.moon.paoloamoroso.it> <871wwyn21r.fsf@plato.moon.paoloamoroso.it> Message-ID: <87wteqfrp5.wl%asf@boinkor.net> Today, Paolo Amoroso wrote: > Paolo Amoroso writes: >> Execution of a form compiled with errors: >> (DEFMETHOD SHEET-DIRECT-MIRROR ((SHEET POSTSCRIPT-STREAM)) >> (POSTSCRIPT-STREAM-FILE-STREAM SHEET)) >> [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] > > I tried to build on the same Linux box the latest McCLIM CVS sources > with CMUCL Snapshot 2006-02 (19C), which is the latest available. > Snapshot 2006-03 binaries are unavailable for Linux, due to a bug > that was still present when the sources on which the snapshots are > built were tagged. McCLIM compilation aborts with the same error. Right, I see it, too. Seems like cmucl 19c has problems with methods specializing on direct subclasses of forward-referenced classes. Here's a patch working around that problem with asdf dependencies. McCLIM builds & runs fine for me on sbcl and cmucl with this patch; I have no postscript code (besided Examples/postscript-test.lisp, which works fine) to test it, though. Here's the patch: -------------- next part -------------- A non-text attachment was scrubbed... Name: ,cmucl-19c-build-failure.patch Type: application/octet-stream Size: 967 bytes Desc: not available URL: -------------- next part -------------- Thanks for the report and the reminder, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From amoroso at mclink.it Sun Mar 19 15:55:06 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Sun, 19 Mar 2006 16:55:06 +0100 Subject: [mcclim-devel] Truly freezing now (was: Freeze period start for McCLIM 0.9.2) References: <87ek17gwfs.wl%asf@boinkor.net> <87d5grgs6g.wl%asf@boinkor.net> <8764migc7z.wl%asf@boinkor.net> <87d5gpotpz.fsf@plato.moon.paoloamoroso.it> <871wwyn21r.fsf@plato.moon.paoloamoroso.it> <87wteqfrp5.wl%asf@boinkor.net> Message-ID: <87pskio2ed.fsf@plato.moon.paoloamoroso.it> Andreas Fuchs writes: > classes. Here's a patch working around that problem with asdf > dependencies. McCLIM builds & runs fine for me on sbcl and cmucl with > this patch; I have no postscript code (besided With your patch McCLIM builds fine. When I start the CLIM Listener, however, it aborts with this error: * (clim-listener:run-listener) Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: the function LISP::DYNAMIC-SPACE-USAGE is undefined. [Condition of type UNDEFINED-FUNCTION] Restarts: 0: [ABORT ] Return to application command loop 1: [RETURN-TO-LISTENER] Return to listener. 2: Return to Top-Level. Debug (type H for help) (KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER "" #.(SYSTEM:INT-SAP #x3FFFC88C) # (14)) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/interr.lisp. 0] It indeed looks like recent versions of CMUCL no longer have this function: * (apropos "DYNAMIC-SPACE-USAGE") * or at least with the same name. Maybe the function was renamed to LISP::DYNAMIC-SPACE-SIZE. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From rpgoldman at real-time.com Sun Mar 19 16:04:42 2006 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Sun, 19 Mar 2006 10:04:42 -0600 Subject: [mcclim-devel] patches to guided-tour subsection "A Simple drawing application" Message-ID: <17437.33050.69282.959990@necronomicon.sift.info> Again, mostly just tweaking grammar and spelling. There are two points below (marked with my initials), however, that seem like they could use some further clarification. I was concerned that I didn't understand McCLIM well enough to provide the clarification. If anyone out there can provide the clarification, but doesn't want to dicker with the text, drop me a line, or find me on #lisp, and I'll write the text. As usual, if I don't hear a squawk in a couple of days, I'll commit the change. best, R P.S. are these patch files really helpful for the text? In particular, is it useful to have my notes on places where we need clarification from their contexts untimely ripp'd? If I provide a comment saying that a paragraph could use amplification, and you see that in a patch file w/o context, is that at all useful to anyone? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: simple-drawing-application URL: From asf at boinkor.net Mon Mar 20 09:44:43 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Mon, 20 Mar 2006 10:44:43 +0100 Subject: [mcclim-devel] Truly freezing now (was: Freeze period start for McCLIM 0.9.2) In-Reply-To: <87pskio2ed.fsf@plato.moon.paoloamoroso.it> References: <87ek17gwfs.wl%asf@boinkor.net> <87d5grgs6g.wl%asf@boinkor.net> <8764migc7z.wl%asf@boinkor.net> <87d5gpotpz.fsf@plato.moon.paoloamoroso.it> <871wwyn21r.fsf@plato.moon.paoloamoroso.it> <87wteqfrp5.wl%asf@boinkor.net> <87pskio2ed.fsf@plato.moon.paoloamoroso.it> Message-ID: <87slpdfo1g.wl%asf@boinkor.net> On 2006-03-19, Paolo Amoroso wrote: > Andreas Fuchs writes: > >> classes. Here's a patch working around that problem with asdf >> dependencies. McCLIM builds & runs fine for me on sbcl and cmucl >> with this patch; I have no postscript code (besided > > With your patch McCLIM builds fine. When I start the CLIM Listener, > however, it aborts with this error: > > * (clim-listener:run-listener) > > Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: the function > LISP::DYNAMIC-SPACE-USAGE is undefined. [Condition of type > UNDEFINED-FUNCTION] Hm, running the listener works for me on a debian-installed 19c on x86. My mcclim cvs checkout has #+cmu(lisp::dynamic-usage), though, and no reference at all to dynamic-space-usage. Is that a modified tree? Are you testing on another platform? > or at least with the same name. Maybe the function was renamed to > LISP::DYNAMIC-SPACE-SIZE. No, that's the overall dynamic space size, not the used space. All that symbol guessing would be much easier if we had to guess exported symbols (-: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From dtc at scieneer.com Mon Mar 20 11:15:31 2006 From: dtc at scieneer.com (Douglas Crosher) Date: Mon, 20 Mar 2006 22:15:31 +1100 Subject: [mcclim-devel] Truly freezing now In-Reply-To: <87slpdfo1g.wl%asf@boinkor.net> References: <87ek17gwfs.wl%asf@boinkor.net> <87d5grgs6g.wl%asf@boinkor.net> <8764migc7z.wl%asf@boinkor.net> <87d5gpotpz.fsf@plato.moon.paoloamoroso.it> <871wwyn21r.fsf@plato.moon.paoloamoroso.it> <87wteqfrp5.wl%asf@boinkor.net> <87pskio2ed.fsf@plato.moon.paoloamoroso.it> <87slpdfo1g.wl%asf@boinkor.net> Message-ID: <441E8ED3.9080902@scieneer.com> Hello, >>Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: the function >>LISP::DYNAMIC-SPACE-USAGE is undefined. [Condition of type >>UNDEFINED-FUNCTION] > > > Hm, running the listener works for me on a debian-installed 19c on > x86. My mcclim cvs checkout has #+cmu(lisp::dynamic-usage), though, > and no reference at all to dynamic-space-usage. Is that a modified > tree? Are you testing on another platform? This change was erroneosly submitted by me in patches for SCL, sorry. The fix: * Revert function 'dynamic-space-usage to 'dynamic-usage. Regards Douglas Crosher -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-revert-dynamic-usage URL: From amoroso at mclink.it Mon Mar 20 16:22:21 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 20 Mar 2006 17:22:21 +0100 Subject: [mcclim-devel] Truly freezing now (was: Freeze period start for McCLIM 0.9.2) References: <87ek17gwfs.wl%asf@boinkor.net> <87d5grgs6g.wl%asf@boinkor.net> <8764migc7z.wl%asf@boinkor.net> <87d5gpotpz.fsf@plato.moon.paoloamoroso.it> <871wwyn21r.fsf@plato.moon.paoloamoroso.it> <87wteqfrp5.wl%asf@boinkor.net> <87pskio2ed.fsf@plato.moon.paoloamoroso.it> <87slpdfo1g.wl%asf@boinkor.net> Message-ID: <87pskh6q82.fsf@plato.moon.paoloamoroso.it> Andreas Fuchs writes: > Hm, running the listener works for me on a debian-installed 19c on > x86. My mcclim cvs checkout has #+cmu(lisp::dynamic-usage), though, > and no reference at all to dynamic-space-usage. Is that a modified > tree? Are you testing on another platform? The patch by Douglass fixes the problem, the correct function is indeed lisp::dynamic-usage. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From asf at boinkor.net Wed Mar 22 09:19:33 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Wed, 22 Mar 2006 10:19:33 +0100 Subject: [mcclim-devel] Truly freezing now In-Reply-To: <441E8ED3.9080902@scieneer.com> References: <87ek17gwfs.wl%asf@boinkor.net> <87d5grgs6g.wl%asf@boinkor.net> <8764migc7z.wl%asf@boinkor.net> <87d5gpotpz.fsf@plato.moon.paoloamoroso.it> <871wwyn21r.fsf@plato.moon.paoloamoroso.it> <87wteqfrp5.wl%asf@boinkor.net> <87pskio2ed.fsf@plato.moon.paoloamoroso.it> <87slpdfo1g.wl%asf@boinkor.net> <441E8ED3.9080902@scieneer.com> Message-ID: <87mzfibzve.wl%asf@boinkor.net> On 2006-03-20, Douglas Crosher wrote: >> Hm, running the listener works for me on a debian-installed 19c on >> x86. My mcclim cvs checkout has #+cmu(lisp::dynamic-usage), though, >> and no reference at all to dynamic-space-usage. Is that a modified >> tree? Are you testing on another platform? > > This change was erroneosly submitted by me in patches for SCL, > sorry. The fix: > > * Revert function 'dynamic-space-usage to 'dynamic-usage. Thanks a lot for the fix, I applied it. -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From csr21 at cam.ac.uk Thu Mar 23 10:14:10 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 23 Mar 2006 10:14:10 +0000 Subject: [mcclim-devel] fix for remove-command-from-command-table In-Reply-To: <20060315204352.GA21673@vja> (Vincent Arkesteijn's message of "Wed, 15 Mar 2006 21:43:52 +0100") References: <20060315204352.GA21673@vja> Message-ID: Vincent Arkesteijn writes: > At present, remove-command-from-command-table doesn't, except for > menu-items. The attached patch fixes that. Could I have a test case for Tests/commands.lisp? Cheers, Christophe From csr21 at cam.ac.uk Thu Mar 23 11:49:56 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 23 Mar 2006 11:49:56 +0000 Subject: [mcclim-devel] Patch: method browser, use clim-mop for portability. In-Reply-To: <4418C5D5.5010409@scieneer.com> (Douglas Crosher's message of "Thu, 16 Mar 2006 12:56:37 +1100") References: <4418C5D5.5010409@scieneer.com> Message-ID: Douglas Crosher writes: > * method-browser (eql-specializer-p, eql-specializer-object): remove these > local definitions and use clim-mop:eql-specializer and > clim-mop:eql-specializer-object for better portability. > > * method-browser (classp): special case for the Scieneer CL. This patch leaves a number of uses of eql-specializer-p and eql-specializer-object unmodified; it's unlikely that the method browser will work if I apply this patch. Cheers, Christophe From csr21 at cam.ac.uk Thu Mar 23 12:01:40 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 23 Mar 2006 12:01:40 +0000 Subject: [mcclim-devel] Patch for CLX backend `medium-draw-ellipse*'-bug In-Reply-To: <87acbt1izy.fsf@sigkill.dk> (Troels Henriksen's message of "Tue, 14 Mar 2006 10:19:13 +0100") References: <87hd63uz29.fsf@sigkill.dk> <87acbt1izy.fsf@sigkill.dk> Message-ID: Troels Henriksen writes: > Troels Henriksen writes: > >> The attached patch fixes this issue > > I should learn to test things better. The attached patch fixes this > properly (and I'm reasonably sure that the bug reporters intended > behavior is a bug in LispWorks). Thank you; I've merged this patch, which seemed self-evidently right. Cheers, Christophe From vincent at arkesteijn.net Thu Mar 23 13:08:20 2006 From: vincent at arkesteijn.net (Vincent Arkesteijn) Date: Thu, 23 Mar 2006 14:08:20 +0100 Subject: [mcclim-devel] fix for remove-command-from-command-table In-Reply-To: References: <20060315204352.GA21673@vja> Message-ID: <20060323130820.GA5864@vja> On Thu, Mar 23, 2006 at 10:14:10AM +0000, Christophe Rhodes wrote: > Could I have a test case for Tests/commands.lisp? The attached test fails with current mcclim, and passes with the fix that I sent. Vincent. -------------- next part -------------- ? remove-command-from-command-table-test.diff Index: commands.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Tests/commands.lisp,v retrieving revision 1.2 diff -u -F^(def -r1.2 commands.lisp --- commands.lisp 30 Sep 2005 16:02:33 -0000 1.2 +++ commands.lisp 23 Mar 2006 13:04:04 -0000 @@ -41,3 +41,12 @@ (define-command-table menu-test-table) (lookup-keystroke-command-item gesture 'menu-test-table))))) 'menu-test-table) (assert (= count 1))) + +(define-command-table removal-test-table) +(add-command-to-command-table 'com-test-command 'removal-test-table) +(remove-command-from-command-table 'com-test-command 'removal-test-table) +(assert (handler-case + (remove-command-from-command-table 'com-test-command + 'removal-test-table) + (command-not-present () t) + (:no-error (x) (declare (ignore x)) nil))) From athas at sigkill.dk Thu Mar 23 13:21:47 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Thu, 23 Mar 2006 14:21:47 +0100 Subject: [mcclim-devel] Patch: CLIM-SYS:MAKE-PROCESS fix for SBCL Message-ID: <87k6algutw.fsf@sigkill.dk> CLIM-SYS:MAKE-PROCESS doesn't pass on the specified process name to SB-THREAD:MAKE-THREAD under SBCL, resulting in unnamed threads. The attached simple patch fixes this. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mp-sbcl.lisp.diff URL: -------------- next part -------------- -- \ Troels "Athas" Henriksen /\ - Insert witty signature From vincent at arkesteijn.net Thu Mar 23 13:25:22 2006 From: vincent at arkesteijn.net (Vincent Arkesteijn) Date: Thu, 23 Mar 2006 14:25:22 +0100 Subject: [mcclim-devel] fix for remove-command-from-command-table In-Reply-To: References: <20060315204352.GA21673@vja> Message-ID: <20060323132522.GB5864@vja> On Thu, Mar 23, 2006 at 10:14:10AM +0000, Christophe Rhodes wrote: > Could I have a test case for Tests/commands.lisp? I've had a brief look at the two tests already present in Tests/commands.lisp, and I think there's something wrong. According to 27.1, "Every command is named by command name, which is a symbol.". However, the two tests in that file give a list as the command-name argument to add-command-to-command-table. After changing that (see attachment) I get an error: Condition COMMAND-NOT-PRESENT was signalled. [Condition of type COMMAND-NOT-PRESENT] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: (CLIM-INTERNALS::PARTIAL-COMMAND-FROM-NAME COM-TEST-COMMAND) 1: (LOOKUP-KEYSTROKE-COMMAND-ITEM (:KEYBOARD #\t 0) NO-MENU-TEST-TABLE :TEST NIL :NUMERIC-ARG 1) 2: ((LAMBDA (MENU-NAME GESTURE ITEM)) NIL (:KEYBOARD #\t 0) #) 3: (MAP-OVER-COMMAND-TABLE-KEYSTROKES # NO-MENU-TEST-TABLE) ... Vincent. -------------- next part -------------- ? remove-command-from-command-table-test.diff ? remove-command-from-command-table-test.diff2 Index: commands.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Tests/commands.lisp,v retrieving revision 1.2 diff -u -F^(def -r1.2 commands.lisp --- commands.lisp 30 Sep 2005 16:02:33 -0000 1.2 +++ commands.lisp 23 Mar 2006 13:09:04 -0000 @@ -8,7 +8,7 @@ (defpackage :clim-tests ;;; command tables (define-command-table no-menu-test-table) -(add-command-to-command-table '(com-test-command) 'no-menu-test-table +(add-command-to-command-table 'com-test-command 'no-menu-test-table :keystroke '(#\t)) (let ((count 0)) @@ -26,7 +26,7 @@ (define-command-table no-menu-test-table (define-command-table menu-test-table) -(add-command-to-command-table '(com-test-command) 'menu-test-table +(add-command-to-command-table 'com-test-command 'menu-test-table :keystroke '(#\u) :menu "Test") From mcclim-devel at common-lisp.net Sun Mar 26 20:44:23 2006 From: mcclim-devel at common-lisp.net (McCLIM developers) Date: Sun, 26 Mar 2006 22:44:23 +0200 Subject: [mcclim-devel] Announcing McCLIM 0.9.2 "Laetare Sunday" Message-ID: <87r74p3pi0.wl%asf@boinkor.net> The McCLIM developers are happy to release version 0.9.2 of McCLIM. It was tested on SBCL (both threaded and unthreaded), OpenMCL, CMUCL, Scieneer CL, and Allegro Common Lisp (ANSI mode only). Get the tarball at or install McCLIM via asdf-install. We are looking forward to your comments and bug reports. Please send them to mcclim-devel at common-lisp.net. The list of currently known bugs can be found at . Have fun using McCLIM (and build good things with it), The McCLIM developers. RELEASE NOTES FOR McCLIM 0.9.2, "Laetare Sunday": Compatibility ============= This release works on CMUCL, SBCL, CLISP, OpenMCL, Allegro CL, LispWorks, and the Scieneer CL, using the CLX X Window bindings. Changes to the Install Process ============================== Implementation-specific INSTALL.* files were removed. Generic and implementation-specific Installation instructions were improved and merged into the file INSTALL. This release requires the "spatial-trees" library by Christophe Rhodes. Get it via asdf-install or at http://cliki.net/spatial-trees. Changes to Backends =================== Copy & Paste code in the CLX backend was improved and should now adhere more strictly to ICCCM. Support for connecting to a ssh-forwarded display was restored. Several unused parts (marked with #+unicode) of the CLX backend were removed, thus restoring buildability on installations of clisp that have the unicode feature turned on. Double buffering for panes was implemented. To use it, create panes with the :double-buffering t initarg. There is now rudimentary support for entering non-Ascii characters from X11 ports using SBCL CLX (a.k.a. telent CLX). McCLIM ships experimental support for TrueType font rendering using the FreeType libraries and the free Bitstream Vera fonts. To use it, link Experimental/freetype/mcclim-freetype.asd to one of your asdf:*central-registry* directories and load the "MCCLIM-FREETYPE" system. An experimental "Null" backend was added that should allow testing of CLIM functionality without requiring a GUI environment to run. Changes to the Documentation ============================ A new chapter on contributed applications was added. Several new figures and examples were added to the manual Clemens Fruhwirth added a CLIM tutorial paper called "A Guided Tour to CLIM". It is available in Doc/Guided-Tour/. Changes to Contributed Applications and Examples ================================================ New application: A CLIM Debugger (by Peter Mechlenborg). It resides in Apps/Debugger/. New application: Functional-Geometry by Frank Buss and Rainer Joswig. It resides in Apps/Functional-Geometry/. The Inspector now is now able to disassemble functions and inspect pathnames. The Listener can now produce vertically-aligned graphs. The Scigraph application now builds on SBCL again. A demo for drag-and-drop-translators was added. Further additions to McCLIM =========================== There is now a test suite, located in Tests/. It contains tests for regions, bounding rectangles, transformations, commands, and the PostScript backend. With the addition of the Null backend, we hope to add several more tests for more chapters of the CLIM spec. New Extension "conditional-commands": allows activation/deactivation of commands when other commands are invoked. It resides in Extensions/conditional-commands/. Status of the CLIM 2 Spec Implementation ======================================== Here is a list of what we think works, organized by chapters and sections of the CLIM 2 specification. Chapter 3 Regions Mostly finished. There are some troublesome parts of the specification that may not be implemented for all possible regions, for instance region-contains-region-p. There may not be an efficient way of implementing this function for all kinds of regions. Chapter 4, Bounding rectangles Finished Chapter 5, Affine transformations Finished Chapter 6, Overview of window facilities Finished Chapter 7, Properties of sheets Finished, though the correct behavior of sheet transformations may not have been tested. Chapter 8, Sheet protocols Finished Chapter 9, Ports, Grafts, and Mirrored sheets Finished Chapter 10, Sheet and medium output facilities Finished Chapter 11, Text styles Mostly complete. There is now experimental support for device font text styles (via make-device-font-text-style) for the CLX, PostScript, and CLX+FreeType backends. Chapter 12, Graphics Finished Chapter 13, Drawing in Color I am note sure about the state of this. I thought we were doing only full opacity and full transparency, but I see traces of more general designs. Chapter 14, General Designs The composition of designs is not supported. We do support regions as designs. Chapter 15, Extended Stream Output Extended output streams are fully supported. Chapter 16, Output Recording Output recording is mostly implemented. This release ships with a standard-tree-output-record type for the first time. The tree output record type speeds up point- and region-based queries, but slows down insertion of output records by a bit. make-design-from-output-record is not implemented. *Note*: the coordinates in output records are relative to the stream. This is in conformance with the Spec, but not necessarily compatible with other CLIM implementations. Chapter 17, Table Formatting Table formatting is completely implemented. Chapter 18, Graph Formatting Graph formatting is fully implemented. The :hash-table argument to format-graph-from-roots is ignored. Support for a :dag graph type was added, as was support for vertically oriented graphs and support for the :arc-drawer argument to format-graph-from-roots. Chapter 19, Bordered Output Bordered output is fully supported. Chapter 20, Text Formatting With the exception of the :after-line-break-initially argument to filling-output, this chapter is fully implemented. Chapter 21 Incremental Redisplay The updating-output interface to incremental redisplay is implemented. McCLIM makes no effort to move i.e., bitblit, output records; they are always erased and redrawn if their position changes. This is much more compatible with support for partial transparency. The :x, :y, :parent-x and :parent-y arguments to redisplay-output-record are ignored. McCLIM follows the spirit of 21.3 "Incremental Redisplay Protocol", but we have not tried very hard to implement the vague description in the Spec. augment-draw-set, note-output-record-child-changed and propagate-output-record-changes-p are not implemented. Incremental redisplay in McCLIM may still suffer from performance problems, despite the presence of spatially-organized compound output record types. Chapter 22, Extended Stream Input The implementation of extended input streams is quite complete. (setf* pointer-position) is not implemented. There is no stream numeric argument, so that slot of the accelerator-gesture condition is always 1. Chapter 23 Presentation Types Most of the literal specification of this chapter is implemented. Specific accept and present presentation methods for some types are not implemented, so the default method may be surprising. The output record bounding rectangle is always used or highlighting and pointer testing. presentation-default-processor is not implemented. The presentation method mechanism supports all method combinations. The body of a presentation method is surrounded with a block of the same name as the presentation method, not just the magic internal name. The method by which presentation type parameters and options are decoded for the method bodies is a bit different from real CLIM. In particular, you cannot refer to the type parameters and options in the lambda list of the method. The NIL value of presentation-single-box is now supported. Presentation type histories are now partially implemented. The gesture C-M-y should recall the last entered presentation. define-drag-and-drop-translator is now implemented. Chapter 24 Input Editing and Completion Facilities with-input-editor-typeout is not implemented. The noise strings produced by input-editor-format and the strings produced by presentation-replace-input are not read-only. This could lead to interesting "issues" if the user edits them. Only a few of the suggested editing commands are implemented. An additional command that is implemented is control-meta-B, which drops into the debugger. add-input-editor-command is not implemented. with-accept-help is not implemented. Chapter 25 Menu Facilities The protocol is implemented, but McCLIM doesn't use it to draw command table menus. Chapter 26 Dialog Facilities McCLIM contains a basic, somewhat buggy implementation of accepting-values. There is little user feedback as to what has been accepted in a dialog. The user has to press the "OK" button to exit the dialog; there are no short cuts. There are no special accept-present-default methods for member or subset presentation types. Command-buttons are not implemented. There is no gadget-based implementation of accepting-values. The internal structure of accepting-values should be "culturally compatible" with real CLIM; if you have some spiffy hack, check the source. :own-window is now supported in accepting-values. Chapter 27 Command Processing command-line-complete-input is not implemented (the functionality does exist in the accept method for command-name). display-command-table-menu and menu-choose-command-from-table are not implemented. Menu-command-parser is not implemented, though the functionality obviously is. Nothing is done about partial menu commands. There is no support for numeric arguments. The command-or-form presentation type is not implemented. Chapter 28 Application Frames raise-frame, bury-frame and notify-user are not implemented. :accept-values panes are not implemented. frame-maintain-presentation-histories is not implemented. frame-drag-and-drop-feedback and frame-drag-and-drop-highlighting are now implemented. execute-frame-command ignores the possibility that frame and the current frame might be different. display-command-menu isn't implemented. Chapter 29 Panes Due to the way the space-allocation protocol is implemented, it is not easy to create application-specific layout-panes. Client code needs to know about :AROUND methods to compose-space, but they are not mentioned in the spec. restraining-pane is partially implemented. Chapter 30 Gadgets This chapter is implemented. with-output-as-gadget is not quite working yet, but it was improved since the last release. From pdm at zamazal.org Mon Mar 27 10:40:33 2006 From: pdm at zamazal.org (Milan Zamazal) Date: Mon, 27 Mar 2006 12:40:33 +0200 Subject: [mcclim-devel] Please remove debian/ from CVS Message-ID: <87psk8jhlq.fsf@blackbird.zamazal.org> Would you please remove the debian/ directory (or at least its contents) from CVS? The files there are obsolete, the package is maintained in Debian properly. Thank you. Regards, Milan Zamazal -- http://www.zamazal.org From pdm at zamazal.org Mon Mar 27 10:48:04 2006 From: pdm at zamazal.org (Milan Zamazal) Date: Mon, 27 Mar 2006 12:48:04 +0200 Subject: [mcclim-devel] Copyright/copying statements Message-ID: <87irq0jh97.fsf@blackbird.zamazal.org> When you add new files to the McCLIM repository that are intended to be distributed under the LGPL or another free license or to be put in public domain, please don't forget to equip them with proper copyright and copying conditions headers. Apparently not everything included in the McCLIM distribution is actually covered by LGPL, so this information is needed to clearly identify the status of each of the distributed files. Thank you. Regards, Milan Zamazal -- http://www.zamazal.org From csr21 at cam.ac.uk Mon Mar 27 10:49:17 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 27 Mar 2006 11:49:17 +0100 Subject: [mcclim-devel] patch for gadget.lisp In-Reply-To: <001001c64629$5d950ad0$6401a8c0@moby> (Paul Werkowski's message of "Sun, 12 Mar 2006 18:04:49 -0500") References: <001001c64629$5d950ad0$6401a8c0@moby> Message-ID: "Paul Werkowski" writes: > This was sent late last year, but it seems the patch got stripped by some > helpful > agent. I hope this one gets through. Please let me know otherwise. I've merged this into CVS. It's post-release, but hopefully we won't wait a year for the next release... Cheers, Christophe From pdm at zamazal.org Mon Mar 27 10:42:51 2006 From: pdm at zamazal.org (Milan Zamazal) Date: Mon, 27 Mar 2006 12:42:51 +0200 Subject: [mcclim-devel] Copying conditions of some McCLIM parts? Message-ID: <87odzsjhhw.fsf@blackbird.zamazal.org> I package McCLIM for Debian and there are some parts in the distribution tarball with unclear copyright and copying conditions. Unfortunately I don't have time to investigate all the affected files, so I mostly remove them from the Debian package, but there are some significant parts which I would like to get clarified: - The McCLIM manual by Robert Strandh in the Doc/ directory. - The contents of the Test/ directory. Could you please clarify whether these parts are covered by the general McCLIM LGPL COPYING statement? Additionally, I consider the following source files to be covered by the general COPYING statement, as they seem to be integral parts of McCLIM: - The files package.lisp and patch.lisp in the top-level directory. - Backends/CLX/package.lisp Backends/Null/package.lisp Backends/PostScript/standard-metrics.lisp - The contents of the Experimental/freetype/ directory. - Goatee/editable-area.lisp - The contents of the Lisp-Dep/ directory. And finally, not all files in Apps/Inspector/ and Apps/Listener/ contain the copying statement, but as the crucial ones there do, I assume they are all LGPLed. Would you please add the standard copying headers to all those files to avoid future confusion? Thank you. Regards, Milan Zamazal -- http://www.zamazal.org From asf at boinkor.net Mon Mar 27 12:03:27 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Mon, 27 Mar 2006 14:03:27 +0200 Subject: [mcclim-devel] Announcing McCLIM 0.9.2 "Laetare Sunday" In-Reply-To: <87r74p3pi0.wl%asf@boinkor.net> References: <87r74p3pi0.wl%asf@boinkor.net> Message-ID: <87mzfc3xio.wl%asf@boinkor.net> On 2006-03-26, McCLIM developers wrote: > Get the tarball at > > or install McCLIM via asdf-install. If you just want to try out the cool demos, here's a pre-built binary with pre-loaded freetype, mcclim demos, functional geometry, the listener, the debugger and the inspector: . It's based on a threaded SBCL 0.9.11 and requires Linux 2.6.x on an i386 machine. Instructions ------------ Download the file (14MB), unpack it, and run the mcclim-listener-0.9.2/mcclim binary. After a few seconds of initialization, a listener window should pop up, in which you can enter lisp expressions, like: (/ 1 0) ; will open the clim debugger or activate menu items like Demos -> Plot Fishes using Functional Geometry and, of course, explore. The listener, debugger and inspector applications have a lot of interesting functions. If you liked this demo, you might enjoy the clim desktop, located at http://www.cliki.net/clim-desktop. Have fun, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From amoroso at mclink.it Mon Mar 27 16:03:32 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 27 Mar 2006 18:03:32 +0200 Subject: [mcclim-devel] Announcing McCLIM 0.9.2 "Laetare Sunday" In-Reply-To: <87mzfc3xio.wl%asf@boinkor.net> (Andreas Fuchs's message of "Mon, 27 Mar 2006 14:03:27 +0200") References: <87r74p3pi0.wl%asf@boinkor.net> <87mzfc3xio.wl%asf@boinkor.net> Message-ID: <874q1j50yz.fsf@plato.moon.paoloamoroso.it> Andreas Fuchs writes: > If you just want to try out the cool demos, here's a pre-built binary > with pre-loaded freetype, mcclim demos, functional geometry, the > listener, the debugger and the inspector: > > . > > It's based on a threaded SBCL 0.9.11 and requires Linux 2.6.x on an > i386 machine. And the 2.6.x kernel must be compiled with support for the NPTL threading library. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From asf at boinkor.net Mon Mar 27 16:45:58 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Mon, 27 Mar 2006 18:45:58 +0200 Subject: [mcclim-devel] Announcing McCLIM 0.9.2 "Laetare Sunday" In-Reply-To: <874q1j50yz.fsf@plato.moon.paoloamoroso.it> References: <87r74p3pi0.wl%asf@boinkor.net> <87mzfc3xio.wl%asf@boinkor.net> <874q1j50yz.fsf@plato.moon.paoloamoroso.it> Message-ID: <87lkuv4z09.wl%asf@boinkor.net> Today, Paolo Amoroso wrote: > Andreas Fuchs writes: >> It's based on a threaded SBCL 0.9.11 and requires Linux 2.6.x on an >> i386 machine. > > And the 2.6.x kernel must be compiled with support for the NPTL > threading library. Right, and on debian it needs the package libfreetype6-dev installed, as well. That should cover the dependencies, I think (: -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From gmane at cmm.kakpryg.net Mon Mar 27 16:36:54 2006 From: gmane at cmm.kakpryg.net (Michael Livshin) Date: Mon, 27 Mar 2006 18:36:54 +0200 Subject: [mcclim-devel] Re: Announcing McCLIM 0.9.2 "Laetare Sunday" References: <87r74p3pi0.wl%asf@boinkor.net> <87mzfc3xio.wl%asf@boinkor.net> <874q1j50yz.fsf@plato.moon.paoloamoroso.it> Message-ID: <87lkuvhmjd.fsf@colinux.pc-mlivshin-ibm.cadence.com.cmm> Paolo Amoroso writes: > Andreas Fuchs writes: > >> If you just want to try out the cool demos, here's a pre-built binary >> with pre-loaded freetype, mcclim demos, functional geometry, the >> listener, the debugger and the inspector: >> >> . >> >> It's based on a threaded SBCL 0.9.11 and requires Linux 2.6.x on an >> i386 machine. > > And the 2.6.x kernel must be compiled with support for the NPTL > threading library. also, make sure your system has libfreetype.so (some Debian installations lack it, so you'll have to make a symlink libfreetype.so -> libfreetype.so.6). cheers, --m From nikodemus at random-state.net Tue Mar 28 06:40:42 2006 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Tue, 28 Mar 2006 09:40:42 +0300 Subject: [mcclim-devel] Re: Announcing McCLIM 0.9.2 "Laetare Sunday" References: <87r74p3pi0.wl%asf@boinkor.net> <87mzfc3xio.wl%asf@boinkor.net> <874q1j50yz.fsf@plato.moon.paoloamoroso.it> <87lkuvhmjd.fsf@colinux.pc-mlivshin-ibm.cadence.com.cmm> Message-ID: <878xqvjclx.fsf@logxor.random-state.net> Michael Livshin writes: > also, make sure your system has libfreetype.so (some Debian > installations lack it, so you'll have to make a symlink > libfreetype.so -> libfreetype.so.6). Lack of a symlink like that is usually an indication of a missing -dev package. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." From gmane at cmm.kakpryg.net Tue Mar 28 11:34:44 2006 From: gmane at cmm.kakpryg.net (Michael Livshin) Date: Tue, 28 Mar 2006 13:34:44 +0200 Subject: [mcclim-devel] Re: Announcing McCLIM 0.9.2 "Laetare Sunday" References: <87r74p3pi0.wl%asf@boinkor.net> <87mzfc3xio.wl%asf@boinkor.net> <874q1j50yz.fsf@plato.moon.paoloamoroso.it> <87lkuvhmjd.fsf@colinux.pc-mlivshin-ibm.cadence.com.cmm> <878xqvjclx.fsf@logxor.random-state.net> Message-ID: <87irpyiyzv.fsf@colinux.pc-mlivshin-ibm.cadence.com.cmm> Nikodemus Siivola writes: > Michael Livshin writes: > >> also, make sure your system has libfreetype.so (some Debian >> installations lack it, so you'll have to make a symlink >> libfreetype.so -> libfreetype.so.6). > > Lack of a symlink like that is usually an indication of a missing -dev > package. oh. right you are! still wondering what exactly the logic behind this is, --m From brian at mastenbrook.net Tue Mar 28 12:50:45 2006 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Tue, 28 Mar 2006 06:50:45 -0600 Subject: [mcclim-devel] Re: Announcing McCLIM 0.9.2 "Laetare Sunday" In-Reply-To: <87irpyiyzv.fsf@colinux.pc-mlivshin-ibm.cadence.com.cmm> References: <87r74p3pi0.wl%asf@boinkor.net> <87mzfc3xio.wl%asf@boinkor.net> <874q1j50yz.fsf@plato.moon.paoloamoroso.it> <87lkuvhmjd.fsf@colinux.pc-mlivshin-ibm.cadence.com.cmm> <878xqvjclx.fsf@logxor.random-state.net> <87irpyiyzv.fsf@colinux.pc-mlivshin-ibm.cadence.com.cmm> Message-ID: <6CF97A4D-D622-4042-AD18-AFEB4291D5C1@mastenbrook.net> On Mar 28, 2006, at 5:34 AM, Michael Livshin wrote: > Nikodemus Siivola writes: > >> Michael Livshin writes: >> >>> also, make sure your system has libfreetype.so (some Debian >>> installations lack it, so you'll have to make a symlink >>> libfreetype.so -> libfreetype.so.6). >> >> Lack of a symlink like that is usually an indication of a missing - >> dev >> package. > > oh. right you are! > > still wondering what exactly the logic behind this is, > --m The symlink is only necessary if you're going to be linking against the library as ld won't resolve -lfreetype to libfreetype.so.someversion (and if you're missing the -dev package, you don't have headers either). SBCL acts more like a linker than a user binary in this case - the SBCL runtime itself is not linked against this library, so it must find and load it at runtime. It would be an interesting project to munge up the runtime when doing save-lisp-and-die :executable t to link to any necessary alien libraries. One could also put the core in a segment of the binary instead of dumping a technically invalid ELF image, too. -- Brian Mastenbrook http://brian.mastenbrook.net/ brian at mastenbrook.net From csr21 at cam.ac.uk Tue Mar 28 13:44:30 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 28 Mar 2006 14:44:30 +0100 Subject: [mcclim-devel] Announcing McCLIM 0.9.2 "Laetare Sunday" In-Reply-To: <87mzfc3xio.wl%asf@boinkor.net> (Andreas Fuchs's message of "Mon, 27 Mar 2006 14:03:27 +0200") References: <87r74p3pi0.wl%asf@boinkor.net> <87mzfc3xio.wl%asf@boinkor.net> Message-ID: Andreas Fuchs writes: > On 2006-03-26, McCLIM developers wrote: >> Get the tarball at >> >> or install McCLIM via asdf-install. > > If you just want to try out the cool demos, here's a pre-built binary > with pre-loaded freetype, mcclim demos, functional geometry, the > listener, the debugger and the inspector: Here is a similar binary for OS X / ppc. It's based on unithreaded SBCL, so some things may not work. In addition to the things which don't work because of single-threadedness, I have observed something strange: on OS X machines here, I need to press RET /twice/ in the listener to activate an expression: after ( * SPC 2 SPC 3 ) RET nothing happens, but when I hit RET once more I get 6 back. Similarly, but equally weirdly, if I just type x RET I get a blank line followed by the CL-USER> prompt back, and only after the /next/ keystroke is the blank line filled with Input "x" does not match However, I have had a report that someone else /doesn't/ see these symptoms. If people do download that binary, could they please report back to say whether or not they have these problems with it? Thanks, Christophe From csr21 at cam.ac.uk Tue Mar 28 14:44:12 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 28 Mar 2006 15:44:12 +0100 Subject: [mcclim-devel] Announcing McCLIM 0.9.2 "Laetare Sunday" In-Reply-To: (Christophe Rhodes's message of "Tue, 28 Mar 2006 14:44:30 +0100") References: <87r74p3pi0.wl%asf@boinkor.net> <87mzfc3xio.wl%asf@boinkor.net> Message-ID: Christophe Rhodes writes: > Andreas Fuchs writes: > >> On 2006-03-26, McCLIM developers wrote: >>> Get the tarball at >>> >>> or install McCLIM via asdf-install. >> >> If you just want to try out the cool demos, here's a pre-built binary >> with pre-loaded freetype, mcclim demos, functional geometry, the >> listener, the debugger and the inspector: > > Here is a similar binary for OS X / ppc. It's based on unithreaded > SBCL, so some things may not work. > > > In addition to the things which don't work because of > single-threadedness, I have observed something strange: on OS X > machines here, I need to press RET /twice/ in the listener to activate > an expression: after > > ( * SPC 2 SPC 3 ) RET > > nothing happens, but when I hit RET once more I get 6 back. Inspecting the standard-input-editing-stream from the debugger I get by hitting C-c in my underlying lisp at this point -- that is, after the first RET and before the second -- I see The object is a STANDARD-OBJECT of type CLIM:STANDARD-INPUT-EDITING-STREAM. 0. OPEN-P: T 1. STREAM: # 2. AREA: # 3. SNAPSHOT: # 4. BUFFER: #(#\( #\* #\ #\2 #\ #\3 #\)) 5. INSERTION-POINTER: 7 6. SCAN-POINTER: 7 7. RESCAN-QUEUED: NIL 8. RESCANNING-P: NIL 9. ACTIVATION-GESTURE: NIL Cheers, Christophe From amoroso at mclink.it Tue Mar 28 15:59:29 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 28 Mar 2006 17:59:29 +0200 Subject: [mcclim-devel] Announcing McCLIM 0.9.2 "Laetare Sunday" In-Reply-To: (Christophe Rhodes's message of "Tue, 28 Mar 2006 14:44:30 +0100") References: <87r74p3pi0.wl%asf@boinkor.net> <87mzfc3xio.wl%asf@boinkor.net> Message-ID: <8764lylfvi.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > Here is a similar binary for OS X / ppc. It's based on unithreaded [...] > In addition to the things which don't work because of > single-threadedness, I have observed something strange: on OS X > machines here, I need to press RET /twice/ in the listener to activate > an expression: after This comment in Apps/Functional-Geometry/geometry.lisp might be relevant: ;;; XXX The use of EXPRESSION in the OR presentation type exposes a bug in the ;;; accept method for expression when rescanning; you have to hit ENTER three ;;; times when entering an expression (e.g., a variable name) as a picture ;;; value. This will be fixed after .9.2.2. -- moore Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Tue Mar 28 16:08:52 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 28 Mar 2006 17:08:52 +0100 Subject: [mcclim-devel] Announcing McCLIM 0.9.2 "Laetare Sunday" In-Reply-To: <8764lylfvi.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Tue, 28 Mar 2006 17:59:29 +0200") References: <87r74p3pi0.wl%asf@boinkor.net> <87mzfc3xio.wl%asf@boinkor.net> <8764lylfvi.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Christophe Rhodes writes: > >> Here is a similar binary for OS X / ppc. It's based on unithreaded > [...] >> In addition to the things which don't work because of >> single-threadedness, I have observed something strange: on OS X >> machines here, I need to press RET /twice/ in the listener to activate >> an expression: after > > This comment in Apps/Functional-Geometry/geometry.lisp might be > relevant: > > ;;; XXX The use of EXPRESSION in the OR presentation type exposes a bug in the > ;;; accept method for expression when rescanning; you have to hit ENTER three > ;;; times when entering an expression (e.g., a variable name) as a picture > ;;; value. This will be fixed after .9.2.2. -- moore I saw a similar comment in builtin-commands.lisp. However, there's something else going on, I suspect, because while the OS X binary running under Apple X11 exhibits this double-RET problem, the same binary displaying on Xorg on my workstation (tunnelled over ssh) does not have the same problem. (I think the XXX comment doesn't apply in any case, because the EXPRESSION presentation type we ACCEPT in the listener has :PRESERVE-WHITESPACE T in its options. Still, it's possible that something in there is causing a problem...) Cheers, Christophe From asf at boinkor.net Tue Mar 28 17:54:29 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Tue, 28 Mar 2006 19:54:29 +0200 Subject: [mcclim-devel] should we keep a NEWS file? Message-ID: <87bqvq4fqi.wl%asf@boinkor.net> Hi all, after the second time I went through the cvs mails to find the noteworthy changes in McCLIM, I think I'd like to take a stab at a more traditional way of reporting release notes. So, how about we keep a NEWS file that tracks the interesting changes (bug fixes, new features, etc.) to McCLIM? Of course, I'll still write a state-of-the-implementation in the release notes, but little changes would probably work better in a chronological list (and I think changes in completeness of the implementation would be easier to track with a news file, too). If nobody objects, I'll add one and populate it with the last commit. (: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From moore at bricoworks.com Wed Mar 29 05:04:39 2006 From: moore at bricoworks.com (Timothy Moore) Date: Wed, 29 Mar 2006 07:04:39 +0200 Subject: [mcclim-devel] argument-precedence-order Message-ID: <442A1567.3090400@bricoworks.com> Are any applications depending on the argument-precedence-order specified for the gadget callback functions? I realize that the default precedence order may be inconvenient, but these functions are defined in the Spec! Tim From d.lewis at gold.ac.uk Thu Mar 30 13:30:10 2006 From: d.lewis at gold.ac.uk (David Lewis) Date: Thu, 30 Mar 2006 14:30:10 +0100 Subject: [mcclim-devel] eps bug Message-ID: Hi, 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. This should fix it: --- Backends/PostScript/sheet.lisp 7 Mar 2006 15:43:44 -0000 1.13 +++ Backends/PostScript/sheet.lisp 30 Mar 2006 13:12:10 -0000 @@ -74,11 +74,11 @@ ((:eps) (let ((record (stream-output-history stream))) (multiple-value-bind (lx ly ux uy) (bounding-rectangle* record) - (setf translate-x (- (ceiling lx)) + (setf translate-x (- (floor lx)) translate-y (ceiling uy)) (format file-stream "%%BoundingBox: ~A ~A ~A ~A~%" 0 0 - (+ translate-x (floor lx)) + (+ translate-x (ceiling ux)) (- translate-y (floor ly)))))) (t (multiple-value-bind (width height) From asf at boinkor.net Thu Mar 30 20:40:44 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Thu, 30 Mar 2006 22:40:44 +0200 Subject: [mcclim-devel] New mcclim.asd: please test! Message-ID: <877j6b4qer.wl%asf@boinkor.net> Hi all, You all probably had to delete your .fasls at some point in the past, because somebody updated setf-star.lisp in the past, and asdf doesn't track rebuilds across defsystem boundaries. I just wrote a new (and more precise, cooler) asdf compile-time dependency groveler, and used it to merge the four systems that make up mcclim's core: :clim, :clim-lisp, :clim-core and :goatee-core. Now, all the components are in one system, and dependencies should be correctly tracked again. - Deleting .fasl files should be a thing of the past. (: The new system definition uncovered two bugs in mcclim already, which were masked by randomly "good" build order. (-: So, here's the new mcclim.asd. It's a drop-in replacement for the mcclim.asd in CVS. Please replace the mcclim.asd in your checkout with this one, and report your results to the list. To give a useful report, I'll have to ask you to delete your fasl files one last time, though. (: -------------- next part -------------- A non-text attachment was scrubbed... Name: mcclim.asd Type: application/octet-stream Size: 22636 bytes Desc: not available URL: -------------- next part -------------- Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From idurand at labri.fr Fri Mar 31 08:44:47 2006 From: idurand at labri.fr (Irene DURAND) Date: Fri, 31 Mar 2006 10:44:47 +0200 Subject: [mcclim-devel] pb mcclim cmucl clx Message-ID: <442CEBFF.8080402@labri.fr> Hello, I have succeeded in compiling mcclim with CMUCL : ---------------------------------------- CMU Common Lisp CVS release-19a 19a-release-20040728 + minimal debian patches, running on vivaldi.emi.u-bordeaux1.fr With core: /usr/lib/cmucl/lisp.core Dumped on: Mon, 2005-11-28 13:34:06+01:00 on vivaldi.emi.u-bordeaux1.fr For support see http://www.cons.org/cmucl/support.html Send bug reports to the debian BTS. or to pvaneynd at debian.org type (help) for help, (quit) to exit, and (demo) to see the demos Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 ---------------------------------------- The compilation ended normally with : ; Compilation unit finished. ; 27 warnings ; 589 notes ---------------------------------------- Now when I start a clim application I get a clx error: CL-USER> (clim-demo::clim-fig) :INTERNET fell through ECASE expression. Wanted one of (:UNIX OR :TCP NIL). [Condition of type CONDITIONS::CASE-FAILURE] Restarts: 0: [ABORT] Abort handling SLIME request. 1: [ABORT] Return to Top-Level. Backtrace: 0: (XLIB::OPEN-X-STREAM "localhost" 10 :INTERNET) 1: (XLIB:OPEN-DISPLAY "localhost" :DISPLAY 10 :PROTOCOL ...) 2: ((METHOD CLIM-CLX::INITIALIZE-CLX NIL (CLIM-CLX::CLX-PORT)) (#(0 14 15 14 15 ...) . #(# #)) # #) 3: ("LAMBDA (PCL::.KEYARGS-START. PCL::.VALID-KEYS. #:G5790 #:G5791 #:G5792)" #<#1=unused-arg> #<#1#> # (:SERVER-PATH (:CLX :HOST "localhost" :DISPLAY-ID 10 ...))) 4: ("DEFMETHOD MAKE-INSTANCE (CLASS)" #<#1=unused-arg> #<#1#> # (:SERVER-PATH (:CLX :HOST "localhost" :DISPLAY-ID 10 ...))) 5: (CLIM:FIND-PORT :SERVER-PATH NIL) 6: (CLIM:FIND-FRAME-MANAGER) 7: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) #1=(CLIM:APPLICATION-FRAME)) (#(14 13) . #(#)) #S(PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL (# . #) :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # NIL) 8: (SWANK::EVAL-REGION "(clim-demo::clim-fig) " T) ---------------------------------------- Any idea of how I can have the thing working? Ir?ne -- Ir?ne DURAND http://dept-info.labri.u-bordeaux.fr/~idurand From amoroso at mclink.it Fri Mar 31 13:56:07 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 31 Mar 2006 15:56:07 +0200 Subject: [mcclim-devel] pb mcclim cmucl clx In-Reply-To: <442CEBFF.8080402@labri.fr> (Irene DURAND's message of "Fri, 31 Mar 2006 10:44:47 +0200") References: <442CEBFF.8080402@labri.fr> Message-ID: <873bgyzpjc.fsf@plato.moon.paoloamoroso.it> Irene DURAND writes: > I have succeeded in compiling mcclim with CMUCL : > ---------------------------------------- > CMU Common Lisp CVS release-19a 19a-release-20040728 + minimal debian [...] > CL-USER> (clim-demo::clim-fig) > > :INTERNET fell through ECASE expression. Wanted one of (:UNIX OR :TCP NIL). > [Condition of type CONDITIONS::CASE-FAILURE] I seem to remember that this issue was fixed in recent versions of CMUCL. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From amoroso at mclink.it Fri Mar 31 15:03:11 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 31 Mar 2006 17:03:11 +0200 Subject: [mcclim-devel] New mcclim.asd: please test! References: <877j6b4qer.wl%asf@boinkor.net> Message-ID: <878xqqwtao.fsf@plato.moon.paoloamoroso.it> Andreas Fuchs writes: > So, here's the new mcclim.asd. It's a drop-in replacement for the > mcclim.asd in CVS. Please replace the mcclim.asd in your checkout with > this one, and report your results to the list. To give a useful Compiles loud and clear with CMUCL Snapshot 2006-02 (19C) under Slackware Linux 10.0. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log