freenode/#sbcl - IRC Chatlog
Search
10:45:19
stassats
constraint propagation of checkgen produced code can mess up the types of the surrounding code
10:46:58
stassats
thinking of solving it by introducing a new lexenv slot identifying that it is coming from checkgen and from which checkgen
11:12:45
Xach
i think it has been discussed on the mailing list but ironclad is broken due to make-ea - this affects many things http://report.quicklisp.org/2018-09-09/failure-report.html
15:08:51
Xach
Hmm, is http://report.quicklisp.org/2018-09-10/failure-report/manardb.html#manardb a manardb code error? The project seems extremely "stable" (last commit 9 years ago)
15:18:07
stassats
basically it ends up being (typecase x (simple-array x) (array (function-that-accepts-simple-vector x)))
15:20:53
Xach
During compilation, when SBCL emits sourch paths like ---> for showing notes and such, does sbcl store that kind of path info to map to a file position?
15:21:24
Xach
Bigger goal is: can I make it easier to make a compilation log clickable, so I can go from note/error/warning/whatever to source file browsing.
15:23:55
Xof
have you looked at swank/sbcl.lisp in slime? it has a compiler-note-location function which might do most of what you need
15:24:54
Xach
Right now I am working from inert logs - the process that produced the logs is long gone. But I'm willing to change that around, dump more data, or do whatever might work.
15:25:18
pfdietz
The value #<unknown immediate object, lowtag=#b1001, widetag=#x79 {21F12979}> is not of type REAL when binding SB-KERNEL::N
15:26:32
pfdietz
will submit a bug on that when a network hiccup here is resolved. might be related to the physenv code that was removed? Lots of unwind-protects in the code that did that.
15:27:55
stassats
that physenv stuff was only invoked from compile-file, and when there was a LET around the function
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