freenode/#lisp - IRC Chatlog
Search
14:32:57
_death
why do you declare *lists-as-plists* as special? did you not defvar/defparameter it?.. and if not, you should also declare it special in the :around method
14:41:22
chrnybo
_death: Described in a paper by Espen Vestre published at a japanese lisp conference
14:41:54
chrnybo
https://franz.com/services/conferences_seminars/jlugm00/conference/Talk05_Vestre.pdf
14:45:36
chrnybo
Sure, apply for a job in OSS, masquerading as an eager architect-type, then come sit next to us in order to join in.
19:33:58
fiddlerwoaroof
akater: I noticed you were talking about class redefinition issues the other day, CL has UPDATE-INSTANCE-FOR-REDEFINED-CLASS that can sometimes help.
19:34:50
fiddlerwoaroof
I've written methods on this for development purposes only to clean up/fix changes arising from class definition changes
19:36:36
fiddlerwoaroof
There's also UPDATE-INSTANCE-FOR-DIFFERENT-CLASS that handles cases where you CHANGE-CLASS on a class that's in use
19:37:03
fiddlerwoaroof
they're not much used, afaict, mostly because we tend to write programs in lisp rather than treating lisp as a system
0:54:18
asarch
How would traverse a directory in Common Lisp showing the kind of file (directory, link, plain file, etc) of each element found?
1:15:06
Jachy
Maybe just combine uiop:subdirectories and uiop:directory-files? Some post-processing could then resolve a symlink. The uiop suggests IOlib might handle symlink situations more cleanly.
1:21:35
fiddlerwoaroof
asarch: OSICAT:WALK and CL-FAD:WALK-DIRECTORY might do the walking part of your question
1:22:18
fiddlerwoaroof
UIOP doesn't have anything obvious, as far as I could tell with a quick apropos
1:22:57
fiddlerwoaroof
e.g. quicklisp doesn't recognize systems that are symlinked into local-projects while sbcl does
1:32:52
aeth
fiddlerwoaroof: huh? Are you saying that Quicklisp doesn't recognize ~/quicklisp/local-projects/foo if foo is a symlink? Because I've never had anything but symlinks in there.
1:33:46
fiddlerwoaroof
it's not exactly true, because CCL will pick up the projects if you quickload them in sbcl first
1:35:09
fiddlerwoaroof
Yeah, I've had some strange experiences where I happen to first use a new thing in local-projects from ccl
1:44:01
verisimilitude
What you should do is use DIRECTORY with a :WILD name and type and then call PATHNAME-TYPE on the resulting list, asarch.
1:53:13
fiddlerwoaroof
And, you have to make sure that you're doing TRUENAME first, because that just tells you what the TYPE component of the PATHNAME struct is
1:53:52
fiddlerwoaroof
so mkdir foo.bar; sbcl -e '(princ (pathname-type #p"foo.bar"))' wil print BAR
1:55:15
aeth
verisimilitude: Is it correct to say 'SBCL on GNU/Linux'? Does SBCL require any GNU software past compilation? (or even in compilation? can the C component use LLVM?)
1:55:26
verisimilitude
In any case, I'd suggest using the standard CL functions for manipulating the file system before I started recommending a library for it; for what asarch wants, it's likely sufficient.
1:56:22
fiddlerwoaroof
pathnames are underspecified in the standard, imho, so it's one place where it's better to use a library like UIOP than the standard functions
1:57:04
fiddlerwoaroof
because, if you use the standard functions, you will almost certainly run into weird cross-implementation edgecases when dealing with the sorts of filenames you find on a modern linux system
1:58:37
verisimilitude
The situation there is already damned due to a lack of any foresight, fiddlerwoaroof. Under most POSIX systems, OS X being an exception, filenames are just octects, without any imposed structure, so it's not even necessarily proper UTF-8, making headaches for any system that doesn't encourage C's chronic lack of typing.
1:59:19
verisimilitude
It's my understanding this is an issue for Python, even, which actually does make an effort to adopt POSIX nonsense.
2:03:22
fiddlerwoaroof
verisimilitude: for the sorts of files one actually does encounter in "normal" systems (read, "any system I've used between 2005 and now"), python has never had an issue opening a file.
2:04:03
fiddlerwoaroof
In CL, I've run into issue like "CL expects the first dot to separate the name from the type and the second dot, if present, to separate the type from the version"
2:05:27
verisimilitude
Anyway, standard Common Lisp doesn't address this, and there's not really a good way to. It seems silly, to me, to suggest a library if it won't solve the entire problem anyway. Do tell if any of you test this.
2:06:45
verisimilitude
My point, fiddlerwoaroof, is that filenames under most POSIX systems are already a broken mess.
2:07:20
fiddlerwoaroof
Sure, but the good thing is that most of the time assuming that filenames are UTF-8 (or some other encoding) is good enough
2:07:57
fiddlerwoaroof
And, one generally prefers to use things the problems one has, not the problems one might have
2:08:33
verisimilitude
I suggest to everyone to simply read the standard and its guarantees and simply try to program using only those. Many programs handle filenames provided by the user, which can generally be manipulated more than well enough to accomplish what is wanted. Then, you get to have a program that will work on any system with Common Lisp thirty years from now.