Lisp filepath issues when running application directly from jar file

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 gmail.com> 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 gmail.com> wrote:
>
>>
>> On Mon, Aug 17, 2015 at 2:04 PM, Ralph Ritoch <rritoch at gmail.com> 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 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
>>>> ***********************************************
>>>>
>>>
>>>
>>
>>
>> --
>> Bye,
>>
>> Erik.
>>
>> http://efficito.com -- 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: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150817/8925cae2/attachment-0001.html>