Re: [PATCH] gnu: lispf4 fixes.

[ng0 <ngillmann@runbox.com>]

ng0 <ngillmann@runbox.com> writes:

> ng0 <ngillmann@runbox.com> writes:
>
>> ng0 <ngillmann@runbox.com> writes:
>>
>>>   [PATCH 1/2] gnu: lispf4: Remove prebuilt binaries.
>>>
>>> This patch can be applied, it is finished.
>>>
>>>   [PATCH 2/2] gnu: lispf4: Fix the searchpath for SYSATOMS.
>>
>> PATCH 2/2 is now: Fix the reference to SYSATOMS, incoming in this thread
>> soon.
>>
>>> This patch requires further input.. The way Ricardo described this
>>> it could be the solution to the SYSATOMS problems (bug #22732) if
>>> someone can write functional C.
>>> If this does not fixes it in the end, I would consider the little
>>> help upstream wants to provide in fixing this and just drop lispf4.
>>> https://github.com/blakemcbride/LISPF4/issues/1
>>>
>>>
>>
>> -- 
>>
>>
>
> Furthermore I think I will re-read the Documentation of how blake
> mcbride ported lispf4 and decide to remove the 'ported' and / or the
> name or specify it in a more clear way. If Blake McBride added nothing,
> it would be reasonable by the quality of messed up code f2c produced to
> just write
>
> description: LISPF4 is an InterLisp interpreter written in FORTRAN by
> Mats Nordstrom, it supports much of the InterLisp Standard.
>

But when you read
https://github.com/blakemcbride/LISPF4/tree/master/Documentation
you see that what has been done was (quoting here):

The conversion steps I performed are as follows:

1.  Convert the system to C and got it running via the F2C program.

2.  Replace the Fortran calls to equivalent C calls to get rid of the
need for the Fortran support library.

3.  Enabled the use of command line arguments to control startup
options.

4.  Changed memory usage to allow runtime capacity specifications.

5.  Changed some code to make it a little more portable.  (The system
should be highly portable in general though.)

Since I have modified the converted C code you should not attempt to
go from the Fortran code to C without loosing all of my changes.
The Fortran code as-is will not run with F2C without a few tweaks.

The system successfully builds on 32 and 64 bit machines.  You may
need to make some adjustments in f2c.h



so the description should at least reflect that McBride did some changes.
> ...while I'm not yet clear about Interlisp vs Interlisp-D, two different
> families often thrown into just Interlisp.
>
> Furthermore I will adjust the homepage (terrible mistake with the ".git"
> at the end, it's annoying.
>
> And when this is done and I understand more and have more time to
> dedicate to historic archiving purposes, I will start working on my own
> interlisp (this could take a while until I can start). Or I find a
> better, cleaner, free implementation of interlisp available.. so far I
> just found interlisp and interlisp-d ones on archiving sites which we
> will not be possible to run or package or both of them.
>
>

--