[08:02] <vila> hi all 1
[08:02] <vila> every 1 ? :-/
[08:16] <jam> morning vila
[08:16] <jam> I'm actually 2, today
[08:16] <jam> :)
[08:16] <vila> :)
[08:17] <spiv> vila: hi :)
[08:17] <jam> hey spiv
[08:17] <spiv> jam: I just made lp:~spiv/twisted/deferred-no-failure-tracebacks-by-default
[08:18] <spiv> jam: the existing benchmarks on http://speed.twistedmatrix.com/ don't really exercise this case at all, so I'll probably try make one
[08:19] <jam> spiv: you need a reasonable amount of state, which is probably the big 'bug'
[08:19] <spiv> Right
[08:19] <jam> because it scales based on your working depth, etc
[08:19] <jam> which means isolated testing probably is quite fast
[08:19] <spiv> I'd be interested to know how much that patch helps
[08:19] <jam> but real-world use is bad
[08:19] <jam> spiv: the proxy patch?
[08:19] <spiv> Well, that one too :)
[08:19] <jam> ah ^^
[08:19] <spiv> But my patch to Twisted as well
[08:19] <jam> I missed the link
[08:20] <spiv> Because there's the odd spot (like t.w.xmlrpc.Proxy) that creates these Failures directly it might have less impact than hacking self.tb = None in Failure
[08:21] <spiv> But maybe it's almost all of the cases we care about?  If it's not too much effort for you to test, please do :)
[08:21] <jam> spiv: from all the discussions I've read on the bug, and grepping through the codebase, the tracebacks are pretty much never used
[08:22] <jam> there is failure.printTraceback which only has 1 or 2 callsights
[08:22] <jam> site
[08:23] <jam> jelmer: feel better, buddy
[08:24] <spiv> jam: right, I think so
[08:25] <spiv> jam: although I expect e.g. unhandled errors in a deferred chain emit them
[08:25] <spiv> jam: that's probably the most common case, and I think they'd probably be valuable there :/
[08:25] <jam> spiv: I think they would be, but I also wonder if we could just leave 'self.tb' and not try to actually walk it
[08:25] <spiv> jam: people using twisted often find it hard enough to track down where those are coming from as it is
[08:25] <jam> I realize some global state may change, but is it enough to warrant?
[08:26] <jam> spiv: I think an env var sort-of-thing is ideal here
[08:26] <spiv> Leaving self.tb is probably a bad idea, because it basically is a memory leak
[08:26] <jam> spiv: well ATM it leaves it until __getstate__ which seems ~ok
[08:26] <jam> or the issue there is that __getstate__ happens before the traceback could be printed?
[08:27] <jam> (because it has no errbacks ?)
[08:27] <spiv> Well, when Deferred handles Failures it cleans them before leaving _runCallbacks
[08:28] <spiv> So it at least avoids the expensive cleanFailure logic if there's another callback in the chain about to be run, because it might handle that failure (and turn the result back to a non-failure)
[08:28] <spiv> We're especially badly hit I think
[08:28] <jam> spiv: initial branch of your stacked branch was very unhappy. Lots of time in Repo.get_parent_map(). I killed it after 115s, and 'bzr branch lp:twisted' completed in 86s.
[08:28] <jam> we should definitely look into that
[08:28] <spiv> Because the codehosting VFS code is mostly building an async API on a sync API
[08:29] <jam> sure
[08:29] <spiv> So the common "d = getSomeDeferred(); d.addCallback(…); d.addErrback(…)" pattern will hit cleanFailure every time, because there's a result immediately
[08:29] <jam> and since everything returns immediately, deferred has nobody to call
[08:29] <spiv> Right
[08:30] <spiv> jam: ouch, and weird
[08:30] <spiv> jam: I guess keep the .bzr.log of that and we can look into it later
[08:30] <spiv> Anyway, it's EOD for me
[08:31] <spiv> Hopefully I've given you some stuff worth playing with :)
[08:32]  * spiv -> afk
[08:32] <spiv> Happy hacking!
[08:33] <jam> spiv: have a good night
[10:08] <lifeless> jelmer: typo in dulwich
[10:08] <lifeless>         of head, then following theat will be the parents.
[11:52] <bialix> hi
[11:52] <bialix> I want to talk about very strange behavior of bzr in mixed windows/linux environment
[11:54] <bialix> if I push from repository branch to other machine (different OS) then I got on the destination end repository branch with shared repository in the same directory where new branch created
[11:54] <bialix> if I push from standalone branch then I got standalone branch on destination end
[11:55] <bialix> it seems to not depend on whether I have on destination end real shared repo or not
[11:58] <bialix> no, it depends
[11:58] <bialix> sorry
[11:59] <bialix> if destination end has no shared repository then I got this strange effect
[12:11] <bialix> Bug #744893
[12:41] <etenil> Hi there
[12:44] <etenil> I created a tag in my branch, and when I try pushing it on my repo, nothing happens, it says "nothing to push". Am I doing something wrong?
[13:06] <maxb> etenil: I think it will have pushed the tag anyway, but the message it gives only reports on revisions
[13:08] <glob> greeting all; every time i commit to a bzr repo, i get a 'math range error'...
[13:08] <glob> bzr: ERROR: Server sent an unexpected error: ('error', 'math range error')
[13:08] <glob> however the commit is successful
[13:09] <glob> local bzr is out of sync, and requires a 'bzr up' to make it happy again
[13:11] <idky> Is there some way to use "vim -R -" as a default pager for `bzr diff`?
[13:12] <etenil> maxb: ah thanks
[13:12] <etenil> I'll make sure it has
[13:12] <Kamping_Kaiser> idky: is that like 'view'?
[13:13] <idky> Kamping_Kaiser: pretty much
[13:16] <Kamping_Kaiser> bzr accepts PAGER=, but i dont think pAGER supports '-' in its commandlines
[13:17] <Kamping_Kaiser> bzr-pager (the plugin) appears to hard code less as the pager value, so not sure how that works with PAGER either
[13:19] <idky> Kamping_Kaiser: I just enter `bzr PAGER='view -'` then?
[13:21] <Kamping_Kaiser> no, "PAGER='view -' bzr diff" causes bzr to throw up since it thinks it should read from stdin (over the -), not sure what the fix to that is.
[13:21] <Kamping_Kaiser> but i will be interested to see what someone else says as the fix
[13:25] <Kamping_Kaiser> i'm off to bed, i'll read up tomorrow :)
[13:25] <Kamping_Kaiser> 'later all
[13:36] <spiv> glob: wow, I'd love to see the server's log of that
[13:37] <glob> i've asked the admin to eyeball the log, i don't have access
[13:37] <spiv> glob: can you add '-Dhpss' to your command line to enable some more logging, and attach the resulting ~/.bzr.log to a bug report?
[13:38] <spiv> glob: (and add anything you are able to discover about the server log)
[13:38] <glob> ok, will do (net time i have to commit, it's a prod instance)
[13:38] <glob> thanks :)
[13:38] <spiv> glob: thanks
[13:38] <spiv> glob: it'd also be good to know which version of bzr the server is running
[13:39] <spiv> glob: (you can find out using the bzr-ping plugin from https://launchpad.net/bzr-ping if you don't know)
[13:44] <glob> spiv, 2.3.1
[14:58]  * jelmer waves
[15:35] <jam> hi jelmer, feeling better?
[16:12] <jelmer> jam: Yeah, much better. Still have a lingering headache so I think I'm going to do some trivial stuff that doesn't require much thought.
[16:57] <knighthawk> is *anyone* using bzr-svn on Fedora? it seems *way* too hard to set up.
[16:57] <jelmer> knighthawk: hi
[16:57] <jelmer> knighthawk: it's not packaged?
[16:58] <knighthawk> jelmer, I haven't been able to find one.
[16:59] <jelmer> hmm, whohas doesn't report any either
[16:59] <jelmer> knighthawk: isn't it just a matter of installing bzr and python-subvertpy and then just unpacking the tarball as ~/.bazaar/plugins/svn ?
[16:59] <knighthawk> took out a branch. had to revert it then install docutils. now trying to install Subvertpy which doesn't have a rpm yet.
[17:00] <knighthawk> so far can't install python-subvertpy
[17:00] <knighthawk> found a src.rpm but running into an issue with rpmbuild on it.
[17:01] <jelmer> centos apparently has packages
[17:01] <jelmer> http://pkgs.org/package/python-subvertpy
[17:01] <knighthawk> the weird thing is that make and make install seemed to work fine *without* subvertpy. but of course when I then tried to use it...
[17:01] <knighthawk> thanks jelmer
[17:46] <vanguard> I would like to push to a plain FTP, but it fails because of "Append/Restart not permitted". What can I do?
[18:20]  * knighthawk hoping that I can run a centos rpm on a fedora 14 box
[22:58] <knighthawk> trying to work with bzr-svn with a self signed certificate. don't know how to tell it to ignore the face that the certificate is self signed.
[22:59] <jelmer> knighthawk: what error are you getting?
[22:59] <knighthawk> ERROR: pycurl.error: (60, 'SSL certificate problem, verify that the CA cert is OK.
[23:01] <jelmer> knighthawk: try using svn+https://
[23:02] <knighthawk> will do jelmer thanks.
[23:03] <knighthawk> thanks jelmer
[23:03] <jelmer> you're welcome
[23:04]  * jelmer gets some sleep