freenode/#lisp - IRC Chatlog
Search
4:51:34
beach
A new version of the specification of the SICL memory allocator is now available in case someone feels like reviewing it: http://metamodular.com/allocator.pdf
6:43:53
beach
shrdlu68: I think that book has some very deep insight. It is quite hard to read though, so I am taking my time. But it has already given me some interesting understanding of some parts of society that concern me.
6:47:07
beach
shrdlu68: I don't know whether the author is going to mention it, but it occurred to me right away that commercial software development is an inadequate equilibrium, which is why free software is often able to do "better" in terms of some quality metric.
6:51:07
shrdlu68
beach: Indeed, the book made me appreciate how powerful behavioral economics is at creating useful models of complex systems.
13:27:59
dim
mmm, how to debug a “Control stack exhausted (no more space for function call frames).” when you can't reproduce the bug?!
13:31:23
phoe
if there's a function or a group of functions that keeps on repeating, that's where you need to look
13:32:32
phoe
if you can't reproduce it then it's not an issue; if you can reproduce it, then you can get a stacktrace
13:33:16
dim
pgloader is a little different from other CL systems, it's an application that I'm not typically the user of
13:34:13
phoe
if the user reports a bug, then they should give you the respective stacktrace as a part of the bug report.
13:36:33
dim
oh I see, the error is caught in the handler-case, not the handler-bind, somehow, preventing the stacktrace from being printed out...
13:36:55
jmercouris
is there any way to get the path of the currently running lisp image? (from a saved binary)
13:38:24
phoe
dim: the first thing I saw when I looked at that was "handler-case on top of handler-bind... this sounds fishy"
13:48:34
Bike
https://common-lisp.net/project/asdf/asdf/Miscellaneous-Functions.html not for executables, tho
13:51:08
sjl_
shinmera's deploy does this https://github.com/Shinmera/deploy/blob/7bd96ba3f88a424e03394de1adadf4a4993f849c/toolkit.lisp#L77-L80 for its resource directory
14:07:21
phoe
I was looking for a library that would allow me to do things like https://plaster.tymoon.eu/view/852#852
14:07:38
phoe
Where I can define individual steps, and elsewhere declare how they depend on each other and in which order they should execute
14:08:38
phoe
And also define the classes of the things I call waves* here, so they'd do different things depending on their classes
16:03:34
jasom
beach: read the allocator description; looks like a reasonably sane malloc implementation. The only "gotcha" I see is if that some allocation patterns could generate very large bins.
16:04:17
jasom
of course if those allocation patterns are unlikely in real-world code it's probably a non-issue.
16:05:43
beach
I don't know. But this technique is from Doug Lea and it is known to be the best one around.
16:06:08
Xach
Josh_2: No, it was a sign. The design and layout was done in lisp (including parsing curves out of the font file) and a lisp program emitted a vector file for a vinyl cutter.
16:06:33
beach
jasom: Plus, I will catch many short-lived objects in the nursery. Objects that get promoted to this heap are likely to be long lived.
16:06:59
Xach
(The font was a unique one I commissioned from a font designer, but that part wasn't lisp)
16:08:11
jasom
Right, but real world mallocs are ultimately about heuristics; if you have linear probing of unbounded length linked lists, there is the potential for slow performance, so it's all about choosing an algorithm where that is unlikely to happen.
16:08:17
beach
jasom: I think it is virtually impossible to judge an an allocator or a GC from the looks of it. So I intend to put in "meters" in the code. The size of bins would be an obvious candidate.