[mcclim-devel] One char patch to presentation-defs

[rpgoldman at real-time.com]

>>>>> "RS" == Robert Strandh <strandh at 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...