135800+ entries in 0.072s
mircea_popescu: but
this is why
this discussion was so important : it has in fact emerged
that
the correct implementation of diff would first a) calculate hash of all files in each dir ;
then b) process moves and only
then c) do
the diffing.
☟︎ phf: (that was by
the way how btcbase patcher worked for a long
time, until i had
to modify it because
there are placeholder items in bitcoin source code
that are at different filepaths)
phf: in
that case we should probably forbid hash identical files
to be in different paths
phf: so basically hash sums
trump namespacing always
mircea_popescu: also, if it dies a flaming death in
this case
that'd be very acceptable, and fuck you for keeping duplicates like
that.
mircea_popescu: this'd require all file movements
to be a separate patch, as you can't both move and edit in
the same go. which imo is bonus
the right
thing
phf: by your previous question you're saying
that diff is supposed
to say
that foo was moved
phf: say you have /a/foo and you have /a/bar/foo where both foo are identical. you're running diff -ruN a b, what is
the expected behavior?
mircea_popescu: if you have a : a/b a/c and b : b/b b/d/c it is
thereby evident upon diffing a and b
that c was moved from a/
to b/d/ if a/c contents === b/d/c contents.
phf: you can communicate
that information
through a patch format, but
that's not something ~diff~ can guess about
phf: diff can't know if
the newly appeared item
that's identical
to an item
that exists elsewhere in previous state has been moved
there from
the elsewhere or created in situ
mircea_popescu: "of course
the user knows
they're not in
the same dir duh" is no design logic.
mircea_popescu: when i say diff a/foo b/foo, diff fails
to output "one is in a,
the other in b" as
the first fucking item on its list of differences.
this is because
the (idiots)
that made diff
thought
they gain something by eliding "the
trivial case".
mircea_popescu: but you can know
that one foo is in a and
the other not
phf: if you do mkdir a;
touch foo;
touch a/foo; mv foo a/foo;
mircea_popescu: "the difference between a/fuckyoustallman.c and b/fuckyoustallman.c is 1)
that one's in a and
the other in b ; 2) no further"
phf: fwiw diff can't even know
that a file has been moved
mircea_popescu: phf sure, and subsistence hunting has
two
things
that it can do,
throw rock or jab spear.
this is in line with it being an occupation of idiots invented by idiotws.
phf: but
then
the question is what is
the responsibility of diff
trinque: problem stemming from
that unix uses file path as a matter of identity, and allows
this
to be mutable (!)
☟︎ phf: diff has
two
things
that it can signal: an addition of a line, and a deletion of a line, which is in line with what it claims
to diff, i.e. diffing of lines
mircea_popescu: ergo, BOTH
these operations have been edits of
the file.
mircea_popescu: if i edit glib.c and replace line 50 with "fuck you stallman", and
then
try
to compile glib.c, i get an error. if i edit glib.c and MOVE glib.c
to /fuck/you/stallman/glib.c, and
try
to compile glib.c, i get an error
phf: sure, but diff's way of indicating change is
to show what happened
to a file,
that is all
the lines of
the file got deleted
phf: well, moving of
the file is a filesystem operation, what does it have
to do with ~diffing~?
phf: diff/patch allows for absolute paths, we don't
them it
though
mircea_popescu: but whatever, in 1970 people couldn't afford disks with actual directory structure in
them
mircea_popescu: and a file's fucking name is its absolute path, not
the last bit
thereof.
mircea_popescu: a file is not "its contents and AN ARBITRARY
TRUNCATION OF ITS NAME"
mircea_popescu: the fact
that unix diff is directory blind is an idiocy larger
than commonly encountered in
that
thing's misdesign
phf: but anyway, i'm not convinced
that file management is a proper concern for diff. we could add it
to a diff format, by placing some instructions in
the prelude (which is normally ignored by unix patchers). rm src/foo.c, mv src/foo.c src/bar.c which can be used as instructions for reader with non compliant patchers, or parsed by
the vpatcher
to be executed.
this is all incredibly inband, but conforms
to
the medium
phf: btw one of
the reasons for dodgy delete function in
the diff is
that patches
theoretically a reversible, -'ing all
the lines of file can conversely be +'d back
phf: actually phf-shiva-swank is still broken in
the experimental patchset, because it was produced by vdiff/patch combination (vdiff made some claims of shasums, which patch didn't verify.
the fact
that i should've verified
the press is a different question)
mircea_popescu: you're absolutely right. patch process must be much looser
than
this.
phf: in
this case
the value of proper vpatch/vdiff is
that
they never produce fuzzy patches and always validate
the shasum for you, but
they don't do
the v-tronic management
phf: well,
this goes back
to
the
threads about whether or not it makes sense
to patch sigs on your workbench. i use patch in my workflow frequently outside of pressing a
tree
to bring
things from one state into another. i might have a dozen of unsigned patches,
that i'm working with
that won't see
the light of day
phf: i don't
think
that's a good idea, but i can't articulate an objection. vpatch now needs
to know about your wot and wot management, or else
the process of patching now becomes explicitly providing a pub key, a corresponding sig and a vpatch itself.
phf: or
the
thinking
that vdiff doesn't sig, but
then vpatch expects a sig never
the less?
phf: i
thought
that's what you were
talking about?
phf: from
that perspective both vdiff and vpatch ~could~ also produce a corresponding sig, in which case
the protocol is
that patch/diff produce an always valid vpatch (i.e. vpatch/sig combination)
mircea_popescu: can you imagine any other context besides pressing
this new diff/patch would be used in ?
phf: in my
thinking vtroner is a larger beast,
that's responsible for
the management of
the entire press chain. patch/diff are dealing with a specific problem of comparing
two states, producing a difference of
those
two
tays, and
then
taking a state into a next state according
to differences
mircea_popescu: in principle we could do incremental builds ; but only if
they can be cleanly upgraded later,
that's a major point.
phf: this
then is entirely unscoped
phf: mpi is a fraction of what gnupg is, are we
then moving away from pgp keys and signatures?
mircea_popescu: and why would diff/patch be outside of vtroner is
the larger design question
phf: chain validation needs
to only go as far as "does
the hash on
the file
that i'm about
to patch corresponds
to what i expect"
phf: well, signature validation is done by gnupg, i don't see any reason
to bring
that whole
thing in, and
there's very little reason
to system("gnupg ...")
phf: take existing stuff, strip it down
to just what we already have -ruN functionality. i
think
that
the actual
tools should be vdiff and vpatch,
that is
they do shasuming
themselves and produce proper vpatches/apply proper vpatches, but without chain or signature validation.
a111: Logged on 2017-12-10 21:23 nocko: I was linked
to FFA guide, started looking around and am now here. I cannot say
that I yet have half an idea what's going on... but hello.
a111: Logged on 2017-01-05 00:49 mircea_popescu: i do not wish
to live in a world where people can make patches consisting of 512kb lines of a
a111: Logged on 2017-01-03 21:14 mircea_popescu: v is really only as powerful as
the underlying differ is.
mircea_popescu: making your file comvertible
to old style patch
through a
truncation op.
mircea_popescu: can EVEN KEEP
the +++ --- style separators, but in
the DATA segment
mircea_popescu: you ~could have a diff format whereby first line is x y z with x =
total line count, y notation line count z data line count, and
then instead of +++ --- bs you just have line count references in
the notation part.
☟︎ mircea_popescu: maybe he bites
the bullet and makes special files. or who
the hell knows. i'm curious.
mircea_popescu: i'm letting him contribute, what. he understands what
the problems are.
mircea_popescu: kinda open matter yet ; but procedurally one
takes
the diff source code, genesises it, patches
the differences and produces a drop-in diff replacement.
a111: Logged on 2017-12-14 19:22 mircea_popescu:
that could've meant
tmsr-diff. what it means practically is
that
there's going
to be a "new" mpi in eucrypt,
textually identical
to
the genesis one ; and people will be re-reading and re-reading and RE-READING whole lots of
the same exact code as if new, resulting in a situation where instead of
the problem being pushed into "a filesystem hierarchy standard" it'll be pushed into a "code standard". which happens
to be exactly
mircea_popescu: in fact, i expect it will be
the MAJORITY of work for humans in
the future.
mircea_popescu: contrary
to naive intuition,
there is no damage in re-reading old code as if it were new.
mircea_popescu: over
time it'll actually get systematized, as in
the aaerne-thompson system for folk
takes, or as in
the
tmsr-diff here. but
that day is far into
teh future.
mircea_popescu: like how oral culture worked,
the concept of a
trope, as found in folk
tales, is really simply equivalent
to "and
this is how mpi goes, and
this is how bubblesort goes..." and so on.
mircea_popescu: that could've meant
tmsr-diff. what it means practically is
that
there's going
to be a "new" mpi in eucrypt,
textually identical
to
the genesis one ; and people will be re-reading and re-reading and RE-READING whole lots of
the same exact code as if new, resulting in a situation where instead of
the problem being pushed into "a filesystem hierarchy standard" it'll be pushed into a "code standard". which happens
to be exactly
☟︎ mircea_popescu: yes we don't have a gns yet, but
this doesn't excuse us from... doing
the same computations by hand as if we had it! it's not suddenly allowable
to go "well since i have no running water i
therefore do not wash". no bitch -- since you have no running water, you walk fifty miles uphil each way
to GET water in a bucket. still wash.
a111: Logged on 2017-12-14 16:13 phf: rs~ might a little bit more meaning out of
the press namespace. one pill
to satisfy later group of people would be
to come up with a filesystem hierarchy standard, i.e. you always press at
the same root, but you're pressing into a
tmsr namespace. so it'll be /bin/bitcoin/... /lib/mpi/...