From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: [PATCH] gnu: lispf4 fixes. Date: Wed, 05 Oct 2016 10:18:55 +0000 Message-ID: <87bmyz2j5c.fsf@we.make.ritual.n0.is> References: <20161004223322.19523-1-ngillmann@runbox.com> <87k2dn2lij.fsf@we.make.ritual.n0.is> <87eg3v2jom.fsf@we.make.ritual.n0.is> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brjIC-000533-KE for guix-devel@gnu.org; Wed, 05 Oct 2016 06:19:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brjI8-0004wK-Bt for guix-devel@gnu.org; Wed, 05 Oct 2016 06:19:15 -0400 Received: from aibo.runbox.com ([91.220.196.211]:58506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brjI8-0004vc-46 for guix-devel@gnu.org; Wed, 05 Oct 2016 06:19:12 -0400 Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1brjI5-0003u8-9w for guix-devel@gnu.org; Wed, 05 Oct 2016 12:19:09 +0200 Received: from x5d83fa6c.dyn.telefonica.de ([93.131.250.108] helo=localhost) by mailfront10.runbox.com with esmtpsa (uid:892961 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1brjHs-0006jV-MF for guix-devel@gnu.org; Wed, 05 Oct 2016 12:18:56 +0200 In-Reply-To: <87eg3v2jom.fsf@we.make.ritual.n0.is> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org ng0 writes: > ng0 writes: > >> ng0 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. > > --