# IRC log for #darcs, 2015-06-01

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.10.0 is out http://darcs.net/Releases/2.10
01:52 c74d joined #darcs
05:51 c74d joined #darcs
07:12 alexei joined #darcs
08:10 c74d3 joined #darcs
09:51 sm joined #darcs
10:23 Rastus_Vernon joined #darcs
10:27 lf94 joined #darcs
10:28 lf94 Hey there! So after seeing the name "darcs" come up a bunch of times, I've started by journey to investigate what it exactly is and how it ticks. So far this[1] and this[2] have been great resources. I have a question though involving the calculation of a patch inverse...
10:28 lf94 1: https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory
10:29 lf94 In the wikibook, the author doesn't really explain how a patch inverse is calculated.
10:30 lf94 Is it determining the last line the modified in patch A before the first line in patch B?
10:30 lf94 And then calculating the offset
10:30 lf94 I can imagine a file with a bunch of modifications all over messing up the calculation...
10:31 lf94 Say you have a 5 line file, and you modify line 2 and 4
10:31 lf94 This modification creates patch A
10:32 lf94 In another "branch", you modify line 3 and insert a line too
10:33 lf94 Nevermind that example actually...I can hardly follow it myself
10:33 lf94 I just have a feeling trying to merge 2 patches that are complex would fail
10:33 lf94 They have to be fairly atomic
14:47 rieper joined #darcs
14:47 gh_ joined #darcs
14:53 rieper joined #darcs
15:01 rieper joined #darcs
15:04 rieper joined #darcs
16:04 sm lf94: that's right, if hunks overlap like that darcs calls it a conflict and will either insert all versions with markers, or abort (unless the overlapping bits are identical)
17:08 * Heffalump appears
17:13 notdan Hi Heffalump :]
17:35 * gh_ stalks
17:38 alexei joined #darcs
17:42 notdan btw Heffalump if you want to do that meeting earlier - I am up
18:44 Heffalump hi notdan :-) I fell asleep on the train home - had a rather late night last night getting home frmom Zurihac
18:44 Heffalump anyway, ready whenever - how's it going?
18:47 alexei joined #darcs
19:00 alexei joined #darcs
19:01 notdan hey
19:01 notdan it's fine. how was Zurihac?
19:01 notdan did you get to hack on darcs?
19:01 Heffalump pretty nice. Big :-)
19:01 Heffalump yes, off and on - sent in some patches to the bug tracker for some minor stuff, and also made some progress to deploying darcsden with nixops
19:02 notdan oh cool
19:02 notdan for testing
19:02 notdan didn't manage to reproduce that darcs dist --zip bug yet
19:03 Heffalump maybe just change the code to drop the ./ anyway - I think it's probably best to preserve the old behaviour unless there's a concrete reason to switch
19:03 notdan Yeah, but I didn't figure out yet where is ./ coming from specifically
19:04 Heffalump it's in the code isn't it?
19:04 Heffalump I'll look up the line I'm thinknig of
19:05 notdan Might be this one: http://hub.darcs.net/co-dan/darcs-soc/browse/src/Darcs/UI/Commands/Dist.hs#233
19:05 notdan but I am not entierly sure
19:05 Heffalump oh, maybe I was wrong about that going into the zip, it's being used to fetch the file
19:06 notdan would you mind if I bug you about nixos in the near future? :P
19:06 Heffalump I'm surprised it doesn't reproduce on another os if yuo have an unzip command at all.
19:06 notdan Heffalump: hm, sorry, I don't quite understand
19:06 Heffalump sure :-) But I'm not very expert with it, still at the cargo cult coding stage.
19:06 Heffalump http://hub.darcs.net/darcs/darcs-screened/patch/20150507135812-21ae5
19:07 Heffalump when I looked at the patch before, I thought the code had change from using darcsdir </> to using path </> darcsdir </>, where path is "." in the old calling case
19:08 Heffalump but actually I think that's only in one place that's not relevant to what goes into the zip file itself
19:11 notdan hm
19:12 notdan I will try debuging it with Debug.Trace and try to pointpoint the problem
19:12 Heffalump perhaps also just check if the zips you get with and without your patch look identical
19:12 notdan ugh I am having a bit of lag on my shell - brb reconnection from home
19:12 notdan heyeah, good idea
19:12 notdan_ joined #darcs
19:13 notdan_ Ok
19:13 Heffalump don't spend too long if you can't reproduce my symptoms - ping me again and I'll debug it myself. It'll be much easier to fix if the fixer can reproduce it, so no point in using your time inefficiently.
19:13 Heffalump and there's always the possibility of me having made a mistake, though what I've seen so far seemed pretty clear-cut
19:14 notdan_ yeah I am sure there is a bug
19:14 notdan_ anyway, do you want me to update you on my status re: darcsden?
19:15 notdan_ Here's what I have: a local backend (similar to the backend that you written); ability to browse local repositories, view files, list repositories (under user or global)
19:16 Heffalump nice!
19:16 notdan_ Support for nested repositories (done with a bit of hacking)
19:16 notdan_ fetching some metadata from _darcs/darcsden/ folder
19:17 alexei joined #darcs
19:17 Heffalump shall I have a play with it - is it your darcsden-local repo on hub.darcs.net?
19:17 notdan_ I think that is mostly it. There are some rough edges awaiting me polishing them, but I recon that the main problem is nested repositories
19:17 notdan_ Heffalump: I can send you a patch bundle
19:18 Heffalump sure
19:18 notdan_ What repo should I send it against?
19:18 Heffalump simon/darcsden
19:19 Heffalump so what's complicated about nested repos? If it's really hard I think it's ok to just not support them for now, depending on other priorities
19:20 notdan_ http://covariant.me/stuff/tmp/forganesh.dpatch
19:20 notdan_ Heffalump: the main problem is the URL hierarchy
19:20 Heffalump oh, I see, yeah
19:20 notdan_ In regular darcsden you have paths user/repo/browse, user/repo/changes, etc
19:21 notdan_ The way I handle them now is a bit hacky - I take apart the request URL, find the "closest" darcs repository and say that the rerst of the URL is the path to a file/directory
19:21 Heffalump so if it's ambiguous where a repo starts you have a problem. Particularly if there's a nested repo in a 'browse' folder.
19:22 notdan_ Currently I am handling the "browse" part specifically - but now I need to add support for all the other darcsden handlers
19:22 notdan_ which is bad practice imo, because it involves code duplication
19:22 notdan_ (in this case -- route duplication :)
19:22 Heffalump I see. Or we could rethink the URL scheme for the local use case.
19:22 Heffalump :-)
19:22 notdan_ and yeah, as you've said -- we have problems if we have a directory named "browse" or "changes"
19:23 Heffalump I think the "longest match" idea makes sense in general, and I guess you could extract the names you need from the same place the handlers are defined somehow - maybe it's possible to introspect them.
19:23 Heffalump but we also want the URLs to look good to users.
19:23 notdan_ oh btw if you want to run the patches make sure to edit Production.hs and change the root directory
19:24 notdan_ yeah it's a problem to find an unambiguous URL scheme
19:25 notdan_ how popular nested repositories are, really?
19:25 Heffalump not very, that I know of, though at some point it might be nice to support something like submodules
19:25 Heffalump but in that case you'd probably want all the browsing to be based off the parent repo anyway
19:26 Heffalump it seems plausible to not support them, but I guess anyone who did use them might find it a bit frustrating
19:26 Heffalump I wonder if there's a nice looking alternative separator character to /, that we could use to translate the paths in the user's home dir
19:27 Heffalump so instead of /home/ganesh/foo/bar becoming http://.../ganesh/foo/bar/path, it might become http://.../ganesh/foo-bar/path
19:27 notdan_ I was thinking of #
19:27 notdan_ but that's kinda weird
19:27 Heffalump hmm, yes, that occured to me too, but doesn't it indicate fragments or something special in URLs?
19:28 Heffalump and of course anything but / can in theory be valid in a real filesystem path
19:28 notdan_ it is used for anchors IIRC, as in <a name="test">...</a>
19:28 Heffalump http://en.wikipedia.org/wiki/Fragment_identifier
19:28 Heffalump "In URIs a hashmark # introduces the optional fragment near the end of the URL. "
19:29 Heffalump ok, so we definitely can't use #, because they get processed client-side
19:29 notdan_ worst case scenario - we can encode a pair (repository,path) in base64 or something along those lines
19:29 Heffalump ok, so how about sticking with the nice URLs we have at the moment, and keeping that as an alternative route in that gives the user a fallback strategy?
19:30 Heffalump (if they can discover it, but that can be addressed separately if it comes up)
19:30 notdan_ keeping what as an alternative route?
19:31 Heffalump the base64 idea (or anything else that's guaranteed unambiguous)
19:31 notdan_ got it. so sticking with nice URLs for now pretty much entails suspending (temporarily) nested repositories, right?
19:32 Heffalump I think so - if it's going to be a significant time sink, it's not really worth it for now
19:32 notdan_ ok
19:33 Heffalump one thing we should discuss is testing your work
19:33 notdan_ Oh yeah
19:33 Heffalump there's the existing test suite that does UI-based tests with selenium. I think noone but me ever runs it :-)
19:33 notdan_ to be honest - I am very clueless at this atm
19:33 notdan_ but I should definitely install selenium and get it to work
19:33 Heffalump at the general concept of how to write good tests, or specifically the darcsden test suite?
19:34 notdan_ well at the general concept of automatic tests for UI-heavy code
19:34 Heffalump right, it's a hard problem
19:34 notdan_ and darcsden specifically :)
19:34 Heffalump in other projects I've worked on we gave up on UI testing because it was too unreliable
19:34 Heffalump I think darcsden would benefit from having some slightly lower-level tests than the UI tests, i.e. something that goes in either at the code level or the raw HTTP level
19:35 Heffalump so you could just add a new set of tests that do something like that
19:35 Heffalump FYI running selenium is just downloading a jar, leaving it running with 'java -jar' and then running the test harness. At least in theory.
19:36 Heffalump so while it's a bit clunky it's not _too_ awful
19:36 notdan_ right
19:36 notdan_ I think raw HTTP tests would be nice for testing basic santity/functionality
19:37 notdan_ code tests: I am not sure, but I will give it a try
19:37 Heffalump one problem I see with raw HTTP tests is what do you look at in the test?
19:37 notdan_ Testing is really important, despite being my least favourite part of writing code
19:37 Heffalump Do you scan the HTML for things you expect, or make sure it's exactly equal to something specific?
19:37 notdan_ Heffalump: that the handlers do not fail?
19:37 Heffalump yeah, me too :-)
19:38 Heffalump notdan_: I see, so just check that you get _some_ result? Makes sense.
19:38 Heffalump what's the benefit of HTTP over calling them directly?
19:39 notdan_ I think this is the easiest way to test handlers and viewes: testing them directly involves a lot of set up, IIRC
19:39 Heffalump I see, fair enough.
19:39 notdan_ Of course I can test individual functions directly, but there I see a similar problem
19:39 Heffalump and I guess there is already infrastructure to fork a server and run it (for the UI tests)
19:40 notdan_ for example, I have a function `getRepo' in DarcsDen.Backend.Presistent.Local. It basically returns a Repository object from a given path
19:40 notdan_ I cannot really test it against a "canonical" Repository object - that would just mean code duplication
19:40 notdan_ but I can test whether it fails or not
19:40 Heffalump btw, I'd suggest you not use HTTP itself for the client library, the code is awful and the maintainer is a lazy **** - it's sole merit is that it has few dependencies and is in the platform.
19:41 notdan_ haha I will keep it in mind
19:41 notdan_ I will try http libraries for conduit or pipes - heard good things about them
19:42 Heffalump I guess the other general topic I had to mention is to make sure you don't wait too long before submitting stuff upstream (i.e. to sm), otherwise it'll be more painful for both you and him
19:43 notdan_ Yeah I wanted to talk about that in more detail
19:43 notdan_ I should also pull stuff from upstream frequently, right?
19:43 Heffalump yes, definitely
19:43 notdan_ OK, I will try to do that
19:44 notdan_ I guess my darcs usage is rather bad in that respect
19:44 Heffalump and as soon as you have anything that would be beneficial to have in darcsden even if you disappeared completely the next day, submit it
19:44 notdan_ usually I have 5-6 WIP patches sitting in my repository
19:44 notdan_ because they are related to 5 different parts of code
19:45 Heffalump it can get hard to keep them genuinely disentangled
19:45 notdan_ I am not sure if that's good darcs usage or not :{
19:45 Heffalump I think whatever works for you, really
19:45 Heffalump I don't see any intrinsic objection, but you might be setting yourself up for conflicts or unintended dependencies
19:45 notdan_ Ok I have a few patches that could go into darcsden. Really minor stuff like comments, removing code duplication, etc
19:45 Heffalump those are always worth submitting asap, yes
19:46 Heffalump I think the general submission model is to push to a repo on hub.darcs.net and ping sm here.
19:46 Heffalump once you're done we can do it with proper "patch submissions" hopefully ;-)
19:46 notdan_ I can submit the Backend.Local.* files, but I think submitting the code that adds a route and a handle is premature - it needs more work and testing
19:47 Heffalump I guess if the code would be totally unusable without more work there's not much point in submitting it - though do make sure you have backups :-)
19:47 notdan_ definitely :)
19:49 Heffalump is it localRootDir I should change in your patches, btw?
19:49 Heffalump and will an absolute path ("/home/ganesh/") work?
19:49 notdan_ yes
19:49 notdan_ line 39 in Production.hs
19:50 Heffalump why do you depend on darcs 2.11?
19:50 Heffalump because doFastZip' is there and not in the 2.10 branch?
19:51 notdan_ oh, that's for fastZip yes
19:52 Heffalump ok - hopefuly we can put that in 2.10, obviously once the current problem is fixed. In general try not to rely on 2.11, darcsden has only just got out of the messy situation of needing development darcs with the 2.10 release and I don't think anyone would welcome it returning to that state.
19:52 Heffalump if some really important reason comes up we'll have to discuss it of course
19:54 notdan_ I see
19:55 Heffalump ok, I can't think of anything else I had to discuss - you? Do you have enough to be doing?
19:55 notdan_ I had a list of more specific things I was thinking of doing - we can go through it quickly if you want?
19:56 Heffalump yep, sure
19:56 notdan_ So, clicking on "fork" raises an error.. but creates a directory anyway. I was thinking of writing code for disabling forking completely, in the same way registration support can be disabled.
19:57 Heffalump I'd kind of expect "fork" to work for local dev
19:57 Heffalump it's what you do if you need a new copy of a repo to work on something separate
19:57 notdan_ 2. I need to read about _darcs/prefs/defaultrepo format and implement the parent functionality for local repositories
19:58 notdan_ Heffalump: hm, makes sense actually
19:58 notdan_ I will read into it
19:58 Heffalump the format is pretty simple, it's a single line containing a repo :-)
19:59 notdan_ Yeah I ment to find darcs functions for parsing those kinds of URLs and find which ones are local and which ones are not
19:59 notdan_ sorry I am actually copy pasting from the notes I made for myself so it's a bit messy
19:59 Heffalump no problem :-)
19:59 notdan_ re: forking, I think the forking UI should be remade a little bit
20:00 notdan_ it should always ask for a path to the new repository
20:00 Heffalump I think that's fine. Wherever possible try to share as much as possible with the server use-case rather than having two divergent paths.
20:00 notdan_ but yeah it sounds doable and useful
20:00 Heffalump So in that case perhaps consider reworking the server UI for forking too.
20:00 Heffalump Personally I would prefer it asked me first, rather than making something I have to rename.
20:01 notdan_ Yeah, exactly
20:01 notdan_ 3. So I need to make sure to display README.md and other markdown
20:01 notdan_ correctly
20:01 notdan_ and other blobs as well
20:02 notdan_ 4. Right now there is a dummy "local" user - we can probably read the information for that user (Full Name, Website, whatever) from the config
20:02 Heffalump 3 - makes sense - though you might want to think about prioritising stuff that's needed to make the local dev work submittable - that sounds orthogonal in some senses
20:02 Heffalump Full name can probably come from the OS
20:03 notdan_ true
20:03 Heffalump perhaps just ignore website, doesn't really seem useful to be telling someone where their own website is
20:03 Heffalump e.g. hard-code it to blank
20:03 notdan_ 5. Need to think about _darcs/darcsden structure -- and actually implement the ability to edit metadata from the browser
20:04 Heffalump in general I would like local dev to have as little state and require as little configuration as possible
20:04 notdan_ 6. Figure out the dates (i.e. stop using the dummyDate variables)
20:04 Heffalump 5 - agreed :-)
20:04 Heffalump 6 - timestamps on the filesystem?
20:04 notdan_ Yeah that's what I was thinking
20:05 notdan_ I also thought it would be nice to have last modification date stored and displayed for repositories. Like on github or even in darcsweb
20:05 notdan_ eh actually darcsweb does not display the last modification date, but gitweb does
20:05 Heffalump I see, last modification time for the darcs repo state or for the working directory?
20:06 notdan_ Hm I need to think about it
20:06 Heffalump either way, yes it sounds useful. If you do it for the working directory try to make use of the "index" to make the scan fast.
20:06 notdan_ IMO, this change actually makes sense not just for local dev but for the hub as well
20:06 Heffalump agreed - though hub wouldn't have local changes
20:06 notdan_ yeah
20:07 notdan_ Well, this is basically it
20:08 notdan_ but if you have any features you can think of that are useful for local development, please do tell me
20:08 Heffalump ok, great. Sounds like you definitely have plenty planned. Are you happy with priorities etc, i.e. what's most important to focus on?
20:08 notdan_ I think the most important thing for now is testing
20:08 Heffalump One thing is being able to use the UI to record patches and do other things that depend on working directory changes (e.g. revert)
20:08 notdan_ the earlier I implement it the better
20:09 Heffalump agreed, that's well worth doing incrementally
20:10 alexei joined #darcs
20:11 notdan_ yeah this is pretty much what i had in mind
20:18 Heffalump ok, great. I'll have a play with what you sent and let you know if I have any comments
20:19 notdan_ thanks :)
20:35 sm joined #darcs
20:43 notdan http://darcs.net/GSoC/2015-Darcsden#first-meeting
20:44 Heffalump nice idea
20:44 Heffalump (writing notes)
20:45 Heffalump lf94: calculating patch inverses will depend on the specific patch type
20:46 Heffalump though it's generally pretty straightforward. For a single hunk change ("at line 5, replace old_lines with new_lines") the inverse is simply "at line 5, replace new_lines with old_lines"
20:46 Heffalump if you have several hunk changes in one file, the offsets need adjusting, but that can be handled by the commutation code
21:42 Meeh joined #darcs
23:53 mizu_no__ joined #darcs