Archive for the ‘Mac’ Category

Whether to call [super mouseDown:] etc or not

From View Programming Guide : Handling Mouse Click and Dragging Events

Notice that the mouseDown: implementation in Listing 4-7 does not call the super implementation. The NSView class’s default implementation for the mouse handling events are inherited from NSResponder and pass the event up the responder chain for handling, bypassing the view in question entirely. Typically a custom NSView subclass should not call the super implementation of any of the mouse-event methods.

Once [super mouseDown:…] is called, mouseDragged: is not called. mouseMoved: can be still received by calling [[self window] setAcceptsMouseMovedEvents:YES]; though.

So, for custom views which needs to handle all details of mouse event, it’s better not to call super’s messages of NSResponder, in other words, mouseDown, mouseUp, mouseDragged, mouseMoved, etc.

There is different results obtained by different combination of acceptsFirstResponder, acceptsFirstMouse etc. So, when implementing mouse event handler, please consider situation thoroughly and test as many as cases you can imagine. ( Hmmmm… S/W engineers who are not considerate tend to think that they know everything and ignore general situation.. So, I wonder if this recommendation would be effective to them. )

Without creating help files using Doxygen/HeaderDoc, Xcode 5에선 자동으로 Quick Help에 코멘트를 보여줍니다.

“structured comments in your own source code are displayed in the quick help panel and in code completion popover views. Doxygen and HeaderDoc structured comments are supported formats.”

http://confusatory.org/post/63488534619/documentation-in-xcode-5

http://dadabeatnik.wordpress.com/2013/09/25/comment-docs-in-xcode-5/

Concurrent programming in OpenCL vs Grand Central Dispatch

http://stackoverflow.com/questions/21504053/concurrent-programming-in-opencl-vs-grand-central-dispatch

converting frame image data in CVImageBufferRef to PNG

This StackOverflow explains how to convert a video frame image in CVImageBufferRef to PNG through CIImage of Core Image and CGImageRef of Core Graphics.
Of course, it can be also changed to NSImage and do whatever you want there too.
(toll-free bridging between Core* and NS*.. :). But in this case, there are some more chores to do manually. )

http://stackoverflow.com/questions/4014396/converting-cvimagebufferref-to-png

Be careful about object ownership around NSOperation and NSOperationQueue

For recent years, Apple people concentrated more on iOS than Mac OS X.
So, during that period of time, I’ve noticed that the quality of SDK for OS X and its documentation got worse.

In the case of NSOperation and NSOperationQueue, actually it was announced before the iOS was announced as far as I remember.
However, at that time, they were implemented around pthread or NSThread to provide eaiser pattern for multithreaded programming under specific scenario. ( Although those serial and pipe-like working model is quite convenient in many circumstances, but not always still. If you need more sophisticated interaction among threads, etc, you still need implementation with pthread/NSThread. )

Here is one example.
Were they clear about object ownership for NSOperation ( and its child classes ) when it’s added into a queue?
For tasks like it’s just queued and quickly consumed and gone, it will not easy to catch a case where an instance of a concrete children classes of NSOperation is deallocated while it’s in a queue and being processed.

However, today I did noticed such a case. So, be careful about this thing.
Making a pattern around something looks cool. It may show yourself a very skillful developer. By glancing at that kind of code, people can think of you as such.
However, it’s only skin-deep.

OperationQueue, Operation and ownership

ADDED : According to the document of NSOperationQueue, it says for addOperation:

Parameters
operation
The operation object to be added to the queue. In memory-managed applications, this object is retained by the operation queue. In garbage-collected applications, the queue strongly references the operation object.

So, at least it’s said to retain the operation. But be careful about it.

When calling boost methods causes EXC_BAD_ACCESS ( boost from Mac Port)

I ran into a weird problem.
Whatever simple boost method I call, it raised EXC_BAD_ACCESS exception. So, I tried to make a really short and simple project with which I can focus on this boost issue other than any other issues.

Why boost crashes

( Hmm.. when was my last time to use “target” instead of creating a sub project for having multiple projects under one project/workspace file? They have their own use, but for flexibility of using projects in other projects, “projects” looks better than “target”, but “target” has its own use. )

As we know, LLVM uses libc++ instead of libstdc++. So, if you create an C++/Objective-C++ project, it will use libc++ by default.

However, let’s take a look at what libraries boost libraries depend on. ( Boost is usually called header-only library. But there are ‘libraries’, really. )

JongAms-MacBookPro:lib jongp$ otool -L libboost_system-mt.dylib
libboost_system-mt.dylib:
/opt/local/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
JongAms-MacBookPro:lib jongp$ otool -L libboost_filesystem-mt.dylib
libboost_filesystem-mt.dylib:
/opt/local/lib/libboost_filesystem-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
JongAms-MacBookPro:lib jongp$

So, those boost libaries depends on libstdc++ not libc++.

Now, you have a clue.
If you change the C++ standard library to use from libc++ to libstdc++, it will not have the problem.

Finally.. it’s coming!!!!! Beyond Compare for Mac!!!

This is my favorite compare & merge tool since early 1990’s.It had the most intelligent comparison algorithm allowing shifted code block matching. It showed differences within a line also.

Now, finally it is coming to Mac.
Don’t need to rely on Apple’s merge tool, which can’t handle sophisticated situation or any other comparison tool available on Mac!

Let’s try!

http://www.scootersoftware.com/support.php?zz=kb_mac

libiconv from MacPort and OS X framework

