Edit
IABSD.fr/xenocara/app/xedit/lisp/README
matthieu
- app/xedit/lisp/README
-
$XFree86: xc/programs/xedit/lisp/README,v 1.12 2002/11/23 08:26:47 paulo Exp $ LAST UPDATED: $Date: 2006/11/25 20:34:53 $ SUMMARY This is a small lisp interpreter for xedit. It implements a subset of Common Lisp and the xedit package implements several of the basic Emacs lisp functions. (shared modules not broken, but needs a redesign for better performance, but won't be made available in the default build probably for a long time, it would be really better to generate the interface dinamically, and/or just link agains't the required libraries and use a ffi interface) +------------------------------------------------------------------------ | It has a very simple method for loading shared modules, slightly based on | the XFree86 loader code, that is currently disabled by default. To enable it, | edit lisp.cf and change BuildSharedLispModules to YES. | | Assuming you have built it with BuildSharedLispModules enabled, you can build | a small test application can be built in this directory running "make lsp". | Two lisp programs are available in the test directory. To test the programs | run "./lsp test/hello.lsp" or "./lsp test/widgets.lsp". +------------------------------------------------------------------------ Currently, it should be used as an helper and/or a small calculator embedded in xedit. For the future it should be possible to write entire interfaces in the xedit text buffers. USAGE SUMMARY To evaluate lisp expressions, put the text cursor just after the lisp expression and press: C-x,C-e - will evaluate it, and print the result to the message window C-j - will evaluate it, and print the result to the edit window, any errors are printed to the message window. C-g - will send an SIGINT to the lisp process, and that process will stop whatever it was processing and jump to the toplevel, to wait for more input. Note that C-j will only work in the *scratch* buffer. NOTES The improvements to xedit including the several possibilites to extend the editor using Lisp are expected to allow making of xedit a versatile text editor for programming, but there is code being (slowly) developed that should also make it useable as a small word processor, for things like WYSIWYG html, etc. The xedit development is being done very slowly, maybe it will get somewhere someday, but it is a pet/hobby project, there is no intention of making of it an end user editor (the idea is to make it an useful development tool). In some aspects the development is trying to mimic several Emacs features, but there is no intention of competition (if xedit ever get something better than Emacs, I hope that it serves as a motivation to make of Emacs an even better editor), actually it is expected to explore different areas and use alternate solutions for the implementation. Most work in a computer is done in a text editor and the more the editor can help the user the better. (debugger is broken and very slow, no prevision for fixing it, but is expected to work correctly for interpreted only code) +------------------------------------------------------------------------ | DEBUGGER | | There is a, currently, very simple debugger implement in the interpreter. | The debugger is now optional, and off by default. To make it available, | you need to recompile with -DDEBUGGER. | To use the debugger, run the lsp sample program as "./lsp -d", and optionally | pass a second parameter, for the file to be interpreted. Once the debugger | prompt is visible, type "help" for a summary of options. To leave the debugger | type "continue". | Note that the debugger is still very simple, it won't work from xedit, and | won't drop to the debugger on "fatal errors". It allows adding breakpoints to | functions and watchpoints to variables. Support for changing data and going to | the debugger on fatal errors should be added at some time. +------------------------------------------------------------------------ COMPILER Now there is a very simple bytecode compiler. It is far from finished, but for simple code can show significant better performance. There is not yet an interface to compile entire files and no interface to store the generated bytecode in disk. There is an interface to bytecode compile toplevel forms as a LAMBDA NIL, but it is not yet exported. If your code needs to call GO/RETURN/RETURN-FROM as the result of an EVAL, it must jump to code in the interpreter, after compiling all calls to GO/RETURN/RETURN-FROM are just stack adjusting and jumps in the bytecode. CATCH/THROW and UNWIND-PROTECT are running as interpreted code for now, so it is safe to use these, but code in such blocks is not compiled/optimized (not even macro expansion is done, as it understands that while not compiled, everything is candidate to redefinition at any time). To compile the code, just write a function, and compile it, example: (defun fact (n) (if (< n 2) 1 (* n (fact (1- n))) ) ) FACT (compile 'fact) FACT NIL NIL (disassemble 'fact) Function FACT: 1 required argument: N 0 optional arguments 0 keyword parameters No rest argument Bytecode header: 1 element used in the stack 2 elements used in the builtin stack 0 elements used in the protected stack Constant 0 = 1 Constant 1 = (2) Symbol 0 = N Builtin 0 = * Builtin 1 = 1- Builtin 2 = < Initial stack: 0 = N Bytecode stream: 0 LOAD&PUSH (0) 2 LOADCON&PUSH [1] ; (2) 4 CALL 2 [2] ; < 7 JUMPNIL 8 10 LOADCON [0] ; 1 12 NOOP 13 JUMP 19 16 LOAD&PUSH (0) 18 LOAD&PUSH (0) 20 CALL 1 [1] ; 1- 23 LET* [0] ; N 25 LETREC 1 27 UNLET 1 29 BCONS1 30 CALL 1 [0] ; * 33 RETURN FACT There are several optimizations that should be done at some time, I don't think adding NOOP opcodes will help everywhere to make aligned memory reads of shorts and ints. It should have explicitly visible registers, not the abstraction of "the current value", so the code generator can choose register allocation for loop control variables, commonly used variables, etc, for example. Jumps should have 3 types: byte relative, 2 bytes relative and 4 bytes relative. For now there is only 2 byte relative jumps, byte relative jumps can show a significant performance increase, but they are disable until it is decided how inlined functions will work, if it just updates the bytecode header and cut&past the bytecode, jumps must be updated, and some jumps may not fit anymore in a byte. OPTIMIZATION There are plenty of possibilities to make the interpreter run faster. Some optimizations that can make it run quite faster in certain cases are: o Better object memory layout and gc. The current memory allocation code is very bad, it try to keep 3 times more free objects than the currently used number, this can consume a lot of memory. The reason is to reduce the gc time cost so that it will in average miss only one in every 4 collect tries. o Implement real vectors, currently they are just a list, so it cannot just deference a given index, and gc time is very long also. o Most lists are never changed once created, it could somehow add an index field in the cons cell, so that NTH/NTHCDR/LENGTH like code could just deference the correct object, instead of traversing the CDR of every cons. This would probably require implementing lists as vectors, while making it easy to deference would make life harder when deleting/inserting sublists in a list. It should also better be done in a way that does not require a lot of objects allocated linearly. HELPING Send comments and code to me (paulo@XFree86.Org) or to the XFree86 mailing/patch lists. -- Paulo