| Time |
S |
Nick |
Message |
| 00:06 |
|
|
gh_ left #darcs |
| 00:23 |
|
|
secorp joined #darcs |
| 00:32 |
|
iago |
well I think I pronounce it right |
| 00:32 |
|
lambdabot |
iago: You have 1 new message. '/msg lambdabot @messages' to read it. |
| 00:34 |
|
Heffalump |
iago: I'm around for a brief fre minutes |
| 00:36 |
|
iago |
Heffalump, what is the purpose of Trees ? |
| 00:36 |
|
iago |
I understand +/- the related code |
| 00:37 |
|
Heffalump |
it's to get something you can merge |
| 00:37 |
|
Heffalump |
if you make a linear sequence of patches, there's nothing to merge |
| 00:37 |
|
Heffalump |
if you make a tree, you can flatten the tree and do some merges |
| 00:37 |
|
Heffalump |
do some merges while flattening the tree |
| 00:37 |
|
iago |
oh, I should read lambdabot before |
| 00:37 |
|
iago |
I get it |
| 00:38 |
|
iago |
but, well |
| 00:38 |
|
iago |
when you generate WithEndState I can imagine you run the apply-patch |
| 00:38 |
|
iago |
and after that you could check if the result is the expected |
| 00:39 |
|
Heffalump |
yeah, I can't remember the precise details of why things are the way they are in that area |
| 00:39 |
|
iago |
(I have stopped at line 343 so maybe I'm losing some detail) |
| 00:40 |
|
iago |
well. just another question |
| 00:40 |
|
iago |
why do you replace "identity" patches by another "identity" patch ? |
| 00:40 |
|
iago |
(localIdentity) |
| 00:41 |
|
iago |
I see (from comments) that in the past that code replaces "identity" patches by the Identity Prim patch, though you have removed Identity Prim recently |
| 00:41 |
|
Heffalump |
try removing that and see what fails |
| 00:41 |
|
Heffalump |
I can't actually remember precisely why, but it's basically because the rest of the code can't cope properly. |
| 00:42 |
|
Heffalump |
localIdentity was a quick hack because I wanted to get rid of Identity, and it was only being used significantly in the test harness. |
| 00:42 |
|
Heffalump |
so I felt making the test harness a bit uglier in exchange for making the main code base nicer (fewer constructors) was worthwhile |
| 00:43 |
|
iago |
ok, that's fine |
| 00:43 |
|
iago |
just asking because I don't see why that is needed |
| 00:43 |
|
iago |
I mean |
| 00:43 |
|
Heffalump |
I think the other code in the tests just doesn't handle the cases properly. |
| 00:44 |
|
Heffalump |
as I said, try removing it and see what goes wrong - I'm fairly sure something does |
| 00:44 |
|
iago |
I don't see why Hunk f l text text could introduce "problems" but localIdentity=Move dummy dummy not |
| 00:44 |
|
iago |
ok, I get it |
| 00:44 |
|
iago |
reverse engineer |
| 00:44 |
|
iago |
one stupid question |
| 00:44 |
|
iago |
shrinkPos _ _ = bug "foo1 in ShrinkablePos" -- DOUBT |
| 00:44 |
|
iago |
that foo1 is something ugly introducing when testing |
| 00:44 |
|
Heffalump |
it wasn't entirely obvious to me when I was changing the code recently either, so I also removed it to see what would happen |
| 00:45 |
|
Heffalump |
I think that's just an unreachable case. It's useful to have a unique message to grep for if it turns out to be reachable. |
| 00:45 |
|
iago |
well |
| 00:45 |
|
iago |
shrinkPatch _ = bug "foo in ShrinkablePos" |
| 00:46 |
|
iago |
maybe this could be: bug "ShrinkablePos bug detected in shrinkPatch" |
| 00:46 |
|
iago |
just asking for curiosity |
| 00:47 |
|
Heffalump |
I don't think the text of error messages in a test harness is worth thinking about much, so I wouldn't have done so when writing them :-) |
| 00:47 |
|
iago |
yep I know, just curiosity I'm not being critic |
| 00:48 |
|
iago |
propIsMergeable (Sealed (WithStartState _ t)) |
| 00:48 |
|
iago |
= case flattenOne t of |
| 00:48 |
|
iago |
Sealed ps -> let _ = seal2 ps :: Sealed2 (FL p) |
| 00:48 |
|
iago |
in case lengthFL ps of |
| 00:48 |
|
iago |
_ -> Nothing |
| 00:48 |
|
iago |
to be honest I don't spend lot of time trying to read this function |
| 00:48 |
|
iago |
but I think it is equivalent to "= Nothing" |
| 00:48 |
|
sm_ |
it is excellent to see people poring over darcs code |
| 00:48 |
|
iago |
which makes me confuse |
| 00:48 |
|
Heffalump |
yeah, I read that and was wondering |
| 00:49 |
|
Heffalump |
I think the key thing is that it forces the result of flattenOne t |
| 00:49 |
|
Heffalump |
but I'm not quite sure what the other gyrations are for. |
| 00:49 |
|
Heffalump |
flattenOne t might throw an exception,so Nothing isn't the only possible "result" |
| 00:49 |
|
iago |
oh |
| 00:50 |
|
Igloo |
It could certainly benefit from some comments explaining why it's useful |
| 00:50 |
|
iago |
that's very confuse |
| 00:51 |
|
iago |
Heffalump, does merge throw an exception? |
| 00:51 |
|
Heffalump |
I think some of the conflict handling code can. |
| 00:51 |
|
Heffalump |
actually I'm sure it can |
| 00:51 |
|
Heffalump |
and I think some of the testing code might too, but I can't remember |
| 00:52 |
|
Igloo |
The "make prop_is_mergeable stricter." patch looks bogus to me |
| 00:52 |
|
iago |
Heffalump, am I right and do you only test filepatches ? |
| 00:52 |
|
iago |
or there is something I didn't read yet |
| 00:52 |
|
Heffalump |
no, that code only tests filepatches to a single file |
| 00:52 |
|
Heffalump |
the key point is to test the conflict handling in v2 patches, not to test patches in general |
| 00:52 |
|
Heffalump |
but it should be generalised |
| 00:53 |
|
Igloo |
Ah, I see, David actually wanted to force the result of lengthFL |
| 00:53 |
|
iago |
I have decided to just work on Darcs2 patches |
| 00:53 |
|
Heffalump |
what I would like is a universal generator for prim patches that generates the full range of patch types but also patches that are relatively likely to have conflicts and dependencies with other generated patches. |
| 00:53 |
|
Heffalump |
and a well-written coherent set of properties patch types should have |
| 00:53 |
|
Heffalump |
and then just tie the two together |
| 00:53 |
|
iago |
so I'm not reading Darcs1 quickcheck generators |
| 00:54 |
|
iago |
there is something interesting so I should read in order to get ideas? |
| 00:54 |
|
Heffalump |
I'm not sure what you mean. What do you actually want to achieve? |
| 00:54 |
|
Heffalump |
If you want to generally improve the darcs code, either do something useful as suggested by someone like me, or propose your own idea and see what people think. |
| 00:55 |
|
Heffalump |
If you need to do something that will look good in your dissertation (which would be perfectly reasonable), then do whatever you feel is appropriate and we can discuss whether it also happens to be useful to darcs. |
| 00:56 |
|
iago |
well, I just want to provide proper quickcheck testing for Darcs2 patches |
| 00:56 |
|
iago |
with good coverage |
| 00:56 |
|
Heffalump |
I really should have gone to bed ages ago. If Igloo stays around I'm sure he can provide useful review/discussion of what you have to say. |
| 00:56 |
|
Heffalump |
ok. Quickly: |
| 00:57 |
|
Heffalump |
there are two main weaknesses with the darcs2 patch testing. (1) It only covers hunk patches to a single file. I view this as relatively unimportant, because of what I said above about the full range of patches being covered elsewhere. The conflictor (V2 conflicts) code and the code that manages primitive patches are mostly orthogonal. |
| 00:57 |
|
Heffalump |
A much more important weakness, that probably contributed to there being real conflictor bugs in darcs today because I failed to address the weakness when writing the tests is that |
| 00:58 |
|
Heffalump |
they do not generate any situations where a conflict happens, is resolved, and then further patches are written on top of the resolution and another merge happens |
| 00:58 |
|
iago |
( when I was talking about see Darcs1-test-code I mean that, for example, you maybe be testing every Prim patch for Darcs1 and you have a more general RepoModel that I can reuse for Darcs2 tests ) |
| 00:59 |
|
Heffalump |
no, the darcs1 test code uses a generate and filter approach - it makes totally random patches and then filters out the ones that aren't valid in sequence |
| 00:59 |
|
* Heffalump |
gone |
| 00:59 |
|
iago |
ok thanks, I note it |
| 01:00 |
|
iago |
I will re-read it again tomorrow and I ask if I have missed something |
| 01:00 |
|
iago |
(I'm quite tired too) |
| 01:05 |
|
iago |
Igloo, why force the result of lengthFL ? |
| 01:06 |
|
Igloo |
iago: Look at the output of this: darcs annotate -p "make prop_is_mergeable stricter." |
| 01:06 |
|
Igloo |
He was trying to force the entire list, rather than just the first constructor, but "case" doesn't do what he expected, so actually it now doesn't force anything |
| 01:07 |
|
iago |
what he was trying to do |
| 01:07 |
|
iago |
is what whnf does |
| 01:07 |
|
iago |
well, rwhnf, I don't recall the name |
| 01:07 |
|
iago |
remember* |
| 01:08 |
|
Igloo |
lengthFL ps `seq` Nothing would do |
| 01:08 |
|
iago |
yep |
| 01:09 |
|
iago |
but I don't know why |
| 01:09 |
|
iago |
could lengthFL raise an exception? |
| 01:09 |
|
Igloo |
The list could be (x : y : z : _|_) |
| 01:09 |
|
Igloo |
In which case forcing the length would give you the _|_ |
| 01:10 |
|
Igloo |
Better still would be some sort of deep seq, which fully forced the list elements too |
| 01:10 |
|
iago |
NFData instance for example |
| 01:11 |
|
Igloo |
Yup, but just doing "lengthFL ps `seq` Nothing" would (a) do what was intended and (b) make that bit of code actually make sense |
| 01:11 |
|
|
sm_ left #darcs |
| 01:11 |
|
iago |
well, now propIsMergeable makes more sense |
| 01:12 |
|
iago |
though I wonder why raise exceptions instead of use Maybe |
| 01:14 |
|
Igloo |
You want to catch "bug" calls - things that can't happen |
| 01:15 |
|
iago |
but propIsMergeable seems to say "if it fails then they are not" |
| 01:16 |
|
iago |
I also wonder why so complicated return type instead "()" |
| 01:17 |
|
iago |
maybe answered in next code-chapters |
| 01:19 |
|
iago |
Igloo, thanks |
| 01:19 |
|
iago |
good night all |
| 01:19 |
|
|
iago left #darcs |
| 01:36 |
|
kerneis |
too late to do good coding, trying to sleep instead |
| 01:36 |
|
kerneis |
good night |
| 01:38 |
|
|
twb joined #darcs |
| 01:49 |
|
|
lispy1 left #darcs |
| 01:49 |
|
|
lispy joined #darcs |
| 01:50 |
|
|
lispy left #darcs |
| 01:51 |
|
|
lispy joined #darcs |
| 02:08 |
|
|
quidnunc joined #darcs |
| 02:08 |
|
quidnunc |
What is the equivalent of "git log -p" |
| 02:08 |
|
quidnunc |
? |
| 02:09 |
|
sm |
what does that do ? |
| 02:09 |
|
quidnunc |
sm: lists patches in each change |
| 02:09 |
|
quidnunc |
for each changeset* |
| 02:10 |
|
sm |
darcs changes -s lists files in each patch/changeset. darcs changes -v shows the actual hunks |
| 02:10 |
|
quidnunc |
sm: Thans |
| 02:10 |
|
quidnunc |
thanks* |
| 02:13 |
|
|
ManateeLazyCat joined #darcs |
| 02:25 |
|
|
quidnunc left #darcs |
| 02:40 |
|
|
lispy left #darcs |
| 02:46 |
|
|
ManateeL` joined #darcs |
| 02:49 |
|
|
ManateeLazyCat left #darcs |
| 02:50 |
|
|
gienah left #darcs |
| 02:51 |
|
|
gienah joined #darcs |
| 02:54 |
|
|
ManateeL` left #darcs |
| 03:21 |
|
|
intripoon_ joined #darcs |
| 03:24 |
|
|
intripoon left #darcs |
| 04:08 |
|
|
gbeshers joined #darcs |
| 04:11 |
|
|
secorp left #darcs |
| 04:28 |
|
|
ManateeLazyCat joined #darcs |
| 04:54 |
|
|
secorp joined #darcs |
| 05:14 |
|
|
ManateeLazyCat left #darcs |
| 05:28 |
|
|
balor joined #darcs |
| 05:37 |
|
|
intripoon joined #darcs |
| 05:40 |
|
|
intripoon_ left #darcs |
| 06:59 |
|
|
ASnyder joined #darcs |
| 06:59 |
|
ASnyder |
It's a real shame that git went so mainstream, should've been darcs |
| 06:59 |
|
ASnyder |
git is such a pain to work with |
| 07:00 |
|
|
raichoo joined #darcs |
| 07:00 |
|
ASnyder |
I can't even do a pull with a prompt on a per patch basis |
| 07:00 |
|
ASnyder |
what the hell is that? Like 10 commands to do one, which may or may not be equivalent |
| 07:03 |
|
sm |
ASnyder: preach on brother. Can you help us improve ? |
| 07:04 |
|
|
raichoo left #darcs |
| 07:05 |
|
ASnyder |
sm: The new 2.5 branch is pretty nice. I think it's the tooling. You need github to support darcs to become meaningful, it's such a shame. I can't stand the git commandline, can't stand it. It's hell compared to darcs. So unnecessarily complicated. |
| 07:05 |
|
sm |
darcsden is a pretty nice proto-github |
| 07:06 |
|
sm |
needs a motivated hacker or two |
| 07:06 |
|
ASnyder |
sm: it's down... |
| 07:06 |
|
sm |
so it is, alexsuraci |
| 07:07 |
|
ASnyder |
sm: I think it's too far gone.. I love darcs, but all the tooling is git. git this and git that. Clearly nobody works with it from the command line without guis, if they did they would blow their brains out |
| 07:08 |
|
twb |
ASnyder: I do |
| 07:08 |
|
twb |
I don't enjoy it, but I enjoy it more than using a mouse |
| 07:09 |
|
ASnyder |
twb: been in #git now asking for the equivalent of our pull with prompt. They tell me fetch + rebase -i + cherry-pick |
| 07:09 |
|
ASnyder |
which isn't working. I wish the repo were darcs |
| 07:09 |
|
twb |
Yeah, it's a fucking pain |
| 07:10 |
|
ASnyder |
twb: been asking for 2 hrs now, nobody things it's odd that it's so hard and complicated to just pick your patches |
| 07:10 |
|
ASnyder |
thinks* |
| 07:10 |
|
twb |
In history-oriented world, it's fundamentally wrong to "cherry pick" patches |
| 07:10 |
|
ASnyder |
twb: as if the default should always be to pull and merge everything |
| 07:10 |
|
twb |
rebase is basically a way to explicitly violate the design |
| 07:11 |
|
twb |
ASnyder: right, that's how you're supposed to operate if you're using a non-Darcs VCS |
| 07:11 |
|
twb |
What that REALLY means is that you have to decide BEFORE you create/commit a patch, which branch it belongs on |
| 07:12 |
|
twb |
If you are sufficiently anal about doing work on a series of well-formed branches, then "pull all patches" plus "merge all patches [from branch X]" is sufficient |
| 07:12 |
|
ASnyder |
twb: so crazy. So You can't have forks, with only partial merges |
| 07:12 |
|
ASnyder |
at some point you have to completely merge the two to continue |
| 07:13 |
|
twb |
ASnyder: yep |
| 07:14 |
|
twb |
Basically forking/branching and merging are explicit in history-oriented VCSes, where darcs allows you to be ad hoc |
| 07:15 |
|
ASnyder |
twb: how did this seemingly unnatural and complex tool become the new defacto distributed versioning system? Clearly the path I've taken. Been using darcs for about 5 years now. |
| 07:15 |
|
twb |
ASnyder: by being faster than anything else, and being backed by a popular project |
| 07:16 |
|
twb |
And the hackers on that project are a large enough corpus to bootstrap it into a positive feedback loop |
| 07:16 |
|
twb |
See also the "Worse is Better" article. |
| 07:17 |
|
twb |
http://en.wikipedia.org/wiki/Worse_is_Better |
| 07:17 |
|
ASnyder |
twb: but git is soo much harder to use |
| 07:17 |
|
twb |
Yes |
| 07:18 |
|
twb |
Because kernel hackers are better at making things fast and mostly correct, than easy to use and 100% correct |
| 07:19 |
|
ASnyder |
twb:I know it's not the place, but since you deal with the hell and are familiar with darcs, how can I do what I want? Nobody in git world can really understand the heresy I'm trying to commit |
| 07:19 |
|
twb |
ASnyder: I don't know |
| 07:20 |
|
twb |
ASnyder: basically I just cp -a the entire working tree a lot, and stick to a couple of things like commit and pull |
| 07:20 |
|
ASnyder |
twb: wow |
| 07:20 |
|
twb |
And manually rebase patches out-of-band |
| 07:20 |
|
twb |
I do not have time to become an expert in every VCS |
| 07:21 |
|
twb |
I know hg better than git, and I know that you are better off doing cp -a's than building a regular workflow around rebas |
| 07:21 |
|
ASnyder |
twb: I see |
| 07:21 |
|
twb |
rebase is for "oh shit I fucked up" not for days ending in Y |
| 07:21 |
|
ASnyder |
twb: not really trying to create a workflow, the situtation is this. |
| 07:22 |
|
ASnyder |
twb: I have one repo that's somewhat old, and a new repo. Client requested a fork of old repo that has some of the new repo stuff, but not all the new repo stuff. Patches are such that they're independent. |
| 07:22 |
|
ASnyder |
Normally in darcs I would just do a darcs pull from the new repo to old repo |
| 07:22 |
|
ASnyder |
choosing what I want |
| 07:22 |
|
twb |
ASnyder: in that case I guess you have to do some rebasing |
| 07:23 |
|
twb |
The way you're supposed to do that in the git world is to keep each feature in a separate branch, so when the customer says "I want only features B and F", you pull and merge only those branches |
| 07:24 |
|
ASnyder |
twb: so odd, how do you keep track of all that. |
| 07:25 |
|
ASnyder |
twb: that's right, all those visualization tools... |
| 07:25 |
|
twb |
ASnyder: well, fortunately git natively knows about branches |
| 07:25 |
|
twb |
Whereas in darcs managing branches is left up to the user |
| 07:25 |
|
twb |
So in git you can say things like "tell me what branches aren't merged yet" |
| 07:26 |
|
twb |
you need to realize that Darcs is the odd man out here -- for everybody else, this is just the way it has always been |
| 07:27 |
|
ASnyder |
twb: I see. This experience makes we want to write a blog post titled "Why I'm sticking with Darcs", and describe this painful process |
| 07:27 |
|
twb |
I ain't stopping you |
| 07:28 |
|
ASnyder |
we've been having internal discussions about switching to git for one of our larger programs, this experience will definitely make me more vocal in opposing that change |
| 07:28 |
|
ASnyder |
regardless of the tooling |
| 07:29 |
|
ASnyder |
twb: so, you mentioned rebasing before, I haven't been able to actually see anything to rebase. What would the process be? I did fetch from that repo and nothing happens. Then rebase doesn't tellme anything. Just a nightmare. |
| 07:30 |
|
twb |
ASnyder: I don't know |
| 07:36 |
|
|
balor left #darcs |
| 07:36 |
|
ASnyder |
twb: I really hate git. Do you know if there are any darcs initiatives with the new 2.5 to get better tooling? I'd be willing to volunteer time and funds to seeing that happen. |
| 07:36 |
|
twb |
I don't really participate in the darcs community anymore |
| 07:40 |
|
kerneis |
ASnyder: they are plans to provide some kind of "darcs based git client" |
| 07:40 |
|
kerneis |
which wouldn't solve the tooling, but would solve your current issue |
| 07:40 |
|
|
sm left #darcs |
| 07:41 |
|
ASnyder |
kerneis: I've seen darcsgit, which is a python script that maps darcs commands to git |
| 07:41 |
|
ASnyder |
but it's clearly not the same |
| 07:41 |
|
kerneis |
did you try darcs-fastconvert to import your git repo, the manage it with darcs, and export it back? |
| 07:43 |
|
ASnyder |
kerneis: that's an intersting idea. Where can I get this fast-convert is it downloadable via cabal? |
| 07:43 |
|
kerneis |
cabal install darcs-fastconvert |
| 07:43 |
|
kerneis |
http://hackage.haskell.org/pac[…]darcs-fastconvert |
| 07:44 |
|
kerneis |
HOWTO: http://lists.osuosl.org/piperm[…]ember/025251.html |
| 07:44 |
|
kerneis |
(and note that 0.2 has support for mark-files, although it is not documented) |
| 07:44 |
|
kerneis |
of course, this would flatten your git history |
| 07:44 |
|
kerneis |
(no more branches) |
| 07:45 |
|
kerneis |
and you won't be able to merge the forked tree with the old one |
| 07:45 |
|
kerneis |
but if all you want is a one-shot fork-and-hack, it is okay |
| 07:45 |
|
ASnyder |
kerneis: sounds promising |
| 07:53 |
|
|
lelit joined #darcs |
| 08:01 |
|
|
darcscommitbot left #darcs |
| 08:02 |
|
|
darcswikibot left #darcs |
| 08:02 |
|
|
darcscommitbot joined #darcs |
| 08:03 |
|
|
darcswikibot joined #darcs |
| 08:26 |
|
|
raichoo joined #darcs |
| 08:30 |
|
|
raichoo left #darcs |
| 08:32 |
|
|
raichoo joined #darcs |
| 09:50 |
|
|
kowey joined #darcs |
| 09:51 |
|
kowey |
good morning |
| 09:56 |
|
raichoo |
good morning kowey |
| 09:58 |
|
kerneis |
hi |
| 10:00 |
|
mornfall |
Morning. |
| 10:12 |
|
|
Brennon joined #darcs |
| 10:13 |
|
Brennon |
Hi |
| 10:13 |
|
kowey |
hi Brennon |
| 10:14 |
|
Brennon |
Whats the point of this room? |
| 10:15 |
|
kowey |
http://darcs.net should give you an idea |
| 10:26 |
|
|
twb left #darcs |
| 10:38 |
|
|
Brennon left #darcs |
| 10:39 |
|
kowey |
ezyang: did you solve your conflict hunting problem from last night? |
| 10:49 |
|
kerneis |
is there an idiomatic way to do: DryRun `elem` opts, except for options with parameters (like Output)? |
| 10:49 |
|
kerneis |
I did: null [ o | Output o <- opts ] |
| 10:49 |
|
kerneis |
but I don't like it |
| 10:50 |
|
kerneis |
not $ null [ o | Output o <- opts ] actually |
| 10:51 |
|
kowey |
I think we've always cobbled together ad-hoc non-solutions each time this came up |
| 10:51 |
|
kowey |
although I think the trend is to put such a function in Darcs.Flag |
| 10:52 |
|
kerneis |
thanks |
| 10:52 |
|
kowey |
anyway, the flags are being rethought, current best option seems to be to use cmdlib |
| 10:53 |
|
kerneis |
yes, there is getOutputName which does kind of that |
| 10:53 |
|
kerneis |
(you need to provide a default name, but I guess "" would be okay, and then just ignore the result) |
| 10:53 |
|
kerneis |
it seems ugly, though |
| 11:14 |
|
|
ManateeLazyCat joined #darcs |
| 11:33 |
|
|
ManateeLazyCat left #darcs |
| 11:56 |
|
kerneis |
question for monads experts: |
| 11:56 |
|
kerneis |
http://pastebin.com/tJN5f872 I feel there is a way to do this without the "case" stuff |
| 11:57 |
|
kerneis |
something like binding the Maybe (remote_repo) to check_post |
| 11:58 |
|
kerneis |
but I can't find the right syntax |
| 11:59 |
|
kerneis |
(I'm not telling it's worth it either, just curious) |
| 12:20 |
|
kowey |
I'm no monad expert, but one option might be wtds <- maybe (return []) check_post remote_repo |
| 12:20 |
|
kowey |
but not sure if that's actually an improvement, seems a bit golfy |
| 12:21 |
|
kowey |
oh, maybe there is something you can do over the whole thing |
| 12:22 |
|
kowey |
should announce_recipents accept the empty list as input? |
| 12:22 |
|
kowey |
or is it fair to say that announce_recipients [] = return () |
| 12:25 |
|
kerneis |
this is the case, indeed |
| 12:25 |
|
kowey |
http://pastebin.com/EbhtDaAM perhaps? |
| 12:27 |
|
kowey |
tricky game of trying to achieve clarity rather than illegibility through concision |
| 12:27 |
|
kerneis |
anyway, what I was looking for is the maybe function, thanks for suggesting it |
| 12:28 |
|
kerneis |
even if I don't use it, it's good to know how it works |
| 12:28 |
|
kowey |
there's also fromMaybe which is a handy variant |
| 13:03 |
|
kowey |
I think this is my final plugin for the darcs wiki: http://wiki.darcs.net/Plugins (if you say issueXXX, it will automagically create the link for you, just like roundup does) |
| 13:04 |
|
mornfall |
Nice. |
| 13:06 |
|
kerneis |
kowey: error 503 here |
| 13:07 |
|
|
gal_bolle joined #darcs |
| 13:07 |
|
kowey |
oops, I just renamed TrackerIntegration to TrackerLinks |
| 13:07 |
|
kowey |
must have forgotten to propagate something |
| 13:09 |
|
kowey |
back up, thanks! |
| 13:09 |
|
* kowey |
is too darn careless |
| 13:16 |
|
alexsuraci |
(darcsden back up) |
| 13:20 |
|
kerneis |
I've turned a Repository p C(r u t) into a Maybe (Repository p C(r u t)) and when I try to pass it Nothing, it does not typecheck |
| 13:20 |
|
kerneis |
Ambiguous type variable `p' in the constraint: `RepoPatch p' |
| 13:21 |
|
gal_bolle |
where did you change that? |
| 13:21 |
|
kerneis |
`decideOnBehavior' in src/Darcs/Commands/Send.lhs |
| 13:22 |
|
kerneis |
I just need a Maybe Repository, so I'm willing to learn any type-checking to trick to make it work |
| 13:22 |
|
kerneis |
(I must confess I don't have a clue about those C(r u t) everywhere) |
| 13:22 |
|
gal_bolle |
can you paste your code? |
| 13:22 |
|
kerneis |
sure |
| 13:23 |
|
gal_bolle |
(onto hpaste) |
| 13:24 |
|
kerneis |
http://pastebin.com/7fhsT14j |
| 13:25 |
|
kerneis |
I pasted call site (line 150), definition, and then error message |
| 13:27 |
|
gal_bolle |
aha! it's because line 150, the compiler does not know what p to call decideOnBehavior on. What is the type signature of sendCmd? |
| 13:27 |
|
gal_bolle |
i see |
| 13:28 |
|
kerneis |
sendCmd :: [DarcsFlag] -> [String] -> IO () |
| 13:28 |
|
gal_bolle |
you need to split sendCmd, so that you can give a type signature to the part where repo is known |
| 13:30 |
|
kerneis |
isn't it possible to put type annotations inline (like in Ocaml)? |
| 13:30 |
|
gal_bolle |
it is possible |
| 13:31 |
|
gal_bolle |
but I'm not sure if (Nothing :: forall p. RepoPatch p => Maybe (Repository p C(r u t))) is going to help the compiler much |
| 13:33 |
|
lelit |
hi kowey, sorry to bother you, but I suppose you have admin rights on the darcs ML? I need to change my subscription address, can you help? |
| 13:39 |
|
kerneis |
gal_bolle: http://hpaste.org/42186/plop |
| 13:39 |
|
kerneis |
no idea if this is correct but it compiles |
| 13:39 |
|
kerneis |
note the C(r u r) on line 2 |
| 13:40 |
|
kerneis |
I'm blindly following GHC error messages |
| 13:43 |
|
kowey |
lelit: ah, I was too shy to mention that I noticed your address was disabled due to excess bouncing |
| 13:43 |
|
kowey |
help on the way |
| 13:44 |
|
lelit |
yes, no problem |
| 13:45 |
|
lelit |
maybe I could switch to reading via gmane... |
| 13:45 |
|
gal_bolle |
kerneis: it's the right thing to do |
| 13:45 |
|
kowey |
what address should I use? |
| 13:46 |
|
lelit |
lele at metapensiero.it |
| 13:46 |
|
kowey |
I'll unset your nomail flag then |
| 13:46 |
|
lelit |
thankyou |
| 13:47 |
|
kowey |
oops, nope, that was me setting your name... hmm, will unsubscribe old address and add new one |
| 13:48 |
|
lelit |
well, I can do the second my myself, just to the first if you like |
| 13:48 |
|
kowey |
ok, done on both (I think) |
| 13:48 |
|
lelit |
great |
| 13:49 |
|
|
gbeshers left #darcs |
| 13:52 |
|
kowey |
potentially interesting reading about rebase http://paul.stadig.name/2010/1[…]ebase-ammend.html |
| 13:52 |
|
kowey |
(in the Eric searches for darcs on google blog search dept) |
| 13:54 |
|
int-e |
worth reading for this statement alone: "And as we all know, public floggings are the lifeblood of software development teams." |
| 14:00 |
|
|
sm joined #darcs |
| 14:01 |
|
int-e |
The arguments are not really applicable for open source work though, I feel. In open source development, the primary audience for changes is patch reviewers. It helps them a lot if patches have a logical structure. And as long as you're hacking in private, you can alter history all you want. Nobody wants to be forced to review all your false starts either. Once a patch is in (one of) the public repo(s), of course, everything... |
| 14:01 |
|
int-e |
...Paul wrote applies. |
| 14:03 |
|
gal_bolle |
he does say that, at some point |
| 14:07 |
|
gal_bolle |
i guess in a commercial setting, private branches are much shorter-lived |
| 14:12 |
|
mornfall |
kowey: I can't agree with that article. |
| 14:12 |
|
kerneis |
I have a patch for issue1344 but do not know how to test it |
| 14:13 |
|
kerneis |
how can make darcs believe that I don't have sendmail? |
| 14:14 |
|
kowey |
version control as for source code archaeology, wonder if the author would be more in an hg mindset |
| 14:15 |
|
kowey |
kerneis: is the check just for existence of sendmail? |
| 14:15 |
|
kowey |
or something else? |
| 14:16 |
|
kowey |
if it's something else, I wonder if you could put a bad sendmail in the PATH |
| 14:16 |
|
kerneis |
not it's the existence |
| 14:17 |
|
kowey |
or maybe ln -s /not/real sendmail |
| 14:17 |
|
kowey |
and design the check to follow links |
| 14:17 |
|
kowey |
or maybe this is better suited for something more like a unit test than a functional one |
| 14:18 |
|
gal_bolle |
you can look at tests/issue1465_ortryrunning.sh |
| 14:20 |
|
kowey |
In Designing for the Digital Age, one of the chapters is on doing User Research |
| 14:20 |
|
kowey |
to figure out who to interview, you're supposed to ask yourself what are the user roles in the product |
| 14:21 |
|
kowey |
so I guess for revision control system, it was something like author, committer/reviewer/maintainer, spectator (guy who just does darcs get and pull from time to time) |
| 15:01 |
|
* kerneis |
removed sendmail to validate the patch |
| 15:11 |
|
* gal_bolle |
should nag kerneis for an automated test…' |
| 15:13 |
|
kowey |
http://twitter.com/#!/ashyboy/[…]12755338205859840 |
| 15:14 |
|
kowey |
this is from a darcs refugee... could be useful sign for what's important in darcs |
| 15:14 |
|
kowey |
and also maybe one thing that darcs could offer to git |
| 15:15 |
|
kerneis |
gal_bolle: this is impossible |
| 15:15 |
|
kowey |
it's gratifying for people to *expect* things like that to work |
| 15:15 |
|
kerneis |
haveSendmail checks directly in /sbin, /usr/bin et al. |
| 15:15 |
|
kowey |
i wonder if you could do some sort of chrooty thing |
| 15:15 |
|
* gal_bolle |
does not dare to propose a chroot |
| 15:16 |
|
* kerneis |
thought about that, actually |
| 15:16 |
|
kerneis |
but this is way way too complicated (need to be root, to copy a shell, and so on) |
| 15:20 |
|
kowey |
one option might be automated tests that you have to run manually |
| 15:20 |
|
kowey |
not noticed by the harness, but if you wanted to test X, then just do foo |
| 15:22 |
|
gal_bolle |
otherwise, just skip the test if sendmail does exist |
| 15:22 |
|
gal_bolle |
and hope one of the buildbot does not have it |
| 15:22 |
|
gal_bolle |
so that it does get run at some point |
| 15:23 |
|
|
gbeshers joined #darcs |
| 15:24 |
|
kowey |
that's probably a fair test |
| 15:24 |
|
kowey |
you could imagine buildslaves being deliberately very minimal |
| 15:25 |
|
|
gbeshers left #darcs |
| 15:25 |
|
|
gbeshers joined #darcs |
| 15:36 |
|
|
gal_bolle left #darcs |
| 15:41 |
|
kerneis |
I'll make functional tests for the three issues tomorrow |
| 15:51 |
|
|
dcolish joined #darcs |
| 16:01 |
|
|
raichoo left #darcs |
| 16:10 |
|
|
ASnyder left #darcs |
| 16:34 |
|
|
sm_ joined #darcs |
| 16:36 |
|
|
sm left #darcs |
| 16:36 |
|
|
sm_ is now known as sm |
| 16:47 |
|
|
lelit left #darcs |
| 16:48 |
|
kowey |
I wonder if the mime-mail package would be useful for darcs |
| 16:54 |
|
|
gh_ joined #darcs |
| 17:19 |
|
|
JaffaCake1 joined #darcs |
| 17:22 |
|
|
JaffaCake left #darcs |
| 17:24 |
|
|
raichoo joined #darcs |
| 17:29 |
|
|
raichoo1 joined #darcs |
| 17:31 |
|
|
raichoo left #darcs |
| 17:41 |
|
|
lispy joined #darcs |
| 17:43 |
|
|
gal_bolle joined #darcs |
| 17:44 |
|
gal_bolle |
kerneis: have you looked at issue643? |
| 17:48 |
|
gal_bolle |
sorry, it's ok |
| 17:55 |
|
|
balor joined #darcs |
| 17:58 |
|
|
arjanb joined #darcs |
| 17:59 |
|
|
kowey left #darcs |
| 18:00 |
|
|
iago joined #darcs |
| 18:04 |
|
iago |
hi all |
| 18:07 |
|
kerneis |
gal_bolle: no, you are right, I missed it |
| 18:07 |
|
kerneis |
well, "will be sent" is misleading, but I should output "would be sent" instead of nothing |
| 18:08 |
|
kerneis |
i'll send a follow-up |
| 18:18 |
|
iago |
Excuse me, what is the meaning of this two type constructors ? |
| 18:18 |
|
gal_bolle |
but there's the "usual recipient" message |
| 18:18 |
|
iago |
data (a1 :\/: a2) C(x y) = FORALL(z) (a1 C(z x)) :\/: (a2 C(z y)) |
| 18:18 |
|
iago |
data (a1 :/\: a2) C(x y) = FORALL(z) (a1 C(x z)) :/\: (a2 C(y z)) |
| 18:19 |
|
gal_bolle |
it's two patches starting (or arriving) at the same state |
| 18:20 |
|
iago |
merge :: (p :\/: p) C(x y) -> (p :/\: p) C(x y) |
| 18:20 |
|
gal_bolle |
merge is (Patch :\/: Patch) -> (Patch :/\: Patch) |
| 18:20 |
|
iago |
so merge takes two patches starting at the same state |
| 18:20 |
|
gal_bolle |
and arriving at respectively x and y |
| 18:20 |
|
gal_bolle |
and give you two patches starting from x and y and arriving at some common point |
| 18:22 |
|
iago |
example |
| 18:23 |
|
iago |
1 -> 2,3 (starting in 1, arriving at 2,3 respectively) |
| 18:23 |
|
iago |
merge gives me 2,3 -> 4 |
| 18:23 |
|
gal_bolle |
yes and the types hide 1 and 4 from you |
| 18:23 |
|
iago |
ok I see |
| 18:24 |
|
iago |
if I have p:1->2 in my repo |
| 18:24 |
|
iago |
I will have a q':2->4 |
| 18:24 |
|
iago |
in order to apply pq' |
| 18:24 |
|
iago |
and if I had q:1->3 I will have p':3->4 |
| 18:24 |
|
gal_bolle |
exactly |
| 18:25 |
|
iago |
thanks |
| 18:37 |
|
|
balor left #darcs |
| 18:57 |
|
|
gh_ left #darcs |
| 19:13 |
|
|
lispy left #darcs |
| 19:13 |
|
|
lispy joined #darcs |
| 19:48 |
|
|
sm left #darcs |
| 20:11 |
|
|
secorp left #darcs |
| 20:19 |
|
Heffalump |
'lo |
| 20:23 |
|
gal_bolle |
'vning |
| 20:27 |
|
gal_bolle |
Paypal api coded under git. @paypal chokes @wikileaks. switch to @darcs for freedom of speech |
| 20:28 |
|
gal_bolle |
(rinse (hg/visa), lather (bzr/mastercard), repeat) World domination achieved |
| 20:31 |
|
Heffalump |
:-) |
| 21:11 |
|
|
Brennon joined #darcs |
| 21:14 |
|
iago |
Heffalump, are you considering leave literate haskell ? |
| 21:16 |
|
iago |
give up / quit / whatever |
| 21:20 |
|
iago |
just asking because I know some projects are now avoiding write new code using literate-haskell, I think I will rewrite Darcs2 testing so I can choose what do you prefer |
| 21:20 |
|
Heffalump |
yes, we agreed we would drop it |
| 21:20 |
|
iago |
(Darcs2 patch-testing) |
| 21:20 |
|
Heffalump |
but noone has written the patches to do it |
| 21:21 |
|
Heffalump |
so just go for it - make sure it's in a separate patch (perhaps one per file if you drop it from multiple files) |
| 21:21 |
|
iago |
well, my idea is just create parallel modules |
| 21:21 |
|
iago |
and finally replace the existing ones |
| 21:22 |
|
lispy |
Heffalump: we've cleaned a fair bit of lhs out, just not all of it. Is that what you meant? |
| 21:22 |
|
Heffalump |
lispy: yes |
| 21:22 |
|
iago |
I prefer to "construct" watching what is yet done |
| 21:22 |
|
iago |
than "fix" trying to get intermediate things (mixing new with old stuff) that compile |
| 21:23 |
|
iago |
s/yet/already |
| 21:23 |
|
Heffalump |
iago: ok, if that works better for you and you are genuinely writing new code |
| 21:23 |
|
Heffalump |
but if you go down that route, please do finish it so we don't end up with yet another module cluttering the place up :-) |
| 21:24 |
|
iago |
ok, don't worry, I will replace entire modules |
| 21:25 |
|
iago |
of course, I don't know what do you mean with "genuinely" |
| 21:26 |
|
iago |
I won't re-invent the wheel |
| 21:26 |
|
iago |
I will as much as possible code from what is done |
| 21:26 |
|
Heffalump |
well, if you wind up cutting/copying significant amounts of code from the old module into the new module, it would have been better to work with the old module |
| 21:26 |
|
iago |
I will get/copy* |
| 21:26 |
|
|
gienah left #darcs |
| 21:28 |
|
iago |
maybe I'm missed, but that way if I make changes to RepoModel I will have to a) re-write every related stuff (many) b) comment lot of related stuff in order to get something compilable |
| 21:28 |
|
|
gienah joined #darcs |
| 21:28 |
|
Heffalump |
well, yes |
| 21:28 |
|
Heffalump |
if you don't want to keep the stuff that you would have to change, delete it first |
| 21:29 |
|
|
Brennon left #darcs |
| 21:29 |
|
iago |
if you prefer that way for some good reason like cleaner history or whatever I will do as possible |
| 21:29 |
|
iago |
but it requires more attention when recording |
| 21:29 |
|
Heffalump |
I guess it doesn't really matter very much given that this is the test suite only, but I think it's good practice in general to have logical patches. |
| 21:29 |
|
Heffalump |
I agree it does slow down development, but it makes review much easier. |
| 21:30 |
|
Heffalump |
but equally a fresh well-written module might be easy to review too. So I don't feel that strongly. |
| 21:38 |
|
iago |
am I missing something or Darcs.Test.Patch.Unit is not using quickcheck generators but a fixed set of hunks no check properties? |
| 21:38 |
|
iago |
(quickhunk to generate hunks) |
| 21:40 |
|
Heffalump |
I imagine so. |
| 21:42 |
|
iago |
so is Unit2 where you check properties using quickcheck |
| 21:43 |
|
iago |
Unit is some kind of module containing strange cases you have found you must ensure that they are checked ? |
| 21:43 |
|
iago |
"realIglooMergeables" ... |
| 21:43 |
|
Heffalump |
I didn't write them so I'm not really familiar with the overall history. |
| 21:43 |
|
Heffalump |
The Igloo case is a special instance of a difficult merging case he described |
| 21:44 |
|
iago |
that kind of thing should be forbidden :( |
| 21:44 |
|
iago |
for me seems a joke to see that |
| 21:46 |
|
iago |
well, that's the life |
| 21:46 |
|
Heffalump |
well, it's a good name for me, because I remember the history so I can instantly identify what it's about without looking at the code |
| 21:46 |
|
Heffalump |
I agree it may seem opaque to newcomers. |
| 21:47 |
|
iago |
well, I think the good way will be give it some name, maybe make reference to Igloo in a comment in which he explains why that case is difficult |
| 21:48 |
|
iago |
I can imagine next darcs developers generation |
| 21:48 |
|
lispy |
Heffalump: oh yeah. Iago may have found a place where we (in our infinite free time/energy) could document something better. |
| 21:48 |
|
iago |
seeing that code and asking "why igloo????" |
| 21:48 |
|
* lispy |
<3 infinite free-time |
| 21:49 |
|
iago |
lispy, no, I found that kind of places very often when reading Darcs code |
| 21:49 |
|
iago |
but that is particularly funny :P |
| 21:50 |
|
iago |
to be honest I will make a requirement to contribute with code of some quality |
| 21:51 |
|
iago |
I don't know what is the current state of Darcs politic to accept code |
| 21:51 |
|
iago |
but in the past was not very strict |
| 21:51 |
|
lispy |
iago: when you find concrete examples of things that seem "funny" to you in the darcs code, make notes as much as you can. Maybe put the notes on the wiki. Eventually someone might fix it if we document it :) |
| 21:53 |
|
iago |
lispy, I won't do it now because I will rewrite these modules |
| 21:53 |
|
iago |
but I'm doing that job when I see I can |
| 21:54 |
|
iago |
just say that I thank you a lot for your help, and I'm sorry if my critics sound bad (maybe due to my English skills) |
| 21:55 |
|
iago |
but honestly if I have decided to contribute to darcs without being this a MSc job |
| 21:55 |
|
iago |
I have serious doubts I will finally take the time to help |
| 21:56 |
|
iago |
it is just a suggestion, please forbid any contribution that is not well documented etc |
| 21:56 |
|
Heffalump |
would that help us improve the quality of the code from where it is now? |
| 21:57 |
|
iago |
do not bad code and slowly fix the existing one |
| 21:57 |
|
iago |
will improve code quality progressively, that's sure |
| 21:57 |
|
iago |
do not introduce* |
| 21:57 |
|
Heffalump |
depends whether the alternative is better submissions, or no submissions |
| 21:57 |
|
iago |
well, if the only submissions are bad |
| 21:58 |
|
iago |
then Darcs future is bad |
| 21:58 |
|
Heffalump |
I disagree that a submission without documentation is a bad one. It's just not as good as it could be. |
| 21:58 |
|
iago |
I think contributors should take care it is better fewer but cleaner contributions |
| 21:58 |
|
Heffalump |
we have a major need to improve the behaviour of the code, as well as its quality |
| 21:58 |
|
iago |
well, 1 contribution is not bad |
| 21:58 |
|
iago |
1000 |
| 21:59 |
|
iago |
becomes bad |
| 21:59 |
|
iago |
lot of non-trivial code without doc (or worst characteristics) |
| 22:00 |
|
iago |
Heffalump, so, introduce more code to fix in the future is not a good idea |
| 22:00 |
|
iago |
you will see I will comment every non-trivial thing I introduce |
| 22:01 |
|
iago |
and I won't get more points in my msc-job for that |
| 22:01 |
|
iago |
I think Darcs developers could do the same |
| 22:01 |
|
iago |
but that's your decision |
| 22:01 |
|
|
Brennon joined #darcs |
| 22:01 |
|
lispy |
iago: I agree that we can and should improve the quality a lot, but we have many competing concerns to balance. I hesitate at making a sweeping policy about what to accept. |
| 22:01 |
|
iago |
just my opinion, I will shut up from now I don't want to boring anybody |
| 22:02 |
|
lispy |
iago: it's an important discussion; you're not offending anyone :) |
| 22:02 |
|
iago |
lispy, from my opinion you are making things going slow |
| 22:03 |
|
iago |
honestly, I could continue to contribute to Darcs after msc-job |
| 22:03 |
|
iago |
but honestly again, I won't do that |
| 22:03 |
|
iago |
if I see I fix code and you introduce new code to fix every week |
| 22:03 |
|
lispy |
iago: You want me to stop writing code :) |
| 22:03 |
|
iago |
I think more haskellers will contribute if they could read Darcs code and take 1/4 time I'm needing to understand the code |
| 22:04 |
|
lispy |
iago: That's a reasonable point. So, how do you access the quality and make the determination to accept/reject? |
| 22:04 |
|
iago |
lispy, it is not to stop writing, is write less, but write clearer |
| 22:04 |
|
lispy |
iago: Do we need to publish more articles about the data model? |
| 22:04 |
|
lispy |
iago: Or is all the code confusing? |
| 22:04 |
|
|
Brennon left #darcs |
| 22:05 |
|
|
Brennon joined #darcs |
| 22:06 |
|
iago |
lispy, no, I'm not saying every line of code is confusing |
| 22:06 |
|
lispy |
iago: My opinion is that if we invested more time in writing tests to go with all the code that we'd be forced to do what you say: Write less code and write it more clearly. |
| 22:06 |
|
Heffalump |
I think most of what you've found confusing is old code. |
| 22:06 |
|
lispy |
iago: Are there places that are more confusing than others? Can you tell us where to focus our time? |
| 22:06 |
|
Heffalump |
I include in that the QuickCheck tests that I wrote in quite a hurry because they were needed to test conflictors quickly. |
| 22:07 |
|
iago |
lispy, I didn't read all Darcs code |
| 22:07 |
|
Heffalump |
iago: it might be most helpful if you point to specific patches that are relatively recent and would benefit significantly from more documentation |
| 22:07 |
|
lispy |
iago: I think your feedback is very valuable. Now I need more details if we are to put it into action. |
| 22:07 |
|
iago |
well, first point |
| 22:08 |
|
iago |
it is very common to see that a definition A is defined at the end of a module |
| 22:08 |
|
iago |
but it is used in the beginning |
| 22:08 |
|
iago |
and there is not recursion involved |
| 22:08 |
|
iago |
so, I wonder WTF I have to go tot he bottom |
| 22:08 |
|
iago |
(WTF is what do you think when you realize that) |
| 22:08 |
|
lispy |
I see. So the order of definition-use is important to you. |
| 22:09 |
|
iago |
lispy, well, I read code from top-down, as most humans :S |
| 22:09 |
|
lispy |
iago: What is it about the order that matters to you? |
| 22:09 |
|
lispy |
(how does it help you?) |
| 22:09 |
|
iago |
because when I see some strange thing, I search it |
| 22:09 |
|
iago |
I have to jump from one line to another |
| 22:09 |
|
iago |
instead of naturally read the code |
| 22:09 |
|
iago |
I'm losing concentration |
| 22:09 |
|
iago |
in order to make searches |
| 22:09 |
|
iago |
that are not needed |
| 22:10 |
|
lispy |
If the thing was not strange would you still need to search for it? |
| 22:10 |
|
iago |
you would like to read a dissertation where chapters are arbitrarily ordered? |
| 22:10 |
|
Heffalump |
I actually think that the ability to do top-down design where appropriate is a big benefit of Haskell over ML. |
| 22:10 |
|
Heffalump |
You can define things and fill in the gaps later. |
| 22:11 |
|
|
ASnyder joined #darcs |
| 22:11 |
|
|
Brennon left #darcs |
| 22:11 |
|
Heffalump |
but I never read entire source files linearly, anyway, which means I tend not to think about ordering at all |
| 22:11 |
|
Heffalump |
from reading other people's code, I think most people do care about it, so I should make more effort |
| 22:11 |
|
iago |
lispy, ... if the thing is not strange I wonder why if A depends on B and B not depends on A, why B is at line 500 and A on line 10 |
| 22:11 |
|
iago |
I think that is reasonable |
| 22:12 |
|
iago |
sometimes I forget some detail |
| 22:12 |
|
iago |
so I have to jump again to 500 |
| 22:12 |
|
iago |
and then again to 10 |
| 22:12 |
|
iago |
instead of just read some lines above |
| 22:12 |
|
iago |
that's irritating |
| 22:12 |
|
lispy |
iago: Yes. I have a similar problem. Not within modules, but across darcs's modules. |
| 22:12 |
|
ezyang |
iago: What editor do you use? |
| 22:12 |
|
lispy |
I use ack a lot which helps me |
| 22:13 |
|
iago |
ezyang, ok, I could use clever ways to jump |
| 22:13 |
|
lispy |
ack can be downloaded here or in most OS distributions: http://betterthangrep.com/ |
| 22:13 |
|
iago |
but that does not justify that order |
| 22:13 |
|
lispy |
Let's not focus too much on solutions. I want to hear about the frustrations first |
| 22:14 |
|
iago |
well, to be honest |
| 22:14 |
|
iago |
I found all witnesses stuff a bit confusing |
| 22:14 |
|
iago |
I don't will say that's something bad because the goal is reduce bugs |
| 22:14 |
|
iago |
though I think it complicates reading |
| 22:15 |
|
iago |
I hope the effort makes sense in terms of not-produced-bugs |
| 22:15 |
|
lispy |
iago: Hmm...Did you read my thesis about them or did you wade in without it? |
| 22:15 |
|
lispy |
iago: I've been reading witnesses long enough now that it's more natural for me... |
| 22:15 |
|
iago |
I read your thesis, 1.5 month ago, at least some chapters |
| 22:16 |
|
lispy |
Chapter 4-5 would be most useful I bet |
| 22:16 |
|
iago |
lispy, in some way I think it is a matter of reading, as you say |
| 22:16 |
|
iago |
though for the newcomer it makes it hard |
| 22:16 |
|
Heffalump |
having tried to add witnesses to some old code, I am pretty confident that witnesses impose a discipline that make bugs much less likely |
| 22:16 |
|
iago |
this is why I say I hope it really is useful |
| 22:17 |
|
Heffalump |
and yes, I do agree they are a significant barrier to entry. We've agreed we need better documentation of them, but someone needs to write it. |
| 22:17 |
|
iago |
:) |
| 22:17 |
|
iago |
and well, I don't know |
| 22:18 |
|
iago |
things like cleverCommute could be documented so I can read "it makes use of this clever trick" |
| 22:18 |
|
iago |
explaning it in two line |
| 22:18 |
|
lispy |
iago: I'm starting to write down the things you're saying, but I may have to leave (I'm at work): http://wiki.darcs.net/Developm[…]le#iagos-feedback |
| 22:18 |
|
iago |
first time you read commute code |
| 22:19 |
|
iago |
you ask, WTF is all the cases that commuteFiledir does not handle ? |
| 22:19 |
|
iago |
s/is/are |
| 22:20 |
|
Heffalump |
personally, I wouldn't have written the code the way it is without being sure it was necessary for performance (i.e. having a fast path) and I would certainly have documented it if I had to write it that way. |
| 22:20 |
|
|
ASnyder left #darcs |
| 22:21 |
|
iago |
lispy, ok thanks for give it some importance |
| 22:21 |
|
lispy |
iago: thanks for taking the time to explain |
| 22:21 |
|
|
raichoo1 left #darcs |
| 22:22 |
|
iago |
Heffalump, I think it is slower |
| 22:22 |
|
iago |
but you handle less cases |
| 22:22 |
|
iago |
which I know they are completely symmetric |
| 22:22 |
|
iago |
because I had to write all of them |
| 22:22 |
|
iago |
sometimes I make a mistake in one of them but not in the symmetric one |
| 22:23 |
|
iago |
and I have found symmetric property does not hold :P |
| 22:23 |
|
iago |
pq <-> rs => rs <-> pq |
| 22:23 |
|
lispy |
iago: I really should go, but as you think of more things, please put them here if you have time: http://wiki.darcs.net/Developm[…]le#iagos-feedback |
| 22:23 |
|
iago |
lispy, ok, no problem |
| 22:23 |
|
iago |
I have a patch in local |
| 22:24 |
|
iago |
for comment cleverCommute for example |
| 22:24 |
|
iago |
I'm really trying to help ;) |
| 22:24 |
|
|
secorp joined #darcs |
| 22:25 |
|
lispy |
iago: cool! |
| 22:26 |
|
Heffalump |
iago: what doesn't it hold for, that particular piece of code? Presumably it does hold generally for commute? |
| 22:27 |
|
iago |
Heffalump, I had to write every pair of cases |
| 22:27 |
|
iago |
ex. Filepatch-Move and Move-Filepatch |
| 22:27 |
|
iago |
if I have Filepatch-Move sound but I have introduced an error in Move-Filepatch |
| 22:28 |
|
iago |
I can found counterexamples for symmetry |
| 22:28 |
|
iago |
that errors where mainly related to the preconditions that I require |
| 22:28 |
|
iago |
(your | condition = Failed) |
| 22:29 |
|
iago |
cleverCommute is clearly (I think) slower |
| 22:30 |
|
iago |
for me only makes sense to avoid code repetition |
| 22:30 |
|
iago |
I think it is not necessary bad, which is bad is not to explain that "clever trick" |
| 22:31 |
|
iago |
well, recovering the old topic |
| 22:32 |
|
iago |
am I free to reorganize modules ? |
| 22:32 |
|
iago |
for instance I prefer to clearly name Unit as "important tests we always have to run" and Unit2 as "quickcheck testing" |
| 22:33 |
|
lispy |
iago: If your work depends on a change you want to make, it's always best to run that change by the mailing list before committing to it |
| 22:33 |
|
lispy |
iago: When it comes to reorganizing code, you are free to do it; just be prepared to explain why it's an improvement |
| 22:34 |
|
iago |
ok |
| 22:34 |
|
|
gbeshers left #darcs |
| 22:35 |
|
|
Brennon joined #darcs |
| 22:36 |
|
iago |
Heffalump, and just to clarify, I think you refactoring work is helpful |
| 22:37 |
|
iago |
at least in general it was helpful for me |
| 22:37 |
|
Heffalump |
iago: yes, please do reorganize things |
| 22:37 |
|
Heffalump |
though I'm not sure if I'd characterise Unit as "important tests"; I don't know enough about them to be confident they really all are. |
| 22:37 |
|
iago |
so maybe you are right and I'm seeing lot of legacy code |
| 22:38 |
|
Heffalump |
I was just trying to partition things into "quick check" and "specific test cases", though I don't have a good name for the latter |
| 22:38 |
|
Heffalump |
the current situation is very much an intermediate state, not the end result, though |
| 22:38 |
|
iago |
Heffalump, well, my idea would be to delete any non senseful specific test |
| 22:39 |
|
iago |
I think once you have good generators (that's my desired goal at least) |
| 22:39 |
|
iago |
you only have to consider very important test cases |
| 22:39 |
|
Heffalump |
how would you decide that a test isn't "senseful" (I think the English word you want is "sensible" or perhaps "useful" btw) |
| 22:39 |
|
iago |
so I can imagine you won't be happy removing any test |
| 22:39 |
|
Heffalump |
I had considered removing some, but I don't feel that comfortable with it. |
| 22:40 |
|
Heffalump |
But I would like to get the test cases into a rather more regular format. |
| 22:40 |
|
Heffalump |
i.e. consistent with each other |
| 22:40 |
|
Heffalump |
once you have that, I don't think the volume really hurts |
| 22:40 |
|
iago |
well, "useful assuming you have good quickcheck coverage" |
| 22:40 |
|
Heffalump |
QuickCheck is great, but I find the non-determinism a bit unsettling. |
| 22:41 |
|
iago |
ok I understand you, "Specific tests" so |
| 22:41 |
|
Heffalump |
The nice thing about test cases is that you can be really sure they ran. As you say if they really aren't useful they could go, but it's hard for me to characterise whether one would be or not. |
| 22:42 |
|
iago |
yep |
| 22:42 |
|
iago |
you are right |
| 22:43 |
|
iago |
I would like to experiment with LSC |
| 22:43 |
|
iago |
but I think time won't be enough |
| 22:43 |
|
|
Brennon left #darcs |
| 22:44 |
|
iago |
LSC would solve in some the problem of don't know what is being tested |
| 22:44 |
|
iago |
in some +way |
| 22:44 |
|
Heffalump |
yeah, that'd be great. |
| 22:46 |
|
iago |
well, just a technical question |
| 22:47 |
|
iago |
after take a look to the code I think the useful coverage analysis I can do is just to check the number of conflicting patches in generated trees |
| 22:48 |
|
Heffalump |
that sounds reasonable |
| 22:48 |
|
Heffalump |
as I said before I'm most keen on having tests that include resolution patches and then further conflicts on top of those |
| 22:48 |
|
Heffalump |
so if you can measure that somehow it'd be great |
| 22:48 |
|
Heffalump |
(btw there are known bugs in darcs 2 patches in that scenario, so you'll probably find them if you do write generators for it) |
| 22:49 |
|
iago |
yeah, that would be the main goal |
| 22:50 |
|
iago |
I'm considering cover more kind of patches |
| 22:50 |
|
iago |
at least move patches |
| 22:50 |
|
iago |
I think commutation rules for move are not trivial |
| 22:50 |
|
iago |
so make sense to test them |
| 22:51 |
|
iago |
that should not be too much work |
| 22:53 |
|
iago |
well I think I have a plan now, 1) measure 2) try go introduce conflicts and dependencies in generators 3) cover move patches |
| 22:53 |
|
Heffalump |
sounds good |
| 22:54 |
|
|
secorp left #darcs |
| 22:55 |
|
iago |
maybe it is too much (there is also quality analysis job to do), I will see, but at least I have to reach 2) so result should be something that you could accept in Darcs without extra work |
| 22:56 |
|
iago |
Heffalump, would be better for you if I collect doubts and write them in just one mail to darcs-devel ? |
| 22:57 |
|
Heffalump |
do you mean questions, or comments? |
| 22:57 |
|
Heffalump |
I'm happy with IRC for being asked questions. |
| 22:57 |
|
Heffalump |
if you have general comments about darcs that other people are likely to want to respond to then the mailing list is probably a better forum |
| 23:01 |
|
lispy |
iago: what is LSC? |
| 23:01 |
|
Heffalump |
LazySmallCheck |
| 23:01 |
|
lispy |
ah |
| 23:06 |
|
iago |
can someone give me the big picture of why shrink, shrinkTree etc are needed? |
| 23:07 |
|
iago |
I read some definitions and partially understand them, but I was waiting to see some use of shrink that makes me say "I get it" |
| 23:07 |
|
iago |
but after take a look to the rest of modules I continue to don't get it |
| 23:08 |
|
lispy |
iago: if you write a QC arbitrary instance for trees, they can branch exponentially. That might be why? |
| 23:08 |
|
iago |
I have to re-read |
| 23:08 |
|
iago |
but I though shrink just shrink file content |
| 23:09 |
|
iago |
but not tree branches |
| 23:09 |
|
iago |
it seems to start shrinking content of first state and then propagating that change to all the tree |
| 23:10 |
|
iago |
I'm not sure if that, in the end, implies reduce the number of branches of the tree |
| 23:10 |
|
iago |
(state=RepoModel) |
| 23:12 |
|
Heffalump |
do you understand what shrink in QuickCheck is for in general? |
| 23:13 |
|
iago |
uhm no, ok, that points me to first look to quickcheck doc |
| 23:13 |
|
iago |
I re-read it recently but I may lost something important |
| 23:14 |
|
Heffalump |
ok. Basically it's about finding a smaller testcase that exhibits a failure |
| 23:14 |
|
Heffalump |
once a test fails, QuickCheck calls shrink :: a -> [a] on the failing input |
| 23:14 |
|
Heffalump |
and tries the results to see if any of them fail too |
| 23:14 |
|
Heffalump |
if they do, it repeats from there |
| 23:14 |
|
Heffalump |
that way, you get a test case that's minimal in some sense |
| 23:14 |
|
iago |
oh, I get it |
| 23:15 |
|
iago |
that's good |
| 23:15 |
|
Heffalump |
so the code in my classes is just designed to give effect to that idea in the context of the stateful generation |
| 23:15 |
|
Heffalump |
since obviously you need to track the state when shrinking too |
| 23:15 |
|
Heffalump |
actually, I rewrote the shrinking a completely different way in a local branch a few months ago, but didn't get round to cleaning it up for submission |
| 23:15 |
|
Heffalump |
basically I figured out how to use commutation to implement shrinking instead, which makes it much less effort to do it. |
| 23:16 |
|
Heffalump |
much less effort for each patch type, that is |
| 23:16 |
|
iago |
ok good |
| 23:17 |
|
iago |
so I think I won't touch shrink |
| 23:17 |
|
Heffalump |
makes sense |
| 23:18 |
|
iago |
at least is good to know there is a good amount of code I don't need to care of :) |
| 23:19 |
|
iago |
oh, one last thing |
| 23:19 |
|
iago |
smartFP _ (Hunk _ [] []) | avoidEmptyHunks = unsafeCoerceP localIdentity |
| 23:19 |
|
iago |
was introduced to avoid empty-hunks due to my doubt ? |
| 23:19 |
|
Heffalump |
no, it's been there a while (in some form) |
| 23:20 |
|
Heffalump |
if you really want to understand what's up with empty hunks, look through darcs history and figure out when the commute code for them was introduced |
| 23:20 |
|
Heffalump |
I have a suspicion that David introduced it at around the time I was writing the tests. |
| 23:21 |
|
iago |
it is funny to see how difficult is to continue development of legacy code |
| 23:21 |
|
iago |
that is when you see comments make sense |
| 23:21 |
|
iago |
David doesn't know why he introduces that cases |
| 23:21 |
|
iago |
:P |
| 23:22 |
|
Heffalump |
I suspect a lot of information can be gleaned from the patch history if we have the inclination |
| 23:22 |
|
* Heffalump |
is going to bed |
| 23:22 |
|
lispy |
Heffalump: g'night |
| 23:22 |
|
iago |
good night |
| 23:37 |
|
|
twb joined #darcs |
| 23:38 |
|
iago |
@tell Heffalump Thu Oct 11 22:38:50 WEST 2007 David Roundy <droundy darcs.net> * make empty hunk patches (never generated by darcs) commute like identity. |
| 23:38 |
|
lambdabot |
Consider it noted. |
| 23:39 |
|
iago |
but there is no extra explanation |
| 23:39 |
|
iago |
at least he said "never generated by darcs" |
| 23:41 |
|
iago |
the previous patch was |
| 23:41 |
|
iago |
Thu Oct 11 22:20:59 WEST 2007 David Roundy <droundydarcs.net> |
| 23:41 |
|
iago |
* Add a test of Prim (hangs?). |
| 23:44 |
|
iago |
the theory of "Introduced-for-tests" seems to be very probable |
