112800+ entries in 0.063s
trinque: with present V behavior, some file has
to always be present as an antecedent for any coherent line of history (there could be many)
trinque will go ahead and
try
to delineate clearly
trinque: phf: where are you at on
the practical problem of "trinque wants
to redo portage in V" and I don't want people giving me patches
that include unrelated ebuilds?
phf: yeah, you guys "bugginess",
this is
the fundamental property of how v was described and how it was implemented
mod6: it used
to be in my V 99994 i would just blindly press all of
the leaves, but
that's was rejected as not
the right
thing. but with
the good changes
that 99993 brings in, could let
the user choose at press
time. just food for
thought.
phf: trinque:
that was
the behavior of v all along!
trinque: the designated head matters along
the walk of one path, but
then you get all of adjacent ones?
trinque: hm. I'd have
to ponder a while
to see what's lost. it's unclear what
the purpose of designating a press head would be in
that scenario
phf: originally
this was \supposed
to be solved by curated wot, i.e. all in-wot-dangling leaves
that can be applied
to current press, by hash, would get pressed
mod6: what if ole mod6 put in a special flag for
that "gimme-all-leaves" instead of
the listing of all?
mod6: you're saying if
there are 69 leaves, and you want
them all,
then you have
to list
them all?
trinque: would have
to name every patch
that happened
to end up a dangling leaf
mod6: and if not,
then user just selects one leaf, as is
today. i dunno, would need some
thought. i may be missing
the mark here
too.
mod6: then would press both
trees
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`
☟︎ mod6: i've been
thinking about
the manifest
thing for a while... and I'm not sure about it... seems like it'd get hairy. and would require versioning in and of itself. however, if we had a sample
to look at, might be easier for me
to grok.
phf: though a manifest could be used as a kind of assert during press, as long as it doesn't rely on filenames. (i believe
the idea of putting antecedent vpatch's hashes into manifest floated around)
mod6: I do have seals for
these signed with my vpatch-testing key... but you can just sign
them with your junk key if you wanna play around
phf: mod6: would you mind uploading
that
test
tree somewhere? i want
to
throw it at btcbase. fwiw, vpatch/vdiff doesn't care about press
tree, as long as
the hashes work out in
the end
mod6: Think I mis-typed
the above
too: *like no pressing of descendants if all antecedents are ~NOT~ present in
the current
tree*
mod6: files are in
the second link above if curious
mod6: Became necessary when
testing for
things like multiple roots, mulitple leaves; and have automation
to break
the
tree into parts so I can ensure of other
things, like no pressing of descendants if all antecedents are present in
the current
tree.
mod6: Can do
this if needed, didn't
take long.
mod6: I made a
test vpatch set for v related development. Super helpful. Allows me
to create
test scenarios and automate
them, ensuring
that I'm not regressing from version
to version.
a111: Logged on 2018-03-30 20:47 phf:
the retrospectively unpleasant part of
this approach is patching vdiff's C, which, after writing a bunch of Ada, is
torture. i believe diana_coman had similar experience
mircea_popescu: exactly how she ended up chained
to a
tree in
the swamp, also.
phf: but i don't
think i could've implemented ~patch equivalent~ differ in reasonable
time. vpatch already ballooned out because of an unfamiliar development environment, and it's much less heuristic based.
phf: the retrospectively unpleasant part of
this approach is patching vdiff's C, which, after writing a bunch of Ada, is
torture. i believe diana_coman had similar experience
☟︎ mod6: then
the new vpatches
to clobber
the
targets can be patched in, one at a
time. making
test cases for each, simpler, and probalby more effective.
mod6: fwiw, I
think minus other
targets, such as
the empty dir
thing, it's probably going
to be easier
to regresion
test without changes for
those
targets -- basically having a 1:1 mapping of
the old
to new.
mircea_popescu: and none of
the
three is
the "wrong" answer ; just,
they lead down different paths and gotta pick something
to
talk about.
mircea_popescu: i have no issue with it, can be added now without any serious loss.
the only
thing not clear
to me is whether you don't want
to add it, can't add it yet or haven't gotten around
to adding it yet.
phf: i grok
that point;
the
things are simply not
there. i've barely arrived
to where i have a working replacement for what we already have on
top of which further work can be built. i guess
the only reason
this one is contentious is because it would've worked better if done upfront.
mircea_popescu: the reason
the list of firm
targets doesn't include
the soft "well, i'm curious what he does about X" is precisely because... how hard am i gonna push it ?
that's kinda
the constraint, on one hand death by vagueness & ambiguity, on
the other death by insufferable overbearingness.
mod6: <+mircea_popescu> "qntra : under
the deluge of
tit bits, website-exchanges btc price keeps falling" lmao << :D
mircea_popescu: phf i'm not saying you're
the badman, or
that it was necessarily plainly communicated. but, for what it's worth,
that's what it was
there.
phf: i'm not even
through
the list of
target items yet, any one of
them can be picked up as an example of "didn't bother
to implement any solution for"
a111: Logged on 2017-12-14 22:49 mircea_popescu: phf so basically
this is cropping down nicely after all. proper vpatch (fixing mod6 's bane,
the empty dir
thing) + proper vdiff (hash-based preprocessing of rename/move + proper use of @@...@@ + keccak hashing).
phf: mircea_popescu:
the conversation from which you quote
the money shot happens in
the context of file renames,
the part where you call upon me quotes keccak specifically, elsewhere you re-enumerate
the list of what looks like
target items,
http://btcbase.org/log/2017-12-14#1751799 ☝︎ mimisbrunnr: Logged on 2018-03-30 18:36 mircea_popescu: reason i even did
things in
this manner is because it's not clear
to me why it was contentious or whether
the contention was resolved.
mircea_popescu: now, from
the evaluation late march, it seems
to me i was correct in
thinking back mid dec
that you understood what
the problems are, but
that you didn't bother
to implement any solution for one of
them ? or what am i missing ?
mircea_popescu: Dec 14 14:07:00 <mircea_popescu> maybe he bites
the bullet and makes special files. or who
the hell knows. i'm curious.
mircea_popescu: Dec 14 14:06:42 <mircea_popescu> i'm letting him contribute, what. he understands what
the problems are.
mimisbrunnr: Logged on 2017-12-06 22:38 mircea_popescu: if we start fucking with vdiff,
this is
the first mover.
mircea_popescu: um. no, i said as much months ago, dja want me
to dig
the log ?
phf: mircea_popescu: right, around
the
time when you made
that mothballed comment did i get cued into
the idea
that you wanted me
to implement it.
mircea_popescu: terrible idea
to do it on
trb. no, you want
to do it on something small and simple, speciifcallty because "it's not hard
to regrind existing
tree"
mircea_popescu: well,
the vdiff new
tree was originally
the most promising point for such a sample. i did say something in
the vein of "i'm not going
to keep
trinque mothballed forever if you don't do it" recently, but anyways.
phf: this doesn't require a new codebase,
trb is
there, can be reground
phf: i don't understand
the solution. i've spent significant amount of
time writing various graph walking algorithms
to feel like without an set of experimental patches it's hard
to have a solution
that actual address
the underlying complexity. what i wanted
to see from
trinque or whoever's attempting
to solve
this problem, is an actual attempt
to construct a press
tree with a manifest file
that does what
they want,
to ensure
that
the approach actual solves
mircea_popescu: so
then you understand
trinque's problem and
trinque's idea ; or just
the problem but not
the idea or what was it ?
phf: "it's for
the reader" meaning
that you clarification is for
the log reader
mircea_popescu: but "it's for
the reader" is a very weak answer, because if patch 3
touching a and b is written so as
to include patch 2, whereas patch 3`
touching a alone is written so as not
to include patch 2, "the reader" will have a most
terrible
time deciding which
to use and why
the fuck his build don't work.
phf: but spyked might also be running into a lateral issue,
that's related
to double presses. in any case ~i~ need
to look at it first before i have understanding of it.
phf: i'm saying
that i understand
the meta problem, because i've seen other people deal with it, and
there's been a lot of competing proposals as
to how
to solve it, including
trb's "makefile" approach.
phf: well, presumably
that's for
the reader.
phf: (there's another problem in my
tree specifically, of double presses. you have
to have
two separate patches for both
trees)
mircea_popescu: should he spyked make a patch 2, which changes file b, is
that patch 2 off G or off patch 1 ?
mircea_popescu: you, phf, made genesis G, with files a, b, c. you
then made patch 1, which changes file a.
mircea_popescu: let me state it canonically
then,
to guide
the looking :
phf: i'm not sure if his analysis of
the problem is correct without looking at it myself first
mircea_popescu: his patch is a loose leaf, because it doesn't
touch any of
the files ?
phf: mircea_popescu: i've seen
that problem before, but i haven't
tried solving it myself yet, because i've not ran into it. i've not had a chance
to attempt spyke's problem/solution yet
mimisbrunnr: Logged on 2018-03-29 15:00 spyked:
the way I understood it from reading v.pl,
the edges in
teh graph are established based on changes introduced by each hunk in
the nodes (the patches). so since
there are no patches changing
the files in vdiff_lib_xalloc_static_xnmalloc.vpatch, it's a leaf (and
this, if I understand correctly, is intrinsic
to
the current design of v).
mircea_popescu: phf do you see
the problem spyked's patch
to your v
tree encountered ?
mircea_popescu: reason i even did
things in
this manner is because it's not clear
to me why it was contentious or whether
the contention was resolved.
mircea_popescu: it's not supposed
to look like anything, nor is it supposed. it flows from a necessity, what.
mircea_popescu: phf
that's
the whole fucking point, implement his idea, having only "vague" understanding of how it's ~supposed~
to look.
then he can comment on it.
trinque: maybe selectively because experimental patches might avoid
touching
the history file until
they graduate
trinque: can compare
to
the actual flow you got out of
the patches and wtf loudly if
they mismatch
phf: trinque: can you produce a sample
then? i don't want
to implement your idea, having only vague understanding of how it's supposed
to look.
there's been many discussions in
the log as
to what
the actual manifest contents should include
trinque: not like I'd have been opposed; it's just easy
to imagine what it'd look like. every patch has an antecedent of
the history file, as well as whichever other files.
mimisbrunnr: Logged on 2018-03-29 14:53 mircea_popescu: is
this deliberate or oversight phf ?
phf: a as
to what format
the manifest supposed
to be. i didn't realize
that
the idea is
that vtools
tree was supposed
to be
the first one
to experiment with it
phf:
http://btcbase.org/log/2018-03-30#1791280 << it's an oversight. i
thought
that
the idea is
that my vdiff/vpatch support programmatically whatever manifest format we come up with, but somebody demonstrates how it's supposed
to work first. it's not hard
to regrind existing
tree, manually add a manifest, and
then see how it looks on a graph. for some reason i
thought
that
trinque has
that experiment in his pipeline, since he also seems
to have a clear ide
☝︎ mircea_popescu: what's in a year. people who "become president" on stanford's list usually
take 3-5 decades.
mircea_popescu: i wonder which one of
these identitties will pop up later doing anything worth
the mention.
mircea_popescu: "qntra : under
the deluge of
tit bits, website-exchanges btc price keeps falling" lmao
trinque: BingoBoingo with
the unmatched comedic
timing
BingoBoingo: <mircea_popescu> (btw, vice is SO butthurt at "fashwave" it's something else. how fucktarded do
these shriveled up, useless cunts who
thought
they can "become writers" need
to be not
to realise
that
the only
thing
they're doing is fanning
teh fire ? aaanyways) << It's like bull baiting, but with babushkas
grimm: thank you ill
tell all my friends ahahaha