1 2018-02-10 09:11:24 <wumpus> doesn't this simply work?  LogPrintf("your result is %s\n", result.write(2));  where result is of type UniValue
 2 2018-02-10 12:20: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
 3 2018-02-10 13:10:34 <wumpus> it's very unlikely that gdb gets your endian wrong
 4 2018-02-10 13:10:41 <wumpus> what kind of architecture is that on?
 5 2018-02-10 13:12:55 <AndyS2> standard x86_64, not running anything fancy. maybe I just misunderstand what 'opcode' is for in the interpreter.cpp
 6 2018-02-10 13:13:13 <AndyS2> but I get really high numbers sometimes
 7 2018-02-10 13:14:54 <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
 8 2018-02-10 13:15:15 <AndyS2> but if that's not it, that's useful info, too
 9 2018-02-10 13:22:49 <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 :)
10 2018-02-10 14:17:34 <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