Lisp filepath issues when running application directly from jar file

Mon Aug 17 12:04:46 UTC 2015

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 at common-lisp.net>
wrote:

> Send armedbear-devel mailing list submissions to
>         armedbear-devel at 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 at common-lisp.net
>
> You can reach the person managing the list at
>         armedbear-devel-owner at 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 at panix.com>
> To: Armed Bear <armedbear-devel at common-lisp.net>
> Subject: Re: Lisp filepath issues when running application directly
>         from jar file
> Message-ID: <5616917D-F789-4F95-93E2-FC3B7633B051 at panix.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> > On Aug 16, 2015, at 02:34, Ralph Ritoch <rritoch at 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 at common-lisp.net
> https://mailman.common-lisp.net/listinfo/armedbear-devel
>
>
> ------------------------------
>
> End of armedbear-devel Digest, Vol 16, Issue 11
> ***********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150817/b6553ac3/attachment.html>