Somehow libiconv has given me lots of headache since I knew its existence.

Today, I ran into a problem with it. (again!)
Although I linked libiconv from OS X framework and included its header files, it complaint in building.

It somehow said there is no _iconv, _iconv_open and _iconv_close defined.
I wonder why and started to think that it may somehow confused with the libconv from MacPort.
Since I’ve used Unix, which is late 80’s, I had questions on libiconv and others. There are libraries of which official page say that the latest version is 1.4.2, for example. But strangely on my Linux machine or Sun machine I used, there are lib<the_library>.2.x.x.a or lib<the_library>.2.so.
Where the 2.x version comes from?

It’s also same with libiconv. The official page says its latest version is 1.14, but somehow Mac OS X has libiconv.2.dylib.
Header files are a little different. But they are anyway the same, iconv, iconv_open and iconv_close.
Then it should be able to find it.

However, this is what’s there.

symbols in libiconv from MacPort
JongAms-MacBookPro:opt jongp$ nm -a local/lib/libiconv.2.dylib | grep iconv
00000000000f90c0 D __libiconv_version
0000000000003000 T _iconv_canonicalize
0000000000002760 T _libiconv
0000000000002790 T _libiconv_close
0000000000001350 T _libiconv_open
00000000000027a0 T _libiconv_open_into
0000000000017980 t _libiconv_relocate
00000000000fa7a8 b _libiconv_relocate.initialized.b
00000000000178c0 T _libiconv_set_relocation_prefix
0000000000002cc0 T _libiconvctl
0000000000002dd0 T _libiconvlist
symbols in libiconv from OS X framework
JongAms-MacBookPro:opt jongp$ nm -a /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/libiconv.2.dylib  | grep iconv
00000000000f26c0 S ___iconv_2VersionNumber
00000000000f2690 S ___iconv_2VersionString
00000000000f60f0 D __libiconv_version
0000000000002f1f T _iconv
000000000000325d T _iconv_canonicalize
0000000000002f41 T _iconv_close
0000000000001c59 T _iconv_open
0000000000002f4e T _iconvctl
0000000000003064 T _iconvlist
00000000000158e2 T _libiconv_relocate
000000000001582d T _libiconv_set_relocation_prefix

It’s very odd.
Anyway, although the /opt/local/lib, the library path of MacPort is included in the library search path in my Xcode project, but what is actually linked by adding explicitly using Link Binary with Libraries phase of Xcode target project was the one from OS X framework.
Then Xcode should try to link with the version instead of the one from Mac Port.

However, in the messages, it just linked with this option : -liconv.2.
But it couldn’t . Somehow the libiconv from Mac Port still preventd the linkage. (again, MacPort version is not 2, but 1.x )
So, I had to remove /opt/local/lib. Then it linked without a problem.

It’s odd that why there are two different versions on Internet. But even though it is if the library is set to be linked using Xcode “Link Binary with Library”, shouldn’t Xcode or its linker abide by that specific one more strictly? It should try to link the libraries set to be linked such way first.

Geocoding “Service” for Mac

Oh.. If you need to use “geocode” often, this tip will be quite useful.

http://oleb.net/blog/2014/01/geocoding-automator-service/

 

iOS의 피해자, Core Data 그리고 개발 용이성대 유지 및 관리 용이성 등에 대한 단상

아무래도 영어가 내 모국어가 아니어서 그런가… 필요해서 읽는게 아닌 경우엔, 좀 모호하다가, 필요해서 읽으면 그제서야 의미가 몸에 와 닿는다.
CoreData..
이 회사에 오기 전엔 쓰지 않았고, 쓸 필요도 없었고, 가능하면 쓰려고 하지 않았다. 왜냐하면 Cocoa Binding에 기반한 이런 기술은 일단 문제가 생기면 어디서 버그가 생겼는지 (만든 사람 빼곤) 알기가 힘들고, 데이터 로딩 타임이 원할 때 되지 않을경우 제어가 좀 힘들어질 수도 있는 등 여러가지 문제가 있기 때문이다.

아무튼 Object Graph가 뭔진 알아도 감각적으로 몸에 딱 스며들진 않았는데, 이제 필요에 의해서 코딩을 하게 되니 그냥 막 몸에 스며든다.
Object Graph가 뭔지에 대한 설명이, 애플도 그렇고 다른 데도 그렇고 뭐 그리 감각적으로 알 수 있게 되어 있지 않은지.
그리고선 CoreData는 DBMS가 아니라는 소리들만 잔뜩하고…

근데 iOS가 인기가 생김에 따라 Core Data도 타격이 컸구나. 분명 몇년전에 NeXIO 관련 프로그램들을 만들땐, MySQL용 Core Data connector library가 분명 있었고, PostgreSQL도 한 두어가지 있었는데, 이젠 다 없어졌다. 그냥 C/C++ library를 이용해서 수동으로 연결하라 이거지.
뭐 그것도 좋다. 솔직히 내가 더 선호하는 방식.
앞서 이야기했듯이 Core Data로 만들 경우, 이런 저런 문제가 있기에…

작성시에 쉬운 것 (Cocoa Binding/Core Data) vs. 유지/관리가 쉬운 것을 택하라면 난 후자를 택한다.

근데 iOS 때문에, 흥미로운 기술들이 많이 죽거나, 어중간한 선에서 그냥 구현되어 나오는 것을 많이 보네…
Resolution Independence
AV Foundation
DashCode
그 밖의 이런 저런 것들

%d bloggers like this: