--- Log opened Sat Jun 06 00:00:42 2020
05:30 -!- dergoegge [~dergoegge@37.120.217.220] has joined #utreexo
08:10 < kcalvinalvin> ok rev is fixed now :)
08:10 < kcalvinalvin> Need to put a datadir option for cli though
08:11 < kcalvinalvin> Should the binary still generate the data folders where they run it?
09:42 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #utreexo
09:53 < adiabat> I'm changing data folders in the hook PR
09:59 < adiabat> so... I guess where run is better than /home/user/.secretFolder
10:00 < adiabat> (I know that's convention but where run seems better for now)
10:14 < rjected> yeah go 1.13 added phone home
10:23 < ThomasV> adiabat: hi, any progress on #130?
10:25 < kcalvinalvin> ThomasV PR #144 fixes it. The actual fix is there, just need the datadir option which adiabat is almost done with
10:26 < ThomasV> great, I will try it
10:27 < kcalvinalvin> ThomasV just replace line 249 in bridgenode/rev.go in PR #144 with the path to index/ and it should work
10:28 < ThomasV> thanks
10:28 < kcalvinalvin> Also, word of warning. I think touching the index/ forces you to reindex
10:29 < kcalvinalvin> Might want to make a separate copy first
10:29 < kcalvinalvin> https://github.com/bitcoin/bitcoin/issues/12690
10:29 < kcalvinalvin> Might be this...
10:30 < ThomasV> does your process 'touch' it?
10:30 < kcalvinalvin> yes
10:30 < ThomasV> why?
10:31 < kcalvinalvin> There's no way to tell where the revblock for a particular block is without touching the block index
10:32 < kcalvinalvin> I guess this is also something to fix/improve upon down the road. Do mind that the whole project is still *very* early
10:33 < ThomasV> so I should not run it while bitcoind is running? :D
10:36 < kcalvinalvin> Well, you couldn't run it while bitcoind is running anyways since leveldb doesn't support one db being used by 2 separate processes
10:36 < kcalvinalvin> But yeah, right now, it will force you to reindex
10:42 < kcalvinalvin> oh wait, there seems to be an easy enough fix
10:48 < kcalvinalvin> Ah it's just an option. I'll throw that in the non-draft PR
11:40 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
11:47 -!- dergoegge [~dergoegge@37.120.217.220] has quit [Quit: leaving]
12:24 < adiabat> kcalvinalvin: can't we look at the DB in a read-only mode?
12:25 < adiabat> we don't want to be messing up the blocks/ dir or index, all we need is read access
12:52 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #utreexo
14:10 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
14:50 < ja> i am getting so tired of changing the internal forest functions to dump their arguments to json that i wonder if i should use eBPF to do it, then i wouldn't need patching...
15:15 -!- dergoegge [~dergoegge@37.120.217.220] has joined #utreexo
15:32 < rjected> If this is for debugging, you can do %#v or %v or %+v and don't have to deal with json at all
15:33 < rjected> in a sprintf
15:33 < rjected> really a simple sprintf is all you need
15:51 < ja> it is to extract samples for testing for equivalence with my haskell implementation. i had sprintf before but it was cumbersome to parse compared to json.Marshal
15:52 < ja> the idea is that  i would run the test suite unmodified and the eBPF program could extract the samples.
15:52 < ja> since, if i do it with json.Marshal, i for example need to make from/to of arrow into From/To or json.Marshal will not emit them
17:42 -!- dergoegge [~dergoegge@37.120.217.220] has quit [Quit: leaving]
19:11 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #utreexo
20:10 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
22:24 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #utreexo
23:13 < kcalvinalvin> adiabat it is in read-only. The problem above was that bitcoin core uses leveldb uncompressed
23:13 < kcalvinalvin> by default, compression was turned on with the syndtr leveldb thing
23:13 < kcalvinalvin> fixed now on my draft pr
--- Log closed Sun Jun 07 00:00:43 2020