cheng/wallet
0
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/master' into docs

Browse Source
This commit is contained in:
reaction.la 2022-07-03 15:20:12 +10:00
commit 7d8ebed948
No known key found for this signature in database
GPG Key ID: 99914792148C8388
43 changed files with 289 additions and 180 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
.gitattributes vendored
View File

@ -40,37 +40,22 @@ Makefile text eol=lf encoding=utf-8
# Force binary files to be binary
###############################################################################
# Set default behavior for command prompt diff.
#
# This is need for earlier builds of msysgit that does not have it on by
# default for csharp files.
# Note: This is only used by command line
###############################################################################
#*.cs diff=csharp
*.webp binary
*.gif binary
*.jpg binary
*.png binary
*.pdf binary
*.doc binary
*.DOC binary
*.docx binary
*.DOCX binary
*.dot binary
*.DOT binary
*.PDF binary
*.rtf binary
*.RTF binary
###############################################################################
# Set the merge driver for project and solution files
#
# Merging from the command prompt will add diff markers to the files if there
# are conflicts (Merging from VS is not affected by the settings below, in VS
# the diff markers are never inserted). Diff markers may cause the following
# file extensions to fail to load in VS. An alternative would be to treat
# these files as binary and thus will always conflict and require user
# intervention with every merge. To do so, just uncomment the entries below
###############################################################################
#*.sln merge=binary
#*.csproj merge=binary
#*.vbproj merge=binary
#*.vcxproj merge=binary
#*.vcproj merge=binary
#*.dbproj merge=binary
#*.fsproj merge=binary
#*.lsproj merge=binary
#*.wixproj merge=binary
#*.modelproj merge=binary
#*.sqlproj merge=binary
#*.wwaproj merge=binary
###############################################################################
# diff behavior for common document formats
#

1
.gitconfig
View File

@ -19,6 +19,5 @@
verify-signatures = true
[submodule]
active = *
recurse = true
[diff]
submodule = log

BIN
Icon.ico
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 44 KiB

193
docs/libraries.md
View File

