162db537d8
Switch the 5 top-level outlier modules to configure-provided substitution
(same template as the rest):
srcdir = @srcdir@
VPATH = @srcdir@
MAGICDIR = @top_builddir@
Their custom rules and ${MAGICDIR}/${MAGICSRC} references keep working:
${MAGICDIR} = @top_builddir@ (build top), $(srcdir) now from @srcdir@.
scmos/doc still recurse into their (static) children via -f.
Verified out-of-tree: full `make` rc=0 -- magic gets srcdir=<src>/magic,
tclmagic.so + scmos techs + 27/28 docs build.
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$