Totally black screensaver

If someone is interested… this screensaver is simply… black.

screensaver

About learning Cocoa

I first learnt about ObjectiveC and Open/GNUStep when I was basically a Linux user. That was quite a lot of time ago. I was a WindowMaker fan, and that was the way I learnt about GNUStep. However, I did not learn ObjectiveC nor GNUStep programming. In fact there was plenty of “wonderful” languages out there and I felt no need for another one. The few GUI applications I did were made with GTK1 and C (yes, GTK 2 did not exist yet and wx was not really widespread; the first time I installed Audacity on Slackware 8.1 I had to google for them) or Qt with C++.
I was quite skeptical with interpreted languages too: I knew a bit of Lisp (more for academic reasons than for “real programming” — that is to say I would not be able to write a piece of useful software; well, this isn’t changed, anyway) and quite a lot of Perl (still I did not use to do what I considered “serious work”: a few cgi and some system scripting). But I’m going off topic.

One day one of my friends showed me the Powerbook G4 and MacOS X (it was Jaguar, for those who care). After some time I bought my first Mac with MacOS X. Before being a Linux user I was a big fan of MacOS Classic (and the first machine I installed GNU/Linux on was an iMac), so I was really happy with the “new deal” of Apple. Still I planned to “install GNU/Linux as soon as possible”. In fact this never happened (but one of this days when I have time and airport support is stable enough…).
The first thing I did was to learn Objective C. I took a look at Carbon, but I wasn’t amazed. I read Apple’s guides about the language. They were clear and well done. Still to code GUI applications I needed a more detailed book (I’m kind of a perfectionist) since the Tutorial, although well done, is designed for absolute beginners. Anyway the Apple guide for the language ObjectiveC is here.

I still have no idea why I chose to learn it. In fact I was a “cross-platform gui”. I still thought I would use both systems, so having my own applications on both of them was probably quite desirable. Moreover the QT MacOS port was young (it was released a couple of months after I bought the Mac, IIRC).
In the same period I was learning Python too, and almost everything else (system tools, web sites, cross platform gui applications with awful Tk) was made with it. I found some similarities between the two languages (in fact I think they were more similarities between Python and Smalltalk, and only indirectly between Python and ObjectiveC). Still one thing was different. Python is a very high level language, but does not force you in anyway into some kind of framework.

In fact you can perfectly “translate” command line from C using the same POSIX APIs or, for example, “convert” a Qt + C++ program. The language Objective C in fact has the same properties. In fact I wrote a few command line utilities and found that the Foundation kit was a well designed environment that abstracted some POSIX interfaces. I quite liked it. And quite liked ObjectiveC.

The only thing I truly missed were namespaces (or analogue things). I spend a couple of days understanding the memory model and that was everything. I bought two books, “Cocoa in a Nutshell” (today I would not buy this) and “Cocoa Programming” by Anguish Buck and Yacktman. They were both good books. I do not use the Nutshell because Apple documentation is more recent today, not because it’s not well done.
“Cocoa Programming” is a “big” book. There are lots of infos. Some of them are advanced topics (for example there are Chapters about optimizations — you know, optimization hinders evolutions, but we want to run our software on something more portable than a mainframe).

The book focuses on how Cocoa was thought with Design Patterns (expecially those from the famous book), even if they change their name (and Anguish/Buck/Yacktman show which Cocoa pattern corresponds to a GOF pattern). I was already acquainted with DP, I read the “Design Patterns: EORSD” some time ago (and recently I bought the book and I’m reading it again). In fact Cocoa developing needs understanding of design patterns, but you can have a less theoretical approach to Cocoa.

I recently read Hillegass’s “Cocoa Programming for MacOS X” and that is what I mean. It’s more like a tutorial, but not as elementar as Apple one. It shows you some “real life” small applications that use key tecnologies. It shows Cocoa structure, main “patterns” (for example how to deal with a NSTableView — and introduces the concept of delegation).
While “Cocoa Programming” shows how much Cocoa can be powerful, Hillegass shows how much Cocoa is easy. There are many things that are not explained in the latter (even if it covers some topics I didn’t find in the other book).

You may need (you probably need) a book like Anguish/Buck/Yacktman’s “Cocoa Programming“, but I strongly advise to start with “Cocoa Programming for MacOS X“. It’s not recent, but it’s well done and complete. You can build a whole lot of applications reading it, and for example explains the Document Based Applications in a very simple yet complete way (for example in “Cocoa Programming” the authors implement classes that act quite like the NSDocument and friends to show you in details how it works, still I was not really able to understand how easy it is programming Doc-based apps with Cocoa; in fact I thought it was hard, since many explanation about how the “true” class works are embedded in the explanation of how to rewrite a subset of it.
Another reason for reading “Cocoa Programming for MacOS X” is its length. Much shorter than the other one, you can read it in less than a week, and dive into programming with more skills. Some useful subjects in “Cocoa Programming” are not at the beginning and you must already know you have to skip chapters and go and read them.
In fact I find the two books complement each other well. I’ve got a third book (well a fourth), but I’m not gonna speak about it this time.

1. “Cocoa Programming” – Anguish/Buck/Yacktman
2. “Cocoa Programming” for MacOS X” – Hillegass

Apple PyObjC tutorial (Cocoa programming with Python)

This is Apple’s tutorial about programming Cocoa with Python. It’s an easy one, but read it if you want to start programming Cocoa with Python. It is quite well done.

Here PyObjC website.

IBM Slows the Speed of Light

IBM Slows the Speed of Light: “dptalia writes ‘According to an article on ZDNet, IBM has come up with a way to slow light to 1/300 of its normal speed. While this has been done in laboratories before, IBM has found out how to do this using standard materials, which opens the possibility of mass production. This means that the dream of having optical based CPUs may be closer than previously thought.’ From the article: ‘When the optical conversion might start to occur is a matter of speculation. Luxtera has said it will start to commercially produce products in 2007. The computer industry, however, tends to move slowly when it comes to major overhauls of computer architecture. Several components will have to be developed before photons can replace electrons inside computers. A paper providing details on the chip will run in Nature on Wednesday.’“

(Via Slashdot.)

C89 and C++ comment: C++ is not a superset of C

In C89 comments are enclosed between /* and */. // is not standard, altought many compilers support it. However, you can force your compiler not to recognise it.
This is the key for the sequent hack: when compiled as C it prints 10, when compiled as C++, it prints 100.

#include <stdio.h>

int main(){
  int a = 100//**/10
    ;
  printf("%d\n", a);
  return 0;
}

How is that possible?

In particular expression 100//**/10 evaluates to “10”. /**/ is a comment and is not considered, so it remains 100/10 (remember that // is not a comment delimiter).

When compiling as a C++ file, everything after // is a comment, and so 100//**/10 evaluates to 100.

This does not work with C99 anymore. // comments are valid in C99.

How to force C89 mode

To force gcc to compile it as strict C89 use -pedantic -std=c89.
I chose to use the .c extension, since using .cc the compiler seems to force C++ compilation (unless you specify the language).
In fact when you compile a C++ file with gcc (ggc, not g++), it understands it is a C++ file and compiles it as a C++ file. However, you will see errors. They are not compiling errors, they are linking ones.
For example:


/usr/bin/ld: Undefined symbols:
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long) const

...
operator delete[](void*)
operator delete(void*)
operator new[](unsigned long)
operator new(unsigned long)
___cxa_allocate_exception
___cxa_begin_catch
___cxa_end_catch
___cxa_rethrow

___cxa_throw
___gxx_personality_v0
restFP
saveFP
collect2: ld returned 1 exit status