## Revisiting the Android, UserLAnd app.

One of the facts which I had reported some time ago was, that a handy, easy-to-use Android app exists, which is called ‘UserLAnd‘, and, that I had installed it on my Google Pixel C Tablet. As the tooltip suggests, this is an Android app that will allow people to install a basic Linux system, without requiring ‘root’. Therefore, it mounts the apparent, local Linux file system with ‘proot’ – which is similar in how it works to ‘chroot’, except that ‘proot’ does not require root by the host system to set up – and any attempts to obtain root within this Linux system really fail to change the userid, of the app that the files belong to, or of the processes running. Yet, becoming root within this sandboxed version of Linux will convince Linux, for the purpose of installing or removing packages via ‘apt-get’.

In the meantime, I have uninstalled the ‘UserLAnd’ Linux guest system from my Pixel C Tablet, in order to free up storage. But, I have set up something like this again, on my Samsung Galaxy Tab S6 Tablet, which has 256GB of internal storage. Therefore, I have a few observations to add, about how this app runs under Android 10.

Through no fault of the developer of this Android app, the user is more restricted in what he can run, because Android 10 places new restrictions on regular processes. Specifically, none of the major LISP Interpreters that were designed to run under Debian 10 / Buster will run. (:1) What the Linux developers did was, to make the garbage collection of their LISP Interpreters more aggressive, through a strategy that changes the memory protection bits of memory-maps, to read-only if they belong to the state of the machine, and then, ~to try deleting as much of the bytecode as can still be deleted~. Pardon me, if my oversimplification gets some of it wrong.

Well, Android 10 no longer allows regular apps to change the protected memory state of any pages of RAM, for which reason none of the affected LISP Interpreters will run. And for that reason, neither “Maxima” nor anything that depends on Maxima can be made to run.

Yet, certain other Linux applications, notably “LibreOffice” and “Inkscape”, run just fine… So does “GIMP”…

Also, the way in which files can be shared between the  Android Host and the Linux Guest System has been changed, as the following two screen-shots show:

Here, the file ‘Text-File.txt’ has been shared between Android and Linux. Larger files can also be shared in the same way, and the folder bookmarked under Linux. (:2)

In many ways, the Linux applications behave as described before, with the unfortunate exceptions I just named, and I intend to keep using this app.

Technically, a Host app that just sandboxes a Guest Application in this way, does not count as a Virtual Machine. A real VM allows processes to obtain root within the Guest System, without endangering the Host System. Also, ‘a real VM’ provides binary emulation, that makes no specific assumptions about the Guest System, other than, usually, what CPU is being used. Emulation that includes non-native CPU emulation is still a somewhat special type of emulation.

Therefore, the ability of Debian 10 / Buster to run under ‘UserLAnd’ depends, in this case, on the Linux package maintainers having cross-compiled the packages, to run on an ‘ARM-64′ CPU…

(Updated 9/13/2020, 21h30… )

## Common LISP has turned any Function a Symbol holds, into An Additional Field.

This was a posting of mine, in which I pondered the more-general question, of how different LISP variants may recognize, that they have encountered a List or an Atom.

In this posting, I went into the specific question more, of how to use Common LISP, and manipulate the distinction between Symbols that store Functions, and Symbols that store Lists. Obviously, Common LISP requests, that we use the built-in function (symbol-function) to refer specifically to the Function stored within.

And in this posting, I carried out a very basic experiment, to see whether a data-type is stored on the plist, in Common LISP. The answer was No.

I should not even refer to my experiments as such, because they are too rudimentary to qualify. Instead, these are simple efforts to educate myself – and anybody else who might be curious enough to read my blog – about LISP, through Common LISP. Testing the plist of a Symbol, is very straightforward in practice.

I have gone further with the present posting, by just confirming what I already suspected. When we use a Symbol to store a Function, in fact this gets treated separately, and again does not get stored on the plist. The function-field could state that the Symbol stores a Compiled Function, or a List that needs to be Interpreted, according to which blocks of addresses it points to…

What I have noticed however, is that in the case of Predefined, Compiled Functions, meta-data does get stored on the plist, which allows the LISP Compiler to act more, as Compilers do, for languages intended to be procedural in style. LISP was originally intended for declarative-style programming, but to be able to compile each function, it was necessary to standardize the way parameter-lists work, as well as return-types, conform to how they work in procedural languages such as C or C++.

In keeping with that, the plist of a Compiled, Predefined, Common LISP Function, contains templates, that state expected parameter-type-lists, just as C Function-Prototypes would have it.

But what seems to follow, is a flavor of LISP, which does not require the plist, in order for images to execute, and in order to be able to evaluate Lists. They only seem to be needed, to develop images and ‘LISP-Programs’.

The following code block shows, what happened in my most recent session…

## A New Realization about Common LISP

In This Posting, I explored the potential fact in great depth, that certain implementations of LISP may have Symbols, one field of which holds a value in the sense that a variable should hold a value, consisting of lists and atoms, while another field can hold a property list, also known as a “Symbol Plist”.

Well it has come to my attention, that Common LISP in particular, has some fixed constraints regarding this subject.

When Common LISP evaluates expressions that are lists, the CAR is allowed to be a nested list, which defines a lambda-expression. But otherwise, the CAR needs to be an atom – i.e., a symbol – which has a compiled function, stored in the plist.

We may export function-definitions into the value-field of a symbol, such as into a variable, like so:


(defvar *function-var*
#'(lambda (pos-arg1 pos-arg2)
(list pos-arg1 pos-arg2) ) )



If we do, then we must call or apply this function like so:



(funcall *function-var* 'Foo 'Blatz)

(apply *function-var* '(Foo Blatz) )




If we do not abide by this convention, we get error messages, because the function-definition in the value-field is not searched by Common LISP, when the symbol is itself the CAR of a list, and because when we assign lists as function-definitions, those do not get assigned to the symbol plist.

This observation seems to be corroborated here.

This convention, of Common LISP, accelerates execution greatly, because the interpreter does not need to make complicated arrangements, depending on what type of functions appear as the CAR of a list. The context now specifies that.

Once we are aware that this constraint exists, adapting our value-field-functions to it, is straightforward, because of the built-in function

(symbol-function 'symbol)

Which disembodies the part of the plist, that is supposed to hold functions and not values, in this case, belonging to 'symbol. Hence, the following experiment should succeed on a working Common LISP Compiler:



GCL (GNU Common Lisp)  2.6.12 CLtL1    Oct 28 2014 10:02:30
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

>(setf (symbol-function 'my-function)
(lambda (pos-arg1 pos-arg2)
(list pos-arg1 pos-arg2) ) )

(LAMBDA-CLOSURE () () () (POS-ARG1 POS-ARG2) (LIST POS-ARG1 POS-ARG2))

>(my-function 'Foo 'Blatz)

(FOO BLATZ)

>(my-function 'Ergo 'Sum)

(ERGO SUM)

>(quit)




Now, the somewhat unexpected line output from the definition, is due to the (setf) function doing what all variable-setting functions in LISP do: They not only bind the value asked for, to the field, but also return the same value to the calling context, because doing so can make certain LISP code more practical.