freenode/#lisp - IRC Chatlog
Search
7:09:53
phoe
I've hit the 50-page milestone on my "article" about the Common Lisp condition system. I guess it's time to start calling it a book instead.
7:13:17
beach
phoe: I am still very busy. Now I need to finish reading and assessing the document by Didier Verna, regarding his "habilitation".
7:25:53
aeth
phoe: when you do have a book, you should put it on one of those sites that does low-volume publishing so people can buy it
8:12:51
ATuin
seems that sbcl was updated at some point to 2.0.3 (dunno if that's the problem or now though)
8:15:52
ATuin
looks like a problem with the paths right? since the binary is the same (one the symlink and the other dereferencing)
8:16:43
ATuin
yep, i think the same, but i want to understand the root of the problem so i can fix it
8:19:59
ATuin
i tried to use (trace) but it does not provide enough info to see exactly what's taking the cpu so busy
9:11:21
phoe
the syntax inconsistencies between HANDLER-BIND and HANDLER-CASE and between RESTART-BIND and RESTART-CASE are kinda gross now that I think about them
9:12:09
phoe
HANDLER-BIND has a &body that accepts forms to be execused while HANDLER-CASE has a &body that accepts handler definitions
9:13:22
no-defun-allowed
The committee did care for aesthetics; there's a section for it in every issue writeup.
9:14:25
shka_
yes, but it is very likely that weirdness like above is the result of the backward compatibility requirements
9:15:00
no-defun-allowed
Maybe. Not so much a "committee" problem as a "don't break things" problem then.
9:36:33
phoe
restart-bind's :test-function accepts #'foo, but restart-case's :test does not accept #'foo
11:24:40
phoe
I remember someone mentioning a macro named HANDLER-CASE* which worked exactly like HANDLER-CASE, except the cases were executed before unwinding the stack. Is anyone aware of any existing permissively-licensed implementation of it?
12:23:41
eta
loading it and running (ROOM) results in 50,077,648 bytes for 1,311,232 dynamic objects (space total)
12:27:21
_death
it includes the runtime, the compiler, docstrings, caches, libraries, docstrings, etc.
12:27:27
p_l
CMUCL (and thus SBCL, which derives from it) compiler is famous for generating fast code. However, the same rules that help it generate fast code mean that it takes more space, due to inlining et al
12:28:17
p_l
eta: immobile space is the stuff that is, for various reason, "pinned" in memory location
12:28:40
p_l
eta: btw, the optimization features? They also take space in terms of compiler code, so you get more space used by compiler, too :)
12:30:40
p_l
the GC algorithms work better if you have large address space + budget for ~2x the amount of memory used at any particular time (it's a quick approximation, not hard rule)
12:31:33
p_l
ACTION remembers when people used to complain about VCL's size when compiling binaries with Delphi :/
12:37:12
phoe
nowadays people run whole virtualized OSes to run their tiny apps; compared to this, SBCL footprint feels smol
12:46:56
jcowan
I am trying to solve a problem with involving the CL integer representation of bit sequences, and I can't see how to do it
12:48:18
jcowan
Given a list of bit positions, (i j k ...) the representation as an integer is 2^i + 2^j + 2^k + ...; that seems clear.
12:50:43
jcowan
Now I have a value n that means "all bits from n to infinity are set", which requires a negative number in the integer representation, i.e. -1 = 0 to infinity, -2 = 1 to infinity, -4 = 2 to infinity, etc.
12:52:08
jcowan
How can I combine these such that I get the integer representation of (i j k n (+ n 1) (+ n 2) ...)? Every time I try to reason it out, I get more confused.
12:57:05
jcowan
We can assume that n > the rest wlg, though the order of i, j, k shouldn't matter, addition being commutative and all.
12:57:07
Posterdati
jcowan: you can have a class with a bit array of n bits to store the < n bits positions
12:57:34
jcowan
I want to represent them as an integer, since almost all cases will fit into a fixnum.
12:57:49
beach
jcowan: Do you want to know how to obtain it in Common Lisp, or do you want some mathematical expression for it?
13:00:01
beach
In Common Lisp, you can use LOGIOR and LOGNOT, so if you know how to do n, n+1, n+2, ... then you can OR it with the one for i j k.
13:00:53
beach
And if you don't know how to do n, n+1, ..., then you can AND it with -1 and the representation for 1, 2, ... n-1.
13:02:33
jcowan
("explain your problem to the teddy bear: only if that doesn't work can you talk to a human being")
13:03:35
beach
Posterdati: No, -1 is an infinite mask with all 1s in it. No need for infinite memory.
13:03:57
beach
Posterdati: And 0 is an infinite mask with all 0s in it. No need for infinite memory.
13:05:31
phoe
CL does the trick of "hey, these are the bits that actually matter, and lets pretend that all the infinite bits that come later are zero" or "are one"
13:06:12
jcowan
Yes, which means (for instance) that you cannot have a bit representation of "all the prime numbers"
13:06:16
phoe
that is how all integers in CL are actually treated, unless you are explicitly use modular arithetic
13:44:44
phoe
> When condition is non-nil, only those restarts are considered that are either explicitly associated with that condition, or not associated with any condition; (...) If condition is nil, all restarts are considered.
13:45:06
phoe
What should (restart-bind ((foo (lambda () 42) :test-function (constantly nil))) (print (find-restart 'foo)) nil) print?
13:46:21
phoe
What should (restart-bind ((foo (lambda () 42) :test-function (constantly nil))) (print (compute-restarts)) nil) print? Will the printed list contain restart FOO?
14:08:00
Bike
phoe: well, i learned something today. i didn't think the tests factored in if no condition was provided to compute-restarts, but based on the glossary entry "applicable restarts" and 9.1.4.2.3, the tests are just called with NIL
14:08:30
Bike
so you can have a restart that's never applicable if a specific condition is given. i wonder if that could ever be good for anything. doesn't seem like it.
14:08:45
Bike
also, i tried your example but thought "why bother with the print" and got an unhandled memory fault and it took me a sec to understand why
14:09:17
phoe
also, yes - you can have a restart that is never applicable if a specific condition is given, that is the whole point
14:09:35
phoe
from what I've read, it is only the case when you are dealing with a nested debugger and have therefore multiple conditions being handled in the dynamic scope
14:09:59
phoe
if you try to handle error A and this results in signaling error B, you probably don't want to see A-related restarts in your debugger
14:10:40
phoe
so, if any restarts are associated with A, they are not visible in (compute-restarts B)
14:10:44
Bike
you can add to your inference the hearsay that i have written a debugger and that is what it does
14:11:24
phoe
the most important one: the test function and association are *separate* and accounted for separately
14:11:37
phoe
therefore the restart can be associated with the proper condition, but its test function may still return NIL
14:12:10
Bike
the association is also dynamic, so in two different dynamic extents calling compute-restarts with the same condition can give you different answers.
14:12:38
Bike
and yes, i understand how this no-condition test works, i'm just failing to think of a practical scenario in which you'd ever want to do this.
14:12:50
phoe
you can rebind dynamic variables between two invocations of (compute-restarts condition) and the test function for the restarts can take the current values of these dynavars into account
14:13:22
phoe
Bike: I have found a use case for that - some restarts are only available if the dynamic environment permits them at the moment
14:13:48
phoe
like, you don't want to call restart USE-FOO-INSTEAD if the dynamic variable *FOO* that houses the FOO that you are supposed to use is bound to NIL
14:14:54
Bike
i'm talking about distinguishing (compute-restarts) from (compute-restarts condition) in such a way that the restart test would specifically want to know that the former and not the latter was done
14:15:08
Bike
for example, given my debugger, you could make a restart that was never visible to the debugger
14:15:43
phoe
you usually never want to have them visible in the debugger, since they don't get you out of it
14:15:50
Bike
okay, well, question two, why would you want restarts that don't perform an NLToC. i have never seen restart-bind in actual code
14:16:36
Bike
by next week you'll have figured out how to use restarts to implement delimited continuations
14:19:32
Posterdati
beach: wasn't my intention, you were right about numbers, but I asked about the specific problem :)
14:19:34
Bike
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/lsp/top.lsp#L1054 htere's where clasp's debugger computes restarts, for reference
14:20:15
phoe
also posting this here so I have something to search for later: an implementation of handler-case* https://plaster.tymoon.eu/view/1740#1740
14:22:37
beach
Posterdati: No, you didn't ask, but you objected to an integer being an infinite bit mask, claiming that it is limited to available memory, and I showed with an example that you can check a bit way outside available memory, but since my explanation did not seem to make sense to you, it is clear that my teaching skills need improving.
14:26:07
phoe
I was unable to find jackdaniel's code so I decided to grab CMUCL's handler-case and smash it with a rock until it looked (hopefully) nice and clean enough to the eye
14:42:46
Posterdati
beach: Common Lisp provides a true integer type, called bignum, limited only by the total memory available (not the machine word size).
14:43:17
phoe
you are talking about the important bits while beach was talking about the non-important bits
14:43:42
phoe
I think beach is well aware that the important bits are only limited by the memory that can store them
14:44:18
phoe
we can always say "let's pretend there's an infinite number of zeroes after these defined bits" and that is exactly what CL does almost everywhere
14:44:41
phoe
these N bits in this case are the significant bits, and these need to fit in memory, yes.
14:45:56
Posterdati
phoe: he stated from n to ininity which is not the case, we can hope that he can store a finite number of bits about position n...
14:46:45
phoe
if your integer has N significant bits, then bits N+1, N+2, N+3, N+4, ..., N+inf are all the same
14:46:50
Posterdati
that's was my point... I didn't realize that beach was talking about the 0 to n-1 bits :)
15:44:02
Xach
Wow, that was quick. The author says he has abandoned them due to lack of interest from users and himself.
15:45:15
phoe
Xach: does he have old versions? he could reupload them somewhere and wait for a maintainer.
15:46:14
Xach
I have old versions, but if the author has abandoned them due to lack of interest, I don't think it is good to ask them to do more work with them.
15:46:57
Xach
I will remove them from Quicklisp, and if anyone notices and cares, I will put them on sharplispers.
15:56:42
Xach
I keep a cached checkout of all vcs projects for building Quicklisp dists, so sometimes a project can disappear from its host for a long time before I notice
15:57:03
Xach
I'm going to be more systematic about fetching from the primary source every so often to detect problems with missing or moved projects.
16:57:49
jcowan
aeth: You asked about alists vs. plists: see http://funcall.blogspot.com/2013/07/alist-or-plist.html by Joe Marshall
17:00:17
jcowan
Actually, bignums may not be limited solely by memory: that was written before machine memories grew so big
17:06:39
jcowan
libgmp allows a maximum of 2^2^39, because the number of 64-bit limbs is bounded by a 32-bit signed value.