interlisp / medley Goto Github PK

When val is an unsigned 32-bit number, the check (mkatom.c:381)

  if (val > 0xffffffff) error("parse_number : Overflow ...exceeded range of FIXP");

is not helpful.

This might give us a way to also build a medley/server in the cloud which would spin up the user's container.
Since the only function of the X server is to translate interlisp's screen bitmap into updates, and normalize the keyboard and mouse.

But that's basically a description of vnc

https://www.realvnc.com/en/developer/docs/latest/api/c/index.html

it would work locally also as a tight interface manager for windows.

/* When trying to get maiko to compile on Raspi4 with the following: */

unzip maiko-master,zip
unzip medley-master.zip
mv maiko-master maiko
mv medley-master medley
PATH=$PATH:/home/pi/medley/bin:/home/pi/maiko/bin
sudo apt-get install clang
sudo apt-get install make
sudo apt-get install libx11-dev
cd maiko/bin
makeright x

/* leads to an error in time.c regarding F_SETSIG */

/* adding the following before the first #include in the whole time.c file ! fixes the problem */
#define _GNU_SOURCE

/* This is of course a crude workaround that only works locally on Raspberry OS and maybe Debian in general /
/ it makes maiko compile and medley work on a Raspberry Pi */

/* someone more knowledgeable then me might want to fix this once and for all*/

/* PS: I am thrilled that InterLisp D is open source! Thank you all! */

The Interlisp tool set helped with some tools for allowing you to build systems from lisp sources, but it didn't enforce it, and we've seen instances #31 where it isn't true.

I imagine in many cases it was set up ok, but in the end we have to check it out file by file.

@rmkaplan has some cases where compiled and source files don't match.

think you have to weigh the risk between
-- the .dfasl is from the wrong version of the file, and it's broken
-- the dfasl is fine but recompiling from the right source will make things worse, because

• a bug in the compiler (due to emulator or needing some declarations or other compile-time environment setup problems)

I don't think those things can be resolved quickly. We have sysouts that work and are pretty stable.
we have compiled files that work. let's put out a release of what we have and warn people and ask for help testing.
I'd like to get to the point where a full sysout can be rebuilt from sources (compilling every file from sources automatically (except having to have a 'starter' sysout to make an init to compile the compiler) but we're not there.

fflush(stdin) has been assumed to flush typed input that has not yet been read by getchar(), but doesn't do so on all OSs some of which required fpurge(stdin) instead. This should be encapsulated in a set of compatibility functions so as not to clutter up more source with #if defined() directives.

in an Interlisp exec, call (RAID "eh?") and then type D to the resulting uRaid prompt.
It may lock up in a loop, or cause a segmentation fault.
It should probably exit to the shell.

some file systems don't support hard or symlinks, some only support symlinks.
shared folders in VirtualBox
Dropbox

Seems like DSK code has some problems with creating new versions in the situation with ACODE;4

more noted from @rmkaplan on changing encoding of all release Lisp files

But there is an ancient EOL issue that I thought had been resolved many years ago, but seems to still be there in the code.

I did a lot of the character reading stuff in the early days, and apparently I also implemented the notion of an external format in the mid 90’s (which I don’t remember at all). But that’s the interface that makes it easy to add the UTF8 stuff.

The issue has to do with the low-level character reading macros. They all go through a macro \inchar that basically wraps a call to \nsin, that then does xccs/ns stuff inline but otherwise calls out to the external format character function.

But \inchar wraps the \nsin call inside another macro \checkeolc, which triggers on CR and LF, and does coercion to internal EOL (which happens to be CR) when the byte sequence matches the EOLCONVENTION of the file.

If it sees a CR and the EOLCONVENTION is CRLF, it peeks at the next byte and reads it if it sees LF. If the macros are told to decrement the byte count, then the CRLF cause the necessary extra decrement. If it doesn’t see the LF, then it returns CR by itself, which is OK because that’s the internal. But if the convention is CR (which it defaults to now) and the file has CRLF, the LF is left in the file, and that screws things up. And if sees a naked LF, it doesn’t get converted to EOL.

In aboriginal times—before text files moves back and forth between operating system environments with different conventions—there was a lot of fussiness about properly interpreting the EOL. This is still the correct thing to do for output files, so that files will look good in their home environment.

