RE: Interlisp-D project

33 views
Skip to first unread message

Larry Masinter

unread,
Aug 13, 2020, 3:34:57 PM8/13/20
to Hansen Hsu, Interlisp core

I’ve been kept somewhat aware of the Interlisp-D project through working with Paul McJones to get the source code release permissions from PARC.

We’re currently in the middle of developing the rollout strategy for releasing these sources to the public, though Paul has informed me that he’s made a copy of the Interlisp-D sources available to you for your work.

 

Yes; the sources Paul gathered were for earlier releases of Interlisp-D; however, there were several years of development at Venue for Medley 1, 2, 3, 3.5, including increasing the address space (and the symbol space), improving common lisp support.

 

So I think the thrust of our efforts are different:

Paul’s effort has been to gather the original early implementations as a way of recording and documenting the history… while the Interlisp.org project is to have an environment that could continue to be useful and even supported. We’re OK with adaptations to make it convenient to use in a modern system, such as Unicode support

 

 

Also, you’ve reached an agreement with John Sybalsky’s stepson to release the Venue Medley source code as open source?

 

Yes; he’s subscribed to the list.

 

Will you be using GitHub for this release? 

 

That is currently the plan; https://interlisp.org/#github-repos-license-files

 

Will that be complementary to CHM’s own release of the PARC-licensed Interlisp-D code?

 

We left that open, not knowing what your plans were.

“if there is a desire to have sources for older versions, we can add a history directory with versions under that (a fugue, harmony, koto). (There weren’t sub-versions fugue.2 fugue.3) The LICENSE file in history can apply to all the older versions.”

It says “directory” but should be “repository” Interlisp/history.

 

I’d like to hear more about the Virtual Museum idea. Is it to recreate a running Interlisp-D environment on a modern system, perhaps an in-browser emulation like Dan Ingalls’ Smalltalk Zoo on LivelyWeb?

 

To get the feeling for what developing code was like, I think you’ll need a longer session; something that can be installed and run for days.

 

To be honest, all I’ve really done is search for “Virtual Museum” and started reviewing.

 

If so, how are you envisioning a collaboration with CHM? Do you see CHM hosting such a live environment?

 

I’m hoping you might advise us, review our plans.

Perhaps we could plan a virtual event like was done for the Alto.

Produce videos recording of demos or explanations?

Tutorials ?   What’s involved in curating a software exhibit.

 

Best,

Hansen

....................................

Hansen Hsu, Ph.D.

Curator, Software History Center

 

1401 N. Shoreline Blvd.

Mountain View, CA 94043

(650) 810-1880 direct

(650) 810-1055 fax

 

Follow Us:

 

 

 

Larry Masinter

unread,
Aug 17, 2020, 10:25:29 PM8/17/20
to lisp...@googlegroups.com

Just FYI conversation with Hansen Hsu (Computer History Museum manager of Software Collection)

 

From: Larry Masinter <masi...@gmail.com> On Behalf Of Larry Masinter
Sent: Monday, August 17, 2020 3:51 PM
To: 'Hansen Hsu' <hh...@computerhistory.org>
Cc: 'Paul McJones' <pa...@mcjones.org>; 'Austin Henderson' <hend...@rivcons.com>
Subject: RE: Interlisp-D project

 

 

You mention video recordings of demos with explanations. We’ve done several of those in the wake of the Alto demo. 

 

Here are three:

Larry Tesler demos Gypsy

https://www.computerhistory.org/collections/catalog/102738551

Dan Ingalls demos Smalltalk

https://www.computerhistory.org/collections/catalog/102738723

Eric Bier demos Cedar

https://www.computerhistory.org/collections/catalog/102781041

 

Interlisp-D would make the third and would be the natural next demo to do.

The advantage of this would be that since we’ve already done several of these, it wouldn’t be significantly more effort to do another and it fits in with an existing project, so we have no need to involve any higher ups to accomplish this.

Right now, though, we’d have to wait until after COVID to schedule studio time to come in and film this, but otherwise I don’t see any obstacles to this happening.

 

I think we might get better demos recording a zoom call using screen-sharing.

