Albrecht Kadlec <albrecht_at_auto.tuwien.ac.at> writes:
> o) I still would like the interpreter to be optional / transient /
> permanent / split / in a shared library.
>
> For most people it's enough to set variables. So they only need
> either
> a config data dump to be read in at startup or
> a transient interpreter, which terminates after setup
>
> If you use lisp functions or hooks you can still benefit from
> a split ascii-to-bytecode translator & bytecode interpreter.
>
> All the junky tokens & syntax tables are in the translator
> and are therefore dumped after reading and parsing the
> config info.
>
> This also speeds things up considerably, since only
> bytecode is executed.
>
> Only in the case that an external program outputs ascii lisp
> commands to be executed by fvwm or eval() is used, this has to be
> fed through the translator.
>
> So the ideal layout would be core fvwm with an option (or command) to
> speedload a variable image, and for complex commands a split bytecode
> interpreter and ascii-to-bytecode translator.
>
> The bytecode interpreter has to be some sort of library. Getting/putting
> common functions from/into a dynamically loaded shared library would be
> great. It will usually be swapped out / unloaded after not being
> accessed for a while.
>
> The translator (Tokenizer / syntax checker) can be either shared library
> or external. Both ways it will be dumped, when it's not used for a while.
Sounds like a good plan to me.
--
Brady Montz
bradym_at_cs.arizona.edu
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu May 07 1998 - 15:51:35 BST