415 entries in 0.408s
: meanwhile as of ch16a: libffa : 5142 loc ; ffacalc : 1279; for total 6421 (incl. readme, manifest
: incidentally manifest
actually includes 2 FG units ( pizarro-owned ) . i had to fly'em back in april , if anyone recalls, cuz of ben_vulpes's misadventure where they were pawed by orcs for whole night
: i.e. in hanbot genesis, there is a/mp-wp/manifest
, while in your vpatch a/manifest
: the signature verifies, and i believe i have the diff and manifest
syntax correct, but i'm getting the "not found in flow" error
: in other noose, phf , mircea_popescu , et al, the bolix is here. dks packs a++ , princely, all parts on manifest
, and kilometre of bubbles. will post photos as soon as i wrap up my albatross of this week, ch14
: Romans 1:18 For the wrath of God is revealed from heaven against all ungodliness and unrighteousness of men, who suppress the truth in unrighteousness, 19 because what may be known of God is manifest
in them, for God has shown it to them. 20 For since the creation of the world His invisible attributes are clearly seen, being understood by the things that are made, even His eternal power and
: anyway, this is no excuse for my long silence, so: I'ma bring rss bot here in the following hour (it's been under heavy testing for the last month, so it should at least be a decent replacement for current deedbot rss functionality) and keccak+manifest
ircbot tree should be out by the 1st of december
: is # acceptable comment inline ? should there be a manifest
: Logged on 2018-11-19 21:44 bvt: alternatively, i could add new functions at common tree part if i don't touch any files included in later vpatches (so adding entries to manifest
would be not possible). seems like some quite unnatural acrobatics to me.
: alternatively, i could add new functions at common tree part if i don't touch any files included in later vpatches (so adding entries to manifest
would be not possible). seems like some quite unnatural acrobatics to me. ☟
: Logged on 2018-11-19 07:54 bvt: mircea_popescu: i understand that empty genesis (well, it's not precisely empty, there is a manifest
file) is suboptimal, however:
: mircea_popescu: i understand that empty genesis (well, it's not precisely empty, there is a manifest
file) is suboptimal, however: ☟
: this now begs the questrion whether if i send my valkiries they would somehow manifest
liquidity. god knows i had no problem dealing as much as i wanted in buenos aires. nor here. nor apparently anywhere (except when it comes to wiring to bb, which is becoming the lulz of all time, somehow)
: Logged on 2018-10-06 14:31 diana_coman: I'll soon do the regrind of eucrypt to move it on to keccak hashes; my plan is to keep the patches precisely as they are otherwise (i.e. including NO manifest
until I actually added it at the end); the way I see it, it's just a swap-in-place of one hash for another; if anyone sees this sort of thing differently - since I'm hmmm,first to regrind a big project? - yell now !
: right. but i'm regrinding ch1-11 into keccak. ought manifest
only to live in ch12 ( 11 technically had one, but it was adhoc, and not conformant to current formulation ) ? or in all ch1-11
: "This manifest
created on x to comply with prevailing standards ; original had no such thing." fir instance ?
: imho also. the q is what's the most accurate , given that orig had no manifest
: asciilifeform imo manifest
~should~ be historically accurate.
: originally i was gonna simply regrind ( by running through new vdiff ) ch1-11, and invite reader to hand-diff if he likes and see that only hashes have changed. but then noticed that the new vdiff also processes files in different order, so this won't give clean 'only hashes' diff. so thinking, may as well retrofit manifest
to each of ch1-11
: mircea_popescu: quite unrelatedly, what's your recommended formula for 'manifest
' in keccak regrinds ? ( i.e. to retrofit manifest
to ancient stuff, or only to latest v cut of it ? and with current blockheight, or to somehow estimate the one at the time of original publication ? )
: no such fucking thing, it's exactly like genetics -- genetically present traits may or may not phenotypically manifest
. but if they do not -- THEY WERE NEVER THERE.
: so -- looking back to the crc32 situation, suppose that for whatever reason the consensus wasn't "yeah, should definitely have both" but "division is stupid, only tables are needed". at that juncture, ave1 could have made an alternate patch to the crc32-lookup consisting of merely a changed manifest
, saying "Hey, for so and so reasons I think this should be a crc32-division, I intend to do it later."
: with the manifest
as we have now and no way to automatically merge an alternative (i.e. having more than one possible ancestor)
: well yes, I can't quite see the point of blanking the manifest
without regenesis since that's basically what it means
: if yer nuking the manifest
, good form would be to regenesis then imho. but yes
: note that it's not even illegal to blank the manifest
or w/e. impolite, yes, but the spec allows.
is a piece of handy docs, not a straightjacket, lol
: ah, alternative line in manifest
too, I see it
: diana_coman: no? you can branch on manifest
like on anyffing else
: typo in manifest
"emplementation" -> implementation ; but one can live with that
: I'll soon do the regrind of eucrypt to move it on to keccak hashes; my plan is to keep the patches precisely as they are otherwise (i.e. including NO manifest
until I actually added it at the end); the way I see it, it's just a swap-in-place of one hash for another; if anyone sees this sort of thing differently - since I'm hmmm,first to regrind a big project? - yell now ! ☟
: Logged on 2018-10-03 16:28 asciilifeform adds ' asciilifeform-recipe switch ' to next cargo manifest
adds ' asciilifeform-recipe switch ' to next cargo manifest ☟
: ave1, you forgot to change manifest
file for your zfp_4_assert.vpatch? (i.e. it's missing from the list in manifest
: trinque: manifest
is done, i built on it in the experimental item linked earlier
: No, the manifest
was published last week, 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
: fwiw I *did* specifically state in the manifest
that it's using Keccak hashes
: I added the manifest
+ comments in it; otherwise *all* code is precisely what I got from pressing your patches
: 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 ?
: BingoBoingo: do what remains to do to put a proper cross on the grave, and after that i'ma start taking cargo manifest
: 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.
: next item i write , will have proper trinqueian manifest
: 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
: there is the manifest
, but afaik it doesn't get machine-parsed
: 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?
: Well, s/all created/placed into the manifest
: 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.
: 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.
: 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
: 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.
: Also, the name of the file would be 'manifest
: the range wars in the very us raged in living memory as an exact manifest
of this whole thing.
: ben_vulpes brings up a good point about my regrind of his Excise Hash Truncation vpatch, I should put in the manifest
: Hm, I wasn't taking about the manifest
thing really, which is another whole question not completely answered.
: mod6: there's the manifest
thing; what else was there
: 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/
: i suppose there is also the other variant, where manifest
.txt actually gets speshul treatment. but imho that's ugly.
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™
: there is a manifest
in this version of vtools
: 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
: 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
: 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 ☟
: 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
: point being, "blind" v could exist that just puts in the patches as seen in manifest
, checks no sigs.
: 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
: I brought up the graffiti because that'd be (and has historically been, before manifest
) the way to attach the graph
: wont be able to press a "makefiles" + manifest
until that subsequent patch, but I don't really see a problem with that
: add a new file for the manifest
, create a vpatch, any subsequent vpatches that don't also edit manifest
must be reground into mainline.
: I was discussing how the manifest
gets welded on, if welding on
: anyhow, if we're talking about how to use the manifest
, got it.
: reference the manifest
file in a later patch.
: if you find the manifest
patrch is useful (as you do), YOU INCLUDE IT.
: 2. you sign another new patch, later on, "fixing-bugzappers.patch". this patch references manifest
patch and ircbot-multichan-etc.
: 1. you sign a new patch, manifest
.patch. at this juncture, phf's viewer will show it to the side, unconnected to the tree.
: aha, once there's a manifest
, all's fine.
: i think trinque's observation is re how to glue the ~old~ tree on, in the first manifest
: 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.