(C) 2024 Swudu Susuwu, dual licenses: choose GPLv2 or Creative Commons Attribution 2 (allows all uses).
./.ssh/ is to use signatures / certificates.
./posts/ stages posts (virtual schools) for https://SwuduSusuwu.SubStack.com/ (which includes https://GitHub.com/SwuduSusuwu/SusuLib/tree/preview/posts/ plus posts which are not about artificial neural tissue, antiviruses, assistants, or autonomous tools).
- https://github.com/SwuduSusuwu/SusuPosts.git is a work-in-progress which is supposed to mirror all posts, and starts with the oldest posts, so for now this does not include new posts (which https://github.com/SwuduSusuwu/SusuLib/tree/preview/posts/ has).
- Switch to the
previewbranch for newest posts.
./hooks/ is git scripts (man githooks) which assist you; install with cp -ra ./hooks/* ./.git/hooks/.
./hooks/pre-commitis custompre-commit.git/hooks/pre-commit.sample(scans for non-ASCII filenames, conflict markers or whitespace errors)
This repo is new. So that fixes do not require use of git push --force on the trunk branch (or tons of trivial fixes which bloat git log), new posts go to the preview branch for review (which can last months).
- For now, just the
previewbranch has posts.
Download with git clone https://github.com/SwuduSusuwu/SusuPosts.git and browse local with cd mid/ && ls.
- To opt-in to the beta (the preview), use
git switch preview(opt-out withget switch trunk).
./.ssh/setup.sh is to setup gpg.ssh.allowedSignersFile (allows to use git verify <ref> or git log --show-signature).
git verify <ref>orgit log —show-signaturesshall match./.ssh/sha256.sigfor new commits- You can compare those certificates to our blog post.)
[Notice: This public crypto "signature", is not related to "signature analysis" (Substr scans).]
View documented issues (for ideas on how to contribute, plus so you do not report documented issues.)
- Use
git switch preview- Preview samples / scripts symptoms of new issues (hint: listen to samples for glitches, or look through script outputs for "Warning:"s or "Error:"s).
- If you found new issue(s) (which aren't due to misconfigurations in your system), comment on the pull request or post new issue(s).
- Notice: sensitive issue(s) have a separate protocol.
General comment/message syntax rules: <> goes around type of option/argument (such as <commit-hash>, [] goes around optional comments/options/arguments (such as [<optional fallback value>], ... is affixed to allow multiple options/arguments (such as [; optional extra arguments]...). This rule is used to document function arguments (such as sh, C or C++ use), plus to document git uses.
To ensure consistent code, submissions of code (such as through pull requests) have language-specific syntax rules:
*.md shall use:
- GitHub flavored Markdown, which is not just compatible with GitHub but also:
- Has lots of unit tests. Most of the differences from the original Markdown are just so rules are less ambiguous.
- Is close to the original Markdown (thus compatible with most Markdown tools, such as
glow).
- ISO 8601, which
- Is the most popular national standard format.
- Versus formats which use locale-dependent names of months, is more portable and less ambiguous.
- Versus formats which use backslashes, is more portable (filesystem paths can include).
- Unix paths start with
./(if relative) or/(if absolute), so thatsed(andgrep) performance is improved.- That is, paths shall match the Regular Expression
^\.*\/[\w]*(more than 1.is allowed). - Microsoft Windows can use Unix paths, except that absolute paths must start with the drive prefix (
[A-Z]:/versus/). - HTTP can use Unix paths, except that absolute paths must start with the protocol (
http[s]*://versus/).
- That is, paths shall match the Regular Expression
If git commit introduces/removes functions, have ./README.md#purposes include this.
Do atomic commits: if swapping the new commit with a previous commit (such as through git rebase -i) -- or if git revert of a previous commit -- causes ./build.sh to return a non-0 exit status, git commit's message shall include such as:
Is followup to: <ref | commit-hash> (<commit-message>)[, comment] [; <ref | commit-hash> (<commit-message>)[, comment]]...
- This shows the temporal order of commits required for
./build.shto pass. <commit-message>is so thatgit rebase(which changes<commit-hash>) does not make it impossible to follow (plus, so comments are reduced), thus you should use the exact message. You can use ellipsis (...) to omit extra lines, but it is best if the first line is exact (left as-is).- This format allows comments to include
<commit-hash>'s and,'s (just not;'s).
git commit message format/syntax:
- affix "()" onto functions (regardless of number of arguments), such as
function(), or use the function name (such asfunction) alone. - if commit does
git add NewFile: message has+\NewFile``. - if
git rm Exists:-\Exists``. - if
touch Exists && git add Exists:@\Exists`or?`Exists``.- Simple wildcards/regex for altered functions:
\%s/oldFunction()/newFunction()/``. - '' is not used as update prefix, since '' has much other use in Regex (wildcards) & C++ (such as block comments, dereferences, or math).
- From the root commit through 159940fb8b60b176a38a13cdfbd9393596daa9b5 (Date: Thu Jul 4 07:56:01 2024 -0700), '@' was the prefix for updates. From then until this commit, '?' was the prefix for updates.
- From this commit on (this is the successor to commit 0ae6233c02d9e04fca60027b1e32b885eb69bb8a (Date: Sat Nov 30 17:50:40 2024 -0800)), '@' is (once more) the prefix for updates, due to: it is more common for projects to so use '@'.
- Simple wildcards/regex for altered functions:
- if
echo "int newFunction() {...}" >> Exists && git add Exists:@\Exists`:+`NewFunction()``. - if
git mv OldPath/ NewPath/:\OldPath/` -> `NewPath/`ormv OldPath/ NewPath/`. - as default branch, choose
master,mainortrunk(do not have more than 1 of those branches, or./Macros.sh:SUSUWU_DEFAULT_BRANCH()is ambiguous). - to indent: use tabs to form blocks, such as:
?`README.md`:
?`#How-to-use-this`:
Split into:
+`## Download`: new; howto clone, howto switch branches.
+`## Optionssetup`: "Options/setup"; howto use `./build.sh` (with or without options.)
?`#How-to-contribute`,
?[Good first issues to contribute to]: (moved into `#How-to-contribute`)
/[Notice: Commit titles can omit backticks (``) if not enough room; the backticks just allow GitHub to do Markdown-format code/paths.]
To sponsor this (which allows us to produce more source codes), you can use crypto (such as Bitcoin) to produce a one-time-use address (which you deposit funds into), and send the address&private-key to a contact which ./SECURITY.md lists.
- Rather than us publish a send-to address (for a particular protocol), this allows us to accept all forms of crypto.
- If amount is more than $100 and you don't trust the contact platforms, use
./.ssh/id_ed25519.pubto secure those.
If you want proof that your crypto/cash will go to produce specific systems, use escrow services (what you send the escrow is: crypto/cash, plus contract which references an open issue which you choose).
- If none of those issues match what you want, you can post your own issue for this.
- Ensure that the escrow contract includes specifics as to what will count as "issue closed" to the escrow service (so you do not have to trust the author), which will release the crypto/cash (once the escrow service considers your issue as closed).
- For example; "The source code (through
./build.sh), must produce a system (a shared object or executable) which uses just half of the training data to setup its neural network, which must produce virtual synapses which the system uses to produce accurate results on the other half, where accurate (for classifiers) is less than 2% false negatives and less than 2% false positives, and accurate (for generators) is divergence of less than 2%." is a contract which an escrow can use for issue #6.
- For example; "The source code (through
You can use Capital 1's affiliate program to allow us to publish more for you.