[LispM] Lambda Software Release 5.0 (Prototype)

[Robert Swindells]

Daniel Seagraves <dseagrav at lunar-tokyo.net> wrote:
>> 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.

>> 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.

The CADR doesn't have the option of using something like the 2x2
Lambda, it has to pull files off a networked fileserver when booting
a cold load.

With that restriction, you tend to keep your development tree on
the server instead of a local LMFS disk.

I don't feel that I have made any changes to the CADR tree so far that
stray too much from the original design.

I wrote a version of the MINI network code that reads files from a
TFTP server. The pathname code also needed some work to get it to
correctly translate between logical pathnames and UNIX ones.

>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.

I think that preserving snapshots of the historical systems at
suitable milestones is important, I have tried to do this for
the CADR.

>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.

I am perfectly happy using zmacs, I'm just starting from the point of
having settled on a workflow on the CADR that is slightly different to
yours.

One part of the CADR development toolchain that does run on UNIX now
is the cold load builder, it is a *lot* faster than the lispm one.