From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Zefram Newsgroups: gmane.lisp.guile.bugs Subject: bug#16364: auto-compile noise can't be avoided by script Date: Sun, 5 Jan 2014 23:41:06 +0000 Message-ID: <20140105234106.GI30283@fysh.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1388967674 19135 80.91.229.3 (6 Jan 2014 00:21:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 00:21:14 +0000 (UTC) To: 16364@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Jan 06 01:21:20 2014 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VzxwV-0004Xc-J2 for guile-bugs@m.gmane.org; Mon, 06 Jan 2014 01:21:19 +0100 Original-Received: from localhost ([::1]:59932 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzxwV-000680-49 for guile-bugs@m.gmane.org; Sun, 05 Jan 2014 19:21:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzxNf-0005yK-Un for bug-guile@gnu.org; Sun, 05 Jan 2014 18:45:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzxNc-0002TB-KN for bug-guile@gnu.org; Sun, 05 Jan 2014 18:45:19 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzxNc-0002T5-GZ for bug-guile@gnu.org; Sun, 05 Jan 2014 18:45:16 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VzxNc-000534-9g for bug-guile@gnu.org; Sun, 05 Jan 2014 18:45:16 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Zefram Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 05 Jan 2014 23:45:16 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 16364 X-GNU-PR-Package: guile X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-guile@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.138896546719209 (code B ref -1); Sun, 05 Jan 2014 23:45:16 +0000 Original-Received: (at submit) by debbugs.gnu.org; 5 Jan 2014 23:44:27 +0000 Original-Received: from localhost ([127.0.0.1]:37213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzxMo-0004zf-An for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:44:27 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49957) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzxJm-0004tX-OM for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:41:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzxJl-0001Uz-5B for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:41:18 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:34448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzxJl-0001Uv-24 for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:41:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzxJj-0004mh-GF for bug-guile@gnu.org; Sun, 05 Jan 2014 18:41:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzxJi-0001Uh-5W for bug-guile@gnu.org; Sun, 05 Jan 2014 18:41:15 -0500 Original-Received: from river.fysh.org ([2001:41d0:8:d47f::2]:52450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzxJh-0001Ud-SE for bug-guile@gnu.org; Sun, 05 Jan 2014 18:41:14 -0500 Original-Received: from zefram by river.fysh.org with local (Exim 4.80 #2 (Debian)) id 1VzxJa-0001ZM-T3; Sun, 05 Jan 2014 23:41:06 +0000 Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Mailman-Approved-At: Sun, 05 Jan 2014 18:44:19 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-Mailman-Approved-At: Sun, 05 Jan 2014 19:21:12 -0500 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7368 Archived-At: Guile 2.0.9 has a facility to automatically cache a compiled version of any Scheme source file that it loads, and it wants the world to know about it! If auto-compilation is enabled, which it is by default, then when guile loads a file (that was not already compiled) it emits a banner describing the auto-compilation. This interferes with the proper functionality of any program written as a guile script, by producing output that the program did not intend. Working around this is tricky (discussed below). There's no straightforward way for a script to avoid the noise while being portable between guile versions 1.8 and 2.0. There's also no way to avoid the noise while actually getting the auto-compilation behaviour. In my particular case, my script makes interesting use of the read-eval (#.) feature, which means that the compilation process actually can't work. This means that *every* time the script is run, not just the first time, guile emits the banner about auto-compilation, followed by a rather misleading warning/error about compilation failure. It's misleading because it then goes on to execute the script just fine. I can demonstrate this with a minimal test case (using read-eval in an uninteresting way, just making the compiler barf by not having applied eval-when to enable it): $ cat t0 #!/usr/bin/guile -s !# (fluid-set! read-eval? #t) (display #."hello world") (newline) $ guile-1.8 -s t0 hello world $ guile-2.0 -s t0 ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-auto-compile argument to disable. ;;; compiling /home/zefram/usr/guile/t0 ;;; WARNING: compilation of /home/zefram/usr/guile/t0 failed: ;;; ERROR: #. read expansion found and read-eval? is #f. hello world $ I can turn off the auto-compilation from within the script by using the --no-auto-compile option, but that breaks compatibility to 1.8: $ cat t1 #!/usr/bin/guile \ --no-auto-compile -s !# (fluid-set! read-eval? #t) (display #."hello world") (newline) $ guile-2.0 '\' t1 hello world $ guile-1.8 '\' t1 guile-1.8: Unrecognized switch `--no-auto-compile' Usage: guile-1.8 OPTION ... Evaluate Scheme code, interactively or from a script. ... Aside from the portability concern, turning off auto-compilation doesn't actually fix the problem. If a compiled version has previously been cached for the filename of a script being run, guile will consider using the cached version even if --no-auto-compile was supplied: the switch only controls the attempt to compile for the cache. If the cached compilation is up to date then it is used silently, which is OK. But if it's out of date, because the cache was for a different script that previously existed under the same name, then guile emits a banner saying that it's out of date (implying that the cached compilation is therefore not being used). So the script's visible behaviour is defiled even if it applies the option. Observe what happens to the second script in this sequence: $ echo '(display "hello world\n")' >t10 $ guile-2.0 t10 ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-auto-compile argument to disable. ;;; compiling /home/zefram/usr/guile/t10 ;;; compiled /home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t10.go hello world $ echo '(display "goodbye world\n")' >t10 $ guile-2.0 --no-auto-compile t10 ;;; note: source file /home/zefram/usr/guile/t10 ;;; newer than compiled /home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t10.go goodbye world I have, however, come up with a truly ugly workaround. The meta option system can be used to introduce a -c option that explicitly loads the script file via primitive-eval, which does not attempt compilation. (Nor does it look at the compilation cache, so this even avoids the problem that --no-auto-compile runs into.) Running the script this way yields a different command line (visible through (program-arguments)) from that which arrives when the script is run via -s, so if the script is to process its command line, for robustness it must pay attention to which way it was invoked. All together, this looks like: $ cat t11 #!/usr/bin/guile \ -c (begin\ \ \ \ (define\ arg-hack\ #t)\ \ \ \ (primitive-load\ (cadr\ (program-arguments)))) !# (define argv (if (false-if-exception arg-hack) (cdr (program-arguments)) (program-arguments))) (write argv) (newline) $ guile-1.6 '\' t11 a b c ("t11" "a" "b" "c") $ guile-1.6 -s t11 a b c ("t11" "a" "b" "c") $ guile-1.8 '\' t11 a b c ("t11" "a" "b" "c") $ guile-1.8 -s t11 a b c ("t11" "a" "b" "c") $ guile-2.0 '\' t11 a b c ("t11" "a" "b" "c") $ guile-2.0 -s t11 a b c ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-auto-compile argument to disable. ;;; compiling /home/zefram/usr/guile/t11 ;;; /home/zefram/usr/guile/t11:7:6: warning: possibly unbound variable `arg-hack' ;;; compiled /home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t11.go ("t11" "a" "b" "c") $ guile-2.0 -s t11 a b c ("t11" "a" "b" "c") I'm not comfortable with this as a workaround. It smells fragile. Also note that though this does avoid the banner appearing for #!-based executions, it's not muffling the banner per se but actually preventing compilation. While for some programs it's desirable to prevent compilation per se (because of the compiler's limitations), there are plenty of programs that would like to be compiled and only want to muffle the banner. Losing the efficiency of compilation is potentially a high price to pay for clean output. Guile should not be emitting this banner by default. It's really not acceptable to damage the visible behaviour of a program that worked fine on older guile versions. It also, for this auto-compilation to serve as the invisible optimising cache as which it's intended, ought to keep quiet about compilation failure: the fallback to interpreting the script should be silent. Debian incarnation of this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734009 -zefram