<ixelp>
CLHS: Function ASSOC, ASSOC-IF, ASSOC-IF-NOT
<beach>
This page says ALIST is an association list. And the glossary says that an association list is a list of conses.
<beach>
Presumably, that implies that an association list is a proper list.
<beach>
But look at the "Notes:" (yes, I know the notes are not part of the standard)...
<beach>
It gives two almost equivalent expressions, but they are equivalent only if NIL is a member of the association list. But then, it is not an association list, now is it?
paul0 has quit [Quit: Leaving]
<beach>
If I were to implement ASSOC, I would take the wording in the "Exceptional situations:" section to mean that if I detect that I don't have a proper list, or if I detect that an element is not a CONS cell, then I would signal an error.
<beach>
And that I don't have to search beyond a matching element to find out whether it is really an association list.
<beach>
Now, SBCL does not signal an error for (say) (assoc 1 '((a . b) nil (1 . 3)))
<beach>
But it does for (assoc 1 '((a . b) 234 (1 . 3)))
<beach>
And the error message hints that SBCL considers an association list to be a list of elements of type LIST, rather than (as the glossary says) a list of elements of type CONS.
<Equill>
I don't like it either, but this appears to be a case of duck-typing: both `(listp nil)` and `(atom nil)` return `t`, so the crucial test in this case is whether an element is considered a list, rather than whether it's (possibly _also_) some other type.
<Equill>
I say this partly because I was banging my head against this kind of thing recently.
<beach>
I take the situation to be a "don't fail unless you have to" one. But this attitude is out of fashion, and nowadays we prefer "help the programmer as much as possible".
<Equill>
The fact that `(consp nil)` is false, is not helping my headache.
<beach>
Are you saying you think it should be true?
cage has joined #commonlisp
<Equill>
It's the part where it's a list but not a cons, that conflicts with my assumption that lists are by definition made of conses. That means there's something I didn't properly understand.
<Equill>
...I'll add that to the pile. It's not a small pile, either :)
<beach>
Well, the empty list is a list, and the empty list is the same as NIL, so NIL must be a list.
<beach>
You are right that lists are "made of conses", but there could be zero conses in a list.
<mariari>
Equill: in ML, lists are defined as CONS or NIL, thus if you had a CONSP function, it should answer false for NIL. The same view can be said for CL, modulo improper lists
<beach>
mariari: There is no need for the "modulo".
<mariari>
beach: fair, I was implicitly typing the cdr to be a LIST, which improper lists lets us say end it with 5
<beach>
The LIST type is equivalent to (OR CONS NULL).
<Equill>
Defining a list as *zero or more* conses resolves that issue. Thanks for that insight.
<beach>
True, the CDR of a list is not necessarily a list.
<beach>
Equill: Pleasure.
Brucio-61 has joined #commonlisp
usr241d2a4d has quit [Ping timeout: 260 seconds]
usr241d2a4d has joined #commonlisp
usr241d2a4d has quit [Ping timeout: 250 seconds]
Gleefre has joined #commonlisp
occ has quit [Ping timeout: 255 seconds]
kenran has quit [Quit: ERC 5.5 (IRC client for GNU Emacs 30.0.50)]
kenran has joined #commonlisp
alendvai__ is now known as attila_lendvai
asarch has joined #commonlisp
kenran has quit [Remote host closed the connection]
LW has joined #commonlisp
kenran has joined #commonlisp
random-nick has joined #commonlisp
asarch has quit [Quit: Leaving]
attila_lendvai has quit [Ping timeout: 260 seconds]
jeffrey has joined #commonlisp
morganw has joined #commonlisp
LW has quit [Quit: WeeChat 3.6]
usr241d2a4d has joined #commonlisp
scymtym has joined #commonlisp
cage has quit [Remote host closed the connection]
kenran has quit [Remote host closed the connection]
cage has joined #commonlisp
MajorBiscuit has joined #commonlisp
MajorBiscuit has quit [Client Quit]
MajorBiscuit has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
pfdietz has joined #commonlisp
jonatack1 has joined #commonlisp
pfdietz has quit [Client Quit]
jon_atack has quit [Ping timeout: 255 seconds]
pfdietz has joined #commonlisp
rgherdt_ has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
Jach has quit [Remote host closed the connection]
rgherdt_ is now known as rgherdt
random-nick has quit [Ping timeout: 265 seconds]
pranavats has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 260 seconds]
occ has joined #commonlisp
<_death>
beach: another alternative is to change the definition of alist.. presumably the notes section mentions nil entries as a reflection of historical use, where one would set some entries to nil as a way to delete entries from an alist without consing
<beach>
Sure.
<_death>
although you could set a cdr of a cons without consing as well
<_death>
again I'm missing my lisp manuals, it'd be interesting to see whether such use is mentioned in one of them
<beach>
Page 431 in CLtL2: It is permissible to let NIL be an element of an a-list in place of a pair. Such an element is not considered to be a pair but is simply passed over when the a-list is searched by ASSOC.
<beach>
So my guess is that the standard did not allow this exception, and that SBCL did not change its implementation according to the standard.
<pfdietz>
It's not much of an efficiency hit to handle these nils. Just specialize the implementation of ASSOC to special case a nil key; in that case, there's an additional check you actually found a cons.
<beach>
You mean a "nil element" as opposed to a "nil key"?
<_death>
pfdietz: there's a mirror argument to KMP's "so asking ASSOC to ignore atoms would mean putting an explicit atom check in the ASSOC inner loop, which might be very slow in some implementations." .. you could say the same for an implementation that explicitly checks for conses
<_death>
<_death>
although this is 2023, not 1987 :)
<pfdietz>
I meant a nil key. If the key is not nil, you never have to check for nil alist elements, since (car nil) != the key.
<_death>
(assoc nil '(nil (nil . 42))) does return (nil . 42) in sbcl though
<pfdietz>
Yes, it should. The nil key case would require checking if the alist element is not itself nil.
<beach>
pfdietz: Ah, yes, I now see what you mean.
<pfdietz>
The error checking that the alist element must be of type LIST is handled automatically by CAR on modern implementations.
<beach>
But aside from SBCL, a test for CONSP must be done in CAR anyway.
<pfdietz>
Using the offset-the-pointer-by-1 trick (or -1).
<_death>
beach: so then you'd have two tests, or need to use some car-of-cons operator
<_death>
I guess (car (the cons x))
<beach>
Presumably, CAR is inlined, so that the second test can be skipped.
<_death>
right
<pfdietz>
I wonder how trapping bad accesses can be made to work with very low overhead in the non-trapping case. You don't want to do something heavyweight to set up a handler for conditions.
<_death>
since car and cdr must have type-error signaling code, maybe implementation don't always choose to inline them
Jach has joined #commonlisp
<_death>
sbcl still does for (defun foo (x) (declare (optimize (space 3))) (car x)) though
usr241d2a4d has quit [Ping timeout: 248 seconds]
usr241d2a4d has joined #commonlisp
tyson2 has joined #commonlisp
Noisytoot has quit [Excess Flood]
usr241d2a4d has quit [Ping timeout: 276 seconds]
Noisytoot has joined #commonlisp
Noisytoot has quit [Ping timeout: 255 seconds]
jonatack2 has quit [Ping timeout: 268 seconds]
jonatack2 has joined #commonlisp
Noisytoot has joined #commonlisp
shka has joined #commonlisp
usr241d2a4d has joined #commonlisp
msavoritias has quit [Ping timeout: 246 seconds]
azimut has joined #commonlisp
msavoritias has joined #commonlisp
Noisytoot has quit [Excess Flood]
Noisytoot has joined #commonlisp
gxt__ has quit [Ping timeout: 255 seconds]
gxt__ has joined #commonlisp
karlosz has joined #commonlisp
MajorBiscuit has joined #commonlisp
karlosz has quit [Quit: karlosz]
jonatack3 has joined #commonlisp
jonatack2 has quit [Ping timeout: 255 seconds]
markb1 has joined #commonlisp
waleee has joined #commonlisp
molson has joined #commonlisp
molson_ has joined #commonlisp
kevingal has joined #commonlisp
kevingal_ has joined #commonlisp
pjb has joined #commonlisp
pestctrl has joined #commonlisp
waleee has quit [Ping timeout: 246 seconds]
dcb has joined #commonlisp
usr241d2a4d has quit []
lucasta has joined #commonlisp
kevingal_ has quit [Ping timeout: 240 seconds]
kevingal has quit [Ping timeout: 240 seconds]
chrcav has quit [Ping timeout: 265 seconds]
chrcav has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
pfdietz has quit [Quit: Client closed]
eddof13 has joined #commonlisp
eddof13 has quit [Client Quit]
attila_lendvai has joined #commonlisp
random-nick has joined #commonlisp
masinter has joined #commonlisp
rgherdt_ has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
Posterdati has quit [Read error: Connection reset by peer]
Posterdati has joined #commonlisp
<jeosol>
good morning all!
<jeosol>
Is there a cl utility I can use to check memory consumption with time. I have a long running workflow (takes like 2-3 weeks) and I run several versions of the workflow using different inputs. The input determines the complexity of the task. I am doing meta-optimization over some functions. With a single function, it tends to run fine. With many
<jeosol>
functions, more complex calculation, the run fails and the computer is restarted. This has happened a few times I am trying to pin-point the issue
<jeosol>
For context, I only use SBCL.
remexre has quit [Remote host closed the connection]
remexre has joined #commonlisp
remexre has quit [Remote host closed the connection]
remexre has joined #commonlisp
Lumine has joined #commonlisp
euandreh has quit [Ping timeout: 250 seconds]
euandreh has joined #commonlisp
lucasta has quit [Quit: Leaving]
<edwlan[m]>
ROOM will show you the current memory usage, could you run it in a thread with a loop and a sleep?
eddof13 has joined #commonlisp
eddof13 has quit [Client Quit]
foretspaisibles has joined #commonlisp
phantomics has joined #commonlisp
xaltsc has joined #commonlisp
foretspaisibles has quit [Ping timeout: 260 seconds]
<jeosol>
I know it will be hard to make recommendations without more context, but I am suspecting increased memory usage. I do start SBCL with --dynamic-space-size but perhaps need to increase it to much larger number.
Gleefre has quit [Remote host closed the connection]
<jeosol>
edwlan[m]: thanks for your response. I am actually running the application through a container, but previous tests with a repl had the same issues. I suspect it has something to do with the code.
Gleefre has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
<jeosol>
edwlan[m]: one think I could do, is do a test and save the results of (room) but it doesn't return an result, just prints to the screen.
<edwlan[m]>
You could use with-output-to-string to solve that, but it’s sort of annoying
<jeosol>
edwlan[w]: I see, output to string then parse it to extract the right parameter?
<edwlan[m]>
You could jump to source and look at its implementation too, there’s probably some implementation-specific API for this information.
<edwlan[m]>
Yeah
<jeosol>
one thing I could do, is rebuild the container, but have a new function using (room) and extract some info say every 30mins and save that to a file. If the run fails, I am still able to view the profile
dilated_dinosaur has quit [Ping timeout: 276 seconds]