Medley on Raspberry Pi OS Bookworm

[pamoroso]

Has anyone tried Medley on Raspberry Pi OS 64-bit under Debian Bookworm? Does Medley work with Wayland and TigerVNC or other VNC clients?

[masinter]

I wonder if we could put up a chart of CPU / OS / author / versions / notes / benchmarks / test results / etc.
that people could add to. There have been a lot of ports.

I imagine we could repurpose the Medley Wiki for that, or even open up a maiko wiki, if adding such a thing to Hugo would be a big deal.

Or we could make it another "pinned" Discussion -- not sure of which technology to use.

What's the smallest / cheapest / fastest implementation? Anyone get Risc V going? Other linux distros?

[nbriggs]

The XWayland compatibility layer should work for Medley on Debian Bookworm on RPi. You'd have to compile it there - not sure if it would require the specification of an extra library. [edit: install the xwayland package; see https://wiki.debian.org/Wayland ]

[pamoroso]

Don't the medley-full-linux-armv7l binaries of the Medley releases work on the Pi? Which platform are they for?

[pamoroso]

What architecture are the medley-full-linux-armv7l*.deb binaries for? 32 or 64 bits?

[pamoroso]

Got it thanks. Then I'll build Medley from source on Raspberry Pi OS 64-bit.

[nbriggs]

You might need to add new makefile segments. What do maiko/bin/osversion and maiko/bin/machinetype report on the RPi 64-bit systems?

[nbriggs]

If they report linux and aarch64 then you should be OK, just need to run (from the maiko/bin directory) ./makeright init && ./makeright x

[pamoroso]

When I have the device I'll let you know what maiko/bin/osversion and maiko/bin/machinetype report 😀 My new Raspberry Pi 400 has been shipped and should be delivered in a few days.

By the way I wasn't sure what architecture the aarch64 files are for either.

[nbriggs]

ARM processors with the 64-bit extensions, according to https://forums.raspberrypi.com/viewtopic.php?t=302345 - so you should just be able to use the linux-aarch64 releases as Larry suggested.

[masinter]

shouldn't the release
medley-full-linux-aarch64-231030-f49729cb_230809-7fce08f9.deb
work on 64-bit Pi OS?

[nbriggs]

