happyhacking

이제 슬슬 기나긴 솔로 생활도 탈출하고.. 정상인으로 돌아가기 위한 계획의 일환으로 몸무게 정상화 작전을 조금씩 해보려고 생각을 하고 있습니다. 그래서, 좀 더 과학적인 모니터링을 위해서 rrdtool로 몸무게 그래프를 만들었습니다.

이 그래프를 이용해서 심각하게 분석을 해 보니까, 회사에서 밤새는 날 집중적으로 체중이 불어서 그 이후에 슬금슬금 내려오다가 또 밤새면 팍~ 오르고 그런 패턴이군요.. 결과적으로는 회사에서 밤을 안 새던가.. 밤새면서 뭘 먹지를 말던가 해야겠습니다. ㅠ.ㅠ

아직은 직접 몸무게를 재서 rrdupdate를 수동으로 해 줘야 하지만.. 앞으로는 크론으로 하루에 한번 자동으로 자는 사이에 몸무게와 체지방을 재서 기록해주는 날이 오기를~ 혹시 관심있는 분은 OpenLook CVS에서 다운 받아서 설치해 보세용~

프로젝트 “수정”에서 동기를 얻어, 프로젝트 “나영”을 시작했습니다. (우히히히) “나영”은 “수정”과 마찬가지로 또 다른 넘쳐나는 블로그 시스템 중의 하나로, 파이썬 기반의 MT클론을 목표로 느슨하게 벽돌쌓기식으로 개발될 예정입니다.

아직은 구조 및 기능 디자인 중이고, 회사에서 휴일에 놀게 해 주면 진행이 좀 더 빨리 될 예정입니다.

시작 기념 인터뷰~

질문

왜 굳이 MT나 수정같은 좋은 블로그가 많이 있는데 또 파이썬으로 만들려고 그러나요?

답

그냥 만들고 싶어서요. -ㅇ-

질문

그것 참.. 뭐 하고 싶어 하는 일이니 말리지는 않겠습니다. –; 그런데 왜 프로젝트를 BerliOS에 열으셨나요? Sourceforge도 있고 KLDP.net도 있고 좋은 곳이 많은데요.

답

그것은!! 그것은!!! BerliOS가 현재 대형 프로젝트 사이트 중에서는 유일하게 SVN을 지원하기 때문입니다. svn mv에 맛들린 사람은 아무래도 CVS로 돌아가기가 곤란하죠? ㅋㅋ

질문

아.. 그렇다면, 프론트엔드 구조는 어떤 식으로 갈 건가요? 혹시 Zope로 만들어서 자기 혼자 쓰려는 건 아닌가요?

답

프론트엔드 계층 뒤에 Quixote를 붙일 예정입니다. Quixote는 프론트 엔드에 mod_python, twisted, cgi를 모두 지원하기 때문에 당근 “나영”도 다 지원을~ 이히힝

질문

오.. 쌈빡하군요. 그럼 데이터베이스는 어디에 저장되는 건가요? 기존에 하던 대로 파일에 다 저장해버릴 심산인가요?

답

흐흐흐. 아.. 최근에 PostgreSQL을 해 보면서 RDBMS에 필을 받았습니다.;; 그래 사람들이 이런거 쓰는 이유가 있었군! 그래서, MT처럼 퍼시스턴스 계층을 추상화해서 파일DB뿐만 아니라 PostgreSQL과 MySQL, 그리고 요즘 인기가 하늘을 찌르는 SQLite도 지원할 작정입니다.

질문

아아.. 당신도 이제 성격이 많이 죽었군요. 그렇다면 페이지 테마는 어떤 식으로 지원할 예정인가요? pyblosxom이나 MT처럼 간단한 치환 정도로?

답

아뇨. 원래는 ZPT로 밀어붙일 계획이었는데, Quixote를 프론트엔드로 쓰자면 아무래도 위젯 기반으로 가게 될 것 같아서. Quixote를 쓰는 다른 프로젝트를 좀 더 연구해 본 다음에 그냥 대세를 따를 작정입니다. 흐흐흐

질문

