You're describing a database.
Depending on the number of jobs, you may be able to store it in memory, otherwise, for small to medium size, sqlite. For larger datasets, Postgresql or MariaDB, for humungous, Parquet or duckdb.
You're describing a database.
Depending on the number of jobs, you may be able to store it in memory, otherwise, for small to medium size, sqlite. For larger datasets, Postgresql or MariaDB, for humungous, Parquet or duckdb.
You mean the termux- commands?
https://wiki.termux.com/wiki/Termux:API
For a tui, there are probably going to be a large number of (possibly reconfigurable) keyboard shortcuts and maybe some sort of command system. How you let the user know about all of them without having to memorize a giant table can be difficult.
That makes sense. In my case I’m looking to play around with the reticulum network / nomandnet so in that case the user would already be knee deep in the tui, so these issues could hopefully be avoided
It’s a game I found in the reticulum network. I can try and find the specific reticulum address later if you’re interested
What is that first screenshot? With the planet game.
Generally, yes, adapting to the size of the window is pretty easy. Most of those libraries have a layout engine, so you define the size of things relative to the size of the window and each other, then the layout engine takes care of the rest.
As for discoverability, well, it’s a hard issue in all UI schemes, and tends to be particularly difficult in CLI/TUI applications due to layout and input constraints. In a GUI application users can click on buttons, scroll, and generally figure things out. For a tui, there are probably going to be a large number of (possibly reconfigurable) keyboard shortcuts and maybe some sort of command system. How you let the user know about all of them without having to memorize a giant table can be difficult. The common options I’ve seen are a “?” popup (lazygit), a context-aware small popup during multi-key commands (helix), a command palette with search (lots), a top menu bar with accelerator keys (old school WordPerfect), or a bottom bar with context available options (lots). They all have their respective tradeoffs, and can make something go from “useable after hours of practice and reading” to “oh, this is intuitive!”.
Yes. htop does it, for example.
Dealing with all the interaction options
Yeah. Is it even possible to have adapt if a user changes the size of their window? Window resizing often seems to break these graphics
Making it all discoverable for your users
Why do you consider this an issue specifically?
Most languages have a fancy TUI library nowadays that makes it pretty easy. Here are a few:
The difficult parts are generally:
Thanks!
Try https://charm.land/, it's in the Go language.
Thank you
I have only the most basic experience digging into that stuff -- from quite a while ago -- but the keywords I think you need to search for to find out more info about this are: escape codes, TUI (i.e. Text User Interface), and curses.
The last is an old library for implementing TUIs. There's successors like ncurses as well. I don't know what people actually use currently though.
Solved it! I was just missing these four lines in the call macro, just above the Push RETVAL section:
A = TEMP_ADDR
D = *A
A = SP
*A = D
Doesnt seem so:

But -f works:

You can git add even if the file is 'listed' in the .gitignore though? Maybe use -f IIRC
.gitignore is good for stuff that will always be there, but is less good for small one-off files and other detritus.
But if your happy maintaining .gitignore correctly, git add . before commit and youll never miss a file again. You may accidentally commit a secrets file, but thats a different problem for a different day.
I just do git status before and after commits
Add a prepush hook that checks if git status is clean (or some other gir command that lists uncommitted files). If it is, either fail straight away of make the hook interactive and ask whether it's ok or something.
Maybe https://pre-commit.com/ has something already.
Then I add those to .gitignore, so I won't forget the files I need to commit, so I don't have to dive through AI slop articles about git to resolve merge conflicts (often things that should have been automatically resolved, except someone didn't have basic common sense).
The problem is that uncommited files in the repo isnt unusual, often people have test files or logs, that you dont want to commit.
I personally use git gui, which will show all the files that arent committed, so that may be a solution for you.
AFAIK it's mostly similar to Linux. But maybe you're looking for this?
I found my own solution: -eq seems to only be intended for numerals. The problem is easily fixed by using == instead. I found this out when I changed the if statement from [[ to [ and got a more precise bash error
Depends on what direction you would like to take your skills in, so knowing your interest would be helpful, (frontend, backend, networking, etc.)
My personal projects are generally motivated by lazyness, but in the beginning they would take up more time than doing the process manually; however, this tradeoff were justified by the learning experience, of course.
I would focus on automating repetitive or cloud dependent tasks such as file conversion, organization, or augmentation. This will give you an opportunity to learn more about different libraries, Python syntax, and working with paths agnostically.
Alternatively, you could dive into networking, but this will require knowledge/learning about the OSI model, network architecture, and packet captures.
If you don't know how to resolve conflicts, you should not be using --force or rebase. It can mess your code even more than conflicts.
As for resolving conflicts, it's pretty straightforward, you have markers in your code for your local changes vs pulled code, just fix it up ro what you think thr code should be. Make sure you resolve all conflicts then stage and commit the changes.