libgmail 프로젝트에서 gmail을 위한 smtp, pop3, ftp 프락시를 만드는 것을 보고도 상당히 충격을 받았지만, 오늘 #perky의 Burnhard님께서 보여준 이 프로젝트를 보고서는 패닉에 빠져서 ~( _-_)~

gmailfs는 리눅스와 SunOS에서 유저랜드측 프로세스에서 파일 시스템을 제공할 수 있게 하는 FUSE를 기반으로 구현된 gmail 파일시스템입니다. 그리고 당연히 구현은 파이썬으로 되어있지요~ 흐흐; 이것 만든 사람은 이틀밖에 안 걸렸다니 참, 이거 libgmail의 위력이란~

저자가 올린 스크린샷을 보면 아이고 ;_; 흐흐 FUSE가 BSD를 지원 안 해서, 테스트 못 해보는게 참 한입니다. ㅠ.ㅠ 이제 FreeBSD책도 나오고 했으니 파일시스템 부분을 공부해서 프비 portalfs 부활운동을..

Boo에 이어 또 다른 .NET 기반의 파이썬 비슷한 언어가 발표되었습니다. 얼마전 Prothon도 .NET 기반으로 옮긴다고 했다가, Guido가 눈물로 애원해서 CPython기반에 확장으로 옮기는 것으로 됐는데, 요즘 .NET 기반 언어들이 정말 많이 나오는 걸 봐서 확실히 이제 슬슬 붐이..

Boo는 파이썬을 기반으로 자기 나름대로 컴팩트한 언어를 새로 구축했는데, 보통 많은 사람들이 요청하는 for ... as나 print의 내장함수화, using: (with:) 구문 같은 걸 도입하고 있다는 점에서 신선합니다. 그런데, 이번에 새로 나온 PyCs의 경우에는 C# 흉내를 내겠다고 하고 있는데, 기본적인 문법틀은 Prothon의 것을 따오고 있습니다. 아무래도 Prothon이 .NET으로 옮기겠다고 했다가 말아서 그 영향으로 분리가 된 것 같은데, Prothon외에도 Microsoft의 C-Omega의 컨커런시 모델이나 내장 XML/SQL 지원을 참조해서 디자인하겠다고 하니, 뭔가 웹 스크립트용으로 갱장히 간편한 언어가 나올 듯 합니다. 흐흐.

점점 파이썬 관련 언어의 구현이 많아지고 있어서 앞으로 Python 3000이 나오면, CPython이 널리 쓰이는 유일한 파이썬 구현이 아니게 될지도~~

작년 여름에도 그랬듯, 여름만 되면 FreeBSD와 Python 양쪽에서 활발한 릴리스 엔지니어링이 일어납니다. 아무래도 유럽사람들의 무진장 긴 (보통 1달) 휴가가 대체로 여름이라서 그런지도 모르겠군요~ 흐흐

하여간 이번에 FreeBSD는 5.3 베타에 이미 들어가서 곧 베타 2가 나올 예정이고, 빠르게 베타가 속속 나와서 결국 9월 3일에 포트 프리즈, 9월 17일에 RC 패키지 빌드, RELENG_5_3 브랜칭이 됩니다. 현재 남은 문제 중에서는 우선 어제 디폴트로 네트웍 드라이버에서 자이언트 락이 빠진 것과, 몇달 전에 들어왔던 preemptive mode를 켜는 경우에 아무데서나 막 행돼버리는 문제 같은 것이 아무래도 결정적이 될 듯하지만, 5.3이 전반적으로 수개월동안 꽤 안정적이었기 때문에, 별 문제 없이 10월에 5.3-RELEASE와 동시에 5.3-STABLE 브랜치가 나올 수 있을 듯 합니다. 포트에서는 xorg가 들어온 지 꽤 지나서, 처음 나왔던 문제들은 대체로 다 해결된 편이고, 5 브랜치가 워낙 오래된 브랜치라서 포트에서도 마찬가지로 큰 이슈는 없을 것 같습니다. 아쉽게도 Python 2.4 final이 적어도 10월은 되어야 나올 수 있을 예정이라, FreeBSD 5.3에 Python 2.4가 포함되지는 못할 것 같네요. (작년에 5.1에 2.3이 못 들어갔던 것과 같은 상황 Y.Y)

파이썬은 2.4의 세번째이자 마지막 알파 릴리스인 2.4a3이 9월 3일 릴리스 예정입니다. 2.4a3에서는 cjkcodecs와 관련되어서는 옛날 C 컴파일러들에서 돌아가는 문제가 수정되었고, 그 외에는 별 국제화 이슈에서 수정된 것은 없을 예정입니다. (u'한글'이 IDLE에서 되게 해야하는 문제가 있는데.. --; 이거 마비노기 때문에.. ;;) 그 외에는 데코레이터가 엄청난 반대에 부딪혔지만 아무래도 귀도는 그냥 밀어붙일 태세로 보이고, 전체적으로 버그 패치만 들어갔으며 부가적으로 지원된 특별한 기능은 없습니다. (FreeBSD 6 지원도 들어갔습니다. ) 2.4a3이후에는 베타 릴리스가 2개정도 나오고 RC 릴리스 1개 이후에 바로 파이널 릴리스가 나와서 최종적으로는 10월중에는 나오지 않을까 싶습니다. 그 다음엔 2.5, 2.6.. (다음엔 3.0? =3 -O-)

당신의 머리카락에서 DNA를 추출해 클론을 만들었다면 그는 과연 당신인가, 아닌가?

이런 전산쟁이가 들으면 뻔한 얘기를 갖고 혼동하는 사람들을 클론 관련 토론을 보면 자주 보게 되는데, DNA는 클래스이고, "당신"은 인스턴스이기 때문에 당연히 다르고, 인스턴시에이션 된 후에도 꾸준히 어트리뷰트들이 바뀌겠다는 뭐 이런 생각을 하고 있었습니다. -O- 뭐 그래도 생명 복제를 어디까지 허용해야 하는가에 대한 건 아무래도 인스턴스를 복사하는 문제하고는 다른 것이라.. 생명 윤리에 대해서 머리 속에서 $@#&%*(@&#%(*로 생각하고 있었습니다. --; (접근하면 양 세는 것 보다 더 강력하게 잠오는 무한루프...)

