This "idiot" refactored a very small portion of your code making it MUCH faster, and also passed more than 90% of the tests ABCL is currently failing, leaving only 3 ansi-tests that are still failing. If I'm an idiot it doesn't say much about you since you've been working on this for years and I've only been working on it for weeks.
Best Regards, Ralph Ritoch
On Mon, Aug 17, 2015 at 8:00 PM, armedbear-devel-request@common-lisp.net wrote:
Send armedbear-devel mailing list submissions to armedbear-devel@common-lisp.net
To subscribe or unsubscribe via the World Wide Web, visit https://mailman.common-lisp.net/listinfo/armedbear-devel or, via email, send a message with subject or body 'help' to armedbear-devel-request@common-lisp.net
You can reach the person managing the list at armedbear-devel-owner@common-lisp.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of armedbear-devel digest..."
Today's Topics:
- Re: Lisp filepath issues when running application directly from jar file (Mark Evenson)
Message: 1 Date: Sun, 16 Aug 2015 14:38:44 +0200 From: Mark Evenson evenson@panix.com To: Armed Bear armedbear-devel@common-lisp.net Subject: Re: Lisp filepath issues when running application directly from jar file Message-ID: 5616917D-F789-4F95-93E2-FC3B7633B051@panix.com Content-Type: text/plain; charset="utf-8"
On Aug 16, 2015, at 02:34, Ralph Ritoch rritoch@gmail.com wrote:
I have used this function in my code without ANY problems. [?]
The SYSTEM package is not intended to be used by users unless there is no alternative. The manual states clearly that functionality provided by SYSTEM is subject to be changed between major releases without warning. Therefore, the argument in this case isn?t that one would have problems using SYSTEM:LOAD-SYSTEM-FILE, but rather that one should use the ANSI interface as implemented CL:LOAD which should be able to load Lisp and/or fasls in all cases needed by the user. My work on EXT:JAR-PATHNAME and EXT:URL-PATHNAME was motivated by precisely the need for CL:LOAD to work in all conceivable cases in the JVM ecology. And the best contemporary mechanism for expression for resolution of and dependency order for CL:LOAD lies in ASDF, hence my emphasis on using its abstraction where extending CL:LOAD is not desirable.
As a side note, over time, we wish to move functions in SYSTEM which useful to the user into the EXTENSION package, but this work is incomplete at best. Currently, there are indeed cases in which using a function from SYSTEM is unavoidable. The use of SYSTEM:LOAD-SYSTEM-FILE is not one of them.
Your attitude regarding "progress" is archaic. If you don't want to
support maven or other java technologies why do you even bother controlling abcl?
Your attitude towards discussion is not only archaic (i.e. immature) but counterproductive towards reaching the sort of consensus needed for progress.
However misguided such an endeavor may be, a couple points follow towards a defense from your sleazy ad hominem ?argumentation?.
As for supporting Maven, I have developed the machinery to use Maven artifacts in ABCL-ASDF, and continued to maintain them (with help from users) even as the lurching horror that comprises Maven release engineering continues to change API semantics between patch level releases. I have offered to collaborate with you on incorporating your initial work on building from Maven, pointing out the problems that I see with your approach to which I have received no reply.
As for supporting ?other technologies?, I suppose you are referring to your attempt to merge abcl-contrib.jar and abcl.jar. In this effort, I pointed out you could do this cleanly with the current code by adding site-specific code to the ?system.lisp? file whose contents are controlled by the Ant build process. Since your Maven build doesn?t use the Ant target to package (one of my explicit criticisms), you presumedly weren?t interested in using this mechanism. I responded twice to your proposal to probe jar files on the classpath for code to pontential load with suggestions which you found too burdensome to discuss so you developed what you needed. Your email announcing this implementation implied you had implemented to a ?specification?, but no such entity existed external to the source code. If you wish to provide such a specification for your current implementation, please do so that others may consider its usefulness.
As to whether I control ABCL, I was going to reply that I am but one maintainer out of five; that you are welcome to convince a majority of the maintainers through useful and accepted contributions that that you should be in ?control? too; and that since the code is GPL?d so you are welcome to get the fork out of here. But at this point, I would reply that if I do somehow ?control? ABCL, I am glad to protect it from idiots like you.
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."