예전의 OpenLook 위키에 있었던 거의 유일한 유용한 자료였던 CJK 페이지를 요즘 쓰고 있는 trac 페이지로 옮겼습니다.

여전히 덜 쓴 부분이 아직 좀 남아 있지만, 혹시 그동안 보고 싶었는데 위키에 안 올라가 있어서 못 보신 분들은 얼른 가셔서 보세용~ (언제 또 trac을 내릴지도 모르는 일 =3=3)

오늘 산 책 《좋은 것부터 먼저 시작하라》를 보던 중에 재미있는 컷을 발견해서.. ^_^

그동안 3년정도 관리해 왔던 한글 PuTTY를 이제 관리하기도 귀찮고, 업데이트도 자주 올라오고 해서 이제 주요 기능을 그냥 다 업스트림 패치를 만들어서 올려버리고 그만둘까 생각을 하게 되었습니다. :)

우선, 현재 한글 PuTTY의 주요 변경점을 보면,

• 한글 위에 커서가 올라가는 경우 커서 크기를 키움
• 한글 입력 도중에 입력창이 별도로 뜨지 않고 현재 위치에서 입력
• 환경 설정창이 한글로 나옴
• 한글 윈도우 98에서 입력이 전혀 안 되는 문제점 수정

여기서 커서 크기가 늘어나는 것은 Hung-Te Lin이라는 사람이 업스트림한 패치가 3월말에 들어가서, 이제 PuTTY에서 별도의 패치 없이도 커서 크기가 자동으로 한글 위에서 늘어나게 되어서 다행히도 이제 한글 PuTTY에서 패치를 안 해도 되게 되었습니다. :)

그 다음, 입력창을 안 띄우는 것은 사실 IME을 쓰는 곳 중에서 창이 걸리적거리는 곳은 거의 한국어가 유일하기 때문에, 아무래도 직접 패치를 할 수 밖에 없었는데, 지난 번에 좀 삽질해서 패치한 위치를 출력단에서 터미널단으로 옮긴 덕분에, 업스트림 패치를 비교적 단시간에 만들 수 있었습니다. :)

한글로 나오는 설정창과 윈98 문제는 현재 업스트림이 가능할 만한 것들이 아니기 때문에, 우선은 업스트림에서는 빼고, PuTTY를 선택적으로 gettext와 빌드할 수 있도록 하는 것을 넣어서 그것을 통해서 넣는 게 나을 것 같네요. 그래서 일단은 차후로~

그래서 일단 업스트림할 것은 제자리 입력 패치 (이른바 onthespot 패치)인데, 패치는 오픈룩에도 올려 두었습니다. 곧 들어가게 되면 이제 한글 PuTTY 다운 받지 말고 그냥 오리지날을~ :)

Hi,

I have been maintained Korean l10n fork of PuTTY for couple of
years.  Seeing the recent cursor-width change in svn head, I decided
to upstream some features of the fork.

The feature is "on-the-spot" input and it's very specific to Korean
IMEs because incremental dictionary searching is required for Chinese
and Japanese but Korean doesn't require any dictionary-based input
interactions nor IME composition window at all.  And many Korean
users feel uncomfortable for that composition windows hide terminal
context.  So I attached the patch that fixes the behavior and it
currently applies only for Korean IMEs on windows systems.

Thanks,
Hye-Shik

회사에서 워크샵을 가면서, 상황 극복을 위한 발전 방향이나 내부의 커뮤니케이션 문제같은 여러가지 것들을 토론했습니다. 지난번 워크샵까지는 그냥 먹고 놀았는데, 이번엔 진지한 토론도 하고 역시 많이 발전을.. :)

명함이나 회사 양식지 같은 여러 곳에 있는 회사의 슬로건은 "Open Source Experts"입니다. 그런데, 뭐 사실 회사가 생긴지 만 6년이 다 되어가지만, 오픈소스회사가 할 만한 일은 하나도 한 일이 없다고 봐도 되겠지요.. 전문가라면 쏙쏙 빼먹기만 해도 되남? 흐흐. 하여간 이런게 상황이 매우 어려운 회사 실정에는 호사스러운 불평일 수도 있겠지만, 그래도 아무도 얘기하지 않으면 그냥 그래도 되는 것이 되기에 용기를 내어 한번 말해 보았습니다.

그렇지만, 뭐 역시 답변은 "회사가 망하고 나서 오픈소스를 해 봐야 무엇하나", "우리나라 사정에는 오픈소스로 돈 벌 수가 없다", "오픈소스를 해야지만 오픈소스 회사인 것은 아니다" 이런 식의 늘 들어왔던 말들이었지요. 사실 이런 생각을 갖고 있는 사람들을 설득하기란 쉽지 않습니다. 오픈소스를 전혀 처음 접한 것이 아니고 이미 오해를 단단히 하고 있기 때문에 거부감을 이미 충분히 가지고 있는 상황이라 생각을 바꾸기가 쉽지가 않지요.

