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:

   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@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."





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150816/f10b225d/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
armedbear-devel mailing list
armedbear-devel@common-lisp.net
https://mailman.common-lisp.net/listinfo/armedbear-devel


------------------------------

End of armedbear-devel Digest, Vol 16, Issue 11
***********************************************