phf: i'm unconvinced there can be such a thing as hygienic latex, possibly there can be ghostscript if you pull out the pdf support (?) ☟︎

phf: i think we might've discussed how all these utility libraries (particularly freedesktop ones) are the holes through which the darkness comes. poppler is one of them, a fork of venerable xpdf it is now everywhere where pdf manipulation is done, naturally with no way to turn of said manipulation when need be

phf: http://btcbase.org/log/2018-07-11#1833362 << oh i see, your flow command outputs an impossible ordering, but press-path gives a correct press order, so i was wrong, sorry about the fud ☝︎

phf: BingoBoingo: i think it's about the right mindset though, can have all the tools in the world, and you're still going to look like a jerk off. nah, i think i just need to get my head game straight

phf: asciilifeform: have you been using yours extensively, i.e. as a booted device, running linux etc. on a day to day, or it's only been on trepanation table so far?

phf: sad, i was warming up to it as a note taking tool..

phf: tried to turn it on right now, the lightbulb blinking rapidly and there's like a "turn on suddenly turn off" whine from board if you listen up close

phf: hmm, cp101pa hardware is really flaky, or perhaps i got a dud unit, because the "random shutdowns" "can't wake up" "stuck in a turn on/turn off mode" issues persist ☟︎

phf: btcbase (being a sprawling common lisp beast) has one of the possible solutions actually implemented and working. i'm wrestling the essence of it out, enough to add some kind of graph sorter to vtools

phf: originally my replacement was for diffing and patching exclusively, not the graph resolution problems. i was tasked with a replacement around the time when my food work got heavy, and i'm only now revisiting it. the problem wasn't even verbalized until closer the the end of vtools development, because particular choice of vtools delivery demonstrated the problem to begin with

phf: well, i'm having hard time thinking about it, yet alone articulating it. like i told ascii (before we continued talking about it anyway), i need some time to reupload the problem, because i haven't thought about it in a while.

phf: mircea_popescu: the problem i describe exists in every single V implementation, hence none of them can press a particular graph

phf: actually, i think i have a memory of that, and no btcbase is entirely hash first

phf: i don't know what a by file processor is

phf: mircea_popescu: i didn't say more than one vpatch are identical, i said that they shouldn't contain identical changes. a single vpatch can contain changes for several files. if two vpatches have a same subset of changes to individual files you have a problem.

phf: (btcbase doesn't choke on circular graphs, though in a general case it bails. if the circle is in the descendants order is determined by walk's order of entry, a circle back to genesis though can still be broken by explicitly designated something as "genesis", etc.)

phf: well, i kind of dig the emergent v graph behaviors, so i don't mind it either way, though btcbase doesn't press cleanly either (^ "all extant V's"). nothing keeping one from tacking on additional state to a crystalized vpatch either, and then you're stuck with another "though shall not, because reasons"

phf: yeah, obviously total state eliminates all the "multiple state transitions in a single vpatch" related problems

phf: manifest doesn't solve this problem, because manifest doesn't get any kind of priority treatment. if you hinged your press purely on a manifest descendent/antecedent chain then everything else will just work™

phf: if you want to reduce the problem to a "don't do this" policy, then it stems from repeated hunks across multiple vpatches, i.e. if you have two or more vpatches that have identical state transitions. something like that is bound to happen when you're attempting to port a feature between branches, as is the case with vtools. (i.e. you patched foo.c in one file "remove broken behavior", you now want to also introduce same fix to the other branch)

phf: in order to produce a graph there's a walk to root phase, the walk keeps track of press state at each node and dismisses connections edges that result in an invalid state. now WHY this is needed is because each individual vpatch doesn't keep track of the entire state, but only about its particular subset of state that changed.

phf: ah see the graph is misleading, because btcbase base grapher culls it. we've ran into similar issue back in the heavy experimental trb days, so one of the very first things that the btcbase distinguished itself on is producing a graph of possible presses, rather than pure antecedent/descendent. this was discussed and documented in the logs, in before "why you do that!1"

phf: there is a manifest in this version of vtools

phf: asciilifeform: nope, another form that as of now doesn't have a name

phf: let me retest it, but as far as i recall it was producing a patch order that doesn't press

phf: like i said couple of days ago i'm going to forward merge that whole right side, right now the only advise is to delete the right hand side because none of the extant V's can resolve that graph, obviously a suboptimal suggestion. i'm working on a better grapher, but until then.. ☟︎