2014의 게시물 표시

햇빛과 햇볕

해에서 비롯된 낱말들 중에 햇빛과 햇볕이 있다. 언뜻 비슷하지만, 그 쓰임은 매우 다르다. 우선 우리가 해에게서 얻는 것이 무엇인지 살펴보자. 해가 뜨면 온누리가 밝아지고, 따뜻해진다. 바로 이 변화를 표현하는 말이 햇빛과 햇볕이다. 햇빛은 누리를 밝게 해주고, 햇볕은 누리를 따뜻하게 해준다. 국어사전에는 이렇게 씌여 있다. 햇빛 : 해가 비추는 빛. 햇볕 : 해가 내리쬐는 뜨거운 기운.  출처 : 다음 국어사전 // ---- 2014/12/23 이를 이해하면, 태양광 발전과 태양열 발전도 쉽게 이해할 수 있다. 간단하게 말해서, 태양광 발전은 햇빛을 이용하는 것이고, 태양열 발전은 햇볕을 이용하는 것이다. 자세히 말하면, 태양광 발전은 아인슈타인에게 노벨상을 안겨준 광전 효과를 이용해서 햇빛을 직접 전기로 바꾸는 것이다. 반면에, 태양열 발전은 우선 오목 거울 따위를 이용해서 햇볕을 한 곳에 모으고, 이 때 발생하는 열에너지를, 열기관을 이용해서 기계에너지로 바꾼다. 이 기계 에너지로 터빈을 돌려 전기를 생산한다. // -----

GALAXY Apps 에서 유료게임 무료로 받자!!!

GALAXY Apps 를 쓰는 사람들은 이미 알고 있겠지만, GALAXY Apps 에서는 유명 유료 앱들을 정해진 시간(약 일주일?)동안 무료로 제공해 주고 있다. 그런데 얼마전부터 게임앱들도 추가되었다. 어떤 게임인지는 몰라도 무료이니까 일단 받아보자 해서 받았다. 이렇게 받은 것들이 Dead Space, Need For Spped Most Wanted, Paladog 들이다. 비록 최신 게임은 아니지만 나처럼 아직 안 해본 사람들에게는 충분히 매력적이다. 지금 Paladog 에 빠져서 눈이 빨개지고 있다. ^^ Paladog 은 12/18 12시 현재 107시간 남았다. 아직 받지 않은 분들은 꼭 받으시길. 그리고 수시로 들어가서 다른 무료 게임앱도 놓치지 말기를...

OS/2 사용자로서 오픈소스 활동하면서 느낀 것들

개인적으로 OS/2 라는 OS 를 즐겨 사용한다. 한 때는 주류 OS 가 될 뻔 했지만, Windows 에 밀려나더니 결국 IBM 은 2006년에 지원을 중단했다. 하지만 다행히도 이후 다른 업체들(Senerity -> Mensys -> ARCA NOAE)과 OS/2 사용자 커뮤니티의 도움 덕택에 eComStation 이라는 이름으로 계속해서 지원되고 있다. 하지만 비주류 중에서도 비주류가 된 것은 부정할 수 없다. Haiku 심지어는 DOS 보다도 대우를 못 받고 있는 듯하니까. 비주류임에도 불구하고 상용 OS 이라서 그런지도. 어쨌든 이런 비주류 OS 를 쓰다 보니 대부분의 F/OSS 프로젝트를 이용하려고 하더라도 패치없이 쓸 수 있는 경우는 정말 극히 드물다. Linux 나 Windows 에서는 가장 일반적인 절차인 ./configure -> make -> make install 만 하면 되지만, OS/2 에서는 모든 단계에서 패치가 필요하다. 그렇다보니 되도록이면 새로운 프로젝트를 추가하지 않으려는 마음이 생겼고, 어쩔 수 없이 사용해야 하는 프로젝트를 빼고는 프로젝트 사용을 최소한으로 줄이고 있다. 처음에는 개인적으로 간단한 프로그램을 만들다가, 점차 OS/2 에서 사용되고 있는 F/OSS 프로젝트에 참여하게 되었다. 워낙 개발자 수가 적다보니 새로운 개발자의 참여를 매우 반기는 분위기였고, 덕분에 보다 적극적으로 참여할 수 있었다. 한 번은 예전 메일을 본 적이 있었는데, 어떤 코드에 대해 논쟁이 있었다. 지금 와서 보면 상대방 말이 맞았는데, 왜 그렇게 우기고 있었는지 이해가 되지 않았다. 어찌나 부끄러워지던지. ^^ 이후 멀티미디어쪽에 관심을 많이 가지면서 다른 OS 의 F/OSS 프로젝트에 관심을 가지게 되었다. 시작은 FFmpeg 이었던 것 같다. 한 번은 OS/2 코드가 삭제되었었는데, 예전 코드를 다시 살리려니 이것이 잘못 됐다, 저것이 잘못 됐다, 이러는 것이다. 도무지 이해가 안됐었다. 그저 예전 코드를...

