[00:00] <lifeless> ok, this makes performance tolerable, just fixing this depth-of-query bug
[00:14] <lifeless> abentley: a thought, isn't 'is_ancestor()' just 'return self.heads([ancestor, descendant]) == set([descendant])'
[00:14] <abentley> Could be.  Haven't thought of it that way.
[00:15] <lifeless> AFAICT it should be equally efficient
[00:16] <abentley> That seems right to me.
[00:19] <lifeless> yah it is
[00:19] <lifeless> and it exposes the bug in heads, because making it the same errors on the test that is_ancestor does not access all history
[00:19] <lifeless> :)
[01:18] <jauricchio> hi all! i have a couple very very basic questions about bzr.
[01:18] <jauricchio> (trying to decide between bzr, darcs, and mercurial)
[01:18] <jauricchio> First of all... does bzr have any support for forests like Mercurial's Forest Extension?
[01:21] <jelmer> work is in progress to add support for nested trees (equivalent of forests as I understand it)
[01:21] <lifeless> superset of forests, because nested trees recurse indefinately, forests are a single construct
[01:22] <lifeless> where is LarstiQ anyhow ? :)
[01:22] <jauricchio> Second question... how well does bzr handle binary files?
[01:23] <jauricchio> (pdfs, icky-word-processor documents, images... up to about 5mb)
[01:23] <jelmer> lifeless: he had problems with his internet connection after his holidays
[01:24] <jelmer> lifeless: haven't spoken to him in a couple of weeks
[01:26] <igc> bbiab
[01:26] <lifeless> jauricchio: binaries are fine
[01:26] <lifeless> jauricchio: they can be a bit slow to diff; but other than that we just preserve them as-is.
[01:28] <jauricchio> lifeless: Does bzr diff magically avoid unchanged files?
[01:28] <jelmer> lifeless, did you see my discussion with aaron on dirstate-with-subtree? do you think now be a good moment to encourage packs-with-subtree over packs-without-subtree?
[01:28] <lifeless> jelmer: no, I didn't.
[01:29] <lifeless> jauricchio: what do you mean? If you mean, do unchanged binaries make 'bzr st' and 'bzr diff' slow - no they don't
[01:29] <jauricchio> Yeah that was the question.
[01:30] <jauricchio> So slowness is only incurred when the file is actually changed
[01:30] <jauricchio> that's good :)
[01:30] <lifeless> if you touch the file we sha it
[01:30] <lifeless> if the sha is different we will diff it
[01:30] <lifeless> (roughly). There are some tweaks in different circumstances.
[01:30] <jauricchio> makes sense.
[01:31] <Vantage13> Workflow question.  Let's say I'm a developer working on multiple features for a release of a projects.  So I make a branch of our most recent version to record my changes that will go into the next release.  Now let's say I've got 5 features I'm adding.    Is there a way to identify code belonging to a feature so that it can be easily added/removed without creating a b
[01:32] <lifeless> Vantage13: your sentence is being truncated
[01:32] <lifeless> Vantage13: 'without creating a b
[01:33] <lifeless> 10:32 < l
[01:33] <lifeless> '
[01:33] <Vantage13> without creating a branch for every feature?
[01:35] <Vantage13> or how do people usually handle this scenario?
[01:35] <jauricchio> I think you wanted to create a branch for every feature. Branches are cheap. :)
[01:36] <Vantage13> jauricchio: branches are, but working trees are not.  Currently our code base is about 2GB, so 5 working trees would be 10GB of space per developer...
[01:36] <jauricchio> Hm... fair enough. (That's a *lot* of code, man...)
[01:37] <jauricchio> Darcs would call this a "spontaneous branch". Prefix your commit messages with something, and you can work with 'all patches prefixed with (matching) some text'
[01:38] <lifeless> Vantage13: there is a 'switch' command in bzrtools
[01:38] <Vantage13> the one thing I thought might deal with this would be using a shared repo and doing a bzr switch for each feature.  So switch to main version, branch feature1, commit, switch back to main version, branch feature2, commit, switch back, etc.  Then merge them all later...
[01:39] <lifeless> Vantage13: this lets you transform a working tree from branch A to branch B quite cheaply
[01:39] <Vantage13> lifeless: exactly what I was thinking
[01:39] <Vantage13> lifeless: does what I described sound right?
[01:41] <lifeless> yup
[01:42] <Vantage13> lifeless: Is there a way to 'switch' and create a branch at the same time?  e.g. switch back to main after feature1, then create a branch for feature2 in the same working tree, then switch to it? (to avoid having to create a second working tree at all)
[01:47] <lifeless> Vantage13: why would you create a second working tree?
[01:48] <Vantage13> lifeless: I wouldn't want to.  I'd just want to create a branch and switch to it from my current working tree (which would be on the main branch)
[01:48] <Vantage13> lifeless: I'm wondering if I can do that without creating another working tree
[01:48] <lifeless> Vantage13: 'bzr branch main new-branch && bzr switch new-branch'
[01:48] <lifeless> won't create a working tree unless your repository is configured to make a working tree
[01:49] <lifeless> so just disable creating working trees
[01:49] <Vantage13> lifeless: ah...
[01:51] <jauricchio> So, another question. Suppose I have a directory within a repo. I'd like to pull it out of the repo with all changes applicable to it, and make a new repo containing only it. With leading pathnames removed.
[01:52] <jauricchio> That is, projects is my repo. I want to take projects/foo/baz and make a new repo containing the contents of baz with all history.
[01:52] <jauricchio> With baz as the top level of the new repo
[02:00] <Peng> jauricchio: I think "hg transplant" could do that (or at least do the reverse, moving baz into project/foo), but I'm not sure if it preserves cset IDs.
[02:00] <Peng> jauricchio: I don't know of a way for bzr.
[02:01] <jauricchio> It's okay if cset IDs are lost
[02:01] <jauricchio> My use case is, I've been working on this little baby project that didn't deserve its own repo. Then I decide it does and I want to share it with the world.
[02:04] <lifeless> Peng: answering questions here with 'hg can do X' isn't exactly helpful.
[02:04] <lifeless> jauricchio: 'bzr split' can do that
[02:05] <jauricchio> lifeless: /me checks docs
[02:05] <Peng> lifeless: Heh, sorry. :P
[02:05] <lifeless> Peng: You're more than welcome to say things like 'packs at 10% faster for me, but you're still 40% slower'. Thats extremely useful to know.
[02:06] <jauricchio> lifeless: 'split' not found in the user reference at doc.bazaar-vcs.org
[02:06] <lifeless> jauricchio: 'bzr help split'.
[02:06] <jauricchio> not installed currently :\
[02:06] <lifeless> ah. Well then. We have the feature.
[02:06] <jauricchio> :) cool
[02:07] <lifeless> and naturally we're expanding on it and improving it as time goes by.
[02:07] <jauricchio> of course
[02:09] <jauricchio> ok, thanks for your help lifeless, Peng, and jelmer. bzr looks to be what i need!
[02:09] <jauricchio> bye
[02:09] <Peng> Cool.
[02:10] <lifeless> Peng: speaking of which, are you still dogfooding packs from time to time ?
[02:12] <lifeless> jelmer: so do you mean bug 131667 ?
[02:12] <ubotu> Launchpad bug 131667 in bzr "--dirstate-with-subtree is documented in the man page" [Medium,Fix committed] https://launchpad.net/bugs/131667
[02:12] <jelmer> yes
[02:13] <lifeless> I would love someone to sit down and take on the patch
[02:13] <lifeless> larstiq was working on it but hes disappeared
[02:13] <lifeless> the patch to make nested-by-reference trees robust
[02:13] <poolie> lifeless, hi, so to check that plan:
[02:13] <lifeless> this is what is needed to make -subtrees a default format and trigger the format bump
[02:13] <poolie> - make new knit repo containing bzr.dev
[02:13] <poolie> - reconcile that.
[02:13] <poolie> - make a new pack repo
[02:14] <poolie> - pull bzr.dev from the first repo
[02:14] <poolie> - pull packs branch
[02:14] <lifeless> (or bzr upgrade --experimental in the reconciled repo)
[02:14] <lifeless> but yes, thats the right list
[02:19] <Peng> lifeless: I keep a copy of bzr.dev and repository in pack format and pull and diff frequently, but that's the extent of my dogfooding.
[02:20] <lifeless> ok
[02:20] <Peng> FWIW, I never reconciled it.
[02:20] <lifeless> did you try the C sequence matcher thing ?
[02:20] <lifeless> which speeds up diff, and would AIUI make your home dir versioning tolerable or even pleasant
[02:22] <Peng> lifeless: I switched it over to hg before I found out about that, and I've never gotten around to trying it.
[02:22] <Peng> Hmm. I could right now, but Firefox is hogging so much RAM it wouldn't be remotely accurate.
[02:22] <lifeless> thats fine, don't worry about it
[02:25] <Peng> Mozilla should pay me for all the RAM upgrades I have to do for Firefox.
[02:25] <lifeless> less tabs++ :)
[02:25] <Peng> Yeah.
[02:25] <Peng> Less Flash++ too.
[02:25] <Peng> That's what's really killing it.
[02:37] <lifeless> poolie: how is it going ?
[02:37] <poolie> reconciling again
[02:37] <poolie> i may skip that as i'm pretty sure i did that in the same repo on friday
[02:42]  * Peng sighs.
[02:42] <poolie> switching terminals
[02:43] <Peng> Firefox froze right before I was going to shut it down.
[02:45] <lifeless> :(
[02:51] <Peng> Hmm. I should probably just cp instead of using "bzr branch".
[03:00] <lifeless> abentley: you're bouncing
[03:08] <abentley> Yes.  Sorry.
[03:08] <abentley> Updated to gutsy, and it's giving me probs.
[03:10] <lifeless> :(
[03:12] <Peng> Uh-ohs.
[03:12] <Peng> Branching the pack version of my homedir crashed with a KnitCorrupt error.
[03:12] <Peng> But I think that branch might be older than the most recent pack format.
[03:13] <lifeless> yes, you probably have annotated knit data in it
[03:13] <Peng> Yeah.
[03:13] <Peng> Yeah, I think it might be like the very first revision it's saying is corrupt.
[03:14] <Peng> Or, the first file.
[03:20]  * Peng watches the progress bar.
[03:24] <Peng> A 700 MB .pack file. That scares me.
[03:25] <Peng> It was 743 MB with annotations, now it's 712.
[03:29] <lifeless> thats cause you have a lot of data with lots of changes
[03:30] <Peng> Well yeah. But I'm afraid of it.
[03:30] <ubotu> New bug: #155629 in bzr "newly-created dirstate file appears blank on curlftpfs filesystem" [Undecided,New] https://launchpad.net/bugs/155629
[03:31] <Peng> One little bit out of 6 billion could be wrong.
[03:32] <lifeless> no different to have many 10M files
[03:32] <Peng> lifeless: With 0.91 with Pyrex and dirstate, real time is 3m9.784s, user is 2m56.132s, sys is 0m10.781s. That might be like a 20 or 30 second improvement.
[03:33] <lifeless> Peng: how many files are there there ?
[03:33] <Peng> lifeless: Uhh. A lot.
[03:33] <lifeless> Peng: and are you committing a merge, or just a regular commit ?
[03:34] <lifeless> Peng: and finally, had you just added new files before the commit ?
[03:35] <Peng> lifeless: What command tells me the total number of files?
[03:35] <lifeless> bzr inventory | wc -l
[03:36] <Peng> lifeless: 4695.
[03:36] <Peng> lifeless: In that commit, 39 files changed. Not a merge, and no new files.
[03:36] <lifeless> had you run bzr add?
[03:37] <lifeless> (bzr add in 0.91 destroys the stat cache)
[03:37] <Peng> lifeless: Nope.
[03:37] <Peng> lifeless: uncommit, maybe a status or two, then commit.
[03:37] <lifeless> thanks
[03:38] <lifeless> thats very slow compared to my current results with packs, which is encouraging
[03:38] <Peng> I'm testing packs right now.
[03:39] <Peng> BTW, hg is like 30 seconds. ;P
[03:39] <lifeless> yah
[03:40] <Peng> Also, I caught it at up to ~355 MB of RAM, and I bet it was bigger at other times.
[03:40] <Peng> Wow.
[03:41] <Peng> real    1m44.768s
[03:41] <Peng> user    1m37.652s
[03:41] <Peng> sys     0m5.437s
[03:41] <Peng> Packs *are* faster.
[03:41] <Peng> The new .pack file is 726 KB.
[03:42] <lifeless> hmmm, not that much faster
[03:42] <lifeless> I'd love it if you could repeat that
[03:42] <Peng> Just run it again?
[03:42] <lifeless> with --lsprof-file foo.callgrind
[03:42] <lifeless> then gzip the callgrind file and mail it to me
[03:42] <Peng> Gack.
[03:43] <lifeless> this won't give me anything private
[03:43] <lifeless> just the callgraph and timings
[03:43] <lifeless> so I can see where the slowness is coming from
[03:43] <Peng> I know.
[03:43] <Peng> I said "Gack." because I had just started running it again.
[03:43] <lifeless> ;)
[03:44] <lifeless> just ctrl-C it
[03:44] <Peng> I did.
[03:44] <Peng> It'll be done shortly.
[03:45] <lifeless> thanks!
[03:45] <Peng> real    2m0.958s
[03:45] <Peng> user    1m38.290s
[03:45] <Peng> sys     0m22.328s
[03:45] <Peng> Huh.
[03:45] <Peng> I would've expected user time to be higher due to lsprof.
[03:47]  * Peng sighs.
[03:51] <ubotu> New bug: #155632 in bzr "KeyError: 77 in pycurl_errors.errorcode" [Undecided,New] https://launchpad.net/bugs/155632
[03:53] <lifeless> poolie: how goes it ?
[03:53] <Peng> lifeless: What's your email address?
[03:59] <lifeless> robert at ubuntu
[04:01] <Peng> Blaah, you have more email addresses than I do.
[04:01] <Peng> ubuntu.com?
[04:01] <lifeless> yah
[04:01] <poolie> lifeless, i think that's the same error i saw on friday
[04:02] <poolie> so
[04:02] <Peng> Wasn't it @canonical.com two months ago?
[04:03] <lifeless> yes
[04:03] <lifeless> its there too
[04:03] <lifeless> you coulda use the prior address :)
[04:06] <Peng> I'll send it in a second.
[04:09] <Peng> Sent.
[04:15] <lifeless> Peng: thanks
[04:17] <lifeless> Peng: 67% is in get_content_maps
[04:17] <lifeless> Peng: which is building up the copy of the the text to diff against
[04:17] <lifeless> 10% in IO
[04:17] <lifeless> we can't reduce that much
[04:17] <lifeless> actually, 5%
[04:18] <lifeless> 5% parsing the deltas from disk
[04:19] <lifeless> ohfuckme
[04:19] <lifeless> Peng: I can see an easy 17% win
[04:19] <lifeless> we're memory copying stuff we don't need to, because of a general 'get many versions' function
[04:20] <lifeless> Peng: if you look at bzrlib/knit.py
[04:20] <lifeless> Peng: the function get_content_maps
[04:20] <ubotu> New bug: #155637 in bzr "patch confict should be an internal error" [Low,Confirmed] https://launchpad.net/bugs/155637
[04:20] <lifeless> see the coyp() calls in there - there are two I think. Guard them with e.g. 'if multiple_versions:'
[04:21] <lifeless> and at the top of the function do
[04:21] <lifeless> multiple_versions = 1 != len(version_ids)
[04:21] <lifeless> this should save 17% trivially.
[04:24] <Peng> lifeless: Cool.
[04:24] <Peng> Hold on.
[04:25] <Peng> lifeless: _get_content_maps?
[04:26] <lifeless> yah
[04:26] <lifeless> line 1000 in my knit.py
[04:27] <Peng> Exactly 1000?
[04:27] <Peng> Anyway, done.
[04:28] <Peng> lifeless: Want a new callgrind file?
[04:30] <lifeless> nah, just run it without callgrind and see if it helps
[04:30] <Peng> Well, I ran it with callgrind and it helped.
[04:30] <Peng> Uhm.
[04:30] <Peng> 56 seconds vs. 1m38s.
[04:31] <lifeless> great
[04:31] <Peng> Yeah.
[04:31] <lifeless> theres another win of the same size in _apply_delta
[04:31] <lifeless> in the same file
[04:31] <lifeless> will be a little more tricky to fix that without leading to bugs
[04:31] <lifeless> I'll do both today though
[04:32] <Peng> I helped make Bazaar faster. Cool.
[04:33] <lifeless> yup
[04:36] <Peng> Well, I'd be happy to re-run it in the future if you ever want me to.
[04:36] <lifeless> tomorrow probably ;)
[04:36] <lifeless> and thanks
[04:37] <Peng> Heh, okay.
[05:15]  * ig1 food
[05:52] <poolie> lifeless, ping?
[05:53] <lifeless> hi
[05:54] <ig1> so lifeless, 3 patches today (so far) - what order do you want them reviewed in if any?
[05:55] <lifeless> don't care about order
[05:55] <lifeless> just about completeness
[05:55] <lifeless> FIFO is fine
[05:55] <lifeless> and probably best
[05:55] <ig1> ok - I'll start with the tests one now
[05:55] <lifeless> oh that one can be ignored
[05:55] <lifeless> leave it till later
[05:56] <ig1> that's why I asked :-)
[05:56] <ig1> graph.heads then
[06:36] <poolie> i've turned my check-knits branch into a plugin
[06:37] <poolie> it's faster than a full check (because it does less)
[06:37] <poolie> it may be useful
[06:40] <lifeless> ig1: how is the review going ?
[06:41] <ig1> getting there ...
[06:41] <ig1> haven't looked at the graph code before
[06:41] <ig1> you have an import pdb but onothing else stands out so far
[06:42] <ig1> s/onothing/nothing/
[06:42] <lifeless> do I? oh foo
[06:42] <ig1> in test_graph.py
[06:43] <ig1> also 2 lines immediately before run_heads_break_deeper ...
[06:43] <ig1> otherwise tests look good
[07:01] <lifeless> is that 'merge it'
[07:01] <lifeless> or 'I'm still thinking' ? :)
[07:02] <ig1> I'm still thinking - need another 20-30 minutes I think
[07:13] <lifeless> ig1: well, next patch is up
[07:14] <ig1> ok - not thru yet to me - will check again soon
[07:18] <lifeless> there it goes
[07:20] <lifeless> Peng: 2851
[07:20] <lifeless> Peng: thats the revno in repository with a bugfix to remove all three list-copies.
[07:22] <lifeless> Peng: it will also, incidentally, reduce memory pressure, but probably not much
[07:58] <poolie_> bug 154283
[07:58] <ubotu> Launchpad bug 154283 in bzr "indexerror in Knit._get_components_positions pulling in pack repo" [Undecided,New] https://launchpad.net/bugs/154283
[08:12] <poolie_> join-branches.txt-20050309044946-f635037a889c0388^@robertc@robertcollins.net-20050919060519-f582f62146b0b458^@^@1747020^M1746789^I1747020^@ 42658896 124$
[08:12] <fullermd> Took the words right outta my mouth.
[08:15] <Lo-lan-do> You have strange things in your mouth.
[08:18] <fullermd> It's like that thing with the old lady who swallowed a fly.
[08:19] <ig1> lifeless: that review finally mailed - few tweaks only as best I can see
[08:27] <Peng> lifeless: Holy crap. With callgrind, user time went from 56 seconds last time to 19. Real time was still at 56 seconds, but Firefox is open now so everything is probably laggier. Sys time went from 23s to 21s.
[08:28] <Peng> lifeless: Trying again, real time is down 10s and the others are down 1 or 2.
[08:36] <lifeless> ig1: yup, copacetic
[08:36] <lifeless> ig1: will do tomorrow.
[08:36] <lifeless> Peng: so is this good ?
[08:37] <ig1> lifeless:quikc Q
[08:37] <ig1> what's the idea behind the version_id param in the apply_delta API?
[08:37] <lifeless> Peng: what is real time sitting at without callgrind ?
[08:37] <lifeless> ig1: KnitContent objects have a version
[08:38] <lifeless> ig1: Plain ones use this for all lines; Annotated ones carry it per-line
[08:38] <lifeless> so the parameter is to totally transform the content object from state to state
[08:38] <Peng> Hold on. I'm brushing my teeth.
[08:39] <ig1> and self_version_id only gets set for one, not the other, is therefore by design?
[08:39] <lifeless> yes
[08:39] <ig1> s/self_/self._/
[08:39] <ig1> ok - thanks
[08:40] <mdke> I'm still playing with svn-import. Does anyone know why I'd get a "server certificate verification failed" on one gutsy computer and not on another, connecting to https://docteam.ubuntu.com/repos?
[08:41] <lifeless> check for /etc/ssl/ca-certificates.crt
[08:41] <lifeless> if its missing run update-ca-certificates
[08:41] <Peng> real    0m22.511s
[08:41] <Peng> user    0m17.378s
[08:41] <Peng> sys     0m2.758s
[08:41] <Peng> lifeless: ^
[08:41] <lifeless> Peng: how does this compare to hg ?
[08:41] <Peng> Umm.
[08:42] <Peng> Very good.
[08:42] <Peng> well?
[08:42] <lifeless> thanks :)
[08:42] <mdke> lifeless: it was present in /etc/ssl/certs/
[08:42] <mdke> I ran the update anyway, no change
[08:42] <Peng> Last hg one I did was:
[08:42] <Peng> real    0m45.080s
[08:42] <Peng> user    0m13.716s
[08:42] <Peng> sys     0m2.316s
[08:42] <lifeless> mdke: sorry yes thats the right place. Other than that I have no suggestions.
[08:42] <mdke> ok, thanks anyway
[08:43] <lifeless> Peng: hmm, still need to shave off lots of user time. But I knew that
[08:43] <mdke> lifeless: one was executed over ssh, could that make a difference?
[08:43] <Peng> Bzr and hg aren't committing exactly the same data.
[08:43] <Peng> So it's not an entirely fair comparison.
[08:43] <lifeless> Peng: bzr's committing less?
[08:43] <Peng> I don't know.
[08:43] <lifeless> ah
[08:43] <lifeless> so its roughly the same but not identical ?
[08:43] <Peng> Bzr is using two-month-old data. Since then, my IRC logs have grown larger, but I've also switched from Opera to Firefox.
[08:44] <Peng> Hm.
[08:44] <Peng> I think hg is about the same as it was two months ago. It used to take about 30 seconds, but I'm not sure if that was real or user time.
[08:44] <Peng> If it was real time, the extra time is just due to Firefox hogging RAM.
[08:47] <lifeless> gnight all.
[08:47] <Peng> Good night.
[09:02] <Peng> lifeless: BTW, bzr is probably committing more changes. Bzr is doing 12 hours of changes while hg is doing 1.
[09:10] <GaryvdM> Is it possible to pull the bzr.dev branch over the bzr protocal
[09:10] <GaryvdM> All the docs point to http urls
[09:18] <poolie_> GaryvdM, you should be able to get it from
[09:18] <poolie_> bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk
[09:18] <poolie_> you need to have a launchpad account
[09:18] <poolie_> we'll offer public bzr:// soon
[09:20] <Peng> Not to be a troll, but is bzr any less slow than http?
[09:21] <Lo-lan-do> I think there are fewer round-trips, so probably.
[09:22] <Peng> It takes a very long time to pull changes to bzr.dev.
[09:22] <Peng> Of course, the one time I time it, there aren't any new changes, and it takes 3 seconds.
[09:23]  * Peng wanders off.
[09:29] <poolie_> ok so it's
[09:29] <poolie_> KnitVersionedFile(file:///home/mbp/newbzr/dest2/.bzr/repository/text%3ATestUtil.py-20050824080200-5f70140a2d938694)
[09:30] <poolie_> bzr: ERROR: Revision<EMAIL_ADDRESS>not present in "<bzrlib.knit.KnitGraphIndex object at 0x8ef5e4c>".
[09:34] <indraveni> hi all
[09:34] <indraveni> i would like to know, whether there are any tools for viewing the bazaar content
[09:34] <indraveni> like for subversion we have, trac, websvn etc
[09:36] <Kinnison> Morning
[09:42] <indraveni> i would like to know, whether there are any tools for viewing the bazaar content
[09:42] <indraveni> like for subversion we have, trac, websvn etc
[09:47] <poolie_> indraveni, yes, look at loggerhead
[09:53] <Peng> indraveni: There's also a bzr plugin for Trac.
[09:55] <GaryvdM> Peng: acording to http://weblogs.mozillazine.org/jst/archives/2007/02/bzr_and_different_network_prot.html bzr is faster than http
[09:55] <GaryvdM> I'm going to test it now
[09:55] <GaryvdM> I live in South Africa - We have slow internet connections.
[10:00] <GaryvdM> bzr+ssh  = 12 sec
[10:00] <ig1> night all
[10:00] <GaryvdM> http = 8.9
[10:00] <GaryvdM> no changes in the tree on either
[10:02] <lifeless> Peng: bzr can be faster than http; packs help with this, on knits latency sucks arse.
[10:03] <Peng> What I wonder is how efficient bzr's smart server is, espcially compared to hg. Hg only uses a smart server, so it must have had a lot of tweaking. With bzr, the smart server is only starting to catch on.
[10:04] <Peng> There is that hpss stuff.
[11:06] <ubotu> New bug: #155730 in bzr "reconcile doesn't adjust knit index references to otherwise-unreferenced file revisions" [Critical,Confirmed] https://launchpad.net/bugs/155730
[11:45] <GaryvdM> On http://bazaar-vcs.org/BzrDevelopment , the Release revids have not been updated for a while
[11:45] <GaryvdM> How can I find out what they are for newer releases?
[12:00] <AfC> GaryvdM: I was going to guess `bzr tags`, but somewhat astonishingly there aren't tags for releases in their 'bzr.dev' branch
[12:00] <fullermd> Sorry, those revids are only available to Members of the Brotherhood.
[12:01] <GaryvdM> Who does the releases?
[12:01] <fullermd> Well, the releases don't come from bzr.dev.  They have their own branches.
[12:01] <fullermd> (and bzr.dev can't have tags anyway, in its current form)
[12:02] <jsk> hi all: does anyone know a good method for doing "bzr pull" over an unreliable connection?
[12:02] <jsk> all: my connection only lasts a maximum of 12 minutes at a time, but the pull operation takes longer (because it's a big tree).
[12:03] <jsk> all: I'm using bzr+ssh://.......
[12:03] <jsk> all: I'm open to using a workaround, such as downloading the tree via HTTP, in multiple chunks.
[12:04] <fullermd> Well, pull saves what it gets, in some granularity.  So as long as it takes you less'n 12 minutes to get a single "hunk" (probably the changes or a subset of the changes to one file, with knits), each pull should move forward.
[12:04] <fullermd> I tend to think "kill your network admin in his sleep" is a more satisfying solution, though.
[12:05] <jsk> fullermd: I'd like to do that to my ISP.
[12:05] <mwhudson> i think jsk would quite like to take that approach
[12:05] <jsk> :)
[12:05]  * jsk has been plotting revenge for some days now
[12:05] <fullermd> Oh, ISP's even easier.  You know they're all in one office   ;)
[12:05] <fullermd> Take off and nuke the site from orbit.  It's the only way to be sure.
[12:05] <jsk> fullermd: :)
[12:05] <AfC> fullermd: (bzr.dev is not tags compatible? You guys are weird)
[12:06] <fullermd> AfC: bzr.dev is still branch5.  I think some Linux distros are still shipping 0.11, so if we updated it they couldn't access it.
[12:07] <AfC> Oh
[12:07] <fullermd> It's probably about time that it would be "OK" to make that switch these days.
[12:07] <Peng> Well, the default format has changed to dirstate-tags.
[12:07]  * AfC refrains from commenting on distros that have such lame upgrade policies, although he notes down a reminder to rant about it again when giving his next conference keynote.
[12:07] <fullermd> Hasn't been any big pressure to, though.  I wouldn't be too surprised if it stayed as-is until there's been a couple releases with packs, then it gets moved there.
[12:08] <mwhudson> like, uh, dapper ?
[12:08] <jsk> fullermd: So you suggest the following steps:
[12:08] <jsk> 1. run "bzr pull --remember bzr+ssh://..."

