freenode/lisp - IRC Chatlog
Search
10:10:23
flip214
sprof still gives me 10.7% of time in SB-DI::FILL-IN-CODE-LOCATION ... isn't that called only when compiling?
11:41:46
dlowe
flip214: usually declaring a function as inline and setting optimize speed to 3 is sufficient
11:42:15
dlowe
you may have to reduce the debug optimization because inlining will interfere with backtraces
11:59:14
dlowe
Macros are more error prone, kind of the wrong level of abstraction, and can introduce loading order problems if you call any user-defined functions.
11:59:42
dlowe
On the other hand, using them for inlining has a nice certainty that dicking around with compiler settings doesn't
12:29:20
Shinmera
There are situations where it's useful for the compiler to be able to ignore them.
12:33:13
no-defun-allowed
The only change to semantics that inlining provides is that redefining that function doesn't have to work "properly", so a conforming implementation could ignore inline declarations and everything would work fine (albeit slightly slower).
13:18:31
dlowe
No, no, if I specify a thing that isn't default behavior and the compiler can't do it, I want a noisy failure
13:20:54
dlowe
(bonus if the compiler also makes noise if I'm trying to redefine an inline function)
13:21:19
dlowe
(all the bonus points if it keeps an inline function dependency tree to automatically recompile when needed)
13:26:18
phoe
"Only an implementation that was willing to be responsible for recompiling f if the definition of g changed incompatibly could legitimately stack allocate the list argument to g in f."
13:52:16
jackdaniel
https://gist.github.com/dkochmanski/959ec9ea865ea5e53c58c154f936fcb6 (an implementation sketch of conformally displaced arrays)
14:03:00
Xach
axion: http://report.quicklisp.org/2020-06-02/failure-report/doubly-linked-list.html#doubly-linked-list
14:24:04
Xach
fe[nl]ix: let me know if the travis-ci update suffices. the process confused me more than i expected so I might have done it wrong.
14:24:33
dlowe
Xach: I got a funny error on local-time where sb-bsd-sockets wasn't able to be required
14:24:57
dlowe
Xach: the problem is that stefil sucks in swank, which tries to require sb-bsd-sockets
14:24:58
Xach
dlowe: that was due to a bit of whiplash with how SBCL_HOME works, should be fixed now.
14:25:34
Xach
ACTION wonders about having state and 1) only reporting new errors and 2) reporting when errors are fixed.
15:03:03
srazzaque
Curious question for all: in situations where you're consuming a library that de/serializes messages from <some format>, would you prefer the representation be in a (a) plist or a (b) alist, or (c) a CLOS object (assuming these messages are not particular large, <100 key-value pairs)
15:04:50
dlowe
if the messages have a defined schema that doesn't change a lot, I'd prefer a CLOS object
15:05:28
dlowe
if the messages could contain anything (like a JSON blob) I'd probably prefer a plist or alist
15:08:12
srazzaque
I made the decision early on to go with CLOS objects for something I'm working on, but complexity and compilation times are getting, a bit high...
15:10:53
dlowe
you could be solving complexity in one spot instead of adding complexity all over, I can't tell from here
15:53:55
srazzaque
dlowe: it's definitely something I need to think through a bit more, but perhaps not at 2am :-)
16:39:06
fe[nl]ix
jackdaniel: see my comment on https://github.com/sionescu/bordeaux-threads/pull/69