in general moving everything to /[src|test] format. Also, moving test suite definitions to AllTests classes in each library instead of inside bazel build files.
FYI, here is what my IDE tree looks like with this change:
Can I still build all test all and make deploy files from top level?
Via command line
Also, everyone on Earth goes to trader Joe's at 17:00
the tests don't run from there... let me see what I can do
I just got the deploy files to build and work
bazel test //...
that works, but not "bazel test :all"
I can with that live
I'll see if I can fix that later
also, I accidentally renamed "snowblossom.lib" package to "lib.src"
As long as the deploy files work, that is in docs
I'll fix that later too if that's OK
Sure
trying to remember java and learn intellij and bazel
do you have a strong preference for or against squash?
I usually squash, but I don't have a strong preference.
I don't even know what that is
[snowblossomcoin/snowblossom] #49 Tster/rejigger projects
squash = pull request goes into master as a single commit
merge = pull request goes into master as individual commits, just like they were originally done on master
smash
absolutely smash in
heh, 13,695 ++ 13,298 --
@Fireduck Interesting how experience formulates into exponential results.
oh god, you are still up?
it's 10:30
sure, just two people doing major refactors is a recipe for "fun"
I'm not refactoring anymore
cool. I am moving node stuff into node and out of lib
nice
I'm thinking about making a GUI client
that would be fantastic
can you throw me some snowballs? snowtest:2e24gaw78ktsldkefsclxt7pe9wc3a82g5cynuty
my laptop sucks at mining
sure
done
One downside of these test suites is that I don't know which tests in particular are taking so long any more: //lib:lib.test (cached) PASSED in 99.9s
I'll look into that
can I open issues from here?
@GitHub help
each test should get it's own line.
I do dig not having to add 10 lines to the BUILD for each test class, so that is cool
using intelliJ you get a nice tree of tests :neutral_face:
looks like you mined one block at least: http://snowblossom.1209k.com:8080/
woot
neat
hmmm, client isn't showing anything
are you connected to my testnet?
I am only seeing two nodes
which are mine
C:\Users\tboone\source\repos\snowblossom>type C:\snowblossom\node.conf db_type=rocksdb db_path=snowdb service_port=2338 node_port=2338 network=teapot peer_count=8
those ports should be 2339
C:\Users\tboone\source\repos\snowblossom>type C:\snowblossom\client.conf network=teapot node_host=localhost wallet_path=testwallet node_port=2338
but doesn't really matter
which block height do you have?
1184
block_height: 2724
you are behind
testnet is currently a bear, it has about 1.6 million transactions
OK, it is going up
but it's slow as fuck
yeah, there is room for syncing improvment especially over slower links (ie, not on my local lan)
it requests and processes one block at a time
did you do some kind of load testing back there?
yeah
it suddenly started going faster
OK
yeah, there are occasional clusters of big blocks
depending on what you are doing, you can test just fine on mainnet :wink:
I'll mark documentation
[snowblossomcoin/snowblossom] Issue opened by tster123
do you have a design in mind for how to checkpoint nodes?
Yes
GetUTXONodeRequest can be used to request for an address
or the entire damn database
and can also specify a specific utxo hash to use
so if a node wanting to quick start has a block in mind, it can get the block summary and then start downloading the utxo from any other node
Once it has those it can go from there, minus a few details
Can you going to recycle HHTT Mining Pool code for this?
for making a mining pool?
a great deal of that code was to deal with strangeness of bitcoin so a mining pool on this would be pretty easy to write (at least for me, lol)