[12:08] <jsk> 6. repeat 2 onwards...
[12:08] <jsk> where "..." represents the full path
[12:08] <fullermd> Well, you'd only need the --remember once.  But yeah, that's the best I've got.
[12:08] <AfC> The subsequent commands won't need --remember
[12:08] <jsk> fullermd: cool. I'll give it a try. thanks :)
[12:08]  * jsk resumes his plotting...
[12:10] <AfC> fullermd: you know, that's not the sort of environment that I would have thought about, but I am curious how the packs modality will work in the face of partial transfers.
[12:11] <fullermd> Well, with a buttload fewer round trips, there's a good chance packs will get done sufficiently quicker that you wouldn't have to many mid-flight disconnects.
[12:11] <fullermd> The individual hunks to download and save would probably be bigger, so I s'pose that with a sufficiently high disconnect rate and low bandwidth, you might get stuck never making any progress with packs, where knits would inch along.  But that's pretty pathological.
[12:12] <jsk> (about to be disconnected)
[12:13] <fullermd> In that case, the answer is probably "keep trying to pull until the smart server gets sufficiently smart and the server upgrades"   ;)
[12:14] <fullermd> 'course, with sufficiently pathological conditions, that solution probably won't work either.
[12:14] <fullermd> Your hunks would just be too large to move in the bandwidth/time available.
[12:20] <VSpike> Hi guys ... just about to try and migrate from Perforce to bzr, and wanted to double check I'm doing the right thing, so may run some things by you all in the next few minutes
[12:23] <VSpike> At the moment, I just need to share development between two of my machines, but eventually I may need to open this up to some of the company's clients, so the "Decentralized with human gatekeeper" model will come into play
[12:25] <VSpike> To start, I'm going to pull my last stable version out of perforce and check it in as a head revision, and then the latest code in my two development branches, and check those in as branches to the head revision.  I don't need to pull across all the perforce history (which is good, because I probably can't)
[12:28] <VSpike> I was just trying to figure out if I should have a shared repository with trees or without
[12:28] <VSpike> I guess because the desktop machine is both my fileserver and workstation, with trees makes sense... does that seem reasonable?
[12:28] <GaryvdM> Yes
[12:28] <fullermd> Well, on the one hand, it doesn't matter.  You can change it around trivially later.
[12:29] <VSpike> fullermd: thanks, that's useful to know
[12:29] <fullermd> But yah, going with trees now would be the easy thing to do (unless the trees are so big it'll cause issues), since you can blow them away and disable them by default later.
[12:29] <Peng> VSpike: You might be able to convert from p4 to bzr without losing history...
[12:30] <VSpike> Peng: I quite like the idea of a clean start - then I can lay out the repository in a more logical way than the rather haphazard one I have in perforce
[12:31] <GaryvdM> If I have a branch object, how do get the bzrdir object?
[12:33] <GaryvdM> Ah - branch.base
[12:35] <mwhudson> branch.bzrdir, isn't it?
[12:39] <GaryvdM> mwhudson: yes
[12:40] <GaryvdM> thanks
[12:53] <jsk_> fullermd: thanks for your help earlier. I think I'll have to try a different method. My connection windows are 12 minutes long, and this doesn't seem sufficient for a "bzr pull" to get to the stage where it has committed anything to disk (the contents of .bzr do not change during this time, despite the network traffic and RAM usage increasing).
[12:54] <jsk_> fullermd: after a full 11 minutes, the "bzr pull" is still at Pull Phase 0/2
[12:54] <fullermd> Bleh.
[12:55] <fullermd> Well, that part doesn't mean too much by itself.  I think 90% of pull's time is in phase 0 (that 0-based numbering still bugs me)
[12:55] <jsk_> computer scientists...
[12:55] <jsk_> :)
[12:57] <fullermd> Well, it's inconsistent too, I think.  The /2 means there are 2 phases, and they're called 0 and 1.  So when it's doing its last byte, it's on phase 1/2.
[12:57] <jsk_> fullermd: I do have ssh access to the server hosting the branch (at the other end of my connection). Perhaps I could create a tar of the branch, and download it in chunks.
[12:58] <jsk_> fullermd: however, I'm not sure if this method will create a working local branch.
[12:59] <jsk_> fullermd: +1 on your suggestion to revise the numbering...
[12:59] <GaryvdM> After you have download the branch, you can do bzr checkout to create a working tree.
[13:01] <jsk_> GaryvdM: that sounds like a good idea. However, I'm hoping to run a "bzr pull --remember" on the local branch, to tie it up with the remote one.
[13:01] <jsk_> GaryvdM: I'm hoping that this operation will complete quickly.
[13:01] <jsk_> GaryvdM: and not take as long as it would with an newly "bzr init"-ed directory.
[13:02] <jsk_> GaryvdM: thanks for your help :)
[13:02] <Edulix> hi
[13:02] <Edulix> I get this
[13:02] <Edulix> edulix@edulix-laptop:~/descargas/dark-extermination$ bzr push<EMAIL_ADDRESS>[13:02] <Edulix> Permission denied (publickey).
[13:02] <Edulix> bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; EOF during negotiation
[13:03] <fullermd> jsk_: Well, you could rsync too (as long as you're sure your destination doesn't have stuff that needs to be not be overwritten)
[13:04] <AfC|dinner> fullermd: he's pulling
[13:04] <AfC|dinner> jsk_: rsync would be ideal for this situation
[13:04] <AfC|dinner> [I used to use rsync to *push* until the bzr server came along]
[13:07] <vila> jsk_: have you tried bzr pull http+urllib:// ? It may be longer but urllib implementation should reconnect automatically on transient errors
[13:14] <matkor> In checkouted tree I can see  parent branch: /home/users/arekdydo/src/abbon/abbon2 which is wrong, how can I change it to proper value ?
[13:15] <fullermd> AfC|dinner: ?  I know, but what's that matter?
[13:16] <AfC|dinner> fullermd: yeah, sorry, you're right.
[13:19] <vila> Edulix: check that you published your ssh key on launchpad
[13:24] <matkor> unbind / bind does not set parent branch it keeps on bugus value ...
[13:25] <fullermd> Parent branch is set/used by pull/merge/missing...   maybe others I forget?
[13:26] <fullermd> If you don't need those to default to anything in particular though, it doesn't really matter (except cosmetically) if the given value is nutty, though.
[13:32] <matkor> fullermd: Ah ! I can set it  by bzr pull --remember
[13:32] <matkor> Thanks
[13:34] <VSpike> I know this is a bit OT, but how tightly wedded is Visual Studio to its \Projects, \Websites layout?  I'm wondering if I can make it play nicely with a head/project1, head/project2, etc.. layout... does anyone have experience?
[14:07] <sabdfl> hey guys
[14:37] <vila> jsk_: you're bouncing :) Did you succeed with your push-inside-a-network-shutting-down-every-12-minutes ?
[14:37] <vila> pull even
[14:39] <vila> sabdfl: hi, just passing around or heard about lifeless wonders ? :)
[14:39] <sabdfl> vila: i hear there are wonders in the works, what's the latest news?
[14:40] <vila> Peng: can you summarize your last experiments with the pack format to sabdfl ?
[14:41] <sabdfl> oh, i saw that bit :-)
[14:41] <vila> sabdfl: :)
[14:41] <sabdfl> very cool indeed!
[14:43] <vila> yup, very encouraging
[15:07] <jsk_> vila: thanks! I did succeed in the end - but only by zipping up the remote branch and downloading it in small chunks. After reconstituting the branch locally, I was able to do a "bzr pull --remember..." followed by two successive "bzr pull" operations to get the branch synced with its parent.
[15:07] <jsk_> vila: (two successive operations were necessary as the first "bzr pull --remember" got cut off by the network going AWOL).
[15:10] <vila> jsk_: just for completeness, I'd be interested if you an try a bzr pull http+urllib:// in a temp directory to test the transient error handling
[15:10] <vila> s/an/can/
[15:11] <vila> jsk_: and you should write a nice letter to your isp too :)
[16:06] <jelmer> mdke: any luck with svn-import?
[18:40] <Vantage> hi, quick question.  How do I configure bzr to create a branch without a working tree (or create a remote branch in a shared repo w/o making a working tree)
[18:45] <Peng> Well, you could use 'bzr init-repo --no-trees'.
[18:46] <james_w> Vantage: there is also 'bzr remove-tree' to do it after the fact.
[18:46] <james_w> and doing a push to a remote location will not create a working tree there.
[18:47] <Peng> If you already have a shared repo and want new branches to stop creating working trees, touching .bzr/repository/no-working-trees should do it.
[19:01] <Vantage> Peng: thanks.  Is that in a document somewhere?  I tried hunting for it on the site, but couldn't find it
[19:01]  * Peng shrugs.
[19:02] <Peng> Vantage: It's in 'bzr help' if you know where to look.
[20:01] <lifeless> moin
[20:01] <jam-laptop> morning lifeless, is my clock right in saying it is 5 am there?
[20:02] <lifeless> yes
[20:02] <fullermd> He's got pack repos.  They let him sleep faster.
[20:02]  * lifeless flips the bird
[20:06] <lifeless> ok, its cooked now ;)
[20:09] <lifeless> jam-laptop: so, what do you have on your plate?
[20:09] <jam-laptop> lifeless: right now I'm just going through the review queue and trying to squash all of the Critical bugs
[20:09] <jam-laptop> At least the ones with relatively simple fixes
[20:09] <lifeless> yah
[20:10] <lifeless> the revisionspec one would be lovely if you could do
[20:10] <jam-laptop> there is a surprising amount of stuff in: http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n
[20:10] <jam-laptop> Which has been approved but not merged
[20:11] <lifeless> I'm back stripping commit down to do only what it needs to do
[20:12] <lifeless> dirstate lookup is problematic
[20:12] <jam-laptop> sounds good
[20:12] <lifeless> I'm considering a basic datatype to factor out - 'sorted dict'
[20:12] <jam-laptop> Any way you can completely stream rather than doing the per-file lookup?
[20:13] <lifeless> well, I wrote a patch that layers on iter changes
[20:13] <jam-laptop> even if it was only for the non-merge case
[20:13] <jam-laptop> that would be a pretty big win
[20:13] <lifeless> but it still has to probe back in because iter changes hides too much
[20:13] <lifeless> the core problem is that commit diffs against an arbitrary parent, not parent 0
[20:14] <jam-laptop> well, that is why I said the "non-merge" case
[20:14] <lifeless> well, I say 'problem'. The reason that iter_changes is not a good fit is that ..
[20:14] <jam-laptop> Certainly I'm aware of the api divergence between multiple parents and _iter_changes
[20:15] <lifeless> I really don't want two code paths here
[20:15] <lifeless> I just feel it would be a recipe for bugs; and this is not a code area we want bugs in.
[20:15] <jam-laptop> lifeless: I'd like to have 1 code path eventually, it is just an issue of crawling before we walk
[20:15] <jam-laptop> I know we've gone around a few times of _iter_changes_for_commit
[20:16] <lifeless> right, a native version of that may well help
[20:16] <lifeless> but OTOH I think lsprof is lying
[20:16] <jam-laptop> :)
[20:16] <jam-laptop> lsprof does skew results a little bit
[20:17] <lifeless> the cache I added shaves 1/2 second off
[20:17] <lifeless> but if lookups really were what it though, it should be more, and it gets a solid hit rate
[20:19] <lifeless> s/though/*t/
[20:19] <lifeless> &t dammit :)
[20:20] <jam-laptop> have you measured its hit rate?
[20:20] <jam-laptop> I wonder if it is less than you think
[20:21] <jam-laptop> (I don't see why it really would be, but it is something to consider)
[20:21] <jam-laptop> For example, if you have an average of 4 files per directory
[20:21] <jam-laptop> you can only have a 4/5 hit rate
[20:21] <jam-laptop> Though that is still 80%
[20:21] <lifeless> I'm testing on good ole moz
[20:21] <jam-laptop> IIRC moz has < 10 files per dir average
[20:22] <lifeless> interesting
[20:22] <jam-laptop> At least, we have 5761 directories
[20:22] <jam-laptop> and 49001 files
[20:23] <Lo-lan-do> Is Moz still using CVS, by the way?
[20:23] <jam-laptop> (49001 + 5761) / 5761 = 9.5
[20:23] <jam-laptop> Lo-lan-do: primary development on Moz is still in CVS
[20:23] <Lo-lan-do> Ouch
[20:23] <jam-laptop> I think one of the "advanced branches" are trying hg
[20:23] <jam-laptop> Either FF 3 or Seamonkey .next
[20:23] <lifeless> jam-laptop: right
[20:23] <jam-laptop> something like that
[20:24] <Peng> Lo-lan-do: There's an hg mirror of the main CVS repo. I think a couple smaller Mozilla projects are primarily using hg.
[20:24] <lifeless> so we could set last_entry_index to 0 when the last_block_index changes
[20:24] <Peng> (Tamarin.)
[20:24] <jam-laptop> lifeless: but don't you "last_entry_index + 1" ?
[20:24] <jam-laptop> So really you want it -1
[20:24] <jam-laptop> Though the code I saw fails
[20:24] <jam-laptop> if you are the first entry
[20:24] <jam-laptop> or the last entry
[20:24] <jam-laptop> because of IndexError
[20:25] <jam-laptop> Which could actually hurt performance
[20:25] <jam-laptop> because you have an exception stack
[20:25] <jam-laptop> that gets created
[20:25] <lifeless> it only fails on first
[20:25] <lifeless> not on last
[20:25] <lifeless> because I didn't plan on seeding it this way
[20:25] <jam-laptop> I thought I saw
[20:25] <jam-laptop> entry_index = last_index + 1
[20:25] <jam-laptop> ...
[20:25] <lifeless> it is
[20:26] <jam-laptop> And then later it does
[20:26] <jam-laptop> if (key > block[entry-1] and key <= block[entry])
[20:26] <jam-laptop> which should fail on the last
[20:26] <jam-laptop> well, at least when it goes past the end of the block
[20:26] <lifeless> which is the first entry on the next block
[20:26] <lifeless> which is a miss anyway
[20:27] <jam-laptop> sure
[20:27] <jam-laptop> you might consider just adding a simple counter
[20:27] <jam-laptop> to see how many queries hit there
[20:27] <jam-laptop> rather than going to the next
[20:28] <lifeless> I did in testing it
[20:28] <lifeless> it was something I felt the cost of an if() to keep it there was not worth
[20:28] <jam-laptop> sure, I wouldn't leave it in for production
[20:28] <jam-laptop> just to get a feeling for what the hit rate was
[20:30] <jam-laptop> lifeless:  but I fully agree that lsprof is not perfect
[20:31] <lifeless> I've cover the start case
[20:31] <lifeless> covered
[20:31] <jam-laptop> Specifically: http://dpaste.com/23102/
[20:31] <lifeless> I'll send a new patch if you would like to review
[20:31] <jam-laptop> just doing "bzr test-prof"
[20:31] <jam-laptop> shows the "two_functions" case taking 2x as long as the one function
[20:32] <jam-laptop> under lsprof
[20:32] <jam-laptop> I get 38ms versus 161ms
[20:32] <jam-laptop> or 4x
[20:32] <jam-laptop> though the wall clock time stays about 2x
[20:33] <lifeless> new patch sent
[20:33] <lifeless> yes, 50K function calls with 1 param is about 15ms
[20:34] <lifeless> I find timeit is very good at this ;)
[20:34] <jam-laptop> http://dpaste.com/23105/
[20:34] <lifeless> hang on while I swtich to a machine with a browser
[20:36] <jam-laptop> first paste is a plugin
[20:36] <jam-laptop> second paste is the timing
[20:37] <fullermd> jam-laptop: If you're looking at critical, 114615 isn't marked critical, but I kinda think it should be...
[20:37] <jam-laptop> bug 114615
[20:37] <ubotu> Launchpad bug 114615 in bzr "Commit can fail and corrupt tree state after encountering some merge/conflicts" [High,Confirmed] https://launchpad.net/bugs/114615
[20:37] <dato> lifeless: (you can wget -qO- dpaste.com/123/text)
[20:38] <jam-laptop> yeah, I wanted to follow up with that one and see if it should be critical
[20:38] <lifeless> dato: yah
[20:38] <dato> lifeless: (sorry, s/text/plain/)
[20:38] <lifeless> dato: but its easier to move for a bit
[20:38] <dato> what fits you best :)
[20:39] <jam-laptop> fullermd: does your test case do something significantly different from mine?
[20:39] <jam-laptop> (I can see that mine is still reproducible in bzr.dev, though, which might be enough to go on)
[20:40] <fullermd> Not sure.  Back when you posted yours, the bug was just (or at least, seemed to just) weird out commit once, then work fine.
[20:40] <fullermd> My later one was where it started marking files as deleted   :(
[20:40] <fullermd> I dunno if that's just that we didn't hit that particular case before, or something in the code changed since we first looked at it.
[20:42] <jam-laptop> fullermd: yeah, mine doesn't break "bzr status" like yours does
[20:43] <fullermd> Yah.  Nobody else would be nutso enough to setup situations like that one   :p
[20:43] <vila> hi all
[20:44] <fullermd> (well, 'stat' isn't broken; it's showing exactly what it thinks is happening.  I found the bug by finding a couple revs later that the file had been deleted by commit)
[20:47] <jam-laptop> fullermd: true
[20:49] <fullermd> In a sense, it's not really data _loss_, since you can just revert the file and get it back.  But it's pretty freakin' scary to see happen to your tree...
[20:53] <lifeless> jam-laptop: so, what do you think of my updated cache ? Good to go ?
[20:55] <jam-laptop> I don't see how it is going to hit the first entry on the next pass
[20:55] <jam-laptop> considering that you will have
[20:55] <jam-laptop> entry = -1 + 1
[20:55] <jam-laptop> block[entry -1]
[20:55] <lifeless> which is 0
[20:55] <jam-laptop> which will be an index error
[20:55] <jam-laptop> or it will give you block[-1]
[20:55] <jam-laptop> which is *really* not what you want
[20:55] <lifeless> if (entry > 0 and block[entry - 1])
[20:56] <lifeless> more precisely, this is the line
[20:56] <lifeless> +                if ((entry_index > 0 and block[entry_index - 1][0] < key) and
[20:56] <lifeless> which only looks at entry_index - 1 if entry_index is 1 or more
[20:57] <jam-laptop> ok, I missed the nesting
[20:57] <jam-laptop> lifeless: I would prefer: present = (block[entry_index][0] == key)
[20:58] <jam-laptop> Though otherwise I think I approved the previous implementation
[20:58] <jam-laptop> and you only changed 1 think
[20:58] <jam-laptop> thing
[20:58] <lifeless> yes you did
[20:58] <lifeless> so I'm asking about the delta
[20:58] <jam-laptop> well if the delta is just using -1 instead of none
[20:58] <lifeless> but I'll add a () around present for you
[20:58] <jam-laptop> bb:approve
[20:58] <lifeless> its assign last_entry_index to -1 when we assign last_block_index
[20:58] <lifeless> and change that one if block line
[20:59] <jam-laptop> lifeless: maybe add a comment about why you are using -1?
[20:59] <jam-laptop> Just a simple
[20:59] <jam-laptop> # setting to -1 since we are likely to ask for the first record next
[20:59] <jam-laptop> or something along those lines
[21:00] <jam-laptop> since we just had the conversation
[21:00] <jam-laptop> I understand what is going on
[21:00] <jam-laptop> but I realize I'll probably forget in a couple months
[21:00] <lifeless>         # Reset the entry index cache to the beginning of the block.
[21:01] <lifeless> ok ?
[21:01] <jam-laptop> sounds good
[21:01] <jam-laptop> I don't know if we want a comment where they are defined
[21:01] <jam-laptop> discussing the basic use case
[21:01] <lifeless> I'll do that while we're here.
[21:01] <jam-laptop> (going linearly through the data)
[21:01] <jam-laptop> and that this is meant to speed up searching for the *next* entry
[21:03] <lifeless>         # These two attributes provide a simple cache for lookups into the
[21:03] <lifeless>         # dirstate in-memory vectors. By probing respectively for the last
[21:03] <lifeless>         # block, and for the next entry, we save nearly 2 bisections per path
[21:03] <lifeless>         # during commit.
[21:04] <jam-laptop> lifeless: good enough
[21:04] <jam-laptop> go for it
[21:05] <lifeless> thanks
[21:26] <vila> bzr revert --no-backup
[21:27] <vila> wrong window :) err right keyboard but not redirected to the right PC to be exact :)
[21:28] <fullermd> Could be worse.  You could be meaning to type that _here_, and do it in the wrong window...
[21:28] <lifeless> heh
[21:29] <jam-laptop> vila: I thought you were just trying to cover up a post you didn't mean to make
[21:29] <vila> jam-laptop: check your mail :) I was just reverting the part I talk about :)
[21:30] <jam-laptop> ah
[21:30] <jam-laptop> yeah, I responded to you
[21:30] <jam-laptop> Would it be possible to put a check like that in permanently?
[21:30] <jam-laptop> vila: ^^
[21:31] <vila> host empty ? I just have to diagnose the smart smoke test part, I fixed the other cases
[21:31] <vila> but I didn't touch anything else
[21:32] <lifeless> we really need to fix urlparse
[21:32] <vila> lifeless: agree
[21:32] <lifeless> nfs+trace+http+urlib://
[21:32] <vila> a simple foo://user@host is enough to make it go nuts
[21:33] <vila> for any foo that is not a known scheme :)
[21:36] <jam-laptop> vila: for some reason urlparse feels that most protocols are not netloc style
[21:36] <jam-laptop> while *we* feel that most *are*
[21:36] <jam-laptop> and it would be more reasonable to register non-netloc protocols
[21:36] <jam-laptop> I suppose it would be different
[21:36] <jam-laptop> if we wanted to support
[21:36] <jam-laptop> file:foo
[21:36] <jam-laptop> or
[21:36] <jam-laptop> file:/path
[21:36] <jam-laptop> rather than file:///path
[21:37] <jam-laptop> we are fairly strict on what type of url we support
[21:38] <vila> jam-laptop: yes
[21:39] <lifeless> jam-laptop: file:foo is not valid. phone: is :)
[21:40] <jam-laptop> well, I *think* that FF and IE will let you type file:foo in the URL and do something with it
[21:40] <jam-laptop> at the minimum
[21:40] <jam-laptop> file:/foo
[21:40] <jam-laptop> should work
[21:40] <jam-laptop> which *we* do not support
[21:41] <lifeless> file:/foo should not work according to std66
[21:43] <vila> lifeless: what is std66, that the second time I run across that reference today ?
[21:44] <vila> yeah, ok, google told me :)
[21:46] <jam-laptop> lifeless: try typing file:/tmp into a browser
[21:46] <jam-laptop> I'm pretty sure it will work just fine
[21:47] <jam-laptop> (I just tested it. and it just renamed it to file:///tmp, but still worked)
[21:47] <vila> I think you both agree :)
[21:47] <lifeless> jam-laptop: crackheadedheuristicsforthewin
[21:48] <jam-laptop> well, browser's have a long culture of DWIM
[21:48] <jam-laptop> considering page reflows
[21:48] <jam-laptop> and "gracefully" handling bad html
[21:49] <vila> jam-laptop: your browser is telling you in a very subliminal way: "Thou Should Fix #123363"
[21:49] <jam-laptop> bug #123363
[21:49] <ubotu> Launchpad bug 123363 in bzr "selftest pollutes /tmp" [Medium,Confirmed] https://launchpad.net/bugs/123363
[21:50] <vila> ubotu, you obviously miss the joke...
[21:56] <lifeless> anyhow
[21:56] <lifeless> brb
[22:03] <lifeless> back
[22:24] <jam-laptop> vila: your last commit was "hhtp" again
[22:24] <jam-laptop> "Make hhtp proxy aware of ..."
[22:25] <vila> LOL
[22:25] <vila> time to go to sleep then :P
[22:25] <jam-laptop> vila: sleep well
[22:25] <jam-laptop> need me to sing a lullaby?
[22:25] <lifeless> nice vila
[22:25] <jam-laptop> I'm getting pretty good at them
[22:25] <lifeless> gnight
[22:25] <lifeless> jam-laptop: :)
[22:25] <vila> thanks for the heads up, I was about to resolve conflicts in smtp_connection, better to that with a fresh mind :)
[22:25] <lifeless> jam-laptop: so, do you have time perhaps, to do the revspec bug I filed ?
[22:26] <lifeless> its not inside the 'make commit fast' envelope, but its really annoying ;)
[22:27] <jam-laptop> lifeless: well, not tonight :) I'm working hard against bug #114615
[22:27] <ubotu> Launchpad bug 114615 in bzr "Commit can fail and corrupt tree state after encountering some merge/conflicts" [High,Confirmed] https://launchpad.net/bugs/114615
[22:27] <lifeless> jam-laptop: ok
[22:27] <jam-laptop> but I can look at bug #154204 tomorrow
[22:27] <ubotu> Launchpad bug 154204 in bzr "revision specs do not lock branches appropriately." [Critical,Triaged] https://launchpad.net/bugs/154204
[22:28] <lifeless> bah corruption
[22:28] <jam-laptop> (that is the one you are talking about, right?)
[22:28] <lifeless> yes, it
[22:28] <lifeless> ...
[22:28] <lifeless> is
[22:28] <mdke> jelmer: thanks for asking. I didn't have any more opportunity to try it; I tried it on a faster machine but it gave me ca-cert errors... weird because the machine has the same configuration as this one
[22:28] <jam-laptop> This is an odd case, where because of a conflict you can get some weird tree states
[22:28] <jam-laptop> Like I just renamed a file back to its original location
[22:28] <jam-laptop> and I get:
[22:29] <jam-laptop> ('a', 'n.OTHER', ...), ('r', 'a/n', ...), ('a', ...), ('r', 'a/n', ...)
[22:29] <jam-laptop> Or if your dirstate parser is rusty
[22:29] <jam-laptop> it says that the file a/n.OTHER
[22:29] <jam-laptop> is renamed to 'a/n' in THIS
[22:29] <jam-laptop> and absent in the base
[22:30] <jam-laptop> and renamed to 'a/n' in the other parent
[22:30] <jam-laptop> (aka, it doesn't exist anywhere, but still has an entry.)
[22:34] <lifeless> hmm
[22:34] <lifeless> so rename is failing to change the 'a' back to 'f'
[22:35] <jam-laptop> well, this is the "temporary" file that the merge conflict generates
[22:35] <jam-laptop> (n.OTHER)
[22:35] <lifeless> yah
[22:36] <lifeless> so this suggests to me a general rename bug
[22:36] <jam-laptop> so what it *should* do is just recognize it as an absent row
[22:36] <jam-laptop> and nuke it
[22:36] <lifeless> that renaming, when it is the last reference to a path, is remove it
[22:36] <lifeless> right, we're agreed.
[22:36] <jam-laptop> I don't know that it is the bug under question
[22:36] <jam-laptop> but it is a weird one
[22:39] <fullermd> Well, in Internet Years, dirstate is approaching the age where it starts "experimenting" with recreational chemicals, so...
[22:45] <jam-laptop> lifeless: are you trying to get to the point that we don't need to build inventories during commit?
[22:45] <jam-laptop> (or is that quite a way off?)
[22:47] <lifeless> I'm going to see about getting rid of the wt inventory during commit
[22:47] <lifeless> basis inventory removal is a tad further off
[22:50] <nDuff> lifeless: bzr-packs has some impressive performance characteristics.
[22:50] <nDuff> lifeless: considerably faster than mercurial in some scenarios, and only slightly slower in others.
[22:50] <lifeless> nDuff: Thats excellent news.
[22:50] <jam-laptop> lifeless: any idea how to detect the record_entry_contents API breakage?
[22:51] <jam-laptop> (You now have an extra parameter)
[22:51] <lifeless> nDuff: We found a serious performance bug in extracting texts yesterday, 30% win for large binaries, may help you there too.
[22:51] <jam-laptop> I'm trying to update cvsps
[22:51] <jam-laptop> cvsps-import
[22:51] <jam-laptop> and I would like it to work with both pre 0.92
[22:51] <jam-laptop> and 0.92
[22:51] <lifeless> jam-laptop: Uhm, look at bzrlib.version_info is probably best.
[22:51] <lifeless> commit is going to be in flux for at least one more release though
[22:52] <jam-laptop> well, I would technically like to work with bzr.dev pre and post fix, too
[22:52] <lifeless> nDuff: (the fix for that is in my repository branch)
[22:52] <jam-laptop> oh, and that api break isn't mentioned in NEWS
[22:52] <jam-laptop> you talk about a *different* api break
[22:52] <jam-laptop> (requiring the root node)
[22:52] <jam-laptop> but not that the number of parameters changed
[22:52] <jam-laptop> lifeless: for the large files, didn't you get that merged?
[22:52] <lifeless> heh, sorry
[22:52] <lifeless> jam-laptop: it is merged, nDuff is testing packs though
[22:52] <jam-laptop> ah, ok
[22:53] <nDuff> lifeless: http://people.ubuntu.com/~robertc/baz2.0/repository/ ?
[22:53] <lifeless> yup
[22:54] <lifeless> it shows up when applying long delta chains
[22:54] <lifeless> basically we did 3 list clones - newlist = oldlist[:]
[22:54] <lifeless> which on files with many \n's leads to thousands of object reference-dereference pairs per delta in the delta chain
[22:55] <lifeless> so a file that has been altered hundreds of times does millions of unneeded object reference pairs
[22:57] <mdke> jelmer: ok, so now svn-import gives me "Invalid revision id {None} in SvnRepository"
[22:59] <jelmer> mdke: what version of bzr-svn? afaik that was a bug fixed in 0.4.2 or 0.4.3
[23:00] <mdke> jelmer: 0.4.1-1 (gutsy)
[23:00] <lifeless> nDuff: I'd be interested in knowing where we were slow, so we can fix that too.
[23:01] <jelmer> mdke: .debs of newer versions are available in debian, http://packages.debian.org/sid/bzr-svn
[23:01] <mdke> jelmer: should I install a later version? is your repository the most reliable one?
[23:02] <mdke> ah, ok
[23:02] <mdke> jelmer: no idea about the ca-cert error I had on the other computer, I guess?
[23:03] <jelmer> mdke: depends on the error
[23:03] <jelmer> mdke: prefixing the url with "svn+" may help
[23:03] <mdke> "server certificate verification failed"
[23:03] <jelmer> does "svn ls <url>" work?
[23:04] <lifeless> jelmer: do you have some debugging notes?
[23:04] <jelmer> lifeless: for what specifically?
[23:04] <mdke> yeah, svn ls works
[23:04] <lifeless> for e.g. me to point e.g. mdke at
[23:04] <lifeless> currently you're really the only person able to help users.
[23:06] <jelmer> there's the FAQ that is going to be part of 0.4.4
[23:07] <nDuff> lifeless: let me get all my results together. there are a few places where I was less rigorous about recording them than I should have been.
[23:08] <jelmer> lifeless: that, and the list of known bugs
[23:09] <lifeless> nDuff: sure, not meaning to put you on the spot in any way. Knowing the envelope you're working on and where it was slow is all. If you find particular ops slow please also feel free to mail me a callgrind for that run
[23:09] <nDuff> lifeless: just threw an exception checking out your branch; see http://pastebin.com/m41646d13
[23:09] <lifeless> nDuff: e.g. 'bzr --lsprof-file foo.callgrind command thing thing'
[23:09] <jelmer> mdke: so, prefixing the url with "svn+" should fix the error then
[23:09] <lifeless> nDuff: ok, thats the bad index in that repo; known issue - I have a fixed copy, one sec.
[23:10] <lifeless> nDuff: http://people.ubuntu.com/~robertc/pack-repository.knits
[23:10] <lifeless> nDuff: ^ that has all the code too, and is probably the one you pulled initially.
[23:11] <jelmer> lifeless: btw, any news on pqm for bzr-gtk/my pqm merge requests?
[23:11] <lifeless> sorry no
[23:12] <lifeless> haven't forgotten, just had no cycles
[23:12] <mdke> jelmer: right. I'm going to put another one on, leave it overnight and see what happens in the morning
[23:13] <jelmer> lifeless: no hurries, just making sure it doesn't drop off your todo list :-)
[23:13] <lifeless> kk
[23:13] <jelmer> mdke: with a newer version ?
[23:13] <mdke> yes
[23:13] <mdke> jelmer: incidentally, since you're here, I'll just ask - if it all goes well, do I get separate bzr branches for trunk and each svn branch? or a single bzr branch? I don't understand the explanation in bzr help svn-import about what --all and --standalone do
[23:14] <jelmer> mdke: yes, you will
[23:14] <mdke> great
[23:14] <mdke> ok, it seems to be getting on with the first branch already, splendid
[23:14] <jelmer> mdke: --all is about importing revisions that were part of historic branches that have since been removed
[23:14] <jelmer> mdke: --standalone is basically about not using a shared bzr repository
[23:14] <mdke> ah, perhaps I wanted that
[23:15] <jelmer> --standalone will blow up the amount of disk space required
[23:15] <mdke> LP doesn't support shared bzr repositories, does it?
[23:15] <jelmer> it doesn't, but you can push from a shared bzr repository to launchpad without problems
[23:16] <mdke> so I can do the import now without --standalone and then create separate branches by pushing them to launchpad?
[23:16] <jelmer> when using a shared repository you'll also have separate branches
[23:16] <jelmer> but yes
[23:16] <mdke> ok. sorry if I don't understand the concepts very well
[23:17] <mdke> the aim is to have LP host branches centrally that the team can access, as long as I can achieve that, I'm happy
[23:17] <lifeless> mdke: so branch is a line of development
[23:17] <lifeless> mdke: repository is physical storage for historical data
[23:18] <lifeless> mdke: every branch has to have a repository available to store its data; either one per branch, which we call standalone branches, or one shared across many branches, which we call a shared repository
[23:18] <mdke> very clear
[23:18] <mdke> and I can use my shared repository to push standalone branches to Launchpad?
[23:18] <mdke> or not?
[23:19] <lifeless> yes, because branch and repository are orthogonal cocepts
[23:19] <lifeless> *concepts*
[23:19] <lifeless> a branch is a branch
[23:19] <lifeless> so you can push a branch from your shared repo to launchpad, and vice verca
[23:19] <mdke> so when I upload a branch from the shared repo to LP, it will take the historical data relevant to it and store it in a standalone branch?
[23:19] <lifeless> yes
[23:20] <mdke> great.
[23:20] <mdke> so essentially the history doesn't get lost either way, whether I import it with --standalone or not
[23:20] <lifeless> right
[23:21] <lifeless> its just much more efficient in terms of disk storage without --standalone
[23:21] <mdke> thanks, and sorry for being a bit slow, but I wanted to make absolutely sure
[23:21] <mdke> ok, we'll see where it gets to overnight. possibly I'll have to leave it to work for some time :D
[23:22] <mdke> thanks for all the help, both
[23:27] <nDuff> interesting.
[23:27] <lifeless> jam-laptop: looks like we need a tree.iter_entries_by_dir
[23:27] <lifeless> that supports file id filtering
[23:27] <nDuff> lifeless: why would an uncommit+recommit take considerably less CPU time than the initial commit?
[23:29] <lifeless> nDuff: the recommit step ?
[23:29] <lifeless> or the two combined ?. Anyhow, no matter - it shouldn't. Unless the hash cache was empty on the first commit
[23:30] <nDuff> lifeless: hmm. initial commit was ~15min of CPU time; the recommit was ~2m wall-clock. wrt the cache in question -- would it be populated by a "bzr status"?
[23:30] <lifeless> yes
[23:31] <lifeless> 15 mins of CPU to 2 is quite remarkable
[23:31] <nDuff> hrm; even when it's needing to repopulate the cache, a bzr status isn't taking nearly 13 minutes.
[23:32] <lifeless> thats really quite bizarre, no pun intended. If you find yourself able to reproduce, a callgraph of it would be wonderful
[23:39] <igc> morning all
[23:41] <lifeless> moin
[23:41] <lifeless> I replied to your graph patch review


[06:09] <coz_> HAPPY NEW YEAR ALL !
[03:12] <klepas> kwwii: ping
[03:12] <kwwii> klepas: hi
[03:13] <klepas> what's going to happen in regard to 1px borders on the 16x & 22px icons in Oxygen?
[03:13] <kwwii> klepas: not much, I guess
[03:13] <klepas> i'm out of the loop in regards to Oxygen, figured i'd ask you rather than pop a possibly stupid question over the ml
[03:13] <kwwii> hehe
[03:13] <klepas> so no 1px borders?
[03:13] <kwwii> well, we are thinking about it, but it nothing has been decided yet
[03:14] <kwwii> I am not sure whether it will happen or not
[03:14] <klepas> *nod*
[03:14] <kwwii> when we started the set, we have black borders around them
[03:14] <kwwii> and then we removed them
[03:14] <kwwii> so going back to using them might take a while
[03:14] <kwwii> anyway, we are thinking about not using 16x16 icons anymore
[03:15] <klepas> although you probably know this, they don't need to be black :-)
[03:15] <kwwii> yeah
[03:15] <klepas> no 16px icons?
[03:15] <kwwii> if it were to happen, I guess we would add a very light border
[03:15] <kwwii> yepp
[03:15] <kwwii> :p
[03:15] <klepas> other than for folders in a file browser
[03:15] <kwwii> we would still make them, for certain things
[03:16] <klepas> i use 16px desktop wide
[03:16] <kwwii> but in general they would no longer be used in most thing
[03:16] <kwwii> s
[03:16] <klepas> maximizes working space
[03:16] <kwwii> ouch
[03:16] <kwwii> how big is your monitor?
[03:16] <klepas> i find it brilliant
[03:16] <klepas> 1680x1050
[03:16] <kwwii> wow
[03:16] <kwwii> well, in kde4 we are moving one size up for almost everything
[03:17] <klepas> i know all the icons, where what is and what they do mostly off by heart for the apps i use the most
[03:17] <klepas> what prompted that?
[03:17] <kwwii> we had a long discussion - but nothing is certain yet
[03:17] <kwwii> we will still have and use 16px icons
[03:17] <kwwii> but not per defualt
[03:18] <kwwii> well, a few will always be needed per defualt
[03:18] <mhb> kwwii: how big your monitor must be in order to ditch 16^2 icons?
[03:18] <kwwii> mhb: that is not really the point, I was just wondering if he had a small monitor since he said he like to maximize the space
[03:19] <klepas> if i was on a 1920x1200 i'd still do what i do now
[03:19] <kwwii> mainly, 16px icons are used for menus and in the filebrowser
[03:19] <klepas> i love it
[03:19] <klepas> those are, i find, still normally 22px at minimum by default under KDE and GNOME
[03:19] <kwwii> so until now the biggest change is that we want to use 22x22 in the menus
[03:20] <klepas> whoa...
[03:20] <klepas> have you guys mocked up Konq's interface with those?
[03:20] <kwwii> actually, there is little difference in size of the menus because we are changing the spacing as well
[03:20] <klepas> i think seeing some potential shots of how it would look like are (a) good (turnoff)
[03:20] <kwwii> we have test code which we changed and it works and looks nice
[03:21] <klepas> what about the text?
[03:21] <klepas> are you going to increase the default desktop font size too?
[03:21] <kwwii> the text stays the same
[03:21] <klepas> that's quite weird... then with the suddenly larger icons?
[03:21] <kwwii> basically in the menus we reduced the spacing around the icons
[03:22] <klepas> so now they are more cluttered?
[03:22] <kwwii> again, none of this is "decided" only in testing
[03:22] <klepas> sorry, i'm not meaning to give you a bashing or anything -- it just seems like a strange decision that i find is unecessary
[03:22] <kwwii> the thing is, you do not really see them as being cluttered
[03:23] <klepas> i haven't seen how it all looks like with the changes being proposed but although it personally sounds not like an improvement, i can't see it's purpose
[03:23] <kwwii> look at osx and see how many 16px icons they use
[03:24] <kwwii> almost none
[03:24] <klepas> fsck osx
[03:24] <kwwii> hehehe
[03:24] <kwwii> it is the nicest looking dekstop around
[03:24] <kwwii> and almost everyone agrees on that
[03:24] <klepas> last time i checked, and i posted this on the ml recently too: no free software project should just model themselves after osx
[03:24] <klepas> unless there was dedicated to do that
[03:24] <kwwii> but again, we'll test and test again before anything is final
[03:25] <klepas> i'd love to see some screenshots
[03:25] <kwwii> oh, we are not doing that at all...just trying to make the nicest looking desktop we can :-)
[03:25] <klepas> (by looking at what osx do and if it's pretty model it? is the question that's going around though... =\ )
[03:26] <TheSheep> actually osx is becoming old slowly
[03:26] <kwwii> once we get that far, I am sure that there will be lots of discussion and such
[03:26] <kwwii> TheSheep: yeah, you are right there too
[03:26] <TheSheep> it's better to be a step ahead :)
[03:26] <klepas> behind...
[03:26] <klepas> osx :)
[03:27] <klepas> (in it's shadows...)
[03:27] <klepas> sorry
[03:27] <klepas> :)
[03:27] <klepas> kwwii: is there a chance you could shoot me a link to some screenshots or something of the sort?
[03:28] <kwwii> klepas: if I had any, or had code to do it, i would, but I do not
[03:29] <kwwii> it is a long way from reality
[03:29] <kwwii> a long, long way
[03:29] <kwwii> one dev tried it out to see how much of a problem it would be
[03:34] <kwwii> sometime in the next couple of months we will put a usability test online, which everyone can take part it
[03:34] <kwwii> s/it/in
[03:34] <klepas> there's a brilliant idea
[03:35] <kwwii> it will help us form a good idea of what everyone thinks, not just a few artists or devs ;-)
[03:35] <msikma> TheSheep: if you think you can be one step ahead, design-wise, of commercial systems, especially the likes of Mac OS X, then good luck.
[03:35] <kwwii> msikma: well put
[03:36] <kwwii> I wonder how much money apple or win puts into the design of their respective desktops
[03:36] <msikma> I'm not saying it's impossible, but you must consider the fact that a large team of dedicated and seasoned designers have worked on it for a long time.
[03:36] <klepas> i just don't see why Mac OS X is always the one that work is being compared to
[03:36] <TheSheep> msikma: you can rip from them and extend :)
[03:36] <kwwii> TheSheep: but that is not really getting ahead
[03:36] <kwwii> just going around
[03:37] <klepas> i don't doubt that Apple has spent a large sum of money on the design work... i just dislike the attitude of "it's what mac does"
[03:37] <TheSheep> msikma: I see a problem with the fact that they are designers (artists) not cognitive psychologists and ui specialists (scientists)
[03:37] <klepas> as a justification of choices in design
[03:37] <msikma> kwwii: I think they put a lot more money in it than Microsoft. It's difficult to change the theme in Mac OS X, and you need to resort to hacks to do that. There's no alternative except making all blue look grey. They are really, really concerned with making sure people can't mess up their interface
[03:37] <msikma> TheSheep: do you really think that Apple hasn't hired a whole team of usability experts?
[03:38] <TheSheep> msikma: I'm pretty sure they fired a large number of them recently
[03:38] <msikma> "Pretty sure"?
[03:38] <klepas> if the designer can't justify the choice they've made without saying "it's what mac does" then there is a preblem
[03:38] <msikma> So that's a reason for doubting the process of a major company who puts design first? I don't find that very constructive, personally.
[03:39] <kwwii> klepas: I was just pointing out that one of the two major desktops does it that way, not saying we want to do it like mac :-)
[03:39] <klepas> well considering we don't know much about the insides of Apple, i think a designer shouldn't go "it's what they do, and they are very knowledgably about that they do, so i copied them"
[03:39] <TheSheep> msikma: there are a lot of very dedicated ui design proffessionals who will gladly give hints and pointers to anyone willing to implement their ideas -- because most ui designers are kinda evangelical about good interface -- they want it done
[03:39] <kwwii> we are not copying them or anyone
[03:40] <klepas> it's more of a matter of "they did it" as a justification
[03:41] <msikma> TheSheep: that's not really a reply to what I was saying.
[03:41] <kwwii> no, it is a matter of "they did it" so I guess we can test the idea we have - the implementation is totally different anyway
[03:41] <msikma> Unless you were adding that to your statement about Apple firing UI designers.
[03:42] <TheSheep> msikma: sorry, I don;t type as fast as you, it's a reply to your lines from 5 lines ago :)
[03:42] <kwwii> we have never gone further than thinking we would like to test it before
[03:42] <msikma> Anyway, the Mac OS X interface is far from perfect.
[03:43] <msikma> In my opinion, there's one glaring mistake, which is the resizing of windows. I mean, why is there a 16x16 hotspot?
[03:44] <msikma> There are other things too. But generally, I find it a very good interface, though recently suffering from some consistency problems.
[03:44] <kwwii> msikma: not sure if I understand you
[03:44] <msikma> kwwii: you can only resize windows in the bottom-right corner in Mac OS X.
[03:44] <kwwii> ahh, now I get it
[03:44] <msikma> Even with the "metal" skin that implements thick window borders.
[03:44] <kwwii> I used mac before anything else, so for me it was not very wierd
[03:44] <msikma> Yeah
[03:45] <msikma> I can kinda get why it was that way back on the G line of processors.
[03:45] <msikma> It was "just the way it was", with respect to old applications that still had to remain functional.
[03:45] <kwwii> I think it is a matter of them trying to keep things simple to an extreme these days
[03:45] <msikma> But with the Intel switch, they surely could have done something to change it.
[03:46] <msikma> Maybe. They mainly seem to be targeting switchers from Windows these days.
[03:46] <TheSheep> I've recently read the apple's HIG. All they care about is how many pixels is between this button and that border.
[03:46] <msikma> Then it would make sense to implement proper resizing, from all sides of the window.
[03:47] <kwwii> yeah
[03:47] <msikma> TheSheep: HIGs are guidelines for application developers, so it's certainly no surprise that they aren't talking about their design decisions in there. That's proprietary to them.
[03:48] <msikma> I'm pretty sure that leaking that sort of information will get you a suit based on violating trade secrets.
[03:48] <TheSheep> msikma: but they could say "use buttons for this, tabs for that and treeview for that"
[03:48] <TheSheep> msikma: compare it with GNOME hig or (shudder) Vista's HIG
[03:49] <msikma> To be honest, I haven't read those.
[03:49] <msikma> I just briefly had a look at them.
[03:49] <TheSheep> msikma: Vista even has a real-live examples taked from newest MS Office "this is how it shoudn't be done"
[03:49] <TheSheep> taken
[03:50] <msikma> I should read the Gnome guidelines. I wonder what they state.
[03:50] <TheSheep> msikma: they make a lot of important UI decissions for you
[03:50] <msikma> Well, that's good.
[03:50] <TheSheep> I think that too.
[03:51] <msikma> I've seen plenty of applications with no thought put into the design at all, so if people were to simply follow such a document, then at least they can get most of it right, given that they're not /complete/ retards.
[03:51] <TheSheep> and consistent
[03:52] <TheSheep> some decissions are arbitrary
[03:52] <TheSheep> like the order of 'ok' and 'cancel' buttons
[03:52] <msikma> Maybe Apple didn't put sufficient effort into their HIG because there is already a lot of design enthusiasm in the Mac community. If you make a bad-looking application on Mac OS X, you simply aren't going to get away with it unless it's a /really/ vital application.
[03:53] <TheSheep> msikma: it seems to me that they are more concerned with looks than with usability
[03:53] <msikma> This is very healthy, I believe, because people aren't going to like it when they notice that their bad design is causing nobody at all to download their program.
[03:54] <msikma> TheSheep: I find that a bold statement. I don't think that this is the case. Usability has always been an important issue for Apple designers. I don't think that they simply don't care.
[03:55] <TheSheep> msikma: yes, but not all developers of mac apps are employees of apple -- they need a HIG that tells more than "how to make your apps look exquisite"
[03:56] <TheSheep> msikma: I'm sure they have some internal documents for that in apple
[03:57] <msikma> I haven't read their HIG, so I can't comment on its contents, but a lacking HIG should not imply that there aren't any other documents online that one may use for a usability reference. That's part of the Mac community, and the important applications that are developed by it are somehow always well-designed, because otherwise they simply don't get any limelight.
[03:57] <TheSheep> msikma: I'd be very glad if you pointed me to some if you find any :)
[03:58] <TheSheep> msikma: I'm not really into mac community, so I simply don't know where to look
[03:58] <msikma> Apple have an entire team to do formal usability tests, so there's no doubt that their internal developers will be paying that much attention to it. They just work, while others design.
[03:58] <msikma> I've never developed a Mac program, so I don't know either.
[03:59] <TheSheep> msikma: what I complain about is that the expert's work remains a secret of apple -- 3rd party developers are at disadvantage
[03:59] <msikma> That could very well be so.
[03:59] <msikma> I'll read their HIG sometime.
[04:00] <TheSheep> it's pretty boring'
[04:00] <TheSheep> :)
[05:07] <plb_> anyone have problems saving svg images in gimp with gimp-svg plugin installed?
[05:07] <plb_> I can open but not save
[05:17] <TheSheep> plb_: isn't that normal?
[05:18] <TheSheep> plb_: I mean, the svg plugin *imports* the svg file as a raster
[05:18] <TheSheep> plb_: no way to convert that back into vectors
[05:20] <plb_> ah
[05:20] <TheSheep> plb_: use Inkscape to edit svg files
[05:21] <plb_> Yeah, I've been trying to do that lol...never really used it before
[05:21] <plb_> I'm trying to make color variations of the ubuntu logo
[05:22] <plb_> in gimp I just adjust hue or color easily
[05:22] <plb_> inkscape I'm not really sure
[05:23] <TheSheep> well, vector images work a litle bit differently
[05:23] <plb_> I see
[05:24] <TheSheep> plb_: I think you could overlay a colorized, half-opaque outline of the logo, for the quickest effect...
[05:24] <plb_> how do I go about that?
[05:25] <TheSheep> plb_: copy the whole logo, and sum it into a single path -- then just set a transparent, colorized background to it.
[05:26] <plb_> ok got it copied but how do I sum it to a single path
[05:26] <TheSheep> plb_: there is an option in the menu for that
[05:30] <plb_> hrm I just don't see it
[05:30] <kwwii> path --> union
[05:30] <kwwii> but all elements have to be ungrouped first
[05:31] <TheSheep> :/
[05:31] <TheSheep> sorry, I thought it would be simplier
[05:31] <plb_> heh
[05:31] <kwwii> and doing it that way will only work with slight variations
[05:31] <plb_> ok let me put it this way...I just want a black ubuntu logo lol
[05:31] <TheSheep> plb_: of course *THE& way to do it is to edit the svg file with a text editor and to a substitution on the colors used :)
[05:32] <kwwii> the "correct" way of doing it would be to select the object and then change the actual color of it
[05:32] <kwwii> for each object which makes up the logo
[05:32] <plb_> gimp is so much easier ;]
[05:32] <TheSheep> text editor is faster :)
[05:32] <plb_> heh
[05:33] <kwwii> but you could select the groups and first click on "no fill" (or line) and then add a color for everything
[05:33] <kwwii> grep is your friend :p
[05:33] <kwwii> artwork via sed....ouch
[05:33] <plb_> heh
[05:34] <TheSheep> plb_: svg is an xml format
[05:34] <plb_> forget "created by the gimp" logo...."created by sed"
[05:35] <plb_> ya
[05:36] <plb_> so what are the plans for feisty in terms of art
[05:39] <kwwii> lol
[05:39] <kwwii> good question
[05:39] <kwwii> I'll stick to the easy questions :-)
[05:40] <plb_> heh
[05:42] <TheSheep> I guess the most recent proposition are the amber-like shiny thingies
[05:43] <plb_> huh?
[05:43] <plb_> what is this
[05:44] <TheSheep> plb_: see the wiki
[05:45] <TheSheep> plb_: https://wiki.ubuntu.com/Xubuntu/Artwork/Feisty/Incoming
[05:46] <TheSheep> oops, sorry, wring page
[05:47] <plb_> not bad
[05:48] <TheSheep> https://wiki.ubuntu.com/ubun2design/u2Attic/u2Brainstorm
[05:52] <plb_> going for a whole different look?
[05:53] <TheSheep> https://wiki.ubuntu.com/ubun2design/u2Specifications/u2Brainstorm/u2BuufFull <-- wow!
[05:53] <plb_> yeah, I saw these icons on gnome-look
[05:53] <plb_> buuf
[05:53] <TheSheep> love them
[05:54] <plb_> are they going to be the default ones for feisty for something
[05:54] <plb_> s/for/or
[05:55] <TheSheep> I don't think so, they are posted as an example of organic look
[05:55] <plb_> Mark should just mattahan to do a custom ubuntu iconset if he likes them so much ;]
[05:55] <plb_> get*
[05:55] <plb_> pay*
[05:55] <plb_> lol
[05:55] <mhb> well
[05:56] <mhb> I guess they won't become default. Ever.
[05:56] <TheSheep> yeah, they don't scale well and have some accesibility problems :)
[05:56] <plb_> I like tango personally ;]
[05:57] <TheSheep> tango's nice as a standard
[05:57] <TheSheep> but pretty bleak
[05:57] <mhb> I like most of the icon sets, including Tango, Oxygen and Human.
[05:57] <mhb> but all in a different way
[05:57] <TheSheep> I hate human for the raster directory icon
[05:57] <TheSheep> it's ugly when scaled
[05:58] <plb_> you have seen the new icons for fedora 7?
[05:59] <TheSheep> no
[05:59] <plb_> on gnome-look called echo or something
[05:59] <plb_> not finished though
[05:59] <mhb> if Human were more complete and fully SVG, I would like it more, too.
[06:00] <mhb> Tango is also not very complete - I can't use it on KDE without some icons missing.
[06:00] <TheSheep> mhb: hmm?
[06:01] <TheSheep> mhb: which ones?
[06:03] <plb_> What about metacity/gtk2 theme...going to get changed as well?
[06:03] <TheSheep> plb_: probably
[06:04] <TheSheep> plb_: https://wiki.ubuntu.com/ubun2design/u2Specifications/u2WindowProposals
[06:05] <mhb> TheSheep: not sure now
[06:06] <plb_> I don't like any of that =\\
[06:06] <TheSheep> plb_: me neither
[06:06] <TheSheep> plb_: fortunately, you are free to change them :)
[06:07] <plb_> doesn't look at all professional
[06:07] <TheSheep> I hate the "pearly" window buttons
[06:07] <mhb> TheSheep: no Configure icon (a wrench in Crystal/Oxygen)
[06:08] <TheSheep> blindly copied from macos
[06:08] <TheSheep> mhb: there is the screwdriver and wrench icon
[06:08] <plb_> http://interfacelift.com/themes-mac/details.php?id=61
[06:08] <plb_> yeah basically lol
[06:10] <TheSheep> follow the leader
[06:11] <_MMA_> troy_s: ping
[06:11] <plb_> I really hope Mark doesn't approve any of those metacity themes lol
[06:12] <mhb> TheSheep: yes, but it's sadly not named well so that it can be used in KDE out-of-the-box :o)
[06:12] <mhb> TheSheep: can't find a "Filter View" icon
[06:13] <TheSheep> mhb: well, since it's the Tango that sets the standard, the bug is obviously in KDE
[06:13] <mhb> TheSheep: heh
[06:14] <mhb> TheSheep: yes, you might say that
[06:14] <mhb> TheSheep: but a standard that doesn't work is kind of worthless to me
[06:15] <kwwii> the freedesktop naming spec will be used in kde4, not kde3
[06:15] <kwwii> and we have a list of icon names we need to add
[06:15] <mhb> kwwii: I know
[06:15] <kwwii> mhb: I was offering that info for TheSheep ;-)
[06:15] <mhb> TheSheep: as kwwii says, it may improve in KDE4 :o)
[06:16] <mhb> TheSheep: it's probably either the packager's fault that it doesn't make a few symlinks to make more icons work in KDE3
[06:16] <mhb> TheSheep: (no either, sorry)
[06:17] <plb_> http://www.padmacolors.org/pics/2005060410.jpg
[06:17] <plb_> something like that would be nice for a gtk2 theme for ubuntu
[06:18] <plb_> it's an osx theme but it's quite nice and fitting for ubuntu I think
[06:18] <mhb> TheSheep: but still the Tango Icon Gallery has several blank places
[06:19] <kwwii> plb_: I guess that has usability problems ;-)
[06:19] <kwwii> but anyway...time for dinner
[06:19] <kwwii> bbl
[06:19] <plb_> never used it myself but I think it fits ubuntu nicely
[06:21] <TheSheep> and it's all I need
[06:34] <mhb> TheSheep: yes, _you_ :o)
[06:35] <TheSheep> mhb: fact is that the less an interface element is distracting, the better it is. Best interfaces are not visible at all.
[06:35] <mhb> TheSheep: I wish all Oxygen, Tango and Human would be complete enough to work on KDE4 :o)
[06:36] <TheSheep> mhb: I thinkt that Tango is open to contributions
[06:36] <mhb> TheSheep: and the latter two to work on KDE3, since both are available now
[06:36] <mhb> TheSheep: it is - if only I had time :o)
[06:37] <TheSheep> mhb: is this the 'oxygen' you mean? http://gnome-look.org/content/preview.php?preview=1&id=50716&file1=50716-1.png&file2=50716-2.png&file3=&name=Verglas+Icons+Set+02%3A+Oxygen
[06:38] <mhb> nope
[06:38] <mhb> http://www.oxygen-icons.org/
[06:39] <mhb> http://www.oxygen-icons.org/?cat=3  <-- preview
[06:41] <TheSheep> iteresting
[06:42] <TheSheep> " It is important to represent devices and media storage in a way that user will immediatly recognize them.
[06:42] <TheSheep> lol
[06:42] <TheSheep> and then they draw a "realistic" hdd, as if an average user have ever seen one
[06:46] <troy_s> _mma_ you here?
[06:48] <_MMA_> i am now.
[06:48] <_MMA_> May I PM?
[06:48] <troy_s> absolutely
[07:05] <kwwii> TheSheep: it is more about the printer, and usb hard drives than anything else...kde rarely if ever uses a normal harddrive icon anway :-)
[07:05] <kwwii> cameras, etc. ad nauseum
[07:06] <TheSheep> kwwii: I see
[07:06] <TheSheep> kwwii: not a kde guy, you see :)
[07:06] <kwwii> ;-)
[07:20] <mhb> kwwii: not exactly true
[07:20] <mhb> kwwii: well KDE does not, but Kubuntu does
[07:21] <mhb> kwwii: open /media (if you have Edgy+)
[07:23] <mhb> kwwii: I have one remote and two local partitions there with a hard drive icon
[07:25] <TheSheep> it should be a 'partition icon' ;)
[07:29] <mhb> kwwii: I guess TheSheep may be right. My father can hardly tell what a computer component does (he didn't recognize the RAM card I gave him this Christmas :o)
[07:35] <TheSheep> otoh how do yu draw a partition? :)
[07:36] <mhb> TheSheep: that's the reason why they use a disk metaphor
[07:37] <TheSheep> maybe a file cabinet methaphor woul work better...
[07:37] <TheSheep> the icon is there already
[07:43] <troy_s> Greets TheSheep
[07:43] <troy_s> et mhb
[07:44] <mhb> hi
[07:44] <troy_s> It is worth discussing the metaphors for hardware... we are still using legacy 'files and folders' from bloody xerox star era
[07:45] <troy_s> etc.
[07:46] <TheSheep> I like how Tango pushes it a little farther
[07:46] <TheSheep> not sure about the 'delete' icon, for example
[07:46] <TheSheep> but I guess it's better than a red X
[07:47] <troy_s> Simple X as a symbol might work well.
[07:47] <troy_s> It is a cross between teaching your audience and having the expectation that your audience will know what something means.  The latter is generally folly.
[07:48] <troy_s> As you can never typify something on a global scale.
[07:49] <TheSheep> well, there is this thing called 'affordance'
[07:49] <TheSheep> and it applies to icons too
[07:49] <troy_s> Do you have an art and design education background Sheep?
[07:50] <TheSheep> troy_s: no, I'm an amateur, but I read everything on the subject that I can get my hands on since several years :)
[07:50] <troy_s> That is a lot more than most can say.
[07:50] <troy_s> Affordance is generally more applied to actual physical implementations
[07:50] <troy_s> For example, putting a closed handle on a door implies a pull.
[07:51] <troy_s> Similar I suppose to a 'button' look for something -- implies pushing in an interface.
[07:51] <troy_s> "pushing" rather.
[07:51] <TheSheep> sure, but putting a beveled frame around something implies click :)
[07:51] <TheSheep> right
[07:51] <troy_s> Exactly
[07:51] <troy_s> I agree 100%
[07:51] <TheSheep> then again, there are colors -- "red means stop"
[07:51] <troy_s> Those are cultural centric
[07:51] <troy_s> Unfortunately.
[07:52] <TheSheep> troy_s: well, some are more than others
[07:52] <troy_s> For example, if you compare NA versus say, French walk crossing colours.
[07:52] <TheSheep> troy_s: red/green seems to be pretty instinctive
[07:52] <troy_s> I have a reference somewhere relating to those two very colours...
[07:52] <troy_s> They aren't quite as instinctive as you would like.
[07:52] <TheSheep> troy_s: all the poisonous animals are either red-black, yellow-black or white-black
[07:53] <troy_s> Sounds like someone has read "universal principles of design"
[07:53] <TheSheep> troy_s: high contrast means "watch out"
[07:53] <troy_s> ')
[07:53] <TheSheep> troy_s: nope, didn't read this one
[07:53] <troy_s> Oh you should...
[07:53] <troy_s> great reference.
[07:53] <TheSheep> I will look for it, thanks.
[07:53] <troy_s> But yes, those archetypes are generally evolutionary in nature -- from longstanding traditions.
[07:54] <troy_s> Such as poisonous creatures, etc.
[07:54] <troy_s> Out for a bit... love to chat about that in a bit.
[07:54] <TheSheep> sounds are pretty nice in this regard
[07:55] <TheSheep> great, I'll be waiting here :)
[10:36] <_MMA_> troy_s: Im testing our theme on Feisty. Theres a difference in how the theme is displayed on Edgy vs. Feisty. In Feisty the desktop icons have a color background behind the text where Edgy doesnt.
[10:36] <_MMA_> It uses Murrine. The .deb and theme Im using are the same on Edgy and Feisty. So Im guessing theres something different outside of our packages giving us the difference.


[01:54] <bluesabre> Unit193: thanks, will hopefully get to uploading tomorrow night
[01:54] <bluesabre> IRL schedule is once again weird :P
[01:54] <Unit193> :(
[09:14] <knome> would something like 13UTC be completely undoable for a meeting?
[09:29] <Unit193> During the week that's a bad time for Sean, and a bad time for me as well.