freenode/#lisp - IRC Chatlog
Search
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'...
17:15:44
Bike
the clhs page on lexical environments includes blocks also, but that's pretty much the same as tagbody tags
17:29:11
stacksmith
Bike: right, but is the dynamic binding separate from other bindings for that symbol?
17:31:46
stacksmith
I am now up to 10. 1) var/symbol-macros 2)fun/macro 3)compiler-macro 4)setf expander 5)classes/types 6)restarts 7)method combinations 8)declarations 9)tags 10)blocks
17:36:38
stacksmith
Bike: looking at source, it does not seem to matter. depending on context, some symbols require a lexical 'search' for the binding site and if not found, have a global meaning. Others are lexical-only - like tags. And slots names come from classes. I think.
17:39:38
stacksmith
I was trying to use the sbcl walker but it seems to skip some parts of source, and does not provide information about _where_ the bindings actually take place.
17:41:48
stacksmith
In some situations, like refactoring names, you want to identify the origination of names.
17:51:23
stacksmith
The location of the lexical binding site in source affects the meaning of symbols with that name in the subtree of the source. Knowing the namespace of a reference is important - you dont want to rename a tag with the same name as a lexical variable, for instance. Or a global variable. Hence the conflation of global and lexical bindings.
18:04:06
stacksmith
CLHS says "If a define-setf-expander form appears as a top level form, ..." which seems to imply that it may be used inside a definition, but the scoping is not clear...
18:10:34
stacksmith
Bike: what does it mean if the form is not a top level form? I am confused. Could you elaborate on how lexical function bindings affect setf bindings?
18:23:50
stacksmith
Yikes. Call me dense, but what the heck happens if a defining macro is inside another definition? It appears that there are no compile-time effects for that form (or the rest of the file), but at some later time - like the next file?
18:25:18
jasom
the compiler need not store the definition of it, so strange things can happen. Ultimately just don't do that
18:27:17
jasom
stacksmith: from a practical point of view, your analysis tool could be free to reject code with non-toplevel defmacros
18:28:15
stacksmith
jasom: is there a reason the spec doesn't just say that defining macros _should_ be toplevel? Is there a situation where it is useful otherwise, or would be problematic if so stipulated?
18:28:22
jasom
non-toplevel DEFUNs have some uses (e.g. a defun inside a let), but I'm strugging to think of any use for a non-toplevel defmacro
18:30:37
Bike
stacksmith: if it's not toplevel it doesn't have the effects described if it's toplevel, namely, being done at compile time. the same as any other form, its effects will occur when it's executed. so if it's in a function body, the global macro binding will be made when the function is called and control reaches the defmacro form.
18:40:52
stacksmith
Usually you don't macroexpand at runtime, I suppose. But binding a global function at runtime is valid, isn't it? CLHS states that there are no compile-time side effects for defun and the definition is not even available. So a defun deep inside another function body will get compiled with the surrounding function but bound when the surrounding function is executed, correct?
18:42:53
stacksmith
I mean when the inner defun is reached, of course, not just the surrounding function.
18:44:27
jasom
there are limitations to redefining functions though, related to the rules of when it is permissible to inline
18:45:23
jasom
but yes, (funcall 'foo) (defun foo () ...) (funcall 'foo) ;; <-- the second funcall will get the new definition of foo
18:48:24
jasom
you provably cannot do a lot of useful static analysis on unrestricted CL code, so you'll need to determine a subset you are going to work with
18:56:57
stacksmith
Ideally I would restrict the subset to thing actually defined by the standard, but sometimes it's a little hard to figure out as I am only an egg.
19:02:54
stacksmith
jasom: I am assuming modern compilers know that you are fiddling with a global function binding, whether it's by setfing fdefinitions or defunning inside a function body, and compile an indirect call. It seems in some cases you can make it impossible to figure out, which should also default the compile to a runtime-safe behaviour. But is there a CLHS restriction of where defun may be located, if not at toplevel?
19:15:52
stacksmith
Is there a static analysis library for CL? I haven't found much - and I can see why...
19:19:37
stacksmith
There are more problems than I ever imagined. A walker almost does the trick, but the walkers I've seen do not correlate source forms to walked forms or provide adequate hooks to definitively walk a form and identify every subform.
19:24:16
pfdietz
A source object can occur more than once in a form, so any such linkage would require some representation of the path down to the objecr.
19:26:48
stacksmith
Ideally, the walker would literally walk the source tree with a callback on every cons, providing environmental info and data about the car. I don't care about macroexpansions other than the side-effects such as new bindings, etc.