Re: [VM] Should `compile' always be visible?
Andy Wingo wi...@pobox.com writes: OK. Still I feel that it would be great to have `compile' and `compile-file' available in the default environment -- they're in the same category as `load', `eval', etc. It would also be good for scripts. But I could be convinced otherwise :) Not sure I'm understanding the discussion here... If your main target is the REPL (as suggested by use of `also' above), that can be addressed by adding `compile' and `compile-file' to (guile-user) rather than (guile), can't it? (And I thought that was Ludovic's original suggestion.) And most scripts wouldn't need to use compile themselves, would they? They'd already be compiled themselves, and would automatically pick up compiled modules in preference to Scheme code modules. Regards, Neil
Re: [VM] Should `compile' always be visible?
On Wed 25 Feb 2009 22:16, l...@gnu.org (Ludovic Courtès) writes: The 1.8 results were against the Fedora guile, and the vm results against libguile/.libs/lt-guile, run inside pre-inst-guile-env. The issue is that `pre-inst-guile-env' adds overhead, which may not be negligible when measuring startup time. Perhaps I was unclear. They were run as: wi...@unquote:~/src/guile/vm$ ./pre-inst-guile-env bash wi...@unquote:~/src/guile/vm$ time for i in 0 1 2 3 4 5 6 7 8 9; do libguile/.libs/lt-guile -c 1; done real0m0.098s user0m0.059s sys 0m0.026s I don't think there's overhead here. There certainly is if you time ./pre-inst-guile instead: wi...@unquote:~/src/guile/vm$ time for i in 0 1 2 3 4 5 6 7 8 9; do ./pre-inst-guile -c 1; done real0m0.307s user0m0.164s sys 0m0.120s Andy -- http://wingolog.org/
Re: [VM] Should `compile' always be visible?
Hi! Andy Wingo wi...@pobox.com writes: On Wed 25 Feb 2009 22:16, l...@gnu.org (Ludovic Courtès) writes: The 1.8 results were against the Fedora guile, and the vm results against libguile/.libs/lt-guile, run inside pre-inst-guile-env. The issue is that `pre-inst-guile-env' adds overhead, which may not be negligible when measuring startup time. Perhaps I was unclear. They were run as: wi...@unquote:~/src/guile/vm$ ./pre-inst-guile-env bash wi...@unquote:~/src/guile/vm$ time for i in 0 1 2 3 4 5 6 7 8 9; do libguile/.libs/lt-guile -c 1; done real 0m0.098s user 0m0.059s sys 0m0.026s I don't think there's overhead here. Right. I wasn't 100% sure what you meant. Thanks, Ludo'.
Re: [VM] Should `compile' always be visible?
Yo, On Tue 24 Feb 2009 00:44, l...@gnu.org (Ludovic Courtès) writes: Yeah, dunno. It would be great to have `compile' in the toplevel environment. OTOH it takes time. Just to be clear: I wasn't so much concerned about load time, but rather about namespace pollution and fuzzy dependencies (ambient authority). Why add yet another set of global bindings if we can avoid it? OK. Still I feel that it would be great to have `compile' and `compile-file' available in the default environment -- they're in the same category as `load', `eval', etc. It would also be good for scripts. But I could be convinced otherwise :) This is all on my laptop running at full speed, an average over 10 runs. Is it when running `pre-inst-guile', the Libtool-generated `guile' script, or the raw `guile' executable? The 1.8 results were against the Fedora guile, and the vm results against libguile/.libs/lt-guile, run inside pre-inst-guile-env. I agree that `syncase' should be loaded by default now that we no longer have to worry about its execution time. Great. We'll have to document syntax-rules at least in the manual though, and we should document syntax-case too. Not that that should block their inclusion. Andy -- http://wingolog.org/
Re: [VM] Should `compile' always be visible?
Hello! Andy Wingo wi...@pobox.com writes: On Fri 20 Feb 2009 01:45, l...@gnu.org (Ludovic Courtès) writes: Do we really need it? Guile `master' doesn't put any autoload in the global namespace, only in `guile-user-module', thus only affecting the REPL. Yeah, dunno. It would be great to have `compile' in the toplevel environment. OTOH it takes time. Just to be clear: I wasn't so much concerned about load time, but rather about namespace pollution and fuzzy dependencies (ambient authority). Why add yet another set of global bindings if we can avoid it? This is all on my laptop running at full speed, an average over 10 runs. Is it when running `pre-inst-guile', the Libtool-generated `guile' script, or the raw `guile' executable? I would like for the base language to include syncase. I think it's worth paying 6 ms. But I would keep compile as autoload, or explicitly included, until other things speed up. Maybe a useful goal would be: always be faster than Python, just because we can :-) Eh eh! I agree that `syncase' should be loaded by default now that we no longer have to worry about its execution time. Thanks, Ludo'.
