freenode/#lisp - IRC Chatlog
Search
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.
2:12:47
aeth
verisimilitude: UIOP will still run in 30 years if anyone's still running ASDF on CL in 30 years.
2:21:12
verisimilitude
(mapcar 'pathname-type (directory (make-pathname :name :wild :type :wild :defaults pathname))))
2:22:36
verisimilitude
If USER-HOMEDIR-PATHNAME returns NIL, which it can, then this will be in error, but I wanted this to be concise.
2:34:29
verisimilitude
If I'm writing a program that expects to use a filename provided by the user, my approach is to MAKE-PATHNAME using the different PATHNAME- functions to get at the parts I actually care about from the pathname namestring and I have the defaults use *DEFAULT-PATHNAME-DEFAULTS*, USER-HOMEDIR-PATHNAME, or then conditionally-included pathnames for POSIX or WINDOWS systems or what have you if neither of those first two are present.
2:35:33
verisimilitude
It's perfectly fine to include pathnames that only apply to certain systems if they're properly conditionally-included and you have proper standard fallbacks. This is using conditionally-included code correctly, because you get an enhanced program rather than a nonstandard one.
2:57:43
buffergn0me
I ran into that Quicklisp CCL local-projects symlinks issue last night for the first time. Not obvious that on CCL (directory X :directories t :follow-links nil) would not pick up symlinks. I wonder if that has anything to do with having consistent behavior on Mac OS or Windows.
3:55:53
akater
fiddlerwoaroof: There is a bug in SBCL with improper initialization. I'm aware of u-i-f-r-c.
4:28:01
fiddlerwoaroof
akater: cool, I was thinking you might be able to work around your issues while waiting for a patch
4:41:03
fiddlerwoaroof
buffergn0me: I forget exactly what the issue was, but I remember finding some indication in the code that this was intentional
4:46:03
loke
I've been writing a text document explaining some details ablout the clipboard work. Where should I put it in the McCLIM source repository?
5:10:53
loke
https://github.com/McCLIM/McCLIM/blob/clipboard-experiments/Documentation/clipboard.org
5:16:52
akater
fiddlerwoaroof: this is not necessarily easily reproducible. I'm not even sure we've come to conclusion that there is a bug. I'm quite sure there is.
5:17:47
akater
Quite some time ago, I patched a system in ~/common-lisp and since then ASDF reloads it each time sbcl starts. Used to load fasls. What could this be?
5:18:32
fiddlerwoaroof
The other day I had an issue where I had to clear the class definition to recompile the class form
5:20:16
akater
It is not in Quicklisp. It also compiles some C code. But as far as I can remember, used to cache everything properly. There's .so in a dir.
5:21:10
akater
My patch made it compatible with some recent ASDF (deprecated use of 'ASDF/LISP-ACTION:LOAD-OP)
5:21:57
fiddlerwoaroof
nevermind, I thought I remembered seeing code where ASDF:LOAD-SYSTEM defaulted to recompiling
5:22:46
fiddlerwoaroof
sometimes ASDF decides to load from fasls and sometimes, for no apparent reason, it recompiles everything
5:23:19
fiddlerwoaroof
maybe something you changed introduced an operation with broken staleness checks?
5:27:19
akater
There was one single change: make-instance to make-operation at one single point. https://github.com/gonzojive/elephant/pull/1/files
5:35:40
akater
Maybe someone who has more experience with ASDF could see something here immediately. I got some other asdf-related patch for this but don't feel like proposing until I figure this out.
5:50:27
fiddlerwoaroof
The biggest issue with evil-mode is accidentally sending normal mode commands to an IRC channel
9:15:00
fiddlerwoaroof
Any way to copy a hash table exactly, including implementation-specific extensions
9:17:06
verisimilitude
If this isn't sufficient, then there's no standard way to do what you want, then, I don't believe.
9:18:06
fiddlerwoaroof
oops, copying is the wrong word, I want an empty hash-table that's exactly like the given hash-table
9:19:50
verisimilitude
Well, there's no COPY-HASHTABLE, so it doesn't seem there's a standard way to get this either, fiddlerwoaroof.
9:20:50
no-defun-allowed
(make-hash-table :test (hash-table-test foo) :rehash-size ... :size ...) is probably the best way to copy the metadata on the table.
10:02:44
pjb
(apropos-list "COPY-HASH")) #| --> (com.informatimago.common-lisp.lisp-reader.reader::copy-hash-table com.informatimago.common-lisp.cesarum.utility:copy-hash-table alexandria.0.dev:copy-hash-table) |#
10:04:02
pjb
verisimilitude: I guess you could reclaim from vendors providing non-standard meta-data for hash-table, to provide a extensions:copy-hash-table function…
10:17:57
no-defun-allowed
I'd like to try to create a frame which (to the user) magically contains an infinite set of gadgets, which are loaded as the user scrolls down.
10:23:04
no-defun-allowed
Actually, I'll pick this up tommorow, this might be too complex given it's almost bedtime.
11:50:20
imjacobclark
Hello - I am delving into the world of socket programming with sbcl and Lisp, I have a working TCP server (woop) which can receive data and send data back. My dad is received as an octet stream and thrown into an array with an element type of unsigned-byte
11:50:54
imjacobclark
how could i go about this? LOC relevant: https://github.com/imjacobclark/cl-servers/blob/master/simple-tcp-server.lisp#L16
11:53:58
pjb
(make-array 2042 :element-type '(unsigned-byte 8) :initial-element 0 :adjustable t :fill-pointer 0)
11:54:57
imjacobclark
pjb: so would this rely on "(sb-bsd-sockets:socket-receive accepted-socket *receive-buffer* nil)" being able to do adjust-array/vector-push-extend ?
11:55:19
pjb
You would have to adjust it before receiving, to free some space where to receive the data.
11:56:28
imjacobclark
interesting, i guess I would never know the size of the data before I receive, and i clear the buffer anyway before i receive new data
11:57:35
imjacobclark
as afaik - i cant peek at the size of the receiving buffer until i actually receive it, which is what sb-bsd-sockets:socket-receive does
11:59:11
pjb
Content-Length: actually https://www.oreilly.com/library/view/http-the-definitive/1565925092/ch15s02.html
11:59:56
imjacobclark
doesn't socket-receive take the entire response though, how could i chunk it up so i can read the content-length header first?
12:00:26
imjacobclark
(as technically at that point the data has been received, regardless of your buffering)
12:01:14
nirved
imjacobclark: you could look at how it's done in other software, i.e. drakma - https://github.com/edicl/drakma/blob/master/request.lisp#L129
12:06:15
nirved
imjacobclark: for post data you could see at hunchentoot too - https://github.com/edicl/hunchentoot/blob/master/request.lisp#L150
12:50:41
Xach
imjacobclark: i've seen one client read a byte at a time until it gets the end-of-header marker.
12:51:24
imjacobclark
Xach: is this possible with sb-bsd-sockets? I know usocket returns 4 bytes at a time, but I think sb-bsd-sockets:socket-read wants to read the whole thing all at once
12:52:33
imjacobclark
how is that achieved? ive tried (sb-bsd-sockets:socket-receive accepted-socket "" 8) and then another (sb-bsd-sockets:socket-receive accepted-socket "" 8)
12:54:36
Xach
(sb-bsd-sockets:socket-receive socket buffer (length buffer)) is the thing to use, then look at the second value to see how much you got.
12:55:20
Xach
If you only want to read 1 byte, use a length of 1, but make sure the buffer is able to hold at least one thing.
12:55:39
imjacobclark
so, once i know the second value (e.g how much I got) what do I do next to continue reading?
12:58:02
Xach
you can get a long way with an api that does something like "call a function on each chunk you get up to matching this particular pattern" and "call a function on each chunk you get for a certain number of bytes". higher-level things can be build on top of that.
12:58:56
Xach
http generally goes: headers end with a pattern, body has a fixed size. or if it's chunked, it's headers up to a pattern, many repeated header pattern/sized chunks.
12:59:30
imjacobclark
so looking at this: https://gist.github.com/imjacobclark/cc68d5803ee96b80576a4c8b0e4a55ab
12:59:46
imjacobclark
https://gist.github.com/imjacobclark/cc68d5803ee96b80576a4c8b0e4a55ab#file-gistfile1-txt-L32-L33