Re: Lisp filepath issues when running application directly from jar file
Hello, Since you are loading resources and not from the filesystem you probably want to utilize the load-system-file function which I believe is provided by the :sys package. I'm not sure how portable this is so you may want to add some additional control logic if you want portability. (load-system-file "path/to/resource.lisp") Best Regards, Ralph Ritoch On Fri, Aug 14, 2015 at 8:00 PM, <armedbear-devel-request@common-lisp.net> wrote:
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. Lisp filepath issues when running application directly from jar file (Hamda Binte Ajmal)
----------------------------------------------------------------------
Message: 1 Date: Fri, 14 Aug 2015 11:20:18 +0100 From: Hamda Binte Ajmal <hamda.binte.ajmal@gmail.com> To: armedbear-devel@common-lisp.net Subject: Lisp filepath issues when running application directly from jar file Message-ID: <CAJEb= LPJuCP6FJoTxuCGaapbo4FHdjnWdEf_QumgMJF-9BhHXQ@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
Hi, I was working on an application, that loads a few lisp files using lisp command (load "fullfilepath.lisp") from java using ABCL. This file in turn loads the other lisp files located in same folder hierarchy, and then i call lisp functions (defined in these files) from java and everything works perfect as long as I run the application from Netbeans. Close to deployment, I tested the application by running it from jar file, I found that there are issues with filepaths, as the files are not a part of file-system, and hence not accessible using a file-path. Does anyone has any idea how to fix this issue ? I tried many things, like
URL url = LispConnector.class.getResource("/Aima/aima/quicklisp/setup.lisp");String path = url.getFile();File f = new File(path); path = f.getAbsolutePath(); path = path.replace("\\", "/");
which returns [image: enter image description here]
But which is wrong as this is not a valid file path and does not exists so lisp : (load "filepath") fails here.
When I use the code
String path = url.toURI();File = new File(path); path = path.getAbsolutePath();
Again it works fine while running from netbeans, but shows error "URI is not hierarchical" error while running the jar file.
Has anyone encountered this issue, please help.
-- Hamda Binte Ajmal NUIG, Ireland
On 2015/8/15 17:39, Ralph Ritoch wrote:
Hello,
Since you are loading resources and not from the filesystem you probably want to utilize the load-system-file function which I believe is provided by the :sys package. I'm not sure how portable this is so you may want to add some additional control logic if you want portability.
(load-system-file "path/to/resource.lisp")
No, you should not use SYS:LOAD-SYSTEM-FILE. As part of the SYSTEM package, it is intended for use by the system while bootstrapping, and its use is not supported by user code. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark, I have used this function in my code without ANY problems. 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? Best Regads, Ralph Ritoch On Sun, Aug 16, 2015 at 5:17 AM, Mark Evenson <evenson@panix.com> wrote:
Hello,
Since you are loading resources and not from the filesystem you
On 2015/8/15 17:39, Ralph Ritoch wrote: probably
want to utilize the load-system-file function which I believe is provided by the :sys package. I'm not sure how portable this is so you may want to add some additional control logic if you want portability.
(load-system-file "path/to/resource.lisp")
No, you should not use SYS:LOAD-SYSTEM-FILE. As part of the SYSTEM package, it is intended for use by the system while bootstrapping, and its use is not supported by user code.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
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."
participants (2)
-
Mark Evenson -
Ralph Ritoch