사실 자신이 오픈소스를 잘 알고 있다고 생각하면서 거부감을 가지고 있는 경영자들의 오해는, 회사가 오픈소스를 하면 처음부터 무조건 레드햇같이 회사의 모든 제품을 오픈소스해야 하는 줄 아는 것이 주가 됩니다. 사실 제품 전체를 통짜로 오픈소스로 만드는 지미안이나 레드햇, IBM같은 곳도 있을 수는 있겠지만, 그런 비즈니스 모델을 적용해도 회사 재정에 문제가 없을 경우에나 그렇겠지요. 반면에 Google Code나 Yahoo Search Developer Network처럼 프러덕트 전체를 오픈소스화하는 것은 아니고, 회사의 이익은 유지할 수 있으면서도 세계 개발자원의 절약에 큰 도움을 줄 수 있는 이런 오픈소스화를 할 수도 있습니다. 회사 주력 제품을 개발하면서 부산물로 나오는 것은 사실 구글이나 야후만 하는 것이 아니라 FreeBSD 소스만 보더라도 수십개의 비-오픈소스 회사가 소스를 기부해 왔고, Python 소스에서도 10여개의 회사가 자신들의 목적에 맞춰서 일정부분의 소스를 기부해 온 것을 볼 수 있습니다.

즉, 오픈소스라고 해서 굳이 목숨걸고 할 필요는 없다는 것입니다. 만약 대용량 메일 솔루션을 만든다면, 그 안에 들어간 서버 프로세스들을 위한 IPC 프레임워크를 공개한다고 해서 메일 솔루션 팔아 먹고 사는데 과연 지장이 있을까요. 오픈소스는 사실 그냥 회사의 도의적 정당성만 형식적으로 주는 것은 아닙니다. 회사의 코드들을 오픈소스화 함으로써, 회사 자체의 관리 부담이 줄어들고, 오히려 외부에서 새로운 기능을 추가해 준다던지 버그를 잡아줄 수도 있는 효과도 노려볼 수 있습니다. 또한, 해당 오픈소스 부분을 사용하는 곳이 많아지면, 비슷한 라이브러리나 모듈을 사용하는 프로그램들끼리의 호환성도 쉽게 올라가서, 오픈소스에 기여하는 회사들끼리 상호운용성이 크게 향상됩니다. 그리고, 오픈소스를 함으로써 개발자들에게는 "내가 이 회사를 다닌다. 우리 회사 라이브러리 써 봤어?" 하고 자부심을 가질 수 있어서 사기충전에도 큰 도움을 주며 새로운 개발자들을 유혹하는 긍정적인 요소가 될 수 있습니다. 개발자들 대부분은 자기 소스를 마음대로 자랑할 수 있을 때에 코드 품질이 훨씬 올라간다는 점에서 품질의 향상에도 영향을 줍니다.

저희 회사에서 점진적인 오픈소스가 진행되지 못했던 점은 물론 개발자들이 능동적으로 릴리스를 하려는 의지가 부족했던 점도 있습니다. 그렇지만, 사실 그렇게 주장을 하더라도 오픈소스 개발자들의 개발 방식과 생활 방법이나 의식은 회사 생활에는 안 맞다는 생각이 이미 마음 속 깊이 있는 관리자들에게 말이 받아들여질 수 있을 지는 의문이군요.. 그냥 며칠 안 남은 병역특례가 얼른 끝나기를.. :)

불면증 때문에 우울증도 겹쳐서 고생하는 친구가 있어서, "나는 잠이 왜 이렇게 많은가!" 궁금하기도 해서 잠에 대한 책을 하나 샀습니다. 그동안 잠에 대한 얘기는 사실 여기저기 짤막한 상식 글에 제법 많이 나와 있는 것을 보았지만, 그런 글들은 그다지 과학적인 연구없이 그냥 경험만을 토대로 얘기한 경우도 있고 체계적인 기반 지식을 얘기해 준 것이 아니라 크게 도움은 잘 안 되는 것 같은 느낌이 많았습니다. 이 책은 잠의 원리를 개략적으로 해설할 뿐만 아니라, 잠/꿈과 관련된 수많은 통용되는 상식들과 사례를 소개하고 있어서 그동안 많은 시간을 자는데 보내고 있으면서도, 정작 잠의 특징에 대해서는 잘 몰랐던 답답함을 어느 정도 해소하였습니다. ^_^

