[LispM] Lambda Software Release 5.0 (Prototype)

[Daniel Seagraves]

> On Apr 28, 2017, at 3:14 PM, Alfred M. Szmidt <ams at gnu.org> wrote:
> 
> Yeah you do; the tape is missing a lot of stuff -- cold load
> generator, ucode assembler, ucode for Lambda.

None of that shipped with the standard system, or even on the options tape for that matter. The cold load generator isn’t even usable unless you have a 2x2 Lambda, and the debugger for that isn’t even usable yet. When I get a good distribution of the regular system then I’ll start adding OS development things to the options tape.

> On Apr 28, 2017, at 2:13 PM, Robert Swindells <rjs at fdy2.co.uk> wrote:
> 
> There were the DJ and JB machines at LMI, we have backups of what was
> on them. The .system files that are in the filesystem explicitly
> reference them. I was expecting that we would put them on different
> logical hosts.

You only need DJ. JB was for K-machine development, and DJ was for Lambda development. The Lambda tree on JB has mods for K-machine development, but is otherwise an older version of what’s on DJ. In any event, you can work from the local machine’s LMFS, there is no need to emulate the file server unless you are testing the network or don’t trust the LMFS (which was the case during development). Restarting K-machine development is a whole other hill of beans.

> Ok, how about describing how you expect us to set things up, or would
> you prefer that we keep trying to guess.


I don’t expect anyone else to do anything except maybe give me bug reports and/or patches for those.

I’m just using the existing stuff on the Lambda. I did all this work to see and use a lispm, not the same emacs and unix tools I’ve been using for the past couple decades. It works, and I didn’t see any reason to start chopping things apart and making some kind of frankensteins’s monster. There will probably be another project along soon enough to do just that. I keep my source on the LMFS of one side of a 2x2 Lambda and I follow LMI’s instructions when it’s time to push bits to the other. When I have something to distribute all I should have to do is pass around patch tapes, unless it’s big enough to warrant a new cold load. When I want to save things, I just save a copy of the disk image. They’re small and copying them is cheap.

In any event, I’m just trying to make a fairly representative distribution that joe random who has never seen a lispm before can use to see what a lispm was like, with fixes to bugs so that most of the things that would have worked back then still work today. This is what I expect the majority of LambdaDelta's usage will be. I’m explicitly trying to not force everyone to be an experienced developer or LMI employee. I’m absolutely not trying to turn Lambda into yet another (slow and obsolete) Unix-based Lisp implementation. If that’s what you’re after, the CADR stuff is at least free to use legally.

If you still want to be involved and you really can’t stand zmacs, there’s an NFS client. If NFS is not acceptable you can FTP things in and out. If that’s also not acceptable, port the BSD chaosnet stuff to modern-era *nix and use that. If none of that is acceptable I don’t know what to tell you. Maybe write one of those nifty user-mode filesystem drivers and loop-mount the LMFS image with it? None of the development toolchain runs on Unix anyway, so there’s no reason you must pull the source out except for maybe archival for version control. We can’t centrally archive it anyway, at least not until we get clear rights to it. I can’t even post it on Github, I have to link to it and hope there’s enough copies floating around to survive mine going away if anything happens.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </archives/lispm/attachments/20170428/16119ede/attachment.html>