Month: December 2003

열린 한글 프로젝트 개설

by

http://kldp.net/projects/hangul

X 한글입력기 “나비”, 윈도우용 IME방식 한글 입력기 “새나루”, GTK+2 한글 입력기 imhangul에서 공동으로 사용할 오토마타 엔진을 위해 “열린 한글 프로젝트”를 개설했습니다. 사실 이전에도 [WWW]사바나에 프로젝트가 있었지만, 사바나는 거의 망해가는 추세로 보이고 해서.. –;;

우선은 한글 조합, 분해와 기본 오토마타 구조를 내년초 릴리즈를 목표로 [WWW]박원규님과 [WWW]최환진님과 같이 할 예정입니다. :)

[WWW]한글 해커 메일링 리스트도 내부에 개설되어 있으니 한글 처리에 관심이 많으신 분들은 가입해 주세용~

제이 『눈부신 날에』

by

http://openlook.org/distfiles/J.ogg (64kbps OGG)

언젠가 아침에 일어날 무렵 라디오에서 듣고 정말 궁금했던 노랜데, 드디어 찾았습니다. :)

단적비연수 OST에 실렸던 곡이네요. (… 하필이면;; )

그런데, 이곡을 찾다가 정말 깜짝 놀란게 하나 있는데 –;
MBC드라마 “상도”에서 다녕아씨와 임상옥이 통군정에서 몰래 만나기로 했는데 안 나와서 안타까움에 어쩔 줄 모르는데 다녕아씨는 자기 방에서 우는 그 장면에서 나왔던 배경음악 [WWW]“상사몽”을 제이가 불렀군요;;; 으허헛 -ㅇ-; 제이 만세 ㅡ.ㅜ

char이 8비트가 아닌 세상

by

엊그제 [WWW]gcc 워닝을 제거하는 커밋을 하나 했는데, 여기에 unsigned char이 256보다 클지도 모르니 체크해봐야된다는 MAL의 답글이 올라왔습니다. 그래서 의아하게 생각하던 와중, Fredrik Lundh가 ANSI C 스펙을 참고해 보라고 해서 찾아봤더니.. char의 크기는 “각 기계에서 주소 지정이 가능한 최소 단위”라고 정의되어 있어서, char은 H6070에서는 9비트이고 Cray에서는 64비트, TI의 DSP칩에서는 16비트라는군요.. (….)

10년간의 char에 대한 믿음이 허물어지는 순간 흑흑 ㅡ.ㅜ char는 int8_t가 아니구나.. 아니였던 것이구나. ㅡ.ㅜ

Univac 시절부터 메인프레임을 써 왔다는 Tim Peters의 [WWW]답변에 따르면 Univac은 이런 char크기 싸움에 휘말리지 않기 위해서 char을 6비트, 9비트 또는 36비트로 쓸 수 있게 했다는군요.. (웃음)

여하간, 귀도와 팀이 char를 8bit로 파이썬 전반에서 사용하는 것에 대해서 괜찮다고 답변을 줬기 때문에, 뭐 더 걱정할 일은 없겠습니다. ^^; 그리고 이번 기회로 역시 20년 이상 경력을 가진 개발자들의 깊은 지식에는 역시 감탄을…

(ANSI C의 세계는 멀고도 험난하구나~~;;)

상대경로(?) 임포트

by

원래 파이썬에서 import 하면 모듈이 존재하는 곳을 맨 먼저 찾고, 표준 서치 패스를 찾게 되어있습니다. 그런데, 얼마 전 Raymond의 [WWW]크리스마스 소원 목록에서 등장해서 엄청난 이슈를 일으키고 있는 명시적 상대 경로 임포트 (explicit relative import)가 이제 뭔가 대세가 되고 있군요.

중간에 문법과 구현 원리가 엄청 많이 제시되기는 했지만, 대충 지금까지의 의견 수렴은

  • ‘.’를 기본 sys.path에서 뺌 (지역 디렉토리에서의 단순 임포트 불가)

  • from의 패키지명 앞에 . 1개를 쓰는 경우 지역 디렉토리, 2개이상을 쓰는 경우 상위 디렉토리를 찾음.

이렇게 되어가고 있는데, 여기서도 구체적인 문법 모양 등의 사안에 대해서는 의견이 아직 분분하군요. :) 예를 들면 현재 같은 디렉토리에 있는 파일을 임포트할 때 import what하면 될 게, 이제 앞으로는 from . import what이 된다는.. 상위 디렉토리의 다른 패키지 모듈을 임포트 하는 경우에는 from ..subdir import what 이런식으로 일단은 될 모양이군요. (아직 결정은 안 됨)