@ -95,34 +95,77 @@ Libraries are best dealt with as [Git submodules].
[build libraries]:https://git-scm.com/book/en/v2/Git-Tools-Submodules
Git submodules leak complexity and surprising and inconvenient behaviour
all over the place if one is trying to make a change that affects multiple
modules simultaneously. But having your libraries separate from your git
repository results in non portable surprises and complexity. Makes it hard
for anyone else to build your project, because they will have to, by hand,
tell your project where the libraries are on their system.
Git submodules leak complexity and surprising and inconvenient
behaviour all over the place if one is trying to make a change that affects
multiple modules simultaneously. But having your libraries separate from
your git repository results in non portable surprises and complexity. Makes
it hard for anyone else to build your project, because they will have to, by
hand, tell your project where the libraries are on their system.
When one is developing code, you normally have a git branch. But
the git commit of the master project in which the submodule is
contained does not notice its subproject has changed, unless the
subproject head has changed. And the subject project head will not
change if it points to a name, rather than to a particular commit. For
ones changes to a submodule to be reflected in the master project in
any consistent or predictable way, the submodule has to be in
detached head mode, with the head pointing directly to a commit,
rather than pointing to a branch that points to a commit.
When one is developing code, you normally have a git branch. But the git
commit of the master project in which the submodule is contained does
not notice its subproject has changed, unless the subproject head has
changed. And the subject project head will not change if it points to a
name, rather than to a particular commit. For ones changes to a submodule
to be reflected in the master project in any consistent or predictable way,
the submodule has to be in detached head mode, with the head pointing
directly to a commit, rather than pointing to a branch that points to a
commit.
Git commands in master project do not look inside the subproject.
They just look at the subproject's head.
You will import a submodule from someone else's project, but eventually you and your team are going to make minor changes to it to customize it to your project. In which case you will need your own remote team repo, in place of the original other team's repo.
This means that signing off on changes to a submodule is
irrelevant. One signs off on the master project, which includes the
hash of that submodule commit.
Construct the copied remote repositories so that their default branch is your tracking branch, not the upstream branch.
When one is changing submodules for the use of a particular
project, making related changes in the master project and
submodules, one should not track the changes by creating and
updating branch names in the submodule, but by creating and
``` bash
git init --bare -b «our_branch»
```
Then, in your local repository where you created the new branch, reset
the remote in your local repository to the new remote by editing `.gitconfig`
and push «our_branch» from your local in which you created your team's new
submodule branch to the remote.
or
``` bash
git clone --bare «their_remote» -b«their_stable_branch_or_release_tag»
cd «our_new_remote»
git symbolic-ref HEAD refs/heads/«our_new_branch»
```
If you fail to set your remote to your team's default branch, then your
local repositories will keep getting reset back to their team's branch, and
chaos ensues.
When moving the remote of a submodule in your local repository (usually from their team's remote to your team's remote) you update `.gitmodules` in your superproject, and in each submodule that has submodules of its own, then
```bash
git submodule update --init --recursive --force
git submodule foreach --recursive 'git status && git switch «our_branch» && git status && git remote -v && git switch --detach'
```
Your submodule remotes propagate from `.gitmodules` file of your superproject, and their branch propagates from the superproject *and* from the remote default branch.
And the branch will *also* propagate from `.gitmodules` if `branch = ...` is set.
Because git is a distributed archive, it is perfectly possible, and often
necessary, to work with all these set to different values, *provided* that
everyone is mindful that they are set to different values, and the
consequences and implications of them being set to different values. Which
consequences and implications get complicated, unobvious, difficult to
predict, and surprising when you are working with submodules.
Git commands in master project do not look inside the subproject. They
just look at the subprojects head.
This means that signing off on changes to a submodule is irrelevant. One
signs off on the master project, which includes the hash of that submodule
commit.
When one is changing submodules for the use of a particular project,
making related changes in the master project and submodules, one should
not track the changes by creating and updating branch names in the
submodule, but by creating and
updating branch names in the containing module, so that the
commits in the submodule have no name in the submodule, the
submodule is always in detached head state, albeit the head may be
@ -146,37 +189,25 @@ the primary project module,and when you have done with a submodule,
git switch --detach
```
Within the submodule, commits are nameless with detached head, except
when you are working on them, the name in primary module naming a
group of related commits in several submodules, which commits do not
usually receive independent names of their own, even though the commits
have to be made within the submodule, not in the containing module
which names the complete set of interrelated commits.
From the point of view of the containing superproject, submodule
commits are nameless with detached head, except when you are working
on them, the name in primary module naming a group of related commits
in several submodules, which commits do not receive independent names
of their own, even though the commits have to be made within the
submodule, not in the containing module which names the complete set of
interrelated commits.
The submodule commits may well belong to different branches and tags in
the superproject, but in the submodules, they are nameless in that all the
submodule commits wind up attached to the same branch, your submodule tracking
branch.
the superproject, but the submodules know nothing of superproject
names, and the superproject knows nothing of submodules names.
In this case, working on submodules as part of a single larger project, you should set
```bash
git config --local submodule.recurse true
```
In the primary project, so that you conveniently push and pull a
group of related changes as one thing, and the build for the whole
project should treat the submodule libraries as having a
dependency on module/.git/modules/submodule/HEAD, rather than
checking every single file in the submodules every time to see
if one has changed, for there could be an enormous number of
them. The primary build should invoke the submodule build, which
*will* check each file in the submodule for changes, only when the
submodule detached head has changed. And therefore, you want it
to change, you want the submodule head to be nameless and
detached, whenever you modify a submodule as part of a larger
project where you test your changes by rebuilding the whole
project to make sure all your related changes fit together.
The primary build should invoke the submodule build, which *will* check
each file in the submodule for changes, only when the submodule
detached head has changed. And therefore, you want it to change, you
want the submodule head to be nameless and detached, whenever you
modify a submodule as part of a larger project where you test your
changes by rebuilding the whole project to make sure all your related
changes fit together.
When tracking an upstream submodule that has submodules of its
own, which have their own upstreams
@ -189,17 +220,33 @@ git pull upstream --recurse-submodules=on-demand «their-latest-release»
Make sure things still work. Get everything working. (You do have unit test, right?)
When you are working a submodule, your branch has to have a name, or
when you push it and pull it, strange things will happen. But the
superproject pushes and pulls by commit, not by name, so when you are
done,
then:
git submodule foreach --recursive 'git push`
```bash
git submodule foreach --recursive 'git switch --detach'
git submodule foreach --recursive 'git push origin HEAD:«your-tracking-branch»'
git submodule foreach --recursive 'git push`
```
As its own thing, a submodule has branches with names. As a component
of a superproject, it has nameless commits.
If you are in a submodule directory of the superproject, and you push and
pull, what you are pushing and pulling had better have a name, or else
unpleasant surprises will happen. If you are in the superproject directory
and pushing and pulling the whole thing, that commit better be detached.
You pull a named release of the project that is a submodule of your project
from `upstream`, diddling with it to make it work with your project, then
you push it to `origin` as a nameless commit, though you probably gave the
various commits you made while working on it temporary and local names
with `switch -c yet-another-idea`
you push it to `origin` under its own name, the you detach it from its name,
so the superproject will know that the submodule has been changed.
All of which, of course, presupposes you have already set unit tests,
upstream, origin, and your tracking branch appropriately.
@ -209,8 +256,7 @@ repository, on your remote submodule repository they need to have a name
to be pushed to, hence you need to have a tracking branch in each of your
remote images of each of your submodules, and that tracking branch will
need to point to the root of a tree of all the nameless commits that the
names and commits
in your superproject that contains this submodules point to.
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
@ -225,10 +271,33 @@ you rely someone else's compiled code, things break and you get
accidental and deliberate backdoors, which is a big concern when you are
doing money and cryptography.
GitSubmodules is hierarchical, but source code has strange loops. The Bob
module uses the Alice module and the Carol module, but Alice uses Bob
and Carol, and Carol uses Alice and Bob. How do you make sure that all
your modules are using the same commit of Alice?
When your submodules are simply your copy of someone else code, it gets
little bit messy. When you change them, it gets messier.
And visual studio's handling of submodules is just broken and buggy. A
command that works in git-bash will produce unexpected surprising, and
unpleasant results in visual studio's git. I really need to give up on
visual studio, it is closed source code, and turning bad.
When one developer makes minor changes in submodule to make it work
with the whole project on which several developers are working on, no
end of mysterious grief ensues, because strange and curiously difficult to
identify differences appear between builds that Git would normally ensure
are the same build. Submodules are a halfway house between completely
absorbing the other party's code into your code, and using it as a prebuilt
library. Instead, we have walls dividing the project into pieces, which is a
lot less grief than on big pile of code, but managing those walls winds up
taking a lot of time, and mistakes get made because a git commit in a
project with submodules that have changed does not mean quite the same
thing, nor have quite the same behaviour, as git commit in a project with
unchanging submodules. But then truly integrating a project that is the
product of a great deal of time by a great many of people, and managing it
thereafter, is likely to take up a great deal more time.
Git Submodules is hierarchical, but source code has strange loops. The
Bob module uses the Alice module and the Carol module, but Alice uses
Bob and Carol, and Carol uses Alice and Bob. How do you make sure that
all your modules are using the same commit of Alice?
Well, if modules have strange loops you make one of them the master, and
the rest of them direct submodules of that master, brother subs to each

0
rho.ico → docs/rho.ico
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 111 KiB

After

Width:  |  Height:  |  Size: 111 KiB

137
docs/social_networking.md
View File

@ -266,23 +266,83 @@ approved links and reply-to links – but not every spammer, scammer, and
shill in the world can fill your feed with garbage.
## Algorithm and data structure.
So rather than a distributed hash table structured by hash distance,
nearest neighbour by social distance.
-## Algorithm and data structure.
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 hash table name
system, but a Kademlia distributed hash table will come under hostile
attack.
have instead for its repository name system a distributed hash
table within which local repositories find the network addresses of remote
repositories on the basis of the public key of a Zooko identity of a person
who pushed a tag or a branch to that repository, a branch being a thread,
and the branch head in this case being the most recent response to a thread
by a person you are following.
So the hashes of identities are tracked by the distributed hash table, but the
hashes of posts are not, because that would result in excessive numbers of
lookups in a table that would very quickly hit its scaling limits. The hashes
of posts are tracked by the repository of the feed that you are looking at, so
require only local lookup, which is faster and less costly than a distributed
lookup. This is equivalent to a fully distributed hash table where the key is
not hash of post, but global name of area of interest, zooko nickname,
zooko public key followed by his human readable thread name (branch
name or tag name in git terminology) followed by hash of post, so that
items that are likely to be looked up together are likely to be located
physically close together on the same disk and will be sent along the same
network connection.
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
repositories out there is enormous and the number of hashes in each
repository is enormous, so this algorithm and data structure will scale, and
the responses to that thread that they have approved, by people you are not
following, will be commits in that repository, that, by pushing their latest
response to that thread to a public repository, they did the equivalent of a
git commit and push to that repository.
Each repository contains all the material the poster has approved, resulting
in considerable duplication, but not enormous duplication.
The underlying protocol and mechanism is that when you are following
Bob, you get a Bob feed from a machine controlled by Bob, or controlled
by someone that Bob has chosen to act on his behalf, and that when Bob
replies to someone, the post that he replies to is copied onto his machine,
containing a link to a feed controlled by the person he replies to, and
similarly with replies that he approves. So posts and links to feeds spread
around the net Usenet style, being duplicated on every machine that
comments on them or approves them and every machine that follows a
feed that contains them. You access a feed BitTorrent style, sharing Bob’s
feed with everyone that follows Bob. Each feed is a mutable torrent, a
Merkle-patricia tree with a single authority determining the current total
state of that tree, with the continually changing root of Bob’s Merkle-patricia
tree signed by Bob using his secret key which is kept in a BIP39
style wallet.
When Dave replies to a text in Carol's feed, the Carol text and the reply by
default goes into his feed, and if it does there will be metadata in his feed
about his social network connection to Carol, which, if Bob is following
Dave's feed, can be used by Bob's client to navigate the distribute hash
table to Carol's feed.
And if Carol approves Dave's reply, or is following Dave or has buddied
Dave, and Bob is following Carol, but not following Dave, then there will
be in metadata in Carol's feed that can be used by Bob's client to navigate
the distribute hash table to Carol's feed.
The metadata in the feed sharing reveals what network addresses are
following a feed, but the keys are derived from user identity keys by a one
way hash, so are not easily linked to who is posting in the feed.
So rather than a distributed hash table structured by hash distance,
nearest neighbour by social distance.
### Replacing Kademlia
[social distance metric]:recognizing_categories_and_instances.html#Kademlia
{target="_blank"}
I will describe the Kademlia distributed hash table algorithm not in the
way that it is normally described and defined, but in such a way that we
can easily replace its metric by [social distance metric], assuming that we
@ -329,37 +389,10 @@ git commit and push to that repository.
Each repository contains all the material the poster has approved, resulting
in considerable duplication, but not enormous duplication.
The underlying protocol and mechanism is that when you are following
Bob, you get a Bob feed from a machine controlled by Bob, or controlled
by someone that Bob has chosen to act on his behalf, and that when Bob
replies to someone, the post that he replies to is copied onto his machine,
containing a link to a feed controlled by the person he replies to, and
similarly with replies that he approves. So posts and links to feeds spread
around the net Usenet style, being duplicated on every machine that
comments on them or approves them and every machine that follows a
feed that contains them. You access a feed BitTorrent style, sharing Bob’s
feed with everyone that follows Bob. Each feed is a mutable torrent, a
Merkle-patricia tree with a single authority determining the current total
state of that tree, with the continually changing root of Bob’s Merkle-patricia
tree signed by Bob using his secret key which is kept in a BIP39
style wallet.
When Dave replies to a text in Carol's feed, the Carol text and the reply by
default goes into his feed, and if it does there will be metadata in his feed
about his social network connection to Carol, which, if Bob is following
Dave's feed, can be used by Bob's client to navigate the distribute hash
table to Carol's feed.
approved links and reply-to links – but not every spammer, scammer, and
shill in the world can fill your feed with garbage.
And if Carol approves Dave's reply, or is following Dave or has buddied
Dave, and Bob is following Carol, but not following Dave, then there will
be in metadata in Carol's feed that can be used by Bob's client to navigate
the distribute hash table to Carol's feed.
The metadata in the feed sharing reveals what network addresses are
following a feed, but the keys are derived from user identity keys by a one
way hash, so are not easily linked to who is posting in the feed.
This handles public posts.
### Kademlia in social space
@ -380,7 +413,8 @@ Each party indicates what entities he can provide a direct link to by
publishing the sum of the vectors of the parties he can link to - and also
the sum of the their sums, and also the sum of their ... to as many deep as
turns out to be needed in practice, which is likely to two or three such
vector sums, maybe four or five. What is needed will depend on the pattern of tracking that people engage in in practice.
vector sums, maybe four or five. What is needed will depend on the
pattern of tracking that people engage in in practice.
If everyone behind a firewall or with an unstable network address arranges
to notify a well known peer with stable network address whenever his
@ -433,7 +467,8 @@ tracking information of large number of other such computers, and a large
number of smaller, less well connected devices, that track their friends and
acquaintances, and also track well connected devices. Big fanout on on the
interior vertices, smaller fanout on the exterior vertices, stable identities
on all devices, moderately stable network addresses on the interior vertices, possibly unstable network addresses on the exterior vertices.
on all devices, moderately stable network addresses on the interior vertices,
possibly unstable network addresses on the exterior vertices.
If we have a thousand identities that are making public the information
needed to make connection to them, and everyone tracks all the peers that
@ -449,11 +484,22 @@ party lookup services, whereupon we need the first two sums.
In that case random peer searching for connection information to another
random peer first looks to through those for which has good connection
information, does not find the target. Then looks through for someone connected to the target, may not find him, then looks for someone connected to someone connected to the target and, assuming that most genuine peers providing tracking information are tracking most other peers providing genuine tracking information, and the peer doing the search has the information for a fair number of peers providing genuine tracking information, will find him.
information, does not find the target. Then looks through for someone
connected to the target, may not find him, then looks for someone
connected to someone connected to the target and, assuming that most
genuine peers providing tracking information are tracking most other
peers providing genuine tracking information, and the peer doing the
search has the information for a fair number of peers providing genuine
tracking information, will find him.
Suppose there are a billion peers for which tracking information exists. In that case, we need the first fifty dimensions, and possibly one more level of indirection in the lookup (the sum of the sum of the sum of vectors being tracked). Suppose a trillion peers, then about the first sixty dimensions, and possibly one more level of indirection in the lookup.
Suppose there are a billion peers for which tracking information exists. In
that case, we need the first seventy or so dimensions, and possibly one
more level of indirection in the lookup (the sum of the sum of the sum of
vectors being tracked). Suppose a trillion peers, then about the first eighty
dimensions, and possibly one more level of indirection in the lookup.
That is a quite large amount of data, but if who is tracking whom is stable, even if the network addresses are unstable, updates are infrequent and small.
That is a quite large amount of data, but if who is tracking whom is stable,
even if the network addresses are unstable, updates are infrequent and small.
If everyone tracks ten thousand identities, and we have a billion identities
whose network address is being made public, and million always up peers
@ -463,9 +509,16 @@ track large numbers of unstable addresses, then we need about fifty
dimensions and two sum vectors for each entity being tracked, about a
million integers, total -- too big to be downloaded in full every time, but
not a problem if downloaded in small updates, or downloaded in full
infrequently. The data can be substantially compressed by a compression algorithm that takes advantage of the fact that the values of a vector have a normal distribution around zero.
infrequently.
But suppose no one specializes in tracking unstable network addresses. If your network address is unstable, you only provide updates to those following your feed, and if you have a lot of followers, you have to get a stable network address with a stable open port so that you do not have to update them all the time. Then we our list of identities whose connection information we are tracking will be considerably smaller, but our level of indirection considerably deeper - possibly needing six or so deep in sum of the sum of ... sum of identity vectors.
But suppose no one specializes in tracking unstable network addresses.
If your network address is unstable, you only provide updates to those
following your feed, and if you have a lot of followers, you have to get a
stable network address with a stable open port so that you do not have to
update them all the time. Then our list of identities whose connection
information we track will be considerably smaller, but our level of
indirection considerably deeper - possibly needing six or so deep in sum of
the sum of ... sum of identity vectors.
## Private messaging

0
wallet.manifest → msvc/wallet.manifest
View File

2
wallet.rc → msvc/wallet.rc
View File

@ -2,7 +2,7 @@
// The visual studio resource editor will screw it up.
#pragma code_page(65001) // UTF-8
// this icon is used with wxFrame::SetIcon()
AAArho ICON "rho.ico"
AAArho ICON "../docs/rho.ico"
// set this to 1 if you don't want to use manifest resource (manifest resource
// is needed to enable visual styles on Windows XP - see docs/msw/winxp.txt

79
wallet.vcxproj → msvc/wallet.vcxproj
View File

@ -43,15 +43,19 @@
<PropertyGroup Label="UserMacros" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<LinkIncremental>true</LinkIncremental>
<IncludePath>GSL\include;wxWidgets\include\msvc;wxWidgets\include;libsodium\src\libsodium\include;mpir;$(IncludePath)</IncludePath>
<LibraryPath>wxWidgets\lib\vc_x64_lib\;libsodium\Build\Debug\X64;mpir\lib\x64\Debug;$(LibraryPath)</LibraryPath>
<IncludePath>$(SolutionDir)wxWidgets\include\msvc;$(SolutionDir)wxWidgets\include;$(SolutionDir)libsodium\src\libsodium\include;$(SolutionDir)mpir;$(IncludePath)</IncludePath>
<LibraryPath>$(SolutionDir)wxWidgets\lib\vc_x64_lib\;$(SolutionDir)libsodium\Build\Debug\X64;$(SolutionDir)mpir\lib\x64\Debug;$(LibraryPath)</LibraryPath>
<CustomBuildAfterTargets />
<IntDir>$(SolutionDir)build\$(Configuration)\</IntDir>
<OutDir>$(SolutionDir)build\$(Configuration)\</OutDir>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<LinkIncremental>false</LinkIncremental>
<IncludePath>GSL\include;wxWidgets\include\msvc;wxWidgets\include;libsodium\src\libsodium\include;mpir;$(IncludePath)</IncludePath>
<LibraryPath>wxWidgets\lib\vc_x64_lib\;libsodium\Build\Release\X64;mpir\lib\x64\Release;$(LibraryPath)</LibraryPath>
<IncludePath>$(SolutionDir)wxWidgets\include\msvc;$(SolutionDir)wxWidgets\include;$(SolutionDir)libsodium\src\libsodium\include;$(SolutionDir)mpir;$(IncludePath)</IncludePath>
<LibraryPath>$(SolutionDir)wxWidgets\lib\vc_x64_lib\;$(SolutionDir)libsodium\Build\Release\X64;$(SolutionDir)mpir\lib\x64\Release;$(LibraryPath)</LibraryPath>
<CustomBuildAfterTargets />
<IntDir>$(SolutionDir)build\$(Configuration)\</IntDir>
<OutDir>$(SolutionDir)build\$(Configuration)\</OutDir>
</PropertyGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<ClCompile>
@ -119,60 +123,59 @@
<CustomBuildStep />
</ItemDefinitionGroup>
<ItemGroup>
<ClInclude Include="app.h" />
<ClInclude Include="db_accessors.h" />
<ClInclude Include="display_wallet.h" />
<ClInclude Include="frame.h" />
<ClInclude Include="introspection_of_standard_C_types.h" />
<ClInclude Include="mpir_and_base58.h" />
<ClInclude Include="ILog.h" />
<ClInclude Include="ISqlite3.h" />
<ClInclude Include="localization.h" />
<ClInclude Include="ristretto255.h" />
<ClInclude Include="rotime.h" />
<ClInclude Include="secrets.h" />
<ClInclude Include="slash6.h" />
<ClInclude Include="sqlite3/sqlite3.h" />
<ClInclude Include="stdafx.h" />
<ClInclude Include="welcome_to_rhocoin.h" />
<ClInclude Include="../src/app.h" />
<ClInclude Include="../src/db_accessors.h" />
<ClInclude Include="../src/display_wallet.h" />
<ClInclude Include="../src/frame.h" />
<ClInclude Include="../src/introspection_of_standard_C_types.h" />
<ClInclude Include="../src/mpir_and_base58.h" />
<ClInclude Include="../src/ILog.h" />
<ClInclude Include="../src/ISqlite3.h" />
<ClInclude Include="../src/localization.h" />
<ClInclude Include="../src/ristretto255.h" />
<ClInclude Include="../src/rotime.h" />
<ClInclude Include="../src/secrets.h" />
<ClInclude Include="../src/slash6.h" />
<ClInclude Include="../src/stdafx.h" />
<ClInclude Include="../src/welcome_to_rhocoin.h" />
<ClInclude Include="..\src\sqlite3.h" />
</ItemGroup>
<ItemGroup>
<ClCompile Include="app.cpp" />
<ClCompile Include="display_wallet.cpp" />
<ClCompile Include="frame.cpp" />
<ClCompile Include="ILog.cpp" />
<ClCompile Include="ISqlit3Impl.cpp">
<ClCompile Include="../src/app.cpp" />
<ClCompile Include="../src/display_wallet.cpp" />
<ClCompile Include="../src/frame.cpp" />
<ClCompile Include="../src/ILog.cpp" />
<ClCompile Include="../src/ISqlit3Impl.cpp">
<PrecompiledHeader Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">NotUsing</PrecompiledHeader>
<PrecompiledHeader Condition="'$(Configuration)|$(Platform)'=='Release|x64'">NotUsing</PrecompiledHeader>
</ClCompile>
<ClCompile Include="localization.cpp">
<ClCompile Include="../src/localization.cpp">
<PrecompiledHeader Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">NotUsing</PrecompiledHeader>
<PrecompiledHeader Condition="'$(Configuration)|$(Platform)'=='Release|x64'">NotUsing</PrecompiledHeader>
</ClCompile>
<ClCompile Include="mpir_and_base58.cpp" />
<ClCompile Include="ristretto255.cpp" />
<ClCompile Include="rotime.cpp" />
<ClCompile Include="secrets.cpp" />
<ClCompile Include="slash6.cpp">
<ClCompile Include="../src/mpir_and_base58.cpp" />
<ClCompile Include="../src/ristretto255.cpp" />
<ClCompile Include="../src/rotime.cpp" />
<ClCompile Include="../src/secrets.cpp" />
<ClCompile Include="../src/slash6.cpp">
<PrecompiledHeader Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">NotUsing</PrecompiledHeader>
<PrecompiledHeader Condition="'$(Configuration)|$(Platform)'=='Release|x64'">NotUsing</PrecompiledHeader>
</ClCompile>
<ClCompile Include="sqlite3/sqlite3.c">
<ClCompile Include="$(SolutionDir)sqlite3\sqlite3.c">
<PrecompiledHeader Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">NotUsing</PrecompiledHeader>
<PrecompiledHeader Condition="'$(Configuration)|$(Platform)'=='Release|x64'">NotUsing</PrecompiledHeader>
</ClCompile>
<ClCompile Include="stdafx.cpp">
<ClCompile Include="../src/stdafx.cpp">
<PrecompiledHeader Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">Create</PrecompiledHeader>
<PrecompiledHeader Condition="'$(Configuration)|$(Platform)'=='Release|x64'">Create</PrecompiledHeader>
</ClCompile>
<ClCompile Include="testbed.cpp" />
<ClCompile Include="unit_test.cpp">
<AdditionalOptions Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">/utf-8 %(AdditionalOptions)</AdditionalOptions>
<ClCompile Include="../src/testbed.cpp" />
<ClCompile Include="../src/unit_test.cpp">
</ClCompile>
<ClCompile Include="welcome_to_rhocoin.cpp" />
<ClCompile Include="../src/welcome_to_rhocoin.cpp" />
</ItemGroup>
<ItemGroup>
<Image Include="rho.ico" />
<Image Include="../docs/rho.ico" />
</ItemGroup>
<ItemGroup>
<ResourceCompile Include="wallet.rc" />

8
winConfig.bat → msvc/winConfig.bat
View File

@ -94,28 +94,28 @@ IF %ERRORLEVEL% NEQ 0 (
echo on
cd ..\..\..
msbuild wallet.vcxproj -p:Configuration=Debug;Platform=x64 -m
msbuild wallet.sln -p:Configuration=Debug;Platform=x64 -m
echo off
IF %ERRORLEVEL% NEQ 0 (
PAUSE
GOTO:EOF
)
echo on
msbuild wallet.vcxproj -p:Configuration=Release;Platform=x64 -m
msbuild wallet.sln -p:Configuration=Release;Platform=x64 -m
echo off
IF %ERRORLEVEL% NEQ 0 (
PAUSE
GOTO:EOF
)
echo on
.\x64\Debug\wallet.exe --complete --test
.\build\Debug\wallet.exe --complete --test
echo off
IF %ERRORLEVEL% NEQ 0 (
echo failed unit test on debug build
) ELSE (
echo passed unit test on debug build)
echo on
.\x64\Release\wallet.exe --complete --test
.\build\Release\wallet.exe --complete --test
echo off
IF %ERRORLEVEL% NEQ 0 (
echo failed unit test on release build

0
ILog.cpp → src/ILog.cpp
View File

0
ILog.h → src/ILog.h
View File

2
ISqlit3Impl.cpp → src/ISqlit3Impl.cpp
View File

@ -14,7 +14,7 @@
#include <memory> // for shared_ptr, unique_ptr
#include <span>
#include "ISqlite3.h"
#include "sqlite3/sqlite3.h"
#include "sqlite3.h"
static auto error_message(int rc, sqlite3* pdb) {
return std::string("Sqlite3 Error: ") + sqlite3_errmsg(pdb) + ". Sqlite3 error number=" + std::to_string(rc);

0
ISqlite3.h → src/ISqlite3.h
View File

0
app.cpp → src/app.cpp
View File

0
app.h → src/app.h
View File

0
db_accessors.h → src/db_accessors.h
View File

0
display_wallet.cpp → src/display_wallet.cpp
View File

0
display_wallet.h → src/display_wallet.h
View File

0
frame.cpp → src/frame.cpp
View File

0
frame.h → src/frame.h
View File

0
introspection_of_standard_C_types.h → src/introspection_of_standard_C_types.h
View File

0
localization.cpp → src/localization.cpp
View File

0
localization.h → src/localization.h
View File

0
mpir_and_base58.cpp → src/mpir_and_base58.cpp
View File

0
mpir_and_base58.h → src/mpir_and_base58.h
View File

0
rho.xpm → src/rho.xpm
View File

0
ristretto255.cpp → src/ristretto255.cpp
View File

0
ristretto255.h → src/ristretto255.h
View File

0
rotime.cpp → src/rotime.cpp
View File

0
rotime.h → src/rotime.h
View File

0
secrets.cpp → src/secrets.cpp
View File

0
secrets.h → src/secrets.h
View File

0
slash6.cpp → src/slash6.cpp
View File

0
slash6.h → src/slash6.h
View File

0
sqlite3/sqlite3.h → src/sqlite3.h
View File

0
stdafx.cpp → src/stdafx.cpp
View File

0
stdafx.h → src/stdafx.h
View File

0
testbed.cpp → src/testbed.cpp
View File

0
unit_test.cpp → src/unit_test.cpp
View File

0
welcome_to_rhocoin.cpp → src/welcome_to_rhocoin.cpp
View File

0
welcome_to_rhocoin.h → src/welcome_to_rhocoin.h
View File

2
wallet.sln
View File

@ -3,7 +3,7 @@ Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.0.32014.148
MinimumVisualStudioVersion = 10.0.40219.1
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "wallet", "wallet.vcxproj", "{B1EC18D5-FA70-4A59-8CAE-EDC65A358314}"
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "wallet", "msvc/wallet.vcxproj", "{B1EC18D5-FA70-4A59-8CAE-EDC65A358314}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution Items", "{2F7D488C-DC53-4ECE-87E2-4FEA32C153EF}"
EndProject