Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2015-12-01

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

All times shown according to UTC.

Time Nick Message
01:46 Big_G joined #darcs
03:27 pointfree Currently working on http://hub.darcs.net/simon/darcsden/issue/149 I'm tracking down everywhere a urlEncodeStr is needed. I should only have to insert urlEncodeStr into very locations. Looks like the darcsden code needs to be (re)factored for more orthogonality.
04:01 mizu_no_oto joined #darcs
05:50 Heffalump joined #darcs
06:53 Heffalump maerwald: argh, yes, the repository directory is set by a bunch of infrastructure that actually calls the underlying command
06:53 Heffalump so by the time it gets to getDiffDoc it's too late
06:54 Heffalump I'd suggest just setting the cwd first then calling the function without WorkRepoDir
07:28 maerwald setting cwd is somewhat dirty, can we not use withRepositoryDirectory?
07:42 maerwald well, I could use "withCurrentDirectory" from System.Directory
07:43 maerwald but the issue might be somewhere else. I have a feeeling getCurrentDirectory returns "." somewhere
07:45 maerwald maybe we need to use "makeAbsolute"
07:48 maerwald it works with "withCurrentDirectory"
12:08 mizu_no_oto joined #darcs
14:57 maerwald is it possible to get information on what has been transferred inside the darcs ssh session where it does "darcs transfer-mode --repodir <dir>"?
17:16 Riastradh joined #darcs
17:22 maerwald so this is how a patchset could be referenced: https://darcs.hasufell.de/hasufell/darcsden-mailnotify/rawpatches/022019d90af8a0a0e4cc8dcaf4f03e4b116d086c..28b26ede331c60289e24e60c096e21b3c0ad2564
18:42 Heffalump maerwald: this is the trade-off between abstracting the CLI and defining a "proper" internal API
18:42 Heffalump maerwald: what would you want that information for, diagnostics?
18:42 Heffalump (the darcs transfer-mode information)
18:48 maerwald Heffalump: for sending a mail
18:49 Heffalump why would you need internal information about darcs operations for that?
18:49 maerwald how else do I construct a mail that a patch has been pushed?
18:49 Heffalump post hook on apply?
18:49 maerwald how do you want to do that globally on darcsden?
18:53 Heffalump put it in every repo it creates?
18:54 maerwald how do you update the hook?
18:54 Heffalump when would you need to?
18:56 Heffalump also, are you sure darcs transfer-mode is in play when a patch is being pushed?
18:57 maerwald I think so
19:01 Heffalump I thought darcs push does an ssh to darcs apply on the remote end
19:01 Heffalump but maybe transfer-mode is used both ways
19:01 Heffalump ah, the help string says it is
19:02 Heffalump but it's all internal implementation detail - relying on it would be fragile
19:02 Heffalump and you wouldn't catch the case of a merge done directly in darcsden, should you want to
19:02 maerwald I find hooks in repositories way more fragile
19:03 maerwald it's an uncontrollable state
19:03 sm g'day all
19:04 Heffalump even though it's the supported way to trigger things?
19:04 sm maerwald: pointfree and I were discussing that yesterday, did you see ?
19:06 sm I was advocating that darcs' hook system should be improved (making it simpler for the user to configure on the filesystem, and also exposing it via libdarcs api)
19:07 maerwald Heffalump: if you have your own repository somewhere, probably yes, but for darcsden I am not sure that will be pleasant to maintain
19:07 Heffalump I think exposing via libdarcs would be ideal, what you really want is a (Haskell) callback
19:08 sm that would be great
19:09 sm should libdarcs users have control over whether the standard filesystem-based hooks are run or not ?
19:09 Heffalump good question
19:10 Heffalump maerwald/sm: is the rawpatches thing going into darcsden mainline? We'll need to get my patch into darcs 2.10 if so.
19:10 maerwald it needs a bit of refactoring, but not much
19:10 maerwald we were discussing the url scheme
19:10 Heffalump (btw, I'd prefer the URL is called 'diff', because in darcs-speak a patch is a darcs patch)
19:10 sm Heffalump: yes it'll go in when there's a darcs release, also when maerwald has measured performance
19:11 Heffalump ah, I probably missed that, haven't managed to read all of scrollback
19:11 sm that demo link above looked pretty quick
19:11 maerwald that's the patchset for repository subscription btw
19:12 maerwald it's in my darcsden-mail-notify repo too
19:12 sm maerwald: it makes me want a button "squash these patches".. a history rewriting aid
19:12 maerwald also, I am struggling with those Monad stacks again
19:12 maerwald I have a type "Snap a" which has an instance of MonadIO and MonadSnap, then I have a type " XMLGenT m a " which also has an instance of MonadIO, but not MonadSnap... now I want to run a "Snap" action inside the XMLGenT... can I do that with lifting/unlifting somehow?
19:13 maerwald I guess I'll have to make a foreign instance or so?
19:13 sm that stuff can be a nightmare  :)
19:13 maerwald Subtyping is horrible
19:13 sm I have wandered around in those types for days
19:14 sm is there anything similar in the codebase , or are you doing something new ?
19:14 maerwald before I write a monad transformer, there should really be a good reason, I feel like people are throwing those out just because they can, designing effect stacks no one can really understand anymore
19:14 maerwald I don't find something similar
19:15 Heffalump sm: that's the kind of thing the darcsden UI should be really suited to (patch squashing)
19:15 sm what is the new thing you're doing, in simple terms ?
19:15 sm Heffalump: yeah!
19:15 Heffalump btw one concern I have about the diff view above is that its dependent on the order of patches currently in the repo
19:16 sm maerwald: you want to run a Snap action inside XMLGenT.. does that mean running handler code inside a template ?
19:16 maerwald no
19:16 Heffalump so if you did something that caused a reordering it could change (though typically that doesn't happen on remote-only repos)
19:16 maerwald I am just examining the request object
19:16 sm can't you fetch that info and pass it into the template ?
19:17 maerwald that'll be a large chunk of code duplication
19:17 maerwald but I guess I'll just do that
19:17 sm Heffalump: yeah, I think that's just understood with darcs though
19:18 Heffalump sm: hmm, maybe. Not sure if it already happens in darcsden, for example.
19:53 sm maerwald: is that latest http://hub.darcs.net/simon/darcsden/issue/30 patch good enough to merge ?
19:53 sm issue notifications are the main thing, other kinds are much less important I think
19:55 sm are all the patches at hub.darcs.net/simon/darcsden/patches -> maerwald's darcsden-mail-notify required/part of the same feature ?
19:57 sm could they be squashed and described a little ? it's not too clear what each brings
19:57 sm the first three, anyway
20:04 aristid joined #darcs
20:05 aristid joined #darcs
20:11 maerwald sm: it has a button now
20:12 maerwald but pointfree might want to check on that
20:12 maerwald the style is not 100% the same with the other button
20:12 maerwald some css stuff probably
20:13 maerwald sm: and yes, I do strict branching now
20:37 sm Published on Sep 15, 2015
20:39 sm eh.. oops
20:45 maerwald sm: I have a weird idea... there is "evalDDXML :: DDXML -> IO XML"... can we have "constructDDXML :: XML -> DDXML"?
20:47 sm maerwald: those types have been completely purged from my brain I'm afraid
20:47 maerwald indeed, they are horrible
20:48 maerwald I don't like hsp, tbh
20:48 sm I don't like the types, but I got it set up so I didn't have to think about them much
20:48 sm and to use, it does has the advantages I mentioned before
20:48 sm have
20:50 sm maerwald: so, do you think the mail patches can be squashed a little ? I'd like to try em out
20:51 maerwald how do you squash in darcs again?
20:51 maerwald git rebase -i HEAD~5 doesn't work ;)
20:51 sm good question.. maybe darcs rebase --help to start
20:52 sm for a small set of contiguous patches, I might just unrecord all and re-record one or more clean ones
20:54 sm if you think they're already well organised, they might just need a little more description
20:56 sm ack.. make sure your working copy is clean before suspending
20:59 maerwald I don't even understand how I squash it
21:00 maerwald it doesn't work with suspend/unsuspend
21:02 sm darcs rebase suspend --last 5 -a suspends all but patch 1 of the 6. Then I could darcs amend --edit to reword patch 1. Or I can darcs rebase unsuspend patch 2. Then darcs unrecord it, and I can darcs amend --edit to squash it into patch 1.
21:02 sm does that help ?
21:03 maerwald rebase +  unrebase does not squash
21:03 maerwald err, suspend + unsuspend
21:03 sm no, it doesn't
21:04 sm to squash patches in darcs, you have to unrecord them and re-record (or amend)
21:04 sm right Heffalump  ?
21:04 sm suspend/unsuspend just helps you escape the patch dependencies so you can actually do that
21:08 maerwald squashed
21:08 Heffalump sm: right
21:10 sm maerwald: thanks. Oh I see you had some short descriptions too (/patches doesn't show them)
21:12 sm so http://hub.darcs.net/maerwald/darcsden-mail-notify/patch/ca2318a3b17ccdad6c801c88592f64596a27e6b1 means people with issue-enabled repos will unconditionally get email on every issue update. This seems like it should be optional, does the next patch let you toggle it ?
21:12 maerwald sm: er, they are just automatically subscribed on initial issue creation, not unconditionally, no
21:13 maerwald if they chose to unsubscribe, then they are unsubscribed
21:13 sm hmm
21:13 * sm stares at "Send email to repo owner on new issue"
21:14 sm if I apply just this patch, repo owners will unconditionally get email for every new issue right
21:14 sm or this one includes unsubscription as well ?
21:15 maerwald I don't understand. The repo owner is added to the subscription list automatically if a new issue in his repo gets opened, nothing more
21:16 sm hopefully that's what I said.. now what if s/he doesn't want to get those emails
21:16 maerwald he unsubscribes
21:17 sm from that one new issue
21:17 maerwald yes
21:17 sm but will still keep getting at least one email for each new one
21:17 maerwald yes
21:17 maerwald I think that makes sense
21:17 sm and have to unsubscribe each time
21:17 maerwald and I don't think you can toggle that in github either
21:17 maerwald why would you?
21:17 * sm checks
21:17 maerwald I don't want to implement a sieve filter...
21:18 sm I'm pretty sure you can, by just unwatching the github repo, even as the owner - no ?
21:19 maerwald our watch function on the repository doesn't work like githubs one... that would be like 10 times more work
21:19 maerwald and I don't see why that complexity is necessary currently
21:19 sm I'm not advocating complexity, just thinking through the impact of this patch
21:20 maerwald what we could do is... remove the autosubscription on issue level
21:20 maerwald and just keep the autosubscription on repo-level
21:20 maerwald for the repo owner I mean
21:20 sm is it desirable that we let someone configure their issue trackers so they don't receive any email at all, if they want ?
21:21 sm I think it is, and it doesn't sound too hard
21:21 maerwald I think he can just remove his email no?
21:22 sm yeess..
21:22 maerwald if he doesn't want any mail whatsoever
21:22 sm but then wouldn't get any system notifications, password reminders - that's too drastic
21:30 sm most of us get too much email, and it seems polite for darcs hub to give you the choice
21:30 sm maerwald: doesn't patch 2, "Add subscription at repository level", cover the need anyway ?
21:31 maerwald not sure which need you mean
21:31 sm what patch 1 does
21:32 sm managing individual issue subscriptions will be tedious, if you're really interested you'll want to control it on the repo/tracker level
21:32 maerwald http://hub.darcs.net/maerwald/darcsden-mail-notify/patch/ca2318a3b17ccdad6c801c88592f64596a27e6b1 this patch is in fact poorly worded, it implements sending mails on new issues too, which wasn't present before
21:33 sm I see. Yes if you say that in the description, and take the auto-subscribe for repo owners out (of this patch), it would be much clearer
21:33 maerwald and at that time, we didn't have repository level subscription
21:33 maerwald so it made sense to auto-subscribe the owner
21:33 sm yeah
21:34 maerwald I think we still want automatic issue-subscription if you _comment_ on an issue... someone may chose he doesn't want to follow the whole repo, but should still get mails for the issues he is directly involved in
21:34 sm yes, I like that a lot
21:35 sm unless you are already subscribed to the repo of course
21:35 sm ?
21:35 maerwald what do you mean?
21:36 sm if I'm already subscribed to the repo, I don't need to also be subscribed to the issue when I comment on it ?
21:36 maerwald yes you do
21:36 sm why's that ?
21:36 maerwald as explained above... otherwise you'll lose all your relevent issues if you unsubscribe from the repo
21:37 sm I see your argument
21:37 maerwald repo level subscription and issue level subscription should and do not interact
21:37 maerwald we just need sane defaults
21:37 maerwald and no, we don't send mails twice if you are subscribed to both
21:38 maerwald the mail functions take the union of both lists
21:38 sm but if after participating heavily in a big project, when you want to stop the emails it means you'll have to chase around the whole tracker finding and unsubscribing everything
21:39 maerwald is that a common use case?
21:40 sm not at present, no. But is yours ? If we're considering two not-so-common use cases, I'd greatly favour the simplest
21:40 maerwald we can add a "no notifications" thing in the settings, but everything else will be corner case implementations
21:40 sm the fewer settings and mechanics the better
21:40 maerwald I'd just wait until someone complains...
21:41 maerwald github is spamming my mail folder too
21:41 maerwald so I had to set up a sieve filter
21:41 sm that's pretty sad :)
21:41 sm let's not do that
21:41 maerwald that's common
21:41 maerwald if you are active on github
21:42 maerwald no one cares about all the fine grained details inside github
21:42 maerwald it's too tedious to figure out
21:44 sm what would be a clear next step. A patch that adds optional repo-level subscription ?  This covers the new issue notifications need
21:45 maerwald I cannot follow. We already have optional repo-level subscription
21:45 maerwald that's what the next patch does
21:45 sm when you say we already have, you confuse me. You're talking about these patches right
21:46 maerwald the only thing I can see is that we remove the automatic subscription on issue-level for the repository owner, because he is already automatically subscribed to his whole repository
21:46 sm I think what I'm saying is can you redo patch 2 so it doesn't require patch 1, which is less clearly good
21:47 sm I think we are agreeing
21:48 sm whole-repository level subscription is clearly good. Let's add that, only, and then see what's needed next
21:48 maerwald only?
21:48 maerwald you don't want to get notifications if one creates a new issue?
21:48 sm without the automatic subscription on issue-level, which can be considered separately
21:48 maerwald that's a one-line change
21:49 sm yes
21:49 sm I don't know why you're making such a big deal about it
21:49 sm :) just kidding
21:49 maerwald and as said, the other patch includes implementation for new issue mails
21:49 maerwald I am trying to rewrite it, but...
21:49 maerwald unrecord + record is tedious
21:49 sm I'm sorry to be making more work for you
21:51 sm and I hope I'm understanding you. When I subscribe to the whole repo, I'll expect to get email for new issues, of course
21:52 sm I won't expect to be auto-subscribed to the new issues individually
21:53 sm do you use darcsum by the way.. I recommend it if not
21:53 sm it's a poor-man's magit
22:02 maerwald * if you are the repository owner, you get autosubscribed to the _repository_
22:02 maerwald * if you are the issue author, you get autosubscribed to the _issue_
22:02 maerwald * if you comment on an issue, you get autosubscribed to the _issue_
22:02 maerwald following that, only the repository owner naturally gets notifications on new issues automatically, as long as he is subscribed to his repo
22:03 maerwald if he comments on an issue manually, he will still get autosubscribed to the issue and that's desired
22:03 maerwald otherwise we are entering algorithm land for this
22:03 sm ok
22:03 maerwald what if he is subscribed to his, but not that and is in that list, but does not want mails on that issue...
22:04 maerwald in that case, someone will have to come up with a formal algorithm to implement
22:04 sm I didn't understand
22:04 maerwald me neither :D
22:05 maerwald also, I cannot seem to reword the patch
22:05 maerwald because of patch dependencies
22:05 maerwald and unrecording will cause a giant mess
22:05 sm that's what darcs rebase suspend/unsuspend is for
22:06 maerwald unsuspending will cause a conflict then
22:06 maerwald I don't want to deal with that
22:06 * sm doesn't see why
22:06 sm shall I try and see ?
22:06 maerwald I will just append a patch on top
22:07 sm suspend hides the depending patches so you can rerecord/amend, then restores them with dependencies on the rerecorded patch
22:07 maerwald I already have a messed up working tree, I don't want to go further
22:09 sm ok.. I see it's late, I'll let you work and go seek food
22:10 sm thanks for the chat
22:10 Heffalump if you have the two patches you want to squash next to each other, then suspend all the ones on top, unrecord the second, amend-record the first
22:10 Heffalump if you can't get them next to each other you won't be able to do that
22:12 maerwald I just added it on top: http://hub.darcs.net/maerwald/darcsden-mail-notify/patch/1414f5e576ce20831109665b8b0ca3179df55424
22:12 Meeh joined #darcs

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