[00:02] <gregcoit> hi.  how do I undo a "bzr rm"?  no other commands have been run since then (like "bzr ci").
[00:06] <maxb> bzr revert pathname should do it
[00:06] <gregcoit> maxb: ty - that worked!
[00:33] <lifeless> mgz: deryck
[00:50] <poolie> good morning
[00:50] <poolie> hi lifeless
[00:50] <lifeless> hi poo
[00:51] <lifeless> hi poolie
[00:52] <poolie> snort
[00:53] <mgz> you really want those last three letters
[00:54] <mgz> lifeless: should I bug him on irc or subscribe him to the bug or what?
[00:55] <lifeless> mgz: overloaded word that
[00:55] <lifeless> I'd discuss with him
[00:55] <lifeless> and see if he wants a unique bug or what have you
[00:55] <mgz> thanks.
=== jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it | Launchpad down/read-only from 23:00 - 00:30 UTC for a code update
[01:04] <spiv> Good morning.
[01:06] <lifeless> hola
=== Chex changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it
[02:25] <poolie> hi there spiv
[02:37] <thumper> in the bzrlib source
[02:37] <thumper> is there a method to do interdiffs?
[02:38] <poolie> thumper: i don't think so-
[02:38] <lifeless> mmm
[02:38] <lifeless> depends on what you mean
[02:38] <thumper> I'd really like to not to have to shell out to interdiff binary
[02:38] <lifeless> ok, that, no - we haven't done that yet.
[02:39] <thumper> I have an old review diff, and a new review diff generated from newer commits
[02:39] <thumper> I want to see the difference between them
[02:39] <thumper> (and email it out)
[02:39] <lifeless> right, lp mp incremental changes ?
[02:39] <thumper> yep
[02:39] <lifeless> if I can suggest a different way
[02:40] <lifeless> you have the old tip O and the new tip N
[02:40] <lifeless> do a preview-merge with O and get a tree - not a diff
[02:40] <lifeless> do a preview-merge with N and get the tree.
[02:40] <lifeless> then do diff between the two preview trees
[02:41] <lifeless> I'd expect that to be more useful, and its not going to be an interdiff, so its easier to read.
[02:42] <thumper> are preview trees up to that yet
[02:42] <thumper> ?
[02:42] <lifeless> If they aren't it will be straight forward to fix I suspect
[02:42] <lifeless> if they aren't I'd really like to know anyhow :)
[02:54] <poolie> lifeless: re ease of reading, the output of interdiff is not a diff of diffs
[02:54] <poolie> iirc
[02:55] <poolie> it's just a diff
[02:55] <lifeless> ah yes
[02:55] <lifeless> I'm thinking debdiff
[02:55] <lifeless> which is interdiff
[02:55] <lifeless> of patches
[02:56] <lifeless> and known to blow up spectacularly with some packages
[02:56] <poolie> jam (if any), lifeless, we need a way to get debug info for out of memory errors
[02:57] <lifeless> poolie: nevertheless the failure modes in two previews seem better to me, IMBW.
[02:57] <lifeless> poolie: yes, agreed.
[02:58] <lifeless> hmm, -Derror should give us something
[03:00] <poolie> can anyone confidently answer about bzr-svn in https://answers.edge.launchpad.net/bzr/+question/116868
[03:00] <poolie> there is a bug for this
[03:00] <poolie> may need jam jam
[03:01] <lifeless> jam jam ?
[04:08] <jam> lifeless, poolie: you rang?
[04:08] <lifeless> I didn't; poolie may have
[04:08] <jam> poolie: what sort of mem info do you want?
[04:09] <lifeless> jam: there is an OOM error occuring on a 30MB file according to some guy in some bug report.
[04:09] <poolie> jam, when bzr crashes with MemoryError i'd like us to get some useful debugging info back from the user
[04:09] <lifeless> be nice to be able to see whats really oging on.
[04:09] <poolie> there's a bug asking for this
[04:12] <jam> poolie: I remember chatting with you about this a bit. One of the problems is that stuff like 'str' objects aren't in the gc list
[04:13] <jam> strs and ints/floats/etc being the most obvious not present
[04:13] <jam> and now StaticTuple :)
[04:15] <poolie> so i guess the question is:
[04:16] <poolie> if there is any data we could easily report we should do it
[04:16] <poolie> even if it's not 100% complete or if it's useful in only a subset of cases
[04:16] <jam> poolie: well, you can certainlly call trace.debug_memory()
[04:17] <jam> which would at least tell you vmpeak and vmsize, etc
=== poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.2 is out
[04:17] <poolie> mm, we should put that into the apport file ,if we don't already
[04:18] <poolie> i don't know if that will tell us _why_ we ran out though
[04:18] <poolie> perhaps the traceback may give some clue
[04:18] <poolie> can we take the question that you'd ask the user experiencing an oom problem
[04:18] <poolie> and automatically answer it when they first hit the bug?
[04:58] <jam> poolie: I'd have to think about what the first questions would be. Things I would usually ask are stuff like "what action were you taking" which should already be in the log file
[04:58] <jam> what the size of files are you working with
[04:58] <jam> I think that would be a bit hard to automatically answer
[05:00] <jam> knowing the sizes of objects in the frames on the stack could be useful
[05:12] <poolie> jam i guess we could walk up the stack and print either the actual contents of the locals, or some data about them
[05:12] <poolie> such as their estimated size
[05:12] <jam> poolie: I think contents is risky, but size could be reasonable
[05:12] <poolie> some risk of leaking private data there
[05:13] <jam> well, I'm thinking more about 100MB files
[05:14] <poolie> that too
[05:14] <poolie> there is a cgitb module that does some of this
[05:15] <poolie> including trimming large values
[05:15] <poolie> so there's a function (in meliae?) that estimates the size of an object?
[05:30] <jam> poolie: in python 2.6 you can use sys.getsizeof()
[05:30] <jam> meliae also exposes something like this
[05:30] <poolie> ok
[05:31] <poolie> so this won't tell us if we're using lots of memory in a global not referenced by the stack
[05:31] <poolie> and it would probably be too noisy to print all the globals
[05:31] <poolie> but that may be an unusual condition
[05:31] <poolie> i guess we could print globals using a lot of memory
[05:34] <jam> we could walk gc.get_referents() at a cost of 1 pointer per object
[05:37] <poolie> cost in terms of needing to allocate more memory to do that?
[05:53] <jam> yeah
[05:53] <jam> for the list that holds it
[05:54] <jam> it could be a problem if we are already oom
[06:21] <lifeless> jam: for when you awake.
[06:22] <lifeless> https://bugs.edge.launchpad.net/bzr-builddeb/+bug/552950
[06:22] <ubot5> Launchpad bug 552950 in bzr-builddeb "Additional changelog entries are modified when merging another branch (affected: 1, heat: 10)" [Medium,Triaged]
[06:22] <lifeless> please comment
[06:57] <yao> if I commit 10 times, from rev 1 to rev 10, in my local branch, and didn't push them to remote branch yet,
[06:57] <yao> I want to uncommit commit #5, what should I do?
[06:57] <yao> 'bzr uncommit' doesn't help,
[07:05] <poolie> yao: it depends on exactly what you want
[07:05] <poolie> do you want to pretend #5 never happened, or do you want to just reverse it's effect?
[07:06] <yao> poolie: former, I think,
[07:06]  * yao is wondering whether it is possible to pretend #5 never happened
[07:45] <aidalgol> Google is turning up nothing on this: is it safe to edit .bzrignore?
[07:49] <spiv> Yep.
[07:52] <aidalgol> OK, good.
[07:53] <aidalgol> Why might this line (in a .bzrignore) have *two* stars?
[07:53] <aidalgol> lisp/**/loaddefs.el
[08:00] <spiv> aidalgol: see 'bzr help ignore', it explains the patterns
[08:00] <spiv> (Also, 'bzr help patterns')
[08:01] <spiv> To answer your specific query: "/**/ - Matches 0 or more directories in a path"
[08:59] <poolie> hi there spiv, vila
[08:59] <vila> hey poolie
[09:00] <poolie> sorry yao i missed you there
[09:00] <poolie> are you still here?
[09:00] <poolie> have a look at the bzr-
[09:00] <poolie> have a look at the bzr-rewrite plugin
[09:00] <yao> poolie: I am here...
[09:01] <poolie> do you want to keep the later commits as distinct commits?
[09:01] <poolie> or are you happy to fold them into just one?
[09:03] <yao> poolie: I want to keep later commits as distinct ones...
[09:03]  * yao is looking at https://launchpad.net/bzr-rewrite
[09:05] <poolie> try bzr help rebase
[09:22] <poolie> we should document that specific case
[10:36] <yoroy> How do I find where bzr is intalled on OS X? Trying to get the Eclipse plugin working.
[10:45] <C-Keen> yoroy: which bzr will tell you on a Terminal
[10:46] <yoroy> C-Keen: forgot to mention I don't want to use a Terminal
[10:46] <yoroy> :)
[10:46] <yoroy> but I could handle it if I knew the command
[10:46] <C-Keen> I don't understand
[10:47] <GaryvdM> mgz: Ping
[10:47] <yoroy> C-Keen: the eclips plugin asks me for the path to the bzr executable. I don't know how to find that path
[10:47] <C-Keen> yoroy: well type 'which bzr' on a Terminal and you know
[10:48] <yoroy> C-Keen: thank you
[10:52] <mgz> pong garyvdm, but I'm leaving in five minutes, hopefully be around a bit later though
[10:52] <GaryvdM> Hi mgz
[10:52] <GaryvdM> The .pyo in the installer were fine
[10:53] <GaryvdM> for plugins
[10:53] <GaryvdM> but the .pyo that were created for plugins that I had in BZR_PLUGIN_PATH got doc strings removed
[10:54] <mgz> did you see the log?
[10:54] <GaryvdM> So if we could get the files in library.zip to be -OO
[10:54] <mgz> you've not got the final part of my don't-recompile-plugin-pyo-files fix
[10:54] <GaryvdM> but leave the exe as -O
[10:55] <GaryvdM> Oh - were is that?
[10:55] <mgz> you need the recent change to bzr setup.py and/or the third rev in the bzr-windows-installer merge proposal
[10:55] <mgz> <GaryvdM> but leave the exe as -O <- if one of us can work out how to do this, it would also be good.
[10:55] <GaryvdM> Ok - I find that an try a build...
[10:56] <mgz> I saw the bug with recompilation and stopped investigating there, but getting the exe as -O would be good.
[10:56] <GaryvdM> mgz: maybe build the library.zip ourselfs
[10:57] <GaryvdM> Ok cool.
[10:57] <mgz> there's probably a neater way, just didn't get as far as looking for it.
[10:57] <GaryvdM> Thanks
[10:58] <mgz> okay, leaving now.
[14:02] <bobslee> hi, does bzr explorer install without a glitch on mac osx?
[14:12] <GaryvdM> bobslee: The installer works well
[14:15] <GaryvdM> bobslee: There are some polish issues on mac though - like the app name in the menu shows as "python".
[14:17] <GaryvdM> bobslee: I'm also not sure if it installs a app icon, so either run "bzr explorer" from a terminal, or create a shortcut icon.
[14:24] <bobslee> GaryvdM: ok thanx for info. But it requires a bunch of dependencies Qt, QBzr.. takes a while to install?
[14:26] <GaryvdM> bobslee: Maybe you are reading a old info. The latest installers have every thing you need.
[14:27] <GaryvdM> bobslee: http://wiki.bazaar.canonical.com/MacOSXBundle/SnowLeopard
[14:27] <GaryvdM> bobslee: What version of Mac OS do you have
[14:28] <bobslee> 10.5 (leopard)
[14:28] <GaryvdM> bobslee: The 10.6 installer has everything, but for the 10.5 installer, you have to install Qt
[14:29] <bobslee> GaryvdM: allrighty, thanx I'll give it a try
[14:29] <GaryvdM> bobslee: http://wiki.bazaar.canonical.com/MacOSXBundle
[14:31] <bobslee> GaryvdM: do you whether bzr supports reverse merging (like i.e. in svn: merge -r1000:993) ?
[14:31] <GaryvdM> bobslee: yes
[14:34] <bobslee> GaryvdM: I prefer to install bzr (explorer) via macports. Is that a good choice? - because I want to prevent dependency/upgrade nightmares..
[14:35] <GaryvdM> bobslee: my experience no, but I don't use a mac much, so I would say investigate yourself.
[14:35] <GaryvdM> bobslee: check if they have the latest versions...
[14:56] <bobslee> GaryvdM: thanx again
[15:43] <detritux> hi all. I've been trying to push my local modification to my launchpad project for a while but never succeeded: Transport operation not possible: readonly transport
[15:43] <detritux> I added my ssh keys to launchpad and logged into launchpad from my bazaar explorer as described in one of the tuto
[15:43] <detritux> any ideas?
[15:51] <GaryvdM> detritux: Have you done 'bzr launchpad-login'?
[15:51] <detritux> yes I did that in the bazaar explorer
[15:51] <detritux> if I run it without any arguments it prints my login so I assume it worked
[15:52] <GaryvdM> detritux: What is the url that you are pusing to.
[15:53] <detritux> bzr+ssh://bazaar.launchpad.net/~ugocupcic/sr-ros-interface/trunk/
[15:53] <GaryvdM> detritux: That's odd.
[15:54] <detritux> :S yeah, I only found tutorials / forums and it seemed quite straightforward each time
[15:54] <GaryvdM> detritux: could you please pastbin the relevant entry from ~/.bzr.log
[15:57] <detritux> 0.173  bazaar version: 2.1.1
[15:57] <detritux> 0.173  bzr arguments: [u'commit', u'-m', u'added dependency to robot_state_publisher for easier build.', u'shadow_robot/sr_hand/manifest.xml']
[15:57] <detritux> 0.175  encoding stdout as osutils.get_user_encoding() 'UTF-8'
[15:57] <detritux> 0.210  ssh implementation is OpenSSH
[15:57] <detritux> 8.869  opening working tree '/home/genugo/Projects/st-ros-interface'
[15:57] <detritux> 8.934  Traceback (most recent call last):
[15:57] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 853, in exception_to_return_code
[15:57] <detritux>     return the_callable(*args, **kwargs)
[15:57] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1055, in run_bzr
[15:57] <detritux>     ret = run(*run_argv)
[15:57] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 661, in run_argv_aliases
[15:57] <detritux>     return self.run_direct(**all_cmd_args)
[15:57] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 665, in run_direct
[15:57] <detritux>     return self._operation.run_simple(*args, **kwargs)
[15:57] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 122, in run_simple
[15:57] <detritux>     self.cleanups, self.func, *args, **kwargs)
[15:57] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 156, in _do_with_cleanups
[15:57] <detritux>     result = func(*args, **kwargs)
[15:57] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/qbzr/lib/commands.py", line 788, in run
[15:57] <detritux>     return run_subprocess_command(cmd, bencoded)
[15:57] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/qbzr/lib/subprocess.py", line 789, in run_subprocess_command
[15:57] <detritux>     return commands.run_bzr(argv)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1055, in run_bzr
[15:58] <detritux>     ret = run(*run_argv)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 661, in run_argv_aliases
[15:58] <detritux>     return self.run_direct(**all_cmd_args)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 665, in run_direct
[15:58] <detritux>     return self._operation.run_simple(*args, **kwargs)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 122, in run_simple
[15:58] <detritux>     self.cleanups, self.func, *args, **kwargs)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 156, in _do_with_cleanups
[15:58] <detritux>     result = func(*args, **kwargs)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 3138, in run
[15:58] <detritux>     exclude=safe_relpath_files(tree, exclude))
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/decorators.py", line 192, in write_locked
[15:58] <detritux>     self.lock_write()
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/workingtree_4.py", line 618, in lock_write
[15:58] <detritux>     self.branch.lock_write()
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 2377, in lock_write
[15:58] <detritux>     remote_tokens = self._remote_lock_write(token)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 2367, in _remote_lock_write
[15:58] <detritux>     repo_token or '', **err_context)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 52, in _call
[15:58] <detritux>     return self._client.call(method, *args)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/client.py", line 132, in call
[15:58] <detritux>     result, protocol = self.call_expecting_body(method, *args)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/client.py", line 145, in call_expecting_body
[15:58] <GaryvdM> detritux: Next time, please use something like http://pastebin.org/ when you paste :-)
[15:58] <detritux>     method, args, expect_response_body=True)
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/client.py", line 81, in _call_and_read_response
[15:58] <detritux>     expect_body=expect_response_body),
[15:58] <mwhudson> detritux: paaaaaaaaaaaste bin
[15:58] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/message.py", line 306, in read_response_tuple
[15:58] <detritux>     _translate_error(self.args)
[15:59] <detritux>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/message.py", line 355, in _translate_error
[15:59] <detritux>     raise errors.LockFailed(*error_args[:2])
[15:59] <detritux> LockFailed: Cannot lock LockDir(lp-70455952:///~ugocupcic/sr-ros-interface/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
[15:59] <detritux> 8.934  Transferred: 1KiB (0.1K/s r:1K w:1K)
[15:59] <detritux> 8.934  return code 3
[15:59] <detritux> 411.969  Traceback (most recent call last):
[15:59] <detritux>   File "_dirstate_helpers_pyx.pyx", line 1852, in bzrlib._dirstate_helpers_pyx._loop_one_block
[15:59] <detritux> StopIteration
[15:59] <iocor> oh my lord
[15:59] <detritux> 417.318  return code 1
[15:59] <detritux> a bit long, sorry :S
[15:59] <detritux> sorry guys, I'll use pastebin next time
[16:00] <mgz> is your launchpad username *not* ugocupcic?
[16:00] <mgz> because you can't push to other people's branches.
[16:01] <GaryvdM> mgz: /whois detritux = "Ugo Cupcic"
[16:01] <GaryvdM> Seems like that is his user :-)
[16:02] <detritux> yeah
[16:02] <mgz> okay, that's me out. anyone else?
[16:06] <GaryvdM> detritux: I just want to make sure about something. Please will you pastebin 'bzr info'.
[16:06] <mgz> on his local branch rather than the lp one?
[16:06] <GaryvdM> Yes
[16:07] <GaryvdM> Ah - maybe bug 412657
[16:07] <ubot5> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/412657)
[16:07] <detritux> http://pastebin.org/385322
[16:07] <GaryvdM> https://bugs.edge.launchpad.net/bzr/+bug/412657
[16:07] <ubot5> Launchpad bug 412657 in Bazaar "update fails when trying to lock master branch (in a readonly checkout) (dup-of: 412223)" [Undecided,New]
[16:07] <ubot5> Launchpad bug 412223 in Bazaar "bzr up locks master branch (affected: 2, heat: 4)" [High,Confirmed]
[16:08] <mgz> that bug doesn't seem to have anything for cause or workaround...
[16:09] <detritux> hm unbind / rebind I can try that
[16:09] <mgz> oh, wait, bind/unbind/redo
[16:09] <detritux> how do you unbind ?
[16:09] <mgz> bzr unbind && bzr bind
[16:10] <detritux> :D
[16:11] <mgz> if that fixes it for you I'd wham an "affects me to" on that bug.
[16:11] <GaryvdM> mgz: Can we chat re installer -OO?
[16:12] <GaryvdM> time ok?
[16:12] <mgz> yup, I'm back and lunched now
[16:12] <GaryvdM> Cool - so I was building with all your patches
[16:13] <mgz> ^or rather, affectsmetoo on the bug that one is duped against I guess
[16:13]  * GaryvdM get branch urls to prove
[16:13] <detritux> yeah I'll do that if it fixes it
[16:13] <mgz> and... stuff still breaks?
[16:13] <GaryvdM> Yes.
[16:14] <mgz> meh, my timestamp checking lines are scrolled out of buffer
[16:14] <mgz> I think I pasted them in here though...
[16:15] <GaryvdM> mgz: The issues was that a plugin that was allready installed on disk from source in a manually set BZR_PLUGIN_PATH got compiled with -OO when bzr.exe ran.
[16:15] <mgz> basically, need see if the mtime of the py file which complains is the same as the stamp in the packaged pyo file
[16:16] <mgz> oh, that's possibly expected
[16:16] <mgz> if it was never actually installed with optimize
[16:16] <GaryvdM> mgz: when I did "set BZR_PLUGIN_PATH=" then it worked...
[16:16] <mgz> one of the things I wanted to find out with that patch is if it's common to use from-source plugins with bundled installers
[16:17] <mgz> which strikes me as dodgy compared to installing into the right plugin dir, but if non-devs actually do it...
[16:18] <GaryvdM> mgz: So the only way that I see -OO viable is if we can get it so that library.zip is compiled as -OO but the .exe is not .
[16:19] <mgz> if people actually do that, I agree (for the moment, a future way is just to mark up plugin cmd objects as well)
[16:19] <GaryvdM> mgz: Your patches to prevent pyo recompile are still valuable though...
[16:19] <mgz> I'll poke around in py2exe
[16:20] <GaryvdM> mgz: How much difference does -OO make compared to -O?
[16:20] <GaryvdM> mgz: I think it would be good to try measure.
[16:20] <mgz> not much, a couple of megs to library.zip and a fractional cold startup improvement
[16:21] <mgz> Alexander did a couple of tests at UDS for me when we were merging it
[16:22] <mgz> https://code.launchpad.net/~gz/bzr/support_OO_flag_installer/+merge/24484
[16:23] <GaryvdM> mgz: the branches that I built with: lp:~garyvdm/bzr-windows-installers/maybe and lp:~garyvdm/bzr/2.2b3+packing
[16:23] <GaryvdM> The latter now has the org -OO patch reverted.
[16:23] <mgz> dod you know if there'll be a 2.2b4 from the current trunk?
[16:25] <GaryvdM> Bla - lp is sloooow at the moment.
[16:25] <GaryvdM> mgz: according to https://edge.launchpad.net/bzr/2.2 - yes
[16:26] <mgz> is that lp's fault or your undersea cable's?
[16:26] <GaryvdM> Oh yeah - I forgot about that.
[16:34] <mgz> okay, reading py2exe source, doesn't seem to be a configurable way of doing it, but could easily chop it in
[16:39] <GaryvdM> mgz: 7.7% faster cold start - Ok - that makes it worth it ...
[16:40] <GaryvdM> mgz: We could also maybe look at which plugins we can do a -OO on, and which not...
[16:40] <mgz> well, it's not a big job to just fix them all
[16:41] <mgz> but messing with py2exe looks amusing
[16:46] <GaryvdM> mgz: Would it work  if we ran byte_compile(optimize=2) for everything going it to library.zip, and then did py2exe with optimize=1 .
[16:47] <GaryvdM> mgz: or does it compile from scratch?
[16:47] <mgz> nope.
[16:47] <mgz> sec, I'll give you a diff to try
[16:52] <mgz> http://paste.ubuntu.com/460272/ < how about that for a horrible hack
[16:54] <GaryvdM> Not to bad.
[16:54] <detritux> GaryvdM: ah I found my real problem in fact. You can't commit on a branch that's being pulled from a svn. That's logical... thanks for your help
[16:56] <GaryvdM> mgz: Suggestion: In build_executable, remember what optimize was, and then restore it.
[16:56] <mgz> I started writing that, then I looked at the diff context and decided it was silly
[16:57] <mgz> really that's a sensible setting we want to keep, so would be best to get a proper version upstream
[16:57] <GaryvdM> mgz: +1 for upstream.
[16:58] <mgz> ...last release was 2008
[17:00] <mgz> I've got theller to look at patches before though so can probably get it in svn at least
[17:01] <GaryvdM> Very useful: http://pastebin.org/385361
[17:03] <mgz> yeah, methods are bound late, get a different object back each time
[17:03]  * GaryvdM goes to find food.
[19:15] <lifeless> vila: hi
[19:16] <lifeless> vila: Is it true, a fix for the locking thing is in 2.1 branch? if so, we should get it into the LP tree
[20:02] <elmo> blah, what's the bzr push trick to push to where I just branched from?
[20:02] <elmo> I thought it was bzr push --parent, but it's not that
[20:04] <james_w> push :parent
[20:04] <elmo> james_w: thanks
[20:30] <lifeless> james_w: hi
[20:30] <james_w> hi lifeless
[20:31] <lifeless> I've pushed up a test
[20:31] <lifeless> I'm going to try and get some more love in place today and tomorrow
[20:31] <lifeless> I can has review? [or is it buried in my email overnight?)
[20:31] <james_w> lifeless: I'm in the middle of looking at it
[20:31] <james_w> it looks broadly fine
[20:32] <lifeless> \o/
[20:32] <lifeless> thanks
[20:32] <lifeless> I realise the test style is a fresh one
[20:32] <lifeless> its not quite -right- but its broadly where I want things to be
[20:32] <lifeless> I think its fairly readable ?
[20:32] <james_w> I don't think you need to use dh-make, but I can understand that working out the needed steps might be a bit much
[20:32] <lifeless> james_w: if you want to give me a recipe to slot into that fixture, great.
[20:33] <james_w> yeah, it's fairly readable
[20:33] <lifeless> I was fighting a bit of an uphill battle at the time ;)
[20:33] <james_w> it's not what I would expect fixtures to be used for really
[20:33] <lifeless> thats interesting
[20:33] <james_w> well, at least say the FileMovedReplacedUpstream part
[20:34] <james_w> I would expect to have something like BranchBuilder, where you call methods, rather than compose fixtures
[20:34] <james_w> I'm happy to see how this develops though
[20:37] <lifeless> great
[20:37] <lifeless> I'll use these as a basis for the next patch too then
[20:37] <lifeless> its why I wanted to get this one seen to rapidly, to avoid a big pile of 'nooo' from you :)
[20:43] <james_w> heh
[20:44] <james_w> I just think that the method calls would make reading the intent of the test easier, but let's find out
[20:44] <lifeless> it would be nice
[20:44] <lifeless> (perhaps)
[20:45] <lifeless> to do @with_fixture(fixture_description_here)
[20:45] <lifeless> thats kindof the philosophic reason for making it all declarable rather than procedural
[20:45] <lifeless> one of the .. reasons
[20:46] <lifeless> another is to be able to switch out implementations very easily, a BranchBuilder is more monolithic, so you would switch out all at once rather than granularly.
=== davidstrauss_ is now known as davidstrauss
[22:46] <davidstrauss> How can I make Loggerhead only bind to localhost?
[22:47] <davidstrauss> nvm
=== oubiwann is now known as oubiwann-away
=== oubiwann-away is now known as oubiwann