476 entries in 0.438s
mod6: No, the
manifest was published last week, trinque.
trinque: I have patches myself which are sitting on the sideline waiting for the
manifest, which I was under the impression you're working on
diana_coman: fwiw I *did* specifically state in the
manifest that it's using Keccak hashes
diana_coman: I added the
manifest + comments in it; otherwise *all* code is precisely what I got from pressing your patches
mircea_popescu: and you can't put "this is keccak" in
manifest because it has to get into the
manifest through being in the filename, rather than just in the comment line ?
mod6: In other news, I've created a new excise hash truncation regrind vpatch, which includes the
manifest.txt pasted above. Am re-testing it, currently. Will post to ML upon success.
a111: Logged on 2018-09-08 23:31 mod6: Hi all, I wanted to get some review, on this
manifest file that would be introduced into trb. It would be placed inside the 'bitcoin' directory along the 'Makefile' and 'src' directories. It follows trinque's proposal here:
http://trinque.org/2018/06/02/v-manifest-specification diana_coman: asciilifeform, since your udp genesis is using the sha hashes + a "history" file I'm not sure: do you have something against the move to keccak + standard
manifest file for v-trees?
mod6: Well, s/all created/placed into the
manifest/
mod6: ben_vulpes: All of the previously created vpatches are coming into the
manifest at the same time. This simply denotes that it was all created at one time.
mircea_popescu: i dun see anything wrong with either approach. having them all have current block height as trinque says, correctly reflects present situation. having them have whatever other denotation you choose (some kind of reconstructed "blocks as it were") has the advantage that it reflects historical knowledge. neither of these is important : FUTURE
manifest.txt versions can reflect w/e we want them to then.
trinque: mod6: I figure giving them the same block times is the right thing, since it's entirely true (and useful to denote) that they were all added to
manifest.txt at that time
mod6: A while back it was argued that a full-regrind of the entire trb vtree was not necessary. Having all the
manifest entries in there, even if starting now, should suffice.
mod6: Also, the name of the file would be '
manifest.txt'.
mircea_popescu: the range wars in the very us raged in living memory as an exact
manifest of this whole thing.
mod6: ben_vulpes brings up a good point about my regrind of his Excise Hash Truncation vpatch, I should put in the
manifest.
mod6: Hm, I wasn't taking about the
manifest thing really, which is another whole question not completely answered.
mod6: After looking at PeterL's blogpost, was curious if there had been any consideration into if a
manifest file should grow up or down (i.e. newest change first, or newest change last in the file). This is purely a cosmetic thing, I suppose it would be up to the author too. Probably why trinque didn't touch on this in the post either
http://trinque.org/2018/06/02/v-manifest-specification/ phf:
manifest doesn't solve this problem, because
manifest doesn't get any kind of priority treatment. if you hinged your press purely on a
manifest descendent/antecedent chain then everything else will just work™
phf: there is a
manifest in this version of vtools
phf: asciilifeform: well, i'm not sure what "spuriously bifurcated tree" means in this case, the goal was stated in the one of the posts, that i'm explicitly maintain two separate branches, that hinge on two separate
manifest paths. this is the kind of stuff v is designed for neh? press to vdiff_sha_static to get one thing, press to vtools_vpatch_newline to get the other
a111: Logged on 2018-07-07 23:27 phf: i've been using vpatch/vdiff without full blown v, because i can order the patches by hand (and there's now an explicit ordering provided by
manifest), and vpatch verifies the hashes for me. it would be handy if i could also press existing sha patches with `vpatch -a sha` or whatever
phf: i've been using vpatch/vdiff without full blown v, because i can order the patches by hand (and there's now an explicit ordering provided by
manifest), and vpatch verifies the hashes for me. it would be handy if i could also press existing sha patches with `vpatch -a sha` or whatever
☟︎ phf: well, yes, you have all the tarbas/ebuilds have a blake in
manifest, but there's no equivalent for a git repo. those are just pulled
mircea_popescu: point being, "blind" v could exist that just puts in the patches as seen in
manifest, checks no sigs.
a111: Logged on 2018-06-26 17:45 phf: trinque: one reason i didn't include patch name in the
manifest is because patch name becomes a promise, unless you enforce it by tooling. i didn't want to go that way, but since current standard
manifest does include patch name, than perhaps V ought to check the
manifest against the patchset. relatedly fully
manifest-based v doesn't even need graph tooling, can presumably press according to
manifest's chain.
trinque: I brought up the graffiti because that'd be (and has historically been, before
manifest) the way to attach the graph
trinque: wont be able to press a "makefiles" +
manifest until that subsequent patch, but I don't really see a problem with that
ben_vulpes: add a new file for the
manifest, create a vpatch, any subsequent vpatches that don't also edit
manifest must be reground into mainline.
trinque: I was discussing how the
manifest gets welded on, if welding on
trinque: anyhow, if we're talking about how to use the
manifest, got it.
ben_vulpes: reference the
manifest file in a later patch.
mircea_popescu: if you find the
manifest patrch is useful (as you do), YOU INCLUDE IT.
mircea_popescu: 2. you sign another new patch, later on, "fixing-bugzappers.patch". this patch references
manifest patch and ircbot-multichan-etc.
mircea_popescu: 1. you sign a new patch,
manifest.patch. at this juncture, phf's viewer will show it to the side, unconnected to the tree.
trinque: aha, once there's a
manifest, all's fine.
mircea_popescu: ed patch is now also well ordered, "caught in the patchchain" as it were) and b) we can and very likely will re-organize the portion between genesis and the
manifest patch later anyway.
mircea_popescu: it's not being proposed as a retoactive fix. the idea is, ~after~ the patch that puts in a
manifest, ~subsequent~ patches will be well ordered. and the fact that the earlier ones aren't exactly well ordered is a) resolved in any practical sense by the fact that you won't have patch imports across the barrier more than 1 deep (ie, once a patch after the
manifest patch references a patch before the
manifest patch, THAT refernec
a111: Logged on 2018-06-26 17:26 trinque: ben_vulpes: because the
manifest has no antecedent, and you're gonna have to go graffiti other files like an idiot
trinque: phf: thought I had there was that if you have only a
manifest in hand, perhaps the name is useful in some dht lookup for the patches later
phf: trinque: one reason i didn't include patch name in the
manifest is because patch name becomes a promise, unless you enforce it by tooling. i didn't want to go that way, but since current standard
manifest does include patch name, than perhaps V ought to check the
manifest against the patchset. relatedly fully
manifest-based v doesn't even need graph tooling, can presumably press according to
manifest's chain.
☟︎ trinque: what it means is that before that point, there isn't a
manifest-enforced press order
trinque: mod6: what do you imagine needs to change in a vtron to support the
manifest?
trinque: phf: harping on it because I don't see evidence that reason for the
manifest has been internalized
a111: Logged on 2018-06-15 17:26 phf:
http://btcbase.org/log/2018-06-15#1825631 << updated, but it's a novel way of using
manifest though: normally it requires a regrind where
manifest is built up as you go, so the press order is enforced through graph. right now your
manifest gives a press order, that's not enforced by anything
phf: trinque: ftr we have the "introduce
manifest now without regrind, use it moving forward" pattern already implemented once
mod6: Perhaps we need to 1: Formally adopt the
manifest spec proposed by trinque, 2: build a V that supports it.
mod6: we'll cross that bridge when we come to it. but first and foremost, the
manifest items seems alright to me; "$blockCount $patchTitle $patchAuthor $comment".
mod6: I can delcare the v054 release with a
manifest of my own ala: To declare a "release", an author's GNS pointer for a project would point to his selected
manifest.
trinque: wherever you introduce the
manifest, if it is not the root, in order to involve it in the flow of the tree, that patch must also edit some other file.
mod6: i see ben's point, but i'd rather trb one whole thing, instead of a 'before
manifest' and 'after
manifest'.
ben_vulpes: well in theory, but in practice everything below makefiles already needs a regrind; aggression to request newblocks if none have been advertised recently; hash truncation atop that. so there's an opportunity to significantly reduce the amount of regrinding by introducing the
manifest after the makefiles release and just regrinding 2 patches instead of the whole tree. unless i misread the situation.
trinque: ben_vulpes: because the
manifest has no antecedent, and you're gonna have to go graffiti other files like an idiot
☟︎ ben_vulpes: mod6: my original q was in re why regrinding the whole tree is necessary instead of introducing the
manifest now and using it going forward
mod6: ben_vulpes: im trying to look at the big picture. the
manifest spec is a part of that, ya.
trinque: the words I wrote right there gave it as an example of "this needs a
manifest"
trinque: there ~are no~
manifest capabilities to be had
ben_vulpes: "
manifest capabilities" are baked into all V implementations
mod6: is his lisp version of V to become the new defacto thing that has
manifest capabilities?
ben_vulpes: mod6: focus on the
manifest design, not the v implementation linked in trinque 's post
trinque: the blog post there is talking about the
manifest file format.
mod6: that said, everything must be pretty much "firmly" in place with V rules,
manifest, naming conventions, what have you, before I wanna move on that.
ben_vulpes: for the sake of exploring the state space; it is more desirable to regrind the whole tree rather than to introduce the
manifest at this point and use it going forward?
trinque: they're ready, being held because I haven't reground the entire tree around a
manifest.
a111: Logged on 2018-06-19 20:52 mircea_popescu: it's not "oh, errybody has a rotten plank or two keeping'em afloat." it's "oh, everybody ~can
manifest matter by will~, currently everybody hanging off the bare minimum rotten plank and they're not even COMPARED".
mircea_popescu: it's not "oh, errybody has a rotten plank or two keeping'em afloat." it's "oh, everybody ~can
manifest matter by will~, currently everybody hanging off the bare minimum rotten plank and they're not even COMPARED".
☟︎ phf:
http://btcbase.org/log/2018-06-15#1825631 << updated, but it's a novel way of using
manifest though: normally it requires a regrind where
manifest is built up as you go, so the press order is enforced through graph. right now your
manifest gives a press order, that's not enforced by anything
☝︎☟︎ esthlos: trinque: I added a
manifest to my v_genesis vpatch. I'm curious, though, how these items (vtron,
manifest) become declared "standard", if ever