112700+ entries in 0.066s
a111: Logged on 2017-12-14 21:34 asciilifeform: whereas if you want
to be able
to compactly represent ~arbitrary
transforms of
text and of dirs, you end up with something like sed on
top of a...
text representation of a
tar ?
phf: mod6:
think plaintext
tar archive
that you stick inside a vpatch.
there's only ever ~one file~ in your
tree. for simplicity it's one large
trb.cpp
that compiles
to
the result. no other dependencies.
phf: this is so
trivial, and also inconsequential
that i apologize for burning s/r on it
phf: i.e.
trb.vpatch ->
trb.web -> foo.c, bar.c, qux.c
mod6: or am i still missing
this?
mircea_popescu: yeah but i suspect
that's a large part of why it went nowhere.
phf: yo, it's not a real solution,
the only reason i was
thinking about is because
that's how knuth's literate programming is done. i mean
the entirety of code is one file, you use project specific
tooling
to extract it.
mod6: <+phf> problem can also be solved with having entire project in one file, <<
to me, was
trying
to picture
trb one giant vpatch, over and over, may have misunderstood
mircea_popescu: phf i don't get it, why would we adapt
the way we do
things
to what'd be convenient for
the machines ?
phf: mod6: wait, what? from
the way vpatch looks perspective
there's literally no difference. you have one diff a/x b/x instead of many, but otherwise
the
thing looks identical.
mod6: vpatches were meant
to be digestable.
mircea_popescu: except first is practical nonsense, and second presumes
thingd about directories, which is untenable.
phf: problem can also be solved with having entire project in one file, or
trinque's approach os
tracking hash chains for
the entire directory (i.e.
treating
the whole press as a single file)
phf: with manifest we're basically saying "there's going
to be one file, which is going
to establish
the one
true chain, and all
these other files are just hanging by
the side"
phf: right, hence
the conversations about sexp v
phf: which we also had
thread about
phf: problem
that you run into is really granularity of files (of which we also had
thread), and
that perhaps having multi-file multi-anticedent vpatches is not
the correct
thing in genera
phf: asciilifeform: it very briefly worked with polarbeard's patches, but
that was around active reground
time, so
the result wasn't particularly interesting. but you could press
to experimental head with or without pb's additions, based on whether or not he was in your wot
mircea_popescu: it does, yes.
the old french word for it is agincourt.
mircea_popescu: the original "many keys" solution
to
that proved untenable.
phf: asciilifeform: come
to
think of it, initially you were
talking about using own wot
to cull
things, which makes no sense if you only have one
tree.
phf: asciilifeform: i didn't say barf, but if you were
to remove, say, makefiles, press
to malleus_mikehearnificarum, you lose mod6_der_high_low_s
mircea_popescu: rather,
there's a shared understanding
that's applied by degrees. because
the sty is so dirty you have
to peel layers off, as
the only possible approach.
mircea_popescu: can you
turn around and say, "fg
tree shows people didn't at
the
time understand v isn't married
to
the underlying format" or something ?
mircea_popescu: for
that matter, pre-solution
to binary issue, even fg
tree was sad.
mircea_popescu: in fact,
the only legacy pantsuit item almost-v-ified would be wp, and
that's STILL not done in spite of being
two degrees of magnitude simpler, because of all sorts of "holy shit, svg"
mircea_popescu: or possibly everyone regarded
trb as a messy pile which isn't properly v-ified even
today. like mpi, or like gentoo
phf: well, cutting "makefiles" from
trb and going up
the graph demonstrates many places where full press wouldn't happen with current behavior, but will still happen with
the "buggy" one. so either
there was a shared understanding
that has changed, or else people who claim
that
that was shared understanding haven't looked at
the
trb
tree at
the
time
to observe
the buggy behavior
themselves.
mircea_popescu: there's no dispute
that understanding of v has evolved ; but i don't happen
to see
the uncertainity.
phf: mircea_popescu: i don't agree
that
the "in
the sense" is correct.
trb patchset relied on pressing
the lateral
trees behavior up until recent nailing down of graph, which was a result of elaboration from clearer understanding. i
think
the understanding of v has evolved, and
things of which
there was much uncertainty and hand waving in
the past are now much more obvious. i don't
think it's
the case
that "the behavior was always
that way" in an accidental
mircea_popescu: with
this mechanism no actual changes
to v need
to be made, it's a "soft fork" as it were.
mircea_popescu: ly not modify previous lines, but
this is
to be enforced by public arbiter, ie, sometimes it will make sense
to.
mircea_popescu: anyway,
the seemingly correct solution is for convention
to be changed, so
that 1. genesis author creates a comments.txt file or else it's not a proper genesis ; 2. all subsequent patches MUST include an edit
to
the comments.txt file of
the codebase
they are pressed upon, which 3. must consist of adding one line at
the end consisting of whatever
text
the patch author deems useful
to add and may not be null and 4. should ideal
mimisbrunnr: Logged on 2018-03-30 22:15 phf:
trinque: i'm describing how
things are right now, how
things were, and what informs my and mod6 opinions on
the subject. uncertainty about past behaviors in my opinion
tends
to influence uncertainty about future solutions
mircea_popescu: but in
the general approach
to
the problem, 1. all specification will sort items into "always" "sometimes : as per conditions" "never" and categories ; and 2. all refinement of specification will move items, but ONLY from
the left
to
the right and not
the other way around.
mimisbrunnr: Logged on 2018-03-30 22:13 phf:
trinque:
there's no "returning
to", original behavior is "press everything
that falls from under
this head"
phf: hmm, manifest's hash
though solves
the same problem, we're essentially driving
the graph by manifest hash chain, and
the other files in patch are for additional culling
phf: e.g.
the patch itself starts with mandatory parent: <hash>/false.
this
though completely eliminates
the complicated graph
transition machinery. all patches are hashed blobs,
that you can point
to by its hash
phf: if we're
trying
to nail down antecedents, why not put parent hash into vpatch prelude. i.e. "this vpatch can only happen after a vpatch with
the given hash has been applied"
trinque: using it as an exercise
to sign all
the patches I haven't,
too.
mircea_popescu: ie, "your patch must do
two
things
to count : build off a valid
tree state ; and explain itself in plaintext in
the comments file for
the project"
mircea_popescu: trinque seems
the logical place
this is going is "make comments file addition mandatory for each patch"
trinque: yeah,
the hash idea was bunk.
phf: i suspect something like ebuild situation requires a non-trivial vpatch management: each port is its own genesis
tree and portage system keeps
track of head's.
this way extending port's
tree allows ongoing development, but
trinque's role is
to update portage's pointers periodically.
this way a press from head must ignore lateral leaves, etc.
mircea_popescu: asciilifeform note
that
this hash is not opposable
to anything. you can hash
the system
time for all
the difference it makes.
phf: ultimately it doesn't matter what's inside manifest, as long as its hash is unique, e.g. it's append only log
that requires >1 byte of change in each vpatch
trinque: asciilifeform: sure, and it's nice
that
this ends up
there in plaintext
to be read, rather
than blobs in a git black box
mircea_popescu: i expanded on
that
to allow comments in
the manifest, in
the spirit of literate (
mircea_popescu: the
trinque original (which im
too lazy
to dig out atm) was "concatenate your whole codebase, hash it, add
the resut on a new line of manifest.txt" pretty much.
mod6: ok, so
that would solve some of
the 'hairyness'. a
True Vpatch ~MUST~ edit chronicle.txt.
trinque: I don't have a pet proposal
to solve it, but it's definitely never getting solved without more eyes on
that
the problem exists
phf: like i said, i understand
the problem, i'm not sure of
the solution, because ~i~ have not attempted
to
tackle it. for example i suspect
that
the manifest might be problem specific, i.e. what you put
there is informed by
the shape of
the
tree you're
trying
to create.
trinque: aside
the
two above, what's been done in
trb is
to include 1 and 2 in patch 3;
the bulk of
the patch is lifted into
the
thing
trinque: so what of
that situation?
phf: mod6:
there's
that
too :)
mod6: oh, and it just dawned on me how it would be np-hard
to walk it backwards.
phf: trinque: i'm describing how
things are right now, how
things were, and what informs my and mod6 opinions on
the subject. uncertainty about past behaviors in my opinion
tends
to influence uncertainty about future solutions
trinque: phf:
there are cases where
two separate edits
to separate files are both needed as antecedents
to yet a 3rd patch, which edits possibly neither of
them.
trinque: then perhaps I'm wrong. I'm
trying
to present a problem
to you by way of examples and it's not
taking.
a111: Logged on 2018-03-30 22:09 mod6: was
thinking,
that if we changed up
the parameterization of v, could maybe resolve
the multiple leaves
thing. imagine
http://www.mod6.net/sps2_dag.png without
the 'j.vpathch', if one wanted
to press both
trees, maybe could
tell v
to : `./v.pl p v outputdir i.vpatch d.vpatch`
phf: trinque: didn't you accuse me of projecting before, ~where did i refuse
to acknowledge
this problem~
trinque: why are you refusing
to acknowledge
this problem?
phf: trinque:
there's no "returning
to", original behavior is "press everything
that falls from under
this head"
trinque: if returning
to "press everything, don't specify HEAD" I don't see
that
there can be multiple lines of history (branches)