[00:00] jam: Shh.. Not that one, the other one! [00:00] :-) [00:01] hi guys [00:01] I'm back on deck [00:01] wb lifeless === mwhudson_ is now known as mwhudson [00:02] So I'm a bit conflicted about all the changes going into the 1.x series. I love how it makes the code better instead of crufty. But at the same time as a packager, I sometimes feel like I shouldn't be pushing a new update to a release. [00:02] is there a way to see what branch format a branch on LP is in without branching it? [00:02] Which is okay for Fedora (just update to the next release, it will be out in < 6 months) [00:02] LaserJock: bzr info URL [00:02] I would generally recommend the http url, otherwise you get something about the RemoteRepository, IIRC [00:03] But it's going to be hard if I do that for RHEL (five years on an old version of bzr with no upstream bug fixes or security fixes). [00:03] darn, still getting "not a branch" [00:03] LaserJock: can you give us more details? [00:04] trying to pull bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ [00:04] abadger1999: well i would argue that we've had lots of upstream bug fixes and security fixes, we just stamp it with a new release ... :) [00:04] but I understand your point [00:04] as of yet, there hasn't been enough impetus to backport anything [00:04] I think we've had only 1 'x.y.1' release, and maybe discussed doing it 2 or 3 times [00:06] jam: Yep! So far I've just rolled out updates with every new bzr release to gain all the new features/performance/bugfixes. [00:06] But every time I see an entry under API BREAKS, I have to re-evaluate whether I can keep doing that or if doing so will break the expectations of the users consuming my package. [00:08] It's just a mismatch between a fast moving product like bzr and pushing it to a distro with a long-term support cycle. [00:09] Not sure what you guys could do about it except maybe emulating gnome by introducing new API (and deprecating the old one) instead of removing API when it is superseded by something better. [00:09] But that's an increased support burden on you so I understand why you wouldn't want to do that. [00:10] abadger1999: we do that for most things [00:10] though "long term" is months in our case, not years [00:10] mwhudson: any thoughts? [00:10] abadger1999: but sometimes we decide to cut our losses, rather than support something broken for a long time [00:10] jam: heh. Yeah :-) [00:10] months vs years is the issue I face :-) [00:11] abadger1999: we've supported the disk formats for years [00:11] yeah but you can't use an old version of bzr for anything [00:11] because everyone *else* is using new formats [00:12] LaserJock: wfm (r3377) [00:12] mwhudson: so it seems that bzr+ssh didn't work but http did [00:12] Which leads to problems on a long-term supported distro... introduce a new version so some users can collaborate with others using the new format or stay with the old version so some other users can continue using their in-house, custom tools. [00:12] LaserJock: oh, hm [00:13] LaserJock: you have done bzr launchpad-login, i take it? [00:13] what do you mean? [00:13] I guess another option would be to allow for multiple versions of bzr/bzrlib to be installed. [00:13] oh, no, I haven't [00:13] why do I need to do that? [00:14] LaserJock: so bzr+ssh knows with user to use [00:14] I told it to use my LP id [00:14] oh, ok [00:14] LaserJock: can you pastebin what happens when something goes wrong? [00:14] Use deprecation until a new disk format appears/you don't want to keep supporting all the cruft. Then release with all that fixed and the module as bzrlib2. [00:15] mwhudson: it's just: [00:15] Using saved location: bzr+ssh://laserjock@bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ [00:15] bzr: ERROR: Not a branch: "bzr+ssh://laserjock@bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/". [00:15] abadger1999: that only really seems doable for a mature project that's not changing rapidly [00:16] That works for libraries, but I don't know that it would work for bzr since it has a client app as well. [00:16] foom: Definitely would be better for mature projects :-) [00:18] But GNOME is a counterpoint. They've managed not to break API compatibility for a long time despite making many changes to the API. But they pay for it by having to drag all the compatible stuff along with the good changes. [00:18] LaserJock: bzr -Dhpss pull and look at ~/.bzr.log ? [00:20] mwhudson: doesn't look all that helpful to me but I can pastebin it for you [00:20] LaserJock: please do [00:21] Oh well, when wearing my Fedora hat I love that bzr is evolving rapidly, when wearing my EPEL maintainer hat, I often feel guilty that I'm pushing a bzr update which may break someone's code somewhere. [00:21] Like I said in the beginning. I'm conflicted about this and don't see an easy answer. [00:21] mwhudson: http://paste.ubuntu.com/7807/ [00:25] LaserJock: can you write to this branch? [00:25] in what way? [00:25] push to it [00:25] supposedly :-) [00:25] are you a member of ~ubuntu-core-doc ? [00:26] yes I am [00:26] LaserJock: I'll take a closer look on the machine... [00:26] I'm just in the middle of trying to fix a boo boo [00:26] which I made need some help figuring it out [00:26] we lost some revisions on the edubuntu-hardy branch [00:27] and I'm not sure the best way of getting them back [00:27] I think as long as I keep the formats straight I should be able to just push [00:27] uh [00:27] there is no .bzr directory at all in the push area for this branch!? [00:28] mwhudson: which branch? [00:28] LaserJock: ~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy [00:29] you mean you can't find one or do I see one? :-) [00:29] mwhudson: yes there is [00:29] ah [00:29] damnit looking at the wrong one [00:30] LaserJock: i'm not asking you a question, don't worry [00:30] mwhudson: ok, phew ;-) [00:30] LaserJock: is there the slightest chance that some one has done the equivalent of "rm -rf .bzr" on this branch? [00:30] mwhudson: mdke said he was updating the branch formats [00:30] oh [00:30] ho ho [00:31] in so doing I lost 9 revisions in my edubuntu-docs branch [00:31] which is what I was originally trying to fix [00:31] but it got me sidetracked when I couldn't bzr pull the ubuntu-hardy branch [00:32] s/edubuntu-docs/edubuntu-hardy/ === Necoro_dM is now known as Necoro [00:37] so, i have to admit, i don't really know what's happened here [00:38] hmm, ok [00:38] if mdke was trying to do format upgrades, that sounds like its probably related [00:38] would be logical [00:38] LaserJock: is the version you see at the http: url at the revision you expect? [00:39] yeah, it pulled in a couple revisions [00:39] it looked fine to me [00:39] looks like 3799 [00:39] i can copy that back into the push area [00:40] i guess i can do the upgrade on the server too while we're at it... [00:42] mwhudson: so you're able to recover the branch? [00:43] LaserJock: yes, if you want me to [00:44] mwhudson: any reason not to? [00:44] I assume we don't want it in the state it's in [00:44] LaserJock: i can't think of one [00:44] as long as we don't loose anything :-) [00:44] LaserJock: do you want it upgraded to rich-root-pack at the same time? [00:45] yeah, that's what we're after [00:45] in progress [00:46] mwhudson: can you see if anything happened to kubuntu-hardy and xubuntu-hardy? [00:46] I know I lost 9 revisions in edubuntu-hardy but I assume I can fix that with a bzr push [00:48] they look ok [00:48] edubuntu-hardy has been upgraded [00:49] which might be where you revisions went [00:49] if mdke did it by downloading the branch, upgrading and uploading it again [00:49] yeah [00:49] I don't know why he wouldn't have the revisions though [00:49] maybe he forgot to bzr pull first [00:51] mwhudson: would it be possible to have one of you guys convert kubuntu-hardy and xubuntu-hardy on the server? [00:51] so we don't end up with issues like this [00:51] LaserJock: yes, sounds sane [00:52] I'm sure mdke would appreciate it [00:52] LaserJock: can you ask a question on launchpad-bazaar ? [00:52] I can [00:53] abadger1999: they have actually broken ABI since 2.0, if you consider ABI in the broader sense of 'the behaviour' rather than just 'it links and structs are the same size' [00:54] abadger1999: but this doesn't invalidate your point about the costs [00:58] mwhudson: question asked and I fixed up edubuntu-hardy === mw is now known as mw|out === kiko is now known as kiko-zzz [01:55] spiv: bug 220806 [01:55] Launchpad bug 220806 in bzr "PyCurlTransport doesn't define the _remote_is_at_least_1_2 property" [Undecided,New] https://launchpad.net/bugs/220806 [02:02] lifeless: ta [02:02] :) [02:05] lifeless, spiv: Initial branch of rocketful over bzr+ssh is excruciatingly slow. [02:05] abentley: hmm. [02:05] abentley: yes [02:05] Our new hire reported it took 4 hours. [02:06] ow [02:06] segwayfuel [02:06] we're running bzr 1.3.1 on devpad [02:06] I'm not sure how long it took for me at first. tens of minutes? [02:06] it should have the newer graph logic [02:07] what bzr did the hire use? [02:07] I dunno, but it looks pretty wrong with bzr.dev. [02:07] did they create a pack or knit local repo? [02:07] there is currently transcoding required, and that can buffer pretty highly [02:08] They just did bzr branch bzr+ssh://devpad.canonical.com/code/rocketfuel/launchpad/devel trunk [02:09] I can confirm that on my box, this does tons of Graph.get_parents_map calls. [02:10] there is a debug flag [02:10] It's doing _walk_to_common_revisions(), which looks wrong. [02:11] it should be exponentially increasing in data retrieval [02:11] with a cap [02:13] Many of these calls were 14k or so. [02:14] if you do -Dhpss [02:14] it reports hit rate and stuff [02:14] I'm reporting the results I got from doing Dhpss [02:15] There were a lot of results with 43474 bytes. [02:16] then a lot with 83598 bytes [02:17] what was the retransmitted revisions count ? [02:18] Always 0 of x [02:19] ok [02:19] how many minutes did the graph traversal take ? [02:20] Dunno. I killed it before it completed. [02:20] how many minutes in was that ? [02:21] and what was the last hit rate you had reached ? [02:22] The time was 488.460 [02:23] The last hit rate was 98% [02:23] what was the rtt around the last request? [02:23] (just the tiem from sending to the hit rate output) [02:24] Looks like 0.009 [02:24] so something doesn't add up here to me [02:25] No, you probably want from 439.611 hpss call w/body: ' to '444.812 Current RemoteRepositor' [02:25] so 5 seconds [02:25] 12 steps a minute [02:27] The length of the last request was 146775 bytes [02:27] thats a pretty big upload [02:28] so there is a tradeoff we can make [02:28] between retransmitted revisions; network latency, and request size [02:29] I thought for initial branches we were still doing the tarball thing. Is that gone? [02:29] yes [02:30] we need to handle such similar cases that can't be special cased like that anyhow [02:30] But it seems like this one could be special-cased to great benefit. [02:31] abentley: there's a new method that will stream all the necessary revision data in a single request -- once it knows what revisions to ask for. [02:31] abentley: the tarball special case nearly broke the supermirror; it was very harsh on server load [02:32] (and without the nasty 'buffer the whole response before sending' that the tarball method had) [02:32] We probably don't need to be so extreme, but I would think _walk_to_common_revisions could be done on the server side. [02:33] abentley: improvements in this area are welcome; I think I've posted lots on the list in the past [02:33] abentley: doing _walk_to_common_revisions on the server side is something that conceptually eludes me [02:33] So I'm wrong in thinking this is a regression? [02:33] I could have sworn it completed in tens of minutes for me. [02:34] its not a 1.4/bzr.dev regression *if* the bulk of the delay is in the graph walk [02:34] lifeless: _walk_to_common revisions is used to determine what we need to send, right? [02:34] abentley: what we need to request from the server yes. And it depends on our local graph [02:35] In this case, we know the local graph is empty. [02:36] abentley: yes [02:37] abentley: though in general we don't want to do size(repo) operations, we do have a [relatively] cheap 'len()' for the revision graph. [02:37] So in this case, we only need server-side data to know what to send. [02:37] Ok, it took just over 1000s for the graph walking for that to complete for me. [02:37] (from my laptop to London) [02:37] yah [02:38] this is clearly improvable [02:38] abentley: I'm ok with us special casing the selection somewhat; I think its important though that 'bzr branch bzr+ssh://launcpad...' into an existing non-empty repo *also* be fast [02:39] Yeah, I agree. [02:39] abentley: the current worker method that is used to fetch is 'RemoteRepository.get_data_stream_for_search' [02:39] The reason I raised it now was because it seemed plausible as a regression. I knew you'd done some work in that area. [02:39] abentley: if I were to special case the empty repository case I would look at constructing a search by hand [02:40] yeah, its very plausible as a regression [02:40] I'm going to see how long it takes me. [02:47] It gets to 99% relatively quickly (only two minutes). [02:48] spiv: It's at 97% for me at 417.137 [02:49] Actually, that's a slightly confusing measurement. [02:49] More interesting is that after about 90s it starts getting lots of results of only 14 bytes, rather than 10s of kB. [02:50] spiv: I bet its running into reached parts of the graph [02:50] spiv: this is where I ran out of time and had to switch tracks [02:51] spiv: history shortcuts will lead to inconsistent round trips being needed to reach a node N [02:52] Is it just me, or should we be implementing a graph traversal on the server side to avoid all these get_parent_map calls? [02:53] abentley: the get_parent_map calls are server side graph traversal [02:53] abentley: remember that we don't have full duplex facilities [02:53] I'm seeing hpss call w/body: 'Repository.get_parent_map' [02:53] Which makes me think we're asking for a whole bunch of parents, then waiting for the result. [02:54] Then asking for more parents. Etc. [02:54] each time we do that we recieve more data than we asked for [02:54] the server anticipates future requests and bundles those into the response [02:55] Cool. [02:55] So that's why you expect it to increase exponentially. [02:55] it performs a breadth first search on the server side [02:55] and trims revisions we've already recieved [02:55] the result is cached in the clients RemoteRepository object [02:56] But it is definitely not increasing exponentially. [02:56] have a read of remote.py's RemoteRepository._get_parent_map [02:56] I think I was misremembering [02:56] I tried a half dozen strategies when doing this [02:56] expoential increases, constnat sizes, etc [02:57] I believe it can be improved significantly while still only exposing 'get_parents_map' to the python client code [03:00] hmm [03:01] exponential backoff would be good [03:02] It started stream_revisions_chunked at 1135s [03:02] I don't know if it needs a new wire flag or not [03:03] so 20 minutes [03:06] I suspect the knit conversion is a performance issue tho [03:06] we're going to be unpacking and repacking the entire history [03:08] That's not a factor for this case, is it? Rocketfuel is in pack-0.92 [03:13] oh, it is too [03:14] I wonder if we annotate it on the server, send it, and then strip on the client [03:18] Well, bazaar seems to be doing *something* fairly CPU-intensive. [03:19] But bazaar doesn't CTRL-\ during network ops... [03:19] 20098 abentley 15 0 1314m 1.2g 3020 S 0 32.7 12:17.25 python [03:20] This is how long it took you to branch rocketfuel? [03:20] Oh, ps output. [03:20] spiv: ^ sure we don't buffer anymore? [03:21] lifeless: yes [03:21] abentley: 'top' actually [03:21] lifeless: jam recently reported that to me too [03:21] lifeless: I haven't had time to dig into it yet, but it doesn't seem to be a regression [03:23] eh? Your 'top' output has my login name? [03:23] On devpad [03:23] Oh. [03:23] abentley: :P [03:24] lifeless: So on my side, 'top' says: [03:24] 15492 abentley 20 0 475m 346m 2816 R 79.6 34.3 11:20.95 python [03:27] * spiv -> lunch [03:39] * mneptok takes this opportunity to pimp htop [03:40] Mmm, sweet htop! [03:41] i've updated my Unix toolset from top to tail. [03:42] (namely, to htop and inotail) ;) [03:47] inotail? Hm, haven't seen that one :) [03:48] really its a bug [03:48] should be able to select() on a disk file fd [03:54] branch complete: 73m, 4.4 seconds. [03:58] rockstar_: It took me 1h, 13 minutes to branch rocketfuel. Does that jibe with your experience? [03:59] I think it was closer to two hours [04:18] I was reading themail on bzr for gedit [04:18] option C - subprocess. This might solve a lot of problems -- to strongly disassociate the ui from bzrlib [04:19] you coould even haev the tui start up a bzrlib process and send it commands. [04:19] you'd have to be careful of context/environment though [04:20] as well as interop with gedit/win32 exlporer/nautilus etc it might help the perceived speed of bzr if the client is very small [04:20] it's a big task though [04:21] see http://www.martiansoftware.com/nailgun/ for a similar idea for java - in this case the client is in C [04:43] bb i a few minutes [06:16] ok, I have the new stream stuff functional [06:16] now to eliminate join, and then optimise the stream copy [06:17] I'm pushing up the current branch, because I'm fading now, still not entirely well I don't think [06:19] lifeless: best wishes for a speedy recovery [06:24] AfC: thanks [06:25] If I have two totally separare bzr trees with no common ancestors is it possible to merge one into the other. [06:25] basically I have some scripts I was keeping in a different bzr branch that I want to add to the main app [06:25] Yes, "bzr merge -r0..-1 ../unrelated" [06:26] spiv: cool that worked. Thanks [06:38] all pushed anyhow - the 'versioned_files' branch [07:48] mwhudson_: yes, I've been doing rm -rf .bzr on it overnight - on purpose [07:49] mwhudson_: I'm just pushing the upgraded branch up now (for ubuntu-hardy) [08:16] mdke: how did the upgrade go? [08:23] jamesh: seems to have gone fine, although i've discovered now that mwhudson_ has the magic ability to do it on the serverside [08:23] https://answers.edge.launchpad.net/launchpad-bazaar/+question/30469 [08:24] mdke: the delete-then-upgrade strategy can take a while for knit branches with a large number of files [08:25] since you get "2*n_files + constant" round trips [08:25] jamesh: yeah, I left the delete on overnight [08:25] sftp lets you do things more efficiently (by pipelining commands), but I don't think lftp takes advantage of that [08:27] jamesh: one thing is that it does seem to break the LP branch - when I deleted it overnight, one of the users got a bit surprised and came in here to ask about how it could be restored; so I found it restored and upgraded when i woke up :) [08:27] mdke: were they accessing it via http or bzr+ssh? [08:27] and did they have write access to the branch? [08:27] without realising that that had been done, I redeleted it and pushed it again [08:28] jamesh: probably bzr+ssh and yes [08:28] mdke: then that access would have gone through to the writable area where you were deleting stuff [08:28] ah [08:29] oh well, I had posted to the mailing list to warn people [08:30] couldn't have done much more [08:33] pack formats comprise many fewer files, so the delete takes a lot less time [08:33] although people are usually upgrading to pack formats than from them [08:36] * mdke nods [09:55] * igc dinner [10:11] Hmm, bzr:// isn't always fastest is it? [10:12] * TFKyle expects file:// would be faster personally :) [10:12] It is, especially into a --no-trees repo [10:13] bzr:// transferred about 5 MB of data then the bzr process on the server starts really chewing CPU [10:13] Mind, this is a rather large tree [10:41] New bug: #220936 in bzr "bzr report internal error when I try to access repository under other locale then repository was created" [Undecided,New] https://launchpad.net/bugs/220936 [11:01] Hi [11:02] I'm wondering if anyone here can help me out with bug 219832. [11:02] Launchpad bug 219832 in bzr "KnitCorrupt: corrupt: incorrect number of lines while branching from svn" [Undecided,New] https://launchpad.net/bugs/219832 [11:51] i got a problem with bzr and paramiko installed in my home directory on a server without root access for me [11:51] installed paramiko using "python setup.py install --home ~" [11:51] did the same for bzr [11:51] when I want to branch from sftp url, I get [11:51] user@server:~$ bzr branch sftp://server/path/to/branch [11:51] bzr: ERROR: Unsupported protocol for url "sftp://server/path/to/branch": Unable to import paramiko (required for sftp support): cannot import name util [11:51] anybody knows what the problem could be? [11:52] silwol: you might need to add where that installed paramiko to PYTHONPATH [11:52] silwol: Do you need to set PYTHONPATH maybe? [11:53] PYTHONPATH is set to ~/lib/python [11:53] without it, bzr does not even run at all [11:54] silwol: and is paramiko there too? [11:54] esd07016@hssesrv01:~$ ls $PYTHONPATH [11:54] bzrlib paramiko [11:54] ok [11:57] do i need pycrypto installed? [11:58] I reckon you do. [11:58] heh, yeah [11:58] hmmm, too bad... there is no gcc :-( [11:59] silwol: out of curiosity, what version of python? [11:59] .24 [11:59] 2.4 [11:59] a current rhel server [12:00] 'k, so that wouldn't work even if it didn't need DES (which it probably does) [12:00] might be able to steal someone elses binaries and hope they work :D [12:02] well, i'll create some on my local pc [12:02] hope there are no symbol problems [12:02] silwol: hmm, you might be able to extract the rpm for rhel (I'd assume it'd have a pycrypto package, I could be wrong though) and throw the files in ~/lib/python === kiko-zzz is now known as kiko [12:03] TFKyle: the admin told me there is none, otherwise he would already have it installed [12:03] ah [12:04] guess gcc is too big for the admin to want to put on? [12:05] i think it's a security issue... will ask him again [12:05] thanks for your help anyway... if i run into problems again, i'll come back [12:08] * TFKyle should probably look into doing pure-py equivs of most stuff in pycrypto, too bad everyone having 2.5 can't be relied on (makes it easier for the hashing stuff, can just call hashlib.sha256/etc. for some stuff instead of having to implement it in pure-py) === mrevell is now known as mrevell-luncheon === mrevell-luncheon is now known as mrevell [13:19] okay, it worked by copying pycrypto compiled on my laptop [13:19] thanks people [13:42] This is bugging me ; I'm trying to test some mods to gconflicts ; but I'm finding it hard to make a simple tree with text conflicts in it [13:45] http://pastebin.ca/994453 [13:45] Can someone explain what I'm seeing in the link? I think it's incorrect behaviour personally, but perhaps there's a good reason. [13:46] What I would expect is a text conflict, not a content conflict [13:46] so would I [13:46] does "bzr conflicts --text" list it? [13:48] Nope [13:49] The logs correctly note each relevant revision as a modification to stuff.txt [13:49] it seems that the file ids get mixed up then, but you're typescript suggests that they shouldn't [13:49] The logs never note a deletion of stuff.txt, so how can a merge produce one? [13:50] Let me try this in a non rich-root repo [13:50] Ok, trying with standalone pack.092 branches [13:51] Does it in plain pack.92 branches too [13:52] I get a text conflict using the same steps [13:52] I can't reproduce either [13:52] awilkins: are you on up-to-date bzr.dev? [13:52] File-ids are identical [13:52] james_w: No, this is 1.31 [13:53] Erm, I thought it was, it's 1.30 [13:55] awilkins: I can't reproduce with 1.3.1 either [13:55] WHen I finish installing 1.3.1 I'll try it again [13:57] thanks [13:59] Same again, contents conflict [13:59] Hmm, let me try with no plugins [14:02] Still the same with no plugins [14:03] Is this a windows-specific thing? [14:05] could be [14:06] I'm presently working on the theory this may be a unicode BOM thing (?!?!?!?) [14:06] I'll try again with ANSI files [14:11] New bug: #195217 in bzr-lpreview "ReadOnly error when running bzr review-submit with no arguments" [Undecided,New] https://launchpad.net/bugs/195217 [14:11] Bingo ; it's because the magic function in bzr is detecting the files as binary [14:11] awilkins: Yes, it could be a unicode BOM thing. binary detection is based on finding non-ascii bytes. [14:11] Specifically 0 [14:11] i.e. the NUL bytes. [14:12] So technically ASCII, but never used in text documents. [14:12] awilkins: Your files aren't utf-16 are they? [14:12] abentley: Yes, they are [14:13] Oh, they are binary, then. Thanks for playing. [14:13] abentley: 'tis what you get by default as output from Powershell [14:13] abentley: You do the same test using cmd.exe as a shell and it works fine [14:18] Grr, the output encoding on PSH being utf-16 by default is bloody annoying [14:18] awilkins: bzr does tend to assume that files are in a bytes-based encoding. Even if I could fix it for utf-16 files, merge would act funny because it wouldn't detect newlines correctly. [14:18] abentley: I agree that utf-16 is something of a marginal format, especially in the west [14:20] I suppose if we detected a BOM, we might be able to skip the rest of the test. [14:20] Want a bug submitted so people can spit on it? [14:20] But that doesn't solve the problem that '\n' doesn't mean newline in utf-16 [14:21] Sure [14:21] No, it's \n\0 with an even offset, yes? [14:22] Well, it depends on whether the UTF-16 is LE or BE. [14:23] Would a BOM convey that, perchance [14:24] Indeed it would. [14:24] Python seems to be pretty encoding-savvy from what I've seen of the docs - first langauge I've seen which knows which encoding your source file is [14:26] It's definitely much better than older languages like C, but Python 3.0 will really get it right. [14:52]