Archive for the ‘Programming’ Category

How to develop augmented reality apps with Vuforia for Windows 10

Dripcap – Caffeinated Packet Analyser and…

Probably Wireshark is too much, it can be good to try this elegant packet analyser, Dripcap. It’s made of a web app framework called Electron. It can be good to know that. Nowadays I don’t hear much about Ember and so on. Lots of Web frameworks are on people’s mouth and gone so quickly so…


libiconv from OS X and Mac Port, and change of Xcode behavior

I have an old project for converting wrongly encoded Korean to properly encode to properly encoded one in mp3 files.

However due to file system corruption while in upgrading to OS X 10.11.6,  I had to rebuild the project again. I found out that I had another project for the same purpose to use different ID3 library. I didn’t remember which project was correct one.

I finally identified the correct one, but had some issues. It was built previously without a problem, but it failed this time. It could be due to changes in Xcode. Yes. there is such change. I will talk about that after taking about difference of libiconv from OS X and Mac Port.

When tried to build, it complaint _iconv, _iconv_open, _iconv_close were missing.
I recalled that there was difference between libiconv from OS X and Mac Port, and there was a comment I wrote for that, but didn’t remember its detailed reasoning for that.

So, I googled and found the stack overflow question above, and it made me recall what problem it had completely.

So,  this time I would like to record it here.

This is the result with libiconv from Mac Port.

JongAms-Mac-mini:lib jongampark$ nm -m  libiconv.2.dylib | grep iconv

0000000000002db1 (__TEXT,__text) external _libiconv
0000000000002dd3 (__TEXT,__text) external _libiconv_close
000000000000158c (__TEXT,__text) external _libiconv_open

This is the result with libiconv from OS X.

JongAms-Mac-mini:lib jongampark$ nm -m /usr/lib/libiconv.dylib | grep iconv

000000000000301c (__TEXT,__text) external _iconv
000000000000336d (__TEXT,__text) external _iconv_canonicalize
000000000000303e (__TEXT,__text) external _iconv_close
0000000000001c41 (__TEXT,__text) external _iconv_open

So, the difference is that the ones from Mac Port have _lib is prefixed while the ones from OS X don’t.

Also, the included iconv.h file should match with the library file.

Finally I would like to talk about the changes of Xcode behavior.

With a version of 7.x.x, Apple changed that default libraries and header files could be searched without specifying them. Especially, if a library, for example, /usr/lib/libiconv.dylib is linked using the build phase, Xcode didn’t require the /usr/lib is added to the library search path. It was new behavior at that time.

However, they changed it again from some version of Xcode later than the version mentioned above. So, the library path should be set to include /usr/lib.
Without that, even though the /usr/lib/libiconv.dylib is linked by build phase setting (Link Binary with libraries ), Xcode couldn’t find that it’s in /usr/lib.

Apple doesn’t document this kind of changes, and it gives headache.
I wonder why Apple keeps changing from one behavior to the other behavior from time to time. If they keep changing to a newer behavior, it could be understandable, although I don’t like it. However, they are kind of going forward and backward.

This is small difference, but can affect big way.
Apple should document this kind thing and handle this seriously.

How to use Apple’s Unicode Hex Input IME

It’s explained here, but ‘how to use’ is buried in the long text without indentation etc.

So, here.

  1. To type U+03B1, press the “Option” key.
  2. press 0, 3, B, 1 while still pressing the “Option” key.


When both ‘true’ and ‘false’ are right

I ran into very interesting logic issue. Probably if someone asks me what case it was, then I would not be able to recall this, because it’s subtle ( but simple ).

