All conformance ansi-test's passed

[Erik Huelsmann]

That's a great result! Congrats!

On Tue, Aug 25, 2015 at 6:54 AM, Ralph Ritoch <rritoch at 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/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.
>

Ok. But did you now support the single case of MAKE-ARRAY with a complex
type that the ansi tests are testing? Or did you implement full complex
type support? The reason I ask is because the above suggests that I
*didn't* say on IRC that we could have fixed that test years ago the same
way you did, since your solution doesn't solve the *class* of problems the
ansi tests are testing for. We opted not to fix the failure untill the
*class* of problems was fixed.

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

Ok. As Peter asked, I'd like to plea for a clear separation between the
ABCL code base and enhancements, if possible, but if not, that there's a
clear naming distinction between the canonical ABCL code base and the one
with your modifications. (I think you already said that you'll use the name
jrelisp?)

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150826/3e558d89/attachment-0001.html>