Bash 설정 파일들...

여러 셸 중에서 가장 많이 이용되고 있는 셸이라면 단연 Bash 일 것이다. Bash 를 쓰다보면 자주 쓰는 alias 나 환경 변수들을 따로 저장해 둘 필요가 생긴다. 그런데 셸의 실행 형태에 따라 읽어 들이는 설정 파일이 다르다. 이를 모르면 아무리 설정 파일을 바꾸더라도 원하는 결과를 얻지 못하고 좌절할 수 있다. ㅠㅠ 셸 의 실행 형태 셸은 크게 세 가지 형태로 실행된다. 첫째는 interactive login shell 이고, 둘째는 interactive non-login shell, 셋째는 non-interactive shell 이다. 각각 어떤 경우에 해당되는지, 그리고 어떤 설정 파일을 읽어 들이는지 살펴보자. interactive login shell 어떤 시스템에 접속해서 shell 의 prompt 를 보기 위해서는 id 와 password 를 입력하는데, 이렇게 접속했을 때 실행되는 shell 이 interactive login shell 이다. interactive login shell 의 경우, /etc/profile 을 읽은 후 ~/.bash_profile 을 읽고 ~/.bash_login 과 ~/.profile 을 읽는다. interactive non-login shell  어떤 작업을 하다 보면 또 다른 셸을 실행시킬 필요가 있다. 이렇게 실행되는 셸이 interactive non-login shell 이다. 간단히 말해서 시스템에 접속한 후에 새로 실행시키는 셸들을 말한다. 이 interactive non-login shell 은 부모 환경을 그대로 물려받고, ~/.bashrc 를 읽는다. non-interactive shell 터미널에서 가장 많이 하는 작업 중의 하나는 스크립트를 실행 시키는 것이다. 이 때 스크립트를 실행시킬 때 작동하는 셸이 non-interactive shell 이다. 이 non-interactive shell 부모 환경만 물려받고, 별도의 파일을 읽지 않지만,...

OS/2 links

 Community Korean community : http://www.ecomstation.co.kr/ eComStation.RU : http://en.ecomstation.ru/ OS2.jp : http://www.os2.jp/ OS/2 Site Austrailia : http://www.os2site.com/ OS2World : http://www.os2world.com/ netlabs.org : http://www.netlabs.org/ IBM  IBM Redbooks : http://www.redbooks.ibm.com/ FTP : ftp://service.boulder.ibm.com/ps/products/os2/ Archives hobbes : http://hobbes.nmsu.edu/ netlabs : ftp://ftp.netlabs.org/ OS/2 Site : http://www.os2site.com/sw/ Development netlabs : http://svn.netlabs.org/   EDM/2 : http://www.edm2.com/ OS/2 Historical Programming and Toolkit Documents : http://cyberkinetica.homeunix.net/os2tk45/ IRC netlabs : #netlabs at irc.freenode.net:6667 Informations OS/2 Warp News and Rumors : http://os2news.warpstock.org/ OS/2 Warp Compatible Hardware List: http://www.os2warp.be/ Personal Homepage Paul Smedley : http://os2ports.smedley.info/ bauxite : http://bauxite.sakura.ne.jp/software/os2/ ...

OS/2 codes: How to pass linker commands to a linker using gcc

Some flags are availabile only to linkers such as ld and emxomfld. To use those flags, it is possible to use ld or emxomfld directly. But it is not recommended, because it is not compatible and comfortable. If so, what are the ways to pass linker commands to linker using gcc ? gcc has two options. One is [-Wl,], which is supported on cross-platform. The other is [-Zlinker], which is specific to OS/2. gcc with [-Wl,] passes commands separated by comma[,] to linkers such as ld or emxomfld. For example, both ld and emxomfld support -Zdll-search, which enables to find .dll as an ordinary library, but it is disabled by default. gcc does not supports this option directly. To enable dll search feature, [-Wl,] is needed, like this. gcc -Wl,-Zdll-search ... gcc with [-Zlinker] passes a command to linkers such as LINK386, ILINK or WLINK. That is, it passes commands only to emxomfld. In fact, it passes to ld as well. But an option(-O) which emxomfld understand but ld does not is prepend...