But at one point it became apparent that this is a mistake for input files. Since you don’t know the provenance of a file, if you are operating on a file—or a region of a file—with text or character input functions, then any of the 3 eol indicators that happen to appear in the file should be mapped to the internal EOL.

In fact, that is what PFCOPYBYTES is doing—it calls \NSIN directly instead of \INCHAR because it doesn’t want the accidental EOL convention of the file to get in the way.

I thought I had cleaned this up a long time ago, but apparently not. I’m tempted to take another crack at it: to change the \CHECKEOLC macro to scoop up all the options, and then to recompile the relatively few functions that contain the macros (which may run into the problem in LLREAD).

What do you think?

the process of loading a new lisp sysout starts with a step called MAKEINIT, which doesn't load in code directly into the VM but rather packs it into INIT.SYSOUT.
Then you run INIT.SYSOUT with a special version of lde called ldeinit.

there is some problem with making a new startable INIT.SYSOUT.

In the meanwhile we're making new sysouts by starting with an old one and loading patch files

"help wanted" is different than "good first time project". In this case, what we need is someone to research what key bindings are now and what they should be. Also for window actions, menus, etc.

I don't think the fact that Interlisp pre-dated Mac and Windows and Linux UI guidelines is important to preserve

Originally posted by @masinter in #50 (comment)

The envos repo has a directory LISPCORE/gabriel with tools for running benchmarks and several generations of benchmarks both cl and il. Migrate this over to Medley and record results for medley on various machines.

Create a SYSOUT that runs automated tests and benchmarks for use while developing maiko.

https://github.blog/2016-02-01-working-with-submodules/

where MEDLEY is SLINGSHOT and MAIKO is RUBBER-BAND
is this a good idea? I'm having my doubts now

the Interlisp way, file package, masterscope, versioned file system, dwim, break package, lispx commands, spy

lafite, tedit, image objects, grapher

as noted by @pmcjones
if at the top level you just say "dir", it produces a stream of all files to all depths.
doesn't elide "invisible" files starting with .
and no interrupt character (control-D control-C control B control P seems to be able to get in there and interrupt.

Possibly related to #29

I see that Medley supports Common Lisp in addition to Interlisp.

What is the status of this? Is it ANSI, CLtL1 or 2, or some other variant? (I recognise that it's old though)

What's the difference between the "Common Lisp" and "Xerox Common Lisp" interactors in the sysouts?

And will both CL & Interlisp be supported going forward or just Interlisp?

Sorry if this is documented somewhere but I've been unable to find anything about it other than that it was added in Lyric.

searching files need to convert XCCS strings into UTF8 strings before searching

we've been discussing via email; issue is to make sure it's captured
https://groups.google.com/g/lispcore/c/vSPTKqrKQ3I/m/zQFrWXt_AgAJ

when I use Filebrowser on a directory that has dates in the 80's and 90's and also some after 2000, the columns don't align. At least the dates aren't wrong.

(Also, the filebrowser seems to start with depth = infinity rather than 1. For running in unix, "hiding" files starting with . would be better with an option to show them all (an enhancement)

I have a big display. When running through X I get a short window with lots of garbage. Some kind of overflow
https://gyazo.com/cec6ddc1f7712edf4ba1a24b1cea000e

/*
Maiko/Medley do not seem to run under windows using the original WSL as described
due to the fact that the original Windows subsystem for Linux does not support _GNU_SOURCE signals
i.e. the Maiko/Medley window shows up under Xming but receives no mouse or keyboard input.
As WSL development has ceased in favour of WSL2 this will not change.

The following receipt works with WSL2 (which is a full Ubuntu running in a shared VM)
and the free Xserver vcXserv under W10.
Its wordy so anyone unfamiliar can use it.
Using a window manager is added fro convenience as WSL2 does not come with one.

There will be more elegant ways, so please feel free to improve ...
*/

/*
running Interlisp release Medley 3.5 on Ubuntu 20. on WSL2 on WIndows 10 1909
assuming wsl2 is the default account for ubuntu under Windows10
and the zip files have been downloaded under W10
*/
sudo apt-get install clang
sudo apt-get install make
sudo apt-get install libx11-dev
sudo apt-get install xterm

/*
accessing Windows C drive to get the downloaded zip files,
so no need to install a browser or git-client in wsl2
*/
cd /mt/c

/*
copy zip files to /home/wsl2/
note that the path to your Windows Download folder from wsl will be something like:
Users//Downloads
*/
cp /maiko-master.zip /home/wsl2
cp /maiko-master.zip /home/wsl2

/*
unzip as follows
*/
unzip maiko-master,zip
unzip medley-master.zip
mv maiko-master maiko
mv medley-master medley

/*
compile the sources - there will be some warnings
*/
cd maiko/bin
makeright x
cd

/*
copy form architecture dependent subdrectory * below maiko to~/medley/bin
e.g.
*/
cp maiko/linux.x86_64 medley/bin

/*
set the PATH so that all parts are found
*/
PATH=$PATH:/home/wsl2/medley/bin:/home/wsl2/maiko/bin

/*
wsl2 runs in a VM with its own IP,
the W10 IP must be determined in a W10 command window using ipconfig ,..
e.g. here 168.178.192.10
set DISPLAY variable in wsl2 so the Xserver on W10 is found
*/
DISPLAY=168.178.192.10:0

/*
on W10 vcXserv a free Xserver should be installed, e.g. from the store
and should be started in a W10 command window without authentication, e.g.
vcxserv -ac
it will create a large window under W10 where all X apps will show up
use xterm as a test whether mouse and keyboard work under X
*/
xterm &

/*
start medley with sysout
*/
cd medley
./run-medley -xfull35

/*
to use the full window size one might want to use a window manager in wsl2
e.g. xfce4
select lightdm when asked
*/
sudo apt-get install xfce4

/*
once the Xserver runs on W10 and the DISPLAY is set in Ubuntu
start the windows manager
*/
startxfce4

/*
start medley to fit on a Full-HD screen
*/
./run-medley -xfull35 -geom 1920x1080 -sc 1900x1024

/* enjoy Medley full size ;-) */

In bbtsub.c helpers for BITBLT and BLTSHADE need to return ATOM_T (a Lisp atom) rather than T (1, which is interpreted as the atom NOBIND as a Lisp atom).

@nbriggs

X11 represents the scroll wheel as mouse buttons 4 and 5, and each click of the wheel gives you a mouse-button-N-press/mouse-button-N-release, where N=4 is one direction and N=5 is the opposite direction.

I think there is room in the mouse button representation word to add buttons 4 and 5. I'm not sure how we'd wire it up to do scrolling though. There's already Lisp code in LLKEY to handle mouse chording (fake the middle button if you have only an OSD two-button mouse on your DLion) and I suspect that that is at least at the right level in the system. I don't think Interlisp-D ever used the Dorado 5-key keyset, did it?
@hjellinek
I'm not aware of any official use or high-level support for the 5-key keyset, but I vaguely recall connecting one - I'm guessing to a Dolphin - and being able to detect key up/down for each key in Interlisp. I even had Brad, our AI Systems hardware tech, build me one from pushbuttons and other odds and ends.

(taking emails to mailing list and making issues)

This came up in examination of @rmkaplan init's definition of "shell"

We still have shell as a function, not a command. I remember the reason: commands are not well integrated into Medley. In particularly, you can do DEFCOMMAND to install a command and use the COMMANDS filepkg command to store them. But you can’t work with them once installed—EDITDEF/GETDEF/COPYDEF don’t work for commands. So, something else that needs to be debugged, probably difficult because the implementation is done in terms of FUNCTIONS and MACROS which are not well integrated (e.g. PF) into the medley development environment. And the relevant functions seem to be in the file CMLDEFFER, which has the following legend at the top:

• "BE VERY CAREFUL CHANGING ANYTHING IN THIS FILE!!! It is heavily self-referential and thick with bootstrapping problems. All but the most trivial changes (and some of those) are very tricky to make without blowing yourself out of the water... You have been warned."

Timezone detection doesn't appear to work on Linux systems, but does work on MacOS.

As many have noted (including most recently @pmcjones )

the MacBook fan was running full-blast because of the busy-waiting emulator

there isn't a straightforward solution because Lisp always is running, if only to track the mouse and blink the cursor, handle incoming network packets, and do other periodic polling events many times a second. But it might be possible to reduce the load if all the processes are hung in I/O or timer wait.

At the moment, there are either no declarations or hand-copied declarations for cross-file references to functions, along with a few forward declarations in the source files.

This should be cleaned up to have consistent include files containing the definitions corresponding to each source file that can then be used to provide forward declarations (each xxx.c should include its own xxxdefs.h) and for cross-file references.

This will silence a large number of warnings for implicit declarations.

I ran the bin/medley script with LDESRCESYSOUT set to a bogus value and received this error message:

Coudn't find a sysout to run;
 ldex options:
 [...]

If you have any further questions, please refer to the manual or
call our tech support at (800)228-5325 or (510)763-0516.

Since this is unsupported software, we should remove that last couple of lines or replace it with something like

Please refer to the manual for further information.

According to the IRM, MAPATOMS takes a function of one argument which is called
with each litatom in the system -- so

(LET ((FNCOUNT 0)) (MAPATOMS (FUNCTION
     (LAMBDA (FOO) (IF (GETD FOO) THEN (SETQ FNCOUNT (ADD1 FNCOUNT)))))) FNCOUNT)

should return the number of atoms with a definition. Instead it fails with

FOO is an unbound variable

If you don't reference the lambda parameter it does indeed call the function 28000+ times successfully.

lde -info should produce one copy of the information, not two:

% lde -info
Emulator for Medley release 3.51
Creation date: Tue Sep 29 19:33:55 2020
Supports 256Mb virtual memory.
Has no foreign-function-call interface.
Supports Sun European Type-4/5 keyboards.
Emulator for Medley release 3.51
Creation date: Tue Sep 29 19:33:55 2020
Supports 256Mb virtual memory.
Has no foreign-function-call interface.
Supports Sun European Type-4/5 keyboards.

The -info option is handled in both the X option reader and in the main program, so print_info_lines() gets called twice.

There are now 2 kinds of compiled files in Medley, with extensions DFASL and LCOM. DFASLs are produced by the common lisp compiler, LCOMs are produced by the byte compiler.

Some files have both DFASL and LCOM versions, that may be compiled on different dates and maybe even on different source versions. The one that gets loaded is likely determined by the order of extensions on a particular list. So this is not a good situation: for each source file there should be only one type of compiled file.

But also, this raises the question, why does the system as a whole have 2 different compilers and 2 different compile-file formats?

The LCOM files have the advantage that incremental loading of single compiled functions via LOADFNS is possible, and that is very useful in debugging contexts. Incremental loading is not possible from DFASL files.

DFASL files presumably have the advantage of faster loading, but on modern machines load-time is in the noise.

So: does anybody know whether the common-lisp compiler and DFASL files have other advantages that would be lost if we gradually deprecated them and reverted everything to LCOM? Are there constructs that only the common lisp compiler can compile, or does it have better or different optimizations than are provided by the byte compiler?

It turns out that the ancient Lisp sysout that we try to update (until we can do a MAKEINIT) contains Interpress but does not contain Postscript. Which seems a little retro--are there any Interpress printers left in the world?

I propose at least to include postscript in the updater that makes the lisp.sysout, and to remove Interpress (and its fonts) from the load-up that we will use when we can build from scratch.

there were some D machines with Color (michele has a color board 512x512x24 bits).

the name (if you prefer that over the number 56) for the caps lock key is LOCK.

call (KEYACTION 56 '(LOCKTOGGLE . IGNORE))
(LOCKDOWN . LOCKUP) was the previous value. Warn users that if you change the caps lock setting while the cursor is outside the X window it will get out of synch because X doesn't see that key event.

There is a directory in history/1990s/1993-envos called 'gabriel' which has the gabriel benchmarks as well as a harness for running them. There are a couple of problems:

• some of the benchmarks take so little time, the printout of the time to 3 decimal digits isn't enough-- the total time is .001 seconds. Either add more digits or run the benchmark more times (but the framework :repeat keyword doesn't do that.

• there are old log files in a 'results' directory inside gabriel. Should new ones go to github pages wiki, or google sheets or in the medley repo?

• The ctak benchmark never stops on a pi.

• the numbers other than "elapsed time" aren't very reliable according to the comments in the maiko C code. Still, elapsed to elapsed time is probably the most useful.

@rmkaplan reported:

Windows may still be the outlier, Mac OSX and Unix/Linux are LF.

It’s really a question of what the default EOL convention should be when output streams are created. It shouldn’t matter for input streams, at least for the operations that read characters and not bytes. The character reading functions should all recognize any of the EOL conventions on files and map them into the internal CR (the value of (CHARCODE EOL). (I remember setting it up that way—silly to have to know where or how a file was created before you could read it).

I thought that Unicode might have something to say about this, but they aren’t very helpful. They point out (in the Unicode 3.0 book that I have) that the CR/LF/CRLF conventions are confused…and then they add to the confusion. They define a new code U+2028 as the unambiguous “line separator” (also an unambiguous “paragraph separator" U+2029).

My Xerox XCCS book doesn’t say anything about this, so I’m not sure what the representation is in XCCS-compliant files (which would have run-codes for mixed character-set strings, but control characters are unique in any run).

My temptation is to change the default, so that we are more compatible with Unix/Mac files. We were never compatible with Windows/CRLF. If not for all files, then at least for UTF8 and UTF16 files.

In prowling around, I have also discovered that some of the low-level files got corrupted by the Japanese. A substantial part of the LLREAD file, for example, is filled with conversion tables for various Japanese coding systems, and this stuff is mixed in in a number of other places. Should have been in separate and later files—hard to imagine that these would be needed in the INIT.SYSOUT.

for use with running new versions of maiko.

Gabriel benchmarks #51 and also tests from envos ( https://github.com/interlisp/envos )
MISC/test
and probably LISPCORE/internal/library/test

@nbriggs :

the whole "makeright ..." build process is a bit of a mess ...

To my mind the real problems are mostly issues with factoring the OS dependencies properly in the code (is it <strings.h> or <string.h>, do you need <time.h> or <sys/time.h> or both? Do we need <unistd.h>? Do we have <stdint.h>? Do we depend in <ioctl.h>? Do we need to use fcntl() or ioctl() to speed up the I/O for X displays? etc. etc. etc.) If someone were, for example, trying to port the code to an ARM processor on e.g. a Raspberry Pi, what would they need to change in the configuration? What if it were WebAsm? What about Apple Silicon? What if we were trying to rebuild Medley 2.0 instead of 3.5? It's not well documented!

(LLSH 8388808 8) returns a negative number. it should just print the bytes. in ACODE

In the keyboard mapping tables, the table entries are defined as unsigned char, but unused entries are initialized to -1 and checked for being > -1. This is incorrect. The type of the entries cannot be changed to signed char because some keyboards have entries greater than 127, however the unused entries could be 255 and the checks could be < 255.

Clean up the code in src/initkbd.c and src/keyevent.c.

Broken, won't load, not useful, buggy, cant open docs in tedit, odd copyright etc

Code in init_conspage() (conspage.c) that sets up the free list of cells on the page does not initialize the last cell on the page, leaving its CAR and next_free values unset. The code that allocates memory also does not initialize memory. The init_conspage() code only produces a well-formed page if memory is set to zero.

This should be fixed by explicitly initializing the last cell on the page rather than depending on memory being zeroed at allocation.

Without setting -sc, the screen defaults to the full size of my display on Kubuntu 20.04. This is not good since I have multiple monitors and it sets the size if the Medley screen to the overall size of all monitors put together. There doesn't seem to be a way to pass in -sc to the script.

the benchmark CTAK which you can find in github.com/interlisp/envos/ under lispcore/gabriel/benchmarks /gabriel-tak.dfasl runs fine (and quickly) on a intel mahine but hangs when running on a pi.

What distinguishes CTAK is the heavy use of catch and throw.
I suspect the UNWIND opcode but mainly because I don't know what it is supposed to do.

In dir.c, enum_dsk_prop() (DOS case) line 570, if the previous stat failed, all the fields in sbuf are undefined, so it is an error to read sbuf.st_mode, sbuf.st_ino, sbuf.st_size, sbuf.st_mtime, sbuf.st_atime. Likewise, in the non-DOS case, line 706.

In enum_dsk(), line 968 the same pattern is duplicated, and at line 1071, and 1162, and 1269, and 1344.

It's unclear what the correct behavior is -- ignoring the symbolic link to the non-existent file would cause trouble if the user attempted to create a file with the same name as the link, perhaps it should lstat the link if the link is bad, but this needs a deeper analysis of the code.

Here’s a hypothesis:

The bug is in MULTIPLE-VALUE-CALL, it isn’t popping the stack properly when it receives more than a single value.

If this is true, then it is a total accident that I tripped over this:

I used SEE of a UTF8 encoded file to test my conversion interface, SEE ends up calling PFCOPYBYTES to interpret font changes in case it is a Lisp source file (which my file is not). PFCOPYBYTES takes start and end byte positions, because it is typically called from PF not for the whole file (as for SEE) but to pick out the definition of functions at particular byte positions as provided by a filemap.

PFCOPYBYTES is set up to deal with the fact that in the NS world (and other external format worlds) there is not a one-to-one correspondence between byte positions and character positions. That’s not an issue for most applications, but it is crucial for the PF invocation.

The low-level character readers hang off the open macro \NSIN, which takes an argument that says whether the number of bytes read should also be returned with the code. In the NS case, the second value is set to a local variable in the inline compilation. But in the case where there is a call out to a different encoding, the encoding-function is given a flag that says it should return the number of bytes it read, as a second value. That’s what’s happening in this case, and since it is repeated many times in a loop and if the stack isn’t cleaned up properly on each invocation, we would eventually get the overflow.

Putting aside this possible bug, this is an unfortunate implementation of PFCOPYBYTES—and according to the edit dates, it is probably something that I did for NS about 25 years ago, screwing up a simpler implementation that Larry had originally done about 10 years before that.

The problem is that it exports the details of a very low-level macroed interface to a very high-level function. The more direct implementation, given that bytes and characters are not 1-to-1, would have been to test the actual file ptr at each character, instead of the over-eager optimization that tries to second guess the counting with simple arithmetic. O better still, to recognize this as a first-class conceptual issue by adding a flag argument to READC and READCCODE indicating whether the bytes-read should also be returned as a second value.

On Aug 2, 2020, at 7:11 PM, Ron Kaplan [email protected] wrote:

Part of the mystery is that the stack overflow doesn’t happen until it has read about 20K characters. So somehow this must be growing over time, even though it doesn’t look like anything should affect that frame from inside the loop in PFCOPYBYTES. The loop calls \NSIN and \OUTCHAR, and in this case the NSIN does an apply* to \JISIN. If you put a break on \JSIN, I wonder if the stack frame is big from the get go, or whether it grows over repeated calls.

On Aug 2, 2020, at 6:41 PM, Ron Kaplan [email protected] wrote:

The last one is from the RESETLST inside PFCOPYBYTES? The other ones from the WITH-OPEN-FILEs in the little test routine?

How do you read the length of that frame, is it the difference between 4c22 and f092?

On Aug 2, 2020, at 5:53 PM, Nick Briggs [email protected] wrote:

So this is what I see when I use the debug tools to dump the stack -- seems to reflect what URAID says, but, near the end of the stack,

4c22: SI:UNWIND-PROTECT alink: 0x4c10, clink: 0x0000, next: 0xf092

that SI:UNWIND-PROTECT appears to have allocated a huge amount of stack space, for reasons I don't understand.

Tried to see if I could load CLOS into the full sysout image, got a break.

@rmkaplan writes

The readtable and the package in the DEFINE-FILE-INFO expression have to be installed before any sense can be made of a file. I discovered that you can’t even read the FILECREATED expression if you don’t deal with those. And it’s actually hard to deal with them, because the specified package may not be defined in that particular file but in some other file that you don’t know about.

With respect to the filecreated expression, FILECREATED itself is safely in the Interlisp package. It will show up as IL:FILECREATED if DEFINE-FILE-INFO says there is a different default package (e.g. “CL”). That’s OK, the problem is that the filecreated expression also has a list of changes—the names of functions, variables, etc. in the file that have been modified. And those are atoms either in the default package (no colon) or in some other package that may or not be known.

I ran into this when I was trying to extract the internal dates for the directory comparisons. I finagled it by temporarily disabling : in the specified readtable, so it wouldn’t break on unknown packages, and then I could just call READ to get the expression rather than writing my own special parser. (I thought of creating at least the default package on the fly, but wasn’t sure whether that would screw up the actual definition of that package if was loaded later.)

I think that this imperfect integration of packages with the filepkg is the source of other problems, for example, that FINDCALLERS and EDITCALLERS tend to break on files that reference not-yet-defined packages.

The new M1 mac is architecture "aarch64". We need to update "machinetype" and add "makefile-darwin.aarch64-x" to support building on these systems.

Missing call to XFree() the result of XGetKeyboardMapping before returning from make_X_keymap leaks the keymap result.