Lisp filepath issues when running application directly from jar file

Hamda Binte Ajmal hamda.binte.ajmal at
Mon Aug 17 13:04:53 UTC 2015

Please, can anyone help me here?

On Mon, Aug 17, 2015 at 2:03 PM, Ralph Ritoch <rritoch at> wrote:

> Erik,
>    Your pointing out ONE fix that didn't completely solve ALL problems
> related to compound types, but that one fix didn't solve all of the
> failures. Most of the repairs I made were complete. I don't expect my fork
> to run most LISP applications because it is only being re-designed to
> support compliant applications. Specifically I dropped automatic support
> for the #No-Break_Space named character. ABCL does not meet my needs,
> period, and it doesn't meet the needs of most business applications.  It
> won't be adopted by the industry until it is refactored to meet the needs
> of the industry, and that is what I am working on. As mark says, he doesn't
> want to allow users to have access to loading lisp from the classloader.
> Appropriate maven integration was also flat-out rejected, and his solution
> of tying system dependent configuration settings to the deployment of
> applications is not conducive to Interoperability.  At the end of the day
> it all comes down to two questions, does ABCL meet my needs today, and will
> it meet those needs in the future. Mark has made it clear that the answers
> to both questions are a resounding NO.  Anyone looking to include a LISP in
> an enterprise application is going to come to the same conclusion, leaving
> ABCL in a subculture that can never be part of the mainstream because it
> doesn't meet the needs of the industry.
> Best Regards,
>   Ralph Ritoch
> On Mon, Aug 17, 2015 at 8:52 PM, Erik Huelsmann <ehuels at> wrote:
>> On Mon, Aug 17, 2015 at 2:04 PM, Ralph Ritoch <rritoch at> wrote:
>>> 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.
>> True. But it's not like you solved all these issues by fundamentally
>> supporting what they're testing for. The complex types that you fixed (and
>> I already said this in IRC) could have been fixed the way you did over 10
>> years ago. We find it more important to fix the underlying issues. I'd like
>> to note here that compliance doesn't come from "not failing the ansi
>> tests", but from implementing the features the tests are trying to test. In
>> other words, you're not compliant with a class of issues by being able to
>> produce on specific instance of the class.
>> The fix to make things "MUCH faster" as you say doesn't solve problems in
>> the bigger picture; does the ABCL in your git repository now have fewer
>> CL-TEST-GRID failures? If not, then it's not more useful than it was
>> before: it doesn't run more of the most-used CL code out there.... Now,
>> *that* would have been a great and useful contribution. I'm affraid that
>> coming rushing in, expecting immediate answers, solving unimportart
>> problems, calling people names if they don't respond quickly enough by your
>> standards and then hard-forking the project all don't classify as great
>> contributions.
>> I hoped that we could get the progress you said you wanted through the
>> discussion that's to be expected when you are an open source contributor.
>> Alas, as Mark points out, there hasn't been much of the discussion I had
>> hoped for...
>> Regards,
>> Erik.
>>> Best Regards,
>>>   Ralph Ritoch
>>> On Mon, Aug 17, 2015 at 8:00 PM, <
>>> armedbear-devel-request at> wrote:
>>>> Send armedbear-devel mailing list submissions to
>>>>         armedbear-devel at
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>> or, via email, send a message with subject or body 'help' to
>>>>         armedbear-devel-request at
>>>> You can reach the person managing the list at
>>>>         armedbear-devel-owner at
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of armedbear-devel digest..."
>>>> Today's Topics:
>>>>    1. 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 at>
>>>> To: Armed Bear <armedbear-devel at>
>>>> Subject: Re: Lisp filepath issues when running application directly
>>>>         from jar file
>>>> Message-ID: <5616917D-F789-4F95-93E2-FC3B7633B051 at>
>>>> Content-Type: text/plain; charset="utf-8"
>>>> > On Aug 16, 2015, at 02:34, Ralph Ritoch <rritoch at> 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
>>>> 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."
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL: <
>>>> >
>>>> ------------------------------
>>>> Subject: Digest Footer
>>>> _______________________________________________
>>>> armedbear-devel mailing list
>>>> armedbear-devel at
>>>> ------------------------------
>>>> End of armedbear-devel Digest, Vol 16, Issue 11
>>>> ***********************************************
>> --
>> Bye,
>> Erik.
>> -- Hosted accounting and ERP.
>> Robust and Flexible. No vendor lock-in.

Hamda Binte Ajmal
+92 344 550 7680
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the armedbear-devel mailing list