Porting to OS/2: Case #19 Windows and Odin

OS/2 and Windows are based on similar architectures. Because of these, when porting programs for other platforms to OS/2, Windows codes are very helpful. Then how about porting from Windows to OS/2 directly ? As I said above, architectures used on OS/2 and Windows are similar. So it's possible to think that porting is relatively easy. However, implementing and replacing Windows APIs are hard and boring task. Especially, porting GUI APIs is peak. Nevertheless, there is no need to be afraid beforehand. Find the way to go slowly. Implementing Windows APIs First way is to implement Windows APIs directly. When you try to this, MSDN is your friend. You should implement those APIs in according to specifications of MSDN. If you have no clues, then try googling or refer to Odin sources. Many people already implemented many Windows APIs in Odin proejct. And Odin project is being maintained at netlabs. Window Coordinate Systems When implementing GUI APIs, there is one thing whic...

Porting to OS/2: Case #18 Qt basic

Qt is a very powerful cross-platform framework. And it was ported to OS/2, but it is more or less old. Because the latest upstream version is 5.3, and OS/2 version is 4.7.3. Nevertheless, Qt4 is still very powerful and useful. In addition, bww bitwise works, who is porting Qt to OS/2, has a plan to port Qt5 as well. So I recommend to use Qt if you have a plan to create GUI programs for OS/2 rather than native PM APIs. And this has another benefits. If you don't use specific codes to OS/2, then you can create a program for other platforms with minimum modifications. This is true when porting to OS/2. That is, if some programs have no specific codes to specific OSes, they can be ported to OS/2 easily. Based on this aspect, let's find basic ways to port programs using Qt to OS/2. Basic procedures to build Qt-programs is like the following. qmake make What a simple. But sometimes, some projects requires some tasks such as configure before qmake. Or, they may use other pr...

별의 적경과 위치 쉽게 알아내기

이미지
지구과학을 공부할 때 만나게 되는 가장 어려운 부분 중의 하나가 천구이다. 그 중에서 별의 적경을 계산하고, 시간에 따라 하늘에서의 위치를 파악하려면 머리가 뽀개질 지경이 된다. 이렇게 복잡하고 어려운 까닭은 적경은 천구의 적도면을 기준으로 하고, 하늘의 위치는 관측자의 지평면을 기준으로 하기 때문에, 3 차원 입체 천구 속에서 서로 교차하는 두 개의 평면을, 머리 속에 떠올리는 것은 쉽지 않고, 게다가 종이 같은 것에 그린다 하더라도 워낙 선들이 많아지니 복잡하기 이를 데 없기 때문이다. 그럼 이대로 주저앉아서 머리가 빙빙 돌다 뽀개지기를 기다려야 하는가 ? 그래야 한다면 이 글을 쓰고 있을까? ^^ 원리는 간단하다. 하나의 평면에 방위와 적경을 모두 나타내면 된다. 너무 간단한가 ? 계속 나아가보자. 그렇다면 지평면과 적도면, 두 개의 평면 중에 어떤 평면을 기준으로 삼는 것이 좋을까 ? 관측은 관측자 중심으로 이루어지기 때문에 지평면을 기준으로 하는 것이 좋다. 다음 그림은 지평면과 적도면을 하나로 합쳐 나타낸 새로운 관측자의 하늘이다. 우선 눈에 띄는 것은 북쪽이 위쪽이 아니라 남쪽이 위쪽이라는 것이다. 이것은 일반적으로 대부분의 천체가 동쪽에서 떠서 남쪽 하늘을 거쳐 서쪽으로 지는 것을 반영한 것이다. 그리고 가운데에 있는 지평선은 하늘에 떠 있는 천체와 이미 지고 보이지 않는 천체를 가르는 기준이다. 곧 지평선보다 위쪽(남쪽)에 있는 천체는 하늘에 떠 있는 것이고, 지평선보다 아래쪽(북쪽)에 있는 천체는 이미 지고 보이지 않는 것이다. 끝으로 각 방위별로 표시되어 있는 시간은 태양의 위치를 뜻한다. 왜냐하면 우리가 사용하는 시간 자체가 태양의 위치를 기준으로 정해지기 때문이다. 예를 들어 현재 시각이 정오(오후 12시)라면 태양은 남쪽 하늘에 위치해 있는 것이고, 오후 6시라면 태양은 서쪽 지평선에 걸려 있는 것이다. 이제 여기에 적경을 적용해 보자. 적경을 알기 위해서는 춘분점의 위치를 알아야 한다. 춘분점의 위치를 알기...

