2018-06-03 05:12:40
@Tyler Boone So some feedback.
So the entire project is labeled snowblossom, why put that string on the front of directories?
In my opinion we should have
src
lib

Fireduck
2018-06-03 05:13:01
node
client
miner
shackleton

Fireduck
2018-06-03 05:13:50
That indent doesn't look right. I mean src with the following directories under it {lib, node, client, miner, shackleton}

Fireduck
2018-06-03 05:15:16
A single bazel project with multiple targets is fine

Fireduck
2018-06-03 05:15:26
bazel is very good about not rebuilding things when it doesn't need to

Fireduck
2018-06-03 05:27:56
I think that makes the dependencies less obvious

Tyler Boone
2018-06-03 05:28:58
And even what all composes a stand-alone "piece"/library

Tyler Boone
2018-06-03 05:29:38
I guess it each library is a folder under src?

Tyler Boone
2018-06-03 05:30:39
lets say component. So we have four binaries that we build, node, miner, client and shackleton

Fireduck
2018-06-03 05:31:10
and one shared library that they all will use, which would be Globals, NetworkParams and most of those *Util classes

Fireduck
2018-06-03 05:31:32
What makes sense to me is to have node/src, node/test, miner/src, miner/test, etc.

Tyler Boone
2018-06-03 05:31:53
I hate that and I'm not sure why

Fireduck
2018-06-03 05:32:12
It might be because want to be able to do "grep something src" and see all uses

Fireduck
2018-06-03 05:32:16
that's the standard layout of java projects...

Tyler Boone
2018-06-03 05:32:40
The standard layout of java projects is designed by normal java developers, so I don't put a lot of weight in that

Fireduck
2018-06-03 05:33:01
yeah...

Tyler Boone
2018-06-03 05:33:38
but deviations from standards make things more confusing for experienced developers too

Tyler Boone
2018-06-03 05:33:53
sure, I was mostly following a form of the google standard

Fireduck
2018-06-03 05:34:05
yeah, it's what you are used to, makes sense

Tyler Boone
2018-06-03 05:34:13
which has java/com/google/etc, basically all source under one tree

Fireduck
2018-06-03 05:34:18
and then javatest/com/google/etc

Fireduck
2018-06-03 05:34:23
all tests under a separate tree

Fireduck
2018-06-03 05:35:14
now that I type that out, I don't know what the advantage of that is

Fireduck
2018-06-03 05:35:41
I'm not a huge fan of that, but I don't hate it so long as the folders under test mirror the folders under src

Tyler Boone
2018-06-03 05:35:42
In your scheme, where do I put tests the test multiple components at once?

Fireduck
2018-06-03 05:35:47
SpoonTest for example

Fireduck
2018-06-03 05:36:07
yeah, they should mirror exactly (which I am aware I haven't been doing)

Fireduck
2018-06-03 05:36:26
let me look at spoontest

Tyler Boone
2018-06-03 05:36:42
You'll love it, it is terrible

Fireduck
2018-06-03 05:36:53
but probably the most useful

Fireduck
2018-06-03 05:37:22
does this simulate running a node and a client and a miner?

Tyler Boone
2018-06-03 05:37:49
It simulates nothing, it does it

Fireduck
2018-06-03 05:37:52
there is no mocking

Fireduck
2018-06-03 05:37:57
classy

Tyler Boone
2018-06-03 05:38:51
if I were emporer, stuff like this would live in a systems/integration test project

Tyler Boone
2018-06-03 05:39:13
What does project mean?

Fireduck
2018-06-03 05:39:22
like "snowblossomlib"

Tyler Boone
2018-06-03 05:39:34
basically "something that compiles to a jar"

Tyler Boone
2018-06-03 05:40:05
bazel does some strange things with tests into binaries but whatever

Fireduck
2018-06-03 05:40:09
I get what you are saying

Fireduck
2018-06-03 05:40:32
yeah, I use more Eclipse/Visual Studio terminology

Tyler Boone
2018-06-03 05:40:39
I haven't totally internalized Bazel yet

Tyler Boone
2018-06-03 05:41:06
Think of bazel as more like make, it isn't super bossy about how you lay out files

Fireduck
2018-06-03 05:41:18
it is just a way to define build rules and dependancies between things

Fireduck
2018-06-03 05:41:53
yeah, that's what I gathered from what you had

Tyler Boone
2018-06-03 05:42:11
I'm a fan of enforcing order upon things

Tyler Boone
2018-06-03 05:43:27
let me finish munging the folders tomorrow based on this feedback and lets see what we think of it

Tyler Boone
2018-06-03 05:43:44
sounds good

Fireduck
2018-06-03 05:43:47
I appreciate it

Fireduck
2018-06-03 05:43:48
I'll go with client/src, client/test, node/src, noce/test, etc

Tyler Boone
2018-06-03 05:44:13
if you don't like it once you see it, it will be easy to switch to src/[node, client], test/[node, client]

Tyler Boone
2018-06-03 05:44:36
cool

Fireduck
2018-06-03 05:45:32
I like the first way because it keeps the tests close to the code, and makes these questions obvious 1) what code is being tested by a given test?, and 2) what tests cover this code?

Tyler Boone
2018-06-03 05:45:59
anyways, I was supposed to be going to bed.

Tyler Boone
2018-06-03 05:46:13
Dan won't be impressed if I stay longer...

Tyler Boone
2018-06-03 05:46:32
ttyl

Tyler Boone
2018-06-03 20:50:05
*https://github.com/snowblossomcoin/snowblossom/compare/0eb2a87eb8de...166b45ac74a5*
https://github.com/snowblossomcoin/snowblossom/commit/166b45ac74a5b6098136a5dd0ed8cf4222ca18a8 - Using latest version for each node id

GitHub
2018-06-03 21:02:22
*https://github.com/snowblossomcoin/snowblossom/compare/166b45ac74a5...0e19313c7630*
https://github.com/snowblossomcoin/snowblossom/commit/0e19313c7630fcfd776a8a10fc988d517392a941 - Only prune expired peers after we get connected

GitHub
2018-06-03 21:02:22
[snowblossomcoin/snowblossom] Issue closed by fireduck64

GitHub
2018-06-03 21:02:23
[snowblossomcoin/snowblossom] Issue closed by fireduck64

GitHub
2018-06-03 21:08:08
So we can do deterministic wallets bip39 style from a seed and HD derivation like other things for EC keys.
That is no problem.
It would be nice to do it for non-EC keys as well, but the part with the xpub deriving addresses without the need of the private key is EC-only magic. But we don't really need that, we could do derivable non-EC keys with using the seed to feed into a deterministic PRNG and then have that used as the SecureRandom to generate other types of keys.
There are problems that probably make this a bad idea:
• If the key generation does any sort of floating point or per-platform/environment optimization it could generate different addresses on different machines/platforms/environments.
• If the key generation algorithm changes in any ways, we will almost certainly generate different keys.
This isn't the sort of thing we can screw around on. Probably a bad idea.

GitHub
2018-06-03 21:13:04
[snowblossomcoin/snowblossom] Issue closed by fireduck64

GitHub