--- Log opened Mon Apr 13 00:00:50 2020
01:18 -!- nick_freeman [~nick_free@i5C7490F4.versanet.de] has joined #utreexo
02:11 -!- nick_freeman [~nick_free@i5C7490F4.versanet.de] has quit [Remote host closed the connection]
02:12 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:b07a:79bc:501:8b87] has joined #utreexo
03:09 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:b07a:79bc:501:8b87] has quit [Remote host closed the connection]
03:10 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:b07a:79bc:501:8b87] has joined #utreexo
03:14 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:b07a:79bc:501:8b87] has quit [Remote host closed the connection]
03:14 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:b07a:79bc:501:8b87] has joined #utreexo
03:14 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:b07a:79bc:501:8b87] has quit [Remote host closed the connection]
03:15 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:b07a:79bc:501:8b87] has joined #utreexo
04:35 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:b07a:79bc:501:8b87] has quit [Remote host closed the connection]
05:31 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:b07a:79bc:501:8b87] has joined #utreexo
05:32 -!- nick_fre_ [~nick_free@2001:16b8:304d:bb00:a943:a994:2c46:e920] has joined #utreexo
05:36 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:b07a:79bc:501:8b87] has quit [Ping timeout: 272 seconds]
05:42 -!- nick_fre_ [~nick_free@2001:16b8:304d:bb00:a943:a994:2c46:e920] has quit [Remote host closed the connection]
05:43 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:a943:a994:2c46:e920] has joined #utreexo
05:45 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:a943:a994:2c46:e920] has quit [Remote host closed the connection]
05:45 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:a943:a994:2c46:e920] has joined #utreexo
09:31 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:a943:a994:2c46:e920] has quit [Remote host closed the connection]
11:45 -!- nick_freeman [~nick_free@i5C7490F4.versanet.de] has joined #utreexo
12:18 < adiabat> ja: I still can't reproduce the failures outside of TestSmallRandomForests
12:18 < ja> weird...
12:18 < adiabat> I'm not too familiar with how it's working, like using reflect heh 
12:19 < ja> well it basically just constructs an arbitrary value of that type
12:19 < ja> the 1,0 test i submitted was generated using this quick-based test
12:19 < ja> i just copied out the logged tree values and put them in another test
12:20 < ja> so you could give me an example of a tree that fails in the test but doesn't fail outside?
12:20 < adiabat> one simple failure is: add 4 elements, delete 0,1,2
12:20 < ja> ok, i'll try to see if that passes on my machine now
12:21 < adiabat> no it still fails
12:21 < adiabat> I just added " TestForestFixed"
12:21 < adiabat> to try to get the same failure and can't
12:21 < ja> what still fails?
12:22 < adiabat> I mean TestSmallRandomForests fails
12:22 < adiabat> but when I try doing the same add/remove with TestForestFixed, it looks OK
12:23 < ja> let me just read your TestForestFixed to make sure it actually would error on any problems...
12:23 < ja> seems like you didn't push it yet?
12:23 < adiabat> Also I added t.Logf(f.ToString()) to parts of TestSmallRandomForests, and it seems like it's saying "proveblock failed" when it hasn't
12:23 < adiabat> TestForestFixed is pushed to master
12:24 < ja> ah sorry, was on wrong branch
12:24 < adiabat> I think the problem is that TestSmallRandomForests is not adding things in the order it thinks it is
12:24 < adiabat> I get:
12:25 < adiabat> adding (the bool values are whether deletion happens): map[64:true 0:false 241:true]
12:25 < adiabat> and then the tree base is 00:0001 01:f101 02:4001
12:25 < adiabat> deleting: [0 1], then tree base is 00:4001 01:f101 02:0001
12:25 < ja> oooh
12:26 < adiabat> and it fails with proveblock failed proving existing leaf: hash 00010...
12:26 < ja> i actually think they changed this in a recent go version
12:26 < adiabat> but 0001 was deleted as it was in position 0
12:26 < ja> so we may not even have the same behaviour...
12:26 < adiabat> oh shoot is it a 1.13 vs 1.11 or somehting bug? arg
12:27 < ja> https://golang.org/doc/go1.12#fmt
12:27 < ja> "Maps are now printed in key-sorted order to ease testing. "
12:28 < adiabat> ok but that works either way
12:28 < adiabat> that only affects the printf
12:28 < adiabat> (also.. how does it know... or does it sort the whole thing after iterating it...)
12:28 < ja> but it would cause different behaviour when copying out a printed map to a different test using the clipboard
12:29 < ja> i dunno how it works, gotta find the diff i guess
12:29 < adiabat> this isn't a printf map issue though; the test is failing and it seems like it shouldn't, based on what's in the tree
12:30 < adiabat> the tree initall has  00:0001 01:f101 02:4001, then positions 0, 1 are deleted
12:30 < adiabat> and then leaf 0001 is asked for, and it fails when there is no proof for it
12:31 < adiabat> but there shouldn't be a proof for it, because 0001 has been deleted
12:31 < adiabat> it was in position 0
12:31 < adiabat> the leaf that remains is 4001
12:31 < adiabat> the problem seems to be map[64:true 0:false 241:true]
12:32 < adiabat> it thinks 0 is false, but .. it's not
12:32 < adiabat> I'm sure the *map* value is false, but it's not actually sticking around
12:32 < adiabat> so the "adding (the bool values are whether deletion happens)" doesn't seem right
12:34 < ja> so it's deleting something it shouldn't, somehow leavesToDeleteSet is not correct?
12:35 < adiabat> yeah seems like it
12:35 < adiabat> I don't reall get "struct{}{}" though
12:36 < ja> it's the value of a type with only one element
12:36 < ja> the 'unit' type
12:36 < ja> the map must need an equality operations on the keys, i wonder if that could be broken
12:36 < adiabat> hm... ok.  But yeah in this case, it's adding [64:true 0:false 241:true]
12:36 < adiabat> but it's not deleting 64 and 241
12:37 < adiabat> it deleted 4001 and f101
12:37 < adiabat> which is 64 and 241
12:37 < adiabat> hm would be nicer to show the map in hex I guess
12:37 < ja> i think i may be reproduce it with this info
12:37 < ja> i'll try now...
12:39 < adiabat> maybe some part where it's looking up, deletions[i] = int(f.positionMap[leafTxo.Mini()])
12:40 < adiabat> that looks correct though, but something around there..
12:42 < adiabat> ok got it to do another one (it's weird, it's sometimes different when I re-run the test but usually the same)
12:42 < adiabat> adding (the bool values are whether deletion happens): map[141:true 158:true 88:false 172:true] deleting: [0 1 2]
12:43 < adiabat> initial forest 00:9e01 01:5801 02:ac01 03:8d01, then 00:8d01 01:5801 02:ac01 03:9e01
12:43 < adiabat> then fails 5801 not found. 0x58 = 88
12:43 < adiabat> but 9e01 is the only one left (0x93 = 158)
12:44 < adiabat> er 0x9e
12:47 < ja> aaah
12:47 < ja> i found it
12:47 < ja> !
12:47 < adiabat> ah
12:47 < ja> it's "el := range deletions" which iterates over indexes, not values
12:47 < adiabat> me too
12:47 < adiabat> yeah
12:47 < adiabat> heh that's why I always do for i, _ := range slice {}
12:48 < ja> yeah i will adopt that
12:48 < adiabat> even though that's supposedly not "canonical" or whatever I always put the _ because I've missed that sometimes
12:48 < adiabat> looks like it passes with _, el := range
12:49 < ja> yeah
12:49 < ja> damn, sorry to have wasted your time
12:49 < adiabat> heh OK phew so the algorithms still work :)
12:49 < adiabat> no no problem
12:49 < adiabat> I found some other stuff to fix
12:49 < ja> i will fix and squash
12:50 < adiabat> OK cool thanks, I will merge then.  and then try getting rev data all working
12:51 < ja> ok, i pushed!
12:51 -!- nick_freeman [~nick_free@i5C7490F4.versanet.de] has quit [Remote host closed the connection]
12:52 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:2542:3f77:1ed4:151c] has joined #utreexo
12:54 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:2542:3f77:1ed4:151c] has quit [Remote host closed the connection]
12:54 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:2542:3f77:1ed4:151c] has joined #utreexo
12:55 < adiabat> ok cool, green checkmark :)
12:56 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:2542:3f77:1ed4:151c] has quit [Remote host closed the connection]
12:56 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:2542:3f77:1ed4:151c] has joined #utreexo
12:57 -!- nick_fre_ [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has joined #utreexo
13:01 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:2542:3f77:1ed4:151c] has quit [Ping timeout: 265 seconds]
13:33 -!- nick_fre_ [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has quit [Remote host closed the connection]
13:37 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has joined #utreexo
15:54 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has quit [Remote host closed the connection]
15:54 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has joined #utreexo
15:59 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has quit [Ping timeout: 260 seconds]
16:02 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has joined #utreexo
16:04 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has quit [Remote host closed the connection]
16:04 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has joined #utreexo
16:33 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has quit [Remote host closed the connection]
16:34 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has joined #utreexo
17:00 -!- nick_freeman [~nick_free@2001:16b8:304d:bb00:748a:b261:22b9:c24b] has quit [Remote host closed the connection]
23:30 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 260 seconds]
23:30 -!- achow101 [~achow101@unaffiliated/achow101] has joined #utreexo
--- Log closed Tue Apr 14 00:00:51 2020