libwilliam | Is there a command that will show when a branch was first initialized? | 02:19 |
---|---|---|
jml | lifeless: also, I looked at testresources sorting last night... dijkstra's isn't at all what we want, I think. | 02:19 |
jml | libwilliam: interesting question | 02:20 |
lifeless | jml: simulated annealing perhaps? | 02:20 |
jml | lifeless: well, I think we really want TSP | 02:20 |
* jml looks up that other thing | 02:21 | |
lifeless | TSP, expand pls | 02:21 |
jml | lifeless: Travelling Salesman Problem. | 02:21 |
lifeless | oh right | 02:21 |
jml | of course, we don't have to solve it for the tests, just the set of resource combinations. | 02:21 |
lifeless | simulated annealing is one of a class of polynomial approximations for NPC | 02:22 |
jml | libwilliam: 'bzr log -r 1' is close, but it's not the same thing. | 02:22 |
lifeless | we don't attach a datestamp to 'init' | 02:23 |
jml | lifeless: well, I think there's a lot of room for flexibility in the algorithm | 02:24 |
jml | lifeless: since the numbers are small and the same solution will often apply across multiple test runs. | 02:24 |
lifeless | sure | 02:24 |
libwilliam | jml: it is the closest possible thing I think. The only reason I was wanting the branch init date was when using a calendar I want the user to be able to select the range of when to show the status... and since status allows a revision range of revision=.. I don't know where to limit the user if they didnt commit revno 1 until the a different day. | 02:25 |
libwilliam | I'll figure out a workaround. | 02:26 |
jml | lifeless: but a probabilistic solution to the TSP is probably a good default. | 02:26 |
jml | spiv suggested a modified Dijkstra's where the end node only 'appears' on the graph when all the others have been traversed | 02:27 |
jml | but neither of us have bother to look at the algorithmic complexity of that. | 02:28 |
lifeless | jml: uhm | 03:18 |
lifeless | just have a start node with no resources, and an end node with cost infinity | 03:19 |
jml | lifeless: I don't think that would work. | 03:19 |
jml | because the path would still be (start_node, end_node) | 03:20 |
lifeless | right, but the cost of that transition is oo | 03:20 |
jml | unless they weren't connected, in which case, (start_node, cheapest_test, end_node) | 03:20 |
jml | lifeless: yeah, but the cost of any other path from start to end will also be ∞ | 03:22 |
lifeless | right | 03:22 |
jml | lifeless: ok in that case I don't know what your point is. | 03:22 |
lifeless | surely that gives us what we want | 03:24 |
jml | Well, experiment is the ultimate arbiter here, but I don't think so. | 03:26 |
jml | Dijkstra's gives us the cheapest path from A to B, without necessarily traversing any nodes in between. | 03:26 |
lifeless | thats right | 03:26 |
lifeless | if A is no resources | 03:26 |
lifeless | and B is infinitely many resources (a sentinel) | 03:26 |
lifeless | then any resource-set might have a cheaper path from current pos to B | 03:27 |
lifeless | so all resource sets get inspected | 03:27 |
lifeless | the by product of the search was what was interested when I looked at this last | 03:28 |
lifeless | anyhow, I'm interested in overall improvements, not the exact algorithm used | 03:28 |
* jml too | 03:28 | |
jml | but I also want to re-enable the disabled test. | 03:29 |
lifeless | ok | 03:30 |
jml | lifeless: do you have a pre-written 'bigger than everything' object lying around? | 03:30 |
lifeless | so my concept was | 03:30 |
lifeless | [no] | 03:30 |
jml | [[maybe it was one of the twisted guys]] | 03:30 |
lifeless | oh yes I do | 03:31 |
lifeless | its in bzrlib | 03:31 |
jml | lifeless: :) | 03:31 |
jml | yay memory | 03:31 |
lifeless | so my idea was that even though djikstra snaps to the shortest path after inspecting everythin | 03:33 |
lifeless | h | 03:33 |
lifeless | g | 03:33 |
lifeless | you know it has inspected it, and there is a by product in the implementation, I don't recall quite what it was | 03:34 |
lifeless | alternatively | 03:34 |
lifeless | if the cost to the final sentinel is not constant, but less by the current cost of the path, it won't snap and you'd get a full traversal, which was cheapest at each individual step | 03:35 |
lifeless | which suffers local-minima problem, but thats frankly not a huge deal in this case, I think | 03:35 |
* jml neither | 03:35 | |
jml | either way, the trick is to force it to actually do a full traversal. | 03:37 |
jml | also, you want to take the final teardown costs into account. | 03:37 |
=== komputes|eee is now known as komputes | ||
=== mzungu_ is now known as mzungu | ||
paolettopn | Hi guys.... | 10:39 |
paolettopn | there is anyone that can help me? | 10:39 |
mwhudson | doh | 10:43 |
=== bac` is now known as bac | ||
lifeless | mwhudson: "no" | 10:52 |
=== gnomefreak is now known as thunderstruck | ||
=== thunderstruck is now known as gnomefreak | ||
fm | is there a way to checkout a bzr repo from launchpad without having bzr. My bzr does not work as I am using python 2.6, but how do i get https://code.launchpad.net/~vila/bzr/py26bzr ?? | 11:35 |
vila | fm: https://code.launchpad.net/~vila/bzr/py26bzr is useless for now with python-2.6, you need to find a python-2.5 | 11:36 |
kiorky | jelmer: ping | 11:37 |
fm | i am afraid suse will not downgrade python for bzr. most other packages are working beta1 is due next week vila... | 11:37 |
kiorky | jelmer: seems that i cant branch over a svnrepo which is on the same filesystem | 11:37 |
vila | fm: I'm afraid bzr will not support python-2.6 next week :) | 11:38 |
kiorky | jelmer: http://rafb.net/p/El3FTn47.html | 11:38 |
vila | It's quite custom for distributions to support multiple versions of python though, I'd very surprised that bzr is the only package not yet ready for python-2.6 | 11:39 |
fm | as 11.1 will be the base for the enterprise products, this will probably mean no bzr on them too. | 11:39 |
fm | you may look at https://bugzilla.novell.com/show_bug.cgi?id=425644 | 11:40 |
ubottu | bugzilla.novell.com bug 425644 in Development "bzr init fails: failed to load bzrlib.repofmt.pack_repo.RepositoryFormatKnitPack1: cannot import name U32" [Normal,New] | 11:40 |
fm | i will ask | 11:40 |
vila | I've seen that report before updating bug #269535 | 11:41 |
ubottu | Launchpad bug 269535 in bzr "bzr does not work with python2.6" [Medium,In progress] https://launchpad.net/bugs/269535 | 11:41 |
fm | ok ;) | 11:42 |
vila | Next step will be to analyze how many root causes for the failures=33, errors=35, some may be less important than others | 11:42 |
vila | but the __init__ behavior change is not trivial | 11:43 |
Odd_Bloke | On a slightly related note, does PQM check if we've had any regressions on 2.4 _and_ 2.5, or does it just use one or the other? | 11:44 |
fm | sadly I do not now python vila. I just wanted to try bzr for an assignment I am currenty working on. as it sounded really cool ... But certainly I am willing to test everything ;) | 11:46 |
spiv | Odd_Bloke: IIRC, it just checks with 2.4 atm. | 11:47 |
vila | I don't use opensuse myself so I can't say how to install a python-2.5, but I'd be very surprised if no way exists to do that | 11:47 |
vila | spiv: are you really there or just passing around ? | 11:48 |
spiv | vila: I'm sort here. | 11:48 |
spiv | s/sort/sort of/ | 11:48 |
vila | anyway, I'd really appreciate your advice about bug #269535 regarding __init__ behavior | 11:49 |
ubottu | Launchpad bug 269535 in bzr "bzr does not work with python2.6" [Medium,In progress] https://launchpad.net/bugs/269535 | 11:49 |
vila | I'm not 100% sure of my diagnosis, but the code path failing is related to RemoteTranport inheriting from Transport and SmartMedium | 11:49 |
vila | s/Transport/ConnectedTransport/ | 11:50 |
mwhudson | oh what | 11:51 |
fm | vila: what is the timeframe to expect python 2.6 support, certainly the next ubuntu version will ship it ... or not? | 11:51 |
spiv | vila: FWIW, I don't see any mention of the __init__ change in http://docs.python.org/dev/whatsnew/2.6.html | 11:52 |
vila | spiv: I can't find back the reference but roughly __init__ now complains when receiving arguments | 11:53 |
spiv | vila: in general, using super() when you don't know that all the bases will have a compatible signature is a bad idea I think | 11:54 |
vila | spiv: I think so too, try bzr gannotate bzrlib/transport/__init__.py on Transport.__init__ :D | 11:54 |
vila | object.__init__ doesn't seem to line base=base starting with python-2.6, that's the problem | 11:55 |
vila | bzr: ERROR: exceptions.TypeError: object.__init__() takes no parameters | 11:56 |
fm | vila: spiv http://bugs.python.org/file2323/new_init_strict.patch thats the patch i guess | 11:58 |
vila | fm: Thanks, that's the reference I was searching ! I read that yesterday but I can't find anymore how I went there.... | 11:59 |
spiv | fm: yeah, I thought it probably was intentional. | 11:59 |
=== Spaz is now known as Kittens | ||
lifeless | yay | 12:04 |
spiv | It's not clear from the discussion at http://bugs.python.org/issue1683368 if they thought it would cause people's code to break. | 12:05 |
lifeless | clearly, super() is broken by design and this just proves it :) | 12:05 |
jml | spiv: without looking at the bug, I'm pretty sure that it wasn't a priority for them. | 12:08 |
mwhudson | spiv: given that it broke the standard library in three places... | 12:10 |
vila | It seems to me that the intent was to apply the patch to 3k but it leaked into 2.6... | 12:12 |
* LarstiQ reads it that way as well | 12:12 | |
vila | hi LarstiQ ! Thanks for the support :D | 12:12 |
LarstiQ | vila: np :) | 12:12 |
vila | Anyway, we'd better fix bzr | 12:13 |
spiv | vila: probably the best fix is to remove the multiple inheritance from RemoteTransport entirely... I'm not sure that it really needs to inherit from SmartClientMedium. | 12:22 |
vila | spiv: That was my intuition and the reason I wanted to ask you :) | 12:24 |
kiorky | uhm | 12:25 |
kiorky | with bundlebuggy | 12:25 |
kiorky | is there a page with all patches for all projects ? | 12:25 |
spiv | vila: the smart client medium is really the underlying connection, so it really ought to be using the ConnectedTransport stuff for managing that, rather than mucking about with multiple inheritance I think. | 12:27 |
vila | so ConnectedTransport as a SmartMedium attribute ? | 12:28 |
spiv | Huh? | 12:29 |
spiv | I mean, ConnectedTransport already has code to manage _shared_connection and the like. | 12:29 |
spiv | For RemoteTransport, that _shared_connection should be the smart medium. | 12:29 |
spiv | For HttpTransportBase, a smart client medium may as well be constructed on the fly as they are needed. | 12:30 |
vila | Some typos are worse than othres s/as/has/ :) | 12:31 |
spiv | Ah, ok. | 12:32 |
jml | vila: typo? I bet you wouldn't even pronounce the 'h' :P | 12:32 |
vila | Damn, uncovered, now everybody knows I use speech recognition while chatting | 12:33 |
jml | :) | 12:33 |
* jml is very tired. | 12:33 | |
johan | is it possible to edit commit messages? | 13:26 |
johan | after the commit is done of course | 13:27 |
lifeless | no | 13:27 |
lifeless | you can create a new commit object with a different message | 13:28 |
johan | too bad, I remember that svn allowed me to do that | 13:28 |
spiv | If it's just the most recent commit, then "bzr uncommit && bzr commit" works well. | 13:30 |
johan | right, but it isn't the last | 13:31 |
* spiv nods | 13:31 | |
=== BasicPRO is now known as BasicOSX | ||
justizin | agh i know i have asked about this before, but forget the name of the feature, i keep hearing there is a comparative feature to svn:externals in dev, or maybe in 1.6, but can't find it in docs or anything. any word? | 18:36 |
justizin | i don't care about compat with svn:externals in bzr-svn, am moving our deployment from svn to bzr and, though i was able to pull the externals with a bash one-liner, it was not as much fun to write as drinking beer :) | 18:37 |
vila | bzr/python-2.6 down to 10 failures, 1 error :D | 19:20 |
vila | See you tomorrow all. | 19:20 |
fm | vila: thanks for working on it! | 19:44 |
gutworth | does bazar support a bisect-like command? | 20:05 |
Odd_Bloke | gutworth: There is a bisect plugin. | 20:11 |
gutworth | I should have known :0 | 20:11 |
unangz | hallo masters | 20:48 |
unangz | how to checkout from windows repository to linux??? | 20:48 |
unangz | can all of you help me??? | 20:49 |
gutworth | have you tried? | 20:50 |
unangz | yes i have | 20:50 |
unangz | i use ftp protocol | 20:50 |
unangz | but i get problem when i commit | 20:50 |
gutworth | oh? | 20:50 |
unangz | because bzr not support for smb protocol | 20:51 |
gutworth | ftp is not a very good protocol anyway | 20:53 |
unangz | what can i do to solve my problem? | 20:53 |
gutworth | can you use ssh or http? | 20:54 |
gutworth | sftp? | 20:54 |
unangz | if i checkout use http, it's clearly can not for commit back | 20:54 |
unangz | http not support for make directories or files | 20:55 |
unangz | how to installing ssh server on windows | 20:55 |
gutworth | bzr serve | 20:56 |
unangz | u have any tools or applocations ssh servers for windows? | 20:56 |
nekohayo | uh oh | 21:17 |
nekohayo | what happens if someone merges a branches, and makes changes before committing the merge? | 21:18 |
nekohayo | seems one of my devs did just that, and it scares me | 21:18 |
gutworth | the changes are just crammed in with the merge | 21:18 |
nekohayo | gutworth: will bazaar know how to differentiate the two? | 21:19 |
nekohayo | or will it basically screw up interactions with other branches afterwards? | 21:19 |
gutworth | what do you mean? | 21:19 |
gutworth | all that will happen is that you won't be able to separate the commits | 21:20 |
gutworth | nothing horrible | 21:20 |
nekohayo | oh ok | 21:23 |
nekohayo | gutworth: I guess bazaar is smarter than I expect it :) | 21:23 |
AmanicA | does anybod know how to convert chroot--1211347476:///bazaartest/trunk/ to file:///bzrroot/bazaartest/trunk/ ? | 21:52 |
AmanicA | so far I've been able to derive the transport from the url, but that only gives file:///bzrroot/ | 21:53 |
lifeless | AmanicA: to do an unlock? | 21:56 |
=== mario_ is now known as pygi | ||
AmanicA | to get the local file while in hook, to pass to other script | 21:57 |
lifeless | AmanicA: external to bzr? | 21:58 |
AmanicA | I mean to convert the branch.base given to hook, into a branch url which I can pass back to bzr log | 21:58 |
lifeless | you can pass chroot--1211347476:///bazaartest/trunk/ straight to bzr log in the same process | 21:58 |
AmanicA | mm the hook fires a php script which then trigers `bzr log -r ...` to obtain other info | 21:59 |
lifeless | right, so external to bzr ;) | 22:00 |
AmanicA | then bzr log complains: errors.UnsupportedProtocol | 22:00 |
lifeless | transport.local_abspath('.') may work | 22:00 |
lifeless | the chroot-* syntax is a special in-process syntax only | 22:00 |
AmanicA | I think I tried that | 22:00 |
AmanicA | I can try again quickly | 22:01 |
AmanicA | SmartMessageHandlerError: The message handler raised an exception: chroot--1211093524:///bazaartest/trunk is not a local path. | 22:02 |
AmanicA | ok so I obtain the transport with : `tr = transport.get_transport(result.branch.base)` | 22:03 |
AmanicA | which seems correct: `tr: <bzrlib.transport.chroot.ChrootTransport url=chroot--1211093524:///bazaartest/trunk/>` | 22:03 |
AmanicA | then `tr.external_url()` gives `file:///var/lib/gforge/bzrroot/` which is the closest to what I want | 22:04 |
AmanicA | except its only the url to the base of the transport, I need file:///bzrroot/bazaartest/trunk/ | 22:05 |
AmanicA | I mean file:///var/lib/gforge/bzrroot/bazaartest/trunk/ | 22:06 |
lifeless | uhm | 22:08 |
lifeless | I didn't say external_url :) | 22:08 |
lifeless | I said local_abspath | 22:08 |
lifeless | oh right, and you get an error on that | 22:08 |
AmanicA | I tried that and it gave ` SmartMessageHandlerError: The message handler raised an exception: chroot--1211093524:///bazaartest/trunk is not a local path.` | 22:08 |
lifeless | I think you should file a bug; it is reasonable to want to run an external script on a branch being pushed to by the smart server | 22:09 |
AmanicA | where do you think the problem/solution would be? | 22:09 |
lifeless | we need to look at the security implications | 22:10 |
AmanicA | oh you mean that method should be implemented?! | 22:10 |
AmanicA | oh, so no easy fix :( | 22:10 |
lifeless | and then likely both fix local_abspath to support the chroot transport type | 22:10 |
lifeless | and possibly provide a public method to get the backing location | 22:11 |
AmanicA | ok I will quickly log a bug mentioning youe sugestions. | 22:12 |
AmanicA | in the meanwhile I might manually translate the url to get my stuff working. I can look into fixing the bug a little later if someone which better knowledge about these things doesn't beat me to it | 22:13 |
=== mario__ is now known as pygi | ||
lifeless | ok, thanks | 22:13 |
AmanicA | thank YOU! | 22:14 |
AmanicA | thanks lifeless, my monkey patch is 2 lines, and works beautifully. I've been trying to figure this out since saturday :( . | 23:24 |
AmanicA | what are we not willing to do in the quest to do things right the fist time.. | 23:25 |
lifeless | :> | 23:36 |
poolie | spiv, lifeless, call in 2m | 23:58 |
* jml kills the music | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!