Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2014-06-21

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

All times shown according to UTC.

Time Nick Message
00:27 capicue joined #darcs
01:19 mizu_no_oto joined #darcs
01:26 mizu_no_oto joined #darcs
01:38 edwardk joined #darcs
02:44 favonia joined #darcs
03:33 frozencemetery joined #darcs
03:34 frozencemetery reading over the darcs source, I see lines like "import Prelude hiding ( pi )", but pi is never used as an identifier.  What's the purpose of hiding pi here?
06:25 lelit joined #darcs
08:11 vikraman_ joined #darcs
08:15 vikraman_ joined #darcs
09:16 Bahoz joined #darcs
09:20 mornfall frozencemetery: pi is short for patchinfo
10:06 mizu_no_oto joined #darcs
10:07 mizu_no_oto joined #darcs
10:09 vikraman joined #darcs
10:42 agrafix joined #darcs
10:44 agrafix left #darcs
10:48 Heffalump frozencemetery: it was probably used as a parameter name or local variable, rather than a top-level definition. The hiding import avoids warnings about name shadowing.
10:55 mizu_no_oto joined #darcs
10:58 agrafix joined #darcs
11:02 agrafix joined #darcs
12:14 agrafix left #darcs
13:17 xstill joined #darcs
14:42 mdiaz joined #darcs
14:50 Heffalump hi mdiaz
14:51 mdiaz Hi heffalump
14:51 Heffalump I'm just trying out Guillaume's script. Do you happen to know a simple way to override the global cache folder?
14:52 mdiaz What do you mean by "override the global cache folder"?
14:53 Heffalump tell darcs to use a different one for this command
14:54 Heffalump I can probably override APPDATA (since this is Windows) but I'm not sure what else that might affect
14:54 mdiaz Ah, no I don't know.
15:09 Heffalump ok, so you want to introduce bucketed cache even if there's no performance improvement? I sort of agree particularly as cache directories can be very hard to look at with the huge number of files (as Guillaume said)
15:09 Heffalump would darcs still read the non-bucketed cache?
15:11 mdiaz Using the patch I sent, no.
15:12 Heffalump I think it would need to do that at a minimum, because otherwise users getting a new version would suddenly lose their existing cache
15:14 mdiaz They can migrate to bucketed manually, using a subcommand of optimize for example.
15:14 Heffalump how would they know to do that?
15:16 mdiaz In the release notes, googling? :)
15:16 Heffalump hmmm...
15:16 Heffalump generally things in darcs should just work
15:19 mdiaz If you think that the best way is by changing the code to support both versions, I have no problems doing so.
15:20 mdiaz But I'm not sure if it's the best way.
15:20 Heffalump what's the argument against doing that?
15:23 mdiaz I think the code will give more messy.
15:25 mdiaz Also at some point we need to make the migration to bucketed, right?
15:26 Heffalump migrate in the sense of stop reading the unbucketed one?
15:26 mdiaz Yes. I think that an automatic migration would affect performance.
15:27 Heffalump I'm not suggesting an automatic migration per se, just that we should still look for unbucketed files as well as bucketed ones, so people's existing cache doesn't suddenly become ineffective
15:27 Heffalump so we wouldn't actively move the unbucketed files, just read them
15:29 mdiaz Okay, that might work better.
15:30 mdiaz The original idea was to make an automatic migration.
15:31 Heffalump yeah - that would be relatively complicated and I agree there's a case for not having the complexity
15:33 Heffalump but I don't think we can just leave abandon old caches completely, we should make things as easy as possible for users
15:36 mdiaz Then I make possible to read both caches, but leaving the option to manually migrate to bucketed?
15:36 Heffalump that sounds reasonable
15:36 Heffalump so the reading code would look for both the bucketed and the unbucketed file
15:36 Heffalump hmm, I guess the other downside of that is that it might slow it down
15:37 mdiaz Yes..
15:37 mdiaz Or we can try both versions.
15:39 Heffalump did you make some benchmark scripts?
15:40 mdiaz No, but I was thinking in something like Guillaume's script.
15:41 Heffalump how have you been benchmarking?
15:45 mdiaz Cloning the ghc-old repository a lot of times.
15:46 mdiaz As Guillaume did.
15:48 Heffalump it's important to have something reproducible - it takes a bit longer to get it setup initially but it makes it much easier to experiment with alternatives
15:49 mdiaz Oki. You managed to run his script?
15:50 Heffalump yes, that worked, but I'm not sure how to use it in a very streamlined way as I didn't manage to override the global cache (I had to move mine aside instead)
15:50 Heffalump though the tests must be doing it properly
15:51 Heffalump in an ideal world there'd be one script I could run that would isolate everything and collect all the relevant numbers we care about for my platform
15:54 mornfall you know, you could also re-use darcs-benchmark...
15:54 mornfall (the way it isolates global cache is by overriding $HOME...)
15:54 Heffalump right, we discussed that before
15:54 capicue joined #darcs
15:55 Heffalump mornfall: according to darcs help environment you need to override APPDATA on windows.
15:56 mornfall yeah, I don't think anybody tried to benchmark on windows seriously before now
15:56 Heffalump but the tests do work on Windows so they must be doing the right thing somehow
15:57 mornfall it uses the DARCS_TESTING_PREFS_DIR hack
15:58 Heffalump ah yes
15:58 mornfall there is probably a way to override APPDATA on windows, but I don't think anyone figured it out
15:58 Heffalump anyway, good reminder about darcs-benchmark - mdiaz, if you can reuse and/or extend that, it would be ideal
15:58 Heffalump Guillaume also mentioned extending cabal bench
16:00 Heffalump s/extending/adding/
16:00 Heffalump but that's probably overkill for now
16:02 mdiaz I'll try. Returning to bucketed cache, how I make it? :).
16:03 frozencemetery mornfall: Heffalump: thanks!
16:03 frozencemetery left #darcs
16:03 Heffalump mdiaz: what do you mean?
16:07 mdiaz1 joined #darcs
16:08 mdiaz1 I do it so it can read both caches or not?
16:08 Heffalump I think that's probably the best compromise.
16:09 Heffalump but I'm not certain. I definitely don't think just abandoning the old cache is a good idea, though perhaps if we detected that situation and printed a warning message telling the user to migrate, it would be ok
16:09 Heffalump another option would be to detect whether the user has migrated or not, and use either the old cache or the new cache.
16:09 Heffalump that would also have the advantage of being better for darcs developers themselves, who might be switching between new and old versions of darcs
16:10 mornfall this also happens to anyone with $HOME on NFS
16:11 gh_ joined #darcs
16:11 Heffalump hi gh_
16:11 mornfall it also has the interesting side-effect of making the performance characteristics different from local filesystem cache
16:12 mdiaz1 Ok. I've to go for lunch. I'll come back later.
16:23 gh_ hi
16:23 Heffalump hi. We were just discussing bucketed cache migration strategies
16:41 agrafix joined #darcs
16:41 agrafix joined #darcs
16:49 gh_ joined #darcs
16:50 gh_ a possible way of "detecting" it: on all platforms except windows, we had a change of global cache path in darcs HEAD (~/.darcs/cache to ~/.cache/darcs)
16:50 gh_ maybe we can assume old path is unbucketed (and shall be used read-only) and new one is bucketed?
16:51 Heffalump oh, that's why your script made the wrong structure :-)
16:51 mdiaz joined #darcs
16:51 Heffalump I'm not sure we need to be too clever like that, if we just want to be able to detect it we can write out a file named "bucketed-cache"
16:51 Heffalump I hadn't realise/had forgotten about the change of the global cache path. How is the transition managed there?
16:54 mdiaz My patch only considers the current path (for now).
16:55 mal`` joined #darcs
16:58 gh_ Heffalump, it just keeps the old cache as read-only
17:00 gh_ http://hub.darcs.net/darcs/darcs-screened/patch/20130719102601-5ef8f
17:06 mdiaz joined #darcs
17:06 Heffalump ok, so it'll look in both
17:07 gh_ I mean, seen from the point of view of end users, who only use official releases, darcs 2.8.4 uses unbucketed cache at ~/.darcs/cache, and 2.10 can use bucketed cache at ~/.cache/darcs , using the old path as read only (and we may provide some "darcs optimize cache" command that handles the migration)
17:13 gh_ hmm environmentHelpHome help string is outdated..
17:15 gh_ as for windows, we can use, say, %APPDATA%\\darcs\\cache2 as the new path
17:17 gh_ I think it's enough of a migration for a cache.
17:20 agrafix joined #darcs
17:20 agrafix joined #darcs
17:22 agrafix joined #darcs
17:23 agrafix1 joined #darcs
17:25 agrafix joined #darcs
17:25 gh_ left #darcs
17:26 agrafix1 joined #darcs
17:27 agrafix joined #darcs
17:28 agrafix joined #darcs
17:29 agrafix joined #darcs
17:30 agrafix joined #darcs
17:31 agrafix joined #darcs
17:32 agrafix joined #darcs
17:33 agrafix joined #darcs
17:34 agrafix1 joined #darcs
17:35 agrafix joined #darcs
17:36 agrafix joined #darcs
17:37 agrafix joined #darcs
17:38 agrafix joined #darcs
17:39 agrafix joined #darcs
17:40 agrafix joined #darcs
17:42 agrafix joined #darcs
17:43 agrafix joined #darcs
17:43 agrafix joined #darcs
17:45 agrafix joined #darcs
17:46 agrafix joined #darcs
17:47 agrafix joined #darcs
17:48 agrafix joined #darcs
17:48 agrafix joined #darcs
17:49 agrafix joined #darcs
17:50 agrafix joined #darcs
17:51 agrafix joined #darcs
17:54 agrafix1 joined #darcs
18:04 gh_ joined #darcs
18:10 mizu_no_oto joined #darcs
18:11 mdiaz joined #darcs
18:11 agrafix joined #darcs
18:12 agrafix joined #darcs
18:13 agrafix joined #darcs
18:14 agrafix joined #darcs
18:15 agrafix joined #darcs
18:16 agrafix joined #darcs
18:17 agrafix joined #darcs
18:18 agrafix joined #darcs
18:19 agrafix joined #darcs
18:20 agrafix1 joined #darcs
18:20 amgarchIn9 joined #darcs
18:21 agrafix joined #darcs
18:22 agrafix joined #darcs
18:40 gh_ Heffalump, the 2-folders approach enables migration to be delayed, while still taking advantage of the existing cache
19:00 capicue joined #darcs
19:08 pointfree-w530 joined #darcs
19:59 amgarchIn9 joined #darcs
20:12 edwardk joined #darcs
21:42 edwardk joined #darcs
22:13 gh_ joined #darcs
22:40 gh_ Heffalump, and I would see a future "darcs optimize cache" command as a way of both 1) migrating unbucketed global cache (if it exists) to bucketed 2) garbage collecting the global cache

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