Interlisp in a browser

[Hayley Patton]

Here is a demo of sorts: https://applied-langua.ge/~hayley/il/ldesdl.html

I have Maiko with the SDL display working with Emscripten/WASM. Key to the port is the "asyncify" feature of Emscripten which lets infinite loops be given up to the event loop without having to contort the loops; I only modified dispatch to call emscripten_sleep(1) periodically.

The code can be found at https://github.com/no-defun-allowed/maiko and hopefully can be built with "SYSOUT=<path to a sysout> ./makeright wasm". I tried to make it work with cmake a while ago, but couldn't work out how to override the system compiler; I'm more experienced with Makefile for better or worse.

(It seems a bit confused about its (machine-type) though.)

[Larry Masinter]

I'm more than a little astounded. Amazing! And building on the SDL work....

Tomorrow's 2PM PST meeting agenda ... lets talk

--
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/3bf8a88c-5108-46d9-ad9b-a2f4186a353dn%40googlegroups.com.

--

https://LarryMasinter.net  https://interlisp.org

[Paolo Amoroso]

On Mon, Nov 13, 2023 at 5:53 AM Hayley Patton <theema...@gmail.com> wrote:

Here is a demo of sorts: https://applied-langua.ge/~hayley/il/ldesdl.html

Pretty cool, it starts up instantly and looks very promising. But, for the record, it doesn't recognize my Italian keyboard layout.

--

Paolo Amoroso | Blog | Mastodon

[Nick Briggs]

Cool.

I’m impressed that emcc and the support infrastructure has advanced to the stage where this requires so few changes to work!

It would be interesting to see if it could be packaged with the sources/library/lispusers files (which total about 5x bigger than the full.sysout) in such a way that the file system access would work.  If it can read using standard unix file system operations it could incorporate an entire release.

You might be able to build with CMake by doing (from a “build” directory at the same level as maiko/bin)

cmake -DCMAKE_C_COMPILER=emcc ..

but the makefile slice is useful anyway - thanks.

It is confused about the machine type because the code in uutils.c:unix_getparm hasn’t been fully updated as we’ve added different machine/architecture types. As you discovered, lacking any other info it claims to be a Motorola MC68020 for the machine type - it’s missing all the ARM processors, and probably others.

We should make a pass to fix that.  The “MACH” and “ARCH” parameters used to reflect what “uname -m” and “uname -p”, respectively, produced - not sure what it should say for WASM based systems.

Cheers,

Nick Briggs

[Nick Briggs]

Input seems a bit sketchy for the US keyboards too. Modifier keys aren’t doing what I’d expect, and I don’t know if one can emulate the 3-button mouse.

It’s exposing some of the rough edges in the SDL input handling.

--
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/CAGi1hzs90r_c%3D8eem1g3Yd62fLSWUvXvX9EdshxMtK9jYXK2fQ%40mail.gmail.com.

[Larry Masinter]

Just for fun:  https://interlisp.org/pub-pdfs/wasm/ldesdl.html

(the pub-pdfs repo for experimenting with publishing PDFs).

 "fuller.sysout"  has all of the sources for all files in the loadups all loaded (plus a few more), masterscope of everything.

No file system => no sysouts, savevms, fonts, any way to get to other files.

I' like to explore using URLs (supported by the browser) for file naming. 

We've built a lot of addons and a few patches that assume we're in a unix environment, and that's not true here.

So we might have to rethink those things.  

Medley (interlisp.org)    

On Sun, Nov 12, 2023 at 8:53 PM Hayley Patton <theema...@gmail.com> wrote:

--

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/3bf8a88c-5108-46d9-ad9b-a2f4186a353dn%40googlegroups.com.

[Nick Briggs]

Thanks for figuring this all out.

Looking to merge it in, I have some suggestions that I’d like your comments on --

(1) If the makefile-emscripten.wasm-wasm has only

default : ../$(OSARCHNAME)/ldesdl.js

then you don’t need to modify unixfork.c to remove the getusershell() definition, and it doesn’t need to build the lde executable, which won’t be used anyway when you’re instantiating the system in a browser.  As purely a matter of taste, we could use medley.js rather than ldesdl.js (just the two places to change) since there will be no “medley” or “run-medley” script in this path.

(2) In timer.c, rather than defining out just settimeofday(…), you can eliminate the entire body of the subr_settime(…) in the EMSCRIPTEN case, e.g.

diff --git a/src/timer.c b/src/timer.c

index 5d75bb2..559d882 100644

--- a/src/timer.c

+++ b/src/timer.c

@@ -288,6 +288,8 @@ void subr_settime(LispPTR args[])

   dosday.year = uxtime.tm_year;

   dosday.dayofweek = uxtime.tm_wday;

   _dos_setdate(&dosday);

