Lisp filepath issues when running application directly from jar file

Mark Evenson evenson at
Sun Aug 16 12:38:44 UTC 2015

> 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 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

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: <>

More information about the armedbear-devel mailing list