Perl 6 - the future is here, just unevenly distributed

IRC log for #darcs, 2014-04-02

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

All times shown according to UTC.

Time Nick Message
00:22 favonia joined #darcs
00:24 whaletechno joined #darcs
00:39 dolio joined #darcs
01:27 edwardk joined #darcs
01:54 gh_ joined #darcs
02:50 alexsuraci_ joined #darcs
03:55 c74d joined #darcs
04:22 mizu_no_oto joined #darcs
06:03 lelit joined #darcs
06:37 gal_bolle joined #darcs
07:09 raichoo joined #darcs
07:34 schlaftier joined #darcs
08:06 raichoo joined #darcs
09:00 amgarchIn9 joined #darcs
11:00 xstill hi, when I do darcs get http://darcs.net --lazy I get darcs: darcs.hs-0: getSymbolicLinkStatus: inappropriate type (Not a directory) and get is incomplete. Any idea what can cause this problem?
11:20 Heffalump what platform?
11:21 Heffalump and does "darcs repair" repair your repository successfully? (Be warned, it'll also download all the history, negating the effect of --lazy)
11:22 xstill linux, I'll try repair, I don't mind downloading history
11:22 xstill my darcs is 2.8.0 from NixOS packages
11:29 xstill hm, I got Extra items in index!
11:29 xstill darcs
11:29 xstill Hash mismatch(es)!
11:29 xstill darcs
11:29 xstill index: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
11:29 xstill working:
11:29 xstill Bad index discarded.
11:29 xstill and darcs/ directory is empty
11:30 Heffalump is the failure repeatable?
11:31 xstill yes, I tryed it several times (not repair, just get)
11:32 xstill get without --lazy does not work either
11:32 Heffalump it works for me with 2.8.1 from Debian. I can't think what is significantly different in your case.
11:33 Heffalump Are the permissions on the folder sensible? Is it a standard filesystem like ext[2,3,4] or something slightly less common?
11:33 Heffalump perhaps run it with strace and see what it's trying to do at the point it fails
11:35 xstill I tried it in my home on ext4 and in tmp on tmpfs, same results permissions are rwx for me
11:35 xstill I'll try strace
11:37 Heffalump if this came from NixOS is it a binary someone else built or one built locally? I'm not that familiar with how the distribution works in practice though I understand the core idea behind Nix.
11:38 xstill hm, actually I can't tell that for sure, but it is probably from binary cache
11:38 xstill it is trying unlink("_darcs/prefs/prefs-new_4aa309bb0f8248f5c007e7211e443fe8") without success
11:39 xstill and then unlink("./darcs30074-new_4aa309bb0f8248f5c007e7211e443fe8")
11:39 xstill 4 times without success
11:39 xstill (it is in repository directory)
11:41 xstill just before it it unlinks _darcs/lock suscessfully
11:43 xstill oh
11:43 xstill sorry, my darcs is in fact not the distribution on
11:44 xstill it is probably binary for darcs.net I forgot in my ~/bin
11:44 xstill *from
11:49 xstill so real distribution darcs is 2.8.4 and work, so it was probably some bug which is fixed already
11:51 Heffalump hmm, ok. I can't think why it wouldn't be able to unlink them.
11:51 Heffalump But if the problem goes away with a newer version never mind.
12:01 mornfall xstill: btw. our hydra has "an" expression to build darcs darcs, but it would need to be updated, as it fails to evaluate right now (probably outdated dependencies)
12:04 mornfall xstill: the stuff is in http://hub.darcs.net/mornfall/darcs-hydra-support
12:04 mornfall if you felt like doing something about it :-)
12:04 mornfall Heffalump: would it be far-fetched to have darcsden make automatic, read-only git mirrors of everything?
12:06 mornfall the code to do so is in darcs now, afterall
12:11 mornfall oh, hm, it no longe has marksfile support?
12:11 mornfall longer*
12:11 xstill mornfall: I'll look at that expression
12:13 mornfall too bad it got dropped, without marks, keeping a mirror up to date becomes pretty expensive
12:18 mornfall (as a bonus, if you limit the validity of git<->darcs mapping to a single darcsden instance, the branch problem might become just about tractable)
12:19 xstill so is this convert --export intended only of one time conversion?
12:19 gh_ joined #darcs
12:20 mornfall xstill: the code it's been adapted from can do incremental conversion efficiently with marksfiles
12:20 mornfall xstill: convert --export as it is can still convert incrementally, but it'll pay a progressive n^2 price to do so
12:20 mornfall (every increment incurs the full conversion cost)
12:21 mornfall xstill: you can talk to gh_ about that :)
12:21 mornfall I have to run to a shop, be back in 30 or so...
12:22 xstill hm :-(, and what are these marksfiles?
12:26 xstill mornfall: why does that expression requires debian sources?
12:29 mizu_no_oto joined #darcs
12:39 gh_ mornfall, http://irclog.perlgeek.de/darcs/2014-04-02#i_8528640 interesting idea
12:58 mornfall xstill: oh, it doesn't really... it's for building in debian VMs
12:58 mornfall xstill: what you want is the ghc_* stuff
14:02 mizu_no_oto joined #darcs
14:13 gh_ mornfall, I wonder if the size of a (darcs --no-working-dir + git mirror) repo pair is smaller or equivalent to the size of a normal darcs repo. I'll test that later.
14:14 mornfall gh_: probably slightly bigger, depending on history length
14:52 dolio What's the branch problem?
15:10 schlaftier joined #darcs
15:12 mornfall dolio: it seems generally impossible to compute darcs repos from distributed git branches in a way that would make the results be valid darcs branches
15:13 mornfall dolio: it may become possible if the branches are centralised (although still likely to be pretty hard)
15:19 xstill does that mean that you cannot import git repo with branches to darcs? I mean just export master for example.
15:27 mornfall you can export master and import that to darcs
15:27 mornfall but you can't export master and another branch and expect that the two darcs repos will behave like branches
15:27 mizu_no_oto joined #darcs
15:28 mornfall Owen did some work on that, but I don't know how it all ended.
15:40 xstill I see
15:42 rdesfo joined #darcs
15:49 mizu_no_oto joined #darcs
15:58 colDrMcBeardman joined #darcs
15:58 lelit joined #darcs
16:02 xstill hm, I can't build hashed-storage from darcs repo (using ghc 7.6.3). First I got error about extra hiding ( catch ) from Prelude, which I deleted, but now I'm getting "Setup: dist/build/Storage/Hashed_o_split: does not exist"
16:04 rdesfo xstill: I'm using 7.6.3 and I'm able to build hashed-storage that is provided in the screen repo
16:07 sm xstill: maybe you need to cabal clean ?
16:10 xstill sm: yes that was it
16:10 xstill thank you
16:12 sm np
16:15 rdesfo left #darcs
16:29 mizu_no_oto joined #darcs
16:37 dolio joined #darcs
16:51 Heffalump mornfall: I'm working towards that kind of goal. Im ntsure how reachable it is right now.
17:00 mornfall Heffalump: which one?
17:06 edwardk joined #darcs
17:13 whaletechno joined #darcs
17:15 amgarchIn9 joined #darcs
17:24 Heffalump git mirroring from darcsden
17:25 Heffalump owst and I agreed we should start again on the bridge implementation. I'm somewhat inclined to go for something that doesn't use the fastconvert approach initially, and add that as an optimisation later
17:26 Heffalump re git exporting, why wouldn't two git repos with a common prefix lead to towo darcs repos with common initial patches?
17:31 sm_ joined #darcs
17:32 rieper_ joined #darcs
17:34 stepcut_ joined #darcs
17:46 gh_ hmm converting the darcs.net repo to git goes from 62 to 103 MBytes
17:49 gh_ after `git gc --aggressive` : 19 MBytes
17:49 mizu_no_oto joined #darcs
17:56 gh_ `git gc --aggressive` takes 1 minute to run on that new repo, as much as the conversion itself
18:00 gh_ wiki.darcs.net -> from 65 MBytes to 27 (git) to 14 (gc --aggressive)
18:02 carter so basically better compression and sharing?
18:03 carter mind you, i think darcs / hg both "autogc"
18:03 carter whereas git does it every once in a while later
18:04 mornfall gh_: you could tell fast-import to deltify more aggressively, I suppose
18:05 mornfall Heffalump: because git branches don't need to have all sharing in the prefix
18:05 mornfall there can be "common" patches up the fork
18:06 mornfall git doesn't care because 3-way will usually weed it out
18:06 mornfall Heffalump: what do you plan to do instead of fastconvert? write git repos directly?
18:07 mornfall for all intents and purposes, the fastconvert stream is a git repo
18:07 mornfall git just makes it quite easy to write and handles most of the complexity on import
18:08 gh_ carter, no, darcs does not autogc
18:08 gh_ carter, at some point in the past it did with hashed pristine files
18:11 amgarchIn9 joined #darcs
18:18 Heffalump mornfall: because a merge commit will sort it out later, you mean?
18:19 mornfall yes
18:19 Heffalump mornfall: was the point about fastconvert stream = git repo relating to how to implement a bridge?
18:19 mornfall yes
18:19 mornfall I don't quite see any other viable strategy for bridging...
18:19 Heffalump owst found some technical constraints in using it to do incremental conversions in both directions, because it was lacking some information that you could directly query git for
18:20 Heffalump viable in what sense, sufficiently performant, or correct?
18:20 mornfall in terms of work and correctness
18:20 Heffalump once youve defined the mapping you can just step through the commits to mirror
18:20 mornfall well yes, if you go *from* git, things become more complicated
18:20 Heffalump I don't see what's technically difficult about that
18:20 Heffalump biab, train getting home
18:20 schlaftier joined #darcs
18:22 gh_ mornfall, I only have a marginal improvement with  git fast-import --depth=8000 (100 instead of 103)
18:28 gh_ So the difference between a darcsfull repo and (darcs --no-working + optimized full git mirror) is:
18:28 gh_ * for darcs.net: +8 Mbytes (initial repo size 62)
18:29 gh_ * for wiki.darcs.net: -7 MBytes (initial repo size 65)
18:29 gh_ that's all. not bad.
18:35 Heffalump oh, also, re exporting darcs repos by default now, I wouldn't personally want to do that because the git repo wouldn't be very faithful (conflicts aren't represented properly) so I wouldn't want people to build on that
18:37 gh_ you mean the intermediate commits of the git repo can be unfaithful?
18:37 xstill why would there be conflicts when re-exporting darcs repo?
18:38 gh_ xstill, because you replay the repository in its linear order of patches, so at some point you may have conflicting patches, possibly followed by resolution patches
18:39 xstill I see
18:40 xstill and that will not work because git will mark conflicts differently?
18:40 mornfall xstill: no, it will work fine -- but you won't see the conflicts at all
18:40 mornfall xstill: you see the linear version of history
18:41 carter Heffalump: there is that hslibgit stuff johnw has
18:41 mornfall darcs repos inherently don't have an order
18:41 mornfall you have to manufacture *some* order, and it will never be accurate
18:41 carter http://hackage.haskell.org/package/gitlib
18:41 mornfall linear order
18:42 mornfall (they have a partial order, but using that for the git repo is probably a really bad idea)
18:42 carter why not map the partial order ot a partial order?
18:42 carter and handle the join points as git merges?
18:42 mornfall Heffalump: I don't think you'll get a satisfactory "faithful" conversion to git
18:43 carter mornfall: doesn't have to be faithful
18:43 mornfall considering that substantial chunk of the data you need is in the user's head
18:43 Heffalump gh_: I mean that you lose information because you can't undo the conflict (like you could on the darcs side)
18:43 mornfall (or nowhere at all, as is the case)
18:44 Heffalump mornfall: there's no canonical order, agreed, but there are mappings that don't entirely the lose the second patch in a conflict
18:44 carter Q: how does mapping to mercurial work?
18:44 gh_ Heffalump, ah sorry
18:44 carter because that might be an "easier" subproblem
18:44 mornfall you can manufacture minimal branching based on conflict resolution, but that has the potential to produce contrived histories
18:44 Heffalump if your darcs repo is ABR where A and B conflict and R resolves it, the git repo from the current code will be A(A^-1)R
18:44 Heffalump carter: mapping what?
18:45 carter HG has that whole "patch queue model"
18:45 carter as one extension
18:45 Heffalump carter: the partial order is also expensive to compute, so that's not going to work too well
18:45 mornfall carter: patch queues aren't "hg" proper
18:45 carter mornfall: well, i'm just thinking out loud :)
18:45 mornfall even if it was free, the git repository would make no sense at all
18:45 mornfall carter: patch queues are a workaround to rebase avoidance
18:46 Heffalump you could perhaps recover a "sensible" git repo using merges in just the right sequence
18:46 Heffalump s/"sensible"/linear/
18:47 carter so maybe a first step in that  would be to formalize what that means?
18:47 carter like a "sensibility metric"
18:47 mornfall it's common for a multi-person darcs repo to see a different history from each person's point of view
18:48 carter really?
18:48 mornfall yes
18:48 carter woah
18:48 carter thats ... intersting
18:48 carter because patch set commutitivyt?
18:48 Heffalump yes
18:48 Heffalump think of it like merge commits in git - there's no intrinsic ordering between the two branches that went into the merge
18:49 Heffalump so even git doesn't really have a linear history
18:49 mornfall if Anna and Bob exchange patches, Anna will see her patches before Bobs and Bob will see his patches before hers
18:49 mornfall they will have slightly different content depending on their interactions too
18:50 carter wat
18:50 mornfall the problem is that git forces you to pick one of the histories as a correct one
18:50 mornfall carter: don't worry, the end result is always the same
18:50 carter oh ok
18:50 mornfall carter: it's just the "how we got there" that isn't
18:50 Heffalump mornfall: a merge still has a non-linear history behind it
18:50 carter yeah
18:51 carter a DAG
18:51 mornfall Heffalump: yes, but unless you have an actual conflict in darcs, you won't be able to reconstruct merge points
18:51 mornfall Heffalump: we didn't have a conflict for maybe a year now :-)
18:51 Heffalump mornfall: right - but my own plan is to linearise the ordering with tags
18:52 Heffalump so you can at least reproduce the conversion by using the same set of tags
18:56 mornfall well, yes, that idea's been floated before, but we never got to a point where having many tags would be feasible
18:56 Heffalump they only need to exist in the bridge repo
18:57 mornfall a marksfile achieves the same thing IIRC
18:57 mornfall but yeah, using tags for that would probably work
18:57 Heffalump I think tags have the right semantics and are native to darcs
18:57 Heffalump and as I said above I would probably want to start with a non-fastconvert based implementation
18:58 mornfall well, I guess overall that's a „no“ to my original question then :-)
19:00 mornfall so I'll just keep hosting my own git mirrors, I can do that
19:00 IbnFirnas_ joined #darcs
19:03 xstill so the problem with darcs -> git is that you may not end up with right history, so you can't reliably go back?
19:16 mornfall xstill: darcs -> git -> darcs is an entirely new level of mess :-)
19:17 mornfall xstill: with convert --export, you end up with whatever history you currently see
19:19 mornfall I think that it's good enough for 90% of usecases, but Heffalump probably sees different usecases than I do.
19:21 xstill hm, so it can cause problem for example if you export you repo to git and then I try to do increment from my version of same repo?
19:21 mornfall xstill: darcs-fastconvert would refuse to do that
19:21 mornfall xstill: if you use incremental support
19:21 mornfall xstill: if you don't, the two repos will diverge in git pretty soon
19:22 mornfall xstill: (at a first reordering)
19:22 mornfall xstill: and never meet again
19:22 xstill mornfall: refuse based on what? The history is different?
19:22 mornfall based on the marksfile
19:22 mornfall you can't "continue" an operation if you changed the already-converted data
19:23 xstill makes sense
19:23 mornfall (marksfile is just a suspended state of the conversion, so to say)
19:23 xstill so you have to keep one "canonica" repo for converting to git
19:23 xstill *canonical
19:24 mornfall yes
19:24 mornfall if you want a mirror, that is
19:24 mornfall with even a linear mirror, it becomes possible for people to actually contribute through git
19:24 mornfall (if you only allow fast-forward on the git repo)
19:24 mornfall and that'd be good enough for me
19:24 mornfall there's no prohibition against a rebase-before-push in git
19:25 xstill ok that is better than what I tought from reading here
19:25 mornfall the problem is that I'm the only one here thinking that's good enough :-)
19:26 xstill and what do you mean by allowing only fast-forward (I'm still not so good with git)
19:26 mornfall but I'll probably implement it anyway, and maybe it'll make it into darcs in another 3-4 years ;-)
19:26 mornfall xstill: that's the default mode for push anyway, I think -- you won't be able to do push -f
19:27 xstill so you can't do that git mirror which allows contribution with convert --export?
19:27 mornfall xstill: not really, you do need marksfiles for that
19:28 mornfall xstill: because the git -> darcs path won't work otherwise
19:28 xstill I always tought that push -f is something that can terribly break someone elses repo copy
19:28 mornfall maybe, yes, dunno :-)
19:28 mornfall I use it all the time...
19:28 mornfall (you can't push and rebase and push without -f)
19:29 xstill on your nixpgks right? It happend to me that I was not able to pull it
19:29 mornfall and since I only know what "git merge" will do in only very limited number of circumstances, I rather rebase everything
19:29 mornfall xstill: yes, you need to do git fetch && git rebase instead of git fetch && git merge (which is what pull means)
19:29 mornfall xstill: but other than that, it mostly works
19:30 xstill yeah, I started using git pull --rebase for my git repos
19:30 xstill I don't like merge commits
19:30 xstill probably because I used darcs before git
19:30 mornfall possibly
19:31 mornfall but I think most git users prefer to ignore merges if possible
19:31 mornfall github makes lots of them automatically, but you pretend they don't exist most of the time
19:32 mornfall the main advantage of git is that the plumbing is pretty indestructible
19:33 mornfall you lose working copy all the time, but .git usually stays in reasonable shape
19:33 mornfall unless you have a tendency to use reset --hard
19:33 mornfall ;-)
19:33 mornfall (or some other dangerous commands :P)
19:34 xstill reset --hard can destroy your .git?
19:35 mornfall haha, https://twitter.com/ferblape/status/448813238638358528/photo/1/large
19:35 mornfall xstill: well, it can detach some of your commits
19:35 mornfall xstill: which may prove hard to find in the resulting mess
19:37 mornfall (well, if I had unlimited time, I'd re-do darcs... but I don't, so I -- most likely -- won't...)
19:38 xstill re-do why?
19:49 mornfall there's plenty of problem in the existing one
19:49 mornfall problems*
19:54 xstill finally I have compiled darcs darcs
19:55 xstill is it safe for regular use?
19:57 xstill btw. why is last release darcs 2.8.4 and current dev 2.9.8, was there no 2.9.* release?
19:58 mizu_no_oto joined #darcs
19:59 mornfall 2.9 is unstable IIRC
19:59 mornfall (quirky pre-3.0 linux-style system)
20:01 xstill like odd versions being unstable?
20:01 mornfall yeah
20:11 sm xstill: it's usually fine to use darcs HEAD for regular use. Currently there is some kind of caching issue that causes a lot of commands to fail when compiled with ghc 7.8, but it's not dangerous
20:12 xstill ok, I'm compiling with 7.6.3 anyway
20:50 gh_ mornfall, I also think it would be good enough to have a git mirror for fast-forward repos. I guess  if we say it's experimental nobody should complain :)
20:51 gh_ it could make a nice proposal for next year's gsoc
20:51 gh_ will owen be still a student? :-)
20:52 nomeata joined #darcs
20:54 alegadea joined #darcs
21:22 n-dolio sm: By the way, 'darcs get --no-working-directory' shows the same complaint on whatsnew as get with the cache funkiness. Is that expected behavior?
21:22 n-dolio This happens even when compiled with 7.6.3.
21:24 schlaftier joined #darcs
21:25 nuun joined #darcs
21:27 mizu_no_oto joined #darcs
21:40 mornfall gh_: I don't really feel like forking darcsden, but other than that, I'd be up to it :)
21:40 mornfall (not as gsoc, as I'm growing too old for that)
21:41 mornfall the catch is that not being able to have that feature on hub.darcs.net makes it more or less useless
21:42 mornfall I can do it with a little perl scripting on my own server with a lot less effort
21:49 mizu_no_oto joined #darcs
21:50 gh_ perl…
21:50 mornfall :-)
21:56 mizu_no_oto joined #darcs
22:20 mdiaz joined #darcs
23:03 nuun left #darcs
23:04 mizu_no_oto joined #darcs
23:26 edwardk joined #darcs
23:36 edwardk joined #darcs

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