Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2017-12-11

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

All times shown according to UTC.

Time Nick Message
02:58 ilbot3 joined #darcs
02:58 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
07:01 ThomasLocke joined #darcs
07:01 ThomasLocke joined #darcs
13:46 mizu_no_oto joined #darcs
14:12 gh_ joined #darcs
14:12 gh_ hi
14:12 gh_ Mysterious_Light: http://darcs.net/FAQ/Performance#how-well-does-darcs-scale
15:07 Mysterious_Light joined #darcs
15:08 Mysterious_Light gh_, thank you, it is what I was searching for.
15:11 Mysterious_Light btw, two links there seem to be invalid.
15:17 Mysterious_Light Am I correct that patch approach in CVS may not cause problems with long histories, a large source tree and large single commits. However, the problem of exponential merging is inevitable.
15:26 Heffalump are you asking about intrinsic properties of the patch approach? (btw, CVS keeps making me think of the old version control system, VCS might be a better generic term for the concept)
15:26 * sm suddenly gets less confused
15:35 gh_ Mysterious_Light, indeed these links are dead, I going to remove them since they are said to be outdated anyway
15:47 Mysterious_Light Heffalump, yes, I want to understand theoretical limits of patch-based VCS, not just one of darcs implementation.
16:08 Heffalump ok, so the exponential merge thing is specific to the darcs approach to conflict management. Pijul doesn't have it, for example.
16:09 Heffalump For scaling in general, I think a lot depends on what kind of caching/pre-computation you do. For example annotate is intrinsically slow (linear in size of history) in any VCS unless you cache the information, like darcs does.
16:10 Heffalump I think merging in general is intrinsically slower in a patch-based VCS than a tree-based one, because you have to merge each patch in sequence rather than just doing a diff3 on the base and final trees. But it's more accurate (at least by some definition) in exchange.
17:43 Mysterious_Light joined #darcs
17:45 Mysterious_Light joined #darcs
17:56 Mysterious_Light Heffalump, 'caching' stands for time-space tradeoff? As far as I understand, constant-space caching cannot change asymptotic time dependency.
18:02 Mysterious_Light Do you know any article about atomic operations in VCS, their cost and their possible combinations that solve common VCS problems (record, merge, annotate etc)?
18:55 gh_ joined #darcs
19:53 Mysterious_Light joined #darcs
20:03 mizu_no__ joined #darcs
20:43 Heffalump Mysterious_Light: well, perhaps more ahead-of-time calculation than on-demand calculation
20:43 Heffalump you can certainly turn annotate from being O(length of history) into O(1) [per line] by pre-calculating the result
21:12 gh_ Heffalump, have you tried to build the current darcs HEAD under windows? I am getting compile errors with Ben's encoding changes. I suspect they have never been tested under windows.
21:14 Heffalump gh_: no, I'll have a quick look. Bit short of time at the moment though :-(
21:41 gh_ Heffalump, me too :D also I'm running a slow windows OS within a virtual box :/
21:42 gh_ I'll see what I can do this weekend. bye!
21:48 sm_ joined #darcs
21:50 Cthulhux` joined #darcs
21:55 Heffalump I have a build error too. Seeing if darcs test --linear can find it.
21:55 Heffalump (maybe you already know the triggering patch, but this is a cheap way to re-check anyway)
23:11 Mysterious_Light darcs handles UTF8, however, I have some troubles with darcs whatsnew with non-ASCII UTF8 characters. For example, em-dash (—) is well-printed by darcs annotate, but is represented with red-highlighted <U+00E2><U+0080><U+0094> by darcs whatsnew. Can it be fixed? using darcs 2.12.5, gnome-terminal.
23:53 Mysterious_Light joined #darcs
23:59 pointfree joined #darcs
23:59 siel joined #darcs

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