You're right - If the RPi 64-bit systems report linux and aarch64 then that prebuilt one should be ok.
If it reports something else (that we don't have yet) it would need a rebuild.

[pamoroso]

I've just installed and configured my new Raspberry Pi 400 and quickly checked Medley. Medley Online works great as usual, here it is in Chromium:

Then I installed the latest AArch64 .deb binaries, the file medley-full-linux-armv7l-231103-328d3f53_230809-7fce08f9.deb. But when I execute medley -a -e -n & I get this error:

lde not found in /usr/local/interlisp/medley/../maiko/linux.aarch64
osversion = linux
machinetype = aarch64

uname -a returns:

Linux raspberrypi 6.1.0-rpi6-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.58-1+rpt2 (2023-10-27) aarch64 GNU/Linux

This is just a quick test, I'll investigate further.

[nbriggs]

That link/.deb file you pointed at is the armv7l NOT the aarch64 version, which you need.

[pamoroso]

You're 106% right but my brain was melted after an eventful RPi 400 installation and configuration session with a couple of unexpected issues that took a lot to fix. I'll try the AArch64 version tomorrow.

[pamoroso]

Success!

I installed the medley-full-linux-aarch64-231103-328d3f53_230809-7fce08f9.deb binary and, although I got these warnings when executing with sudo apt install ./medley-full-linux-aarch64-231103-328d3f53_230809-7fce08f9.deb, everything seems to be working fine:

N: Lo scaricamento è eseguito come root, ma non in una sandbox, poiché l'utente "_apt" non ha accesso al file "/home/pi/Scaricati/medley-full-linux-aarch64-231103-328d3f53_230809-7fce08f9.deb". - pkgAcquire::Run (13: Permesso negato)
W: APT had planned for dpkg to do more than it reported back (0 vs 5).
   Affected packages: medley-interlisp:arm64

Translation of the messages in Italian (the .deb file has permissions 644):

The download was carried out as root, but not in a sandbox, because user "_apt" has no access to the file [...] (13: permission denied)

Here's Medley on the desktop:

And here at full screen:

The only known issue is Medley uses the default English keyboard layout and doesn't recognize my Italian one. Also, text in the Exec is printed at a speed similar to a TTY terminal and individual characters can be seen appearing one at a time. Is this the level of performance D machines delivered back in the day?

[pamoroso]

This screencast I recorded on my Pi 400 shows how slow is starting up the AArch64 X version of Medley:

vokoscreenNG-2023-11-19_14-45-15.mp4

Using the system once it runs is equally slow. For example, when opening DInfo I can see each node of the IRM TOC tree being drawn and the whole process takes a few seconds.

[Michele31415]

On 11/7/2023 6:09 AM, Paolo Amoroso wrote: ... The only known issue is Medley uses the default English keyboard layout and doesn't recognize my Italian one. Also, text in the Exec is printed at a speed similar to a TTY terminal and individual characters can be seen appearing one at a time. Is this the level of performance D machines delivered back in the day?

Definitely not.  Even the D0 zipped out text fast enough that it looked like the entire line appeared at once.             - Michele

[pamoroso]

When I SSH with X forwarding to the Pi 400 from my Chromebox via ssh -X and launch Medley it starts up almost immediately. It's launching it directly from the Pi 400 that takes a dozen seconds or more and prints text so slowly.

[nbriggs]

So something about the display subsystem on the Pi - in the local case it's talking to the X11 server on the Pi, in the ssh case it's talking to the X11 server on the Chromebox. Is the Pi display subsystem based on Wayland (and therefore forcing it through Xwayland)?

[pamoroso]

Yes, Raspberry Pi OS Bookworm is based on Wayland and Medley is definitely going through Xwayland.

[nbriggs]

Do other X11 programs displaying through Xwayland show similar slowdowns? To get through a comparable path it would need to be something that displays monochrome bitmaps.

[pamoroso]

Ordinary X programs that output in color have no such slowdown in Wayland on the Pi 400. Right now I can't think of any that displays only monochrome bitmaps. When I find a screencasting tool with Wayland support, I'll record a session to show you how slow launching Medley is with Wayland.

I'd try to build Medley from source with SDL2 support for AArch64 but makeright doesn't seem to have any such option. How do I build for SDL2?

[pamoroso]

Never mind, I found the instructions for building with SDL2.

[nbriggs]

Right... all SDL builds are SDL2. ./makeright sdl should do it.

[pamoroso]

I successfully built from source the SDL branch of Maiko and both lde and ldesdl run fine, e.g. with the --help option.

How do I proceed? Assuming lde and ldesdl are in the path, do I just clone the Medley repo and launch run-medley from there?

[nbriggs]

You could do that, or reuse the packaged version of medley you already installed

[pamoroso]

With lde and ldesdl in the path, launching run-medley from the root of the freshly cloned Medley repo yelds this error as I still need to figure how to generate the loadups:

MEDLEYDIR has no loadups: /home/pi/medley/medley
I tried to infer it based on your working directory, but that didn't work.
Try cd there or setting the MEDLEYDIR environment variable to its location.

But the files of the already installed packaged version do work with the SDL version of Maiko. I set MEDLEYDIR to /usr/local/interlisp/medley, cded there and, with lde and ldesdl still in the path, I executed ./medley -a -e -n &, and it worked.

This time Medley starts up instantly and performance is generally good. For example, the DInfo windows open instantly and clicking a node in the tree window instantly displays the corresponding entry in the document window.

Here's what Medley looks like:

Interestingly, the LispUsers Hanoi program seems to run in bursts of activity rather than continuously. The discs move nearly instantly in a group from one peg to the other, the program pauses for a moment, the group moves to another peg, and so on. The discs don't move one at a time.

From the SDL instructions I seem to understand in the SDL version the keyboard input is suppposed to follow the OS keyboard selection, but this is not the case with my setup. My Italian keyboard layout is not recognized and I still have to press the keys in the corresponding position of the English keyboard.

[nbriggs]

We could be changing the screen faster than the display's refresh rate - probably 50/60 Hz - you'd have to slow the display operations down in the Lisp code to make it run slow enough that you can see the movement. On systems with a slower CPU that wouldn't have been so much of a problem.

[pamoroso]

An excess of performance is a good problem to have, especially on a humble Pi 400 😃

I'm making progress with the loadups. From MEDLEYDIR (i.e. ~/medley/medley), with lde and ldesdl in the path I executed loadup-all.sh -apps and it run smoothly (the Medley window did open and process several files) but ended with these errors:

[...earlier output omitted...]
>>>>> START loadup-aux
sysout /tmp/loadups-6611/full.sysout
running: lde   -g 1042x790 -sc 1024x768 -title "Medley Interlisp" -m 256  /tmp/loadups-6611/full.sysout
greet: /tmp/loadups-6611/loadup-aux.cm
Couldn't find a sysout to run: No such file or directory

 either setenv LDESRCESYSOUT or do:
 medley [<sysout-name>] [<options>]
 -info                    Print general info about the system
 -help                    Print this message
 -pixelscale <n>          The amount of pixels to show for one Medley screen pixel.
 -sc[reen] <w>x<h>]       The Medley screen geometry
 -t <title>               The window title
 -title <title>           The window title
