| 16:58 |
billymg |
!. version |
| 16:58 |
bitbot |
I am bot version 719639. |
| 16:58 |
billymg |
slow bot |
| 16:58 |
billymg |
!. uptime |
| 16:58 |
bitbot |
billymg: time since my last reconnect : 0d 0h 3m |
| 17:00 |
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 |
| 17:13 |
asciilifeform |
billymg: neato! |
| 17:19 |
shinohai |
\o/ |
| |
~ 2 hours 33 minutes ~ |
| 19:53 |
billymg |
test pg restart |
| 19:53 |
billymg |
neat |
| 19:54 |
billymg |
will put together the patches now, there's three: bot-recursion-fix, pg-auto-reconnect, minor-reader-tweaks |
| |
~ 50 minutes ~ |
| 20:44 |
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 |
| 20:48 |
signpost |
iirc the thing's not parallel, is it? |
| 20:48 |
signpost |
oughta be trivially parallelizable |
| 20:48 |
* |
signpost has been using ramdisks on gigantic presses for max brrrr |
| |
~ 36 minutes ~ |
| 21:25 |
billymg |
signpost: yep, single threaded also |
| 21:27 |
asciilifeform |
vtronic sig verification obv. could be parallelized; errything else is inherently sequential tho |
| 21:27 |
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 |
| 21:28 |
billymg |
a few times was doing `./v.pl p v thepatch.vpatch` instead of `./v.pl p v press_dir thepatch.vpatch` |
| 21:29 |
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 |
| 21:30 |
billymg |
that should be caught in the first nano second, "where's your press dir?" |
| |
~ 19 minutes ~ |
| 21:49 |
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? |
| 22:02 |
billymg |
asciilifeform: added the patches to my logotron vtree page (the last three) |
| |
↖ |
| 22:03 |
billymg |
will write up the post possibly later today or tomorrow |
| 22:06 |
signpost |
asciilifeform: I'd expect hashing also paralellizable, and why not pressing hunks as well? |
| 22:07 |
signpost |
a vpatch with two separate sequential edits to the same hunk seems pretty sinful. |
| 22:09 |
signpost |
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`. |
| 22:10 |
signpost |
if the alterations happen in a temporary copy of the files, you can preserve atomicity of successful presses |
| |
~ 46 minutes ~ |
| 22:57 |
asciilifeform |
signpost: asciilifeform never in worst nightmare imagined anyone doing GB+ vpatches, so did not consider |
| 22:58 |
* |
asciilifeform knows why signpost is doing it, but had to note. |
| 23:02 |
* |
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 |
| 23:03 |
asciilifeform |
http://logs.bitdash.io/pest/2022-01-20#1002920 << ty! will look |
| 23:03 |
bitbot |
Logged on 2022-01-20 22:02:49 billymg: asciilifeform: added the patches to my logotron vtree page (the last three) |