이 책에서는 앞 부분의 50페이지 정도는 정말 지루하게도 약장수처럼 자는 것이 얼마나 좋은가, 잠 안 자면 얼마나 피곤한가를 반복적으로 설명을 하고 있는데, 사실 그 부분은 어찌나 지루한지.. 그냥 건너 띄는게 나을 것 같더군요. =.=; 그 다음부터는 우선 잠의 단계에 대해서 설명하고 있는데, 보통 TV같은 곳에서 진정한 잠이라고 자주 언급을 하는 REM수면 외에도 그 바로 앞 단계인 서파수면이 그렇게 중요한 지는 처음 알았네요~ REM 수면은 오히려 거의 안 자는 동물도 있다고 하고.. (스포일러 중! 쿠쿠)

그 이후에도 이제.. 잠을 방해하는 요소인 카페인, 알코올, 니코틴 등이 어떤 방식으로 잠을 방해하는가에 대한 것, 잠을 잘 오게 하려면 체온이 올라갔다가 서서히 내려가야 한다는 점, 대부분의 사람은 일어날 시간을 미리 자기 전에 생각하면 대충 그 시간에 일어날 수가 있다는 점 등 연구가 충분히 된 결과들을 재미나게 설명을 하고 있어서 책을 놓기가 쉽지가 않네요. :)

이 책의 저자는 행동생물학을 전공한 박사임에도 불구하고, 문학 작품을 인용하는 경우가 굉장히 많은데, 거의 영문학을 연구한 사람이 아닌가 의심스러울 정도군요. 보통 컴퓨터과학 서적에서 시도때도 없이 인용해대는 앨리스 얘기도 당연히 나오고 있구요. :) 재미있었던 오스카 와일드의 일화 하나를 소개해 봅니다.

창조적인 일을 한 위대한 인물들 가운데 무수한 사람들이 올빼미였다는 사실은 무척 안심이 된다. 오스카 와일드 역시 진정한 올빼미였다. 한 친구가 오스카 와일드에게 다음날 아침 9시에 자신의 집에 들러 달라고 부탁하자, 오스카는 이렇게 대답했다.

"자네 참 대단한 사람이군! 난 절대로 그렇게 늦게까지 깨어 있지 못하네. 나는 늦어도 5시에는 늘 잠자리에 들거든."

-- 폴 마틴, 《달콤한 잠의 유혹》

수개월 전에 사이트를 대폭 개편했지만, 당시에 모자랐던 정신력으로 -.- 첫 페이지만 제대로 보이고 클릭을 조금만 하면 여기 저기 깨져 있었습니다. 친구의 얘기도 있고 해서 주말에 사이트의 깨진 부분을 메워서 이제 대충 눌러 봐도 돌아가는 사이트처럼 변신시켰습니다. :)

• 방명록 부활 - 방명록을 다시 붙이고 껍데기를 좀 덜 다른 사이트처럼 안 보이게 바꿨습니다.
• 위키위키 링크 수정 - 아직 위키 페이지들은 복구되지 않았지만, Trac으로 구성된 위키위키를 다시 링크해 놓았습니다. 아울러 CVSWeb 대신 Trac의 소스 브라우저로 링크해 두었습니다.
• "좀 더 관심이 있어요" 페이지 채움. ^.^
• 라이선스 페이지 한글로 채움. (zlib/libpng 라이선스입니다.)
• 페이징 지원 추가 - 페이지 목록이 나오는 깔끔한 것은 아니지만, 카테고리별 보기와 전체 보기에서 다음, 이전 페이지로 가는 링크를 넣고 페이징해서 볼 수 있도록 했습니다.

페이징은 희한하게도 coreblog 프러덕트 자체에는 대충 구현이 되어 있는데, 스킨에서는 전혀 사용되지 않고 있었습니다. 그래서 스킨만 좀 고치니까 잘 되는군요. :) 혹시 필요하신 분이 있으실까봐 소스를 약간 붙여넣어 봅니다.

nocomment 처리하는 부분 근처에 추가:
<dtml-unless start>
  <dtml-call "REQUEST.set('start', 0)">
</dtml-unless>

본문 끝 부분에:
<dtml-comment>이전, 다음 페이지 지원</dtml-comment>
<dtml-call "REQUEST.set('entries_total', len(rev_category_entry_items(category_id=cat_id)))">
<dtml-if "int(start) > 0">
<a href="categorylist_html?cat_id=<dtml-var cat_id>&start=<dtml-var expr="max(0, int(start) - page_items)">">이전 페이지</a>
</dtml-if>
<dtml-if "int(start) + page_items < entries_total">
<a href="categorylist_html?cat_id=<dtml-var cat_id>&start=<dtml-var expr="int(start) + page_items">">다음 페이지</a>
</dtml-if>

지난 목요일인 5월 19일 거의 1년간 하지 못했던 파이썬 마을 작은 세미나를 했습니다. 이번에는 세번째인만큼 지난 번 같은 대동 화합적인 1개 트랙로 수십명 같이 듣기 모드보다는, 오래 지속될 수 있도록 관심사와 숙련 정도에 따라 필요하신 곳에 참여하실 수 있도록 2개의 트랙을 준비해서 동시에 옆 방에서 진행하는 방식으로 바꿨습니다. 사실 100명 넘게 참여하는 세미나 같으면야 당연히 이렇게 하지만.. 겨우 10명 하면 많이 하는 곳에서 이렇게 2개로 나눈다는 것이 좀 부담스럽기는 했습니다. 쿠쿠 그런데 뭐 대충 성공! (각 트랙별로 10분 정도씩 참가해 주셨습니다.)

이번에 진행한 트랙은 2개로 1번 트랙에서는 넓고 시원하고 탁 트인 방에서 이만용이사님이 "파이썬 신식 클래스 (new-style class)"를 진행하셨고, 2번 트랙은 좁고 통풍 안 되고 더운 방에서 제가 파이썬 흑마법이라는 주제로 진행을 했습니다. 각각 1시간 30분씩 진행을 했는데, 제가 진행한 2번 트랙은 더워서 다들 파이썬에 대한 열기가 후끈후끈!! (;;;) 지난 번까지는 계속 회비를 1만원으로 했는데 매번 뒷풀이를 하고 나면 돈이 모자라서 세미나 후유증으로 재정을 고려하고 그래야했습니다. 그래서 이번에는 과감히 1만 5천원으로 회비를 올렸더니만! 뒷풀이 테이블 하나에 안주를 3개씩 시키는 호화스러운 뒷풀이를 할 수 있었습니다. 하하 다들 만족하시는 분위기라.. (비싸서 안 오신다는 분도 있었지만 ㅠ.ㅠ.)

이번 세미나에서 발표한 프리젠테이션과 소스를 올려 두었습니다. 이번에 아쉽게도 못 오신 서지원님꼐서 vnc2swf로 녹화를 하면 어떻겠냐 하셨는데, 제가 아직 사용법을 숙지를 못 해서 못했네요 --; 다음엔 꼭! :)

한동안 웹서버를 lighttpd로 외도를 했습니다만, 얼마 전에 다시 아파치로 돌아왔습니다. 역시 쓰는 사람이 적으면 같은 문제를 겪는 사람의 수가 적은 것이 크나큰 한계네요..

lighttpd를 쓰면서 즐거웠던 것은, php를 밖에다 두고 fastcgi로 쓰는 것이 일반화되어 있어서 매뉴얼에 상세히 작성되어 있었기에 왠지 분리를 했다는 뿌듯함에.. :) 그리고 프로세스 개수도 적고 해서 퍼포먼스 차이를 별로 실감하지 못하면서도 왠지 빠른 것 같이 느껴지고 그랬는데, 문제는 역시 한 1주일 쓰다보니까 발견이 되었습니다.

lighttpd를 쓰다 보면, 비동기 웹서버의 특성 상 아무래도 fastcgi나 proxy를 써서 백엔드로 많이 넘기게 되는데, 생각보다 개발자가 특이한 상황을 아직 많이 접해보지 못한 것 같습니다.

• fastcgi가 돌다가 에러가 단 1번이라도 나면, 바로 그 핸들러가 서비스 설정에서 빠지기 때문에 보안 상으로는 좋을 지는 몰라도 실제로는 수시로 뻑나서 서비스가 어렵 ㅠ.ㅠ
• fastcgi를 외부 서버로 돌리고 있을 때 서버가 죽어버리면 unknown state: 3이라는 에러로그를 무한정 뿌립니다. (하드디스크 꽉 찰 때까지!) /var에 4기가 할당했는데 왜 자꾸 풀나나 했더니.. 허헛; 이 현상은 소스를 확인해 보니까, fastcgi 비동기 접속 상태가 열댓개가 있는데 그 중에서 자주 나오는 2개만 핸들하고 나머지는 프로그램을 안 해 놨더군요.. -.-;;
• proxy도 같은 현상. unknown state 싫어싫어~

한동안은 "그래 나도 lighttpd에 이바지해야지" 하고, 앗싸 버그! 모드로 수정을 해 보았는데, 별로 하나 수정하면 또 다른데서 뻑나고 그래서.. 흐흐 쉽지가 않네요. 결국은 우리 마음의 고향 아파치로 돌아왔습니다. 돌아오고 나니 어찌나 반갑던지 ㅠ.ㅠ 대충 설정해도 찰떡같이 돌아가 주고! 그래 역시 집이 좋구나.

기왕에 fastcgi-php를 세팅한 김에, 아파치에서도 fastcgi로 돌렸는데, 역시 동적인 서비스에서는 웹 서버의 영향이 거의 없는 것이 맞는지, phpBB의 첫 페이지를 벤치마크해 본 결과 lighttpd로 돌린 것이 230 요청/분, apache로 돌린 것이 227 요청/분 이렇게 나왔습니다. 사실 벤치마크하는 도중에 CPU는 95% 정도를 php가 먹고 있었기 때문에, 정말로 웹서버는 별 영향이 없네요.. 그래 아파치 좋아~ :)