+#elif defined(MAIKO_OS_EMSCRIPTEN)

+  /* nothing to see here - can't even try to set the time */

 #else

   struct timeval timev;

   timev.tv_sec = *((int *)NativeAligned4FromLAddr(args[0])) - UNIX_ALTO_TIME_DIFF;

(3) I’d prefer if the checks for __EMSCRIPTEN__ were limited to the one place in the maiko/platform.h — in the rest of the code it should test for MAIKO_OS_EMSCRIPTEN being defined.

(4) I haven’t tested this modification yet - but I think that rather than introducing a new instruction count to drive the calls to emscripten_sleep(1) in xc.c it could either share the countdown for the timer/io, or it might be able to repurpose the current subr_yield() where it currently does a nanosleep(…) — that’s driven off the background functions to avoid consuming an entire CPU core in the non-browser case.  Do you have a sense for how often the wasm code needs to yield in order for the browser to stay responsive?

— Nick

On Nov 12, 2023, at 8:53 PM, Hayley Patton <theema...@gmail.com> wrote:

[Frank Halasz]

Regarding the renaming of ldesdl.js to medley.js:  There may not be medley/run-medley bash scripts involved, but there will need to be their equivalent (written in JavaScript) that set up the DOM/JavaScript environment for ldesdl.js to run as configured by the user - sysout location, file system parameters,  scroll/noscroll, etc.

For ease of maintenance across platforms, seems like to would be a lot easier to keep the naming structures parallel - the Maiko code is named lde<platform><.ext>.  And  the code that sets up the environment and launches lde<platform><.ext> is called medley<.ext> or run-medley<.ext>.

-- Frank

On Sat, Nov 18, 2023, 3:06 PM Nick Briggs <nicholas...@gmail.com> wrote:

Thanks for figuring this all out.

Looking to merge it in, I have some suggestions that I’d like your comments on --

(1) If the makefile-emscripten.wasm-wasm has only

default : ../$(OSARCHNAME)/ldesdl.js

then you don’t need to modify unixfork.c to remove the getusershell() definition, anl.jsd it doesn’t need to build the lde executable, which won’t be used anyway when you’re instantiating the system in a browser.  As purely a matter of taste, we could use medley.js rather than ldesdl.js (just the two places to change) since there will be no “medley” or “run-medley” script in this path.

To view this discussion on the web visit https://groups.google.com/d/msgid/lispcore/0FF0E152-94C2-45B1-A047-212B45B43758%40gmail.com.

[Nick Briggs]

Where, currently, <platform> is actually the display subsystem technology (x or sdl) which is invoked by just plain “lde” which chooses the appropriate one to invoke (and lives on to provide the OS process forking).  We don’t differentiate in the file name by what I’d traditionally call <platform> — the OS and CPU architecture the code is compiled for.

I expect we’ll construct a medley (.html ?) page to invoke the javascript/wasm.  As I said, it’s a matter of taste, I’m not particularly attached to my proposal.

— Nick

[Hayley Patton]

> Looking to merge it in, I have some suggestions that I’d like your comments on …

That all sounds reasonable; I don't know how often we have to yield though. And does subr_yield get called while Lisp is doing some long-running computation?

> There may not be medley/run-medley bash scripts involved, but there will need to be their equivalent (written in JavaScript) that set up the DOM/JavaScript environment for ldesdl.js to run as configured by the user - sysout location, file system parameters,  scroll/noscroll, etc.

That currently exists in emscripten.wasm/ldesdl.html - I don't like it being out of src/ but that's orthogonal.

[Frank Halasz]

>> There may not be medley/run-medley bash scripts involved, but there will need to be their equivalent (written in JavaScript) that set up the DOM/JavaScript environment for ldesdl.js to run as configured by the user - sysout location, file system parameters,  scroll/noscroll, etc.

> That currently exists in emscripten.wasm/c - I don't like it being out of src/ but that's orthogonal.

ldesdl.html currently has a barebones setting of run parameters for lde - and none to be passed through lde to Medley.  And it has no user interactions to set any run parameters.

Whether you add it to ldesdl.html or create a wrapper/calling html file and whether the js code is included in the html files or in separate js files is a minor design issue.  

The important thing is for emscripten.wasm ldesdl to be at all useful it requires a UI in which the user can set any or all of the many parameters for Maiko/Medley - screensize, scroll/noscroll, location of personal INIT file, start from a sysout (which?) or start from previous lisp.virtualmem, user's initials, and so on.  All of these need some sort of UI that allows the user to set them (or read them from some initialization file).

-- Frank

To view this discussion on the web visit https://groups.google.com/d/msgid/lispcore/91ebc148-2059-4fbc-b464-4b2b20f792d3n%40googlegroups.com.