mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-06-10 14:00:21 +02:00
3de80ed52f
* ice-9/boot-9.scm (compile-time-environment): Remove definition from boot-9 -- instead, autoload it and `compile' from (system base compile). * libguile/objcodes.h: * libguile/objcodes.c (scm_objcode_to_program): Add an optional argument, `external', the external list to set on the returned program. * libguile/vm-i-system.c (externals): New instruction, returns the external list. Only used by (compile-time-environment). * libguile/vm.c (scm_load_compiled_with_vm): Adapt to scm_objcode_to_program change. * module/language/scheme/translate.scm (translate): Actually pay attention to the environment passed as an argument. (custom-transformer-table): Expand out (compile-time-environment) to something that can be passed to `compile'. * module/system/base/compile.scm (*current-language*): Instead of hard-coding `scheme' in various places, use a current language fluid, initialized to `scheme'. (compile-file, load-source-file): Adapt to *current-language*. (load-source-file): Ada (scheme-eval): Removed, no one used this. (compiled-file-name): Don't hard-code "scm" and "go"; instead use the %load-extensions and %load-compiled-extensions. (cenv-module, cenv-ghil-env, cenv-externals): Some accessors for compile-time environments. (compile-time-environment): Here we define (compile-time-environment) to something that will return #f; the compiler however produces different code as noted above. (compile): New function, compiles an expression into a thunk, then runs the thunk to get the value. Useful for procedures. The optional second argument can be either a module or a compile-time-environment; in the latter case, we can recompile even with lexical bindings. (compile-in): If the env specifies a module, set that module for the duration of the compilation. * module/system/base/syntax.scm (%compute-initargs): Fix a bug where the default value for a field would always replace a user-supplied value. Whoops. * module/system/il/ghil.scm (ghil-env-dereify): New function, takes the result of ghil-env-reify and turns it back into a GHIL environment. * scripts/compile (compile): Remove some of the tricky error handling, as the library procedures handle this for us. * test-suite/tests/compiler.test: Add a test for the dynamic compilation bits. |
||
|---|---|---|
| .. | ||
| standalone | ||
| tests | ||
| ChangeLog-2008 | ||
| guile-test | ||
| lib.scm | ||
| Makefile.am | ||
| README | ||
This directory contains some tests for Guile, and some generic test support code. To run these tests, you will need a version of Guile more recent than 15 Feb 1999 --- the tests use the (ice-9 and-let*) and (ice-9 getopt-long) modules, which were added to Guile around then. For information about how to run the test suite, read the usage instructions in the comments at the top of the guile-test script. You can reference the file `lib.scm' from your own code as the module (test-suite lib); it also has comments at the top and before each function explaining what's going on. Please write more Guile tests, and send them to bug-guile@gnu.org. (Note that you must be subscribed to this list first, in order to successfully send a report to it.) We'll merge them into the distribution. All test suites must be licensed for our use under the GPL, but I don't think I'm going to collect assignment papers for them. Some test suite philosophy: GDB has an extensive test suite --- around 6300 tests. Every time the test suite catches a bug, it's great. GDB is so complicated that folks are often unable to get a solid understanding of the code before making a change --- we just don't have time. You'll see people say things like, "Here's a fix for X; it doesn't cause any regressions." The subtext is, I made a change that looks reasonable, and the test suite didn't complain, so it must be okay. I think this is terrible, because it suggests that the writer is using the test suite as a substitute for having a rock-solid explanation of why their changes are correct. The problem is that any test suite is woefully incomplete. Diligent reasoning about code can catch corner conditions or limitations that no test suite will ever find. Jim's rule for test suites: Every test suite failure should be a complete, mysterious surprise, never a possibility you were prepared for. Any other attitude indicates that you're using the test suite as a crutch, which you need only because your understanding is weak.