Tag Archives: Programming

Rosyna Keller

By now, many of you have no doubt heard of Rosyna Keller and the problems that he’s suffered. He wrote about them today; the full post can be found on Medium at https://medium.com/@rosyna/the-horrors-of-extended-stay-debilitating-depression-and-a-plea-for-help-c450425fb9ec. (If you can help him, please take a moment to go to Paypal and send what you can spare.)

As Michael Tsai’s blog post on the subject shows, there are many of us who know Rosyna and what he’s done for the Mac developer community. But there are also many who don’t, so I’d like to explore it for a moment from my own perspective.

Michael Tsai writes that Rosyna is “an enigma”, and that’s certainly true. I was only barely aware of him at the time when I benefited most from his work. He was the brilliant mind behind APplication Enhancer (known in the dev community as APE) and the outstanding haxies made by Unsanity. (He was not, to my knowledge, the sole person involved in the development of those projects, but his role was considerable.) My personal favorite had to have been ShapeShifter, a tool which allowed users of Mac OS X back in the 10.5 and earlier days to heavily theme their installations. WindowShadeX, Xounds, and Mighty Mouse were also staples of any Mac install I used. I credit the availability of these haxies with keeping me from souring entirely on development in general at that time in my life- they allowed me the chance to get used to OS X, without losing the sense of flexibility that the older MacOS had.

Those of you who were around for the pre-OSX era are probably scratching your heads about now and wondering what I’m talking about. The truth is, I was simply much younger, and the ability to make my screen change to the colors I wanted after getting stuck with the stupid that was Aqua was really important to me!

Even more than that, the very existence of APE grabbed hold of my imagination – and let me remind you that I would never have known what it was if not for the haxies and all the work Rosyna put into Unsanity. At the time, I was a great amateur as a developer; I knew very little about what was really going on in the system. Many who know me may find that surprising, given the study I’ve made of exactly that subject and in light of my work on OS X Internals, but it was things like APE which put me truly on that track.

In short, while Rosyna can’t be said to be solely responsible for my career, his work was a major factor in making what I’ve accomplished so far possible.

Of course, all I knew about this “Rosyna” back then was that it was a name associated with Unsanity. I never really read the blog, I had no knowledge of the history of the person or the company, and when the haxies stopped coming, a lot of it all faded from my memory. It wasn’t until several years after that I ran into him.

And even then, I didn’t know who he was for a long time yet. All I saw was someone who, despite his obvious misery, reminded me a lot of myself in many ways. It’d be a lie to say I’ve ever been through what he has, but he was a person who made sense to me on a personal level. There aren’t a great many of those; the majority of my relationships are largely or entirely professional.

Imagine my amazement when I finally learned he was the (to me, at least) legendary Rosyna of Unsanity! The symbol of the magic that could be wrought within the machines before me, if you’ll allow me the conceit. Again, while he wasn’t the only inspiration I ever had, he was certainly an important and memorable one, even if I didn’t realize it for a long time.

I learned in that time that it wasn’t just Unsanity that Rosyna was known for. He is a diligent researcher, a person of great insight into the workings of these machines. He has solved problems no one else could. He has helped any number of fellow developers and fellow people when he could, and with more patience and compassion than some of the most famous minds of our generation.

And for this, he has ended up with the burdens he’s described.

In the time that followed, I lost touch with him for a while. When I was lucky enough to connect again, I found him in the precursors to the troubles he described in the Medium post.

Through everything, Rosyna has remained a person who keeps hold of the things that, to my limited knowledge, fascinate and cheer him. He has his eyes on the things that are happening, and while his choices of what matter may seem strange to some, he has rarely if ever Tweeted or otherwise remarked on something that I didn’t find at least momentarily worth my attention. And for me, that’s saying a lot.

In depression, he’s never lost hope. In turmoil, he’s reached out for help, a strength that I’ve failed to find in myself many times over. In the extremity of fear and oppression, he’s spoken out for himself and risked asking the kindness of a community infamous for narcissism and elitism, and in doing so, proven that that very infamity is undeserved.

I can only hope I would have half the strength in me that he does if ever I found myself in his position.

If you are reading this, I ask you to reach out to Rosyna and help him. Even if all you have is a kind word – they do not fall on deaf ears.

More about OCDepend

A few hours after I posted about the email I got from CPPDepend, I received this response:

Hello,
I read your interesting feedback about our product posted in your blog, and what can I confirm is:

- It's not a spam, this mail was sent to only 3 people, that we consider they have a good Objective-C skill to have their valluable feedbacks.
- You are right some effort must be done for OCDepend in our website.
- Maybe I'm wrong but I dont think that OCDepend features exist in XCode, for example CQLinq is a powerful tool to request code base and enforce its quality.

If you have time to test the product it will help us a lot to improve the product,

Best Regards.

Dane.

Here is my response:

Hi Dane,

Please note, in the interest of full disclosure, that I have also posted this response on my blog for my readers to see.

First, I’d like to say that I’m impressed. Not everyone would bother to take the time to respond to comments like the ones I made, and considering how “form letter” the first email was, I’m doubly gratified to see a personally addressed response the second time around.

