feedbot: http://trilema.com/2020/augmentum-gratiae/ << Trilema -- Augmentum gratiae
diana_coman: jfw - I had a go today at installing the whole gbw orchestra: on the positive side, it's apparently doable in less than a day (at least when having already in place a trb-compat node (for the online part), a gales install (for the offline part) and otherwise the whole pile of vpatches and the sources for all the stuff to add to a basic gales install); on the questions side - the check of gscm
diana_coman: turned out 4 fails - are these known or what do I have wrong in there?
jfw: diana_coman: heh, I suppose less than a day is a start at least.
diana_coman: as additional observations: building and installing the whole pile of gports that were in fact required when starting with the most basic gales was indeed quite tedious
jfw: yes the test failures are known (noted in package/README, iirc)
diana_coman: for that matter hm, my very basic install seems to have been more basic than dorion's or something.
jfw: and yes the not-quite-a-portage is... not-quite-usable :/
diana_coman: jfw - I was getting to the part of "less than a day is a start" indeed - it might be just me, but I finally managed to use that watch command of the gbw-node only after I ...read the code for it specifically, lol
jfw: re dorion's: yeah looks like there are autoconfs and the like not pictured
diana_coman: re time though do note that I'm not that much used to gales and even less to the 2 new types of install (the gports + the /package etc); not that they are extremely complicated as such, either of them, but I was surely not terribly fast (and yeah, I found ways to mess it up, ofc, though through my mistake)
jfw: re "watch", was the "help" hard to find, or not helpful enough or something else? I see it is pretty terse.
diana_coman: jfw - help was easy to find; I even had the examples from both dorion and whaack; but me being me, if it said "list of addresses", I took it for instance first to mean that I can therefore go watch tag1 addr1 tag2 addr2 (with enter,s ure)
diana_coman: then the more confusing thing was that watch tag addr [enter] addr2 actually imported correctly the first and crashed on the second for maximum puzzlement (until I read the code so I saw it wanted tag [enter] addr1 [enter] addr2
diana_coman: ah, I even got a case where it didn't crash but didn't add anything either, lol
jfw: possibly missing an error check for excess CLI arguments; but yeah the tag is CLI arg while list of addresses is stdin.
jfw: "linewise" could certainly be expanded in the help; thanks for noting the trouble.
diana_coman: jfw - since atm the online part is still busy scanning so I won't poke it just yet, might as well ask first - if I add another address to watched list and I know already that it doesn't appear until block Y - can I set it to scan from there or is it just full reset?
jfw: revisiting http://ossasepia.com/2020/07/01/ossasepia-logs-for-Jul-2020/#1027989 - I still see it as more general: it's adding to the v.pl tree the capability to fetch a complete set of patches from a given publisher, using a more streamlined scheme than mod6 had included. Indeed I'd be the only one publishing in that format at the start, but nothing says it has to stay that way.
sonofawitch: 2020-07-17 21:35:45 (#ossasepia) diana_coman: jfw - so it's basically jfwsoftware-starter, pretty much.
jfw: diana_coman: there's no easy command to scan from arbitrary height but setting the scan_height in the state table will do it.
diana_coman: jfw - my understanding was that you were planning to add not only the capability but the hardcoded publisher=jfw since keys etc; ie adding the capability to my mind does not include specific keys of anyone.
diana_coman: ah, setting in the table is good enough for sure.
jfw: diana_coman: I see what you mean about the keys.
jfw: so the change to the v.pl tree is general but the starter would be indeed be optimized for my stuff albeit re-targetable.
diana_coman: so it sounds like a .vpatch that adds the capability itself and thus perfectly fine in the tree and otherwise a starter pack that is optimised for your use.
jfw: exactly
diana_coman: no problem that I can see there at all.
jfw: cool, ty.
diana_coman: and speaking of seeing problems - while the PORTS doc for gales was basically salvation itself, it was still an initially confusing salvation, lol
jfw: haha
diana_coman: that /var/build/gales-linux as "REPO" and then to expect REPO/gports ahem; specifically: I had /gales/gports
diana_coman: and the sources as a tar separately so I was looking where to plonk those
diana_coman: so reading that made me think they should be in /var/build/gales-linux but then...what gports there?
diana_coman: to solve this for the logs: the sources in fact go into /gales/dist/src
jfw: hm, I used to think of the gports tree as a separate thing like the portage tree; then decided it's simply a part of the larger gales tree (i.e. including the bootstrap stuff) hence REPO/gports. Perhaps instructions got crossed somewhere
diana_coman: the gports are in /gales/gports
diana_coman: one can of course create wherever any dir and link that to those but yeah, it's not src/gports
diana_coman: jfw - yeah, it read a bit like that ie something left from older/changed stuff
jfw: there isn't presently any assumption about the gports path: builds are done relative to working directory. might need to add one if another level of automation is added though, so in that case yes /gales/gports (or symlink from there) it is
jfw: not mentioning the /gales/dist/src tarball-hopper in PORTS is indeed an omission.
jfw: it's the equiv. of /usr/portage/distfiles.
diana_coman: well, if it's any consolation, there were way, way funnier things to notice in the output of compiling stuff like perl and python
jfw: I bet.
jfw: Off to unwrap what I expect is my shiny new APU1 - aka "only x86 computer still on the market not known to be evil" or thereabouts
feedbot: http://ztkfg.com/2020/07/block-explorer-progress-whats-done-whats-next/ << whaack -- Block Explorer Progress - What's Done, What's Next
whaack: jfw: Is there any reference (other than the trb codebase) that specifies the encoding for all the various data structures used to store a block and its transaction? The bitcoin wiki is closed to what I'm looking for https://en.bitcoin.it/wiki/Block_hashing_algorithm, with the field / size in bytes column, but I would like a full list that actually contained the type in addition to the byte size
whaack: (i.e. big endian int, little endian uint)
jfw: whaack: if you're looking for an authoritative reference that specifies things, then no, "the code is the spec" unfortunately. Secondary sources may still be helpful for introduction or quick reference although I've found the wiki to be of mixed (mostly poor) quality.
jfw: I did however freeze a copy of it.
jfw: https://developer.bitcoin.org/reference/ purports to descend from documents I once found helpful.
jfw: possibly the gbw-node block/tx unpacking code? which itself cites trb source files
jfw: http://fixpoint.welshcomputing.com/2019/draft-gbw-node-frontend-part-1/?b=Bitcoin%20data&e=parsing#select
jfw: on endianness specifically, most everything is implicitly little-endian because Satoshi was in the Wintel bubble.
whaack: jfw: Alright, yes the gbw-node unpack code is the best reference I have for the moment but i'm looking for the way the extraneous fields (sequence number, version number) are stored. Arguably since they have no use their encoding is insignificant.
jfw: whaack: from http://btcbase.org/patches/asciilifeform_aggressive_pushgetblocks/tree/bitcoin/src/main.h#L272 we see that nSequence is handled in the "usual" way. http://btcbase.org/patches/asciilifeform_aggressive_pushgetblocks/tree/bitcoin/src/serialize.h#L123 is the heart of the macro/template serialization monstrosity, wherein we see that basic types are simply done as a memory dump; from the
jfw: context we then infer that an unsigned int is 32-bit little endian.