What we’re missing is some help planning (who demos what why etc) and in post-production (clean up the zoom recording, add an intro, trim outtakes, ums, etc.) .

Maybe doing these as an “event” with remote people able to ask questions?

 

I imagine a “software history exhibit” that takes some ideas and shows their development over time:    “Hypertext”, for example, could show NLS, NoteCards, HyperCard, Early Web; “Scroll bars” could show star, Interlisp, smalltalk, windows, mac. “Line art editing” (Internet Sketch, Illustrator) “IDEs”, “email management”

(Interlisp included its own email manager).

 

I think that’s what Austin was talking about (right, Austin?)

 

For the release of Interlisp sources, my thinking has evolved:

 

We’re currently using source code through Venue, who had a license to distribute the software for Medley consistent with the LICENSE files in our various GitHub repositories.

 

The CHM collection, which includes lots of things not covered by Envos or Venue agreements, needs to have its own LICENSE file in general, consistent with the terms Xerox released it to you.  There will be of course overlaps, but licenses are additive.  We don’t need to wait for the CHM release, but it will be important to have it, for establishing context (was this feature there before such and such date?)

 

If you do a “raw” release of what you have with whatever LICENSE terms you pick, perhaps we can rearrange things to match our release for easier access.

 

 

The odd thing about software collections is that they don’t have to be in any particular place.

Lots of Copies Keeps Stuff Safe. I wouldn’t worry about the URLs and hosting.

 

Maybe we should coordinate with Dan Ingalls.

 

 

 

 

Larry Masinter

