billymg: !. version
bitbot: I am bot version 719639.
billymg: slow bot
billymg: !. uptime
bitbot: billymg: time since my last reconnect : 0d 0h 3m
billymg: ^ this bot is now the same version as the one on dulapnet, with the bot <> bot echoing suppressed, and the tweaked logline regex (for pestnet) set via a config knob
asciilifeform: billymg: neato!
shinohai[billymg]: \o/
billymg: test pg restart
billymg: neat
billymg: will put together the patches now, there's three: bot-recursion-fix, pg-auto-reconnect, minor-reader-tweaks
billymg: pressing really takes forever on large trees. iirc thing is O(n^2), right (or worse)? seem to recall something about bvt having a sped up version but not sure if he ever released it or what happened with it
signpost[asciilifeform]: iirc the thing's not parallel, is it?
signpost[asciilifeform|billymg]: oughta be trivially parallelizable
signpost[asciilifeform] has been using ramdisks on gigantic presses for max brrrr
billymg: signpost: yep, single threaded also
asciilifeform: vtronic sig verification obv. could be parallelized; errything else is inherently sequential tho
billymg: the single "not found in flow" error message is not helpful at all either, oughta be able to see where it choked and spit out something more meaningful
billymg: a few times was doing `./v.pl p v thepatch.vpatch` instead of `./v.pl p v press_dir thepatch.vpatch`
billymg: had to wait for the entire thing to finish only to see "not found in flow", then proceeded to double check hashes and sigs
billymg: that should be caught in the first nano second, "where's your press dir?"
billymg: signpost: regarding the ramdisks, if disk is one of the bottlenecks couldn't v.pl load all the patches into ram first, then do its thing?
billymg: asciilifeform: added the patches to my logotron vtree page (the last three)
billymg: will write up the post possibly later today or tomorrow
signpost[asciilifeform|billymg]: asciilifeform: I'd expect hashing also paralellizable, and why not pressing hunks as well?
signpost[asciilifeform]: a vpatch with two separate sequential edits to the same hunk seems pretty sinful.
signpost[asciilifeform|billymg]: in my mind one could scan through the vpatch, yield each patch-hunk-offset to a given worker thread, and worker thread hashes `before`, presses hunk, and hashes `after`.
signpost[asciilifeform]: if the alterations happen in a temporary copy of the files, you can preserve atomicity of successful presses
asciilifeform: signpost: asciilifeform never in worst nightmare imagined anyone doing GB+ vpatches, so did not consider
asciilifeform knows why signpost is doing it, but had to note.
asciilifeform to this day uses the lightly-modified for keccakism phf variant of own 'v.py', what w/ coupla dozen ln and 0 possiblity of threading bugs
asciilifeform: http://logs.bitdash.io/pest/2022-01-20#1002920 << ty! will look
bitbot: Logged on 2022-01-20 22:02:49 billymg: asciilifeform: added the patches to my logotron vtree page (the last three)
signpost[asciilifeform|billymg]: I'm gonna sign the horror even.
signpost[billymg]: but yes, all *subsequent* patches better damned be small.
signpost[asciilifeform|billymg] is doing the gruntwork to actually separate distinct software into distinct vpatches, and the musl-specific tweaks also into own patches.
signpost[asciilifeform]: this is what remains before a first release.
signpost[asciilifeform]: got dulap build going with that 2016 gnat btw. works great.
signpost[asciilifeform] will leave a disk installer for a subsequent patch, plan to port the cuntoo installer over.
asciilifeform: nifty
asciilifeform used that gnat, iirc, prior to ave1's thing