freenode/#sbcl - IRC Chatlog
Search
15:31:40
Xach
stassats: what might that mean? like that there would be more data, or side data, to map to file positions or lines or something?
15:39:13
Xof
so you'd "just" need something like (handler-bind ((condition (c) (progn (log (sb-ext:condition-location-info c)) nil))) (ql:quickload ...)) to get hold of and record the information
15:39:39
Xof
[ for clarity for readers of logs: sb-ext:condition-location-info does not currently exist ]
15:44:35
pfdietz
I would love having conditions traceable back to where they were signaled. Useful for test generation and distinguishing different failures (stack inspection in the handler-bind function would also help with that.)
16:57:45
pfdietz
It was up to date with git pull. Anyway, the bug went away when I built with a more recent sbcl (had been using 1.3.2 for some reason).
17:41:08
makomo
how would one use sb-walker to, for example, enumerate all of the functions called within a body of code, excluding any locally defined functions with FLET/LABELS?
17:42:48
makomo
well, something application-specific. i have a DSL where i need to, before evaluating any code, "preprocess" that code to find all the calls to a certain function in order to build the model of the system
17:43:43
stassats
i don't trust sb-walker, so i would've hooked into IR1, but that's probably not suitable for you
17:43:51
makomo
it's a bit like VHDL, except that the processes use arbitrary lisp code. i need to find all calls to the function "<-" because i want to register those processes as drivers for signals
17:46:45
stassats
maybe it's adequate enough, but just the fact that it's not used by the compiler makes me not trust it
17:47:45
makomo
yeah, now i'm suspicious as well. it does look like pretty old code though, looking at the comments
17:48:00
makomo
but still, i'm not sure how i would fetch all of the functions called using sb-walker
17:51:41
makomo
stassats: i've thought of that before, but thought it might not be possible in my case. maybe my DSL design is wrong. for example, a component definition looks like (defcomponent some-component () (:process <body>))
17:55:52
makomo
stassats: so i guess it's a DSL mixed with lisp code. i can't just substitute <- in this case since that portion is within the lisp code. i would like to not miss any signal assignments which might be buried under macros and such ("<-" is signal assignment)
17:56:17
makomo
it can't be a function since i need this information before actually executing the code, to setup the model, etc.
17:59:14
makomo
perhaps i could put the body of a process within a lambda, let the compiler do its work and register this special information during macroexpansion
18:00:51
makomo
i guess i don't need the number of expansions though, i would just use the signal's name and a hashtable or something
18:03:49
makomo
but doing this at macroexpansion-time gets me into trouble with the compiler environment then :(
18:04:44
makomo
everything would have to be loaded before a component could be defined for guaranteed results
18:06:52
makomo
then again, that might not be that bad since the point of the program is to process these definitions at run-time, and not for them to be compiled along with the program itself
18:07:40
makomo
stassats: i guess, but i would just like to avoid these half-baked solutions if possible
18:08:16
stassats
you fully bake it by iterating and not spending too much time thinking over an issue
19:39:40
Xach
http://report.quicklisp.org/2018-09-10/failure-report/cl-python.html#clpython is a new one to me!
19:39:51
Xach
caused by this, i think: https://github.com/metawilm/cl-python/blob/master/lib/thread.lisp#L134
22:52:00
makomo
oh right, they're right after the ANSI ones: https://github.com/sbcl/sbcl/blob/master/src/pcl/walk.lisp#L470
22:55:08
drmeister
Ok - thanks - I have sbcl 1.4.10 installed using brew on macOS - I'll investigate why that script doesn't work.
23:31:36
drmeister
I'm not - do you see what I'm doing wrong? It's starting up a shell and not sbcl.
0:14:59
stassats
and splitting and joing blocks is O(N) on nodes, because it has to update (ctran-block ctran)