I’m still somewhat troubled that the original email read very much like marketing spam. Thank you for contacting me and for considering my opinion valuable, but in my opinion, sending a generic email that doesn’t say anything about why I’m receiving it or give me any sense that it was even intended for me is a very poor way to ask me to review your product. Since you did take the time to respond to me, however, I will offer these additional thoughts:

The value of the pro license you offered in your first email, USD $500, is by itself something I would not recommend to any Objective-C developer in the first place. Mac developers, particularly the smaller ones like myself, are not as used to such high-cost licensing schemes as you’ve probably come to expect from your Windows customers. I certainly wouldn’t consider buying something that expensive unless I had very certain and solid proof that it was going to save me a significant amount of time over the tools Xcode already provides.

Without actually looking at the product itself (and I’ll emphasize to other readers, I have not looked at OCDepend itself and can offer no direct judgements about it), I have browsed your website considerably, and I have to say again: It is entirely lacking. As a developer, I read the phrase “CppDepend and OCDepend are based on Clang for more reliability.” and immediately dismiss it as nonsense. It turns me off, severely so. Basing something on Clang does not intrinsically make it reliable; it only means you have access to the exact same system upon which modern versions of Xcode are built! And Xcode itself shows that it’s extremely possible to be based on Clang and still be horribly unreliable.

Your cited feature that makes OCDepend so much better than Xcode is this “CQLinq” language that allows for querying of my code. To what end, exactly? To “request code base”? Assuming I understand your intended meaning, this means I can get information about my code in query-language form. I presume “enforce its quality” refers to something like putting this query language in a Git commit hook or other such script to check that conventions are being followed. Your website cites CQLinq as being “for maximum flexibility”, which is meaningless if it’s actually your flagship feature; that phrase makes it sound more like an add-on for advanced users. I don’t mean to make light of your English, and if I’m doing so, I apologize, but I can’t see what this feature is meant to do for me. Your website gives the following example:

from m in Application.Methods  
where m.NbLinesOfCode >  30  && m.IsPublic
select m

Which returns all public methods longer than 30 lines of code. So, I have to learn a new domain-specific language applicable solely to your product in order to do something that’s ill-defined at best to begin with. What is a line of code? Do blank lines count? Lines consisting only of an opening or closing brace? Comments? Preprocessor macros? Macros that delete code under certain conditions? To say nothing of the fact that Objective-C doesn’t have the concept of non-public methods.

CppDepend also advertises its ability to compare builds. Any developer who needs to do this is almost certainly already using Git or Mercurial (or some other VCS) to do so for free. For tracking builds in the wild there are such tools as HockeyApp, Crashlytics, and TestFlight. CppDepend’s dependency graphing already exists in Xcode, and quite frankly, most of its other features for code quality look like something of interest purely to managers more concerned with metrics than functionality. No developers with whom I’ve ever personally worked in Objective-C (my personal experience only, that of others will almost certainly differ) have worried about metrics like these. They’re more the subject of The Daily WTF articles!

In summation, from what I can see without downloading your product, I can’t imagine I’d ever give it a second glance. It is obviously true that my experience may be atypical, that there may be much more useful features in your product that are not listed on your website, that I’m simply in a bad mood today, or any number of other explanations for my disinterest. I remain very much open to being proven wrong, and I look forward to that possibility, but as it stands I could not recommend this product to anybody (again, for those others reading, I haven’t in fact downloaded it at all, so take it with a grain of salt). I would see the price tag and immediately veer towards the tools I already have unless yours could quickly and convincingly show me that it was better for the job.

— Gwynne Raskind

Objective-C and the Web

Earlier today, courtesy of @GlennChiuDev, I was reading Kevin Lawler’s informal tech note about using Objective-C to power the Web. I found myself agreeing with quite a lot of it.

I then had the chance to read @heathbordersresponse to the original post, which I realized I was also agreeing with in considerable measure.

So here’s my response to both. I’ve assumed that readers have at least skimmed both the original post and the response so that I don’t have to do what Heath did and duplicate everything they said here :).

Kevin makes the point that Apple has hugely improved Objective-C in recent times, especially with the most recent releases of OS X and iOS. Heath objects that while Objective-C has certainly improved, it’s still a strict superset of C and comes with all of C’s well-known and discussed-to-death problems.
While I agree with every one of Heath’s list of issues with Objective-C, my thought is that everyone works best in whatever works best for them. Some people (myself included) are going to be more comfortable in a bare-metal-with-extensions language like Objective-C, while others are never going to enjoy it in comparison to Java. It’s a personal thing, and I’d argue that a programmer who doesn’t like Java, for whatever reason, will never save time in it no matter how many conveniences it provides over Objective-C. Heck, I get plenty of scripting done in PHP even though I agree that Python and even Ruby have enormous language advantages and that PHP has severe community and design issues, because I’m extremely familiar with it.

