Camelia, the Perl 6 bug

IRC log for #darcs, 2013-01-24

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

All times shown according to UTC.

Time Nick Message
00:47 mizu_no_oto joined #darcs
01:51 Kilian] joined #darcs
01:51 Kilian] Hi
01:54 Kilian] can someone tell me if http://urchin.earth.li/~ian/co​nflictors/paper-2006-10-30.pdf is up 2 date about the solution for handling the patch conflicts? or where i can find some up2ate information about that topic?
01:57 Kilian] ups, didnt saw this page http://darcs.net/Talks, my fault, maybe its too late already ...
02:59 intripoon_ joined #darcs
03:47 mizu_no_oto joined #darcs
03:50 mizu_no_oto joined #darcs
04:05 favonia joined #darcs
04:12 jochu joined #darcs
04:18 mizu_no_oto joined #darcs
04:18 carter_ joined #darcs
04:18 preflex_ joined #darcs
04:40 mizu_no_oto joined #darcs
04:50 Kilian]1 joined #darcs
04:53 mizu_no_oto joined #darcs
08:49 bsrkaditya joined #darcs
08:59 bsrkaditya left #darcs
09:04 raichoo joined #darcs
09:24 amgarchIn9 joined #darcs
10:31 owst joined #darcs
10:32 iago joined #darcs
10:41 iago joined #darcs
11:10 owst Kilian]1: I'm not sure what Camp (the system that was being based on those notes) is in. I don't think the conflict representation that darcs currently uses is written down anywhere, unfortunately...
11:12 owst Actually, I don't think that paper describes what Camp does.
11:12 owst Well anyway, Igloo, who wrote that paper, was working on an alternative implementation/Coq proofs, but it's not finished
11:18 donri joined #darcs
11:25 jyyou joined #darcs
12:10 Kilian]1 oh, i didnt realized that there is another vcs called camp
12:11 owst Yeah, it was spawned from attempts to find a better/correct conflict representation
12:15 Kilian]1 so camp is more a research project?
12:16 owst Yeah
12:18 Kilian]1 thanks for your help
12:18 owst np
12:19 owst Why are you interested?
12:19 owst (if you are, that is ;-))
12:23 Kilian]1 iam going to write an app for android as bachelor thesis, it should handle dezentral, versionized file handling, like GIT
12:24 Kilian]1 and iam looking for alternatives besides GIT
12:25 owst Ah, cool
12:25 owst You might look at some of the Operational Transformation stuff, something like what Google Wave was based on
12:26 owst Obviously things like dropbox and etherpad, too
12:26 Kilian]1 to be serious, i only heard about darcs a year ago from one guy of the game NIkki and the robots
12:27 owst Fair enough; it's lost a lot of mindshare, so it's not surprising!
12:28 Kilian]1 can i handle binary files with darcs? patches sounds like non-binary data only
12:28 kerneis Kilian]1: yes, binary files are handled with special patches
12:29 kerneis but you don't have binary diffs
12:29 owst You *can* handle them, but the patches are stupid (they contain the whole binary file, each time)
12:29 kerneis when you update a binary file, darcs stores the new file in full
12:29 Kilian]1 so its the same like in git, there you have also the complete file stored twice if you update it
12:30 kerneis indeed
12:49 donri what happens if you try to merge binary patches?
12:51 owst You get a conflict, I imagine
12:51 donri i bet with git you get the latest version
12:52 owst Really?
12:52 owst That sounds strange :-)
12:52 donri i don't really know but seems like something git would do :p
12:55 owst As far as I can tell, trying to commute two binary patches will just fail, so merging will be a conflict
12:56 Kilian]1 na, in git i would update a binary file locally and do a add, commit & push, so there cant be a conflict at all in my opinion, i think its the same for darcs?
12:56 Kilian]1 a merge is put two versions of one file together
12:57 owst Kilian]1: what if another user does the same...
12:58 Kilian]1 owst: there should be a timestamp
12:58 owst There's no centralisation in Git, so it's easy for two people to make concurrent changes
12:58 owst Kilian]1: timestamp relative to who?
12:59 Kilian]1 a timestamp can always be transformed in the timezone you are livng in, iam not sure about the this in git for binary files but thats what i would expect how it should work
13:00 owst Git doesn't use timestamps...
13:15 owst Kilian]1: see here for a script to demonstrate what Git does with binary files: http://pastebin.com/QcXjkf6J
13:18 Kilian]1 owst: i see thanks, and in darcs the result would be the same?
13:19 owst In that you'd get a conflict, yes
13:19 donri ah, good
13:20 donri i was thinking maybe it depends on what you merge into what, such that e.g. the merged code gets precedent
13:24 owst In fact, mark-conflicts seems to use the pulled-in version of the binary file
13:24 donri well i meant in git, and without conflicts
13:32 nomeata joined #darcs
14:31 gh_ joined #darcs
14:38 dcoutts joined #darcs
14:38 dcoutts joined #darcs
14:42 dcoutts joined #darcs
14:42 dcoutts joined #darcs
15:10 mizu_no_oto joined #darcs
15:18 mizu_no_oto joined #darcs
15:28 sm morning all
15:28 sm what's the best way to "stash" unrecorded changes, again ?
15:29 sm darcs diff >save.diff; darcs revert -a ?
15:30 sm Kilian]1: did you see git annex ?
15:32 Kilian]1 sm, not yet, thanks for the hint, i will take a look at this
15:32 owst sm: something like that
15:33 owst I wrote a recipe up for someone on reddit, lemmie find it
15:33 sm hmm, patch things the output of darcs diff is garbage
15:33 sm my other thought is darcs record -am WIP; darcs obl --last 1 -a -O
15:33 sm s/things/thinks/
15:33 owst http://pastebin.com/J04Hw2uB
15:34 owst sm: doesn't darcs diff list the patches at the start of the output?
15:35 mizu_no_oto joined #darcs
15:35 sm ah you did the latter in  your script.. thanks
15:36 sm owst: no, here it just starts with a diff command line
15:36 owst Yeah, the script is a bit noisy tbh, looking at it agian.
15:36 owst what does patch say?
15:37 owst which version of darcs?
15:37 sm 2.8.1
15:37 sm $ patch <save.diff -n
15:37 sm patch: **** Only garbage was found in the patch input.
15:38 owst isn't 2.8.1. unified diff by default?
15:38 owst i.e. -n is wrong
15:38 sm doh! thanks. I guess -n was --dry-run
15:38 sm I've tripped on that before
15:38 owst Yeah, it is unifed
15:39 * owst remembers diff because that was one of the first changes I made to darcs :-)
15:39 sm diff & patch works fine then, and seems easier for a quick stash
15:40 sm record+obliterate & apply may be a bit more featureful for longer-term stashing
15:40 sm owst++ !
15:40 owst darcs diff > wip.diff; darcs rev -a; echo '*wibble*'; patch < wip.diff
15:40 owst ?
15:41 sm patch -p1
15:41 owst darcs rec -am 'WIP'; darcs ob --last 1 -O -a; echo '*wibble*'; darcs apply WIP.dpatch; darcs unrec --last 1 -a
15:41 owst or thereabouts
15:41 owst diff looks quicker to type ;-)
15:41 sm exactly
15:42 sm right, on with this build test
15:42 owst darcs stash could be an alias to the rec/ob bit
15:43 owst darcs unstash could be an alias to apply/unrec
15:43 owst they could stash to some "stash.dpatch" in _darcs/patches
15:43 owst and not allow multiple stashes
15:44 sm we need that darcs-X plugin mechanism
15:44 gh_ sm, darcs revert -a, then darcs unrevert
15:44 sm ooh, interesting
15:44 gh_ (to stash unrecorded changes in _darcs/patchs/unrevert )
15:44 sm thanks gh_
15:45 sm I'll give that some testing
15:45 owst gh_: that would unrevert extra stuff that was already in the unrevert patch, I think?
15:46 gh_ owst, I think that each time you use revert, the unrevert patch gets rewritten from scratch
15:47 owst Oh does it?
15:47 gh_ I mean, unrevert only saves you from the last time you used revert
15:47 owst Right
15:47 owst I wouldn't have expected that, I suppose
15:47 gh_ otherwise the unrevert patch would grow forever...
15:47 sm I think darcs will warn me whenever I'm about to mess it up the saved revert state
15:47 owst gh_: yeah, good point
15:47 sm so this method seems about as lightweight it could be. nice
15:48 owst Yeah
15:48 owst that's cool
15:48 sm and I should have learned this sooner  :)
15:48 * owst should've thought about it :-)
15:49 gh_ sm, I discovered this use of unrevert when I started a thread on the list about removing the command from darcs
15:50 gh_ http://darcs.net/FAQ#is-there-an-e​quivalent-of-git-stash-for-quick-s​aving-of-working-directory-changes   I wrote that
15:50 sm Nod. It just seems a little less safe than the others. So we have three ways of stashing
15:52 owst gh_: Yeah, you're correct - unrevert is overwritten each time
15:52 sm gh_: well documented, +1!
15:53 sm revert + option to save the revert file wins
16:08 mizu_no_oto joined #darcs
16:19 mizu_no_oto joined #darcs
16:44 owst Heffalump: I think I was being stupid when I said get no longer works with OF repos - it works, and performs an upgrade to hashed
16:44 owst conclusion: never listen to me, when in the pub :-)
16:44 rdesfo joined #darcs
17:09 * sm unreverts.. "darcs revert has stash built-in. Awesome."
17:10 owst :-)
17:10 owst *limited stash ;-)
17:10 owst Maybe revert should warn you that you'll overwrite an existing unrevert patch
17:10 owst Otherwise people may expect to be able to do multiple stashes
17:11 sm but, that could get annoying when you're just reverting
17:11 owst Yeah
17:11 sm revert could accept an optional stash name
17:12 owst Yeah, that be a good way to automate gh_'s suggestion of moving the unrevert.dpatch
17:28 Heffalump I use darcs obliterate -O to stash. The main downside is you have to stash everything that might be edited
17:48 mizu_no_oto joined #darcs
17:50 drostie joined #darcs
17:56 mizu_no_oto joined #darcs
17:58 raichoo joined #darcs
18:37 sm darcs-devel was perhaps not the right place to cc 'Re: Patch for issue "Dirty state after failed fork"', sorry about that
18:43 * owst read it but didn't have any comments
18:47 Heffalump I think it's fnie if hub development is done via darcs-devel
18:50 sm ok, great
18:51 sm I just caught up on some mail lists, nice activity in darcs dev land
19:29 schlaftier joined #darcs
19:35 owst joined #darcs
19:40 Kilian]1 left #darcs
19:49 markstos joined #darcs
19:54 markstos I just found an unfortunate regression between Darcs 2.8.0 and Darcs 2.9.7. In the latest version "darcs annotate file.txt" fails to include some lines in a file. They simply aren't there. Running the same command with "darcs 2.8.0", the lines are there. Is this a patch-index fail?
19:55 markstos Sorry, the repo is not available, and I'm not sure what triggers the condition exactly.
19:56 markstos darcs show patch-index-status claims it is up-to-date and darcs show patch-index-test passes.
19:56 sm markstos: maybe you can get another copy of the repo, without patch index enabled, and compare
19:57 markstos Ok, I'll try darcs optimize --disable-patch-index and try the annotate command again.
20:00 markstos I can confirm that disabling the patch index fixes it. I'll head to the bug tracker.
20:07 Heffalump markstos: does your repo have any replace patches in it?
20:07 markstos No, we never use those.
20:09 Heffalump ok, this might be an incentive for me to write the repo obfuscator (I'm part way there - I wrote a tool to undo the hashing and compression in a darcs repo, which makes it easier to hack things)
20:10 markstos I tried to rebuild the patch index, but it ran out of stack space. I tried to re-run optimize with more stack space, but it said I had to re-compile. So now I'm re-compiling to re-optimize, to re-test darcs annotate so that I can proceed with my software development.
20:11 Heffalump oh dear, sorry...
20:12 sm :/ that sure would be a great test repo.. would obfuscation be enough for you to feel ok with publishing it ?
20:12 markstos Is there a environment variable or config file where I can put my standard "cabal install" flags, so I don't have to worry about forgetting "-frts" in the future?
20:13 markstos Quite likely, subject to my reviewing the result after running the obfuscator over it.
20:13 markstos "match_co baling out
20:13 markstos " looks like scary compiler output.
20:13 markstos Heffalump, thanks for fixing the zero-things-in-rebase issue.
20:16 owst you can ignore match_co bailing out
20:16 Heffalump np, I'm sorry I left it there for so long, given that it caused people trouble getting out of it
20:20 markstos I've re-compiled, re-optimized and re-tested now, with darcs 2.9.7+35. The result is that... the line is back now.
20:21 Heffalump i.e. the output is correct with a fresh index?
20:21 markstos So it appears that one or both othe patch-index "status" and "test" were not accurate.
20:21 markstos Heffalump: that's right a fresh index fixed it. Well, I also upgraded from 2.9.7+10 to 2.9.7+35.
20:22 Heffalump that's unlikely to matter
20:23 Heffalump do you still have the repo with the bad index?
20:24 markstos Heffalump: no, I didn't save it. I see that would have been helpful now. Each repo copy is ~ 1 G.
20:24 markstos Here's the report I just filed: http://bugs.darcs.net/issue2294
20:25 owst Heffalump: Do you know what's causing the stack space issue?
20:26 markstos I understand it to be the general large size of my repo in combination with some low GHC default settings.
20:26 Heffalump well, it's likely also a performance/behaviour bug in the patch index code
20:27 owst yeah
20:27 owst that's what I meant
20:27 markstos If I don't re-compile with -ftrs, and use this liberally, I run into it all the time:  +RTS -K100M -RTS
20:27 Heffalump I guess we could simulate a large repo somehow, but given that markstos doesn't use replace patches, perhaps I should just finish the obfuscator
20:27 Heffalump or rather write it :-)
20:28 Heffalump one worry is that if it's buggy we could spend more time confused by that than we gain from getting his repo
20:29 owst $ darcs optimize --disable-patch-index
20:29 owst Done optimizing!
20:29 owst $ darcs optimize --enable-patch-index
20:29 owst darcs failed:  unrecognized option `--enable-patch-index'
20:29 owst Grr
20:30 Heffalump it's just --patch-index
20:30 Heffalump I got bit by that too
20:31 owst darcs.net's repo doesn't overflow for me
20:31 owst that's annoying
20:31 Heffalump yeah, I think markstos has one that's 50% bigger or so
20:31 markstos :) darcs has about the same number of patches as I do.
20:31 Heffalump markstos: how big is _darcs in your repo?
20:32 markstos 1.7G
20:32 markstos (larger than I thought!)
20:32 Heffalump and how big is the whole thing including the working dir?
20:32 Heffalump (or just the working dir - _darcs)
20:32 markstos I have 1.1G just in _darcs/inventories. Surprising.
20:32 Heffalump darcs leaks stuff I think :-/
20:32 Heffalump if you did a fresh get it would probably shrink
20:33 markstos 2.1G for the whole project dir, including darcs. It's grown since I measure it last.
20:33 markstos Another branch has only ~364M in _darcs/inventories. Interesting.
20:34 owst It isn't safe for darcs to delete inventories, since someone could be getting an old version
20:34 owst Heffalump: I wonder if this is related to the laziness bug
20:34 owst (I wonder if new inventories are being written out, all the time)
20:35 markstos My largest inventory file is 1.3M , I just apparently have a lot of them.
20:35 Heffalump I roughly understand the laziness bug
20:35 owst Oh, cool.
20:35 Heffalump unfortunately it might need a patch index format change to fix
20:35 owst Urk
20:35 Heffalump the patch index doesn't actually record clean tags...
20:35 owst Is patch index actually released, though?
20:35 markstos I have about 4000 files in _darcs/inventories.
20:35 Heffalump no, so less painful than otherwise
20:36 owst what do you mean, "the patch index doesn't actually record clean tags..."
20:36 Heffalump it just has a list of patch names
20:36 owst So?
20:37 Heffalump the update code is based on looking at the repo, and looking at the patch index, and comparing the patches in each
20:37 Heffalump without having a clean tag common to both that you can stop at, you have to read all the patch names in the repo to compare with the index
20:37 owst Oh, so it can look too far back, even though the UI wouldn't present anything past a clean tag?
20:37 Heffalump yes, though it's not really to do with the UI
20:38 Heffalump it's like when you do a remote operation - once you find a clean tag common to both repos, you can assume that they are identical before that tag
20:38 Heffalump similarly with the patch index - when updating it with respect to a new repo state, it needs to be able to stop
20:38 Heffalump the patch index update isn't command-specific - it just diffs what it sees in the repo with what the patch index already has
20:39 owst Right
20:39 * markstos wonders if you could pull a patch index from another repo, and then just fix the changes since the last common tag.
20:40 Heffalump yes
20:40 Heffalump in fact you could manually copy it over then run any darcs command to bring it up to date
20:40 Heffalump but that's a hack, of course
20:41 Heffalump (and I'm not 100% certain that's the case, but it's my understanding based on what I've looked at so far)
20:52 markstos Interesting.
20:58 Heffalump I think get already grabs the remote patch index (not certain though)
20:58 Heffalump I can see a case for pull doing it too, but perhaps not a priority for 2.10
20:58 Heffalump markstos: please feel free to mark bugs on the tracker as milestone 2.10, btw, we can always undo that in a later triage step
20:59 markstos Thanks. I'll keep that in mind.
21:49 mizu_no_oto joined #darcs
22:21 sm__ joined #darcs
22:48 mizu_no_oto joined #darcs
23:28 xymox joined #darcs
23:49 mizu_no_oto joined #darcs

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