[00:06] lifeless: did you see my whining earlier about the bzrtools edgy+ packaging being broken? [00:07] dato: (and thanks for the suggestion of sid, I can fix it easily enough myself, I just want the bazaar-vcs.org repos to be installable :) [00:07] lifeless: and/or is launchpad bugs an appropriate place for that kind of problem? === mw is now known as mw|out === Winterstream is now known as WinterstreamAway [01:16] spiv, does this error about "remote server did not return a token" mean anything to you? [01:17] Sounds like a locking issue? Where did this occur? [01:18] new mail to the list [01:18] if it's not familiar off hand i'll check launchpad and file a bug [01:19] Not familiar off-hand, no. [01:20] I'd be interested in the -Dhpss log for that. [01:26] New bug: #176020 in bzr ""remote server did not return a token" assertion error" [Undecided,New] https://launchpad.net/bugs/176020 [02:28] poolie: re "Branch 6 options" in the User Guide, the intro text looks wrong [02:29] I assume these options all apply to new formats and perhaps to dirstate as well, not just dirstate-tags [02:30] how should I word that and can anyone suggest a better heading? I don't think "Banch 6" will mean much to most users [02:35] igc: the branch 6 options do not apply to dirstate. Branch 6 introduced tags. [02:37] abentley: but doesn't dirstate support the 5 settings listed: [02:37] append_revisions_only [02:37] parent_location [02:37] bound_location [02:37] bound [02:37] No. [02:37] push_location? [02:37] wow [02:37] Those were not part of the config file for branch format 5. [02:38] They were in separate files. [02:38] ah [02:38] And there was no strict equivalent for "bound" or "append_revisions_only". [02:39] abentley: so should I just say "dirstate-tags or later" formats? [02:40] Sure. [02:40] thanks [02:43] Actually, I guess push location was in use for format 5, but it was typically stored in locations.conf instead of branch.conf [03:55] * igc lunch [04:54] spiv: poolie_: that token bug - bet you its a knit local branch, pack remote branch, or some such. [04:59] lifeless: hmm, interesting thought. [05:04] note - I haven't read the bt or anything [05:04] just a guess [05:05] * spiv nods [06:11] hello guys, anyone awake? [06:20] I am, but I'm not very useful. [06:20] what's the proper way to go about deleting a branch from a repository? [06:24] pattern: rm -rf the branch [06:25] nice [06:25] thanks, lifeless [06:27] pattern: The revisions unique to that branch won't be removed, but it shouldn't be wasting enough space to be worried about. [06:27] Peng: me neither, just wanted to get some "best practices" recommendations of using bzr... being very annoyed by all the git mambo... [06:28] reading the user guide patch [06:28] luislavena: Git mambo? [06:29] Peng: yeah, all the "fuzz" around the -powerful- git, but couldn't get the picture of the unique checkout/mirror and their use of branch/feature and switch... [06:29] still don't get it, and reading the user guide have a question :P [06:32] I didn't understand any of the terms in that sentence, but I'm kind of overloaded right now. [06:32] Peng: no problem, I'm kind of tired too... [06:32] I'm not tired, I'm overloaded. [06:33] Argh, I'm about to explode. [06:33] what the hell, I'll re-read the user guide for nth time and try to compare some of the functionality... [06:33] Peng: oh, sorry :| [06:34] luislavena: If you have a question, just ask it :) [06:35] * fullermd wraps some duct tape around Peng for safety. [06:35] will be a best practice use a checkout to mirror a dev trunk? [06:35] I mean, I don't plan to work directly on it, but create my branch of it (feature-NN) [06:36] * luislavena think bzr have so many options that is overwhelming [06:36] Yes, a checkout would work. So would a branch that you just never commit in; the major difference would be whether you "update" or "pull" to keep it caught up. [06:36] (at least, the checkout _should_ work. There've been occasional hiccups in the past where checkout wanted to be able to write to the upstream for locking) [06:37] fullermd: ok, then a branch on a treeless repo will do the trick. [06:38] * fullermd nods. [06:38] FWIW, I don't use checkouts. I don't see the point, and since they aren't bzr's main functionality, I don't expect them to work as well. [06:38] (I do occasionally use a lightweight checkout to save downloading the history, though.) [06:39] I see, thank you Peng [06:40] I'll try to get used to the workflow, being a svn guy for quite long :P [06:40] I use checkouts with some regularity, especially for work (as opposed to personal) projects. For all the uber-distributed disdain for it, the shared-branch workflow does very well if it fits what you're doing. [06:40] fullermd: that's the problem, found something that 'fit' whatever I'm trying to do. [06:40] couldn't get a clear picture of the workflow that will fit better with my development. [06:41] Yeah, it can be tricky. Once you digest it, though, the choice is great, since there's so many different problems that need different solutions. [06:41] And even the same problem at different times. bzr's been great for me at allowing that adaptability. === poolie_ is now known as poolie [06:42] Peng: thank you. [06:43] fullermd: thank you too for your comments [06:44] luislavena: Any time :) [06:47] a last (for now) question: [06:47] lets say I have one share repo and my "dev" branch on it, all locally. [06:48] I can push it remotely, but I need it to be inside another shared repo? or can stand by itself? [06:49] luislavena: it can stand by itself. [06:49] luislavena: if you have a shared repo on the remote side, pushing a new branch to that repo will automatically use that shared repo, but if there isn't it'll just make a standalone branhc. [06:49] It's a good idea to use a shared repo, though. [06:49] If you use 'push' to send it around, it will go into another repo, or by itself, whichever fits at the other end. [06:50] You can't, e.g., just tar it up and move it around though, unless it's standalone (or you tar and move the whole repo) [06:51] I didn't tried the remote stuff, being using bazaar quite some time (but not full due work) but didn't make pushing yet :-$ [06:52] luislavena: basically, push will work either way. Just like locally, bzr can copy less data if there's a shared repo that already has some of the revisions you're pushing, though. [06:53] thank you guys again, I'll try to find what fits best my workflow (trunk, production and staging with local features that will be merged on these 'stages') [06:53] spiv: if there is already data, push should only require to add the missing data, not remove and start all over, right? :| [06:56] luislavena: right. [06:57] luislavena: But if you aren't using a shared repo, it will send all of the data again. [06:57] Peng: well, if you push a new branch it will [06:57] Peng: If you're just pushing new revisions to a branch you've already pushed, it won't. [06:58] Oh, right. === doko_ is now known as doko [07:06] what if I "diverge" the branch and try to push it to the original branch location? [07:06] nevermind, will try wtih some dummy data :D [07:36] hey guys, think I made a mistake... I canceled a push... and now I am getting this... [07:36] No handlers could be found for logger "bzr" [07:36] when ever I try to push. How can I fix this issue? [07:46] just found the work around... it is a bug in both launchpad and bzr [07:57] poolie: can I merge the bug tracking doc changes? jml said they were ok with him [08:03] I just created a branch called 'hope', where I was hoping that a massive merge bringing in some changes from a different upstream project would work. [08:03] It didn't [08:03] rm -r hope/ [08:04] Clearly, I have no hope. [08:23] * igc dinner [09:09] at 16:30 we have a half hour tutorial on bzr in #kubuntu-devel for https://wiki.kubuntu.org/KubuntuTutorialsDay, if there's a knowledgeable bzr person who could hang around and answer the questions I don't know that would be good [09:10] Riddell: That's UTC? [09:11] spiv: yes [09:11] possibly not ideal for .au [09:12] or that side of the world [09:13] Yeah. There's likely to someone around at that time, though. [09:23] i'll be around if you can't get somone more qualified [09:23] jelmer or vila maybe? [09:26] Good morning Bazaaros! [09:43] Riddell,mwhudson: I just joined there as well [09:43] hi Matt [09:54] thanks [11:04] re [11:13] smart server run good ? [11:15] Good? [11:16] can i use as production? [11:17] Sure. [11:17] now use this via simple ssh [11:17] bzr+ssh? [11:17] yes [11:17] What do you mean? [11:19] now bzr run not as smart-server [11:19] What do you mean? [11:19] nevermind, sry, i need run [11:27] i read the website, thanks Peng [11:28] Ok. === mwhudson_ is now known as mwhudson [11:47] hi :) === mrevell is now known as mrevell-lunch [12:25] Riddell: just curious, what is the biggest issue with the KDE repository when using it with bzr-svn? [12:25] Riddell: The memory usage when it's caching all revision metadata? [12:37] jelmer, the memory usage makes is almost unusable [12:38] jelmer, you have to restart it about every 1000 revisions, which gets boring for 700k revisions [12:38] (and people who are not aware of the bug will be very surprised) === cprov is now known as cprov-out [13:04] jelmer: yes, caching the metadata is just unworkable unfortunately === kiko is now known as kiko-fud === mrevell-lunch is now known as mrevell === cprov-out is now known as cprov [13:41] * quicksilver cries [13:42] why do so many blog postings about VCSes not even mention bzr? [13:42] http://blog.moertel.com/articles/2007/12/10/how-i-stopped-missing-darcs-and-started-loving-git [13:42] Because people don't know it exists? [13:42] SVN has all the limelight. And Git. [13:42] Git was in news lots because of the bitkeeper/kernel stuff [13:47] and mercurial currently has some little hype thanks to opensolaris and openjdk. perhaps canonical should also do some little advertising ;) [13:49] I wonder how I found bzr? [13:50] There were those Mozilla comparisons, but I think I knew about it before them. [13:52] i think i found it through some darcs-to-* comparison ... [13:55] hi there.. I am trying to migrate some svn project to bzr. I am working on a fedora core 7 machine, and I cannot get the bzr-svn plugin to work, due to the subversion bindings version mismatch... has anyone managed to get this working on a fedora core machine ? [13:57] ricardokirkner: my tongue-in-cheek answer for getting this working is installing ubuntu in a chroot/vmware/xen :) [13:57] but once upon a time i did manage to build the right version of the bindings on os x === kiko-fud is now known as kiko [14:12] luks, Riddell: Thanks for the feedback. [14:12] I'll see if I can spend some time fixing that memory leak in the next couple of days. === mrevell_ is now known as mrevell [14:26] ricardokirkner: I'm not aware of anybody providing pre-built rpms of a patched subversion, but there is a link on the bzr-svn wiki page to a howto that explains how to patch subversion on fedora === kiko is now known as kiko-phone === cprov is now known as cprov-lunch === kiko-phone is now known as kiko [15:19] Hey, I'm having a problem with bzr-email. i have a branch that i want a linux user group to be able to commit to (locally) - that works fine, but the bzr-email only seems to work if it's the owner [15:20] Daviey: do you have a specific traceback we can see? [15:20] !paste [15:20] pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) [15:20] ubotu: paste [15:20] jam: eek, i'm not sure where logs for bzr-email are kept [15:21] Daviey: well, mostly I'm interested in seeing what you saw on the terminal [15:21] Either that [15:21] or you can give me the tail of ~/.bzr.log [15:21] $ bzr commit [15:21] added test [15:21] Committed revision 1. [15:21] thats all on a working one [15:21] Daviey: you may want to use paste.ubuntu-nl.org since it won't throttle you for a big message [15:21] i will [15:22] I'm also not sure what you mean by "only works if it is the owner". [15:22] I'm not sure if you realize that each user needs to have bzr-email installed [15:22] and configured [15:22] yeah, i do [15:22] just my own user testing atm [15:22] It doesn't seem like the branch permissions should effect it, but I'm happy to help you debug what is going on [15:24] http://pastebin.com/m1f1da47f [15:25] thats if i commit to a folder where i'm in the same group, and have rw perms [15:27] http://pastebin.com/m7a54f32a and thats if i commit from a branch in ~ (hence i'm the owner) [15:27] jam: ^ [15:29] Daviey: I don't see much of a difference there [15:29] (only the revision_id and timestamps seem to change) [15:29] jam: there isn't! :( .. but the second works and the first doesn't [15:29] Daviey: define "works" :) [15:29] Sends an email versus not sending an email? [15:29] ie, sends an email [15:29] yes [15:31] I'm guessing it still looks for $HOME/.bzr/ of current user, and not the group user? [15:32] Daviey: Do you mean $HOME/.bazaar/bazaar.conf ? [15:32] yes [15:32] (sorry) [15:32] I'm sure we don't ever look in a group .bazaar [15:32] Config file is always per-user [15:32] I don't think we have a "group config" [15:32] You could probably set things in the branch itself [15:32] via $BRANCH/.bzr/branch/branch.conf (for --dirstate-tags or newer branches) [15:33] oww, i'll try that [15:36] Daviey: is there even a normal way to say "give me the home directory for this group" ? [15:36] You could have all users override BZR_HOME [15:36] to have it look in a different place for ~/.bazaar/bazaar.conf (and locations.conf) [15:36] But then it wouldn't really be per-branch [15:37] (only want one branch atm) [15:38] Can post_commit_to & post_commit be in bazaar under default? Or should the wildcard [*] be used in locations.conf? [15:41] hmmf, doesn't work with $BRANCH/.bzr/branch/ either [15:49] Daviey: I think you can put it in [DEFAULT], but only do that if you want all commits to send email [15:49] I know I have some branches I consider "private" [15:49] Daviey: what does "bzr info" give in the group branch? === mw|out is now known as mw [15:50] I'm wondering if it is an older format that only uses ~/.bazaar/locations.conf [15:51] Branch format 6 (and above) uses .bzr/branch/branch.conf [15:53] also ~/.bazaar/locations.conf takes precedence over .bzr/branch.conf just in case [16:00] How does one install bzr plugins? [16:00] I have grabbed the push-and-update plugin's source, but there aren't any docs associated with it. [16:00] glyph: Drop it in bzrlib/plugins or ~/.bazaar/plugins. === cprov-lunch is now known as cprov [16:07] jam: i'm using Bazaar (bzr) 0.15.0, but Gutsy package of bzr-email [16:07] ouch... that's an old Bazaar. [16:07] I would recommend upgrading if possible [16:07] bleh. [16:07] Some known minor bugs with how it handles renames [16:08] and does anyone have a suggested replacement for transport.split_url? [16:08] I see it is a "@deprecated_function(zero_ninety)" but no suggestion of a replacement [16:09] glyph: for what we need, I believe you can just grab items off of the transport itself [16:09] transport._user [16:10] transport._scheme [16:10] transport._password [16:10] etc [16:10] glyph: if you are interested in updating push-and-update, I'm happy to merge any patches [16:10] By the way, it would be nice to change it to work as a post-push hook [16:10] rather than a separate command [16:10] jam: Yeah, I was thinking the same thing [16:10] So it could install a branch hook [16:10] and then if it sees that the URL is ssh/sft [16:10] sftp [16:11] it could check if there is a remote working directory [16:11] jam: I don't think I understand the workings of bzr well enough to actually patch this though :) [16:11] and then trigger the rest of the code [16:11] glyph: ok, I'll take a few minutes and put something together [16:11] jam: <3 [16:11] I wrote it originally, but just haven't really needed it since [16:12] jam: I don't really "need" it, but it makes an awesome demo [16:12] jam: I was just showing bzr to a guy I know who maintains a stereotypically absurd apache configuration [16:12] Why does diff need a working tree? [16:12] "bzr init" in /var/www kind of blew him away ;) [16:12] Peng: it theoretically doesn't [16:12] Peng: igc has a patch on the ML which gets rid of that [16:12] but it would have been nice for "push" to just update the working tree on the server (since that's really his main use-case anyway) [16:14] that reminds me my discussion with lifeless the other day about a possible `push -u`, and that I still have to mail the list [16:15] jam: Oh, cool. [16:15] Just out of curiosity, why does it currently need one? [16:15] I think it changes the basic flow of the command, but it means you don't need WT [16:16] Peng: because it is a DWIM command, and it is complicated to get all of the edge cases working [16:16] For example, you can diff a working tree file that doesn't exist in the branch [16:19] jam: Oh, that makes sense. [16:21] Can anyone help with pqm? Here's where I am currently: http://rafb.net/p/lSPpmX40.html [16:35] hi. I managed to branch from my svn repository to a bzr repository, but in order to do that, I had to create a repository with the dirstate-with-subtree format. My problem now is that I cannot make a branch from this last branch into a repository with another format, or even convert the repository format [16:35] any ideas on what I should try? [16:40] ricardokirkner: they are incompatible repository formats [16:41] ricardokirkner: my recommendation is that you keep your bzr-svn branches in a separate shared repository. why do you want to use an existing one, since they are separate projects, anyway? [16:41] dato: maybe what I am doing makes no sense.. what I want to do is to migrate a project completely to bzr. [16:42] for that I branched from the svn repo [16:42] ok, very well [16:42] (what version of bzr do you have?) [16:42] but then, since the repository format is not the default one (it requires dirstate-with-subtree format), I wanted to branch to another repository, in the new format [16:42] I am using bzr 0.92 [16:43] is there a better way to do that? [16:43] you cannot go back from dirstate-with-subtree to dirstate [16:43] that is, branches originally created with bzr-svn are not compatible with the default format [16:43] but that should not be a very big problem, I think [16:45] but if I want to stay in bzr from now on... that means I will have to stay frozen on that repository format forever? [16:46] bzr 1.0-rc1 introduces a couple new, non-experimental repository formats, rich-root and rich-root-pack, to which you can upgrade from dirstate-with-subtree [16:46] any of those two is very safe to use [16:46] (the upgrade maybe slow, though) [16:47] do centralized version control systems offer particular advantages to commercial companies? [16:47] so, what you are saying is.. I should stay with the current format -- dirstate with subtrees -- until bzr 1.0 is out, and then I will be able to upgrade the repository format.. correct? [16:47] is it harder to keep your code closed / secret with a distributed VCS? [16:48] xif: Yes, but not inherently. [16:48] Peng: what do you mean? [16:48] ricardokirkner: yeah. but if you don't upgrade, you'll make people with older bzrs able to branch. why do you seem so anxious to upgrade, though? :) [16:49] xif: Well, with a centralized VCS, it's still possible to extract the entire history and wind up with just as much information as with a DVCS. [16:49] xif: The DVCSes currently aren't really focused on commercial environment so they don't have as good access-control features. [16:49] because I think... (here I might be wrong) that new repository formats should be more efficiente (performance wise) and eventually, I will want to switch [16:49] ricardokirkner: Well, the developers aren't trying to make new repo formats that are slower! [16:50] * Peng notices the backlog and scratches that last line. [16:50] Peng: so you claim CVCSes are more oriented for commercial / closed environments, so - incidentally to them being centralized - they're also a bit easier to protect than the DVCSes? [16:50] Haven't packs been pushed much more rapidly than previous backwards-incompatible changes were? [16:51] xif: Well, I'm just talking about Subversion here. [16:51] ricardokirkner: there is always a way to upgrade to newer repository formats, for example in 0.92 you already have pack-0.92-subtree [16:52] Peng: so SVN specifically has more evolved access-controls than most DVCSes? [16:52] ricardokirkner: and that upgrade is pretty straightforward. the full details of this story is that -subtree is an experimental format, and a new format was created a bit for bzr-svn use case, the rich-root one. [16:53] dato: ok... but currently there is no way to move the repository to the currently default format. actually that is no issue as long as the dirstate with trees format is efficiente enough [16:53] xif: I'm saying that svn has better access-control than the DVCSes I have experience with (bzr and hg), and that, while that is one thing that's being worked on, I've never seen commercial environments discussed. [16:53] dato: what would you recommend me to do? [16:53] I crafted that sentence too carefully. [16:54] ricardokirkner: oh. maybe it would help for you to think that, given that 0.92's default format is "dirstate", dirstate-with-subtree is actually an addition to it :) [16:54] Peng: I see === cpro1 is now known as cprov [16:54] Peng: I'm asking because I'm wondering why a certain company is using Subversion instead of bazaar / git / hg [16:55] oh... ok. :-$ I hadn't though of it that way [16:55] they have some very smart people there, many of the Python knowledgeable - people likely to prefer bazaar or hg [16:55] ricardokirkner: what to do, depends on how much concerned are you about having the latest and the greatest, and about maintaining compatibility with older bzrs for other people for branch from you. [16:55] so I guess that the codebase being top-secret has something to do with it... [16:55] xif: Well, even if companies have some smart people, they're generally insane. :) [16:56] Peng: nah, this company's ok, I think :-) [16:56] xif: When you have gigabytes of history, it sucks that DVCSes copy the whole thing to every developer's computer. [16:56] their CEO / CTO is a former hacker. [16:56] ah, that might make sense as well [16:56] Peng: what's the common solution for such a problem? [16:57] xif: http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html [16:57] I believe the Linux codebase has it, right [16:57] xif: Solution? [16:58] Peng: certainly there are some projects - e.g. the Linux kernel project - requiring said "gigabytes of history" while using a DVCS [16:58] xif: Meh. [16:58] xif: Linus doesn't care if it hurts you, as long as it works for him [16:59] xif: 10+ GB seems to be common in corporate environments, but not so much with FOSS. [16:59] oic [16:59] xif: I don't know of any FOSS stuff over 2 GB. [16:59] xif: Bazaar has "lightweight checkouts" and we are working on "shallow/stacked branches" to avoid some of it [16:59] Peng: Moz was >3 GB in CVS [16:59] Peng: OOo is about 20GB in CVS [16:59] but not all of that is code [17:00] they have stuff like mp3's of people's interviews in their CVS repo [17:00] jam: Moz may be 3 GB in CVS, but one can assume it would be a lot smaller in git. [17:00] jam: But OOo, oh. [17:00] Peng: sure, it dropped to ~1GB in Bazaar [17:00] s/git/anything else/, then. :P [17:01] Still, 1GB is non-trivial for most download [17:01] jam: "to avoid some of it" -> what's "it"? [17:01] xif: downloading the full set of history [17:01] Lightweight Checkouts store 0 history locally [17:01] (They don't even store copies of the files like in svn, do they?) [17:01] Stacked/Shallow branches would store a few commits [17:01] jam: I see, thanks. I'm reading your blog now [17:01] Peng: correct [17:02] :X [17:02] Peng: but we do keep the inventory locally, so "bzr status" works [17:02] why should I use bazaar over git or mercurial? [17:02] but "bzr diff" has to hit the remote [17:03] xif: http://bazaar-vcs.org/BzrVsGit [17:03] xif: http://bazaar-vcs.org/BzrVsHg [17:03] thanks :-) [17:03] and http://bazaar-vcs.org/BzrVsSvn, but mostly it just points to my blog [17:04] yeah, and I don't think many people who actually know either (or even understand CVCS vs. DVCS) would need help deciding between SVN and BZR [17:05] ropiku: you're trying to push to launchpad? [17:05] Riddell, yes and it says that I don't have a registered SSH key [17:05] Riddell, and I pasted my .ssh/id_rsa.pub onto launchpad [17:07] ropiku: what's your LP id? [17:07] Riddell, I think the weird stuff is that I push to sftp://bazaar.launchpad.net/~ropiku/kubuntu-tutorial/ropiku-branch [17:08] Riddell, ~ropiku (and name Mihai) [17:08] that all looka fine [17:08] Riddell, and it says "Launchpad user 'mihai' doesn't have a registered SSH key." that's my local username [17:08] oh, different user name [17:09] sftp://@bazaar... [17:09] so bzr push sftp://ropiku@bazaar.launchpad.net/~ropiku/kubuntu-tutorial/ropiku-branch [17:09] pushing... [17:09] Created new branch. ;) [17:09] Blehh, BzrVsHg was written by a marketer, wasn't it? [17:10] Riddell, ssh was connecting to my local username, that was it ? [17:10] ropiku: yes, which is the wrong username for launchpad [17:11] At first glance when it was first created, I thought that article was garbage, but now it looks kinda-OK, except that it sounds like marketing trash. [17:12] what's the difference in using sftp:// instead of bzr+ssh, isn't bzr more efficient ? [17:12] yes [17:13] for bzr+ssh, bzr has to be installed in the remote end [17:13] I'm leaning towards bazaar because: [17:13] 1) it's pure Python. I like pure Python [17:13] 2) I like Ubuntu and Canonical. [17:14] xif: Psst, bzr has some Pyrex (combines Python and C) and C bits. :P [17:14] Peng: oh shoot [17:14] Peng: errr [17:14] xif: those are optimizations and the same functionality is provided by pure bzr [17:14] pure python, I mean [17:15] Right. I was trying to think of how to say that. [17:15] Anyway, bubble-bursting over. [17:15] xif: you don't *have* to compile them, we have pure-python fallbacks [17:15] Wikipedia says bazaar is Python: [17:15] http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Technical_information [17:15] But they are a bit faster if you do [17:15] Mercurial OTOH is listed as "Python, C" [17:15] jam: yeah, it's still cool though [17:15] also, Pyrex is better than plain C. [17:16] Yeah, Mercurial has four C modules. [17:16] Bzr has parts of modules written in Pyrex or C with alternate Python versions. [17:16] What about Cython? [17:16] what about it? :-) [17:16] vila: ping [17:16] it's a nicer Pyrex afaik, but less people use it [17:16] jam: btw, how do create "Python fallbacks" for C code? [17:17] just rewrite the whole thing in Python, then make sure it passes the same tests? [17:17] Cython is pretty new. [17:17] xif: correct [17:17] Except the other way [17:17] jam: cool, good to know [17:17] we had it written in Python [17:17] and then we implemented it in C/Pyrex [17:17] yeah, I assume so: Python is better for prototyping [17:17] and made sure that all the tests pass with both ways [17:17] A couple months ago Cython's website said it was only experimental, but I can't find that now. [17:17] So when we run "make check" it tests both implementations [17:18] vila: I'm getting a "500 Too many spams from your IP" when trying to send email to you, but the page it sends me to is in french [17:18] jam: what's the deciding factor between using C or Pyrex for the optimized rewrite? [17:18] vila: http://postmaster.free.fr/ [17:18] xif: Generally we prefer Pyrex [17:18] we had 1 person rewrite something in C [17:18] and it was good enough we weren't going to rewrite it again in Pyrex [17:19] I personally always use pyrex [17:19] for things I've rewritten [17:19] jam: WTF ? [17:19] I really like how it handles exception handling without me needing to worry about it all the time [17:19] vila: I *think* my ISP somehow got blacklisted [17:19] I stopped sending directly from my home machine [17:20] because of blacklist sites that block whole ranges [17:20] jam: OK, so there's no technical reason to ever prefer C over Pyrex, but some people (at least one person) had a personal taste preference for C extensions, which is the only reason there are pure C extensions in Bazaar's codebase [17:20]