340100+ entries in 0.219s

ascii_butugychag: this would give you
the entire
tree as represented by your patches+seals+keys set.
ascii_butugychag: my intent was
that
the user would include ALL of
the leaves he is interested in by using a custom patch dir, and
then press
to
the last.
ascii_butugychag: (you could cut into
the middle of a leaf set more or less alphabetically)
jurov: i guess
this is not implemented yet, ability
to press multiple non-conflicting heads at once
PeterL: but if I use a leaf, will it include
the other leafs?
PeterL: ok, so what do I use as head? one of
the leafs?
PeterL: oh, I was
thinking about it upside down, I guess
PeterL: (p | press) (<press_dir> <head>) << so I have
to specify
the genesis? what is head?
mod6: im
testing
the wrong fucking scalar in my condition :<
polarbeard: I actually do
that, but because metamake is really dumb :(
mod6: when you press, if
the hash of
the pressed file doens't match
the expected, it should die right
then and
there.
mod6: i know at one point i did negitive
tests on
this, but my problem in
there is idiotic, i was not paying close enough attention
ascii_butugychag: my point was
that
there is not a special knob, you don't need it, your unix file system is
the knob
mircea_popescu: <jurov> and my other question about maintaining A and A' in "mempool" ? << everything is in
the mempool al ltime anyway.
ascii_butugychag: place
the ones you want in a dir, make sure you have
the desired seals, and press
PeterL: I am looking at mod6's v, and
trying
to figure out how
to control it?
polarbeard: why isn't
the last version
the only valid one?
PeterL: I mean, I see leafs of malleus_mikehearnification and maxint_locks_corrected, what if I want
to include both? or am I misunderstanding what is going on?
jurov: but
the actual files must be renamed, no?
ascii_butugychag: jurov: A and A' are, if dropped in
the hopper, equally legit pressings
jurov: does v allow
to press both AB and A' from one repository?
PeterL: can v press
to multiple heads, or do I have
to pick one?
ascii_butugychag: incidentally,
to answer a question
that jurov asked a while ago, it is not only possible
to use an arbitrary hash function with v, but even,
theoretically,
to use none at all.
mircea_popescu: really, a properly behaving o shouldn't be a big deal
to write neh ?
ascii_butugychag: v is simply a mathatron
that deals in
the basic operation h,s1,o,s2 where s1 and s2 are strings, h is an operation (usually a hash) for recognizing said strings via
trapdoor, and o is a
transform
ascii_butugychag: at any rate, v really started as a pill against
this particular
thing
ascii_butugychag: gnupatch has 'fuzz' because... you never know whether
the comments got regendered ? or what.
polarbeard: finds surrounding lines, omits whitespace, and don't know what more dirty
tricks
polarbeard: uhg,
those would require --backup-if-mismatch --force
ascii_butugychag: reminds me of
the circular connectors, with 100s of pins,
that rockets had - in su
they copied american plugs, yes; but
they also had sergeants with hammers
ascii_butugychag: i wonder who
thought 'fuzzy' diff was a good idea for a default
to begin with
mod6: i've got some idiotic
thing going on in
there, looking now.
mod6: and.. even if it does press, it should have immediately haulted when it saw
this:
mod6: the output hashes of net.h/net.cpp/bitcoinrpc.cpp are not matching
the vpatch at all,
this should have died mid press.
mod6: im just
trying
to be sure, im already pretty sure... but i wanted you
to look/test so i dont end up with more on my plate
ascii_butugychag: mod6: you can give
the green light
to yourself, just vdiff
the result of applying my
two patches vs.
the result of applying your unified.
mircea_popescu: creates
thriving communities and supports
the implicit "fragmentation=strength" properties of
the wot something fierce.
mod6: before i re-grind
this patch, im gonna look into V a bit while I wait for ascii
to give me
the green light on
the other
two reground from lastnight.
mircea_popescu: but as polarbeard among others can
testify,
this makes writing code fucking difficult,
thanks god.
mod6: but
that could be somehow broken as well, obviously,
this needs some attention.
mod6: it verifies
the post press checksum.
ascii_butugychag: i
thought mod6's vtron actually verified each patch operation ?
mod6: right
this is actually a really good
test case.
mircea_popescu: because if i sign random shit
that doesn't actually connect
to
the
tree even if it claims
to
polarbeard: yes, sorry for
that, got me
totally by surprise
mod6: no worries,
they need
to be re-ground, i'll work on
that.
mircea_popescu: well yes because he never actually published
them, ie, by sending
to ml or w/e
the process is.
mod6: and
thats even with a full sync of
the mirror as it exists up until
this very minute.
mircea_popescu: mod6 as he says,
turns out he wrote it on
top of patches
that didn't make in
mod6: still needs
to be re-ground, but was just weird
that it had no matching antecedents
mod6: ah, so
this is what is very weird:
jurov: but how do I add both A and A' into
the repo without renaming?
jurov: imo both A and A' should be kept at leas B' isn't reground
too
ascii_butugychag: it is no more immediately decidable
than a young chain fork in bitcoin
jurov: is
that always decidable? if i have A, which has a child patch B, and author regrinds A into A' which is
to be kept?
ascii_butugychag: an obsolete patch is simply one
that doesn't keep getting built on.
jurov: and since everyone is regrinding patches right and left, maybe we'd like
to revisit
the notion of "obsoletes
that other one"
ascii_butugychag: ty mod6. i'd like
to note
that in a
time of 'fog of war', when some patch is up in
the air, it is not necessary
to hold off on ~all~ work, but only
things which concern
the affected subsystems.
mod6: or at least until i give
the "all good" signal in here.
polarbeard: yes, it needs reground, I didn't know it will be submitted so what I published is on
top of my better logging patches
mod6: if anyone else is in
the middle of creating a patch - maybe hold off a day or so before you submit until I can straighten out
the
tree &
test everything.
mod6: this one needs
to be reground
mod6: looks like it compiled fine -- even
though
the patch had
to apply with Hunk offset garbage