좀딱의 또다른 세상

세차 운동은 어떤 물체가 회전하고 있을 때, 물체 뿐만 아니라 회전축 자체가 도는 것을 말한다. 예를 들면, 팽이가 회전할 때 축이 기울어져도 바로 넘어지지 않고, 일정시간 기울어진 채로 축 자체가 움직이는 모습을 볼 수 있는데, 이것이 세차운동이다. 아래 그림을 보면 쉽게 이해가 될 것이다. 출처: http://ko.wikipedia.org/wiki/%EC%84%B8%EC%B0%A8_%EC%9A%B4%EB%8F%99 지구 역시 회전, 곧 자전을 하고 있기 때문에 자전축이 세차운동을 하고 있을 것이라고 예상이 가능하며, 이것은 사실이다. 이에, 지구 세차운동의 원인이 무엇이고, 그 방향은 어떻게 결정되는지 알아보자. 지구 세차운동의 원인에는 일월세차(해 달 때문에 생기는 세차) 또는 행성세차(행성 때문에 생기는 세차) 따위가 있는데, 그 중에서 주요한 원인은 일월세차이며, 그 중에서도 해가 핵심 원인이다. 알다시피, 지구는 양 극 사이보다 적도의 길이가 더 긴 타원형이다. 적도 부분이 부풀어 있는 까닭은 지구 자전 때문이다. 그리고 지구 적도면은 공전 궤도면에 대해 23.5 도 기울어져 있다. 바로 이것 때문에 해에 따른 세차 운동이 발생한다. 더 자세히 알아보자. 지구는 지구의 북극 상공에서 내려다 봤을 때, 반시계 방향으로 자전하고 있다. 이 때 돌림힘(토크)의 방향은 지구 북극 방향이 된다. 돌림힘이란 어떤 물체를 회전시키는 힘을 말하며, 이 힘의 방향은 앙페르의 오른손 법칙을 이용하면 쉽게 알 수 있다. 다시 말해서 회전 방향을 손가락으로 가리킨 후 손을 말아쥐고, 엄지를 세웠을 때, 엄지가 가리키는 방향이 돌림힘의 방향이다. 그리고 이 방향은 회전축과 항상 나란하다. 하지만 같다는 뜻은 아니니 조심하자. 지구의 자전 방향대로 손을 말아쥐면 지구 북극 방향과 엄지의 방향이 일치함을 확인할 수 있다. 다음 그림을 보자.   그림에서는 잘 나타나지 않았지만(ㅠㅠ), 지구는 적도 방향이 자전축 방향보다 조금 더 긴 타원

getnameinfo(), freenameinfo() and getaddrinfo() are not provided by kLIBC. Like poll(), you can find the replacements from many projects such as FFmpeg and Gnulib. Here is the one based on VLC. getaddrinfo.h : https://github.com/komh/os2compat/blob/master/network/getaddrinfo.h getaddrinfo.c : https://github.com/komh/os2compat/blob/master/network/getaddrinfo.c

poll() is similiar to select(), and is used widely. However, kLIBC does not have it. Fortunately, there are many replacements for it. Here, I provide the one from VLC. You can find them in many projects such as FFmpeg and Gnulib. poll.h : https://github.com/komh/os2compat/blob/master/network/poll.h poll.c : https://github.com/komh/os2compat/blob/master/network/poll.c

git 를 사용하다보면 때때로 저장소 전체가 아니라 특정 브랜치 하나만 받고 싶을 때가 있다. svn 의 경우 디렉토리 단위로 받을 수가 있고, 브랜치도 하나의 디렉토리이기 때문에 별 어려움이 없었다. 하지만 git 에서는 이것을 어떻게 해야 할지 궁금했다. 구글링을 해 본 결과 clone 옵션 중에 -b(또는 --branch) 가 있었다. -b 옵션이 없으면 master 브랜치를 가져오고, -b 옵션이 있으면 해당 브랜치를 가져온다. git clone URL -b branch_name [dir] 그런데 사실 이것은, 저장소 전체를 가져와 HEAD 를 해당 브랜치로 바꾸는 것 뿐이다. 다시 말해서, HEAD 가 master 를 가리키는 것이 아니라 해당 브랜치를 가리키는 것이다. 결국 clone 하고나서 해당 브랜치를 checkout 한 것과 동등하다. git branch -r 을 해보면 전체 브랜치들이 모두 보인다. 그렇다면 실제로 해당 브랜치만 가져올 수는 없을까 ? 1.7.10(?) 부터 --single-branch 옵션이 추가되었다. 이 옵션을 사용하면 저장소 중에서 해당 브랜치만 clone 한다. git clone URL -b branch_name --single-branch [dir] 이것을 실행하고 나서 git branch -r 을 해보면 해당 브랜치만 나오는 것을 확인할 수 있다. 전체 저장소가 아니라 해당 브랜치에서만 작업하기를 원한다면 --single-branch 가 맞춤옵션이다. 게다가 전송 시간도 줄어들고 저장 장치에서 차지하는 용량도 줄어드니 더욱 좋다.