Kevin goes on to say that Java was meant to be a write-once run-anywhere language but failed at it, and Heath counters by pointing out that Java does indeed do this.
This isn’t really a simple argument in either direction. Java was indeed intended as write-once run-anywhere, but while Java CLIs and servers do fulfill this promise for the most part, I think Kevin was thinking (as I did at first) of Java GUIs. To a one, I have never met a Java GUI I like, on any platform. Java apps look and act horribly non-native on OS X, are slow (and odd-looking, if less so) on Windows, are just as clunky as everything else on X11 (my personal opinion of all the X windowing toolkits is that they all stink), and as for Android… well, I don’t like Droid, and even that aside, Java working “right” on one platform is the exact opposite of the promise. In that respect it might as well not be any different from Objective-C in its platform dependence.

I do have to agree with Heath and disagree with Kevin regarding writing portable C/C++ being easy. Even if you use only POSIX APIs exclusively, which will severely limit your functionality in the general case, this is a nightmarish undertaking. Even if you restrict yourself only to Linux variants, nevermind trying to work with all the other UNIXen, OS X, and Windows, it’s all but impossible without a complex system like autoconf (which is another entire rant about horrible garbage in the making).

With regards to the JVM, I have to agree with Heath again: The JVM is absolutely a useful UNIX system layer, and JIT does make it a lot less slow than Java used to be. Similarly with garbage collection; GC is an abomination in C and Objective-C, but that’s because the design of those languages precludes the collector having full knowledge of what is and isn’t a live object without very restrictive constraints. In a fully virtualized language like Java or C#, properly implemented garbage collection is absolutely a useful technology.

I can’t say much about Java re: Oracle, since I don’t know much of what really happened there, but just from reading the respective posts, I have to say Heath makes a more persuasive argument than Kevin’s declarative statements.

Kevin then goes on to say that object-oriented programming is a win over functional programming, and Heath objects, saying that there are a great many people who disagree. In this case, while I personally agree with Kevin in my own work, this is another area where personal preference and training will trump blanket statements every time.

Kevin also talks quite a bit about Automatic Reference Counting (ARC); Heath didn’t respond to this section. I find ARC an absolute divine gift in Objective-C, but all ARC does is bring the syntax of GC to a non-GC environment, and in an incomplete fashion: The developer must still be careful to avoid retain cycles with weak references and explicit nil-ing of strong references.

Kevin goes on to talk about Apple’s failed WebObjects project. He gives some reasons and thoughts about Apple moving Objective-C to cross-platform deployment. He seems to be unaware of GNUStep, ObjFW, and other similar projects, but setting that aside, I absolutely agree that Apple bringing the full Objective-C runtime, including most if not all of Foundation, to a wider UNIX base would be spectacular. Reviving and expanding the former OpenDarwin project would also be awesome, in my opinion. In this, I’m completely on Kevin’s side; this should happen and he lists several good reasons for Apple to do it.

Now Kevin goes on to say what is no doubt the most controversial thing in his entire post: “Xcode is an excellent IDE, with tolerably good git support.”

Like Heath, I must say: This. Is. Patently. False.

Xcode 3 was a tolerably good IDE, absolutely. Not modern or fully-featured by any measure, but fairly decent. Xcode 4, however, is a crock of <censored>. I’ll let Heath’s response speak for me on this for the most part, but I’d like to add that Xcode’s git support is also absolutely abysmal. Worst of all, there’s no way to shut it off, even if you never told Xcode that the project had a git repo.

So to summarize, what Kevin seems to have posted is a rant about his issues with functional languages and Java, and his love for Objective-C, without a lot of facts to back it up. I’m strongly in agreement with his feelings on most points, and I totally agree that Objective-C would be an awesome language for Web programming, but I suspect Apple hasn’t gotten into the field exactly because Java isn’t the terrible beast he made it out to be. This is a shame, to be sure.

As a footnote to those who still follow this blog hoping for a post on this subject: Missions of the Reliant isn’t dead! I’ve been pretty busy for a long time, but I will find time to work on it!

A potential direction for Objective-C

As with my Xcode rant, this is a modified version of a mail I sent to an Apple mailing list, in this case objc-language:

I agree that adding an === operator to Objective-C would be, at the very best, questionable at this late date, if indeed it was ever anything else. My experience in PHP has been that the two are very often confused and misused, and I can’t see that being any different in Objective-C.

I do strongly support the concept of @== and @!= operators that equate to [object isEqual:] and its negation, as well as the associated @<, @> etc. operators. If one of the objects in question can be determined not to implement compare:, throw a compile error. If either operand is typed id, throw a runtime exception, exactly as [(id)[[NSObject alloc] init] compare:] would do now. In short, make the operators mere syntactic sugar, just like dot-syntax and the collection literals, rather than trying to toy with the runtime as @"" does.

This is not “arbitrary” operator overloading, as with C++. That would be an absolutely abhorrent idea, IMO. Define new, unambiguous operators and make it very clear exactly what happens when they’re used. Don’t make it possible to change that behavior from affected code. Add a compiler option or ten so you can do -fobjc-compare-selector='myCompare:' or what have you (as with the one for the class of constant strings), but that’s all.

I understand people who complain that Objective-C is getting “too big”, but the fact that the collection literals were implemented (yay!) makes it clear, as far as I’m concerned, that it’s understood that the language is just too verbose (and difficult to read) as it stands. Adding a new set of clear, intuitive operators would not detract from its usability. People who don’t know enough to write @== instead of == were already going to write == instead of isEqual: anyway, as a rule.

My Xcode rant

