| Time |
S |
Nick |
Message |
| 00:29 |
|
|
balor joined #darcs |
| 00:45 |
|
mornfall |
Now that's better. darcs convert --import fastimport-tahoe-lafs 211,68s user 3,05s system 95% cpu 3:45,49 total |
| 00:58 |
|
|
zooko joined #darcs |
| 01:20 |
|
mornfall |
Hm. Could be that a map of bytestrings is becoming rather slow on the order of ~10k items in it? |
| 01:21 |
|
mornfall |
(of the form 1, 2, ... 10000, in form of decimal strings...) |
| 01:38 |
|
mornfall |
Something's utterly wrong. My profiling binary is twice as fast as non-profiling? |
| 01:45 |
|
mornfall |
Just a little over one minute. \o/ |
| 01:56 |
|
mornfall |
... can't win... it's either fast or correct, but not both |
| 02:06 |
|
lispy |
mornfall: I think my parser is now either just as fast as the previous darcs parser or faster (any jitter during benchmarks makes it impossible to get a good reading) |
| 02:07 |
|
mornfall |
:) |
| 02:07 |
|
mornfall |
Sounds good. |
| 02:12 |
|
mornfall |
git -> darcs, tahoe-lafs 3 minutes, ghc-testsuite 6m30... not blazing-fast but not unusably slow either |
| 02:39 |
|
mornfall |
tahoe-lafs down to 1:20 (and staying OK) ... so much for cutting times in half |
| 02:42 |
|
mornfall |
(ghc-testsuite to 3m20 which is not as nice, but still not bad) |
| 02:43 |
|
mornfall |
So tomorrow boring stuff like parsing/converting dates and tags and authors... |
| 02:51 |
|
lispy |
oh. Hrm. I just realized my 'darcs-unmodified' that I bench against includes my refactor now |
| 02:51 |
|
lispy |
So, I guess I sped it up relative to the stuff Heffalump applied, but maybe not relative to without it |
| 03:17 |
|
|
abuiles joined #darcs |
| 03:18 |
|
abuiles |
sm, are you around ? |
| 03:22 |
|
|
sshc_ joined #darcs |
| 03:29 |
|
sm |
hi abuiles |
| 03:29 |
|
abuiles |
sm, how is it going ? |
| 03:29 |
|
sm |
good, relaxing. What's up ? |
| 03:30 |
|
sm |
I'm not really here, just checking if you need something |
| 03:30 |
|
abuiles |
sm, my patch has been applied, maybe when you have a chance could you check if it the problem you were having still appears.. ( it shouldn't ) |
| 03:30 |
|
sm |
ah, thanks |
| 03:30 |
|
|
exlevan joined #darcs |
| 03:30 |
|
sm |
I forgot the issue, do you remember the number ? |
| 03:31 |
|
exlevan |
morning |
| 03:31 |
|
abuiles |
sm: not sure if you open a ticket, but it was the one of darcs hanging up |
| 03:31 |
|
abuiles |
hi exlevan |
| 03:32 |
|
sm |
thanks |
| 03:33 |
|
abuiles |
sm: cool, thanks to you too. |
| 03:39 |
|
|
sshc joined #darcs |
| 03:40 |
|
|
twb joined #darcs |
| 04:03 |
|
|
zooko joined #darcs |
| 04:12 |
|
|
bos joined #darcs |
| 04:28 |
|
|
abuiles left #darcs |
| 04:55 |
|
|
clochette joined #darcs |
| 05:16 |
|
lispy |
mapPrimFL is buggy |
| 06:02 |
|
|
twb joined #darcs |
| 07:00 |
|
|
Quiark joined #darcs |
| 07:02 |
|
|
darcscommitbot joined #darcs |
| 07:03 |
|
|
darcswikibot joined #darcs |
| 07:18 |
|
|
twb joined #darcs |
| 07:56 |
|
Quiark |
I don't understand this behaviour - when there is a conflict and I do a revert, the conflicted piece of code simply disappears and darcs says everything is ok...? |
| 08:07 |
|
|
Jaak joined #darcs |
| 08:19 |
|
Quiark |
Which probably also explains why the lines which resolve a conflict are marked as + even though they were there before. |
| 08:24 |
|
|
twb joined #darcs |
| 08:50 |
|
mornfall |
exlevan: Early, duh. :) I went to sleep maybe 30 minutes before you got up :D |
| 08:58 |
|
mornfall |
Quiark: That's because conflict in behaves as "neither side has happened". That's because this is the simplest unique resolution of a conflict. Anything you want to add on top has to be done explicitly (the resolution). |
| 08:58 |
|
mornfall |
+darcs |
| 08:59 |
|
Quiark |
So maybe I didn't accidentally remove the function - I just did a revert after a conflict. |
| 09:00 |
|
Quiark |
Anyway, I gave up investigating and simply recorded a new patch with the correct contents. |
| 09:01 |
|
|
kowey joined #darcs |
| 09:01 |
|
kowey |
good morning |
| 09:01 |
|
lambdabot |
kowey: You have 3 new messages. '/msg lambdabot @messages' to read them. |
| 09:02 |
|
kowey |
Quiark: I've been reading the logs, sorry conflicts are being so tricky! It's one of the weak spots in the Darcs UI |
| 09:02 |
|
kowey |
Quiark: I'm trying to encourage more use of the FAQs within #darcs, for example, http://wiki.darcs.net/ConflictsFAQ |
| 09:04 |
|
mornfall |
: - ) |
| 09:04 |
|
kowey |
I think the general model is a friendly FAQ link followed by personalised advice |
| 09:05 |
|
kowey |
so Quiark, in your case, if you make a conflict disappear by reverting, you can always recover it by doing "darcs mark-conflicts" |
| 09:06 |
|
twb |
Though if you only reverted some things, it might make a mess of other files' unrecorded changes |
| 09:07 |
|
Quiark |
I think I understand it better now. There is even a chance I actually did it right, but I'm not sure :) |
| 09:07 |
|
kowey |
one severe error I made in #darcs was when tibbe was complaining about conflicts, I tried to justify the behaviour as it stemming from Darcs trying really hard to get things right |
| 09:08 |
|
kowey |
(he was saying that "getting conflicts right is important" [paraphrasing]) |
| 09:08 |
|
kowey |
now, this sort of statement makes sense if you're a Darcs hacker |
| 09:08 |
|
kowey |
but for a frustrated user like tibbe... argh! |
| 09:11 |
|
kowey |
Quiark: if there's anything Darcs can do to give you confidence you did it right, let me know |
| 09:11 |
|
twb |
built-in pep talks |
| 09:12 |
|
kowey |
one issue is that Darcs does not give a "patch X conflicts with patch Y" |
| 09:12 |
|
twb |
Tell me about it |
| 09:12 |
|
twb |
And it defaults to --allow-conflicts, which imo is evil |
| 09:12 |
|
kowey |
only for pull |
| 09:12 |
|
twb |
I guess |
| 09:13 |
|
kowey |
it actually defaults to --mark-conflicts for pull |
| 09:13 |
|
kowey |
and --dont-allow-conflicts for apply |
| 09:14 |
|
kowey |
which translates to --dont-allow-conflicts for push |
| 09:14 |
|
kowey |
the conflicts FAQ should maybe start talking about --skip-conflicts |
| 09:15 |
|
twb |
! |
| 09:15 |
|
twb |
I never knew that one |
| 09:15 |
|
Quiark |
kowey, it seems the biggest problem was that I didn't understand that doing a revert on a conflicted repo is what made the function disappear |
| 09:16 |
|
twb |
I've been looping over --dont-allow-conflicts |
| 09:16 |
|
kowey |
it's a relatively new feature by Heffalump |
| 09:16 |
|
kowey |
introduced in Darcs 2.4 |
| 09:16 |
|
Quiark |
kowey, so I was trying to find the patch in which I deleted it |
| 09:17 |
|
mornfall |
kowey: About the Mac, give it some time I guess. Things at uni tend to be slow, moreso during summer holidays. |
| 09:17 |
|
mornfall |
kowey: If we are in a hurry, I'd suggest trying to get it hosted in the US. |
| 09:17 |
|
kowey |
thanks, mornfall.. just launching things in parallel |
| 09:18 |
|
kowey |
perhaps osuosl would be able to oblige |
| 09:18 |
|
kowey |
or maybe this sort of thing is way outside their remit |
| 09:18 |
|
mornfall |
Well, I have a KVM farm now. Maybe OSX runs in KVM? :) |
| 09:19 |
|
kowey |
hmm! http://osuosl.org/services/hosting/policy |
| 09:19 |
|
kowey |
google says: http://www.insanelymac.com/for[…]?showtopic=133321 |
| 09:20 |
|
kowey |
actually maybe getting it hosted at osuosl would be the sanest solution |
| 09:20 |
|
kowey |
and would be long-term safest (in terms of what happens when we get a Dr mornfall) |
| 09:20 |
|
* kowey |
sends them an email to see if it'd be possible |
| 09:27 |
|
mornfall |
It seems that Darwin is dead. |
| 09:27 |
|
mornfall |
(If it wasn't I'd install that somewhere.) |
| 09:27 |
|
kowey |
there is a PureDarwin project which tries to take up the mantle |
| 09:27 |
|
kowey |
but they haven't gotten to the release an ISO stage, if I understand |
| 09:27 |
|
mornfall |
True, I have an ISO. I'll see if it boots in KVM (it didn't in VirtualBox). |
| 09:27 |
|
kowey |
this would also avoid the issue of being against Apple's EULA |
| 09:28 |
|
mornfall |
But if we can have a Mac Mini at OSUOSL, that'd be probably the simplest & cleanest. |
| 09:29 |
|
kowey |
so I described the problem (we want a Mac to buildbot, benchmark and debug darcs on) and asked generally if they could help |
| 09:30 |
|
kowey |
I think I'm angling for an answer like "oh actually, we have a bunch of XServe's sitting around that need using" |
| 09:31 |
|
kowey |
anyway thanks for saying the "hosted-in-USA" keyword... that was just what I needed to trigger thinking about osuosl |
| 09:31 |
|
kowey |
wish it occurred to me months ago when I first mentioned it. |
| 09:32 |
|
kowey |
Quiark: I wonder if darcs changes should display something like "pending conflicts..." (hunks) on top |
| 09:33 |
|
kowey |
Quiark: there is one corner case to account for, which is that some users in some circumstances may actually want the both-sides-cancel out resolution (doubtful) |
| 09:39 |
|
|
dcoutts joined #darcs |
| 09:39 |
|
|
dcoutts joined #darcs |
| 09:48 |
|
Quiark |
kowey, I don't know. The other VCS have it easier, because the repo and working copy are more independent there. |
| 09:57 |
|
kowey |
what do you mean? |
| 09:58 |
|
Quiark |
for example a merge in svn only modifies the working copy unless I commit. So a revert really does revert to a state which the user understands. |
| 09:59 |
|
Quiark |
I don't have that much experience with merges in hg or git though |
| 10:00 |
|
twb |
I have enough experience with them that I don't ever want to do them again |
| 10:01 |
|
twb |
They made me angrier than anything else, except using literal tabs |
| 10:11 |
|
mornfall |
:D |
| 10:16 |
|
Quiark |
I guess that when darcs has already spent 12 minutes applying a patch bundle on a strong machine, it's time to kill it and investigate? |
| 10:18 |
|
mornfall |
Anyone can think of some test repositories to import? :) |
| 10:18 |
|
twb |
mornfall: that zoo stuff? |
| 10:18 |
|
mornfall |
Oh, I mean git repos. |
| 10:18 |
|
twb |
linux |
| 10:18 |
|
mornfall |
:P |
| 10:18 |
|
mornfall |
Something a bit lighter for start maybe. |
| 10:19 |
|
Quiark |
go to github.org |
| 10:19 |
|
twb |
curl -s http://code.haskell.org/~twb/P[…]nces/.bin/twb-get | grep git |
| 10:19 |
|
twb |
Hum, not too helpful without a -B1, but you get the idea |
| 10:19 |
|
twb |
mornfall: emacs! |
| 10:19 |
|
* mornfall |
tries gitit |
| 10:20 |
|
kowey |
maybe some bits and pieces of gnome or kde |
| 10:21 |
|
kowey |
Quiark: maybe --skip-conflicts to see how much you can apply first? |
| 10:21 |
|
kowey |
Quiark: thanks for your comments on merging (I'll try to think more after lunch) |
| 10:23 |
|
Quiark |
kowey, you're welcome |
| 10:24 |
|
|
intripoon joined #darcs |
| 10:25 |
|
twb |
kowey: you need to offline your brain to digest food, eh? |
| 10:27 |
|
kowey |
:-), just trying to get myself to focus on work-work |
| 10:40 |
|
mornfall |
Gitit converted OK. |
| 10:40 |
|
* mornfall |
trying midori |
| 10:41 |
|
mornfall |
Now I wonder how to get git fast-export list also tags... |
| 10:44 |
|
kowey |
another candidate would be the git git repo |
| 10:49 |
|
twb |
mornfall: if you can git->darcs an etckeeper repo, I'll be happy |
| 11:06 |
|
mornfall |
Tags are tricky. :\ |
| 11:11 |
|
|
JaffaCake joined #darcs |
| 11:13 |
|
twb |
Apart from anything else, "tag" means different things to different VCSs |
| 11:14 |
|
Quiark |
kowey, if you want to talk about conflicts, I have one more use case :) |
| 11:16 |
|
kowey |
gah, my university insist on tampering my email and sometimes breaking GPG |
| 11:17 |
|
kowey |
*tampering with - they like to append a "this message has been spam scanned" footer directly on the body |
| 11:17 |
|
kowey |
Quiark: let's hear it! :-) |
| 11:18 |
|
Quiark |
kowey, I write code on my local machine and let WinSCP automatically upload it to a remote machine where I compile and run it. Both source and destination are under darcs. I realise this is somewhat nasty and other possibilities may be better, but anyway. |
| 11:18 |
|
mornfall |
Hmm! |
| 11:20 |
|
twb |
kowey: are you attaching or inlining your sig? |
| 11:20 |
|
kowey |
so you winscp the contents of the working directory? |
| 11:20 |
|
kowey |
attaching, twb |
| 11:20 |
|
twb |
Hum |
| 11:20 |
|
Quiark |
kowey, I record changes on my local machine and now I do darcs push to the remote machine. Of course there are conflicts, because the working copy there already has the changes which I'm pushing. |
| 11:20 |
|
twb |
then LART is the only workaround |
| 11:20 |
|
Quiark |
kowey, yep, _darcs remains untouched |
| 11:20 |
|
kowey |
it's actually normally clever enough to not do its tampering on signed messages |
| 11:20 |
|
kowey |
but sometimes MessageLab's cleverness fails |
| 11:21 |
|
mornfall |
I can import --all dumps now! And I get darcs tags. |
| 11:21 |
|
kowey |
twb, I sent a plea requesting that their "this message is phishproof!" footers be added as attachments |
| 11:21 |
|
kowey |
knowing that it will have no effect, as their priority (understandably) is to cater to the Windows users here |
| 11:21 |
|
twb |
Tell them to use Disposition: inline and it'll look the same in their fucked up outlook client |
| 11:22 |
|
Quiark |
kowey, in other VCS when I do this I just do a revert and that's it. In darcs, I'm in a rather strange state now, because it says there are conflicts, but the patches in the repo themselves are ok. |
| 11:22 |
|
kowey |
Quiark: wait, what? |
| 11:22 |
|
kowey |
oh, I see |
| 11:23 |
|
kowey |
Is this with a darcs 2 format repository? |
| 11:23 |
|
kowey |
(darcs show repo) |
| 11:23 |
|
Quiark |
yes |
| 11:24 |
|
kowey |
OK, and so using darcs push would be unacceptable to you because you're doing Work in Progress and are not yet ready to record, right? |
| 11:24 |
|
kowey |
I'm somewhat surprised that this isn't picked up by darcs' duplicate patch handling on darcs-2 format repos |
| 11:25 |
|
Quiark |
kowey, yes, amend-record probably isn't a way either. And WinSCP is much faster |
| 11:26 |
|
kowey |
hmm |
| 11:27 |
|
kowey |
Quiark: I think the only thing may be to have a prehook for push that does a remote revert |
| 11:27 |
|
Quiark |
it's rather messy now because I had to apply the patches in batches and do reverts a few times in between, otherwise it would hang (doing something but don't know what) |
| 11:28 |
|
kowey |
something along the lines of "ssh example.com darcs revert --repo foo -a" |
| 11:31 |
|
Quiark |
Yeah, that would probably help. But I still don't understand the situation right now, because I think the patches in the repo are not conflicting (because they are the same as on my local machine which is ok). |
| 11:32 |
|
kowey |
Quiark: another thing which you could try is to have a non-darcs-managed build repo |
| 11:32 |
|
kowey |
so you winscp to the build repo, but you darcs push to the src repo |
| 11:32 |
|
Quiark |
yes, that's what I'm probably going to do |
| 11:33 |
|
* kowey |
is starving... can we pick this up later? |
| 11:33 |
|
Quiark |
kowey, oh, you haven't eaten yet, sure |
| 11:34 |
|
kowey |
timezone diff :-) back in a bit |
| 11:44 |
|
* mornfall |
sends off his convert work and goes to look for food as well... |
| 12:12 |
|
mornfall |
Oh dear. The emacs git repo goes back to 1992. |
| 12:12 |
|
mornfall |
That's going to take a while. |
| 12:16 |
|
mornfall |
27k/546k objects... see you tomorrow :D |
| 12:16 |
|
burp |
546k patches with darcs? :O |
| 12:16 |
|
burp |
that's gonna be a good test |
| 12:16 |
|
mornfall |
No, objects. There's going to be maybe a tenth of the number of commits. |
| 12:17 |
|
burp |
hm, ok still :> |
| 12:17 |
|
mornfall |
Well, GHC has 20k patches. 50k is on the same order, I guess... |
| 12:17 |
|
burp |
and it works well with darcs? nice |
| 12:18 |
|
mornfall |
Optimistic extrapolation says it should be done in about 3 hours. |
| 12:18 |
|
mornfall |
Unless I run out of space on $HOME... |
| 12:30 |
|
mornfall |
(10 % done... anyway, those libc and gcc tags in the emacs repo look real funky) |
| 12:31 |
|
mornfall |
and I guess I need to go out since it's beautiful wheather and I'm starting to freak out here |
| 12:33 |
|
burp |
mornfall: do you use "darcs-fast-import" unmodified? |
| 12:33 |
|
mornfall |
Not at all. |
| 12:34 |
|
mornfall |
I am using darcs convert --import that I just implemented. :) |
| 12:34 |
|
burp |
oh |
| 12:34 |
|
burp |
can I pull that from somewhere? |
| 12:34 |
|
mornfall |
I am just testing it, I have no need to own a darcs copy of emacs history. |
| 12:35 |
|
mornfall |
burp: Not yet, I need to update hashed-storage first... |
| 12:35 |
|
burp |
ok |
| 12:35 |
|
mornfall |
I'll do that when I get back from out. :) |
| 12:35 |
|
burp |
looking forward for it |
| 12:35 |
|
mornfall |
:)) |
| 12:35 |
|
mornfall |
Glad to hear that. |
| 12:35 |
|
* mornfall |
runs out. |
| 12:36 |
|
kowey |
Quiark: so about conflicts... |
| 12:37 |
|
Quiark |
kowey, I think I will resolve the situation somehow, but I'm just curious about the state the repo is in now (the patches are ok, but I have a conflict nevertheless) |
| 12:37 |
|
kowey |
what does darcs whatsnew report? |
| 12:38 |
|
kowey |
and did you say you pushed the changes in batches? |
| 12:39 |
|
Quiark |
When I did darcs apply on everything, it hung (CPU at 100% but no info). Then I did apply --skip-conflicts |
| 12:39 |
|
Quiark |
then revert, then some more applying, when it froze again revert and so on :) |
| 12:40 |
|
Quiark |
so I'm after a revert now and whatsnew shows no changes |
| 12:53 |
|
kowey |
can you share this repo, by the way? |
| 12:54 |
|
kowey |
I'm just curious about the cause for the hanging |
| 12:54 |
|
kowey |
Quiark: sorry, I was distracted by trying to deal with the public domain code in our test suite |
| 12:55 |
|
kowey |
also, you did a revert after apply --skip-conflicts |
| 12:55 |
|
kowey |
that means you reverted everything, right? |
| 12:57 |
|
Quiark |
emm..I don't know :) |
| 12:58 |
|
kowey |
OK, and what do you mean when you say "when it froze again, revert" |
| 12:58 |
|
kowey |
If I understand correctly, apply is atomic |
| 12:59 |
|
kowey |
so if you C-c an apply with lots of patches, then none of them get applied... |
| 13:00 |
|
Quiark |
I'm not sure if I did a revert right after apply --skip-conflicts |
| 13:00 |
|
kowey |
ok |
| 13:00 |
|
Quiark |
maybe I did apply one more patch |
| 13:00 |
|
kowey |
hard to keep track of the details without a typescript, huh? |
| 13:01 |
|
kowey |
is it possible that the conflicts come from the patches themselves? |
| 13:01 |
|
kowey |
ie. do you have multiple branches of development with conflicting patches (ignoring working dir) |
| 13:02 |
|
Quiark |
Probably yes, I work on my branch of mornfall's code, sometimes there are conflicts. But they should be already resolved. |
| 13:02 |
|
kowey |
ah! |
| 13:03 |
|
kowey |
ok, so one thing that you may want to know about |
| 13:03 |
|
kowey |
is that if you push patches A and B which conflict with each other |
| 13:03 |
|
kowey |
without also pushing C (a patch that resolves the conflict) |
| 13:03 |
|
kowey |
then Darcs will complain that you have a conflict |
| 13:03 |
|
kowey |
and mark it up |
| 13:03 |
|
Quiark |
but I think I pushed C too |
| 13:04 |
|
Quiark |
see the repo here http://www.fi.muni.cz/~xplasil/tmp/darcsprob/ |
| 13:04 |
|
kowey |
that's with all the patches? |
| 13:05 |
|
Quiark |
yes |
| 13:05 |
|
kowey |
how far back does this push go? |
| 13:06 |
|
Quiark |
so when i do mark-conflicts and whatsnew -s, only the file divine/explain.h is conflicting. Which is a file which only exists in my repo. So it seems that darcs got most of it right and there's just some smaller problem with this file. |
| 13:08 |
|
Quiark |
I wonder which patches are in conflict |
| 13:08 |
|
kowey |
this is what's most interesting for me |
| 13:09 |
|
kowey |
this is sort of a chance for us to think about how to make darcs conflicts easier for users to cope with |
| 13:09 |
|
kowey |
because right now there's a lot of "argh! I don't get it!" |
| 13:09 |
|
kowey |
which is not how you want your revision control systems to be :-( |
| 13:09 |
|
kowey |
particularly one that prides itself on being very very easy to use |
| 13:10 |
|
kowey |
Quiark: darcs changes -s could be helpful here |
| 13:11 |
|
Quiark |
kowey, I think one of the biggest problems with darcs is that it works differently from git/hg or even svn. |
| 13:11 |
|
kowey |
particularly darcs changes -i -s |
| 13:12 |
|
kowey |
that's probably unlikely to change |
| 13:12 |
|
kowey |
but even within a patch-oriented way of looking at things, we're not doing a good enough job with users and conflicts |
| 13:12 |
|
Quiark |
Yeah. When someone learns git, he thinks he knows all the DVCS. |
| 13:13 |
|
kowey |
sort of there being two reasons (1) unfamiliar and (2) bad |
| 13:13 |
|
kowey |
we can't fix (1), but we should be working on (2) |
| 13:13 |
|
kowey |
just setting sights higher now that we've made a bit of performance progress :-) |
| 13:14 |
|
kowey |
so if you do a darcs changes -s -i, you'll get a summary on each patch |
| 13:14 |
|
kowey |
and you can step through them interactively |
| 13:14 |
|
kowey |
this is useful because when you see a bang, as in M! ./divine/explain.test.h |
| 13:14 |
|
kowey |
you know it's a patch with a conflict in it |
| 13:14 |
|
kowey |
and you can hit 'v' to see the contents |
| 13:15 |
|
mornfall |
I overshoot a bit with those 50k patches ... 87k objects converted and I've already got 44k patches. |
| 13:16 |
|
kowey |
when I fetched that repo, Quiark, I noticed that not all conflicts were resolved |
| 13:16 |
|
kowey |
I did darcs mark-conflicts |
| 13:16 |
|
mornfall |
In other news, there's a whole lot of young mothers with small children outside in the park. |
| 13:16 |
|
kowey |
and then darcs whatsnew -s |
| 13:16 |
|
kowey |
M ./divine/algorithm/explain.h +551 |
| 13:16 |
|
* mornfall |
everywhere. :D |
| 13:17 |
|
Quiark |
kowey, yep, this is the problematic repo. The local one from which I pushed is ok. |
| 13:17 |
|
mornfall |
Lemme patch that hashed-storage so I can move on to other stuff. |
| 13:18 |
|
kowey |
Quiark: right, so basically what we have here is one of those A+B but not C situations |
| 13:18 |
|
Quiark |
so I should try pushing to it again |
| 13:18 |
|
kowey |
in your local repo, I think there may be a patch you have not yet pushed, which resolves the conflict in ./divine/algorithm/explain.h |
| 13:19 |
|
kowey |
so what I *think* will work is if you revert in the darcsprob repo (which is marked up, see http://www.fi.muni.cz/~xplasil[…]orithm/explain.h) and push the patch in question |
| 13:19 |
|
kowey |
one trick is darcs push --match 'touch divine/algorithm/explain.h' |
| 13:22 |
|
|
arjanb joined #darcs |
| 13:28 |
|
Quiark |
kowey, ok, by comparing darcs changes from both repos I found that on the problematic machine is one more patch which is most likely causing the problem |
| 13:29 |
|
kowey |
ah! darcs pull --dry-run |
| 13:29 |
|
kowey |
(and darcs push --dry-run) |
| 13:29 |
|
kowey |
is the easy way to compare changes |
| 13:29 |
|
kowey |
for future reference... |
| 13:30 |
|
Quiark |
It did not occur to me that the other repo might have a bogus patch. |
| 13:30 |
|
kowey |
you can also do darcs changes on just a file, darcs changes divine/algorithm/explain.h |
| 13:30 |
|
kowey |
ok, so you've hopefully solved your immediate problem |
| 13:31 |
|
Quiark |
yes, it seems to be fine now, thanks |
| 13:31 |
|
|
balor joined #darcs |
| 13:31 |
|
Quiark |
as for user friendliness, maybe darcs should show info about the conflicts (which patches are conflicting) at some point (don't know which point though :) |
| 13:32 |
|
kowey |
great! we're still left with the general "users look at darcs conflicts, and go WTF?" problem to deal with in the long term |
| 13:32 |
|
kowey |
Quiark: well, there's 3 basic things I can think of |
| 13:32 |
|
kowey |
the first is the mark-up problem: http://bugs.darcs.net/issue833 |
| 13:32 |
|
Quiark |
and the thing that revert removes the changes from working dir and then darcs looks like everything is perfectly fine |
| 13:33 |
|
kowey |
the second is the which patch conflicts with what problem |
| 13:33 |
|
kowey |
and the third is the notification problem, which I think you're pointing to |
| 13:34 |
|
kowey |
so the tricky thing, Quiark is that darcs doesn't yet know the difference between mark up it introduced and stuff you typed |
| 13:34 |
|
kowey |
maybe darcs revert by default should do a mark-conflicts |
| 13:35 |
|
kowey |
so that you always revert to a conflicted state... |
| 13:35 |
|
mornfall |
kowey: I guess the invisible conflicts problem could be fixed by darcs printing a WARNING: You have unresolved conflicts in this repository. |
| 13:35 |
|
mornfall |
kowey: Whenever you do things like pull/push/... |
| 13:35 |
|
kowey |
or whatsnew |
| 13:35 |
|
Quiark |
maybe. Or just be loud about the fact that there is a conflict. Not just at revert but at other times as well |
| 13:38 |
|
kowey |
Quiark: one tiny way you could help the cause, http://bugs.darcs.net/issue1681 |
| 13:38 |
|
kowey |
won't change much, but it will at least make the notifications we do print more visible |
| 13:39 |
|
kowey |
Quiark: I'd like to file some tickets for this. May I make you nosy on them? |
| 13:41 |
|
mornfall |
Darn. There's a leak in convert --import. :( |
| 13:41 |
|
kowey |
:-( |
| 13:42 |
|
mornfall |
Ohwell. |
| 13:43 |
|
mornfall |
(Or maybe it's not a leak, just that those 100+ thousand objects for which I hold hashes in memory are just too big...) |
| 13:44 |
|
* mornfall |
kills the conversion and repairs the result... |
| 13:45 |
|
mornfall |
So I need a priority queue. How do you do that in Haskell? :) |
| 13:46 |
|
* mornfall |
googles |
| 13:47 |
|
burp |
http://hackage.haskell.org/pac[…]ive/pkg-list.html |
| 13:47 |
|
burp |
there are a few priority queue implementations |
| 13:49 |
|
Quiark |
kowey, I'm sorry, I don't have haskell platform installed any more and I'm quite busy now |
| 13:50 |
|
mornfall |
Let's try the pure one. |
| 13:50 |
|
kowey |
Quiark: no problem, just doing it-never-hurts-to-ask |
| 13:50 |
|
Quiark |
:) |
| 13:51 |
|
kowey |
Quiark: but OK if I add you to some conflicts-related tickets? |
| 13:51 |
|
kowey |
it means you may get some CC traffic |
| 13:51 |
|
|
zooko joined #darcs |
| 13:52 |
|
kowey |
(and feel free to say no! noise-mgmt is a very important and individual thing) |
| 13:53 |
|
Quiark |
kowey, ok, add me, I can always unlist myself |
| 13:53 |
|
kowey |
thanks |
| 13:54 |
|
mornfall |
It seems I actually need a priority-set. |
| 13:54 |
|
mornfall |
:D |
| 13:56 |
|
|
lispy joined #darcs |
| 14:09 |
|
mornfall |
Ok, that space leak is not new. It's in darcs-2.4 as well (it also happens during check). |
| 14:11 |
|
kowey |
for the interested, the conflict UI tickets that I can think of are http://bugs.darcs.net/issue833 (marking), issue1911 (dependencies), issue1912 (notification) and issue1681 (notification ez) |
| 14:36 |
|
|
zooko` joined #darcs |
| 15:16 |
|
|
zooko joined #darcs |
| 15:19 |
|
mornfall |
gets update >>= ($ x) . ($ path) |
| 15:19 |
|
mornfall |
Haskell rocks. |
| 15:19 |
|
mornfall |
:D |
| 15:23 |
|
kowey |
is that the same as gets update >>= (\f -> f path x)? |
| 15:23 |
|
lispy |
?unpl gets update >>= ($ x) . ($ path) |
| 15:23 |
|
lambdabot |
((gets update) >>= \ e -> e path x) |
| 15:24 |
|
|
balor joined #darcs |
| 15:24 |
|
lispy |
Not sure if lambdabot understands >>= |
| 15:24 |
|
lispy |
?redo gets update >>= ($ x) . ($ path) |
| 15:24 |
|
lambdabot |
Maybe you meant: do read todo undo |
| 15:24 |
|
lispy |
?do gets update >>= ($ x) . ($ path) |
| 15:24 |
|
lambdabot |
do { a <- gets update; (($ x) . ($ path)) a} |
| 15:24 |
|
lispy |
?unpl \a -> (($ x) . ($ path)) a |
| 15:24 |
|
lambdabot |
\ a -> a path x |
| 15:25 |
|
lispy |
I guess it does |
| 15:25 |
|
mornfall |
:) |
| 15:37 |
|
lispy |
where is the ratify stuff now? |
| 15:38 |
|
kowey |
it's a module Ratified (src/Ratified.hs) |
| 15:38 |
|
lispy |
so how do you ban something? |
| 15:38 |
|
lispy |
It seems anyone can just stick a function in there and import it as they see fit? |
| 15:38 |
|
kowey |
contrib/darcs-errors.hlint I think |
| 15:39 |
|
lispy |
right so I add something to .hlint and then to get around it they can just put it in ratified and import it? |
| 15:39 |
|
kowey |
I think that's the idea. |
| 15:40 |
|
lispy |
does anyone actually check for that in patch review? |
| 15:40 |
|
kowey |
one thing to add is System.FilePath.(</>) [should be System.Posix.FilePath.(</>)] |
| 15:40 |
|
kowey |
... although there's an example that just doesn't need ratification |
| 15:40 |
|
kowey |
since the answer is just to use some other module instead |
| 15:41 |
|
kowey |
check for what, lispy? |
| 15:41 |
|
|
balor joined #darcs |
| 15:41 |
|
kowey |
oh, that ratified uses are sensible? |
| 15:41 |
|
lispy |
yes |
| 15:41 |
|
kowey |
a third piece of the puzzle is that Ratified should be imported qualified |
| 15:41 |
|
kowey |
(huh, seems like something haskell_policy should enforce) |
| 15:42 |
|
kowey |
so it kinda sticks out on patch review |
| 15:42 |
|
kowey |
but it's still up to the reviewer to say "hey! that's a ratified thing, better see if it makes sense to use it" |
| 15:43 |
|
lispy |
someone inserted a bunch of unnecessary unsafeCoerce# and it's making me insane |
| 15:44 |
|
lispy |
why have the type witnesses if we're just going to litter the code with unsafeCoerce?? |
| 15:45 |
|
mornfall |
Missing out a lift can have dire consequences. The errors are totally opaque... |
| 15:45 |
|
|
bos joined #darcs |
| 15:47 |
|
lispy |
how do I run the hlist stuff? |
| 15:47 |
|
lispy |
er, hlint |
| 15:48 |
|
kowey |
you can just cabal test tests/haskell_policy.sh |
| 15:48 |
|
kowey |
which in turn runs hlint with a flag to pick up the errors from darcs-errors.hlint |
| 15:52 |
|
|
zooko` joined #darcs |
| 15:54 |
|
kowey |
hmm, http://lackingrhoticity.blogsp[…]rface-in-git.html |
| 15:55 |
|
kowey |
the author points at Darcs set-of-patches style repos as a possible solution to problem of splitting/merging repos |
| 15:56 |
|
kowey |
I think we can only go so far, ourselves, though |
| 15:56 |
|
kowey |
splitting can be blocked on dependencies, and merging on duplicates (eg. Makefile) |
| 15:57 |
|
mornfall |
kowey: merging can be fixed by not having add-add conflicts. |
| 15:57 |
|
kowey |
right |
| 15:58 |
|
mornfall |
kowey: and splitting can be fixed by splitting named patches into prims (which never have cross-file-boundary dependencies, at least for now) |
| 15:58 |
|
kowey |
as suggested by Ganesh in http://wiki.darcs.net/Ideas/AddAddConflicts (add/add) |
| 15:59 |
|
kowey |
so the answer is that yes, Darcs approach would solve the problem, but not Darcs-2010 |
| 15:59 |
|
mornfall |
Yes, it's a very nice property (because subtree checkouts fall out of it for free). |
| 16:00 |
|
mornfall |
(Which are easy with SVN but mostly impossible with GIT.) |
| 16:00 |
|
kowey |
maybe I should write a short comment |
| 16:01 |
|
kowey |
although every time I comment on a blog, I want to say "gah! shut up, already, Eric" |
| 16:14 |
|
|
zooko joined #darcs |
| 17:05 |
|
|
balor joined #darcs |
| 17:07 |
|
|
exlevan joined #darcs |
| 17:38 |
|
|
bos joined #darcs |
| 17:42 |
|
|
abuiles joined #darcs |
| 18:20 |
|
|
lispy1 joined #darcs |
| 18:21 |
|
lispy1 |
?tell Heffalump have you ever read this paper? http://homepages.inf.ed.ac.uk/[…]apers/composable/ I haven't had a chance yet. But section 3.6 has indexed monads that look a lot like RIO. More over, as I explained on my blog delimited continuations seems to have a connection to VCS. That paper uses index monads to type composable continuations (same idea, different terminology). So I think there may actually be something interesting to pursue here. |
| 18:21 |
|
lambdabot |
Consider it noted. |
| 18:25 |
|
|
[1]intripoon joined #darcs |
| 18:27 |
|
mornfall |
burp: I have updated patch332, so you can have a go at the patches if you like |
| 18:28 |
|
burp |
nice |
| 18:28 |
|
burp |
I will try |
| 18:29 |
|
mornfall |
burp: http://bugs.darcs.net/file1688[…]ble-flags_.dpatch should be the patchfile, http://bugs.darcs.net/patch332 has some instructions :) |
| 18:29 |
|
mornfall |
Hm. Make that "--progress=500", git barfs with the space... (sigh). |
| 18:30 |
|
mornfall |
And off I go to bed. See you around. :) |
| 18:30 |
|
|
balor joined #darcs |
| 18:36 |
|
|
lispy1 joined #darcs |
| 18:39 |
|
burp |
mornfall: hm, sadly your patch doesn't build for me |
| 18:42 |
|
Heffalump |
lispy1: I've seen the general line of work, though I'm not sure about that paper. I'm still not really convinced about the connection, I just haven't had time to disagree properly :-) Also I think some of the problems are with just mundane stuff like still having do notation both for the indexed monads and the normal ones in the same file. |
| 18:42 |
|
lambdabot |
Heffalump: You have 1 new message. '/msg lambdabot @messages' to read it. |
| 18:46 |
|
* burp |
runs darcs trackdown "cabal install" |
| 18:46 |
|
burp |
hm or better cabal configure && cabal build |
| 18:53 |
|
|
tux_rocker joined #darcs |
| 19:00 |
|
tux_rocker |
hi |
| 19:02 |
|
tux_rocker |
i have some trouble at work now with an application that went berserk for a change |
| 19:02 |
|
tux_rocker |
darcs 2.5 beta 3 may have to wait a couple of days |
| 19:02 |
|
|
abuiles left #darcs |
| 19:05 |
|
burp |
mornfall: |
| 19:05 |
|
burp |
Trying without the patch: Mon Aug 9 01:25:46 CEST 2010 Petr Rockai <me mornfall.net> UNDO: First version of a fast-importer (convert --import). Success! |
| 19:05 |
|
burp |
this is the first one that compiles :/ |
| 19:26 |
|
mornfall |
burp: How come? |
| 19:26 |
|
mornfall |
burp: Do you have hashed-storage HEAD? |
| 19:26 |
|
burp |
yes |
| 19:26 |
|
burp |
not off to bed yet? then I can paste the error |
| 19:26 |
|
mornfall |
I got up again. |
| 19:27 |
|
mornfall |
I'll retry in a bit, so hurry up with the error. :) |
| 19:28 |
|
burp |
http://paste.railsbox.eu/show/325/ |
| 19:28 |
|
mornfall |
Oh! You have to build with -f-library. |
| 19:28 |
|
burp |
this is with your whole patch stack applied |
| 19:28 |
|
burp |
oh |
| 19:28 |
|
mornfall |
I screwed the witnesses. |
| 19:28 |
|
mornfall |
I *knew* I wanted to add something important to that TODO list. |
| 19:29 |
|
* mornfall |
adds a comment |
| 19:29 |
|
burp |
*tries compiling now* |
| 19:30 |
|
burp |
yay, it worked |
| 19:34 |
|
burp |
I have an exported file from hg-fast-export.py, that should work with your import, right? |
| 19:34 |
|
mornfall |
Well, no idea. I only tried with git fast-export. :) |
| 19:34 |
|
mornfall |
And with darcs convert --export. |
| 19:34 |
|
burp |
let's try |
| 19:34 |
|
burp |
cat /tmp/bzr-fastimport/exporters/hedgewars.export | ~/build/darcs.net/dist/build/darcs/darcs convert --import foo |
| 19:35 |
|
burp |
"foo" is growing :D |
| 19:37 |
|
burp |
mhm, already 800MB ram usage, I'll give it 2GB and then abort :> |
| 19:37 |
|
mornfall |
How big is the project? |
| 19:37 |
|
burp |
~700MB |
| 19:37 |
|
mornfall |
Oh dear. :) |
| 19:38 |
|
mornfall |
Hm. The converter also doesn't quite support binaries... |
| 19:38 |
|
mornfall |
(It'll create text patches no matter what.) |
| 19:38 |
|
burp |
oh� |
| 19:38 |
|
lispy1 |
Heffalump: well, they are definitely connected, even if only because del. cont. are powerful enough to describe all the state transitions |
| 19:39 |
|
lispy1 |
Heffalump: It's possible you disagree with my mapping of darcs into del. cont. operations. That part is still fuzzy (although, I did create a .hs file to demonstrate a merge) |
| 19:39 |
|
burp |
you need to handle that next then ;) |
| 19:39 |
|
mornfall |
burp: darcs in general doesn't like binaries |
| 19:39 |
|
burp |
you mean in the sense, that it doesn't use binary diffs? |
| 19:40 |
|
lispy1 |
burp: Yes, but binary diffs are sort of bad anyway. |
| 19:40 |
|
mornfall |
burp: Well, it stores binaries *extremely* inefficiently. |
| 19:40 |
|
lispy1 |
burp: the real problem is yeah what mornfall just said |
| 19:40 |
|
burp |
hm ok |
| 19:40 |
|
lispy1 |
burp: In darcs, binary really means "don't merge this with other versions of this file." |
| 19:40 |
|
burp |
it's stable at 1.5G ram usage now |
| 19:41 |
|
lispy1 |
burp: and that's an important abstraction to have. Any machine generated content you typically don't want humans trying to merge because they may not understand the bytes. |
| 19:42 |
|
lispy1 |
burp: so binary serves as a way to say, 'hey, when there are multiple updates to this blob, don't try to merge them.' |
| 19:42 |
|
Heffalump |
lispy1: VCS is related to a turing machine because you can implement it on one, but that's not particularly useful |
| 19:42 |
|
lispy1 |
Then we endup with binary format that stores all the new and all the old |
| 19:43 |
|
lispy1 |
Heffalump: Sure it is. That's how we were able to implement darcs in Haskell :) |
| 19:43 |
|
Heffalump |
there's a trivial optimisation to that format that noone's got round to implementing (it'd also be backwards incompatible in terms of darcs versions, though not in terms of patch theory) |
| 19:43 |
|
Heffalump |
lispy1: :-p |
| 19:44 |
|
burp |
"\o/ It seems we survived. Enjoy your new repo." |
| 19:44 |
|
mornfall |
burp: wow. |
| 19:44 |
|
burp |
it's mainly binary stuff, because it's a game repository |
| 19:44 |
|
lispy1 |
Heffalump: but to be fair, there is a deeper connection (I'm sure of it, regardless of how poorly I've explained it) between vcs and del. cont. And I think it's a useful connection too. |
| 19:44 |
|
mornfall |
yeah, I derived that from the name and size :) |
| 19:45 |
|
lispy1 |
Heffalump: I just have to get to a point where I can explain what I'm seeing |
| 19:47 |
|
burp |
<mornfall> Hm. The converter also doesn't quite support binaries... - hmm |
| 19:47 |
|
lispy1 |
Heffalump: to be fair, I'm not confident that darcs fits elegantly into it -- which to me says that the patch theory might have some warts. Some warts that it may help point out. |
| 19:47 |
|
burp |
what do you mean by that? as far as I can see it worked here |
| 19:48 |
|
burp |
the changes say things like "addfile ./share/hedgewars/Data/Maps/FlightJoust/preview.png binary ./share/hedgewars/Data/Maps/FlightJoust/preview.png " |
| 19:48 |
|
mornfall |
Huh? |
| 19:48 |
|
lispy1 |
burp: darcs does some magic to find binary files. So it may have auto detected that one as binary |
| 19:48 |
|
mornfall |
I don't think that should be possible. :) |
| 19:49 |
|
mornfall |
burp: Oh! |
| 19:49 |
|
mornfall |
burp: I see. |
| 19:49 |
|
mornfall |
burp: If they are "obviously" binary then it works. |
| 19:49 |
|
mornfall |
burp: But the normal regex filtering that darcs does is not implemented. |
| 19:49 |
|
burp |
hm ok |
| 19:50 |
|
mornfall |
(Obviously meaning they contain funky characters like ^Z or such...) |
| 19:50 |
|
lispy1 |
mornfall: but the is_funky is still there right? |
| 19:50 |
|
lispy1 |
or maybe it's isFunky these days. Not sure how far Eric's refactors have gone |
| 19:50 |
|
burp |
well, that I should be fine with that repository, as graphics and sounds are probably all "obvious" |
| 19:50 |
|
lispy1 |
Heffalump: in other news, I noticed that we have unsafeCoerce# in Prim.lhs when it can (and should be) unsafeCoerceP |
| 19:50 |
|
lispy1 |
Heffalump: in a _lot_ of places. |
| 19:51 |
|
lispy1 |
Heffalump: I'd like to add GHC.Base ( unsafeCoerce# ) to the banned imports list |
| 19:51 |
|
lispy1 |
Heffalump: I started working on that this morning before going to work but I accidentally unpulled my patch right before sending :( |
| 19:51 |
|
Heffalump |
oops :-( |
| 19:51 |
|
Heffalump |
sounds fine, anyway |
| 19:52 |
|
lispy1 |
Do unpulled matches continue to exist though? They are just removed from inventory right? |
| 19:52 |
|
lispy1 |
If so, i might be able to find it with find later |
| 19:52 |
|
lispy1 |
Heffalump: I also discovered that mapPrimFL is a very dangerous function. |
| 19:53 |
|
lispy1 |
Heffalump: it reorders the patches using an Ord instance |
| 19:53 |
|
lispy1 |
Heffalump: and so it cannot enforce its invariants nor can it check them |
| 19:53 |
|
lispy1 |
Heffalump: I'm not sure what to do about it yet though |
| 19:53 |
|
lispy1 |
It just has to assume that Ord for Prim is correct |
| 19:54 |
|
lispy1 |
We really need a variant of Data.Map that lets you create it with specified compartor |
| 19:54 |
|
lispy1 |
That would help a lot |
| 19:54 |
|
lispy1 |
(in mean in general, not just for mapPrimFL) |
| 19:58 |
|
Heffalump |
lispy1: I think so (re obliterate) |
| 19:59 |
|
Heffalump |
lispy1: I know mapPrimFL is a bit dangerous looking, but it's a useful looking optimisation |
| 19:59 |
|
Heffalump |
and it's been there a long time and has never been implicated in any trouble |
| 19:59 |
|
Heffalump |
it's nothing to do with Ord being correct. |
| 20:00 |
|
lispy1 |
Heffalump: Well, it has been in the critical path of bugs. issue525 |
| 20:00 |
|
Heffalump |
it's a question of whether the code as a whole is correct in its assumption that it can freely reorder patches that touch different files |
| 20:00 |
|
Igloo |
What are the keys in the map it makes? |
| 20:00 |
|
Heffalump |
I did vaguely consider dropping the optimisation when I was doing the witnesses |
| 20:00 |
|
Heffalump |
Igloo: FileName |
| 20:00 |
|
lispy1 |
Igloo: files |
| 20:00 |
|
Heffalump |
and it rejects move patche |
| 20:01 |
|
lispy1 |
It only takes patches that can be converted to Simple |
| 20:01 |
|
Igloo |
Ah, OK |
| 20:01 |
|
Heffalump |
lispy1: I don't see anything in the comments on that bug about it |
| 20:01 |
|
Heffalump |
lispy1: if we benchmark we could consider removing it. I don't think it's worth worrying about too much though. |
| 20:02 |
|
* Igloo |
wonders when it's actually used with patches that aren't already sorted by filename |
| 20:02 |
|
lispy1 |
Heffalump: sortCoalenceFL is implemented using mapPrimFL. The comment in the source says: -- Running canonize twice is apparently necessary to fix issue525; |
| 20:02 |
|
lispy1 |
-- would be nice to understand why. |
| 20:02 |
|
lispy1 |
The first call is before sortCoaleseFL and the second is after it |
| 20:02 |
|
lispy1 |
Heffalump: well, removing it breaks darcs |
| 20:02 |
|
Heffalump |
lispy1: removing what? |
| 20:03 |
|
lispy1 |
Heffalump: I was going to do exactly that benchmark |
| 20:03 |
|
Heffalump |
the optimisation? |
| 20:03 |
|
Heffalump |
you're saying that mapPrimFL f ps = f ps causes the tests to fail? |
| 20:03 |
|
lispy1 |
Heffalump: Yeah, maybe my refactor was wrong but I did, mapPrimFL f x = f x |
| 20:03 |
|
lispy1 |
yes |
| 20:03 |
|
Heffalump |
and it breaks 525? |
| 20:03 |
|
lispy1 |
It broke many things, but I didn't test issue525 directly |
| 20:04 |
|
Heffalump |
well, that sucks. It looks like it should be an optimisation only. |
| 20:04 |
|
lispy1 |
Heffalump: So, I think the patches come out the other end sorted by file name |
| 20:04 |
|
lispy1 |
And that probably interacts with the shrinking and other things |
| 20:04 |
|
Heffalump |
yeah, they would |
| 20:04 |
|
Heffalump |
lovely. Not. |
| 20:05 |
|
Heffalump |
that means that if you stick a move into a sequence of patches, darcs' behaviour will change |
| 20:05 |
|
Heffalump |
on the other patches too |
| 20:05 |
|
Heffalump |
any move, even one unrelated to the existing patches |
| 20:06 |
|
lispy1 |
hm |
| 20:06 |
|
lispy1 |
Heffalump: So it's not the ordering of Prims that matters here is it? I mean my complaint about Ord |
| 20:06 |
|
lispy1 |
It's using Ord on String |
| 20:09 |
|
lispy1 |
Heffalump: so then do you have an idea for how to demonstrate a bug in the current implementation? |
| 20:10 |
|
Heffalump |
lispy1: well, I guess the ordering does sort of matter, but I suspect it's more to do with the bucketing by filename. |
| 20:10 |
|
Heffalump |
lispy1: sounds like you already have. If replacing something described as an optimisation causes a behaviour change, that's a bug. |
| 20:11 |
|
Heffalump |
if you want an external case I guess boil down one of the test failures you get. |
| 20:11 |
|
lispy1 |
Heffalump: that's a good idea. |
| 20:11 |
|
lispy1 |
Heffalump: I just thought maybe you had a sequence in mind (I don't) |
| 20:11 |
|
|
balor joined #darcs |
| 20:11 |
|
Heffalump |
lispy1: I don't know what actually goes wrong. I wouldn't have expected anything to. |
| 20:12 |
|
Heffalump |
generally, taking a sequence of Prims on the same file that can be coalesced, and comparing behaviour with a sequence of Prims + an unrelated move, might be the way to demonstrate a difference |
| 20:12 |
|
lispy1 |
Heffalump: Well, I suspect that what really goes wrong is that things don't 'replay' in the right order. I recall one of the tests that failed was complaining it couldn't create a file in a directory that doesn't exist. |
| 20:12 |
|
Heffalump |
I think the "proper" fix is to figure out how to make canonize actually canonize things, rather than just sort of try to improve them a bit |
| 20:13 |
|
Heffalump |
oh, that's the same problem as I found with treeDiff the other day. It turns out treeDiff produces wrong patches, but if you run canonizeFL on the result they get fixed. |
| 20:13 |
|
Heffalump |
I guess mapPrimFL is the mechanism by which they get fixed. |
| 20:13 |
|
Heffalump |
so it might be that fixing treeDiff solves the problem |
| 20:14 |
|
Igloo |
I don't understand why that doesn't break remove patches |
| 20:14 |
|
Heffalump |
Igloo: I don't even want to understand. I just want to fix it :-) |
| 20:14 |
|
Igloo |
Amen |
| 20:15 |
|
Igloo |
Although understanding that might be useful in fixing it correctly |
| 20:15 |
|
Igloo |
Aha, toSimple (DP _ RmDir) = Nothing |
| 20:16 |
|
Igloo |
So the "optimisation" is necessary to fix adds, but would break removes |
| 20:17 |
|
Igloo |
And you can presumably easily make darcs fail, or produce a bad patch, with a patch that adds a directory and file, while at the same time removing another one |
| 20:17 |
|
Heffalump |
oh, good point |
| 20:18 |
|
lispy1 |
Igloo: oh, that might be what EXAMPLE.sh does |
| 20:18 |
|
lispy1 |
mkdir d e; echo 'Example content.' > d/f; record -lam; darcs mv d/f e/; record -am |
| 20:18 |
|
Heffalump |
Igloo: I made a patch that does that, and it's clearly in the wrong order, but darcs check doesn't fail |
| 20:19 |
|
Heffalump |
the slightly stricter checker I wrote for my shrinker will though |
| 20:19 |
|
lispy1 |
Heffalump: I'm 90% sure that EXAMPLE.sh was one of the failing ones |
| 20:19 |
|
lispy1 |
Heffalump: so you might start with it |
| 20:20 |
|
Heffalump |
oh, darcs has broken. It doesn't know that the file I added exists, even though it's in the patch. |
| 20:20 |
|
* lispy1 |
gets HEAD to do a test |
| 20:20 |
|
Igloo |
Hmm, I can't make it fail with 2.4.3 |
| 20:20 |
|
Heffalump |
so I was able to record the add again. darcs check still doesn't complain though. |
| 20:20 |
|
Igloo |
Is this code newer than that? |
| 20:20 |
|
|
exlevan joined #darcs |
| 20:21 |
|
Heffalump |
I rewrote it (mapPrimFL) for witnesses, but I didn't intend to change the behaviour. |
| 20:21 |
|
lispy1 |
Heffalump: I don't think you did |
| 20:22 |
|
mornfall |
Igloo: I don't think anything changed since 2.4 in that dept. |
| 20:22 |
|
Heffalump |
except that mapPrimFL got rewritten by me |
| 20:22 |
|
lispy1 |
Heffalump: if I get the 2.4.0 tag it won't have your rewrite, right? |
| 20:23 |
|
mornfall |
Heffalump: Oh? |
| 20:23 |
|
Heffalump |
mornfall: just to add witnesses. |
| 20:23 |
|
Heffalump |
but that wasn't completely mechanical given that it's fundamentally unwitnessable |
| 20:23 |
|
mornfall |
Ok, I must have reviewed that I guess. :D |
| 20:23 |
|
Igloo |
Hmm. Shouldn't http://paste.debian.net/82667/ tickle the bug? |
| 20:24 |
|
Heffalump |
Igloo: yes, I think so |
| 20:24 |
|
Igloo |
Does it in HEAD? |
| 20:24 |
|
mornfall |
It might be failing to do so due the thick layer of pending magic. |
| 20:25 |
|
Heffalump |
Igloo: no. |
| 20:25 |
|
Heffalump |
I'll make a paste of what I did |
| 20:25 |
|
Igloo |
Ah, good spot. This breaks: |
| 20:26 |
|
Igloo |
http://paste.debian.net/82668/ |
| 20:26 |
|
Heffalump |
yes, I think you have to use -l |
| 20:27 |
|
Igloo |
Someone please feel free to add that as a test, with whichever licence will cause the fewest arguments |
| 20:27 |
|
mornfall |
:D |
| 20:27 |
|
Heffalump |
I think each contributor should have their own licence. |
| 20:28 |
|
mornfall |
A different one, hopefully. |
| 20:28 |
|
mornfall |
So that we get to put multiple license boilerplates to each test... :D |
| 20:28 |
|
lispy1 |
Heffalump: I just reviewed your refactor. I think it's fine. I can't see how it would change the behavior we care about |
| 20:29 |
|
Heffalump |
Igloo: you get that breaking with 2.4 too, right? |
| 20:29 |
|
Igloo |
That's 2.4.3 |
| 20:29 |
|
Heffalump |
which I think dispels the suspicion that something has changed |
| 20:29 |
|
Igloo |
And so actually, in the case I guessed the optimisation might actually optimise, the optimisation isn't actually used |
| 20:31 |
|
lispy1 |
Heffalump: So one thing I don't get. (fromSimple . toSimple) /= id, right? |
| 20:31 |
|
lispy1 |
Heffalump: You necessarily lose patches here or I'm not seeing something? |
| 20:31 |
|
Heffalump |
so, I think the route to fixing this, is (a) make treeDiff produce things in the right order and (b) check whether mapPrimFL still changes behaviour. |
| 20:31 |
|
Igloo |
(c) remove mapPrimFL unless someone can give an example of something that it optimises |
| 20:32 |
|
Heffalump |
lispy1: that equality is not type correct, even if you ignore currying |
| 20:32 |
|
Heffalump |
Igloo: I'd put that in reverse: remove mapPrimFL if someone checks the benchmarks first. |
| 20:32 |
|
Heffalump |
lispy1: and the extra Maybe is what's key to it not being id |
| 20:32 |
|
lispy1 |
Heffalump: Well, I guess I'm just asking, "Doesn't it remove patches and then you can't recover them because it's a surjection?" |
| 20:33 |
|
Heffalump |
where does it remove patches? mapPrimFL falls back. |
| 20:33 |
|
Heffalump |
which is the root of the test case Igloo mentioned |
| 20:33 |
|
lispy1 |
> mapM (\x -> if x == 1 then Just 2 else Nothing) [Just 1, Just 2, Just 3] |
| 20:33 |
|
lambdabot |
No instance for (GHC.Num.Num (Data.Maybe.Maybe t)) |
| 20:33 |
|
lambdabot |
arising from the lite... |
| 20:33 |
|
Igloo |
(fromSimple . toSimple) would lose patches, but it isn't used |
| 20:33 |
|
lispy1 |
:t mapM |
| 20:33 |
|
lambdabot |
forall a (m :: * -> *) b. (Monad m) => (a -> m b) -> [a] -> m [b] |
| 20:34 |
|
Heffalump |
mapM f xs on the Maybe monad fails if f fails on any element of xs |
| 20:34 |
|
lispy1 |
> mapM (\x -> if x == 1 then Just 2 else Nothing) [1, 2, 3] |
| 20:34 |
|
lambdabot |
Nothing |
| 20:34 |
|
lispy1 |
Okay |
| 20:34 |
|
lispy1 |
So they have to all be simple patches |
| 20:35 |
|
lispy1 |
Otherwise we just do f x |
| 20:35 |
|
Igloo |
Right |
| 20:36 |
|
lispy1 |
So how is that code really splitting things into chunks? |
| 20:37 |
|
lispy1 |
That happens inside mapWithKey I guess |
| 20:37 |
|
lispy1 |
So, I wonder how that's an optimization |
| 20:38 |
|
* Igloo |
can't read "fromSimples" other than in a meerkat voice </UK-only comment> |
| 20:38 |
|
Heffalump |
is that a chipmunks reference? |
| 20:39 |
|
Igloo |
No |
| 20:39 |
|
Heffalump |
lispy1: it's an optimisation if f is quadratic on the list it gets passed |
| 20:39 |
|
Heffalump |
which most functions that do significant commutation are |
| 20:39 |
|
lispy1 |
Heffalump: Oh. Right |
| 20:39 |
|
Heffalump |
the right general fix is to make commutation faster, somehow. I've been thinking about that for a while. |
| 20:39 |
|
lispy1 |
I get it now, yes |
| 20:39 |
|
Igloo |
http://www.youtube.com/watch?v=4Ust9YBlEfY |
| 20:39 |
|
Heffalump |
(faster in time complexity) |
| 20:40 |
|
lispy1 |
Igloo: hehe, nice |
| 20:40 |
|
Heffalump |
Igloo: I don't watch enough TV to get that :-) |
| 20:41 |
|
|
abuiles joined #darcs |
| 20:41 |
|
Heffalump |
IM to have got that before the youtube link |
| 20:41 |
|
Igloo |
Oh, I see. So it's probably still worth chunking the patches by filename; just not sorting them first |
| 20:42 |
|
lispy1 |
Heffalump: so mapPrimFL is using the map to partition things. The assumption it makes is that if everything is "simple" then you can divide the patches up based on the paths of things they modify. |
| 20:42 |
|
Igloo |
That's a pretty scary thing for mapPrimFL to be doing, though. I guess it's probably safe in practice, but it still scares me. |
| 20:42 |
|
mornfall |
Heffalump: Not using consed lists could help, maybe? |
| 20:43 |
|
lispy1 |
mornfall: you want to use something like Data.Vector isntead? |
| 20:43 |
|
Heffalump |
mornfall: for commutation in general? |
| 20:43 |
|
mornfall |
Heffalump: For commutation, yes. |
| 20:43 |
|
Igloo |
Now I actually look at it, mapPrimFL isn't a map at all |
| 20:43 |
|
Heffalump |
you need good summary information for trees to help. |
| 20:43 |
|
Heffalump |
Igloo: agreed |
| 20:43 |
|
lispy1 |
mornfall: what do you mean by consed lists? |
| 20:44 |
|
lispy1 |
Igloo: it is in the fmap sense |
| 20:44 |
|
mornfall |
lispy1: The functional version of linked list. :) |
| 20:44 |
|
Heffalump |
lispy1: no it's not |
| 20:44 |
|
Heffalump |
the unoptimised version is just ($) |
| 20:44 |
|
Heffalump |
mornfall: the complexity is the fact that every patch has to commute past every other. |
| 20:44 |
|
mornfall |
Heffalump: Well, you could do a radix sort then. :] |
| 20:45 |
|
mornfall |
Heffalump: Based on filenames... |
| 20:45 |
|
mornfall |
Just like mapPrimFL does. |
| 20:45 |
|
Heffalump |
mornfall: sure, but moves get in the way |
| 20:45 |
|
Heffalump |
and within a single file you're still screwed, though it may not matter in practice |
| 20:45 |
|
mornfall |
Heffalump: That's why you want to avoid the filename-based hunks. |
| 20:45 |
|
mornfall |
Heffalump: Among other things. |
| 20:45 |
|
Heffalump |
you mean have filepatches apply to unique id, not filename? |
| 20:46 |
|
mornfall |
Just stick in a good ol' UUID and you can radix through like a hot knife through butter. |
| 20:46 |
|
Heffalump |
until we get hunk move |
| 20:46 |
|
mornfall |
Right. Then you are screwed again. |
| 20:46 |
|
mornfall |
But there's no proof that hunk move is even possible. |
| 20:46 |
|
Heffalump |
sez who? |
| 20:46 |
|
mornfall |
me... is there? |
| 20:46 |
|
lispy1 |
Are you saying it's not map/fmap because it reorders the list? |
| 20:47 |
|
Heffalump |
well, depends what you mean by a proof. |
| 20:47 |
|
Heffalump |
lispy1: I'm saying it's not map or fmap because it just isn't the same :-) |
| 20:47 |
|
mornfall |
Heffalump: Well, let's say that there's also no proof that conflictors actually work (unless Igloo has made some further advances that I don't know about). :) |
| 20:47 |
|
Heffalump |
ah, but we have positive evidence they don't work :-) |
| 20:48 |
|
mornfall |
Well, I mean, at all. |
| 20:48 |
|
Heffalump |
I'm pretty certain hunk move does work, it's just a question of getting the right commute rules. |
| 20:48 |
|
mornfall |
We have definitely good evidence that they don't work very well. |
| 20:49 |
|
Igloo |
lispy1: mapped functions only see one element, not a list |
| 20:49 |
|
mornfall |
Heffalump: Hunk move would commute by teleporting other hunks when they overlap, right? (And like ordinary hunks for non-overlaps and fails for partial overlaps?) |
| 20:49 |
|
Igloo |
Heffalump: I'm not convinced camp's conflictors don't work (but also don't have a proof that they do) |
| 20:50 |
|
mornfall |
I've been always saying that we should just not allow conflicted repositories to exist. :) |
| 20:50 |
|
lispy1 |
Igloo: yeah, I guess I was (incorrectly) thinking of that chunk as one big value that it gets. Sort of like if you map (f :: [a] -> [a]) over [[a]] |
| 20:50 |
|
Heffalump |
mornfall: correct (if by overlap you mean containment and partial overlaps you mean offsetting) |
| 20:50 |
|
Heffalump |
and re conflictors, we know they have bad time complexity |
| 20:50 |
|
mornfall |
And space complexity, too. |
| 20:50 |
|
Heffalump |
they're just bad. Graphs FTW ;-) |
| 20:51 |
|
mornfall |
But there's a reasonable chance that there's a lower bound on size of conflict representation that commutes correctly that's not O(1)... |
| 20:51 |
|
Heffalump |
Do you mean O(n)? |
| 20:52 |
|
mornfall |
I mean O(1). |
| 20:52 |
|
mornfall |
Anything beyond O(1) leads to quadratic repositories. |
| 20:52 |
|
Heffalump |
O(1) in what? |
| 20:52 |
|
mornfall |
In number of conflicted patches. |
| 20:52 |
|
Heffalump |
so you have k conflicted patches and then they don't get stored at all in the conflict? |
| 20:53 |
|
mornfall |
Right. So that's impossible so I conjecture that any self-contained conflict representation will lead to quadratic repositories. |
| 20:53 |
|
Heffalump |
as long as you only store each patch in one conflictor, the repository doesn't grow. |
| 20:53 |
|
Heffalump |
IM not in complexity terms. |
| 20:53 |
|
Heffalump |
and you only ever need to store it in one conflictor, because once it's undone it can't be redone |
| 20:54 |
|
mornfall |
How do you conflate the patches into a single conflictor? |
| 20:55 |
|
Heffalump |
conflate what patches? |
| 20:55 |
|
mornfall |
All that conflict. |
| 20:55 |
|
mornfall |
I mean, if you have a conflict fight... |
| 20:55 |
|
mornfall |
you get conflict among conflictors |
| 20:55 |
|
Heffalump |
a conflict fight has resolution patches |
| 20:55 |
|
mornfall |
how do you avoid storing the confictors that conflict in the new patch? |
| 20:55 |
|
Heffalump |
you don't need to |
| 20:56 |
|
Heffalump |
just don't store them :-) |
| 20:56 |
|
Heffalump |
hmm. Perhaps it's not that simple. |
| 20:56 |
|
Heffalump |
but it might be. |
| 20:56 |
|
mornfall |
I have some issues with believing that you can define correct commute. |
| 20:56 |
|
mornfall |
(Without storing them.) |
| 20:57 |
|
Heffalump |
If you don't locally know what you conflict with, it might be hard to know when you can unconflict yourself. |
| 20:57 |
|
Heffalump |
You might need to keep a count of things you conflicted with that aren't actually stored with you. |
| 20:58 |
|
Igloo |
If you don't know what you conflict with, you can't know if you are being commuted to the left of something you conflict with or a dependency, can you? |
| 20:58 |
|
mornfall |
It'd be interesting to know that you can get away with just a counter... |
| 20:58 |
|
mornfall |
Igloo: Sounds like a problem indeed. |
| 21:00 |
|
Heffalump |
you can't get up to something you conflict with without having that stored in you |
| 21:00 |
|
Heffalump |
perhaps |
| 21:01 |
|
Igloo |
DYM in A+B+C, C would only store A? |
| 21:01 |
|
Igloo |
If so, how do you handle A and B being commuted? |
| 21:01 |
|
Heffalump |
what's in conflict? |
| 21:01 |
|
Igloo |
All of them |
| 21:02 |
|
mornfall |
(I know it's getting old, but I am a bit sceptical about solving a global problem (conflicts) locally (in commute) :P) |
| 21:03 |
|
Heffalump |
A[B|A][C|] |
| 21:03 |
|
Igloo |
Is that all the information that would be stored? |
| 21:04 |
|
Heffalump |
dunno yet :-) In my current idea, yes. |
| 21:04 |
|
Heffalump |
though as I said C might need to store the count 2 as well. |
| 21:04 |
|
Igloo |
What would it look like if B and C don't conflict? |
| 21:04 |
|
Heffalump |
ok, let's add numbers |
| 21:04 |
|
Heffalump |
A[B|A,0][C|,2] |
| 21:05 |
|
Heffalump |
and A[B|A,0][C|,1] |
| 21:05 |
|
lispy1 |
mornfall: re: global vs. local. Yes, that's my feeling as well. |
| 21:05 |
|
Heffalump |
in the initial case and your new one |
| 21:05 |
|
mornfall |
(I have a nagging feeling that I have seen this representation somewhere.) |
| 21:05 |
|
* Igloo |
is not optimistic about this |
| 21:07 |
|
Heffalump |
I see your point :-) |
| 21:07 |
|
Heffalump |
well, we can at least eliminate internal redudancy in a single conflictor by using a graph |
| 21:07 |
|
Igloo |
DYM you can make it more space efficient? |
| 21:07 |
|
Heffalump |
yes |
| 21:11 |
|
mornfall |
Ok, my 2008 representation is fairly different. |
| 21:12 |
|
Heffalump |
look, even if it's wrong I need my own conflict representation or I'll never be a proper darcs hacker! |
| 21:12 |
|
Igloo |
:-) |
| 21:12 |
|
lispy1 |
haha |
| 21:12 |
|
lispy1 |
monad tutorial : haskell :: conflictor representation : darcs hacking |
| 21:14 |
|
mornfall |
:) |
| 21:17 |
|
mornfall |
My current position is that handling conflicts at a repository level would work a lot better. |
| 21:32 |
|
abuiles |
hi |
| 21:32 |
|
Heffalump |
hi abuiles. Have you produced a conflictor representation yet? ;-) |
| 21:33 |
|
mornfall |
:D |
| 21:33 |
|
abuiles |
hi Heffalump, what ? |
| 21:33 |
|
abuiles |
ohh sorry, |
| 21:34 |
|
abuiles |
I wasn't reading the log. |
| 21:34 |
|
Heffalump |
that's ok, we'll forgive you as long as you produce one by tomorrow. |
| 21:34 |
|
abuiles |
I need to do first a monad tutorial. |
| 21:35 |
|
Heffalump |
god, how did you ever get accepted for GSoC without that basic qualification? |
| 21:35 |
|
Heffalump |
standards must be slipping! |
| 21:35 |
|
abuiles |
I was pure. |
| 21:35 |
|
Igloo |
It's quite an easy task. All you need to do is write down an algorithm that doesn't work. |
| 21:37 |
|
arjanb |
and you have to invent a new notation for it |
| 21:37 |
|
mornfall |
:D |
| 21:38 |
|
mornfall |
It's reminding me of those days of revctl where everyone had their own dag-aware text merge algorithm. |
| 21:41 |
|
abuiles |
mornfall, I just send the patch to support the environment variable for setting the timeout, I'm not adding support for HTTP yet. |
| 21:42 |
|
burp |
mornfall: have you tried if the stuff in the repository is still correct for your imported repositories? |
| 21:42 |
|
burp |
I mean, in case of branches |
| 21:44 |
|
mornfall |
burp: In what sense? |
| 21:45 |
|
mornfall |
burp: The tags get mangled somewhat by branch switching, for one. |
| 21:45 |
|
burp |
that it still compiles for example, as changes from different branches are not "mixed up" |
| 21:45 |
|
mornfall |
burp: If I unpull patches? No I haven't tried that. |
| 21:45 |
|
mornfall |
burp: The history is linearised and you get warnings about that. |
| 21:46 |
|
burp |
but the latest one should work |
| 21:46 |
|
burp |
(let me try again) |
| 21:46 |
|
mornfall |
Yes, heads should be identical. |
| 21:46 |
|
mornfall |
diff -ruN -x .git -x _darcs gitrepo darcsrepo |
| 22:00 |
|
burp |
sadly not the case |
| 22:01 |
|
mornfall |
Bummer. |
| 22:01 |
|
burp |
but might be that the hg-fast-export.py is fault |
| 22:01 |
|
mornfall |
Try importing it into git, then. |
| 22:01 |
|
mornfall |
It may also help to pass it through real git: git fast-import and then fast-export the result again. |
| 22:09 |
|
burp |
ok, git fast-import worked, I will reexport there now |
| 22:18 |
|
|
Igloo joined #darcs |
| 22:18 |
|
|
Heffalump joined #darcs |
| 22:22 |
|
burp |
ok, nice with git fast-export one can export just one branch� that works in any case |
| 22:25 |
|
burp |
interesting, the _darcs directory gets much bigger now through git fast-export |
| 22:27 |
|
mornfall |
burp: That's probably because git uses "blob" commands in the stream. |
| 22:27 |
|
mornfall |
burp: Which need to be stored until the operation finishes, since they can be referenced at any time. |
| 22:28 |
|
mornfall |
burp: Darcs will clean that up after finishing (assuming it finishes). |
| 22:28 |
|
burp |
ok |
| 22:28 |
|
mornfall |
Btw. there's fast-export --all. |
| 22:28 |
|
mornfall |
But fast-export HEAD (or master) should work fairly reliably, yes. |
| 22:32 |
|
burp |
hm, no such cleanup it ~300MB bigger, but at least works :> |
| 22:33 |
|
Igloo |
Did anyone do anything with that testcase, or should I file a ticket? |
| 22:38 |
|
burp |
darcs optimize did it's job :) down from 1.1GB to 780MB |
| 22:38 |
|
burp |
mornfall: will you create support for incremental imports? |
| 22:39 |
|
mornfall |
burp: That's missing optimize at the end I guess, sorry. :) |
| 22:40 |
|
mornfall |
burp: Eventually, I guess so, although I'll be busy with other stuff for a while. |
| 22:40 |
|
burp |
ok |
| 22:40 |
|
mornfall |
It'll probably just use tags with marks in it. Shouldn't be too hard. |
| 22:41 |
|
mornfall |
lambdabot: @src fix |
| 22:41 |
|
lambdabot |
fix f = let x = f x in x |
| 22:42 |
|
mornfall |
What good is it? : - P |
| 22:45 |
|
mornfall |
I want iterate-until-fixpoint. :| |
| 22:56 |
|
|
balor joined #darcs |
| 23:36 |
|
Igloo |
mornfall: Any idea why darcs thinks a file should be removed, when the file exists in working and there is noting in pending? |
| 23:37 |
|
|
abuiles left #darcs |
| 23:37 |
|
|
FunctorSalad joined #darcs |
| 23:37 |
|
Igloo |
Hmm, recording a patch that doesn't include those changes has made darcs no longer want to record them |
