Camelia, the Perl 6 bug

IRC log for #darcs, 2013-07-24

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

All times shown according to UTC.

Time Nick Message
00:28 edwardk joined #darcs
02:05 kofno joined #darcs
02:24 Modius joined #darcs
02:57 mizu_no_oto joined #darcs
03:05 edwardk joined #darcs
03:33 preflex_ joined #darcs
03:41 edwardk joined #darcs
03:57 kmels joined #darcs
04:15 mizu_no_oto joined #darcs
04:44 mizu_no_oto joined #darcs
04:47 edwardk joined #darcs
05:24 dolio joined #darcs
05:52 amgarchIn9 joined #darcs
05:59 adnap_ joined #darcs
06:02 edwardk_ joined #darcs
07:12 lelit joined #darcs
07:46 pr_ joined #darcs
07:52 owst_ joined #darcs
07:56 raichoo joined #darcs
08:25 bfrank_ joined #darcs
08:30 kaol joined #darcs
08:30 dolio joined #darcs
08:32 mornfall joined #darcs
08:55 owst joined #darcs
08:55 owst Heffalump: gal_bolle made a good point yesterday, Merge and Commute are differently typed. How can you try one and then the other, with the same pair of patches?
08:57 lambdabot joined #darcs
09:39 amgarchIn9 joined #darcs
09:57 gh__ joined #darcs
10:51 kofno joined #darcs
11:01 alexei joined #darcs
11:11 gh__ can anyone under windows look at http://bugs.darcs.net/issue2334 ?
11:39 favonia joined #darcs
11:47 owst Does anyone else think something like `darcs cha -s --last 3` should just show the patch (summaries) rather than asking to view each one interactively?
12:18 donri joined #darcs
12:19 nomeata joined #darcs
12:31 gh__ owst: yes, probably
12:35 owst gh__: patch looks good, feel free to push to screened/reviewd
12:36 owst perhaps with more 'e'
12:36 owst :-)
12:37 gh__ owst: the announce add patch I guess?
12:39 owst yeah
12:39 gh__ oops you're right about coding style :/
12:39 owst it's very minor
12:40 gh__ will know it for next times
12:56 bfrank_ I think I asked this yesterday, but does anyone know why pull doesn't have a --unified option?
12:57 konundra joined #darcs
12:57 bfrank_ also, what happened to the --intersection option on get?
13:00 gh__ bfrank_: I'm the one "guilty" of adding the --unified flag to record.  I'm not sure why pull (or apply) does not have it.
13:01 bfrank_ ahh, I mean, it is a nice feature, was just wondering why
13:01 gh__ bfrank_: the thing is --unified is buggy already with record. we could try to extend it to pull anyway. you want to look into it?
13:02 gh__ bfrank_: sometimes things are not done just because nobody thought of it, or has time to code it
13:02 bfrank_ ah. That makes sense
13:02 bfrank_ it does sort of fragment the usability a bit
13:04 gh__ if pull had --unified then apply should too
13:04 bfrank_ yeah, I just think it is nice the way unified shows more context
13:04 bfrank_ really quite nice
13:10 mizu_no_oto joined #darcs
13:30 owst gh__: One thing I just thought is that the tense is wrong for the messages: "will add" and "will stop tracking".
13:30 owst darcs has "done it" so it should be "added: " and "stopped tracking:"
13:33 bfrank joined #darcs
13:36 gh__ owst: yeah but it is only validated later, at the moment of doing "record".. I'm not sure in fact. The "adding" message is also what bazaar-ng outputs.
13:40 gh__ fossil says "ADDED"
13:46 owst guess what git says ;-)
13:58 gh__ owst: nothing? :)
13:58 gh__ like hg
14:00 owst yup
14:01 gh__ anyway, I don't mind having a native speaker of english sending followup patches to fix all confirmation messages
14:01 gh__ mentionning no names
14:03 owst :-)
14:08 bfrank when recursively adding files, is there anyway to have it only show the files that are added instead of showing all files?
14:08 owst bfrank: example?
14:09 owst *can you give an
14:09 bfrank I dunno, I did a darcs status
14:09 bfrank and it showed 3 files with a lowercase a
14:09 bfrank for the status
14:09 bfrank but when I do darcs add -r ., it lists all files
14:09 bfrank even files that were already added
14:09 owst Can you paste an shell output somewhere just to make sure I understand you
14:09 bfrank hmm
14:09 owst s/an shell/a shell session/
14:10 bfrank let me derive a simple example
14:10 owst cool, thanks
14:10 owst Argh, last regrets using y/n for the final prompt bites again!!
14:11 owst (y|n)+nn *damn, one too many n's*
14:11 owst And no way to recover my selected hunk state
14:11 owst I'm sure that's been asked-for before...? (recover accidentally cancelled record state)
14:13 bfrank www.pastebin.com/GpsyZazp
14:14 owst bfrank: Yeah, I see your point
14:14 owst So, I wonder if given a directory, darcs should only attempt to add files it doesn't already know about.
14:14 owst seems sensible to me
14:14 owst bfrank: have a quick look in the BTS (bugs.darcs.net) for any tickets that sound relevant
14:14 bfrank and told me which ones it was adding, rather than complaining about the ones already added
14:15 sm morning all
14:15 bfrank morning
14:15 owst hey sm
14:16 sm owst: I'm starting to think changes should just be non-interactive by default
14:16 owst I like it when I just say `darcs cha`, but I seem to not like it anywhere else
14:16 owst So maybe, it should be interactive with no "extra" flags by default
14:16 sm for that one case, you could add -i ?
14:16 owst Yeah, but I always forget
14:17 sm half interactive half not is pretty confusing
14:17 sm when you add in two differnt commands working slightly differently as well
14:17 owst Well, I would describe it as "if you give no more specific behaviour, changes is interactive, otherwise not"
14:18 sm and the varying effect of PAGER and terminal type
14:18 owst Ughhh
14:18 owst ;-)
14:18 sm you'll probably find some flags you want to use but stay interactive
14:18 owst Have we released interactive-as-default?
14:19 sm no I guess not
14:19 owst Cool
14:19 bfrank not sure I see the add -r . on bugs.darcs.net
14:20 owst bfrank: ok, so, I think you can safely make a new bug then (with that example you gave, and the expected output)
14:23 bfrank I guess, another thing that could happen would be to show the files already added if -v were added or something
14:24 owst bfrank: yup, I can imagine "skipping already added file: ./foo"
14:24 owst (put that in the bug too)
14:26 bfrank the skipping already added file: ./foo" to the request for it to do that with a -v flag?
14:26 bfrank ok, will do
14:29 Modius joined #darcs
14:31 bfrank man
14:31 bfrank this is a wordy bug
14:32 bfrank owst: are you able to refine this after I submit it?
14:32 sm write a draft, then rewrite it :)
14:32 sm or paste, we'll help
14:32 owst Yeah, that
14:32 owst (sm's suggestion)
14:33 bfrank pastebin.com/YZJVbeCg
14:34 mizu_no_oto joined #darcs
14:35 sm looks great
14:36 bfrank ok, should I submit it?
14:36 owst Just tweaking
14:36 bfrank ok
14:37 owst gh__'s patch lists the files added, so that part isn't necessary
14:37 owst (he's just sent the patch, so it's not even in screened yet)
14:37 bfrank oh
14:38 owst but the other part of the bug is valid :-)
14:39 bfrank hmm, so the -v part?
14:39 owst http://pastebin.com/nGnp7SAS
14:39 bfrank ok
14:39 owst and the "only try adding unadded files" when specifying a dir to `darcs add`
14:41 bfrank ha
14:41 bfrank ok, I will submit your adjustments
14:41 owst Cool :-)
14:41 owst Thanks for the bug report! :-)
14:41 bfrank yup
14:41 bfrank the only problem now
14:41 bfrank is a good title
14:41 bfrank I was going to use
14:41 bfrank Recursive add should show files added, not files already added. But that is kinda crappy
14:42 owst ha, how about "darcs add on a directory is too verbose w.r.t existing files"
14:42 owst or something
14:42 bfrank ok
14:42 bfrank sounds good to me
14:42 bfrank thanks for your help
14:43 bfrank issue 2335
14:44 owst np
14:46 sm nice bfrank
14:51 bfrank ha, it was mostly owst. ;)
14:56 owst jlneder: I'm still not convinced about the extra complexity introduced to Rebase-related code, for the diff algorithm choice. I don't think the user will ever want to change it...
14:59 kmels joined #darcs
15:00 jlneder owst: i really don't know. If you say it is not going to be used, i guess i could remove it entirely from rebase and use Myers for default.
15:02 owst Well, it certainly adds a lot of complexity to that patch.
15:03 owst Perhaps, separate the rebase code into another patch, and attach it to the tracker.
15:03 owst That way, if we ever want it, we can apply it later
15:04 gh__ jlneder, owset: if we trust Patience better than Myers to generate pretty patches, then we should put Patience by default
15:04 owst The user wouldn't "see" the differences (if any, I'm not sure they could be any) between selecting Meyers or Patience
15:04 owst gh__: ...and there wasn't much in it, performance-wise?
15:06 gh__ owst, jlneder did a couple of benchmarks on his blog, patience defends itself very well, it seems
15:06 owst cool, I would agree then
15:08 owst jlneder: Put a comment at the point of selecting Patience for Rebase, justifying it, you could say that it wasn't deemed to have a user-facing impact, and added complexity to keep the UI option etc.
15:09 jlneder the diferences between myers and patience diff in curly-braced languages are a lot more common and are going to be diferent and i think in that cases it could be a difference with rebase command. Performance wise, i don't think there are any noticeable difference.
15:10 owst Any language with lots of repeated lines
15:10 owst BEGIN ... END etc, but yes, I get your point
15:10 jlneder yes yes, i was only saying an example.
15:11 jlneder Fortran is not my language of choice ;-)
15:11 mtp ruby's got "end"
15:11 mtp :)
15:55 owst jlneder: What did you miss in your previous patch bundle?
15:57 jlneder i change getChangesWith to getChanges as gh suggest.
16:01 owst Ok, if you replace bundles, give a reason (the sentence you just said would be fine!)
16:06 owst gh__: moved patch looks good to go
16:06 owst (quickest review?!) :-)
16:09 gh__ owst: ok
16:10 gh__ owst: and the remove one?
16:12 owst gh__: yep: http://irclog.perlgeek.de/​darcs/2013-07-24#i_7364867
16:12 owst Oh, that was for the add one, nevermind
16:12 owst yes to all 3
16:12 gh__ ok
16:26 gh__ bye
17:02 sm complexifying code should require pretty strong justifying evidence I think
17:49 lelix joined #darcs
18:10 Heffalump fwiw, I think that the diff algorithm probably could have some impact on the behaviour of rebase, but I doubt it would be significant
18:10 Heffalump I would like coalescing patches and diff to be independent, really
18:13 mizu_no_oto joined #darcs
18:15 sm see that metahistory chat on #haskell ? I totally think that'll happen. We could be first! :)
18:16 sm hello Heffalump
18:24 Heffalump it's roughly what mercurial does
18:24 Heffalump though the old commites cuold be gced
18:24 Heffalump s/commites/commits/
18:27 bfrank___ joined #darcs
18:43 owst joined #darcs
18:52 kmels joined #darcs
19:13 edwardk joined #darcs
19:22 bfrank joined #darcs
19:29 konundra joined #darcs
19:30 edwardk joined #darcs
20:00 alexei joined #darcs
20:26 gh_ joined #darcs
20:40 mizu_no_oto joined #darcs
21:27 dcoutts joined #darcs
21:29 kofno joined #darcs
21:37 lispy closed type families allow for some cool stuff
21:38 lispy I bet with those a lot of the type witnesses could be cleaned up
21:38 lispy for example
21:38 lispy now you can write:
21:38 lispy type family Equal (a :: k) (b :: k) :: Bool where; Equal a a = True; Equal a b = False
21:38 lispy where ';' is a newline
21:38 lispy and the Equal ... lines are indented
22:11 kofno joined #darcs
22:16 mizu_no_oto joined #darcs
23:18 Heffalump how would the type-checker ever prove the disequality of two witnesses? Distinct existentials perhaps?
23:21 kmels joined #darcs

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