그런데, 작년에 읽었던 프랜시스 후쿠오카의 《Human Future》를 읽고서는 아아 그래 뭔가 똑똑한 사람들이 이미 생각 개진을 많이 해놨구나 느끼고 있기는 했는데, 마침 오랜만에 책을 찾다가 뭔가 아주 사이비 종교 광고 책 처럼 생긴 《클론 AND 클론》을 발견했습니다. 표지와 제목은 영 미심쩍었지만, 그래도 저자 중에 굴드씨가 있었기에.. 믿고서는

이 책은 99년에 나온 책인데, 돌리가 나온 직후에 여러 생명 윤리 관련 전문가들이 쓴 글들을 모아서 발간한 책입니다. 굴드 같은 이 분야의 전문가들의 냉철한 글외에도 SF 소설가들의 복제가 일어난 후의 세상을 그린 소설, 철학자들의 여러 철학론에 비춘 해석, 종교계 윤리학자들의 종교적인 관점에서의 이성적인 해석 등 여러가지 유익한 글들이 엮여있습니다.

처음에는 소설 여러개가 엮여 있는데.. 이 책을 번역한 이한음씨가 아무래도 과학서만 번역하던 분이라 그런지 무미건조에 하나도 재미가 없는 1장을 채 읽기가 힘든 이 문체란.. ;; 꿋꿋이 참고 그래도 몇페이지 읽다가 결국은 소설을 넘겼습니다. -0- 그 다음부터는 이제 굴드, 도킨스, 조지 존슨 등의 유명한 과학자들의 글이 나옵니다. 굴드씨의 글은 아주 짧은데 일란성 쌍둥이는 이미 과학적으로 가능한 클론보다도 더 완벽한 클론인데 왜 사람들은 클론에 대해서 그렇게 부정적인가에 대해 분석을 하고 있는데, 그 주된 문제점으로써 일란성 쌍둥이는 동시에 태어나기 때문에, 서로의 존재가 다른 사람들에 대해 정체성의 문제가 될 정도로 심각한 일은 없는 편이지만, 클론은 시간적 차이가 있기 때문에, 뒤에 태어난 클론이 앞에 태어난 원본의 삶에 일어나는 여러 일에 대해 충격을 받거나 운명으로 받아 들이고 비관적으로 살 경우 같은 점을 들고 있습니다. 아아 흐흐 이건 전혀 생각을 못 했던 것인데 이런 문제가 있군요. -O-;

도킨스씨는 역시 한쪽 끝 끌개 지역에 분포하는 사람이라, 글도 아주 과격하게 전혀 반대할 이유가 없다하고서 여러가지 논거를 내세우고 있습니다. 뭐 자세한 것은 워낙 긴 논리적 전개가 필요해서 직접 읽어 보셔야 겠지만, 논리적이지 않은 반박을 하는 일부 과격한 종교계 사람들의 전형적인 예에 대한 설명을 듣고 나니, 그 사람들 패턴이 이해가 됩니다.;;

""" 이 토론자들 가운데 가장 유명한 사람은 최근에 주님의 전당에 뽑힌 사람이었는데, 그는 텔레비전 스튜디오에서 여성들과 악수하는 것을 거부함으로써 토론을 신속하게 시작되도록 하는데 기여했다. 그의 악수 거부가 여성들이 생리 중이거나 불결할지 모른다는 두려움 때문이라는 것은 명백했다. 여성들은 그 성직자에게 종교적 선입관에 항상 수반되기 마련인 '존경'을 표하면서, 나라면 도저히 할 수 없을 정도로 매우 우아하게 그 모욕을 받아들였다. 패널 토론이 시작되고 좌장인 여성이 이 턱수염 난 성직자에게 정중히 경의를 표하면서, 복제가 피해를 끼칠 것인지 말씀해달라고 부탁하자 그는 원자폭탄은 해롭다고 대답했다. 그렇다. 거기에는 정말 반대 의견이 있을 여지가 없다. 그러나 복제를 논의하기로 예정되어 있던 토론은 어디로 갔단 말인가? """

역시 도킨스씨는 끝까지 아주 다혈질적으로 맹렬히 공격하고 있는데, 음 그래 그래~ 하면서 그런대로 수긍이 흐흐; 물론 도킨스씨 글 같은 것만 있으면, 뭔가 균형이 안 맞았겠지만, 미국의 국가 생명 윤리 자문 위원회나 윤리학 교수, 법윤리학 권위자들의 글들이 후쿠오카의 글에서처럼 "아 이런 똑똑한 사람들! 이런 것도 생각했군!"하는 탁 치게 만드는 논리들이 전개가 돼서 "그래 나는 세상 걱정 안 해도 되겠구나~"하는 결론만;;;; 얻게 되었습니다. 흐흐

생명윤리에 대한 토론은 아무래도 그동안 여러 군데서의 경험을 보면 그냥 쉽게 감정적인 자기 논리 세계를 기반으로 한 단방향적인 주장이 연속되다가 그냥 감정싸움으로 끝나는 경우가 많은데, 이런 책에서 체계적인 논리적 주장들로 종교/윤리적 관점의 반론이 전개되는 것을 보니 굳이 이런 얘기는 아무데서나 할 필요가 없겠다는 생각이 듭니다. ^-^;; (결국은 이런 산만한 결론으로 치닫는다.. --;)

그래요, "과학과 논리학은 무엇이 옳고 그른지 말해줄 수 없는" 것이지요. (리처드 도킨스)

드디어 고대하던 그 책 D&I of FreeBSD가 도착했습니다! 미리 아마존에 예약을 했는데도 꽤 늦게 도착을 했네요.. 영업일 3~5일이라더니 실제로는 8일째에 도착을.. ㅠ.ㅠ

아아 처음 딱 받은 소감은?

