Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2017-10-19

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:56 ilbot3 joined #darcs
01:56 Topic for #darcs is now http://darcs.net/ | logs: http://irclog.perlgeek.de/darcs/ | darcs 2.12.5 is out http://darcs.net/Releases/2.12
05:48 ThomasLocke joined #darcs
05:48 ThomasLocke joined #darcs
05:56 byorgey joined #darcs
05:56 byorgey joined #darcs
06:33 ThomasLocke joined #darcs
11:51 gh_ joined #darcs
12:30 gh_ hi
13:08 byorgey joined #darcs
13:08 byorgey joined #darcs
14:10 byorgey joined #darcs
14:10 byorgey joined #darcs
16:21 gh_ I am preparing a talk about Darcs that I'm going to give next week
16:23 gh_ by searching online I found two old and interesting interviews of Tom Lord (author of Arch) and our own David Roundy, from 2004
16:23 gh_ Tom Lord: https://web.archive.org/web/20160624154515/http://osdir.com/Article1687.phtml
16:23 gh_ David Roundy: https://web.archive.org/web/20160303225751/http://osdir.com/Article2571.phtml
16:30 byorgey joined #darcs
16:30 byorgey joined #darcs
17:51 ilbot3 joined #darcs
17:51 Topic for #darcs is now http://darcs.net/ | logs: http://irclog.perlgeek.de/darcs/ | darcs 2.12.5 is out http://darcs.net/Releases/2.12
17:57 siel joined #darcs
17:58 Heffalump gh_: darcs grew out of discussions between David and Tom, from what I recall (maybe it's in the interviews)
18:04 gh_ Heffalump, David mentions it in his interview, yes. Also, I looked up these interviews because Tom's name is mentioned in David's patch theory documentation (but I did not know who he was, I never used arch myself)
18:13 sm gh_: nice
19:42 gh_ looks like I'm on my way to write my own formalization of patch theory
19:42 gh_ "as we know it"
19:43 Heffalump oh?
19:45 gh_ I haven't read every formalization available on the wiki, but for instance, as to why every patch should be invertible, it is not because of commuting or merging, but only because some operations (revert, rollback) need to apply the inverse of a patch to a working tree
19:46 gh_ patches themselves should not be invertible because of commutation, instead invertiblity should be a property of the commutation function itself
19:46 gh_ or maybe I have missed something
19:50 gh_ I'm not talking about conflicts yet, just the classic examples of pulling or unrecording patches
19:53 Heffalump that's true to an extent (I once experimented with dropping Invert instances from some parts of Aura and it didn't seem out of the question)
19:53 Heffalump but without inverses you also lose the nice relationship between commute and merge
19:53 gh_ for instance in the Darcs wikibook: "The purpose of commuting the patches is essentially to push patch A on to end of the list, so that we could simply apply its inverse." <- I don't agree with this. To me, any prefix of a patch sequence is a valid patch sequence, there is no need for inverses for this.
19:54 Heffalump yes, I agree with you
19:54 Heffalump well, except that practically you want to apply its inverse to pristine
19:54 Heffalump for speed
19:55 gh_ yes, I think this is the point of exposing patch theory like this
19:55 Heffalump but you could equally define an 'unapply' operation rather than injecting inverses into the same domain as patches
19:55 gh_ but I's rather start with explaining patch theory without pristine
19:55 gh_ yes
19:56 gh_ "Heffalump> but without inverses you also lose the nice relationship between commute and merge"   <- I still have to get to this part
21:02 gh_ ok, defining merging without asking invertibility of patches is possible but cumbersome
21:03 gh_ that would work with an 'invertAndCommute' function that should comply with : commute(invertAndCommute(Q,R)) = invAndCommute(R,Q)     , for all Q,R parallel patches
21:04 gh_ ( invertAndCommute(A,B) would be equivalent to commute(inv(A),B) )
21:06 Heffalump the nice thing about the definiton with native merging is that commute(inv(A),B) is just a normal commute
21:07 gh_ yes
21:08 gh_ the pair of functions commute and invert is simpler and easier to define (and trust) than the pair of funtions commute and invertAndCommute
21:27 Heffalump also, you're kind of just moving the problem: you either have commute and merge being unrelated, or commute and invertAndCommute being unrelated
21:28 Heffalump either way, it's much nicer when you just have one function that induces the other
22:02 vorot93[m] joined #darcs
22:37 pointfree1 joined #darcs
22:37 Naughtmare[m] joined #darcs

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary