Camelia, the Perl 6 bug

IRC log for #darcs, 2011-05-01

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

All times shown according to UTC.

Time Nick Message
00:13 raichoo joined #darcs
00:25 raichoo left #darcs
01:04 navaati left #darcs
01:29 gwern left #darcs
01:40 aculich_ left #darcs
01:44 aculich joined #darcs
01:45 gwern joined #darcs
02:17 owst left #darcs
02:28 intripoon joined #darcs
02:31 intripoon_ left #darcs
03:28 gwern left #darcs
03:29 gwern joined #darcs
03:29 gwern left #darcs
03:29 gwern joined #darcs
04:13 sm left #darcs
04:16 gwern left #darcs
04:28 lispy joined #darcs
04:29 gwern joined #darcs
04:29 gwern left #darcs
04:29 gwern joined #darcs
06:41 copumpkin is now known as danp_
06:41 danp_ is now known as bambam
06:46 jderque joined #darcs
06:48 bambam is now known as copumpkin
07:13 jderque left #darcs
08:11 kolmodin joined #darcs
08:11 kolmodin left #darcs
08:11 kolmodin joined #darcs
08:12 raichoo joined #darcs
08:48 balor_ joined #darcs
08:48 balor__ left #darcs
08:55 Heffalump mornfall: I'm still trying to absorb your Prim v3 proposals completely, but my general feeling is that perhaps you're overabstracting prematurely
08:56 Heffalump at least in some areas
08:56 mornfall Could be. Which these would be, though?
08:57 Heffalump why is everything an abstract object?
08:57 mornfall Well, I don't know what else to make of them.
08:57 Heffalump well, I would have files and directories as we do now :-)
08:57 mornfall (Do you mean the "files" don't you?)
08:58 Heffalump the statement "all patches operate on abstract objects" seems a bit broad.
08:58 Heffalump and adding ", identified by UUIDs" then seems a bit limiting in some sense, though perhaps it isn't.
08:59 mornfall Well, with abstract I mean that there's no prescribed representation for objects per-se.
08:59 mornfall Even though each object will have *some* representation.
09:00 mornfall But they are prescribed to have an UUID attached.
09:00 mornfall (So darcs will track "things" with UUIDs on them, where most "things" would be text files...)
09:02 mornfall You can take "object" to mean "any of a text file, binary file, directory" at least until someone comes up with more object types (see adding new patch/object types too)...
09:02 balor_ left #darcs
09:02 balor_ joined #darcs
09:03 Heffalump but you also have to address within the objects, so it doesn't fully specify what the patch acts on
09:04 mornfall True, but that depends on object type anyway.
09:04 mornfall Different objects are addressed differently.
09:04 mornfall (Inside that is. On the outside, it is uniform.)
09:04 Heffalump I'm just not sure why it's essential that you have to have a layer of objects prescribed for every patch.
09:04 Heffalump does it buy us something in ease of use or efficiency?
09:06 mornfall Hard call. I would say it buys us consistency.
09:06 Heffalump the way I see it, it's nice to have filesystem objects have UUIDs. Some mythical future objects might have no need for it.
09:07 mornfall You realize you are actually making things more abstract not less? :)
09:07 mornfall Anyway, if we come up with an example of something where UUIDs get in the way, I will consider that.
09:07 mornfall But I think it's a good idea to impose them on everything.
09:08 mornfall The only thing that breaks down are prims that touch every object, eg. But I can't imagine an use for that.
09:09 mornfall (The type constraints don't allow that either...)
09:09 Heffalump I think prims that touch every object would actually touch the root object recursively
09:10 mornfall Well, changes in a file does not imply a change in the directory holding it (UUIDs are not hashes).
09:10 mornfall Although you maybe mean something else yet.
09:10 mornfall ?
09:11 Heffalump no, I just mean that if you want to change every object, you should actually do a recursive traversal from the root object instead. That way if you rename that later the scope of your patch follows it.
09:11 Heffalump why do preferences need a UUID?
09:12 mornfall They don't really "need" it -- files don't "need" UUIDs either.
09:12 Heffalump no, but we have a concrete benefit from files getting UUIDs
09:12 Heffalump is there one for prefs?
09:13 mornfall Hard call. You do have an add-add conflict for prefs too, if they are really just files (even if they don't have traditional working copies).
09:14 mornfall (I don't plan setpref patches, just normal hunks for prefs.)
09:14 Heffalump I don't see how the add-add conflict matters - that's a real conflict, because prefs are global
09:14 Heffalump unless you have a plan to scope them somehow, which might be plausible
09:14 Heffalump oh, well I guess what I call "semi-conflicts" might still make sense for prefs
09:15 mornfall What would semi-conflict be?
09:15 * Heffalump thinks a bit (also trying to persuade toddler to get dressed, so not concentrating fully anyway..)
09:15 Heffalump I described it in the AddAddConflicts wiki page
09:15 * mornfall looks
09:18 mornfall Ok, so semi-conflict is not a conflict but a violation of constraint on objects, AIUI. (Each name in a directory can be only mapped to a single UUID).
09:19 mornfall Well, it can also be casted out as a normal conflict I guess, between the manifest patches.
09:19 Heffalump well, I view it as a more general concept - a conflict is a fundamental disagreement between patches resolved by a merger/conflictor/whatever.
09:19 Heffalump A semi-conflict is one that can be resolved by other means.
09:21 mornfall So basically you don't enforce the constraints on objects, but when they are violated you flag the working copy. Further patches will depend only whatever they change, like they normally do, and not on both the patches that caused the inconsistency. Is that right?
09:21 mornfall depend on*
09:22 Heffalump yep
09:22 mornfall (And an example of object constraint is that every filename is only mapped once in a directory.)
09:24 mornfall Back to prefs, if you remove the UUIDs from those, you can't use hunk patches on them, which is what I want to do -- prefs are not a distinct object type, they are just "text" objects. But they are referenced in the repo by UUID and not part of the working hierarchy.
09:27 Heffalump not entirely convinced they should have hunk patches :-) But anyway, hunk patches don't need to directly reference UUIDs.
09:27 mornfall What would hunk patches reference then?
09:28 Heffalump I'd quite like to see things in layers, cleaning up the existing FilePatchType / DirPatchType stuff
09:28 mornfall If they use filenames, you lose half the advantages of having the UUID in the first place.
09:28 Heffalump you'd have something like FilePatch Object FilePatchType
09:29 Heffalump or, FilePatch UUID FilePatchType and PrefPatch UUID FilePatchType
09:29 mornfall I don't see the advantage of making PrefPatch special...
09:29 lispy left #darcs
09:30 mornfall The core doesn't need to know anything at all about preferences.
09:30 mornfall Since the upper layers can simply implement them in terms of files.
09:30 mornfall And since files don't need to be manifest in the working copy anymore, you avoid the namespace conflict.
09:31 mornfall (I.e. this is more or less equivalent to using addfile _darcs/prefs/foo and hunk _darcs/prefs/foo with current state of the matters; which would of course be way ugly...)
09:35 Heffalump I'm still not sure I see why prefs being hunk patches is right.
09:35 Heffalump isn't that going away from having semantic patches?
09:35 mornfall Not at all. We just don't have capacity to provide semantic patches for such a low-priority thing as preferences, IMHO.
09:36 mornfall And they are adequately served by hunk patches.
09:36 mornfall You can see for yourself how the setpref "semantic" patches turned out: fully neglected.
09:36 mornfall I would argue that changelog patches are much more important.
09:37 mornfall And for the couple of prefs that behave like sets, you can have set patches.
09:37 mornfall (And since prefs are plain objects, you can really use whatever object type that is appropriate for them.)
09:38 mornfall For some it'll be text, for others set, I guess. You could have a special "authorspellings" object type if it did any good (although set will probably work reasonably enough).
09:40 mornfall But things like boring are files, and the prefs system works around that by not manipulating them directly but letting you pick a filename which is then managed using hunks anyway.
09:43 Heffalump so if we think prefs patches should have some kind of special behaviour in future, then designing for that now makes sense
09:44 Heffalump they're not really neglected, just broken. We just can't change anything.
09:46 mornfall They could be made less broken by fixing their commute function.
09:46 mornfall Adding conflict marking.
09:46 mornfall Etc.
09:46 mornfall But it's a lot of extra work I guess.
09:46 Heffalump right, but we can't fix their commute function
09:46 Heffalump at least not in v1/v2
09:46 mornfall We can.
09:46 mornfall It's not going to break things any more than they already are.
09:47 mornfall Old darcsen are going to pick random winner anyway.
09:47 Heffalump it would, it could make inconsistent repos
09:47 Heffalump oh, true
09:48 mornfall They always did.
09:49 mornfall I am just trying to say that hunk patches already have everything that you need to add to the setprefs to make them reasonably useful. So it makes sense to reuse.
09:49 mornfall They may not be completely ideal, but since we aren't painting ourselves into a corner anymore by using hunks for prefs with V3, I'd say what the hell.
09:50 mornfall I mean, by using whatever non-pref patches we have.
09:51 mornfall You could use changelog patches for maintaining a specifc preference, if that's what makes most sense.
09:51 Heffalump that's probably ok, it's the use of UUIDs that seems wrong.
09:51 mornfall If you want a scalar object, you can have that.
09:51 mornfall (Which is what setprefs are now, just incomplete.)
09:52 mornfall Do you mean that a specific preference should have the same ID in all repos everywhere?
09:53 Heffalump yes (and I think it probably shouldn't live in the UUID namespace)
09:53 mornfall So you want the object IDs to be of two kinds, UUID and Hardcoded.
09:54 Heffalump or implicit, perhaps
09:54 Heffalump that's why I was thinking of PrefPatch above
09:54 mornfall Implicit?
09:55 mornfall But we will have a few different prefs, which need different IDs.
09:56 Heffalump PrefPatch PrefPatchName (=String) HunkPatch
09:56 mornfall Well, Hunk ID ..., where data ID = UUID ByteString | Pref String would work as well.
09:57 Heffalump this comes back to my argument about layers
09:57 Heffalump I would rather each layer be as independent as possible. It would be good if we could prove properties about FilePatchType independently of the rest of the repo structure.
09:58 mornfall Well, I would rather split up the patch types using the object types they operate on.
09:59 mornfall (Since the commute rules respect types, in the proposal.)
09:59 Heffalump I don't think those are mutually exclusive - we have the Haskell type system
09:59 Heffalump I'd like to be able to write instance Commute FilePatchType
09:59 mornfall But what *is* a FilePatchType?
10:00 jderque joined #darcs
10:01 mornfall Would it just contain the "binary -> binary" and "text -> text" patches, and maybe the conversions?
10:01 Heffalump I think it would actually be TextPatchType and BinaryPatchType as separate types
10:01 mornfall In that case we are in agreement. :)
10:01 Heffalump so Hunk | TokReplace
10:02 Heffalump if you are also happy for the ID to be specified at a layer above, yes
10:02 mornfall I will have to ponder about IDs yet.
10:02 mornfall Where I wrote UUID I really meant ID.
10:02 Heffalump I don't want Hunk ID OldText NewText or whatever, I want TextPatch ID TextPatchType
10:02 mornfall Whether they are universally unique or not is a separate matter to ponder.
10:03 mornfall Oh, that.
10:03 mornfall Well, that breaks down once you try to define hunk move.
10:03 mornfall Which operates on two IDs.
10:03 mornfall But is still a TextPatchType.
10:06 mornfall So while I acknowledge that having a type that only works with "an" object without specifying it may be worthwhile, we do have patches that need more than one object to operate on.
10:06 mornfall And if you want prove things about text -> text patches, you definitely shuold include hunk move in that.
10:08 mornfall You can always put in A and B for the IDs for reasoning purposes.
10:09 mornfall (You can probably define data ID = UUID ByteString | ... | ID_A | ID_B | ID_C and use the last 3 for QC/HUnit tests as needed...)
10:10 mornfall Or idA = UUID "000000000...0A", idB = "0000...0B" etc.
10:10 mornfall +UUID
10:10 mornfall Shouldn't hurt too much.
10:20 Heffalump no, I don't think it's a TextPatchType
10:21 Heffalump I think it has to live a bit higher up, or you have to decompose it into Cut and Paste (and then it still lives high enough up to reference a clipbord)
10:21 Heffalump (I'm only very intermittently around now)
10:28 owst joined #darcs
10:28 mornfall Can't decompose it, since commute of the Cut would have to change the Paste somewhere else.
10:28 mornfall Hm. Clipboard.
10:28 Heffalump or you have to make up clipboard names
10:29 Heffalump (UUIDs again, though that seems excessive!)
10:29 mornfall But I still don't understand how the three-piece hunk move commutes.
10:29 Heffalump my three-piece?
10:29 Heffalump s/my /
10:29 mornfall Either the clipboard has everything and then cut/paste are redundant, or it doesn't and then it can't be commuted correctly.
10:29 mornfall Or clipboard is not a patch?
10:30 mornfall Either way, I think that allowing Cut to commute independently of Paste is extremely dangerous, since it needs non-local commute effect, whether mediated by a magic clipboard or not.
10:31 mornfall And excessive layering can be a real drag, too.
10:33 bsrk2 joined #darcs
10:40 Heffalump hi bsrk2
10:40 Heffalump sorry I haven't responded to your emails yet, been a bit busy
10:40 Heffalump mornfall: I don't propose users should have that, but it might be a useful internal abstraction
10:45 bsrk2 left #darcs
10:45 Heffalump mornfall: deriving the commute rules for hunk move is a nightmare without the cut/paste split, anyway
10:46 Heffalump clipboard isn't a patch itself, the patch is "cut text to clipboard X" and (the inverse) "paste text from clipboard X"
11:03 mornfall Well, as long as it only exists during commute, I don't oppose.
11:03 mornfall But I don't think that atomicity of named patch commute should be required for correctness.
11:17 zbeasnyy left #darcs
11:45 bsrk2 joined #darcs
11:59 ManateeLazyCat joined #darcs
12:01 bsrk2 left #darcs
12:08 Jaak left #darcs
12:33 balor_ left #darcs
12:43 balor_ joined #darcs
12:43 Heffalump mornfall: I'm definitely not proposing that cut/paste be split between different named patches, or even exist in the on-disk representation
12:44 Heffalump but I think what you mentioned on the wiki about having atomic patch groups might be a neat solution
12:49 mornfall Might, but I am wary of that.
12:51 Heffalump well, the alternative of multi-object patches seems intuitively more complicated
12:51 Heffalump actually, in the move = cut+paste model, the atomic commute is only an internal implementation detail
12:52 Heffalump I can't see wanting to expose them to users. Which probably means they don't go on-disk either.
13:35 ManateeLazyCat left #darcs
13:39 shenshei_ joined #darcs
13:39 shenshei left #darcs
14:14 jeltsch joined #darcs
14:23 balor_ left #darcs
14:29 bsrk2 joined #darcs
15:08 Riastradh left #darcs
15:26 jderque left #darcs
15:59 gal_bolle joined #darcs
16:00 gal_bolle hi all
16:06 balor_ joined #darcs
16:06 gal_bolle Heffalump: is there a reason why patch491 is not applied? I believe it to be all right, so i'll apply it unless you shout
16:08 Heffalump no reason, just noone reviewed it and I didn't get round to self-pushing
16:08 gal_bolle ok
16:08 gal_bolle pushing it, then
16:08 Heffalump needs-screening really needs clearing up :-/
16:09 Heffalump darcswatch seems to be being unrelible which doesn't help
16:22 gal_bolle does anyone have opinions on relying on temporary (http://hackage.haskell.org​/package/temporary-1.1.1) for creating temporary directories?
16:22 ManateeLazyCat joined #darcs
16:23 Heffalump for what?
16:24 gal_bolle for createTempDirectory :: FilePath -> String -> IO FilePath
16:24 Heffalump for use in what context?
16:25 gal_bolle i use it to make check work out of repo
16:25 gal_bolle i believe we do our own thing in diff somewhere
16:27 Heffalump don't see any reason why not
16:27 ManateeLazyCat left #darcs
16:27 Heffalump check it works on our GHC range though
16:27 Heffalump (6.10 -> 7.0)
16:27 gal_bolle ok
16:28 balor_ left #darcs
16:29 balor_ joined #darcs
16:30 balor_ left #darcs
16:30 balor__ joined #darcs
16:33 Heffalump or persuade people to drop 6.10 for 2.8
16:34 gal_bolle or create a ghc6.10 vm just to test
16:37 balor__ left #darcs
16:37 Heffalump a VM seems excessive, you can just install it in a directory
16:37 Heffalump or you mean for all devs to share?
16:38 Heffalump buildbot kind of offers that with the try stuff
16:39 gal_bolle a vm seems easier than having multiple cabal/ghc-pkg/… fighting with each other
16:39 mornfall Yeah, but buildbot is still waiting for replacement drives. Sadly.
16:41 Heffalump gal_bolle: they don't fight, cabal installs into a subdir named after the compiler
16:42 gal_bolle well, in my experience, upgrading to 7.0 at some point, cabal7 was using ghc-pkg6 (or maybe the other way around), which resulted in much confusion and frustration
16:43 gal_bolle hmm, the posthook is not letting me push patch491: RuntimeError: unable to find our most recent change (20110214220707-81bb2-3188cc738f9​d99787422100e8d17e322fde62225.gz) in the last 80 changes
16:44 gal_bolle oh well, it did push it after all
16:51 mornfall Prolly caused by the buildbot lag.
16:56 jderque joined #darcs
17:09 gal_bolle mornfall: I have a patch for hashed-storage that adds an exported function, should I change the version number in the same patch, or do you want to change it when you tag?
17:15 mornfall gal_bolle: I don't make version changes in same patches as code changes.
17:15 mornfall Release script will bump the version anyway.
17:15 gal_bolle ok
18:09 balor__ joined #darcs
18:18 balor__ left #darcs
18:21 balor__ joined #darcs
18:36 Heffalump what's a good name for a flag to amend-record to suppress the "You're not foo, amend anyway?" prompt? I'm thinking --allow-different-author, but it's not very nice
18:44 gwern --force?
18:45 gal_bolle --steal
18:46 Heffalump I don't want to override the author, just allow amending (or actually unsuspending during a rebase, which uses the same code path)
18:47 gal_bolle --pry
18:47 Heffalump a bit too obscure, I think :-)
18:47 Heffalump --allow-any-author ?
18:47 Igloo Being long isn't a problem, as people are unlikely to actually use it as a flag
18:47 Igloo They'll just put it in their .darcs/defaults
18:48 Heffalump I'm not sure that's the intended use
18:48 Heffalump though perhaps it is
18:48 Igloo Well, why use the flag when you can just answer the prompt?
18:48 Heffalump even with rebase, editing other people's patches is something you should be very careful about
18:48 Heffalump right now, because I have 739 patches I don't own to unsuspend
18:48 Igloo Ah, OK
18:49 Heffalump possibly an option at that prompt to "ok to all" would be an alternative
18:50 * Heffalump decides to go for --allow-different-author for now
19:40 jcpetruzza joined #darcs
19:48 JaffaCake1 joined #darcs
19:51 JaffaCake left #darcs
20:48 copumpkin left #darcs
20:48 copumpkin joined #darcs
21:13 jderque left #darcs
21:24 jcpetruzza_ joined #darcs
21:24 jcpetruzza left #darcs
21:24 jcpetruzza_ is now known as jcpetruzza
22:02 raichoo left #darcs
22:36 jeltsch left #darcs
22:38 jcpetruzza left #darcs
23:03 shenshei_ left #darcs
23:12 gal_bolle left #darcs
23:13 gal_bolle joined #darcs
23:17 balor__ left #darcs
23:25 navaati joined #darcs
23:25 navaati hi
23:25 owst hi navaati
23:26 navaati is there a convenient way to run darcs replace on all the files of my repo ?
23:33 kowey joined #darcs
23:34 jcpetruzza joined #darcs
23:36 owst Not that I know within Darcs. I did this and it appeared to work, but it's horrible ;) `find -type f | grep -v '_darcs' | xargs darcs replace x y`
23:37 jcpetruzza left #darcs
23:37 navaati hum… i'll have to use this, then, thanks
23:41 owst np, sorry I couldn't give you something less ugly!
23:44 kowey MSR hackathon date http://doodle.com/6iz8stzuinvduv27
23:45 owst Cool, last week of GSoC.
23:45 owst kowey: did you see my email about the 1 letter typo?
23:47 kowey yes, fixed, thanks! :-)
23:47 owst Cool :)
23:48 owst kowey: re MSR hackathon - are you thinking of going?
23:49 kowey am thinking of going
23:50 owst Cool, well I'd certainly been keen to go as well.
23:50 owst Depends whether I get my PhD as to whether I'm in Soton over Summer, but if I am I could probably drive up (and give you a lift).
23:50 kowey still crashing lots of planes... not being a good Air Traffic Controller lately
23:50 kowey oh, that'd be great!
23:51 owst My girlfriend lives nearby Cambs, so I'd probably stay there. It's also close to Heffalump too.
23:52 owst I mean Cambridge of course - too used to the colloquialism ;)

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