+++++ SUCCESS +++++
..... files created .....
ls: impossibile accedere a '/tmp/loadups-6611/whereis.hash': File o directory non esistente
ls: impossibile accedere a '/tmp/loadups-6611/exports.all': File o directory non esistente
<<<<< END loadup-aux

>>>>> START copy-all
Error: no such file /tmp/loadups-6611/full.sysout. Exiting.
Error: no such file /tmp/loadups-6611/lisp.sysout. Exiting.
Error: no such file /tmp/loadups-6611/apps.sysout. Exiting.
Error: no such file /tmp/loadups-6611/whereis.hash. Exiting.
Error: no such file /tmp/loadups-6611/exports.all. Exiting.
Added init.dribble to loadups
Error: no such file /tmp/loadups-6611/lisp.dribble. Exiting.
Error: no such file /tmp/loadups-6611/full.dribble. Exiting.
Error: no such file /tmp/loadups-6611/whereis.dribble. Exiting.
Error: no such file /tmp/loadups-6611/apps.dribble. Exiting.
Added RDSYS to library
Added RDSYS.LCOM to library
<<<<< END copy-all

+++++ loadup-all.sh: SUCCESS +++++

The error in Italian means "ls: unable to access '/tmp/loadups-6611/FILENAME': no such file o directory". The loadups directory contains only init.dribble (it should contain all the loadups, right?) and /tmp/loadups-6611:

pi@raspberrypi:/tmp/loadups-6611 $ ls -l
totale 8660
-rw-r--r-- 1 pi pi   89161 10 nov 20.17 I-NEW
-rw-r--r-- 1 pi pi   70631 10 nov 20.17 I-NEW.LCOM
-rw-r--r-- 1 pi pi 4313088 10 nov 20.17 init.dlinit
-rw-r--r-- 2 pi pi  116674 10 nov 20.17 init.dribble
-rw-r--r-- 1 pi pi 4166656 10 nov 20.17 init.sysout
-rw-r--r-- 1 pi pi       0 10 nov 20.17 loadup.timestamp
-rw-r--r-- 2 pi pi   55804 10 nov 20.17 RDSYS
-rw-r--r-- 2 pi pi   42967 10 nov 20.17 RDSYS.LCOM

[pamoroso]

This is weird.

From a shell with no MEDLEYDIR set I executed the already installed packaged X version and it ran with no trace of the slowdowns I initially described. Now the packaged X version runs cnsistently well with performance similar to the SDL version described earlier.

The system may have had an unusually high load when I ininitially tested the X version. Weird indeed.

[nbriggs]

yes, very odd.

[pamoroso]

Please disregard my earlier report as I still had lde and ldesdl in the path. With a clean path the X version of Medley is as slow as initially reported.

[nbriggs]