It seems everyone who develops for OS X or iOS these days has their own rant about the problems with Apple’s development environment, Xcode. Well, here’s mine, excerpted from a message I sent to the xcode-users mailing list.

Xcode 3 was getting pretty good for awhile, but then Xcode 4 was released, a massive backwards step in functionality which has only been getting worse with its point releases. I have suffered, shockingly, very few of the crashes and data loss bugs which other people have been plagued with, but I have plenty of gripes just the same.

Xcode 4’s integrated layout may look good on paper, and even work better for some people, but for others it’s a hopeless struggle to manage screen space and get a consistent workflow going. Xcode 3’s ability to pop open and then close the build progress window was delightful; with Xcode 4 I just get the build log in my editor pane without being able to see the code I’m working on. Ditto that the IB integration into Xcode; with a windowed layout that would have been tolerable, but as it is I spend considerable time just going back and forth between interface and code views to see what the heck I’m doing – and no, tearing off Xcode 4’s tabs doesn’t make it better, because that has a near-100% tendency to completely destroy my window position and layout settings. Xcode 4 took away the class hierarchy view. It took away the ability to compile one file at a time. The integrated debugger console is painful and takes away from code editor screen space. Workspaces are just plain broken and do not work as advertised. The configuration editor is a step up, but unfortunately the “scheme” concept is a two steps down. Switching between Debug and Release should not require chugging through three settings panels to find the right switch. And don’t talk to me about the inability to shut off Git integration on a per-project basis (or, for that matter, at all). Why can’t I enable Guard Malloc or change the debugger used for unit tests? Why am I sacrificing valuable screen space (and I say that having a 27″ screen, fully aware that people are doing dev with Xcode 4 on 11″ Macbook Airs) for an iTunes-like status display when Xcode 3’s status bar was just as useful?

And Xcode 4 itself is, as a whole, sluggish in every respect. Operations of all kinds, from editing text to creating connections in IB to switching between code files, which were perceptually instantaneous in Xcode 3 take visible time in 4. Even those 200 milliseconds here and there add up to an overall feeling that I’m spending more time waiting for my development environment to catch up with my thinking than I am actually writing code. Yes, it’s very nice that the debugger console and utility panels slide neatly in and out with smooth animation, but I’m a developer; Apple doesn’t have to market eyecandy to me. I’d strongly prefer instant response. And all I get for all this trouble is ridiculously bloated memory usage forcing a restart of the program every several hours of serious work.

Before anyone asks, yes, I’ve filed several Radars. All have been closed as duplicates (which means I’ll never hear anything about them again) or ignored (same result). The impression I get from Apple is that they think that they have enough people who build their livelihoods on the iOS ecosystem that they don’t have to put any effort into improving the tools for those who give a darn about a time when writing code wasn’t an exercise in stockpiling $20,000 for a tripped out Mac Pro whose stats can compensate for Xcode’s flaws.

Some other good examples of the problems people have with Xcode:

Guest post on Michael Ash’s blog

I am honored to announce that I’ve done a guest spot regarding assembly language on the blog of well-known Mac developer Michael Ash. You can find my post at his blog. I highly recommend every one of his posts for OS X and iOS developers of all kinds. Thanks for the opportunity, Mike!

Markdown is cool

I have discovered that the minimalist markup language known as Markdown is absolutely awesome. Why? Because it’s utterly simple, utterly expressive, easier to type than HTML, and works spectacularly in TextMate.

That is all.

For those of you who are still hoping for Missions of the Reliant news, I want you all to know I have not forgotten or abandoned the project. I will come back to it, hopefully someday soon. I thank all of you who remain from the bottom of my heart for your incredible patience, and hope you’ll bear with me just a little longer!

Missions of the Reliant: Happy Belated Anniversary, Reliant!

