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.

Construct a base cygwin docker environment

Appium install method

Using Appium and inspect.exe script can be written to automate the cygwin download and install.

Phase one is to test that a target can be build, where the source is my machine the appium host. The cygwin image is copied to the target machine from my build host.

Phase two is to see if the build can be done on the target machine directly.

This Critic closed see Cycle 2

Critic of Build a CYGWIN environment in docker.

AddUser needs debugging, fails to work as expected

Build the base CYGWIN environment.

UI Automation

UI Automation is an automation tools for Windows UI. Can a powershell script build the base CYGWIN image?

• Can this be done in the docker windows image? likely no.
• Can cygwin install be automated? likely yes.

UIAutomation.dll how to get it?

Best Instructions

The UIAutomation.dll file is in a cryptic named file which need to be extracted. The best instructions for how are at https://community.spiceworks.com/how_to/160771-how-to-obtain-and-install-uiautomation-dll.