My XCode 4.x Review

Here is an attempt at trying to enumerate the things I experienced using XCode 4 while developing an iOS application.

As you will read from my comment below, what came out of my experience dealing with XCode are lots of annoyances and major issues. The long due redesign of Interface Builder by now, didn’t bring so much value to the table. Having two processes communicating for building one app was not so painful. At least, when one was crashing the other one was still running. Now everything goes down in flame and more often than I wished. Kaboum!

In general, XCode 4 feels extremelly sluggish even on a MPB with 8GB of RAM. I’ve been putting my XCode 4 upgrade on hold for some time after reading so much bad press about it from sites like Chromium Project, as late as last December. I finally upgraded because I needed to code against the latest iOS SDK. I thought that waiting for a dot release would resolve an early adoption syndrom (never trust a dot zero release). Nope, that didn’t work with XCode. Even Project Builder on NextStep 486 felt faster in comparison. Performance in XCode 4 is abysmal. You are not going to get any speeding tickets using XCode 4. On the contrary: lots of coffee breaks while the app is doing “something”. I’m tempting to ask for Apple to run their own performence tools (Shark) and figure out where are these bottlenecks are in XCode then fix them please.

More regarding performance: I get the spinning cursor more too often than not. Sometimes it happens when I did a user “mistake”. Try selecting all your files when the focus is on the project navigator instead of the file opened (the cursor is not in the document.) You’ll curse when you see the result. I believe the code is literaly going through its XML project files parsing away with no interruption possible whatsoever. Keep waiting, because it will eventually get back to you. This is not right.

Indexing is in the way. while XCode is re-indexing constantly, which is fine by me, sometimes it’s locking up the UI after a build, which now becomes a problem. It’s as bad as “Emptying the trash” message in Finder. And I thought that only iTunes runs on a single thread. Here you want to say: “Who cares!?!” if it’s indexing, just do it and leave me alone. Can I resume typing code now, please?

What indexing is good for? Auto-complete for one. So how does AC measures up? Not very well, I am afraid to say. Jumping to definitions in C++ is going to bring you the whole list of functions in every possible files that exists on your system. No wonder it takes forever to index. And this is happening while you are clicking on a namespaced function!!! WTF Apple! I hate to bring it up, but have a look at how it’s done in Visual Studio to see a useful example of selective navigation thru symbols.

The dreaded alert message: “XCode has encountered an error, do you want to continue or select crash”. Nice! While my files are opened and unsaved for a while now… @#$% What should I do? This message appears more often than than I wished it did, about 2 or 3 times a day. What other choices do I am than to click continue really? Am I crazy enough to click the crash option? I don’t consider my application such an heavy development to realize that Apple can’t be using XCode 4 internally for their own development. If they did, they would fix this type of problems, don’t you think?

This brings me to the next point: XCode is not another MacOS X application. For one, it doesn’t follow the automatic updates mechanism. It means that even with the tons of crash reports Apple is getting, don’t expect to see any bug fix updates frequently. I can tell that XCode may even be internally not subject to the same quality level as users applications. It seems that if Apple staff were using XCode, most of these problems would be fixed by now.

One thing you do when you develop an iOS application or at least try to do, is build a modular application with re-usable pieces. Apple calls these “Frameworks”. That is a great concept. Bundle the libs and headers in one package and drag them around to your next project. Except that you can’t build a Framework that works on iOS and the Mac Simulator (it’s called universal) because Apple removed that option from XCode 4. I use a script from StackOverflow, but frankly I am perplexed at to why would Apple remove such a convenient feature on purpose.

The addition of Frameworks and libraries went some place under “Build Phases”. Just measuring the hit score for that given hint on StackOverflow makes me realize how clunky the location for that functionality has been thought out. I struggle with XCode. Sometimes, the project will open (after one of those crashes), and no project navigation or toolbar. I need to go and reselect those.

And when you finally found that option Apple keeps moving around such as “adding libraries” you have to type in an auto-complete dialog the name of your libraries that you have to select one by one. Ugh! Did I mention that folders with libraries inside don’t automatically open when you type their names? Click, click, click…

GDB visual interface is far from being useful. I’ve tried using it to inspect arrays and other objects. I have to constantly go back to the cli on the right side. We are miles away from Intellij IDEA ease of use their great debugging UX.

When you start to enable and disable too many breakpoints, the app gets confused. It suddenly won’t let you put a breakpoint on a line. You need to delete them all and then you are able to add a breakpoint.

Analyzing compile error using error logs is an exercise in mouse click practice. The most recent error log won’t pop up. Instead you often need to access it thru the right-most icon then click on the top entry in the list. Why?

Analyzing the linker logs. All entries are truncated at 200 lines, so you end up clicking (again) or expanded dialogs to see the full logs. It’s there all right, not just conveniently accessible.

Using most recent files: Suddenly the tabs are gone and you are left with two arrows to navigate thru hundred of files. What gives? The most recent file list is burried in a sub level in that icon line.

The debugging process suffers from the most-recently used page cache eviction bug. The OS will keep paging out the latest app you compile even if you want it to go away since you are recompiling a fresh new one.

