Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2015-09-28

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

All times shown according to UTC.

Time Nick Message
00:06 mal`` joined #darcs
01:18 mizu_no_oto joined #darcs
01:34 c74d3a joined #darcs
01:41 sea-gull joined #darcs
01:49 haasn` joined #darcs
02:00 Riastradh joined #darcs
02:51 mizu_no_oto joined #darcs
03:05 IcyFoxy Heffalump: I've been using the V3 Prims as a reference. It definately throws around the full Hunks. I'll be detaching the Hunks in my implementation.
03:06 IcyFoxy Camp was my first reference, but I found darcs to be much more useful.
03:19 IcyFoxy Heffalump: Another idea that I've had, unsure for how effective it would be. Multiple threads for commuting patches (I.e. each working on different UUIDs) at once.
03:20 * IcyFoxy wants darcs to be fast. ^ And likely to get writing haskell code again. :-)
04:43 c74d3a joined #darcs
05:04 Heffalump IcyFoxy: cool :-) (re making darcs fast/writing Haskell)
05:04 Heffalump IcyFoxy: I'm not sure about parallelising, because most reordering operations are inherently linear - to figure out what to reorder next you need the results of the last one
05:05 Heffalump but I could be wrong about that
05:05 Heffalump do you actually want to work on the darcs codebase then? There's almost certainly plenty of opportunities for speedups there.
05:32 IcyFoxy Heffalump: I do. However, right now - I'm interested in porting the core to Rust as my use-case is too different. But yes, I am very interested in working on Darcs' codebase. *Just not yet*.
05:33 IcyFoxy Writing from scratch also gives me a better understanding on what is going on under the hood.
06:08 Heffalump yeah, makes sense
06:39 dolio You'd probably want to find out what's actually slow, too.
06:39 dolio I built a profiling darcs a few days back, and ran it on a no cache checkout of darcs.net.
06:39 dolio And it spent most of its time doing gzip.
06:39 dolio Reportedly, at least.
06:40 dolio That might be specific to get, though.
08:38 IcyFoxy dolio: I suspect too much time is spent copying the hunks around for every invert and commute. So a definate thing will be trying detached hunks.
10:19 gh_ joined #darcs
10:56 mizu_no_oto joined #darcs
11:03 mizu_no_oto joined #darcs
11:06 mizu_no_oto joined #darcs
11:47 thorkilnaur__ joined #darcs
13:10 IcyFoxy Far from complete but progress.  https://gist.github.com/james-darkfox/b5188b0ad8457114ea7b
13:14 IcyFoxy ^ Feedback would be very much appreciated. I'm implementing darcs in Rust and I need to know if I'm doing things right. :)
13:16 IcyFoxy Line 32, just noticed I don't add the remaining patches after commuting fails.
13:21 Riastradh joined #darcs
13:26 IcyFoxy Actually; should fail as it failed to reach the desired context.
14:13 byorgey joined #darcs
14:34 IcyFoxy Heffalump: As for the parallelizing, it would need grouping. I.e. Commute task per UUID altered. Filtered down to just that UUID and once applied, update the main tree. This would need benchmarks regardless, and I'm curious for what the possible results might be.
14:39 IcyFoxy ^ Groups to prevent overlaps from the results of each commuting task. However, the times where any speedup would occur are rare: large merges, anything else? Cloning into an old tag, maybe? It doesn't need to re-order, but the applying could be multi-threaded.
18:12 Riastradh joined #darcs
18:22 aristid_ joined #darcs
18:53 sm IcyFoxy: nifty.. does it work ?

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