Lisp filepath issues when running application directly from jar file

Mon Aug 17 13:14:01 UTC 2015

Hamda Binte Ajmal,

   From ABCL/Lisp what you want to do, loading from the classloader, is NOT
possible unless your willing to use (load-system-file
"path/to/resource.lisp") which is provided by the system package.

Note the defpackage I used to access the system package.
https://github.com/rritoch/abclp/blob/master/src/main/abclp/META-INF/abcl/abclp/abclp.lisp#L8

>From Java side you can call Load.loadSystemFile as you can see here.

https://github.com/rritoch/abclp/blob/master/src/main/java/com/vnetpublishing/java/abcl/abclp/Main.java#L30

Mark makes it very clear that he doesn't want these features available to
users so there is a high possibility that they will add additional code to
make it more difficult to access this capability. As I stated in my
previous email, ABCL just doesn't meet the needs of our applications, but
Mark doesn't seem to  care.

Best Regards,
  Ralph Ritoch

On Mon, Aug 17, 2015 at 9:04 PM, Hamda Binte Ajmal <
hamda.binte.ajmal at gmail.com> wrote:

> 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/e65c01f3/attachment-0001.html>