The one-year anniversary of the project to port Missions to modern Mac OS was one week and 5 days ago. I’m sorry I missed it, but as always, life puts a heck of a damper on the fun we want to be having. Still, I’ve got a few extra minutes to spend on it, and in the last few months I’ve learned a lot of new things. One of them is that having a plan is almost always a good idea! So as gift and apology, here’s the plan for the present and future of Missions of the Reliant!

  1. Because I haven’t worked on the project in a while, and because the time I’ve spent in iOS has taught me a great deal about proper Cocoa programming and OpenGL, my first action in returning to the Xcode project titled “Missions” will be to go through the game’s subsystems and fix some of the rather basic mistakes I made as a less experienced coder. This includes such things as the use of VBOs in OGL, unification of the disparate “node” classes into a proper hierarchy (eliminates an amazing amount of duplicated code), replacement of some of the things I hand-crafted (such as audio file access) with third-party libraries (since the ones I’ve investigated invariably did better at what they were meant for than my efforts), and possibly an even more general refactoring if I decide it’s necessary (a decision which pends further review).
  2. After that comes completion of the missing gameplay functionality. I don’t at this moment have a decent list of what’s missing available, but the stuff that comes to mind are most of the computer functions and the enemy AIs. Once all of that is done, the lot of it has to be tested to make sure I didn’t miss anything above the level of fine details. This leads up to…
  3. … The storyline, the literal “missions” of the Reliant! Those of you who played the original game (almost all of you, I’m sure) will remember that Mike provided three of them – invasion, rebellion, and time travel. These require tying together all of the gameplay elements in their proper linear fashion, which may sound simple, but this is one place where the mass of spaghetti in the original source code isn’t nearly so sad to look at (with, as always, apologies to Mike), because that was the only way to do it without OO features at least as advanced as Objective-C’s.
  4. At that point, the game will be ready for beta testing, and a 1.0 release. Said release will of course be freeware, and I plan to distribute through the App Store as well as on my Web site. I plan to ask Mike for suggestions on how to handle beta testing, but I tentatively plan to open it up to, at the very least, to everyone who subscribed to the mailing list.
  5. With 1.0 behind us, there will still be plenty to do. The game in that state will not be a direct port, and just won’t provide the sense of nostalgia I suspect many of you are, like me, hoping for. There are too many new features and changes in the interface. Some of them were my creativity getting the better of me, some were just inevitable moving between two completely different operating systems and programming languages across a gap of more than a decade. I plan to make a 1.5 (or whatever!) release which provides a “classic gameplay” mode, wiping out all the new features and restoring as close to the original exact interface behavior as possible. User feedback may, of course, convince me that this would not be worth the effort, but that’s something to think about at the time, not now.
  6. Finally, I never saw Missions as a static game. Mike released it as such because, among other things, that was the only kind of game we had back in those days. But just like Kirk and the Enterprise had lots more adventures after the original series, so can this game have more episodes. My vision is of downloadable content, and even a scripting interface so anyone can make new episodes for the game. This is a project almost as large as the game itself, and is another thing to possibly set aside based on the feedback of players, but it’s something I would certainly enjoy doing.
  7. Even further in the future, perhaps a 3D engine and models? The sky’s the limit! But let’s not get ahead of ourselves. At that point we’re talking about an entirely new game, practically an MMO if one takes the thought far enough, and that’s pretty silly if you look at it from right now. It might not be later!

I hope it’s obvious that I’ve put some thought into all of this. I still won’t have a lot of time to work on the game, but any is more than the none I’ve had lately, so expect to see updates coming again.

As always, my deepest thanks go out to you all for your patience as I’ve struggled my way through this project, and I’ll continue to do my best not to disappoint.

P.S.: I have considered making the game require Snow Leopard to play. It’s been long enough since its release that this might not be a bottleneck to most people, and it would considerably simplify some of the code; Apple added quite a few nice things to Cocoa only that recently. Please leave some feedback on this thought in the comments or on the mailing list!

A handy trick with blocks and callbacks in Objective-C

While writing some code to implement a block-based callback on top of some classes which are still stuck in the target-action paradigm, I stumbled across this rather nice little trick for doing so in a category without having to do any memory management tricks at all in retain-release mode. This example comes from adding a block callback to iOS’s UIBarButtonItem (DR is for Dark Rainfall, of course):

// This category is required, but doesn't have to be in the same place.
// The concept is simple, and used by several other code libraries: Because blocks are
// also objects when the Objective-C runtime is loaded, a category on NSObject adds
// the selector to them. Obviously it would be foolish to call this category on an object
// that was not a block.
@interface NSObject (DRBlockCallback)
- (void)DRcallbackBlock;
- (void)DRcallbackBlockWithSender:(id)sender;
@end

@implementation NSObject (DRBlockCallback)
- (void)DRcallbackBlock { ((void (^)())self)(); }
- (void)DRcallbackBlockWithSender:(id)sender { ((void (^)(id))self)(sender); }
@end
// Now for adding a block callback...
@interface UIBarButtonItem (DRButtonBlockCallback)
- (id)initWithBarButtonSystemItem:(UIBarButtonSystemItem)item block:(void (^)(id))b;
@end

@implementation UIBarButtonItem (DRButtonBlockCallback)
- (id)initWithBarButtonSystemItem:(UIBarButtonSystemItem)item block:(void (^)(id))b
{
    // Call correct initializer. Provide the block callback as action, but no target yet
    if ((self = [self initWithBarButtonSystemItem:item target:nil action:@selector(DRcallbackBlockWithSender:)]))
    {
        // It's necessary to copy the block and hang on to it somewhere. Categories can not add
        // ivars to a class. Associated references were designed to solve exactly this kind of
        // problem. This call associates the block with this object, conveniently doing the needed
        // copy as well.
        objc_setAssociatedObject(self, "DRactionBlock", b, OBJC_ASSOCIATION_COPY_NONATOMIC);
        // Now when the block is retrieved back from the association, the copy is returned, which is
        // the target for the block callback action.
        self.target = objc_getAssociatedObject(self, "DRactionBlock");
    }
    return self;
}

// There is no need to override dealloc. The association will automatically be dissolved when the
// object is released, at which point the copied block will also be released.
@end

Poof. Proper management of a block’s memory in a retain-release environment without any effort! This little trick could be further simplified by another method on NSObject, something like - (id)associateBlock:(void (^)(id))b withKey:(const char *)key;, but that’s overkill in my opinion. For completeness’ sake, I also wrapped the whole thing in #if NS_BLOCKS_AVAILABLE, though on iOS that’s probably unnecessary, as I have no intention of ever developing for <4.0 again, and even on OS X I would use PLBlocks if I had to target Leopard.