아파치에서 php-fastcgi를 설정하면서 지난 번에 했던 php 패치가 제대로 동작을 하지 않았는데, 스크립트 파일 위치를 chroot된 디렉터리를 chroot되기 전 경로 기준으로 주는 바람에 그런 것이어서, 약간 패치를 더 해 봤습니다. 아파치 php-fastcgi 쓰시려는 분들은 써 보세요. :)

최근 FreeBSD의 미래와 관련된 무척 흥미로운 (정말로!) 얘기들이 많이 나오고 있는 BSDCan 2005에서 일이 하나 터졌습니다. 인텔의 펜티엄 연산 버그 이후로 가장 큰 문제가 아닐까 하는데, FreeBSD 커미터인 Colin Percival (freebsd-update와 portsnap으로 유명한)이 인텔의 Hyper-Threading 구현의 보안 결함을 BSDCan에서 발표한 것입니다.

아직 무슨 문제인지, 고칠 방법은 무엇인지가 구체적으로 발표된 것은 아니고, BSDCan에 참가하고 있는 개발자들 간에는 활발한 토론이 이뤄지고 있는 듯합니다. 해당 문제로 인해서 영향을 받을 수 있는 것은, 다른 사용자 프로세스에 의해서 RSA키같은 사적인 정보들이 노출될 수 있다는 것인데, 아무래도 CPU상의 문제가 그런 영향을 미칠 수 있는 방법을 생각해 보면 HTT에서 같은 프로세서에 우연히 같이 올라간 프로세스가 서로 메모리 영역 보호가 잘 안 된다거나.. 알게 모르게 특수한 상황에서 레지스터가 공유돼 버리는 것이 아닌가 한번 때려 맞혀 봅니다. -.-; 그래서, FreeBSD에서는 하이퍼쓰레딩이 이제 디폴트로 꺼지는 것으로 우선 처리가 됐고, NetBSD에서는 올바른 피해가기 패치를 마련한 다음에 발표할 예정이라고 합니다. 그리고 SCO에서도 패치를 한 걸로 봐서는, OS에 큰 상관 없이 하이퍼쓰레딩을 지원하는 모든 OS에 영향을 주는 것 같군요.

흐흐흐.. 인텔 화이팅~ -O-;;;

IRC 봇 SugarCube의 주요 플러그인 중의 하나였던 지하철 플러그인이 최근에 정보 싸이트로 쓰고 있던 WebSubway가 개편을 하는 바람에 안 돌아가게 돼 버렸습니다. 한동안 고치기 귀찮아~~~을 외치며 우어우어 거리고 있다가, 휴가 중 짬을 내어 봇에서 따로 쓸 수도 있게 그냥 일반화 클래스를 만들어버렸습니다.

사용법은 대충 이런식..

>>> import pprint, SeoulSubway
>>> pprint.pprint( SeoulSubway.shortest_path(u'서울대입구', u'여의나루') )
{'bare_time': 31,
 'charge': 900,
 'distance': 12.4,
 'nummoves': 12,
 'path': [<Route path="서울대입구 (2호선) => 영등포구청 (2호선)" etime=17>,
          <Transfer station="영등포구청 (2호선)" etime=6>,
          <Route path="영등포구청 (5호선) => 여의나루 (5호선)" etime=13>],
 'total_time': 37}
>>> SeoulSubway.last_train(u'서울대입구', u'선릉')
(24, 41)

흐흐 일단 SugarCube에 적용해 놓았는데, 다른데 msnm 봇이나 웹사이트 같은 데 활용하실 분들은 마음껏 사용하세용~ (라이선스는 libpng/zlib 라이선스) 소스는 OpenLook Trac에서 받으실 수 있고, 소스코드 문서도 있습니다. (크크~)

압도적인 인기의 오픈소스 라운드 로빈 데이터베이스인 RRDTool이 1.2가 릴리스 되었습니다. 그동안의 버전이었던 1.0에서 상당히 오래 머물러 있었는데, 갑자기 1.2로 올라오고 나서는 요새 유행하는 모든 것이 새롭다 스타일이군용~ 쿠쿠~

