Camelia, the Perl 6 bug

IRC log for #darcs, 2010-11-15

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

All times shown according to UTC.

Time Nick Message
00:04 iago left #darcs
01:26 zookofamilytime joined #darcs
01:35 twb joined #darcs
01:49 zookofamilytime left #darcs
02:27 gwern left #darcs
03:05 ManateeLazyCat joined #darcs
03:13 ManateeLazyCat left #darcs
03:39 intripoon_ joined #darcs
03:42 intripoon left #darcs
03:50 zookofamilytime joined #darcs
03:51 zookofamilytime is now known as zooko
04:33 zooko` joined #darcs
04:34 zooko left #darcs
04:37 zooko` is now known as zooko
06:25 sm left #darcs
06:27 zooko Anyone have OpenSolaris/x86 and could build darcs 2.5 for me?
06:27 twb zooko: did you already check the binary page on the wiki?
06:27 Funktorsalat left #darcs
06:36 zooko Yes.
07:32 balor left #darcs
07:45 jutaro joined #darcs
07:46 raichoo joined #darcs
07:53 lelit joined #darcs
08:01 darcscommitbot left #darcs
08:02 darcswikibot left #darcs
08:02 darcscommitbot joined #darcs
08:03 darcswikibot joined #darcs
08:05 darcsohlohcommit left #darcs
08:06 darcsohlohcommit joined #darcs
08:50 raichoo left #darcs
08:51 skade joined #darcs
09:10 zooko left #darcs
09:23 skade left #darcs
09:36 balor joined #darcs
09:50 balor left #darcs
10:15 gal_bolle joined #darcs
10:15 gal_bolle hi all
10:15 gal_bolle alexsuraci: how do i get back my login/pass for darcsden, which I lost?
11:04 kowey joined #darcs
11:23 rks left #darcs
11:33 ManateeLazyCat joined #darcs
11:36 twb left #darcs
11:44 kowey left #darcs
11:50 ManateeLazyCat left #darcs
11:50 ManateeLazyCat joined #darcs
11:57 ManateeLazyCat left #darcs
11:57 ManateeLazyCat joined #darcs
12:11 ManateeLazyCat left #darcs
14:01 gh_ joined #darcs
14:29 kowey joined #darcs
14:32 gh_ hi
14:33 gh_ kowey, http://bugs.darcs.net/patch456 is a mistake from me, it is the same bundle as the last I sent for patch442
14:34 kowey thanks! only 119 messages to go
14:34 gh_ I used the command darcs send --subject"patch442" instead of  darcs send --subject"[patch442]" so the patch tracker failed to associate it
14:37 kowey ah! hence the subject
14:37 gh_ yup
14:39 kowey things still in orbit for me: (a) darcs-users/-devel split ... I guess I should just do it :-/
14:39 kowey (b) user model documentation to finish
14:39 kowey (c) we may need a new Windows czar and packager - salvatore MIA?
14:42 zooko joined #darcs
14:43 gh_ it's true that a lot of traffic on -users is for patches
14:45 copumpkin left #darcs
14:48 sm joined #darcs
14:51 gal_bolle kowey: do you have an example of issue1922 failure? i'd like to test my fix
14:52 gh_ hi gal_bolle (i've just seen yannick doing his talk this morning in Marne)
14:54 kowey gal_bolle: perhaps mornfall does, since he noticed it (sorry to pass the buck)
14:56 mornfall I guess the original unpull -o based test I wrote for something else (what was it?) no longer exists...
15:01 kowey I see an issue1892
15:02 sm_ joined #darcs
15:03 kowey bah, work now, triage later
15:03 kowey left #darcs
15:04 intripoon joined #darcs
15:05 sm left #darcs
15:05 sm_ is now known as sm
15:07 intripoon_ left #darcs
15:12 mornfall gh_: http://paste.dqd.cz/hu1n/
15:12 mornfall No time to do this properly, gotta run. hopefully you can work it out from this...
15:13 gal_bolle ok, i'll try to start from that
15:13 gal_bolle thanks
15:15 mornfall Sorry, I mistabbed.
15:16 mornfall (--> bassoon)
15:24 gal_bolle thanks, the test goes from fail to ok
15:24 gal_bolle s/the/your/
15:34 gal_bolle left #darcs
15:35 gal_bolle joined #darcs
15:45 gal_bolle left #darcs
15:49 zooko left #darcs
15:57 gh_ left #darcs
15:58 mornfall NSIS/cabal integration would be useful. (Probably not very easy, though.)
15:58 dcoutts nullsoft installer?
15:59 mornfall Yeah.
15:59 mornfall (That's what cmake uses. There may be other options.)
15:59 mornfall (I can say make package in cmake and get an installer. With relatively little additional cmake build code.)
16:00 dcoutts there's a cabal 2 MSI tool I think
16:00 mornfall That might be even better. Hm.
16:01 mornfall There's this bamse package.
16:02 mornfall Maybe we could try it out. Once building an installer is a one-command process, we could just provide windows binaries from that.
16:04 mornfall Well, some other day. Gotta do other stuff ATM.
16:04 dcoutts mornfall: If you try it I'd be interested to know how it goes
16:05 mornfall Okey. Will drop you a line.
16:05 dcoutts mornfall: I've used innosetup before which is ok
16:05 dcoutts pascal style scripting
16:05 dcoutts gtk2hs installer uses it
16:09 mornfall Oh. arbtt actually has an inno setup thing integrated in its source.
16:09 mornfall The syntax is really funny though. Not that nullsoft is that much better.
16:15 zooko joined #darcs
17:21 rks joined #darcs
18:13 zooko left #darcs
18:27 zooko joined #darcs
18:43 jutaro left #darcs
19:00 gal_bolle joined #darcs
19:01 secorp left #darcs
20:23 gh_ joined #darcs
20:24 iago_ joined #darcs
20:25 raichoo joined #darcs
20:46 balor joined #darcs
21:14 kowey joined #darcs
21:25 gh_ I have patches for get, put and init --old-fashioned removal
21:25 gh_ just that, otherwise all OF handling is preserved
21:26 Heffalump what's the point of that?
21:27 gh_ another baby step towards making repository-related code less entangled
21:27 gh_ moreover I think now darcs 2 should never have had these flags
21:27 gh_ as soon as it defaulted to creating hashed repos
21:29 gh_ another patch renames ``init --hashed`` to ``init --darcs-1``
21:30 Igloo I find "init --darcs-1" very confusing
21:30 Igloo It makes a repo that darcs 1 can't read
21:30 Heffalump I don't really see the point for users of dropping get/put/init but not the rest
21:32 gh_ Igloo, when I see "darcs help init" with the options "--hashed" and "--darcs-2" I am confused since it is just a matter of patch semantics.. maybe they should both be renamed to --patch-type-1 and --patch-type-2
21:32 gh_ Heffalump, it's not for users, it's for us
21:32 gh_ Heffalump, I don't see the point of users running init --old or get --old
21:32 gh_ I suspect nobody thinks about doing it
21:32 gh_ and this is what we want to get away from btw
21:33 gh_ Igloo, the output of darcs help init now reads:
21:33 gh_ --darcs-1   darcs-1 patch semantics
21:33 gh_ --darcs-2   darcs-2 patch semantics [DEFAULT]
21:34 Igloo Just for the record, I run "get --old"
21:34 gh_ you are a power user :)
21:35 Heffalump sorry fo r silence baby feeding
21:36 gh_ I don't think we should focus too much on people who keep on using OF repos; not trying to offense anyone who does, but just look at the code, and maybe more importantly, the UI
21:36 kowey so long as there's an orderly withdrawal...
21:36 gh_ the UI for init makes much more sense now.. choose your patch semantics, that's all
21:37 kowey (no surprises)
21:37 gh_ kowey, that's what I am aiming for. Just doing baby steps for the moment.
21:38 gh_ maybe the (mega)patch to really handle the withdrawal will be written by someone more qualified
21:38 * sm tries to think of when you might need --old-fashioned with a newer darcs version
21:38 sm a baby baby step would be to just remove get/put/init --old-fashioned from all docs except the list-of-hidden-commands
21:40 gh_ I'm not familiar with hidden aliases, but I suspect you can not have hidden flags
21:40 gh_ sm, and the aim is to remove the code for that, most importantly...
21:40 gh_ so hiding the flags is not interesting
21:41 sm you plan that future darcs will not be able to read old repos ?
21:41 gh_ yes, I agree with the ``darcs optimize --upgrade`` only approach
21:42 gh_ that has been presented on the list 2 months ago
21:42 gh_ (late august)
21:43 gh_ (I do not "plan" it myself)
21:43 mornfall gh_: There already was one. :) But it fell behind.
21:43 sm gh_: but would darcs be able to get an old-fashioned remote repo ?
21:44 sm sorry if this was all discussed on list, I don't remember it
21:44 mornfall gh_: (patch374)
21:44 gh_ sm, from the UI pov, enabling get but not pull nor push would be inconsistent, that was the argument to also disable getting
21:45 gh_ mornfall, sorry, I haven't look at your patches
21:45 gh_ there was a lot of them :) I am trying to propose the little changes towards OF deprecation one after another
21:46 mornfall Well, pull and get are both fairly easy, and are about a page of code that can be fairly well isolated.
21:47 sm I don't think I'd want future darcs to stop reading random darcs repos around the net
21:51 Heffalump the previous plan was to get rid of OF and bring hashed performance up to speed by the next release
21:52 copumpkin joined #darcs
21:52 Heffalump without that plan I don't think we should drop OF at all. And the message to users of just dropping get/put/init and nothing else would be very confusing.
21:52 gh_ sm, ok, presented like this...
21:53 gh_ sm, read-only access may be another path then
21:54 gh_ Heffalump, "dropping get/put" is a too wide description of what I'm proposing. you can continue getting from OF repos
21:54 Heffalump I mean the ability to work with OF repos locally.
21:54 gh_ (ok, for put it's accurate :) )
21:54 Heffalump you're basically saying that users can keep the ones they have but they can't make new ones except by hacking
21:54 gh_ yes
21:57 sm I'm trying to think when you might need to do that. Say you're working with big repos and some issue with the new formats has come to light, so you need to create OF repos for a while, and you don't want to give up the goodness of using a current darcs version
21:58 sm (sounds like Igloo)
21:58 Heffalump gh_: I think that's as bad (or even worse) as just dropping OF completely.
22:00 Igloo get, push and pull are exactly the operations I need on OF repos, so from where I'm sitting you may as well remove support completely if you're going to remove those  :-)
22:00 gh_ Heffalump, but from a hashed repos you can still push and pull to OF repos as before
22:00 gh_ Heffalump, and directly work in them as before, also
22:01 sm gh_: say there's a performance issue in hashed repos, that you need OF to avoid. It's happened before
22:01 mornfall sm: OF are already hopelessly slow with current darcs versions.
22:01 mornfall (Many operations just read each repository file.)
22:02 gh_ sm, there has been no work since (let's say) 1 year about improvinf OF performance
22:02 gh_ *improving
22:03 mornfall Heffalump: Btw., about those named patches as tags thing.
22:03 gh_ on the other hand we have had a lot of work on making the best out of the (knowingly limited) hashed format
22:04 gh_ it wouldn't be hard to introduce hashed repositories with bucketed pristine.hashed directory for private repositories
22:04 gh_ I mean experimentally
22:04 mornfall Heffalump: I have been thinking that it may make sense to implement generic repository code, that deals with sets (represented as a commutable sequence) of (unlabeled, but "named", non-composite) patches.
22:05 mornfall Heffalump: The tag stuff could live inside that layer.
22:05 mornfall Without knowing anything about concrete patches.
22:06 sm I believe darcs should always be able to read and create local repos in all major historical repo formats, however hidden/discouraged it might be
22:07 mornfall sm: Well, that can only work if we have resources to either re-implement or re-factor the existing code to deal with them.
22:08 mornfall Which we don't.
22:08 mornfall So either those resources materialize, or though luck.
22:08 gh_ sm, not very relevant but: it is already not the case since you can not create an OF darcs 2 repo
22:08 sm I don't think OF darcs 2 is a major format, ie encountered in the wild
22:10 sm anyway, yes resources. But that's what I believe would be the best.
22:10 sm earlier I wasn't sure
22:10 gh_ as of now you can not contribute to a project that uses darcs-2 semantics and at the same time enjoy OF's advantages
22:15 Igloo gh_: sm is talking about not removing support for something that used to be supported
22:15 Igloo Not supporting things that never existed
22:16 gh_ alright, I wanted to point out the UI inconsistency
22:18 Heffalump mornfall: or we could just take working on the existing code more slowly
22:18 Heffalump we have to choose, and not by a process of random patching. Decide the policy, then implement it.
22:19 mornfall Heffalump: Well, it's not as simple. It works as long as there's enough contributors motivated to do that kind of work.
22:19 gh_ the proposal of removing get/put/init --old support avoids involving a megapatch that removes everything, and has the advantage of preserving every read operation and write operation into existing OF repos
22:19 Heffalump mornfall: not quite sure I get the point, still.
22:20 mornfall Which is not very rewarding, most of the time.
22:20 Heffalump mornfall: sure. But there are some (I would do it, to the extent that I work on repository code, for example)
22:21 mornfall I would do it too -- given (well, not unlimited, but enough) time.
22:21 Heffalump gh_: once we've decided the policy, we can implement it whatever way is best. But my opinion is that removing those and leaving the rest isn't a rational policy.
22:21 mornfall Say, if I worked on darcs as a job, it may be viable.
22:21 gal_bolle actually there are two problems: finding motivated people, and having their time diverted from other tasks
22:22 kowey left #darcs
22:22 Heffalump I am not strongly opposed to dropping OF. But our old strategy, which was agreed, isn't happening any more. We would need to agree a new one before we push ahead.
22:24 gh_ Heffalump, ok, there should be a discussion (on the list) about what should happen with 2.8
22:24 Heffalump sounds good
22:24 gh_ the one of late august never really had a conclusion
22:24 gh_ nor did the adventure branch proposal
22:25 kerneis do you have feedback from users still using old repositories?
22:25 Heffalump yes, there was some in the old thread
22:26 Heffalump whoever wants to drive an OF-removal proposal should gather that up and start a new discussion without forcing those people to repeat themselves, IMO
22:26 gh_ yes, I have in fact a wiki page on my laptop with links to that discussion
22:29 Heffalump I certainly thought we'd reached a conclusion that we'd drop OF, get hashed-storage perf up to par with how OF is/was, and if we failed bring back OF.
22:30 mornfall I think that is still a reasonable plan.
22:36 Heffalump do we have enough people time available to do the perf improvements?
22:36 sm just let's not drive more folks away from darcs by wasting their time with unnecessary compatibility hassles
22:40 sm we've been good on that score I think
22:43 mornfall Heffalump: Hard to tell. Also depends on how releases are scheduled.
22:44 mornfall I should've kept a list of what needs to be fixed.
22:47 Heffalump is the bugtracker a good place to keep it?
22:47 mornfall Presumably.
22:47 Heffalump gal_bolle: shall I apply findCommandAndUncommon?
22:48 mornfall Common not Command (hopefully!)
22:48 Heffalump yes, that :-)
22:48 mornfall (By the sound of it, it does make me a bit uneasy, but I haven't seen much of the patch...)
22:48 Heffalump mornfall: it makes a witnessed fork
22:49 Heffalump the code looked ok (look for a common tag then explicitly pull out common patches past that tag)
22:49 Heffalump grmph, we have a bunch of patches submitted against HEAD that conflict with screened. What should I do, resolve the conflicts in screened?
22:49 mornfall Yeah, that does suck indeed.
22:49 mornfall About findCommonAndUncommon, what worries me is the duplicate patch handling thing.
22:50 Heffalump ah. hmmm.
22:50 mornfall I am not sure it's possible to fix it under that scheme of API.
22:50 mornfall But I am guilty as charged of not fixing it already...
22:50 Heffalump in that case let's hold off until we understand that a bit better - can you comment on the patch? (445)
22:52 Heffalump finally, I have another big pile of refactorings in the Patch namespace nearly ready to submit (abstracting Prim out as a parameter to Patch/RealPatch); anyone up for review?
22:53 mornfall What would nearly ready mean? :)
22:54 Heffalump couple of days, I guess: I need to readd support for Split patches in the parser just in case there are any lurking.
22:54 Heffalump and possibly do a final rebase to catch up with screened.
22:54 mornfall If it includes a "won't redo it from scratch after you review it" I can have a look, although probably not before sleeping tonight.
22:55 gal_bolle normally findCommonAndUncommon should not interfere with duplicate patches
22:55 gal_bolle it just returns (Fork common us them)
22:55 mornfall gal_bolle: Which is wrong, unfortunately.
22:55 gal_bolle where common = findCommon blah
22:56 mornfall It's counterintuitive that it's wrong. But it is.
22:56 gal_bolle then how can using findCommon and findUncommon be right?
22:56 mornfall gal_bolle: We still need to change one of them to give you an extra list that needs to be threaded around a bit. See my last comment on the patch.
22:57 mornfall (Well, the link to those issueNNNNs.)
22:57 gal_bolle ok, i look
22:57 mornfall It may be possible to just do the same with a single function, too. That's why I say I haven't checked.
22:57 Heffalump mornfall: http://darcs.vm.spiny.org.uk/~ga​nesh/darcs-primabstract-staging - I'll just be adding support for reading split patches, and possibly a last rebase.
22:57 mornfall But it should be investigated, I guess.
22:57 balor left #darcs
23:04 mornfall Btw. if you run into hashed performance bugs on the tracker, you can probably assign them to me (unless there is someone else with positive interest in fixing them).
23:04 raichoo left #darcs
23:05 gal_bolle these issues are not fixed in the current darcs, but do you have a fix?
23:06 mornfall What do you mean?
23:07 gal_bolle i'm not sure about the status of these two issues
23:08 gal_bolle wrt head, screened and 2.5
23:08 gal_bolle afaiu, in head, newsetIntersection does the right thing
23:08 gal_bolle but find*Common* don't
23:08 iago_ left #darcs
23:09 gal_bolle and this is not changed by my patch
23:09 gal_bolle s/is/would not be/
23:11 gal_bolle and then whichever version we have needs to get the extra list added
23:12 gal_bolle which should be doable simply by having findCommonAndUncommon return a (Fork _ _ _, [Sealed2 Patch]) or some such
23:13 gal_bolle instead of just a Fork _ _ _
23:14 mornfall Yeah, if that's how it is, then OK.
23:15 mornfall (I just wasn't sure. I don't have a fix, no. Just had a plan for how to fix it.)
23:16 gal_bolle it really returns the same information as the old find*Common*, just with the extra bits that some witnesses are identical
23:16 mornfall Ok.
23:17 gal_bolle (ie, end of common and start of each uncommon)
23:17 gal_bolle so it's just as wrong, but no more
23:18 Igloo What's in the list?
23:19 Igloo The common patches that couldn't be commuted to the prefix?
23:19 gal_bolle i think so
23:19 Igloo Are they also in teh two forks?
23:20 gal_bolle yes, they would end up there
23:20 gal_bolle (currently, you just get fancy fireworks, i think)
23:20 Igloo Wouldn't a set of patch names make more sense than a list of floating patches?
23:21 Igloo Well, I guess it depends what you might want to do with them
23:26 gal_bolle left #darcs
23:40 rks left #darcs
23:49 mornfall You need the contents, to actually check they are really duplicates.
23:49 mornfall IIRC, anyway.
23:52 Igloo What do you check they are duplicates of? And what context do you put them in?
23:53 copumpkin left #darcs
23:54 mornfall Hm. I think what you actually do is pass [PatchInfo] and use that to look up things in the original sequences. But I really don't recall very well, and I am really sleepy.
23:55 mornfall So bed it is, I can think about it later, if needed.
23:56 gal_bolle joined #darcs

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