오우. 뭔가 패키징이 감동입니다. 역시 국내 배송과 해외 배송은 좀 다른 걸까요.. 비닐 공기 팩으로 꽉 채우고 책 자체도 안 움직이게 골판지를 대서 비닐에 싸놨군요. 전에 아마존 재팬에서 DVD 살 적에는 제법 허술하게 와서 실망 했었는데.. 흐흐. 역시 책이라 그런지 10만원 이하라 그런지 관세는 따로 없군요. 표지가 검은색에 오렌지라 4.4BSD 책 보다 뭔가 뽀대가 납니다. -O-

전체적인 구성은?

책 안의 디자인은 4.4BSD 책과 거의 똑같습니다. groff류의 툴들을 쓴 게 그대로 그냥 개정된 것이라 그런지.. 여전히 글자는 좀 지나치게 빡빡한 면이 있고 한데.. 뭐 빡빡한 대신 내용에 비해 얇아져서 그런대로 들고 다니면서 보기도 좋은 것 같은 것으로 위안을.. 흐흐; 역시 4.4BSD 책의 후속편 답게, 많은 부분에서 4.4BSD책을 기반으로 쓴 흔적이 남아 있습니다. 그렇지만 아무래도 세월이 많이 지나고 내부 구조가 바뀌다보니 뒷부분으로 갈 수록 새로 쓴 부분이 많아져서, 전체적으로 보면 FreeBSD 5.2 커널의 반 정도는 커버하고 있다고 볼 수 있겠네요. 이번에 실질적으로 내용을 쓴 Neville-Neil씨가 원래 글을 잘 쓰는지, 딱딱하고 지루하기 짝이 없는 4.4BSD 책의 문체에서 많이 벗어나서 쉽고 눈에 잘 들어오는 문체로 대폭 개선된 듯 해서 아주 읽기가 편합니다.

FreeBSD 고유의 업데이트들은 잘 반영이 되었는가?

우선, 최근에 등장한 FreeBSD 고유의 디자인들인 CAM, GEOM, ULE scheduler에 대해서는 어느정도 잘 다루고 있고 특히 softupdate와 UFS2에 대한 내용은 최근 업데이트까지 모두 아주 자세히 설명하고 있습니다. 그런데, KSE, netgraph, kld, 802.11, ipfw, acpi 같은 부분은 제법 관심이 있을 만한 주제인데도 빠져 있어서 조금 아쉽군요.

책의 난이도 및 구성의 품질은?

책의 난이도는 4.4BSD 책보다는 설명이 쉽게 되어 있어서 이제 어느정도 학부 교재로도 쓸 만큼 되었습니다. (앞쪽 책 소개란에 학부 교재로 쓰면 어떤 숙제가 좋은 가 얘기도..;;) 그런데 아무래도 OS의 기초부터 뭔가 다루는 책은 아니니까.. 그냥 부교재 정도로.. -o-; 비슷한 소재의 책 중에서 단연 최고의 인기인 《Solaris Internals》에 비해서는 FreeBSD 고유의 독창적인 디자인들과 FreeBSD를 소재로 쓰여져 있다는 장점은 있지만, 여전히 Solaris Internals가 그림이 훨씬 알기 쉽게 그려져 있고 설명이 친절해서, FreeBSD에 애착이 있는 독자가 아니라면 그냥 《Solaris Internals》가 읽기 좋을 것 같다는 생각이 듭니다. 책 중 8페이지가 연속으로 그림, 소스, 표 전혀 없이 본문만 연속될 때는 마치 오픈룩 블로그처럼 삭막하다는 압박감이 느껴지는군요. -O-

예~ 전체적으로 지난 버전에 비해 개선되고 재미있어졌지만 약간 아쉬운 점도 있습니다. 그래도 BSD 사용자라면 꼭 한 권쯤은 사 둬야 할 책인 듯 하네요. 버스에서 슬쩍슬쩍 읽어보는데도, 참 "아 내가 이렇게 생긴 OS를 쓰고 있었군~!"하는 느낌이 새록새록.. (4.4BSD는 좀 읽다가 포기 --;;)

FreeBSD 5의 첫번째 안정버전 릴리스인 5.3의 Beta1이 나왔습니다. 아직 5.3에서도 완전하지 않은 기능들이 많이 있지만, 그래도 계속 CURRENT로 남겨둬 봐야 계속 불안정한 것들이 들어올 것이니 언젠가는 적당히 STABLE로.. 흐흐.. 아직 SMP지원에 문제가 있기 때문에 SMP 사용자는 BETA2까지 기다리 라는군요.

이제 openlook도 5.3-BETA1로 올려야겠군요~ 참, 그리고 Python 2.4a2는 9월 2일에 나올 예정입니다.

최근에 CJKCodecs 1.1과 Python 2.4a2가 릴리스된 후에 구형 C 컴파일러를 사용하는 분들께 버그 레포트를 빗발처럼 받았습니다. -o-; 이번에 완전히 새로 구현한 _codecs_iso2022.c 에서 구조체 끝에 크기가 지정되지 않은 어레이인 C99 문법을 쓰는 바람에 gcc3이나 VC++에서는 잘 됐지만, gcc2나 HP-UX, IRIX, Tru64 같은데서 에러가 났던 것입니다. 근데 gcc2에서는 어레이 크기를 0으로 써버리는 수법으로 우선 에러를 넘길 수 있긴한데 다른데서는 따로 할 방법이 없어서 우선은 풀어쓰는 방법으로 패치를 올리고 버그를 보고한 사람들에게 테스트를 해 달라고 했는데, 이게 계속 왔다갔다 해야하다보니 불편해서, 시간이 꽤 오래 걸렸군요 흐흐