What does xrandr -q say? How about xdpyinfo (better attach it as a separate file, it's likely quite long)

[pamoroso]

The output of xrandr -q:

Screen 0: minimum 16 x 16, current 1920 x 1080, maximum 32767 x 32767
XWAYLAND0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 290mm
   1920x1080     59.96*+
   1440x1080     59.99  
   1400x1050     59.98  
   1280x1024     59.89  
   1280x960      59.94  
   1152x864      59.96  
   1024x768      59.92  
   800x600       59.86  
   640x480       59.38  
   320x240       59.52  
   1680x1050     59.95  
   1440x900      59.89  
   1280x800      59.81  
   720x480       59.71  
   640x400       59.95  
   320x200       58.96  
   1600x900      59.95  
   1368x768      59.88  
   1280x720      59.86  
   1024x576      59.90  
   864x486       59.92  
   720x400       59.55  
   640x350       59.77

And here's xdpyinfo:

xdpyinfo.txt

[nbriggs]

If you're doing loadups you need to, from the maiko bin directory, do ./makeright init to create the ldeinit, which will be created in the same place as the lde and ldex. Alternatively, just make a loadups/ directory in your checked-out medley directory and copy the sysouts there from the release medley directory.
All sysouts are architecture independent.

[pamoroso]

This is a great opportunity to learn how to build everthing from source, so I'm going to do the loadups. From maiko/bin, after ./makeright sdl cleanup and ./makeright sdl I execute ./makeright init and get this error:

pi@raspberrypi:~/medley/maiko/bin $ ./makeright init
making so far for linux on aarch64.
making with display single releasename init-linux.aarch64 ldename ldeinit
start making lde for init-linux.aarch64.
make: makefile-init-linux.aarch64: File o directory non esistente
make: ***  Nessuna regola per generare l'obiettivo «makefile-init-linux.aarch64».  Arresto.

Translations of the errors in Italian:

• Missing file or directory.
• No rule to generate target «makefile-init-linux.aarch64». Aborted.

There's indeed no file makefile-init-linux.aarch64 and a comment in makeright says `makeright init requires directory "maiko/init.${architecture}" which is missing too. Are the makefile and the directory generated automatically? How?

[pamoroso]

I followed your instructions and successfully built ldeinit.

Then I added the lde* executables to the path, cded to the Medley source tree, set MEDLEYDIR to that directory, removed the loadups directory of the previous attempts, and launched scripts/loadup-all.sh -apps. The latter completed successfully but then Maiko opened this blank Medley window:

and dropped me into URaid:

+++++ SUCCESS +++++
..... files created .....
-rw-r--r-- 1 pi pi 4314112 11 nov 17.49 /tmp/loadups-4837/init.dlinit
-rw-r--r-- 1 pi pi 116678 11 nov 17.49 /tmp/loadups-4837/init.dribble
-rw-r--r-- 1 pi pi 4167680 11 nov 17.49 /tmp/loadups-4837/init.sysout
-rw-r--r-- 1 pi pi 55804 11 nov 17.49 /tmp/loadups-4837/RDSYS
-rw-r--r-- 1 pi pi 42967 11 nov 17.49 /tmp/loadups-4837/RDSYS.LCOM
-rw-r--r-- 1 pi pi 89161 11 nov 17.49 /tmp/loadups-4837/I-NEW
-rw-r--r-- 1 pi pi 70631 11 nov 17.49 /tmp/loadups-4837/I-NEW.LCOM
<<<<< END loadup-init

>>>>> START loadup-mid-from-init
sysout /tmp/loadups-4837/init.dlinit
running: ldeinit   -g 1042x790 -sc 1024x768 -title "Medley Interlisp" -m 256  -NF /tmp/loadups-4837/init.dlinit
greet: /tmp/loadups-4837/loadup-mid-from-init.cm
Misaligned pointer in NativeAligned4FromLAddr 0x1

*Error* Segmentation fault at address (nil).
Please record the signal and code information
and do a 'v' before trying anything else.
Enter the URaid
#:CL::NILTARTUP.EXPRESSIONSONSSSIONS

< 

[nbriggs]

please attach your makefile-init-linux.aarch64 -- that's the behavior you get if it didn't have the right flags to the compiler and if you move the mouse over the window as it's doing the init (though I thought I'd fixed that problem on August 9th)

