Re: GSoC status report

[<Joe...@t-...>]

Hi,

Daniel Jour wrote:

>AFAIK the FFI is a pretty important piece of CLISP, so I guess it should "stay", right?
Yes. It seems to me like most people have a use for it.

>(It's - according to the self tests - working, at least on linux)
Did you mean the Lisp level FFI tests or the C tests part of the libffcall library?
Did you build the ffcall library on your own or use the binary package from the distribution?

>Are there any known "out of tree" modules for CLISP?
You mean written by other people and not in the CLISP source? I can't remember of
any such mention in the mailing list. Presumably, people just used the ability
to dynamically load a foreign library (as in other Lisp implementations),
without creating a module structure.


>CLISP can be build in quite a few different configurations.
>* ffcall
+2 See above

>* dynamic modules
There used to be a possibility to use that without ffcall, but nowadays the
Lisp packages seem to use a mixture of both. The low-level stuff for dynamic
modules (linking of object files) should not be problematic, but individual
modules may have trouble interfacing with their respective libraries as the
latter ones will have evolved (e.g. libSVN, Oracle, GTK etc.) during the
last 6 years.

Effort here very much depends on how many other packages you are ready to
install, then test.

These should be unproblematic (but please ask Sam, he knows better), thanks of
few or old dependencies:
 +1 rawsock (mentioned every so often in the mailing list)
 +1 FastCGI
 + POSIX RE
 + zlib (highly subjective)

 ~ syscall may be important to several users, but may need updates, as the Linux kernel evolved;
 ~ PCRE certainly got a new API meanwhile;
 ? Oracle
 ? Postgres
 ...

>* unicode
+2 I believe this needs libiconv (except on the MS platform). Probably it doesn't
Make sense in 2016 to release something that does not support encodings.
I can't remember much trouble building with encodings.

>* readline
+1 Excellent for comfort. Has never been a problem getting it to run AFAICR.
Not needed with SLIME or withint Emacs, but I don't know whether current SLIME
still supports CLISP (I haven't heard about CLISP in the SLIME mailing list
for a long time).

>* threads (POSIX, WIN32, SOLARIS?)
Still not 100% ready, issue with hashtables IIRC. Don't try and debug this for now,
that would be another project IMHO.

>* jitc (lightning)
Can't remember, was that subproject led to completion?


>Then, CLISP can also be build without libsigsegv. What configurations are the most interesting ones?
+2 A CLISP release should not be built without libsigsegv. Libsigsegv is required
for generational GC, and a CLISP without genGC is an order of magnitude slower
than when it's available.
OTOH, better without genGC than no CLISP at all. YMMV.

IIRC, early binaries for MS-Windows ran without libsigsegv.
Actually, has libsigsegv ever been ported to MS-Windows?


>Regarding configurations: What about the different garbage collectors /
>object representations? (TYPECODES vs HEAPCODES)
Just let configure do its magic. IIRC, one is less troublesome but less
performant in the 32bit world, and the other next to mandatory in a 64bit
world (there's a lot of room in 64 bits to store typecodes).


>a socket failure
There were/are a few bugs related to sockets reported to the mailing list.
(sometimes due to compiler errors?)


>What about "64bit support"? (I'd consider that important, but it's currently "broken"
>in the sense that it doesn't get configured even when the target would support it.)

>All of these are running on amd64, I plan to add x86 VMs soon.

>* linux, ./configure, (defaults) with gc checker: builds, passes tests  except
>ffi 64 bit (HAVE_LONG_LONG seems to be undefined for whatever reason).
> Same without gc checker.

I'm confused. If on amd64, you're building a 64bit version, aren't you? So what
doesn't get configured and what builds and passes tests?


>* netbsd, ./configure, (FFI: no, readline: no, sigsegv: yes): build fails  due to an
>issue with mmap, though this seems to be "fixed" downstream by  disabling mmap support.
"Downstream" means the NetBSD CLISP package maintainer?
Mmap issues can get very hairy and very low-level fast. CLISP tries to put
its typecodes within the 32 bit pointers and may soon get in conflict with the
OS memory layout. I don't know how ASLR works with CLISP. I'd expect much less
mmap trouble with a 64bit build. (Note that I never put my hands on a NetBSD system.)

Oh, please read what I write with a grain of salt. It's all from memory;
I haven't compiled CLISP in the last ~10 years.

Regards,
	Jörg Höhle