• 베이스 그래픽 라이브러리가 바뀌었습니다. 원래 gd 라이브러리를 사용했었기에, 국제화에 한계가 있었으며 비트맵 그래픽만 가능했었지만, 이제는 기반 라이브러리가 libart로 바뀌고, freetype으로 폰트 렌더링을 하기 때문에, 이제 anti-alias 벡터 그래픽이 가능해졌고, 트루타입 폰트 (한글도 가능!)도 지원됩니다. 와와!
• 새로운 출력 포맷: 이제 기존 포맷 외에도 SVG, PDF, EPS가 지원됩니다.
• VDEF 지원: 기존에 CDEF와 DEF와 LINE등을 써서는 최대값이나 평균값 같은 것을 무척 단순하게 밖에 표현할 수가 없었는데, 이제 VDEF로 그래프 전역에 있는 다른 값들을 다룰 수가 있게 되었습니다.
• 예상값 밖으로 튀는 것 검사: Holt-Winters Forecasting 라는 것을 사용해서, 이제 원래 진행되던 것 외로 데이터가 튀는 것에 대해서 표시를 할 수 있게 되었습니다.
• COMPUTE 데이터 타입: 이제 로깅 남길 때 데이터 타입을 지정해서 로그를 남길 때 미리 계산해서 RRD에 넣을 수 있게 되었습니다.
• 외부 라이브러리 별도 배포: rrdtool에서는 그동안 gd라이브러리, png, jpg같이 외부 라이브러리들을 모두 소스에도 같이 묶고 static 링크를 하는 방식으로 배포하고 있었는데, 동적 라이브러리를 최대 활용하는 최근 트렌드에 맞춰서 이제 모두 외부 소스를 쓰며, 동적 링크를 하게 되었습니다. 그래서, 이제 컴파일하기가 간단하지가 않습니다. 으흐흐 -ㅇ-; 포트 없으면 이제 컴파일도 못하겠 -.,-;
• mmap 지원: 이제 파일 I/O를 할 때 mmap을 씁니다. mmap은 lazy on-demand I/O를 하다보니 아무래도 rrd 파일을 관리할 때 좀 더 시간을 절약할 수도 있을 것 같군요.

rrdtool 1.2로 만든 anti-alias 이미지

한편, 마티즈같이 바뀌지 않은 것이 하나 있는데.. 바로 이것! :)

checking in... and out again
ordering CD from http://people.ee.ethz.ch/~oetiker/wish .... just kidding ;-)

그런데, 오늘 어떤 사람이 py-rrdtool을 rrdtool 안에 넣으려고 Oetiker씨와 얘기를 하고 있다고 라이선스에 대해서 저에게 문의를 해 왔는데, 잘 되면 다음 1.2버전 부터는 rrdtool만 깔면 파이썬에서도 쓸 수 있게 되겠군용.~

요새 파이썬 개발팀의 주요 이슈는 PEP-340 Anonymous Block 입니다. 거의 다른 이슈들을 완전히 누르고 하루에도 수십통씩 관련 메일이 올라올 정도로 다들 열에 올라 있는데, 이 논의와 비슷한 얘기는 이전에도 몇번 있긴 했지만 딱히 어디로 결론이 나지는 않았었습니다. (PEP-310, PEP-325) 그러나 4월 중순에 C++ 프로그래머였던 사람이 조심스럽게 질문을 한 것에 대한 답글들에서 개발자들이 열을 내기 시작해서, 귀도가 4월 27일에 직접 PEP를 쓰기에 이릅니다.

이번 PEP-340은 현재 드래프트 상태이고, 확실히 의견이 모아진 것도 아니며, 그냥 실험적으로 논의되는 상태를 정리하는 것을 위한 안이지만, 이전의 유사 주제의 PEP들에 비해 상당히 여러 분야를 한꺼번에 통합하고 있고, 신선한 개념을 많이 제공하고 있다는 점에서 뭔가 유사한 것이 약간의 부분이라도 파이썬 2.5에 들어갈 것 같은 감이 듭니다. 으흐흐~ 파이썬 2.5에는 특히 AST가 거의 들어갈 것이 확실시되고 있으니까.. 그 김에 문법도 확 -.-,;;

PEP-340에서 소개하는 Anonymous Block은 파이썬 1.5 이후의 문법 상의 가장 획기적인 변화라고 부를 수도 있겠는데, 사실 많은 수의 개발자들이 2.4까지 계속 문법 변화가 많았으니 이제 2.5부터는 문법은 바꾸지 말자하고 암묵적인 동의를 했음에도 불구하고, 이번에 예전에 수년동안 있었던 문법 변화보다 더 많은 변화가 들어가 버리니.. 파이썬 중도보수파들도 이제 파이썬의 변화에 반감을 느낄 것 같기도 합니다. 으흐~

Anonymous Block이 해결하려는 이슈를 소개해 드리자면, PEP에서 언급된 대로 "좋은 프로그래머들은 자주 나오는 코드를 재사용 가능한 함수로 분리"를 합니다. 그런데, 함수나 클래스로 쉽게 분리가 되는 경우도 많이 있지만, 어떤 경우에는 루틴의 앞부분과 끝부분, 오류처리부분과 루틴의 중간 중간이 드문드문 반복되는 패턴으로 자꾸 나오는 경우가 있습니다. 예를 들면, 공유 자원의 접근을 위한 뮤텍스라던지, DB 접근을 위한 트랜잭션 처리 블럭, HTML의 헤더/푸터나 table 앞뒤 장식, 임시 파일의 생성 등 수많은 경우가 해당이 될 수 있겠는데요. 이런 경우에는 콜백으로 빼서 클래스를 생성하자니 배보다 배꼽이 크게 되고, 그렇다고 매번 풀어쓰기에는 반복되는 로직을 자꾸 중복하게 되는 찝찝한 경우가 생기는데, 이런 경우를 극복하기 위해서 Anonymous Block (현재 파이썬 메일링에서는 그냥 "block"이라고 부르고 있습니다.)가 제안되었습니다.

