Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2017-04-06

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

All times shown according to UTC.

Time Nick Message
01:47 ilbot3 joined #darcs
01:47 Topic for #darcs is now http://darcs.net/ | logs: http://irclog.perlgeek.de/darcs/ | darcs 2.12.5 is out http://darcs.net/Releases/2.12
02:28 bluepixel joined #darcs
02:59 bluepixel joined #darcs
06:20 Heffalump bfrk: there's a patch "  * refactored repair/check command
06:20 Heffalump " in screened that isn't in the patch tracker
08:02 gal_bolle joined #darcs
08:16 gal_bolle joined #darcs
09:23 gal_bolle joined #darcs
09:24 vikraman joined #darcs
13:05 Weltraumschaf joined #darcs
14:02 leg joined #darcs
14:16 carter joined #darcs
15:29 Riastradh joined #darcs
16:30 bfrk joined #darcs
16:34 bfrk UI design question: for clone we have --repodir as an alias for --repo-name; note this is the target repo (normally the second argument); there is no option yet for the source repo
16:37 bfrk I find this confusing. clone --repodir could as well mean the second argument, now that we can clone /to/ a remote location, too.
16:41 bfrk And --repo-name is not much better. It is unique to clone and convert, but init also creates a new repo but supports only --repodir. And the name of the flag gives no indication about whether it is input or output repo.
16:43 bfrk I think we need new options: --source-repo and --target-repo for clone and convert. And init should have (only) --target-repo.
16:43 sm bfrk, my 2c: --repo-name is a historical artifact existing in only two commands, which should be purged; --repodir as an alternative for get/clone's argument serves no purpose, so use it to specify the destination
16:44 sm darcs get http://hub.darcs.net/darcs/darcs-screened --repodir ~/src/darcs/screened
16:46 sm I think we are in danger of having as many options as git
17:07 bfrk sm: only nowadays you can as well say: darcs get local-path remote-url even though this is perhaps less commonly used; it serves as replacement for darcs put
17:10 bfrk sm: re ...serves no purpose: yes, momentarily. I was thinking about a situation where we no longer pass normal arguments to the commands, only options. Yes, that is contrary to what I said begore but gh_'s comments have got me thinking that this may be a worthwhile goal...
17:12 bfrk sm: If we convert all normal arguments to options before passing them to the commands, we have *one* place where to do the "fixing" (conversion of argument paths) instead of two separate ways as we have now
17:13 bfrk sm: perhaps the new options I have been proposing (source, target repo) could be made hidden, so that the user does not see them.
17:19 bfrk sm: re ...as many options as git: if we convert all normal arguments to options, this means we need a few new options. This is true. My current ideas: --subpath=SUBPATH for repo path arguments (i.e. relative to the root of the repo), --pref-xxx=VALUE for the (I think) four pref types, --source-repo, --target-repo for clone, convert, init. I think that's it.
17:22 bfrk sm: The move command may need an extra --target-path=SUBPATH, or we could implicitly use the last one as the target (same as when we give them as normal arguments)
17:23 bfrk OTOH --repo-name would disappear.
17:26 leg joined #darcs
17:27 bfrk sm: The new options are mostly for libdarcs and for internal use. We could hide them completely from the command line. Indeed, it might make sense to do this uniformly: hide every option that duplicates passing normal arguments from the command line UI.
17:34 bfrk sm: The API for a command would have type Config -> IO (), where Config is an abstract type (isomorphic to [DarcsFlag]) with an API for adding options (which I haven't designed yet).
17:41 bfrk I am well aware that this plan is ambitious and will need some work to be properly designed and implemented. But the more I think about it the more I come to the conslusion that it is the only chance of
17:41 bfrk Oops, pressed the wrong key.
17:42 bfrk Scrap the last sentence. I think it will be worthwhile. Clearer structure, better external API.
17:47 Heffalump bfrk: there's a patch "  * refactored repair/check command" in screened that isn't in the patch tracker
17:52 sm bfrk: I hear that it might simplify some code paths and improve maintainability.. what's the impact on the user experience ? That is the goal after all
17:59 jeltsch joined #darcs
18:07 bfrk Heffalump: Strange. i am normally very careful when i push to screened. I there something I can do about this? Hm, perhaps darcs send against a local repo that doesn't have the patch.
18:08 Heffalump bfrk: yes, that's the simplest
18:08 Heffalump bfrk: if you have trouble I can send it in for you
18:17 leg joined #darcs
18:22 bfrk Heffalump: done, see http://bugs.darcs.net/patch1553
18:26 bfrk sm: it was not my goal in this case. rather i want a better external API and better internal structure while (mostly) maintaining the UI as it is.
18:29 bfrk sm: My personal opinion about CL UI is that arguments are easier to use on the CL than options. It's less typing and feels more functional.
18:30 bfrk That is why I want the new options to be hidden from the UI, at least by default.
18:35 bfrk sm: I want us to think in terms of (command) configuration, rather than options. There should be a clear correspondence between the options and arguments in the UI and the configuration, but not necessarily one-to-one
18:42 bfrk The UI should be designed so that in the normal, typical case you need to provide no options at all. For instance, I think --only-to-files should be on by default since in almost all cases, when you pass one or more repo paths, you want that behaviour (e.g. darcs changes -i -v PATH).
18:49 bfrk Heffalump: I need advice on what to do about issue2530. I see that this is a regression and there is/was an existing report about this (Issue1599). Should I close the new one as duplicate and re-open the old one? I also renamed the test to failing-... but since it lives under network/ this has no effect.
18:50 bfrk (I mean: it is still tested by default and then fails)
19:08 Riastradh joined #darcs
19:16 Weltraumschaf joined #darcs
19:17 Heffalump I guess we need to rename it to failing- and then fix the test harness to actually respect that.
19:17 Heffalump Or bisect to find where it actually broke. I could probably do that.
19:21 bfrk Heffalump: i tried darcs test --linear but that broke down because of build problems. probably did it wrong (used cabal new-build w/o clean and at some point got ghc errors about out-of-date interface files)
19:21 Heffalump I'll have a play with it
19:23 bfrk Heffalump: cool, thanks. I'll look into the test program and see if I find why failing... is not honored inside network.
19:37 Heffalump one of the unsubmitted updates to darcs test I have is to have it recognise "skip" states where it doesn't know if the test is passing or failing
19:46 bfrk Heffalump: not sure I understand what this is about. do you expect conflicts when i change the harness?
19:46 Heffalump no, I mean I have a version of darcs that can track down failing changelists even if there are some build failures on the way
19:47 Heffalump i.e. "solves" your 'darcs test --linear' problem above
20:06 bfrk joined #darcs
20:13 bfrk Heffalump: thanks, that sounds pretty useful
20:38 Heffalump bah, --backoff doesn't find a test-working state, will need to try --linear
21:48 bfrk Heffalump: i fixed the harness so that failing- prefix is honored by network tests, too
21:48 Heffalump cool
22:02 bfrk btw, I think with new-build there should be no build failures. the cabal people said this is a ghc bug and when i posted to ghc-users i got at least one confirmation. it helps to clean the dist dir but then --linear takes ages to complete...
22:03 Heffalump new-build can't get past the patch I submitted a while ago to deconditionalise HTTP
22:03 bfrk ah, okay
22:03 Heffalump I'm actually just retrying my trackdown with a repository I reordered to push that patch as early as possible
22:04 Heffalump I spend too much time shaving yaks like that and not enough coding :-)
22:04 bfrk hah i know the feeling
22:07 bfrk in my day job i spent about 3 hours today together with a colleague to find a mysterious bug. it turned out we had overlooked a compiler warning telling us that there is no prototype for fchmod (obscure arch with extremely old compiler) and then we also overlooked that there was an error message after dynamically loading our binary.
22:08 bfrk so when the function was called it jumped into nowhere
22:09 bfrk because fchmod really did not exist
23:15 bf_ joined #darcs
23:25 jeltsch joined #darcs

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