역시 별 수 없군요 ㅎㅎㅎ. 블로그 시스템들은 대충 정적 페이지를 만들어주는 녀석들과 동적으로 서비스하는 걸로 나뉘는데, 요즘은 아무래도 동적으로 서비스하는 게 우세인 듯 하죠? “나영”은 어떤 방식을 채택할 것인가요?

답

얼마전에 MT를 깔아보고 참 감동 받은 것이 정적 페이지 제너레이션이었습니다. 제 블로그만 해도 스팸 메일 주소 긁어가는 봇들이 한번 닥치면 아주 거의 서버가 죽을 지경으로 CGI가 뜨는데.. ㅠ.ㅠ 정적 페이지라면 이런 문제가 없어질텐데 말이죠 흑흑.. 가급적이면 정적페이지로도 웬만한 기능은 동작하도록 하고, 전부 동적으로 생성할 수도 있는 MT방식 그대로를 따를 작정입니다.

질문

아아.. 대단하군요. 지금까지 들은 말을 종합해 보면 아무래도 10년짜리 프로젝트를 시작하려는 것같은 분위기가 물씬 나는데, 당신의 전적으로 과연 릴리스나 한 번 할 수 있을지 걱정 되는데요?

답

하하하.. 네.. (.. 다소곳 –;)

질문

그나저나 왜 프로젝트의 unix name이 na0입니까? 나-제로라고 읽으라는 뜻인가요?

답

nayeong 하면 아무래도 좀 길어서 mt같이 짧은 애칭을 써보자 하고 na0로 했습니다. 앞으로 홈페이지에 열심히 써 놓아야죠. 흐흐 “How to pronunciate na0?”: Say, “Nah-Young”! You must remember that it’s not pronunciated “Nah-Zero”. …. (문법이 맞는지는 모른다 –;)

질문

예. 부디 아무쪼록 10년 안에 프로젝트를 꼭 완성하시길 바랍니다.

답

고맙습니다. (_ _)