SubGit 으로 만든 git 저장소에 svn 저장소의 변경 사항이 적용되지 않을 때 해결 방법

SubGit 은 git 를 이용해서 svn 저장소에 접근할 수 있는 기능을 제공하는 아주 강력한 도구이다. 하지만 가끔 svn 저장소에는 분명히 변경 사항이 있는데, git 에서는 보이지 않는 경우가 있다. 처음에는 svn 을 git 로 바꾸는 작업을 처음부터 다시 했었는데, svn 저장소가 매우 크다면 git 저장소로 바꾸는데 시간이 꽤 많이 걸린다. 그래서 좀 더 나은 방법이 없을까 생각해보다 찾아낸 것이 SubGit 의 install 명령을 다시 수행하는 것이다. 이미 있는 git 저장소에 subgit install 을 다시 수행하면 git 저장소에 아직 적용되지 않은 변경 사항만을 svn 저장소로부터 가져온다. 따라서 훨씬 시간이 줄어든다. 예를 들어, git 저장소가 ~/git/repo.git 이라면, subgit install ~/git/repo.git  을 하면, 다시 올바르게 작동한다. // ---- 2014/12/20 subgit 과 git 저장소를 원격 서버에 설치해서 쓰고 있는데, subgit 데몬이 시간이 좀 지나면 저절로 죽었다. 이게 꽤 빈번한터라, 매번 서버에 접속해서 subgit install 을 수행야 했는데, 정말 귀찮은 작업이었다. 그래서 더 좋은 방법이 있지 않을까해서 개발사에 물어보았다. 개발사의 설명은 이랬다. 일단 subgit 데몬이 죽는 이유는 로그 분석에 따르면 커널이 죽이는 것이라고 했다. 해결 방법으로는 메모리를 늘리거나 스왑을 설정하라라는 것이었는데, 관리자가 아닌 서버에 더부살이 하는 입장에서 그렇게 하기에는 힘들었다. 그리고 svn 저장소로부터 git 저장소로 변경사항들을 가져오려면 이를 위한 데몬이 실행되어야 하는데, 문제는 이 데몬이 자동으로 실행되지 않는다는 것이다. 데몬이 실행되는 경우는 두 경우라고 한다. 하나는 subgit install 이고, 다른 하나는 git push 이다. git pull 은 해당되지 않는다. 따라서 아무리 git pull 을 하더라도...

구글 드라이브에 HWP 올리기

이미지
요즘에는 많은 사람들이 안드로이드 기반 스마트 폰을 쓰고 있는지라, 적어도 한 사람당 구글 계정 하나씩은 가지고 있다. 이 구글 계정을 통해 구글의 많은 서비스를 이용하고 있는데, 그 중에서도 구글 드라이브라는 클라우드 저장 서비스를 이용할 수 있다. 계정이 하나 만들어지면 15GB 의 저장 공간이 주어지는데, 다른 유사 서비스에 비해 용량이 작은 것 같지만, 몇 가지 조건만 맞으면 저장 공간 사용량으로 인정되지 않기 때문에, 그리 작은 공간도 아니다. 그리고 계정을 원하는 만큼 만들 수 있기 때문에 사실 저장 공간이 제약되는 것도 아니다. 여러 개의 계정을 관리해야 하는 번거로움이 있지만... 저장 공간을 사용하지 않는 방법으로 구글 드라이브에 맞는 문서로 변환해서 저장하는 것이 있다. 구글 드라이브는 MS 오피스 문서를 거의 완벽하게 변환한다. 하지만, 안타깝게도 HWP 에 대해서는 지원하지 않는다. 그대로 올리면 문제 없지만, 구글 드라이브에서 직접 보고 싶은 경우에 상당히 아쉬운 점이다. 하지만 아예 방법이 없는 것은 아니다. HWP 파일을 MS Word 문서로 변환하면 된다. 첫번째는 HWP 에서 MS Word 문서로 저장하는 것이고, 두번째는 MS Word 에서 HWP 읽어 들여 MS Word 형태로 저장하는 것이다. 최신 버전의 한글은 모르겠지만, 한글 2007 에서는 수식이 올바르게 변환되지 않았다. 하지만 MS Word 에서는 올바르게 읽어들였다. MS Word 에서 HWP 를 읽어 들이기 위해서는 별도의 변환도구가 필요하다. 아래 링크를 따라가면 받을 수 있다. Microsoft Word를 위한 아래아한글 문서 변환 도구 받을 파일은 자신이 사용하는 오피스에 따라 달라진다. 오피스가 32비트(x86)용이라면 HwpConverter_x86_ko-kr.exe 를 받고, 오피스가 64비트(x64)용이라면 HwpConverter_x64_ko-kr.exe 를 받으면 된다. 잘 모르겠으면, 둘 다 받고 하나씩 설치해서 HW...

