phf: i also have another approach, with V_PATCHES=[('http://.../foo.vpatch', 'http://.../foo.vpatch.first.sig', 'http://.../foo.vpatch.another.sig'),...] where ebuild basically keeps explicit press order, but can also rely on emerge for pulling the files from remote. none of it is particularly satisfying

phf: asciilifeform: i don't think so either, but it's a question of what's the format of vpatch. if the a/foo b/foo is mandatory or if you e.g. can have v2/foo v3/foo. right now the answer is "don't do it that way", which is fine, but it's cheap to talk through that stuff.

phf: and then vdiff v1 will give you a/foo b/foo genesis

phf: asciilifeform: right, that's possibly something to make mandatory then, that is a diff of any two directories produces a a/... b/... patch. so that you can have v1/foo v2/foo v3/foo and vdiff v2 v3 produces a/foo b/foo

phf: err vdiff foo where inside foo you have multiple folders. it's tied to whether or not those parent folders a and b should be implicit, and if vdiff should do the right thing in that case, or keep it all explicit and require the creation of a and b top level folders always.

phf: or perhaps vdiff foo/{bar,buz}/... should be producing /a/foo/bar/... /b/foo/bar/... and /a/foo/buz/... /b/foo/buz/...

phf: but to your point specifically, i was thinking that if you provide only one argument, right now vdiff errors out, so i think it would be better if it produced genesis. e.g. vdiff foo could produce a a/foo/* false b/foo/* 123 vpatch

phf: vpatch is picky about what it accepts, it's basically only a/foo/* b/foo/*, where's vdiff can accept a totally random stuff like /foo/bar/qux diffed against /dev/null or whatever. right now even diffing two straight files e.g. vdiff x y will produce a non-pressable vpatch. this is all not so much a bug as an unexplored aspect of vdiffing which is also part of the whole rename tracking. ☟︎

phf: well, no, colorize, when it does its colorizing, has to know a bit about identifiers and tokens and such. so hooking in this case involves getting some information from colorize that says "i got an identifier FOO, give me back a link to where it should link"

phf: asciilifeform: i have a ksum PoC for you, http://btcbase.org/patches/vtools_ksum signed but it's from workbench, potentially buggy. "ksum foo bar qux" gives you shasum style <hash> foo\n<hash> bar\n<hash> qux\n

phf: you can basically do (cat foo.vpatch bar.vpatch qux.vpatch) | vpatch and expect the resulting press to be fully valid, hashes and all ☟︎

phf: asciilifeform: please to clarify, do you mean that you can say run "./vpatch < foo" and if that fails you run it as "./vpatch -t sha < foo". or are you saying "./vpatch < foo" and it attempts to, internally, first keccak then sha?

phf: well, 100 ln patch to the compiler, because it can't be done as a user proggy (e.g. (symbol-value 'foo) triggers a mechanism of some sort, without an indirection)

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: gentoo out of the box turned out to have all kinds of interesting surprises (i haven't ran gentoo in years, so it was interesting to see the holes through which the darkness comes). like the foo-9999999.ebuilds that just pull from the mystery github repos without any kind of checksumming ☟︎

phf: ccl has a fancy system, based on hacked up gcc, for generating ffi mappings (called interfaces), which you then can use with (use-interface-dir :foo) (#_foobar ...)

phf: i've skimmed it when it came out and i agree with your feedback. primarily making it self contained, i.e. getting rid of cl-ppcre for parsing (!!1) and needless dependencies like uiop by way of classical (defun run-program (foo bar) #+sbcl (sb-ext:...) #+ccl (ccl:...) #-(or ccl sbcl) (error ...))

phf: http://btcbase.org/log/2018-04-27#1805906 << asdf3 is pretty much standard in all the lisps right now, you have to go out of the way to downgrade. at the very least avoid implicit uiop dependency and declare it in your asdf file (this is by the way even fare's recommendation, but people ignore it "oh i have asdf3, means i can just throw a sneak uiop:foo all over my code) ☝︎

phf: perhaps try select * from moduli left outer join (select distinct unnest(mods) as mod from factors) as foo on moduli.idx = foo.mod where foo.mod is null

phf: with foo as (select distinct unnest(mods) as mod from factors) select * from moduli left outer join foo on moduli.idx = foo.mod where foo.mod is null;

phf: mircea_popescu: maybe try this with foo as (select distinct unnest(mods) as mod from factors) select * from moduli left outer join foo on module.idx = foo.mod where foo.mod is null;

phf: but right now it's very easy to add foo:... clause. the complete set of these is from:, notfrom:, refs: (specific number of references that the post has), and not:

phf: mircea_popescu: notfrom, and it's not proper grammar. the whole thing is an AND, and the foo:... commands are constraints. so not is more properly should be called something like "filter:"

phf: i.e. trb.vpatch -> trb.web -> foo.c, bar.c, qux.c

phf: this gnulib solution actually wants you to define FOO_INLINE, which is set to "inline" when defined, and "extern inline" when used, so you can't even avoid the #define hackery with "extern inline". "Other non-C99 compilers use static inline so they suffer from code bloat, but they are not mainline platforms and will die out eventually." ☟︎

phf: http://btcbase.org/log/2018-02-23#1785630 << so offending attribute is _Noreturn, which is a c11 feature that was only introduced in 4.7. but! i tested with 4.6.4 on freebsd before release, i now also compiled 4.4.3 and it still works. running cpp-4.4 on the file it looks like something in freebsd headers actually replaces _Noreturn with an __attribute__ call that older gcc's support. with a test file with `void _Noreturn foo() {...}' but without any includes, ☝︎

phf: asciilifeform: they have a stupid gb style scheme of *.foo.uy