freenode/#lisp - IRC Chatlog
Search
6:58:20
beach
ASDF seems to find all the .asd files in my hierarchy that existed when I put a link in quicklisp/local-projects. But it doesn't seem to find .asd file that I created after that, even though I have started a fresh SBCL.
7:05:23
mfiano
https://github.com/quicklisp/quicklisp-client/blob/master/quicklisp/local-projects.lisp#L19-L20
7:08:55
mfiano
Basically, get used to calling ql:register-local-projects if you have a symlink in local-projects, or you create new systems in a sub-directory.
7:10:00
beach
It's just that the technique I used before, i.e. putting symlinks in .cache didn't require any action other than restarting SBCL after I create a new system.
10:46:19
hjudt
a question about good practice: alexandria is considered pretty stable. can i rely on this by simply using this lib, or is it better to import selected symbols of it, or take the safe way and use alexandria:symbol in my code so one sees immediately where the symbol comes from?
10:49:24
pjb
hjudt: in general, lisp software is stable. We don't have enough resources to change it every other day.
10:49:52
pjb
hjudt: the fastest CL software is sbcl which issues an new release each month. (You don't have to upgrade each month).
11:04:31
beach
hjudt: I still recommend using explicit package prefixes. It makes it more obvious where the symbols come from to the person reading the code.
11:06:22
flip214
beach: that's good advice -- though I'm not sure whether for such well-known things like alexandria the line length lost isn't a higher cost.
11:10:31
Xach
beach: My practice was to put things directly at the top-level always, whether directories, symlinks to single projects, or symlinks to .asd file. So the thing I made initially always worked. But later I realized that I add new .asd files in subdirectories sometimes, and the magic would fail, so I made a way to scan deeper manually.
11:12:47
beach
Xach: OK, but when I use ASDF directly and I put symbolic links in .share, ASDF picks up new, deeply nested .asd file as soon as I start a new session. Are you using a different mechanism from that of ASDF then?
11:23:16
pjb
hjudt: beach: in any case, for released software, you would freeze the versions of your dependencies. So it doesn't matter if stuff is added o not.
11:23:22
aeth
Personally, I use :use only in two cases: (1) my own packages and (2) if the package is heavily tied to something else. (A bar/foo package that deals with the cl-foo bindings to foo might :use foo)
11:23:44
aeth
Although you could argue that in case #2 you're *more* likely to have name conflicts, not less
11:36:18
Xach
beach: The algorithm is this: if there is a valid system index file in the local-projects directory, look inside it for the system with the given name and return the result. a system index file is valid if it exists and is newer than the timestamp of the directory in which it lives.
11:36:46
Xach
those rules mean that new files that don't affect the directory timestamp will not be found automatically.
13:37:26
beach
So if I implement the memory manager in Common Lisp, let's say on x86-64, and I create functions that read and write memory using 64-bit addresses, I don't take any great risk by assuming that such addresses will always be fixnums. On a typical existing operating system, I just restrict addresses to the lower half of the available 48-bit address space, and I am far from the fixnum limit.
13:43:17
TMA
beach: for the foreseeable future the full 64 bit address space will not be used, except maybe on supercomputer clusters
13:46:29
beach
For a while there I was worried about how to avoid bignums in the memory allocator. I thought perhaps I needed to inline the memory-access functions so that the compiler could elide the box/unbox pairs. But it won't be necessary for some time.