Notag

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…)

Ran into another issue with my netrek-server move to cmake.

Attempting to link with an internal library gives me a whole bunch of
“non_lazy_ptr” linking errors:

Linking C executable trimscores
Undefined symbols:
“_Cambot_out”, referenced from:
_Cambot_out$non_lazy_ptr in libnetrek.a(getpath.o)
“_NoCount_File”, referenced from:
_NoCount_File$non_lazy_ptr in libnetrek.a(getpath.o)
“_Global”, referenced from:
_Global$non_lazy_ptr in libnetrek.a(getpath.o)

Spent alot of time poking around google until I found this url:

http://software.intel.com/en-us/articles/intelr-fortran-compiler-for-mac-os-non_lazy_ptr-unresolved-references-from-linking/

Summary

of the above url says that when you “ranlib” you really should “ranlib
-c” and makes reference to the libtool manpage (more on this later).

If I ‘ranlib -c ntserv/libnetrek.a’ and make

$ make

Linking C executable trimscores
[ 98%] Built target trimscores

Things work.

First question, how to I add “-c” to ranlib evocation?

I build libnetrek via the ADD_LIBRARY as noted below:

ADD_LIBRARY (netrek STATIC
advertise.c
alarm.c

warning.c
)

Which generates this command line:

/usr/bin/ar cr libnetrek.a CMakeFiles/netrek.dir/advertise.o
CMakeFiles/netrek.
dir/alarm.o CMakeFiles/netrek.dir/warning.o
/usr/bin/ranlib libnetrek.a

My gut tells me to change CMAKE_RANLIB but maybe a change the ADD_LIBRARY?

My research on ranlib lead me to libtool and the libtool manpage. On
osx-10.5.7 (all I have access to) the libtool manpage states:

” Libtool with -static is intended to replace ar(5) and ranlib.
For backward compatibility, ranlib is still available, and it supports
universal files. ”

To ultimately, the ADD_LIBRARY should be changed to libtool. Just
passing that information along.

Thanks.

(more…)

Run into the strangest linking error for tools/trimscores on osx/darwin.

Compile of trimscores.c to .o no problems.

Go to link.

/usr/bin/gcc -g -Wl,-search_paths_first -headerpad_max_install_names -
fPIC trimscores.o -o trimscores ../ntserv/libnetrek.a
Undefined symbols:
“_Cambot_out”, referenced from:
_Cambot_out$non_lazy_ptr in libnetrek.a(getpath.o)
“_NoCount_File”, referenced from:
_NoCount_File$non_lazy_ptr in libnetrek.a(getpath.o)
“_Global”, referenced from:
_Global$non_lazy_ptr in libnetrek.a(getpath.o)
“_PlayerFile”, referenced from:
_PlayerFile$non_lazy_ptr in trimscores.o
_PlayerFile$non_lazy_ptr in libnetrek.a(getpath.o)
“_GodLog”, referenced from:
_GodLog$non_lazy_ptr in libnetrek.a(getpath.o)

I’ve removed al CFLAGS and LDFLAGS still get the same linking error.

Ok, lets look at libnetrek, getpath.o in there?

$ ar t libnetrek.a | grep getpath
getpath.o

getpath cannot resolve (as an example) GodLog, poking around I found
GodLog is defined in data.c

#ifdef CHECKMESG
char MesgLog[FNAMESIZE];
char GodLog[FNAMESIZE]; <———-
#endif

Is data.o in libnetrek?

$ ar t libnetrek.a | grep data
data.o

Is GodLog inside data.o?

$ ar x libnetrek.a data.o
$ nm data.o | grep GodLog
00000100 C _GodLog

Any ideas?

Used darcs-fast-export and bzr’s fastimport to “convert” Quozl’s daracs repo into a bzr repo. Worked great.

Since the RSA stuff has been removed CHANGED to the BSD License I pushed the branch to launchpad:

https://code.launchpad.net/~tanner/netrek-server/osx-branch

Terse announcement here:

https://launchpad.net/netrek-server/+announcement/2851

And the answer is yes, I’m building the osx branch using cmake. I’ll post another day on why I switched.

(more…)

As previously discussed here:

Here
Here

And

There

I offered to pickup and help with the development of the netrek client for osx.

At the time I had never written a line of objective-c. Cocoa was
something chocolate, served hot, with marshmellows. So, I started down
the path of “Hello, world!”.

As I dabbled I made little projects, licensed them under GPLv2, and put
them into bzr.

I will start to put these little projects into launchpad so others who
wish to start down the netrek-client-for-osx development path will have
example code to look at.

In each project, I tried to incorporate a feature or features I felt
would be useful in netrek client for osx.

The first project I’ve put up in launchpad is called FirstApp (nice
huh?) and it uses the Sparkle (http://sparkle.andymatuschak.org) framework for self-updating.

You can view code here:
https://code.launchpad.net/~tanner/+junk/xcode+FirstApp

You can get the code here:
bzr branch lp:~tanner/+junk/xcode+FirstApp

By default, the xcode project compiles a 0.1 release of FirstApp, I
have 0.2 release online (via appcast). So after running FirstApp 2 time
(see http://tinyurl.com/4bbwhe #5 for why 2 times) you should get the
auto-update window.

FirstApp demonstrates the use of Sparkle for self-updating osx
applications. Which I think would be a useful feature in a netrek client for osx.

NOTE: Release 0.2 is 10.5/i386 application so if you aren’t 10.5 and
aren’t i386 things will be ugly! I have since learned how to compile
universal binaries (i386/ppc) but Sparkle requires you to split
revisions of osx and I do not have anything but 10.5 systems.

Trying this twitter stuff out. You can check my profile here. And follow along