For those waiting for Missions of the Reliant news, I beg your patience. I have not forgotten!

Missions of the Reliant: He’s dead, Jim.

With heartfelt apologies to DeForest Kelley.

The doctor is now a useful officer. Good luck getting the last word, though. Wounded crew get treated with the very latest technology, the skill of the best surgeons in all the Alliance, and often a grumpy bedside manner well worthy of Robert Picardo. I wish I could make a Doctor Who reference as well, but I know I could never do justice to a series I’ve only seen a tiny slice of.

Aside from the working doctor, I fixed a long list of minor bugs, things like the engineer doing repairs at the wrong speed, wrong text colors in the console, weapons and helm commands not requiring skill from the officers, and so forth. Stay tuned for more!

Missions of the Reliant: How many times do I have to tell you, the right tool for the right job!

Here are some highlights of my latest progress:

  • The engineer now has something to do. Systems can be repaired at a speed relative to the officer’s engineering skill.
  • When systems are damaged, the appropriate officer tells you so.
  • I fixed a really annoying problem with key presses repeating so fast it was very easy to give incorrect commands.
  • I finally realized I had to manually adjust the texture width for kerning for strings drawn in Geneva.

The doctor is next. I’m pondering an easter egg that would change the name of the officer to David Tennant. Squee.

Missions of the Reliant: Receiving subspace message from Alliance HQ

According to my commit log, I’ve accomplished a lot, but I think a lot of that is stuff I’d already done and mentioned here, and just not committed. Bad programmer! Bad! No treat for you! Anyway, there is one thing I know hasn’t hit the blog yet, and that’s incoming subspace transmissions. Those are the big blobs of text in the middle of the screen containing all that awesome plotline Mike wrote. Nice stuff, if you ask me. Those work now, and they come in correctly via the helmsman, using the reports interface and everything. Only part that isn’t quite right yet is there’s no HQ text flashing at the corner of the viewscreen, but that’s easily done. I’m inching ever so slightly closer to having a fully implemented mission here.

Things still missing to make Assault on the Alliance completely functional:

  • Engineer functionality (repairing damaged systems)
  • Doctor functionality (healing wounded crew)
  • Starbase interaction (don’t actually need all of it to make the mission work, though it won’t be as much fun without a Mat-Trans or crew swapping)
  • Cruiser and battleship AIs (actually less complicated than the fighters)

That’s all! Stay tuned for more progress!

Lua + iPhone = mess

And now one of the rare not-Missions-related posts.

I found myself with the need to run Lua code under iOS. Yes, this is legal according to the current Apple Developer Agreement. Who knew the journey I’d undertake in the process.

Originally, I got it running by just building the Lua source files into a static library and linking it in, then using the C API as usual. Worked like a ruddy charm. But then I decided to get clever. “Wouldn’t it be great,” I thought, “if I could run the bytecode compiler on the source and make them into unreadable bytecode objects?” So originally, I tried piping the source files through luac and running them otherwise as usual. The story of how I got Xcode to automate this process without a damned Run Script build phase is another one entirely.

Bad header in precompiled chunk.

Docs say, “The binary files created by luac are portable only among architectures with the same word size and byte order.” Fine. x86_64 and armv[67] are both little-endian, but sizeof(long) on x86_64 is twice what it is on armv7. Duh! Running Stuff on Apple Systems 101. Universal binary, here I come! I built lua 32-bit and lipo’d myself a nice universal binary of luac, ran it via /usr/bin/arch -arch i386.

Bad header in precompiled chunk.

What? Byte order and word size are correct. So I delved into the Lua source code. lundump.c, lines 214-226. Precompiled chunks are checked for version, format, endianness, size of int, size of size_t, size of Lua opcodes, size of the lua_Number type, and integralness of lua_Number. All of which should have been correct- until I remembered that I’d changed the luaconf.h of the iOS binary’s Lua to make lua_Number a float. It’s a double by default.

Rebuild my universal binary of luac using the same luaconf.h the iOS project uses. Run it through yet again. Lo and behold, it worked that time. It doesn’t really feel right to me running i386-compiled bytecode on armv7, but since Lua doesn’t even remotely have support for cross-compilation and I don’t feel like jumping through the hoops of making a luac utility on the device without jailbreaking, it’s the best I can do.

I would be remiss if I didn’t remark also upon the journey of learning how to make Xcode automate this process for me. There was more than just running luac to be done. I wanted my Lua scripts run through the C preprocessor, to get the benefits of #include and #define. Easier said than done. The C preprocessor doesn’t recognize Lua comments, and while because comment stripping is part of preprocessing I could have used C comments instead, it would have meant changing a goodly bit of code, and messed with the syntax coloring. And more importantly, my sense of code aesthetics. It’s always bothered me that the C preprocessor can be both Turing-complete and damn near impossible to work with (an aptly-named Turing tarpit). So I wrote a pre-preprocessor (also in Lua, naturally) to strip the Lua comments out first. But then I had to parse and handle #include manually. Oh well. The real benefit of C preprocessing is the macros anyway. It was quite an interesting bit of work making Lua talk to clang; the built-in library for doing things is a little bit lacking. Anyway, the upshot was there were three steps to processing Lua files in the iOS project: preprocess, luac, copy to Resources.

