-
Notifications
You must be signed in to change notification settings - Fork 1
/
README
66 lines (58 loc) · 2.91 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
This is dfsch - dfox's scheme implementation. It's essentialy an
embeddable scheme interpreter. For now it's still lacking many
scheme functions, but it's generally usable as embedded scripting
language.
Also, for now, there isn't any good documentation except sparse
doxygen tags in source and source itself.
An useful example how to use this library is binary `dfsch-repl'
produced by compilation, it's source is `src/repl.c'. It's simple
interactive interpreter with some additional convenience features.
Interpreter depends on Boehm-Demers-Weiser conservative garbage
collector, in theory it is possible to replace all calls to GC_MALLOC
with malloc(3) for testing on platforms without working libgc (for
example Interix), but running any non-toy code without working GC is
not good idea. Console I/O library (used by REPL and debugger) is able
to use readline, but can reasonably work without it.
Platform that is more-or-less UNIX is currently required for correct
operation. One thing is unix module which is currently always built
and does not make much sense on systems that do not implement APIs
exported by it, but it is trivial to disable this module and it's
requirements are not too critical (I believe that MS VC CRT could
almos pass as UNIX for purposes of this module). Interpreter library
itself uses pthreads in few places and module support requires
well-behaved dlopen(3). This causes problems on NetBSD where dlopen(3)
resides in ld.so and not in libdl, which tends to confuse libgc's
build process and our configure, this could probably be easily fixed,
but I currently don't have reasonably fast system with NetBSD
(Ultra 5 @ 270MHz with 64-bit only NetBSD is _REALLY_ slow). Other
known problematic platform is Cygwin where shared libraries behave in
ways that are simply beyond my understanding.
I suppose that if you want to embbed dfsch in application that is
supposed to run or NT or similar platforms best approach is to link
modified version (with stubed out/removed module support and modified
multithreading support) statically into your application. I would be
interested in patches resulting from such endeavour.
Platforms that generally work and are reasonably tested are:
* Linux 2.6 on i386
* Linux 2.6 on amd64
* Linux 2.6 on Alpha
* Linux 2.6 on Sparc (32b mode is more tested, but 64b should
work too)
Platforms where it worked last time I tried:
* Linux 2.4 on StrongARM
* Linux 2.6 on StrongARM
* Solaris 10 on sparc
Platform that almost worked last time I tried:
* NetBSD 4.0.1 on sparc (pure 64b)
- Problems with confused libgc shared library support as stated
above
* Cygwin
- General shared library magic
Platforms that simply didn't wok last time I tried:
* Interix
- No libgc port and general lack of interest on my part.
Platforms that I'm interested in:
* Linux on PowerPC
* Bare hardware
* Cross-compilation of some subset of dfsch to small embedded
platforms (e.g. AVR)