[pamoroso]

Here's makefile-init-linux.aarch64:

makefile-init-linux.aarch64.txt

[nbriggs]

Is your maiko git repository current? Can you try the loadup-all.sh again, but don't touch the keyboard or mouse until it has finished.

[pamoroso]

git pull confirmed my Maiko repo is up to date. I rebuilt Maiko and ran loadup-all.sh -apps without touching the keyobard or mouse but the process still failed in the same way: a blank Medley window and URaid.

[nbriggs]

OK, can you attach a debugger to the ldeinit process and get the stack trace for the C code...

[nbriggs]

Uh, I don't see any reference to -e in either the medley or run-medley scripts. I use

./run-medley -g 1280x700 -sc 1280x700 -noscroll loadups/full.sysout

(because that's the best screen size for my laptop - yours would be a different size)
and if I want an Interlisp exec I just get one from the background menu.

[pamoroso]

Running ./medley --help from the root of the Medley source tree returns this flags section:

flags:

[...]

    -e | --interlisp           : (for apps.sysout only) Start in the Interlisp exec

[...]

-e can't work anyway as I haven't built apps.sysout. Doh.

[pamoroso]

After cloning the Notecards repo at the same level as Medley's:

pi@raspberrypi:~/medley $ tree -L 1 .
.
|-- maiko
|-- medley
`-- notecards

4 directories, 0 files

I rebuilt the loadups with loadup-all.sh -apps and this time everything went smootly without the error Can't find package CLOS to look up symbol LOAD-CLOS:

+++++ SUCCESS +++++
..... files created .....
-rw-r--r-- 1 pi pi 2295160 11 nov 21.18 /tmp/loadups-10446/whereis.hash
-rw-r--r-- 1 pi pi 187002 11 nov 21.16 /tmp/loadups-10446/exports.all
<<<<< END loadup-aux

>>>>> START copy-all
Added full.sysout to loadups
Added lisp.sysout to loadups
Added apps.sysout to loadups
Added whereis.hash to loadups
Added exports.all to loadups
Added init.dribble to loadups
Added lisp.dribble to loadups
Added full.dribble to loadups
Added whereis.dribble to loadups
Added apps.dribble to loadups
Added RDSYS.~4~ to library
Linked RDSYS to RDSYS.~4~ in library
Added RDSYS.LCOM.~4~ to library
Linked RDSYS.LCOM to RDSYS.LCOM.~4~ in library
<<<<< END copy-all

+++++ loadup-all.sh: SUCCESS +++++

Ececuting ./medley -a -e -n & produces this beautiful view:

I think I made it.

[nbriggs]

Yes, I believe you did. It should feel faster locally on the Pi than over the browser.

[pamoroso]

On the Pi the SDL version feels about the same as over the browser.

On the Chromebox it's noticeably faster in the browser than running the X version locally. By the way, chromeOS uses Wayland for everything: Chrome, Android, and the Crostini Linux container. So on Crostini the X version of Medley is likely going through Xwayland (or Google equivalent) too.

[nbriggs]

When you log in to your RPi, does it give you the option of an X11 session or a Wayland session? I know Ubuntu 22.04 and later gives you that option if you've got a Wayland capable GPU (I am running Ubuntu on a VM that won't run Wayland)

[nbriggs]

p.s., you don't need to rebuild the loadups - just make the new ldesdl and start the same full.sysout again.

[pamoroso]

Doh... that's why I stick with Lisp. This time I commented out the definition:

// #define  SDLRENDERING 1

And here is the version with SLDRENDERING undefined;

medley-aarch64-sdl-SDLRENDERINGundef.mp4

[nbriggs]

OK, great - it doesn't look as though there's a noticeable difference to me - do they seem different speeds to you?

[pamoroso]

No noticeable difference to me either.

[nbriggs]

OK, I'm doing to leave the default as the SDLRENDERING case.