I finally caved in to my sense of danger and went looking for the extremely scanty reverse-engineered documentation on Xcode plugins. It was pretty awful. The API looks to be quite a mess of inconsistently named attributes with strange side-effects. It took me two hours to hunt down the cause of a “empty string” exception as being the use of $(OutputPath) inside a cosmetic attribute (Rule name). It was hardly perfect even when I declared it done, and then I realized I had the architecture problem again. I had to run a different luac for x86_64 than for everything else. If i386 was the only other architecture, I could’ve just let it be done by a universal binary, but no, it had to cover armv[67] too. Ultimately it turned out a second plugin was necessary, lest Xcode be sent into a downward spiral of infinite recursion at launch. Ugh. Don’t talk to me about all the horrifying effects the tiniest typo could have on Xcode. I love the one in particular where the application was fully functional, except for builds and the Quit command. Uncaught Objective-C exceptions equals inconsistent program state, people. And it’s not just that the API is entirely undocumented. You get those sorts of weird behaviors even if you never install a single plugin or specification file; the Apple developers don’t always get it right either. The application is a horrid mess, and I find myself desperately hoping that Xcode 4 is a full rewrite. I can’t discuss anything about Xcode 4 due to NDA, of course.

As a side note to all this, compiling extension modules for Lua also turned out to be an unmitigated nusiance. It turns out, you see, that the extension authors out there tend not to run their code on Darwin-based systems, and so all the ludicrous quirks of dyld tend to hit a user of their code smack in the face. Finding out that I needed to pass -bundle -undefined dynamic_lookup to the linker instead of -shared was easy enough from the Lua mailing list posts on the subject. Figuring out why that didn’t work either meant realizing I’d built Lua itself with -fvisibility=hidden for no good reason at all, causing the dlopen() calls to crash and burn. Figuring out why my self-written pcre interface module randomly crashed with a bad free() during Lua garbage collection meant debugging and valgrinding like nuts until I found out you’re not supposed to link liblua.a to the extension module. Static library + linked to both loader and module = two copies of the code. Anyone’s guess which you get at any given time. One could only wish dyld was able to make itself aware of this ugly situation.

If anyone’s interested, give a holler in the comments and I’ll post the pcre extension as an opensource project. It’s not fully featured (in particular it’s missing partial and DFA matching, as well as access to a few of the more esoteric options of the API), but it does work quite nicely otherwise. It’s built versus PCRE 8.10 and Lua 5.1, and is upwardly compatible with the still-in-progress Lua 5.2 as it currently stands.

I promise I’ll get some work on Missions done this week!

Missions of the Reliant: Thanks for the support!

I don’t have any real progress to report, with one exception: The “Report” command for all crew members, the one which tells you that systems are damaged and that crew members are hurt and that messages are incoming and all that sort of thing, is now complete and working. It’s not tested past the most basic stuff yet, though, so give me time :-).

The real thought behind this post is to thank you all for the unremitting support you’ve all shown these past months as I’ve worked on the game. Every few posts I get a whole list of comments from everyone who says they’ll wait for me to finish it, telling me how much they look forward to the results of the work I’ve put in. I just wanted to say, I truly appreciate it, and I’m certain I wouldn’t have gotten even this far without that to encourage me. Thanks, everyone :-).

And, as always, a special thanks to Michael Rubin; without the enthusiasm he showed when I first approached him with this idea, it couldn’t have happened.

As a gesture of my appreciation, here’s a short QuickTime clip of the Reliant entering warp drive. I’ve been promising you a real look at this thing for a long time. Enjoy! And please blame CoreText and QuickTime for the text layout and sound synch problems! ;-)

QuickTime Player plugin required. Tested on Firefox 3.6 and Safari 5.0. No guarantees about other browsers.

As always, stay tuned!

Missions of the Reliant: Take the weapons station

Well, I cleaned up the command console code quite a huge bit, it now works quite nicely, and also the gunner’s commands are all fully implemented (with the exception of, as with the helmsman, “Report”). I wish I had more progress to report, but I’m still here and I’m still working on the game, so hopefully you won’t lose hope yet.

This project has taken quite a bit longer than I ever expected, I have to admit. I started back in February with the impression that it would be a simple port, but I forgot at the time that I hadn’t yet learned much about OpenGL, OpenAL, and other such things. It’s turned into a tremendous learning experience for me, in everything from subsystems and frameworks to code design and testing procedures. Then real life came and intervened, kicking my progress down to an even slower crawl. That all being said, I’ve been enjoying it all the way through, even when OpenGL and CoreGraphics have been violently frustrating me with the problems of text rendering on a CGL surface :-).

I hope to have a more substantial update this weekend. Wish me luck! As always, my thanks to Michael Rubin for giving me the chance to work at this, even if I have taken just this side of forever ;-)

Missions of the Reliant: Status update

It’s been awhile since I’ve updated, and I thank anyone who had the patience to wait around to read this post! To all of you, I apologize for the long hiatus.

