cleaned up whitespace
This commit is contained in:
parent
9f3309df1e
commit
034983be0b
@ -22,4 +22,3 @@
|
||||
recurse = true
|
||||
[diff]
|
||||
submodule = log
|
||||
|
||||
|
@ -140,7 +140,7 @@ primary fork name, should be temporary and local., not pushed to the
|
||||
project repository, But when you are modifying the submodules in a
|
||||
project as a single project, making related changes in the module and
|
||||
submodule, the shared names that are common to all developers belong in
|
||||
the primary project module,and when you have done with a submodule,
|
||||
the primary project module,and when you have done with a submodule,
|
||||
|
||||
```bash
|
||||
git switch --detach
|
||||
@ -202,7 +202,7 @@ various commits you made while working on it temporary and local names
|
||||
with `switch -c yet-another-idea`
|
||||
|
||||
All of which, of course, presupposes you have already set unit tests,
|
||||
upstream, origin, and your tracking branch appropriately.
|
||||
upstream, origin, and your tracking branch appropriately.
|
||||
|
||||
Even if your local modifications are nameless in your local submodule
|
||||
repository, on your remote submodule repository they need to have a name
|
||||
@ -213,7 +213,7 @@ names and commits
|
||||
in your superproject that contains this submodules point to.
|
||||
|
||||
You want `.gitmodules` in your local image of the repository to
|
||||
reflect the location and fork of your new remote repository, with
|
||||
reflect the location and fork of your new remote repository, with
|
||||
your remote as its `origin` and their remote as its `upstream`.
|
||||
|
||||
You need an enormous pile of source code, the work of many people over
|
||||
@ -526,7 +526,7 @@ such cases.
|
||||
|
||||
## Choco
|
||||
|
||||
Choco, Chocolatey, is the Windows Package manager system. Does not use `*.msi` as its packaging system. A chocolatey package consists of an `*.nuget`, `chocolateyInstall.ps1`, `chocolateyUninstall.ps1`, and `chocolateyBeforeModify.ps1` (the latter script is run before upgrade or uninstall, and is to reverse stuff done by is accompanying
|
||||
Choco, Chocolatey, is the Windows Package manager system. Does not use `*.msi` as its packaging system. A chocolatey package consists of an `*.nuget`, `chocolateyInstall.ps1`, `chocolateyUninstall.ps1`, and `chocolateyBeforeModify.ps1` (the latter script is run before upgrade or uninstall, and is to reverse stuff done by is accompanying
|
||||
`chocolateyInstall.ps1 `)
|
||||
|
||||
Interaction with stuff installed by `*.msi` is apt to be bad.
|
||||
|
@ -109,7 +109,7 @@ mangle together
|
||||
then ends gracefully, and the next stream and the next
|
||||
concurrent process starts when there is something to do. While a stream lives, both ends maintain state, albeit in a
|
||||
request reply, the state lives only briefly.
|
||||
1. A message.
|
||||
1. A message.
|
||||
|
||||
Representing all this as a single kind of port, and packets going
|
||||
between ports of a single kind, inherently leads to the mess that we
|
||||
|
@ -10,11 +10,11 @@ git remote set-url origin git@cpal.pw:~/libsodium.git
|
||||
git remote set-url upstream https://github.com/jedisct1/libsodium.git
|
||||
cd ..
|
||||
cd mpir
|
||||
git remote set-url origin git@cpal.pw:~/mpir.git
|
||||
git remote set-url origin git@cpal.pw:~/mpir.git
|
||||
git remote set-url upstream https://github.com/BrianGladman/mpir.git
|
||||
cd ..
|
||||
cd wxWidgets
|
||||
git remote set-url origin git@cpal.pw:~/wxWidgets.git
|
||||
git remote set-url origin git@cpal.pw:~/wxWidgets.git
|
||||
git remote set-url upstream https://github.com/wxWidgets/wxWidgets.git
|
||||
cd ..
|
||||
cd wxWidgets/3rdparty/catch
|
||||
|
@ -269,10 +269,24 @@ For this to work, the underlying structure needs to be something based on
|
||||
the same principles as Git and git repositories, except that Git relies on
|
||||
SSL and the Certificate Authority system to locate a repository, which
|
||||
dangerous centralization would fail under the inevitable attack. It needs to
|
||||
have instead for its repository name system a distributed name system, but
|
||||
a Kamelia distributed hash table will come under hostile attack.
|
||||
have instead for its repository name system a distributed hash table name
|
||||
system, but a Kamelia distributed hash table will come under hostil
|
||||
attack.
|
||||
|
||||
So rather than a system relying on nearest neighbour by hash distance, nearest neighbour by social distance.
|
||||
So rather than a system relying on nearest neighbour by hash distance,
|
||||
nearest neighbour by social distance.
|
||||
|
||||
Social distance is costly and complex to calculate. If there are more than
|
||||
thirty or a hundred entities, need to use dimensional reduction. But we do
|
||||
not need to do it very often.
|
||||
|
||||
Social distance, if calculated in a shill and Sybil resistant way, lacks the
|
||||
nice mathematical properties of the Kamelia distance metric, so does not
|
||||
necessarily guarantee you will find what you are looking for. Or if it does, going to be a lot more complicated to prove. But it seems likely that most
|
||||
of the time, it will perform well, because most of the time you will be
|
||||
looking for someone close. We will have to find out by experiment.
|
||||
|
||||
The reason that Kamelia network cannot work in the face of enemy action, is that the shills who want to prevent something from being found create a hundred entries with a hash close to their target by Kamelia distance, and then when your search brings you close to target, it brings you to a shill, who misdirects you. Using social network distance resists this attack.
|
||||
|
||||
The messages of the people you are following are likely to be in a
|
||||
relatively small number of repositories, even if the total number of
|
||||
|
@ -23,13 +23,13 @@ namespace ro {
|
||||
assert(index[pu] == 0);
|
||||
index[pu] = *q++;
|
||||
}
|
||||
assert(*(p - 1) == '\0' && *q == '\0');
|
||||
assert(*(p - 1) == '\0' && *q == '\0');
|
||||
/* when an instance of this class is declared constexpr,
|
||||
an assert does not trigger a run time error,
|
||||
because expression evaluated at compile time.
|
||||
Instead the compiler reports that the expression
|
||||
did not evaluate to a constant,
|
||||
|
||||
|
||||
The error is confusing, because the error points to
|
||||
the declaration where the initialization was invoked,
|
||||
instead of pointing to the assert.
|
||||
|
16
slash6.cpp
16
slash6.cpp
@ -30,10 +30,10 @@ static constexpr uint8_t index2base64[]{
|
||||
// But on reflection, useless, since human typed stuff like this should use Bitcoin's base 58 encoding
|
||||
// So going to switch to regular base64, despite the unreasonably immense amount of work I put into it.
|
||||
|
||||
// Unfortunately, Wireguard, with which I am going to need to interoperate, uses RFC4648, whose
|
||||
// algorithm is fundamentally different - no special treatment for I, O, o, and l, and uses =
|
||||
// Unfortunately, Wireguard, with which I am going to need to interoperate, uses RFC4648, whose
|
||||
// algorithm is fundamentally different - no special treatment for I, O, o, and l, and uses =
|
||||
// to handle the case where you have boundary problems between eight and six bit groups.
|
||||
// They force everything to four character groups, using an = sign to indicate that the
|
||||
// They force everything to four character groups, using an = sign to indicate that the
|
||||
// bytes being represented stop before a multiple of three. https://www.base64encode.org
|
||||
|
||||
|
||||
@ -57,11 +57,11 @@ static_assert(index2base64[63] == '_', "surprise numeral at 63");
|
||||
|
||||
// Compile time execution is C++ is a pain, because expressions are apt to unpredictably lose
|
||||
// their constexpr character for reasons that are far from clear.
|
||||
//
|
||||
//
|
||||
// You can declare anything reasonable to be constexpr, and the compiler will not issue an
|
||||
// error message until the code that attempts to use what you have declared constexpr is
|
||||
// error message until the code that attempts to use what you have declared constexpr is
|
||||
// invoked from somewhere else "expression does not evaluate to constant"
|
||||
//
|
||||
//
|
||||
// an assert in an expression evaluated at compile time does not trigger a run time error,
|
||||
// Instead the compiler reports that the expression did not evaluate to a constant,
|
||||
//
|
||||
@ -96,8 +96,8 @@ public:
|
||||
|
||||
static constexpr charindex ascii2six_ar(index2base64);
|
||||
|
||||
//
|
||||
//
|
||||
//
|
||||
//
|
||||
// You really have to write compile time code in templates as a language, which is the totally
|
||||
// obscure and hard to use language apt to generate remarkably voluminous error messages
|
||||
// will little obvious connection to the actual problem, and surprising result that are ver
|
||||
|
Loading…
Reference in New Issue
Block a user