이 이외의 의견으로는 이런 것도 있습니다. (다들 나름대로의 지지자들을 확보. :) )

  • 상위 디렉토리에 올라갈 때 .대신 __parent__를 쓰고 현재 디렉토리에서 임포트할 때에는 __here__에서 임포트

  • 상위 디렉토리에 올라갈 때 ../../ 식으로 슬래쉬를 넣자는 의견

  • 그냥 상대경로 임포트를 놔둔 채로 표준 경로에서 임포트할 때 from stdlib import xxx로 하자는 의견

어떻게 될 지는 며칠 더 토론이 진행되어야 될 것 같습니다. :)

생명이란 무엇인가? 그후 50년

by

[ISBN-8986270862] 40년대 분자생물학 붐을 일으킨 바로 그 에르빈 슈뢰딩거의 «생명이란 무엇인가»의 강연 50주년을 기념하여 93년에 나온 (번역판은 올해) «생명이란 무엇인가? 그후 50년»을 읽었습니다.

므흣. 이 책은 슈뢰딩거의 업적을 평가하고 “생명이란 무엇인가?” 주제에 대한 현재 기술과 미래의 진행에 대해서 열명의 저명한 과학자들이 논문을 한 편씩 낸 것을 묶어놓은 것인데, 참여한 사람들 이름이 어찌나 화려한지.. 으흐흐 저자들 이름만 봐도 뭔가 무서운 책이라는… +_+ 특히 스티븐 제이 굴드, 제레드 다이아몬드, 존 메이나드 스미스, 만프레드 아이겐, 로저 펜로즈 등 스타급 저자들의 탁월한 글들은 본인들의 책에서 쓴 것 못지 않게 정말 재미있습니다. 와와~

우선, 스티븐 제이굴드와 제레드 다이아몬드, 스튜어트 카우프먼 같은 앞쪽에 나오는 저자들은 대체로 슈뢰딩거의 업적에 대해서 비판적으로 평가해보는 내용을 담고 있는데, 셋이서 어찌나 똑같이 비판을 하는지.. 뭐하러 슈뢰딩거 기념 논문에 이런걸 세개나 썼는지 모르겠군요 므흐 -ㅁ-; 하여간, 비판하는 내용을 뺀 나머지 부분이라도 역시 굴드와 다이아몬드의 글은 정말 재미있습니다. :)

원래 좋아했던 굴드와 다이아몬드 외의 다른 저자들의 논문 중에서 인상깊었던 것은, 만프레드 아이겐의 “무엇이 미래의 생물학을 지배할것인가?”였는데, 아이겐의 일반인의 과학에 대한 시각, 과학 정책, 바이러스 이야기, 20세기 생물학에 대한 평가 같은 것들을 보면 역시 엄청난 포쓰가 느껴집니다. 뒷 부분의 로저 펜로즈와 스콧 켈소 등의 논문은 방정식이 등장하고 양자 물리학 공식이 막 왔다갔다 해서 정신이 없지만 –; 서너번 더 읽어보려구요;; 혹시나 이해 될까봐 -_-;;

고등학교 때 읽고서는 세계관이 흔들리게 됐었던 «생명이란 무엇인가»를 읽고서, 무려 6년만에 놀랜 가슴을 이 책으로 정리할 수 있었습니다.(또 오바한다 –;)

생물을 연구해 보면 현재의 물리학이 얼마나 원시적인지 잘 알 수 있다.

– 알베르트 아인슈타인

크리스마스 트리

by

어느 과후배가 게시판에 그린 크리스마스 (프리오더) 트리 … 아이디어가 깜찍하군요. :)

Python versus PieThon

by

지난 5월이었던가요.. PyCon에서 Parrot(perl6에 사용될 JIT 지원 VM)팀의 Dan Sugalski가 귀도에게 내년에 패럿기반의 파이썬과 오리지널 CPython간의 벤치마크 시합을 해서 지는 쪽이 맥주를 사고 50달러 내기를 했던 것을 기억하실겁니다. :)

최근 Dan Sugalski가 이 작업을 위해서 본격적으로 벤치마크할 프로그램의 조건을 구체적으로 얘기를 꺼내기 시작했는데, 대충 파이썬 코어팀과 Dan간의 협의 사항은 이렇게 정해졌네요

  • 순수 인터프리터 자체만 테스트하는 것을 목표로 함

  • I/O 성능은 테스트하지 않음

  • 정규표현식 성능은 테스트하지 않음

  • eval과 expr은 테스트하지 않음

  • 펜티엄 기반의 리눅스 박스에서 테스트함

  • 파이썬 소스가 아닌, 바이트코드를 기반으로 하며 최소한 30초 이상 작동하는 코드로

  • 바이트코드는 12월 내에 결정

  • 확장 모듈은 사용하지 않고 빌트인 함수는 사용함

귀도는 Parrot이 엄청난 격차로 CPython을 이긴다면, CPython을 버리고 파이썬 기반을 패럿으로 옮겨버릴 수도 있다고 합니다. (과연.. :) )

