2b4fcf5968
rules.mak has no @...@ substitutions, so there is no reason to copy it into
the build top. Point all 38 subdir Makefile.in includes at the source copy
directly -- ${MAGICSRC}/rules.mak instead of ${MAGICDIR}/rules.mak -- and
remove AC_CONFIG_FILES([rules.mak:rules.mak]) from configure. defs.mak (the
one make fragment with substitutions) remains the only generated file in the
build top. readline/ and the top Makefile never included rules.mak, so they
are unaffected; AC_CONFIG_SRCDIR(rules.mak) (the srcdir sentinel) is kept.
Now editing rules.mak in the source tree takes effect without reconfiguring.
Verified rc=0, 375 files, both in-tree and out-of-tree; out-of-tree build
top has no rules.mak; distclean rc=0.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| scm | ||
| Makefile.in | ||
| README | ||
| lisp.h | ||
| lispA-Z.c | ||
| lispA-Z.h | ||
| lispArith.c | ||
| lispEval.c | ||
| lispFrame.c | ||
| lispGC.c | ||
| lispIO.c | ||
| lispInt.h | ||
| lispMagic.c | ||
| lispMain.c | ||
| lispParse.c | ||
| lispPrint.c | ||
| lispString.c | ||
| lispTrace.c | ||
| lispargs.h | ||
README
This is a mini-scheme interpreter, even though the files are all named
lisp*.{c,h}.
This interpreter is *extremely* slow. I can think of lots of ways to
improve its memory usage and performance (a factor of 5 improvement
seems easy), but it is very robust and it works. :) Besides, it turns
out that the bottleneck in most common tasks is magic itself, not the
interpreter.
The memory usage of this interpreter is ridiculously high. Collect garbage
often. :) Garbage collection is done automatically based on the
variable scm-gc-frequency at the top-level . . . i.e., when you see
magic's ">" prompt. To collect garbage at intermediate points in the
computation, you have to call "collect-garbage" explicitly.
-Rajit Manohar <rajit@csl.cornell.edu>
Computer Systems Laboratory
Cornell University
Ithaca NY 14853
http://www.csl.cornell.edu/~rajit/
$Header$