IRC channel logs
2026-09-28.log
back to list of logs
<ArneBab>mwette: Would I have to prepare each one of them, so most of my code wouldn’t be open for hacking in the REPL? <old>I'm not following what is your usage of the coop REPL. <old>I see two usages. One is developping, in which case you probably want optimization off, like gdb -O0 -g <old>the other case is production trouble-shooting, in which case you want the optimization and well it's normal if thing were optimized and you can't access them <old>a third case is perhaps a sandboxded REPL for a video game or something like this <old>in any cases, you probably want to control the optimization level ahead <mwette>old: Does reload-module reload downstream dependent modules? <old>I haven't look at it, but apriori I would think it only force reloading the module from disk <old>mwette: right reload-module is very trivial <old>it does a exursion into the target module and reload the source file in it <old>I think that one could hook up BLUE in a way to auto-reload module on file chance, tracking macros/inline procedure changes <lechner>Hi, what's the recommended way to invoke code at a known location in the file system, please? Is there something other than "load"? <rlb>There's primitivel-load. <lechner>rlb: Thanks! Doesn't that do practically the same thing? <rlb>Oh, sorry, I was thinking about load-from-path, not load. <sneek>I've been faithfully serving for one month and 2 days <sneek>This system has been up 6 weeks, 6 days, 5 hours, 17 minutes <old>great I made call-with-stack-overflow-handler restartable .. <old>I have to think about how to make time-limit now working <old>I think I can make it work with the help of POSIX timer