libera/#ecl - IRC Chatlog
Search
10:27:00
psilord
Is there a TODO list, or a pile of issues or anything like that to help direct people that might desire to poke ECL and add features?
10:28:48
jackdaniel
for example mine is: 1) integrate fast gf (basically finished for over 6 months, but needs final touches - that is 90% of work); 2) add the type inferencer
10:31:08
jackdaniel
regarding embedding c code you may use c-inline and clines (the latter is for top level forms)
10:31:19
jackdaniel
if you are interested in a more complete example, see contrib/sockets/sockets.lisp
10:32:26
jackdaniel
if you spot forms like @(return 0) = err; - it is a syntactic sugar provided by dpp (preprocessor shipped with ecl)
10:32:59
jackdaniel
another example is @"lisp string" and @symbol or @[symbol] (the last one returns the symbol value)
10:33:40
jackdaniel
and as for c-inline, things like #0 #1 #2 are lisp arguments supplied to the form (it is documented)
10:35:28
jackdaniel
there are other interesting ffi abstractions defined in the file src/lsp/ffi.lsp
10:36:53
psilord
Thank you for your time to explain stuff tonight jackdaniel. Time for bed for me. Night!
10:37:04
jackdaniel
it may be also somewhat of interest, but ecl fasls compiled with the main compiler are libraries (.so, .dll etc, depends on the platform)
11:22:24
selwynning
ive been reading more about gc on wasm and it seems that others have arrived to similar conclusions wrt simulating the stack (other suggestions include a shadow stack)
11:32:21
jackdaniel
because when you throw, then the catch must be sticked somewhere in the environment (and that applies to other things too)
11:36:51
jackdaniel
(I didn't read into this stuff for some time so I may confuse concepts - sorry!)
11:38:09
jackdaniel
or maybe not? perhaps we should build our own stack that needs to be "reinstated" when ascyntify returns
11:38:46
jackdaniel
either way asyncify seems to be a key feature that will allow managing the dynamic context
14:15:47
selwynning
are there any dependencies aside from libffi and bdwgc that are likely to need porting?
14:17:27
jackdaniel
ecl dependencies are: libffi (optional, requires porting), threads (optional, requires porting), bdwgc (required, requires porting), gmp (required, has portable "C" implementation)
14:18:06
jackdaniel
there are also platform specific bits in files unixfsys.d and file.d and they may need porting
14:18:29
jackdaniel
but from dependencies I think that only bdwgc must be ported (and libc for exotic platforms without it)
14:19:49
selwynning
libffi is somewhat of a lower priority since im ultimately aiming to run in a sandbox, but i will at least think about it eventually
14:20:37
jackdaniel
if you can afford cross-compiling ffi bindings along with ecl, then libffi is not strictly required
14:28:04
jackdaniel
regarding a "simulated stack", note that we already do something like that - we have a lisp stack in the interpreter
14:28:33
jackdaniel
we have also a frame stack that is shared by all runtimes (these frames basically represent return points)
14:28:55
jackdaniel
and there is ihs frame stack (debugging stack to keep track even of inlined lisp functions along with their "real names")
14:29:49
jackdaniel
these things have somewhat extensive comments in appropriate files (stacks.d stacks.h environment.d etc - I might have missed some)
18:56:43
selwynning
if we build without cmp - will ecl write any files anywhere during normal operation
19:28:29
jackdaniel
so you could i.e point a logical pathname to an in-memory vector and have it working like a file
19:44:02
selwynning
i did think it would be nice to mix logical pathnames with this virtual filesystem stuff
20:03:56
selwynning
tempted to simply turn off gc by defining gc_malloc to be malloc and seeing if ecl builds
20:46:43
jackdaniel
it initializes stacks and the environment, if there are any top-level forms that need to be executed at startup - they are
20:48:01
jackdaniel
about 10 functions initializing different modules, they are nicely named like init_gc, so you may look it up easily