<div dir="ltr">That's a great result! Congrats!<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 25, 2015 at 6:54 AM, Ralph Ritoch <span dir="ltr"><<a href="mailto:rritoch@gmail.com" target="_blank">rritoch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>Hello,<br><br></div>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.<br><br></div>To embed this conforming version into your java applications add the following dependencies which have been released at maven central.<br><br>        <dependency><br>            <groupId>com.vnetpublishing.lisp</groupId><br>            <artifactId>jrelisp-abcl-impl</artifactId><br>            <version>0.0.2</version><br>        </dependency><br><br>        <dependency>  <br>            <groupId>com.vnetpublishing.lisp</groupId><br>            <artifactId>jrelisp-abcl-contrib</artifactId><br>            <version>0.0.2</version><br>        </dependency><br><br></div>The source code for this release can be found at <a href="https://github.com/rritoch/jrelisp-abcl/tree/55e808d3c0084d16d1ed04c36a6f5a5ecad4de08" target="_blank">https://github.com/rritoch/jrelisp-abcl/tree/55e808d3c0084d16d1ed04c36a6f5a5ecad4de08</a> .<br><br></div>While I have moved some files around it is still an ABCL implementation that is mostly backwards-compatible with the official ABCL releases.<br><br></div>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.<br></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.</div></div></div></blockquote><div><br></div><div>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?)</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div>
</div></div>