Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2014-04-27

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

All times shown according to UTC.

Time Nick Message
02:04 gh_ joined #darcs
03:32 mizu_no_oto joined #darcs
03:59 gh_ joined #darcs
05:50 slyfox joined #darcs
05:50 slyfox joined #darcs
07:01 raichoo joined #darcs
07:03 bishboria joined #darcs
07:26 lelit joined #darcs
08:03 alexei___ joined #darcs
08:57 alexei___ joined #darcs
10:41 owst joined #darcs
11:18 c74d joined #darcs
14:42 owst joined #darcs
15:13 sm go slyfox, go owst
15:47 pointfree-w530 joined #darcs
16:15 hvr yey, compiling darcs HEAD "just works"
16:17 hvr I'm currently running a repeated one-shot darcs-to-git mirror job of the style
16:17 hvr $DARCS get --no-working-dir --complete --repodir=tmp.transformers.darcs  http://code.haskell.org/~ross/transformers
16:17 hvr git init --bare tmp.transformers.git
16:17 hvr (cd tmp.transformers.darcs && $DARCS convert --export --quiet) | (cd tmp.transformers.git && git fast-import --quiet > /dev/null)
16:17 hvr does this make sense?
16:18 hvr (the result can be seen at http://git.haskell.org/darcs-mirrors/transformers.git )
16:20 owst hvr: looks sensible to me
16:21 hvr I noticed that 'git fast-import' has the --done option
16:22 hvr but darcs convert --export doesn't seem to produce the expected 'done' command?
16:23 owst I'm not surprised - the fast-convert format spec has no doubt changed since the --export command was originally coded
16:23 alexei___ joined #darcs
16:23 owst What does --done do?
16:23 hvr the man-page says:
16:23 hvr "Terminate with error if there is no done command at the end of the stream. This option might be useful for detecting errors that cause the frontend to terminate before it has started to write a stream.
16:24 owst I see. As a hack you could manually concatenate one of the correct form before piping into git.
16:25 hvr or I could just not use '--done' :-)
16:25 owst Not sure what sort of errors it's alluding to anyway :-)
16:25 owst Yeah, or that ;)
16:25 hvr I guess it's just for detecting a truncated command stream
16:25 hvr like an explicit EOF
16:27 hvr anyway, doing that fast export/import thing is ridiculously fast; runs in under 2-3 secs
16:28 owst Yeah, darcs repos are pretty simple for the exporter to handle
16:28 hvr and luckily the two darcs repos for wich I need a Git view are rather small :)
17:06 alexei___ joined #darcs
17:19 sm what does --complete do ?
17:21 gh_ sm, nothing really different that not passing --lazy to get, except that now (in HEAD) it no longer tolerates CTRL+C
17:23 Heffalump what was the idea behind that, out of interest?
17:23 sm gh_: so it disables ctrl-c  ? interesting
17:23 gh_ so dow it's:  1. no flags: get basic + complete repo, tolerates CTRL+C on complete step 2. --lazy: get basic repo 3. --complete: get basic + complete repo, does not tolerate CTRL+C
17:24 gh_ s/dow/now
17:24 gh_ Heffalump, this help me do the new implementation of `put` (http://bugs.darcs.net/patch1145)
17:26 gh_ Heffalump, because the new implementation requires that a local complete repository be created. If the --complete mode was ctrl+C'able, the clone-to-ssh operation would still carry on as if nothing happened.
17:26 gh_ Heffalump, I first wanted the relevant functions to return a Boolean telling whether cloning went _really_ complete, but that ended up being ugly
17:29 Heffalump ah, I see
17:31 gh_ Heffalump, and now, one can also check the exit code of get --complete to see whether it was interrupted
17:32 Heffalump makes sense
17:32 Heffalump owst: at least you can do the hashed-storage hacking without lots of fiddling around :-)
17:35 owst Heffalump: indeed so
17:35 owst Doing some cabal hacking instead at the moment :-)
17:36 owst Which is related - I missed that hashed-storage was inlined, so my add-source dep wasn't needed, but cabal doesn't really tell you its looking for the .cabal file for the dep, rather than the main project
17:36 owst s/wasn't/was no longer/
17:37 raichoo joined #darcs
17:38 Heffalump this is the problem you mentiond a couple of nights ago, or a different one?
17:47 owst Yeah I found it a couple of nights ago, haven't had a chance to look into it.
18:13 alexei___ joined #darcs
18:37 gh_ joined #darcs
18:37 dolio joined #darcs
18:46 owst First cabal patch submitted \o/
18:54 Heffalump sm: couple of patches for darcsden in my branch on hub - just updates for recent darcs HEAD
19:29 owst joined #darcs
19:30 owst gh_: http://bugs.darcs.net/msg17378 can you check this again please?
19:52 alexei___ joined #darcs
20:20 owst joined #darcs
20:39 owst Say a user does this, assuming foo is already recorded: 1) rm foo 2) mkdir foo 3) darcs wh 4) darcs rec. Currently, darcs just fails at 3) (not sure about 4)), and is stuck until foo is renamed. I think whatsnew and record should show a warning, and the behaviour should be to act as if the removal was recorded, before the directory was added, but without requiring anything of the user.
20:39 owst What do people think?
20:40 owst (also, if I the behaviour I say is implemented, I don't think the contents of teh directory should be automatically added, but darcs shouldn't complain if the user explicitly adds them)
20:41 owst Or, we could not be that clever, and refuse to do anything until the directory is renamed away, but present a nice error message
20:43 Heffalump what about if 3) is 'darcs add foo'
20:43 Heffalump I think it's fine to treat it as a removal of foo though, that's what would happen without the mkdir
20:45 owst If 3) is add, darcs currently fails saying that foo is already in the repository
20:45 Heffalump that's also broken, I think
20:45 owst Yeah, me too
20:45 owst So presumably, we'd have to add some patches to pending that removed the file foo
20:46 Heffalump or treat it as if they are in pending
20:46 Heffalump in your original scenario, I think darcs should behave very similarly if the new directory is 'foo' to if it is 'bar'
20:47 owst Hmm, good point.
20:47 Heffalump oh, yes, definitely has to go into pending
20:47 Heffalump in the darcs add case, because 'darcs add foo' means "put mkdir foo in pending"
20:48 owst So should whatsnew warn, or quietly add the hunk/rmfile to pending?
20:48 owst I'd argue whatsnew shouldn't be modifying pending.
20:48 Heffalump whatsnew definitely shouldn't be modifying pending
20:48 owst agree about the darcs add case
20:48 owst Ok, so whatsnew could just output a warning, telling the user to either darcs add, or rename the dir and darcs revert to recover the recorded file contents
20:49 Heffalump why can't it just tell the user about the rm, like it would in the mkdir bar case?
20:49 Heffalump and wh -l would also tell the user aout the mkdir foo
20:50 owst I suppose it can. We'd need to special case some diff code somewhere.
20:50 owst In fact, it's probably in the HS index code that I'm about to start looking at
20:50 Heffalump what actually fails in this case?
20:50 Heffalump I would hope we could avoid special casing diff code in cases where the user-visible behaviour isn't a special case (viewed from the right perspective anyway :-) )
20:50 owst I'm not sure actually.
20:51 owst heh, true.
20:52 owst Wow, the output of +RTS -xc is not so easy to decipher with darcs - exceptions everywhere!
20:53 xstill joined #darcs
20:54 owst Yeah, it's the index reading code that currently fails with "inappropriate type (is a directory)"
20:55 Heffalump I guess making that more robust is the starting point then. And then IMO whatever we use to diff ought to notice differences in directory contents
20:55 owst Yep, I'll start there.
20:56 owst The index code looks tricky, wish me luck :-)
20:56 gh_ joined #darcs
21:11 mornfall owst: are you sure it's the index code failing?
21:12 owst Yup, lemmie find the stack trace
21:12 mornfall owst: I would suspect it's something trying to call a read on the Blob that came out of the index
21:12 owst Yeah, that sounds like what I saw
21:12 mornfall readFile ... readblob = readSegment (basedir index </> BSC.unpack (iPath item), Nothing)
21:12 mornfall this will clearly fail if the thing is a directory in the real filesystem
21:13 mornfall maybe you want to fix exists = fileExists st :-)
21:13 mornfall (say it should check it exists as a file)
21:14 mornfall fileExists st && !isDirectory st
21:14 mornfall which will still fail if it's a symlink to a directory I guess?
21:14 owst mornfall: http://lpaste.net/103283
21:15 mornfall yes
21:15 mornfall what I say :-)
21:15 owst Cool
21:16 mornfall I'm not sure you want to add a recursive symlink resolver though...
21:16 mornfall I planned to properly support symlinks in h-s/fslib, but we all know the fate of that.
21:17 owst No, I don't think I do want to add that
21:18 mornfall So for the simple case, this is easy to fix. For a case involving symlinks, it'll probably stay broken on one side or the other.
21:21 Heffalump do we have a clear definition of the intended semantics of symlinks in a darcs repo?
21:22 Heffalump Do we just follow them and treat them as if they are the target, or do we ignore them?
21:22 mornfall I think what we have is a hodgepodge of tradition, no clear intent.
21:23 Heffalump ok, so if we want to do anything with symlinks we first need to define that
21:23 mornfall I think the only sane thing to do is add support for symlinks at repo level.
21:23 Heffalump which I guess means having a quick look at what darcs actually does in practice then making a decision
21:23 Heffalump perhaps, though that introduces compatibility problems and you still have to decide what a symlink pointing out of repo should mean
21:25 mornfall Symlinks out of repo are the easy part, actually. :)
21:26 Heffalump I guess if you think having an absolute path like that under version control, yeah
21:26 mornfall The hard part is that your repo is no longer a filesystem tree but a filesystem dag.
21:26 Heffalump is a good idea, that is
21:26 Heffalump anyway, all this is a bit irrelevant since we don't version symlinks and won't any time soon
21:27 Heffalump any also because owst can just ignore symlinks if he only cares about fixing the file -> directory case
21:27 mornfall Well, if you don't have first-class symlinks, the dag effect in the working copy is a mess that you more or less cannot fix.
21:28 mornfall (Other than maybe saying that symlinks don't exist as far as darcs is concerned.)
21:41 Heffalump slyfox: I guess we can live with slowing down fetch. Are you now using both fixes - fix-non-atomic-global as well as the one at http://dpaste.com/hold/1800634/ (I copied it from your one as that is soon to expire)
21:41 Heffalump ?
22:07 slyfox Heffalump: now i'm using only the 'fix-non-atomic-global', didn't have time this w/e to study correctness of the second patch (i'm afraid it's a bit broken)
22:12 slyfox will investigate a bit more on monday/tuesday
22:31 mizu_no_oto joined #darcs

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