From time to time, you may encounter the following error when compiling. Undefined symbol ___sync_val_compare_and_swap_4 referenced from text segment This function is an atomic builtin of gcc. Nevertheless, even though you are using the latest gcc, this may occur. This is because this atomic builtin enabled only at i486 cpu or later, but the default architect of OS/2 gcc is i386. If you want to confirm the architect of your gcc, do this. gcc -E -dM - < nul And you can find __tune_i386__. Now add -march=i486. gcc -march=i486 -E -dM - < nul Then, you can find __tune_i486__ instead of __tune_i386__. In addition, you can find another differences. Especially, Colored By Color Scripter ™ 1 2 3 #define  __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define  __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define  __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 Consequently, if you encounter that error, then add -march=i486 to your compiler flags. For references, atomic builtins of

fork() is used to create a copy of a parent process. kLIBC also supports it. Unfortunately, however, its implementation is imperfect more or less although it works well in general. In addition, it is not efficiency because OS/2 kernel does not support fork() directly unlike Unix-like systems. So kLIBC had to implement fork() by itself. As I said above, fork() works well in general. So if you have no problems, it's ok to use fork(). But if you have a problem or want more efficiency, you should use another methods. fork() alone When Unix-like systems did not support threads, fork() was a way to implement threads. So you can replace fork() alone with a thread. The following is an example replacing fork() with a thread in stream/cache2.c of MPlayer. Colored By Color Scripter ™ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

Pipes are used for IPC(inter-process-communication). OS/2 kLIBC also supports them. However, there are some differences. First, kLIBC's anonymous pipe which is provided by pipe() does not support non-blocking mode. Second, it does not work with select(). To overcome these, there are two ways. One is to use a name pipe and the other one is to use socketpair(). Named pipe Named pipe is a IPC method based on server and client communication. Server side creates a name pipe, client side opens it, then communicate each other. Although this is IPC method, it is possible to use a named pipe in one process. We can create non-blocking pipes with this. However, this has a problem. First, select() does not work as well, because a named pipe is not a socket. Instead, you can use native APIs such as DosWaitNPipe(). Second, some kLIBC io functions such as fcntl() do not work. In this case, you can use DosSetNPHState() or DosSetFHState() APIs. socketpair() socketpair() is a IPC met

요즘 노트북에 달려 있는 터치 패드는 굳이 마우스가 필요없을 정도로 편리하다. 그런데 터치 패드를 보다 편리하게 쓰기 위해서는 제조사에서 제공하는 드라이버 말고, 편의성을 향상시켜주는 별도의 제어 프로그램이 필요하다.  Elan Touchpad 의 경우에 ETDCtrl.exe 가 그런 역할을 하는데, 아쉽게도 VirtualBox 와 궁합이 맞지 않는다. ETDCtrl.exe 와 VirtualBox 가 동시에 실행 중이면 ETDCtrl.exe 가 CPU 하나를 완전히 점유한다. 인터넷을 검색해보면, 많은 사용자들이 이 문제를 호소하고 있는데, 딱히 근본적인 해결방법은 보이지 않는다. 그저 CPU 점유율이 올라가면 ETDCtrl.exe 를 죽였다가 다시 실행시키는 방법뿐이다. 또는 아예 ETDCtrl.exe 를 사용하지 않든지. 내 경우에도 ETDCtrl.exe 를 죽이고 실행하는 것을 반복했었는데, 여간 불편한 것이 아니다. 이게 귀찮아서 죽이고 실행시키지 않으면 터치 패드의 효용성은 급격히 떨어졌다. 그래서 혹시 새로운 드라이버는 괜찮지 않을까 해서 찾아보았는데, 다행히도 찾을 수 있었다. 11.6 부터 11.8, 11.12, 11.13, 11.14 까지 시험해 봤는데, 설치도 잘 되고, VirtualBox 와도 궁합이 잘 맞는 드라이버는 11.6 이었다. 이런 고통을 받고 있는 분이라면, 이 드라이버를 받아서그 고통에서 얼른 벗어나기 바란다. 해당 드라이버는 케이벤치 자료실에서 구할 수 있다. 로그인은 필요하지 않으니, 다운로드 버튼만 누르면 된다. 편의를 위해 링크를 남겨둔다. http://www.kbench.com/software/?q=node/51591