즉, "block"에 진입하는 시점, 오류또는 정상 종료로 인한 이탈 시점, 반복을 하는 시점, 중간에 루프의 인자가 약간 바뀌는 시점 같은 것들을 기존의 문법인 제너레이터를 확장한 것과 짬뽕을 해서 멋지게 만들어 보자는 것이 요점입니다. 2.3부터 지원되고 있는 제너레이터는 이미 상당히 다양한 용도에 사용할 수 있는 성공한 문법이지만, next 메쏘드에 인자를 전달할 수가 없어서, 상태 관리가 매우 힘들다는 점이나 try: finally 블럭이나 try: except 블럭을 yield와 걸쳐서 사용할 수 없어서, 자원의 정상적인 해제가 불가능하다는 점에서 아쉬움이 있었는데 이러한 문제점도 여기서 완전히 해결되었습니다.

현재 상태에서 PEP-340에서 변경하는 기본 statement 변화는 이런 것들이 있습니다.

• __next__ 메쏘드 신설: 기존의 이터레이터 프로토콜에서는 __next__가 아니라 next메쏘드를 쓰고 있었는데, 이 이름이 범용으로는 아무래도 맞지가 않았기에, __next__로 새로운 메쏘드를 신설하고, __next__에 이제 인자 1개가 None이 기본값인 옵셔널 인자로 들어갑니다.
• __exit__ 메쏘드 신설: 이터레이터 프로토콜에 자원 해제를 위한 메쏘드가 없어서, 그동안 lock 해제 같은 것이 매우 곤란했었는데, 그 경우를 위해서 예외 발생 여부에 상관없이 항상 호출되는 __exit__ 메쏘드를 새로 만듭니다.
• next() 빌트인 함수: i.__next__()라고 맨날 쓰기에는 너무 보기가 안 좋아서, next(i)로 사용할 수 있도록 빌트인 함수가 신설됩니다.
• for 루프 변경: for 루프의 정의가 변경됩니다. 아래의 인자 있는 continue나 탈출 함수 호출을 위한 정의 변경이고, 예전 사용법으로 쓰는 경우는 똑같습니다.
• continue 인자 추가: continue 키워드 뒤에 이제 인자를 붙일 수 있게 되었습니다. continue 키워드 뒤에 인자를 쓰는 경우에는 바깥에서 돌고 있는 for또는 "block" 블럭의 이터레이터에게 전달됩니다. 즉, for 루프의 본문과 이터레이터가 직접 통신이 가능하게 되었습니다.
• Anonymous block 추가: 아직 이름이 정해지지 않은 (아직 "block"이라고 부르고 있습니다.) 새로운 블럭 키워드가 추가됩니다. 이 키워드는 for과 유사한 목적으로 사용될 수도 있지만, 이터레이터 인자를 항상 대상으로 하고 있다는 점에서 좀 다릅니다. 자세한 설명은 아래에서..
• 제너레이터 예외 처리: 이제 제너레이터의 yield statement가 try: except 블럭 안에도 들어갈 수 있게 되었으며, try: finally 블럭 안에도 들어갈 수 있습니다.
• yield statement 리턴값: 제너레이터의 __next__로 들어오는 인자를 받기 위해서 이제 yield statement가 들어온 값을 리턴합니다.

대충 훑어봐도 엄청난 변화임이 확실히 느껴지는데, 이게 아직 확실히 정해진 것은 아니니 허어억~ 하고 미리 놀라실 필요는 없습니다. (나중에 들어가면 그때 놀라면;; -o-) Anonymous Block을 사용하는 예제로 가장 많이 나오는 DB 트랜잭션 처리 같은 경우에는 이렇게 됩니다.

def transaction(conn):
    cur = conn.cursor() # 이 부분은 제너레이터 생성시 실행
    cur.execute('BEGIN WORK')
    try:
        yield cur # 최초 인자로 한번 넘겨 줌
    exception:
        cur.execute('ROLLBACK') # 블럭 안에서 예외 발생 시
    else:
        conn.commit() # 블럭 안에서 예외 발생 없이 종료

# 이 아래가 실제 실행 시작점
block transaction(conn) as txn:
    txn.execute('SQL~ SQL~~~')

그리고, 이제 yield가 리턴값을 갖을 수 있기 때문에 유사-클로져나 유사-코루틴을 이제 쓸 수가 있게 되었습니다. 예를 들어서, 이런 코드가..