다운로드 6000의 인기 소프트웨어 한글 푸티 0.55.h1이 릴리스 됐습니다. 메인스트림 PuTTY의 예전 버전에서 발견된 보안 버그로 인해 조급해 하시는 분들이 많아서 좀 일찍 작업을 했습니다. 이번 업데이트는 그래도 비교적 벤더 임포트 이후에 머지하는데 컨플릭트가 하나밖에 안 나서 간단한 것이었지만 그래도 awkn`n님께서 많이 도와주셔서.. 이히히

이번 한글푸티 릴리스부터는 ssh.c의 한글 번역을 모두 제거했습니다. 여기 ssh.c에서는 터미널에 직접 출력을 하게 되는데 푸티는 자체적으로 다국어 지원이나 실시간 인코딩 번역같은 프레임웍을 전혀 갖추고 있지 않기 때문에 한글 번역을 해 봐야, 터미널 인코딩이 CP949가 아니면 제대로 안 돼서 어쩔 수 없었습니다. 0.55의 주요 기능을 보니 아랍어 지원과 오른쪽에서 왼쪽으로 쓰는 언어 지원 (bidi)가 추가되고 있는게 다국어를 제외한 다른 다국어 지원은 정말 대단하네요… 다음 한글 패치버전부터는 꼭 멀티 플랫폼도 꼭 지원하도록.. (..)

fender옹의 뽐뿌질에 혹해서 뽀대 데스크탑의 결정체 gDesklets의 IRC 디스플레이 국제화 패치를 했습니다;; HanIRC는 utf-8이 아니라 cp949를 쓰다보니 아무래도 서양사람이 만든 gDesklets-irc가 제대로 돌아가기는 힘들었는데, 아무래도 gdesklets 센서가 파이썬이다보니 제법 쉽게 패치할 수 있었습니다.

gDesklets의 좋은 점은 배경에 녹아있다보니 아무래도 회사원을 위한 플러그인이 아닐까하는! (배경을 한참 보고 있어도 뭔가 채팅하는 것임을 눈치채기가 쉽지가 않다 -.-!!) 입력 창도 마우스가 위로 올라가야지만 나오고.. 아무래도 원 저자도 회사에서 몰래 IRC하는 사람이 아닌가 싶군요 -o-

전체 보기

고친 것은~

• 서버 인코딩 설정, 변환 지원 추가: 요 부분은 Twisted가 lineReceived, sendLine 메소드를 오버라이드 할 수 있게 만들어 놔서 다행히 쉬웠습니다~

• 유저네임 바꿀 수 있게: HanIRC는 유저네임에 한글 쓰는 것을 허용하지 않는데, Twisted의 IRC 프로토콜은 유저네임에 닉네임을 그대로 쓰게 되어있어서, 한글 닉네임을 쓰면 접속을 거부하는 문제가 있었습니다.

• 패스워드 지원: irssi proxy같은 것에 붙으려면 아무래도 패스워드 입력할 수 있게 해야~

• 다국어 지원: 누가 어느 방에 들어갔습니다. 같은 메시지가 gettext처리가 안 돼 있었는데 고쳤습니다~

• 이스케이프 버그 수정: 토픽에 <>가 들어가면 pango 태그 에러가 와장창 뜨는데 escape하도록 고쳤습니다. 외국 사람들은 토픽에 <>를 안 쓰는 것일까요? ;;

• 글자 제대로 짜르게: 몇몇 부분에서 utf-8 문자열을 그냥 막 짜르게 했는데. str.split()을 하면 0xa0으로도 짜르게 되기때매 UTF-8에서 0xa0이 들어가는 부분에서 utf-8 문자열이 망가집니다. 요 부분은 유니코드로 쓰도록 고쳤습니다.

• 한국어 번역추가: 흐흐흐

패치는 업스트림 했으니 곧 반영 되겠죠? 패치 받기 한국어 번역 받기

요즘따라, x11/gnometerminal 에서 editors/vim 을 쓰다가 나오면 터미날 그러면서 그 다음부터 글자들이 다 깨져버리는 현상이 있었습니다. (흐흑 나만 그런건가 ㅠ.ㅠ)

그래서 늘 vim갔다가 오면 reset; stty erase ‘^?’ 해줘야하는데.. 어찌나 불편한지.. 그러나, 귀찮아서 그냥 늘 그렇게 쓰다가.. 드디어 더는 못 참겠다 해서 script 로 로깅을 해봤습니다. 그랬더니 바로 ISO-2022의 KS X 1001을 GL에 매핑하는 코드인 ESC $ ( C EM9L3N 을 출력하고서는 다시 GL을 ASCII로 안 돌려놓은 것.. 흐흑 그래서 그 다음부터 나오는 코드를 전부 그놈터미날이 KS X 1001이라고 가정해버려서 그런건데.. EM9L3N은 GL을 GR로 올려놓으면 ‘터미날’이 됩니다. 그런데, 그놈 터미날 문제인지, vim문제인지.. 아니면 또 다른 녀석의 문제인지 추적하기가 귀찮은 나머지.. ;; -ㅇ-; 그냥 임시 땜빵으로 alias vi=$HOME/bin/vimwrap하고서는 vimwrap에 다음 스크립트를 넣어버렸습니다.

(^[는 ctrl-v ctrl-[)

으흐.. 일단 되기는 하는데.. 나중에 시간날 때 다시 자세히 해 봐야겠네요;;

지지난주에 갑자기 TV를 보고싶어져서, 시그마 TV라는 TV 카드를 샀습니다. 흐흐 덕분에 거의 TV 중독증세가 슬슬 –;

그런데, 기본 프로그램을 좀 써보니 이게 원래 쓰던 사람과셈틀 것 보다 몇개가 상당히 불편한 것입니다. 항상 맨위에가 볼륨조절만 하면 풀리고 (정확히는 OSD 윈도우를 메인 윈도우 위로 임시로 올리고 내리다가 풀림) 리모콘으로 컴퓨터를 못 꺼서, 꼭 누워서 TV보다가 컴퓨터 끄러 와야해서.. 어찌나 불편한지.. 흐흐; 그리고 채널 돌릴때도 채널이 수십개 되다보니 돌리려면 참;;

그래서, 필요함은 삽질의 어머니.. 마그마TV를 간단하게 만들어 봤습니다. 주요 기능은

• 리모콘으로 리부팅, 윈도우 끄기 가능

• 리모콘으로 채널 메모리 가능 (바로가기)

• 리모콘으로 프로그램 실행 가능 (외부 스크립트 연결)

• 시그마TV 항상 맨위에 풀림 방지 기능

므흐흐. 일단 1.0에서는 이정도로 하고, 나중에 시간날 때 다음 버전에서는 SigmaTV를 안 띄우고도 동작할 수 있도록 하는 것이나, 훌륭한 오픈소스 TV프로그램인 DScale 지원, 메신저창 임시로 확대해서 보여주기 등 기능을 넣어볼까 합니다. 므흐흐~;

Zope코드를 웹에서 좀 고치다 보니까 textarea에서 코딩하기가 너무 번거로워서 Mozilla의 URL 클릭이나 textarea 수정을 외부 에디터로 빼주는 장난감인 Mozex로 한번 써 봤습니다. 와와 gvim이 뜨고 아주 좋군! 하는데 한글이 우루루 다 깨지는 것.. 그러니까.. “한글”은 바이너리로 5C 00 이 되는데 즉, D55C AE00이 lower 8bit로 짤린 것이지요. 흐흐흑. 그래서, 모질라 자바 스크립트를 한참 삽질을 할까 해보다가, 역시 구글님에게 물어보기로 했습니다.

역시나 벌써 해결한 사람이 있군요.. 으흐흐.. 저기 있는 대로 해보니 한글이 잘 나옵니다.

기왕 고치는 김에 mozex 서브 메뉴로 안 내려가고 바로 메뉴가 뜨게 XUL도 좀 고쳐서 jar를 묶어 봤습니다. 필요하신 분은 써보세용~

• X11용 (인코딩은 UTF-8로 되어있음)

• Win32용 (인코딩은 EUC-KR로 되어있음)

얼마전에 파이썬을 이리저리 컴파일하고 놀다가, 얻은 팁을 하나 씁니다.

일반적으로 뻔히 나오는 NULL 포인터 체크나, 범위 검사 같은 조건절 같은 경우에 한쪽으로 가는 확률은 극도로 적습니다. 따라서, 이런 경우에는 분기가 많이 되는 쪽이 더 빨리 실행되도록 최적화를 하는 편이 좋은데, C 언어에서 뭔가 이런 걸 정해주는 문법적인 도구가 없기때매 컴파일러가 제 멋대로 판단을 하죠. 그런데, 언제 생겼는지 (아마 꽤 됐겠지만;;) gcc에도 브랜치 통계를 기반으로 한 최적화가 있더군요. 아주 간단합니다. -fprofile-arcs를 주고 컴파일을 한번 해서 실행하고, 그 옵션을 빼고 -fbranch-probabilities 를 주고 다시 컴파일하면 됩니다. 먼저 한번 실행하는 건 통계 자료를 모으기 위한건데 .da 확장자를 가진 파일들이 우두두둑 생성됩니다.

파이썬을 컴파일할 때에는 OPT=”-fprofile-arcs -O3″ ./configure 해서 한번 컴파일하고 pystone을 한번 실행한 다음에, OPT=”-fbranch-probabilities -O3″ ./configure 해서 또 컴파일하면 대충 모듈 빼고는 그냥 다 됩니다. 므흐흐 그래서, 이렇게 컴파일한 결과! pystone이 17210에서 21057로 올라갔습니다. 공짜로 22% 향상! 꺄아. 히히

아무래도 OpenSSL이나 아파치 같은 것들도 브랜치 확률 정보를 줘서 컴파일을 하면 좀 더 빨라질 것 같은 예감이 듭니다.. 근데 이건 아무래도 컴파일도 두번 해야 하고, .da 다루기가 까다로워서 바이너리 패키지 같은 데 쓰기는 좀 어렵지 않을까 하는 생각이 드는군요. ^_^

;;;; (앗;;)

에고서핑(egosurfing)을 늘 즐기는 퍼키군… (구글에서 자기 이름치고 낄낄낄거리는 ㅂㅌ모습을 상상하지 마세요;; ㅠ.ㅠ ) 급기야.. 자동으로 에고서프 검색 결과 개수를 그래프로 그릴 수는 없을까 고민하던 와중.. rrdtool을 붙잡고 해보기로!;; 결국 그렸습니다 으흐~; 6시간에 한번씩 크론이 떠서 검색하고 그래프를~

여기-> GoogleStatistics

소스도 올라가 있으니 심심하신 분 같이 해봅시다; -O-;

지난 8비트가 아닌 char 사건 때 C 타입이 그동안 알아왔던 것과는 다르구나 하는 느낌이 있었는데.. 새로 다른 쓰레드에서 IPv4 어드레스같은 용도를 위해 고정된 크기의 표준 타입이 있으면 좋겠다는 제안에 답변을 받으면서 C 타입을 새로 공부해야겠다는 생각이 들었습니다. 으흐흐;;

원전의중요성에서도 누차 강조됐듯, 백날 C 책을 읽어봐야.. ANSI/ISO C 문서를 안 읽고서는 C를 안다고 말하기가 부끄러운 것인 것을 이제서야 깨닫게 되었다는.. ㅡ.ㅜ (진짜 원전이야 K&R white book이기는 하지만, 아직까지 K&R 문법만 지원하는 컴파일러는 대형 메인프레임/유닉스 서버에서나 볼 수 있는 것이니까;;)

하여간, 찾아서 본 ISO C 문서에서의 바이트 정의는 이런 것이었습니다.

byte addressable unit of data storage large enough to hold any member of the basic character set of the execution environment (실행 환경의 기본 문자 세트 전체를 담을 수 있을 만한 충분한 크기를 가진 주소 지정이 가능한 데이터 저장 공간의 크기)

• NOTE 1 It is possible to express the address of each individual byte of an object uniquely. (각각의 바이트는 주소로 표현될 수 있다.)

• NOTE 2 A byte is composed of a contiguous sequence of bits, the number of which is implementation defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. (바이트는 연속된 비트들로 조합되어있는데 그 수는 구현에 따라 정의된다. 가장 낮은 비트를 low-order bit라고 부르고 가장 높은 비트를 high-order bit라고 부른다)

즉, 그동안 수많은 입문서, 교과서, C 관련 서적, 상식서적, 수험서적에서 나왔던 “바이트는 8비트를 묶은 것을 1바이트로 부르는 단위다.” 이런 것은 쌩판 거짓말이었던 것입니다. ;; 그리고, int, short, long등의 정의도 “16비트 컴퓨터에서는 16비트임” 뭐 이런 것과는 차원이 다른, 그냥 char 크기의 n배이다. 뭐 이런 정의 밖에 없다는 것을 발견할 수 있습니다. (크기는 구현하는 사람 맘대로..) 그런데, 진짜 크기를 구체적으로 지정할 수 있으면 얼마나 좋을까하는 생각에, 좀 더 찾아보니 POSIX 확장 헤더인 줄로만 알고 있었던 stdint.h와 inttypes.h가 ANSI/ISO/IEC C99에도 있는 것을 발견! (stdint.h는 7.18, inttypes.h는 7.8에) stdint.h와 inttypes.h에 있는 타입들은 extended integer types라고 부른다는데, stdint.h에는 int16_t uint32_t 이런 타입들이 정의되어있고, inttypes.h에는 fprintf 류 함수를 위한 PRI 시리즈와 fscanf 류 함수들을 위한 SCN 시리즈 매크로가 있는데, PRIdLEAST32 (fprintf의 %d에서 사용 가능한 가장 작은 32비트 타입), SCNuFAST16 (fscanf의 %u에서 사용 가능한 가장 빠른 16비트 타입) 이런식이네요..

ANSI/ISO/IEC C 문서는 ANSI 홈페이지에서 30달러에 파는데, ISO 워크그룹 홈페이지에서 마지막 드래프트를 공짜로 받을 수도 있습니다. 흐흐;;