Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2015-09-30

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

All times shown according to UTC.

Time Nick Message
01:01 IcyFoxy Heffalump: Re parallelizing again, Is there any reason that various objects cannot be partioned for the commuting? I.e. On the primitive patch level, a change to file A doesn't need to do anything but with the history of file A. Directory structure is the only remaining dependency at this point. With the exception of the named/unnamed patches (which IIRC are the 'commits' that call in the primitive patches
01:01 IcyFoxy which commute works against directly)
01:05 IcyFoxy Heffalump: Re, Issue/PR integration; as I'm thinking for decentralised infrastructure, this will be a must. The CI would be either the developers signing having compiled and tested a merge before it is accepted. In any case the organisation/official repository could be guarded by PR rules. Again with the DHT backend, everyone would sync and pull. No pushing. The PRs would be a ghost merge between the master
01:05 IcyFoxy and the desired new head - emphasising on the differences between the two branches.
01:07 IcyFoxy Then if you look at good bots on GitHub. @homu or @bors, both PR tracking bots in the rust community. @homu r+ tells homu that the PR has been approevd and it'll merge for travis and get it to build it. Accepting a PR is reversed if another PR merges first preventing undesired automated conflict generation.
01:08 IcyFoxy With darcs, the conflicts are less of an issue here due to the patch level, vs snapshot level of git. However, we still want some repository moderator (or an automated bot) to provide the build && test results at a minimum. These results would then be tracked directly by darcs.
01:09 IcyFoxy Is coalesce used for cleaning up the output of amend-record?  I can see how considering the merge property.
01:09 IcyFoxy When else is coalesce used?
02:10 mizu_no_oto joined #darcs
05:12 Heffalump IcyFoxy: I see, so you break up patches into primitives and commute those? OK, sounds plausible that you'd get a fair amount of parallelism then.
05:14 Heffalump IcyFoxy: I think coalesce is implicitly used as part of record, but it's just an engineering detail there - there's some slightly convoluted arrangement where it first constructs a hunk that's basically "remove entire old contents of file, add entire new contents", then invokes diff from inside coalesce or something
05:15 Heffalump for amend-record it's important because otherwise if you have a 5 line hunk in the original patch, then you change one word in the new contents of the hunk and record again, you'd end up with two hunks instead of one
05:15 Heffalump coalesce is also used in rebase, but I doubt you'd care about that initially
05:15 Heffalump I can't think of any other uses off the top of my head
05:26 IcyFoxy Heffalump: Thanks.
05:28 IcyFoxy Aren't the patches already separate from the primitives? I was using Prim.v3 as a reference and it looks like they are already separate? As for the partitioning, this could be done per file and then concurrently work on each file (or directory, maybe after all it's files have been handled already).
05:30 IcyFoxy Moving a file 'foo' from a/foo to b/foo crosses over directory-level contexts.
05:33 IcyFoxy 3. a, b, foo must all exist at the point they are aligned to. One problem would be if Alice removes dir /b; while Bob moves a file from / to /b/. When these two branches are merged. Bob moves file from / to /b/ then alice removes it. I feel like move will need to have extra checks **like this** such that merging branches like this would notify about the file going from the visible /foo to /b/foo where /b/ a
05:33 IcyFoxy nd subsequently /b/foo is removed.
05:35 IcyFoxy Another useful detail I'd like to have is the ability to mount deleted objects into their last existing state. I.e. /.darcs-archive/b/foo can be accessed without rolling back. (Such directory would need to be manually configured to exist)
05:35 IcyFoxy And would likely have b-UNIQUE_IDENT/foo-UNIQUE_IDENT format.
05:37 IcyFoxy Heffalump: In the alice/bob /foo -> /b/foo case. Maybe the merge should conflict because for Alice to remove /b/ she needs to delete it's contents too. Which is foo is a new file in that directory that she hasn't deleted - then she hasn't met the ability to delete the directory.
05:49 IcyFoxy ^ I think the latter is what is happening; so that case would cause a mereg conflict.
10:11 gh_ joined #darcs
10:12 IcyFoxy Hmm... Quick test. darcs rebase suspend; select 3 patches; yynnny. darcs rebase pull; select all; darcs rebase apply; low CPU usage, low RAM usage and appears hung.
10:12 IcyFoxy ^ Against darcs-2.10
10:14 IcyFoxy strace says the only syscall is FUTEX_WAIT_PRIVATE, repeating many times; with only a single write every second or so.
10:16 gh_ IcyFoxy, maybe darcs is trying to download some patch from some unreliable source? what does " darcs show repo |grep Cache" say?
10:16 IcyFoxy Networking is not an issue. The repository is already up to date. I just decided to test out rebase.
10:16 IcyFoxy I'll repeat this in a more reproducable way.
10:20 gh_ IcyFoxy, we already had some surprising cases where darcs tries to read more history than needed and starts opening/downloading patches like crazy
10:20 IcyFoxy Strange
10:22 gh_ IcyFoxy, yes, it was caused by interactive selection code wanting an FL while reading the repo gives an RL so you have to reverse and invert everything
10:22 gh_ (in case you know about FL's and RL's)
10:23 IcyFoxy Well... I've just done a darcs clone --lazy; darcs rebase suspend (selected 6/7 of the patches); darcs apply and now I have 6 instances of 'darcs rebase apply' appearing in htop. No networking on any of them. CPU 0.5% mem 0.2% time spent increasing.
10:23 IcyFoxy I've been focusing on commuting with my darcs implementation, I've seen FL and RL and don't quite know what they expand to. I'm expecting Forward, Backwards ... L-something.
10:25 The^One forward list, reverse list I think
10:26 gh_ yes, that's what it means
10:30 IcyFoxy Ah list
10:30 IcyFoxy Thanks
10:31 gh_ definitions of FL and RL are here https://hackage.haskell.org/package/darcs-2.10.1/docs/Darcs-Patch-Witnesses-Ordered.html
10:32 IcyFoxy I've noticed.
10:32 IcyFoxy A friend just asked me what :> was and I referenced that file and suggested the documentation
10:32 IcyFoxy Thanks for the link ;)
10:32 gh_ great :)
10:32 IcyFoxy ^ Perfect timing :P
10:33 IcyFoxy So FL = :>, BL = :< ?
10:34 IcyFoxy Ah :>: vs :<:, not :> or :<
10:34 IcyFoxy Subtle
10:39 IcyFoxy gh_: Any idea what the 'darcs rebase apply' is hanging in? Again. Isn't trying to touch networking.
10:39 gh_ IcyFoxy, not really, I'm not familiar with this command sorry
10:39 gh_ got to go!
10:39 IcyFoxy Gone fast
10:59 mizu_no_oto joined #darcs
11:17 mizu_no_oto joined #darcs
11:52 gal_bolle joined #darcs
12:30 IcyFoxy Heffalump: 2 base lists to track with my current design. Primitives: Directory structure, file changes (per backed file identifier); Named: tracking cross file primitive groups and commit messages.
12:34 IcyFoxy That with detached hunks (reference until actually applying or optimizing down (coalesce)), I'm hoping for at least better large scale performance. Unsure for where exactly darcs' merging/conflict issues are, so no comment on that part (for now).
12:37 IcyFoxy '2' lists, while the former is concrete, and the second is really N directories + M files; so 1+dirs+files. Only touching lists when their objects are relevant to the operation.
15:24 thorkilnaur joined #darcs
16:51 ilbot3 joined #darcs
16:51 Topic for #darcs is now http://darcs.net/ | logs: http://irclog.perlgeek.de/darcs/ | darcs 2.10.0 is out http://darcs.net/Releases/2.10
18:22 Heffalump IcyFoxy: "named patches", i.e. the things with comments you see in the UI, are made up of a bunch of primitive patches
18:22 Heffalump you need to know whether all the primitive patches commute successfully to know if the entire named patch does, if it doesn't then you have to reject the commute
18:23 Heffalump for merges you can still merge even if some fail (if you have conflicts in your patch type, e.g. the RealPatch layer in Darcs.Patch.V2), but you still need to reassign the results to the right named patches
18:24 Heffalump I don't know what's wrong with darcs rebase apply - how big was your repo?
18:24 Heffalump btw for PRs, the darcs equivalent of a PR is much more lightweight, it's just sending a patch
19:12 sm IcyFoxy: also, does the rebase hang in a non-lazy repo ?
19:17 Heffalump what do people think about implicit parameters in the darcs code? (I may have asked this before...) I know they get a bad press, but I think they're a great way of passing down configuration without making things too noisy
19:25 burp_ joined #darcs
19:51 sm I'm probably typical in never have used them for real and being a bit unclear on where they are a win
19:51 sm I don't work with the darcs code enough to know
19:53 sm they add to the unfamiliar new things darcs contributors must deal with. But, as someone said here recently that seems can be an attraction
19:55 sm I wonder how many projects on hackage use them
21:43 gh_ joined #darcs
22:49 mizu_no_oto joined #darcs
23:52 Riastradh joined #darcs

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