unread,
Sep 30, 2020, 1:56:20 PM9/30/20
to Johannes Steffens, Interlisp core
more background on the relation of the Medley Interlisp project (https://Interlisp.org) and the CHM.
(Different goals but coordinated efforts).

---------- Forwarded message ---------
From: Hansen Hsu <hh...@computerhistory.org>
Date: Thu, Aug 13, 2020 at 4:46 PM
Subject: Re: Interlisp-D project
To: Larry Masinter <L...@acm.org>
Cc: Paul McJones <pa...@mcjones.org>


Hi Larry,

Adding Paul to this thread.

On Aug 13, 2020, at 12:34 PM, Larry Masinter <L...@acm.org> wrote:

Yes; the sources Paul gathered were for earlier releases of Interlisp-D; however, there were several years of development at Venue for Medley 1, 2, 3, 3.5, including increasing the address space (and the symbol space), improving common lisp support.
 
So I think the thrust of our efforts are different:
Paul’s effort has been to gather the original early implementations as a way of recording and documenting the history… while the Interlisp.org project is to have an environment that could continue to be useful and even supported. We’re OK with adaptations to make it convenient to use in a modern system, such as Unicode support

Understood. This makes sense. 

Also, you’ve reached an agreement with John Sybalsky’s stepson to release the Venue Medley source code as open source?
 
Yes; he’s subscribed to the list.

Excellent.

Will you be using GitHub for this release? 
 
 
Will that be complementary to CHM’s own release of the PARC-licensed Interlisp-D code?
 
We left that open, not knowing what your plans were. 
“if there is a desire to have sources for older versions, we can add a history directory with versions under that (a fugue, harmony, koto). (There weren’t sub-versions fugue.2 fugue.3) The LICENSE file in history can apply to all the older versions.”
It says “directory” but should be “repository” Interlisp/history.

Thanks for outlining your plan.

Paul and I have been discussing how to release the PARC sources as well. There have been discussions about using GitHub as well.
However, Paul has indicated to me that to do a proper GitHub release would be a substantial effort on our end, as we would need Tioga file format translation, and also someone would have to take various versions of the sources and put them into GitHub in a way that would preserve the versioning. Paul has suggested, and I have concurred, that at least for a quick initial release, it would be easier to release the sources in the same way as our previous Alto code release, which was as either zip files linked from a web page or translated into HTML using the tools Paul wrote for that release. This would take the least amount of effort. However, we also understand it would be more useful going forward if we could also release these on GitHub as well. For that, we would need significant help from volunteers such as yourself to massage the PARC file formats and get it into a way that would make sense for GitHub. The idea there would be for CHM to host its own GitHub repositories with various portions of code that were received from PARC, including, but not limited to, Interlisp-D. 
I understand if you feel it would make more sense to release the PARC Interlisp-D code alongside the Venue code in the same repository, as it would indicate continuity and be easier to use. However I’m not sure at this time whether the terms of the agreement we have with PARC would allow that, as we need to provide a specific license approved by PARC and CHM in order to conform with the agreement. (I don’t believe the PARC license precludes you from forking it to make modifications, however, but only for noncommercial purposes.)
In any case, worse comes to worst, we might have to have separate repositories for the PARC code and the Venue code with separate licenses. But nothing is set in stone yet, we’ll be developing the plan further, and I’ll let you know more as we get closer.

I’d like to hear more about the Virtual Museum idea. Is it to recreate a running Interlisp-D environment on a modern system, perhaps an in-browser emulation like Dan Ingalls’ Smalltalk Zoo on LivelyWeb?
 
To get the feeling for what developing code was like, I think you’ll need a longer session; something that can be installed and run for days.
 
To be honest, all I’ve really done is search for “Virtual Museum” and started reviewing.
 
If so, how are you envisioning a collaboration with CHM? Do you see CHM hosting such a live environment?
 
I’m hoping you might advise us, review our plans.
Perhaps we could plan a virtual event like was done for the Alto.
Produce videos recording of demos or explanations?
Tutorials ?   What’s involved in curating a software exhibit.

There are a number of possible ways we could collaborate.
Right now, in terms of virtual “exhibits,” everything is very tightly controlled at the moment, in part due to the new constraints of COVID, in part to financial constraints. 
A second event on the scale of the live Alto event is unlikely to happen, as that event involved an enormous expenditure of resources and staff time.
Perhaps a smaller scale event might be possible, but it would have to fit into our new event plan, in which new events are being focused around CHM’s new emphasis on AI and Innovation. Interlisp-D certainly could fit into the AI focus. But we’d need to coordinate carefully with the event staff, who are planning events (especially remote ones) that are accessible to a wide, non-technically sophisticated audience. 
If an event is something you’d like to see, please write up a proposal that I could bring to the event group for their consideration.

However, other avenues may be possible.

You mention video recordings of demos with explanations. 
We’ve done several of those in the wake of the Alto demo. 

Here are three:
Larry Tesler demos Gypsy
Dan Ingalls demos Smalltalk
Eric Bier demos Cedar

So, two out of three of the major PARC integrated development environments/languages are covered already.
Interlisp-D would make the third and would be the natural next demo to do.
The advantage of this would be that since we’ve already done several of these, it wouldn’t be significantly more effort to do another and it fits in with an existing project, so we have no need to involve any higher ups to accomplish this.
Right now, though, we’d have to wait until after COVID to schedule studio time to come in and film this, but otherwise I don’t see any obstacles to this happening.

Another possibility, which would definitely require buy-in from management, would be to have CHM host a running, or even a set of running, Interlisp-D environments in a browser, that users could access through a subdomain of the CHM website.
As I mentioned in my previous e-mail, we have been working with Dan Ingalls on exactly this. We’ve created a mirror of his LivelyWeb site to host a number of historical emulated Smalltalk instances that trace its development over multiple versions.
Here are some examples:

This has been a collaboration with Dan Ingalls. Our IT department has provided the hosting and allowed Dan access to the subdomain smalltalkzoo.thechm.org, which is hosting LivelyWeb, a JavaScript environment that is emulating various Smalltalks. LivelyWeb preexisted this CHM domain, however, and its original version on LivelyWeb.org still exists as a separate site. Dan wanted to maintain a curated version of it on CHM servers in case LivelyWeb got shut down or hacked, and secondly, he wanted to modify it to make it slightly more accessible to general audiences as a kind of virtual living exhibit that people could play with, in the way you envision for Interlisp-D. Dan is currently working to fix up the various examples to accomplish this, so the final version of the Smalltalk Zoo on CHM won’t be exactly the same as the original LivelyWeb version, though most of the code will be the same. Part of Dan’s motivation for this was to have these examples be pointed to from his recent ACM HOPL paper on Smalltalk.
If you could make a version of Interlisp-D that could run emulated in a browser, in a similar fashion to Smalltalk on LivelyWeb, I could see us creating a second subdomain for Interlisp-D on our website. I would have to prepare a presentation to management to make the case to do this, but I think it could be done. 
If Interlisp-D can’t run in a browser, however, I’m not sure what the solution would be. Would you want to provide downloads to an environment or emulator that someone could install on their PC or Mac? In such a scenario, I don’t know how hosting it on CHM would necessarily be of benefit, as you could host such files on your own web servers.

In any case, while you could sort of describe this as an “exhibit,” it’s not going through any of CHM’s traditional exhibit procedures, and it’s not really curated in the sense that any of our traditional exhibits are, with detailed historical interpretation. Really it’s a virtual emulation environment that exists on its own as a special area of the website. Dan has more or less the freedom to do what he needs to do in his subdomain, and other than some supervision from IT and some coordination with myself, we’ve mostly let Dan do his thing. In a way, I see this as less an exhibit as a virtual software artifact that we’re making accessible through the website, as other than a blog post which I’m writing for Dan to publicize the Smalltalk Zoo, there is little involvement from the rest of the curators or collections staff. If we host Interlisp-D in a similar way, I would treat it similarly to what I’m doing with Dan and Smalltalk.

Another avenue for collaboration, which I’ve mentioned earlier, is on organizing the Interlisp-D source code itself for public release.
Given our staff constraints, we need help from volunteer organizations of technically proficient people such as yours to help with getting the code into a state that developers would actually find useful.
Of course, as I mentioned earlier, our code releases need to comply with the terms of our agreement with PARC, so any collaboration would require that we handle the public release of the code through CHM’s mechanisms. But this is definitely one area you could be of substantial help to us.

I look forward to further discussions.

Best,
Hansen
....................................
Hansen Hsu, Ph.D.
Curator, Software History Center
 
1401 N. Shoreline Blvd.
Mountain View, CA 94043
(650) 810-1880 direct
(650) 810-1055 fax

Follow Us:

John Cowan

unread,
Sep 30, 2020, 3:45:41 PM9/30/20
to Larry Masinter, Johannes Steffens, Interlisp core
The idea of Interlisp-in-the-browser is interesting.  The obvious way to do it is to compile maiko for Wasm using Emscripten or clang (and a recent browser as well).  

Another interesting approach would be to modify maiko to speak HTTP and JavaScript, using the browser window as the Interlisp root window.  This would probably be too costly to use for remote execution, but very nice locally: no X server needed.  I have no idea if this is practical.



John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org
LEAR: Dost thou call me fool, boy?
FOOL: All thy other titles thou hast given away:
That thou wast born with.



--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lispcore/CAKq15veC-cQ-q%2BcO-e068MWfHofm1%3DDpVCv%2Bn%2BKwV7b7UkKnyQ%40mail.gmail.com.

Nick Briggs

unread,
Sep 30, 2020, 4:07:33 PM9/30/20
to John Cowan, Larry Masinter, Johannes Steffens, Interlisp core
On Sep 30, 2020, at 12:45 PM, John Cowan <co...@ccil.org> wrote:

The idea of Interlisp-in-the-browser is interesting.  The obvious way to do it is to compile maiko for Wasm using Emscripten or clang (and a recent browser as well).


I had a lot of trouble trying to get a working Emscripten setup, or a clang that would do it correctly either.  If you have experience building WebASM projects from C code that depends on a C runtime library, system calls, and a file system, can you point me at working info on how to set it up?

  

Another interesting approach would be to modify maiko to speak HTTP and JavaScript, using the browser window as the Interlisp root window.  This would probably be too costly to use for remote execution, but very nice locally: no X server needed.  I have no idea if this is practical.


Medley/maiko maintains the display bitmap, and knows (mostly) what regions of the display bitmap have changed, so any method which can build on that would likely be a workable path forward.  The only tricky bit is the cursors -- it worked very hard to deal with displays without built-in cursor overlays, but that code hasn't been exercised recently and may have suffered bit rot.

-- Nick

John Cowan

unread,
Sep 30, 2020, 4:09:27 PM9/30/20
to Nick Briggs, Larry Masinter, Johannes Steffens, Interlisp core
Alas, I have no such expertise.  There are lots of games you can play in web browsers, though, and I'm told that rewrite-the-whole-window is the usual rule.

Nick Briggs

unread,
Sep 30, 2020, 4:14:15 PM9/30/20
to John Cowan, Larry Masinter, Johannes Steffens, Interlisp core
Darn, I thought I might have found a resource!   Rewrite the window is fine.  There are also games you *must* play -- you have to cooperate with the Javascript event loop because Javascript in the browser is NOT multithreaded -- a program running in the browser's Javascript environment has to yield to the browser in order for the system not to flag the page as hung.  This doesn't play well with something like the Interlisp emulator, which just runs (flat out) in an infinite loop.

-- Nick

John Cowan

unread,
Sep 30, 2020, 11:18:17 PM9/30/20
to Nick Briggs, Larry Masinter, Johannes Steffens, Interlisp core
On Wed, Sep 30, 2020 at 4:14 PM Nick Briggs <nicholas...@gmail.com> wrote:
 
Darn, I thought I might have found a resource!   Rewrite the window is fine.  There are also games you *must* play -- you have to cooperate with the Javascript event loop because Javascript in the browser is NOT multithreaded -- a program running in the browser's Javascript environment has to yield to the browser in order for the system not to flag the page as hung.  This doesn't play well with something like the Interlisp emulator, which just runs (flat out) in an infinite loop.

From the _Smalltalk: Bits of History, Words of Advice_ book, in the chapter "The Design and Implementation of VAX/Smalltalk-80" by Stoney Ballard (Three Rivers) and Stephen Shirron (DEC), pp. 146-47:

The Smalltalk-80 system as distributed is not designed to either run background processes or co-exist on a timesharing system. This is due to the large number of places where the code loops waiting for a mouse button. The system can be converted to one which is entirely event driven by inserting wait messages to an "any event" semaphore into the loops. We found these loops by noticing whenever the idle process was not running, yet nothing else seemed to be happening. We would then type control-C to interrupt the Smalltalk-80 system and find out who was responsible. The debugger was then used to edit and recompile the offending methods. Converting all the interaction to an event-driven style allowed background Smalltalk-80 processes to run whenever the user was not actively interacting with the Smalltalk-80 system.

It is generally considered uncivil to run programs that are not doing anything worthwhile on a timesharing system. To fix this, we replaced the Smalltalk-80 idle process with one that called two special primitives. The Smalltalk-80 code for this is as follows.

IdleLoop
  [true] whileTrue:
    [[Smalltalk collectGarbage] whileTrue.
    Smalltalk hibernate]

 The collectGarbage primitive performed an incremental activation of the garbage collector, returning false if there was nothing left to do.  The hibernate primitive suspended the Smalltalk-80 VMS process, letting other users run. The hibernate primitive returned whenever an external event happened. Since this loop runs at the lowest priority, it is preempted by any Smalltalk-80 process with something to do.

This made us more popular with the other users of the VAX, and also reduced the overhead of the garbage collector when interacting with the Smalltalk-80 system in a bursty manner (which is usually the case). The Smalltalk-80 process itself also benefited from this because the VMS scheduler assigns a lower priority to compute-bound processes.  By hibernating often enough, the Smalltalk-80 process would preempt other users running compilers and the like, leading to a snappier response when browsing or editing.

[Note that this is about the VMS implementation, not the BSD one, which was called Berkeley Smalltalk.]

John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org
Female celebrity stalker, on a hot morning in Cairo:
"Imagine, Colonel Lawrence, ninety-two already!"
El Auruns's reply:  "Many happy returns of the day!"

Nick Briggs

unread,
Sep 30, 2020, 11:55:56 PM9/30/20
to John Cowan, Larry Masinter, Johannes Steffens, Interlisp core
Thanks for that.

Larry Masinter

unread,
Sep 30, 2020, 11:58:17 PM9/30/20
to Nick Briggs, John Cowan, Interlisp core
Reply all
Reply to author
Forward
0 new messages