Windows에서 libssh2를 MinGW로 빌드하기

cmake를 사용하는 libssh와는 달리, libssh2는 Windows에서 리눅스와 같은 환경에서 프로그램을 컴파일하기를 요구합니다-이를테면 MSYS같은게 필요하죠. 인터넷에 보면 libssh2를 빌드하는 많은 방법들이 있습니다만, 이들 중 상당수는 소스코드나 빌드파일을 어느 정도까지는 스스로 고쳐야 합니다.

그래서…… 평소 성향대로, 이 포스팅에서는 좀 반대로 가려고 합니다.소스코드에 손대지 않고 빌드하는 방법을 소개합니다.

준비물은 아래와 같습니다:

1. MSYS
2. MinGW-w64 기반 빌드가 필요합니다. 제가 테스트한 환경은 두 군데입니다: MinGW-builds 64bit-winthreads-SEH exception build와 TDM-GCC 64bi
3. 물론, libssh2의 소스코드도 필요합니다. :P

빌드는 다음 순서대로 진행합니다:

1. 소스코드 압축을 해제합니다.
2. 가장 중요한 단계입니다: configure에서 OpenSSL과 OpenSSL이 의존하는 Win32 라이브러리를 강제로 참조하도록 합니다. 이를테면 이런 식입니다:
   ./configure –with-libs-prefix=“/d/Components/openssl” –with-libssl-prefix=“/d/Components/z"  LDFLAGS=”-L/d/Components/openssl/lib -lssl -l crypto -lgdi32 -lws2_32"
3. [Optional] 만일 64비트로 빌드해야 한다면 –build=amd64를 LDFLAGS 이전에 삽입해주세요. 이런 요령으로 하시면 됩니다:
   ./configure –with-libs-prefix=“/d/Components/openssl” –with-libssl-prefix=“/d/Components/z” –build=amd64 LDFLAGS=“-L/d/Components/openssl/lib -lssl -l crypto -lgdi32 -lws2_32”
4. make 실행후 모니터를 감상해주세요. :)
5. 빌드 끝!

별건 아닙니다만, 이 글이 libssh2를 손수 빌드하려는 길잃은 양(……)들께 도움이 되셨으면 합니다.

Compiling libssh2 in Windows with MinGW-builds

Unlike libssh, which uses cmake, libssh2 forces you to use Linux-like environment even in Windows, which eventually makes you to install MSYS on your system. You can find many ways are to build libssh2 in Windows on the net, but most of them requires you to manually edit configuration files in some way.

OK, here goes the opposite…… You’ll NOT MAKE ANY CHANGES in the source code.

First, the requirements:

1. MSYS
2. MinGW-w64 based build. I used two variants: MinGW-builds 64bit-winthreads-SEH exception build, but TDM-GCC 64bit also works
3. libssh2 source codes(of course! :P)

And the procedure:

1. Decompress the source code.
2. The most important step: force to add OpenSSL and Win32 libraries OpenSSL needs on configure step, something like this:
   ./configure –with-libs-prefix=“/d/Components/openssl” –with-libssl-prefix=“/d/Components/z” LDFLAGS=“-L/d/Components/openssl/lib -lssl -l crypto -lgdi32 -lws2_32”
3. [Optional] If you’re building 64bit binary, dont forget to add –build=amd64 before LDFLAGS, like this:
   ./configure –with-libs-prefix=“/d/Components/openssl” –with-libssl-prefix=“/d/Components/z” –build=amd64 LDFLAGS=“-L/d/Components/openssl/lib -lssl -l crypto -lgdi32 -lws2_32”
4. run make and enjoy. :)
5. PROFIT!

Hope this helps some lost sheeps who want to build libssh2 in his/her own.

Building cURL under MinGW-w64 with zlib and SSL support under Windows

It’s simple:
mingw32-make mingw32-winssl-zlib

Do not use OpenSSL. Substitute it with Windows native SSL support. I have no idea on why but it seems to be related to linker.

Windows에서 MinGW-w64로 zlib와 SSL이 지원되는 cURL 빌드하기

간단합니다:
mingw32-make mingw32-winssl-zlib

핵심은 OpenSSL을 사용하지 않는 대신 Windows의 native SSL 지원으로 바꾸는 겁니다. 이유는 잘 모르겠지만 linker에서 뭔가가 잘못된 것 같더군요.

Qt야 Qt야 요즘 왜그러니......

1. MinGW library를 static으로 설정하는 부분을 pri 파일로 만들어두고 include했는데 적용이 안됨
2. configure에 분명 -static 옵션을 붙였는데 DLL을 생성하는걸로 모자라pro파일에 CONFIG=static이라고 넣어줬는데도 dynamic으로 링크함

Qt야 Qt야 너 왜이러니.

