I have been wondering about the reception of an independent patch Library for Maple.

I'll lay out a few ideas, and then maybe some criticism (or indifference) might follow.

I'm a bullet-point sort of person:

• sourceforge project with a few willing experts for vetting and gatekeeping of submissions.
• Patch .mla Library archive, going into /toolbox/Patch/lib/ so as to get picked up automatically by libname.
• Self-building, with batch scripts, if copyright prevents redistribution of .mla directly. (Maple itself can do platform independent batch work.)
• Distribute only "diff" files. Scripts extract source from users own installed Maple, apply diffs, and reload into patch Library. (printlevel, writeto, eval, savelib.)
• Distribute something that describes or lists the changes, with examples.
• Version specific diff files.
• Cumulative diffs would preempt allowing pick-and-choose from multiple edits to a single routine. All or nothing.

That's the essence. Of course not all Library routines can be so easily properly extracted to source and validly reloaded. But many can.

If the idea is worth trying, then some Mapleprimes book posts would be one place to start. Tips on handling module-based packages, or routines with remember-table/Cache entries (that get shown upon print) might be nice to have here. Routines which self-modify could also need special handling.

An alternative to source diffs could be something like this "live surgery". I don't know how easily or well that might scale.

A big concern would naturally be that a patch shouldn't break anything. A test suite is needed for that. The minimum would be base tests for the altered routines. Comprehensive test suites take a great deal of resources to author. Without proper testing, patched routines are risky enough to be worthless.

The central goal would be to improve Maple. That should make it a better and more attractive product. If it's not an improvement, then it's not a good idea.

acer