I strongly support the suggestion that any extensions to ABCL be provided as a separate package. An acceptable alternative would be to change the name of any extended versions to something that won’t be confused with the “Official” ABCL. I’ve used ABCL as a front-end to some large Java applications and I don’t want to have any confusion about whether I’m using the official version or something else. A version "that is mostly backwards-compatible” isn’t going to cut it.
On Aug 25, 2015, at 11:55 , Blake McBride blake@mcbride.name wrote:
Great! Thanks!
Notwithstanding the successful ANSI tests, Lisp issues will invariably arise as it does with all other Lisp implementations. I therefore suggest that you keep all non-ANSI Lisp features or additions in a separate and optional package. Otherwise, I can't imaging anything you can add that wouldn't render ABCL no longer Common Lisp.
I really appreciate the fresh ABCL blood! Thank you! I feel the other ABCL maintainers may have some good input into your additions. The necessity of the fork is sad.
Blake McBride
On Mon, Aug 24, 2015 at 11:54 PM, Ralph Ritoch <rritoch@gmail.com mailto:rritoch@gmail.com> wrote: Hello,
I have been able to get ABCL to pass all of the ansi conformance tests. While this is not an official ABCL release, all of the modifications I made are released under the MIT license and may be freely integrated into ABCL at the discretion of the maintainers.
To embed this conforming version into your java applications add the following dependencies which have been released at maven central.
<dependency> <groupId>com.vnetpublishing.lisp</groupId> <artifactId>jrelisp-abcl-impl</artifactId> <version>0.0.2</version> </dependency> <dependency> <groupId>com.vnetpublishing.lisp</groupId> <artifactId>jrelisp-abcl-contrib</artifactId> <version>0.0.2</version> </dependency>The source code for this release can be found at https://github.com/rritoch/jrelisp-abcl/tree/55e808d3c0084d16d1ed04c36a6f5a5... https://github.com/rritoch/jrelisp-abcl/tree/55e808d3c0084d16d1ed04c36a6f5a5ecad4de08 .
While I have moved some files around it is still an ABCL implementation that is mostly backwards-compatible with the official ABCL releases.
Moving forward it is likely that any future development on these branches will further deviate from ABCL. I am not claiming that this solves EVERY compliance issue but I have found solutions for each of the ansi conformance test failures. Any remaining compliance issues can be considered a bug. My primary intention of passing every test is to lock the build process so that builds will fail if any of the ansi tests fail.
It is unlikely that future modifications to these forks will have any relevance to ABCL. I will likely continue developing features that are needed for modern application development and therefore are of little interest to some, if not all, of the ABCL maintainers. That being said, v0.0.2 is the best release to source conformance solutions from for ABCL as it passes every conformance test. Any future releases will no longer be based on improving ABCL but be for the purpose of better supporting modern application development.
Best Regards, Ralph Ritoch