Notes

When I finally ditched my paper notebooks.

Re-entrancy

Reentrancy is an aspect of computation wherein the program or subroutine at hand is safe to be called irrespective of its other invocations or their state of interrupt. These are thus signal safe and are shareable stubs of code. It might resemble thread safety but over here it is about running concurrently on a single processor system. Thus, is different. Results need not carry any idempotency. Some rules for such a subroutine are :

  • Reentrant code may not hold any static or global non-constant data.

  • Reentrant code may not modify itself.

  • Reentrant code may not call non-reentrant computer programs or routines.

A Lowly Convoluted Changeset

We have a tool operating out of a python3 script bundle. This repository is inside a parent git repository, as uber appliance code base > microservice (which is a monolith unto itself) > functional tool. On exporting the uber appliance to a customer / testing environment, the script is added into a folder within a service opt folder. This is of course beyond the scope of git or any VCS, since it is the final deliverable.

So, I have a local change at uber/tool matching with origin/uber/tool, while my test machine has similar functionality provided at /opt/---/uber-tool-service/tool_renamed. My local change is definitely behind the changes at the test machine. Herein, to patch test it, I might just start a new build for the entire appliance, or even the monolithic microservice by generating the requisite deliverables (.ova, .jar, .rpm), however my script is not compiled on the other end. It just exists. Minus the test methods, plus the bundling of dependancies.

To patch this, I initially just injected my changes as they were onto the appliance. But as the scope grew and so did my weariness of making a log about it, my steps follow as such:

  1. git diff development -- ../diff-tool.patch on my local branch.

  2. Transfer this file all along to the test machine. A bunch of scp ../diff-tool.patch root@test.machine:/home/folder

  3. Inside the test machine, take a backup of the pre-configured tool (wise sayings), tar -cvzf resting-og-tool.tgz /opt/---/uber-tool-service/tool_renamed

  4. Apply the git patch onto the non git tool as per : patch -p1 </home/folder/diff-tool.patch

  5. Realize that the tool at local and origin is now renamed to tool-renamed

  6. Replace the names on the patch file.

  7. Add in a convoluted escape sequence only to marvel at the beauty of https://stackoverflow.com/a/2465176 which lists down

    From the documentation:

    Instead of the / which surrounds the pattern and replacement string, you can use any other single-byte character, but not an alphanumeric character, \, " or |. This is useful if you want to include a / in the search pattern or replacement string.

  8. And marvel at the simplistic beauty to end up in a lowly convoluted changeset.

PreviousWebPages

Last updated