그래서 뭔가 좋은 방법이 없을까 하다가 생각난게 PythonTesters 페이지에 있는 HP Test Drive에 대한 내용이었습니다. 아무나 계정을 주긴 한다는데.. 정말로 줄까~ SF 처럼 상상을 초월하도록 느리지는 않을까 하는 걱정이 있긴 했지만.. 그래도 한번 해 보자 하는 다짐을 하고~ TestDrive에 접속해 봤습니다. 아아 가입하는 페이지가 무척 간단한데, 가입을 작성하고 나면 바로 메일로 비밀번호와 접속할 수 있는 머신들의 IP주소가 날아옵니다. ssh가 아니라 telnet으로 열어주는데, 들어가는 포트와 나가는 포트가 ftp와 telnet을 제외하고는 완전히 막혀있기 때문에 웹에서 뭘 받는다거나 scp로 올린다거나 그런게 전혀 불가능합니다. 오로지 소스를 올릴 때는 ftp로 올려야하고 telnet으로 작업을 해야하는 뭐 적당히 답답한 환경이군요 흐흐 속도도 그럭저럭 빠르고! 제공되는 머신은 한 30개정도 되는데 FreeBSD 클러스터 처럼 NIS와 NFS로 묶여있어서 아무데나 올려도 같은 홈디렉토리처럼 쓸 수 있어서 아주 편합니다.

지원되는 OS들은 HP-UX, Tru64, OpenVMS, FreeBSD, NetBSD, Debian GNU/Linux, Mandrake Linux, RedHat ES/AS, SuSE Linux 등이 있고, 아키텍처도 OS마다 다양해서 Alpha, Opteron, IA64, IA32, EV5/6/7 등등 다양하군요. 그리고 기본으로 다 C 컴파일러가 HP에서 파는 것과 GCC가 깔려있어서 그런대로 테스트 환경으로 편한 편입니다~ 그리고, 오라클 테스트도 할 수 있게 돼 있는데.. 뭐 오라클은 할 줄 몰라서;; -ㅇ-

Compaq Tru64 UNIX V5.1B (Rev. 2650) (spe147.testdrive.hp.com) (pts/3) 

login: perky
Password:
Last login: Thu Aug 19 12:15:42 EDT 2004 from 61.75.76.229
Compaq Tru64 UNIX V5.1B (Rev. 2650); Mon Dec  1 14:41:44 EST 2003
Welcome to the Compaq Testdrive Program
---------------------------------------
spe147.testdrive.hp.com> uname -a
OSF1 spe147.testdrive.hp.com V5.1 2650 alpha
spe147.testdrive.hp.com> cc -V
Compaq C V6.5-207 (dtk) on Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-207 (dtk) (dtk) cc Driver
spe147.testdrive.hp.com>

흐흐. Tru64 C Compiler는 특히 에러 내용이 무척 친절해서 포터빌러티 테스트를 할 때 정말 좋은 것 같네용.. 멀티 플랫폼 개발하는 분들께는 꼭 추천입니다.

오늘 파이썬 버그 메일링 리스트를 보다가 깜짝 놀랐습니다. Submitter: rivest라고 되어있어서 으흠. Rivest도 그렇게 영 없는 성은 아니구나~ 하고 생각을 하고 있었는데. 아니.. 이름이 Ronald인 것입니다. 오호 이름까지 같은 사람이 있군! 하고.. 버그 내용을 살펴보고 있었는데.. 헛~!!! 아니 밑에 메일이 mit.edu!! 그렇다면 이게 바로 그 진짜 Rivest씨 아닌가! 아아.. 이런 사람들은 그냥 펜 잡고 신선 놀음만 하는 줄 알았더니, 파이썬 쓰다가 파이썬 버그 보고를 "직접"할 정도의 실무 열의를 갖고 있다니 정말 감동입니다. 주르륵 주르륵. 이제 앞으로 SHA1 안 쓰고 MD5만 써야겠습니다. -O-;;;

얼마전에 Python 3000에 대한 대략적인 것을 이제 슬슬 정해 보자고 토론 되었던 대로, 오늘 PEP3000이 등록되었습니다. amk와 brett이 지난 PyCon때, 얼마전 토론, 위키에서 나온 내용 등을 토대로 정리한 것인데 처음 듣는 것도 몇개 있어서 상당히 흥미롭군요. 아직 나올 날은 멀었지만 무척 세련되어 질 것 같아서 설렙니다. 주요 차이점들 (아직 그냥 예정이고 결정된 것은 아님) 중 제가 재미있다고 생각한 것들은 이렇습니다.

• 문자열은 이제 유니코드!: 엊그제 블로그에서 얘기했던 대로, 이제 바이트 타입을 따로 신설하고, 자바나 C#처럼 기본 문자열 타입을 유니코드로 가 버릴 듯합니다. 이로써 세련된 다국어 지원을 좀 더 완벽히 지원할 수 있을 것 같네요. ^^;

• long과 int의 완전 통합: 현재는 int와 long이 따로따로 있으면서 int가 상황에 따라 long으로 업그레이드 되는 어정쩡한 통합 구조를 택하고 있는데, Python 3000에서는 int와 long이 같은 타입으로 값에 따라 내부 표현을 정하며 외부 인터페이스는 완전히 동일한 방법을 택할 듯 합니다.

• 정적 타입 인자의 지원: 효율적인 최적화나 입력값의 제한 등 여러가지 정적 타입인자의 장점을 선택적으로 취하기 위해서, 필요한 경우 정적 타입을 쓸 수 있도록 합니다.

• 모든 클래스가 new style: 현재 Exception을 비롯한 대부분의 라이브러리에서 구식 클래스를 쓰고 있는데, Python 3000에서는 완전히 모두 new style class로 바뀝니다.

• 이터레이터의 대거 도입: dict.keys(), dict.items(), range(), zip() 등을 비롯한 대부분의 리스트를 리턴하는 내장 타입, 내장 함수들이 이터레이터를 리턴하도록 바뀝니다.

• print, exec, lambda 키워드 소멸: print 키워드가 사라지고 write(), writeln()등의 내장 함수로 대체되며, exec키워드 대신 exec함수가 생기고, lambda는 그냥 없어집니다.

• 백쿼트 (``) 표현 소멸: 파이썬에서 제일 Perl스러운 부호 중의 하나인 ``가 없어집니다.

• 내장 함수들 대거 소멸: apply, buffer, callable, compile, coerce, input, intern, map, filter, raw_input, reduce, xrange 등 현재 다른 스타일로 대체되었거나 대체되는 중인 내장 함수들이 모두 사라집니다.

이 외에도 앞으로 10배는 더 많이 충격적인 내용이 들어가야 할 것 같은데~ 모두 좋은 아이디어를 생각해 봅시다 크흐흐;

