Re: clisp - general interest in code cleanup

[Daniel J. <dan...@gm...>]

Hi Sam,

Sam Steingold writes:
> this approach does not scale.

Can you elaborate on that a bit? As I already wrote to Don, it's just
the way I'm used to, based on previous experiences, but I'm completely
open to learn :) (I'm completely self-taught and have never received
any mentoring or - real, useful - teaching in "programming").


> all files include lispbibl.d, so this means that all files use them. :-)

Hehe, what I meant was more like: There seems to be versions of
alloca, an avl tree, sorting code, safe malloc and more in CLISP's code
that could be also provided by gnulib. That's what's confusing me: Are
these separate versions on purpose, or just not yet replaced by the
Gnulib ones?

>>> 2. fix gnulib/Windows interaction (gnulib assumes FD to be an int,
>>>    Windows uses Handles)
>>
>> Can you provide a bit more background on that? Is this related to
>> http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00033.html and
>> thus a general gnulib issue? Or does this only affect CLISP?
>
> this is a general property of gnulib.
> clisp used to work around this, but the latest import of gnulib files (5
> years ago?) broke it.
> IIRC, clisp no longer builds on windows.

I think it builds on cygwin with Ken's patches, but not "native" windows.
I'll try to get a windows machine / vm up in order to check this.

What's the general course of action here? Fix it in gnulib (as far as that's
possible, eventually using it's local modules feature) or work around "here"?

What priority do non cygwin builds on windows have? Targeting mingw or
the microsoft compilers?


>> How "extensive" are these self-tests?
>
> there are a lot of them and they cover most of the code.
> (modules have their own tests).

I found them, they're awesome.


>> I guess I should get a proposal ready ASAP then.
>
> please do!

Work is in progress, I have rough version that's ready for sharing soon.
Due to the limited time left I add some notes here to start with:

-- Title: CLISP - Make a release (finally)
-- Summary:
CLISP has seen its last release in 2010, almost 6 years ago.
Since then there have been a lot of changes, partly implemented features
and bug fixes. In combination with an import of Gnulib modules this
resulted in a code base that is no longer portable and not suitable for a
release. The purpose of this project is to fix the portability issues and to
cleanly include suitable Gnulib modules, allowing a new release with the
improvements of the past years to be published.

--Raw notes regarding plan:
* Get a complete picture of the code, especially what's broken on non linux
platforms.
* Get rid of (probably? almost) everything that can be provided by a suitable
gnulib module, using the most up to date version of gnulib (replace one part,
then run self tests, update doc, repeat). Potentially extending self tests.
* Fix gnulib on Windows. At least "enough" for CLISP to work.
* Mid-term: core CLISP builds and passes self tests on Linux, BSD, Mac and
Windows.
* update CLISP modules
* include useful (not yet used) patches and changes. It might be worthwhile to
think about holding back (possibly reverting) some half-finished changes here,
keeping them for a next release until they're finished (multithreading? jit?)
* general clean up of code and implementation notes ("polishing for the
release", so to say)
* Finally: release.

-- Skills I already “have”: C and Lisp, knowledge of memory management and
garbage collection as well as general VM/bytecode design and compiler
building. GNU make, Shell programming, general Linux competence.

-- Things I need to learn: Proper usage (as a developer) of the autotools and
the GNU build system, “hands on experience” regarding release process(es),
probably understanding CLISP's VM in depth will help, and finally how to
achieve portability to a lot of platforms. Update of my knowledge of windows
programming (it's been a while).

Sam, do you think that I should include references to previous work? Most
helpful is probably my stackoverflow.com account .. since my github repositories
... ehm .. aren't exactly neat and tidy and contain only a small
(largely outdated)
fraction of the stuff I've been doing all the years :)

Regarding communication: I'm best reached via email, but starting early-mid
April irc becomes an option, too, though I'm constrained regarding time of day.
This might be an issue if you'd like (very) frequent real time communication.
There's not much planned during the coding (and bonding) time span, apart
from a possible holiday of probably a week early August. My exams are at the
end of July, though that won't interfere (I'm thankfully learning fast
and was able
to complete this semesters exams with top scores without being present
or investing
much time during the semester. This has been the same for the last semesters, so
I'm very sure that this will work.)

Do I need to explicitly mention you in the proposal, or is this GNU
internally sorted out?

Looking forward to some feedback (if still possible, I know that only a bit more
than 16 hours left isn't exactly "much time")

Daniel

> --
> Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000
> http://www.childpsy.net/ http://memri.org http://islamexposedonline.com
> http://honestreporting.com http://truepeace.org http://think-israel.org
> God had a deadline, so He wrote it all in Lisp.