From: Ivan Z. <mel...@me...> - 2013-06-05 05:10:55
|
Heyya all, I have a somewhat bizarre question. I want to provide what is essentially a shared library for Common Lisp programs, but I cannot decide on the way to do that. The purpose is to allow all the little programs I write to use each other's packages, but not in a cite-specific way. I want it to be done in a distribution-specific way, so that anyone who runs a distribution I support (say, Slackware) can simply install clisp, install my "shared library" package, and then be able to run all and any of my programs, as well as write new code using my "libraries" as easily as possible. The question is, what's the best way to do this with clisp? I thought about logical path names, and also about using custom:*load-paths*, but neither seems perfect. Can anyone offer any wisdom? |
From: Pascal J. B. <pj...@in...> - 2013-06-05 20:18:29
|
Ivan Zaigralin <mel...@me...> writes: > Heyya all, I have a somewhat bizarre question. I want to provide what > is essentially a shared library for Common Lisp programs, but I cannot > decide on the way to do that. The purpose is to allow all the little > programs I write to use each other's packages, but not in a cite-specific > way. I want it to be done in a distribution-specific way, so that anyone > who runs a distribution I support (say, Slackware) can simply install > clisp, install my "shared library" package, and then be able to run all > and any of my programs, as well as write new code using my "libraries" > as easily as possible. > > The question is, what's the best way to do this with clisp? I thought about > logical path names, and also about using custom:*load-paths*, but neither > seems perfect. Can anyone offer any wisdom? Have a look at http://cliki.net/site/search?query=deployment Since you're asking on the clisp mail-list, I will first mention something specific to clisp: modules. http://www.clisp.org/impnotes/modules.html Now, while modules are designed to be written in other programming languages, compiled into a shared library, and loaded dynamically into clisp (with a require expression), you can provide a lisp file along with the shared library to be LOAD'ed by clisp once the shared library is dynamically linked in. You could have a stub shared library and put all the code in the lisp file, which would make a bona fide module ;-) Notice that debian (ubuntu, etc) already distributes clisp itself with its modules as separate apt packages. It would be trivial to reuse those .deb files. But more seriously, you have deployment choices to make: What kind of code do you want to deploy? - lisp sources (.lisp), - byte code compiled fast loading files (.fas), - binary shared libraries (.so). The two first kinds of files can be loaded with LOAD or ASDF or QUICKLISP (and you can configure quicklisp to work with a site installation instead of $HOME/quicklisp/). The later, can be either in the form of a module (see above), or a shared library loaded with FFI (or rather CFFI). The question here is how to generate a binary shared library? clisp can't do it. But ecl can, if your source is in lisp (otherwise, use the compiler of the language in which your library is written). Of course, loading libecl.so into clisp (thru CFFI), to load then a shared library compiled with ECL into clisp, then converting clisp lisp data into C data and then into elc lisp data and back at each "foreign" function call, sounds a little silly. This is not a good deployment choice, if your source is lisp, as things are. So remains .lisp or .fas. You can either concatenate all your .lisp or .fas (in the right order) into a single one, and just load it, or write a .asd file to load several of them. You can then package the result with the home system distribution management system, to be installed in some /usr/share/clisp/ or other directory, and provide a configuration to load it (either a path, or a asdf configuration). Or more simply, just put every .lisp and .asd in some git repository, and give the url to Zach Bean, who will include it in the next release of quicklisp. quicklisp is our "package" distribution system. Let the user choose to configure quicklisp system-wide or user specific. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. You can take the lisper out of the lisp job, but you can't take the lisp out of the lisper (; -- antifuchs |
From: Ivan Z. <mel...@me...> - 2013-06-23 18:09:44
|
On 06/07/2013 05:52 PM, Pascal J. Bourguignon wrote: > Ivan Zaigralin <mel...@me...> writes: >> (load (translate-logical-pathname "MY-HOST:package-name")) > > or just (load "MY-HOST:package-name") That's the other thing I don't really understand. The default behavior of clisp seems to be to treat all strings as physical pathnames (due to the break with ANSI in parse-namestring http://www.clisp.org/impnotes.html#parsename), so I am not able to load anything logical without (setf custom:*parse-namestring-ansi* t) With ANSI behavior, though, load works as intended. But now all namestrings beginning with MY-HOST: are treated as logical pathnames, and the physical pathnames starting with MY-HOST: are shadowed. Is that right? I can see I can get around it by calling (load "./MY-HOST:foo.lisp") to load the file "MY-HOST:foo.lisp" in the current directory. Are these my only two options? Choosing between (load (logical-pathname "MY-HOST:foo.lisp")) and (setf custom:*parse-namestring-ansi* t) (load "MY-HOST:foo.lisp") with all the shadowing? |
From: Pascal J. B. <pj...@in...> - 2013-06-23 19:12:43
|
Ivan Zaigralin <mel...@me...> writes: > On 06/07/2013 05:52 PM, Pascal J. Bourguignon wrote: >> Ivan Zaigralin <mel...@me...> writes: >>> (load (translate-logical-pathname "MY-HOST:package-name")) >> >> or just (load "MY-HOST:package-name") > > That's the other thing I don't really understand. The default behavior of > clisp seems to be to treat all strings as physical pathnames (due to the break > with ANSI in parse-namestring http://www.clisp.org/impnotes.html#parsename), > so I am not able to load anything logical without > > (setf custom:*parse-namestring-ansi* t) > > With ANSI behavior, though, load works as intended. But now all namestrings > beginning with MY-HOST: are treated as logical pathnames, and the physical > pathnames starting with MY-HOST: are shadowed. Is that right? I can see I > can get around it by calling (load "./MY-HOST:foo.lisp") to load the file > "MY-HOST:foo.lisp" in the current directory. Are these my only two options? > Choosing between > > (load (logical-pathname "MY-HOST:foo.lisp")) Yes, parsing namestrings can be ambiguous. Instead, use make-pathname. C/USER[13]> (setf (LOGICAL-PATHNAME-TRANSLATIONS "MY-HOST") '(("**;*.*" "/tmp/**/*.*"))) ((#P"MY-HOST:**;*.*" "/tmp/**/*.*")) C/USER[14]> (typep (make-pathname :name "MY-HOST:foo" :type "lisp" :case :local :defaults #P"") 'logical-pathname) NIL C/USER[15]> (typep (make-pathname :name "foo" :type "lisp" :case :local :host "MY-HOST" :defaults #P"") 'logical-pathname) T -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. You know you've been lisping too long when you see a recent picture of George Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin |
From: Sam S. <sd...@gn...> - 2013-06-25 18:01:06
|
> * Ivan Zaigralin <zryvxnzc@zryvxnzc.pbz> [2013-06-23 14:09:34 -0400]: > > I am not able to load anything logical without > > (setf custom:*parse-namestring-ansi* t) you can call TRANSLATE-LOGICAL-PATHNAME explicitly too. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 13.04 (raring) X 11.0.11303000 http://www.childpsy.net/ http://www.memritv.org http://dhimmi.com http://ffii.org http://honestreporting.com http://palestinefacts.org An elephant is a mouse with an operating system. |