| === medberry is now known as med_out | ||
| === JasonO_ is now known as JasonO | ||
| stewart | hi all! | 07:25 |
|---|---|---|
| stewart | is there a magic "upgrade all launchpad bzr trees for project X to new repo format" button hiding somewhere? | 07:25 |
| stewart | or does the magic sftp "bzr upgrade" work for all that... | 07:25 |
| stewart | and also, any idea what "Standalone tree (format: unnamed)" could possibly mean ? | 07:27 |
| lifeless | it info -v | 07:39 |
| lifeless | bah | 07:39 |
| lifeless | info -v will help you see what it means | 07:39 |
| stewart | ahh.. packs with knits without subtree | 07:41 |
| lifeless | probably an unusual combination of tree/branch/repo | 07:41 |
| Jordan_U | I'm working with the branch http://bzr.savannah.gnu.org/r/grub/trunk/grub/. "bzr log | grep tags:" prints "tags: 1.99" yet "bzr checkout -r tag:1.99 /tmp/grub" fails with "bzr: ERROR: No such tag: 1.99". What am I doing wrong? | 08:10 |
| Jordan_U | Ahh, I see what I did wrong now. | 08:11 |
| Jordan_U | I thought that if ommitted branch location would be the branch corrosponding to the current directory. I guess it's not. | 08:16 |
| LarstiQ | Jordan_U: it will try to check out /tmp/grub in the current location | 08:32 |
| Jordan_U | LarstiQ: Thanks. | 08:32 |
| LarstiQ | Jordan_U: I suspect you might be used to git checkout? | 08:35 |
| Jordan_U | LarstiQ: Yes :) | 08:36 |
| LarstiQ | Jordan_U: yeah, same names unfortunately don't always imply same operation :) | 08:36 |
| Jordan_U | LarstiQ: I actually did read "bzr help checkout" before using it. | 08:37 |
| * LarstiQ shakes a fist at Estonian/Finnish false friends while at it | 08:37 | |
| LarstiQ | Jordan_U: maybe it should be more explicit that one can't supply TO_LOCATION without supplying BRANCH_LOCATION? | 08:38 |
| Jordan_U | LarstiQ: I'd say so. | 08:38 |
| LarstiQ | hmm, not sure how to get the option parser to spit that out | 08:39 |
| * LarstiQ will file a bug and let other people sort it out | 08:43 | |
| dandaman | is there anything for bzr in ubuntu 10.10 like there is for tortoise svn on windows where the UI is your file explorer? | 08:44 |
| Jordan_U | LarstiQ: Thanks. | 08:44 |
| LarstiQ | dandaman: nautilus-bzr exists, don't know if it is on the same level | 08:44 |
| LarstiQ | dandaman: might be packaged in bzr-gtk | 08:45 |
| dandaman | i shall investigate | 08:45 |
| dandaman | i'm not well acquainted with the command line yet(which i'd really like to, but no time) and the explorer ui is garbage | 08:46 |
| * dandaman apologizes if anyone who worked on that is in the channel, just my opinion | 08:46 | |
| dandaman | his* | 08:46 |
| LarstiQ | dandaman: the apology would carry more weight if you gave feedback on why you think that ;P | 08:47 |
| LarstiQ | not that I'm involved | 08:48 |
| dandaman | its just a lot less inferior to a folder explorer UI, less intuitive | 08:49 |
| LarstiQ | dandaman: mkay, that might be taste I suppose | 08:55 |
| LarstiQ | dandaman: found nautilus-bzr yet? | 08:55 |
| dandaman | yeah i installed it | 08:55 |
| dandaman | I'll get it set up when i'm not stoned, and thus be able to read instructions | 08:55 |
| * LarstiQ personally abhors the explorer/nautilus view | 08:55 | |
| LarstiQ | dandaman: hah, ok :) | 08:56 |
| dandaman | really? | 08:56 |
| LarstiQ | yeah | 08:56 |
| dandaman | its so easy to us | 08:56 |
| dandaman | use* | 08:56 |
| LarstiQ | dandaman: how do you quantify easy? :) | 08:56 |
| dandaman | just right click on the file you worked on a second ago and its committed | 08:56 |
| LarstiQ | dandaman: except I don't use a filemanager in my daily workflow to begin with | 08:56 |
| dandaman | barely worry about conflicts because you commit one file at a time | 08:56 |
| dandaman | do you use the command line? | 08:56 |
| LarstiQ | yeah | 08:56 |
| dandaman | well see | 08:57 |
| LarstiQ | and emacs/vi integration | 08:57 |
| dandaman | command line is probably the most efficient | 08:57 |
| LarstiQ | and qbzr | 08:57 |
| dandaman | i just don't exactly have the time to learn how to use it to the point where i'd feel comfortable with it | 08:57 |
| * LarstiQ nods | 08:57 | |
| LarstiQ | that's fair | 08:57 |
| dandaman | after graduation i'll have some time | 08:57 |
| dandaman | and i'm going to learn a whole bunch of stuff i meant to learn on the side | 08:57 |
| dandaman | also, i need to find a place that wants to hire api programmers | 08:58 |
| dandaman | don't know why, but i decided that's what I want to do | 08:58 |
| LarstiQ | Jordan_U: took a while, but: https://bugs.launchpad.net/bzr/+bug/784459 | 09:06 |
| ubot5 | Ubuntu bug 784459 in Bazaar ""bzr help checkout" should make dependence of TO_LOCATION on BRANCH_LOCATION more explicit" [Medium,Confirmed] | 09:06 |
| mgz | morning all! | 09:23 |
| LarstiQ | morning mgz :) | 09:24 |
| mgz | LarstiQ: if you're still interested in the file handles issue for pypy, I have a couple of tools that may help | 09:26 |
| mgz | also, vila and I are going to investigate later today to see if the babune osx and windows issues are also file handle exhaustion related | 09:27 |
| LarstiQ | mgz: yeah | 09:30 |
| LarstiQ | mgz: I have made some notes | 09:30 |
| LarstiQ | and some lacking commits | 09:30 |
| LarstiQ | I'll push the latter | 09:30 |
| LarstiQ | mgz: http://richtlijn.be/~larstiq/DEBUG_NOTES | 09:32 |
| LarstiQ | mgz: and maybe it is useful to put a small test script to demonstrate the generator-with-resources problem | 09:33 |
| LarstiQ | mgz: http://richtlijn.be/~larstiq/halfcon.py | 09:36 |
| LarstiQ | mgz: most fun: enable the pdb line, run the script (cpython or pypy, doesn't matter in this case), note the pid it prints out, run "watch -n 1 'ls -lU /proc/<pid>/fd"; and step through the code | 09:37 |
| LarstiQ | mgz: (not too fast, watch only updates once a second) | 09:37 |
| * jelmer waves | 09:38 | |
| LarstiQ | jelmer: hei jelmer :) | 09:38 |
| jelmer | LarstiQ, dude! | 09:39 |
| LarstiQ | mgz: even with those attempts at cleaning up resources, running `pypy ./bzr selftest -s bt.blackbox` the amount of open files fluctuates. Usually between 700 and 1023 (where we get too many open files) | 09:40 |
| LarstiQ | jelmer: still alive ;) | 09:40 |
| LarstiQ | mgz: I hope the DEBUG_NOTES file is clear? | 09:41 |
| mgz | okay, back from swapping | 09:42 |
| * mgz reads notes | 09:42 | |
| mgz | LarstiQ, so, jam recently added a cleanup in Transport._seek_and_read which is what Transport._readv (always?) calls | 09:45 |
| mgz | are there cases where that codepath with the close isn't being hit? | 09:46 |
| * LarstiQ looks at the code | 09:46 | |
| jam | mgz: LocalTransport should always call _seek_and_read, HTTP and others don't | 09:46 |
| LarstiQ | mgz: where is this cleanup? | 09:46 |
| jam | LarstiQ: try/except/fp.close raise else: fp.close | 09:47 |
| jam | line 718 in bzrlib/transport/__init__.py | 09:47 |
| LarstiQ | jam: that is no good if the generator is not fully consumed | 09:47 |
| jam | mgz: and we can change that back to try/finally now \o/ | 09:47 |
| jam | LarstiQ: generators raise GeneratorExit if they aren't consumed | 09:47 |
| jam | at least in python 2.5+ | 09:47 |
| jam | pypy *should* be doing the same | 09:48 |
| LarstiQ | jam: in what case? | 09:48 |
| LarstiQ | when they're garbage collected? | 09:48 |
| LarstiQ | That may take a while | 09:48 |
| jam | LarstiQ: yes | 09:48 |
| LarstiQ | jam: it _does_ clean them up from time to time, dropping from say 800 to 300 open files | 09:48 |
| LarstiQ | but not fast enough | 09:48 |
| mgz | okay, that sounds fun. | 09:49 |
| jam | LarstiQ: so 1) we can change it to try/finally so it is at least clearer. 2) We can look at changing the StopIteration code black to close them again | 09:49 |
| LarstiQ | jam: the reason I think it is due to not being consumed is that I added debug prints/sys.counter checking, and we were not hitting the final fp.close | 09:49 |
| jam | LarstiQ: http://paste.ubuntu.com/609397/ | 09:50 |
| jam | try that | 09:50 |
| jam | it should allow the file to get closed when its associated iterator is consumed | 09:50 |
| jam | before we yield | 09:50 |
| jam | and it should be pretty rare that we don't access all the readv data | 09:50 |
| mgz | LarstiQ: I also have a record of which testcases in the suite use files and rely on refcount semantics to clean them up, this can also add to your 800 files open scenario | 09:50 |
| mgz | lots of the problems are shallow issues with particular tests | 09:50 |
| jam | it will occasionally happen that we do "zip(X, readv)" and the X stops, so it doesn't even check if the readv is stopped | 09:50 |
| jam | I have another idea, too | 09:50 |
| LarstiQ | jam: that is almost what my code looks like, but I'll try that (the raise might be different) | 09:51 |
| jam | LarstiQ: we don't want the raise there | 09:51 |
| jam | that was a bug in my diff | 09:51 |
| jam | ah, my diff removed it | 09:51 |
| jam | I just read it wrong | 09:51 |
| LarstiQ | mgz: hmm, maybe. But I don't think so | 09:51 |
| mgz | see (warning, big page) http://float.endofinternet.org/xmlbin/newtestresult and click any of the little yellow boxes | 09:51 |
| jam | anyway, you don't have to do that part, but you can | 09:51 |
| jam | except... that's buggy to | 09:52 |
| jam | too | 09:52 |
| jam | it looks like we still iterate c_offset | 09:52 |
| mgz | it's possible pypy can be clever about some of those formulations | 09:52 |
| jam | so closing the file early will bring other bugs | 09:52 |
| jam | let me think about it a bit | 09:52 |
| jam | we should only close the file once we're sure we've read everything | 09:52 |
| jam | ah, nm | 09:53 |
| jam | if offset_stack is empty | 09:53 |
| jam | then we know we're done | 09:53 |
| jam | since we have returned everything the caller asked of us | 09:53 |
| LarstiQ | jam: that fp.close in the StopIteration works wonder | 09:55 |
| * LarstiQ failed to see it the first time :/ | 09:55 | |
| jam | LarstiQ: it used to be there, but we moved it because it is cleaner to have just the try/finally (and doesn't matter much in production code) | 09:56 |
| mgz | that's a little suprising, | 09:56 |
| jam | mgz: I'm not terribly surprised. anything with a lazy garbage collector can be *really* lazy | 09:56 |
| jam | and we do a lot of readv | 09:56 |
| mgz | do lots of callers use the zip idiom and never exhaust the generator? | 09:56 |
| jam | mgz: I wouldn't have thought lots | 09:56 |
| mgz | if so, might want the close there, and try/except/close/raise | 09:56 |
| jam | but if BTreeGraphIndex does | 09:57 |
| jam | that is a pretty core | 09:57 |
| mgz | rather than try/finally | 09:57 |
| jam | mgz: you can always close twice | 09:57 |
| jam | at least with all the objects I tried | 09:57 |
| LarstiQ | but can't close lists | 09:57 |
| mgz | ...that's probably safe | 09:57 |
| jam | LarstiQ: fp should never be a list | 09:57 |
| jam | mgz: note that you *can't* os.close(FID) twice, but that should be safely encapsulated for us | 09:57 |
| LarstiQ | jam: aye, I was referring to the 'if isinstance(data_ranges, types.GeneratorType)' in https://code.launchpad.net/~larstiq/bzr/bzr-pypy/+merge/60986 | 09:58 |
| LarstiQ | since you can explicitly close a generator | 09:58 |
| LarstiQ | since python 2.5 iirc | 09:59 |
| mgz | yup. | 09:59 |
| * LarstiQ is 10% into the blackbox tests and observes a maximum of 37 open files dropping down to 7 every couple of seconds | 10:00 | |
| jam | LarstiQ: so I'd rather not change btree_index unless we have to. | 10:08 |
| jam | it is going to be really rare for btree_index to not get fully consumed | 10:08 |
| jam | I'm guessing what you are running into is actually in pack.py | 10:09 |
| jam | Where when reading disk content | 10:09 |
| LarstiQ | jam: I have no firm grasp on the matter | 10:09 |
| jam | we create a Readv* class | 10:09 |
| jam | which doesn't have StopIteration written anywhere | 10:09 |
| jam | so it is probably never consuming the readv object | 10:09 |
| LarstiQ | jam: right, I pondered a .close method on that | 10:09 |
| LarstiQ | jam: so, shall I uncommit the previous revision, reinstate the close on StopIteration, and push --overwrite? | 10:13 |
| poolie | jam, hi | 10:15 |
| poolie | you can dial in if you like | 10:15 |
| poolie | also i was wondering if it would work for you to benchmark on gcc-linaro rather than a synthetic tree | 10:15 |
| jam | poolie: I'm dialed in | 10:15 |
| jam | just on mute because they are doing construction here | 10:16 |
| jam | poolie: I did it on gcc-linaro | 10:16 |
| LarstiQ | yay, blackbox tests completed with 160 open files max | 10:19 |
| poolie | o/ LarstiQ | 10:19 |
| poolie | great | 10:19 |
| poolie | i wonder if we can add assertion there are no more open files from the start of a test to an end | 10:20 |
| poolie | well, not specifically an assertion, but eg a fixture | 10:20 |
| LarstiQ | mgz: I'm fixing the remaining cases of file(path, mode).write(content) in the blackbox tests | 10:46 |
| poolie | jam are you still there and muted? | 11:05 |
| poolie | i'm just putting statik's graphs onto the blogpost | 11:05 |
| poolie | i love how the right hand bar is basically imperceptible | 11:05 |
| Daviey | Hi, is there a pre branch hook? I can't seem to find one? | 11:05 |
| mgz | LarstiQ: cool. do refer to that webpage I posted earlier if it helps you see which tests don't close files. | 11:05 |
| LarstiQ | mgz: I got the ones done that were causing failures in blackbox | 11:06 |
| LarstiQ | loads more of occurences that don't cause immediate failures, but won't tackle those right now | 11:07 |
| === jam1 is now known as jam | ||
| LarstiQ | mgz: http://float.endofinternet.org/xmlbin/newtestresult makes my browser unhappy :) | 11:07 |
| mgz | yes, that's the problem with the number of tests bzr has... I need to remember one of the blackbox-only runs | 11:09 |
| * LarstiQ is running all the tests now | 11:10 | |
| * LarstiQ knows of 3 failures in blackbox: 1 LocaleError, and two cases where the order of files returned is different than under cpython | 11:10 | |
| LarstiQ | we'll see if there are any outside | 11:11 |
| LarstiQ | in, oh, 2 hours | 11:11 |
| jam | mgz: is the width of an entry relevant there? | 11:11 |
| jam | I don't quite understand the narrow grey vs the wide green, etc. | 11:11 |
| mgz | the wide ones are tests | 11:13 |
| mgz | the narrow ones are containers, test class, module etc | 11:13 |
| mgz | click the narrow one to expand all the tests in that class | 11:13 |
| jam | mgz, LarstiQ: the fp.close() change has landed in bzr.dev 5890 | 12:01 |
| LarstiQ | jam: cheers | 12:13 |
| LarstiQ | bah | 12:13 |
| LarstiQ | pypy oomed :/ | 12:13 |
| jam | LarstiQ: is there a way to ask pypy to run the garbage collector more often? | 12:14 |
| LarstiQ | jam: --jit threshold=N maybe | 12:14 |
| * LarstiQ looks for more documentation | 12:14 | |
| LarstiQ | or, now that I think of it, that probably has to do with how often code runs before it is cached | 12:15 |
| jam | LarstiQ: AIUI, pypy has higher memory requirements than CPython, but mostly for the code parts, not necessarily for the data parts | 12:16 |
| jam | though how would you OOM from code parts? | 12:16 |
| * LarstiQ has trouble reading the oom-killer output | 12:17 | |
| LarstiQ | jam: http://paste.ubuntu.com/609458/ fwiw | 12:19 |
| * LarstiQ does have a fairly memory constrained setup, and no swap | 12:20 | |
| jam | LarstiQ: not that I know what to do with that :) | 12:20 |
| LarstiQ | jam: you're good at making sense of things ;) | 12:20 |
| jam | offhand it looks like you were about 1.5GB which would certainly be oh-crap big | 12:20 |
| jam | are you in 32-bit or 64-bit? | 12:21 |
| LarstiQ | 32bit, and 1.5GB is the amount of physical memory I have | 12:22 |
| LarstiQ | jam: trying PYPY_GC_MAX=50MB now | 12:34 |
| jam | vila: set_last_revision_info *is* an RPC, but we always allow VFS fallbacks. so it is possible for clients to override if they get really clever, or run old versions of bzr | 12:39 |
| jam | so in the "I haven't tested this" I think if the server says "append_revisions_only=True" then it will be refused | 12:39 |
| vila | jam: yeah, I know this will take time to be truly fixed :-/ | 12:40 |
| vila | jam: but I'm happy enough with what we already have in the mean time | 12:40 |
| vila | jam: also, IMHO, the "flaw" I'm referring to is that we shouldn't *blindly* allow overriding server settings | 12:45 |
| jam | vila: believing that a pure client will respect server settings is flawed | 12:46 |
| jam | someone can always hack the client to not | 12:46 |
| jam | making sure that it is enforced *by the server* is a much better way | 12:46 |
| jam | vila: and then we disable VFS | 12:58 |
| vila | jam: sure, we can enforce that for a smart server but we should also try to have a reasonable behavior for dumb servers | 12:59 |
| vila | jam: I think we're are in violent agreement here ;) | 12:59 |
| jam | vila: I think having someone set it in locations.conf is not much removed from someone hacking branch.py to ignore the value | 13:00 |
| jam | it is slightly easier, but they need to know to do it | 13:00 |
| vila | jam: s/removed/remote/ ? | 13:01 |
| poolie | jam: what do we do with https://code.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537 | 13:02 |
| vila | right, but you mentioned consenting adults, so my point is that we should be clearer for the users about what *can* be safely overriden in locations.conf and what shouldn't | 13:03 |
| jam | vila: someone setting append_revisions_only = False in locations.conf could almost as easily change branch.py to ignore the setting | 13:04 |
| jam | so if someone is going to hack their client to get around a setting | 13:04 |
| jam | they're going to do it anywhay | 13:04 |
| vila | ... | 13:04 |
| jam | so lets make sure we do it correctly where it matters | 13:05 |
| jam | and try to be nice, but we don't have to bend over backwards | 13:05 |
| jam | vila: as said above, if they have direct write access they can also not hack bzr but just do | 13:05 |
| jam | sftp .bzr/branch/last-revision sftp://REMOTE/branch/.bzr/branch | 13:05 |
| jam | vila: so I file it under "I'm not worried about local settings overriding remote ones for cases where users can do the work anyway'" | 13:06 |
| vila | dumb servers can't enforce anything obviously | 13:06 |
| spiv | jam: I think perhaps vila's point is that it's surprising to users, not that users can do it anyway | 13:06 |
| vila | what I want is that a smart server admin can say: this is my server, you can access it only with bzr+ssh, and don't mess my append_revisions_only, ok ? | 13:07 |
| vila | we are not there yet | 13:07 |
| jam | vila: we are if we were at the point that you could disable VFS | 13:07 |
| jam | so lets do that instead | 13:07 |
| vila | no | 13:07 |
| vila | even with no vfs we don't forbid overriding in locations.conf | 13:08 |
| jam | vila: with no vfs the *server* will enforce append_revisions_only | 13:08 |
| vila | but yes | 13:08 |
| jam | set_last_revision() is already calling an RPC | 13:08 |
| vila | let's get rid of vfs first | 13:08 |
| jam | and I'm sure the server can't read my locations.conf fil/e | 13:08 |
| jam | file | 13:08 |
| spiv | vila: well, if the server is enforcing it what the client's config thinks is a bit irrelevant. | 13:08 |
| vila | really ? Even when we create the branch ? Where is append_revisions_only is coming from ? | 13:11 |
| vila | and what if I just use bzr config -d remote a_r_o=False ? | 13:11 |
| spiv | The server may have a plugin installed that always sets that flag when creating branches. | 13:12 |
| spiv | It could even have a plugin that intercepts config update RPCs. | 13:12 |
| vila | right, there are various ways to solve the issue, but there still is an issue ;) | 13:12 |
| spiv | Or perhaps the server's locations.conf globally enables append_revisions_only ;) | 13:14 |
| vila | spiv: indeed, but this works only for the smart server since we don't even try to read the remote locations.conf for the dumb ones | 13:15 |
| spiv | Of course, but we were discussing the smart server case. | 13:15 |
| vila | and that's the flaw I'm referring to, the actual model has some dark spots | 13:15 |
| * vila nods | 13:15 | |
| spiv | There's no ambiguity about what dumb servers do :) | 13:15 |
| vila | I'm worried for people that don't realize that running both a smart server *and* a dumb one can have surprising effects | 13:16 |
| spiv | Conflicts during merge: Text conflict in doc/en/release-notes/bzr-2.4.txt | 13:16 |
| * spiv blinks | 13:16 | |
| vila | and until recently even lp was running both a smart and an sftp server right ? | 13:16 |
| spiv | vila: still is | 13:17 |
| spiv | I think people aren't too surprised by "you can set a setting in multiple places, and if you do and they disagree, then you might have to think carefully/experiment to find out which value wins" | 13:18 |
| vila | spiv: hmm, right, so I don't want to discuss to much on that now but can we agree that there are some confusing scenarios around ? | 13:19 |
| vila | spiv: yup | 13:19 |
| spiv | In general our story for "I'm an admin of a bzr host, and I want to set policies for the branches/repos" is pretty lacking. | 13:20 |
| vila | spiv: yes, thanks, that's I was trying to express :) | 14:17 |
| vila | s//what/ | 14:17 |
| vila | it's related to the way we [should] handle BranchConfig and RemoteBranchConfig (or even RemoteConfig) | 14:18 |
| santagada | http://bazaarvcs.wordpress.com/2011/05/17/faster-large-tree-handling/ this seems really interesting, is there some more benchmarks planned for when this is merged? | 14:21 |
| santagada | comparing to mercurial and git, etc | 14:21 |
| santagada | I do know that the guy that did some benchmarks for bazaar passed away but this looks like a huge speed gain for it | 14:23 |
| poolie | santagada: yes, we probably will | 14:31 |
| poolie | do comparisons | 14:31 |
| poolie | jam, still here? want to join us? | 14:31 |
| LarstiQ | hrmf | 14:32 |
| LarstiQ | someone with more memory will need to run the complete testsuite under pypy | 14:33 |
| poolie | cos it leaks? | 14:33 |
| santagada | LarstiQ, if you have a simple step by step I can run it here (4gb 64bit linux) | 14:33 |
| LarstiQ | poolie: at 1.0GB rsize my oom-killer won't let it live anymore | 14:34 |
| LarstiQ | santagada: just a sec | 14:34 |
| santagada | LarstiQ, do you want to run it on trunk or 1.5? I would recommend trunk | 14:36 |
| LarstiQ | santagada: I've been using a 1.5 binary, but if you can try pypy trunk that would be nice too | 14:42 |
| * LarstiQ has no resources to translate it himself | 14:42 | |
| LarstiQ | santagada: once you have a copy of lp:bzr and pypy, it is just "pypy ./bzr selftest | tee selftest.log" | 14:43 |
| santagada | LarstiQ, will do... will take some time to download lp:bzr | 14:45 |
| LarstiQ | santagada: that's ok with me | 14:46 |
| santagada | maybe I should update bzr first (2.3.1 here) | 14:46 |
| LarstiQ | santagada: where is it at now? | 14:46 |
| santagada | I think the daily nightly has some of the patches I just pated here so it should be faster at checkout stuff | 14:47 |
| LarstiQ | santagada: the 2.4 fixes are about a local checkout afaik, the issue is working tree handling/building, not network transfer | 14:48 |
| LarstiQ | santagada: are you branch over http or bzr+ssh? (ie, is your launchpad-login set) | 14:49 |
| LarstiQ | santagada: do I understand correctly you already have pypy setup? | 14:49 |
| santagada | bzr: ERROR: No module named testtools | 14:54 |
| santagada | LarstiQ, bzr: ERROR: No module named testtools | 14:54 |
| LarstiQ | santagada: ah, right | 14:55 |
| santagada | LarstiQ, I use bzr+ssh, and I have pypy-1.5 and the latest nightly installed | 14:55 |
| LarstiQ | santagada: cool :) | 14:55 |
| * LarstiQ growls at browsers | 14:56 | |
| LarstiQ | santagada: you can download testtools from pypi.python.org | 14:57 |
| LarstiQ | untar it, and run `pypy setup.py install` | 14:57 |
| santagada | LarstiQ, ok | 14:57 |
| LarstiQ | possibly you could get away with importing it from cpython site-packages, but this is quick enough | 14:57 |
| santagada | LarstiQ, installed in both pypy version... it is running 5/25157 | 14:59 |
| LarstiQ | santagada: thanks! | 15:00 |
| santagada | just to be clear, tests are probably going to be slower or the same speed as cpython | 15:00 |
| santagada | not much the jit can do about those | 15:01 |
| santagada | LarstiQ, I could also run some benchmarks if they are as easy as this selftest thing | 15:01 |
| LarstiQ | santagada: they're quite a bit slower ime | 15:02 |
| LarstiQ | santagada: that would be good too, let me see if I can figure out how the benchmarking is done | 15:02 |
| santagada | I would guess merges are going to be faster if using this new ordering/data structure | 15:03 |
| LarstiQ | santagada: https://launchpad.net/bzr-usertest replaced the old selftest --benchmark apparently | 15:05 |
| santagada | should I stop the selftest? | 15:06 |
| santagada | 118/25k | 15:06 |
| LarstiQ | santagada: please let that run (first) | 15:06 |
| LarstiQ | santagada: I'm aware of a couple of failures on pypy, but I'd like the complete set run now | 15:07 |
| santagada | the docs on that page point to a user that doesn't exist anymore on launchpad | 15:07 |
| LarstiQ | it is probably similar to what Naoki reported, but want to be sure | 15:07 |
| LarstiQ | santagada: yeah :/ | 15:07 |
| santagada | LarstiQ, I'm running on nightly so you don't report on issues already solved. After I can run on pypy-1.5 just for comparisons | 15:08 |
| LarstiQ | poolie: https://launchpad.net/bzr-usertest links to http://people.ubuntu.com/~ianc/plugins/usertest/doc/ | 15:08 |
| LarstiQ | poolie: which no longer exists | 15:08 |
| LarstiQ | santagada: right, I'm reasonably confident they're bugs in bzr depending on cpythong behaviour, but extra confirmation doesn't hurt :) | 15:09 |
| poolie | hm | 15:09 |
| poolie | i wonder if i can still get it out | 15:10 |
| poolie | or perhaps i have a copy | 15:10 |
| santagada | LarstiQ, cpython | 15:10 |
| santagada | :D | 15:10 |
| LarstiQ | argh | 15:10 |
| LarstiQ | santagada: indeed | 15:10 |
| santagada | pythong would be a good 1st April joke | 15:10 |
| LarstiQ | I think it's been made before | 15:11 |
| santagada | a leaner python or something | 15:11 |
| santagada | LarstiQ, 701/25k I think this will take a lot of time | 15:38 |
| LarstiQ | santagada: hmm, I'm inclined to say that seems to go slower than it did on my netbook? | 15:39 |
| LarstiQ | santagada: if you don't mind running it, I can wait | 15:40 |
| LarstiQ | or rather, do mathematics in the mean time :) | 15:40 |
| Riddell | vila: http://people.canonical.com/~mwh/bzrlibapi/bzrlib.html | 15:45 |
| vila | Riddell: thanks ;) | 15:45 |
| spiv | Riddell: http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html and http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html were those docs I just mentioned | 15:49 |
| spiv | (in case you hadn't already seen them) | 15:49 |
| LarstiQ | santagada: hmm, we might actually have found a pypy bug | 16:18 |
| quiznilo | I'm trying to use bzr just to download some source code... I don't even know what that is called in bzr-lingo. I can't find any docs basic enough to help me, is there a good starting point doc-wise? | 16:18 |
| santagada | LarstiQ, what? | 16:18 |
| santagada | quiznilo, I don't know for sure, but "bzr checkout --lightweight lp:<launchpad project>" might be exactly what you want | 16:19 |
| LarstiQ | santagada: you might not have seen the failure yet, but you made me ready for the posibility it might not be bzr :) | 16:19 |
| quiznilo | thank you sir | 16:20 |
| LarstiQ | santagada: locale.setlocale() raises different error classes between python and pypy it seems | 16:20 |
| LarstiQ | santagada, quiznilo: --lightweight isn't really designed for non-local usage, so that might be slower than just `bzr branch lp:<launchpad project>` | 16:21 |
| quiznilo | unable to authenticate to SSH host | 16:22 |
| quiznilo | I'm just downloading, I'm not uploading... | 16:22 |
| santagada | LarstiQ, my log for now http://nopaste.linux-dev.org/?11997 | 16:22 |
| LarstiQ | quiznilo: if you have launchpad-login set, bzr will use ssh also for download because it can be faster that way | 16:23 |
| quiznilo | so unset launchpad-login? | 16:23 |
| santagada | quiznilo, I think launchpad should have a tarball download option you should probably fill a issue somewhere | 16:23 |
| LarstiQ | quiznilo: that, or login, or there is some way to turn ssh off | 16:24 |
| santagada | quiznilo, yep, or send your ssh-key to launchpad | 16:24 |
| * LarstiQ looks it up | 16:24 | |
| quiznilo | this is windows lol | 16:24 |
| quiznilo | I don't have a ssh-key | 16:24 |
| santagada | ok then just unset it | 16:24 |
| santagada | if you just want to look at code | 16:24 |
| LarstiQ | santagada: hmm, blackbox.test_info.TestInfo.test_info_locking is new to me | 16:24 |
| santagada | LarstiQ, this is running with the latest pypy | 16:25 |
| LarstiQ | santagada: that, and mgz turned on unexpected successes counting as failures today or yesterday | 16:25 |
| LarstiQ | but he's not online atm | 16:25 |
| * LarstiQ is currently looking into that LocaleError | 16:26 | |
| santagada | LarstiQ, I leave work in 2 hours, but I will let this running | 16:26 |
| LarstiQ | santagada: cheers | 16:26 |
| LarstiQ | the mbcs one is also new to me, but the rest I've squashed | 16:27 |
| quiznilo | there is no 'bzr unset' command or anything else to unset my user | 16:30 |
| maxb | james_w: Thanks for the approve on lp:~maxb/udd/explanations - just to note, I don't have landing access - will you land, or shall I ask one of the folks at the bzr sprint with me to do so? (Or is it acceptable for me to be added to ~udd ?) | 16:40 |
| james_w | maxb, I don't think there would be an issue with you being in ~udd, let me add you | 16:41 |
| santagada | quiznilo, I don't know, maybe edit the bzr config by hand | 16:42 |
| james_w | maxb, added, please go ahead and land | 16:43 |
| maxb | Thanks, will do! | 16:43 |
| LarstiQ | santagada: https://code.launchpad.net/~larstiq/bzr/bzr-pypy/+merge/60986 fwiw | 16:48 |
| LarstiQ | quiznilo: there is bzr config, which has a --remove option | 16:49 |
| quiznilo | k | 16:52 |
| santagada | LarstiQ, my user is santagada on launchpad.net also | 16:53 |
| quiznilo | http://howto.praqma.net/bazaar/bazaar-on-windows <-- helped with SSH issues | 16:53 |
| LarstiQ | santagada: stable usernames are so convenient :) | 16:53 |
| LarstiQ | quiznilo: good | 16:53 |
| quiznilo | bzr checkout lp:IrcDotNet <- yeilds: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/IrcDotNet/". | 16:59 |
| === beuno is now known as beuno-lunch | ||
| quiznilo | I know the project has a link to the 0.4.0 SRC, but I was told to use BZR to download 'tip' | 17:00 |
| LarstiQ | quiznilo: the projectname appears to be lower case | 17:01 |
| quiznilo | I think he said 'tip' | 17:01 |
| LarstiQ | quiznilo: lp:ircdotnet exists | 17:01 |
| quiznilo | hmm | 17:01 |
| quiznilo | there it goes... I think | 17:01 |
| LarstiQ | quiznilo: 'tip' means the most recent revision (on a branch, in this case lp:ircdotnet is assumed methinks) | 17:01 |
| LarstiQ | well, it's a bit more general in say mercurial, but never mind that :) | 17:02 |
| quiznilo | I think I got it, thanks for your help, I've never used a VCS system before beyond: git co git://whatever | 17:02 |
| santagada | quiznilo, if you plan to program you should learn at least one | 17:09 |
| santagada | quiznilo, and use it | 17:09 |
| quiznilo | I've been programming for years | 17:13 |
| quiznilo | thanks for the help | 17:14 |
| === hunger_ is now known as hunger | ||
| === deryck is now known as deryck[lunch] | ||
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| poolie | o/ jam | 18:52 |
| jam | hi poolie, just casually around | 18:52 |
| poolie | np, hi | 18:57 |
| jam | I have this update_basis_by_delta monkey on my back | 18:57 |
| jam | I can't shake it :) | 18:57 |
| poolie | http://www.pixoulphotography.com/2011/05/18/official-uds-o-group-photo-and-personal-photo-set/ nice | 19:01 |
| === BasicPRO is now known as BasicOSX | ||
| james_w | jelmer, maxb: thanks for all the branches/fixes | 19:53 |
| james_w | I guess you've finished for the day now, so I can get back to work ;-) | 19:53 |
| jelmer | james_w: Hey :) | 20:01 |
| jelmer | james_w: Sorry (: Thanks for the quick reviews, that's really useful. | 20:02 |
| james_w | no problem | 20:02 |
| james_w | I'm only kidding | 20:02 |
| jelmer | You know where to find me if I can return the favour :) | 20:02 |
| james_w | it doesn't take me at all long to review your code | 20:02 |
| === BasicPRO is now known as BasicOSX | ||
| workthrick | hiya, is it currently possible/reasonable to work with bzr-colo on a bound branch? | 20:44 |
| workthrick | I work from multiple machines, and have in the past forgot to commit things in one place and then couldn't use it in the other. So I moved to having all of my branches bound to a single remote one so that it's impossible to forget to push | 20:45 |
| workthrick | but now I've got enough complexity in the code that I'd actually like to have colocated branches. Yet I don't want to go back to pushing manually | 20:46 |
| workthrick | I see I can't make a chain of bound branches, bzr errors at me if I have A bound to B and B bound to C | 20:51 |
| workthrick | which is good in a way, at least it states plainly that it refuses to cooperate instead of breaking silently :) | 20:51 |
| mgz | ...it's really time to leave and get some food now | 20:52 |
| mgz | just *one* little merge proposal first | 20:52 |
| LarstiQ | doh | 21:00 |
| * LarstiQ will have to ask mgz tomorrow | 21:00 | |
| workthrick | hmm, actually it seems that bzr-colo should be happy working with a remote workspace | 21:08 |
| thomi | Hi. Why is "Repository.copy_content_into(...)" a "destrive operation"? Surely if it's a _copy_... or am I missing something? | 21:34 |
| thomi | *destructive, that is. | 21:34 |
| workthrick | hmm, how can I tell bzr to filter out paramiko's messages below WARN? It connects a logger, and it outputs everything to console by default, which is horribly verbose | 21:41 |
| workthrick | hmm, why does bzr connect 4 times (!) over ssh to carry out bzr colo-branches on a remote workspace? | 22:14 |
| workthrick | remote == sftp:// | 22:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!