| Time |
S |
Nick |
Message |
| 00:01 |
|
iago |
:S |
| 00:01 |
|
iago |
I don't how to do it |
| 00:02 |
|
lispy |
iago: darcs changes | head |
| 00:03 |
|
lispy |
iago: better yet, darcs changes --last 1 |
| 00:04 |
|
iago |
lispy, ? |
| 00:04 |
|
iago |
trackdown '... & darcs changes --last 1' ? |
| 00:04 |
|
lispy |
iago: yeah |
| 00:04 |
|
lispy |
iago: well |
| 00:05 |
|
lispy |
iago: I haven't tested it, but roughly that |
| 00:06 |
|
iago |
darcs failed: Not a repository: . (./_darcs/inventory: openBinaryFile: does not exist (No such file or directory)) |
| 00:06 |
|
iago |
:P |
| 00:06 |
|
sm |
darcs trackdown 'darcs changes --last 1' doesn't work unfortunately because it's just a temporary working copy, not the repo |
| 00:06 |
|
sm |
see: darcs trackdown 'pwd; ls -l' |
| 00:07 |
|
lispy |
has trackdown always worked that way? |
| 00:07 |
|
sm |
trackdown seems pretty darn cool, yet this is a pretty major hole |
| 00:07 |
|
* sm |
doesn't know.. there's gotta be a way |
| 00:08 |
|
lispy |
I figured trackdown did a --lazy clone |
| 00:09 |
|
twb |
lispy: it only copies the working tree |
| 00:10 |
|
lispy |
oh, trackdown is linear and it prints the patches as it visits them |
| 00:10 |
|
lispy |
Or at least, it used to be linear |
| 00:10 |
|
sm |
well I don't see how the manual's examples work.. it'll print "Success!" and then you're back where you were |
| 00:10 |
|
lispy |
Was it changed to bisection? |
| 00:10 |
|
sm |
true, it prints the patches. I guess that's all it does |
| 00:10 |
|
sm |
http://darcs.net/manual/node7.[…]14000000000000000 |
| 00:11 |
|
lispy |
"While the test command exits with an error return code, darcs ``unapplies'' one patch from the version controlled files to retrieve an earlier version, and repeats the test command. If the test command finally succeeds, the name of the hunted down patch is found in the output before the last test run." |
| 00:12 |
|
sm |
iago: so the answer is, look for the last patch it prints before success |
| 00:12 |
|
|
isaacd joined #darcs |
| 00:16 |
|
sm |
hmm.. darcs failed: Bad patch (during trackdown --bisect): |
| 00:16 |
|
sm |
./hledger/Hledger: renameFile: inappropriate type (is a directory) |
| 00:16 |
|
sm |
mac case insensitivity perhaps |
| 00:16 |
|
|
alexsuraci joined #darcs |
| 00:17 |
|
|
alexsuraci left #darcs |
| 00:17 |
|
lispy |
sm: or possibly a bug report :) |
| 00:17 |
|
|
alexsuraci joined #darcs |
| 00:18 |
|
sm |
used my darcs bug reportin' budget today! |
| 00:18 |
|
alexsuraci |
sm: made some nice changes to darcsden+ssh last night, working on more now |
| 00:18 |
|
sm |
yay alexsuraci |
| 00:19 |
|
lispy |
sm: this makes me wonder (in general) about using trackdown with randomly generated histories to find bugs in things like apply/commute |
| 00:19 |
|
alexsuraci |
no more Crypto dependency, and fixed a bunch of ssh stuff (pull over ssh, the scp fallback works now, and a few other harder-to-reproduce things) |
| 00:19 |
|
lispy |
sm: seems like it should exercise those code paths fairly well |
| 00:19 |
|
sm |
lispy: it's pretty cool, now that I know (how) it actually works I'll be looking for things to do with it |
| 00:20 |
|
sm |
alexsuraci: very nice |
| 00:20 |
|
sm |
alexsuraci: oh I keep thinking darcsden is on hackage, and looking there |
| 00:20 |
|
iago |
sm, print nothing |
| 00:20 |
|
alexsuraci |
i'd really like to remove the HsOpenSSL dependency from ssh, as it's only used for relatively inconsequential parts |
| 00:20 |
|
iago |
sm, |
| 00:20 |
|
iago |
$ darcs trackdown 'grep FlattenPos src/Darcs/Test/Patch/QuickCheck.hs' |
| 00:20 |
|
iago |
Tracking down command: |
| 00:20 |
|
iago |
grep FlattenPos src/Darcs/Test/Patch/QuickCheck.hs |
| 00:20 |
|
iago |
data TreeWithFlattenPos p C(x) = TWFP Int (Tree p C(x)) |
| 00:20 |
|
iago |
-> (WithStartState RepoModel (TreeWithFlattenPos Prim) C(x) -> t) |
| 00:20 |
|
lispy |
alexsuraci: oh is darcsden written in Haskell? |
| 00:20 |
|
iago |
-> (WithStartState RepoModel (TreeWithFlattenPos Prim) C(x) -> t) |
| 00:20 |
|
iago |
instance Show2 p => Show (TreeWithFlattenPos p C(x)) where |
| 00:20 |
|
iago |
instance Show1 (TreeWithFlattenPos Prim) where |
| 00:20 |
|
iago |
instance Arbitrary (Sealed (WithStartState RepoModel (TreeWithFlattenPos Prim))) where |
| 00:20 |
|
iago |
Success! |
| 00:21 |
|
iago |
that's all |
| 00:21 |
|
alexsuraci |
lispy: yep, its ssh server is too |
| 00:21 |
|
sm |
I'm still wishing for anonymous browsing a list of darcsden.com's repos.. just sayin |
| 00:21 |
|
lispy |
alexsuraci: oh interesting, the ssh server is in Haskell? |
| 00:21 |
|
alexsuraci |
i'll look into why /browse is broken, that should be what you want |
| 00:21 |
|
iago |
I don't see any info about any patch |
| 00:21 |
|
alexsuraci |
lispy: yep, it's on hackage |
| 00:21 |
|
sm |
iago: because that command succeeds with head, it doesn't have to undo any patches |
| 00:21 |
|
alexsuraci |
i wouldn't grab it yet unless you like Crypto dependency hell |
| 00:21 |
|
lispy |
alexsuraci: How much of it is pure haskell and how much uses some existing implementation in C or otherwise? |
| 00:22 |
|
alexsuraci |
lispy: almost all of it is pure haskell. the parts that count, anyway. it uses HsOpenSSL for a few minor things, which I'd like to eradicate. |
| 00:22 |
|
iago |
uhm |
| 00:22 |
|
lispy |
alexsuraci: which package is it on hackage? |
| 00:22 |
|
alexsuraci |
"ssh" |
| 00:23 |
|
sm |
with --bisect it actually says "Test does not fail on head.", but otherwise not |
| 00:23 |
|
lispy |
alexsuraci: cool |
| 00:23 |
|
alexsuraci |
lispy: i'll have a new version up soon |
| 00:23 |
|
sm |
"oh is darcsden written in haskell ?" |
| 00:23 |
|
sm |
lispy: are they not letting you out much ?? :) |
| 00:23 |
|
sm |
darcs hacker that you are ! |
| 00:23 |
|
* alexsuraci |
really needs to fix his irssi theme to show the username for highlights |
| 00:24 |
|
iago |
sm, ok sure, I have added -v, though what Darcs returns is the whole content of the file |
| 00:24 |
|
lispy |
sm: The rock I live under doesn't get any news :) |
| 00:26 |
|
alexsuraci |
man, my local ghc setup is all sorts of screwy |
| 00:27 |
|
sm |
"don't allow any tomfoolery with the scp path" |
| 00:27 |
|
sm |
nice, nice |
| 00:29 |
|
* alexsuraci |
wonders why installing ghc6-doc tries to use /usr/local/lib/ghc-7.0.1/haddock, which doesn't exist |
| 00:29 |
|
sm |
brr |
| 00:30 |
|
sm |
which platform is that ? |
| 00:30 |
|
alexsuraci |
ubuntu 10.10 |
| 00:30 |
|
alexsuraci |
i installed ghc 7 but later switched back to ghc 6, no idea where that's sticking around |
| 00:30 |
|
alexsuraci |
wish ghc came with a "make uninstall" :| |
| 00:31 |
|
sm |
aha |
| 00:31 |
|
twb |
sm: checkinstall? |
| 00:31 |
|
twb |
Sorry, bad completion |
| 00:31 |
|
sm |
well, apt-get purge <ghc pkgs> ? |
| 00:31 |
|
lispy |
alexsuraci: ghc, ghc-pkg, runhaskell, runghc are usually the most important symlinks to fix |
| 00:31 |
|
sm |
I have found ghost data left being in /var/lib/ghc-xxx as well |
| 00:31 |
|
sm |
left behind |
| 00:31 |
|
alexsuraci |
looks like a bunch of stuff stuck around in /usr/local/bin |
| 00:32 |
|
alexsuraci |
and that probably took priority in my $PATH |
| 00:32 |
|
sm |
that'll do it |
| 00:32 |
|
* alexsuraci |
still wishes "make uninstall" was required by law |
| 00:33 |
|
alexsuraci |
there we go! |
| 00:33 |
|
twb |
I don't |
| 00:33 |
|
twb |
If you want package management, use a bloody package manager |
| 00:33 |
|
twb |
"make uninstall" is optimistic at best |
| 00:34 |
|
alexsuraci |
if make install installs it, it should know how to remove it, or at least try |
| 00:34 |
|
alexsuraci |
most things do, it's the ones that don't that constantly cause problems. if it was in my package manager i wouldn't be compiling it. |
| 00:36 |
|
twb |
Indeed; the right solution is thus to get it into your package manager |
| 00:37 |
|
iago |
please help... |
| 00:37 |
|
iago |
I need to know some patch name |
| 00:37 |
|
iago |
I need to review record message |
| 00:38 |
|
iago |
must be some way to do that |
| 00:38 |
|
iago |
otherwise trackdown looks a bit non useful for me |
| 00:39 |
|
sm |
iago: did you get what I said before ? the test you pasted succeeds in HEAD |
| 00:39 |
|
iago |
sm, yep, but I change it by "grep -v" |
| 00:39 |
|
iago |
what I see is that Darcs now prints me the content of the file, just before that change were introduced |
| 00:40 |
|
iago |
but I'm not interested in the content but in the record message |
| 00:40 |
|
sm |
I see what you mean. Is the -v being picked up by the main command ? |
| 00:40 |
|
iago |
Tracking down command: |
| 00:40 |
|
iago |
grep -v FlattenPos src/Darcs/Test/Patch/QuickCheck.hs |
| 00:40 |
|
iago |
Success! |
| 00:40 |
|
iago |
yeah |
| 00:41 |
|
iago |
and indeed I search the given content and FlattenPos does not appear |
| 00:41 |
|
sm |
aside: you might find that easier by searching the output of darcs changes -v --only src/Darcs/Test/Patch/QuickCheck.hs |
| 00:42 |
|
sm |
oh, and also you probably wanted grep -vq |
| 00:42 |
|
iago |
well, that command just gives me two patches |
| 00:42 |
|
iago |
none of them is what caused the change |
| 00:43 |
|
iago |
uh8mm |
| 00:43 |
|
sm |
and also, that grep will always succeed with or without -v |
| 00:43 |
|
iago |
ok, sorry, I make a mistake |
| 00:44 |
|
|
jutaro joined #darcs |
| 00:45 |
|
|
jutaro left #darcs |
| 00:45 |
|
iago |
sm, thanks a lot! |
| 00:45 |
|
iago |
though I wonder why trackdown does not gives you more useful info |
| 00:45 |
|
sm |
no problem.. I'm still trying to do what you're trying |
| 00:46 |
|
sm |
that darcs changes command shows me all the patches, including one with TreeWithFlattenPos |
| 00:46 |
|
iago |
yep |
| 00:46 |
|
iago |
I grep for "data TreeWithFlattenPos" |
| 00:47 |
|
iago |
I want to know which patch introduces that data type and all related stuff |
| 00:47 |
|
sm |
ah |
| 00:47 |
|
sm |
I don't grep that command, I do it in an emacs shell buffer and search |
| 00:48 |
|
iago |
well, I do it in a "less buffer" |
| 00:48 |
|
iago |
just say "grep" for no specific reason |
| 00:49 |
|
iago |
I was doing a grep when using trackdown |
| 00:49 |
|
iago |
so I continue to talk about grep.. well, does not matters a lot |
| 00:49 |
|
sm |
ok |
| 00:50 |
|
|
secorp joined #darcs |
| 00:50 |
|
sm |
I haven't figured out a command to exit with failure if grep succeeds, but I'm sure there's one |
| 00:50 |
|
sm |
there's also annotate |
| 00:52 |
|
sm |
oh I guess annotate would not answer your question |
| 00:52 |
|
sm |
it was ganesh's "shrinking of conflictor pairs" in 2007, wasn't it |
| 00:53 |
|
iago |
yep |
| 00:53 |
|
iago |
not very useful record message indeed |
| 00:56 |
|
iago |
well, maybe TWFP was introduced as a way to improve shrinking |
| 00:58 |
|
sm |
hm. It might sound excessive, but I think every data type should have a haddock explaining it |
| 00:58 |
|
iago |
it is excesive |
| 00:58 |
|
iago |
but every non-trivial data type should have a haddock explaining it |
| 00:58 |
|
iago |
:P |
| 00:59 |
|
twb |
The trivial ones can have an explanation "-- this is trivial" |
| 00:59 |
|
twb |
>duck< |
| 00:59 |
|
sm |
obviously that's subjective, I'm not sure the overheard of haddocking "trivial" types is a real problem |
| 00:59 |
|
sm |
true enough |
| 00:59 |
|
iago |
sm, well, I think it is quite "objective" |
| 00:59 |
|
iago |
Perhaps is trivial |
| 00:59 |
|
iago |
RealPatch is not |
| 01:00 |
|
Igloo |
iago: For future reference, this seems to work for me: http://paste.debian.net/102582/ |
| 01:00 |
|
sm |
well look, Heffalump thought TreeWithFlattenPos was trivial, and here you are years later burning up time trying to figure it out :) |
| 01:00 |
|
iago |
maybe you should define what the brackground of a Darcs reader should be, pointing some specific documents to read before that adventure |
| 01:00 |
|
iago |
I can expect Prim to be trivial |
| 01:00 |
|
iago |
given that any Darcs reader should read a brief introduction to patch theory first |
| 01:01 |
|
Igloo |
But personally I'd have just searched the "changes -v" output |
| 01:01 |
|
iago |
Igloo, thanks |
| 01:02 |
|
iago |
sm, well, when I comment code I figure out what is trivial for others |
| 01:02 |
|
iago |
"if I only know X, is that trivial?" |
| 01:03 |
|
sm |
do you know what's trivial and what's obscure for me when I read darcs code ? not really .. why not just document every type, it's not hard |
| 01:03 |
|
iago |
well, a matter of taste |
| 01:03 |
|
iago |
for me Perhaps data type is trivial |
| 01:04 |
|
sm |
exactly, many different folks will be reading darcs code |
| 01:04 |
|
iago |
you usually find something to be trivial after commenting it and realize you are literally duplicating info |
| 01:05 |
|
iago |
anyway, I agree with you |
| 01:05 |
|
iago |
given the current state of Darcs, improve commentaries is a need |
| 01:05 |
|
|
lelit left #darcs |
| 01:05 |
|
iago |
today I was seeing some studies about software quality in open-source projects |
| 01:06 |
|
sm |
well I agree with you too. :) I just wonder if that simple rule had been in place from the beginning, it might have been a bit tedious and it might have been ignored sometimes, but wouldn't we be in better shape today ? |
| 01:06 |
|
iago |
best quality implied more productivity |
| 01:06 |
|
iago |
you should give it a try |
| 01:07 |
|
sm |
I do my best |
| 01:07 |
|
iago |
well, I think you should impose some rules |
| 01:08 |
|
sm |
http://hledger.org/code-doc/ <- pretty much all types haddocked |
| 01:08 |
|
iago |
companies are considered chaos until they state how things are done |
| 01:08 |
|
iago |
not just over-document processes |
| 01:08 |
|
sm |
ok wait a minute, that's what I started by suggesting and you were arguing against me damnit :) |
| 01:08 |
|
iago |
no, I'm not arguing against you |
| 01:08 |
|
iago |
lool |
| 01:10 |
|
iago |
most code I see was Heffalump or David Roundy job, AFAIK |
| 01:10 |
|
iago |
well, I don't check every record, and I don't intention to do it |
| 01:11 |
|
sm |
oh yes ? it would be interesting to get stats on code authorship, linewise |
| 01:11 |
|
iago |
well, if you actually have good comment discipline |
| 01:12 |
|
iago |
you shouldn't be the author of the code I was reading last weeks |
| 01:16 |
|
iago |
sm, can I know why do you understand I was arguing against you? |
| 01:18 |
|
sm |
iago: well, I said "hm. It might sound excessive, but I think every data type should have a haddock explaining it", you said "it is excesive" and said only non-trivial types should be covered |
| 01:18 |
|
sm |
and we debated from there |
| 01:21 |
|
iago |
well, I partially agree |
| 01:22 |
|
iago |
or I agree in the fundamental idea (==> coment more, specially clearly non trivial stuff) |
| 01:29 |
|
iago |
anyway I misunderstood you, I though you was saying that I was criticizing you |
| 01:29 |
|
sm |
iago: no, we were just arguing in a friendly constructive way |
| 01:30 |
|
sm |
and then I thought you switched and it made me laugh :) |
| 01:31 |
|
sm |
I appreciate the work you're doing on the darcs code. Since we're here, can I ask you what's going on here: data Tree p C(x) where ... ? |
| 01:31 |
|
iago |
I switched? |
| 01:31 |
|
sm |
yes, but why don't we drop it :) |
| 01:32 |
|
sm |
my perception is not reality |
| 01:32 |
|
sm |
I must admit |
| 01:32 |
|
iago |
sm, what is your question about Tree ? |
| 01:32 |
|
iago |
what is wrong? |
| 01:32 |
|
sm |
well, it's a tree where the node value is p ? (a patch I presume, though unspecified) |
| 01:33 |
|
sm |
and what's C(x) ? some kind of constructor, or associated type, or.. ? |
| 01:33 |
|
iago |
are you giving me examples of thing to comment |
| 01:33 |
|
iago |
or just asking because you don't get it |
| 01:34 |
|
sm |
I really don't get it |
| 01:34 |
|
iago |
ok |
| 01:34 |
|
lispy |
sm: C(x) look like a CPP macro around a type variable x |
| 01:34 |
|
iago |
Tree is a "tree of patches", think that branches are indeed repo branches |
| 01:34 |
|
lispy |
sm: That's the whole type witnesses bit, it's actually documented in several places |
| 01:35 |
|
sm |
I looked at TreeWithFlattenPos first, to see how "trivial" it is for me. It wasn't at first. It is more so now that I see it just adds an int to Tree. Now I'm trying to understand Tree - not trivial for this wanna be darcs coder |
| 01:35 |
|
sm |
ok |
| 01:35 |
|
iago |
sm, lol |
| 01:35 |
|
sm |
I can see indeed how you wouldn't want to document type witnesses again in every new type |
| 01:36 |
|
iago |
to understand treewithflattenpos you have to read arbitrary instances of Tree |
| 01:36 |
|
iago |
and then commutePairXXX |
| 01:36 |
|
iago |
sm, when I read this code I understand what Tree is |
| 01:36 |
|
iago |
what I don't understand is WHY |
| 01:36 |
|
iago |
didn't* |
| 01:37 |
|
iago |
I think some Darcs code is "easy to understand" but are implicit design decisions that are hard to understand |
| 01:37 |
|
sm |
yes |
| 01:37 |
|
iago |
for instance, I know what TreeWithFlattenPos does, but I don't know WHY you need it |
| 01:37 |
|
lispy |
I think Heffalump wants to remove the use of C(), but I actually think it helps a little bit at this point just to clearly distinguish which types are type witnesses |
| 01:38 |
|
lispy |
Make them distinct from the rest of the types flying around |
| 01:38 |
|
iago |
sm, for Tree, x represents the initial state of the tree, I don't know if it clarifies something |
| 01:38 |
|
iago |
I usually ignore C(...) stuff |
| 01:38 |
|
iago |
only cares when coding |
| 01:39 |
|
sm |
here's the haddock I wrote: -- ^ A Tree plus an integer indicating its "flatten position". |
| 01:39 |
|
sm |
:) |
| 01:39 |
|
iago |
:P |
| 01:39 |
|
sm |
it's a start |
| 01:39 |
|
iago |
I would write |
| 01:39 |
|
iago |
TreeWithFlattenPos indicates which pair of patches get after flatten the tree |
| 01:39 |
|
iago |
since with Tree, you always pick the last pair |
| 01:40 |
|
sm |
I see |
| 01:40 |
|
iago |
but to know that you need to careful read all QuickCheck code |
| 01:40 |
|
iago |
which is bad |
| 01:40 |
|
iago |
:� |
| 01:40 |
|
iago |
:| |
| 01:41 |
|
* sm |
nominates iago to lead the test code haddockization strike force |
| 01:41 |
|
Igloo |
:-) |
| 01:42 |
|
sm |
actually, I think more code docs would be so useful that I submitted a haddock patch to report coverage stats |
| 01:43 |
|
sm |
but it just reports on the console.. not yet in the web docs which is where you need it to motivate folks |
| 01:44 |
|
iago |
motivate... |
| 01:44 |
|
iago |
:P |
| 01:44 |
|
iago |
in 2010 we have to motivate people to comment code? |
| 01:45 |
|
sm |
of course you do. Nothing happens without motivation |
| 01:45 |
|
iago |
well, I don't know |
| 01:45 |
|
sm |
if we want better code and a more effective community, we should line up the right incentives |
| 01:45 |
|
iago |
I though it was well-known the importance of commenting |
| 01:46 |
|
lispy |
You could be commenting it right now instead of talking about it? ;) |
| 01:46 |
|
* lispy |
has to run |
| 01:46 |
|
iago |
lispy, me? |
| 01:46 |
|
lispy |
sure :) |
| 01:46 |
|
lispy |
Or do you need more motivation :) |
| 01:46 |
|
* lispy |
is going to stop making jabs |
| 01:46 |
|
lispy |
have a nice evening! |
| 01:46 |
|
|
lispy left #darcs |
| 01:46 |
|
sm |
well I did get that far, but I think it might be more productive to get buy-in on the idea than chip away one haddock at a time myself, given that those patches may never be accepted |
| 01:47 |
|
sm |
nor even reach a darcs committer, judging by past experience :/ |
| 01:47 |
|
iago |
I see a problem the day Heffalump stops to work on Darcs |
| 01:48 |
|
iago |
(or some other developers) |
| 01:48 |
|
iago |
but that is a Darcs-team problem |
| 01:48 |
|
sm |
sometimes a developer leaving opens up space for new blood |
| 01:48 |
|
sm |
not you Heffalump :) |
| 01:48 |
|
iago |
new blood that takes complex code without any useful comment |
| 01:49 |
|
iago |
and get bored about it and left the project before start |
| 01:49 |
|
iago |
or just keep that code without change |
| 01:49 |
|
iago |
because he can't change nothing since he does not understand it |
| 01:50 |
|
iago |
i.e. just talking about the non-written knowledge that will be lost |
| 01:50 |
|
iago |
just to give a concrete example |
| 01:50 |
|
iago |
I have to improve Darcs testing |
| 01:51 |
|
sm |
well we're in agreement here. I'd like to see the knowledge you've dug up, with help from others, documented in a form that won't rot |
| 01:51 |
|
iago |
but.. can I throw away that TreeWithFlattenPos? I don't know... Ganesh doesn't know... who knows?? |
| 01:53 |
|
iago |
I understand what TWFP does, but I don't get why do you need to pick pairs from other positions |
| 01:53 |
|
iago |
is this decision based on test coverage? <-- I think not, test coverage was very bad |
| 01:53 |
|
iago |
and then? |
| 01:59 |
|
iago |
wel, too late, time to go bed |
| 01:59 |
|
iago |
sm, I will document my final result |
| 01:59 |
|
iago |
I'm not documenting that code right now because I will rewrite some of them |
| 02:00 |
|
sm |
fair enough |
| 02:00 |
|
iago |
good night all |
| 02:00 |
|
iago |
see you |
| 02:00 |
|
sm |
so TWFP is to allow commuteExamples to select a specific commute pair |
| 02:00 |
|
iago |
uhm |
| 02:00 |
|
iago |
yes |
| 02:01 |
|
sm |
I don't know why either, but you've made it interesting to me, I don't know how :) |
| 02:01 |
|
sm |
maybe we'll find out tomorrow |
| 02:01 |
|
iago |
another interesting thing |
| 02:02 |
|
iago |
is that Unit2 check properties with both Tree and TWFP |
| 02:02 |
|
iago |
someone added TWFP as improvement but does not removes use of Tree ? |
| 02:02 |
|
sm |
what do you mean by Unit2 ? |
| 02:02 |
|
iago |
Darcs.Test.Patch.Unit2 |
| 02:02 |
|
sm |
ah |
| 02:02 |
|
iago |
testProperty "Checking recommute using QuickCheck Tree generator" |
| 02:02 |
|
iago |
(isNothing. (unseal $ commutePairFromTree $ |
| 02:02 |
|
iago |
(recommute commuteReals))), |
| 02:02 |
|
iago |
testProperty "Checking recommute using QuickCheck TWFP generator" |
| 02:02 |
|
iago |
(isNothing . (unseal $ commutePairFromTWFP $ |
| 02:02 |
|
iago |
(recommute commuteReals))), |
| 02:02 |
|
iago |
why? |
| 02:03 |
|
iago |
the only difference is how you pick pairs |
| 02:03 |
|
sm |
have you already annotated all those lines to find the author ? is it Heffalump ? |
| 02:03 |
|
iago |
no, I don't |
| 02:03 |
|
* sm |
tries |
| 02:03 |
|
iago |
but AFAIK the main author was Heffalump |
| 02:03 |
|
iago |
though David Roundy also makes changs |
| 02:04 |
|
sm |
that Heffalump knows more than he's saying.. let's slip him a few beers tomorrow |
| 02:04 |
|
iago |
lol |
| 02:04 |
|
iago |
maybe he is boring of my questions |
| 02:05 |
|
iago |
sm, check commutePairFromTree |
| 02:05 |
|
sm |
may be.. hard to give good answers when you're at work and minding a kid too |
| 02:06 |
|
iago |
and say me the name is not the best |
| 02:06 |
|
iago |
in the past, was a right name (I just quickly take a look to the "past"), then code changes but name no |
| 02:06 |
|
sm |
aha |
| 02:07 |
|
sm |
well, all that Unit2 TWFP stuff was added by "break Darcs.Test.Patch.Unit up to facilitate witnessing", ganesh |
| 02:08 |
|
iago |
yep |
| 02:08 |
|
iago |
I saw it |
| 02:08 |
|
sm |
well I'd better eat and work, and you probably want to sleep |
| 02:08 |
|
sm |
thanks for the chat iago |
| 02:09 |
|
iago |
thanks you |
| 02:09 |
|
iago |
good nigh |
| 02:09 |
|
iago |
or good afternoon for you |
| 02:09 |
|
sm |
good night |
| 02:09 |
|
iago |
good night so |
| 02:09 |
|
iago |
see you |
| 02:09 |
|
|
iago left #darcs |
| 02:24 |
|
|
ManateeLazyCat joined #darcs |
| 03:06 |
|
* alexsuraci |
created http://bugs.darcs.net/issue2019 |
| 03:07 |
|
alexsuraci |
wasn't sure what milestone to put there |
| 03:12 |
|
|
intripoon_ joined #darcs |
| 03:15 |
|
|
intripoon left #darcs |
| 03:44 |
|
|
ManateeLazyCat left #darcs |
| 04:36 |
|
twb |
What's the status of table support in gitit? |
| 04:36 |
|
twb |
Er, in the rst backend specifically |
| 05:01 |
|
alexsuraci |
yay, submitted a patch (hope I did that right) |
| 05:43 |
|
Heffalump |
"break Darcs.Test.Patch.Unit up to facilitate witnessing" is a recent refactoring, you'd have to look at where it came from and keep reading the history of that |
| 05:43 |
|
Heffalump |
(bring on hunk move!) |
| 05:53 |
|
Heffalump |
reading the patch "shrinking of conflictor pairs", it does indeed seem that the intention of TWFP is to improve shrinking. I would guess that, experimentally, I discovered that it was effective. |
| 05:54 |
|
Heffalump |
I can't quite see the logic right now, because changing the flatten position actually seems like quite a fundamental change to the resulting pair. |
| 06:00 |
|
Heffalump |
oh, I guess that complicated merges at the end of the tree tend to be at least as complex as merges earlier on in the tree |
| 06:00 |
|
Heffalump |
so sometimes it's best to look further back |
| 06:11 |
|
Heffalump |
if anyone sees iago, point him at the logs from now |
| 07:25 |
|
|
twb left #darcs |
| 07:28 |
|
|
etarasov joined #darcs |
| 07:29 |
|
|
jeltsch joined #darcs |
| 07:30 |
|
|
ketil joined #darcs |
| 07:51 |
|
|
exlevan left #darcs |
| 07:55 |
|
|
etarasov left #darcs |
| 07:55 |
|
|
etarasov joined #darcs |
| 08:01 |
|
|
darcscommitbot left #darcs |
| 08:02 |
|
|
darcscommitbot joined #darcs |
| 08:03 |
|
|
darcswikibot joined #darcs |
| 08:11 |
|
|
raichoo joined #darcs |
| 08:20 |
|
|
jutaro joined #darcs |
| 08:23 |
|
|
jutaro left #darcs |
| 08:33 |
|
|
lelit joined #darcs |
| 08:43 |
|
|
isaacd left #darcs |
| 09:07 |
|
|
jutaro joined #darcs |
| 09:16 |
|
|
gh_ left #darcs |
| 09:26 |
|
|
kowey joined #darcs |
| 09:29 |
|
kowey |
morning |
| 09:47 |
|
|
lelit left #darcs |
| 09:48 |
|
|
lelit joined #darcs |
| 09:54 |
|
|
lelit left #darcs |
| 09:55 |
|
|
lelit joined #darcs |
| 10:03 |
|
kowey |
oh, hmm, always running into the dilemma of "should I ask them to file a ticket, or is it better to do it myself?" |
| 10:04 |
|
kowey |
I think in the long term it's supposed to be better to ask, so here goes :-) |
| 11:21 |
|
|
balor__ joined #darcs |
| 11:50 |
|
|
jutaro left #darcs |
| 11:56 |
|
|
gbeshers joined #darcs |
| 12:40 |
|
kowey |
inkscape makes it easy to steal colours from http://marklodato.github.com/v[…]ide/index-en.html |
| 12:41 |
|
kowey |
hoping to represent patches as little squares (colour coding them for patches in common, source repo patches, target repo patches) |
| 13:11 |
|
|
raichoo1 joined #darcs |
| 13:12 |
|
|
raichoo left #darcs |
| 13:48 |
|
|
etarasov left #darcs |
| 14:14 |
|
|
balor__ left #darcs |
| 14:14 |
|
|
balor__ joined #darcs |
| 14:19 |
|
|
balor__ left #darcs |
| 14:29 |
|
|
exlevan joined #darcs |
| 14:42 |
|
kowey |
comments? http://imgur.com/Uaeas.png |
| 14:47 |
|
int-e |
. o O ( now add a conflict between t4 and s7 ) |
| 14:48 |
|
int-e |
I'd try to hilight the selected patches differently. The circles look a bit odd and too thin to me. |
| 14:48 |
|
kowey |
hmm, let's see... |
| 14:49 |
|
int-e |
And it wasn't immediately clear what the circles denoted, but I guess there'll be some text going with the diagram. |
| 14:49 |
|
kowey |
yeah, so http://wiki.darcs.net/Using/Model (re merging) is hard to read because it breaks things down into too many possible scenarios |
| 14:49 |
|
kowey |
and this image tries to pack more scenarios into one |
| 14:49 |
|
kowey |
yeah, maybe more text |
| 14:50 |
|
* kowey |
has made his peace with Inkscape |
| 14:50 |
|
kowey |
I resent having to watch a video to figure out how to use this thing, but once you get the hang of it, it's actually quite good |
| 14:55 |
|
|
balor__ joined #darcs |
| 14:58 |
|
kowey |
is this an improvement? http://imgur.com/plJUW.png |
| 14:58 |
|
int-e |
yeah inkscape takes some getting used to (and I still can't use grids effectively) |
| 14:58 |
|
int-e |
that's clearer. |
| 14:59 |
|
int-e |
The circles have a gap at the bottom now, is this a glitch in inkscape? |
| 14:59 |
|
kowey |
thanks for the help! I'll see if I can fit this into the tutorial (more ideas always welcome) |
| 14:59 |
|
kowey |
I'm a bit puzzled by that gap |
| 14:59 |
|
kowey |
I don't see it in inkscape... also my svg file has this huge black blob on it, as though partially redacted |
| 15:00 |
|
sm |
you don't have a mac there kowey I suppose |
| 15:01 |
|
kowey |
I'm an OmniGraffle user, normally |
| 15:01 |
|
sm |
aha.. I just learned that and found it good |
| 15:01 |
|
kowey |
I like inkscape for its native svg format, though |
| 15:01 |
|
sm |
true enough |
| 15:01 |
|
kowey |
OmniGraffle is much easier to just pick up and run with, although maybe less powerful |
| 15:01 |
|
kowey |
and solving a slightly different problem? |
| 15:03 |
|
kowey |
that said, my first attempts at diagramming darcs in OmniGraffle look like ass: http://en.wikibooks.org/wiki/U[…]rking_with_others |
| 15:06 |
|
sm |
meaning aside, I think those look pretty nice .. OG gives you those nice dropshadows etc. |
| 15:07 |
|
sm |
what a pity it doesn't also talk SVG |
| 15:08 |
|
kowey |
the pro version does |
| 15:08 |
|
kowey |
not that well, I found (years ago) |
| 15:08 |
|
kowey |
more attempts at diagramming darcs: http://en.wikibooks.org/wiki/U[…]arcs/Patch_theory |
| 15:08 |
|
kowey |
always felt a dissatisfaction with those, dunno why |
| 15:09 |
|
sm |
they look quite nice |
| 15:09 |
|
kowey |
the drop shadows are a bit of liability if you're using latex |
| 15:09 |
|
kowey |
I forget why |
| 15:21 |
|
kowey |
#inkscape were most helpful, the "redacted" black bar in http://imgur.com/bOLDH.png was due to a 0-character flowed text object lurking around |
| 15:22 |
|
kowey |
tabbing through the objects until I saw "Flowed Text" (there is a way to hunt for them) allowed me to hunt-seek-kill |
| 15:24 |
|
sm |
yay |
| 15:25 |
|
sm |
last I looked, inkscape seemed a very well-run project |
| 15:41 |
|
Igloo |
Hmm, the shopping list idea is nice in the sense that inserting and deleting things makes sense, but unfortunately order doesn't really matter, so the need for commuting is harder to motivate |
| 15:44 |
|
|
etarasov joined #darcs |
| 15:45 |
|
kowey |
oh! hadn't considered it from that perspective |
| 15:45 |
|
kowey |
gh_'s "all the seats were occupied" example may be much better for that |
| 15:46 |
|
Igloo |
"all the seats were occupied"? |
| 15:46 |
|
kowey |
a sentence broken up with unlines . words |
| 15:46 |
|
kowey |
so you get fun little patches like "actually they were rooms" conflicting with patches like "actually they were tables" |
| 15:46 |
|
kowey |
and just by reading the patch name, you understand the intention |
| 15:46 |
|
kowey |
brilliant |
| 15:46 |
|
Igloo |
Ah. That can be a bit fiddly with finding edits that make sense |
| 15:47 |
|
* Igloo |
is wondering about directions, where you can add and remove things like "past the church" |
| 15:48 |
|
Igloo |
Although having lines be single words is also an davantage. Hmm. |
| 15:48 |
|
kowey |
yeah, directions itself well to inserting and deleting things and still has a sense of order |
| 15:49 |
|
|
raichoo1 left #darcs |
| 15:49 |
|
kowey |
directions would be less artificial/contrived looking |
| 15:50 |
|
kowey |
it may not have the same property of patches being intuitive/obvious, but may be obvious enough to still work |
| 15:51 |
|
Igloo |
I can't think of a good reason for pulling only selected changes to directions, though. Nor shopping lists for that matter |
| 16:01 |
|
jeltsch |
kowey: Hi, did you notice my mail on the darcs users list? |
| 16:01 |
|
kowey |
I haven't checked my mail recently, sorry |
| 16:02 |
|
* kowey |
is trying to unlearn that compulsion :-) |
| 16:02 |
|
kowey |
oh, no new mail since my reply? |
| 16:04 |
|
kowey |
http://wiki.darcs.net/Using/Mo[…]th-cherry-picking <-- now on the wiki |
| 16:04 |
|
kowey |
I hope widespread SVG support is something I can count on |
| 16:05 |
|
kowey |
otherwise, I suppose I could write a plugin for the wiki to do some kind of magic... |
| 16:05 |
|
jeltsch |
kowey: I mean the e-mail from ca. 18 hours ago. |
| 16:06 |
|
kowey |
encoding problems in darcs 2.5? <1292539069.1409.109.camel townsend> |
| 16:07 |
|
kowey |
if so, I believe I've commented on it (not very helpfully, I regret) |
| 16:07 |
|
jeltsch |
I haven’t received any answer so far. :-( |
| 16:07 |
|
kowey |
oh dear |
| 16:07 |
|
jeltsch |
Ah no. |
| 16:07 |
|
kowey |
http://lists.osuosl.org/piperm[…]ember/025933.html |
| 16:07 |
|
kowey |
I might have neglected to reply-all |
| 16:08 |
|
jeltsch |
You sent it to the list *and* to myself. If this happens, the mail doesn’t get into my darcs ML folder, which is where I looked for it. |
| 16:08 |
|
jeltsch |
So I missed it. |
| 16:08 |
|
jeltsch |
I’ll have look at it. |
| 16:09 |
|
kowey |
I see |
| 16:09 |
|
kowey |
I tend to do that to account for people who aren't subscribed |
| 16:09 |
|
kowey |
it just says "err... more research needed!" |
| 16:11 |
|
kowey |
I mean... it seems like if we're going to output something we internally think of as being Unicode text, we should either systematically output it in a Unicode-capable encoding, or just use the locale |
| 16:11 |
|
kowey |
(and somehow degrade gracefully) |
| 16:12 |
|
kowey |
but there's the question then of what to do with these bytestrings (which we can only assume to be UTF-8 for metadata) |
| 16:12 |
|
kowey |
I suppose the policy then should be that all darcs metadata must be converted to Unicode text before we output it, no bytestrings for IO for metadata |
| 16:12 |
|
|
jutaro joined #darcs |
| 16:12 |
|
kowey |
bytestrings only for data |
| 16:14 |
|
sm |
kowey: speaking of mail.. fyi I sent a patch yesterday, apparently delivered to patchesdarcs.net. I think alexsuraci did too |
| 16:14 |
|
kowey |
hmm |
| 16:15 |
|
kowey |
oh that's funny |
| 16:15 |
|
kowey |
OH! |
| 16:15 |
|
int-e |
kowey: on SVG: firefox doesn't render svgs in img tags. object tags work. (but noscript seems to classify SVGs as scripts by default. mumble. probably because of the object tag.) |
| 16:15 |
|
* kowey |
rushes to log in |
| 16:16 |
|
kowey |
doh |
| 16:16 |
|
int-e |
http://e.metaclarity.org/52/cr[…]owser-svg-issues/ |
| 16:17 |
|
kowey |
wednesday afternoon UTC, I was working on the BTS a bit |
| 16:17 |
|
int-e |
(apparently the state of the art is to put an img tag into an object tag.) |
| 16:17 |
|
kowey |
and I dutifully set my avoid_test_spam flag |
| 16:17 |
|
kowey |
which I created out of guilt for all the "test message" spam I keep generating |
| 16:17 |
|
int-e |
(with the img tag refering to a plain bitmap (png, whatever)) |
| 16:17 |
|
kowey |
only this time, I forgot to unset it |
| 16:18 |
|
kowey |
so now by trying to avoid noise but not paying enough attention to what I was doing, I ended up causing more trouble, wah! |
| 16:18 |
|
|
raichoo joined #darcs |
| 16:27 |
|
kowey |
int-e: thanks... think I'll just use png and include the svg source |
| 16:39 |
|
|
exlevan left #darcs |
| 16:39 |
|
|
darcswikibot left #darcs |
| 16:39 |
|
|
darcscommitbot left #darcs |
| 16:39 |
|
|
jeltsch left #darcs |
| 16:40 |
|
|
int-e left #darcs |
| 16:40 |
|
|
vsync_ left #darcs |
| 16:41 |
|
|
exlevan joined #darcs |
| 16:41 |
|
|
darcswikibot joined #darcs |
| 16:41 |
|
|
darcscommitbot joined #darcs |
| 16:41 |
|
|
jeltsch joined #darcs |
| 16:41 |
|
|
int-e joined #darcs |
| 16:41 |
|
|
vsync_ joined #darcs |
| 16:51 |
|
alexsuraci |
oi, haskell.org down once again |
| 16:53 |
|
alexsuraci |
/etc/hosts fix: http://hpaste.org/paste/42369/[…]ellorg_ips#p42382 |
| 16:54 |
|
|
jeltsch left #darcs |
| 16:57 |
|
sm |
lord.. I could do a better job of running h.o |
| 16:57 |
|
|
balor__ left #darcs |
| 16:57 |
|
sm |
it's not that hard to keep a site up people |
| 16:57 |
|
sm |
rent a linode for heaven's sake |
| 17:05 |
|
alexsuraci |
gasp! "cabal configure" without a billion lines of dependency conflicts! |
| 17:05 |
|
int-e |
sm: the server is fine this time. it's DNS trouble. |
| 17:06 |
|
alexsuraci |
had to build darcs with mtl 2.x and HTTP 4000.1.x for that |
| 17:06 |
|
int-e |
namely the .org root servers claim that the name servers for haskell.org are ns{1,2}.pendingrenewaldeletion.com. |
| 17:07 |
|
alexsuraci |
er... http://hpaste.org/42384/wait_what |
| 17:07 |
|
* alexsuraci |
bangs head on desk |
| 17:07 |
|
|
sm_ joined #darcs |
| 17:07 |
|
|
exlevan left #darcs |
| 17:08 |
|
|
exlevan joined #darcs |
| 17:08 |
|
alexsuraci |
hell hath no fury like a cabal scorned |
| 17:09 |
|
int-e |
alexsuraci: yes, I love when it does that. with passion. and by love, I mean hate. |
| 17:09 |
|
int-e |
alexsuraci: sometimes running cabal configure -v4 gives some clue at what's going wrong. |
| 17:10 |
|
alexsuraci |
i can't even figure out what would lead to that. even with "mtl >= 2.0" in darcs' .cabal. |
| 17:10 |
|
alexsuraci |
cabal configure works fine, it's cabal install that fails |
| 17:11 |
|
sm_ |
fun |
| 17:11 |
|
|
sm left #darcs |
| 17:11 |
|
|
sm_ is now known as sm |
| 17:11 |
|
sm |
I mentioned a similarly amusing failure the other day and dcoutts pointed me to item 1 on the cabal faq |
| 17:12 |
|
sm |
http://www.haskell.org/cabal/F[…]ndencies-conflict |
| 17:12 |
|
sm |
there's a -v4 ? really ? |
| 17:13 |
|
int-e |
it's an arbitrary number, I think. |
| 17:13 |
|
alexsuraci |
it said only 0..3 is valid when i tried that |
| 17:13 |
|
int-e |
ok |
| 17:21 |
|
|
isaacd joined #darcs |
| 17:27 |
|
alexsuraci |
sm: updating darcsden for the latest darcs atm |
| 17:27 |
|
alexsuraci |
er, that wasn't meant to be a tab completion but whatever, maybe you're interested :P |
| 17:33 |
|
|
isaacd left #darcs |
| 17:35 |
|
|
raichoo left #darcs |
| 17:40 |
|
|
jeltsch joined #darcs |
| 17:42 |
|
|
raichoo joined #darcs |
| 17:44 |
|
kowey |
hmm, this conflict diagram probably needs work, http://wiki.darcs.net/Using/Mo[…]atches-cancel-out |
| 17:44 |
|
kowey |
but this is actually not so hard to do, thanks to layers |
| 17:44 |
|
* kowey |
hurries home to avoid getting stuck in snow |
| 17:44 |
|
|
kowey left #darcs |
| 17:52 |
|
int-e |
hmm, except it's done on a hunk-wise basis. so some parts of the patches remain. hard to illustrate though. |
| 17:54 |
|
|
jutaro left #darcs |
| 17:58 |
|
|
lispy joined #darcs |
| 18:00 |
|
lispy |
sm: the problem is a DNS problem this time around |
| 18:00 |
|
lambdabot |
lispy: You have 1 new message. '/msg lambdabot @messages' to read it. |
| 18:06 |
|
|
iago joined #darcs |
| 18:09 |
|
sm |
sure, doesn't matter |
| 18:09 |
|
sm |
sign up with a quality registrar like dyndns, set up proper expiry alerts, manage at linode |
| 18:10 |
|
sm |
oh, it's all so easy I tell you |
| 18:10 |
|
lispy |
sm: it's already in a quality VPS |
| 18:12 |
|
|
balor__ joined #darcs |
| 18:22 |
|
|
lelit left #darcs |
| 18:23 |
|
iago |
if someone cares inverCommute code is duplicated in cleverCommute |
| 18:24 |
|
iago |
to be honest I don't know why don't just define invertCommute in terms of Commute class |
| 19:10 |
|
|
secorp left #darcs |
| 19:13 |
|
lispy |
iago: patches welcome :) |
| 19:13 |
|
lispy |
iago: and if you don't have time for that, http://bugs.darcs.net or keep a list of tidy up stuff on the wiki |
| 19:36 |
|
Heffalump |
iago: http://irclog.perlgeek.de/darc[…]0-12-17#i_3097996 has a few comments on the conversation about TWFP etc |
| 19:54 |
|
iago |
lispy, feature ? |
| 19:55 |
|
iago |
(Priority field) |
| 19:55 |
|
|
secorp joined #darcs |
| 19:56 |
|
iago |
Heffalump, thanks |
| 20:02 |
|
|
lispy left #darcs |
| 20:03 |
|
|
lispy joined #darcs |
| 20:07 |
|
iago |
lispy, please add "code improvement" priority or something :P |
| 20:16 |
|
lispy |
iago: I don't manage the bug tracker |
| 20:16 |
|
lispy |
iago: file a request or email the list |
| 20:19 |
|
Heffalump |
just make up some other priority for now |
| 20:36 |
|
Heffalump |
iago: if you could mark the patches you'd like in screened as 'needs-screening' I'll take a look at them nowish |
| 20:38 |
|
iago |
just add that text to ChangeNote? |
| 20:38 |
|
iago |
oh sorry I see |
| 20:38 |
|
iago |
a priority |
| 20:42 |
|
iago |
an status |
| 20:42 |
|
iago |
... I need holidays |
| 20:46 |
|
|
arjanb joined #darcs |
| 20:52 |
|
|
kowey joined #darcs |
| 20:53 |
|
iago |
lispy, don't you see a bit strange that mapFL return type is [] ? |
| 20:54 |
|
kowey |
hmm, is this a question about naming? because there's mapFL_FL if I remember correctly |
| 20:56 |
|
iago |
yes |
| 20:56 |
|
iago |
in some way |
| 20:56 |
|
iago |
for me is a bit like the "identity" stuff |
| 20:56 |
|
iago |
I read map, and FL |
| 20:56 |
|
iago |
and I expect mapFL to preserve structure |
| 20:56 |
|
kowey |
Igloo, one thought which occurred to me on way home is that advantage of one-word lines is compactness |
| 20:57 |
|
kowey |
also, it occurred to me that recipes might also work, instead of directions... although it may be a bit harder to modify recipes |
| 20:57 |
|
kowey |
iago: yeah, I kind of tripped up on that when I first saw it |
| 20:58 |
|
Heffalump |
I don't like the naming much either |
| 20:58 |
|
Igloo |
kowey: Oh, recipes is a nice one |
| 21:01 |
|
Igloo |
Is mapFL similar to the currently-proposed chop? |
| 21:01 |
|
Heffalump |
no |
| 21:01 |
|
Heffalump |
(FORALL(a b) p C(a b) -> t) -> FL p C(x y) -> [t] |
| 21:02 |
|
lispy |
iago: Not sure what you mean, [] is a value |
| 21:03 |
|
Heffalump |
it's a type constructor too |
| 21:03 |
|
lispy |
a value or a type constructor |
| 21:03 |
|
Heffalump |
iago thinks that mapFL should be what we actually call mapFL_FL |
| 21:04 |
|
lispy |
oh yeah, mapFL is for mapping over an FL |
| 21:04 |
|
lispy |
but that doesn't mean it has to return an FL |
| 21:04 |
|
iago |
lispy, well, sounds strange |
| 21:05 |
|
iago |
map is supposed to preserve structure |
| 21:05 |
|
iago |
you are using a naming that treats the normal as strange and the strange as normal |
| 21:06 |
|
kowey |
when I first saw it, I never said anything because I just assumed my elders were wiser than me |
| 21:07 |
|
iago |
kowey, well, I usually don't care who does something |
| 21:07 |
|
kowey |
good thing somebody finally spoke up! |
| 21:07 |
|
iago |
I know genius do stupid things |
| 21:08 |
|
lispy |
iago: it's not called map, it's called mapFL |
| 21:08 |
|
lispy |
iago: for the reason you cited |
| 21:09 |
|
lispy |
mapFL_FL would be the one with the weird name |
| 21:10 |
|
iago |
well, for me mapFL means, "the map of FL" |
| 21:10 |
|
lispy |
iago: But, map is hard to reuse because it's in the prelude. |
| 21:10 |
|
iago |
I don't know what your rules are for inferring meaning |
| 21:10 |
|
lispy |
also, droundy doesn't like reusing well known names. So he asked me not to do that |
| 21:11 |
|
lispy |
I have no problem with having Data.FL.map |
| 21:11 |
|
iago |
well |
| 21:11 |
|
lispy |
and Data.ByteString.map |
| 21:11 |
|
iago |
after see code fro droundy |
| 21:11 |
|
lispy |
But, I have to work with other people |
| 21:11 |
|
iago |
I don't consider him an authority in this field |
| 21:11 |
|
iago |
>P |
| 21:12 |
|
iago |
but that's ok |
| 21:12 |
|
iago |
just mentioning something strange for me |
| 21:12 |
|
Heffalump |
I keep writing a Functor2 type class and then dropping it because it turns out I don't actually need it then. |
| 21:12 |
|
lispy |
iago: make a list :) Document it |
| 21:13 |
|
lispy |
Heffalump: IMO, we should have a bit of a library with mirrors of the standard stuff, but I was asked not to do it and so never did :) |
| 21:13 |
|
Heffalump |
you could replace mapFL_FL with fmap2 then, at the cost of more ambiguity |
| 21:13 |
|
lispy |
I kind of agree |
| 21:13 |
|
lispy |
I'm not fond of mirror things just to deal with kinds |
| 21:14 |
|
lispy |
I guess I mean type indexed data types |
| 21:14 |
|
Heffalump |
given the existence of Data.Bytestring.map, FL.map makes sense, but then we'd have to import Darcs.Witnesses.Ordered as FL |
| 21:14 |
|
Heffalump |
so we'd probably want to break it up further first |
| 21:14 |
|
Heffalump |
anyway, I don't have the energy :-) |
| 21:15 |
|
lispy |
I couldn't recall the full name so I said FL, but Darcs.Witnesses.Ordered.map seems okay-ish. |
| 21:16 |
|
lispy |
But, we'd want FL/RL maps |
| 21:16 |
|
iago |
lispy, sometimes you have to understand I can't do, I just mention, if that is important for you, you should do |
| 21:16 |
|
iago |
after all, you are darcs devs |
| 21:17 |
|
iago |
I mean, I am not |
| 21:17 |
|
iago |
and I could simply say nothing |
| 21:18 |
|
lispy |
iago: you are a darcs dev. But, you also have to meet us half way if you want it done. The half-way point that I would like, are lists (on wiki, bug tracker, wherever makes sense) that document the changes. |
| 21:18 |
|
lispy |
iago: irc is too easy to lose |
| 21:20 |
|
iago |
well I think first I have to "discuss" it with you, sometimes I see stuff but I haven't got the time to go deeper |
| 21:21 |
|
iago |
so I think it is better just mention it |
| 21:22 |
|
lispy |
iago: could you maintain a list and then email darcs-users/darcs-devel at the end of your programming session? |
| 21:23 |
|
iago |
ok, I will try to do it |
| 21:23 |
|
iago |
but in the end we will talk if that matters or not |
| 21:25 |
|
lispy |
thanks |
| 21:26 |
|
lispy |
iago: my stance is that the feedback is important, let's not lose it. |
| 21:26 |
|
lispy |
iago: That's my biggest concern here. |
| 21:27 |
|
iago |
ok, I just create a FEEDBACK text file |
| 21:27 |
|
iago |
:D |
| 21:28 |
|
lispy |
iago: great |
| 21:28 |
|
iago |
kowey, were you talking about TDD few days ago? |
| 21:32 |
|
Heffalump |
we've discussed it. I think it'd be good if people chose to use it. We don't want to impose it. |
| 21:33 |
|
iago |
maybe I don't understand open source projects made by volunteers |
| 21:33 |
|
iago |
but in any other context that is considered bad |
| 21:33 |
|
Heffalump |
what is considered bad? |
| 21:34 |
|
Heffalump |
FYI, darcs works in a fairly similar way to most commercial work I've done. |
| 21:34 |
|
iago |
don't have A WAY of doing things |
| 21:35 |
|
lispy |
iago: what do you mean by a WAY? |
| 21:36 |
|
iago |
well, the first symptom of maturity is that everybody knows how things are done, and they are done in a single and specific way |
| 21:36 |
|
iago |
maybe parametrized |
| 21:36 |
|
lispy |
iago: You're on the team (Yay!). Now you are allowed to edit our wiki, our bug tracker, send email to the list, contribute patches, initiate discussions, make suggestions, contribute to discussions, etc. |
| 21:37 |
|
lispy |
We do have some formalized processes. |
| 21:37 |
|
iago |
Heffalump, "darcs works in a fairly similar way to most commercial work I've done." <-- that means something? |
| 21:37 |
|
iago |
most commercial work is a chaos, we could look many analysis concluding that |
| 21:37 |
|
Heffalump |
most of the commercial projects I've worked on have had a similarly disorganised approach to commenting, development and have a big legacy |
| 21:38 |
|
iago |
lispy, wow ... |
| 21:38 |
|
Heffalump |
there's a trade-off between imposing process that just annoys people and using a process to improve quality |
| 21:39 |
|
iago |
well, people should learn why X is better |
| 21:39 |
|
iago |
that's one of the first steps to impose quality :P |
| 21:41 |
|
* kowey |
returns to keyboard |
| 21:41 |
|
iago |
lispy, I have two usernames (if kowey don't remove one of them), iago? |
| 21:41 |
|
lispy |
iago: have you seen for example: http://wiki.darcs.net/BugTracker/PriorityStatus |
| 21:41 |
|
lispy |
iago: and these: http://wiki.darcs.net/Development#processes |
| 21:42 |
|
kowey |
iago: oh yeah, sorry still didn't do that |
| 21:42 |
|
kowey |
we do try to document what cultural norms we have |
| 21:42 |
|
kowey |
I'm not a big believer in Process-ising or turning things into rules |
| 21:43 |
|
iago |
lispy, I didn't sorry |
| 21:44 |
|
iago |
now I took a quickly look |
| 21:44 |
|
iago |
that's good |
| 21:44 |
|
iago |
kowey, it is the only way to improve |
| 21:45 |
|
iago |
very expert people after many years studying soft development conclude that |
| 21:45 |
|
iago |
well, to be more concrete, many groups of very expert people.. |
| 21:45 |
|
iago |
working independently... |
| 21:46 |
|
kowey |
what's the only way to improve? formalising processes? |
| 21:46 |
|
iago |
it helps up to some point of course, it is not "the only key" |
| 21:46 |
|
iago |
the only way to improve how do you do things, is to formalise how things are done |
| 21:46 |
|
iago |
(first) |
| 21:46 |
|
kowey |
yeah, Karl Fogel actually says a little something to that effect, in a bit softer language |
| 21:47 |
|
kowey |
I'm not very well read (producing OSS and mythical man-month + prag prog) |
| 21:47 |
|
kowey |
so I tend to refer to Producing OSS a lot |
| 21:48 |
|
iago |
I had to study CMMI and ISO 9001:2000 |
| 21:48 |
|
lispy |
iago: have you looked in details at the CMMI stuff? |
| 21:48 |
|
iago |
I don't know what ProducingOSS states |
| 21:48 |
|
lispy |
iago: It's a bit dated at this point, for example |
| 21:49 |
|
iago |
lispy, no! |
| 21:49 |
|
lispy |
iago: But we definitely use a revision control system (one of their recommendations :) |
| 21:49 |
|
iago |
I don't know (just as raw data in my memory) all CMMI levels and its key points |
| 21:49 |
|
kowey |
ah here's what Karl says about it: http://producingoss.com/en/written-rules.html |
| 21:49 |
|
lispy |
iago: It's more important to figure out why they recommend things (what they contribute, why, and when not appropriate) and tailor things than it is to define a list of "stuff" to do |
| 21:50 |
|
iago |
lispy, version control is a point of a bigger topic called SCM |
| 21:50 |
|
iago |
lispy, quality norms rarely say how you must do things |
| 21:50 |
|
kowey |
so far, a lot of what we try to document are things that have to be a certain way for automation purposes |
| 21:50 |
|
iago |
specially ISO |
| 21:51 |
|
iago |
who is intented to be fully generic |
| 21:51 |
|
kowey |
or things we've either scratched our heads or disagreed about before coming to a sort of consensus, eg. what to do about GHC versions |
| 21:51 |
|
lispy |
The only process change I want to see at the moment is more testing, but that seems to be changing for the positive at the moment :) |
| 21:51 |
|
iago |
they say things like: "you should evaluate that the product satisfies client needs" |
| 21:51 |
|
kowey |
http://wiki.darcs.net/Development/Policy |
| 21:52 |
|
iago |
there are very well paid people who goes to your org and says you "do it in that way" |
| 21:52 |
|
kowey |
and a lot of our changes (eg. testing) arise from lots of negotiation and also people just doing stuff |
| 21:52 |
|
kowey |
like people who want more testing trying to improve the test infrastructure so tests are easier to write |
| 21:53 |
|
lispy |
iago: A big important thing to keep in mind, is that our pool of performers are volunteers. We can't really force them to do anything. We just encourage and try to set norms. Enforcement is tricky. |
| 21:54 |
|
kowey |
well, you *can* use a little coercion, and at times it may be appropriate |
| 21:54 |
|
iago |
lispy, I know |
| 21:54 |
|
kowey |
in the sense of if you'd like to volunteer for us, great, but here are our expectations |
| 21:55 |
|
kowey |
but it doesn't seem appropriate yet (and I'm too fluffy to coerce, so somebody else would have to do it) |
| 21:55 |
|
iago |
kowey, lot of projects restrict stuff |
| 21:55 |
|
iago |
and they receive many contributions |
| 21:55 |
|
* kowey |
nods |
| 21:55 |
|
kowey |
right, setting standards is not necessarily a barrier |
| 21:55 |
|
Heffalump |
they don't limit their contribution pool by using Haskell in the first place :-) |
| 21:55 |
|
lispy |
To be clear, we do restrict stuff. |
| 21:56 |
|
|
jutaro joined #darcs |
| 21:56 |
|
iago |
for instance |
| 21:56 |
|
iago |
seems incredible Darcs do not enforce a coding style |
| 21:56 |
|
iago |
is one of the most basic stuff |
| 21:56 |
|
iago |
is really hateful see mixed styles |
| 21:56 |
|
kowey |
maybe this isn't very relevant, but Evidence Based Teaching says that in order for people to learn effectively, they need (1) challenging goals (2) good feedback |
| 21:57 |
|
lispy |
iago: One thing we try to do, is get people involved at their current level of contribution and then work with that person to raise the bar |
| 21:57 |
|
kowey |
so I tend to think of high standards the same way I'd think of "challenging goals" |
| 21:57 |
|
kowey |
yep, what lispy says is sort of an ideal |
| 21:57 |
|
kowey |
I find that difficult (for me) to do |
| 21:58 |
|
iago |
Heffalump, :P Haskell is by far the most "cool" functional language |
| 21:58 |
|
iago |
think in positive |
| 21:58 |
|
kowey |
for what it's worth, I think for "light" things like coding styles |
| 21:58 |
|
kowey |
it actually makes sense to have standards |
| 21:59 |
|
iago |
I know you have some stuff in the wiki |
| 21:59 |
|
iago |
as the use of camelCase |
| 21:59 |
|
kowey |
(analogy: some linguists think it's stupid to enforce grammar, because grammar is something that comes naturally... but that it makes perfect sense to enforce spelling standards, because writing is based on convention) |
| 21:59 |
|
iago |
though not something very specific |
| 21:59 |
|
kowey |
well, camelCase is something we pushed towards, no? |
| 22:00 |
|
kowey |
oh, sorry wasn't reading very carefully |
| 22:01 |
|
kowey |
wasn't there a good coding style guide for Haskell out there? |
| 22:01 |
|
iago |
don't ask me please |
| 22:01 |
|
iago |
not something as javacon at least |
| 22:01 |
|
kowey |
there's Igloo's http://urchin.earth.li/~ian/style/haskell.html but I remember seeing something else too |
| 22:02 |
|
lispy |
kowey: check the h.o wiki, I seem to recall stuff. But, I've never really been passionate about the stuff I read there |
| 22:02 |
|
kowey |
well, yeah, so I don't think you really need to convince us to adopt something like a coding style |
| 22:02 |
|
kowey |
in the sense that I don't think anybody is actively resisting the idea |
| 22:02 |
|
kowey |
it's just nobody has yet had the gumption to push it through |
| 22:03 |
|
kowey |
ah this: https://github.com/tibbe/haskell-style-guide |
| 22:03 |
|
Heffalump |
most software projects develop organically. What's appropriate for a small project is different from what's appropriate for a large one. |
| 22:04 |
|
iago |
Heffalump, large projects are an error |
| 22:04 |
|
iago |
large teams are an error |
| 22:04 |
|
iago |
first law in project management |
| 22:04 |
|
iago |
so, that's not a problem |
| 22:04 |
|
iago |
well, "first" because I want, just a law |
| 22:05 |
|
lispy |
kowey: interesting. I don't use that style, no do I see it here at Galois. Not really excited about it either, FWIW |
| 22:05 |
|
Heffalump |
iago: so the linux kernel is an error? |
| 22:06 |
|
iago |
I don't know how they work |
| 22:06 |
|
iago |
small project doesn't mean small code base |
| 22:06 |
|
Heffalump |
it has a large number of contributors |
| 22:06 |
|
iago |
yeah, but very small real team |
| 22:07 |
|
iago |
(I think) |
| 22:07 |
|
Heffalump |
depends how you define tean |
| 22:07 |
|
iago |
anyway as I said, I don't know nothing about OSS projects |
| 22:07 |
|
Heffalump |
team |
| 22:07 |
|
lispy |
kowey: mainly, I think the indentation and newline creation is a bit..weird |
| 22:07 |
|
Heffalump |
how much experience do you have of commercial software development? |
| 22:07 |
|
iago |
I don't see why they should be governed by very different rules |
| 22:07 |
|
iago |
Heffalump, nothing! but I don't think if that is good or bad |
| 22:08 |
|
iago |
I know how you should work, and I know work myself or with a team |
| 22:08 |
|
|
secorp left #darcs |
| 22:08 |
|
kowey |
lispy: hmm, out of interest, how would you indent things? |
| 22:08 |
|
kowey |
more generally, I'd say that this is the sort of thing that lends itself to bikeshedding |
| 22:08 |
|
Heffalump |
you might be in a better position to make pronouncements about what's right and wrong if you did have some :-) |
| 22:08 |
|
iago |
though I didn't work for a company, that's right |
| 22:08 |
|
iago |
Heffalump, well, AFAIK most companies do that in the wrong way |
| 22:09 |
|
Heffalump |
how do you know it's wrong? |
| 22:09 |
|
lispy |
kowey: oh definitely. I don't really think it's healthy to worry too much about coding standards :) |
| 22:09 |
|
kowey |
so it *may* be helpful to just impose it (I mean making sure there's nothing disastrously inappropriate for our needs) |
| 22:09 |
|
iago |
Heffalump, beucase I study that topic |
| 22:09 |
|
kowey |
well, no the point is that you pick something and then just stick with it so it never becomes an item for discussion |
| 22:09 |
|
kowey |
see what I mean? |
| 22:09 |
|
iago |
Heffalump, my knowledge comes from others |
| 22:09 |
|
Heffalump |
theory and practice are often closer in theory than in practice :-) |
| 22:10 |
|
iago |
usually better than not knowledge at all |
| 22:10 |
|
kowey |
(as opposed to leaving people to wonder, because some people do) |
| 22:10 |
|
lispy |
kowey: so this is the code I've written most recently that is publicly available: http://code.haskell.org/~dagit[…]Data/BPlusTree.hs |
| 22:10 |
|
lispy |
kowey: so that shows my current style |
| 22:10 |
|
iago |
and, anyway, I develop software |
| 22:10 |
|
iago |
LOT OF |
| 22:10 |
|
iago |
and I'm bored of work in team |
| 22:11 |
|
iago |
doing it in the context of a company is another stuff |
| 22:12 |
|
kowey |
the Go language approach is to just enforce style in the language |
| 22:12 |
|
kowey |
using a standard reformatter, if I understand correctly... end of discussion |
| 22:13 |
|
iago |
experience doing things wrong doesn't seem to be very relevant either |
| 22:14 |
|
Heffalump |
you don't think it might give an insight into what improvements would be worthwhile? |
| 22:14 |
|
iago |
kowey, enforce style means you need a tool to check that style |
| 22:14 |
|
iago |
usually they are integrated with compiler |
| 22:15 |
|
iago |
so compiler does not compile if style is wrong |
| 22:15 |
|
Heffalump |
iago: kowey is saying that with Go the tool actually does the reformatting too |
| 22:15 |
|
iago |
I know |
| 22:15 |
|
kowey |
dunno if it's actually part of the language per se |
| 22:15 |
|
kowey |
so I'm mis-speaking or speaking very slopilly |
| 22:15 |
|
Heffalump |
hlint is a good start, anyway |
| 22:15 |
|
kowey |
all I know is that it's not something that's left to the coder's discretion |
| 22:16 |
|
kowey |
so I'm happy for us to just pick something with only as much deliberation as we need |
| 22:17 |
|
kowey |
maybe have some tests on some of our pre-existing code to see if it makes sense, and not tolerate too much but-I-like-that-way discussion |
| 22:17 |
|
kowey |
*anyway* iago started this discussion by asking about TDD? |
| 22:17 |
|
iago |
I'm not sure I started it |
| 22:17 |
|
iago |
but yes, I asked about TDD |
| 22:18 |
|
kowey |
yes, TDD is an interesting situation here |
| 22:18 |
|
iago |
actually I would like to ask you what the notion of TDD is |
| 22:18 |
|
kowey |
I think you saw me attempt to summarise the situation? |
| 22:18 |
|
iago |
I though TDD means write tests firsts |
| 22:19 |
|
kowey |
I don't really know, not being a TDD practitioner myself... my sort of head-picture is that the every action the programmer undertakes |
| 22:19 |
|
iago |
implies could be a better word |
| 22:19 |
|
kowey |
begins with tests |
| 22:19 |
|
kowey |
which *seems* to mean unit tests |
| 22:19 |
|
iago |
to be honest I don't think you should take the most cool "word" in test world |
| 22:19 |
|
kowey |
well, of course not |
| 22:20 |
|
iago |
testing while programming, check coverage, etc |
| 22:20 |
|
iago |
is good |
| 22:20 |
|
kowey |
look, it's not about following some fad or fashionable methodology |
| 22:20 |
|
iago |
and it is not TDD |
| 22:20 |
|
kowey |
the way zooko puts it is "not accepting patches unless they come with tests" |
| 22:20 |
|
iago |
I don't know if you can call it TDD |
| 22:20 |
|
kowey |
fine |
| 22:21 |
|
iago |
not an expert anyway |
| 22:21 |
|
kowey |
so I need a term I can use |
| 22:21 |
|
iago |
kowey, testing |
| 22:21 |
|
kowey |
because "testing while programming" is too vague |
| 22:21 |
|
iago |
:P |
| 22:21 |
|
kowey |
"testing" is too vague |
| 22:21 |
|
kowey |
what darcs currently does could be called testing |
| 22:21 |
|
iago |
NO |
| 22:21 |
|
iago |
well, yes... |
| 22:21 |
|
kowey |
I need something to indicate the sort of hyper-aggressive testing people are calling for |
| 22:22 |
|
kowey |
I mean, "testing better" maybe |
| 22:22 |
|
kowey |
but that's too soft to act as a mental anchor |
| 22:22 |
|
kowey |
that's why I (ab)used the word TDD, because it acted as some Thing in my head, that Thing-We-Dont-Do-Yet |
| 22:23 |
|
iago |
TDD implies you write tests while designing |
| 22:23 |
|
iago |
before actually write code |
| 22:23 |
|
iago |
you think tests BEFORE |
| 22:23 |
|
iago |
bad thing: do tests before ALL code is done |
| 22:24 |
|
iago |
for example, do tests just for RC version |
| 22:24 |
|
iago |
common good thing: test while programming |
| 22:24 |
|
iago |
TDD: before programming |
| 22:24 |
|
kowey |
this tweet on testing seemed insightful |
| 22:24 |
|
kowey |
http://twitter.com/#!/wfaler/s[…]15762116757684224 |
| 22:24 |
|
kowey |
iago: yeah... |
| 22:25 |
|
|
exlevan left #darcs |
| 22:25 |
|
lispy |
kowey: yeah, this is why i've started saying "evidence based correctness" |
| 22:25 |
|
kowey |
iago: but from a patch maintainer's point of view, I can't tell what the patch submitter actually did |
| 22:25 |
|
kowey |
iago: so I can only use the existence of a test as a precondition to the code existing as an approximation |
| 22:26 |
|
kowey |
"testing as precondition" |
| 22:26 |
|
iago |
just imagine this case |
| 22:27 |
|
iago |
X submits a patch which introduces stuff that need be testing |
| 22:27 |
|
iago |
X receives a msg "if you don't test then go hell" |
| 22:27 |
|
iago |
that is |
| 22:28 |
|
iago |
testing as precondition, ... I don't know |
| 22:28 |
|
* kowey |
sticks with his sloppy use of TDD until we work out a more appropriate term |
| 22:28 |
|
iago |
actually, lot of patches won't need new tests |
| 22:29 |
|
* lispy |
agrees with kowey |
| 22:29 |
|
kowey |
I think there's enough fuzziness here that reaching for some sort of linguistic precision is not that helpful |
| 22:29 |
|
kowey |
but I could be mistaken |
| 22:30 |
|
iago |
well I don't care |
| 22:30 |
|
iago |
just asking if you are actually talking about TDD |
| 22:30 |
|
kowey |
perhaps from the perspective of people who do get testing, the failure to make certain key distinctions is detrimental to understanding the issue well enough to make progress on it |
| 22:30 |
|
iago |
I know what do you mean now |
| 22:30 |
|
kowey |
I mean something that is a sort of collective-TDD |
| 22:30 |
|
kowey |
ie. not that individuals do TDD necessarily |
| 22:31 |
|
kowey |
but that if Darcs were a single organism |
| 22:31 |
|
kowey |
and if you stepped back far enough, you could arguably saying that the Darcs-creature was doing TDD |
| 22:31 |
|
kowey |
even if its various cells were not |
| 22:31 |
|
iago |
Heffalump, one point, google agrees with my view of small projects and small teams |
| 22:31 |
|
iago |
if that makes you trust more in my theoretical point |
| 22:32 |
|
iago |
I just recall it as an example of a company following that ideas |
| 22:32 |
|
Heffalump |
small teams are clearly more efficient. But it's not always realistic to keep to small teams. |
| 22:33 |
|
iago |
Heffalump, divide and conquer |
| 22:33 |
|
iago |
small teams working on small projects could end constructing very big software |
| 22:33 |
|
Heffalump |
again, not always realistic |
| 22:34 |
|
Heffalump |
yes, a good principle to follow |
| 22:37 |
|
kowey |
one issue with testing is that the people who feel strongly that we should be more aggressive about testing aren't in a position to Lead by Example [no time] - A |
| 22:37 |
|
kowey |
people who are test-curious and feel that it may be a positive thing lack the skills/experience to actually weigh in (can't say TDD-or-whatever is good because I never do it) - B |
| 22:38 |
|
kowey |
whereas people in the trenches, doing the most of the hard work, feel that there are more effective ways of improving our code quality/stability than testing - C |
| 22:39 |
|
kowey |
so A talking to C isn't all that effective, because C just says to A "well, if you feel so strongly about it, why don't you submit patches?" |
| 22:39 |
|
kowey |
but A can't! |
| 22:39 |
|
kowey |
B isn't going to be much help because B only has a vague notion what A is going on about and C's arguments seem plausible too |
| 22:40 |
|
iago |
Heffalump, I have the "metric" for real patches --> no nested conflicts |
| 22:41 |
|
Heffalump |
cool |
| 22:41 |
|
iago |
well, maybe I'm something wrong |
| 22:42 |
|
iago |
something inconsistent |
| 22:42 |
|
iago |
kowey, curiosity |
| 22:43 |
|
iago |
what are the ways C people argue may help more? |
| 22:43 |
|
kowey |
(so for the situation to make progress, afaict, either we need As acting more like Cs and/or we need B to learn more about the A way of things through practical experience) |
| 22:43 |
|
kowey |
(so for example, what I will attempt to do is is include in my patch reviews a bit of hypothetical "if I were to test this code, how would I go about it" musing) |
| 22:44 |
|
kowey |
(but that's not a promise, because it may cause my brain to fry) |
| 22:44 |
|
* kowey |
looks up the discussion... |
| 22:45 |
|
lispy |
Someone was telling me yesterday about a paper where the author argued that hindley-milner type systems are at the sweet spot for preventing bugs. dependent types find even more, but require exponentially more effort. |
| 22:45 |
|
lispy |
I wonder if TDD is in an analogous sweet spot |
| 22:45 |
|
iago |
lispy, well |
| 22:46 |
|
iago |
yesterday I had a talk of a guy from Software Improvement Group and I could say their opinion is YES |
| 22:46 |
|
iago |
but not for TDD, for good testing |
| 22:46 |
|
iago |
to be clear |
| 22:46 |
|
kowey |
oh btw, iago, I figured out your patch500 mystery |
| 22:47 |
|
kowey |
it's because roundup cleverly avoids sending mail when the message body is empty (which I think you predicted) |
| 22:47 |
|
* kowey |
still hunting.. I thought I'd managed to capture the C pov in a relatively succinct sentence sometime |
| 22:48 |
|
iago |
kowey, :) |
| 22:48 |
|
kowey |
ah, http://irclog.perlgeek.de/darc[…]0-12-04#i_3056706 |
| 22:48 |
|
kowey |
it's a bit vague, sorry |
| 22:48 |
|
iago |
I don't know why, but I have very good luck finding bugs |
| 22:48 |
|
iago |
lol |
| 22:48 |
|
kowey |
:-) |
| 22:49 |
|
kowey |
but that's not really the part about the C pov that answers your question... it's a much older discussion I'm thinking of |
| 22:49 |
|
iago |
of course |
| 22:50 |
|
Igloo |
The only thing I can remember is refactoring |
| 22:50 |
|
iago |
improve quality is a need |
| 22:50 |
|
iago |
though I understand Ganesh point |
| 22:50 |
|
kowey |
something about making the library not crazy |
| 22:50 |
|
sm |
"domain name was seized by Network Solutions".. yikes |
| 22:50 |
|
iago |
some code is a mystery |
| 22:51 |
|
iago |
refactoring is not the only key |
| 22:51 |
|
iago |
and should be done with care |
| 22:52 |
|
kowey |
ok, lower bound is 2010-09-06 |
| 22:52 |
|
iago |
I see some strange stuff surely result from a refactoring |
| 22:52 |
|
kowey |
searching shouldn't be *that* hard... |
| 22:52 |
|
Heffalump |
sm: it's sorted now, right? |
| 22:53 |
|
sm |
Heffalump: dunno, I expect so |
| 22:58 |
|
kowey |
ah-ha! http://irclog.perlgeek.de/darc[…]0-08-31#i_2766701 <-- iago |
| 22:59 |
|
kowey |
you can go up from there (found by searching for 'correctness' in the IRC log search ui, _ilbot++) |
| 22:59 |
|
lispy |
yeah, #takusen and #isabelle use _ilbot and it's great! |
| 23:00 |
|
kowey |
ooh, that bit of conversation had an "if only lispy were here" and now you are! |
| 23:00 |
|
* lispy |
has to go to a meeting |
| 23:00 |
|
lispy |
bye |
| 23:00 |
|
kowey |
see ya |
| 23:02 |
|
iago |
ok I see, mornfall is part of C |
| 23:03 |
|
kowey |
to recap C, effort spent on testing is effort not spent on improving interfaces in darcs library |
| 23:03 |
|
kowey |
(opportunity cost argument?) |
| 23:04 |
|
iago |
effort spent improving interfaces is not effort adding features.. |
| 23:04 |
|
iago |
effort spent writing tests |
| 23:04 |
|
iago |
a) let you to modify code without fear |
| 23:04 |
|
kowey |
no that C dislikes testing [C writes tests too] but that C thinks of cleaning up the library as being the bigger contributor to quality/stability |
| 23:04 |
|
* kowey |
hopes he's wearing his C cap right |
| 23:04 |
|
iago |
b) detect bugs earlier, fix them is cheaper |
| 23:05 |
|
kowey |
A's point as articulated by zooko is that the notion of cost in testing needs to treated more carefully |
| 23:05 |
|
iago |
and why not: 1. proper splitting into modules 2. unit testing on each module ??? |
| 23:05 |
|
kowey |
eg. what if whatever you'e doing, testing actually makes you go faster? |
| 23:05 |
|
kowey |
hmm, I think I meant ie |
| 23:06 |
|
iago |
kowey, well, I think zooko point is conditioned by python, ie dynamic types |
| 23:06 |
|
|
jeltsch left #darcs |
| 23:06 |
|
iago |
I found some "dynamic" people arguing they don't need type system because they write tests while coding |
| 23:06 |
|
* kowey |
nods |
| 23:07 |
|
kowey |
we also have static-typing-As around, mind |
| 23:07 |
|
kowey |
but I don't know if they would use the zooko argument |
| 23:07 |
|
iago |
anyway, we could agree that find a "empty list" error message |
| 23:07 |
|
iago |
while you are writing the function that cause it |
| 23:07 |
|
iago |
is much more cheaper than find it later when calling "darcs record" |
| 23:08 |
|
iago |
I think it is the most important point |
| 23:08 |
|
iago |
bugs are cheaper when detected as early as possible |
| 23:08 |
|
iago |
so you need to code a bit, test a bit ... |
| 23:09 |
|
kowey |
yes, which is why anything that sounds like it might push bug detection up front intrigues me |
| 23:09 |
|
kowey |
(hence the B camp) |
| 23:09 |
|
kowey |
because B understands the A argument in the sort of look-at-the-big-picture sense |
| 23:10 |
|
iago |
I think no special skills are needed to write common tests |
| 23:10 |
|
iago |
you may need some specific people assuming more important work |
| 23:10 |
|
kowey |
and in the sense of you perceive the cost of writing tests, so resist them |
| 23:10 |
|
iago |
as writing generators in the case of quickcheck |
| 23:10 |
|
kowey |
but you don't perceive the savings from bugs not even hapenning in the first place (which is unfortunate) |
| 23:11 |
|
kowey |
so you tend to undervalue the latter because you never experience a non-event |
| 23:11 |
|
kowey |
iago: I would like some hand-holding perhaps |
| 23:11 |
|
* kowey |
plans to review patch458 tomorrow morning |
| 23:11 |
|
kowey |
shall we discuss testing some more then when I have something specific in front of my eyes? |
| 23:12 |
|
sm |
writing a test for darcs is not that easy right now, making it easier is a good way to get more of them |
| 23:12 |
|
Heffalump |
yeah, that'd be really helpful |
| 23:13 |
|
Heffalump |
it's not obvious to me how to make it easier though |
| 23:13 |
|
* Heffalump |
goes to bed |
| 23:13 |
|
iago |
kowey, sorry because my English is not very good to express myself as I would like |
| 23:13 |
|
iago |
though the main two reasons I would argue are what I have said |
| 23:13 |
|
sm |
seeing the current test results is also not that easy, making that easier would get more of them |
| 23:14 |
|
iago |
1) you can CHANGE code without fair, you know there is a set of tests with very good coverage ready to detect bugs |
| 23:14 |
|
Igloo |
By "test", are you thinking of QC-like things, or shell scripts? |
| 23:14 |
|
iago |
2) you detect bugs earlier and then they are cheaper |
| 23:14 |
|
iago |
so, even if you don't detect bugs in first place, they are good by 1) |
| 23:14 |
|
iago |
I think we are talking about unit testing |
| 23:14 |
|
kowey |
I don't really understand 1) |
| 23:15 |
|
iago |
kowey, in 2007 Ganesh write one module |
| 23:15 |
|
Igloo |
s/fair/fear/ in 1) |
| 23:15 |
|
kowey |
but I'm really sleepy now, and I think there is some value in having tests as insurance for future code |
| 23:15 |
|
iago |
yeah |
| 23:15 |
|
iago |
fear, sorry |
| 23:15 |
|
kowey |
oh, then I understand 1), thanks! |
| 23:16 |
|
iago |
anyway, I feel your current tests are a mixture |
| 23:16 |
|
iago |
you test primitive patches with real patches |
| 23:16 |
|
iago |
and you call it unit testing |
| 23:16 |
|
kowey |
right, but you see that this is just another sort of A argument that B likes but doesn't actually make concrete progress, right? |
| 23:16 |
|
kowey |
because B knows why testing is a good idea in principle because A is very persuasive |
| 23:16 |
|
kowey |
basically, sm has the right idea |
| 23:17 |
|
kowey |
it's all about getting B to deeply understanding what testing entails |
| 23:17 |
|
iago |
kowey, maybe working on a specific example |
| 23:17 |
|
kowey |
and/or lowering all the little silly technical barriers |
| 23:17 |
|
iago |
a case study |
| 23:17 |
|
iago |
take X small part of Darcs and work on it |
| 23:17 |
|
kowey |
basically B doesn't need to be convinced that testing is a good idea, that problem is solved |
| 23:17 |
|
iago |
to show how |
| 23:18 |
|
kowey |
yeah, that's the spirit |
| 23:18 |
|
kowey |
A should not be trying to convince B |
| 23:18 |
|
kowey |
A should be trying to teach B |
| 23:18 |
|
kowey |
so that B can perhaps have a chance at convincing C (well ok, it's not that tidy) |
| 23:18 |
|
iago |
ok, so A do that and write a small report |
| 23:18 |
|
kowey |
and this B is going to bed,... good night and thanks! |
| 23:18 |
|
iago |
good night |
| 23:19 |
|
|
kowey left #darcs |
| 23:19 |
|
sm |
any tips for: Configuring darcs-2.5... |
| 23:19 |
|
sm |
setup: ghc version >=6.4 is required but the version of /usr/local/bin/ghc |
| 23:20 |
|
iago |
I had no problems with 6.12.1 |
| 23:20 |
|
Igloo |
Well, first, I think the test needs to be updated to require a newer GHC than 6.4... |
| 23:20 |
|
iago |
I expect that to not be very helpful |
| 23:20 |
|
Igloo |
What version is /usr/local/bin/ghc ? |
| 23:20 |
|
sm |
Igloo: 6.12.3, as usual |
| 23:21 |
|
sm |
I guess this is something in Cabal, invoked by our Setup.hs ? |
| 23:24 |
|
* Igloo |
can't see where that test is |
| 23:24 |
|
Igloo |
Looking at HEAD, which may be different |
| 23:26 |
|
sm |
doh.. I should add a -v3 instead of these trace statements |
| 23:27 |
|
sm |
("/usr/local/bin/ghc",["--numeric-version"]) |
| 23:27 |
|
sm |
/usr/local/bin/ghc returned ExitFailure 3295469 |
| 23:27 |
|
sm |
works fine at the command line of course |
| 23:30 |
|
sm |
Igloo: hm, I boiled it down to https://gist.github.com/745899 - wonder if that's relevant |
| 23:31 |
|
Igloo |
sm: What platform? |
| 23:31 |
|
sm |
mac. I have process-1.0.1.4 also installed, though it was hidden |
| 23:32 |
|
Igloo |
Ah, that's probably the problem, then |
| 23:32 |
|
sm |
and what do you know.. after forcibly unregistering it, I can configure again |
| 23:33 |
|
sm |
is process special, then ? having two versions installed is a bad idea ? |
| 23:36 |
|
Igloo |
It's not particularly special, but it includes C code |
| 23:36 |
|
Igloo |
I recommend avoiding having multiple versions of any package installed |
| 23:39 |
|
sm |
seriously ? hmm, that means some adjustment to my practices |
| 23:40 |
|
sm |
I'm not sure it's possible, given the range of things I use from hackage; I'd probably need separate cabal/ghc metadata dbs |
| 23:44 |
|
sm |
alexsuraci: I'm building with mtl 2 like you.. did you get a src/Darcs/Patch/Choices.hs:269:13: Not in scope: data constructor `State' error ? |
| 23:45 |
|
sm |
I should try your patch eh |
| 23:45 |
|
sm |
where is it ? |
| 23:46 |
|
|
raichoo left #darcs |
