Lisp filepath issues when running application directly from jar file

Mon Aug 17 13:23:24 UTC 2015

Hi Ralph,

Pointing out what Mark doesn't want is only going to fuel the controversy
and definitely not helping Hamda. Please stop doing that. Also please stop
bashing ABCL on ABCL's mailing list. People are here because they are
interested in ABCL and using ABCL. They are not interested in being told
that ABCL is insufficient in some way or another that may or may not
coincide with their goals.

If ABCL turns out to be insufficient for people, they can come to that
conclusion on their own with the *help* of the mailing list, working
through the issues that they are experiencing. So, if you have anything to
add to the discussion within the bounds of ABCL's *public api*, please do
so; if not, please refrain from making unrelated comments and/or fuelling
controversy.

Regards,

Erik.

On Mon, Aug 17, 2015 at 3:14 PM, Ralph Ritoch <rritoch at gmail.com> wrote:

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

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150817/1fe453df/attachment-0001.html>