just my .02EU to this discussion.
I have not hacked ABCL at all, but I have a vested interest in seeing
it working well: it is the choice system we will be using to integrate
CL in our Moodle platform for teaching.
On Aug 12, 2008, at 15:39 , Erik Huelsmann wrote:
> Well, it seems there are a number of decisions which need taking. I'll
> put my position forward on each of them below; if you don't agree,
> that's fine, however you'll need to speak up for me to know :-)
> * Minimal supported Java version
> Since J2SE 1.5.0 was released 4 years ago next month, I propose to
> use that as the minimal version
It is ok with me, however, Java 6 is not much of a change from 5 and
that is the stable version now. As per Java 7, it does not seem quite
> * Annotations (@... codes such as @Override)
> I mainly use the NetBeans IDE for development, which complains
> about these missing.
> Since I do see some value in having them, my general idea is they
> should be inserted.
I have no opinion on these.
> * Code compilation (warnings)
> Generally, all code - if possible - should compile without warnings.
> This means that the interpreter will need to be patched in 64
> locations to eliminate the "unchecked" warnings
I agree, however, maybe some of these could go away by expanding
> * ANSI compliance
> In general, patches should increase ANSI compliance, or have no
> impact on it at all (monotonically non-decreasing)
> The way to test this is by using pfdietz's CL ANSI compliance test
> suite, just like ECL (and possibly SBCL) does.
> I mailed pfdietz asking him where the test suite is currently being
P.F.Dietz's test suite is currently the canon. Getting it to run and
tracking it should be a top priority.
> * Releases
> I'm a strong proponent for doing releases, preferably regularly.
A like releases as well, but they do require quite some time to set
up. I'll leave this decision to you.
> * Binary availability
> If at all possible - and I think it is - we should distribute a JAR
> file generated from official releases,
> so people can replace their existing jar with the newer one.
> * Backward compatibility
> If possible, releases should be backward compatible. When not, this
> should be explicitly mentioned.
This is a worthy goal. I think that this would impact mostly the
interaction with the JVM and the Java environment.
> Next to these decisions, there's the question: Does ABCL belong on
> common-lisp.net instead of on SourceForge? Both SBCL and ECL also have
> their repositories on common-lisp.net, even though they have their
> mailing lists and binaries on SF.
The move to common-lisp.net would be welcome. I like the one stop-
shop place for CL projects.