Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2014-04-24

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

All times shown according to UTC.

Time Nick Message
00:14 lambdabot joined #darcs
00:57 c74d joined #darcs
01:26 c74d3 joined #darcs
01:45 c74d joined #darcs
03:17 edwardk joined #darcs
04:00 c74d joined #darcs
04:54 haasn joined #darcs
05:23 c74d joined #darcs
06:10 lelit joined #darcs
06:37 slyfox joined #darcs
06:37 slyfox joined #darcs
06:39 Heffalump I've tagged 2.9.9 to include the hashed-storage merge
07:03 bishboria joined #darcs
07:08 raichoo joined #darcs
08:36 schlaftier joined #darcs
09:14 gal_bolle joined #darcs
09:23 owst joined #darcs
09:33 xstill joined #darcs
09:53 slyfox^w_ joined #darcs
09:54 slyfox^w_ i've got a workaround for http://bugs.darcs.net/issue2364 for ghc-7.8 but need an advice how to fix it properly
09:56 slyfox^w_ AFAIU darcs has a global cache ~/.darcs/cache, which gets populated via speculateFileOrUrl
09:56 slyfox^w_ but that function first creates empty file there, and then downloads contents there
09:57 slyfox^w_ if copyFileOrUrl will start on the same URL, then tit will copy partially downloaded globally cached file and get broken repo
09:58 slyfox^w_ i've worked it around by making specilate a synchronous operation: https://github.com/gentoo-haskell/gentoo-haskell/blob/master/dev-vcs/darcs/files/darcs-2.8.4-fix-nonatomic-global.patch
09:58 slyfox^w_ but real fix would be to: 1) populate global cache atomically, 2) dont send copyFileOrUrl URL fetch request until speculate finishes on the same URL
09:59 slyfox^w_ does that make any sense?
10:06 owst What's the "workflow" for calling speculateFileOrUrl and copyFileOrUrl?
10:06 owst I.e. how does darcs call those functions?
10:08 slyfox^w_ http://code.haskell.org/~slyfox/l - it's the precise log
10:08 slyfox^w_ oh, sorry. it's already working one
10:08 slyfox^w_ i'lle recreate buggy version right now
10:09 owst Can you just explain it in few words? What's the point of the functions and what's the expected control flow between them?
10:10 slyfox^w_ ah, 'speculate' seems to "prefech" files "in advance" into global cache right from "tentative" (as they will be first what user needs), when 'copy' asks files to be fetched into working directory (synchronously)
10:11 raichoo joined #darcs
10:12 owst 'right from "tentative"' what do you mean?
10:15 slyfox^w_ sorry, the file for prefetch is called "hashed_inventory" (should be 'right from "hashed_inventory"')
10:19 owst Right, so darcs makes a bunch of asynchronous speculative downloads depending on the contents of hashed_inventory. Later, it tries to copy the files into the repo, but since they may not have finished downloading it can take an incomplete version of the file.
10:20 owst I think the fix would be to ensure that the copy is blocked until the async download has finished
10:20 owst Wait, is there actually async download going on? How is that handled? Do we spawn some threads to do the download or somesuch?
10:22 raichoo1 joined #darcs
10:31 slyfox^w_ there is one downloading job (urlNotifications async download completion Mvars), but when file is in cache it's just get picked from there
10:33 alexei___ joined #darcs
10:40 owst And the problem is the file is in cache even though its not completely downloaded?
10:44 slyfox^w_ yes: http://bpaste.net/show/230305/ - here 2e5a856e74ebea0de850ed9a17f45b534b43af38d0f77a94a88c5c6abe2a4a4a hets speculated and instantly "downloaded" of size zero
10:44 slyfox^w_ s/hets/gets/
10:50 owst Hmm, I'm having a tough time reading that log. I had a feeling that files get downloaded to $NAME-new or something like that, and upon completion, renamed (atomically) to remove the suffix.
10:50 owst Why is the file succeeding download and being empty?
10:51 owst Is the connection dropping out?
10:52 slyfox^w_ nope, it's a persistent error. file gets downlaoded correctly
10:52 slyfox^w_ it's get copied before download is finished
10:58 owst So the file isn't succesfully downloading with size 0, it's just that the copy happens before the download has finised?
11:01 raichoo joined #darcs
11:31 Heffalump on a different tangent, I was wondering about replacing our download code with wreq
11:36 owst Yes, that also occurred to me
11:37 Heffalump I think that's the right long-term approach, but if we have a short-term workaround (I didn't read the thread above in detail) then we should probably go with it
11:48 owst Indeed. I wonder if it handles queuing and connection pooling and keep-alive type stuff, or if we'll need a wrapper around it
12:16 gal_bolle joined #darcs
12:58 slyfox^w_ i've found even shorter workaround
12:59 slyfox^w_ random intermediate temp tiles for download are not really random
13:04 owst In what way, slyfox^w_ ?
13:10 slyfox^w_ http://dpaste.com/1794461/ - on each download iteration the junk part of temp file was the same
13:22 gh_ joined #darcs
13:26 owst How does that fix the issue?
13:33 gal_bolle joined #darcs
13:47 c74d joined #darcs
13:49 mizu_no_oto joined #darcs
13:52 c74d joined #darcs
14:21 c74d joined #darcs
14:48 raichoo joined #darcs
14:58 alexei___ joined #darcs
15:03 byorgey_ joined #darcs
16:00 gh_ joined #darcs
16:17 mizu_no_oto joined #darcs
16:44 edwardk joined #darcs
17:05 alexei___ joined #darcs
18:02 favonia joined #darcs
18:09 gal_bolle joined #darcs
18:17 mizu_no_oto joined #darcs
18:33 whaletechno joined #darcs
18:42 raichoo joined #darcs
18:43 alexei___ joined #darcs
18:46 gh_ how do I check (in Haskell) whether a remote ssh-accessible host has a darcs executable?
18:48 mornfall gh_: I'd go with trying to run it.
18:53 lelit joined #darcs
19:03 favonia joined #darcs
19:05 c74d joined #darcs
19:05 n-dolio joined #darcs
19:08 c74d joined #darcs
19:10 gh_ mornfall, yeah, I went for running 'darcs --version' and checking the error code
19:10 gh_ *exit code
19:11 Heffalump might be useful to capture the --version simultaneously
19:14 haasn joined #darcs
19:30 c74d joined #darcs
19:32 gh_ joined #darcs
19:37 gh_ I'm on http://bugs.darcs.net/issue1066
19:55 Heffalump was just thinking that if you're making a library call that returns Bool and is implemented that way, it could return Maybe String or similar instead
20:00 gh_ Heffalump, yes probably
20:55 favonia joined #darcs
20:56 owst joined #darcs
20:56 owst evening all
20:57 owst gh_: around?
21:04 schlaftier joined #darcs
21:06 schlaftier joined #darcs
21:18 Heffalump owst: presumably slyfox^w_'s patch fixes the issue by avoiding clashes in those filenames
21:21 alegadea joined #darcs
21:22 owst Oh, I didn't realise it was a clash that was a problem.
21:23 owst I'm not sure I understand where the clash is coming from, but oh well :-)
21:24 owst Heffalump: how do you feel about darcs move recognising post-hoc moves, where the target is known to darcs already. I'll explain the intended semantics:
21:24 owst *darcs knows a recorded version of foo*
21:24 owst *darcs knows a recorded version of bar*
21:24 owst mv bar foo
21:25 owst *oops, need to tell darcs that*: darcs mv bar foo
21:25 owst which would: add to pending the rm of recorded foo, and then move of bar -> foo
21:25 Heffalump owst: that was how I understood slyfox^w_'s statements, but I could be confused
21:26 Heffalump how common is doing mv to overwrite a recorded file?
21:26 Heffalump but this is just a generalisation of the existing behaviour of 'darcs mv', right? i.e. making it correct in the overwrite case
21:26 Heffalump if so that seems sensible just to make it more consistent
21:27 Heffalump though it should probably print a message telling the user that
21:27 owst Yeah, it allows you to recognise post-hoc moves into unknown files, but not overwriting known files.
21:28 owst I've just added behaviour to allow you to move known files into known, but deleted in working, files
21:29 Heffalump I think I would classify all this as bugfixes rather than new features
21:30 owst Cool, yeah, I felt it was a bug that I couldn't do the latter, but the former just seemed sensible, when I figured out what each combination of file status should do
21:30 Heffalump but I do think it would help the user if you tell them about the rm
21:31 owst Yeah, I think so too
21:54 owst The question is, what should the rm message say - I want it to not sound scary! :-)
22:03 owst N.B. The target path `bar' is recorded in the repository, but deleted in the
22:03 owst working directory. To ensure consistency of the move patch, patches will be
22:03 owst prepended that reflect this deletion.
22:03 owst Not sure how that sounds - any opinions?
22:19 edwardk joined #darcs
22:24 lelit joined #darcs
22:46 owst Argh - just wasted ages trying to figure out why cabal suddenly complained about not being able to find a .cabal file.
22:47 owst I had previously added the in-house hashed-storage as a sandbox source, and then pulled Ganesh's patches that inlined hashed-storage to the darcs cabal file.
22:48 owst cabal tries to read a cabal file for each source that has been added. Since it'd been deleted for hashed-storage it couldn't find it. Solution: cabal sandbox delete-source hashed-storage
22:48 owst d'oh
23:21 xstill joined #darcs
23:38 owst Kind incompatibility when matching types:
23:38 owst FreeLeft (FL prim) :: * -> * -> *
23:38 owst FreeLeft (FL prim) :: *
23:38 owst Ughhh, I give up - bed!
23:49 owst joined #darcs

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