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

[C Y]

--- Robert Strandh <strandh at 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