From: Bruno H. <br...@cl...> - 2017-05-27 21:27:48
|
Hi Vladimir, > Related issue is the barrier to entry for newcomers. Having so many build > options and the dense codebase cause frustration to people interested to > get involved. I don't know what is the solution for this but it's > definitely a problem. "Dense codebase" is equivalent to "software that does complex things". If people want something less dense, they can look at interpreter-only implementations, SIOD, or similar. One approach that I've tried is modularization (libiconv, libsigsegv, libffcall are outside clisp now; clisp has its own module system). Maybe this modularization should be pushed further? Possibly every module should be accompanied with unit tests? Another thing is that many people don't like #if; they prefer abstractions. In some places we have abstractions with possibly more than 1 implementation (e.g. HASHSET in spvw_circ.d); maybe this should be coupled with a consistent coding style (.h and .c files for specification and implementation, respectively)? Do people feel the same ("dense codebase", "frustration") only about the C part of clisp, or also about the *.lisp files? > Normal users are also affected - people try something and submit bug > reports without reading http://www.clisp.org/impnotes/clisp.html#bugs and > following conversation is about 'clisp --version', build options, etc. > Probably having binary releases is the 'good enough' solution for this. I don't think one can do anything about this, other than to remind the users what information to provide. Different OSes have different support for mmap, __thread, system calls, etc. - therefore invariably the builds on different OSes will end up using different code paths. Or should we hook into 'apport', so that the details get collected automatically? It today's world, it's most often not the developers of a package who make the binary releases, but the distributors [1]. We can talk with them but we will never get them to distribute the same binaries. Bruno [1] https://repology.org/metapackage/clisp/versions |