IRC channel logs
2023-04-18.log
back to list of logs
<unmatched-paren>is there some %whatever variable i can set to disable the auto-compile messages when i use LOAD? <unmatched-paren>seems like there isn't, looking at boot-9.scm; i'll just disable auto-compilation <ArneBab>RhodiumToad: I want to disable them, too, because they are totally annoying :-) <unmatched-paren>RhodiumToad: i was trying to load scheme files within a scheme program, a bit like guix does with guix.scm files etc <old>GUILE_AUTO_COMPILE=0 ? <old>%load-should-auto-compile <Arsen>don't those variables work as (%foo newval) <old>they aren't parameters no <Arsen>so (%load-should-auto-compile #f) <Arsen>hm, I must've been thinking of something else then <old>unmatched-paren: maybe %load-verbosely ? <mwette>I used to patch guile to suppress all the messages. <old>Seems like a lots of user find the warning anoying more than useful <old>not the first I heard about this here <unmatched-paren>looking at the guile source code modules/ice-9/boot-9.scm, it seems the warning procedure is run unconditionally <old>warning ;;; compiling? <old>maybe you can replace the binding <old>what is weird is that %load-should-auto-compile is #t in my REPL <old>but it's actually called in boot-9.scm <unmatched-paren>agh, scm_puts(";;; compiling ", ...) is in do_try_auto_compile(...) with no way to disable it <old>Because #t is not a procedure. seems like the value is changed somewhere to #t <RhodiumToad>%load-should-auto-compile is not %warn-auto-compilation-enabled <old>ahh nvm it's in a cond <old>so %laod-should-auto-compile is actually the condition that's okay <unmatched-paren>(call-with-output-file "/dev/null" (lambda (/dev/null) (parameterize ((current-warning-port /dev/null)) ...))) <old>yes but you loose valid warnings that way <old>such as compilation warning <old>You could instead do (call-with-output-string (lambda (port) (parameterize ((current-warning-port port)) ...))) <old>and then parse the result to remove any warning that are noise <old>What I meant is that the Guile compiler emit warning such as "undefined variable" <old>which might be of interest here when loading a file <unmatched-paren>so it doesn't matter if there are warnings during compilation, there will be exceptions thrown during execution <old>well sure if that's okay for your use case why not <unmatched-paren>of course i still think there should be a way to disable that unnecessary information <unmatched-paren>(also, i think it should be possible to obtain those warnings as Scheme data, so you can print them however you like) <unmatched-paren>like, make COMPILE-FILE throw a continuable exception whenever there's a warning <unmatched-paren>and then the handler can print it and resume the compilation process <old>that or configuring a hook <old>that replace the default behavior <old>(%on-warning (lambda (msg) #f)) ;; Be quiet! <old>Make it a parameter and you have the same thing as continuable exception <old>without the expensive longjmp <ArneBab>old: those undefined variable warnings are extremely useful, just the auto-compile messages are mostly noise. <ArneBab>they can be a hint that pre-compilation failed, but when I want to ship a commandline program, I don’t want it printing implementation details. <ArneBab>the same when I develop locally: I see from the startup delay that it’s compiling, but the messages obfuscate the messages I really need to see. <mwette>maybe add a current-info-port and let peeps direct that to a file <mwette>compile messages go to current-info-port <old>ArneBab: I know. That's why I don't mask the warning <old>however, some warnings are pure noise that should not be mangled with actual warning of compilation <old>Having different ports would be great <old>current-compilation-warning-port perhaps <ArneBab>I tried once to get the need-to-recompile messages to be off by default, but got lost trying to wrap all instances … <ArneBab>I think it would be good to have compilation-need-to-recompile disabled by default to make it much easier to share small executable scripts without explicit compilation step. Using -e '(module-name)' has the lowest startup time, but it causes compilation messages to show up. <mwette>unmatched-paren: I think you missed the "add" in my statement