The new old sign

Juxtaposition of new and old signs

The station name:

First class compartment:

Exit number (in Hung Hom station where you need to use different escalator for different exit):

What kind of university is this? (rant)

I'd hate to say, but what kind of University is this? I got my umbrella stolen again! F***!

<rant>

I really got irritated about these kind of things. An umbrella is not expensive, but I expect people in the university would be well-mannered to respect the property of others. I used to think university was a safe place, I would place books on the table in canteen when I got out to order food, but this naive thinking got shattered when a medicine - you are correct, MEDICINE!! - student stole my book (well technically it is library's book) in Chung Chi Tang. How on hell can I place my trust on a doctor which stole others' book!? Surely he'd got the best results academically to get into Chung Chi College and the Faculty of Medicine, but go to hell with his morality. Personally I do not regard books (esp. those from library) would be a tempting target for thefts (books have low resale value after all), but I was (literally) shocked when that happened on me one year ago.

These happens to postgraduate students as well. I tried to be less racism here and *may be* this is a cultural difference - just go to *ANY* postgraduate hall and you will see all kinds of shocking things, and forget about the rumors about the manners of these "well-educated" people. Personally I don't care about what their room looks like (my room is untidy), but please f**king h*ll keep the public area clean. I think EMO really did a great job in keeping the hostel from deteriorating but ***please*** think twice before you put all kind of food stuff into the sink. I have seen all kind of stuff blocking the drainage in the pantry sink - grapes (that is last night), rice (yuck... how difficult and disgusting to clean!), noodles (WTF!?), and the worst of all - chicken ring bones. Hell the freaking rubbish bin is *JUST RIGHT NEXT* to the sink (within 2 meters). I really don't know what kind of **POSTGRADUATE** students we have in CUHK. Also don't forget about those [NO SPITTING] signs - they are here for a good reason - People DO spit in washing basin... Ugh... how disgusting. We are not in kindergarten man...

The morale of the story: Don't automatically assume university students (even the postgraduates) are "better" than average person you found in Mong Kok. So pathetic huh?

</rant>

Porting NPVR to Mac OS X, Part II

Amazingly I have ported 95% of NPVR to OS X in less than a week. The missing bits are the PlatformService and ShaderTuner plugins, which have not been ported yet as they contain a little bit of Win32 codes in it.

TODO:

1. Cocoa version of PlatformService: 2 hours
2. Cocoa version of ShaderTuner: 6 hours
3. Implement ToggleMenuItem using GLUT in murex: 2 hours
4. Implement dialogs using Cocoa in murex: 3 hours

I hope to write more about the things I learnt when porting the program to OS X a bit later. I have also compiled a universal binary of the GLEW library, and I will post it (probably with the framework bundle) once I have more time in hand.

Porting NPVR to Mac OS X, Part I

I got this after a long struggle and head banging with sharing Makefile between OS X (gcc) and Windows (MSVC). This error means that I have ported the plugin system to OS X. Surprisingly the OS X (and other POSIX systems?)'s dlopen()/dlsym()/dlclose() are very much similar to the Win32 LoadLibrary()/GetProcAddress()/FreeLibrary() calls.

./framework.out 
Loading plugin 'GLUserInterface.dyld' ... done. 
Initializing plugin 'GLUserInterface.dyld' ...kCGErrorRangeCheck : Window Server communications from outside of session allowed for root and console user only
INIT_Processeses(), could not establish the default connection to the WindowServer.Abort

Note: The error occurs because I am running this through SSH, and I hope to get a screenshot tomorrow when I sit in front of the iMac. :)

Porting Murex to Mac OS X, Part II

Done.

This thread helped me to compile universal binary of Boost 1.35.0. Probably I would see if they can be packed in a framework and upload it later.

Murex had been ported to Mac OS X in Universal Binary! (Screenshot later) As I have expected porting to OS X helped me to iron out a few bugs/glitches.

libmurex-glut.a: Mach-O universal binary with 2 architectures
libmurex-glut.a (for architecture ppc): current ar archive random library
libmurex-glut.a (for architecture i386): current ar archive random library
libmurex.a:      Mach-O universal binary with 2 architectures
libmurex.a (for architecture ppc): current ar archive
libmurex.a (for architecture i386): current ar archive