뭐 잘못 먹었니……

Lazarus+Firebird+ZeosDBO: Cannot read files in Hangul

When connecting to Firebird using ZeosDBO in Lazarus, if the filename contains Hangul(Korean), the database file cannot be read. Using UTF8ToSys() or Utf8ToAnsi() was of no use. The error occurs when Firebird calls CreateFile(open), though with TIBConnection the file can be read if I apply UTF8ToSys() to DatabaseName.

I liked ZeosDBO as it seems faster that TSQLConection, but now is the time to turn off autocommit and manually do it. Well, considering the origin(a component for Delphi), support for Lazarus is ought to be limited.

Found in following environment:
Lazarus 1.2.4, ZeosDBO 7.1.3a, Firebird 2.5

P.S:Considering the case, the same would happen to files with Chinese or Japanese characters in the name. Pity to CJK users!(including me)

Lazarus+Firebird+ZeosDBO: 한글 파일명 읽기 불가능

Lazarus에서 ZeosDBO를 사용해서 Firebird에 접속할때 파일명이 한글로 되어있으면 파일을 읽지 못하는 문제가 있습니다. UTF8ToSys()나 UTF8ToAnsi()를 사용해도 마찬가지였습니다. 정확히는 Firebird가 파일을 읽기 위해 CreateFile(open)을 호출할때 오류를 일으킵니다. 하지만 TIBConnection은 DatabaseName에 UTF8ToSys()를 적용해주면 정상적으로 동작하더군요.

ZeosDBO가 TSQLConnection보다 속도가 빨라서 좋아했는데, 이젠 TIBConnection에서 autocommit 끄고 돌린 다음에 수동으로 commit하는게 나을 것 같습니다. 아무래도 델파이용으로 만들어진 컴포넌트다보니 Lazarus 지원은 썩 좋지 않은 듯 하네요.

Lazarus 1.2.4, ZeosDBO 7.1.3a, Firebird 2.5에서 확인했습니다.

First Impression after Third Attempt for wxWidgets

wxWidgets is like….. awkward and inconvenient to use. I think now I know why so many projects are moving from wxWidgets to Qt.

As determining to go with Qt for big projects and go with Lazarus for small projects from now on.

Qt에 대한 단상 몇가지

1. 바이너리 크기가 생각보다 큽니다: Qt Quick Controls 기반의 GUI 프로그램을 만들려면 이정도는 갖고 있어야 합니다:

• Qt DLL(22MB: Core, GUI, Network, QML, Quick, Widgets)
• ICU(26MB)
• Qt Quick Controls QMLs and support DLLs(20MB)
• 그리고 기타 필요한 것들

뭐 이쯤 되면 DLL hell은 당연히 열리고도 남게 마련입니다. 특히 Qt Quick Control을 쓰게 된다면요. ;)
몇몇 기능을 제거하면 프로그램 크기를 줄일 수는 있겠지만, 가장 간단한 “hello world”급 프로그램을 띄우는데만 해도 15~20MB정도가 필요합니다. 몇몇 경우, 특히 간단한 업무용 프로그램용으로는 배보다 배꼽이 더 큰 경우가 발생하기도 하죠(파일 의존성 관리라던가, 유지보수라던가……).

2. 상용 라이선스 구매자들에 대한 혜택 증가: 이를테면 Qt Quick Charts나 Qt QML compiler같은 것들이 예시가 될 수 있겠습니다. 물론 상용 라이선스 구매자들에게 더 좋은 서비스를 제공하는 것은 당연한 일입니다만, 물론 Digia가 Qt의 개발에 꽤 괜찮은 성과를 보이고 있긴 하지만, 때로는 너무 돈 낸 사람들만 신경쓰고, 오픈소스 커뮤니티는 홀대하는 건 아닌가 하는 생각도 듭니다.

3. Digia는 Qt 프로젝트에서는 꽤 좋은 성과를 보여주고 있지만, 재무상태가 생각보다 썩 좋은 것 같진 않습니다. 이 포스팅(http://worldcadaccess.typepad.com/blog/2011/03/nokia-sells-qt-cad-vendors-hearts-go-pitter-patter.html)과 회사의 재무현황 지표를 참고해보세요(http://www.digia.com/en/Company/Investors/Financials/Key-Figures-Monitor/).

4. Model-Delegate-View Framework는 생각보다 손이 많이 갑니다: Qt의 model-delegate-view framework는 QAbstractItemModel의 사용을 강제하는 경향이 있고, 이 모델은 구조상 복잡성 때문에 간단한 데이터 표시용으로 쓰기에는 너무 복잡한 경향이 있습니다. 데이터 추출이나 가공이 복잡하다면 이 프레임워크는 꽤 유용한 도구와 인터페이스지만, 대부분의 경우 저는 LCL(Lazarus Component Library)에 있는 TStringGrid가 그리워지더군요.

5. Qt Quick Controls는 아무리 봐도 뜨거운 감자일 뿐: Qt Quick은 위대한 기술입니다. Qt Quick Controls는 widget처럼 생긴 화면을 Qt Quick 위에서 사용할 수 있게 해주는 또다른 기술개발의 결정체입니다. 문제라면…… 라이브러리가 너무 크고, Qt Quick의 JIT 컴파일러 기동때문에 시작이 늦고, Digia가 꽤 여러가지로 신경을 쓰긴 했지만 C++쪽과의 통신도 그렇게 썩 매끄럽지는 않은 것 같습니다. 그렇다고 이걸 안 쓰자니 Qt Quick의 무한한 확장성을 버리는 꼴이 되고…… 최근 추가된 QQuickWidget이 이런 부분을 어느정도 상쇄해 주긴 하지만, 그렇다고 본질적인 문제가 완전히 해결되지는 않아 보입니다.

6. 기능-성능 tradeoff: Qt는 GUI 라이브러리가 아니라 응용프로그램 개발용 종합 프레임워크로 보는게 옳을 것입니다. Qt에는 프로그래머를 편하게 해주는 다양한 기능이 있지만, 이들 기능을 위해 성능을 희생하게 되는 경우를 종종 보게 됩니다. 저도 제가 직접 만든 linked list가 QLinkedList에 비해 5배 이상 빠르게 움직이는걸 경험했고, Google에서 잠깐만 검색해보시면 STL이 Qt보다 더 빠르다는 이야기를 쉽게 찾으실 수 있을겁니다.

Qt가 대단한 기술임을 부정하고 싶지는 않습니다. 저는 Qt를 매우 좋아하고, 지금도 수많은 프로젝트들이 Qt로 돌아서고 있습니다(특히나 wxWidgets에서 오시는 분들이 많더군요). 하지만 Qt를 선택하기 전에 몇몇 생각해봐야 할 부분이 있는 것 또한 현실입니다. 한 1년여 Qt를 특히나 최신버전 중심으로 사용해보니 몇몇 어두운 부분이 보이더군요.

저요? 전 가끔 제 생각에 ‘이건 아니다’ 싶으면 주류를 화끈하게 벗어나는 경향이 있고…… 그래서 전 이번에도 Qt에서 wxWidgets로 이전해 보려고 합니다. 제가 만든 단순한 프로그램들의 배포를 위해서 수십개 파일의 의존성을 관리하기에 저는 너무 게을러요. :(

Some thoughts about Qt nowadays

1. The size of the binary is too large: to open a GUI application with Qt Quick Controls, you should have

• Qt DLLs(22MB: Core, GUI, Network, QML, Quick, Widgets)
• ICU(26MB)
• Qt Quick Controls QMLs and support DLLs(20MB)
• And anything you want

And of course, the DLL dependency hell is open to you, especially if you use Qt Quick Controls. ;)
You can minimize the application size by deactivating some features but still it’s about 15~20MB for simple “hello world” application. Sometimes it’s too heavy to bring all the files for only simple tasks.

2. More benefits to commercial licensees: Qt Quick Charts, Qt QML compiler, and so on. It’s of course fair to give more to commercial licensees but I’m afraid their(Digia’s) efforts ar skewed too much to its customers, though I know that they did quite good job on developments of Qt.

3. The financial status of Digia seems not as good as its leadership in Qt project. Check this post(http://worldcadaccess.typepad.com/blog/2011/03/nokia-sells-qt-cad-vendors-hearts-go-pitter-patter.html) and the financial status of the company itself (http://www.digia.com/en/Company/Investors/Financials/Key-Figures-Monitor/).

4. Model-Deligate-View Framework, overcomplicated: the model-delegate-view framework of Qt seems to make the data represntation overcompilcated as it forces to use QAbstractItemModel deligates to display items. If the data gathering and manipulation is complicated the framework provides useful tools and interfaces to interact, yet most of the time I long for my beloved TStringGrid in LCL(Lazarus Component Library).

5. Qt Quick Controls, a hot potato: Qt Quick is a great technology and Qt Quick Controls is yet another great creation as programmers can make use of Qt Quick technology inside what seems to be the legacy widget-looking interfaces. Yet the size of support library is too big, startup is slow as Qt Quick JIT compiler needs some time to initialize, and it’s still a bit painful when communicating from/to C++ side though Digia did good job in interface handling. Of course you can use Qt Widgets but in this case you lose the unlimited extensibility and power Qt Quick has, though recently added QQuickWidget class complements things a bit.

6. Feature-performance tradeoff: Qt is not just yet another GUI library. It’s rather an application framework from the bottom. It has so many features which makes the programmer convenient, but to support many features it had to sacrifice some performance. Among my personal experiences, I found out my own linked list worked about five times faster than QLinkedList. Or, just google it and you can read so many articles that performance of STL is similar or better against Qt ones.

I don’t want to deny Qt is great technology. I really enjoy using Qt, and even now more and more projects turn to Qt(especially from wxWidgets), meaning there are more programmers who feels like me. But there are things you should consider when choosing Qt. I just wanted to describe some “dark side” stuff against Qt after using the technology for about one year or so, chasing the upstream.

My answer after all those situations? Sometimes I was against the mainstream if I think so. I’m moving from Qt to wxWidgets. I’m too lazy to manage tens of files for only simple applications I make.

Qt WebKit: 사라져가는 위대한 프로젝트를 바라보며

작년 11월에 Digia는 Qt WebEngine이라 불리는 새로운 프로젝트를 시작했습니다. Google의 Chromium에 기반한 이 프로젝트는 현재의 Qt WebKit을 대체할 목적으로 만들어졌습니다. 대부분의 사람들은 Chromium을 쉽게 자신들의 프로젝트에 도입할 수 있게 된다는 사실을 크게 반겼습니다. Digia는 Qt WebEngine이 Qt WebKit과 가능한 한 최대한 호환되도록 만들겠다고 약속하였고, 당대에서는 Nokia의 환경에서도 Digia가 꽤 좋은 평가를 받았던지라 많은 사람들이 그 약속을 믿었습니다.

지난주에 Qt WebEngine 팀이 새로운 블로그를 올렸고, 저는 그 글의 댓글에서 API에 대한 약간의 “불평”을 발견했습니다. 위키를 확인해본 결과, 제가 web crawler 개발에 사용하는 핵심 기능인 QWebElement는 사용 불가로 낙인이 찍혀 있더군요 - 위키에 따르면, Chromium 자체가 멀티프로세스 기반이다보니 이 기능 자체가 비동기적으로 구성되어야 하는데, Qt WebEngine의 디자인은 동기화 구성이 기본이라 더이상 지원하지 않는다고 합니다.

QWebElement뿐만이 아닙니다. 제가 컨텐츠의 정상 여부를 활용하는데 사용하는 QNetworkAccessManager도 사용되지 않습니다. Qt WebEngine은 Chromium의 자체 네트워크 스택을 사용하며, 이렇게 되면 전 엔진의 네트웍에서 무슨 일이 벌어지는지 가늠할 수 있는 방법이 없어집니다.

덕분에 전 제 개발품에서 일부 기능을 부득이하게 삭제해야 되는 상황에 처했습니다. 일단 예측 가능한 미래만 놓고 본다면, Qt WebKit 자체는 9월 발표 예정인 Qt 5.4가 나오는 11월까지는 어떻게든 생존하겠지만, Qt 5.5 오픈소스 에디션이 발표되는 순간 무슨 일이 생길지는 아무도 모릅니다.

그간 WebKit이 유지보수에 손이 좀 많이 갔다고 하기도 하고, 저는 Digia의 개발팀을 좀 더 “효율적으로” 관리하고자 하는 의지 또한 존중합니다. 허나, 지난주 블로그 포스트에 달린 댓글들마냥 Qt WebEngine이 기대와 다르게 훨씬 더 적은 기능만을 갖고 출시된다면 아마 실망하는 사람이 적잖을 것 같아 우려됩니다.

현재 저는 현재의 개발환경을 대체할만한 무언가를 찾고 있습니다. Qt가 그동안 버전업을 하면서 셋업은 복잡해지고, QML 시작은 느려지고(빈 창 하나 띄우는데 최고 10초까지 소요) 하는 등의 상황을 보면서 뭔가 제 마음에 들만한 대체요소를 찾고 있긴 했습니다만, 울고 싶던 차에 Qt WebEngine이 뺨을 제대로 때려주는군요. 일단 현재는 wxWidgets+wxWebConnect(아니면 wxWebView) 컴보를 대체품으로 생각하고 있습니다.

어쨌든, Qt WebKit은 꽤나 위대한 프로젝트였습니다만, 이 프로젝트가 역사 속으로 사라질걸 생각하니 참 가슴이 아픕니다. 특히나 그렇게 사라지는 행위가 제 뒤통수를 크게 때리는 경우에는 더 그렇습니다.

Seeing the Doomed, yet Great Project: Qt WebKit

Last November, Digia announced the start of the new project named Qt WebEngine. Based on Google Chromium, it is a drop-in replacement of Qt WebKit. Most of the people welcomed the project, as they can easily use Chromium and Blink to their own environment. Digia said that Qt WebEngine will be as compatible as possible against Qt WebKit, and everybody belived in the promise, as Digia had a good reputation against Nokia, as they were practically leading the project well even in Nokia days of Qt.

Last week, I read a new blog article from Qt WebEngine team, and I saw some “complaints” about APIs for the new module. I jumped to the wiki and found out that my beloved QWebElement, which is the most needed core feature for my web crawler engine, will be unavailable in Qt WebEngine - according to the wiki, due to multi-process nature of the Chromium the feature should be designed asynchronously, but the design of Qt WebEngine is synchronous, it is not supported anymore.

Not only QWebElement. It also doesn’t integrate QNetworkAccessManager, which is another thing I use to check sanity of the content. Qt WebEngine uses Chromium’s own network stack, meaning I cannot review any network action from the Engine.

Thanks to the changes, my product won’t be able to support some of the features it currently has. From the foreseeable future, Qt WebKit will survive until Qt 5.4, which is expected to be released at this September, but there’s no guarantee what’ll happen when Qt 5.5 open source edition is released.

Of course there are be some reasons beyond giviing up WebKit as it requires more manpower for maintenance and I respect their decision to manage their development team in “more efficient” way. Yet I’m afraid there will be more who’re frustrated against new Qt WebEngine for its limited features as I read from some replies for Qt WebEngine blog article last week.

Well, now I search for some alternative development environment. I was already searching for a replacement of Qt itself as I see it become feature-bloat, resulting in more complicated setup environment, slow startup time in QML(up to 10 seconds for showing blank window), as I adopt new version of the library. And Qt WebEngine accelerated my move. Currently I consider wxWidgets+wxWebConnect(or wxWebView) combination as a replacement for current development environment.

Anyway, Qt WebKit was a great project, yet seeing one of the greatest development projects fade out to the history is quite a pain. Especially if the fadeout directly hits me hard.

The Power to Think for Oneself

Do not force them to think. From the beginning they didn’t even try to think at all. They just followed others’ thoughts and thickened thoughts that way.

스스로 생각하기

그들에게 생각하라고 강요하지 마라. 그들은 애시당초 생각하려고 하지도 않았다. 그저 누군가의 생각을 따라가다가 그렇게 행동이 굳어버렸을 뿐이다.

Miracle

There’s no such thing as miracle. There are only things that seem to be.

기적

기적은 없다. 단지 그렇게 보일 뿐.

오늘 슬쩍 만져본 C++ IDE들에 대한 단상

Qt Creator: 아무래도 현재 쓰고 있는 것이다 보니 어쩔 수 없이 팔이 안으로 굽을 수밖에 없긴 하지만, 아무래도 최강이라고밖에는 할 말이 없습니다. 게다가 이 녀석은 지금도 계속 진화중이에요.

Code::Blocks: 현재로서는 Qt Creator에 대항할 수 있는 유일한 제품이라고 생각합니다. 만일 제가 Qt를 쓰지 않았다면 아마 wxWidgets와 함께 이 녀석을 쓰고 있었을 거에요. 여러가지로 만족스럽습니다.

CodeLite: 어…… 일단 보기엔 좋습니다. 그런데 그게 다에요. code completion 라이브러리의 데모로 출발한 녀석치고는 code completion이 별로 맘에 안든다는 것만 빼고요. 좀 어색하게 움직일 뿐더러, 반응도 늦습니다. 그나마 예전에는 refactoring때문에 CodeLite를 쓰시는 분들도 계시긴 했습니다만, Code::Blocks 13.12에 포함된 refactoring이 훨씬 더 강력해 보입니다.

Eclipse CDT: 느리고 무겁습니다(그리고 이게 제가 Java를 좋아하지 않는 이유라지요). 너무 복잡하고요. 좀 뒤져보니 서로 다른 여러가지 이유들로 인해 불평하는 C++ 개발자들이 꽤 많이 보이는데, 문제(?)라면 이것들이 다들 공감이 가는 이유들로 채워져 있었다는 겁니다.

First impressions of C++ IDEs I tried today

Qt Creator: OK. I’ve got to admit that I’m skewed, but it’s the greatest, yet still evolving.

Code::Blocks: A great alternative to Qt Creator. If I were not using Qt, I’m certain I’d use this cool thing with wxWidgets.

CodeLite: Eh…… Looks good. And that’s all. Though started as a demo for code completion library, its completion is below my expectation - it behaves a bit awkward to me, and reaction is slow. Refactoring? Forget it. Code::Blocks 13.12 has it all.

Eclipse CDT: Slow and heavy(and that’s the reason I don’t like Java). Too complicated. There were so many complaints among C++ developers for so many different reasons, and I totally agree with each of the claims.

라자루스로 돌아오다

6개월인가, 8개월인가정도만에 라자루스를 다시 설치했습니다. Qt가 거의 모든 기능을 제공해줄 뿐 아니라, Boost와 함께 쓰면 더이상의 것은 필요없다는 말이 나올 정도로 완벽했지만, 아무래도 덩치가 너무 큰게 마음에 걸리더군요. 예. Qt의 단점을 논할때마다 꼭 나오는 말이지만, 기능이 너무 많아서 라이브러리가 무식하게 커지는 단점이 꼭 켕겼습니다.

최근에 Qt를 가지고 간단한 GUI 프로그램을 만들 일이 있었습니다. 별건 아니고 libssh를 사용해서 SCP로 다운로드받은 내용을 Qt Quick Control에 있는 테이블로 보여주는 프로그램이었는데, 이게 이것저것 다 합치니 50MB정도가 되더군요. 뭐, 반정도는 ICU(27.5MB)였으니, ICU를 빼고 Qt를 다시 빌드하면 크기가 좀 줄어들긴 하지만 EXE, DLL, 그리고 Qt Quick Control을 구성하는 QML 파일들을 모두 합치면 이것도 여간 번거로운게 아니죠.

가장 큰 문제가 되는 부분은 프로그램의 cold start가 일어날 때입니다 - 제 Core i5에서도 프로그램이 인터페이스를 띄우는데게 3초가 넘게 걸렸습니다. 이정도 시간이면, 사용자가 “왜 프로그램이 실행이 안되냐” 하면서 프로그램 아이콘을 다시 클릭하고도 남을 시간입니다.

하여간 이래저래 켕기는게 있어서 대안을 좀 찾았습니다. 그리고 그 물망에 오른건 wxWidgets와 Lazarus였습니다. 사실 첫번째 후보는 wxWidgets였습니다 - 어쨌든 C++ 사용자는 Object Pascal 사용자보다 많은게 현실이니, 도움은 더 받을 수 있으리라는 생각이 들더군요(뭐, 제가 따로 조사해본 결과를 통해 추측해보면 wx 사용자나 Lazarus 사용자나 수는 대충 비슷해 보이긴 합니다만……).

승부는 빈 창을 띄우는 프로그램을 빌드한 이후 갈렸습니다. wxWidgets는 7.45MB짜리 프로그램을 만들어냈고, (개인적으로 심한 애증관계에 있는)Lazarus는 1.44MB짜리 파일을 만들었습니다. 둘다 cross-platform이고, native widget을 사용하는 동일 구조라는걸 고려해본다면, 승자는 Lazarus더군요.(참고로, Qt는 native widget을 사용하지 않습니다. 단지 인터페이스를 native처럼 그려내기 위해 관련 DLL을 참고할 뿐입니다.)

하지만, 그럼에도 불구하고, 그놈의 적은 사용자 수가 끝까지 제 발목을 잡았습니다. 주변에 물어볼 사람도 없이 혼자서 맨땅에 헤딩하는 상황이 될게 뻔했던거죠.

그런데 이 때, 제 친구 중 한 분이 중요한 한마디를 하더군요:
“좋아하는 걸로 하세요.”
삽질을 각오할 열정이 있다면(……), 사용자 수가 적은건 별로 문제가 되지 않습니다. 사실 모든 사람들이 아무 생각 없이 몽땅 다 주류만 쫓아갔다면, D나, Vala나, Haskell같은건 있지도 않았을거고, LISP같은 것들은 아마 살아남지 못했을 겁니다.

결국 이놈의 애증 만발한 라자루스가 다시 제 시스템에 설치되었습니다. 이걸로 뭘 더 하게 될지는 모르겠지만, 어쨌든 언젠가는 뭔가 하게 되겠죠.

추신:
Lazarus를 떠나있는 동안 instantFPC라는게 나왔더군요. 이게 뭔가 하니 파스칼 소스코드를 스크립트처럼 쓰는건데…… 사실은 실시간으로 후딱 컴파일하고 돌리는 거랍니다. 뭐 파스칼 컴파일러가 무식하게 빠른거야 어제오늘 일이 아니라는걸 보면, 이렇게 무식한 구조로 JIT(..??) 컴파일러를 만들어도 크게 문제는 없을 것 같긴 합니다.
(제 Core i5 시스템에서 Lazarus IDE를 -O3로 처음부터 다시 컴파일하는데 2분이 채 안 걸렸습니다.)

Back to Lazarus

I reinstalled Lazarus. It’s been a while - about 6 to 8 months or so. Using Qt, though the library provided almost everything, especially when used with Boost, I was always concerned with the fact that it’s too heavyweight - yes. Qt is feature bloated and the size of library is sometimes too big.

Recently I developed a simple GUI application, which downloads something using SCP and show on a grid. It was based on Qt Quick Controls and libssh. Later I found out that the package was bigger than 50MB. Of course half of the library was ICU(about 27.5MB) so I could remove it if I rebuild Qt without ICU, but still it’s 25MB with lots of files(EXE, DLL, as well as a lot of Qt Quick Controls QML files). The size of file matters, especially in cold start - in my Core i5 system, the application needed more than 3 seconds to show its main interface. It’s slow enough for the user to click the icon again, thinking that Windows in some way ignored user’s click.

So I searched for some alternatives. I considered two: wxWidgets and Lazarus. My first consideration was wxWidgets - well, anyway there are far more C++ users than Object Pascal users so I may get more helpful materials(though according to my short research on a few sites, actual user base would be about the same for both).


The winner was clearly Lazarus. Both are cross-platform, and use native widgets, meaning smaller application = simpler architecture = faster speed. After building a GUI application with empty form, I turned to my beloved love-hate Lazarus again - wxWidgets gave me an EXE of 7.45MB, while Lazarus gave me one of only 1.44MB.
(c.f. Qt is not native - it just ‘refers to’ native GUI library to draw the interface in native way.)

But I was still reluctant to use Lazarus again, because I clearly know how small the user base of Object Pascal is, meaning I may be the lone survivor after all other developers turning back to other environment, fighting the hard fight.

And this time, one of my friend said something important:
“Do whatever you’d like to do.”
Small user base is not a problem so long as you have passion. If everyone mindlessly follows the mainstream, there would be no D, Vala, Haskell, etc., and LISP and others would not have survived.

So I landed again to the land of my beloved love-hate Lazarus. I’m not sure what I’ll do with this thing, but I’m sure that some day I’ll do something with it.

P.S:
During the time I left my FreePascal/Lazarus world, the Lazarus team made something fun; instantFPC. It reads FPC source code and run it as if it’s a script. In fact it compiles the source code and run the binary, but please remember, Pascal compilers are among the fastest compilers in the world(in my Core i5 system it took less than 2 minutes to fully rebuild Lazarus IDE with -O3 switch).

"Why Boost doesn't boost my productivity"

I found a good article on learning Boost, C++ libraries.
http://agentxcpp.wordpress.com/2013/05/18/why-boost-doesnt-boost-my-productivity/

To make a long story short, the author wants to say that “Boost requires unnecessarily complicated coding style, which decreases code readability quite a bit.” Of course Boost contributed to the C++ a lot, for example boost::thread became the standard for C++11 std::thread. Yet, for some, libraries discourage readabilities of the code, and documentation lacks necessary information, resulting in making big wall against the newcomers who want to enter the world of Boost.

One thing fun is that the target being compared is Qt, which I rely on the most. Say, even myself sometimes asked myself that “why do people use Boost?”, because most of the features are already ready-made in Qt and Qt tries to reimplement main features of Boost.

I agree with the author most of the time, but considering boost::thread or boost:signal, which don’t require much time to learn, the viewpoint is not always applicable to all of the components - it’s just case by case.

Well, please regard this memo as one small opinion of a programmer who didn’t take any formal programming course, but by chance earn money by programming in a niche market.

"Why Boost doesn't boost my productivity"

어제 C++ 라이브러리 모음인 Boost에 대해 이것저것 찾아보다가 읽어보게 된 글입니다.
http://agentxcpp.wordpress.com/2013/05/18/why-boost-doesnt-boost-my-productivity/

내용이 좀 깁니다만, “Boost는 똑같은 결과를 내기 위해 가독성이 떨어지는 복잡한 코드를 요구한다”가 골자가 되겠습니다. 물론 boost::thread 등이 C++11에 채용되는 등 C++에 대한 Boost의 기여도가 적지 않음을 알고 있습니다만, 몇몇 소스 가독성을 떨어뜨리는 코딩을 유도하는 라이브러리와 부족한 문서화는 분명 Boost에 입문하려는 사람들에게 커다란 장벽으로 자리잡는다 할 것입니다.

게다가 하필 비교대상이 제가 가장 많이 의존하는 Qt더군요. 그러고보면 요즘 웬만한건 Qt로 다 되는데다가 Boost의 주요 기능들이 Qt에서 재구현되는 경우가 꽤 있는걸 보면 가끔은 ‘Boost를 왜 쓰지?’ 하는 생각이 들 때도 있습니다.

일견 공감이 많이 됩니다만, 한편으로 boost::thread나 boost::signal같은 것들은 별다른 공부 없이도 쉽게 쓸 수 있는걸 보면 이 건은 case by case라고 보는게 옳지 않을까 싶습니다.

뭐 정식(?)으로 프로그래밍을 배운 적이라고는 한 번도 없이, 모든걸 독학으로 공부했지만 얼떨껼에 니치 마켓(?)을 찾아 프로그래밍으로 밥벌어먹게 된 사람의 쓸데없는 뻘소리였습니다.

넥서스 5와 내 영어실력

넥서스 5를 구매하다.
그 유명한 “OK Google”은 미국식 영어만 알아듣는다는 사실을 확인하다.
자, 그럼 이제 미국식 영어발음을 연습해볼까나. :P

P.S:Google Now가 U.S. English 세팅에서 내 발음을 거의 다 알아듣는다!
내 발음은 세계적인 글로벌 기업 구글이 인정한 발음이야!
내 쩔어주는 미국식 영어발음을 보고 다들 열폭하라고!

Nexus 5 and My English

Bought Nexus 5.
Found out that the famous ”OK Google” feature is available only when you set your language to U.S. English.
Time to practice “standard” U.S. English pronunciation. Hmpf. :P

P.S:Fortunately Google Now understand my English quite well.lol lol lol
OK Google. You accepted my pronunciation is quite that of American Native. ;)

Windows에서 MinGW-builds(MinGW-w64)를 이용하여 libssh를 빌드하는 경우 유 의점

라이브러리 의존성: zlib, openssl

메모

• zlib: 큰 문제 없음. mingw32-make -f win32/Makefile.gcc 한방으로 해결 가능
• openssl: www.mingw.org에서 MSYS를 다운로드받은 후, 소스코드를 MSYS의 tar로 풀어낼것. 그렇지 않은 경우 tarball 안에 있는 symlink가 제대로 처리되지 않음
• libssh: 두가지 유의사항이 있음
  1. 빌드 디렉토리는 소스코드 디렉토리가 아닌 다른 곳이어야 함
  2. 소스코드 직접 수정 필요: return pthread_self().p를 return pthread_self()로 수정해야 함. 이는 MinGW-builds와 www.mingw.org 양쪽 경우에 대해 pthread 드라이버의 구현 방식이 다르기 때문일 것으로 추측함(소스코드를 비교해보지는 않았음)

Memo on building libssh in Windows with MinGW-builds(MinGW-w64)

Requirements: zlib, openssl

Remarks

• zlib: Just mingw32-make -f win32/Makefile.gcc and that’s all
• openssl: Install MSYS from www.mingw.org and use tar on that MSYS package to untar the source tarball. If not, the links on the tarballs are not adequately managed
• libssh: two things
  1. The build directory should be other than the source tree
  2. You’ve got to edit source code to return pthread_self(), rather than pthread_self().p, which is used under #ifdef _WIN32_. This seems to be because of the differences of pthread implementations between mingw.org and mingw-w64 (though not I didn’t compare the source codes)

QByteArray::indexOf()

QByteArray::indexOf() shows almost the same speed of my implementation of Boyer-Moore-Horspool full string search library based on char*. As Qt has the same source code, chances are GCC 4.8.2 devoted to the performance improvement.

QByteArray::indexOf()

Qt 5.2.1에서 QByteArray::indexOf()가 내가 만든 char* 기반의 Boyer-Moore-Horspool full string search와 거의 동일한 속도를 내고 있다. Qt쪽의 소스코드가 동일한 걸로 봐서 GCC가 4.8.2로 업데이트되면서 나온 최적화 결과인 듯.

Search Speed: Records vs. Full Text Search

If the data can be divided into records, hash table based lookup is more than twice faster than Boyer-Moor-Horspool style full string search.

Example: QMap/QHash vs. QString::indexOf()

검색 속도: 레코드 vs. 텍스트 전체 검색

만일 레코드 단위로 분리가 가능하다면, 해시 테이블 기반의 lookup function이 Boyer-Moore-Horspool 스타일의 full string search보다 2배 이상 빠르다.

예: QMap/QHash vs. QString::indexOf()

Qt+Boost=invincible

Nowadays I was trying node.js (actually, following tutorials).
During the following, some thoughts popped up:

1. node.js says one of the biggest strength lies in asynchronous callback
2. Qt is designed to be asynchronous
3. Boost has boost::async

Now, the thoughts spread more……

1. Which of the two, node.js or C++, would have more libraries?
2. Which will be faster, JIT or static compilation?

My conclusion: why do I try node.js, though I can do it everything with Qt + Boost?

Qt+Boost는 무적입니다

요즘 node.js가 뜬다길래 node.js를 끼적거려봤습니다.
그러다가 문득 생각이 든게……

1. node.js는 비동기식이라는게 가장 큰 장점이잖아?
2. Qt도 비동기인데?
3. Boost도 boost::async가 있지..??

이쯤해서 생각 전개!

1. node.js하고 C++하고 어느게 라이브러리가 더 많을까?
2. JIT하고 static compilation하고 어느게 더 수행속도가 빠를까?

결론: Qt + Boost로 다 되는데 왜 node.js를 하려는 거지?

……어?!