log☇︎
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?
ascii_butugychag: if you press to genesis, you get the bitcoin we started with.
ascii_butugychag: genesis is where a v object comes to exist.
PeterL: ok, so what do I use as head? one of the leafs?
PeterL: oh, I was thinking about it upside down, I guess
ascii_butugychag: PeterL: the genesis is always implicit in the head
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 :<
ascii_butugychag: mod6: i still see 'offset' in there?
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.
mircea_popescu: PeterL you specify where you want to end up.
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?
ascii_butugychag: this is really the best way, imho
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?
ascii_butugychag: PeterL: at the same time ?!! why??
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.
ascii_butugychag: it kinda reduces to 'p'
mircea_popescu: it's the "clever" one that takes 18bn loc
mircea_popescu: really, a properly behaving o shouldn't be a big deal to write neh ?
ascii_butugychag: that it works at all, to our purpose, is a marvel.
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
mircea_popescu: welcome to the club polarbeard eh.
mircea_popescu: well this has been a most instructive experience.
ascii_butugychag: in fact, the use of gnudiff/patch is really happenstance
ascii_butugychag: 'this patch applies IF THIS HASH otherwise FUCKOFF'
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.
ascii_butugychag: than to a ppm of anything
ascii_butugychag: and the overall effect is more similar to the rocket pins
ascii_butugychag: prolly enough to be 'interesting'
ascii_butugychag: and i warned, that this has to be switched off
mircea_popescu: oh oh nm then.
ascii_butugychag: tries to make the patch fit
mircea_popescu: just you know, run a tail on the file. good enough
ascii_butugychag: it is 'patch' that does this
mircea_popescu: but... so then why bother doing a diff
ascii_butugychag: tries to find a place where the context fits.
polarbeard: finds surrounding lines, omits whitespace, and don't know what more dirty tricks
mircea_popescu: how does this work ? i'm sitting here doumbfounded.
polarbeard: uhg, those would require --backup-if-mismatch --force
ascii_butugychag: http://www.koehlke.com/media/MIL-Spec/Delphi-28840-connector.jpg << them
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
mircea_popescu: then it wouldn't have had this problem :D
ascii_butugychag: mircea_popescu:, mod6: notice the '5 offset' ??
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:
mircea_popescu: unautomated tests ftw huh
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: if same - then works
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.
mircea_popescu: anyway : this FORK BY DEFAULT!!11 tendency of the v world, whereby it takes serious work and generally http://trilema.com/wp-content/uploads/2014/03/sea-otters.jpg to stay on the same branch is one of its best features imo.
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: so many things you gotta check!
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.
ascii_butugychag: but not the return code of patch -p0 < .... ?
mod6: it verifies the post press checksum.
ascii_butugychag: (also important to disable 'fuzziness' in the latter)
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
mircea_popescu: but this MIGHT be a bug in v
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?
ascii_butugychag: when there are two prongs of equal length
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.
ascii_butugychag: jurov: it's a 'longest chain' sort of thing. see old thread.
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