#ossasepia | 2019-10-17

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

10:06

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

10:07

see the logbot v-tree

~ 2 hours 39 minutes ~

12:46

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

12:46

ng the code, and can now proceed with the annotation task you assigned me.

12:53

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

12:53

ing it out)

12:56

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/

13:02

whaack: are you trying to rediscover dijkstra's toposort algorithm or what's with the remembering?

13:03

whaack: do you know dijkstra's algo? (yes or no)

13:03

well I reasoned it out again, but I had read it before a long time ago

13:03

whaack: so go and read it from a ref book if you need to, what; that's what ref books are for!

13:06

this algo in particular is pretty simple too, greedy taking of vertices that don't have any incoming edges + eliminate it and repeat

13:08

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)

13:08

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

13:09

but no, I hope you are not going to plan to spend Sunday nights working, ugh

13:11

for this week i absolutely need to to get my stuff done. but it can be spent reading The Odyssey which is enjoyable

13:12

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.

13:16

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)

13:18

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

13:19

s/i solved it/i tried to solve it

13:24

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.

13:25

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.

13:29

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)

13:33

whaack: re v-line, see the new comment

13:34

bvt: ty i will take a look

13:42

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

13:42

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.

13:45

whaack: technically speaking there IS a most recent patch because of the manifest file

13:46

but you basically used there the wrong contexts and got messed up

13:47

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

13:47

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?

13:48

whaack: pay attention to using the proper terms because if you do, it helps you *a lot*

13:49

whaack: does the above make sense?

13:49

diana_coman: yes it makes sense. except I do not know about the manifest file.

13:52

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

13:52

(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".

13:52

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

13:54

whaack: see for instance the mp-wp v-tree perhaps

13:55

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.

14:00

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.

14:07

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

14:07

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.

14:09

I have to bbl, I'll be gone for about 1.5 hours.

14:12

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).

~ 1 hours 15 minutes ~

15:28

diana_coman. back. okay, so the user of V has a notion of a "most-recent-patch", but the tool V itself does not.

15:34

whaack: quite.

15:45

http://logs.ossasepia.com/log/ossasepia/2019-10-17#1006745 << whaack : trinque's v-manifest spec is archived here : http://archive.is/Ye3Xx

15:45

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

15:49

ty dorion. i updated http://ztkfg.com/2019/10/v-study-reference-links/ to include this.

15:49

nice.

~ 50 minutes ~

16:40

*

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.

16:48

jfw: works.

16:50

diana_coman: I'm getting the bureaucratic treatment from EsperNet #help: http://paste.deedbot.org/?id=GeV5

16:53

thimbronion: so ask them why can't guarantee and then/or how does the decision work

16:56

diana_coman: Ok. That makes sense. Done.

16:59

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?

16:59

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

17:02

diana_coman: I can publish a review for this week tomorrow. Should I skip my plan post for my vacation week?

17:09

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)

17:09

and yes, I'd set it up on whatever vps or anything else you have available really

17:10

thimbronion: you can publish the plan post for the week after vacation, not a bad thing to have already done when you come back

17:10

diana_coman: ok.

17:10

re logger yes, if you have an instance of a client running and in the chan, it will log (make sure it does, lol)

17:11

thimbronion: is it clear what and why is the idea there?

17:12

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?

17:12

diana_coman: because maybe they have a bunch of connected users but nothing's really going on.

17:14

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!)

17:15

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

17:16

but make sure now that you get data properly so you have what to look at.

17:16

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.

17:17

diana_coman: impossible to know until tried though.

17:18

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.

17:18

thimbronion: well, for one thing you can time them so it's not all at once

17:18

s/whether or not how/how/

17:19

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?

17:19

showing you "care" about dalnet!!

17:19

whaack: lolz@almost working; "here, have some almost food" :D

17:20

lol

17:21

whaack: the vpatch is a whole though, you can't and shouldn't apply it partially

17:22

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.

17:22

thimbronion: ah, are you leaving for holidays this Sat or what?

17:23

diana_coman: Yes, Sat - Sat.

17:27

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.

17:27

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.

17:29

diana_coman: ok.

17:29

whaack: and worse, you'll end up with either multiple parents or semirandom choice of parent

17:29

whaack: but start from def: what IS the parent of a new vpatch?

17:30

right. so as far as i can tell, you absolutely need some sort of manifest file

17:32

from my understanding the parent of a new vpatch is the result of a series of pressed vpatches, (not even a vpatch itself)

17:33

whaack: that doesn't make "parent" ALL the vpatches in that series though, does it?

17:34

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

17:35

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.

17:36

however if p3 doesnt modify any of the files in p2 that get added/changed in p2, then p1 is also a parent

17:37

whaack: hm? it depends on what does p3 depend really; the child vpatch depends on some specific files as identified by their hashes

17:38

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)

17:39

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

17:40

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

17:40

for that matter a case where "more than one possible parent" should -> ERROR

17:40

borked tree basically.

17:42

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=

17:44

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

17:46

"read and find out"! lol

17:46

*

diana_coman will bbl

17:48

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.

~ 23 minutes ~

18:11

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 .

18:11

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)

18:12

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. )

~ 1 hours 24 minutes ~

19:37

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.

19:37

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.

19:39

dorion: all right; tomorrow evening then.

19:40

dorion: what was with that latency anyway?

19:47

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.

19:50

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.

19:50

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.

19:51

dorion: at least it should make it easier to write the whole story down now; when is your eta for blog up?

19:53

diana_coman: I think I can have a first post by Saturday, but giving myself a buffer of Sunday.

19:54

dorion: would you rather we postpone the talk for next Tuesday then?

19:55

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.

19:56

dorion: lol@accept; yes, I offered it in the idea that it makes it easier for *you*; hence the "rather".

19:57

diana_coman point taken.

19:59

I think I read the "rather" as an offer and decided the accept the offer.

20:01

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.

20:02

dorion: it's enough if you ping only once with "this is my blog url+ip"

20:04