From 'OR' to Invention - Towards a Common Lisp Desktop Development Enviornment and Implementation-Specific "Robot Innards"

Part 1 - Logic and/or GUIs

This week, I've completed a session of the DeVry University Online (DVUO) basic digital electronics course, ECT-114. Among the topics addressed in the course: The generic qualities of basic boolean logic operations.  Presently, I'll skip the reiteration of the typical overview I may sometimes wish to present about MIT CADR, in all of its public domain Lisp Machine design qualities. There are reference resources available, online, about that topic in computing history -- such as at Unlambda.

The page that I am writing, here, it is not a project page about a Lisp Machine design, insomuch. Inasmuch, this is not a page about Xilinx FPGAs, and it's not a page about SysML, and it's not a page about SPICE NG. I think, those are all relevant topics for Lisp Machine design, but this it no about those topics -- not "This page," insomuch.

This is a page more about my wishing to develop an idea in regards to data flow programming, the ARM architecture, and digital logical applications. It's a sort of "Once in ever" kind of thing, to me, that I think I have arrived at a convenient coincidence of some concepts, at that.

Here's my best approximation of an outline:

• Boolean logic
• Boolean logical operations in Common Lisp, such as BOOLE [function]
• Data flow programming
• The ARM MCU instruction set architecture, as a subset of RISC architectures
• At that, referencing: Dandamudi, Sivarama P. Guide to RISC Processors. Springer (New York) 2005. Kindle edition
• Specifically,  Kindle location 1521, in that same edition
•  Not: The literally four instruction architecture of CADR — but that's pretty neat.

 Dandamudi's effective ARM instruction set reference,  specifically at that location in the same book, the full set of boolean logical operations in ARM is denoted -- as I would write in a literal expression syntax, here:

• AND
• OR
• XOR
• NOT -- and similarly, 'mvn'

Dandamudi also denotes the bit clear instruction, 'bic' and the count leading zeros instruction, 'clz', in that same context. Personally, I would like to focus on those four instructions denoted in that itemized list -- because that's it. In that exacting set of instructions in the ARM instruction set, there are exactly three diadic logical operations and the monadic compliment operation, NOT. Assuming that I've not made any to wide-arcing an interpretation of the matter,  presently, it must be that -- under such as DeMorgan's theorem -- those total of four microcontroller unit (MCU) instructions can be used for implementing all possible boolean logic functions.

I think that's pretty neat, firstly. Secondly, it reminds me of an at least ad hoc view -- "my own view," that -- about the VOP architectures of each of CMUCL and SBCL

So, then, of what practical relevance could that simple, cheerful matter of observation then be? I think, there could be a number of ideas that one could follow through with, at that:

