[resent to the correct address - I hope...]
I was wondering why the :highlight option to :single-box wasn't working as I thought it should. Turns out there was a wee typo. Patch attached.
JQS
Index: presentation-defs.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/presentation-defs.lisp,v retrieving revision 1.44 diff -u -r1.44 presentation-defs.lisp --- presentation-defs.lisp 22 Jun 2005 09:49:15 -0000 1.44 +++ presentation-defs.lisp 25 Jul 2005 13:05:48 -0000 @@ -993,7 +993,7 @@ (multiple-value-bind (min-x min-y max-x max-y) (output-record-hit-detection-rectangle* record) (if (and (<= min-x x max-x) (<= min-y y max-y)) - (if (or (null single-box) (eq single-box :higlighting)) + (if (or (null single-box) (eq single-box :highlighting)) (funcall-presentation-generic-function presentation-refined-position-test (presentation-type record) record x y)
David Murray adm@cpmg.tv writes:
[resent to the correct address - I hope...]
I was wondering why the :highlight option to :single-box wasn't working as I thought it should. Turns out there was a wee typo. Patch attached.
Thanks, I've applied this patch. (Whether it should take two weeks to apply a one-line patch, I don't know; you be the judge...)
Is there any code in Examples/ or Apps/ which exercises this code path? If not, it might be worth including some -- if we can't have an automatic regression test suite, then we might as well have a manual one.
Cheers,
Christophe
On Aug 8, 2005, at 1:11 PM, Christophe Rhodes wrote:
David Murray adm@cpmg.tv writes:
[resent to the correct address - I hope...]
I was wondering why the :highlight option to :single-box wasn't working as I thought it should. Turns out there was a wee typo. Patch attached.
Thanks, I've applied this patch. (Whether it should take two weeks to apply a one-line patch, I don't know; you be the judge...)
No, it shouldn't. In my lame defense, I'm traveling and not paying much attention :) Thanks, Christophe.
Tim
Timothy Moore writes:
No, it shouldn't. In my lame defense, I'm traveling and not paying much attention :) Thanks, Christophe.
Perhaps you can make up for it by making incremental redisplay respect the output recording protocol, and not count on there being a slot called coordinates? :-)
Timothy Moore moore@bricoworks.com writes:
On Aug 8, 2005, at 1:11 PM, Christophe Rhodes wrote:
Thanks, I've applied this patch. (Whether it should take two weeks to apply a one-line patch, I don't know; you be the judge...)
No, it shouldn't. In my lame defense, I'm traveling and not paying much attention :) Thanks, Christophe.
I was going to start this message by saying "I wasn't trying to apportion blame", but then I realised that that would be a slightly disingenuous response. I was not and am not trying to apportion blame, but it was a pointed message nonetheless, and for the pointiness I apologise.
It does raise at least one question, though: who "owns" the McCLIM code, where by "owns" I actually mean "feels that he has ownership of"? Perhaps more to the point, who "owns" the development process? It's obviously harder to provide timely responses at present, when no-one can devote even a substantial portion of their time to McCLIM development, than it has been in the past, when students both feckless and directed have had as part of their tasks to work on it: now many of those students are Real People, with jobs and so on to sap their time and energy...
Now, we at work are using McCLIM as a substrate for our research and library work, but we seem to be diverging (not too rapidly yet, thankfully) in our local tree despite my having write access, simply because I cannot afford the time to take "ownership" (responsibility, if you will) of the various problems we encounter and work around -- such as the incremental-redisplay performance issues I've mentioned before, the status of arbitrary output-recording streams as candidates for updating-output, and suchlike -- we think we have another problem with freetype fonts (but the report for that might well be stuck in the mailing list moderation queue...), and so on, and so on.
I hope I'm not coming on too strong -- I certainly don't expect the world to arrange itself for my convenience, so that I can have what I want, right now -- but I think that we as a time-poor developer community need to think how best to manage going forward with McCLIM, now that a sufficient base of functionality has been built.
We don't have the luxury of commercial resources being thrown at us, and I suspect that this isn't going to change in the near term. Sadly, nor do I see much in the way of research funding in this area; these things are always possible -- I will try to sneak in requests for some time to work on the stack of lisp code that we use in future grant applications, for instance -- but the timescale and the odds are unfavourable. We even managed to avoid the shower of money (which, as Einstein proved, is equivalent to time) thrown at the Lisp community by Google -- the project I proposed to integrate R-trees into output-recording was not funded...
I suppose this boils down to two questions. Firstly, how do we best manage the development resources that we currently have? Some of this is a social problem, but the good news is that it's mostly technical: experience tells me that we're much better at solving technical problems than social ones. My own feelings on CLiki-as-bugtracker are known, I think, but Paolo is a perfectly acceptable User Interface from my point of view, so while he remains willing to serve like that, it's fine. What we lack is any kind of automatic regression testing to give confidence that bugs remain fixed; lacking a wide userbase as we do, we can't depend on timely notification of regressions from users. I have some of a Null backend for McCLIM which could be used, if completed, as a means of testing even the graphical output protocols; somewhat inevitably, though, I don't have time to advance on it at more than a snail's pace...
Secondly, how do we cause the available development resources to grow? Absent sources of funding, this means finding people to work for free... never a great prospect on its own. Killer apps and a certain amount of "evangelism" help; whether a text editor and a score editor are sexy enough for that, I don't know -- is anyone else working on anything exciting? (People here may not know that the closure web browser is at least partially revived: it is known to run in McCLIM using the X backend and recent CMUCL or SBCL releases; on the other hand, there's no way that a web browser is going to be a killer application in today's world...)
I'm afraid I don't have any easy answers -- and I know that these things take time. On the other hand, it's possible that a little thought now would reduce the time it takes for the situation with regards to active development to improve...
If you've made it down to here, congratulations, and thank you for reading :-). Any thoughts?
Cheers,
Christophe
Christophe Rhodes csr21@cam.ac.uk writes:
problems than social ones. My own feelings on CLiki-as-bugtracker are known, I think, but Paolo is a perfectly acceptable User Interface from my point of view, so while he remains willing to serve like that, it's fine. What we lack is any kind of automatic regression testing to give confidence that bugs remain fixed; lacking a wide userbase as
Yes, I am still willing to maintain the bug list. Any feedback on that page after using it for some time? Is the page easy to browse? Any redundant information? What about moving the closed bugs section to a different page?
As for testing, each time I update my working copy of the CVS repository, I also rebuild the CLIM Listener and play a bit with it. Occasionally, I also do this with the demos. It's not formal testing, but does provide a quick opportunity to see whether anything is obviously broken.
Secondly, how do we cause the available development resources to grow?
[...]
anything exciting? (People here may not know that the closure web browser is at least partially revived: it is known to run in McCLIM using the X backend and recent CMUCL or SBCL releases; on the other hand, there's no way that a web browser is going to be a killer application in today's world...)
A web browser application probably not, but a comfortably hackable browser may have some appeal.
Paolo
"PA" == Paolo Amoroso amoroso@mclink.it writes:
PA> Christophe Rhodes csr21@cam.ac.uk writes: >> problems than social ones. My own feelings on CLiki-as-bugtracker are >> known, I think, but Paolo is a perfectly acceptable User Interface >> from my point of view, so while he remains willing to serve like that, >> it's fine. What we lack is any kind of automatic regression testing >> to give confidence that bugs remain fixed; lacking a wide userbase as
PA> Yes, I am still willing to maintain the bug list. Any feedback on PA> that page after using it for some time? Is the page easy to browse? PA> Any redundant information? What about moving the closed bugs section PA> to a different page?
Is there some reason to do this instead of a Bugzilla? Is the latter just too much of a pain to maintain?
PA> As for testing, each time I update my working copy of the CVS PA> repository, I also rebuild the CLIM Listener and play a bit with it. PA> Occasionally, I also do this with the demos. It's not formal testing, PA> but does provide a quick opportunity to see whether anything is PA> obviously broken.
Would you consider writing up a McCLIM cliki page describing what you do when you play with the lisp listener? This is the only application beside my own (that I know of) that uses format-graph-from-roots. I'd love to have a quick list of things to try before committing a patch.
>> Secondly, how do we cause the available development resources to grow? PA> [...] >> anything exciting? (People here may not know that the closure web >> browser is at least partially revived: it is known to run in McCLIM >> using the X backend and recent CMUCL or SBCL releases; on the other >> hand, there's no way that a web browser is going to be a killer >> application in today's world...)
PA> A web browser application probably not, but a comfortably hackable PA> browser may have some appeal.
How about a front-end for some of the MP3 stuff in Practical Common Lisp?
How about configuration consoles for some of the CL applications out there. E.g., I've just discovered that Albert has a ton of configuration options....
Just a thought....
As an aside, can anyone point me to a sample application that has some pane devoted to displaying information about the state of the application (e.g., a filename that is the current document, mode of interaction, etc.)? I'm a little hazy on how to manage the use of labels, etc.
Thanks!
R
rpgoldman@real-time.com writes:
Is there some reason to do this instead of a Bugzilla? Is the latter just too much of a pain to maintain?
This was discussed here in the past, but I don't have links handy. I seem to remember that this is because such tools make reporting bugs too much a hassle.
Would you consider writing up a McCLIM cliki page describing what you do when you play with the lisp listener? This is the only application
I execute this command, which shakes the Listener a bit:
Show Class Subclasses (class) t
Then I walk the file system a bit by clicking on pathnames.
As an aside, can anyone point me to a sample application that has some pane devoted to displaying information about the state of the application (e.g., a filename that is the current document, mode of
Do you mean something like a status bar?
Paolo
"PA" == Paolo Amoroso amoroso@mclink.it writes:
PA> rpgoldman@real-time.com writes: >> Is there some reason to do this instead of a Bugzilla? Is the latter >> just too much of a pain to maintain?
PA> This was discussed here in the past, but I don't have links handy. I PA> seem to remember that this is because such tools make reporting bugs PA> too much a hassle.
>> Would you consider writing up a McCLIM cliki page describing what you >> do when you play with the lisp listener? This is the only application
PA> I execute this command, which shakes the Listener a bit:
PA> Show Class Subclasses (class) t
PA> Then I walk the file system a bit by clicking on pathnames.
OK, that crashes for me! The problem is that it tries to use a TREE style graph formatting while also setting the merge-duplicates argument to true. When I patched the code to allow actual duplicate merging (AFAICT, this was just ignored before), I made it a violation to have :tree layout and :merge-duplicates = t.
When the lisp-listener crashed, I was wondering if this was The Right Thing or not. Alas, the CLIM specification seems unhelpful and possibly even garbled on this point:
"If the boolean merge-duplicates is true, then duplicate objects in the graph will share the same node in the display of the graph. That is, when merge-duplicates is true, THE RESULTING GRAPH WILL BE A TREE [emphasis added -rpg]. If merge-duplicates is false (the default), then duplicate objects will be displayed in separate nodes. duplicate-key is a function of one argument that is used to extract the node object component used for duplicate comparison; the default is identity. duplicate-test is a function of two arguments that is used to compare two objects to see if they are duplicates; the default is eql. duplicate-key and duplicate-test have dynamic extent."
The material in all caps above seems to be a flat-out mistake --- if you merge duplicates, you can introduce cycles. So it is specifically if merge-duplicates is FALSE that you get a tree, right?
I tried temporarily changing :merge-duplicates to NIL Any reason not to do that?
As far as I can tell
Then when I clicked on an item, the listener crashed for me:
Error: Class #<STANDARD-CLASS CLIM:BOUNDING-RECTANGLE> is not yet finalized. [condition type: PROGRAM-ERROR]
in COM-SHOW-CLASS-SLOTS...
I get a number of meta-object related bugs when I do this. Seems like perhaps ACL's MOP implementation is not particularly happy with the class browser. :-(
I probably don't have too much time to spend on that, alas.
>> As an aside, can anyone point me to a sample application that has some >> pane devoted to displaying information about the state of the >> application (e.g., a filename that is the current document, mode of
PA> Do you mean something like a status bar?
Yes, that sort of thing. Probably one in CLIMACS, I figure. Seems to be one in the clim-listener I could probably copy.
There are two interesting things about the clim-listener "wholine" statusbar:
1. CLIM's layout algorithm seems inadequate --- it seems to require special help to manage the wholine, since there needs to be special compose-space and allocate-space methods. Anyone have any idea why that is? Does this reflect problems with CLIM?
2. Doesn't use incremental redisplay. I would have thought that the wholine, for example, would be a good application for this, since most of the time the user ID won't change, and even the package name is probably pretty stable. Is this because of problems with incremental redisplay? Or is it just that rendering the wholine is so cheap it's not worth the trouble?
Thanks, R
rpgoldman@real-time.com writes:
Then when I clicked on an item, the listener crashed for me:
[...]
I get a number of meta-object related bugs when I do this. Seems like
I use CMUCL, and class browsing commands seem to work fine.
Paolo
"PA" == Paolo Amoroso amoroso@mclink.it writes:
PA> rpgoldman@real-time.com writes: >> Then when I clicked on an item, the listener crashed for me: PA> [...] >> I get a number of meta-object related bugs when I do this. Seems like
PA> I use CMUCL, and class browsing commands seem to work fine.
They're badly busted for me. This seems like a morass of ACL MOP tweaking, alas. So this probably won't be a good way for me to evaluate graph-formatting patches. :-(
R
rpgoldman@real-time.com writes:
They're badly busted for me. This seems like a morass of ACL MOP tweaking, alas. So this probably won't be a good way for me to
What about Closer (Closer to MOP in particular)?
http://common-lisp.net/project/closer
Paolo
"PA" == Paolo Amoroso amoroso@mclink.it writes:
PA> rpgoldman@real-time.com writes: >> They're badly busted for me. This seems like a morass of ACL MOP >> tweaking, alas. So this probably won't be a good way for me to
PA> What about Closer (Closer to MOP in particular)?
PA> http://common-lisp.net/project/closer
Thanks, but I'm primarily interested in the CLIM listener as a way to test my graph-drawing patches.
I don't want to bite off another chunk of McCLIM to work on, just yet!
:-)
Best, R
On 8/9/05, rpgoldman@real-time.com rpgoldman@real-time.com wrote:
There are two interesting things about the clim-listener "wholine" statusbar:
- CLIM's layout algorithm seems inadequate --- it seems to require special help to manage the wholine, since there needs to be special compose-space and allocate-space methods. Anyone have any idea why that is? Does this reflect problems with CLIM?
The compose-space method is only there because I'm picky about the size and appearance of the wholine. I'm doing something unusual in the wholine, drawing the beveled decoration behind the text in the handle-repaint method (with output recording off) before replaying the recorded output. This way the decoration does not pollute the output history, and I can redraw the decoration without recomputing the contents of the pane. If the size of the pane changes, the bevel should adjust to fill it. The allocate-space method is there to make this happen (repaint the window when the size changes).
A simpler approach might have been to use some kind of border pane around a vanilla application-pane. Still, I think it's good to know how to do this.
- Doesn't use incremental redisplay. I would have thought that the wholine, for example, would be a good application for this, since most of the time the user ID won't change, and even the package name is probably pretty stable. Is this because of problems with incremental redisplay? Or is it just that rendering the wholine is so cheap it's not worth the trouble?
I expect that rendering the wholine is very cheap.
Paolo Amoroso amoroso@mclink.it writes:
rpgoldman@real-time.com writes:
Is there some reason to do this instead of a Bugzilla? Is the latter just too much of a pain to maintain?
This was discussed here in the past, but I don't have links handy. I
I do have such a link now:
http://www.paoloamoroso.it/log/050227.html
But, unfortunately, the links to individual mcclim-devel messages in the archive are stale.
Paolo
rpgoldman@real-time.com writes:
As an aside, can anyone point me to a sample application that has some pane devoted to displaying information about the state of the application (e.g., a filename that is the current document, mode of interaction, etc.)? I'm a little hazy on how to manage the use of labels, etc.
The only thing I can think about is the info pane in Climacs which provides functionality equivalent to the Emacs mode line.
Christophe Rhodes writes:
It does raise at least one question, though: who "owns" the McCLIM code, where by "owns" I actually mean "feels that he has ownership of"?
It would be hard to come up with such a person, I think.
Perhaps more to the point, who "owns" the development process?
That's a more reasonable question to ask. I think it would have to be a very active current developer, but I don't see one like that at the moment. Probably Tim Moore would be the one that comes closest.
It's obviously harder to provide timely responses at present, when no-one can devote even a substantial portion of their time to McCLIM development, than it has been in the past, when students both feckless and directed have had as part of their tasks to work on it: now many of those students are Real People, with jobs and so on to sap their time and energy...
True, and I do think McCLIM needs such an owner (I have called that person a Newman-type person for McCLIM). I am afraid there are no candidates at the moment. And Tim now has a real job, so we can expect even less work on McCLIM from him.
Now, we at work are using McCLIM as a substrate for our research and library work, but we seem to be diverging (not too rapidly yet, thankfully) in our local tree despite my having write access, simply because I cannot afford the time to take "ownership" (responsibility, if you will) of the various problems we encounter and work around -- such as the incremental-redisplay performance issues I've mentioned before, the status of arbitrary output-recording streams as candidates for updating-output, and suchlike -- we think we have another problem with freetype fonts (but the report for that might well be stuck in the mailing list moderation queue...), and so on, and so on.
There are indeed many such problems that need to be addressed. While technically speaking I have the time over the next year to take on this ownership, I do not think I will, because I have at least two more large-ish programming projects to take care of. Though I guess if Dave Murray takes care of Climacs, and someone else of Gsharp, I could work on McCLIM :-)
Also, like I have said many times, McCLIM needs a near-total overhaul in terms of code maintainability and compliance with the standard. So if I were to take ownership, I would not start by fixing immediate problems, but by improving the code in order to make such fixes easier. We are talking at least a few months of work I would think.
I hope I'm not coming on too strong -- I certainly don't expect the world to arrange itself for my convenience, so that I can have what I want, right now -- but I think that we as a time-poor developer community need to think how best to manage going forward with McCLIM, now that a sufficient base of functionality has been built.
Sure.
I suppose this boils down to two questions. Firstly, how do we best manage the development resources that we currently have?
I think this will be hard unless there is at least one person willing to invest time in understanding the spec and the code. Only someone with a relatively global view of both would be able to determine whether a suggested patch for a problem will break something else. Now, with a bit of luck, that person would not have to actually do that much coding, but could rely on others to actually suggest patches.
What we lack is any kind of automatic regression testing to give confidence that bugs remain fixed; lacking a wide userbase as we do, we can't depend on timely notification of regressions from users. I have some of a Null backend for McCLIM which could be used, if completed, as a means of testing even the graphical output protocols; somewhat inevitably, though, I don't have time to advance on it at more than a snail's pace...
Automatic regression testing would be very nice, but it is a huge task in itself. It requires, it seems to me, having understood the spec, which we know is both ambiguous, self contradictory, and incomplete.
Secondly, how do we cause the available development resources to grow? Absent sources of funding, this means finding people to work for free... never a great prospect on its own. Killer apps and a certain amount of "evangelism" help; whether a text editor and a score editor are sexy enough for that, I don't know --
A score editor certainly has some limited audience, but it could be a killer app to its particular audience. For that, it needs to work properly, which is why I was planning to work on it a bit more this year.
A text editor could be a killer app when it acquires functionality comparable to SLIME, and even better in some areas. Implementing most of SLIME in Climacs probably requires a lot of work, but I am guessing that the existence of features unique to Climacs would attract more developers willing to put into it what is currently in SLIME. Though, that will not help McCLIM very much.
is anyone else working on anything exciting? (People here may not know that the closure web browser is at least partially revived: it is known to run in McCLIM using the X backend and recent CMUCL or SBCL releases; on the other hand, there's no way that a web browser is going to be a killer application in today's world...)
There are two different meanings here to "killer app". The first meaning is an application that is interesting to the general public and that provides functionality that existing applications do not have. Gsharp could become such an application, but it would attract very few, if any, developers.
The second meaning is an application that is uniquely hackable because it is written in CL and would therefore attract CL developers who would be willing to put up with fewer features than what some similar existing application have, in return for easily being able to add their own features. Closure and Climacs are such applications.
I think the second type of applications would be more suited to attract new developers for McCLIM.
And to answer your question, no I am not personally working on anything else, exciting or not.
I'm afraid I don't have any easy answers -- and I know that these things take time. On the other hand, it's possible that a little thought now would reduce the time it takes for the situation with regards to active development to improve...
Definitely.
If you've made it down to here, congratulations, and thank you for reading :-). Any thoughts?
I really do think that someone would have to sacrifice the better part of a few months to fully read and understand the spec and the code. It would be easier for someone who has already read and understood the spec, of course.
"RS" == Robert Strandh strandh@labri.fr writes:
RS> Christophe Rhodes writes:
[...snip...]
RS> Also, like I have said many times, McCLIM needs a near-total overhaul RS> in terms of code maintainability and compliance with the standard. So RS> if I were to take ownership, I would not start by fixing immediate RS> problems, but by improving the code in order to make such fixes RS> easier. We are talking at least a few months of work I would RS> think.
Suggestion: if we decide to do such a thing, would it be possible to do another code freeze and "stable" release in the meantime?
Esp. if we'd like to get more users, it might be nice for us to have a version that was easy to grab (asdf-install?), and about which programmers could develop an oral tradition involving limitations, workarounds, etc.
>> What we lack is any kind of automatic regression testing >> to give confidence that bugs remain fixed; lacking a wide userbase as >> we do, we can't depend on timely notification of regressions from >> users. I have some of a Null backend for McCLIM which could be used, >> if completed, as a means of testing even the graphical output >> protocols; somewhat inevitably, though, I don't have time to advance >> on it at more than a snail's pace...
RS> Automatic regression testing would be very nice, but it is a huge task RS> in itself. It requires, it seems to me, having understood the spec, RS> which we know is both ambiguous, self contradictory, and RS> incomplete.
I have found that generating tests that exercise a patch every time I generate a patch helps grow a population of regression tests. I see two additional challenges, however:
1. inadequacy of existing regression/unit testing frameworks. I've actually been working on an extension of Waters' RT system for my own projects to meet some of these needs. I found that Waters' system doesn't scale that well --- one needs a notion of test groups and one needs setup and tear-downs. But other frameworks that offered these facilities seemed either to be orphaned (sometimes in a half-finished state) and/or intertwined with large numbers of other libraries.
2. Difficulty of non-graphically testing a graphical framework like McCLIM.
RS> The second meaning is an application that is uniquely hackable because RS> it is written in CL and would therefore attract CL developers who RS> would be willing to put up with fewer features than what some similar RS> existing application have, in return for easily being able to add RS> their own features. Closure and Climacs are such RS> applications.
I don't mean to carp, but it's hard to see Climacs as such an application because Emacs (resp Xemacs) are already so extensible and they suck up much of the available extension energy. I'm not at all sure that Closure will be such, either, since Firefox is so popular, despite its use of (ugh) JavaScript.
What about IRC clients? This seems to have an audience that likes to hack, and the existing ones all seem to have at least one glaring hole...
rpgoldman@real-time.com writes:
RS> Also, like I have said many times, McCLIM needs a near-total overhaul RS> in terms of code maintainability and compliance with the standard. So RS> if I were to take ownership, I would not start by fixing immediate RS> problems, but by improving the code in order to make such fixes RS> easier. We are talking at least a few months of work I would RS> think.Suggestion: if we decide to do such a thing, would it be possible to do another code freeze and "stable" release in the meantime?
Esp. if we'd like to get more users, it might be nice for us to have a version that was easy to grab (asdf-install?), and about which programmers could develop an oral tradition involving limitations, workarounds, etc.
I guess so. Though, a "near-total overhaul" could still be incremental, or that's the way I would do it anyway.
RS> The second meaning is an application that is uniquely hackable because RS> it is written in CL and would therefore attract CL developers who RS> would be willing to put up with fewer features than what some similar RS> existing application have, in return for easily being able to add RS> their own features. Closure and Climacs are such RS> applications.I don't mean to carp, but it's hard to see Climacs as such an application because Emacs (resp Xemacs) are already so extensible and
I might be wrong of course, but my bet is that when it comes to CL development, extending Emacs or Xemacs will be much harder because of the need to communicate with CL over byte streams.
they suck up much of the available extension energy.
perhaps this is a sign that they are not easy enough to extend :-)
--- Robert Strandh strandh@labri.fr wrote:
There are indeed many such problems that need to be addressed. While technically speaking I have the time over the next year to take on this ownership, I do not think I will, because I have at least two more large-ish programming projects to take care of. Though I guess if Dave Murray takes care of Climacs, and someone else of Gsharp, I could work on McCLIM :-)
Perhaps you could consider your work on McCLIM to be the necessary preliminary work for Climacs/Gsharp? ;-)
Also, like I have said many times, McCLIM needs a near-total overhaul in terms of code maintainability and compliance with the standard. So if I were to take ownership, I would not start by fixing immediate problems, but by improving the code in order to make such fixes easier. We are talking at least a few months of work I would think.
Personally I give such a goal three cheers! There are not enough major apps/users to cause a severe upset if this is done right now, so now is an excellent time. Indeed, we might regret it if we don't - maintainable code is a MUST in my book.
Automatic regression testing would be very nice, but it is a huge task in itself. It requires, it seems to me, having understood the spec, which we know is both ambiguous, self contradictory, and incomplete.
Then we should make this goal part of the overhaul - indeed, I see no other viable way to approach it. Perhaps the spec should merge with the McCLIM code and become a literate document - the code in essence being the fully specific expression of the spec? Perhaps the Axiom philosophy is infecting me but it would seem to be an almost ideal arrangement - use Albert or some such to produce a nice, formatted version of the spec from the source code, and maintain spec and code as one document.
A score editor certainly has some limited audience, but it could be a killer app to its particular audience. For that, it needs to work properly, which is why I was planning to work on it a bit more this year.
But CAN it work properly without a revamped and robust McCLIM?
There are two different meanings here to "killer app". The first meaning is an application that is interesting to the general public and that provides functionality that existing applications do not have. Gsharp could become such an application, but it would attract very few, if any, developers.
In open source terms, I still think the ideal "killer app" would be an advanced mathematical document interface. However, that's non-trivial in virtually every way imaginable, and would only attract a few developers. rtoy has broken the ice with a basic interface to Maxima, but a "killer app" level interface would be months and months of work, some of it extremely involved.
The second meaning is an application that is uniquely hackable because it is written in CL and would therefore attract CL developers who would be willing to put up with fewer features than what some similar existing application have, in return for easily being able to add their own features. Closure and Climacs are such applications.
A math interface would definitely not meet this criteria - too specialized.
I really do think that someone would have to sacrifice the better part of a few months to fully read and understand the spec and the code. It would be easier for someone who has already read and understood the spec, of course.
I like your refactoring idea - for McCLIM to take off it should be sufficiently robust to not cause new users any major frustrations beyond learning it in the first place. I personally think the next step should be taken - integrate the spec with the code itself, and iron out any bugs/limitations in the spec that present themselves.
Not that I rate an opinion, of course - actual code trumps mere ideas ;-).
Cheers, CY
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
C Y writes:
Perhaps you could consider your work on McCLIM to be the necessary preliminary work for Climacs/Gsharp? ;-)
Nice try :-)
A score editor certainly has some limited audience, but it could be a killer app to its particular audience. For that, it needs to work properly, which is why I was planning to work on it a bit more this year.
But CAN it work properly without a revamped and robust McCLIM?
Yes, I think so. I mean, McCLIM is quite stable (in the sense that it is not crashing) and usable. The main problem for Gsharp is that I have had to write more code than I would have wanted to get around current problems with McCLIM. Of course, at some point, it becomes more advantageous to fix McCLIM than to write workarounds.
In open source terms, I still think the ideal "killer app" would be an advanced mathematical document interface. However, that's non-trivial in virtually every way imaginable, and would only attract a few developers. rtoy has broken the ice with a basic interface to Maxima, but a "killer app" level interface would be months and months of work, some of it extremely involved.
Nice project, definitely.
for McCLIM to take off it should be sufficiently robust to not cause new users any major frustrations beyond learning it in the first place. I personally think the next step should be taken - integrate the spec with the code itself, and iron out any bugs/limitations in the spec that present themselves.
There are of course many ways of integrating the code and the spec. There are places in the current code with references to the spec, but I am guessing you want to go further than that. I am not sure I see how such integration would have a major impact on the maintainability of the code, though.
--- Robert Strandh strandh@labri.fr wrote:
C Y writes:
Perhaps you could consider your work on McCLIM to be the necessary preliminary work for Climacs/Gsharp? ;-)
Nice try :-)
It was worth a shot :-P
Yes, I think so. I mean, McCLIM is quite stable (in the sense that it is not crashing) and usable. The main problem for Gsharp is that I have had to write more code than I would have wanted to get around current problems with McCLIM. Of course, at some point, it becomes more advantageous to fix McCLIM than to write workarounds.
Ah, OK.
There are of course many ways of integrating the code and the spec. There are places in the current code with references to the spec, but I am guessing you want to go further than that. I am not sure I see how such integration would have a major impact on the maintainability of the code, though.
Well, it's more a case of convenience, but the psychology is good too - when you write a piece of code the text describing the purpose of the code is right there for reference/documentation, and if you need to update the spec due to code enhancements it's again right there. It's the whole "literate programming" thing. I know actions speak louder than words on such things though :-/.
Cheers, CY
____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
C Y writes:
Well, it's more a case of convenience, but the psychology is good too - when you write a piece of code the text describing the purpose of the code is right there for reference/documentation, and if you need to update the spec due to code enhancements it's again right there. It's the whole "literate programming" thing. I know actions speak louder than words on such things though :-/.
I know only very little about literate programming, but it seems to me hard to obtain in an advanced programming language like CL, where the actual implementation of some functionality could be spread out over several files, so that you could not naturally get a textual association between the code and the spec. Also, there is obviously a lot of code that corresponds to nothing at all in the spec, but which should be documented nevertheless. It looks to me like an integrated documentation system like Concordia would be more appropriate. Luckily, McCLIM would be ideal for implementing such a system. Now, we just have to find someone to do that.
"RS" == Robert Strandh strandh@labri.fr writes:
[...snip...]
>> But CAN it work properly without a revamped and robust McCLIM?
RS> Yes, I think so. I mean, McCLIM is quite stable (in the sense that it RS> is not crashing) and usable. The main problem for Gsharp is that I RS> have had to write more code than I would have wanted to get around RS> current problems with McCLIM. Of course, at some point, it becomes RS> more advantageous to fix McCLIM than to write workarounds.
I'm afraid that hasn't really been my experience. I can often crash McCLIM when I do something that upsets its processing of ACCEPT, in particular, and updating output seems to work very, very badly with scrolling panes, so badly that I can't think of a single interaction which hasn't required me to iconify and de-iconify the frame to make it repaint reasonably. And usually I have to resize the frame by hand in the process. This seems to me to be pretty far from usable.
This isn't meant to be whining --- I'm working to help improve the situation. But I'm not as sanguine about the current status. As I mention below, I think we need a bunch more gadgets.
>> In open source terms, I still think the ideal "killer app" would be an >> advanced mathematical document interface. However, that's non-trivial >> in virtually every way imaginable, and would only attract a few >> developers. rtoy has broken the ice with a basic interface to Maxima, >> but a "killer app" level interface would be months and months of work, >> some of it extremely involved.
RS> Nice project, definitely.
One could imagine biting off a smaller piece --- perhaps something involving MathML? But typesetting math is not that easy! It took even Knuth a bunch of years!
>> for McCLIM to take off it should be >> sufficiently robust to not cause new users any major frustrations >> beyond learning it in the first place.
I think it should also be enhanced to be able to generate interfaces that don't cause their users (as opposed to their programmers) cognitive upset. So there ought to be file-choosers that look mostly like other file-choosers, etc.
Unfortunately, that's a lot of gadgetage to be written.
For me, McCLIM is useful because it lets me build UIs that are good for me to use, which mostly means for debugging --- the objects are very "apparent" and I can grab them and wrestle with them in the REPL. To be honest, if I wanted to just write a user interface for real users (FSVO "real"), I'd be inclined to just bolt something onto a lisp server using a more conventional framework, and a different programming language.
>> I personally think the next step should be taken - integrate >> the spec with the code itself, and iron out any >> bugs/limitations in the spec that present themselves.
RS> There are of course many ways of integrating the code and the spec. RS> There are places in the current code with references to the spec, but RS> I am guessing you want to go further than that. I am not sure I see RS> how such integration would have a major impact on the maintainability RS> of the code, though.
A simple step that could be taken would be to put bits of the spec into the documentation strings. I don't have the appetite for that level of cut-and-paste drudgery, though :-/
As far as ironing out bugs and limitations in the spec, we probably need to have a real project owner to make that feasible. Which takes us back to Christophe's original question. ;-)
R
rpgoldman@real-time.com writes:
I'm afraid that hasn't really been my experience. I can often crash McCLIM when I do something that upsets its processing of ACCEPT, in particular, and updating output seems to work very, very badly with scrolling panes, so badly that I can't think of a single interaction which hasn't required me to iconify and de-iconify the frame to make it repaint reasonably. And usually I have to resize the frame by hand in the process. This seems to me to be pretty far from usable.
OK. I guess I just haven't had to use those parts of McCLIM.
This isn't meant to be whining --- I'm working to help improve the situation. But I'm not as sanguine about the current status. As I mention below, I think we need a bunch more gadgets.
Well, yes, sort of. I mean, since CLIM is so stratified, it is *possible* though not necessarily *desirable* for an application to implement the gadgets it needs. This fact makes it less urgent to add more functionality to McCLIM. I do think stability and compliance are higher up on the list.
One could imagine biting off a smaller piece --- perhaps something involving MathML? But typesetting math is not that easy! It took even Knuth a bunch of years!
TeXmacs does a fairly good job, it seems. Now if we could only convince Joris to use CL and McCLIM...
I think it should also be enhanced to be able to generate interfaces that don't cause their users (as opposed to their programmers) cognitive upset. So there ought to be file-choosers that look mostly like other file-choosers, etc.
Unfortunately, that's a lot of gadgetage to be written.
Yeah, but that's the fairly easy part. Anyone who has a week or so of time to spend could do that.
A simple step that could be taken would be to put bits of the spec into the documentation strings. I don't have the appetite for that level of cut-and-paste drudgery, though :-/
Also, see my previous message. Sometimes there is not a very immediate association between code and spec text.
As far as ironing out bugs and limitations in the spec, we probably need to have a real project owner to make that feasible. Which takes us back to Christophe's original question. ;-)
It is a totally different project in my opinion. To improve the current code, the owner needs to know both the spec and the code. To improve the spec, only a limited amount of knowledge of the code is required.
Robert Strandh writes:
It is a totally different project in my opinion. To improve the current code, the owner needs to know both the spec and the code. To improve the spec, only a limited amount of knowledge of the code is required.
could you please say more about which particular aspects of mcclim need to be improved in what ways ?
what is the list of the current 5 top problems that would benefit from large architectural changes ?
(i've only started listening in on this mailing list recently...)
kr kr@n-a-n-o.com writes:
Robert Strandh writes:
It is a totally different project in my opinion. To improve the current code, the owner needs to know both the spec and the code. To improve the spec, only a limited amount of knowledge of the code is required.
could you please say more about which particular aspects of mcclim need to be improved in what ways ?
I am not a McCLIM implementor and I don't know the details of architectural changes. As a user, I would like a fully working ACCEPTING-VALUES, with real gadget views and :OWN-WINDOW t (i.e. for creating dialogs). I would also appreciate improvements to the PostScript backend, more specifically better management of page margins (in most cases the output is cropped at the margins).
Paolo
On Friday, August 12, 2005, at 07:37 am, kr wrote:
Robert Strandh writes:
It is a totally different project in my opinion. To improve the current code, the owner needs to know both the spec and the code. To improve the spec, only a limited amount of knowledge of the code is required.
could you please say more about which particular aspects of mcclim need to be improved in what ways ?
In terms of documentation I think deviations (which probably are _not_ gratuitous!) from the spec, fixes for vendor compatability and general documentation of extensions / extensions wanted would be useful.
what is the list of the current 5 top problems that would benefit from large architectural changes ?
Personally I'd like to see more structure in the organisation of the code (though this is quite superficial). I'd like to see a directory hierarchy for the code, many source files split apart (I hate long source files but maybe that's just me). I'd also like to see finer-grained packages (e.g. geometry functionality defined in :mcclim-geometry, drawing functionality in :mcclim-graphics, etc. etc.). These changes are pretty trivial.
I'd like to revisit the silica functionality; in particular, setting up transformations for sheets with a vertical dimension > 2^16 (which currently seems written specifically for CLX). I'd like some of the X restrictions removed from the code (I forget even where they are now, but I'm pretty sure there's code in the 'core' of McCLIM to restrict ellipses to rectilinear transforms only, for example).
I'm pretty sure there's a threading bug somewhere which doesn't show up under CLX due to (I think) the asynchronous nature of the X protocol (though this is perhaps more likely to be specific to Beagle - I need to do more investigation). Of course, if CLX isn't asynchronous I'm deluding myself...
I'd like to see a 'proper' test suite, just in case.
I'd like to see the menu code use CLIM menus (menu-choose-from-drawer etc.) which I don't think they do at the moment.
On the whole, I don't think many 'large architectural changes' are necessary. Most functionality seems to be present but there are corner cases that need to be investigated. Of course, more back ends might be good, along with extensions (going back to an earlier discussion regarding bezier path rendering, there's an implementation of this in the DUIM sources which looks like it would be quite straightforward to port into McCLIM). Output to PDF would be more useful to me than output to PostScript.
There's probably a bunch of performance improvements that could be made (spatial-tree based output records spring to mind).
I think generally the code just needs some polish and a LOT of documentation. Somebody maybe wants to pick up the QA task in earnest (I always planned to do this but don't really have time at the moment; anyway, Beagle is far from finished).
At the moment I'm looking at porting DUIM from Dylan to CL so if that goes anywhere there's likely to be opportunities for cross-pollination between McCLIM and DUIM (though how much overlap there will be in reality is not clear; probably not that much).
Just my tuppenny worth; all of which are on my todo-list, time permitting.
-Duncan
(i've only started listening in on this mailing list recently...)
-- regards markus krummenacker
mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Duncan Rose duncan@robotcat.demon.co.uk writes:
I'd like to see a 'proper' test suite, just in case.
By the what, what does a GUI test suite look like?
Paolo
--- Paolo Amoroso amoroso@mclink.it wrote:
By the what, what does a GUI test suite look like?
Hmm, interesting question actually! The only ones I can recall seeing usually seem to test if something is displayed properly by running through a bunch of "test" applications and watching for errors reported, or don't do anything automatically but consist of demo programs which are intended to exercise parts of the code.
More interesting might be to store pixmaps or vector descriptions of correctly rendered test windows/apps, compare internally an internally rendered bitmap to the stored "correct" version, and see if there is any difference. Advantages: doesn't need to display anything onscreen, and thus doesn't need a graphical desktop to do "real" testing. Disadvantages: space intensive and rather difficult to code.
Much of the code could probably use ordinary unit testing, the challenge would be ones where the output of interest is graphical. Nifty to think about.
Cheers, CY
____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
On Friday, August 12, 2005, at 08:31 pm, Paolo Amoroso wrote:
Duncan Rose duncan@robotcat.demon.co.uk writes:
I'd like to see a 'proper' test suite, just in case.
By the what, what does a GUI test suite look like?
This is what the Functional Developer DUIM one looks like:
http://www.gwydiondylan.org/images/duim-gui-tests-hd12.png
This isn't a million miles away from what we have for McCLIM already, but is more complete.
Note that the DUIM source tree also contains 'unit' tests, which include (as far as I know, I will investigate further) examples where specific windowing calls are redefined so that at least it's possible to say 'up to this point the functionality is correct' even though that might not lead directly to fully-working code.
Testing GUI apps is always a pain; there are testing utilities available (generally they record input events, then replay them as necessary and compare the results) but I haven't seen a good general purpose cross-platform one.
-Duncan
Paolo
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
kr writes:
Robert Strandh writes:
It is a totally different project in my opinion. To improve the current code, the owner needs to know both the spec and the code. To improve the spec, only a limited amount of knowledge of the code is required.
could you please say more about which particular aspects of mcclim need to be improved in what ways ?
what is the list of the current 5 top problems that would benefit from large architectural changes ?
(i've only started listening in on this mailing list recently...)
That list is going to have to be fairly vague at the moment, because I haven't figured out in detail what the problem is:
* in several places, implementation of some part of the spec uses internal classes and/or methods that are not part of the spec in such a way that it is impossible for the user to create a spec-conforming extension that will work with this implementation. An example (until Tim Moore fixed it, though the fix seems to have some problems) was the fact the output recording protocol required a particular slot in the output record, that is not part of the spec. Thus writing your own output record was impossible.
* I have reasons to believe that the space-requirement protocol is wrong in places, but this is admittedly vague.
* there are definitely some problems with sheet transformations in combination with output recording. If you have a sheet transformation in place then the output records will end up in the wrong place.
* output recording, despite improvements by Gilbert Baumann and Tim Moore is still not good enough with respect to performance. A tree-structured output record is necessary.
That's only four points, but the first one is probably true in several different parts of McCLIM.
Hope this helps.
Robert Strandh writes:
kr writes:
could you please say more about which particular aspects of mcclim need to be improved in what ways ?
what is the list of the current 5 top problems that would benefit from large architectural changes ?
(i've only started listening in on this mailing list recently...)
That list is going to have to be fairly vague at the moment, because I haven't figured out in detail what the problem is:
- in several places, implementation of some part of the spec uses internal classes and/or methods that are not part of the spec in such a way that it is impossible for the user to create a spec-conforming extension that will work with this implementation.
As a very typical example, see my previous message where the implementation of incremental redisplay assumes that output records are regions, which is not the case according to the spec, although it is the case with the McCLIM built-in output records. So, things work as long as only the built-in output record classes are used, but no longer do when client code defines new output records that are not regions.
kr writes:
could you please say more about which particular aspects of mcclim need to be improved in what ways ?
what is the list of the current 5 top problems that would benefit from large architectural changes ?
(i've only started listening in on this mailing list recently...)
If you are thinking of taking on a chunk of McCLIM please let us know, and we will be happy to give you advice and encouragement.
On Aug 9, 2005, at 9:28 PM, rpgoldman@real-time.com wrote:
I'm afraid that hasn't really been my experience. I can often crash McCLIM when I do something that upsets its processing of ACCEPT, in particular, and updating output seems to work very, very badly with scrolling panes, so badly that I can't think of a single interaction which hasn't required me to iconify and de-iconify the frame to make it repaint reasonably. And usually I have to resize the frame by hand in the process. This seems to me to be pretty far from usable.
I'm not necessarily disagreeing about the state of accept (more accurately input editing) and incremental redisplay, but I'm having some trouble searching through the mail archives for specific complaints. In particular I have not noticed problems with scrolling and updating-output in my use of it. Do you mind (re)posting some specific bugs?
Thanks a lot, Tim
"TM" == Timothy Moore moore@bricoworks.com writes:
TM> On Aug 9, 2005, at 9:28 PM, rpgoldman@real-time.com wrote: >> I'm afraid that hasn't really been my experience. I can often crash >> McCLIM when I do something that upsets its processing of ACCEPT, in >> particular, and updating output seems to work very, very badly with >> scrolling panes, so badly that I can't think of a single interaction >> which hasn't required me to iconify and de-iconify the frame to make >> it repaint reasonably. And usually I have to resize the frame by hand >> in the process. This seems to me to be pretty far from usable. TM> I'm not necessarily disagreeing about the state of accept (more TM> accurately input editing) and incremental redisplay, but I'm having TM> some trouble searching through the mail archives for specific TM> complaints. In particular I have not noticed problems with scrolling TM> and updating-output in my use of it. Do you mind (re)posting some TM> specific bugs?
Tim, sorry to have taken so long to get back to you. Rereading your email, I see that I have misled you. I was referring above to two *separate* problems. I.e., (1) I have found it very easy to toss my McCLIM app into the debugger by typing a bad character in the middle of ACCEPTing arguments and (2) I have frequently had trouble with updating output that has left me with a small subset of a scrolling window redrawn, and with the rest of that window a blank, gray area.
I'm not sure that (1) is a bug, per se. It's not that ACCEPT ever returns a bad value, it's just that it is not robust to getting bad input. I would have thought that ACCEPT should by default trap the INPUT-NOT-OF-REQUIRED-TYPE. As a programmer, I don't see how I can do this, if ACCEPT doesn't. I.e., when I write a define-<foo>-command form, it's internal CLIM stuff that handles getting the arguments for me, and if I type something wrong, I'd rather not have the application dumped into the debugger. So shouldn't that command processing exit somewhat gracefully by default?
Similarly, as I mentioned earlier, it would be nice if one could use the ABORT gesture in the middle of ACCEPT and have something good happen. Seems like if I type something bad and can't fix it in input-editing, I'm just doomed to complete the interaction, and then have the command fail into the debugger. I looked into this a little, and it seemed like there was no place in the %ACCEPT code that looked for an ABORT gesture, but the bottom layers of McCLIM are pretty mysterious to me. Is this a GOATEE thing, or should it be handle by %ACCEPT or ACCEPT-FROM-STREAM? If you can give me a pointer, I'd be happy to try to fix it myself.
Best, R
Hi
On Mon, Aug 22, 2005 at 12:10:45PM -0500, Robert P. Goldman wrote:
Similarly, as I mentioned earlier, it would be nice if one could use the ABORT gesture in the middle of ACCEPT and have something good happen. Seems like if I type something bad and can't fix it in input-editing, I'm just doomed to complete the interaction, and then have the command fail into the debugger. I looked into this a little, and it seemed like there was no place in the %ACCEPT code that looked for an ABORT gesture, but the bottom layers of McCLIM are pretty mysterious to me. Is this a GOATEE thing, or should it be handle by %ACCEPT or ACCEPT-FROM-STREAM? If you can give me a pointer, I'd be happy to try to fix it myself.
Some minutes after you seemed to have left the channel I posted a patch for you. Basically it is just adding (handler-bind ((abort-gesture #'abort)) in the beginning of ACCEPT in presentation-defs.lisp. That seems to be okay.
ABORT-GESTURE is the condition that is signaled when any of the gestures in *ABORT-GESTURES* is read (in STREAM-READ-GESTURE). Right now *ABORT-GESTURES* contains only :abort on mcclim, which is a the keyboard gesture (#\c :control) (on Genera it contains #\Abort, the ABORT-key).
I do not find explicitly in the clim specification that an accept should be aborted on any abort-gesture, but it seems to be the right thing.
I did short tests with ACCEPTING-VALUES and it seems to behave correctly with this patch, i.e. the whole dialog will be aborted. Or would it be better if only the editing of the single input-gadget is aborted?
Also Genera CLIM and Dynamic Windows behave in the same way, although one gets thrown into the debugger if one presses ABORT during editing a text-field of an CLIM:ACCEPTING-VALUES dialog... This does not happen with McCLIM and this patch.
If noone complains I'll apply it to the repository.
Regards, Max
MGR> Hi
MGR> On Mon, Aug 22, 2005 at 12:10:45PM -0500, Robert P. Goldman wrote: >> Similarly, as I mentioned earlier, it would be nice if one could use >> the ABORT gesture in the middle of ACCEPT and have something good >> happen. Seems like if I type something bad and can't fix it in >> input-editing, I'm just doomed to complete the interaction, and then >> have the command fail into the debugger.
[...snip...]
MGR> Some minutes after you seemed to have left the channel I MGR> posted a patch for you. Basically it is just adding MGR> (handler-bind ((abort-gesture #'abort)) in the beginning of MGR> ACCEPT in presentation-defs.lisp. That seems to be okay.
MGR> ABORT-GESTURE is the condition that is signaled when any of the MGR> gestures in *ABORT-GESTURES* is read (in STREAM-READ-GESTURE). Right MGR> now *ABORT-GESTURES* contains only :abort on mcclim, which is a the MGR> keyboard gesture (#\c :control) (on Genera it contains #\Abort, the MGR> ABORT-key).
MGR> I do not find explicitly in the clim specification that an MGR> accept should be aborted on any abort-gesture, but it seems MGR> to be the right thing.
MGR> I did short tests with ACCEPTING-VALUES and it seems to MGR> behave correctly with this patch, i.e. the whole dialog will MGR> be aborted. Or would it be better if only the editing of the MGR> single input-gadget is aborted?
MGR> Also Genera CLIM and Dynamic Windows behave in the same way, although MGR> one gets thrown into the debugger if one presses ABORT during editing MGR> a text-field of an CLIM:ACCEPTING-VALUES dialog... This does not MGR> happen with McCLIM and this patch.
MGR> If noone complains I'll apply it to the repository.
Has anyone squawked? If not, how please do apply it.
Best, R
Hello
On Thu, Aug 25, 2005 at 09:47:35AM -0500, rpgoldman@real-time.com wrote:
MGR> Basically it is just adding MGR> (handler-bind ((abort-gesture #'abort)) in the beginning of MGR> ACCEPT in presentation-defs.lisp. That seems to be okay. MGR> If noone complains I'll apply it to the repository.Has anyone squawked? If not, how please do apply it.
I've just done that. See: http://common-lisp.net/pipermail/mcclim-cvs/2005-August/000297.html
Sorry for the delay, at least everybody have had some time to complain or improve the patch already. :)
Bye, Max
-
Andy Hefner -
C Y -
Christophe Rhodes -
David Murray -
Duncan Rose -
kr -
Max-Gerd Retzlaff -
Paolo Amoroso -
Robert P. Goldman -
Robert Strandh -
rpgoldman＠real-time.com -
Timothy Moore