freenode/#sbcl - IRC Chatlog
Search
23:40:24
stassats
unlike C, you don't have to recompile the whole thing and restart to insert a print or a break
23:44:42
lottaquestions_
Yeah, I've heard of trace. I am still in the discovery phase of discovering the limits of sbcl and slime
23:45:20
lottaquestions_
there have been cases where I recompiled and loaded, and sbcl ignored newly added break forms
23:47:49
lottaquestions_
what I have been doing has been C-c C-k for compile and load the current buffer's file
23:51:11
lottaquestions_
To call the new code, I was restarting the frame above the frame that contains the new code
23:52:09
lottaquestions_
unless of course there is something different I should be doing to run the new code
23:53:20
stassats
and restarting frames doesn't always get the arguments right, so be mindful of that
23:54:09
stassats
compiling new code doesn't change the actual code, just the name association to that code
23:55:51
lottaquestions_
basically all I have had as pointers on how to do this is a video by a one Marco Baringer, a blog by someone with the handle malisper and a video of some other guy debugging a web server (hunchentoot maybe? not sure)
23:56:50
lottaquestions_
I wouldn't mind pointers on the subtleties of SBCL+slime to allow me to use it effectively
23:58:07
lottaquestions_
oh...<compiling new code doesn't change the actual code, just the name association to that code>
23:58:50
lottaquestions_
how do I change the actual code ? I do not mind going and reading up if there is documentation somewhere that actually explains this
1:04:59
|3b|
lottaquestions_: if you didn't try it already, higher DEBUG (with local declarations, restrict-compiler-policy, or C-u C-c C-k, C-u C-c C-c etc in slime) might give you better debugging
2:02:15
lottaquestions_
@|3b| I have this set at the beginning of all my files: (declaim (optimize (debug 3)))
2:11:44
|3b|
(though arguably bad style for any code you share with others, since it affects everything loaded after it too)
2:13:51
lottaquestions_
That's right. One thing that really puzzled me about what stassats said was that one has to stop using the old code and start calling new code.
2:15:55
|3b|
it has no effect on existing code, so a running function won't be affected by recompiling that function. only calls made after the binding is changed will see the new code
2:15:57
lottaquestions_
so say I have a function called foo, that I recompile with C-u C-c C-c, how do I get to use the new version of foo instead of the old one? stassats seemed to be saying that there is a way of doing it
2:18:25
|3b|
just not always obvious what counts as "call it" in that case, for example inlined code doesn't get automatically recompiled, and function objects (for example returned from #' ) only see the specific code from when it was evaluated, not any code associated with that name later
2:20:17
|3b|
and code interrupted by debugger/stepper/etc continues executing the old code, though sounds like you got that part. restarting something higher on the stack usually works for that (when it is calling through the binding)
2:23:01
lottaquestions_
I already experienced the function objects issue :-), and had interesting results with restarting frames ie disappearing global variables
2:23:57
|3b|
yeah, debugger isn't perfect, so sometimes you have to just exit and start from top call
2:25:21
|3b|
restarting frames doesn't help much when there is external state (files, network, destructive modification of data structures, etc), since nothing restores that state
2:26:12
|3b|
(unless you write a bunch of magic unwind-protect code to simulate transactions or something, but even that probably wouldn't help with network code)