OpenLook

오늘은 엊그제 얘기했던 korean/gdick 을 포트에 집어넣었습니다. 흐물.. 이제 프비에서도 쉽게 사전을!

그 외에 잡다구리 주인 없는 포트들 파이썬 버젼 올라가면서 깨진 것들을 고쳤습니다. (자꾸 고치라고 메일 보내서 -.-)

• graphics/py-opengl : tk8.4 지원이 안 들어가 있어서 tk8.3용으로 되어있는 헤더를 이름 바꿔서 써버림. -.-;

• devel/fnorb: Makefile.pre.in에서 @DEFS@ 를 빼야 제대로 컴파일되는 문제.

• biology/pymol: fnorb랑 같은 문제

• devel/pybibliographer: fnorb랑 같은 문제

• math/scigraphica: exec 안에 네스티드 스코프성 변수를 써버리는 바람에 2.3에서는 신택스 에러나서, eval로 바꿔버림.

뿡뿡 =3

<에헴>오늘의 간추린 FreeBSD 소식을 말씀드리겠습니다.</에헴> -;;

• 며칠 전 포트에 dns와 polish 카테고리가 생기고, xfce4 가상 카테고리가 생겼습니다.

• 드디어 /bin, /sbin을 동적 컴파일을 하는 DYNAMICROOT가 Gordon Tetlow의 작업으로 커밋되었습니다. WITH_DYNAMICROOT=yes를 make.conf에 넣고 make world하면 되는데, 요건 할 얘기는 많지만 내일의 블로그 거리를 남겨두기 위해 자세한 것은 내일;;; _-_

• 오는 8월 24일 4.9 릴리즈를 위한 -STABLE 트리 Freeze에 들어갑니다. (9월말에 릴리즈 예정)

• Colin Percival의 새로운 프로젝트로 binup 프로젝트가 교체되었습니다. 그동안 BSDi가 넘어간 이후에 중단되어 있었는데, 이제 앞으로는 혹시나 새로운 Colin의 프로젝트가 성공한다면, 보안성 있고, 빠르고, 적은 대역폭을 사용하는 바이너리 업데이터를 가질 수 있게 될 것입니다.

그리고.. 곁다리로 Python 소식 하나… Python 2.3.1이 9월 두째주 쯤에 릴리즈될 예정입니다. 이번 버전의 릴리즈 짜르(Czar)은 마침 9월 첫째주에 휴가인 py2exe와 ctypes로 유명한 Thomas Heller가 맡는 다는군요. 기대가 됩니다.!

요즘 윈도우 파티션에 들어있는 mp3들을 우찌 잘 들어볼 방법이 없을까. 이런 저런 고민을 하다가, msdosfs.ko를 libiconv.ko를 쓰게 하는 게 아무래도 구조상 무리라서 (현재 libiconv.ko는 CES가 제대로 지원될 수 없는 구조..) msdosfs.ko에 직접 UTF-8패치를 해보려고 시도를 해 봤습니다.

그래서, 이런 저런 닭짓끝에, 기본적인 인코딩/디코딩은 성공했는데.. 두둥.. 웬걸~ 글자가 앞쪽만 잘려서 나오는 겁니다. 으흐.. 이게 무슨 일이냐 해서 보니.. UTF-8 시퀀스가 유니코드 글자 개수만큼 바이트로 잘려서 나오는… 그러니까.. ‘한글’이라는 파일 이름은 ‘\xed\x95\x9c\xea\xb8\x80’ 인데, 이게 앞에 2바이트만 잘려서 ‘\xed\x95’가 되는 것.. 왜 그런지 여러모로 뒤져보니.. 이런! msdosfs.ko가 글자 길이를 그냥 원래 유니코드 시퀀스 길이로 계산해버리는.. 그러니, 사실상 256:256 컨버트가 가능한 ISO-8859 쓰는 녀석들만 msdosfs를 정상적으로 쓸 수 있다는.. 그런 구조로 되어있던 것이었습니다.

그래서, 제대로 계산하게 좀 패치를 했는데(좀 미심쩍은 부분이 있긴 했지만..), 또 웬걸~ 좀 파일 이름만 길어지면 또 뒤가 잘리는.. 그 문제는 이번에는 또 윈도우의 파일 시스템 구조 특성상 13글자 단위로 뒤에서부터 엔트리가 시작돼서.. 긴 파일 이름이 여러 슬롯으로 나뉜다는 것입니다. 그러니.. 결국 파일 이름이 좀 길어지면 13글자 단위로 쪼개서 뒷 블럭부터 변환이 일어나서.. 가변폭 인코딩인 UTF-8로서는 도저히 길이 계산을 할 방법이 없어진다는… 도식적으로 그려보자면 “1234567890123에헤라디여바람분다창문닫아라” 라는 파일이 있다면

• ATTR_WIN95 엔트리: ‘라’를 들고 있고 WIN_CNT가 2

• ATTR_WIN95 엔트리: ‘에헤라디여바람분다창문닫아’를 이름으로 들고 있고 WIN_CNT가 1

• ATTR_WIN95 엔트리: ‘1234567890123’을 이름으로 들고 있고 WIN_CNT가 0

• 일반 파일 엔트리: ‘123456~1 123’을 이름으로 들고 있음. (짧은 이름이 123456~1.123이 됨)

이렇게 돼서.. 순서대로 파싱하려면 맨 끝에있는 ‘라’가 먼저 나와버리기 때문에, 현재 msdosfs.ko처럼 ATTR_WIN95 엔트리를 처리하면서 변환까지 같이 하는 구조에서는 가변폭 인코딩을 처리할 방법이 전혀 없습니다. 그래서 궁리를 좀 해보니, WIN95 길이의 최대길이인 256글자를 스택에 들고 있으면서 거기에 버퍼링을 해 뒀다가 그걸 한꺼번에 전체를 인코딩하는 방법 밖에는 없겠다 싶었습니다. 그래서 좀 찾아보니.. 으허허 역시 Apple Darwin에서는 벌써 그런 방법으로 고쳐놓았더군요. 그래서 결국은 FreeBSD의 win2unixfn 함수가 없어지고 getunicodefn이 msdosfs_conv에 들어가서, msdosfs_vnops에서는 win2unixfn으로 일일이 엔트리마다 변환해서 dp->d_name에 직접 쓰는 것이 아니라, getunicodefn으로 각 엔트리별 유니코드 스트링을 스택에 버퍼한 다음에 그걸 사용하는 것으로 되어있었습니다. 그런데, Darwin은 원래 파일시스템이 유니코드 기반이라 변환이 필요없지만, FreeBSD는 8bit byte sequence형태이므로 변환할 필요가 있기 때문에 Darwin것 그대로 수용은 불가능했지만, 그래도 뭔가 좀 빌려 쓰면 될 것 같네요.

음.. 그래서.. 결론은? 에.. 며칠 삽질 더 해야겠다는.. 크크;;

이렇게 하고 나면 뭐 거의 libiconv.ko에도 바로 붙을 수 있는 수준 –;;;;;