[00:33] <igc> morning
[00:58] <spiv> igc: morning
[01:33] <igc> hi spiv
[01:42] <lifeless> spiv: was last monday a public holiday?
[01:44] <spiv> lifeless: yeah, Labour Day in NSW
[01:46] <lifeless> ]thanks
[02:08] <lifeless> -< food >-
[03:13]  * igc lunch
[03:54] <Peng_> Lately, Loggerhead is such a memory hog that running it is impractical. It's getting killed for hitting ~250 MB daily.
[03:54]  * Peng_ whines
[03:56] <Peng_> ("Lately" being "some time from 2009-07-07 to ~2009-09-07". Maybe it has to do with upgrading everything to 2a?)
[03:57] <Peng_> Sorry, I'm done now.
[03:58] <Peng_> That's the kind of thing I should put on Twitter where nobody has to read it. :P
[04:01] <mwhudson> Peng_: it's probably 2a related at a guess
[04:05] <Peng_> It ran for 10+ weeks with no intervention, then I upgraded to 2a and it (well, presumably it) OOMed my VPS within a day. :D
[04:05] <Peng_> Hmm, when there is a MemoryError traceback, it does tend to be 2a-related.
[04:06] <Peng_> But it could just be that something else uses too much memory, and then that's what pushes it over the edge.
[04:12] <mwhudson> Peng_: you could try jam's static tuple branch i guess
[04:12]  * igc dentist - bbl
[04:13] <Peng_> Being lazy here, how much RAM does that save per tuple?
[04:14] <spiv> Peng_: lots ;)
[04:15] <Peng_> It has a significant number of lists, too, though not nearly as many as the tuples.
[04:15] <spiv> I think at least 16 bytes per tuple, and that doesn't count the interning.
[04:15] <Peng_> Currently 320,000 tuples, 100,000 lists. :D
[04:16] <spiv> Whee!
[04:16] <Peng_> The peak number of tuples is 460,000.
[04:17] <Peng_> This might crash your browser/X/monitor/desk, but you can see for yourself at http://bzr.mattnordhoff.com/loggerhead/_dozer/index if you want to.
[04:18] <Peng_> (Adblock http://bzr.mattnordhoff.com/loggerhead/_dozer/chart/ctypes.CFunctionType to avoid the crashiness.)
[04:31] <Peng_> (FYI, I just blocked the image server-side.)
[04:41] <Peng_> Oooh, jam has lots of interesting memory-related branches in development.
[04:45] <spiv> Peng_: IIRC there's just one big branch that's been split into pieces for review
[04:45] <spiv> Peng_: If I were experimenting with it I'd just jump straight to the end result.
[04:55] <Peng_> spiv: I'm not sure all of it is merged into the big branch, though.
[05:26]  * RenatoSilva can't understand very well stuff like this :( http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar
[05:28]  * RenatoSilva still thinks rebase is a very nice way of keeping a private feature branch updated with mainline.
[05:31] <spiv> RenatoSilva: well, if it works well for you, then keep doing that.
[05:32] <spiv> RenatoSilva: personally, I find I'd rather keep the original history intact, but I don't mind having a history that's slightly more complicated than linear.
[05:35] <RenatoSilva> ok I just mean that a good reason against rebase in private branch still misses, I fell like it's the natural way of keeping up-to-date with mainline, that's a bit weird when you see all the folks out there saying it's bad
[05:36] <johnjosephbachir> hey folks. how do i back out a particular change from a particular file? in subversion this would be: svn merge -c -<any revision number> <any path>; svn commit
[05:36] <RenatoSilva> I think I shoulld follow you folks and use merges, but rebase "is still in my heart" :D
[05:39] <spiv> RenatoSilva: well, I don't really understand why you don't like merges
[05:39] <spiv> RenatoSilva: and you don't really understand why some people don't like rebase, so I guess we're even ;)
[05:41] <spiv> johnjosephbachir: you can do "bzr merge -r X..X-1"
[05:41] <spiv> Er,
[05:41] <spiv> johnjosephbachir: you can do "bzr merge -r X..X-1 ."
[05:41] <spiv> The "." is important :)
[05:41] <johnjosephbachir> spcool, just encountered the X..X+1 case in the docs, and was going to try the case you mentioned (and was expecting failure : ) )
[05:41] <johnjosephbachir> got it, thanks
[05:42] <spiv> johnjosephbachir: oh, and you can specify a file name at the same time, of course.
[05:42] <johnjosephbachir> s/spcool/spiv cool/
[05:42] <spiv> :)
[05:42] <johnjosephbachir> spiv, okay
[06:08] <igc> back
[07:44] <bialix> hello all
[07:53] <vila> hi all, hi bialix
[07:57] <smartgpx> igc: hi, Ian - are you free for a moment, please?
[08:11]  * spiv wonders why Python will make sure numbers will always compare lower than other objects if both sides give NotImplemented...
[08:12] <spiv> (Oh, except for None, of course, which is special-cased before that special-case...)
[08:23] <spiv> Oof, it takes a while to review C code.
[08:23] <spiv> But then, it was > 1000 lines of diff, so maybe it's nothing to do with C :)
[08:23] <lifeless> spiv: whats id(34) for you
[08:24] <spiv> 148469204
[08:25] <spiv> Or thereabouts, anyway ;)
[08:26] <bialix> bonjour vila
[08:28] <lifeless> spiv: I'd guess that your objects have a higher id
[08:29] <spiv> lifeless: by a factor of ~20, it seems ;)
[08:30] <lifeless> spiv: so I don't think its a deliberate thing :)
[08:30] <spiv> lifeless: hah!
[08:30] <spiv> lifeless: you'd think that...
[08:30] <lifeless> spiv: did you find a check for it in the core?
[08:31] <spiv> lifeless: read the definition of default_3way_compare in http://svn.python.org/projects/python/trunk/Objects/object.c
[08:32] <spiv> (that function is invoked when both sides don't implement tp_richcompare or they do and it returns NotImplemented)
[08:32] <lifeless> spiv: I'll assume thats a yes
[08:32] <spiv> lifeless: here's the highlight: /* different type: compare type names; numbers are smaller */
[08:33] <spiv> i.e. PyNumber_Check(v) it uses "", otherwise v->ob_type->tp_name;
[08:33] <lifeless> bleep
[08:33] <spiv> s/i.e./i.e. if/
[08:33] <spiv> After special-casing None, of course.
[08:34] <spiv> If the type names match, it will compare type pointers, so you weren't totally on the wrong track ;)
[08:35] <lifeless> how did you end up down there
[08:35] <spiv> Reviewing jam's StaticTuple patch, he has a test that at one point asserts that 10 < some static tuple.
[08:35] <lifeless> lol
[08:36] <spiv> Which seems a bit insane to me, but seeing as I had the Python source handy I thought I'd quickly check to see if it was going to be fragile across runs or platforms as well...
[08:37] <lifeless> is it deliberate or a typo?
[08:37] <mneptok> oh, how i miss that phrase in repsonse to my e-mails to Canonical lists.
[08:37] <spiv> And, at least with CPython 2.6, it seems reliable, but yeesh...
[08:37] <vila> lifeless, spiv: Working on thread leaks, I realize the root cause of many test bugs is that: SocketServer is *not* intended to be used with a client thread in the same process...
[08:37] <lifeless> mneptok: which phrase?
[08:37] <mneptok> "seems a bit insane to me"
[08:38] <spiv> lifeless: deliberate, but I pretty questionable IMO.
[08:38] <lifeless> spiv: what does it do for us?
[08:38] <spiv> lifeless: I can understand testing that comparison with arbitrary types doesn't blow up, but then asserting that they should be always less or greater doesn't seem valuable to me.
[08:39] <lifeless> is it a proxy for 'the result of __cmp__ is an int', perhaps?
[08:39] <spiv> mneptok: you're considered wholly sane at your new workplace?
[08:39] <lifeless> seems a bit insane to me
[08:39] <mneptok> spiv: i report to Monty Widenius. by comparison, i seem somewhat well-adjusted.
[08:39] <spiv> vila: really?  yeesh.
[08:40] <lifeless> vila: can we work around it?
[08:40] <spiv> vila: I always assumed SocketServer was a toy, but I figured that was because I was a bit biased being a Twisted dev :)
[08:40] <mneptok> spiv: ill try to get Monty angry and record him swearing in a pidgin of Swedish, Finnish, and C++
[08:40] <lifeless> mneptok: nice
[08:40] <lifeless> mneptok: you having fun there?
[08:40] <vila> It's fixed, that was scary though and hard, hard, hard to not become insane :)
[08:41] <mneptok> lifeless: very much so.
[08:41] <lifeless> vila: *insaner*
[08:41] <spiv> mneptok: "may your compiler always fail with inscrutable template errors!"
[08:41] <lifeless> vila: :)
[08:41] <mneptok> lifeless: although i miss Woody. we need a company pony.
[08:41] <vila> spiv: not a toy, just one assumption was missed: the client can be in the same process
[08:41] <vila> lifeless: right :)
[08:41] <lifeless> we don't have woody now, AIUI
[08:41] <spiv> vila: I told you I was biased ;)
[08:41] <lifeless> vila: what did they do to make that an assumption that matters?
[08:42] <mneptok> spiv: "Hjorsorn bjarrtor type identifier;
[08:42] <vila> lifeless: the point is about what they did *not* ... They did not synchronize their threads
[08:43] <lifeless> vila: meep; unsafe always
[08:43] <spiv> vila: I basically don't trust anyone except Twisted to get portable sockets and concurrency in Python right.
[08:43] <vila> lifeless, spiv : the good news is that synchronizing the threads was easy once I understood what was needed
[08:43] <vila> lifeless: huh ? not symcing is unsafe or do you mean even syncing result in an unsafe system ?
[08:44] <mneptok> i rented a movie called "Portable Sockets." i thought it would help me learn Python network programming. it was a porn film about hitch-hiking. :(
[08:45] <spiv> mneptok: I doubt you'll fare much better with titles involving "Twisted" or "Python"...
[08:45] <vila> spiv: I don't have experience with twisted to speak, but indeed, I fixed a bunch of micro-bugs around with sockets and threads with spectacular variations in test failures....
[08:45] <spiv> Well, maybe they'll have less hitch-hiking.
[08:46] <spiv> vila: right
[08:46] <mneptok> spiv: something tells me lifeless is away from IRC editing the quotes page.
[08:46] <vila> so in the end, our code base is safe, our test code base is magnitude *safer* with respect to http, ftp test servers...
[08:47] <lifeless> vila: using objects across threads is a bad bad bad bad bad bad idea without mutexs
[08:48] <spiv> lifeless: that's the GIL, right? ;)
[08:48] <lifeless> spiv: I wish!
[08:48] <lifeless> it would be great if the GIL only released a thread when C code was reached.
[08:48] <lifeless> stuff would be so much more debuggable :P
[08:48] <vila> but the GIL is no magical bullet, you had to have stronger sync points, I used threading.Event objects for that
[08:48] <spiv> lifeless: Hmm.
[08:49] <spiv> lifeless: you can approximate that, perhaps...
[08:49] <spiv> lifeless: sys.setcheckinterval(sys.maxint)
[08:49] <lifeless> spiv: evil evil man
[08:50] <spiv> lifeless: check that in your site.py and tell me how it works out for you ;)
[08:50] <lifeless> be an interesting way to find bugs
[08:50] <spiv> lifeless: hey, they wouldn't put those two symbols in the same module if they didn't want them to be used together!

