archive snowblossom slack dev
prev 2018-06-03 next
2018-06-03 05:12:40
Fireduck
@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
2018-06-03 05:13:01
Fireduck
node client miner shackleton
2018-06-03 05:13:50
Fireduck
That indent doesn't look right. I mean src with the following directories under it {lib, node, client, miner, shackleton}
2018-06-03 05:15:16
Fireduck
A single bazel project with multiple targets is fine
2018-06-03 05:15:26
Fireduck
bazel is very good about not rebuilding things when it doesn't need to
2018-06-03 05:27:56
Tyler Boone
I think that makes the dependencies less obvious
2018-06-03 05:28:58
Tyler Boone
And even what all composes a stand-alone "piece"/library
2018-06-03 05:29:38
Tyler Boone
I guess it each library is a folder under src?
2018-06-03 05:30:39
Fireduck
lets say component. So we have four binaries that we build, node, miner, client and shackleton
2018-06-03 05:31:10
Fireduck
and one shared library that they all will use, which would be Globals, NetworkParams and most of those *Util classes
2018-06-03 05:31:32
Tyler Boone
What makes sense to me is to have node/src, node/test, miner/src, miner/test, etc.
2018-06-03 05:31:53
Fireduck
I hate that and I'm not sure why
2018-06-03 05:32:12
Fireduck
It might be because want to be able to do "grep something src" and see all uses
2018-06-03 05:32:16
Tyler Boone
that's the standard layout of java projects...
2018-06-03 05:32:40
Fireduck
The standard layout of java projects is designed by normal java developers, so I don't put a lot of weight in that
2018-06-03 05:33:01
Tyler Boone
yeah...
2018-06-03 05:33:38
Tyler Boone
but deviations from standards make things more confusing for experienced developers too
2018-06-03 05:33:53
Fireduck
sure, I was mostly following a form of the google standard
2018-06-03 05:34:05
Tyler Boone
yeah, it's what you are used to, makes sense
2018-06-03 05:34:13
Fireduck
which has java/com/google/etc, basically all source under one tree
2018-06-03 05:34:18
Fireduck
and then javatest/com/google/etc
2018-06-03 05:34:23
Fireduck
all tests under a separate tree
2018-06-03 05:35:14
Fireduck
now that I type that out, I don't know what the advantage of that is
2018-06-03 05:35:41
Tyler Boone
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
2018-06-03 05:35:42
Fireduck
In your scheme, where do I put tests the test multiple components at once?
2018-06-03 05:35:47
Fireduck
SpoonTest for example
2018-06-03 05:36:07
Fireduck
yeah, they should mirror exactly (which I am aware I haven't been doing)
2018-06-03 05:36:26
Tyler Boone
let me look at spoontest
2018-06-03 05:36:42
Fireduck
You'll love it, it is terrible
2018-06-03 05:36:53
Fireduck
but probably the most useful
2018-06-03 05:37:22
Tyler Boone
does this simulate running a node and a client and a miner?
2018-06-03 05:37:49
Fireduck
It simulates nothing, it does it
2018-06-03 05:37:52
Fireduck
there is no mocking
2018-06-03 05:37:57
Tyler Boone
classy
2018-06-03 05:38:51
Tyler Boone
if I were emporer, stuff like this would live in a systems/integration test project
2018-06-03 05:39:13
Fireduck
What does project mean?
2018-06-03 05:39:22
Tyler Boone
like "snowblossomlib"
2018-06-03 05:39:34
Tyler Boone
basically "something that compiles to a jar"
2018-06-03 05:40:05
Fireduck
bazel does some strange things with tests into binaries but whatever
2018-06-03 05:40:09
Fireduck
I get what you are saying
2018-06-03 05:40:32
Tyler Boone
yeah, I use more Eclipse/Visual Studio terminology
2018-06-03 05:40:39
Tyler Boone
I haven't totally internalized Bazel yet
2018-06-03 05:41:06
Fireduck
Think of bazel as more like make, it isn't super bossy about how you lay out files
2018-06-03 05:41:18
Fireduck
it is just a way to define build rules and dependancies between things
2018-06-03 05:41:53
Tyler Boone
yeah, that's what I gathered from what you had
2018-06-03 05:42:11
Tyler Boone
I'm a fan of enforcing order upon things
2018-06-03 05:43:27
Tyler Boone
let me finish munging the folders tomorrow based on this feedback and lets see what we think of it
2018-06-03 05:43:44
Fireduck
sounds good
2018-06-03 05:43:47
Fireduck
I appreciate it
2018-06-03 05:43:48
Tyler Boone
I'll go with client/src, client/test, node/src, noce/test, etc
2018-06-03 05:44:13
Tyler Boone
if you don't like it once you see it, it will be easy to switch to src/[node, client], test/[node, client]
2018-06-03 05:44:36
Fireduck
cool
2018-06-03 05:45:32
Tyler Boone
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?
2018-06-03 05:45:59
Tyler Boone
anyways, I was supposed to be going to bed.
2018-06-03 05:46:13
Tyler Boone
Dan won't be impressed if I stay longer...
2018-06-03 05:46:32
Tyler Boone
ttyl
2018-06-03 21:02:22
GitHub
[snowblossomcoin/snowblossom] Issue closed by fireduck64
2018-06-03 21:02:23
GitHub
[snowblossomcoin/snowblossom] Issue closed by fireduck64
2018-06-03 21:08:08
GitHub
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.
2018-06-03 21:13:04
GitHub
[snowblossomcoin/snowblossom] Issue closed by fireduck64