select() is a main cause of raising CPU loads. Because unlike Unix-like systems, select() on OS/2 kLIBC works only on sockets. If any other descriptors than sockets are passed to select(), select() fails. And if select() is in a loop, the loop will be reapted tightly. As a result, CPU load go to the peak. So if CPU load is the peak when you ported something, then search select() and check if select() is used on sockets. If not, you have to replace the codes with the same functioning codes not using select(). Fortunately, MinGW also shares this defect. So you may use MinGW codes to avoid this problem. Otherwise, you have to do it yourself although it may be difficult somewhat.

오래 전에 구술/논술 대비해서 지구과학 영역별로 정리한 내용이다. 각 영역을 누르면 내용을 볼 수 있다. 지질 , 지구물리 , 대기 , 해양 , 천체

오래 전에 지구과학 영역별로 정리한 내용이다. 각 영역을 누르면 내용을 볼 수 있다. 지질 , 대기 , 해양 , 지구물리 , 판구조론 , 천체

socklen_t When porting network stuffs, you'll often encounter the complains of a compiler about socklen_t. Because OS/2 kLIBC does not define it. So we should define it by ourselves. It's simple. Just use typedef or #define. Colored By Color Scripter ™ 1 typedef   int  socklen_t; Colored By Color Scripter ™ 1 #define  socklen_t  int Or, you can use -D option of gcc. gcc some_options -Dsocklen_t=int some_options Macros for shutdown() shutdown() uses macros for its argument. Unfortunately, however, OS/2 kLIBC does not have them. They are SHUT_RD, SHUT_WR, and SHUT_RDWR. And they correspond to 0, 1 and 2, respectively. So use #define. Colored By Color Scripter ™ 1 2 3 #define  SHUT_RD     0 #define  SHUT_WR     1 #define  SHUT_RDWR   2

libtool is a part of autotools to create shared libraries in an unified way on various platforms. Unfortunately, however, libtool lacks OS/2 support. So patches for this are provided separately. To use this patched libtool, you should regenerate your build system with autoreconf. Then libtool works well on OS/2 as expected. By the way, this is not enough. Unlike Unix-like systems, OS/2 does not allow to create DLLs which have undefined symbols. This is possible to static libs. But DLLs have to have all the symbols like the executables. For this, libtool requires some flags. That is, -no-undefined. Without this flag, libtool complains about that, and creates static libs instead of DLLs. For examples, if removing -no-undefined from linker flags of FLAC, the following message is printed. Colored By Color Scripter ™ 1 2   CCLD     libFLAC.la libtool: link: warning: undefined symbols not allowed in i386-pc-os2-emx shared What is how to add -no-undefined flag ? The

태풍은 저기압의 일종이다. 그럼에도 불구하고, 태풍은 일반 저기압과는 다른 특징을 보이는데, 태풍의 눈이 대표적이다. 일반 저기압 중심에서는 상승 기류가 지배하지만, 태풍의 중심부에서는 강한 상승 기류 속에 약한 하강 기류가 나탄나다. 이 약한 하강 기류 때문에 구름이 사라져, 위성 사진으로 보면 이 부분만 구멍이 뚫린 것처럼 보인다. 이러한 까닭으로 이 중심부를 태풍의 눈이라 부른다. 결국 태풍의 눈은 중심부의 약한 하강 기류 때문에 나타나는 현상인데, 이 약한 하강 기류가 어떻게 발생하는 것일까 ? 우선 태풍의 구조부터 살펴보자. 출처: http://blog.daum.net/starynights/26 이 그림을 보면, 태풍 주변부에서 바람이 들어와 위쪽으로 빠져나가고, 그 일부가 중심부에서 아래쪽으로 내려오고 있음을 알 수 있다. 이 과정을 따라가 보자. 주변부에서 바람이 중심으로 들어갈 때 바람의 속력은 점점 증가한다. 이는 각운동량 보존법칙 때문이다. 각운동량은 회전의 중심으로부터 떨어진 거리와 선운동량(질량과 속도의 곱)의 곱으로 계산된다. 식으로 표현하면 이렇다. L = r x m x v (L: 각운동량, r : 중심거리, m : 질량, v : 속도) 그런데 중심으로 들어갈수록 중심거리 r 이 작아진다. 질량 m 은 일정하므로, 각운동량 L 이 보존되기 위해서는 속도 v 가 증가해야 한다. 따라서 바람의 속력이 점점 빨라지는 것이다. 이를 설명하기 위한 가장 대표적이 예는 피겨 스케이터의 회전이다. 팔을 벌리고 있다가 팔을 가슴으로 끌어 안으면서 회전 속도가 점점 빨라지는 것과 같은 이치이다. 바람이 안쪽으로 계속해서 들어가는 이유는 기압경도력과 전향력 및 마찰력의 영향이다. 태풍도 저기압이기 때문에 기압경도력은 안쪽을 향한다. 기압경도력만 있다면 그대로 중심을 향하겠지만, 전향력과 마찰력의 영향으로 안쪽으로 회전하면서 들어가게 된다. 그런데 회전하는 물체는 원심력을 받게 된다. 이 원심력은 공기를 바깥쪽으로 빠

