freenode/#lisp - IRC Chatlog
Search
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.
16:09:39
jasom
also be aware that malloc implementations are limited by their API; all you get is a pointer which means that you need to store the metadata next to the data. There are some allocation patterns for which this is highly suboptimal so I've seen C code with non-malloc allocators for just this reason.
16:10:02
beach
jasom: If there are big bins like that, it means that the chunks could not be coerced with others. And Paul Wilson's result makes that very unlikely.
16:10:46
beach
jasom: Yes, I totally agree with everything you say. Again, I am counting on the nursery collectors to filter the problematic stuff.
16:11:35
beach
This is even more true since the nursery collectors use a sliding GC algorithm, so that the relative age of objects that are promoted is very precisely known.
16:13:00
beach
So objects that are promoted together in the global heap are very likely used by the same point in the application. I did not include this optimization in my description, but it is described by Doug Lea: if no perfect fit is found, then the previous big block is reused again, so that objects stay together.
16:13:27
jasom
The worst fragmentation I ever saw was with a real-time allocator that was disallowed any unbounded iteration, so it never moved allocations up in bins, just down...
16:15:28
beach
How is that related to disallowing unbounded iteration? Oh, because reusing blocks would make it unable to bound the time?
16:16:16
jasom
right it would either require significant space overhead for a non-in-place store of blocks for a bin, or it would have to walk a list like yours does, neither of which was acceptible
16:17:22
jasom
then someone with a non-embedded background decided to allocate a bunch of temporary stuff in a C++ std::list early on in the program, and suddenly no large allocations were possible :(
16:27:24
Xach
Josh_2: it's a decoration, it replicates a style of town line sign that is unique to Maine, and slowly being replaced with generic signs as the old ones wear out.
16:53:18
Josh_2
sat here wondering why I can't connec to my hunchentoot site, turns out I had 127.0.0.1/4242 instead of 127.0.0.1:4242 Q_Q
17:02:15
dlowe
amusingly, slot initargs can also be in any package - they aren't limited to the keyword package.
17:02:42
dlowe
I've seen a reasonable article that we should be using non-keyword initargs to prevent collision between different users of a class
17:03:31
Bike
if you mean "namespace" like how variable and function bindings are separated, they're not in a global namespace. they're particular to the class.
17:05:56
stacksmith
Is there a place in CLHS or elsewhere that lists the separate binding spaces? I've counted 7 but would love to see an authoritative list...
17:06:47
jasom
stacksmith: I'm pretty sure there isn't anything in the spec; google "lisp-n" for lists other people have come up with
17:07:36
dlowe
lisp-1 vs lisp-2 was an interesting implementation question. This lisp-n business is just useless pedanticism.
17:08:04
dlowe
Now, I appreciate useless pedanticism as much as any nerd, but we've been hammering that this for 30 years and it's time to find some new jokes.
17:09:27
specbot
The Global Environment: http://www.lispworks.com/reference/HyperSpec/Body/03_aaa.htm
17:09:50
stacksmith
Not asking just to start an argument - I am happy with whatever n is. I actually need to know (I think) to analyze source for my project. Just knowing the symbol is not sufficient - I need to know what kind of a binding is implied, and where the binding takes place...
17:10:43
Bike
another measure is introspection tools. sbcl's interface to swank has sixteen forms of global definition that aren't sbcl specific
17:10:51
dlowe
I can make my own namespace by just making a hash table and populating it with symbol keys
17:12:09
stacksmith
Bike: could you point me to the said sbcl's swank interface? Do you mean the implementation-specific files in the swank project?
17:13:09
Bike
it's basically: declarations, packages, method combinations, classes, setf expanders, functions, compiler macros, variables, types.
17:14:09
jasom
I think that only variable, function/macro/operators, declarations and tagbody tags are lexically scoped, but I might be wrong.
17:14:14
stacksmith
Bike: functions, macros, compiler macros and setf expanders seem to share a 'namespace'...