<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 16, 2015, at 02:34, Ralph Ritoch <<a href="mailto:rritoch@gmail.com" class="">rritoch@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">I have used this function in my code without ANY problems. […]</div></div></div></div></blockquote><div><br class=""></div><div><div>The SYSTEM package is not intended to be used by users unless there is no</div><div>alternative. The manual states clearly that functionality provided by SYSTEM</div><div>is subject to be changed between major releases without warning. Therefore,</div><div>the argument in this case isn’t that one would have problems using</div><div>SYSTEM:LOAD-SYSTEM-FILE, but rather that one should use the ANSI interface as</div><div>implemented CL:LOAD which should be able to load Lisp and/or fasls in all cases</div><div>needed by the user. My work on EXT:JAR-PATHNAME and EXT:URL-PATHNAME was</div><div>motivated by precisely the need for CL:LOAD to work in all conceivable cases in</div><div>the JVM ecology. And the best contemporary mechanism for expression for</div><div>resolution of and dependency order for CL:LOAD lies in ASDF, hence my</div><div>emphasis on using its abstraction where extending CL:LOAD is not desirable. </div><div><br class=""></div><div><div>As a side note, over time, we wish to move functions in SYSTEM which useful to</div><div>the user into the EXTENSION package, but this work is incomplete at best.</div><div>Currently, there are indeed cases in which using a function from SYSTEM is</div><div>unavoidable. The use of SYSTEM:LOAD-SYSTEM-FILE is not one of them.</div></div></div></div><div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">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?<br class=""></div></div></div></div></blockquote></div><div class=""><br class=""></div><div class=""><div class="">Your attitude towards discussion is not only archaic (i.e. immature) but</div><div class="">counterproductive towards reaching the sort of consensus needed for progress.</div><div class=""><br class=""></div><div class="">However misguided such an endeavor may be, a couple points follow towards a</div><div class="">defense from your sleazy ad hominem “argumentation”.</div><div class=""><br class=""></div><div class="">As for supporting Maven, I have developed the machinery to use Maven artifacts</div><div class="">in ABCL-ASDF, and continued to maintain them (with help from users) even as the</div><div class="">lurching horror that comprises Maven release engineering continues to change</div><div class="">API semantics between patch level releases. I have offered to collaborate</div><div class="">with you on incorporating your initial work on building from Maven, pointing</div><div class="">out the problems that I see with your approach to which I have received no</div><div class="">reply. </div><div class=""><br class=""></div><div class=""><div class="">As for supporting “other technologies”, I suppose you are referring to your</div><div class="">attempt to merge abcl-contrib.jar and abcl.jar. In this effort, I pointed out</div><div class="">you could do this cleanly with the current code by adding site-specific code to</div><div class="">the “system.lisp” file whose contents are controlled by the Ant build process.</div><div class="">Since your Maven build doesn’t use the Ant target to package (one of my</div><div class="">explicit criticisms), you presumedly weren’t interested in using this</div><div class="">mechanism. I responded twice to your proposal to probe jar files on the</div><div class="">classpath for code to pontential load with suggestions which you found too</div><div class="">burdensome to discuss so you developed what you needed. Your email announcing</div><div class="">this implementation implied you had implemented to a “specification”, but no</div><div class="">such entity existed external to the source code. If you wish to provide such a</div><div class="">specification for your current implementation, please do so that others may</div><div class="">consider its usefulness. </div></div><div class=""><br class=""></div><div class=""><div class="">As to whether I control ABCL, I was going to reply that I am but one maintainer</div><div class="">out of five; that you are welcome to convince a majority of the maintainers</div><div class="">through useful and accepted contributions that that you should be in “control”</div><div class="">too; and that since the code is GPL’d so you are welcome to get the fork out of</div><div class="">here. But at this point, I would reply that if I do somehow “control” ABCL, I</div><div class="">am glad to protect it from idiots like you.</div></div><div class=""><br class=""></div></div><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">-- <br class="">"A screaming comes across the sky. It has happened before but there is nothing <br class="">to compare to it now."<br class=""><br class=""><br class=""><br class=""><br class=""></div>
</div>
<br class=""></body></html>