From: Anthony J.R. Heading
Subject: State of AKCL?
Date: 
Message-ID: <1th62vINNmvb@signal.dra.hmg.gb>
How much work is going on on AKCL? It seems basically to be a
very solid piece of code: it build nearly first time on my
NeXT. (Trying to build for a Decstation, though, fell over due
to a missing file savedec31.c.)

The installation procedure is horrific and pretty
uninformative. akcl is basically code for hackers -
nobody else is going to manage to sort out configuring
an emacs or similar environment to make it useable.
In which case, since it's undocumented, it would
be nice if the installation was a bit more manual,
so that one could understand what was being
bootstrapped when, etc. As it is, the enormous
set of patches to a prehistoric release of kcl,
coupled with automatic variable substitution into
header files and multiple recursive Makefiles is
basically beyond me. By which I mean I can't
scan the code just to get a feel for how it works.
And I suspect that the same goes for a lot of us
run-of-the-mill programmers. 

Why not tidy it up a bit, into a state where ordinary
people can understand what's going on? Some
documentation on why akcl is different to kcl
would be nice, even if it's only rambling notes.

I am, of course, very grateful for the efforts of
the authors in providing the code at all. It always
irritates me enormously to see free software being
criticised by people who haven't made any effort
to contribute themselves. In the case of akcl, though,
it isn't set up to make it easy for anyone new to
help.

Anthony

PS. If anyone does want to send me any
documentation or pointers to discussions, I
promise to read them.

From: Patrick Tufts
Subject: Re: State of AKCL?
Date: 
Message-ID: <zippy.737996142@berry.cs.brandeis.edu>
·······@signal.dra.hmg.gb (Anthony J.R. Heading) writes:
[....]

>The installation procedure is horrific and pretty
>uninformative. akcl is basically code for hackers -
>nobody else is going to manage to sort out configuring
>an emacs or similar environment to make it useable.

What's so hard about getting it to run under Emacs?  Can't you just
set the right emacs hook to point M-x run-lisp to "akcl", or rename
"akcl" to "lisp"?  I would think either way would be enough to get M-x
run-lisp to do the right thing.

--Pat "though M-C-x might be a problem"

disclaimer: I've never installed Lisp, and I've never had to fiddle
around hooking a new Lisp into Emacs
From: Milt Epstein
Subject: Re: State of AKCL?
Date: 
Message-ID: <C7E83w.1C7@sparc0a.cs.uiuc.edu>
In <···············@berry.cs.brandeis.edu> ·····@cs.brandeis.edu (Patrick Tufts) writes:

>·······@signal.dra.hmg.gb (Anthony J.R. Heading) writes:
>[....]
>
>>The installation procedure is horrific and pretty
>>uninformative. akcl is basically code for hackers -
>>nobody else is going to manage to sort out configuring
>>an emacs or similar environment to make it useable.
>
>What's so hard about getting it to run under Emacs?  Can't you just
>set the right emacs hook to point M-x run-lisp to "akcl", or rename
>"akcl" to "lisp"?  I would think either way would be enough to get M-x
>run-lisp to do the right thing.

I believe all you need to do is set the variable
inferior-lisp-program, e.g. (setq inferior-lisp-program "akcl").
(If this is what the original poster was referring to.)


>--Pat "though M-C-x might be a problem"

I don't think this will be a problem -- M-C-x probably works by
sending a command to the proper buffer, so it shouldn't matter what
process is actually running in that buffer (assuming the command sent
is not nonsense to that process :-).

-- 
Milt Epstein
Department of Computer Science
University of Illinois
·······@cs.uiuc.edu