One of the shortages of OS/2 is lack of an unified installer. IBM provided some installers such as Feature Installer. But they were not used widely. Instead of them, some users created their own installer. Among them, WarpIn is most popular. However, WarpIn has a dependency problem.  If a program depends on some DLLs, it should be installed before. If installing a program regardless of those dependencies, then the program cannot be executed. The other problem is that some programs and libraries are distributed in zip. By the way, WarpIn does not recognize them as dependencies. As well as, WarpIn packages are not distributed in an unified repository. So to find dependent packages, it is required to search internets. Fortunately, hobbes acts as a main repository for WarpIn as well as other programs and libs. To overcome these cons of WarpIn, some people tried to port rpm/yum system. And rpm/yum packages are now hosting on netlabs. If you use rpm/yum, then you can solve these problems

When wildcards(*, ?) are provided as arguments, OS/2 accepts them as is, but Unix-like systems expand them to real entires. In fact, who do this is a shell. Fortunately, OS/2 shells such as CMD and 4OS2, do not this task. So this became the task of applications. You can do this by yourself. But kLIBC provides a function and a link flag for this. The function is _wildcard() and the flag is -Zargs-wild. If you add -Zargs-wild to your linker flag, then _wildcard() is called automatically on startup. Or do like this. Colored By Color Scripter ™ 1 2 3 4 5 6 7 8 9 10 int  main(  int  argc,  char  *argv[]) { #ifdef  __OS2__     _wildcard(&argc, &argv); #endif        /* some codes */           return  0; } By this, you can expand wildcards in arguments to real file entries. For examples, if you call a program with "*.cmd", then original argc will be 2 and argv[0] will be a program name, argv[1] will be "*.cmd&quo

When porting programs and libraries from Unix to OS/2, one of the most problematic cases is a line ending problem. OS/2 including Windows and DOS uses CR/LF pair to mark an end of line. Whereas, Unix-like systems use LF only. And OS/2 distinguish text mode(aka translation mode) from binary mode(aka no translation mode). That is, OS/2 translates LF to CR/LF when writing to devices, and CR/LF to LF when reading from on text mode. Whereas, Unix-like systems don't care about distinguishing text mode from binary mode. In OS/2's terms, Unix-like systems treat all the devices as binary mode. And the default mode of OS/2 is text mode. These are the causes of a line ending problem. For example, if we open a file with open() without both O_TEXT and O_BINARY, it is opened in text mode. Likewise, fopen() without both "t" and "b", it is opened in text mode. But on Unix-like systems all of them are opened in binary mode. If they are real text files, nothing is probl

해륙풍, 산곡풍, 계절풍은 모두 차등 가열과 관련된 현상이다. 한 부분이 다른 부분보다 더 가열되거나 또는 더 냉각될 때 공기의 밀도와 기압의 분포가 달라지는데, 이 차이에 따라 이들 바람이 일어난다. 먼저 바람의 이름을 붙이는 방법부터 알아보자. 바람의 이름은 바람이 불어오는 쪽의 이름을 따서 붙인다. 예를 들어, 동풍이라고 하면, 동쪽에서 불어오는 바람이다. 마찬가지로 해풍이라고 하면 바다에서 불어오는 바람이고, 곡풍이라고 하면 골짜기에서 불어오는 바람이 된다. 이를 기억하고 해륙풍, 산곡풍, 계절풍에 대해 알아보자. 해륙풍 해륙풍은 바닷가에서 나타나는 바람으로 육지와 바다의 비열 차이 때문에 발생한다. 낮에는 육지가 바다보다 비열이 작기 때문에 더 금방 가열이 되어, 육지 공기가 부풀어 오른다. 이렇게 되면 등압선의 수직 분포가 달라져, 아래와 같이 된다. 상공에서는 육지 기압이 바다 기압보다 높으므로, 육지에서 바다로 바람이 분다. 그리고 바다 상공에 모인 공기는 해수면으로 하강하여, 다음과 같은 순환을 완성한다. 따라서 지상의 경우, 낮에는 바다에서 육지로 바람이 부는 해풍이 발생한다. 밤에는 육지가 바다보다 더 빨리 냉각이 되므로, 낮과는 반대 현상이 나타난다. 육지의 공기가 냉각되어 육지의 등압선 수직 간격이 좁아지므로, 상대적으로 바다 상공의 기압이 더 높아진다. 따라서 바다 상공에서 육지 상공으로 바람이 불고, 육지 상공에 모인 공기는 지표면으로 하강하여 지표면의 기압을 해수면의 기압보다 상대적으로 높게 만든다. 따라서 지상의 경우, 밤에는 육지에서 바다로 바람이 부는 육풍이 발생한다. 산곡풍 산곡풍은 산 정상과 골짜기에서 나타나는 바람이다. 산곡풍도 해륙풍과 마찬가지로 차등 가열이 그 원인이다. 낮에는 산비탈면이 직접 가열되고, 이 때문에 그 위에 있는 공기도 가열되어 공기 부피가 팽창한다. 이렇게 되면 동일 고도에 있는 다른 공기들에 비해 밀도가 작아져 상대적으로 가벼워진다. 따라서

경도풍이란 상공에서 등압선이 원형일 때, 기압경도력, 전향력, 구심력의 균형으로 원운동을 하는 바람이다. 고기압과 저기압에서 이 힘들의 균형 관계가 차이가 나는데, 이를 확인하고 이로부터 고기압과 저기압에서 나타나는 경도풍의 속력을 비교해보자. 고기압 고기압은 중심부의 기압이 주변보다 높으므로, 기압경도력의 방향은 바깥쪽을 향한다. 기압경도력 때문에 일어난 바람은 전향력의 영향으로 북반구에서는 진향방향의 오른쪽으로 이동방향이 꺾이는데, 이는 전향력과 기압경도력이 정반대의방향이 될 때까지 계속된다. 그런데 앞서 말했듯이 경도풍은 원운동을 한다. 원운동을 하기 위해서는 구심력이 필요하다. 이 구심력은 바로 전향력과 기압경도력의 차이에서 발생한다. 곧, 구심력 = 전향력 - 기압경도력 ----- (1) 이 된다. 저기압 저기압에서는 고기압에서와는 반대 현상이 나타난다. 왜냐하면 저기압은 중심부의 기압이 주변부보다 낮아, 바람을 일으키는 근본적인 힘인 기압경도력의 방향이 안쪽을 향하기 때문이다. 이에 따라 전향력은 바깥쪽을 향하게 되고, 구심력의 크기는 아래와 같이 결정된다. 구심력 = 기압경도력 - 전향력 ----- (2) 속력 비교  이제 식 (1) 과 식 (2) 를 각각 전향력에 대해 정리해 보면, 식 (1): 전향력 = 기압경도력 + 구심력 ----- (3) 식 (2): 전향력 = 기압경도력 - 구심력 ----- (4) 이 된다. 이 때, 식 (3)과 식 (4)를 비교하면, 식 (3)의 전향력이 식 (4) 의 전향력보다 크다. 그런데 전향력(=fV)은 속도에 비례하므로, 식 (3)의 속력이 식 (4)의 속력보다 크다. 다시 말해서, 고기압과 저기압의 규모가 동일하고, 기압경도력(등압선의 간격)과 구심력(기압경도력과 전향력의 차이) 따위가 모두 같을 때, 고기압의 경도풍이 저기압의 경도풍보다 빠르다.

On OS/2, gcc supports two object formats. One is aout, which is a traditional format of Unix world. The other is OMF, which is a native format of OS/2. When porting to OS/2, which is more proper ? My answer is aout. Because aout is supported by binutils, which is used by most of projects from Unix world. Using OMF requires additional works. And aout can be converted to OMF easily with emxomf.exe. As well as, kLIBC/gcc supports aout to OMF auto-conversion at linking time. Whereas, OMF to aout is not supported. If you want to port, use aout. And if you develop a library with gcc, then use aout and convert it to OMF with emxomf.exe. How can I select aout or OMF ? gcc provides -Zomf flags. This flag unlike the other -Z flags, works as both a compilation flag and a linker flag. If -Zomf is used at compilation time, the object file is OMF format. Otherwise aout format. If -Zomf is used at linking time, OMF linkers by emxomfld.exe are used. Otherwise, ld.exe is used. By the way, I rec