Finally I have begun to port the plugin system to OS X. The plugins would be in the dylib format and the dl*() functions can be used to load/unload them. The estimated time ahead to complete porting the plugin system is one afternoon.

The final milestone is to port the ShaderTuner plugin with the custom Win32 sliders to Carbon/Cocoa.

That's all for today and all of my energy had drained away.

Porting Murex to Mac OS X, Part I

Finally I have set out to port Murex (the name of my home-brew cross platform GUI library) to Mac OS X. I still want to stick with GNU make and therefore I have tried to modify the make file to make it work on OS X. Here is the results after a lot of hard work and head scratching.

Also it seems like compiling static library is possible but not-quite-supported in OS X. May be I would abandon the idea of having a static library.

$ make -f Makefile.mac 
g++ -dynamiclib -framework GLUT -framework OpenGL bin/murex.lib -o bin/murex-glut.lib bin/murex-glut/GLUTEngine.obj bin/murex-glut/GLApplication.obj bin/murex-glut/GLFactory.obj bin/murex-glut/GLMenu.obj bin/murex-glut/GLTimer.obj bin/murex-glut/GLWindow.obj
ld: Undefined symbols:
__ZN5boost7signals10connectionD1Ev
__ZN5boost7signals6detail11signal_baseC2ERKNS_9function2IbNS1_12stored_groupES4_SaINS_13function_baseEEEERKNS_3anyE
__ZN5boost7signals6detail11signal_baseD2Ev
__ZN5boost7signals6detail14named_slot_map3endEv
__ZN5boost7signals6detail14named_slot_map5beginEv
__ZN5boost7signals6detail16signal_base_impl12connect_slotERKNS_3anyERKNS1_12stored_groupENS_10shared_ptrINS1_9slot_base6data_tEEENS0_16connect_positionE
__ZN5boost7signals6detail17call_notificationC1ERKNS_10shared_ptrINS1_16signal_base_implEEE
__ZN5boost7signals6detail17call_notificationD1Ev
__ZN5boost7signals6detail9slot_base17create_connectionEv
__ZN5boost7signals9trackableD2Ev
/usr/bin/libtool: internal link edit command failed
make: *** [bin/murex-glut.lib] Error 1

Nice error, isn't it? Next milestone: compiles the required boost library (preferably in Universal Binary) on OS X.

After some struggling I have decided to drop my porting effort and go to EKS rehearsal. I was very happy today, except that Johnny and Kenneth didn't have dinner with us!

Eat my own dog food

I have finally set out to "revert" up some of my stupid C++ code written long ago, and I would show case two of my stupid-ness here.

#define SHARED_PTR boost::shared_ptr

This is real. I don't know what the hack I was thinking while writing this line of code. The whole header file is reproduced here in its entirety to celebrate its removal.

#ifndef _HANDLE_HPP
#define _HANDLE_HPP

#include "boost/shared_ptr.hpp"
#define SHARED_PTR boost::shared_ptr

#endif /* _HANDLE_HPP */

WTF!?

PS: Probably I was thinking that the file is for "easier" transition to std::shared_ptr once it C++0x is released, but I think everybody would think otherwise.

Favor forward declaration over #include

In short I have been convinced that I should use forward declaration when ever possible.

Cocoa Masochism

Is is official! A new form of masochism is found and will be included in the upcoming DSM-V.

After downloading the Nibless Leopard Cocoa application from this (very) smart guy I was disappointed to know that there is a file (or more accurately a directory) named "NiblessLeopard.xcodeproj" in the zip archive. In order to fulfill my masochism I have decided to take this further to remove the dependency on XCode, and after some struggling I am pleased to announce the release of these two files.

• Makefile
• MakeBundle

You would be able to "make" your first Nib-less + XCode-less Cocoa application after downloading NiblessLeopard.zip and these two files, together with some undocumented (who would think of writing documentation during hacking?) changes to the files.

This marks the beginning of my masochistic Objective-C/C++ and Cocoa voyage.