def accumulator(default=0):
    sum = default
    while True:
        sum += yield sum  # 반복하면서 인자들을 모두 더함

block accumulator(0) as sum:
    # 현재 총합을 보여주고 새로 더할 값을 받음
    v = input('%d >>> ' % sum)
    if v >= 0:
        continue v # 0 이상의 수가 들어오면 더하고 계속
    else:
        break

흐흐.. 결국 껍데기 부분의 루틴 분리에 획기적인 개선을 가져올 수 있는 좋은 도구가 될 수 있을 만한 것 같이 보입니다. 여전히 수많은 이슈들과 특히 키워드 이름을 무엇으로 할 것인가 등의 많은 문제들이 남아있지만, 아무래도 파이썬 2.5에 들어가면 가장 멋있을 것 같은 기능임에는 틀림이 없군요. :) 문법 변화라는 점에서는 원래 예정과는 좀 다르게 간다는 점에서는 약간 찝찝한 감이 있긴 하지만.. 뭐 이제 류창우님의 말씀 대로.. 파이썬도 C++이 가던 길을 걷고 있는 건지도.. (먼산)

얼마 전에 회사에서 새로운 서버를 세팅하면서, 데비안에 없는 패키지 몇 개를 깔끔하게 설치하기 위해 방법을 알아보던 중, 회사 동료인 상현씨의 조언으로 checkinstall를 이용해서 설치하게 되었습니다. checkinstall은 인스톨하는 도중에 preload된 동적 라이브러리가 파일 변경사항을 로그로 남겨서, 그 로그를 기반으로 마치 패키지를 이용해서 깐 것처럼 해 주는 도구이더군요. 물론 바이너리 패키지도 만들어 주고 해서, 패키징되지 않은 프로그램을 임시로 재빠르게 깔아야하는 경우에 매우 편리했습니다.

사실 예전에 autoplist.py라고 ktrace기반의 pkg-plist 자동 생성기를 만들었습니다. 그런데, 당시 FreeBSD의 베이스가 정적 링크되어 있었기에 LD_PRELOAD 트릭을 사용할 수가 없어서 ktrace를 기반으로하다보니 너무 부하가 심해서 mozilla같은 대형 포트를 깔 때에는 거의 5분 이상이 걸리는데다 로그를 남기는 하드디스크 용량도 너무 많이 들고 해서 아주 간단한 포트 외에는 쓰기가 힘들었습니다.

FreeBSD는 그래도 간단한 임시 포트를 만들기가 데비안에 비해서는 쉬운 편이긴 하지만, 아무래도 pkg-plist 만드는 압박이 있기에 FreeBSD에도 그런 것이 있으면 삶을 활기차게 사는 데에 큰 도움이 되겠구나. 하는 생각이 들었습니다. :) 이제 FreeBSD도 베이스가 완전 동적으로 되었기에, FreeBSD 사용자도 이제 젖과 꿀이 흐르는 자동 plist 생성의 세계로! 그런데, 우선 인스톨 로그를 위한 sysutils/installwatch포트가 워낙 오래된 것이어서 그런지, 5.x에서는 log 심볼의 중복이라던지 여러가지 문제점으로 계속 버스에러로 죽었는데 그 문제를 약간 추적해서 수정해서 메인테이너에게 보냈습니다. (아직 커밋되지는 않았습니다.)

그래서 그걸 이용해서 결국 주말에 pkg_trackinst와 pkg_genplist를 LD_PRELOAD기반으로 만들었습니다. 우선, pkg_trackinst는 패키징이 안 되어있는 소프트웨어를 make install할 때에 당시에 설치되는 파일들을 분석해서 자동으로 패키지로 설치한 것처럼 만들어주고 바이너리 패키지도 만들어서 다른데서도 똑같이 설치할 수 있도록 만들어주는 도구입니다. 그리고, pkg_genplist는 다른 패키징은 다 끝나고 pkg-plist파일만 생성하면 끝나는 상태에서 pkg-plist를 자동으로 생성해 주는 도구입니다.

pkg_trackinst는 오늘까지 만든 부분에서 거의 잘 돌아가고 있지만, 아직 pkg_genplist는 mtree를 사용하지 않고 있어서, 중복된 파일도 막 올려대고 특히 manpage쪽이 문제가 많이 있습니다. 그렇지만, 주말도 거의 끝난데다가.. 다른 시스템들에서도 잘 돌아가는지 보고 싶어서 일단 버전 0.1을 릴리스했습니다. (파이썬 2.4, FreeBSD 5.2이상이 필요하고, 앞에 언급된 installwatch 포트 패치가 적용되어 있어야 합니다.)

패키지 만드는 법이 귀찮지만 pkg_delete는 하고 싶은 분이나 plist 만드는 것이 귀찮아진 분들 한번씩 테스트해봐 주세용. :)