SIDEBAR
»
S
I
D
E
B
A
R
«
MYProjects now hosted on Bitbucket.org
April 22nd, 2009 by jens

I’ve set up new homes for my various programming projects on Bitbucket.org, which is rather like Github, only for Mercurial instead of Git. (hg clone github.com, perhaps?)

In addition to Mercurial repository hosting, each project gets a nice source browser, a wiki, and a bug-tracker.

To kick things off, I’ve put up a new release of MYNetwork. It doesn’t change the core functionality much, but it adds

  • A new PortMapper class that lets you open up your TCPListener to receive connections from outside your local network, when behind a NAT;
  • Bonjour classes for browsing for network services.

I’ve also restored the BLIP protocol documentation that went AWOL when my own local project server died last year.


11 Responses  
  • ssp writes:
    April 23rd, 20092:02 AMat

    Very interesting to see this. And a shame that the Port Mapping features will remain pretty much hidden unless you know where to look for what exactly.

    Did you manage to gather additional information on which techniques are used by the library to achieve port mapping and in which areas it is superior/inferior to other libraries like TCMPortMapper?

           
  • dete writes:
    April 23rd, 20098:16 AMat

    I’d be interested to see why you chose Hg over Bzr or Git. I’m fighting with the same choice right now and, even if the answer is “Coin Flip”, it would help me with my own decision…

    Thanks!

           
  • Jens Alfke writes:
    April 23rd, 20098:42 AMat

    ssp — Yeah, it’s odd that the port-mapping API is so hard to find; I don’t think there’s any documentation beyond the comments in the header. Hopefully my class will make it a bit more visible.

    I know that the implementation uses UPnP or NAT-PMP to ask the router for a mapping. Fortunately most NATs support one or the other these days. It does not use any of the tricks to poke holes through the NAT (as described by Kegel, Ford, et al).

    I haven’t looked at the source code of TCMPortMapper, but from the description it sounds like it uses the same protocols. I don’t know which would be better, to be honest. The system API built into mDNSResponder may be better at keeping track of network changes, but that’s just speculation.

           
  • Jens Alfke writes:
    April 23rd, 20098:54 AMat

    dete — I don’t have any ironclad reasons for preferring Mercurial. It comes down to

    • I went through Monochrome and Bazaar and Mercurial, and then decided that I needed to pick one system and stick with it. So by the time I heard about Git, I had already made my decision.
    • Mercurial and Bazaar are written in Python instead of C. This makes the source code much easier to understand, and more likely to work OS X. (It also means they’re more Windows-friendly than Git, which isn’t an issue for me but has been for other teams.) Performance has not been an issue for me at all, though I can imagine it could be with huge repositories.
    • The command syntax of Mercurial makes a lot more sense to me than Git’s.
    • Mercurial is smaller and easier to install than Git (which dumps dozens of binaries into your bin directory.)
    • Mercurial and Bazaar have a fairly similar syntax and workflow, but there’s something about Bzr’s that has ended up confusing me and leading to weird conflicts when pushing changes between repos. Mercurial just ‘clicked’ better, and I pretty much always know what I’m doing with it.
    • I’ve read a bit about the underlying data structures of both systems, and I really like Mercurial’s better than Git’s. Git might scale better for extremely large projects, but Mercurial’s implementatio is very elegant.
    • I don’t like Linus Torvalds’ attitude in recent years. I’ve seen some mailing list posts by him, responding to technical criticisms of Git, that were really nastily condescending. I’d rather not be associated with that.

    That being said, it’s not a religious issue for me. If I want to work with a project that’s using Git (like most Ruby stuff) then I’ll check it out and work with it using Git. Whatever gets the job done. :-)

           
  • ssp writes:
    April 23rd, 200912:18 PMat

    I thought I’d give the NAT thing a little try to see how well it works for me. So far I haven’t been particularly successful with the dns-sd -X command (which from the output of the tool sounds like it may just use the same underlying code), so I tried the project you uploaded.

    Unfortunately it fails to compile on my Machine (X.5 / Xcode 3.1.2) with plenty of “‘for’ loop initial declaration used outside C99 mode” errors. I suppose that fiddling with the right compiler option may make that one go away (I think the ‘problem’ are counting variable declarations inside the ‘for’ statement), but I’ll just note that I find open source stuff much more convincing when it compiles right away.

           
  • Jens Alfke writes:
    April 23rd, 20095:09 PMat

    ssp — MYPortMapper will probably behave the same as dns-sd, since both call the same system API.

    As the error message says, the code uses C99. Did you read the setup instructions? They say that pretty clearly, in boldface no less.

    The MYNetwork.xcode project does “compile right away” if you follow the directions. To use the sources in your projects you may need to set the language pop-up in Xcode to C99 or GNU99, as the directions say. For details on the build settings you can look at the .xcconfig files in MYUtilities.

           
  • ssp writes:
    April 23rd, 200910:57 PMat

    Good to know about the relation to dns-sd. So far I always had the impression that dns-sd doesn’t work properly as it always displays an external port of 0. Playing around with it, MYPortMapper and Port Map led me to think this may be some bug because MYPortMapper also gives an error after about a second even though the port has been correctly opened. This seems to work all right in other setups, so it may be an issue between OS X and my router or so.

    I didn’t even compile your code inside my project. It looks like the compiler options in your project are set to ‘default’ but really want to be set to ‘C99’. I have no clue about XCode intricacies but perhaps you have an inadvertent ‘C99’ default setting on your system which makes things work out of the box. I assume that making that setting explicit could avoid the problem.

           
  • Jens Alfke writes:
    April 24th, 200912:20 AMat

    ssp— I’ve seen the public port coming back as 0, and the docs don’t say anything about it, but in my experimenting it seemed to mean an error, so my code interprets it as such. In your setup, do you get a returned port of 0, but the mapping does get opened? Hm.

    The compiler options in MYNetwork.xcodeproj are set by the .xcconfig files in the MYUtilities directory. Where does it indicate default compiler settings in your Xcode? If you choose Edit Project Settings, select the Build tab, choose Show: All Settings, and look for “C Language Dialect” in the list, it should be set to GNU99.

    As far as I know there are no system-wide compiler settings that could be causing this problem. Every project sets them independently.

           
  • ssp writes:
    April 26th, 20091:19 PMat

    @Jens: I re-downloaded the project to make sure I didn’t mess anything up and those compilation errors appeared again. When looking at the Inspector for the project the setting for the C Language Dialect is ‘Compiler Default’. Setting it to xxx99 solved the problem for me.

    As I don’t even know what these settings are about I’m pretty sure I didn’t (knowingly) mess around with them. Neither do I have a clue which setting _should_ appear there by default.

           
  • Jens Alfke writes:
    April 26th, 20095:47 PMat

    @ssp — I think I know what’s wrong, but let’s track this on the shiny new official bug tracker, where it’s now Issue #2…

           
  • dete writes:
    April 29th, 200910:22 PMat

    Jens, thanks for the rundown on the DVCS choice, I 100% agree with your points about git, esp. Torvalds’ user-hostile attitude.

    The choice between Hg and Bzr is a tough one for me, and I was leaning towards Bzr until I saw Murky; I love the graph column in the history view and even a seriously pre-release native GUI client beats a total of zero GUI clients for Bzr.

    For me, Bzr appeals because of the ability to bind to an upstream repo, so that it temporarily works the same way as SVN (update automatically pulls, commit automatically pushes). Very useful in a commercial deployment.

    Mercurial also pissed me off because “hg resolve” actually does a remerge (which Bazaar properly calls “bzr remerge”), and you have to use “hg resolve -m” to do the right thing… It’s a little thing, but it’s a little thing that speaks to a lack of attention to detail.

           


»  Substance:WordPress   »  Style:Ahren Ahimsa