--- Log opened Fri Apr 24 00:00:04 2020
01:03 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:785c:f881:7a06:8408] has joined #utreexo
01:10 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:785c:f881:7a06:8408] has quit [Remote host closed the connection]
01:11 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:785c:f881:7a06:8408] has joined #utreexo
02:29 -!- nick_fre_ [~nick_free@2001:16b8:3039:2300:3d9a:9b7:df29:2d7d] has joined #utreexo
02:30 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:785c:f881:7a06:8408] has quit [Ping timeout: 265 seconds]
05:16 -!- nick_fre_ [~nick_free@2001:16b8:3039:2300:3d9a:9b7:df29:2d7d] has quit [Remote host closed the connection]
07:16 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:3d9a:9b7:df29:2d7d] has joined #utreexo
07:17 < adiabat> ja: why do you need to access ramForestData directly in the c binding?
07:17 < adiabat> is there another way, maybe some other functions can be exported?
07:18 < adiabat> also, hmm, OK you also get the crash, I need to reproduce this.  I will start making some tests to try and cause it
07:18 < adiabat> since my blk/rev files don't seem to do it
07:18 < ja> adiabat: right now, i convert the c-serialization to go, i instantiate the ramForestData directly and shove it in there
07:19 < ja> adiabat: what would be the better way? i don't wanna add the elements since the c-forest should already satisfy the invariants, and no illegal tree could be stored
07:19 < adiabat> what do you mean by convert the c-serialization to go?
07:20 < adiabat> are you writing serialization code in c, and having go call that?
07:20 < ja> nah, other way around. i wrote c structs, that go copies the forest into
07:21 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:3d9a:9b7:df29:2d7d] has quit [Ping timeout: 272 seconds]
07:21 < ja> so that i could port methods one by one, access all the elements of the forest from c
07:22 < ja> it would be possible to have an opaque wrapper, but then you can't really write any operations for the tree in your alternate language
07:22 < adiabat> is the goal to have a full re-implementation in c, or just to have c functions be able to call the go forest methods?
07:23 < adiabat> I guess if it's on disk data this wouldn't be as bit of an issue
07:23 < adiabat> because then you have access to the raw forest data file
07:23 < ja> the immediate goal was the latter
07:23 < adiabat> I guess for ramForestData, all you need is a pointer to the stat of it
07:24 < adiabat> the ramForestData isn't really garbage collected though, it's basically a giant malloc and it never gets smaller
07:25 < ja> hmmm i should just show you my code, wait i'll push it
07:25 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:3d9a:9b7:df29:2d7d] has joined #utreexo
07:25 < adiabat> ok
07:25 -!- nick_fre_ [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has joined #utreexo
07:26 < adiabat> another way would be to just capitalize everything and make a accumulator interface and tell people to use the interface methods
07:27 < ja> here it is: https://github.com/ysangkok/utreexo/blob/cgo/c/forest_c_.go
07:28 -!- nick_fre_ [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has quit [Remote host closed the connection]
07:28 < ja> python though
07:28 -!- nick_fre_ [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has joined #utreexo
07:28 < ja> well, when doing this code i definitely asked myself what is even the value of having anything private if you're not doing stable software. maybe i have done too much python though
07:29 < ja> what would be an accumulator interface? Add/Remove? isn't the interface almost already there?
07:29 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:3d9a:9b7:df29:2d7d] has quit [Ping timeout: 260 seconds]
07:30 < adiabat> Yeah, the public / private thing is kind of annoying sometimes, it signals "intent" I guess
07:30 < adiabat> yeah the internface is basically:
07:30 < ja> well, it is enforced, so more than just a signal ;)
07:31 < ja> here are my c-forest representation that i have go copy into: https://github.com/ysangkok/utreexo/blob/cgo/c/forest.h
07:31 < adiabat> Modify(), ProveBatch(), VerifyBatchProof()
07:31 < adiabat> hm right now there's a lot of exported stuff that shouldn't be
07:31 < adiabat> hm I guess Undo() also is the interface
07:32 < ja> i am actually not even sure if it is possible to have an opaque interface, since you can't let go-objects escape the garbage collector.
07:32 < adiabat> also for forest it's not certain we even need VerifyBatchProof(), since the bridge node doesn't do that
07:32 < ja> "Not all Go types can be mapped to C types in a useful way. Go struct types are not supported; use a C struct type. Go array types are not supported; use a C pointer."
07:33 -!- nick_fre_ [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has quit [Ping timeout: 265 seconds]
07:33 < ja> yeah, i don't care too much about proofs for now
07:33 < adiabat> hm
07:33 < ja> this is really just me trying to reimplement the forest with an API into the go forest for verification :P
07:33 < adiabat> hopefully don't have to change the go code too much to accomodate a c binding though
07:34 < adiabat> yeah a c rewrite of like transform.go is probably easier
07:34 < adiabat> since there's almost no go-sepcific stuff, it's just some loops 
07:34 < ja> well, that is the problem. the code i linked is working, but it is capitalizing all the stuff in utreexo/
07:34 < adiabat> I mean... as a temoprary measure I think that's OK
07:34 < adiabat> right now it seems pretty haphazard what's capitalized
07:35 < adiabat> GetTops shouldn't be...
07:35 < ja> maybe it would make more sense to just only do the disk format. then the API into the forest would just pass a filename. the filesystem is a portable api :P
07:35 < adiabat> Add() is but Remove() isn't hah
07:35 < adiabat> yeah on disk might be easier also
07:36 < adiabat> easy to see what's going on since if it crashes it leaves the whole thing on disk to look at
07:36 < ja> ok, i think i'll do that then, let's see...
08:14 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has joined #utreexo
09:04 < kcalvinalvin> hmm I think issue 114 could be some dumb off by one thing
09:17 < kcalvinalvin> oh nvm I
09:17 < kcalvinalvin> 'm dumb
09:17 < kcalvinalvin> oh boy
09:17 < kcalvinalvin> I didn't have the rev*.dat file on my directory
09:17 < kcalvinalvin> I'm guessing ja didn't either 
09:22 < kcalvinalvin> adiabat ok great it works when I throw in the rev*.dat file
09:26 < ja> why would the rev*.dat be missing?
09:28 < kcalvinalvin> So right now, the binary searches for the rev*.dat files in the directory you're executing it at
09:28 < kcalvinalvin> I didn't have it in there
09:28 < kcalvinalvin> Since you were resuming, there might have been some bugs in there
09:29 < kcalvinalvin> Try ```rm -r *data testnet-ttldb``` and try running it again
09:30 < ja> aaaah
09:30 < ja> maybe we should start putting a version header in the files...
09:32 < kcalvinalvin> ok I'm hitting another bug
09:32 < kcalvinalvin> fun
09:32 < kcalvinalvin> adiabat what does your directory look like?
09:34 < adiabat> I just have blk00000.dat and rev00000.dat
09:34 < adiabat> and cmd
09:34 < adiabat> then it makes a bunch of directories and files
09:35 < adiabat> for mainnet I have 
09:35 < adiabat> blk00000.dat  blk00001.dat  cmd  rev00000.dat  rev00001.dat
09:35 < adiabat> the current master should at least actually give an error instead of crashing
09:35 < adiabat> it... did err=fmt.errforf() but then didn't return, oops
09:36 < adiabat> but now should return and the errors should go up and make it quit
09:36 < kcalvinalvin> ah ok I think there's something wrong with rev reader
09:41 < kcalvinalvin> adiabat could you try with blk00001.dat and rev000001.dat added?
09:41 < kcalvinalvin> I'm crashing on block 85780
09:54 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has quit [Remote host closed the connection]
09:55 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has joined #utreexo
10:31 < adiabat> still crashing? or error
10:31 < adiabat> will try in a bit (mtg now)
11:02 < adiabat> kcalvinalvin: this is on testnet?  downloading that now
11:02 < adiabat> (my servers are all dead... and can't get into building to fix them so gotta go local :)
11:03 < kcalvinalvin> yes I did that on testnet
11:03 < kcalvinalvin> oof
11:04 < adiabat> ok will have testnet blk/rev 01 in a couple min
11:04 < adiabat> rev00001.dat            47% 9776KB 372.7KB/s   00:29 ET
11:04 < kcalvinalvin> at times I guess it'll be faster for someone to mail you the blockchain data every week haha
11:04 < adiabat> aw yeah blazin fast
12:16 < adiabat> still not getting any problems with first couple files of testnet.  but everyone's files are different... will try moe
12:16 < adiabat> *more
14:15 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has quit [Remote host closed the connection]
14:57 -!- nick_fre_ [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has joined #utreexo
15:16 -!- nick_fre_ [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has quit [Remote host closed the connection]
15:16 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has joined #utreexo
15:38 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
15:45 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #utreexo
15:54 -!- nick_freeman [~nick_free@2001:16b8:3039:2300:28ad:d788:7d88:1417] has left #utreexo []
15:55 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Quit: jb55]
16:30 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #utreexo
16:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Client Quit]
--- Log closed Sat Apr 25 00:00:05 2020