>the structure of the affi.d file indicates that it can easily be turned
>into a regular module. can it?
I was happy never to have to use the weirdos unix =
configure+shell+subdirectory infrastructure just to build my pet module =
(although that complexity maybe fine for automatic builds and such - =
many people's work). It *is* a module, but it just keeps memory of old =
times. It is, next to queens.c, CLISP's oldest module.
Similarly, when I play with extensions, I do not use the module =
infrastructure (separate directories and so). Instead I start with the =
modules by hand, much like AFFI. When it's FFI stuff, I notice code =
pieces must go into foreign.d because some stuff is not exported, and I =
move code over to there.
That's why years ago I was very upset that O(symbol) has different =
semantics inside core CLISP and modules.
>it is not built by default now and there is no easy way to do it (one
>has to edit lispbibl.d or Makefile). in fact, I am not sure it will
>compile OOTB... is anyone using it?
I am (was) almost certainly the only one.
You can move affi.d to ATTIC.
Why modifying lispbibl?? All I had to do was add one line to modules.h, =
compile affi.d (like other .o were compiled) and relink lisp.run.
I don't even need another lisp.mem! (That's why the old package issue =
that prevent using an old .mem for nothing else but a missing package =
bugged me -- I digress).
That gave me fast edit/test cycles.
>ISTR that you wanted to extend it to support UFFI and other low-level
>stuff. are you still planning to?
FFI stuff that I publicly talked about would have gone into FFI, not =
>1. turn affi into a regular C module.
Nobody is interested in that.
>2. merge its functionality into the regular FFI.
IIRC, I have a FFI:MEM-READ/WRITE-VECTOR that's beeng sleeping in my src =
tree for over a year (but there was some slight design problem with =
WRITE, so I did not publish it).
>3. remove it from CLISP.