mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[mcclim-devel] Method browser applicable methods improvement
by Willem Broekema 04 Mar '08

04 Mar '08

In the method browser, the function COMPUTE-APPLICABLE-METHODS-FROM-SPECIALIZERS determines the applicable methods by first creating a list of prototype instances for the specializers. The instances are then fed to COMPUTE-APPLICABLE-METHODS. The problem is that fetching prototype instances of built-in classes is brittle (the function is not part of ANSI), e.g. in Allegro: CL-USER(78): (mop::class-prototype (find-class 'integer)) Error: The slot EXCL::PROTOTYPE is missing from the object #<BUILT-IN-CLASS INTEGER> of class #<STANDARD-CLASS BUILT-IN-CLASS> during operation SLOT-VALUE [condition type: PROGRAM-ERROR] Restart actions (select using :continue): 0: Try accessing the slot again 1: Return a value 2: Return to Top Level (an "abort" restart). 3: Abort entirely from this (lisp) process. See also this discussion: http://groups.google.nl/group/comp.lang.lisp/browse_frm/thread/a15fd265fa3b… The attached patch makes the method browser robust against unavailable prototype instances, and documents where things still to wrong. Cheers, - Willem

2 1

[mcclim-devel] cpu constantly at 99% with just a simple GUI open
by Dietrich Bollmann 04 Mar '08

04 Mar '08

Hi, I build a very small GUI based on the calculator example. But when starting the GUI the CPU is constantly at 99%. Is this normal? Is there some configuration option to get a different behaviour? Does McCLIM use some kind of polling internally? And is there some hope that this might change in the future? Some day I would like to experiment with some realtime application and a busy CPU probably wouldn't be something good :) Thank you, Dietrich By the way: Rick Taube, the author of "lambda-gtk" and "common music" recently seemed to have switched from lambda-gtk to a C++ based gui (using "juce") which seems to communicate with his lisp code via a socket. I suppose that his main reason was the audio functionality which is part of "juce" and the possibility to easily use the same code for Windows, Mac and Linux. But another reason might have been a better realtime behaviour compared to the lambda-gtk gui. Would this be a better way to go?

4 13

[mcclim-devel] Drei Lisp syntax fix
by Willem Broekema 02 Mar '08

02 Mar '08

There is a small error in FORM-TO-OBJECT, which causes the method for incomplete-quote-form to be shadowed by the NO-APPLICABLE-METHOD default method. The attached patch fixes this. Cheers, - Willem

2 2

[mcclim-devel] drei-gadget-panes
by Thomas Persson 16 Feb '08

16 Feb '08

Hi A small patch to make a drei-gadget-pane inherit from the application-frame's command-table.

1 0

[mcclim-devel] Reinstate #\: as command-dispatcher
by Rudi Schlatte 07 Feb '08

07 Feb '08

Hi, The description of *command-dispatchers* at the bottom of http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/27-6.html#_1436 is quite clear: #\: must be included. I'd like to commit the attached patch, but based on my recent track record I figured it would be better to ask first. Cheers, Rudi

3 2

[mcclim-devel] New McClim installation
by Bill Sauer 05 Feb '08

05 Feb '08

Hi, I would like to setup mcclim on a new machine. I have cmucl 19d and fedora 8. I have searched the Web for clues on how to do this but much of it seems out of date with broken links. Is there anywhere I can find out in a straight forward manner what needs to be done and in what order. I have been on the mailing list for some time and it's pretty clear that mcclim is evolving rapidly which is good. My concern is that what ever I setup be amenable to reasonably easy upgrades as mcclim grows. Thanks for the help. Bill Sauer

2 2

[mcclim-devel] Download page broken for mcclim
by Michael Mateas 03 Feb '08

03 Feb '08

Hi, I'm trying to download mcclim. This link: http://common-lisp.net/project/mcclim/downloads/mcclim-0.9.5.tar.gz, on the mcclim project page, is broken. Could someone fix this link, or let me know where else I can get hold of mcclim-0.9.5? Thanks, -Michael

2 1

[mcclim-devel] DREI: delete-elements* isn't defined
by Evgeny M. Zubok 01 Feb '08

01 Feb '08

The method/function (delete-elements*...) isn't defined but used in buffer.lisp. McCLIM is running on CLISP 2.41.

4 8

[mcclim-devel] Fwd: Your message to mcclim-cvs awaits moderator approval
by Andy Hefner 31 Jan '08

31 Jan '08

Imagine a batch of commits to freetype here. =/ ---------- Forwarded message ---------- From: <mcclim-cvs-bounces(a)common-lisp.net> Date: Jan 31, 2008 3:58 AM Subject: Your message to mcclim-cvs awaits moderator approval To: ahefner(a)common-lisp.net Your mail to 'mcclim-cvs' with the subject CVS mcclim/Experimental/freetype Is being held until the list moderator can review it for approval. We're sorry, due to the volume of spam we receive most mailinglists require you to subscribe before posting. You may cancel this post (at the URL below) or waiting for the moderator to approve it. Thanks and sorry for the inconvenience. The reason it is being held: Message body is too big: 44477 bytes with a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL:

1 0

[mcclim-devel] McCLIM 2.0 in 2008
by Troels Henriksen 30 Jan '08

30 Jan '08

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

7 15

← Newer
1
...
22
23
24
25
26
27
28
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel