IRC channel logs


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
<RhodiumToad>why do you want to disable the message?
<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
<unmatched-paren>but then i realised i don't really need auto-compilation
<RhodiumToad>or --no-auto-compile on the command line
<unmatched-paren>old: yup, i've SET! that to #F
<old>does it work?
<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.
<unmatched-paren>old: i saw that; i don't think that does it
<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
<unmatched-paren>ACTION looks again
<old>which procedure?
<old>warning ;;; compiling?
<unmatched-paren>it's defined in C though
<unmatched-paren>libguile/read.scm, i think
<unmatched-paren>sorry, load.scm
<unmatched-paren>SCM_DEFINE (scm_sys_warn_auto_compilation_enabled, ...)
<unmatched-paren>line 1092
<old>maybe you can replace the binding
<old>to just (const #t)
<unmatched-paren>hmm, yeah, that's a good point
<old>what is weird is that %load-should-auto-compile is #t in my REPL
<unmatched-paren>agh, there's still more messages
<old>but it's actually called in boot-9.scm
<RhodiumToad>why is that weird?
<unmatched-paren>agh, scm_puts(";;; compiling ", ...) is in do_try_auto_compile(...) with no way to disable it
<unmatched-paren>ah well
<old>Because #t is not a procedure. seems like the value is changed somewhere to #t
<RhodiumToad>you're confusing two different symbols
<unmatched-paren>disabling auto-compilation works fine for me
<RhodiumToad>%load-should-auto-compile is not %warn-auto-compilation-enabled
<unmatched-paren>actually, wait
<old>ahh nvm it's in a cond
<old>so %laod-should-auto-compile is actually the condition that's okay
<old>make sens
<RhodiumToad>yeah, it's used as a value, not a procedure
<unmatched-paren>okay, i figured out how to "disable" it
<unmatched-paren>(call-with-output-file "/dev/null" (lambda (/dev/null) (parameterize ((current-warning-port /dev/null)) ...)))
<unmatched-paren>i mean, it works!
<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
<unmatched-paren>i have an exception handler that wraps errors from LOAD
<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!
<unmatched-paren>that would also work, i suppose...
<old>Make it a parameter and you have the same thing as continuable exception
<old>without the expensive longjmp
<ArneBab>wingo: wuff
<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
<unmatched-paren>mwette: seems to go to current-warning-port, no?
<unmatched-paren>current-info-port is unbound in my repl
<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