I am experimenting with a SBCL compiled for mingw64

I use the Solarian Programmer’s Guide to build SBCL under mingw64. I am building the 2.0.0 from source.

I have MSYS2 installed at C:\devel\msys64 which is /c/devel/msys64 in MSYS2.

I have the binary windows distribution of SBCL 2.0.0 at /c/devel/SBCL_2_0_0-bin and I keep the sources at /c/devel/SBCL_2_0_0-src this includes the source.tar.bz2 the binary msi, as well as the expanded source.

I used these steps at MSYS command line do:

Make mingw64/sbcl run from slime.

In a previous post I created a sbcl which runs from the mingw64 shell. When I run sbcl from the ming64 prompt all works as expected but running it from CMD causes sbcl to complain that the core was built for another runtime.

This problem has two potential solutions:

• 1. Compile sbcl with CMD runtime.
• 2. Start a bash login shell and run sbcl programatically.

Option 1) requires I study the make process and possible build SBCL under MSYS2 by directing make to use mingw64 gcc.

Software is brittle

A change of a single character in the source code can cause a failure. When debugging these type brittle errors are fixes. It is only with testing to address the brittle points that software can become useful.

Software systems can be brittle

The inspiration for this post is the difficulties I am having using SBCL on Windows 10. I have viewed SBCL as a unix product with limited support for the Windows port. Code has been contributed that assumes “the unix way” of thinking (should I say the New Jersey way?)

There is no current Chocolatey package from SBCL!

SBCL 2.0.0 on 12/29/2019 which include a windows installer. There is a homebrew package for SBCL (see https://formulae.brew.sh/formula/sbcl#default ) so MacOS has a current SBCL. When you check for Chocolatey package from SBCL (see https://chocolatey.org/packages/sbcl ) you find a package had a error 5 years ago.

The old chocolatey package is not maintained.

A new chocolatey package should be created and a maintence procedure should be created. The best strategy is to introduce a script chocolatey release script into the SBCL release code in the SBCL build source code.

The source for info on MSYS2

I refer to the Detailed Install Guide Updating packages.

Instructions

In MSYS2 shell execute pacman -Syuu follow the instructions about terminating the shell process, I just close the window, and say OK to the termination dialog. Repeat until no more upgrades.

Ephemeral + Customization

Launch an ephemeral vm with customized environment. All permanent state is stored in an attached environment. The vm can be killed or restarted without data loss.

Redesign for reliablity

Current useage

• Main Client uses a FileHistoryHost volumn and a Bugzilla server
• FileHistoryHost is a shared Windows Volumn from the host.
• FileHistoryHost also run a VirtualBox.
• A VM debian is run on the VirualBox.
• VM debian runs a Bugzilla service.
• VM debian runs a MariaDB service.
• Bugzilla service uses MariaDB as a store.
• VM debian does backup the Bugzilla database to FileHistory Host.
• Former Main Client needs Fan Repair.

BlueSky Wishes

• Backup as a service with switchable archive servers
• MariaDB in separate VM or container
• Bugzilla in separate VM or container
• A development build service - likely Gitlab Runner based.

This view is of a higher level

To allow docker process isolation of our target container we start with a specific version container. It is desired that this process will work for all relased OS versions.

Using GUI Install of a component…

Large complexities of any scripted GUI install, require a design period to create extract the necessary GUI element info, an install method design and debug process, an orchestraion design using GUI install toolkit.

In the redesign process for automation for cygwin in a docker container the following needs to be considered.

Considerations

• Appium or WinAppDriver based scripts
• The inclusion of WinAppDriver in target container.
• Configuration of WinAppDriver ports
• A developer language - Can I use common lisp?
• Scripting of automation

Terms

• A Task a specified activity
• A Documented Structure a solution to Task.
• A Coded Structure a completely coded solution to a Task.

Thoughts

• Proof of concepts demostrates how to perform a certain activity leading to documentation and/or coding of a Task.
• Issues about ports and appium for direct WebAppDriver relate to “the stucture” of the proposed solution to a task.
• A Coded Structure is prefered over a Documented Structure.

Resources

• WinAppDriver Docs page
• WebAppDriver Docs on Appium or WebAppDriver
• Common Lisp Selenium Tutorial

Dynamic variables

Early versions of LISP had Dynamic variables. This distinguished those variable from the Static ones which are largely fixed. Things were fairly simple under this scheme but more complex for the programmers.

Lexical variable and Closures

Later LISPs developed “lexical” bindings where the scope of the variables was limited by enclosing forms with in the text of LISP code, lexical is borrowed from the lexical analsys phase of compilers.