[mcclim-devel] McCLIM 2.0 in 2008

[Robert Strandh]

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

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------