> For the complete documentation index, see [llms.txt](https://doing.goshrow.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doing.goshrow.tech/stuff-i-liked/notes.md).

# Notes

## 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](https://askubuntu.com/questions/83868/compress-in-tgz) (wise sayings), `tar -cvzf resting-og-tool.tgz /opt/---/uber-tool-service/tool_renamed`

4. Apply t[he git patch onto the non git tool](https://www.reddit.com/r/git/comments/m1sw8a/apply_patch_files_to_non_git_repo/) 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](https://stackoverflow.com/questions/7842333/is-it-possible-to-interactively-delete-matching-search-pattern-in-vim) on the patch file.&#x20;

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

   From the [documentation](http://vim.wikia.com/wiki/Alternate_delimiters_for_the_replace_command):&#x20;

   > 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://doing.goshrow.tech/stuff-i-liked/notes.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.