[08:50] <lifeless> s/-.*/>
[08:51] <spiv> :)
[08:53] <mneptok> remind me never to share a hotel room with spiv
[08:56] <spiv> mneptok: They give you shampoo... and a shaver only wall socket!  These *must* belong together...
[08:57] <lifeless> mneptok: 'they wouldn't put those two employees in the same room if...' ?
[09:03] <mneptok> lifeless: exaaaaaactly
[09:34] <igc> mneptok: mariadb on home page now
[09:35]  * igc dinner
[09:51] <mwhudson> * spiv wonders why Python will make sure numbers will always compare lower than other objects if both sides give NotImplemented...
[09:51] <mwhudson> spiv: it's so different numeric types end up "next to" each other
[09:51] <mwhudson> so sorted([1, 1.5, 'bob']) keeps the numbers together
[10:06] <idnar> I thought it just compared type(x).__name__ or something silly like that
[10:13] <mwhudson> idnar: naive!
[10:13] <mwhudson> mixed type comparisons are inherently as insane as a sack of cats anyway
[10:16]  * idnar giggles to hide the hysteria in his voice
[11:03] <spiv> mwhudson: *boggle*
[11:05] <spiv> mwhudson: because it would be terrible if sorted([1, 1j, 'bob']) didn't keep 1 and 1j together... ;)
[11:10] <mwhudson> spiv: also see my comment about cats
[13:18] <Zand3r> Is there any bzr specific documentation covering workflows tied to the Eclipse IDE? Having read the 'known issues' for bzr-eclipse I opted to try qbzr-eclipse but I can not see how I would take an existing eclipse project, create feature-branches and switch between them. I raised this over the weekend and am no further... I'd be happy for the bulk of my bzr interaction to be via bzr explorer but even that doesn't help the feature branches show as ec
[13:18] <Zand3r> projects without a lot of manual importing each time.
[13:25] <bialix> Zand3r: is your existing eclipse project is under bzr control?
[13:27] <bialix> perhaps you want to use workflow with one lightweight checkout and many treeless branches in shared repo?
[13:28] <Zand3r> bialix: Currently no (I've tried putting it under bzr control using qbzr-eclipse and bazaar explorer.... the former litters it with a couple of directories like 'trunk' but bazaar explorer seems to initialise it correctly..... what I do after that I am stuck (ultimately I will upload the project to a central bazaar repository but that doesn't solve the issue of switching branches so that the eclipse project represents the current branch).
[13:30] <Zand3r> bialix: Am I correct in thinking that 'many treeless branches' will mean a directory per branch... if so then there does not seem to be a way to have eclipse show all branches and/or have my currently active project 'become' the branch I want to use unless I'm totally missing something obvious.
[13:30] <bialix> I don't use eclipse, so I can be totally wrong, but IIRC author of qbzr-eclipse said he's using approach of light checkout of many branches
[13:30] <bialix> Zand3r: current bzr model is always 1 directory per branch
[13:31] <Zand3r> bialix: Ok... Someone at the start of the weekend also suggested lightweight checkouts for use with eclipse so there must be something in that I just can't see how it works with Eclipse - I need to play some more I think.
[13:31] <bialix> lightweight checkout can switch between branches
[13:31] <bialix> wait a sec
[13:32] <bialix> Zand3r: http://doc.bazaar-vcs.org/latest/en/user-guide/organizing_your_workspace.html#local-sandbox
[13:33] <bialix> one lightweight checkout allows you to have one working directory for Eclipse
[13:34] <bialix> and you can create as many feature branches in separate repo as you need
[13:34] <bialix> to visualize branches in repo bzr-explorer is very good
[13:35] <bialix> I really don't have experience with bzr eclipse plugins and I dunno if any of them capable to show you shared repo content
[13:35] <bialix> but you can file a bug as wishlist ;-
[13:35] <bialix> but you can file a bug as wishlist ;-)
[13:36] <Zand3r> Interesting... I think I need to create a repository elsewhere on the disk temporarily for testing, import my project into that and perform a lightweight checkout in Eclipse (depending on how well the gui tools support this  - if at all)
[13:36] <Zand3r> I'll have a play and see what happens - thanks for the pointers
[13:36] <bialix> mmm, I think it's better to create light checkout from command-line (or bzr explorer) and open it in eclipse then
[13:39] <Zand3r> I'm looking at this from the perspective of my colleague who i'm going to ask to use this system alongside me so I'm trying to do everything via a gui which would be within his comfort zone (as opposed to the command line) however bzr explorer looks 'really' nice so I see no issues with relying on that for the bzr interaction and using Eclipse only for code editing, etc. assuming Eclipse doesn;t have a problem with that (I'll have to see if Eclipse 
[13:39] <Zand3r> refresh the project files when bzr explorer switches the branch)
[13:41] <bialix> qbzr-eclipse and bzr-explorer use dialogs from qbzr plugin under the hood, so there is possible overlap in functionality
[13:42] <bialix> what is your OS?
[14:33] <faldridge> is the ability to do a bzr branch on an svn repo built-in, or do you need the bzr-svn plugin?
[14:34] <jelmer> faldridge: you need the bzr-svn plugin
[14:34] <faldridge> jelmer: ok, thanks.
[15:01] <jimmy_dean> Currently while trying to pull from a remote branch to a Windows XP machine, bzr is never able to complete that pull no matter what. I've tried this on several different installs of Windows. Everytime is raises a Memory.Exception error after churning on the pull for several minutes. Any ideas what this means?
[15:01] <jimmy_dean> the same task on Linux or OS X finishes fine, only does this on Windows
[15:59] <Zand3r> Can anyone please advise if it is possible to perform a lightweight checkout (and branch/switch) in Bazaar Explorer as detailed here http://doc.bazaar-vcs.org/latest/en/user-guide/organizing_your_workspace.html#local-sandbox - it would appear not but I am new to bzr (and by extension the explorer gui) so want to make sure I am not missing something.
[16:06] <bialix> Zand3r: sure
[16:07] <bialix> Zand3r: use menu Bazaar -> Start -> Checkout
[16:09] <bialix> to switch Bazaar -> Work -> Switch Checkout
[16:09] <bialix> there is excellent tour, did you saw it?
[16:10] <bialix> Zand3r: http://doc.bazaar-vcs.org/explorer/en/visual-tour-windows.html
[16:10] <bialix> there is also pages for GNOME, KDE and MacOSX
[16:12] <phinze> so why does `bzr switch` require access to the old url?
[16:13] <phinze> use case: switching from a non-absolute DNS reference to a server ('dev') to an absolute one: ('dev.domain.com') ... switch bailed on trying to resolve 'dev', but unbind/bind worked
[16:13] <phinze> so no problem really just curious
[16:14] <phinze> hmmm " For heavyweight checkouts, this checks that there are no local commits versus the current bound branch, then it makes the local branch a mirror of the new location and binds to it.
[16:14] <phinze> i guess that would do it, so bzr switch --force would probably work
[16:15] <Zand3r> bialix: I saw the bzr explorer tour thanks... Bazaar -> Start -> Checkout does not give an option to make it lightweight
[16:15] <bialix> Zand3r: IIRC it will create lightweight checkout by default
[16:16] <Zand3r> bialix: Oh! - doh! - Thanks.
[16:16] <bialix> phinze: there is bug about this problem
[16:16] <bialix> phinze: this partially fixed in bzr 2.0 (--force flag)
[16:17] <bialix> Zand3r: it's not obvious, I know
[16:17] <bialix> Zand3r: try it
[16:57] <j^> if i get AttributeError: 'module' object has no attribute 'ProgressBarStack' in a local loggerhead install with bzr 2.0 is this a known problem and is there an easy fix?
[17:10] <fullermd> It probably means a plugin is out of date.
[17:18] <joke> hi. I'm new to using bzr and I would like to know the signature checking works. I asked on the mailinglist but noone answered. Does someone know how it works?
[17:29] <joke> I configured bzr to sign every commit which works fine. But setting the option check_signatures=require don't seem to activate signature checking.
[17:49] <dash> jelmer: hi. any suggestions on making svn-import take less than 10G of RAM? :) (using bzr-svn 1.0)
[17:52] <fullermd> joke: Once upon a time check_ didn't do anything.  I don't know that it's ever been changed to, but I haven't really been paying attention.
[17:52] <davidstrauss> Is it safe to "cp -R repoA repoB"?
[17:53] <davidstrauss> I mean, even if people are using repoA?
[17:53] <fullermd> In an absolute sense, probably not, since there's no guarantee that cp would walk things in the same order as bzr updates them.
[17:54] <fullermd> You'd probably have to do something like 'loop rsync until nothing has changed' to be certain.
[17:58] <joke> fullermd: thanks. bzr 2.0 help configuration says bzr should check if signatures are present and valid if set to require. so there should create_signature should create them.
[17:58] <joke> fullermd: so there should be a different between both options.
[18:54] <faldridge> I've read the workflow for bzr-svn at <http://doc.bazaar-vcs.org/latest/en/user-guide/svn_plugin.html> but this talks about committing feature branches to the trunk.  What if I want to checkout trunk, create a branch locally, and then only push my branch back up?
[18:57] <Tak> faldridge: ...to a non-trunk branch?
[18:57] <faldridge> Tak: yes, I want to create the branch in the remote repo
[18:57] <jfroy|work> verterok: I'd like to add the fastimport plug-in to the standard core distro
[18:57] <jfroy|work> yay or nay on that?
[18:58] <faldridge> Tak: the idea being to submit the branch to the server for code review and then let the trunk committers approve or reject the branch
[19:00] <Tak> hmm, my gut feeling is that it should Just Work with `bzr push svn://path/to/feature/branch` , but I'm not sure
[19:01] <faldridge> Tak: ok, I'll give it a shot, thanks.
[19:18] <Peng_> Crap, the archaic build system on one of my machines doesn't like _simple_set_pyx.pxd.
[19:20] <Peng_> Wait, what are .pxd files? Pyrex? That's simple enough to upgrade.
[19:26] <Peng_> What's the minimum Pyrex version that bzr supports?
[20:34] <gioele> I'm using bzr-git. Is there a way to make bzr produce the git version of a bundle?
[20:36] <Peng_> Try "bzr send --format git" or so.
[20:36] <Peng_> Dunno if it's still experimental or not.
[20:37] <RenatoSilva> If we have deploy.bat in .bzrignore and we change the file name to deploy_server.bat, will bzr know somehow that no deploy.bat exists in the tree and tehrefore the user should either update or delete the pattern? (update in this case)
[20:37]  * Peng_ /away!
[20:40] <gioele> Peng: thank you!
[20:41] <gioele> RenatoSilva: yes if you use "bzr mv deploy.bat deploy_server.bat"
[20:41] <gioele> or bzr mv --help if you already moved the file
[20:44] <RenatoSilva> gioele: interesting! what other shell-like commands bzr has?
[20:44] <jam> Peng: ping
[20:45] <gioele> not many: ls and mkdir for example. I'd love to have bzr cp but it is not ready yet. Have a look at bzr help commands
[20:53] <RenatoSilva> bzr mkdir is like mkdir + add?
[20:53] <jderose> RenatoSilva: yes, exactly
[20:54] <maxb> How can I tell bzr that I want to diff my current branch with a non-tip revision of a different branch?
[20:54] <RenatoSilva> ok, thanks all
[20:55] <gioele> maxb: bzr diff --old revno:431:/path/to/branch
[20:55] <maxb> aha
[20:55] <maxb> thanks
[20:56] <gioele> maxb: bzr help revisionspec
[20:56] <gioele> np
[20:56] <RenatoSilva> however, I think in some point bzr could check the ignore changes even if not using bzr mv
[20:56] <gioele> RenatoSilva: ?
[20:56] <RenatoSilva> look at my example and forget bzr mvc
[20:57] <lifeless> maxb: or bzr diff -r 431:/path/to/branch
[20:57] <RenatoSilva> bzr mv
[20:57] <gioele> I still don't get it. Are you suggesting bzr should automatically do "bzr mv --auto" (<- this command really exist)?
[20:57] <Peng_> jam: <3
[20:58] <RenatoSilva> gioele: somehow bzr could tell the user the pattern is not being used anymore, probably because you have moved or deleted the underlying files
[20:59] <jam> Peng_: So what platform are you on that had pyrex 0.9.5? (and an easy upgrade to 0.9.6, but not to > 0.9.6.3?)
[20:59] <jam> hi lifeless
[20:59] <gioele> ah, you would like to clean up the list of ignore files... I think there are pros and cons to that, it is not a clear-cut situation
[20:59] <Peng_> jam: Your average, everyday old, out-of-date platform. There's nothing wrong with dropping support for it. And both upgrades were easy, just installing from source.
[21:01] <Peng_> jam: (Ubuntu Gutsy, but you didn't hear that from me.)
[21:02] <RenatoSilva> gioele: at least the ones matching single files (without regex)
[21:03] <gioele> RenatoSilva: on you branch. How can bzr know about what is happening on other people's working trees?
[21:05] <Peng_> jam: FYI: bzrlib/_static_tuple_c.c:693: warning: function declaration isn’t a prototype
[21:10] <jam> Peng_: can you try to just remove the 'void' from init_static_tuple_c(void) and see if that makes the warning go away?
[21:10] <jam> line 650 by my count
[21:12] <Peng_> 737 for me.
[21:13] <Peng_> Err, wait, from .h or .c?
[21:13] <Peng_> Never mind.
[21:13] <jam> Peng_: .c
[21:13] <Peng_> jam: Did that. Now it warns twice, lines 693 & 738.
[21:14] <jam> Peng_: hmm... so 693 maybe you want to put *in* the 'void' and leave it for line 737
[21:15] <Peng_> jam: 693 is _workaround_pyrex_096, fyi
[21:15] <RenatoSilva> does bzr have a default ignore list?
[21:16] <Peng_> jam: And that does indeed fix it.
[21:16] <lifeless> hi jam
[21:16] <Peng_> RenatoSilva: Yes. It's dumped to ~/.bazaar/ignore too.
[21:16] <Peng_> RenatoSilva: Or was, anyway. Dunno the situation now.
[21:16] <RenatoSilva> Id like to print the list, but found nothing in bzr help ignore
[21:17] <Peng_> jam: I've been wanting to ask you, I'm interested in trying out your memory reduction stuff. Which branch(es) should I try?
[21:17] <jam> Peng_: wait about 1hr and then try bzr.dev :)
[21:17] <dash> memory reduction? this is relevant to my interests
[21:18] <dash> well ok, memory _usage_ reduction would be. Not so much ejecting SIMMs from my motherboard.
[21:18] <Peng_> jam: <3
[21:19] <jam> dash: Basically, python 'tuple' objects carry around a large Garbage Collector header
[21:19] <jam> I wrote a 'StaticTuple' class that refuses to reference objects that could create a ref cycle
[21:19] <jam> and drops the GC header
[21:19] <jam> which
[21:19] <jam> a) reduces peak mem about 20%
[21:20] <jam> b) Turns out to have a major impact on performance w/ large projects
[21:20] <jam> because the python "GC" is no longer evaluating these 500k nodes
[21:20] <jam> "time bzr branch launchpad-2a" was 11m => 8m for me, and about 17% less peak mem
[21:20] <jam> I'm still looking at other places to improve
[21:20] <jam> but that was a decent start worth landing... :)
[21:20] <luks> hm, what about long-running processes using bzrlib?
[21:21] <jam> luks: I would still expect a decent memory + performance improvement
[21:21] <lifeless> luks: what about them?
[21:21] <jam> I don't have any numbers on it
[21:22] <Peng_> Loggerhead is my main interest in RAM usage. Over the last 3 months it's gotten nearly unusable.
[21:22] <luks> but it would leak memory wouldn't it?
[21:22] <lifeless> luks: no
[21:22] <jam> luks: It isn't going to leak more memory than what we are already doing
[21:22] <luks> how does it get deleted?
[21:22] <jam> as these objects cannot participate in ref cycles
[21:22] <lifeless> luks: same as usual
[21:22] <jam> luks: standard ref counting
[21:22] <jam> python has 2 ways to track objects
[21:22] <lifeless> luks: they just don't participate in GC; refcounting still happens
[21:23] <luks> I thought you mean they are completely outside fo the GC system
[21:23] <jam> luks: well, there are 2 "GC" in python
[21:23] <lifeless> they are :P
[21:23] <jam> refcounting ,and cycle detector
[21:23] <luks> jam: I know, I thought you mean both
[21:23] <jam> it still is refcounted
[21:23] <jam> I don't think you can avoid that
[21:23] <jam> without using some sort of proxy object
[21:24] <jam> and if you have a proxy object... you have a refcounted object
[21:24] <jam> so if you want to reference one of these individually
[21:24] <jam> ...
[21:24] <jam> if we wanted to think harder about it, we could do like "nodes[10]", but you still need that 10 handle, which requires a python object...
[21:25] <jam> Peng_: the code to expose StaticTuple to the btree reader is in pqm now, so barring any issues, 20-30min it will be in bzr.dev
[21:28] <lifeless> jam: you've seen the progress bar?
[21:29] <lifeless> jam: looks like it failed
[21:29] <davidstrauss> How does Launchpad restrict users from accessing the shell while still offering the bzr+ssh transport?
[21:29] <lifeless> it does not use openssh
[21:30] <davidstrauss> lifeless: what does it use?
[21:30] <vxnick> being stupid here, but how can I specify a new remote location (for pull) for an existing working tree?
[21:30] <lifeless> twisted conch
[21:30] <lifeless> more or less
[21:30] <Peng_> vxnick: "bzr pull --remember ..."
[21:30] <luks> vxnick: bzr pull URL --remember
[21:30] <lifeless> vxnick: bzr pull --remember URL
[21:30] <Peng_> Jinx!
[21:30] <vxnick> that's the one, thanks all :)
[21:31] <davidstrauss> lifeless: thanks
[21:31] <jam> lifeless: yes, it is very nice to see
[21:31] <jam> (the progress bar)
[21:31] <vxnick> what about for a checkout? there's no --remember flag in the help for that
[21:31] <lifeless> vxnick: bzr switch URL
[21:31] <vxnick> thanks
[21:32] <jam> lifeless: I had not seen that you have the failure/error tracker, though
[21:32] <jam> well that and you don't stop on the first error now
[21:33] <lifeless> jam: I didn't think we'd changed the stop on first error
[21:33] <jam> Running [ 22% 4836 test(s) 107 failure(s) 127 errors(s) ] Current test ...
[21:33] <jam> lifeless: ^^ sure looks like it is not stopping
[21:33] <lifeless> jam: yeah
[21:33] <Peng_> Some of those are XFAIL/unsupported features, right?
[21:33] <jam> though: check-nodocs: extensions
[21:33] <jam>     $(PYTHON) -Werror -O ./bzr selftest -1 --subunit $(tests)
[21:33] <lifeless> jam: skips/missing dependencies will report as failures normally
[21:33] <lifeless> Peng_: yes
[21:34] <lifeless> jam: I smell a bug in the subunit integration
[21:34] <lifeless> still, I prefer it this way
[21:34] <jam> lifeless: prefer... ?
[21:34] <lifeless> you can run the error mail through subunit-filter | subunit2pyunit
[21:34] <jam> w/ subunit? Or getting "failures" for skips?
[21:34] <lifeless> jam: not stopping
[21:35] <lifeless> tells you all the issues in one roundtrip
[21:35] <jam> lifeless: yeah, long ago it was that way
[21:35] <jam> I think we changed it because the round-trip time was too long
[21:35] <jam> by the way, nobody else is stepping up to be the 2.1.0b1 RM, right?
[21:35] <jam> (so I should start focusing on that tomorrow)
[21:36] <lifeless> I think you're it, yes
[21:36] <Peng_> TypeError: can only concatenate tuple (not "StaticTuple") to tuple
[21:36] <Peng_> Looks like there are some real errors.
[21:39] <Peng_> That's not the only one, either.
[21:45] <mathepic> Grr
[21:45] <mathepic> The Loggerhead for bzr.dev isn't working :\
[21:47] <Peng_> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/ WFM, if that's what you mean
[21:48] <lamalex> Can I cherrypick multiple sets of revisions?
[21:49] <lamalex> something like bzr merge revX..revY,revN..revM branch
[21:49] <lamalex> ?
[21:50] <lifeless> yes
[21:50] <lifeless> do the first one
[21:50] <lifeless> then the second with --force
[21:50] <lamalex> lifeless: are you talking to me or someone else
[21:50] <Peng_> lamalex: You.
[21:51] <lamalex> how do i do one with --force and one without. two seperate commands?
[21:55] <lamalex> thanks lifeless
[21:57] <jam> Peng_: Yeah, it looks like we have more code that expects an explicit "tuple()" object that I didn't catch yet
[21:57] <jam> like (foo,) + value
[21:57] <jam> which thought it was concatenating tuples, etc
[21:58] <jam> and bencode(StaticTuple) fails as well...
[21:59] <jam> lifeless: can I use subunit without bootstrapping autoconf onto my windows machine?
[22:03] <jam> argh....
[22:03] <lifeless> jam: yes
[22:03] <jam> UnavailableFeature: Internally performed glob expansion
[22:03] <jam> ... :(
[22:03] <lifeless> jam: the python stuff is in python/
[22:03] <jam> lifeless: yeah, I set PYTHONPATH and got it to work
[22:03] <lifeless> then do:
[22:04] <jam> but there is no "setup.py" that I could find for subunit itself
[22:04] <lifeless> cat trace | subunit-filter --no-skip | subunit-ls > failing.list
[22:04] <lifeless> ./bzr selftest --load-list failing.list
[22:05] <lifeless> jam: right, its got C and perl and c++ all in the one project; setup.py is epic fail for that
[22:05] <jam> lifeless: but it should would be nice to put the  'subunit' module into my PYTHONPATH
[22:05] <jam> "sure would"
[22:06] <jam> and the pure-python scripts into the Scripts dir
[22:06] <jam> since I'm not building anything else...
[22:06] <jam> also, it fails a bit because if I do:
[22:06] <jam> --no-passthrough
[22:06] <jam> then it strips the extra context per failing test
[22:06] <jam> but if I don't
[22:06] <jam> then I get all the "make" garbage at the beginning
[22:06] <jam> anyway, I'll work through that
[22:07] <lifeless> what 'extra context' ?
[22:07] <jam> lifeless: when a blackbox test fails it includes the log
[22:07] <jam> ah, perhaps --subunit is stripping that out entirely?
[22:07] <lifeless> jam: --subunit drops that
[22:07] <jam> AssertionError: Unexpected return code 0 != 3
[22:07] <jam> not helpful
[22:07] <lifeless> my protocol branch of subunit is working towards supporting that
[22:07] <davidstrauss> Is there an equivalent to --tunnel-user= for bzr?
[22:08] <lifeless> davidstrauss: I don't know what --tunnel-user= is
[22:08] <lifeless> davidstrauss: so I can't answer the question
[22:09] <davidstrauss> lifeless: It's an option for svnserve allowing multiple users to use the same Unix user while forcing the user mentioned in commits, etc.
[22:09] <lifeless> davidstrauss: no; because commits are done on the client
[22:09] <davidstrauss> lifeless: Like a global --author
[22:09] <lifeless> davidstrauss: 'commit' to a smart server is actually 'push'
[22:09] <davidstrauss> ah
[22:10] <lifeless> you can write a pre tip change hook to reject users
[22:10] <lifeless> or you could write a post tip change hook to rebase-and-alter
[22:10] <lifeless> [though the latter may find bugs/limitations in what that hook is expected to do :P]
[22:18] <davidstrauss> lifeless: Hmm. Thanks for the suggestions. I think Bazaar will eventually have to find a way to enforce accountability for stuff like this. (Even if it's a separate field like "apparent user.")
[22:18] <mkanat> Pack -> 2a conversion seems really slow in 1.18.
[22:18] <mathepic> Update to 2.0
[22:18] <mkanat> Okay. :-)
[22:18] <lifeless> mkanat: its largely that 'pack' is much slower.
[22:19] <lifeless> mkanat: but 2.0.0 is somewhat better at the conversion
[22:19] <mkanat> lifeless: Ah, okay. :-)
[22:19] <mkanat> Yeah, I have an Intel X25-M SSD and it's still taken like 3 minutes and isn't done converting 6000 or so revisions yet.
[22:19] <mathepic> What are the best documents to read to get started in bazaar development?
[22:23] <Peng_> davidstrauss: People push others' revisions all the time, though.
[22:23] <Peng_> davidstrauss: I guess requiring GPG signatures would do it.
[22:23] <davidstrauss> yeah :-/
[22:24] <lifeless> are you looking for undeniability?
[22:26] <mkanat> Hmm. I just did "bzr reconfigure --use-shared" on a packs branch above a 2a repository, and it seems that my repository simply disappeared and no longer exists now.
[22:26] <mkanat> Not my 2a repository.
[22:26] <mkanat> The packs repository in the subdirectory. I just get: bzr: ERROR: No repository present: "file:///home/mkanat/projects/parse-stacktrace/"
[22:28] <Peng_> You might have a .bzr/repository.backup somewhere.
[22:28] <mkanat> Peng_: Actually, not that I see.
[22:28] <mkanat> I mean, it's ok, this was a checkout, but....
[22:28] <lifeless> file a bug please
[22:29] <lifeless> its probably because it was a checkout
[22:29] <jam> mkanat: the output of ls -R would probably be helpful
[22:29] <mkanat> lifeless: Okay.
[22:29] <lifeless> I suspect it changed it from checkout to standalone and didn't add a repo
[22:29] <mkanat> jam, lifeless: Okay. I'll see if I can reproduce.
[22:31] <lifeless> mkanat: firstly please just file the bug with all the data you have so far
[22:31] <mkanat> lifeless: Okay.
[22:34] <mkanat> Okay, filed: https://bugs.launchpad.net/bzr/+bug/449886
[22:34] <mkanat> And yes, it's reproducible.
[22:38] <phinze> hey bzr folk, what's everyone using for developer code reviews?
[22:39] <phinze> basically i'm looking for something that can do a diff between two branches with nice links out to the source code for when the reviewers want context
[22:39] <phinze> right now we're doing gist.github.com + manual hops to loggerhead, but wondering if there's anything out there people are using
[22:40] <jam> phinze: launchpad code review
[22:40] <jam> used to use Bundle Buggy
[22:40] <mkanat> phinze: I think review-board also supports bzr.
[22:42] <phinze> jam: oh you guys moved past bundle buggy?  that must have been recently?
[22:42] <jam> phinze: a few months ago...
[22:42] <RenatoSilva> can't understand the purpose of bzr merge --pull
[22:42] <phinze> ah gotchya, how are you liking it
[22:43] <phinze> mkanat: thanks for the review-board reference -- will check it out
[22:45] <jam> phinze: things to like, things to not like, I guess. The integration w/ the rest of launchpad is nice. It is missing a few bits that we used to use
[22:46] <jam> it has been getting better, though
[22:47] <mathepic> There are a lot of references to the bundle buggy on the site
[22:47] <RenatoSilva> can I have an alias in the branch rather than ~?
[22:48] <RenatoSilva> is there a command for that or will I need to manually edit branch.conf?
[22:53] <mkanat> lifeless, jam: It seems to be happening with branches too, not just checkouts.
[22:56] <mkanat> Oh, hmm, I might have an idea of what's going on.
[23:05] <mkanat> It might not actually be so severe.
[23:13] <lifeless> mkanat: why are you using reconfigure anyhow?
[23:13] <lifeless> mkanat: I thought you wanted to upgrade?
[23:16] <mkanat> lifeless: I did the upgrade and it kept it in the repo, didn't realize, and then did a reconfigure.
[23:16] <mkanat> lifeless: I mean, kept it in the standalone repo.
[23:17] <mkanat> Okay, I explained what happened, on the bug.
[23:19] <davidstrauss> Is there a way to include function names in preview patches with "bzr send"?
[23:23] <lifeless> davidstrauss: not at the moment, there is a general request that we support function names in diffing; that would follow on
[23:24] <davidstrauss> lifeless: In the mean time, it seems like it would make sense to offer --diff-options for send, just like with diff.
[23:25] <lifeless> davidstrauss: file a bug :)
[23:27] <davidstrauss> lifeless: Done :-) https://bugs.launchpad.net/bzr/+bug/449923
[23:43] <mathepic> I'm trying to find where bzr send creates the diff
[23:43] <mathepic> Could someone help me out
[23:48] <mathepic> Does send create its diff with MergeDirective._generate_diff
[23:51] <RenatoSilva> IDEs would help on that
[23:52] <mathepic> Nah, they love to take over the project structure
[23:52] <mathepic> Not something I want to do
[23:53] <RenatoSilva> unfortunately Eclipse has not a good Python IDE
[23:55] <mathepic> I left Eclipse
[23:55] <mathepic> Now I just use emacs
[23:55] <mathepic> Bit more primitive, but you can get everything done