"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...