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?
I think one also should look whether the implemented facilities are usable (look and feel also) and correctly drawn.
Are the implemented gadgets working?
How about menus, choices, accepting values dialogs, etc?
Is incremental updating working?
Is there enough error checking and reporting in define-application- frame? This macro created great frustrations among CLIM users (buggy, poor error checking, non-obvious effects, poor overall robustness). Make mistake and you had to restart the App, or the whole Lisp. I'm not saying that McCLIN has these problems, but it should checked.
Am 15.01.2008 um 23:28 schrieb Troels Henriksen athas@sigkill.dk:
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 _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Rainer Joswig joswig@lisp.de writes:
I think one also should look whether the implemented facilities are usable (look and feel also) and correctly drawn.
While look & feel is obviously important for a GUI programming toolkit, I think the focus for a 2.0 release should be on spec compliance, with look & feel being a secondary goal to be worked on once it's clear that a full spec implementation has been reached (or is close).
Are the implemented gadgets working?
How about menus, choices, accepting values dialogs, etc?
Is incremental updating working?
These are all instances of "do we implement the spec?" (The answer is no for some of those.) I've heard that incremental output, as described in the spec, is not feasible to implement, does anyone have knowledge about that? Otherwise, my experience is that it works pretty well.
Is there enough error checking and reporting in define-application- frame? This macro created great frustrations among CLIM users (buggy, poor error checking, non-obvious effects, poor overall robustness). Make mistake and you had to restart the App, or the whole Lisp. I'm not saying that McCLIN has these problems, but it should checked.
The biggest problem with define-application-frame is that it has confusing semantics and a lot of different ways to express similar things. We can't really change this, as it's demanded by the spec (right?), but perhaps we could emit some warnings for common errors. In any case, that is secondary to making sure it works as specified.
Troels Henriksen wrote:
Rainer Joswig joswig@lisp.de writes:
I think one also should look whether the implemented facilities are usable (look and feel also) and correctly drawn.
While look & feel is obviously important for a GUI programming toolkit, I think the focus for a 2.0 release should be on spec compliance, with look & feel being a secondary goal to be worked on once it's clear that a full spec implementation has been reached (or is close).
Are the implemented gadgets working?
How about menus, choices, accepting values dialogs, etc?
Is incremental updating working?
These are all instances of "do we implement the spec?" (The answer is no for some of those.) I've heard that incremental output, as described in the spec, is not feasible to implement, does anyone have knowledge about that? Otherwise, my experience is that it works pretty well.
Does accepting-values and input editing work now? The last time I checked, it didn't work for commands that took multiple arguments. If I remember correctly, when I changed only one value from the default, it looked like McCLIM would cycle through all of the other fields, and I could never get the process to terminate correctly. I encountered this building a GUI for a program that takes a very large number of keyword arguments to tailor its behavior. I will try to test this again, but fear that because of other commitments, won't be able to do it until after the end of January. Does anyone else have a McCLIM program with commands with several arguments?
I will try to see if I still have a copy of a program that used this --- I may have ripped it all out and done some messy kludge of n commands to replace it....
Troels Henriksen writes:
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 think this is a laudable goal, and even if it doesn't happen, having this goal might make progress faster in 2008.
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:
The more general problem I see is that whenever I feel like working on some feature of McCLIM, I feel stymied because of the lack of maintainability of McCLIM.
For that reason, I think an effort like this should start with some preventive maintenance activities such as:
* Remove commented-out code, or uncomment it.
* Add signed-and-dated comments to difficult passages whenever reasonable.
* Make sure McCLIM compiles with as few warnings as possible
* Add references to the spec for code that implements some required functionality.
* [and probably some more things that I can't think of right now]
* 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?
It is hard to tell what is missing because some parts of the spec are optional, such as color blending for instance.
Also, color blending would be easy to implement if we had a backend such as the one I started a while back that would use a single CLX window as a frame buffer.
But it might not be highest priority to implement all of the spec. I would say it is more urgent to make the parts that are currently implemented work according to the spec. I am thinking of things like output-record inheriting from standard-rectangle and then assuming all output records do so.
* 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.
Sounds good.
* 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.
Again, this sounds good, but that's partly because whether this is reasonable or not depends on what (if any) such extensions are selected.
* 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.
I think we should have at least one backend that uses a single mirrored sheet (the graft, I suppose), so that we can test unusual sheet transformations and such. The X-window-as-frame-buffer backend I suggested above would do that, but perhaps Gtkairo will as well.
* 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.
I am starting to think that docstrings are evil (because they are mostly noise to the person reading the code). I would like to discuss the possibility of using (SETF DOCUMENTATION) instead.
The following is what is NOT necessary for a McCLIM 2.0 release:
* More than one fully working backend.
See above. The CLX backend might not be good enough for testing everything we would like.
* Documentation covering CLIM itself. The spec will have to do for now.
What do you mean by this?
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.
Sounds like a good suggestion to me.
Robert Strandh strandh@labri.fr writes:
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:
The more general problem I see is that whenever I feel like working on some feature of McCLIM, I feel stymied because of the lack of maintainability of McCLIM.
I don't think it's that bad, to be honest. McCLIM doesn't do too many obscure things, except that a newcomer may be confused about where exactly events are read (I certainly was).
- Remove commented-out code, or uncomment it.
Definitely, I heavily dislike commented-out code.
- Add signed-and-dated comments to difficult passages whenever reasonable.
I'm not sure I like this. I much prefer relying on the version control system to provide me with this kind of information.
- Make sure McCLIM compiles with as few warnings as possible
This is a no-brainer, and I already did some work on it back in November, I think. Most of the remaining warnings are missing defgenerics, which is a lot of work, but not hard at all.
- Add references to the spec for code that implements some required functionality.
Isn't this reference just the name of the function in question?
It is hard to tell what is missing because some parts of the spec are optional, such as color blending for instance.
I don't think it is necessary for us to implement all optional parts before a stable release.
But it might not be highest priority to implement all of the spec. I would say it is more urgent to make the parts that are currently implemented work according to the spec. I am thinking of things like output-record inheriting from standard-rectangle and then assuming all output records do so.
I think it's very important to have a full implementation of the non-optional parts of the spec in a stable release, otherwise it has no meaning.
Again, this sounds good, but that's partly because whether this is reasonable or not depends on what (if any) such extensions are selected.
I think MCCLIM-IMAGES should at least be selected, because it's useful and somewhat simple. I don't know what else. Perhaps Freetype should stop being Experimental and become an Extension?
I think we should have at least one backend that uses a single mirrored sheet (the graft, I suppose), so that we can test unusual sheet transformations and such. The X-window-as-frame-buffer backend I suggested above would do that, but perhaps Gtkairo will as well.
This is mostly related to testing, not to actual use. Thus, while it would be useful, I don't think it is critically important to a stable McCLIM release.
* 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.I am starting to think that docstrings are evil (because they are mostly noise to the person reading the code). I would like to discuss the possibility of using (SETF DOCUMENTATION) instead.
I think they are just as useful as comments to the person reading the code. I'm not a fan of (SETF DOCUMENTATION), as it separates the documentation from the code, making it easier for the two to get out of sync.
* Documentation covering CLIM itself. The spec will have to do for now.What do you mean by this?
I don't like the CLIM spec too much, and I would like to revise it into something that is more usable. This would probably involve more examples and descriptions of how the functions actually behave in McCLIM (the spec is sometimes unclear or nonsensical).
Troels Henriksen athas@sigkill.dk writes:
Robert Strandh strandh@labri.fr writes:
I am starting to think that docstrings are evil (because they are mostly noise to the person reading the code). I would like to discuss the possibility of using (SETF DOCUMENTATION) instead.
I think they are just as useful as comments to the person reading the code. I'm not a fan of (SETF DOCUMENTATION), as it separates the documentation from the code, making it easier for the two to get out of sync.
Optimally, documentation and test cases should be coupled to catch against this. It's on my todo list of Editor-hints to think and experiment in this area.
(If a reader of this list has got some ideas he'd like to share, I'd like to ask him to subscribe to gmane.lisp.editors.hints.devel, or the respective common-lisp.net mailinglist such that his opinions get archived at the right place.)
-T.
Troels Henriksen wrote:
Robert Strandh strandh@labri.fr writes:
* 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.I am starting to think that docstrings are evil (because they are mostly noise to the person reading the code). I would like to discuss the possibility of using (SETF DOCUMENTATION) instead.
I think they are just as useful as comments to the person reading the code. I'm not a fan of (SETF DOCUMENTATION), as it separates the documentation from the code, making it easier for the two to get out of sync.
I'd suggest that having docstrings in defgenerics is benign, because they don't push meaningful code off the screen (assuming one doesn't use :method). That would tend to confine the objections to documentation strings to ones that attach to method definitions and function definitions. In that case, one could put a (setf documentation) right after the definition in question, so that they wouldn't float away from the code, but wouldn't push the lambda list away from the body of the definition. I assume that, the way they are placed, below the slot definitions, documentation strings for defclass are benign.
Would that be a reasonable compromise?
Robert Goldman rpgoldman@sift.info writes:
I'd suggest that having docstrings in defgenerics is benign, because they don't push meaningful code off the screen (assuming one doesn't use :method). That would tend to confine the objections to documentation strings to ones that attach to method definitions and function definitions. In that case, one could put a (setf documentation) right after the definition in question, so that they wouldn't float away from the code, but wouldn't push the lambda list away from the body of the definition. I assume that, the way they are placed, below the slot definitions, documentation strings for defclass are benign.
Would that be a reasonable compromise?
I could live with that. Also because the majority of the interesting docstrings live in defgenerics and defclasses, anyway.
Troels Henriksen writes:
- Add signed-and-dated comments to difficult passages whenever reasonable.
I'm not sure I like this. I much prefer relying on the version control system to provide me with this kind of information.
Although I agree that the information about who wrote a comment and when is indeed available through the version control system, it is not necessarily very convenient to get to. Either way, my remark was more about the comment itself than about the signature and date.
- Add references to the spec for code that implements some required functionality.
Isn't this reference just the name of the function in question?
No, because unless you know all functions in the spec by heart, you cannot know whether some code is intended to implement such a function, or whether it is a function specific to the way it was implemented. The reference to the spec could take the form of a section number. There is something like that in regions.lisp.
It is hard to tell what is missing because some parts of the spec are optional, such as color blending for instance.
I don't think it is necessary for us to implement all optional parts before a stable release.
I agree, but we must decide what optional parts should be included.
But it might not be highest priority to implement all of the spec. I would say it is more urgent to make the parts that are currently implemented work according to the spec. I am thinking of things like output-record inheriting from standard-rectangle and then assuming all output records do so.
I think it's very important to have a full implementation of the non-optional parts of the spec in a stable release, otherwise it has no meaning.
Of course, but I think the easiest way to get there is to make sure the parts we have work first of all.
Robert Strandh strandh@labri.fr writes:
No, because unless you know all functions in the spec by heart, you cannot know whether some code is intended to implement such a function, or whether it is a function specific to the way it was implemented. The reference to the spec could take the form of a section number. There is something like that in regions.lisp.
Yes, I see how this would be useful.
I agree, but we must decide what optional parts should be included.
How about anything that is currently implemented? Which parts of the spec are optional? I know about general designs, but what else?
Of course, but I think the easiest way to get there is to make sure the parts we have work first of all.
Fortunately, I think most of them do. McCLIM isn't as bad as its reputation with respect to stability and compliance, the issues I know of are certainly fairly obscure.
Troels Henriksen writes:
I think they are just as useful as comments to the person reading the code. I'm not a fan of (SETF DOCUMENTATION), as it separates the documentation from the code, making it easier for the two to get out of sync.
I would agree for projects where the spec evolves rapidly and the code with it. For projects with a relatively stable spec like CLIM or CL itself, I find the docstrings distracting. I mean, if you read the code for CAR, do you really find it useful to see the docstring?
Robert Strandh strandh@labri.fr writes:
I mean, if you read the code for CAR, do you really find it useful to see the docstring?
No, but it is useful for, say, CLIM:ACCEPT with its seventeen keyword parameters, or the insanely complex CLIM:DEFINE-APPLICATION-FRAME macro that seemingly no-one fully understands.
On Jan 17, 2008 3:37 PM, Troels Henriksen athas@sigkill.dk wrote:
Robert Strandh strandh@labri.fr writes:
I mean, if you read the code for CAR, do you really find it useful to see the docstring?
No, but it is useful for, say, CLIM:ACCEPT with its seventeen keyword parameters, or the insanely complex CLIM:DEFINE-APPLICATION-FRAME macro that seemingly no-one fully understands.
How about someone putting together a quick hide/show-docstring[s] command. That way the comments are physically attached but need not take up screen space.
JQS
Am 17.01.2008 um 08:27 schrieb Robert Strandh:
I am starting to think that docstrings are evil (because they are mostly noise to the person reading the code). I would like to discuss the possibility of using (SETF DOCUMENTATION) instead.
Doc strings are for users of those functions/macros. It helps me to understand what the function does, how I call it, what results I get back and so on. I really like that feature.
If for some code the documentation string gets in he way, using (SETF DOCUMENTATION) is absolutely fine.
Troels Henriksen athas@sigkill.dk writes:
* 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?
I added a page on the McCLIM Wiki - http://mcclim.cliki.net/Implementation%20Status - listing the implementation status for the various parts of the spec. If you *know* that we implement some part of the spec (and you're *really* sure), please update that page. Alternatively, pick a spec section and rigorously check that we implement every function, macro and keyword, or at least have made a conscious decision not to. There used to be an implementation status list bundled with the older release announcements, but I know of several errors in them for the spec sections I'm familiar with, so I'd rather not base this attempt on them.
-
John Q. Splittist -
Rainer Joswig -
Robert Goldman -
Robert Goldman -
Robert Strandh -
Tobias C. Rittweiler -
Troels Henriksen