IRC log for #darcs, 2010-02-08

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?%4[…]d-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[…]l&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/pac[…]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/piperm[…]nuary/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

← Previous day | Channels | #darcs index | Today | Next day → | Search | Google Search | Plain-Text | plain, newest first | summary