Camelia, the Perl 6 bug

IRC log for #darcs, 2010-02-08

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

All times shown according to UTC.

Time Nick Message
01:23 twb joined #darcs
01:29 lisppaste2 joined #darcs
05:30 sshc joined #darcs
07:14 balor joined #darcs
08:02 darcscommitbot joined #darcs
08:03 darcswikibot joined #darcs
08:11 gh_ joined #darcs
08:12 lelit joined #darcs
09:55 gh_ joined #darcs
10:05 gal_bolle joined #darcs
11:27 kowey joined #darcs
12:29 gal_bolle hi all
12:29 Heffalump hiya
12:30 gal_bolle hi Heffalump, regarding witnesses in Changes.lhs, I think seals are the right thing to do, since there's no point for witnesses
12:30 Heffalump yes, I agree with that
12:30 Heffalump (I thought I said so :-)
12:35 gal_bolle as for the second witness of  PatchSet, this is the only way to make using get_common_and_uncommon in Changes legitimate
12:37 Heffalump hmm, couldn't thatbe made to take the RL type directly?
12:38 gal_bolle yes it could
12:38 gal_bolle it seemed to me that making PatchSet an alias for RL (RL) and having explicitly PatchSet Origin was clearer
12:38 gal_bolle but i may be wrong
12:39 Heffalump I think it's the tags invariant that bothers me most about it
12:39 gal_bolle in particular, it makes it explicit that when a RL RL is called a PatchSet, its tags are clean
12:39 gal_bolle yes, it should be enforced somehow
12:39 Heffalump I guess the existence of witnesses means you can't actually stick a partial PatchSet together with something else and end up with unclean tags
12:40 Heffalump because by definition the C(Origin foo) thing that you added to PatchSet(foo x) would be exactly what the tags in the PatchSet neeeded.
12:40 gal_bolle yes, but it would be good to eventually make PatchSet a newtype so that it does not happen
12:40 Heffalump ok, I guess I'm happy with it then.
12:41 Heffalump are you able to easily sort out the conflict?
12:41 gal_bolle i haven't looked at it yet
12:41 Heffalump ok. Let me know and I'll push whichever version you want.
12:41 gal_bolle ok
12:46 gal_bolle I don't seem to get a conflict
12:47 gal_bolle do you have an idea what patch it's conflicting with?
12:51 Heffalump there's a conflictor in the actual patch file you submitted
12:51 gal_bolle ah ok
12:51 Heffalump I think it's to do with the addition of Sealed2 to theimport from Sealed in Ordered
12:52 gal_bolle yes, the filterFL patch is older, so that's where it must have come from
12:56 gal_bolle ok, goto seminar, then i'll send an amended version
13:11 kpreid_ joined #darcs
14:24 intripoon joined #darcs
14:32 kowey sigh, stupid pending patch
14:48 kowey gh_: can you reproduce issue1739 in tcsh?
14:48 gh_ no, I suspect it depends on the settings of my terminal
14:48 gh_ which is gnome-terminal
14:48 kowey meanwhile, I'm puzzling over a rather alarming case where my pending patch is empty, but darcs swears up and down that I've removed a directory
14:49 kowey hope it's not index-related :-(
14:49 gh_ I omitted to mention that  "darcs: Char.intToDigit: not a digit 513" is suddenly written in red
14:49 kowey oh dear, deleting the index makes this go away
14:54 kpreid_ joined #darcs
15:21 lispy joined #darcs
15:22 lispy1 joined #darcs
15:22 lispy1 joined #darcs
15:30 mdmkolbe joined #darcs
15:39 kowey hey, I can reproduce gh_'s problem
15:40 kowey under gnome-terminal/bash doing darcs changes --match "author nomeata"
16:02 mornfall kowey: Have you stored the index, and written down the circumstances?
16:02 mornfall (Why things like these never happen to me?)
16:03 kowey mornfall: I have stored the index (I think), and I've been trying to reproduce this (before I got distracted)
16:04 kowey the *rough* story is that I renamed a dir (mv d1 d2) and its contents (cd d2; mv foo.x foo.y) only to realise later on that I need to darcs mv it
16:04 kowey and somehow, through some combination of mv, darcs mv, and editing the pending patch (ie. giving up and trying to start from fresh by getting rid of unwanted changes), I got into a state where darcs still thinks I removed the stuff
16:04 kowey even when it's still there
16:05 mornfall I am quite sure editing the pending patch is not supported.
16:05 kowey [and then when trying to reproduce it, I stumbled upon issue1740, which seems unrelated]
16:05 kpreid_ joined #darcs
16:05 mornfall Also, after editing it, you have to touch _darcs/index_invalid *at least*.
16:06 mornfall Darcs has logic to do things to index whenever it touches the pending patch.
16:06 kowey oh
16:06 kowey well I think that's simple enough then
16:06 mornfall Yes, likely.
16:06 kowey we still informally advise people to edit the pending patch (while saying you're technically not supposed to)
16:06 mornfall Do we?
16:07 kowey only nowadays with the index, you should really really really try not to do that
16:07 kowey or IRC, at least :-/
16:07 mornfall What happened was, anyway, that you had a pending patch removing a directory, which was reflected in the index, then you removed the pending but didn't tell darcs to fix up its index because pending has changed.
16:08 mornfall You can tell people to rm _darcs/index if they mess with pending (or pristine, for that matter, but that's even more likely to get them in trouble than editing pending).
16:09 kowey OK, so the index isn't literally the working dir, but of the "pending" changes as represented by the combination of pending+working?
16:10 kowey I really don't like that we tell people to edit the pending patch, but sometimes it feels like we have no choice :-(
16:10 kowey ...but I think we can limp along with "edit the pending patch, and don't forget to delete the index"
16:10 mornfall Well, if you have "mv" patches pending, this obviously has to be reflected in index, since it is reflected in the working copy.
16:12 kowey and likewise with addfile...
16:12 mornfall Yes.
16:13 kowey here's why we still sometimes tell people to edit [most likely delete] the pending patch: http://bugs.darcs.net/issue?%40search_text=&am​p;title=&%40columns=title&topic=28&amp​;id=&%40columns=id&creation=&creat​or=&activity=&%40columns=activity&​%40sort=activity&actor=&nosy=&prio​rity=&%40group=priority&status=-1%2C1%​2C2%2C3%2C4%2C5%2C6%2C16%2C17&%40columns=s​tatus&assignedto=&%40columns=assignedt​o&%40pagesize=50&%40startwith=0&%4​0queryname=&%40old-queryname=&%40a
16:13 kowey ction=search
16:15 Heffalump can't the index store the timestamp of pending?
16:15 Heffalump That would provide robustness.
16:16 mornfall Index doesn't know anything about pending.
16:16 mornfall I mean, not in itself. Darcs knows how to construct the Tree that correctly reflects pending.
16:17 mornfall We could change the index_invalid mechanism to something else, maintaining validity data in a file (e.g. also keeping pending timestamp).
16:23 lispy1 Good morning
16:23 lispy1 kowey: looks like the fund raising is going really well this time
16:23 kowey and now for some random entertainment - http://www.google.com/trends?q=darcs%2C+bzr&a​mp;ctab=0&geo=all&date=all&sort=0
16:24 kowey only $695 to go!
16:24 kowey ...in a week
16:26 mornfall Denmark is skewing the bzr results. : - )
16:27 lispy What gets stored in the index?
16:27 lispy It's an index of the working dir?
16:27 kowey http://bzr.dk/ may be why
16:28 lispy kowey: that long bug link you pasted didn't come through correctly, I think.  It looks like it spanned two posts
16:28 lispy kowey: tinyurl might be appropriate here
16:28 mornfall lispy: http://hackage.haskell.org/packages/archive/hashed​-storage/0.4.6/doc/html/Storage-Hashed-Index.html
16:28 kowey oh :-(, that would be a search for the 'ThePendingPatch' topic in the tracker
16:28 lispy mornfall: is that darcs specific?
16:29 mornfall No?
16:29 kowey or rather http://is.gd/7WOq4
16:29 lispy mornfall: :(
16:29 mornfall lispy: ?
16:29 lispy mornfall: the docs you linked, are they darcs specific?  It seems to be part of the general hashed-storage documentation
16:29 mornfall lispy: No, they are not darcs specific. Why?
16:30 mornfall There isn't much darcs-specific about the index.
16:30 lispy mornfall: I would like to know what darcs puts in its index
16:30 mornfall Well, could you maybe read the docs first?
16:30 kowey lispy: I think mornfall is saying that "darcs" does not put anything in the index
16:30 kowey and that the index can be seen as purely a by-product of our using hashed-storage
16:30 lispy So darcs doesn't use an index?
16:31 mornfall *sigh*
16:31 * kowey hopes he didn't just add noise to this
16:31 mornfall Please, read the documentation.
16:31 kowey it's quite short
16:31 mornfall If something is not clear then, ask.
16:33 lispy That talks about trees and working directories?  Do I assume they are the same?
16:33 mornfall Tree is a data structure.
16:33 lispy And what does darcs store in that?  Does it store _pristine?  my working dir?  working dirs that related to tags?
16:34 mornfall The working copy.
16:35 mornfall (That's the Tree that is used to build the index, anyway -- restricted appropriately. Trees are also used to store pristine, and to do in-memory patch application.)
16:37 lispy I guess I'm not familiar with the terminology.  A working copy == ?
16:38 mornfall Well, the working copy is stuff outside _darcs.
16:38 kowey to be fair, it's possible we need to be more precise in our language, especially since we have this pending patch floating around in there
16:38 mornfall Or, if you prefer, the unrecorded state.
16:38 lispy working copy == darcs's working dir?
16:39 lispy The unrecorded state would include pending, so pending is in the index?
16:39 mornfall (bassoon... bbl)
16:41 lispy So I guess there is a Tree for the working dir and a Tree for working + pending?
16:41 lispy Is that what you mean by "in-memory patch application"?
16:42 kowey it does sound like talking about the index as reflecting the unrecorded state is more accurate than talking about it reflecting working [but I'm not following closely enough]
16:42 kowey and also, it sounds like it doesn't /really/ make sense to talk about working + pending
16:42 kowey since working in a sense is a superset of pending
16:43 * kowey may be saying silly things
16:43 lispy That's not true
16:43 kowey oh
16:43 lispy I think you have it backwards
16:43 kowey I was just thinking that you could have files in the working directory that you have not 'darcs added'
16:43 lispy Pending exists because not all unrecorded changes can be inferred from the set of files/directories in the repository
16:44 kowey by diff alone
16:44 lispy I think of the set of files/directories in the repository as 'darcs's working dir'
16:44 lispy When you add Pending to that, you get the unrecorded state
16:44 kowey I think I do too
16:44 kowey hmm, OK
16:45 lispy And Pending is one of these easy to forget about things due to uncommon casses
16:45 kowey so let's contrast these two ways of looking at this; I'm clearly not the expert here!
16:46 kowey my conceptualisation of this was something like: pristine, pending, unrecorded, working
16:46 kowey each of these being successively supersets of each other (in some fluffy sense)
16:46 lispy I agree that at least that many states exist :)
16:47 kowey the idea being that we use the pending patch to store things that you couldn't possibly infer just by doing a diff on working and pristine alone
16:47 lispy I think super/sub set relations will fail for subtle reasons, but as long as you realize that it may be an "OK" analogy
16:47 kowey I think I do realise like, hence my use of fluffy
16:47 kowey in the sense that patches cancel, so it's kinda hard to talk in terms of sets
16:48 kowey but in any case, I tend to see those as being a sort of succession -- and that unrecorded == working if you do darcs --look-for-adds
16:48 lispy I'm not sure I agree with the order of pending, unrecorded, working, either.  This ordering you're after haunted me before and I couldn't resolve it satisfactorily
16:49 kowey Right, so what you're telling me is that I have this backwards...
16:49 kowey in your conceptualisation of this we still have that many states, but... (this is where you fill in)
16:50 lispy What I recall is that I had some vague feeling that pending / working interleave instead of following perfectly in order
16:50 lispy I forget the example now
16:50 lispy I want to say it was related to add/removing files and having their contents
16:51 lispy Pending doesn't store hunks...and possibly that's merely an implementation detail
16:51 lispy Although, from what Petr is saying maybe the index does store the hunks of Pending
16:51 lispy (effectively)
16:52 kowey I think my conceptualisation of this is that pending + a diff between pristine/working gets you unrecorded
16:52 lispy I agree
16:53 kowey and that this diff is limited by things such as what things you tell darcs to do record on
16:53 kowey so if you darcs record foo, then unrecorded only includes the diffs between pristine/working foo, but not bar
16:53 lispy The scope can be narrowed?  (I agree, but I fail to see the relevance)
16:53 kowey just that working always includes everything (in my conceptualisation)
16:54 kowey whereas unrecorded does not
16:54 kowey which is to say that to me, working literally is just your files and directories
16:54 lispy Right, so going from unrecorded -> recorded, you can pick a subset of your changes
16:55 kowey shall we consider the case of darcs replace?
16:55 lispy I guess replace patches go into pending?
16:55 lispy I've never tried and looked
16:55 kowey because I think this may reveal why we conceptualise this differently
16:56 kowey replace patches do go in pending
16:56 lispy oh dear
16:56 kowey which may be why you tend to think of pending / working as being interleaved
16:56 lispy $ darcs init
16:56 lispy darcs: error while loading shared libraries: libicuuc.so.38: cannot open shared object file: No such file or directory
16:57 mornfall Pending does not change working. Pending is reflected in working.
16:57 kowey but this doesn't really bother me... if you do darcs replace foo bar - the fact that the working dir only contains "bar"
16:57 kowey fits into the recorded -> pending -> unrecorded -> working model quite happily
16:57 mornfall When you do a darcs replace, the working copy will get the token replaced and darcs will note down that this was due to a replace patch, and stores it in pending.
16:57 mornfall So it knows, when it diffs, that those should not be hunk patches but replace patches.
16:58 mornfall Likewise with mv: it notes that this is not a rm+add but a mv.
16:58 lispy Well shoot, I have libicu38 installed
16:58 kowey so I think me and mornfall are looking at it in the same way
16:58 gbeshers joined #darcs
16:59 kowey lispy: could it be some kind of LD_LOAD_WHATEVER?
16:59 mornfall Working already contains all the changes that are noted in pending.
16:59 lispy kowey: I doubt it, I haven't changed my env
16:59 mornfall There's always an implicit treatment of the change, that is overriden by pending:
16:59 mornfall - addfile: ignored by default, pending makes it not-ignored
17:00 mornfall - mv: rm+add
17:00 mornfall - replace: hunks
17:00 Heffalump so why does the index get affected by pending?
17:00 mornfall (With "ignored by default" I mean that the files exist in working, and therefore diff would produce them if it knew about their existence...)
17:00 lispy I did upgrade some packages recently
17:01 lispy I think I'll  have to rebuild darcs :(
17:01 lispy My libicuuc went from 3.8 to 4.0
17:01 mornfall Heffalump: It is an optimisation (there are more instances of the same in darcs elsewhere) -- we, by default, ignore files that don't exist in "recorded+pending".
17:01 Heffalump i.e. the index doesn't list them?
17:02 mornfall Heffalump: Right.
17:02 mornfall --look-for-adds has always been sort of a special case, where we turn off that optimisation and look at all (nonboring) working files.
17:03 * lispy should get back to work work
17:04 mornfall It could be argued that look for adds should be default and people should be encouraged to keep boring up to date... (maybe by saying "darcs boring path/to/file").
17:04 mornfall Which would sort of obviate the need to keep addfiles in pending at all.
17:05 kowey is boringness really the reason we don't use --look-for-adds all the time?
17:05 mornfall (I.e. the action would be other way around: instead of stating what you want you state what you don't want...)
17:05 mornfall kowey: More or less. :)
17:05 kowey I thought there was something more immediate...
17:05 kowey oh, ok!
17:05 mornfall kowey: The optimisation can be done with boring as well as with pristine. No problem really.
17:05 lispy Just a general FYI people:  At least on Ubuntu Jaunty -> Karmic, the libicu versions change enough that it will break your darcs until you recompile.
17:05 kowey oh, thanks! I was meaning to upgrade sometime
17:07 * lispy now builds the latest HEAD
17:07 kowey I think I thought it was just an issue of "I don't want darcs to nag me to add a bunch of files I don't want to deal with [yet]"
17:07 mornfall Yes, when you do a major-version library upgrade, you are expected to rebuild things. Either that, or keep around the old previous major (which is facilitated by the soname mechanism on ELF-based systems...)
17:07 kowey ...which aren't really boring either
17:07 kowey but then maybe that's why I keep having to record "oops, I forgot to add Foo" patches
17:07 mornfall kowey: You could make the same argument for edits. The result is git's model, where you have to add each change.
17:08 lispy arch had the issue of requiring all files to be either added or explicitly ignored (before you could even record) and it was a terribly UI decision :)
17:08 mornfall lispy: Sure. But we have interactive record.
17:09 kowey which was so compelling that basically every other DVCS user is fixated on this when they talk about darcs
17:09 lispy Hmm...darcs head doesn't require hashed-storage-0.4.6?
17:09 kowey as in, "I used to use darcs, but now that git has add -p, I'm super-duper happy"
17:10 mornfall Whatever floats their boat. :)
17:10 kowey :-)
17:10 * kowey still has to write down the arguments for why staging is actually handier than just amend-recording sometime
17:11 lispy Yeah, having directories full of clones of darcs repos is kind of annoying at times
17:11 lispy For project foo, you endup having a foo top level and inside it you have the individual darcs repos
17:12 lispy Eg., you're manually staging
17:13 kowey this is what I was referring to http://lists.osuosl.org/pipermail/d​arcs-users/2010-January/022724.html <-- past-Eric told me to write these down somewhere
17:17 mornfall kowey: Btw. I do think that flipping the default to be look-for-adds would make things simpler, if we can do it in a way that wouldn't compromise performance.
17:18 kowey I don't have an opinion
17:19 * lispy suspects that proposing that would cause a lot of "zOMGs" in the audience and would prefer to keep the current defaults.
17:19 kowey as long as the end result still has that sort of happy darcs simplicity (slightly ineffable quality) or amplifies it from a UI point of view, I think I'm ultimately happy
17:19 kowey well, sometimes you don't listen to your users (but you watch them like a hawk)
17:19 lispy and swoop down and pounce on them?
17:19 lispy :)
17:19 kowey I mean this in the most respectful way, of course
17:19 kowey in the sense that as a user, it's not always easy to know what you want
17:20 lispy Yeah, I can think of plenty of anecdotal cases where you want either default more than the other
17:20 kowey certainly not a case of we-developers-know-better, just... tricky... delicate...
17:20 lispy Now that we do it one way, people (and scripts) would possibly need to adapt to the other way?
17:20 mornfall Well, I don't have an opinion strong enough to go and suggest this change. I've joust thought to voice it here.
17:20 mornfall just*
17:21 lispy (but I admit, I don't follow why the switch is good)
17:21 mornfall (That's what happens when you think of the word after the one you are currently typing...)
17:23 kowey http://wiki.darcs.net/DifferencesFromGit <-- there, written down
17:23 kpreid_ joined #darcs
17:26 gal_bolle left #darcs
17:38 balor joined #darcs
17:58 kpreid_ joined #darcs
18:25 arjanb joined #darcs
19:16 kpreid_ joined #darcs
19:36 gwern joined #darcs
19:36 gwern joined #darcs
19:54 gwern joined #darcs
19:54 gwern joined #darcs
21:19 kowey joined #darcs
22:05 balor joined #darcs
22:06 nomeata joined #darcs
22:07 kpreid_ joined #darcs
22:10 intripoon joined #darcs
22:27 kpreid_ joined #darcs
23:02 mdmkolbe left #darcs

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