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... .
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
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 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... .
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
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
25.08.2015, 07:54, "Ralph Ritoch" rritoch@gmail.com:
Any future releases will no longer be based on improving ABCL but be for the purpose of better supporting modern application development.
Modern application development?
Could you say several more words about this?
Best regards, - Anton
Anton & Blake,
One example feature that I hope to support is OSGI. Direct support for OSGI will likely cause a significant performance loss. That is why I'm going to do a quick optimization of the entire system before I start working on the new features. I believe OSGI is scheduled to be included in Java 9, along with some new packaging facilities which I also hope to support when I can find adequate documentation on the subject. These are all features that belong in a fork because they can and probably will have a negative impact on the performance of applications that don't need those features. I hope to make these features pluggable eventually, but hard coding them initially is much easier.
Using ant instead of maven is also a limitation I'm not willing to accept. Most of the people I've talked to think I should skip maven and go directly to a gradle build system. Since gradle can utilize maven, maven is adequate for most development needs at this point.
Best Regards, Ralph Ritoch
On Tue, Aug 25, 2015 at 11:59 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
25.08.2015, 07:54, "Ralph Ritoch" rritoch@gmail.com:
Any future releases will no longer be based on improving ABCL but be for
the purpose of better supporting modern application development.
Modern application development?
Could you say several more words about this?
Best regards,
- Anton
Hi all,
On Tue, Aug 25, 2015 at 6:07 PM, Ralph Ritoch rritoch@gmail.com wrote:
Anton & Blake,
One example feature that I hope to support is OSGI. Direct support for OSGI will likely cause a significant performance loss. That is why I'm going to do a quick optimization of the entire system before I start working on the new features. I believe OSGI is scheduled to be included in Java 9, along with some new packaging facilities which I also hope to support when I can find adequate documentation on the subject. These are all features that belong in a fork because they can and probably will have a negative impact on the performance of applications that don't need those features. I hope to make these features pluggable eventually, but hard coding them initially is much easier.
If the intent is to migrate things back to the original project in due time, the open source name for such an effort would be "a remote branch", not a fork. If you are not aware of this difference, you could start naming your repository "a branch". If you *are* aware of the difference (and I think you are, because you already were looking for a different name for your project, judging by the IRC communication), then I can only say it's a pity that you didn't have the patience to go through the process that's customary in open source to get your patches accepted. As an illustration of what I mean there: my first Mercurial patch was accepted yesterday. My initial submission was in May or June. Due to time constraints on my side *and* requirements from theirs, this process simply can take long and becomes more smooth over time.
Using ant instead of maven is also a limitation I'm not willing to accept.
Most of the people I've talked to think I should skip maven and go directly to a gradle build system. Since gradle can utilize maven, maven is adequate for most development needs at this point.
Just for the record I'm taking this to the mailing list, because most of this took place on the mailing list: the project asked to migrate *all* current functionalities to Maven, if you want to deprecate the Ant build, not *just* the ones that are needed to make the ABCL upload into the Maven repository. Our hesitation to accept the Maven based build lies in the fact that we have had two build systems in the past. Out of experience, we can say "It doesn't work". So, claiming we don't want to move forward is simply wrong. We want to do it in a way that doesn't kill half the project's infrastructure. I'm sure people understand that, if presented this way.
Erik,
I have a very specific set of features that I'm trying to produce which don't in any way change the language itself. The end goal is to be able to use ABCL for enterprise applications, such as those that would run using technologies such as Apache Camel, Apache Tomcat, Apache Servicemix, and the Spring framework. I don't intend to allow politics to stand in the way of achieving these capabilities. As for the dual-build system, removing ant scripts isn't a high priority but is something I'm willing to consider once the primary objectives are reached. I am still very far from achieving the primary objectives. No matter what fate this fork has, it is going to break backwards compatibility from the perspective of Java and if this does merge back than it should merge back at a version 2.0 of ABCL. There are also some core issues that I'm wrestling with such as what Java version to bind to. I would very much like to bind to Java 8, as I am now doing, but Android doesn't yet support Java 8 so I am strongly considering binding to Java 7 if I achieve the set goals before Android has support for Java 8. For complete Interoperability with enterprise applications I will also need to change the compilation system to minimally support Java 7 and add features to facilitate the generation of annotations. Spring, Hibernate, JPA, and many other enterprise technologies make extensive use of annotations. While annotations would be a nice feature to support, I have a long way to go before I understand the compilation system enough to upgrade it.
As for renaming the branch, I simply don't like the name "armed bear". It is a marketing issue. Does anyone actually believe IBM, Oracle, or Microsoft would be open to tagging their systems with "Powered by armed bear", I highly doubt it. "Powered by jrelisp" is neutral without no sociopolitical ties and something a fortune 500 company could use without concern for the impact it may have on their PR.
Best Regards, Ralph Ritoch
On Wed, Aug 26, 2015 at 3:28 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi all,
On Tue, Aug 25, 2015 at 6:07 PM, Ralph Ritoch rritoch@gmail.com wrote:
Anton & Blake,
One example feature that I hope to support is OSGI. Direct support for OSGI will likely cause a significant performance loss. That is why I'm going to do a quick optimization of the entire system before I start working on the new features. I believe OSGI is scheduled to be included in Java 9, along with some new packaging facilities which I also hope to support when I can find adequate documentation on the subject. These are all features that belong in a fork because they can and probably will have a negative impact on the performance of applications that don't need those features. I hope to make these features pluggable eventually, but hard coding them initially is much easier.
If the intent is to migrate things back to the original project in due time, the open source name for such an effort would be "a remote branch", not a fork. If you are not aware of this difference, you could start naming your repository "a branch". If you *are* aware of the difference (and I think you are, because you already were looking for a different name for your project, judging by the IRC communication), then I can only say it's a pity that you didn't have the patience to go through the process that's customary in open source to get your patches accepted. As an illustration of what I mean there: my first Mercurial patch was accepted yesterday. My initial submission was in May or June. Due to time constraints on my side *and* requirements from theirs, this process simply can take long and becomes more smooth over time.
Using ant instead of maven is also a limitation I'm not willing to accept.
Most of the people I've talked to think I should skip maven and go directly to a gradle build system. Since gradle can utilize maven, maven is adequate for most development needs at this point.
Just for the record I'm taking this to the mailing list, because most of this took place on the mailing list: the project asked to migrate *all* current functionalities to Maven, if you want to deprecate the Ant build, not *just* the ones that are needed to make the ABCL upload into the Maven repository. Our hesitation to accept the Maven based build lies in the fact that we have had two build systems in the past. Out of experience, we can say "It doesn't work". So, claiming we don't want to move forward is simply wrong. We want to do it in a way that doesn't kill half the project's infrastructure. I'm sure people understand that, if presented this way.
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
That's a great result! Congrats!
On Tue, Aug 25, 2015 at 6:54 AM, Ralph Ritoch 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... .
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?)
armedbear-devel@common-lisp.net
-
Anton Vodonosov -
Blake McBride -
Erik Huelsmann -
Peter Olsen -
Ralph Ritoch