요즘 파이썬계에서는 PEP318 펑션 데코레이터가 엄청난 태풍으로 몰아치고 지금은 다 싸우다 지쳐서 수그러드는 태세지만 여전히 결론은 안 나고 문법을 새로 도입할 때마다 겪는 진통을 톡톡히 겪고 있습니다.

그 와중에 두가지 문자열 처리 이슈가 띄엄띄엄 토론되고 있는데, 바로 "Decoding incomplete unicode"와 "adding a byte sequence type to Python"입니다. 전자는 StreamReader나 StreamWriter에서 현재 표준 UTF-8, UTF-7 코덱은 완결되지 않은 상태를 제대로 처리하지 못하고 있으며, CJKCodecs의 코덱들은 대충 파일이 끝나면 시퀀스도 끝났다고 보고 처리하고 있는데 이를 프로그램측에서 명시적으로 끝이다 아니다를 결정해 주는 API를 추가하자는 Walter의 제안으로 시작되었습니다. Walter의 제안에서는 패치도 나왔지만 API가 지나치게 복잡하고 Marc-Andre가 API가 변경되는 것에 강하게 반발하고 있어서 어떻게 될 지는 모르겠지만, 아무래도 필요하기는 할 것 같네요. CJKCodecs에서도 끝인가 아닌가 판단하는게 참 모호해서, EUC-JISX0213 코덱 같은 경우에는 호출 도중에 어디에서 짤리느냐에 따라 결과가 달라지기도 하는 문제가 있습니다 -O-

그 다음에 "adding a byte sequence type to Python"은 b"xxxx"라고 쓰면 바이트 시퀀스로 처리하고 문자열처럼 쓰지 말자 뭐 이런 내용인데, Java나 C#처럼 유니코드가 나온 이후에 나온 언어들은 대체로 다 채택하고 있는 byte와 char타입의 분리에 대한 내용입니다. 현재 파이썬에서는 "xxx"라고 쓰면 이게 싱글 바이트 시퀀스이면서 문자열을 겸하는데, 원래 싱글 바이트 시퀀스의 역할을 b"xxx" 표기법으로 바꿔버리고 "xxx"는 순수한 문자열 객체로 뭐 어쩌고 저쩌고 하자는 원래 제안이 올라왔었습니다. 그런데, 대충 토론의 결론은 이렇게 되면 하위호환성 문제가 되니까, Python 3000에서 "xxx"는 유니코드 타입으로 바꿔버리고 b"xxx"를 싱글 바이트 시퀀스로 쓰자는 쪽으로 결론이 났고 귀도가 이를 확인해 줬습니다. 그리고 물론 싱글 바이트 시퀀스 타입에서는 기존에 있던 str.lower이나 str.isalpha같은 문자열에서만 있는 메쏘드들이 다 사라질 것이라고 합니다. 현재 문자열은 뭐 영어 사용자들을 위한 문자열이나 다름이 없으니 Python 3000 아주 기대가 되는군요. 냉큼 바뀌면 좋겠습니다. ㅋㅋㅋ (그러나.. 그 기존에 문자열을 바이트 시퀀스로 쓰는 대부분의 코드들은 어찌 포팅할지 -ㅇ-)

방금 파이썬에 FreeBSD 6 지원을 추가 했습니다. 주로 테스트 코드들과 plat-freebsd6/IN.py, 그리고 setup.py에서 플랫폼에 따라서 모듈을 선택하는 부분이 변경되었습니다. 흐흐;

짠~

