Transcript for #bitcoin-dev 2018/02/10

09:11 wumpus doesn't this simply work? LogPrintf("your result is %s\n", result.write(2)); where result is of type UniValue
12:20 AndyS2 I'm currently not able to test this, but when running gdb on bitcoind with debug symbols, I've had a rough time interpreting some variables like 'opcode' and the like. could it be that I'm missing some big endian vs little endian stuff? I tried changing that setting inside gdb, but it broke everything. I'm a noob, btw
13:10 wumpus it's very unlikely that gdb gets your endian wrong
13:10 wumpus what kind of architecture is that on?
13:12 AndyS2 standard x86_64, not running anything fancy. maybe I just misunderstand what 'opcode' is for in the interpreter.cpp
13:13 AndyS2 but I get really high numbers sometimes
13:14 AndyS2 just remember from the book by AA that serialized transactions are read 'the other way around', and when I dumped 'opcode' to disk, it had four bytes with all zeroes on the right side
13:15 AndyS2 but if that's not it, that's useful info, too
13:22 AndyS2 got a nicer debugging gui now. So opcode has weird values sometimes, but I also see OP_DUP and other reasonable ones now, so all is well I think :)
14:17 AndyS2 ah, I'm stupid. uninitialized memory gave me huge numbers in the opcode-enum-variable (guess it's 4 bytes internally?), and then (not directly connected) I also forgot that the opcodes 1-75 push the 1-75 following bytes. thought it was a weird scheme where 1-75 pushes a 1 or a 2 or a 75, even though I have probably read about this stuff a thousand times