| Noldorin__ | err | 00:25 |
|---|---|---|
| Noldorin__ | bzr mv --after is still telling me the ssource file is not versioned...help please? | 00:26 |
| Noldorin__ | anyone around? :-) | 00:37 |
| Noldorin__ | anyone? | 01:00 |
| Noldorin__ | bah, never mind. my bad | 01:11 |
| === newbie is now known as Guest75465 | ||
| === yofel_ is now known as yofel | ||
| wgz | and back. | 14:10 |
| jelmer | hey wgz | 18:24 |
| wgz | hey jelmer! | 19:18 |
| jimis | How can I see which revision of trunk I merged earlier? | 19:45 |
| lifeless | bzr missing is the usual way | 19:48 |
| lifeless | log -n2 (or -n0) will show you the merge in your local tree, but not the revno of that revision on trunk itself. | 19:48 |
| jimis | lifeless: thanks, I didn't know about bzr missing | 19:51 |
| jimis | so the revision I last merged is the last one bzr missing shows, minus one? | 19:51 |
| jimis | (the reason is that I want to produce a diff of my tree versus that revision of trunk) | 19:52 |
| jimis | nice, a new revisionspec syntax | 19:56 |
| jimis | bzr diff -rrevno:112685:../gcc-lp-notrees/trunk | 19:56 |
| lifeless | oh | 20:00 |
| lifeless | for that you might like | 20:00 |
| lifeless | bzr diff -r ancestor:../gcc-lp-notrees/trunk | 20:00 |
| lifeless | or merge --preview can be good as well | 20:00 |
| jimis | ancestor is nice thanks :-) | 20:02 |
| jimis | merge --preview I think doesn't do what I need | 20:03 |
| lifeless | merge --preview *into* trunk will show you the result of merging your branch into trunk | 20:03 |
| lifeless | including conflicts | 20:03 |
| jimis | *into* is the key word :-) | 20:03 |
| jimis | I don't want to "bzr switch" because I have local changes :-p | 20:04 |
| lifeless | so; pushd ../../gcc-lp-notrees/trunk; bzr merge --preview $! | 20:04 |
| lifeless | or something like that | 20:04 |
| lifeless | + popd | 20:04 |
| jimis | hmmm pushd/popd | 20:04 |
| jimis | didn't know | 20:04 |
| jimis | aah you mean the shell command, not a bzr command... | 20:05 |
| lifeless | ah | 20:05 |
| lifeless | OLDPWD | 20:05 |
| jimis | lifeless: as the name suggests gcc-lp-notrees is a --no-trees branch, which doesn't have contents. Can I still do that | 20:06 |
| lifeless | pushd ../../gcc-lp-notrees/trunk; bzr merge --preview $OLDPWD; popd | 20:06 |
| lifeless | ah, no | 20:06 |
| jimis | And I do work on a single checkout, using "bzr switch" for a git-like workflow | 20:06 |
| lifeless | but | 20:06 |
| lifeless | you should be able to in principle - can you file a bug, or would you like me to ? | 20:06 |
| jimis | please do :- | 20:06 |
| jimis | and I'll try later to file one for showing the source revision for merges, in bzr log | 20:07 |
| jimis | I think that would be extra useful | 20:07 |
| jimis | In general bzr needs work for single-dir workflow | 20:08 |
| jimis | and that's the only way to work on huge projects like gcc | 20:08 |
| lifeless | oh totally. | 20:09 |
| lifeless | https://bugs.launchpad.net/bzr/+bug/886906 | 20:09 |
| ubot5 | Ubuntu bug 886906 in Bazaar "merge preview wants a working tree" [Undecided,New] | 20:09 |
| jimis | thanks lifeless | 20:10 |
| lifeless | de nada | 20:10 |
| jimis | no connection with linaro though :-p | 20:10 |
| lifeless | ah - I will fix that :) | 20:10 |
| jimis | I started working on gcc this summer for GSOC | 20:10 |
| lifeless | the linaro folk do quite some gcc work | 20:11 |
| jimis | I don't know why I chose bzr but it made my life pretty hard :-p | 20:11 |
| lifeless | fixed, thanks | 20:11 |
| jimis | I have on my TODO to file 4-5 bugs about bzr single-dir workflow | 20:11 |
| jimis | and pre 2.4 bzr was a _nightmare_ | 20:12 |
| jimis | at least now it's workable... | 20:12 |
| lifeless | cool, please do! | 20:12 |
| jimis | https://bugs.launchpad.net/bzr/+bug/886910 | 20:21 |
| ubot5 | Ubuntu bug 886910 in Bazaar "bzr log should show source tree revision for merges" [Undecided,New] | 20:21 |
| jimis | Also do you know if "bzr merge" has a "pretend" option? How can I know if conflicts will happen? | 20:22 |
| lifeless | --preview :) | 20:23 |
| jimis | lifeless: preview shows a diff if I'm not mistaken? | 20:24 |
| lifeless | yes, including conflicts | 20:24 |
| jimis | I want the exact output as merge, but without applying any changes | 20:24 |
| jimis | so that I don't get lost in the thousands line diff | 20:24 |
| lifeless | I'm not sure | 20:24 |
| jimis | --pretend would be nice :-p | 20:24 |
| lifeless | TBH what I do is just merge; bzr st; bzr revert if I want that sort of thing | 20:24 |
| lifeless | even on large trees merge should be pretty fast these days | 20:25 |
| jimis | it's manageable :-p | 20:25 |
| jimis | 10min is fast enough | 20:25 |
| jimis | pre-2.4 it was unmanageable :-p | 20:25 |
| lifeless | 10min? wow :( | 20:27 |
| jimis | "bzr status" needs badly to be speep up... It know takes ~1.5 min but such an operation should be less than 10s | 20:27 |
| lifeless | thats slow | 20:28 |
| lifeless | do you have the C extensions ? | 20:28 |
| jimis | lifeless: I'm not sure, I only did a "setup.py install" thing | 20:29 |
| jimis | how can I see? | 20:29 |
| lifeless | IIRC - check ~/.bzr.log, it whines in there | 20:30 |
| jimis | Sun 2011-11-06 22:16:44 +0200 | 20:31 |
| jimis | 0.292 bazaar version: 2.4.1 | 20:31 |
| jimis | 0.292 bzr arguments: [u'log', u'-n0'] | 20:31 |
| jimis | 0.491 looking for plugins in /home1/public/jimis/.bazaar/plugins | 20:31 |
| jimis | 0.491 looking for plugins in /home1/public/jimis/dist/lib/python2.6/site-packages/bzrlib/plugins | 20:31 |
| jimis | 0.620 looking for plugins in /usr/local/ActivePython-2.6.4.10-linux-x86_64/lib/python2.6/site-packages/bzrlib/plugins | 20:31 |
| jimis | 0.640 encoding stdout as sys.stdin encoding 'UTF-8' | 20:31 |
| jimis | 0.940 encoding stdout as sys.stdin encoding 'UTF-8' | 20:31 |
| jimis | 109.609 Transferred: 0kB (0.0kB/s r:0kB w:0kB) | 20:31 |
| jimis | 109.610 return code 0 | 20:31 |
| jimis | I don't see any whining, right? | 20:31 |
| lifeless | seems fine | 20:31 |
| lifeless | are you on MacOSX ? | 20:31 |
| jimis | no, RHEL5 | 20:31 |
| jelmer | hi jimis, lifeless | 20:32 |
| lifeless | hmm | 20:32 |
| jimis | hey jelmer | 20:32 |
| lifeless | cause 1.5 minutes is (IIRC) 10 times the duration I had when I was optimising status on trees of a similar size | 20:32 |
| ephan | Hey | 20:32 |
| lifeless | hi jelmer | 20:32 |
| jimis | lifeless: My experience on this host tells me it's the NFS mounted home | 20:32 |
| lifeless | jimis: hah. Yes, NFS will kill your performance | 20:32 |
| ephan | I am getting "Permission denied (publickey)." | 20:33 |
| ephan | Should I ask a question on Launchpad, I Found a lot similar like these, but none like mine | 20:33 |
| jimis | lifeless: it uses synchronous stat() calls which means for every file a full round-trip | 20:33 |
| lifeless | jimis: out of curiosity, how long does 'time find . -type f -type d' take | 20:33 |
| lifeless | jimis: in principle those get cached by the local OS, and readahead can happen as well | 20:34 |
| jimis | lifeless: I've done that, it's pretty slow I think | 20:34 |
| jimis | lifeless: not the stat() metadata | 20:34 |
| lifeless | jimis: yeah, bzr st cannot be faster than that. | 20:34 |
| lifeless | its the lower limit | 20:34 |
| jimis | that's only cached for 2-3 seconds as far as I know | 20:34 |
| jimis | a solution would be asynchronous stat(), which doesn't exist :-p | 20:35 |
| jelmer | I also think merge hasn't had much attention from our speed-meister yet | 20:35 |
| lifeless | in practice emulating a single-user chatty environment on a shared high latency substrate is doomed to be painful | 20:35 |
| lifeless | jelmer: its had a couple of base passes | 20:35 |
| lifeless | jelmer: but there is probably plenty of room to improve | 20:35 |
| jimis | The proper solution would be multiple lightweight python threads, blocking separately on stat() | 20:36 |
| jimis | it's on my TODO :-p | 20:36 |
| lifeless | mmm, that will be -very- slow on a non-NFS machine | 20:36 |
| jimis | cause I see this slowness everywhere: find, rsync, but most annoyingly bzr | 20:36 |
| lifeless | python and threading don't play all that well together | 20:36 |
| jimis | lifeless: I don't think show, why? | 20:36 |
| jimis | ah I see | 20:36 |
| lifeless | python has a single threaded core | 20:37 |
| jimis | hmmm | 20:37 |
| glyph | lifeless: erm | 20:37 |
| lifeless | executing code in two threads requires a full context switch every time one of them wants to execute bytecode | 20:37 |
| jimis | isn't there a "threading" module or something? I remember an easy way for light threads | 20:37 |
| lifeless | there is, and it works, and if you're blocked on IO its great; the problem I am pointing out is that on NFS you are combating latency | 20:38 |
| glyph | jimis: they're heavyweight (operating system) threads, not lightweight (interpreter) threads, and they don't parallelize CPU work, since there is a single lock for executing bytecode | 20:38 |
| lifeless | and on local machines you're not, because your page cache will be hot and doesn't have the same arbitrary time based locked + does decent readahead | 20:38 |
| glyph | python and threading play together just fine as long as you don't care at all about performance :) | 20:38 |
| lifeless | heh, I'm all about performance ;) | 20:39 |
| glyph | the right solution of course is that bzr should use twisted!! woooooo | 20:39 |
| glyph | (and then the bzr developers should spend like 2 years implementing a general purpose, fast, event-driven filesystem I/O layer) | 20:39 |
| lifeless | glyph: while I love twisted, it still adds quite some overhead ;) | 20:39 |
| glyph | lifeless: if it's a realistic possibility that bzr could use twisted to address some of these issues, I'd love to sit down at some point and talk about how to get the import time down to something acceptable to bzr | 20:40 |
| glyph | lifeless: the runtime overhead is negligible, even negative :) | 20:40 |
| jimis | glyph, lifeless: this threading model sounds fine for blocking on I/O... | 20:40 |
| glyph | lifeless: mostly I was just trolling but whenever I go trolling I am ready to back it up with some discussion at least ;) | 20:40 |
| lifeless | glyph: its an interesting question. Uhm, I don't see how the runtime overhead can be negative, you'd be doubling the object alloc/free rate at minimum, if every file statted returned a deferred | 20:41 |
| glyph | lifeless: Hrm | 20:41 |
| glyph | lifeless: that's not at all how I'd do it | 20:41 |
| jimis | Anyway, it remains for me to implement it sometimes, and measure real numbers :-p | 20:41 |
| lifeless | jimis: indeed :) | 20:41 |
| lifeless | glyph: directory at a time? | 20:41 |
| glyph | lifeless: on the other hand, the thing that would do the "right thing" is still kinda in development; I'll keep you posted when there's a prototype | 20:41 |
| glyph | lifeless: no, Deferreds are the wrong abstraction for an arbitrarily-big stream of events | 20:41 |
| glyph | lifeless: that's the mistake web2 made and that's why its performance was a disaster | 20:42 |
| lifeless | glyph: ah, a producer of some sort :) | 20:42 |
| glyph | lifeless: yes. except our existing producer API is _also_ a disaster. Hence the new thing :) | 20:42 |
| lifeless | glyph: so, I'd like to see the right thing; in particular how you introduce file system concurrency w/out threading and without sacrificing the non-threaded case..... on linux, with its appalling non-threaded concurrent disk IO story. | 20:43 |
| lifeless | hmm, that came out negative | 20:43 |
| lifeless | 'I am interested'. | 20:43 |
| lifeless | And suspect its hard. | 20:43 |
| glyph | lifeless: it is hard, and it's basically impossible to get right (wouldn't it be nice if linux didn't suck) but the answer rhymes with "one thread per platter" | 20:43 |
| lifeless | glyph: you might be interested in the disk IO work Alex Rousskov has been doing in squid3 | 20:44 |
| glyph | lifeless: you want one thread doing the work and one feeding it, and you want the feeder thread to get a little bit ahead of the other thread and build up a buffer, because its performance is going to be all over the map as different directories have different tree balances | 20:44 |
| jimis | lifeless: the /proper/ way is posix AIO (see aio.h) | 20:44 |
| glyph | jimis: hahahahaha | 20:44 |
| lifeless | glyph: you may know this already but squid is a twisted-like program - nonblocking callback based core, some work threads and helper processes. | 20:44 |
| glyph | jimis: oh that's a good one | 20:44 |
| jimis | but stat() has no AIO hook | 20:44 |
| lifeless | jimis: AIO is sadly sadly sadly broken. | 20:45 |
| glyph | jimis: http://stackoverflow.com/questions/87892/what-is-the-status-of-posix-asynchronous-i-o-aio | 20:45 |
| lifeless | the kernel implementation is atrocious, because abstractions leak. | 20:45 |
| glyph | lifeless: the kernel implementation is mostly just atrocious because it's atrocious | 20:45 |
| jimis | FWIW I've used linux AIO (not posix, linux kernel specific) | 20:45 |
| jimis | it works, and it works fast | 20:45 |
| jimis | but still no stat() | 20:45 |
| lifeless | glyph: really? Cause at LCA a kernel dude was up saying how bad it was | 20:46 |
| lifeless | glyph: and the next New World Order was going to fix everything. | 20:46 |
| glyph | lifeless: I'm agreeing | 20:46 |
| lifeless | glyph: ;) | 20:46 |
| glyph | lifeless: I'm just saying that it's not because any abstraction leaked, it's because it sucks completely | 20:46 |
| glyph | the abstraction _as designed_ is terrible, the POSIX guys were on crack or something when they came up with it | 20:46 |
| glyph | I mean, come on | 20:46 |
| glyph | here's an idea | 20:46 |
| glyph | "select() works on regular open files, and recv() can give you a short read on an open file" | 20:47 |
| glyph | why is _that_ so hard | 20:47 |
| jimis | jelmer, maybe you know: showing find the source revno in "bzr log" is easy, or it would need some kind of hack? | 20:48 |
| lifeless | glyph: indeed | 20:48 |
| lifeless | I have to pop out | 20:48 |
| glyph | lifeless: In my experiments on this topic, worker processes fared better than worker threads, because the GIL has some messed up interactions with the weird way Linux uses I/O to bias scheduling | 20:49 |
| lifeless | but look at alex's disker work | 20:49 |
| lifeless | he's been tuning to interact well with the linux write daemon, tuning IO to match disk load, spilling requests when needed etc. | 20:49 |
| glyph | lifeless: where is this? | 20:49 |
| lifeless | glyph: the GIL...messed up...weird. | 20:49 |
| lifeless | glyph: sounds familiar :) | 20:49 |
| jelmer | jimis: what do you mean with the source revno? | 20:50 |
| lifeless | glyph: http://wiki.squid-cache.org/Features/RockStore | 20:50 |
| lifeless | bbiab | 20:50 |
| jimis | jelmer: the source revno of merges, see bug #886910 | 20:50 |
| ubot5 | Launchpad bug 886910 in Bazaar "bzr log should show source tree revision for merges" [Undecided,New] https://launchpad.net/bugs/886910 | 20:50 |
| jelmer | jimis: I'm not aware of any revspecs at the moment that do that; what are you looking to do exactly (perhaps there's some way of doing it without that?) | 20:53 |
| jelmer | jimis: another thing you can do is to use "bzr log -n1", though that will get you more data | 20:53 |
| jimis | jelmer: still the revno is missing | 20:54 |
| jimis | for now lifeless helped, and I did "bzr missing" | 20:54 |
| jelmer | jimis: sorry, I meant "bzr log -n2" | 20:54 |
| jimis | aha | 20:54 |
| jimis | I'll try | 20:54 |
| jimis | still "bzr missing" wasn't perfect, I had to /guess/ the revision I needed was the last it reported, minus one | 20:55 |
| jimis | jelmer: nope, -n2 doesn't show it | 20:58 |
| jimis | anyway, I'll leave that bug there, I'll look into it myself sometime hopefully it's easy | 20:58 |
| jelmer | jimis: it does here, perhaps I don't understand what you mean | 20:59 |
| jelmer | jimis: -n2 isn't showing the revision number for nested revisions for you? | 20:59 |
| jimis | jelmer: revno: 109439.2.3244 | 21:01 |
| jimis | but I want the original revision that I merged | 21:01 |
| jimis | which is 115532 for example | 21:01 |
| jelmer | ah, you're looking for the revision number as it exists *in the original branch* ? | 21:01 |
| jimis | right! | 21:02 |
| jimis | maybe I should edit that bug :-p | 21:02 |
| jimis | so I can diff easily | 21:02 |
| jimis | jelmer: so is it easy or needs hack? | 21:02 |
| jelmer | jimis: that's not easy, as you'll need to reference the original branch somehow | 21:02 |
| jimis | I see, thanks | 21:03 |
| poolie | hi all | 22:41 |
| jelmer | hi poolie | 22:42 |
| jelmer | did you have a good weekend? | 22:42 |
| poolie | hi, yes thanks | 22:43 |
| poolie | three parties 8) | 22:43 |
| jelmer | :) | 22:45 |
| poolie | the bbq sunday had some people i hadn't seen for ~9 years so that was a bit strange | 22:46 |
| poolie | but nice | 22:46 |
| poolie | how are you? | 22:46 |
| jelmer | not as many parties, but still had a very good weekend :) | 22:47 |
| poolie | it's unusual for me | 22:47 |
| poolie | so i think i saw you took the bug about, um | 22:48 |
| poolie | passing --allow-fallback, is that right? | 22:48 |
| jelmer | yeah - there's an approved MP for it now, but I haven't landed it yet | 22:48 |
| jelmer | not sure what your plans were regarding deployed of newer buildd changes | 22:48 |
| jelmer | *deployment | 22:49 |
| poolie | i'm going to try to get buildd building as a separate tree from launcphad | 22:49 |
| poolie | i got approval for all the changes needed to make it disconnected while still being in the same tree | 22:50 |
| poolie | with a new txfixtures project split out | 22:50 |
| jelmer | ooh, neat | 22:50 |
| poolie | yeah, it's one small step towards easier deployment, perhaps | 22:50 |
| poolie | some tests fail | 22:50 |
| poolie | i am hoping to fix them today and then build a package and then try to get lamont to install it tomorrow, my time, his monday | 22:51 |
| poolie | iwbni he could pair with say spm or some other losa so that other people get comfortable deploying things | 22:51 |
| poolie | i wonder if we could at least trust them to deploy to staging buildds | 22:52 |
| poolie | trust/teach | 22:52 |
| jelmer | hmm, yeah. that would probably already make a huge impact on the amount of time it takes to get something deployed | 22:53 |
| poolie | anyhow, that's my main thing for today | 22:54 |
| poolie | i think you should merge https://code.launchpad.net/~jelmer/launchpad/buildrecipe-allow-fallback-to-native/+merge/81271 | 22:55 |
| poolie | or i can do it | 22:55 |
| poolie | it will eventually clash with my split-out | 22:55 |
| poolie | though, obviously it's trivial to move it across | 22:56 |
| jelmer | poolie: ok, I'll land it. I just wanted to check with you in case you wanted to deploy anything separately before the new bzr-builder | 22:58 |
| poolie | :/ | 22:58 |
| poolie | it's hard to decide | 22:58 |
| poolie | deploying seems both expensive and risky | 22:58 |
| poolie | so i'm torn between testing out small changes individually, and deploying larger batches so we're not stuck here until christmas | 22:59 |
| poolie | i think on the whole doing this whole batch together is better, including trying to split out buildd stuff | 22:59 |
| poolie | which may make things easier in future | 22:59 |
| jelmer | +1 | 23:03 |
| poolie | jelmer, oh the other thing someone should look at | 23:07 |
| poolie | is https://bugs.launchpad.net/udd/+bug/848064 | 23:07 |
| ubot5 | Ubuntu bug 848064 in Ubuntu Distributed Development "Revision not present branching from udd-imported branches on lp" [Critical,Confirmed] | 23:07 |
| poolie | i decided to stick with the buildd updates | 23:08 |
| poolie | oh we need to work out the sru too | 23:29 |
| jelmer | I uploaded a package to oneiric | 23:34 |
| jelmer | we just need to do the verification | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!