alice(perky):~/cvs/python% ./python 
Python 2.4a2 (#31, Aug 18 2004, 23:04:50)
[GCC 3.4.2 [FreeBSD] 20040728] on freebsd6
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[24306 refs]
>>> sys.platform
'freebsd6'
[24308 refs]

이히히;

요즘 회사 일이 너무 바빠서 퇴근도 눈치보고 하는 중이라.. 뭐 재미있는 일을 할 시간이 없네요.. 아흑흑 iso-2022 코덱 컴파일 제대로 안 되는 문제도 벌써 PR이 5개나 올라오고 이거 뭔가 조치를 취해야..

어제 갑자기 이상한 해외 결제 하나가 핸드폰 신용카드 결제 알림 SMS로 왔는데~ 뭔가 가격이 꽤 쎄길래 궁금했었는데. 드디어, 몇달 전에 예약한 D&I of FreeBSD [ISBN-0201702452]가 출고되면서 결제된 것이군요! 이히이히. 일단 기본적인 배송 방법은 뭔가 기다리기가 지루할 것 같아서, 중간 속도의 배송 방법으로 했는데, 8월 9일~8월 13일 도착 예정 이라는군요. 아이 설레서 잠을 못 자겠넹. 크크;

몇주 전쯤에 커런트에 gcc 3.4가 들어오면서, gcc 마이너 버전이 올라갈 때마다 있는 행사인 포트 대량 깨짐이 일어났습니다. gcc가 점점 더 문법이 빡빡해 지는 것 같군요.. 3.0에서 3.1로 올라갈 때는 정말 엄청났던 기억이 납니다 흐흐; (2.95에서 3.0으로는 빌드 고치는 PR 만 수십개를 올려서 한달만에 포트 커미터가 된 사람이 여럿 나올 정도였긴 하지만;; )

이번에 제 포트 중에서는 graphics/py-gdchart 와 archivers/py-lzma 가 깨졌다고 kris가 벤또를 통해서 알려왔는데, py-gdchart는 switch문 안에서 default뒤에 스테이트먼트 없이 그냥 끝내는 바람에 에러가 났던 것이고.. (이게 왜 그동안은 컴파일 됐던 것이지 흐흐;;) py-lzma의 경우에는 무지 신기한 에러라서 고치긴 했는데 왜 이렇게 하면 고쳐지는지 이해도 못 하고 있습니다. (사실은 C++을 할 줄 몰라서;;)

그게 어떤거냐면~ 소스가 대충 이렇게 되어있습니다.

template <int aNumMoveBits> 
class CBitModel
{
public:
  UINT32 Probability;
  void UpdateModel(UINT32 symbol)
  {
      (중략)
      Probability -= (Probability) >> aNumMoveBits;  // <= *여기1*
  }
};

template <int aNumMoveBits>
class CBitEncoder: public CBitModel<aNumMoveBits>
{
public:
  void Encode(CEncoder *encoder, UINT32 symbol)
  {
    encoder->EncodeBit(Probability, kNumBitModelTotalBits, symbol);
    UpdateModel(symbol); // <= *여기2*
  }
(후략)

정말 이상하게도 *여기1* 부분에서 Probability가 멤버임에도 불구하고 그냥 Probability라고 쓰면 undefined라고 에러가 납니다. 그래서 this->Probability로 고치는 걸로 해결했는데.. --;; 왜 그러면 또 되는지~ 흐흐.. 그리고 *여기2* 부분에서도 UpdateModel이 부모 클래스인 CBitModel의 메쏘드인데도 또 undefined라고 그래서.. 그것도 this->UpdateModel로.. 우엑~ gcc 3.4의 미스터리인지.. 원래 템플릿을 쓰면 그런건지 잘 모르겠네요 *.*

최대용량 파이썬 배포본으로 유명한 Fourthought의 CEO인 Uche씨가 블로그에 Python 2.4 is coming이라는 글을 썼는데 CJKCodecs에 대해서 좋게 썼네요 ;;

그리고 두번째 문단에서 지원님이 구현하신 제너레이터 익스프레션에 대해서도 굉장히 우호적으로~ 으히히. 과연 데코레이터와 스트링 인터폴레이션에 대해서도 이렇게 말할 수 있을지는... (흐읍~ 흐읍~)

(뭔가 자랑하고 나니 뻘쭘하다.. -o-)

올해 KTX의 도입때문에 철도 예약이 대폭 개편되면서, 이번 추석 승차권 예매도 완전히 바뀌었군요~ 기존에는 100% 오프라인에서 처리하고 취소표를 인터넷으로 푸는 방식이었는데, 이번부터는 60%를 인터넷에서 10,11,12일 예매하고, 40%를 오프라인에서 처리하는 방식으로 되었습니다.

10일은 장항선, 중앙선, 11일은 전라선, 12일에 경부선을 하게 됩니다. 이번에 아주 독특한 것은 일반적인 철도 예매처럼 조건 입력 -> 조회 -> 예약 -> 예약 확인 순서로 하는게 아니라 오로지 예약만 된다는 .. 그러니까 예약 당일에는 조회가 안 된다는 것이군요.. 그래서 미리 예약 가능한 열차 번호와 출발 시간을 정확히 입력을 해야 한다고 합니다. -ㅇ- 흐흐 그래서 저는 철도 목록을 미리 인쇄해서 좋은 시간을 대충 골라 두었습니다. 대충보기에는 열차가 상당히 많아서 그런대로 정상적인 방법으로도 가능할 것 같긴 한데.. 과연 쉽게 될지 모르겠네요; 이번엔 일반 예매랑 방법도 완전히 달라서 미리 스크립트를 준비할 수도 없고 해서 --; 클릭 연습이나 하는 수밖엔;;

추석에 내려가시는 분들 꼭 성공하시길; -o-

평소에 하루에 5통 내외의 낮은 소통을 갖고 있는 파이썬 개발자 메일링 리스트에 요즘 하루에 100통 정도의 엄청난 난리가 나고 있습니다. 바로, PEP318 펑션/메쏘드 데코레이터 때문인데요. 작년부터 엄청난 토론이 있었지만 별로 예쁜 문법이 안 나왔다가, 이번엔 결국 귀도와 앤써니의 합작으로 2.4a2 릴리스 이틀 전에 기습적으로 CVS에 커밋되었습니다. 보통은 커밋 되기 전에 소스포지나 개발자 메일링 리스트에서 여러 주를 토론을 하고 리뷰를 하다가 넣는데 이번엔 거의 우리나라 국회 날치기 처리하듯이.. ;;

이번에 들어간 문법은 @method 이렇게 펑션 윗줄에 연달아 쓰는 것인데, 이 외에는 리스트를 앞이나 뒤에 달아쓰는 것, | 연산자 활용하기, ^연산자 활용하기, AS 활용하기 등등 별의 별 나올 수 있는 문법은 다 나왔지만 결국은 몇명은 좋아하고 몇명은 다 싫어하는 문법들이란 것이 나오고 말았습니다. 메일이 수백개가 오간 뒤 어느정도 @method 데코레이터 문법이 어느정도 지지자들을 모으고 있는데, 이 문법은 새로운 기호를 사용해서 기존 파이썬 기반 확장 문법을 사용하던 ipython이나 Leo 등등에서 심각한 문제를 만들고 하위호환성 보장이 전혀 안 된다는 문제가 있지만 생각보다 쓰다보면 그다지 안 예쁘지는 않다는 장점이 있군요; 저도 처음엔 펄 같아보여서 아주 싫었는데 그런대로 쓰다보니 괜찮네요 흐흐; -ㅇ-;

이번 데코레이터 날치기 통과를 계기로 파이썬이 싫어졌다고 공공연히 밝히는 유명한 개발자들이 굉장히 많기는 하지만.. 아무래도 print >> fp 문법처럼 결국은 모두 다 싫어하면서도 쓰는 문법이 되지 않을까 생각해 봅니다 --;

파이썬은 소스가 수도 코드라서 아무래도 버그 추적할 때 문서보다는 소스를 찾아댕기는 일이 많습니다. 그런데, /usr/local/lib/python2.3/site-packages/twisted .. 뭐이렇게 길다랗게 나가는 디렉토리를 매번 일일이 치고 들어가는 건 참 고통스러운 일인데.. 그래서, pydoc처럼 간단히 vi를 열 수 있는 녀석을 만들어 봤습니다.

#!/bin/sh (-)
# Written by Hye-Shik Chang <perky@FreeBSD.org>
if [ ! "$1" ]; then
        echo "vipy {modulename}: opens vi session for a python module."
fi

FILEPATH=`python -c 'import '$1' as x
print x.__file__' | sed -e 's,\.py[oc]$,.py,g' -e 's,/__init__\.py$,,g'`
if [ $? != 0 ]; then
        exit $?
fi
if [ -r "$FILEPATH" ]; then
        $EDITOR $FILEPATH
else
        echo "Module $1 not found."
fi

vipy {모듈이름} 하면 바로 해당 소스를 vi로 띄워줍니다.

최근 FreeBSD에 프랑스인 개발자들이 엄청나게 불어나면서, 한 사람 한 사람 들어올 때 마다 다른 프랑스인 개발자들이 세계 정복이 다가오고 있다면서 아주 프랑스어판을 한번씩 만들어 버립니다. 흐흐; 그런데, 프랑스인이 많긴 많은데, 진짜로 많은가 이번엔 Ruslan이 직접 calendar.freebsd를 기반으로 통계를 냈군요.. 물론 여기에 등록 안 한 개발자들도 있기 때문에 약간 모자라는 값이긴 하지만.

출생 국가별 미국 55 일본 19 소련(연방국가 전체 합계) 18 독일 17 영국 12 프랑스, 오스트레일리아 7 캐나다 6 중화민국(대만) 5 덴마크 5 아일랜드 4 네덜란드, 남아프리카공화국, 이탈리아, 오스트리아 3 에스파냐, 그리스, 브라질, 벨기에, 대한민국 2 짐바브웨, 스웨덴, 중국, 노르웨이, 핀란드, 동아프리카, 불가리아 1

FreeBSD 개발자가 지금 350명쯤 되니까 대충 1/3정도만 계산된 수치이군요..

Ruslan은 그 외에 출생월, 출생년 별로도 통계를 냈는데 이렇게 나왔습니다.

9,10,11,12월이 다른 달에 비해 현저히 낮게 나온 걸 보면 뭔가 가을~겨울 사이에 태어난 사람들은 FreeBSD 개발자가 되기에 뭔가 어려운 것이 있나봅니다;;

그리고, 생년 별로는

평균 연령은 30.65살이고 가장 나이가 많은 사람은 Greg Lehey가 1948년 9월생, 가장 어린 사람은 Hiten M. Pandya가 1986년 9월생입니다.

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

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

멀티 플랫폼 SSH 클라이언트인 PuTTY에서 심각한 보안 버그가 발견되어, 0.55가 릴리스되었습니다. 우리나라에도 물론 많은 사용자들이 이미 PuTTY를 (주로 윈도우에서) 사용하고 있었기 때문에 영향을 미칠지도 모르겠네요. 흐흐. 이번 버그의 주요 내용은 호스트 키 교환이 일어나기 전에 서버측의 고의적인 시도가 있는 경우 PuTTY 클라이언트가 띄워져 있는 컴퓨터에서 임의의 해로운 코드를 실행해서 클라이언트 측을 공격할 수 있다고 합니다.

아무래도 믿을 수 있는 서버들만 접속하는 상황에서는 뭐 그다지 중요하지는 않겠지마는.. 으흐흐 혹시나 아무데나 접속할 일이 있는 분이 있다면 고치시는 게 좋겠네요. 'ㅇ'; 한글푸티는 제가 요즘 파이썬 2.4a2 작업하느라 좀 바뻐서 금방은 패치를 못 내놓을 것 같고 주말에는 돼야 겠네요~ 으흐흐; 우선 급하시면 오리지날 판을 쓰세요~ ;;

전에 인사이트 출판사에서 메일온 것에 하나 답변을 줬던 적이 있는데, 나중에 좋은 책이 출간됐다고 하나 보내줬는데 바로 이 《컨설팅의 비밀》을 받았습니다. 아무래도, Programming Pearls 같은 책을 주로 번역 출판하던 회사라서 뭔가 싸구려 책은 아니겠지 했는데, 컴퓨터 관련 책도 아니라니 참 기대가 됐습니다.

회사에 택배를 우선 선불로 보내줘서 아주 좋은 인상을;; 그런데 아아 역시 이거 상당하군요. 페이퍼백이 14900원이라니 -ㅇ-; 그래 뭔가 읽을 게 있으니 그렇게 했겠지 하고;; 으음 그런데 뭔가 뒷면의 추천에 오우 김창준님이 추천하는 말 끝을 쓰셨군요. 뭔가 기대가 되면서.. 그런데 받고 한 3분쯤 있다가 갑자기 친구 승범이에게서 msnm메시지가 왔는데 앗 갑자기 웬 방금 받은 책의 표지가 있는 페이지의 URL을 알려주는 것이 아닙니까! 아앗 내가 이 책 받은 걸 어떻게 알았지! 했는데 아이 이런 흐흐 승범이가 이 책의 일러스트를! 아 그림이 어디선가 본 그림체 같다 했더니~ 아 이제 책에 호감이 굉장히 생기면서 괜히 뿌듯하면서;;

그런데 그 이후로 책을 다 읽는데는 시간이 꽤 걸렸습니다; 우선 전에 읽던 《베트남 10000일의 전쟁》과 《전쟁의 역사》를 덜 읽어서 출퇴근할 때만 읽다보니 아무래도 시간이.. 내용은 주로 컨설턴트의 고객 다루는 방법, 자기 발전하는 방법에 대해서 쓰고 있는데, 유명한 책이라서 그런지 역시 법칙이 상당히 많아서 뒤에 부록으로 법칙 목록이 정리되어있기도 합니다.; 각각의 법칙이 실제 저자의 경험에서 나온 것이라 그런지 설명이 상당히 수긍이 가도록 되어 있어서 아아 그래 맞아 맞아~ 하며 맞장구를 치며 읽게 됩니다. 수긍이 갔던 부분 몇군데를 발췌해 보자면,,

돈이 필요하면, 일자리를 구하지 말라.

왜? 이상한가? 만약 돈이 절실하면 이 일자리 하나로 돈 문제를 해결하려고 몸값을 너무 높게 책정할 것이기 때문이다. 아니면 가격을 바탕으로 자신을 팔려서 가격을 너무 낮게 책정하던가. 이러한 경우 둘 다 컨설팅에서 몸값을 도구로 사용할 유용한 기회를 놓쳐 버린다. --- 254 페이지, 금전에 대한 니드와 다섯 번째 법칙

뭔가를 잃는 최선의 방법은 그것을 지키려고 애쓰는 것이다. --- 201 페이지, 로머의 원칙

그 외에도 꼭 컨설턴트가 아니라도 누군가에게 뭔가 조언을 할 일이 생길만한 경우, 외부의 컨설턴트에게 대처하는 경우 등에서 이 책을 안 읽었더라면 여러번 시행착오를 거쳤을 만한 일들이 많이 적혀 있어서 "페이퍼백이 14900원"임에도 불구하고 아주 가치 있는 책으로 느껴집니다.

파이썬 릴리스 엔지니어인 앤써니 백스터씨에 따르면 이번 주 목요일에 파이썬 2.4a2를 릴리스할 예정이라고 합니다. 2.4 브랜치의 첫 릴리스이자 MSI 인스톨러가 실제 사용이 가능할 지 알아보는 첫 알파 릴리스였던 2.4a1에 이어 이번 2.4a2에서는 2.4의 가장 큰 싸움터였던 318 메쏘드 데코레이터의 시험 무대가 됩니다.

메쏘드 데코레이터는 필요성에 대해서는 대체로 최소한 +0 정도는 주고 있었지만, 공감을 얻어내는 깔끔한 문법이 하나도 나오지 않은 상태에서 반발을 사는 안만 수십개가 난립하고 있었는데, 우선 2.4a2에서 귀도의 결정으로 앤써니가 자바 스타일 문법을 그대로 사용한 것을 우선 트렁크에 넣었습니다. 이렇게 됩니다.

>>> @staticmethod 
... def test(self):
...     pass
...
>>> test
<staticmethod object at 0x816c8d4>

지금까지 함수 끝에다가 test = staticmethod(test)했던 다른 언어에서 건너온 사람들이 거부감을 느낄 듯 한 문법상의 문제점을 해결을 해서 뭐 그럭저럭 괜찮은 것 같기는 하지만서도.. @라는 여태까지 파이썬에서 사용되지 않았던 기호를 하나 더 사용하게 된 것은 조금 거부감이 듭니다. 뒤에 as붙이는 거나 []안에다 마구 써대는 것 보다는 그래도 훨씬 나은 것 같네요;;

그리고, 2.4a2에서는 CJKCodecs 1.1이 머지돼서 HKSCS와 JIS X 0213:2004지원이 원활해졌습니다. 또한, 인터랙티브 셸에서 sys.stdin.encoding을 존중하지 않던 문제가 해결되어, 이제 u"한글" 이런 식으로 인터랙티브 셸에서도 쓸 수 있게 되었고, 일본 사람들이 shift-jis 로캘에서 몇몇 글자를 입력하면 이스케이프때문에 에러가 나는 문제가 해결됩니다.

그 외에 국제화와 관련이 없는 주요 문제들로는

• 그동안 임포트 중에 실패한 모듈들이 모듈 캐시에 남아서, 그 다음에 또 임포트하면 마치 에러가 안 난 것처럼 배시시 거리고 있는 현상이 이제 고쳐졌습니다.

• None이 컴파일러에서 상수형으로 처리되어 더이상 None = 1 같은 처리가 불가능해졌습니다. (..)

• SSL 소켓을 넌블러킹 소켓으로 사용할 수 있게 되었습니다.

• threading 모듈의 쓰레드 오브젝트에 local이라는 속성이 추가돼서 TLS(Thread-Local Storage) 사용이 가능해 졌습니다.

• Optik이 1.5로 업그레이드 되었습니다.

오늘 드디어 한국 사람으로는 최초로 소스 커미터로 편용현씨(yongari@)가 등록되었습니다. 그동안 pf 포팅을 하시면서 Max Laier를 통해서 소스를 넣고 계셨는데, 이제 쉽게 pf 커밋을 직접 하실 수 있게 되었군요.

developers@에 보내신 소개말씀에 따르면 네트워크 스택, 패킷 필터링, 디바이스 드라이버와 sparc64포팅에 주로 관심이 많이 있으시다고 그러시는군요. 멘터는 5.x 릴리스 엔지니어인 Scott Long씨가 맡아 주고, 아마 sparc64부분에서 Jake Burkholder씨가 코-멘터링하는 것 같습니다.

이제 다음엔 도큐먼트 커미터가 나올 차례인가요?

며칠 전에 NBSP가 space인가 아닌가에 대해서 얘기를 좀 했었는데, 이 문제가 아무래도 불거지게 된 것은 BSD Rune Locale의 isctype 함수들의 특성 때문이었습니다. BSD Rune은 4.4BSD 시절에 생겨난 것으로, POSIX Locale가 만들어지기 이전부터 디자인된 멀티바이트 캐릭터셋 API이기 때문에, 그 이후 POSIX Locale 스펙과 맞지 않는 점이 있습니다. 바로, POSIX에서는 isspace, isalpha같은 ctype함수들을 싱글 바이트로 표현할 수 있는 코드포인트들로 제한을 하고 있지만, Rune에서는 iswctype이 도입된지도 얼마 되지 않았고 그냥 isctype 함수들이 wide character 코드포인트까지 모두 담당해버려서 결국 UTF-8 로캘같이 전체가 하나의 캐릭터셋이라서 싱글 바이트의 경우와 wide character가 겹쳐버리는 경우 잘못된 답이 나와버리는 것입니다.

그래서 Tim에게 메일을 보냈더니 Rune과의 하위호환성을 5.x까지는 유지하겠다고 manpage에 써 놓아서 우선 바꾸지는 못 하지만, 6.x에서 고칠 수 있겠다는군요.. 그리고 manpage에 언급을 넣어 줘서 COMPATIBILITY에 이제 isctype에서 와이드 캐릭터 전영역을 커버하지 않도록 곧 수정될 수도 있다는 경고가 붙게 되었습니다. 그러면서 우선 버그를 피해갈 수 있는 방법을 하나 알려줬는데.. 이렇게 합니다 ;;

#undef isspace 
#define isspace(x) isspace(btowc(x))

흐흐;; 우선 파이썬 포트와 파이썬 2.4 트렁크에 해당 패치를 넣으려고 합니다.