Notag

Got this spam email to the owner of the netrek-development mailing list. I got a pretty good laugh.

I had an epic failure and did not darcs add the cmake build files. “Worse” James’ osx merge branch is based of trunk and had all the deprecations of PING, RCD, RSA, so I had to spend some time merging branches.

Worked with Dave to get res-rsa-2.9.3 released. Good stuff.

Looks like you need to “beg” the LP admin’s for a project rename. Bummer.

Can follow along here.

As discussed on irc, all the launchpad teams associated with the Netrek
Project are being collapsed into a new time called netrek-developers.

Details to follow on how to change your maintainer to netrek-developer.

And here are the details.

Bah, have to ask LP admin to delete your team once you move it over to
netrek-developers.

See https://answers.launchpad.net/launchpad/+question/72902
for details.

I just issued a ‘darcs send’ to Quozl for the osx port (actually, I think I sent it to him 2 times, darcs newbie, sorry!)

The port wasn’t hard, mostly fixed up the macros and conditional compile directives. In the end the code changes aren’t very intrusive. I do not expect the code changes to be rejected after Quozl reviews them.

On the other hand, I totally gutted the build system and started from ground zero with cmake. This change might be controversial and I don’t expect Quozl to patch upstream right away, even with a code review.

In fact, the patch breaks the old autotool build! The the old autotools will not compile Vanilla anymore unless someone goes back to the configure.in and strips out all of the include-files-as-macros-hackery that it does.

Going to repeat the above.

NOTE:: The osx/cmake patch BREAKS building with autotools!

Why?

First the selfish reasons.

The autotools are a pita under osx. They pollute the system, seem to need constant tweaking, and generally not Mac-friendly.

Next, what version of autotools? autoconf-2.63 or autoconf-2.13? automake1.4, automake1.7, automake1.8, or automake1.9? All? Some? Just ick! And we all hate m4, right?
Now the techincal (non-selfish) reasons.

With cmake, you just need one tool; cmake. The 3 platforms we really care about are official supported (as well as others).

There’s plenty of “cmake FTW!” in Google. Good read is why KDE moved to cmake.

What I’m most excited about are cmake generators. In short, the ability to generate native build “instructions”. Like Makefiles for Linux, cygwin, even MinGW. NMake for Vistual C++. Xcode project files of osx.

For specific info look here.

And goodies, like CPack, for building software for your specific platform.

For specific info look here.

I’ll work with Quozl and the community to iron out all the rough spots. I am willing to do the work it takes to get cmake adopted as the build tool for the netrek-server.

If that doesn’t work, at least have cmake along side the autotools as a choice of build tool (cmake can co-exist with the autotools since it does out-of-source building (more in another post)).

I’ll continue to maintain the osx-branch of netrek-server until either of the 2 above situations present themselves.

For specific info on the osx-netrek-branch look here.

Oh, how things have changed. First netrek clients do not need to be blessed to work on the majority (all?) servers.

Now, it looks like res-rsa has had it’s license change so it can be exported outside the US!

I’m only 9 years late!

Port of the code was easy. Just couple header inclusions. I love cmake!

Working with res-rsa’s maintainer to get my changes merged into upstream.

Following up on my previous post here.

The second mini-project I’ve put up in launchpad is called “Simple Table”. It purpose to to explore Cocoa’s NSTableView.

I really struggled with how Cocoa uses MVC. Took me a day or two to wrap my head around the fact the NSTableView really is using MVC itself. Once I had the eureka moment and things started to make sense, I whipped up “Simple Table” example.

Get this branch: bzr branch lp:~tanner/+junk/xcode+SimpleTable
View the code: http://bazaar.launchpad.net/~tanner/+junk/xcode+SimpleTable/files

A Tableview, grid, what have you will be something used in a osx netrek client (Metaserver listing?). It’s more then a nice feature, it’s a requirement?

Next post wil be an expansion on this little project.

Spent the last 2 night adding unit testing to MetaBiff.

Yes, write the tests then code, but I was struggling through Cocoa, Xcode, and objective-c, I really did not have much of anything I really wanted to keep. I treated the whole session as 1 big spike solution.

I have a good grasp on OCUnit. Still stumbling on OCMock, but that might be my design ad much as lack of knowledge.

To help myself on unit tests and mock objects I started to refactor my code using Key-Value Coding. It seems OCMock makes heavy use of technology.

I do love @property and @synthesize for compiler generated setters and getter. I highly recommend it!

The lessons learned today.

How to check for an exception in OCUnit?

STAssertThrows([parser parse:@"a"], @”Protocol ‘a’ unknown.”);

When you want to compile NSString objects use STAssertEqualObjects!

STAssertEqualObjects(returnedVersion, expectedVersion,
                   @"Protocol header type did not match: return=%@ expected=%@", returnedVersion, expectedVersion);

STAssertEqualObjects([continuum valueForKey:@"name"], @”continuum.real-time.com”, @”Names does not match.”);

Next up to really understand Run Loops and how they relate to threads.

I’ve gotten netrek-server 2.15 ported to osx. It compiles clean, I even cleaned up the warnings.

I’m building everything in ntserv, newstartd, robots, robotd, tools, sequencer, keycomp, xsg, and pledit.

I was informed gum is no longer maintained? (if so, remove it from darcs?)

I prefer to work in bzr and would like to continue working there until we know that the osx code is stable and ready for merge back into upsteam/darcs.

The branch is hosted on launchpad: bzr branch lp:~tanner/netrek-server/osx-branch
Web view: https://code.launchpad.net/~tanner/netrek-server/osx-branch

I did alot of clean-up as I went.

#ifdef and macros for platforms and operating systems from the ancient past I refactored and just put in the equivalent (generally speaking) POSIX API calls. Example sun3? sun4? sequent? bzero vs memset? string.h vs strings.h?

What I would like to do is open a launchpad bug for each major “drop” of an old platform and allow the developers to discuss it.

I also removed most (all?) of the deprecated APIs, as hinted above, memcmp vs bcmp, memcpy vs bcopy, memset vs bzero. Like above, I’ll open a LP bugs and let the developers discuss.

Other clean ups:

* SYSV signals vs BSD signals
* Header file inclusions unistd.h? strings.h? stdlib.h? fctl.h?
* strcpy, strncpy, string stuff in general
* random, srandom vs rrandom,ssrandom
* usleep vs micosleep

Everyone think using LP bugs to discuss the changes is a good methodology for tracking all of this?

I purposely left out how to build the branch, the tools I used, and what not, as I did not start on a pristine osx install. I’m am currently working on documenting everything and will put something on the wiki when I think I have something that won’t cause more problems then it solves.

Right now, I’m just looking to start the discussion, let developers use tools they know (vim, emacs, etc) and give me a code review.

(more…)