bool vaFacebookAPI::HandleResponse(zuint32 what, zRecord *record, zRecord *current, zRecord *previous)
    bool isHandled = true;

    if (record == nullptr || current == nullptr) {

        // You can think of this as 'handled' or 'not handled' depending on
        // how you think. But architecturally it should be treated as 'not handled'
        return false; // 👈🏼 This case 


1. You can think that it can return ‘true’, because such case is considered and you decided not to do anything. So, It’s handled as such. So, it’s right to be ‘true’.

2. You can think it it can return ‘false’, because for that case nothing is processed and just returns. So, you can regard it as ‘not handled’. So, ‘false’ is correct.

Interesting, isn’t it?
One logic, depending on how you think it can be thought as ‘true’ and ‘false’

So, true is true, and false is also true. 😉

deprecation of C++ style for loop and its replacements are…

New Features in Swift 2.2

Swift… 이거 참..
Telestream에서 일을 한 이래, 제대로 Objective-C/Cocoa에서 새로 나오는 것을 시도하거나, 심지어 Swift를 공부할 짬이 없었다. C#/.NET이나 C++도 마찬가지…
이전 회사들에선 퇴근하고서도 당연히 했고, 회사 내에서도 할 일 다하고, 추가로 더 알아보곤 했는데, 도대체 이 회사에선…
Cocoa에 대해서 알고 있던 것도 까먹고. 그래서들 미국 애들이 이런 회사에 지원을 안하나보다.

아무튼 투덜대는 것은 이만하고..
난  Swift가 도대체 마음에 들지 않는다.
Swift가 후져서가 아니라, 이건 순전히 마케팅에 의한 것이란 생각이 들기 때문이다.
GNU의 Objective-C 컴파일러를 들춰본 사람들은 얼마나 간략하게 Objective-C가 만들어져 있는지 안다. C++쪽은 별 이상한 짓을 해서라도 기능을 추가하는데, 굳이 몇가지 Objective-C의 단점을 들춰서 그걸 Swift를 합리화하는 건 뭐하지 않나? 문제가 있으면 고치면 되지 않나?

더군다나 Swift는 헷갈리는 면이 많다. 새로 언어를 배우는 어린 학생들이야 모르겠지만, 내겐 이 Swift는 어떤 면에선 Pascal, 어디선 C, 어디선 Perl 같은 느낌이 든다. Python을 하는 사람들은 Python 같은 부분도 있다고 한다.
일단 모드가 Pascal 모드로 바뀌면 Pascal 다워야 하고, C로 바뀌면 C 다워야 한다. 그래야 기억하기도 좋고 그렇지. 이건 순전히 잡탕같은 느낌이어서, 간만에 Swift 문서를 읽어서 익혀 두어도 나중에 기억이 잘 안난다. 왜? 파스칼 같으면 쭉 파스칼 같아야 하는데, 어느 순간 Perl 같다거나 그런식이기 때문이다.

그리고 2.2에서 새로 나온 문법을 보자.
다음의 코드를 보자

for var i = 0; i &lt; 10; i++ {

이걸 이제 없애고 다음과 같이 바꾼다 한다.

for i in 0 .. &lt; 10 {

이까진 좋다. Fast Enumeration 스타일이니까.

근데, 다음을 보자.

for i in (1...10).reverse() {

for i in 0.stride(to: 10, by: 2) {

저거 그냥 (10…1)로 못 만드나? 물론 reverse()도 지원하면서?
뭐 첫번재 예는 그렇다치자.
두번재 예..

저거.. 영어가 모국어인 사람은 0.stride(to..)가 와 닿을지 몰라도, 외국인들에겐 그렇지 않다. stride의 뜻이 그다지 강하게 다가오지 않기 때문이다.
단어의 뜻을 아는 것과, 그것이 얼마나 강하게 다가오느냐는 다른 문제이다.
Apple의 사전 앱에서 뜻을 보자.
1. 성큼 성큼 걷기. 활보
2. 한걸음, 한달음.

아.. 안다가온다.
이런게 낫지 않나?

for i in 0.increment(to: 10, by: 2) {

for i in 0.increment(to: 10, by: -2) {

두번째 것은 다음과 같은 동일 표현을 가질 수 있겠다.

for i in 10.decrement(to: 0, by: 2) {

Swift는 컴퓨터 언어에서의 cultural difference와 사람이 쓰는 언어에서의 cultural difference를 고려하지 않고 디자인되는 느낌이다.
이건 문제다. 그리고 내가 Swift를 좋아하지 않는 문제 중의 하나이다.



Well, it will be interesting to read the post.
Knowing such things are good and beneficial, but not always.








He said “No.”
Damn.. then he must be clear on that.

What the..

%d bloggers like this: