freenode/#ecl - IRC Chatlog
Search
3:23:09
mitigate
is there any reasonable way to hand bitfield packed structs in lisp? struct foo { int a:1; int b:7; }; - sizeof(struct foo) = 4 ?
3:26:30
mitigate
BTW I'm seeing "Cannot interrupt the inactive process" errors when connecting connecting to a swank server. I'm not able to debug it - I just put a handler case around (kill-thread) in (sentinel-stop-server) to work around it.
3:37:23
pjb
mitigate: so you should read the documentation of the C compiler, and translate that to normal FFI stuff.
3:38:17
pjb
mitigate: eg. if the C compiler packs the 1 and 7 bit fields into a single 32-bit int, then you can declare a defcstruct with a single 32-bit int. Then you have to know where those bits are stored? Once you know that, you can use ldb and dpb to access them.
3:57:16
mitigate
but the problem i'm having in my head is in using that info to implement (ffi-slot-value struct slot-name)
6:20:49
shakdwipeea
I am trying to create some bindings for godot engine using https://github.com/GodotNativeTools/godot_headers. This basically allows using dynamically linked libraries from godot engine.
6:22:36
shakdwipeea
From the godot_headers README, they are defining library endpoint as /** Library entry point **/
6:53:37
mitigate
i may screw up my system requiring a reboot if that happens i'll be gone for a few hours
6:54:56
shakdwipeea
Okay, the problem I am facing is when I load the so files generated from my lisp files. godot errors out with Can't resolve symbol godot_gdnative_init .
6:55:09
shakdwipeea
In my lisp files I had just defined it as (defun godot_gdnative_init (p-options))
7:06:23
mitigate
Error: Can't open display: :0 are you using ecl_init before loading the library and trying to call the function?
7:07:56
mitigate
there is more involved.. but i'm afraid i'm out of time now. i'm sure jackdaniel will help if he sees this
7:13:09
shakdwipeea
In that case then maybe I will have to write the main file (the one to be compiled to so) as a c source and then call the lisp functions from there.
7:26:16
jackdaniel
shakdwipeea: check out examples/embed directory for example how to use ecl from C module (hello.c)
7:26:59
jackdaniel
yes, you must call cl_boot (and module_init if you have compiled modules, this is also in the example)
7:28:50
jackdaniel
!notify mitigate please verify, what slime/swank version do you have (and what connection type is chosen). also if you have recompiled ecl *after* loading slime, you may want to remove ~/.slime/fasls directory. upstream slime works fine with ecl as far as I'm concerned (even for remtoe connections)
7:29:03
Colleen
Unknown command. Possible matches: 8, set, say, mop, get, have a, grant, award, time, tell,
7:29:08
jackdaniel
:notify mitigate please verify, what slime/swank version do you have (and what connection type is chosen). also if you have recompiled ecl *after* loading slime, you may want to remove ~/.slime/fasls directory. upstream slime works fine with ecl as far as I'm concerned (even for remtoe connections)
7:29:16
jackdaniel
!tell mitigate please verify, what slime/swank version do you have (and what connection type is chosen). also if you have recompiled ecl *after* loading slime, you may want to remove ~/.slime/fasls directory. upstream slime works fine with ecl as far as I'm concerned (even for remtoe connections)
7:29:25
jackdaniel
:tell mitigate please verify, what slime/swank version do you have (and what connection type is chosen). also if you have recompiled ecl *after* loading slime, you may want to remove ~/.slime/fasls directory. upstream slime works fine with ecl as far as I'm concerned (even for remtoe connections)
9:04:10
shakdwipeea
I followed the embed examples and wrote a c program including the ecl header files and then compiled that to so file.
9:04:59
shakdwipeea
but when I try to load the library. I get Can't open dynamic library ... undefined symbol: cl_symbols
9:06:21
shakdwipeea
here is the c file I'm trying https://gist.github.com/shakdwipeea/49204c5191f0e5fcf93bda518a54c624
9:10:50
jackdaniel
did you add -lecl when compiling? in general, did you provide adeqate cflags and ldflags?
9:11:22
jackdaniel
-Wl,--rpath,/home/jack/Pulpit/lisps/ecl-wip/lib -L/home/jack/Pulpit/lisps/ecl-wip/lib -lecl -lgc -ldl -lm
9:13:47
shakdwipeea
this is the command I am using for compiling and the warnings https://pastebin.com/PPRZ2740
9:14:54
jackdaniel
you need to see then why clang doesn't accept linker flags (or how to supply them)
9:16:57
shakdwipeea
I just tried with gcc .. I don't get the warnings but the library still doesn't work.
10:25:21
mitigate
ok i found pjb's article on cll on exporting C-callable functions from lisp - <87iorjqo1c.fsf@kuiper.lan.informatimago.com>
10:37:47
mitigate
shakdwipeea - you have to define a callback in lisp via your ffi's defcallback - and then arrange to have that pointer given to your C code and then call that directly
10:40:44
mitigate
see <87iorjqo1c.fsf@kuiper.lan.informatimago.com> on comp.lang.lisp - which only states that ecl doesn't export the callback
10:42:32
mitigate
when building a shared library in C the linker exports all functions so you can call it directly from lisp. The reverse mechanism isnt there - afaik
10:42:52
pjb
mitigate: what is the subject of th message? google groups doesn't let us search by message-id.
10:44:31
pjb
I was just thinking about writing a library using libecl for non-lisp programs, and wondering about the garbage collector. Would it just work on lisp objects, and let the embedding program have its own memory management?
10:46:34
jackdaniel
pjb: bdwgc replaces malloc with its own version for static libraries, afaik it doesn't do that with dynamic ones (when linked against libgc.so). *but* if you link libgc statically in libecl it shouldn't interfere
10:46:59
jackdaniel
but it will still scan memory which is not collected (conversatively), so if you reference lisp object from C it won't get removed
10:54:50
jackdaniel
*and* when ECL builds with bdwgc statically (that is compiles it to libgc.a) then it disables such redefinition and this compiled-in libgc doesn't conflict with system libgc.so whatsoever
11:02:36
pjb
so in 16.1.3, this make in this shar produce a hello.o that contains the symbols: _L1hello _LC4cffi_callbacks___hello_lib__hello_ no _hello. I guess we could #define hello LC4cffi_callbacks___hello_lib__hello_ in main.c
11:50:18
pjb
jackdaniel: as I understand it, the goal would be to be able to build a library (shared or static) with C API entry-points that could be linked (on option, alone or with the libecl, libgc (and possibly other dependencies) libraries) in a program that would be oblivious of the use of CL to implement our library.
11:51:37
pjb
(in case of shared libraries, they could be dynamically linked at compilation-time with the program, or a program could use dlopen/dlsym to use it, depending on the needs).
11:55:11
pjb
I can see 3 points to address: 1- the selection of the compilation and link options for the dependency libraries (libecl, libgc, etc); 2- definition of the FFI to be able to declare symbols that are exported by the library and symbols that are not (by default). 3- the handling of the initialization/finalization of the library, (ie. execution of the toplevel initializations, etc): we would want to specify the name of the initializa
11:55:11
pjb
function, and possibly a custom hook to be called after the initialization of the library.
11:56:02
pjb
for 3- I guess it's not a good idea to let the user define his own callback entrypoint that would call the library initialization function, since this callback would be written in lisp, so it would need the library (and ecl environment) already initialized.
11:56:49
pjb
There's also a fourth point: 4- how to deal gracefully if a program tries to link several such libraries (with some having libecl statically linked with them, and some using dynamically linked libecl)?
11:58:42
pjb
If they all use shared libecl, no problem; if they all use statically linked libecl, I guess each would live in its own ecl instance, its own heap, etc. But in general how do we deal with common resources (signal handlers, and so on).
12:00:29
pjb
In the end, perhaps we won't be able to make the use of CL (ecl) entirely oblivious to the client program, but that would be a goal, to help adoption of such libraries, (and hence trojan CL into system distributions >;-} ). Of course, on the marketting side, we may mention CL anyways (or not).
12:14:47
pjb
(Oh, no, not lisp symbols, linker symbols. And t or T are flags displayed by nm to indicate the symbol is in text (code) and t = unexported T = exported. ie. dlsym finds only symbols marked T.