LispForum

Hi all,

I am posting this being aware that it is maybe a totally dumb question and hoping that I did not miss something obvious. I am pretty new to CL (using SBCL on OS X) and only using it as a hobby in my spare time without any special purpose at the moment. While I found a lot of great material in the web teaching different aspects of why CL is so great at different levels I still have a very basic problem I could not find a clear answer for. With every new book, tutorial, etc. I get to know new functions, shortcuts, etc. which are pretty handy and which I want to keep for later usage.

I thought it would be best to have a module with all that functions and macros (maybe later different modules sorted by topics?) and "installed" it in such a way that my SBCL knows about it. While reading some stuff about require, adsf and quicklisp I got somehow lost and was wondering what would be a sane and easy way to just extend my local installation.

Is there anything like "the best way" to add "private" modules to a local installation?

Thanks in advance for every hint
Martin

mabu77 wrote:I thought it would be best to have a module with all that functions and macros (maybe later different modules sorted by topics?) and "installed" it in such a way that my SBCL knows about it. While reading some stuff about require, adsf and quicklisp I got somehow lost and was wondering what would be a sane and easy way to just extend my local installation.

Here's one way: add your code straight to your RC file. Naturally, you can also REQUIRE packages or LOAD individual .lisp files. The only caveat is that loading a lot of code will make SBCL take longer to start up, which is annoying if you have to restart SLIME a lot, for example.

I've heard some Lispers prefer to use "images" of their environment. Not sure how that works in practice.

Because I also have a similar question, if we have the four files: main.lisp, file1.lisp, file2.lisp, util.lisp; file1 and file2 depend on util; main depends on file1 and file2. Is it correct to load in both file1 and file2 the util.lisp, and then just load in main the 1 & 2?

Duke,

thanks for your reply. I think my main confusion is due to the fact that I do not see the clear analogy to emacs lisp which I am used too. In el I define my load-path and than use require in my .emacs file for loading packages (sorry for calling them modules -- my fortran history). With sbcl I did not find the right variable to manipulated the load-path. Just to blind to see, i guess...

Regards
Martin

Duke is right, at least while your collection of helper functions is relatively small - the RC file (e.g. .sbclrc) is a handy place to put them. That's where I keep a function for setting up linedit, because I normally only want it in interactive sessions where I'm not using VIlisp.
If you start relying on any of these functions in your actual code, though, trust me when I say that you'll want to move those functions into an actual ASDF package and specifically include that dependency. Also, if my set of helper functions ever grows large enough, I'll put it in its own package and then use .sbclrc to auto-load that on startup.

Duke's right that some people use images to take care of such things, but it's probably something you want to worry about later. Basically, the CL runtime consists of a VM and a system image that runs on that VM - the default one includes things like the cl-user package, but you do have the option of saving the state of an image and then telling CL to use that image when it starts up. This works well enough, and can speed things up significantly when you regularly need to load a large number of packages (the same ones each time, that is) but has enough gotchas that you're better off climbing up a few other learning-curves beforehand.

Sorry, I tried posting this reply yesterday, but lispforum.com was having some issues with responding in a sane way.

Thank you all for your replies. I finally set up a ASDF package for my extensions which i keep in different files and everything works fine now

Best regards
Martin