270 entries in 0.579s
mod6 is testing the phexdigit fix
regrind 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.
mircea_popescu: the idea was "no more new work on sha,
regrind old work at leisure"
a111: Logged on 2018-09-19 14:42 mod6: Before we embark on an entire
regrind of the trb-vtree to use keccac, I think we just need a major release version of a "defacto" vtron that supports both SHA512 (for other legacy projects) and keccac. Sounds like phf's might fit the bill, but want to ensure that when the Foundation tackles this problem, it's on very stable footing.
diana_coman: fwiw I was talking strictly of *new* stuff for now; notice that I did *not*
regrind eucrypt either - that can wait; new stuff however should use keccak imo
mod6: Before we embark on an entire
regrind of the trb-vtree to use keccac, I think we just need a major release version of a "defacto" vtron that supports both SHA512 (for other legacy projects) and keccac. Sounds like phf's might fit the bill, but want to ensure that when the Foundation tackles this problem, it's on very stable footing.
☟︎ diana_coman: the issue at hand is more simply that being sha means it will have to go through
regrind at some point and so I'm not very keen on adding to it patches just to have what to
regrind later; but maybe that's just me
a111: Logged on 2018-07-06 23:15 phf: considering the slow adoption of the keccak approach and also a large number of existing sha512 patches, i'm planning on doing a
regrind where i merge the keccak and the sha branches together, so that vpatch/vdiff can produce both hashes on a switch, until further notice.
mircea_popescu: or you mean "
regrind the patch" ? usually
regrind means you know, the whole tree.
mircea_popescu: the 5 don't have to
regrind anymore than you do, can just import the patch.
a111: Logged on 2018-09-18 18:19 asciilifeform: this is the inevitable cost of v, you gotta weigh 'i can fix this typo, but 5 people will need to either
regrind or abandon my tree'
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: ben_vulpes brings up a good point about my
regrind of his Excise Hash Truncation vpatch, I should put in the manifest.
phf: ave1: i've updated zfp with
regrind and the latest zfp_3_platform
hanbot: diana_coman the
regrind presses here without errors with phf's vpatch. i didn't try pressing with v.pl, possibly they're incompatible...?
a111: Logged on 2018-07-07 11:40 spyked: btw trinque, I'm getting back to trilemabot-works next week, so I can do the
regrind after trilemabot part ii if that's too deep in your queue.
mircea_popescu: esthlos genesis ~never needs redoing. it's a purely administrative decision, to
regrind, dun sweat it.
spyked: btw trinque, I'm getting back to trilemabot-works next week, so I can do the
regrind after trilemabot part ii if that's too deep in your queue.
☟︎ phf: considering the slow adoption of the keccak approach and also a large number of existing sha512 patches, i'm planning on doing a
regrind where i merge the keccak and the sha branches together, so that vpatch/vdiff can produce both hashes on a switch, until further notice.
☟︎ a111: Logged on 2018-06-26 17:45 trinque: could say we want trb to be exemplar of "how to V", in which case yeah,
regrind it all
mircea_popescu: trinque which is why the
regrind mechanism even exists
ben_vulpes: it's either there or
regrind back to the genesis
trinque: could say we want trb to be exemplar of "how to V", in which case yeah,
regrind it all
☟︎ 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: opting to
regrind the entire tree, and whatever other vpatches that need to be folded in that currently are not.
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.
mod6: i'll
regrind the whole trb tree. however, I think if we -must- do this, we should only do it one time. and i really don't even want to do it at all.
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?
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
☝︎☟︎ mircea_popescu: phf, looked to me like a
regrind (patrch got absorbed)
a111: Logged on 2018-06-02 20:10 trinque: I gotta
regrind ircbot for spyked anyway, so this isn't even duplicated effort
trinque: I gotta
regrind ircbot for spyked anyway, so this isn't even duplicated effort
☟︎ esthlos: cool, i'll watch out for it and
regrind spyked: mircea_popescu, then if they're separate branches and if I want to make purely hypothetical spykedbot that does both? would end up with patch with two antecedents, should v press that? should I
regrind?
a111: Logged on 2018-03-30 23:52 phf: well, i'm now convinced that manifest is an elegant, minimally invasive solution. i'll try it in a
regrind.
a111: Logged on 2018-04-25 03:53 phf: trinque: there wasn't anything wrong with polarbeard's patches in general, he just happened to be doing his work when there was a lot of regrinds going on in the tree and after third time he was asked to
regrind he decided he had enough and quit
phf: trinque: there wasn't anything wrong with polarbeard's patches in general, he just happened to be doing his work when there was a lot of regrinds going on in the tree and after third time he was asked to
regrind he decided he had enough and quit
☟︎ trinque: I'm blocked on not having the manifest, so next on my plate is to
regrind every patch with a manifest entry.
phf: mod6: this might've been encountered before, but i'm talking about the vtools patchset that was there before
regrind a111: Logged on 2018-04-06 21:19 phf:
http://btcbase.org/log/2018-04-06#1793646 << i'm moving too slow, please wait till tomorrow for me to push the
regrind with fixes. if you can give me that version of mp-wp.vpatch unsigned that would be helpful
phf: mircea_popescu: let's revisit this question in a couple of days, i'll give it some thought too. i want to finish
regrind in the next day before hanbot is done with standing up her mp-wp instance
phf: well, i'm now convinced that manifest is an elegant, minimally invasive solution. i'll try it in a
regrind.
☟︎ 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"
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
☝︎ mod6: Speaking of posts, I should have my
regrind post up later tonight.
mircea_popescu: i'm guessing the only way out of this predicament is to have an actual
regrind, into a new genesis, of all the patches we actually want.
mircea_popescu: meanwhile, if this tree is orphaned for whatever reason (such as someone regrinding some chunk that includes portions downstream from minigame's press point), the prevailing of that
regrind is ~actually~ based on proper social behaviours. it must have been supported by minigame too, to have prevailed ; or else minigame's agency must have been indeed so insignificant as to warrant some serious self-examination there.
ave1: I'll be happy to
regrind my 2 (so far) patches if needed
trinque: experimental patches meanwhile wouldn't, and the operator is invited to
regrind the experimental item into a patch which edits changelog, if it's graduating out of "experimental"
a111: Logged on 2018-01-18 20:58 mircea_popescu: the problem is that later on, eucrypt's smg_keccak will be pulled into the main to be used for purposes ; if EVEN LATER it gets a patch, phf will then not actually have a way to seamlessly "get just the patch", he will have to
regrind at that time anyway.
mircea_popescu: ie, this "independent parts in an automatic fashion" is a hope impossible in practice. the only way he can have it is if HE reads it, as it is found wherever it is found (eucrypt as it happens here), and then HE puts it in, as a
regrind, ie, yes, "de novo" item.
mircea_popescu: the problem is that later on, eucrypt's smg_keccak will be pulled into the main to be used for purposes ; if EVEN LATER it gets a patch, phf will then not actually have a way to seamlessly "get just the patch", he will have to
regrind at that time anyway.
☟︎