The other debugging short-coming are intropection of variable on the source document. The hilighting of info on parts of the code deosn’t reveal any content value. Again, you are forced back to using ‘p’ and ‘po’ in gdb cli.

Debugging multi-threaded app causes crashes at a worrisome rate. I ended up implementing thread disabled code to be able to debug it.

And whatever you do, don’t rename or remove files and projects OUTSIDE XCode unless you are ready to work from the lastest backup.

On a side note: my recommendation is to stay away from snapshots since they lock you down in XCode while replicating functionalities you should get from a a good versioning system like svn or github. Plus, it will take another few hours of uninterrupted work for XCode to snapshot your project. Why this can be done in the background if you have to absolutely use this is beyond me. Once more, I seriously doubt that Apple is using their own “dog” food here.

In conclusion, XCode is a development tool that should be designed exclusively to boost developer productivity on a platform that Apple claims greatly simplifies development.. In order to achieve this sound goal, I suggest for Apple to fix the major bugs and start giving its developers community some love, by offering a tool everyone enjoys using on a daily bases.

 

Node.js for Android committed on github

Yesterday, I posted my initial port of Node.js for Android on github (https://github.com/ldesegur/nodejs-android). This is a very early work, as my main job has kept me away from making more progress. However, results are showing some promises. I am sharing this code so other people are able to help.

So far, v8 and libev seem to work. libeio needs some more work on the I/O side. I’ve wrapped all the missing bionic kernel calls, so they are emulated correctly on the thwarted libc available on Android. They appear with ANDROID defines. Maybe node.js main could take those back into their repo? I have yet to modify the makefiles, conforming to ndk-buiid, to generate JS2CC files, so for now, the translated js to native are committed in the repo. Running basic eval commands with node.js returns results in the log files.

Why am I working on this and how can it benefit other developers?

I believe there is a tremendous benefit to have Node.js running client side. In my personal quest to find a way to write JS code performing well on mobile devices, offering native functionalities and being modular so it’s updatable using AJAX, I couldn’t find a better solution than what node.js provides to server side developers. Node.js gives very simple and elegant way to write JavaScript code in multiple modules with ‘export’ and ‘require’ declarations. The ‘process’ mechanism lets JavaScript access bindings and native code. V8 offers native-style performance and the V8 bridge is simple and will allow other libraries to be developed as local and remote modules.

My goal, as I move forward with this project, is to offer all functionalities that a modern browser DOM would supply (including xmlhttprequest and webgl), to the client JavaScript executables.

Porting node.js to Android

After spending a couple of days dealing with Android NDK madness, some esoteric and intricate Linux implementations on this device, I finally got node js latest to run as a native app on Android.

I was planning to originally run a v8 client on Android so I started with the v8 port. That one was easy. However, when I realized how much benefits node brings to any JavaScript development, and
not only server side, it was obvious that the rest of the stack needed to be ported.

I did some research, hoping someone had gone thru the hoops already. But all I could find was a direct port done on Linux arm and running with root privilege. I couldn’t adopt this approach because my ultimate goal is to deliver JavaScript apps running on standard phones and available on Android market.

Now that I am done with the initial port, my next task is to clean up the codebase, refine some of the plug-in native bindings, fix a bunch of remaining specific issues (e.g. fs, console, ipv6, etc…) and post the result of this work on github (ldesegur/nodejs-android.)

Let me know if you have any interest. I would certainly appreciate any help on this project.

Building libev and libeio with Android NDK

First, libeio: I beat autoconf, autoreconf and automake until I was able to get a config.h. Surprise! It’s equivalent to config.in with all options on.  Next, I added this lines in the xthread.h file, just after include <pthread>

#ifdef ANDROID
#include <asm/page.h>
#endif

This takes care of the PAGE_SIZE definition missing from <limits.h> (it’s defined as itself in that file, I kid you not…)

And since bionic is built non-posix, I added these lines after include <sys/select.h>, in the unix section (!WIN32):

  #ifndef ANDROID
  #include <sys/statvfs.h>
  #else
  #include <sys/vfs.h>
  #define statvfs statfs
  #define fstatvfs fstatfs
  #endif

The Android.mk is very straightforward, I just build the eio.c file pointing local includes to the same dir.

To build libev, you’ll need to add the following lines to ev_select.h:

#ifdef ANDROID
typedef int fd_mask;
#endif

That’s how the openssl people apparently solved this missing type definition.

We are almost there. Next, add the following lines just after EV_USE_CLOCK_SYSCALL:

#ifndef ANDROID
# include <syscall.h>
#else
# include <sys/syscall.h>
#endif

Finally, the next thing to do is to compile two files: ev.c & event.c with local includes set to the same dir. That sounds simple when you read this, but since the extra c files are included by the ev.c main file, compiling them directly with their headers will result in undefining variables, and this won’t compile. It would have been nice to wrap the .c files around an #ifdef #endif, to avoid this. The configuration works with all setting turned on (including latest GCC and libc).

And The Winner Is…

I am a C/C++ developer who turned as a Java developer by faith. Those languages are my computer mother tongue. I write in imperative languages since the dawn of time (and before that it was assembly.) While in college, I encountered Lisp on one of these unfamous Symbolics machines. It was at the time when the first Macintosh came out, back in 1984. The choice of languages to make my living at that time was simple. I had to program on the Mac because I felt in love with the little bugger and I couldn’t afford a 10 of thousands dollars Lisp machine. I started my company creating software for the Mac. From that time, I realized that I would always use 2 computer languages at once, one for building and shipping products at work, the other for learning new things and experimenting at home. Over the years, some of those experiments landed with their adoption in the workplace (Java), some never left the playground (Smalltalk.) I still consider that it is a necessity to do my homework and the benefit has always been a result in improving my programming and debugging skills.

Now, 25 years later or so, I decided to re-evaluate what I’ve been learning and using to program so far. Java is the predominant language that I currently use at work. I decided to make the shift a long time ago, because I was just fed up with all these C++ annoyances. I paid the toll of being an early adopter but looking back, the investment was worth it. I’ve also used Perl (and hope to have never to do that again) and now use Python for scripting shell tasks, which syntax I find appealing and libraries amazingly complete and simple to use. But I got buried into that mode for a while now, and it’s easy to keep doing the same thing over and over and not pay attention to what’s happening out there. So I kicked myself in the arse and did some probing around.

What pushed me toward this rebirth in language knowledge is due by both curiosity and a bit of luck. Last year, I moved offices at work and bumped into an old copy of Common Lisp that someone had left behind on the shelf. By then, I started looking at what the functional landscape would look like for a Java developer like myself with a predisposition for new stuff. I was fairly happy to see that languages like Scala and Clojure had gained popularity and started evaluating them with small projects.

As a pragmatic developer, I’ve always tried to keep an eye on what’s coming up and I took the guided tour with few languages. I evaluated Erlang in my previous job but didn’t care so much about its ugly syntax. I’ve pushed back a couple of times on using Haskell for doing serious work. These languages have great and compelling features. But at one point or another, I run into some limitations. I’d go and burry myself a few days in the syntax trying to solve puzzle games and writing basic algorithms. I understand that getting to know a language will make you like it more because efficiency is an advantage. It’s pretty much the case for all languages, including human ones. But I also believe that love at first sight should be part of the sticky factor. From all the languages, I’ve tried and used, at some point, I run into this little detail that will make me wonder: “Why did they have to do it that way? It’s stupid!”. It happened to me way too much with Haskell and Erlang. From then on, it’s easy to lose faith in the language, because you are doing this for fun and not for money.

In order to evaluate languages, I’ve built a classic set a good set of problems from algorithm and data structures classics. The 3 books you’ll find on my desk are “Structure and Interpretation of Computer Programs” (SICP) by Sussman, “The Art of Computer Programming” (TAOCP) by Knuth and “Algorithm Design” by Skiena. Other less frequently used books are “Compilers” (the dragon book), “Introduction to Algorithm”, “Concrete Mathematics” and a bunch of books on algorithms, data structures and transaction processing. A while ago, I realized that anything else I can either google it up or just read some wiki about it. That includes but is not limited to design patterns, web architecture (caching), graphics and cryptography.

Until now, I kept coming back to Haskell just for the kick of it (like a hard drug), hoping to finally adopt the most original language I’ve ever used. Haskell has plenty of good and innovative ideas inside of it. But I can’t seem to get along with the syntax very well. I spent many hours in the libraries source code trying to make sense of some grammar, but my mind just won’t click on certain things. It’s not that it’s too complicate for me because I’ve learned other functional languages but I realized that all the sugary syntax won’t cover the lack of foundations that I come across at one point or another. I didn’t care about the popularity of the language. I wanted to believe. But I couldn’t “fall in love” with it. Same deal with Erlang. To some, Erlang is like a tank, ugly but efficient. To me, it’s feels more like the ugly little duck that didn’t grow up yet.

After all these months of looking around and trying new languages, I’ve recently installed a Scheme compiler on my laptop. It’s name is SISC standing for Second Interpreter of Scheme Code (I am not sure what happened to the first one…) I’ve also picked up a usde copy of “The Little Schemer” by Friedman and Felleisen (the cartoons are very cute) to refresh my LISP memories. So far so good. I haven’t forgotten so much after all. The syntax is a bit different but nothing really crazy. I realized that life is a vicious circle. LISP showed up its face again after more than two decades. I can’t ignore the signal.

What’s interesting about SISC is that it’s built on JVM. And because I’m an Android developer, I’d love to contribute and be able to use it on the platform (someone has done a successful test already.) Why not Kawa? I looked at it and found out that Google is using it as a runtime for App Creator, but SISC seems to be a better candidate for dynamic coding (ala JRuby.)

My goal is to go thru the SICP book once more and solve problems with the SISC REPL. I hope to start sharing the results of this endeavor pretty soon. I’ll then tackle the Skiena book and maybe Sedgenwick if I have the energy and the time. My long term goal, God willing, is to re-read TAOP, and do the same for problems marked <= 25 (at first…) I’ve never digged M/MIX anyway 🙂

Till next time, have fun!