• To study any single fork of an ARM port of SBCL 
• to see how the full set of Boolean Logic procedures are implemented in SBCL on ARM
• likewise, to study the VOPs implementation in CMUCL and SBCL
• optionally, to model some of "those VOPs" in a relatively bare-bones visual model, in an abstract graphical syntax such as of UML 
• focusing specifically on CLtL2 BOOLE [Function]
• To study more of CCL
• firstly, to determine how it may be approached, and if it is already done in CCL, to implement assembler instructions directly in Lisp code, in CCL on Linux ARM and Android ARM platforms
• commenusrately, to study how the CLtL2 BOOLE function is implemented in CCL
• whether via LibC
• or directly in assembler instructions?
• Novel sidebar: To begin to develop a graphical model for logical data flow programming, in Common Lisp, commensurate with either mode of study
• Inspired by National Instruments LabVIEW
• Focusing on CLIM
• in any single Lisp implementation on Linux
• Linux and not Windows, as both a practical and personal choice -- namely, because my SLIME configuration really isn't working out, presently, in my Windows 8.1 desktop OS environment. (There's something about SLIME REPL not being loaded correctly in Emacs 24 on WIndows -- I haven't tried out XEmacs, at that, but might try that out, next, on the PC....)
• because:
• CLIM was defined with a platform-agnostic window system interface
• CLIM is implemented in the free/open source McCLIM source tree
• CLIM can be integrated well with CLOS MOP 
• CLIM in CLX would not need any foreign function calls, such as might be difficult to "Trust" solidly in some implementations' respective interfaces onto the PC host environment -- or alternately, one might wonder: Why is CL+J not implemented any further than in MKCL, if it's not a matter of "hairy" FFI in some other Common Lisp implementaitons?
• CLIM's window system interface framework, that being "one thing", mostly in regards to geometric interfaces onto user interface (UI) layouts
• CLIM's effective gadget toolkit being "another thing," such that might seem to effectively parallel such gadget toolkits as are provided by  UI components such as Qt and the Cairo UI, those implemented in C and C++, on existing operating system architectures.
• CLIM effectively "Leaves a door open" for further widow system development, with the respective CLIM implementation publishing a fairly architecture-neutral meta-interface, such as may be utilized by any CLIM application user interfaces, for interfacing transparently onto any single, host platform window system. In that much, it could seem nicely "Designer friendly," though it might not seem so stellar as a Qt application in all its maturity of human computer interface (HCI) designs
• and if that's not enough for a practical sense of focus, but of course CLIM isn't easy to "Make work" on Microsoft Windows platforms -- not without something like XMing or Cygwin -- probably not anything I myself would recommend for production applications, in any sort of a consumer market, if simply due to the complexity of running an X server on top of the Microsoft Windows Explorer shell.
• If that's still not enough for practicality: It is possible, moreover, to install a Linux virtual guest image onto a Microsoft Windows desktop host platform, using Virtualbox. 
• I myself would recommend Linux Mint as a Linux desktop OS, whether for a virtual guest installation or directly as a host OS on a desktop PC. Personally, I think Mint's Cinnamon desktop environment is pretty keen for desktop Linux work
• Using a virtual Linux Mint 64 bit edition (specifically LMDE 201403) in Virtualbox (4.3.12) on a 64 bit Microsoft Windows PC (Microsoft Windows 8.1)  "there" it is possible to run the Mint desktop environment in Dropbox seamless mode, such that the Linux guest desktop applications then would integrate quite smoothly with the desktop environment of the host PC OS. 
• I think it's fine for a development environment, and with some further adaptation in the Linux guest desktop configuration -- e.g towards a more specific window manager selection and towards disabling the screensaver configuration, for instance -- that it could be alright for "production use," then, as a production-grade developer environment component
• Of course, I've read that there's a Common Lisp desktop environment. That could be towards something of a good component for a desktop Common Lisp software development toolchain, as such -- simply, a nice Common Lisp interface onto the bare-bones X.org session, the virtual guest installation then not really needing adding any further "GUI features" in such a configuration -- not menus, not panels, not pager, just GUI applications and maybe X session management.
•  So, that's my recommendation for a working McCLIM development environment on a Microsoft Windows desktop OS -- all in one itemized list. Some features "New"
• Because invention.

There's also the ARM MCU, beside all of the Intel desktop wonderment.


Assorted resources

•  Gorrie, Luke, et al. Connecting to a remote lisp. SLIME Project
• Virtual Networking. Debian Wiki
• Stumpwm
• To do: X Session Management in a Bare-Bones Common Lisp Window Manager

 Because invention, and kites.

 Part 2 - "Development Environment" Not for Sale

In regards to beginning to develop a development environment with Virtualbox, Linux Mint (LMDE),  and Common Lisp, there are some initial observations I would denote:

• Preferring Git for SCCM roles, I use Git, even for so much as storing my Emacs configuration files, i.e "Dot directory"
• Using Git in a virtual guest OS is not the same as using Git on a host PC
• When the virtual guest OS is running in Virtualbox, then a Git client in the virtual guest OS may access a repository installed on the host PC, namely if and only if:
• The Git repository on the host PC would be stored in a Virtualbox shared folder, and/or....
• The Git repository on the host PC would be available via a network service protocol such as SSH
• Thus requiring that an SSH service would be running in the host PC OS -- as could be installed via Cygwin, when the host OS is Microsoft Windows
• Therefore, effectively requiring that any changes made in the guest OS would be Git-pushed from the source tree/repository on the guest OS to the source tree/repository in the host OS, and conversely
• The Shared folders approach would be simpler
• The SSH git approach -- the second "of  those" -- depending on the host OS' firewall configuration, it may serve to allow for the Git repository to be accessed from the host OS via local LAN. Furthermore, it would not be exclusive of the shared folders approach.
• A git repository in such a host environment may be shared with the guest OS via shared folder and via the local LAN (and the guest OS, ostensibly)  if the appropriate SSH service would be configured appropriately for the latter.