FreeBSD NDIS 호환성

by

블루님이 무려 5년 전에 [WWW]freebsd-chat에 제안하시기도 했고, 2달전, 슬래시닷에 [WWW]리눅스용이 공개돼서 열풍이 몰아쳤던 NDIS 드라이버 로더 호환성 레이어가 최근 FreeBSD에서 구현되고 있습니다.

리눅스용은 상용으로 공개된 반면에, FreeBSD에서는 메인스트림에 오픈소스로 들어오고 있다는 점이 아주 좋군요 :) NDIS를 처음 들어보시는 분들을 위해서 약간 소개를 드리자면, NDIS는 Network Driver Interface Specification으로 Microsoft와 3Com이 공동으로 개발한 네트웍 드라이버/프로토콜 드라이버 겸용의 스태커블 구조의 API입니다. Windows 95이후 모든 버전은 NDIS를 지원하고 있어서, 네트웍 카드들과 프로토콜 드라이버들 (예를 들면 WinPcap의 packet32나 Windows XP Wireless Zero Configuration에서 사용되는 ndisuio, 리눅쓰코리아의 DynaRADIUS WCM에서 쓰는 dot1xuio 드라이버 같은 것들)이 모두 윈도우 커널 API가 아닌 NDIS만을 사용해서 구현되어 있습니다. 따라서, 대부분의 윈도우용 네트웍 드라이버들은 NDIS만 구현하면 쉽게 다른 x86기반 OS에서도 사용할 수 있는 것인데, 이제 FreeBSD에서도 윈도우용 드라이버들을 쓸 수 있게 되는 것~! :)

소스를 보면, 지원되는 NDIS OID (SNMP처럼 OID기반 Query/Set을 합니다.)가 OID_STATUS, OID_GEN, OID_802_3, OID_PNP, OID_802_11 계열 밖에 없어서, 우선은 오직 무선랜 카드들만을 대상으로 하고 있다는 냄새를 맡을 수 있습니다. 역시 브로드콤의 정책때문에.. 으흐;;

그런데, 이제 앞으로 NDIS 레이어가 들어가버리면, 무선랜카드 드라이버들이 구현이 안 될테니 non-x86 아키텍처가 아주 큰 문제군요.. 그리고, NDIS가 3Com과 MS가 공동으로 특허를 갖고 있다는 것도 좀 찜찜~~

여하간.. NDIS 삽질을 정말 열심히 하고 있는 Bill Paul(wpaul@)씨 화이팅~ (Bill Paul은 FreeBSD의 다른 대부분의 랜카드 드라이버도 작성한 일종의 괴물 분류입니다. -o-)

아이언 파이썬

by

며칠 전 [WWW]Miguel의 블로그에 올라온 블로그가 크게 파장을 일으키고 있네요. Jython 개발자인 Jim Hugunin이 .NET 기반의 새로운 파이썬인 Iron Python을 만들어서 Microsoft 내부 메일링 리스트에 결과를 올렸는데, 예전의 Active State의 구현이나 Parrot계열의 Pirate의 실망스러운 결과와는 완전 상반되게 70%나 CPython보다 빠르다는 결과를 얻었다고 합니다. ([WWW]원본 메일 (Miguel의 복사본))

특히나 function call, integer add쪽은 CPython에서 엄청난 오버헤드가 있는 것으로 유명했던 부분이라.. 역시나 IL asm으로 직접 번역하는 것으로 구현된 Iron Python보다 엄청나게 느린 것으로 결과가 나왔군요. 그리고 range의 경우에는 메모리 할당이 단편적으로 엄청나게 일어나기 때문에 CPython이 유리한 게 나왔고 eval(“2+2”)쪽은 CPython은 컴파일러가 순수 C로 구현되어있기 때문에, 흐흐..

하여간 .NET IL asm으로 직접(C# 안 거치고) 파이썬 코드를 번역하면 아무래도 CPython보다 더 빠르지 않을까 생각하던 초기 .NET 개발자들의 예상은 대충 맞았다는 것이 증명되고 있는 듯 합니다. 아직 Iron Python이 많이 구현되지 않은 반면 최적화를 수행하지 않았기 때문에, 앞으로 변동이 좀 있을 것 같기도 한데.. 하여간 무지 기대가 되네요. :) (MS에 팔아먹으면 대략 낭패 –; )

한편, Iron Python이 오픈소스가 아닌 MS나 다른 회사의 상용 제품으로 들어가는 것을 대비해서 최적화를 계획해야할 텐데, CPython도 이제 슬슬 표준 환경에서의 JIT 지원에 대해서 본격적으로 진지하게 고려해 봐야 할 것 같기도 합니다. (PyPython은 아직 까마득.. 으흐…)