While I’m still working on Missions of the Reliant actively, it is not at this time my highest priority. As always, the needs of reality interfere; as Missions is not a project I expect to be making money from, I can not unfortunately prioritize it above projects I do expect to be paid for, as much as I might like to. For this reason, I’m afraid I must, with apologies, beg the patience of all of you as work continues on the game at a slower pace.

All that being said, there has been some progress. The command console, that little window where you interact with crew and the computer, is now completely working and looks correct at last! All but two of the helm commands are implmented, and those two are missing only because I haven’t built the functionality for crew reports and subspace messages in yet. My plan is to implement the commands for the weapons officer, engineer, and doctor next, in that order. The latter two automatically bring the functionality of system repairs and treatment of downed crew members, filling in two more gaps in the functioning of the Reliant as a whole.

From there, it’s just a matter of the battleship and cruiser AIs and a bit of game logic to manage their spawning, and the first mission is essentially done.

Once again, thanks to everyone for your patience and support!

Missions of the Reliant: You’ve got to know why things work on a starship.

I finally worked out the major design issues blocking the way for the command input console (also known as that tiny rectangle in the bottom right you see short messages and crew commands in) to exist. Long story short, a lot of things were being handled by the player object and the crew objects that should’ve been handled in the command console class (which didn’t exist yet). Took a bit of retooling to put everything where it belonged.

The console and computer (which I had to implement at the same time since the console depends on it being an addressable input processor) are far from finished products, to be sure. The console pretty much doesn’t work (though it does display not responding when a crew member is down), and the computer is just a framework of code so the console can operate. There really was no way to implement either one separately at this point, since the console depends on the computer and the computer has no function at all without the console. However, at this point I’ll be focusing on the console and adding the computer later, since finishing the computer involves also implementing a number of thus-far ignored displays (such as the galactic map, the ship mods and cargo screens, and the library screens), whereas finishing the console brings back functionality that was partially working before and isn’t now.

A lesson to take away from some of the snafus I’ve made during this project is to have clearly defined rules of interaction between objects early on, and to stick to them. The “responder” class which defines common functionality for anything that needs setup/teardown, mouse/key input, periodic tasking, and access to (pseudo-)global objects does not define any way of letting subclasses say “these objects here need to know about any input I don’t handle and need to be tasked when I’m tasked”, for example (and there’s no larger list of responders to iterate over), which has resulted in a number of subclasses each doing it a bit differently. It works, but it’s ugly as heck. (For the curious, the main game controller prods several top-level objects from its own responder methods, each of which tick others that they’re responsible for; it’s a mess.) I need to go back and standardize and commonalize this stuff. Why didn’t I do that before? At the time I never realized so many different objects were going to need to respond commonly to those inputs, because I hadn’t known then about all the design necessities that I do now. There just weren’t enough objects then to make it worth managing responders the way Cocoa does with NSResponder (first, previous, and next responders in a chain). Now there are.

Who knows. Maybe a certain five-digit prefix code will become an easter egg that does something interesting.

Missions of the Reliant: Why the bridge is an easy target at the top of the saucer section is something I never understood.

I’ll give you this one, Star Trek fans. It’s a shortening of a quote from the Captain’s Table series of books, specifically book five, “Once Burned”, by Peter David: “Why in God’s name the bridge, arguably the most important strategic point of the vessel, is an easy target at the top of the saucer section is something I never completely understood. Why not just paint a big target on your ship and write, ‘Aim here for best shot at the captain’?” – M’k’n’zy of Calhoun, inner monologue.

Straegic design choices have never been shown to be a strength of the human race. Take, for example, this ever-lengthening thread on Apple’s objc-language mailing list, which can be summarized as an increasingly complicated debate on the merits of the design of the C language. What it really boils down to, though, is two important points:

  1. Designers of any sort, linguistic or otherwise, do not have the power to see into the future.
  2. Users of any sort will cling to the old and proven over the new and possibly better 99 times out of 100.

This is a problem I’ve run into in Missions. My code design as it currently stands has no real place for me to implement the code necessary for handling all the different screens of commands and text necessary to implement crew and computer interaction. Right now, I’d have to duplicate a lot of interface code in two (possibly three) separate places, and unifying it would mean exposing implementation details across two subsystems. True, Mike’s original code exposed everything to everything with global variables, and that’s a legitimate approach for games, but I know it’s not necessary in this code if I take the time to go back and redo some of the code structure correctly. Also, it offends my sense of object-oriented design; I worry that it’ll open me to further trouble later on.

Anyway, the practical upshot of all this is that it’s going to take me a while to do something I should have dealt with much sooner. Refactoring, even across only a minor subset of a code base, is a significant pain. I’ll try to keep tabs on my progress here, but if I don’t post for a week, don’t worry, it just means I’m still working.

Missions of the Reliant: We have high hopes that this will, if successful, generate power to keep us alive

The viewscreen “system” is implemented, or more exactly the source code needed to do more interesting things with it is in place. It can’t currently take damage or go offline, so there’s no functional change. It’s a bit of code work that needed doing for the sake of correctness and to ease later improvements.

Life support is now implemented and functional, and damage to it will make crew members start going down.

Computer is next, which means crew interaction is next. Long overdue!