OS/2 codes: How to writes initialization/termination codes with gcc

When programming, one of the most annoying things is to write initialization/termination codes. In case of DLL, OS/2 provides the opportunity for this by _DLL_InitTerm(). However, if it is a static library, OS/2 does not provide any ways for this. Instead, compilers provides its own ways for this. Of course, gcc has its own ways. They are __attribute__((consturctor)) for intialization and __attribute__((destructor)) for termination. Here are the sample code. Colored By Color Scripter ™ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 #include  <stdio.h> __attribute__((constructor)) static   void  before(  void  ) {     printf( "constructor : before()\n" ); } __attribute__((destructor)) static   void  after(  void  ) {     printf( "destructor : after()\n" ); } int  main(  void  ) {     printf( "ma...

OS/2 codes: How to override standard functions in kLIBC

Sometimes there is a time when it is needed to override the functionality of some functions. To do this, at least two ways can be considered. Macros First is to use macros. For examples, if you want to override pipe(), then you can write the codes like this. Colored By Color Scripter ™ 1 2 3 4 5 6 7 8 9 10 #include  <io.h> int  my_pipe( int  *ph) {     some_codes;      return  (pipe)(ph); } #define  pipe(ph) my_pipe(ph) At line 7, a parenthesis is used to prevent pipe() from being expaned to my_pipe() by a macro. This way has an advantage that this can be applied to all the functions. But this has a disadvantage that this can be applied only locally. If you want to apply globally, then you should create a header for a macro and all the sources should include that header. Alias The other way is to use alias. kLIBC provides aliases for standard functions, which do not ha...

OS/2 codes: How to link statically against kLIBC

Originally, it is not supposed to link statically against kLIBC. That is, all the programs linked against kLIBC will depend on libcxxx.dll. Neverthelss, it is not impossible. Do the following. gcc -Zomf -static -o test.exe test.c -lc_omf386 Then, you can get test.exe without dependency on libcxxx.dll.

GNU Make 와 gcc 를 이용한 멀티 타겟 Makefile 만들기

예전에 GNU Make 와 gcc 를 이용한 auto-dependency Makefile 만들기 를 썼었는데, 이것은 단지 하나의 타겟만을 만들 수 있었다. 이번에는 이 부분을 개선해서 멀티 타겟 Makefile 을 만들어보자. 멀티 타겟을 지원하기 위해서는 GNU Make 의 몇 가지 함수를 먼저 살펴볼 필요가 있다. foreach 함수 foreach 함수의 문법은 다음과 같다. $(foreach var,list,text) 기능은 list 의 내용을 빈 칸을 기준으로 구분해서 var 에 각각 대입하고, 매번 text 를 확장한다. 예를 들면, l := $(foreach d,a b c d,l $(d)) 이 경우, l 은 l a l b l c l d 가 된다. call 함수 call 함수의 문법은 다음과 같다. $(call var,param,param,...) call 함수는 var 를 일종의 함수처럼 처리한다. var 뒤의 param 들은 var 의 $(1), $(2), ... 로 대체된다. 예를 들면, merge = $(1)/$(2) path := $(call merge,a,b) 이 경우 path 는 a/b 가 된다. define 지시자 define 지시자와 endef 를 통해 멀티 라인 변수를 만들 수 있다. 다음과 같이 쓰인다. define m echo foo echo $(boo) endef 만일 call 함수와 함께 쓰인다면 보통의 함수와 같은 역할을 할 수 있다. eval 함수 eval 함수의 문법은 다음과 같다. $(eval text) eval 함수는 text 의 내용을 Make 파일의 일부로 해석하게 만든다. 예를 들면, .PHONY: all define a all:     echo hello endef $(eval $(a)) 이것은 다음처럼 처리된다. .PHONY: all all: ...