thimbronion: diana_coman: I am stumped on how to work on the timidity problem. I see it. It's there. Also, replied and updated post: http://thimbron.com/2019/10/irc-diplomacy-oftc-undernet-espernet-dalnet/#comment-28
diana_coman: thimbronion: http://thimbron.com/2019/10/irc-diplomacy-oftc-undernet-espernet-dalnet/#comment-29 - this is btw something to add to easily while you are on holiday; if anything you can set up a fleet of bouncers to collect data from all networks & chans while you enjoy hawaii or whatever
diana_coman: thimbronion: re script for analysis you might find the awk irssi2tmsr thing good for initial cleanup of join/part and similar so you have whatever conversation remains in there
diana_coman: see the logbot v-tree
whaack: good morning diana_coman. I figured out/remembered an insight for toposort, namely that it's easier to check if a node has no future dependencies than to check if a combination of applying the already sorted nodes is an antecedent of an unsorted node. This puts me more on track for completing this week's goals. But I am still uncertain whether I will make it. In either case I feel that I did the exercise I needed to do before readi
whaack: ng the code, and can now proceed with the annotation task you assigned me.
whaack: diana_coman: I also want to clarify what is the end of my work week. Is it Sunday night or Monday night, and at what time in which time zone? (And humbly, I will guess the prelude to your answer: it is very stupid that I did not ask this immediately before I made my post, because how could I begin to allocate time on a 1 week horizon if my bounds are +-24hrs? This shows I just took a guess as to what I could get done without reason
whaack: ing it out)
whaack: s/easier to check if a node has no future dependencies/easier to check that a node is not a dependency of any of the unsorted nodes/
diana_coman: whaack: are you trying to rediscover dijkstra's toposort algorithm or what's with the remembering?
diana_coman: whaack: do you know dijkstra's algo? (yes or no)
whaack: well I reasoned it out again, but I had read it before a long time ago
diana_coman: whaack: so go and read it from a ref book if you need to, what; that's what ref books are for!
diana_coman: this algo in particular is pretty simple too, greedy taking of vertices that don't have any incoming edges + eliminate it and repeat
diana_coman: http://logs.ossasepia.com/log/ossasepia/2019-10-17#1006713 - Sunday night strictly speaking; practically speaking for as long as I'm in the UK, it would be Monday 6am UK time (ie GMT+1 currently & GMT when clocks change)
ossabot: Logged on 2019-10-17 08:53:12 whaack: diana_coman: I also want to clarify what is the end of my work week. Is it Sunday night or Monday night, and at what time in which time zone? (And humbly, I will guess the prelude to your answer: it is very stupid that I did not ask this immediately before I made my post, because how could I begin to allocate time on a 1 week horizon if my bounds are +-24hrs? This shows I just took a guess as to what I could get done without reason
diana_coman: but no, I hope you are not going to plan to spend Sunday nights working, ugh
whaack: for this week i absolutely need to to get my stuff done. but it can be spent reading The Odyssey which is enjoyable
diana_coman: whaack: the exact planning of when to get the work done depends on your schedule really but as a rule you should plan somewhere a buffer too.
diana_coman: whaack: note that it might *happen* that you have to spend some night(s) working, sure, but those should be the exception really not a plan ie mainly either 1. terribly poor time management on your part in which case good it hurts, get better at it 2. force majeure (that is rare by definition)
whaack: ok. and yes re dijkstra's, i solved it in the wrong direction at first but realized it was better to do the algorithm you state and reverse the list at the end
whaack: s/i solved it/i tried to solve it
diana_coman: whaack: you *really* should ask what something means if you don't know it, not just wing it! a v-line is not what you think, ugh.
whaack: You're right, I just assumed a vline meant a sequence of applied vpatches from genesis. But even if I'm right I am just taking a guess based off the name.
bvt: whaack: you really shouldn't import v.py's implementation of toposort into your understanding of V (as noted by diana_coman and asciilifeform before), also because it also has known limitations (http://thetarpit.org/2018/botworks-regrind#selection-105.0-123.28)
diana_coman: whaack: re v-line, see the new comment
whaack: bvt: ty i will take a look
whaack: diana_coman: Understood, to demonstrate I will put it in my own words. I wrote the incorrect statement that when you create a new vpatch you must start from pressing to "the most recent vpatch." This is wrong because there is hardly any notion of a "most recent patch" since a set of vpatches form a tree that can split. If for example that tree has 3 nodes a,b,c and b and c are both children of a, then there is no notion of "most re
whaack: cen patch" b and c are both at the same level of the tree. So one can create a patch on top of b or c, or even on top of a.
diana_coman: whaack: technically speaking there IS a most recent patch because of the manifest file
diana_coman: but you basically used there the wrong contexts and got messed up
diana_coman: ie "most recent" is of interest mainly in user-context really; in your V-discussion context you should stick to the relevant terms for the *structure* since that is what you are discussing; ie you have a root node and you have leaf nodes
diana_coman: so at most you could have said a leaf node; at which point hopefully the q would have naturally popped up: why not a non-leaf node?
diana_coman: whaack: pay attention to using the proper terms because if you do, it helps you *a lot*
diana_coman: whaack: does the above make sense?
whaack: diana_coman: yes it makes sense. except I do not know about the manifest file.
diana_coman: whaack: ha! the discussion/intro of a manifest file is in #trilema (although it goes on a bit until current shape so possibly a search works best to figure out what and how
ossabot: (trilema) 2017-12-26 mircea_popescu: how about a convention whereby all new genesises must contain a manifest.genesis file, which file will be constantly patched on each patchj, no exceptions, by adding a line which reads : "This is patch #x and the codebase hash is blabla".
diana_coman: the standard was written on trinque's blog but atm that's down; you can however take any current v-tree and look at it
diana_coman: whaack: see for instance the mp-wp v-tree perhaps
whaack: diana_coman: makes a lot of sense. I wrote down in my notes to ask why a hash of all the files in the codebase was not included, since applying a vpatch could have a different result depending on which leaf node it was applied to.
diana_coman: whaack: hopefully the contexts&terms part is clear too because it's quite important; you basically said "most recent" when what you meant was (it would seem) "leaf node" that further was assumed for some reason to be unique at any given time.
whaack: diana_coman: i understand the importance of using the correct terms. if i have the wrong set of symbols mapping to a concept then my incorrect mapping makes communication ~impossible (amongst other problems.) As for the "most recent" being interest in user-context maybe I do not fully understand what you mean here. I think it means that as a user of V you want to try to constantly know what the "most recent vpatch" is. In practical
whaack: terms this means you want to know what is the best leaf to press to. This is similar to how you want to know what the most recent block is, but for either you can never be assured you are fully sync'd.
whaack: I have to bbl, I'll be gone for about 1.5 hours.
diana_coman: whaack: more to the point is the fact that V does not *care* about "most recent", time itself -at least as the linear thing most commonly thought of- is not part of V as such (and the fact that it has to be forced in via manifest file reflects this), hence not appropriate to talk about most recent when you describe V; onth a user may care (as in your example above or for whatever other reason).
whaack: diana_coman. back. okay, so the user of V has a notion of a "most-recent-patch", but the tool V itself does not.
diana_coman: whaack: quite.
dorion: http://logs.ossasepia.com/log/ossasepia/2019-10-17#1006745 << whaack : trinque's v-manifest spec is archived here : http://archive.is/Ye3Xx
ossabot: Logged on 2019-10-17 09:52:41 diana_coman: the standard was written on trinque's blog but atm that's down; you can however take any current v-tree and look at it
whaack: ty dorion. i updated http://ztkfg.com/2019/10/v-study-reference-links/ to include this.
diana_coman: nice.
jfw gives ETA of tomorrow night for first of upcoming blog posts. First task I think will be to review log for what exactly was asked/offered and work out a more detailed schedule.
diana_coman: jfw: works.
thimbronion: diana_coman: I'm getting the bureaucratic treatment from EsperNet #help: http://paste.deedbot.org/?id=GeV5
diana_coman: thimbronion: so ask them why can't guarantee and then/or how does the decision work
thimbronion: diana_coman: Ok. That makes sense. Done.
thimbronion: http://logs.ossasepia.com/log/ossasepia/2019-10-17#1006708 << is the idea here to set up a cloud instance with a bouncer on it maybe per network, then manually list and join all channels on the network and just take advantage of znc's built in logging?
ossabot: Logged on 2019-10-17 06:02:05 diana_coman: thimbronion: http://thimbron.com/2019/10/irc-diplomacy-oftc-undernet-espernet-dalnet/#comment-29 - this is btw something to add to easily while you are on holiday; if anything you can set up a fleet of bouncers to collect data from all networks & chans while you enjoy hawaii or whatever
thimbronion: diana_coman: I can publish a review for this week tomorrow. Should I skip my plan post for my vacation week?
diana_coman: thimbronion: as much as you can automate quickly, automate; note that the list of channels is likely to be loooong; but a /channels or similar will retrieve it and then simply feed that into the conf to join automatically (or similar setup)
diana_coman: and yes, I'd set it up on whatever vps or anything else you have available really
diana_coman: thimbronion: you can publish the plan post for the week after vacation, not a bad thing to have already done when you come back
thimbronion: diana_coman: ok.
diana_coman: re logger yes, if you have an instance of a client running and in the chan, it will log (make sure it does, lol)
diana_coman: thimbronion: is it clear what and why is the idea there?
thimbronion: diana_coman: I think we would be interested in how much actual discussion is happening in their chans - like - non-join/part lines/day. Is that it?
thimbronion: diana_coman: because maybe they have a bunch of connected users but nothing's really going on.
diana_coman: thimbronion: yes but the important part is that we want to do this properly ie systematically; so we have actual data to point to when we make a claim ; (and for that matter if surprisingly it turns out that there is some very active and interesting thing going on somewhere in there - all the better, we can go directly to it!)
diana_coman: thimbronion: and note that once you have that, you can make a direct comparison and say something along the lines: look here , you claim 10k users but their actual *words* (let alone meaning!) adds up to less than x% of tmsr talk over similar timeframe
diana_coman: but make sure now that you get data properly so you have what to look at.
thimbronion: diana_coman: ok that makes sense. Yes. I don't know how they'll handle someone simultaneously joining all channels. I do anticipate some sort of wrist slapping or kicking for that kind of behavior.
thimbronion: diana_coman: impossible to know until tried though.
whaack: diana_coman: My vpatch topo sort is almost working. The problem is if a vpatch brings any file back to a previous state, the set of vpatches is considered cyclic. This seems wrong, since a vpatch may revert one file while adding a new file. The manifest i think would solve this issue, but I'm not sure whether or not how the non-manifest version should handle this.
diana_coman: thimbronion: well, for one thing you can time them so it's not all at once
whaack: s/whether or not how/how/
diana_coman: thimbronion: and for the other thing, whatever they do, you document it and post it on blog, what; not to mention that...uhm, what exactly is wrong with joining all channels?
diana_coman: showing you "care" about dalnet!!
diana_coman: whaack: lolz@almost working; "here, have some almost food" :D
whaack: lol
diana_coman: whaack: the vpatch is a whole though, you can't and shouldn't apply it partially
thimbronion: diana_coman: ok. Also, I only have a few hours to put into mass logging before I go, so I cant't guarantee that this will be working on 1 or more networks before Sat.
diana_coman: thimbronion: ah, are you leaving for holidays this Sat or what?
thimbronion: diana_coman: Yes, Sat - Sat.
whaack: diana_coman: The problem boils down to: I don't know how to write the function is_vpatch_parent_of_other_vpatch(vp1, vp2) . My naive solution is return true if any of the descendants of vp1 are in the antecedents of vp2. But it's possible that that is true without vp1 being the parent of vp2.
diana_coman: thimbronion: I see; well, do what you can to have at least a test run if nothing more; it sort of sucks because it fit perfectly with "being away" but such is life.
thimbronion: diana_coman: ok.
diana_coman: whaack: and worse, you'll end up with either multiple parents or semirandom choice of parent
diana_coman: whaack: but start from def: what IS the parent of a new vpatch?
whaack: right. so as far as i can tell, you absolutely need some sort of manifest file
whaack: from my understanding the parent of a new vpatch is the result of a series of pressed vpatches, (not even a vpatch itself)
diana_coman: whaack: that doesn't make "parent" ALL the vpatches in that series though, does it?
diana_coman: whaack: you are the result of a similar "press" in your own family tree; that doesn't mean you don't have some direct parents
whaack: diana_coman: right. if you have a vline of p1,p2,p3 (and p2 depends on p1) then p3's parent, if its going to be a vpatch, is certainly p2.
whaack: however if p3 doesnt modify any of the files in p2 that get added/changed in p2, then p1 is also a parent
diana_coman: whaack: hm? it depends on what does p3 depend really; the child vpatch depends on some specific files as identified by their hashes
diana_coman: whaack: and yes, the manifest file makes this problem entirely go away in that it clearly enforces a single line at any point in the tree (you can have a tree with as many branches as you want but the manifest file will be different too)
diana_coman: whaack: the point is this: as each vpatch changes the manifest file, you know for sure that you won't end up with the situation when a vpatch COULD be pressed on either result of p1 or of p2
diana_coman: so you just need to look at hashes: which vpatch results in all the hashes required as "starting state" for p3? if it's p1, then p1 is parent; if it's p2, then p2 is parent
diana_coman: for that matter a case where "more than one possible parent" should -> ERROR
diana_coman: borked tree basically.
diana_coman: note that historically though (ie before manifest), there used to be multiple parent cases, yes; e.g start of http://btcbase.org/patches?patchset=eucrypt&search=
whaack: so eucrpt_keccack_birate_fix and eucrypt_ch15_arbitrary_e both are parents of ch16. and i guess the problem bvt was saying is ~ python v is just going to find a path from genesis to ch16 without being greedy about applying patches
diana_coman: "read and find out"! lol
diana_coman will bbl
whaack: lol k. for the interest of time i will publish what i have so far and then move on with the what/why/how and annotations on stan's code.
asciilifeform: whaack: as bvt earlier reminded, my orig 'v' wasn't 'final word on subj', but rather proof of concept; there are corner cases where it stops and reqs manual intervention, but moar recent vtrons Do Right Thing .
ossabot: Logged on 2019-10-17 09:29:17 bvt: whaack: you really shouldn't import v.py's implementation of toposort into your understanding of V (as noted by diana_coman and asciilifeform before), also because it also has known limitations (http://thetarpit.org/2018/botworks-regrind#selection-105.0-123.28)
asciilifeform: ( fwiw asciilifeform still uses his orig v, or rather the version upgraded to use keccak hashes by diana_coman & phf , it handles correctly all the trees i actually use . but fact remains. )
dorion: http://logs.ossasepia.com/log/ossasepia/2019-10-16#1006705 << hi diana_coman. to be explicit, continuing yesterday's thread tomorrow evening (GMT) is going to work better for me. blog set up is ongoing.
ossabot: Logged on 2019-10-16 18:21:18 diana_coman: dorion: 10 minutes from q to answer though does not a conversation make; so we'll continue tomorrow or Friday evening; write it down too when you get your blog up.
diana_coman: dorion: all right; tomorrow evening then.
diana_coman: dorion: what was with that latency anyway?
dorion: diana_coman: upon reflection I got stuck on that point becuase it's a bit of a sore spot that I continued to work with Coinapult people following what happened there.
diana_coman: dorion: ah, I see; well, good to think of that for sure, but you can't just put the whole world on pause while you do it.
dorion: on top of that I was a bit fatigued from the outpour at that point, in part because it was the first time I've publically written about it.
diana_coman: dorion: at least it should make it easier to write the whole story down now; when is your eta for blog up?
dorion: diana_coman: I think I can have a first post by Saturday, but giving myself a buffer of Sunday.
diana_coman: dorion: would you rather we postpone the talk for next Tuesday then?
dorion: diana_coman ok, I accept postpoing till next Tuesday evening GMT. That'll give me plenty runway to get at least a couple of posts and provide more structure/context compared to flow of consciousness chat.
diana_coman: dorion: lol@accept; yes, I offered it in the idea that it makes it easier for *you*; hence the "rather".
dorion: diana_coman point taken.
dorion: I think I read the "rather" as an offer and decided the accept the offer.
dorion: diana_coman I am about to step away for a few hours. I'll link the posts here when published and keep up with the log in the meantime.
diana_coman: dorion: it's enough if you ping only once with "this is my blog url+ip"
dorion: noted.