11300+ entries in 0.023s
mod6: so say we go with that... that 'foobar.vpatch' just inherits an antecedent 'genesis.vpatch'; how does one distinguish between 'foobar.vpatch' as a root and 'genesis.vpatch' as a root without additional criteria?
mod6: <+mircea_popescu> either it builds in its own independent tree, or else it declares an antecedent in the trb tree. << so in the latter part here, should my 'foobar.vpatch' that just adds one file without any antecedents or descendants actually inherit an antecedent, in this case 'genesis.vpatch' ? just trying to understand ...
mod6: <+asciilifeform> mod6: wtf means 'root and leaf at the same time' << in the old code, it is a root, because it has no antecedents, and it is a leaf because it also has no descendants.
mod6: asciilifeform: yah, got it.
mod6: ok i guess that would be bad in the sense that "i'm just staring this project, my genesis should be a root even though nothing descends it yet..."
mod6: ok, so that's basically what I was wondering. to be designated a proper 'root', do we also add the criteria of "must have an actual proper decendant"
mod6: so in the case of my previous implementation (V99995), these island-roots would simply endup at the end of the flow, as a leaf. as they are both a root and a leaf at the same time.
mod6: ok, i'd have to look at shiva genesis again here. but yeah, multiple roots.
mod6: so this one single vpatch has a 'false' input, and a non-zero sha512 output.
mod6: Say that we have a flow, like trb, with all sorts of vpatches that stem from one single root. where that root is designated as a 'root' because all of its inputs are 'false'. what should happen with a vpatch that, for instance, just adds a file to the source and has no antecedents, nor decendants.
mod6: So, my V changes that implement a proper wot-variant V are looking pretty decent. however, I thought up an edge case that I'd like to discuss a bit more -- and I know we've been over this a bunch, and even recently.
mod6: i'm making some good progress on my V changes this week. hopefully won't be too long be for I can help you out with any wallet related things you might be doing on trb.
mod6: hai davout. how goes?
mod6: but I'm so glad I wrote these.
mod6: these automated tests could use some serious cleanup and refactoring -- they work fine, just not very pretty, etc.
mod6: phf: yeah, might be a worthwhile project.
mod6: yeah, i saw some of that. neat stuff.
mod6: would that alone be worth experimenting with, just to see how expensive it really would be?
mod6: i did see that. and yah, that sucks. for lack of a better way to put it.
mod6: would it be a worthy project for someone to start to write some essential libs for tinyscheme?
mod6: (i ask all of the questions because im simply curious, and it seems to be such a broad range of different dialects, if that's even a way to put it)
mod6: what is the general feeling of 'common lisp' within the republic?
mod6: what's the meaning there, is LISP the "proper" lisp for an actual lisp machine?
mod6: capitalized in the sense that most lispers live in the park in san fransisco?
mod6: <+phf> no in scheme land you have mit scheme and scheme48 << with these, which one is more preferred? or why choose one over the other?
mod6: 'cl' is like 'lisp' formal right?
mod6: well, yeah, but arn't all scheme interpreters built with C?
mod6: is there any big hang-ups about chicken scheme?
mod6: oh, yeah. almost forgot... having the feather stems in the pillows is the worst. i refuse to use them for that reason. nothing worse than those things poking you in the face.
mod6: omg. i bet the bolognese is awesome.
mod6: don't fuck with a guys meat.
mod6: i'd get medieval on someone if they did that to my salami
mod6: we talked about how some this happened once upon a time in a socialist hell hole.
mod6: i was at the deli the other day, buying up all the meats... and just remembering, and getting even pissed about the thought of some asswads substituting soy in for fat.
mod6: all meat, no carbs type thing.
mod6: i just had this impression that alf was on atkins or something
mod6: why would any one care who feeds what to a street-cat?
mod6: btw, i wanted to note that hanbot v. random .ar derp would have been an awesome battle to watch.
mod6: that is a LOT of eps, Sir.
mod6: we're creapin up on 450`000 blocks.
mod6: There's still a bunch more clean up and testing ahead, but a step in the right direction. o7
mod6: oh yah. lol, could hardly walk down the driveway.
mod6: warmed up, now its raining and freezing. slicker than a minnow's dick out there.
mod6: The good news is, it sounds like we're all aligned on this.
mod6: <+mircea_popescu> a patch can only apply if ALL of its antecedents are present ; not if ANY of its antecedents are present << this.
mod6: asciilifeform_dns_thermonyukyoolar_kleansing.vpatch
mod6: I'll work on getting axiom into place in the code, will update further if I hit another issue or need further discussion/direction:
mod6: mircea_popescu: thanks for talking me through it though. Even though for some out there, this might be painfully obvious stuff, but it's not, at least for me. So it's worth going over in detail.
mod6: i don't know how the mechanical hash matching would work otherwise.
mod6: so those four, are vpatches that touch the same files that "asciilifeform_dns_thermonyukyoolar_kleansing.vpatch" touches.
mod6: whoops, missed a space & comma above
mod6: bitcoin-asciilifeform.4-goodbye-win32.vpatch, asciilifeform_dnsseed_snipsnip.vpatchasciilifeform_zap_showmyip_crud.vpatchgenesis.vpatch
mod6: Once I have that part correct, will update and continue wrapping up the automated tests. Then further testing will begin, etc.
mod6: Anyway, wanted to spend a few minutes elaborating on my latest battles; I'm making progress, but still need some time to get it straightend out.
mod6: this makes sense in theory, and mechanically because otherwise, unable to press.
mod6: so I propose that I need to ensure of its removal by reverse checking every decendants antecedents.
mod6: and removal of one doesn't, in my current implementation, ensure it's removal, as there are three other antecedents for this.
mod6: so technically, yeah, "asciilifeform_dns_thermonyukyoolar_kleansing.vpatch" has four antecedents.
mod6: (and anything else that depends on init.cpp downstream from that as well)
mod6: ah, since there are more than one graph edge, it must be clobbered as well, "asciilifeform_dns_thermonyukyoolar_kleansing.vpatch", I mean.
mod6: So I'm thinking that I need to add an additional check to ensure that every vpatch has a corresponding, existing, antecedent in the current flow.
mod6: So my code finds all the decendants, then topographically sorts them. Then press based on the flow.
mod6: And for that one edge, it does make sense, but since that vpatch changes more than one file, this causes a problem when the files being changed do not aligh.
mod6: There is an edge betwee"bitcoin-asciilifeform.4-goodbye-win32.vpatch" and "asciilifeform_dns_thermonyukyoolar_kleansing.vpatch" which causes my V to think that "asciilifeform_dns_thermonyukyoolar_kleansing.vpatch" still belongs in the flow.
mod6: Since this is a multi-edge edge case (for lack of a better way to put it), this happens.
mod6: His graph doesn't show all of the edges, and as this correctly highlights, I believe to be less than perfect.
☟︎ mod6: So basically what I'm seeing is that, once I discover my proper decendants, I also need to reverse check the graph for ~existing~ antecedents to ensure that a proper press can happen.
mod6: Even though the flow is correct, it depends on changes that are no longer there for files such as init.cpp...
☟︎