Re: newcomers

Bruno Haible <[email protected]>
Newsgroups gmane.lisp.clisp.devel
Message-ID <3018446.gCG5BWsVLA@omega>
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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.