요즘 근황

1. 바쁘고 잠 부족

매일 5시간 이하로 자는 나날이 3일 이상 지속되었을 때 사람 정신이 얼마나 피폐해지는지를 요즘 체험하면서 지낸다. 미치겠다. 조금만 틈만 나면 정신줄을 확 놓고 싶어지고, 짜증나고 일의 집중도와 생산성이 급격히 떨어진다. 이 말년이 표현했듯이 생명체의 4대 의무 중 하나가 잠의 의무이다. -_-;;

1999년쯤, 당산 철교가 재시공 중인 관계로 서울 지하철 2호선의 서쪽 고리가 끊어져 있던 시절, 노조가 파업까지 해서 비전문가인 대체 기관사가 투입된 적이 있었다. 그랬는데 그 중 어떤 사람은 극심한 과로로 인해 눈 뜨고 잠드는 경지에까지 이르렀고, 두단식 승강장이 되어 버린 합정 역의 수동 운전 구간에서 열차를 못 세우고 선로가 끊어진 곳으로 열차를 탈선시키는 아찔한 사고를 냈었다. 조금만 더 갔으면 열차는 끊어진 다리를 넘어 강으로 추락했을 테니 말이다.

그런데 그 사람 심정이 이해가 된다. 난 잠에 약하니, 아무래도 나폴레옹 같은 위인은 못 되는 게 틀림없다. 덕분에 블로그 글 비축분도 예전에 비해 줄어드는 중.

그런 와중에도 <날개셋> 한글 입력기 다음 버전 개발은 틈틈이 치열하게 진행되고 있다.열몇 가지에 달하는 개선 사항들 중, 요 근래엔 굉장히 좋은 성과가 있어서 하나 소개하겠다. 프로그램의 모든 과정에서, 운영체제의 known, system DLL 말고 일반 DLL을 로딩할 때는 언제나 절대 경로를 지정하게 개선함. 이것은 아주 바람직하고 진작에 취했어야 할 조치인데, 이로써 얻은 긍정적인 효과는 다음과 같다.

- fake DLL을 잘못 로딩하거나 인식할 가능성을 원천 차단하여 프로그램의 잠재적인 보안 위협을 크게 줄였다. 가령, <날개셋>과 전혀 관계가 없는 동명이인(namesake) NGS3.DLL을 로딩하는 프로그램 내부에서도 이제 <날개셋> 외부 모듈이 잘 동작할 수 있다.
- FireFox Nightly에서 <날개셋> 한글 입력기 외부 모듈이 전혀 구동되지 않는다는 버그 신고가 들어와 있었는데, 이를 덩달아 해결. (FireFox 구버전에서는 그런 현상이 없었다 함)
- 드디어.. 서로 API가 호환되지 않는 <날개셋> 버전을 사용하는 타자연습과 입력기 외부 모듈이 “동시 구동이 가능해졌다!” 이제 앞으로는 타자연습에서 외부 모듈을 같이 쓰기 위해서 두 프로그램을 항상 동시에 업데이트해야 할 필요가 없다.

2. 국어 정보 처리 시스템 경진대회

국어 정보 처리 시스템 경진대회라는 게 있다. 문화 체육 관광부와 국립 국어원이 공동 주최하는 이 대회는, 가장 직접적으로는 방대한 양의 세종 말뭉치를 효율적으로 조회하고 의미 태깅을 똑똑하게 해 주는 소프트웨어의 개발을 독려하기 위해 시행되었다. 하지만 그것 말고도 한국어· 한글과 관련된 뭔가 독창적인 소프트웨어는 무엇이든 응모 대상이 될 수 있다.

그러고 보니 공모전인데 왜 경진대회라는 표현이 쓰였는지 모르겠다. 2009년부터 시행해서 올해로 3회째이다.
한 달도 더 된 뒷북이긴 하다만, 본인은 <날개셋> 한글 입력기 6.3을 출품해서 은상을 받았다. 대상과 금상에 이은 3등.

사실, 내 프로그램은 다른 작품들과는 체급이 근본적으로 다르다. 11년 전에 1.0이 이것보다 더 큰 대회에서 1등을 한 적도 있는 걸... 그리고 내 프로그램은 말뭉치라든가 사전, NLP 같은 분야를 직접적으로 다루지도 않는다. 이런 프로그램이 나올 거라고 심사 위원들이 전혀 예상하지 못했을 소재의 프로그램이다만(오히려 심사 위원 중에 내가 과거에 두벌식 제정 위원 중 하나였다고 말한 분도 있었다-_-)...
그래도 내 프로그램은 국어 정보 처리와 분명 밀접한 관계가 있다. 저 정도로 입상을 했으니 옛날 생각이 나고 기분은 좋다. 입상작들의 수준도 그렇게 호락호락 허접한 편은 결코 아님.

금상을 받은 분은 나이 지긋한 개인 개발자이신데 세종 전자 사전 통합 검색 시스템을 만들었다.
대상을 받은 울산 대학교 팀은 전산학과의 한국어 처리 연구실에서 한국어 형태소 분석기를 개발하면서 몇 년째 작정하고 이 대회만 공략한 경우이다. 한 우물만 파면서 2010년 금상에 이어 이번에 대상을 수상했다.

3. 늦가을의 불청객, 모기

11월이 꺾여 가는 와중에도 아직까지 날씨가 별로 춥지가 않다. 특히 이상 고온이 기승을 부리던 월초엔 집에서 여전히 에어컨이나 선풍기를 틀어야 할 정도였다.
그래서일까? 본인은 이놈의 모기 때문에 홍역을 치르며 악몽 같은 가을을 보냈다. 하긴, 뉴스에서도 보도된 적이 있을 정도였다.

저녁에는 가능하면 선풍기· 에어컨을 가동하기보다는 문을 개방하여 집안을 냉각시키고 싶은데, 그럴 때면 정말 어김없이 모기가 기어들어오곤 했다. 피 빨아먹지, 게다가 귓가에 날아다니는 소음은 사람 기분 잡치기에 최적이다. 차라리 열대야가 기승을 부리는 한여름에는 문을 열 생각 자체를 안 하고 무조건 에어컨 콜인데, 지금은 그게 아니다 보니 모기가 더욱 부각되는 것 같다.

때려잡자니 피 빨아먹은 모기는 벽에 지저분한 혈흔을 남기고, 살충제는 사람에게도 무척 해로운 화학 약품이고... 처리하는 방법도 딜레마이다.

하루는 한밤중에 한적한 주택가에다 차를 세워 놓고 차 안에서 잠을 잤다. 냉각과 환기를 위해 창문을 약간만 열어 놨는데... 그게 실수였다. 그로부터 30분이 채 되기 전에 팔뚝에 가려움이 느껴졌고, 실내등을 켜서 차내를 둘러봤을 때 나는 기겁을 하고 말았다.
그 좁은 틈새를 타고 모기가 이 작은 승용차 안에 서너 마리씩이나 들어와 있었기 때문이다. ㅜㅜ 이런 썩을..;; 이놈들은 잠도 안 자나.;;

제아무리 살생을 하지 말자고 주장하는 박애주의자라 하더라도 파리· 모기를 죽이지 말자고 주장하는 사람은 없을 것이다. 체벌 반대, 사형 반대, 채식주의, ‘자연으로 돌아가자’ 이런 식의 주장에 본인은 성경적으로 100% 동의하지 않는다. 자연으로 돌아간다 해도, 이미 죄로 인해 타락하고 저주받은 자연은 인간에게 어차피 좋은 것만 선사하지는 않는다. 죄로 인해 어쩔 수 없이 필요해진 필요악이나 그 말단의 나쁜 결과만 지워 보려 애써도, 그 본질적인 원인이 없어지지는 않는다.

4. 노트북 키캡 이탈

지금 쓰는 제 4대 노트북은 용하게도 최초로, 3년이 넘게 키캡 하나 안 빠지고 잘 쓰고 있었는데
드디어 키캡 하나 이탈.. ㅜ.ㅜ
보통 단골로 빠지던 키캡은 Space나 화살표 키, 엔터 같은 부류인데 이번에는 이례적으로 문자 키인 기본 자리 F 키가 빠졌다. 문자 키의 키캡이 빠진 경우는 본인의 노트북 인생 13년 만에 처음이다.

뭐, 화살표나 엔터도 이미 키캡이 덜렁덜렁하고 상태가 위험하긴 마찬가지임.
노트북 키보드는 이거 좀 튼튼하게 만들 수 없나 아쉽긴 하다.
나중에 키캡이 세 개째까지 빠져 버리면 키캡을 전면 교체할 생각이다.
그나저나 키보드 밑에 껴 있던 먼지와 온갖 솜털의 양을 보고 기겁함. 먼지는 그렇다 치지만 이 털들의 정체는 뭐냐!!

5. VMware로 녹음하기

VMWare에서 돌리고 있는 guest OS에서 마이크 녹음이 안 되는 걸 보고 놀랐다.
guest OS에서 나는 소리를 녹음하는 게 아니라, host에서 꽂은 마이크의 소리를 guest에다가 전달하여 녹음하는 것 말이다.

host는 비스타이고 guest는 XP. 물론 하드웨어 계층의 차이가 많이 나는 OS이긴 하다만, USB에 네트웍에 별걸 다 잡아 주는 천하의 VMWare가 마이크를 못 잡아 주다니?
녹음을 시키면 마이크 소리는 없이 그냥 잡음만 녹음될 뿐이다.
한국어와 영어 키워드로 인터넷 검색을 해 봐도 딱히 답이 안 나온다..;; 원래 잘 안 되나 보다.
윈도우 XP에서만 돌아가는 음성 인식 관련 기능을 좀 테스트하고 싶었는데 말이다..

Posted by 사무엘

2011/11/15 08:29 2011/11/15 08:29
, ,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/599

여타 소프트웨어들이 다 그렇듯이, 본인의 <날개셋> 한글 입력기에도 자기 정체성을 소개하는 고유한 About 대화상자가 있다. 타자연습은 그냥 별도의 About 탭이 대화상자를 대신하고 있고..;;

이게 참 재미있는 게, 원래 도스 시절에 풀다운 메뉴를 갖춘 각종 응용 프로그램들은 About 표시 기능이 맨 첫째 메뉴의 첫째 항목에 있었다.
하지만 윈도우 운영체제의 관행은 정반대로 맨 마지막 도움말 메뉴의 맨 마지막 항목에 About을 놓는 것인지라, 위치가 그렇게 바뀌어 버렸다.
과거 도스용 아래아한글과 윈도우용 아래아한글을 비교해 보면 차이가 명확하다.

사용자 삽입 이미지

뭐, 아래아한글은 아래아한글이고, 이제 내 프로그램의 경우를 살펴보자.

사용자 삽입 이미지

일단 이 프로그램이 <날개셋> 한글 입력기의 어느 부속품이며(편집기, 외부 모듈, 변환기 등등) 부속품의 버전이 무엇인지를 명시한 후, 이 프로그램이 <날개셋> 한글 입력기라는 제품의 구성 요소임을 밝힌다.
(이 글은 최신 6.3버전이 완성되기 한참 전에 작성된 글이어서 스크린샷은 6.2 기준. -_-)

모든 부속 프로그램들은 About 대화상자를 표시하는 명령이 어떤 형태로든 존재한다. 편집기는 도움말 메뉴에, 외부 모듈은 language bar의 도움말 메뉴에, 변환기는 대화상자의 시스템 메뉴에, 입력 패드는 트레이 우클릭 메뉴에 등.

그 다음으로 나오는 것은 한글 입력기 전체의 버전과 구동하는 CPU 비트수이며, 이 프로그램의 간단한 용도와 저작권, 날짜, 라이센스, 제작자 홈페이지 주소처럼 갖출 건 다 갖추고 있다. ^^

거기에다 간략한 운영체제 버전과 메모리 양 정보는 액세서리. 윈도우 9x에서는 리소스 퍼센티지도 나온다. -_-
개인적으로는 홈 에디션, 프로페셔널 에디션, 서버 에디션 같은 정보도 표시해 주는 기능이 있으면 좋겠지만, 귀찮아서-_- 생략.

<날개셋> 한글 입력기의 버전과 함께 나타나는 비트수는, 현재 돌아가고 있는 모듈의 비트수이다.
그러므로 64비트 OS에서 64비트 에디션을 설치했더라도, 현재 <날개셋> 한글 입력기를 사용하는 프로그램이 32비트라면 이 수치는 32비트로 나타난다. 따라서 이걸 보면, 굳이 작업 관리자를 열지 않더라도 이 프로그램의 비트수를 바로 알 수 있다.

그 대신, 64비트 OS에서 32비트 프로그램을 사용하고 있다면, 운영체제 버전 다음에 '64 bit'라는 숫자가 따로 명시된다. 이 점 착오 없기 바란다.
32이든 64이든 운영체제와 프로그램의 비트수가 일치하면 이런 말이 따로 뜨지 않는다.

외부 모듈은 이것 말고도 유용한 정보가 About 대화상자에 또 뜨는 게 있다.
바로, 스크린샷에서 보다시피 현재 구동 중인 응용 프로그램이 TSF / IME중 어느 기술 계층을 사용하는가이다.
비스타부터는 무조전 TSF이니까 이게 큰 의미는 없다만, TSF A급인지 B급인지도 가르쳐 주고, 게다가 비스타 이상에서는 TSF 확장 모드를 사용 중인지도 알려 준다. (TSF A*라고 별표가 추가됨)

한글 입력기로서, 특히 사용자가 버그 신고를 할 일이 있을 때 무척 유용한 정보를 덩달아 제공해 주는 셈이므로 참고하기 바란다.

또한, 오늘날의 사용자가 볼 일은 없겠으나,
윈도우 9x에서 윈도우 3.x용 16비트 프로세스 밑에서 <날개셋> 한글 입력기 IME를 돌려서 About 대화상자를 띄웠다면,
무려 16 bit IME mode라는 말까지도 뜬다. -_-;;
무조건 NTVDM을 돌리는 NT 계열은 해당사항 없음.

IME라든가 훅 DLL 같은 걸 만드는 게 아니라면, 32비트 DLL이 16비트 EXE 밑에 붙을 일은 없을 텐데, 무척 신기한 경우이다. 16비트 EXE는 32비트 EXE처럼 자신만의 주소 공간을 갖고 있지 않고 굉장히 이상한 방법으로 실행된다.
그 상태를 판단함으로써 지금 EXE가 16비트인지 32비트인지를 알 수 있다.

그 반면, 32비트와 64비트끼리는 과거처럼 호환성이고 썽킹(thunking)이고 나발이고 없이 코드가 서로 상종을 안 하기 때문에, 둘을 완전히 따로 만들어야 하지만 말이다.
그러고 보니 32비트와 64비트는 이렇게 서로 따로 노는데도 불구하고, 비주얼 C++ IDE는 32비트 프로그램임에도 64비트 OS에서 64비트 프로세스를 잘도 디버깅을 할 수 있는지 무척 신기하다. 제아무리 커널 오브젝트 핸들을 32비트와 64비트 프로세스끼리 공유가 가능하다 해도, 이건 보통일이 아닌 것 같다.

이상, <날개셋> 한글 입력기의 about 대화상자에 대한 설명이었다.

Posted by 사무엘

2011/10/07 08:17 2011/10/07 08:17
Response
No Trackback , a comment
RSS :
http://moogi.new21.org/tc/rss/response/580

<날개셋> 한글 입력기가 받아들이는 입력 단위는 여러 종류가 있다.

가장 먼저, 딱히 내부적인 메카니즘 없이 유니코드 문자를 있는 그대로 받아들이는 '일반 문자'가 있어서 심지어 한글 자모도 그냥 일반 문자처럼 입력시킬 수 있다.
오토마타를 거쳐 조합되는 한글은 입력 단위 차원에서 세벌식과 두벌식으로 종류가 나뉘어 있다. 그래서 한 글자판 안에 세벌식 자모 글쇠와 두벌식 자모 글쇠가 따로 존재할 수 있다.

이 외에 한글 입력기 내부의 상태를 다양하게 바꾸는 특수글쇠가 존재하며, Bksp라든가 한자 키는 그런 특수글쇠의 일종으로 처리된다. 다만 Bksp는 한자 키와는 달리, 한글 입력기가 처리할 때도 있고 그렇지 않고 응용 프로그램이 자체적으로 처리할 때도 있기 때문에, 키 위치를 한글 입력기가 마음대로 옮길 수 없다는 차이가 존재한다.

<날개셋> 한글 입력기는 흠좀무스럽게도 여러 자모를 한꺼번에 배당해서 중성과 종성을 한번에 입력한다든가, 심지어 지금 글자의 종성과 다음 글자의 초성을 한번에 입력할 수 있으며, 숫자 키패드처럼 '000'(UTF16 기준 최대 6바이트) 같은 문자열을 한 글쇠에 배당할 수도 있다. 이건 지난 5.65버전부터 가능해졌는데, 예전에는 그런 두세 글자를 한꺼번에 입력하려면 "<날개셋> 고급 입력기"의 사용자 정의 조합을 써야만 했었다.

이렇듯, 이 프로그램은 내부 구조가 대인배스러우며, 사용자 정의 가능성의 폭이 매우 크다.
그런데 '상태 전이'는 도대체 뭘 하는 놈일까?
이건 나름 무려 <날개셋> 한글 입력기 3.0 시절부터 있었던 기능이다. (2004년.. 그 엄청난 옛날!)
얘는 이름으로부터 알 수 있듯이, 오토마타의 내부 상태 번호를 지정된 코드값으로 바꿔 준다.

보통 오토마타 상태는 한글 자모를 입력하면서 그 입력값에 따라서 바뀌는 법인데,
그렇게 하지 않고 오토마타 상태만 바꿈으로써 그 이후의 한글 입력기의 동작 방식을 바꾸는 일종의 특수글쇠와 비슷한 효과를 낸다.
상태 전이 글쇠는 한글을 조합하고 있는 중에만 사용할 수 있으며, 0번 상태로 가게 해서 조합을 중단시키게 할 수도 없다. 다시 말해 상태 전이는 언제나 nonzero끼리만 가능하다.

가령, 평소에는 이어치기 방식으로 한글을 입력하다가 어쩌다가 가끔 모아치기나 무한 낱자 수정 같은 걸 일시적으로 쓰고 싶을 때, 두 방식의 오토마타를 모두 설계해 놓은 뒤 두 상태를 전환하는 기능을 배당하면 된다.
그 메카니즘은 다음과 같다.

초-중-종성 순서대로 들어온 입력만 허용하는 이어치기 오토마타는 다음과 같다. 수식을 해석하여 표로 나타낸 것이다.

현상태 비고
0 1 2 3  
1 1 2 3
2 0 2 3 중, 초중
3 0 0 3 중, 중종, 초중종, 초종

그 반면, 모아치기 오토마타는 다음과 같다.

현상태 비고
0 1 2 2  
1 1 3 3
2 3 2 2 중, 종, 중종
3 0 3 3 초중, 초중종, 초종

결국, 이어치기든 모아치기든 처음에 초성만 입력되었을 때는 공통으로 1번 상태이지만, 2번과 3번 상태는 각 성분이 입력된 상태가 서로 다를 수 있다.

두 오토마타를 합쳐야 하기 때문에, 서로 공유하는 한글 상태별로 오토마타 상태를 더 늘리도록 하겠다. 즉,

이어치기: 초 / 중,초중 / 종,중종,초중종,초종
모아치기: 초 / 중,종,중종 / 초중,초중종,초종

이었으니까 이들의 공통분모는

초 / 중 / 초중 / 종,중종 / 초중종,초종

으로 더욱 세분화할 수 있다. 중-중종과 초중종-초종만이 모아치기와 이어치기 모두에서 한 묶음으로 따라다니기 때문이다.
이렇게 상태 수만 늘린 채 모아치기 오토마타를 재구성하면 다음과 같다.

현상태 비고
0 1 2 4  
1 1 3 5
2 3 2 4
3 0 3 5 초중
4 5 4 4 종, 중종
5 0 5 5 초중종, 초종

그리고 동일한 상태에 따라 이어치기 오토마타를 expand하되, 1~5라는 상태 번호에다가 10을 더하여 11~15를 만들면 다음과 같다.

현상태 비고
0 11 12 14  
11 11 13 15
12 0 12 14
13 0 13 15 초중
14 0 0 14 종, 중종
15 0 0 15 초중종, 초종

이 오토마타들을 한데 집어넣어 주면 이렇게 된다.

0 → A ? 1 : B ? 2 : C ? 4 : 0
1 → A ? 1 : B ? 3 : C ? 5 : 0
2 → A ? 3 : B ? 2 : C ? 4 : 0
3 → B ? 3 : C ? 5 : 0
4 → A ? 5 : B|C ? 4 : 0
5 → B|C ? 5 : 0
11 → A ? 11 : B ? 13 : 15
12 → B ? 12 : C ? 14 : 0
13 → B ? 13 : C ? 15 : 0
14 → C ? 14 : 0
15 → C ? 15 : 0

그리고 적당한 글쇠에다가 다음 수식을 넣어 준다.

C1|T+(T>=10 ? -10 : 10)

C1은 '상태 전이'를 나타내는 접두사이다. T는 오토마타 상태 번호를 나타내는데, 이게 10보다 큰 상태이면 10을 빼 주고, 그렇지 않으면 10을 더한다. 따라서 1 ↔ 11, 13 ↔ 3 같은 오토마타 상태를 왔다갔다 할 수 있다. 초성과 중성만 입력된 상태의 모아치기 상태(3) 혹은 이어치기 상태(13)처럼 말이다.

지금까지 설명한 것처럼 오토마타를 짜면, 기본적으로 모아치기가 시작하는데 상태 전이를 해 주면 이어치기가 되게 할 수 있다.
그러나 0번 상태에 대한 수식을 A ? 1 : B ? 2 : C ? 4 : 0 대신, A ? 11 : B ? 12 : C ? 14 : 0 로 지정해서 이어치기 상태로 먼저 가게 하면, 기본적으로 이어치기인데 상태 전이를 해 주면 잠깐 모아치기가 되게 할 수도 있다.

즉, ㅏ를 입력했는데 평소 같으면 초성 ㄱ을 누르면 ㅏㄱ가 따로 갈라져 버릴 것이다. 이때 상태 전이 키를 잠시 누르면, 그 상태에서 '아'나 '악'을 어느 순서대로든 입력할 수 있는 상태가 된다. 상태 전이 기능은 바로 이런 식으로 활용할 수가 있다. 글자판을 바꿀 때와는 달리, 한글 조합 상태가 그대로 유지된다!

오랜만에 <날개셋> 한글 입력기의 레어템 테크닉에 대한 글을 썼는데 전달이 잘 됐으려나 모르겠다.
주어진 유한한 요소만 고침으로써 컴퓨터에서 한글을 내가 원하는 어떤 창의적인 형태로든 다룰 수 있게 하고, 그 과정에서 세벌식 글자판의 우수성을 부각시키는 것이 이 프로그램의 개발 목적이다.

IME도 개발돼 있긴 하지만 <날개셋> 한글 입력기의 대표 프로그램은 역시 편집기라는 전용 프로그램이다. 그야말로 윈도우 95 스타일의 기본 GUI를 그대로 답습하고 있는 소박한 프로그램이지만 이 작은 에디터가 본인에게는 마치 내 정신의 고향 같다. ^^;;

Posted by 사무엘

2011/09/21 08:28 2011/09/21 08:28
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/572

날개셋 한글 입력기 6.3

추석 연휴가 끝나자마자 <날개셋> 한글 입력기의 따끈한 새 버전 소식이 기다리고 있다. (만세 ㄲㄲ)
본인의 사정으로 인해, 6.2가 나온 지 한 달이 채 되지 않아 6.21도 아니고 이례적으로 6.3이 나오게 됐다. 원래는 10월쯤에 내놓으려고 했는데.

그 대신 이게 올해의 마지막 버전업이 되지 싶다.
이번 학기를 마친 뒤엔 드디어 종합 시험(논자시;;)을 봐야 하고, 또 이번에 듣는 과목은 지난 학기의 과목과는 달리, 국어학 배경이 빈약한 본인에게는 만만찮은 것들이다.
그래서 프로그램 개발부터 좀 마무리를 짓고 나서 그런 일들에 전념하고자 한다.

6.3은 +0.1 이상에 해당하는 기능 추가와 개선이 충분히 이뤄졌다.
외부 모듈이 TSF 환경에서 옛한글 같은 2글자 이상의 조합을 표현할 때 조합이 끊어지던 문제를 완전히 해결했고,
한글 표현 체계와 에디팅 엔진이 크게 바뀌었던 직전 버전에만 자잘하게 존재하던 여러 버그들도 잡았다. 편집기의 경우 화면 잔상이 남던 것부터 시작해 심하면 프로그램이 죽던 문제까지도 있었다. 더 구체적인 내역은 모방 범죄 예방을 위해 알리지 않겠다. ㄲㄲ

정 재민 님께서 보내 주신 글꼴 데이터를 반영하였으며, 유용한 텍스트 필터도 세 종류나 추가했다.
- 호환용 영역의 한자를 본디 형태로 바꾸는 필터 (정 재민 님 제안)
- 본문 중의 수식을 계산하고 숫자의 경우 진법을 싹 바꿔 주는 필터
- 패턴 치환 필터. 이건 프로그램 설치해서 도움말을 읽어 보기 바란다. 일괄 치환과 더불어 아주 유용한 기능으로, 이걸 쓰면 칼럼 단위의 데이터를 다루기 위해 엑셀 같은 별도의 프로그램을 쓸 일이 크게 줄어든다. <날개셋> 편집기는 키매크로나 칼럼 블록 기능을 제공하지 않지만, 대체 기능을 텍스트 필터의 형태로 꾸준히 제공하고 있다.

그리고 뭐니뭐니해도 6.3 버전의 가장 큰 특징은 Bksp 키를 다루는 체계를 싹 바꿨다는 점.
<날개셋> 한글 입력기는 1.0 시절부터 Bksp에 여타 한글 입력기에서는 찾을 수 없는 특수한 기능들을 제공해 왔다. 즉,

- Bksp와 Shift+Bksp의 용도를 구분하고,
- 조합 여부와 상관없이 한글을 낱자나 글자 단위 중 원하는 형태로 얼마든지 지울 수 있다.
- 그리고 한글이든 비한글이든 지금 글자가 다 지워진 후 그 앞에 또 한글이 있으면 그 한글에 달라붙어서 조합 상태가 재연된다. 앞 글자도 seamless하게 계속 낱자 단위로 지우거나 고치거나 빠진 낱자의 추가 입력이 가능하다.
- 게다가 이걸로도 모자라서, 두벌식 글자판의 경우 도깨비불 현상까지 고려해서 이전 상태를 복원해 준다. 일명 역도깨비불인데,

안해 → 않 (≠ 안해 → 안ㅎ → 안)
보끼 → 볶 (≠ 보ㄲ → 보ㄱ)

같은 동작도 지원된다는 뜻이다.

그리고 그 후 10여 년 뒤, 6.3 버전에서는, <날개셋> 한글 입력기의 간판 기능으로 손색이 없는 이 기능을 지정하는 방식이, 예전보다 훨씬 더 깔끔하고 체계적이고 전문적으로 바뀌었다.

사용자 삽입 이미지

스크린샷을 보면, 예전에 Bksp 동작 방식에 있던 서너 개의 체크 옵션이, 자주 쓰는 predefined configuration을 바로 가져오는 콤보 상자로 대체되었음을 알 수 있다. 자세한 설정은 말 그대로 '자세히' 버튼을 눌러서 나타나는 별도의 대화상자에서 해야 한다.

스크린샷에서 알 수 있듯, Bksp와 Bksp, 그리고 한글을 조합 중일 때와 그렇지 않을 때, 각 상황별로 한글을 무슨 순서대로 지울 것이며 이 글자가 다 지워졌을 때 앞의 한글에 달라붙을지를 일일이 사용자가 설정할 수 있다. 예전 버전에서는 기능 자체만 제공되었지 이 정도로 세밀한 설정은 가능하지 않았다.

또한 두벌식 역도깨비불 재현도 별도의 옵션으로 바뀌었다. 따라서 두벌식 자판을 쓴다고 하더라도 그냥 달라붙기 기능만 쓰지, 역도깨비불까지 원하지는 않는 사용자라면 해당 옵션을 끄면 된다. 이런 취사선택도 예전 버전에서는 가능하지 않았다.

과거의 3.0부터는 자그마한 옵션이 하나 추가되었는데, 입력 순서와 상관없이 하위 낱자부터 한 타씩 지우는 옵션이 그것이다.
ㅇ+ㅜ+ㅣ+ㄴ 순으로 입력했든 ㅇ+ㅜ+ㄴ+ㅣ 내지 ㅜ+ㅇ+ㅣ+ㄴ 순으로 입력했든, '윈'은 무조건 종성부터 역순으로 지워서 위-우-ㅇ이 되게 하는 기능인데, 이것이 바로 위의 스크린샷에서는 '최하위 낱자의 직전 한 타'이다. 이런 차이는, 당연한 말이지만 동일한 글자를 여러 가지 순서로 입력할 수 있는 모아치기가 가능한 세벌식 체계에서만 의미가 있다.

그에 덧붙여 이 새 버전에서는 '최하위 낱자 전체'라는 옵션도 추가됐다. 말 그대로 낱자 단위로 한꺼번에 지워 버리는 옵션으로, 아무리 복잡한 한글이라도 초· 중· 종성이 모두 갖춰져 있다면 세 타 만에 다 지워진다. '윈'을 지울 때 '위' 다음에 '우'를 안 거치고 바로 'ㅇ'이 된다는 뜻. 사실, PC용이 아닌 휴대전화용 한글 입력기의 Backspace는 다들 이런 방식으로 구현되어 있다.
여담이지만, 내부적인 구현 오버헤드는 최하위 낱자를 따지는 방식이, 고전적인 '직전에 입력된 한 타'보다 더 크다.

이쪽 기능을 대대적으로 손을 좀 봐야겠다고 거의 6.0 개발 초창기 시절부터 생각은 하고 있었는데 드디어 해내게 되어 무척 기쁘다. 진작부터 지원돼야 했을 기능들이다.
물론, 주변 글자를 자유자재로 다룰 수 없고 write-only만 가능한 TSF B급 이하 환경에서는 '달라붙음' 같은 기능은 전혀 쓸 수 없고, '조합 상태가 아닌 한글을 지우는 단위' 역시 오로지 글자 전체 단위로 제약을 받게 된다.

기능을 구현하는 과정에서 <날개셋> 한글 입력기의 내부 구조도 제법 바뀌었다. 하지만 더 합리적으로 바뀌었다. 그 내막을 살펴보면 이렇다.

지난 3.0 버전 이래로 Bksp 키는 입력 스키마가 '낱자 단위 지우기' 아니면 '글자 단위 지우기'라는 특수글쇠를 생성하는 형태로 내부적으로 처리되었다. 그리고 전자와 후자를 Bksp와 Shift+Bksp에다 각각 대응시킬지, 아니면 반대로 Shift+Bksp와 Bksp에다 대응시킬지를 '입력 스키마'의 옵션으로 지정 가능했다. 그게 끝이었다.

그러나 이제부터는 입력 스키마는 Bksp일 때 Bksp1, 그리고 Shift+Bksp일 때 Bksp2라고 언제나 고정적인 특수글쇠만을 생성한다. 이런 특수글쇠는 1부터 4까지 현재 네 종류가 예약되어 있는데, 이들 자체에는 어떤 특정 동작 방식이 규정되어 있지는 않다. 각 특수글쇠의 해석은 전적으로 그 아래의 '문자 생성기'만이 담당하게 된다. 그것이 바로 저 'Bksp 동작 방식' 옵션인 것이다.

그리고 그 추상적인 Bksp와는 별개로, 특정 방식대로 한글 낱자를 지워 주는 특수글쇠가 또 존재한다. 즉, 진짜배기 Bksp는 입력기의 옵션이 어떻게 지정됐냐에 따라서 낱자/글자 단위로 지우고 필요하다면 달라붙기나 역도깨비불까지 제공하는 반면, 그냥 낱자 단위, 입력 역순, 글자 전체(위의 스크린샷에 있는 네 옵션 중 하나) 삭제라는 고정불변 단편적인 Bksp 기능도 임의의 글쇠에다가 특수글쇠의 형태로 배당해서 쓸 수 있다는 뜻이다.

아시는 분이 있으려나 모르겠는데, <날개셋> 한글 입력기에는 0x10과 0x11에 '뒷글자 삭제'라고 해서 Del과 유사한 기능을 하는 특수글쇠가 이미 있다. 그것처럼 Bksp와 유사한 기능을 하는 네 가지 특수글쇠도 일관성 차원에서 추가된다고 이해하면 정확하다.

이들 특수글쇠는, 편집 환경만 지원된다면(TSF A급 같은), 이미 완성된 한글도 물론 낱자 단위로 자기 방식대로 지울 수 있다. 하지만 그런 이상적인 환경이 아니라면, 이미 완성된 글자는 건드리지 못한다. 사실 Bksp 키 자체가, 한글 입력기가 조종하는 것과 에디터 응용 프로그램이 조종하는 것이 공존하는 체계이다. 완성된 글자는 한글 입력기가 아니라 응용 프로그램이 지워 주며, 응용 프로그램은 일반적으로 '진짜' Bksp 키가 들어왔을 때만 그런 동작을 하기 때문이다.

이런 식으로 시스템 개편을 했는데, 솔직히 내가 생각했지만 내가 봐도 너무 멋있다..;; 이 맛에 프로그래밍 하는 거다.
이것저것 생각해 놓은 게 많아서 당분간은 새 버전의 Readme엔 '※ 한글 입력 체계' 카테고리가 쭉 있을 것으로 보인다. 한글 입력기 본분에 충실한 기능이 계속 강화되고 개선되고 있기 때문이다.

6.3 버전은 6.2와 API가 완전히 호환된다.
다음 버전은 내년 초에 6.5 정도가 목표이다. 버그 없이 프로그램을 잘 만들어서 가능하면 0.0x대로 내려가지는 말고 버전을 쑥쑥 크게 올려야겠다.

Posted by 사무엘

2011/09/14 08:29 2011/09/14 08:29
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/569

1.

이 블로그는 좀 특이한 구석이 있다.
보통, 덕력이 좀 높은 블로거는 전문 분야 블로그와 일상 잡담 블로그를 분리해서 운영한다.
하지만 본인은 그렇게 하지 않으며 모든 관심 분야에 대한 글을 한 블로그에다 몰아서 올린다.
블로그를 따로 운영해야 할 정도로 덕력이 아주 높은 것도 아니어서 말이다..... 어? ㄲㄲㄲㄲ

난 사람들이 자기 관심 분야 블로그에만 가는 걸 원하지 않는다.
내 근황이 궁금하고 나에 대해 알고 싶어서 내 블로그에 온 사람이라면, 좋든 싫든 프로그래밍 관련 글도 보고, 철-_-도 관련 글도 보고, 한글 관련 글, 기독교 관련 글도 보길 원한다.
독자 여러분은 어떻게 생각하실지 모르겠지만 어쨌든 본인은 내 식대로 이런 식으로 블로그를 운영해 나갈 것이다. ㅋㅋ
<날개셋> 한글 입력기 카테고리가 몇 달째 글이 없으니 오늘은 또 오랜만에 개발 근황을 전하도록 하겠다.

2.

<날개셋> 한글 입력기의 다음 버전은 6.2로 확정했다. 나흘 뒤인 8월 21일 아침에 나올 예정이다. 현재 코딩은 거의 마쳤고 테스트와 도움말 작성 중이다.
편집기를 안 쓰는 분에게는 그리 큰 해당 사항이 없겠지만, 6.2에 대해서는 지금까지 오랜 숙원이었던 에디팅 엔진의 최적화 소식부터 먼저 전해야겠다.
무려 7년 전, 3.0 시절 이래로 변함없이 남아 있던 에디팅 엔진을 뒤집어엎었다. 옛날 코드의 로직을 재구성하여 더 정교하게 다시 만드는 게 쉬운 일이 아니었다.

예전 버전이 얼마나 비효율적이었는지를 단적으로 설명하자면 이렇다.
수십만 줄에 달하는 텍스트를 불러와서 맨 앞줄에서 엔터를 눌러서 줄을 삽입하거나 텍스트를 붙여넣으면 그 줄부터 문서 끝까지 내부적으로는 행번호가 다 renumbering된다. -_-;;
그리고 undo 한번 할 때마다 그 텍스트 레이아웃이 전부 다시 짜진다.

이제는 아무리 큰 문서를 불러와도 텍스트 레이아웃과 재배치는 영향을 받은 문단에서만 일어나며, renumbering도 없어졌다. Ctrl+Z를 마음껏 눌러도 된다.
다른 작업 우선순위에 밀리고 또 밀려서 7년 동안 못 하고 있던 일을 이제야 해냈다.
3.0을 만들던 당시는 세벌식 모아치기와 새로운 한글 입력 오토마타에 치중하느라, 에디팅 엔진은 비록 구닥다리 2.x에 비해서야 혁신이었지만 그래도 시간 관계상 대충 발로 짠 부분이 있었던 것이다.

이번 버전은 파일 저장도 매 줄마다 디스크에 쓰는 게 아니라, 수 MB 단위로 버퍼에다 미리 저장한 후 한꺼번에 디스크에 쓰게 함으로써 속도를 크게 향상시켰다. 이렇게 하는 게 이 정도로 큰 차이를 만들 줄은 몰랐다.
<날개셋> 변환기의 파일 변환 속도도 훨씬 더 빨라졌다.
학교에서 실제로 수~수십 MB에 달하는 옛한글 말뭉치 파일을 다뤄 보고서야 성능을 개선할 필요를 느꼈다.

3.

그리고 <날개셋> 편집기는 이제 legacy format(한컴 2바이트 코드 및 한양 PUA)으로 클립보드를 읽고 쓰는 기능이 없어지고, 편집 메뉴에 '선택하여 붙여넣기'(Paste special) 기능도 없어진다. Paste special은 무려 <날개셋> 한글 입력기 2.0때부터 있었던 기능이지만, 이 프로그램이 텍스트에다 서식을 넣을 수 있는 워드 프로세서도 아니고 사실 필요 없는 기능이다. 유니코드 하나만 신경 쓰면 되니까 말이다.

그 대신 이 기능들은 <날개셋> 변환기로 이동한다. 다만, 지금까지 한컴 2바이트 코드를 읽는 것 말고 '쓰는' 기능은 제2수준 한자를 지원하지 않았었는데, '쓰는' 것도 가능해진다. 클립보드 변환 기능까지 그대로 지원되긴 하지만, 아래아한글 97이나 <날개셋> 무려 2.x와 텍스트 데이터를 변환하는 상황이 아니라면 이제 쓸 일은 없을 것이다. 그러니 호환성 유틸리티인 변환기로 기능 이전.
하지만 유니코드가 등장하기 전에 아래아한글이 국어 정보 처리에 끼친 영향력을 감안하면, 한컴 2바이트 코드 지원을 완전히 없애 버릴 수는 없다.;;

또한, 옛한글을 한양 PUA <-> 유니코드 5.2 형식으로 변환하는 기능은 '텍스트 필터'로도 들어가서 편집기나 외부 모듈이 즉석에서 사용 가능하게 된다. 한양 PUA의 인지도는 아직까지도 무시할 수 없기 때문에..;;
이걸 감안하면, 비록 편집기의 한양 PUA 지원 기능은 겉으로는 일관성 차원에서 사라지지만, 동일 기능이 더 유용한 다른 형태로 대체되는 셈이다.

덤으로, <날개셋> 변환기는 옛한글 변환은 지금까지 UTF16 방식의 파일밖에 지원하지 않았다가 이제 드디어 UTF8도 지원할 예정이다. 그리고 명령줄에서는 하위 디렉터리의 모든 파일을 재귀적으로 찾아서 변환하는 /S 옵션이 추가된다.

4.

이렇듯, <날개셋> 한글 입력기의 다음 버전은 편집기와 변환기가 바뀐 게 많고 외부 모듈은 변화 사항이 상대적으로 적다고 볼 수 있다. 그래도 외부 모듈이 바뀐 걸 나열하자면,

첫째, 한글 글자판을 찾을 때 무조건 맨 위의 0번부터 그 아래가 아니라, 6.0에서 추가된 개념인 '기본 입력 항목'부터 먼저 고려하기 시작했다. (진작에 이렇게 했어야지..)
둘째, 편집기와 외부 모듈을 같이 쓰는 경우, 편집기에서 프로그램의 UI 언어를 바꾸면 외부 모듈도 아쉬운 대로 그걸 따라가게 했다.

이 외에, 프로그램 전반적으로는
수식에서 ? : 연산자와 콤마 연산자가 변수를 되돌리면 거기에 바로 대입이 가능하게 문법이 확장되었으며,
정 재민 님의 제안과 도움 덕분에 몇몇 글꼴들이 최신 유니코드 규격대로 업데이트되었다.
그리고 천지인· 나랏글과 더불어 스마트폰의 3대 복수 표준 입력 방식 중 하나가 된 팬텍 SKY 방식도 예제 입력 설정 파일을 만들어서 추가했다.

텍스트 필터 중에 '일괄 치환 필터'라고, 여러 건의 바꾸기 작업을 한꺼번에 수행하고 심지어 줄바꿈 문자까지 찾기-바꾸기 문자열에 포함할 수 있는 강력한 필터가 있는데,
여기에 있던 사소한 버그를 잡고, 이 필터에 '반복 적용' 옵션을 추가했다.
이걸 잘 활용하면 [   a   ], [ b  ] 같은 문자열도 싹 다 [a], [b] 같은 식으로 일괄적으로 공백 정리를 할 수도 있다. 이런 기능을 넣을 생각을 지금까지 왜 안 했는지 모르겠다.
적은 노력에 비해서 무척 유용할 수 있는 기능을 찾아내서 구현하는 건 참 즐거운 일이다.

끝으로, 타자연습은,
문장 연습 중에 오타를 내고서 Ctrl+Z를 눌렀을 때, 텍스트가 없어진 뒤에도 텍스트 위의 오타 마크가 사라지지 않던 버그를 잡았다.
그리고 게임은 이제 레벨이 올라갔을 때 자동 저장을 해 주지 않는다. 게임 중에 사용자가 단축키를 눌렀을 때만 해당 단계의 점수, 방어력, 주인공으로 나중에 게임을 이어서 할 수 있게 그 상태가 저장된다. 따라서 해당 단계의 초반에 저장을 하든, 끝날 때가 다 돼서 저장을 하든 그건 상관없다.

<날개셋> 타자연습의 게임 저장 체계는 어찌 보면 페르시아의 왕자 1의 그것과 비슷해졌다고 볼 수 있다.
(레벨의 첫 시작 시점만 저장할 수 있고, 한 시점만 저장 가능하다는 점에서)

5.
끝으로 여담,
<날개셋> 편집기처럼 텍스트 에디터를 처음부터 새로 만든다는 건 결코 쉬운 일이 아니다.
특히 유니코드의 complex script를 완벽하게 지원하려면 이미 거의 워드 프로세서 수준에 도달한다. 커서 이동, 마우스 포인터 위치로부터 문자열 위치 판단, 문단 정렬 같은 기본 중의 기본 작업들조차 완전 어려운 작업이 되기 때문이다. 내 프로그램은 그런 자질구레한 건 개발의 주목적이 아니기 때문에 죄다 깔끔하게 무시하고 개발되는데도 이 작업만으로도 코드의 양이 만만찮다.

WinAPI.co.kr의 운영자로 유명한 김 상형 님은 이런 텍스트 에디터를 개발하는 튜토리얼을 제공하고 있으니 초보 개발자들에게 무척 유익하다. 요즘 세상에 저 정도 프로젝트를 대인배스럽게 공개하는 분은 정말 드문데... 관심 있으신 분은 참고하기 바란다.

<날개셋> 입력기와 타자연습의 다음 버전도 어김없이 예전 버전과의 API 호환성은 깨질 예정이다. =_=;;; 따라서 둘을 원활히 같이 쓰려면 둘을 모두 업데이트해야 한다.
이제는 좀 바꿀 일이 없겠지 싶은 요소들도 계속 바뀐다. 그만큼 <날개셋> 한글 입력기는 여전히 활발하게 개발이 진행 중이고 살아 있는 프로젝트라는 뜻이기도 하다.

당초 계획했던 한자 관련 기능을 추가 못 하고, 입력기 커널에 내가 원하는 기능을 여건상 못 넣었는데, 이건 올해 하반기에 나올 또 다음 버전에서 기약을 해야겠다.

Posted by 사무엘

2011/08/17 08:11 2011/08/17 08:11
,
Response
No Trackback , 11 Comments
RSS :
http://moogi.new21.org/tc/rss/response/556

C/C++에는 ? : 라는 독특한 연산자가 있다. A ? B: C꼴로 표현되어 피연산자가 3개나 붙는 유일한 연산자이다.
이 연산자의 역할은 매우 단순하다. A가 참이면 연산자의 값은 B가 되고, 그렇지 않으면 C가 된다. 그래서 아예 if문의 역할을 간단히 대신할 수도 있으며, 콤마 연산자와 결합하면 어지간한 함수 호출마저도 한 연산식에다 박아 넣을 수 있다. 다만, 그게 너무 사악하다고 여겨졌는지-_-, C# 언어에는 콤마 연산자가 사라지고 콤마는 for 키워드 안에서만 제한적으로나 허용되지 싶다.

? : 는 &&, || 와 마찬가지로 C/C++에서 단축연산이 적용된다. A && B에서 A가 거짓이면 B는 실행이 전혀 되지 않고 전체 결과가 거짓이 되며, A || B에서 A가 참이면 B는 실행되지 않고 바로 전체 결과가 참이 된다. 그런 것처럼 ? :는 선택되지 않은 항에 대해서는 당연히 연산이 일어나지 않는다.

<날개셋> 한글 입력기는 짝퉁 C언어 문법 수식 해석기를 내장하고 있기 때문에, 이를 이용해 글쇠, 오토마타, 글자판 전환 글쇠 등에서 문자 입력 시스템의 자유도를 굉장히 높일 수 있다. 비록 튜링 완전한 수준은 못 돼도 말이다. 이때에도 ? : 연산자는 물론 매우 요긴하게 쓰인다.

? : 는 좌결합이 아니라 우결합이다. A ? B : C ? D : E는 (A?B:C) ? D : E가 아니라 A ? B : (C?D:E)로 결합한다. 그러므로 전자처럼 쓰려면 괄호를 넣어 줘야 한다.

? : 는 다른 연산 구문들을 포함하는 if문 대용처럼 쓰이는 만큼, 연산자의 우선순위가 상당히 낮다. 다른 평범한 연산자들이 다 결합한 뒤 나중에야 적용된다. 그게 합리적이다.
그러나 얘도 콤마와 대입 연산자보다는 순위가 높다. 그렇기 때문에 A = B ? C : D 라고 써 주면 알아서 A = (B?C:D)로 해석되어, A에는 B 조건의 충족 여부에 따라 C 아니면 D가 대입된다.

반대로, ? : 의 내부에 콤마 연산이나 대입 연산이 포함되어야 한다면 이들 연산은 무조건 괄호로 싸야 한다.

A ? (B=2): (C=5)
B에다가 괄호를 안 하면 = 가 ?와 :를 둘로 쪼개 버리는 효과가 나기 때문에 에러가 발생한다.
그리고 C에다가도 괄호를 생략할 수 없는데, 괄호를 안 하면 연산의 의미가 (A?(B=2):C)=5가 되어 버리기 때문이다. 우선순위의 특성상, =가 C항이 아니라 ? = 전체와 대응한다는 뜻 되겠다.

그리고 또 생각해 볼 것은, ? : 연산자의 값은 L-value가 될 수 있겠냐는 점이다. (대입 가능하겠냐)
<날개셋> 한글 입력기는 수식이 처음 도입된 3.0 이래로 지금까지 (조건 ? A:B)=100 과 같은 구문이 지원된 적은 없다. 그러나 이제 <날개셋> 6.0 이후의 다음 버전부터는 그게 가능해진다. 단, 2항과 3항 중 하나라도 변수에 연산자가 조금이라도 붙어서 A+2, -B 같은 형태가 되면 L-value 원칙이 깨지게 되는데, 그런 오류는 수식 입력 시점에서 프로그램이 자동으로 감지해 준다.

이게 지원되면 조건 ? (A=100): (B=100)보다야 구문을 더욱 간단하게 만들 수 있으니까 사용자의 입장에서 좋을 것이다. 더구나 콤마 연산자도 최후의 항의 변수 정보를 남겨 주기 때문에 (조건 ? (A=100,C): (B=50,D)) +=20 같은 복잡한 대입도 가능해진다. 저 식의 의미는 무엇일지 독자 여러분이 생각해 보기 바란다.

정작 이 연산자에서는 괄호가 필요하지 않다. 조건 ? A:B=100 이라고 하면 (조건 ? A:B)=100이 되며, 100 대입 연산은 3항의 B에만 연결되는 게 아니라 ? : 연산의 결과 전체에 걸린다. ? : 의 우선순위가 =보다 높기 때문에 =보다 먼저 계산되기 때문이다.

<날개셋> 한글 입력기로 복잡한 수식을 다뤄 본 분들은 이미 아시겠지만, 이 프로그램은 사용자가 입력한 수식을 어느 정도 자동으로 간소화를 한다. 상수 연산은 미리 계산을 해 버리며, 100/0나 2=A 같은 뻔한 에러는 미리 지적해 준다. 그리고 우선순위 규정상 굳이 칠 필요가 없는 괄호도 알아서 제거를 해 버린다.

(A+B)-C는 A+B-C로 바뀌며, 이와 비슷한 맥락으로 (조건 ? A:B)=100도 그냥 조건 ? A:B=100으로 바꾼다. 이건 프로그램의 오동작이 아니므로 놀라지 말고 수식을 사용하면 된다.

그런데 비주얼 C++ 같은 요즘의 C/C++ 컴파일러들은 ? :를 본인이 생각한 것처럼 취급하지 않는 것 같다.
A==100 ?B:C=400 라고 하면 =400은 3항의 C에만 붙지 B에는 붙지 않는다. (A==100 ? B:C)=400이라고 해 줘야 한다.
또한 ?와 : 사이에 있는 2항은 사이에 대입이나 콤마 같은 연산자(우선순위가 ? :보다 한참 더 낮은!)가 괄호 없이 연결되어 있어도 알아서 2항의 일부라고 인식해 주는 듯.
물론, 그렇다고 해서 A=조건 ? 2항: 3항 같은 문장이 있으면 A=까지 조건으로 끌어들이지는 않는다.

이런 세세한 동작 방식에 대해서 정보를 얻고 싶어서 비주얼 C++ 도움말을 찾아봐도, ? :는 대입 연산자보다 우선순위가 높다던가, 2항과 3항의 타입이 서로 다를 때 연산자 값이 정해지는 원칙 같은 원론적인 말밖에 없다. 그 말대로라면 무조건 내 프로그램처럼 괄호를 써야만 할 텐데 말이다.

그 간단한 ? : 연산자에도 의외로 복잡한 사연이 있다는 걸 알 수 있다.
어쨌든 내 프로그램은 ? : 안에 대입이나 콤마 연산을 포함시키려면 무조건 괄호를 써야만 하는 구조가 앞으로도 유지될 것이다.

Posted by 사무엘

2011/06/05 19:20 2011/06/05 19:20
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/521

날개셋 한글 입력기 6.0

※ 드디어 6.0 시대

5.8 이후 거의 5개월에 가까운 기간 동안 <날개셋> 한글 입력기가 발전한 결과물을 드디어 이렇게 선보이게 되어 대단히 기쁩니다. 무려 6.0!! 5.x에서 6.0이라는 이름이 전혀 아깝지 않을만치 변했습니다. 5.8 이후 소스 커밋은 약 60여 회(change set 개수)가 있었군요. 9개 모듈과 공용 라이브러리의 소스 코드 총합은 현재 약 6만 1천 줄.

초· 종성 공유 낱자 결합 규칙이 추가된 덕분에, 프로그램의 핵심이라 할 수 있는 한글 입력 오토마타 부분이 오랜만에 크게 바뀌었습니다. 아직 100% 완전체가 구현된 건 아니지만 이걸 쓰면 복잡한 두벌식 한글 입력 방식을 구현하는 게 눈물나게 수월해집니다. 그 구체적인 메카니즘은 도움말에 자세히 설명되어 있습니다. 진작부터 추가되어야 했을 기능인데 이제야 도입됐고요.

조합 자동 종료 타이머는 제어판에서 ‘입력 일반’ 항목에 수식의 형태로 깔~끔하게 추가됐습니다. 예제로 제공되는 삼성 천지인 입력 방식이 당장 이걸 사용합니다. A==3 ? 1000: 0 즉, 오토마타 상태가 3번(종성 입력)일 때 1초간 제한을 둬서 사용자가 다음 타를 입력하지 않으면 음절을 끊게 됩니다. 그냥 1000이라고만 입력하면 모든 조합 상태에서 1초 제한이 걸리겠죠.
한글 입력 상태는 A, 그리고 <날개셋> 고급 입력기의 사용자 조합 상태 번호는 B이므로 이들 변수에 대한 수식을 자유롭게 지정할 수 있습니다.

현재 사용할 입력 항목과, 프로그램이 시작될 때 처음으로 지정할 입력 항목을 따로 지정할 수 있게 되고, 입력 항목의 배열 순서를 숫자 직접 입력 및 up-down 컨트롤로 손쉽게 바꿀 수 있게 된 것도 개인적으로는 정말 멋진 변화 사항이라 생각합니다. 제어판 화면을 직접 보시면 압니다.

이 외에도 바뀐 것 많습니다.
외부 모듈의 안정성 관련 이슈는 MS IME의 소스를 직접 참고하지 않는 한 앞으로 6.x 시대에도 계속 나올 것 같고..

※ 타자연습

타자연습은 명목상으로는 바뀐 API 구조대로 프로그램을 재컴파일하고 연습글을 일부 고친 것 말고는 변화 사항이 없습니다. 그래서 버전을 올리지 않았습니다. 그러나 기능 변화가 없다고 입력기만 6.0으로 업그레이드하고 타자연습을 업그레이드하지 않으면, 타자연습 내부에서는 <날개셋> 한글 입력기 6.0 외부 모듈을 사용할 수 없게 됩니다. 자체 입력란 말고 일반 입력란에서는 한글을 입력할 수 없고 MS IME 같은 다른 IME를 써야 한다는 뜻입니다.

그러므로 <날개셋>을 윈도우용 IME로 사용하면서 타자연습도 동시에 사용하시는 분이라면 타자연습 프로그램을 반드시 업그레이드해야 합니다. 가능한 한 API 수준의 바이너리 호환성을 안 깨뜨리려고 노력하지만, 6.0은 한글 입력과 타자 재현 루틴 쪽이 많이 바뀌다 보니(타자연습도 핵심적으로 자주 사용하는 기능인데!) 어쩔 수 없이 호환성이 깨지게 됐습니다.

그래도 변화가 너무 없으면 재미없으니까..
연습글의 변화로는,
헌법 연습글에서 헌법 전문(preface)만 있던 걸 1장과 2장도 추가했습니다.
그리고 ‘재미있는 이야기에’ 주옥같은 김 성모 어록을 단문 연습글로 추가했습니다! “미안하다. 똥 싸느라 늦었다”, “더 이상의 자세한 설명은 생략한다”, “하지만 드라군이 출동하면 어떨까?” 등으로 세벌식 타자 연습을 즐겨 보세요!! ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

연습글의 패치 정도는 정말로 자동 업데이트 시스템이라도 있으면 편하긴 하겠죠. 저도 그런 것의 필요성을 느끼고는 있습니다.

※ 몇몇 표기법 변경

프로그램의 모든 UI와 도움말, 그리고 타자연습의 경우 연습글에서 한국 인명의 1-2자 성명은 성과 이름을 붙여 쓰는 것으로 표기를 바꿨습니다. (공병우, 김용묵) 제 프로그램을 처음 접하는 사람에게 이질감을 줄이기 위해서 취한 조치입니다.
하지만 여타 길이의 인명은 여전히 띄어 씁니다. (김 구, 남궁 억, 김 에스더 등~)

한 10년 동안 일부러 표준 표기법을 안 지키다가 관행을 되돌렸으나, 제 느낌상 다시 생각해 봐도 성과 이름은 일관성 있게 띄어 쓰는 게 더 합리적입니다.
제 블로그는 저의 개인 공간이기 때문에 앞으로도 둘을 여전히 띄어 쓸 것입니다.

※ 안 마태 글자판

안 마태 한글 소리글판이 업데이트됐다는 소식을 들었습니다. 그런데 공식 홈페이지에 제대로 홍보가 안 돼 있고, 키보드 드라이버를 개발하시는 분이 블로그에 게시해 놓은 배열과 공식 홈페이지의 배열이 일치하지 않으며, 심지어 레이아웃이 일반 키보드의 모양과도 일치하지 않는 부분 등 여러 문제로 인해, 제 프로그램의 예제 데이터에는 아직 업데이트를 안 했습니다.

※ 다음 버전은?

이제 6.0 이후의 입력기의 다음 버전은 현재로서는 6.1이나 6.2 정도로 생각 중입니다. 시기는 올해 가을쯤? 이번에는 한글이 아닌 ‘한자 기능 강화판’ 컨셉이라는 생각이 들기에 충분할 겁니다.
단어 단위 한자 변환 기능이 드디어 추가되고,
자료가 확보되는 대로 surrogate(확장 B 이상) 영역의 한자에 대한 독음· 부수 입력 지원 등이 계획되어 있습니다.

아주 옛날스러운-_- 글쓰기를 좋아하는 분 중에, 단어 단위 한자 변환 기능이 있다는 이유로 새나루 입력기를 아주 좋아하는 분이 있죠. 참고로 제 편집기는 세로쓰기도 지원한다만... -_-;;;

뭐, 제가 한자 혼용론자의 수요를 의식하는 건 아니고요. 저런 쪽의 연구는 단순히 MS IME와의 기능 격차를 줄이고 제 프로그램의 기술 데모를 만든다는 성격이 더 강합니다. 단어 단위 한자 변환은 MS IME가 그런 것처럼 TSF A급 프로그램에서만 제공될 것입니다.

지금은 옵션이 달랑 3개밖에 없는 편집기 계층에 한자를 단어 단위로 변환할지 글자 단위로 변환할 지 선택을 할 수 있게 되며, surrogate 영역의 확장 한자까지 후보로 출력할지 설정하는 옵션도 추가됩니다. 솔직히 일반 사용자가 BMP 이외의 한자를 쓸 일은 거의 없고, 그런 것까지 그냥 추가해 버리면 한자 후보가 이제 너무 많아지기 때문이죠.
부수+독음(ㄱ~ㅎ이니셜 정도) 연동 한자 검색 기능 추가도 검토 중입니다. 꽤 유용할 것입니다.
물론 한자 관련 기능만 계획되어 있는 건 아니고요.

※ 잡설

이번 6.0은 제발 잔버그가(특히 새로 추가된 기능에서) 발견되지 않았으면 하는 바람이 간절합니다.
작업 완료에 앞서 도움말을 쭉 읽고 검토를 했는데, 좋은 의미로든 비아냥거리는 의미로든 이게 정녕 내가 내 머리로 만든 프로그램과 설명서가 맞나 하는 생각이 들더군요. 내가 지금까지 참 어지간히도 또라이 같은 짓을 했구나 하는 생각.. -_-;;

맥/리눅스로의 포팅, 프로그램 아이콘, 그리고 다국어 UI 번역 등 역할 분담의 필요성이 느껴집니다. 타자연습은 이미 도저히 내 혼자 개발을 할 수 없는 경지에 간 지가 오래이고..;; 저도 슬슬 개발자 마인드에서 벗어나 사장-_- 컨셉으로 가야 하지 않나 싶습니다.

타자연습의 경우, 생각 같아서는 10년 가까이 묵은 연습글들 대부분을 이제 좀 갈아엎어 버리고 싶답니다. -_-;; 그런데 그것도 제가 할 시간과 능력이 안 되고. 게임은? ‘더 이상의 자세한 설명은 생략한다’ 수준. 어쨌든 결론은 돈인데..;;
“내가 나루토를 보면서 느낀 건데, 사람을 쓰려면 돈이 존나 필요할 거 같아. 그런데 날개셋은 수익이 없잖아? 그러니까 우린 안 될 거야 아마..” ㅋㅋㅋㅋㅋ 뼈 있는 농담. -_-

뭐 그렇습니다.
유용하게 사용하시기 바랍니다. ^^

Posted by 사무엘

2011/04/28 11:24 2011/04/28 11:24
Response
No Trackback , 34 Comments
RSS :
http://moogi.new21.org/tc/rss/response/503

My Programming Life

1.

<날개셋> 한글 입력기는 동일한 입력기 커널을 공유하는 세 개의 프런트 엔드가 있다.
그 중에서 가장 존재감 있는 터줏대감은 전용 에디터인 편집기이고, 실질적으로 가장 널리 이용되는 프로그램은 윈도우용 IME인 외부 모듈이다. 한편, 편집기처럼 실행되어 마치 IME처럼 동작하는 포인팅 장치 입력 유틸리티인 입력 패드도 지난 5.3 버전에서부터 추가되어 제 3의 프런트 엔드 구실을 하고 있다.

그 중 가장 먼저 만들어진 ‘편집기’는... 프로그램을 만든 본인부터가 에디터로서 아주 유용히 사용한다.
차라리 외부 모듈은 디버깅 할 때 외에는 사용하지 않는다. 운영체제의 기본 IME로 지정되어 있으면 파일을 고칠 수가 없어서 디버깅을 못 하기도 하기 때문이다.

<날개셋> 편집기는 어떤 점에서는 아주 답답하다. 가변폭 글꼴이 지원 안 되고 글씨 크기 조절도 안 되고, ClearType 렌더링이라든가 OpenType 스펙 등 오늘날의 모든 최신 타이포그래피 기술로부터 완벽하게 소외된 외딴 섬이기 때문이다.

그러나 한편으로 <날개셋> 편집기는 아주 작고 가벼우면서도 윈도우 95 이래 어떤 OS에서나 동일하게 유니코드 5.2 옛한글을 마음대로 조합할 수 있고 한글을 내 마음대로 다룰 수 있는 우리집 안방 같은 공간이다. 내가 만든 프로그램이어서 자화자찬 차원이 아니라 정말로 그렇다.
입력 기능뿐만 아니라 다양한 텍스트 필터도 있고, 한글을 자모 단위로 찾고 입력기에다 넘겨주는 글쇠를 붙여넣는 것 같은 아기자기한 기능도 있다. 도스 시절 추억의 도깨비 한글 비트맵 글꼴을 볼 수 있는 건 덤이다.

예전에는 옛한글은 오로지 내장 글꼴로밖에 표현할 수 없었는데 5.3에서부터 임의의 조합 테이블과 추가 자모를 내장 가능한 자체 비트맵 글꼴 포맷을 제정함으로써 <날개셋> 한글 입력기의 커널은 나름대로 글꼴도 독립을 이뤘다. 아래아한글 1.x와 비슷한 글월 입력 환경을 윈도우 환경에서 재현해 낸 것이다.

완전한 텍스트 에디터 엔진을 처음부터 새로 만들었기 때문에, 앞으로 한글 표현 방식이 어떻게 바뀌든 이 구조에 맞춰 엔진을 마음대로 내가 고칠 수 있다.
리눅스나 맥 OS에서는 이런 게 언제쯤 상륙 가능할까? ㄲㄲ

2.

지금까지 <날개셋> 한글 입력기를 만드는 과정에서 그 당시엔 내가 방법을 전혀 몰라서 어려움을 겪던 고비가 몇 차례 있었다.
- 인스톨 패키지 만들기(2002~2003년): MSI 기반으로 완전히 해결
- 외부 모듈(2004~2005년): 3.x 초창기 버전 때 무수한 시행 착오를 겪으면서 결국 안정화 단계. 하지만 “아직까지도” 일부 극소수 몰상식-_-한 응용 프로그램에서 사소한 오동작 버그 신고가 올라오고 있음
- 64비트(2007년): 결국은 본인이 64비트 기계를 직접 장만하면서 지원에 성공.

3.

한 컴퓨터를 놔두고 세벌식 사용자인 본인과 두벌식 사용자인 지인이 같이 앉아 문서를 읽으면서 검토와 교정을 하고 있었다. 이때 복벌식 입력 방식을 아주 유용하게 사용했다. 글자판 전환을 할 필요 없이 서로 자기에게 익숙한 글자판으로 자기가 수정하고 싶은 곳에서 바로 글자를 입력하면 되니 이렇게 편할 수가 없었다. ^^

이거 하니까 세벌식 관련 다른 팁이 또 생각난다. 세벌식 숫자 배열이 익숙한 분이라면, numlock이 켜져 있을 때 오른손 숫자 자리가 non-shift 자리로 내려오게 하면 엑셀 같은 데서 숫자 입력을 아주 편리하게 할 수 있다. <날개셋> 한글 입력기로는 가능하다.

4.

버전 5.53 내지 5.65쯤부터 추가되었지 싶은데, <날개셋> 편집기로 프로그램이 아닌 문서 창(MDI)의 시스템 메뉴를 보면 해당 문서 파일의 ‘속성’ 창을 바로 꺼내거나, 탐색기를 꺼내거나 전체 경로를 복사하는 명령이 있다. ‘파일 경로 복사’를 고르면 되는데, 지금까지는 진짜 말 그대로 파일의 경로가 텍스트 형태로 복사되어 메모장에서만 그걸 붙여넣을 수 있었다.

그런데 탐색기에서 Ctrl+V를 누르면 해당 파일 자체가 실제로 복사도 되게끔 프로그램을 고쳐 봤다. 메모장과 탐색기는 클립보드를 사용하는 방식이 완전히 다르기 때문에 이 기능은 서로 충돌을 일으키지 않으며, 이렇게 하니까 아주 편하다. 5.8 버전에 이 기능이 반영되지 못해서 아쉽다.

5.8을 릴리즈한 후 현재까지 도움말의 오타 내지 로그인 화면· 아웃룩· vim 등에서의 사소하지만 쉽지 않은 외부 모듈 관련 버그가 몇 개 보고되어 있다. 하지만 다들 프로그램의 성능이나 안정성(죽는다거나-_-)과 관련된 건 아니다. MS IME의 소스를 직접 보지 않는 이상 이런 것까지 다 완벽하게 처리하는 버그 없는 IME란 제작 불가능하다. -_-

5.

다음은 <날개셋> 타자연습 이야기. 지금부터는 그림도 좀 곁들이겠다.

사용자 삽입 이미지
요즘도 실력 유지를 위해 타자 연습을 안 하는 건 아닌데,
주옥같은 연습글을 만들었다. 다음 버전에 추가할지 진지하게 고민 중이다. ^^;;

공 병우 세벌식은 10년을 넘게 써도 한글의 위상을 끌어올린 정말 위대한 발명품임이 느껴진다. 그 반면 저 불편한 현행 두벌식 글자판은 어떻게 쓰는지 그걸로 빨리 치는 사람들이 대단하기 그지없다. 세벌식의 단점--기껏해야 글쇠 수 좀 많고 4단 쓰는 것--에 비해 두벌식의 단점은 훨씬 더 치명적이다.

사용자 삽입 이미지
2008년부터 2010년까지 존재하는 본인의 게임 점수판은 전부 ‘승리’(12단계 깨고 엔딩)이다. 본인이 사무엘이라는 이름을 쓰기 시작한 건 2008년 말부터임.
<날개셋> 타자 게임은 과거의 한메 타자 베네치아보다 훨~씬 더 어렵지만 요즘은 한글 타자가 워낙 일상화했기 때문에 본인 말고도 엔딩 보는 사람이 꽤 있을 것이다.

6.

끝으로, 10년 전에 만들었던 WordTech 엔진(컴퓨터 자동 대국 기능)을 요즘 완전히 새로 다시 짜고 있다. 스크린샷은 기존 WordTech와, 새 엔진(GUI를 갖다붙이지 않은 콘솔 프로그램)끼리 서로 검증 대국을 시키는 모습이다.

사용자 삽입 이미지
본인은 <날개셋> 한글 입력기를 만들기 전엔 국내에서 거의 최초로 크로스워드 게임 엔진을 만든 바 있으나... 그 당시의 작품은 지금의 관점에서 보면 기술적으로 개허접.. ㄲㄲㄲㄲ

요즘은 워낙 컴퓨터가 똑똑해진 덕분에, 굳이 이것보다 더 빠르고 메모리를 덜 쓰는 크로스워드 게임 엔진을 만든다는 게 큰 의미는 없지만... 이번에 새로 짠 코드는 메모리 사용량, 계산량, lexicon의 자료구조와 알고리즘, 코드의 깔끔함과 재사용성 등 모든 면에서 10년 전의 구닥다리 코드와는 비교가 되지 않는다. 참으로 아름답다. ^^;;

사실, 이렇게 만들면 된다는 이론적 기반은 이미 수 년 전에 완성되었지만 <날개셋> 개발 때문에 뒷전으로 밀려서 지금까지 작업을 못 하고 있었을 뿐이다.
WordTech도 버전업 좀 하고 싶은데.. ㅠㅠ 컴퓨터과학과 대학원 수업에서 무슨 과목으로든 프로젝트로 좀 할 기회라도 있었으면 좋겠다. 이 엔진 얹으면 버전 4.0으로 가는 건데.;;

콘솔은 만국의 공통 인터페이스이다 보니(표준 입출력 스트림^^), 엔진을 비주얼 C++뿐만이 아니라 오랜만에 DJGPP로도 컴파일해서 도스에서 돌려 봤다. 똑같이 32비트이기 때문에 별 어려움 없이 돌아간다. 지금도 DJGPP가 버전업이 되고 있는지는 모르겠지만 내가 보유하고 있는 건 무려 1997년에 설치한 버전. 혹시 bool 키워드가 지원되지 않나 확인해 봤는데 다행히 지원한다.

10년 전에는 DJGPP의 그 느린 빌드 속도가 무척 거슬렸으나 지금은 그마저도 전광석화. 별도의 도스박스 같은 에뮬뿐만이 아니라 그냥 윈도우 운영체제의 NTVDM에서도 잘 돌아간다.
단, printf의 포맷 지정자로 %c만 인식하고 %C는 인식하지 않는다. 대문자를 찍는다는 생각에 %X와 %x(16진수 숫자)를 구분하듯 습관적으로 %C를 지정해 줬는데 인식이 안 되더라. 뭐, 어차피 찍을 때 chCode+'A' 식으로 대문자를 지정하기 때문에 %c와 %C는 전혀 구분할 필요가 없고 %c만 지원해도 충분하긴 하다.

이상으로 본인의 programming life 잡설 끗.

Posted by 사무엘

2010/12/29 16:46 2010/12/29 16:46
, , , , , ,
Response
No Trackback , 12 Comments
RSS :
http://moogi.new21.org/tc/rss/response/440

※ 아래의 세 버그는 해당 기능이 처음으로 추가된 5.31버전부터 지금까지 1년이 넘는 시간 동안 존재하다가 이제야 발견하고 고쳐졌습니다.

- "코드번호로 변환" 텍스트 필터의 설정을 고쳤는데 번호 표현 형태(format)가 사용자의 설정대로 제대로 적용되지 않던 버그
- <날개셋> 편집기의 "계산기"에서 '사용할 상수'를 바꿔 줬는데도 해당 분야에 속하는 상수가 제대로 인식되지 않던 버그

- 외부 모듈: <날개셋> 한글 입력기는 TSF A급 프로그램에서는 bksp 키를 눌렀을 때 앞 글자로 달라붙는 기능을 사용할 수 있습니다. 그런데 언제부턴가--한 5.3x 정도부터로 추정-- 완성된 글자를 처음으로 지울 때는 달라붙는 게 동작하지 않는 문제가 있더군요. 아마 입력 패드 같은 기능이 처음으로 추가되면서 들어간 side effect 같습니다. 이걸 발견하여 버그를 고쳤습니다.

※ 아래의 버그는 현재의 최신 버전인 5.65에만 있다가 고쳐졌습니다.

- <날개셋> 편집기를 중복 실행을 허용하지 않은 상태에서 또 중복 실행하면, 예전 인스턴스에서 새 문서도 같이 만들어져야 하는데 되지 않는 것
- <날개셋> 제어판의 '낱자 처리' 탭에서 낱자 결합 규칙의 내정값으로 "유니코드 5.2 옛한글"을 골랐는데도 유니코드 5.2에서 새로 추가된 초록색 옛한글 낱자들이 로딩되지 않던 문제
- 낱자 결합 규칙 리스트에서 비사이클 -> 사이클이 있는 결합 규칙을 대상으로 Ctrl+클릭을 했을 때 프로그램이 무한 루프에 빠지고 죽는 버그 (Ctrl+클릭 기능 자체가 5.65에서 새로 추가된 것임)

※ 다음은 사소한 개선 사항들입니다.

편집기 UI: 프로그램을 종료(Exit)할 때나 창을 한꺼번에 모두 닫을 때(Close All), 저장되지 않은 문서가 둘 이상 있으면 "저장할까요?" 대화상자와 더불어 "다음부터 이 질문을 하지 않음" 체크 상자가 뜹니다. 그래서 이걸 체크하면 여러 문서들을 한꺼번에 저장하거나 단번에 무시하고 버릴 수 있게 했습니다.
단, 이 UI는 윈도우 비스타 이상에서부터만 지원됩니다.

변환기 UI: 클립보드의 옛한글 텍스트 표현 방식을 자동으로 감지하는 버튼을 추가하고, 이에 덧붙여 원본 형식과 대상 형식을 switch하는 버튼을 추가했습니다. 아래아한글 200x와 2010, 그리고 MS 오피스 200x의 옛한글은 모두 표현 방식이 다릅니다. 변환기를 사용하면 각 방식을 손쉽게 교환할 수 있습니다.

편집기: 수천-수만 줄, 수 MB에 달하는 대용량 텍스트를 블록으로 잡아 복사할 때의 성능을 크게 개선했습니다. 예전에는 이때 잦은 메모리 재할당으로 인해 디스크 thrashing이 일어나면서 동작이 멈출 때도 있었지만, 이제는 전체 메모리를 한 번만 미리 잡아놓고 복사가 매우 신속하게 수행됩니다.

입력 패드와 외부 모듈도 편집기의 한글· 영문 비트맵 글꼴 설정을 따라갑니다.

정 재민 님이 추가로 제공해 주신 비트맵 글꼴을 적용하고, 임 정택 님이 제공해 주신 신세벌식 입력 설정을 적용했습니다. 그리고 예제로 제공되던 천지인 입력 방식을 복잡한 받침까지 완전한 일치하는 형태로 개선해 넣었습니다.

※ 다음은 알려진 문제입니다.

1. 현재 <날개셋> 한글 입력기 5.65와, <날개셋> 타자연습 3.21은 저의 부주의로 인해서 버전 충돌이 있습니다. 그래서 타자연습에서 입력기 외부 모듈이 동작하지 못합니다.
이 문제는 앞으로 입력기가 5.80으로 버전업되고 덩달아 타자연습도 버전업되었을 때, 이 둘을 모두 최신 버전으로 업데이트하면 해결될 예정입니다. 불편을 끼친 것에 양해를 구합니다.

2. <날개셋> 한글 입력기를 기본 IME로 지정한 후 gvim (7.3 기준)을 실행하여 A를 눌러 편집 모드로 들어가면, 영문이던 한영 상태가 느닷없이 한글로 바뀌는 현상이 있습니다. 참고로 TSF 모듈에서만(= 윈도우 비스타/7급) 나타납니다.

이것은... 운영체제의 동작 방식에 대한 정보 미비로 인해 해결이 어려울 것 같습니다. 그 프로그램에 맞게 동작을 고쳐 놓으면, 다른 프로그램에서 side effect가 생기는 식의 현상이기 때문입니다. MS 워드나 파워포인트가 처음 실행될 때 영문이 아닌 한글 모드로 시작하게 하는 옵션과 완전히 동일한 맥락이기 때문에, 제 프로그램이 gvim의 한글 모드 전환만 예외적으로 봐 줘야 할 명분이 없습니다.
물론 MS IME에는 그런 현상이 없죠. 그건 소스나 정확한 스펙이 공개되어 있지 않는 걔네들 방식대로만 가능한 것이기 때문에 제가 그 이상 더 정확한 동작을 구현할 수 없습니다.

3. 윈도우 7, 스타크 2에 이어 비주얼 스튜디오 2010에서도 한글 입력이 잘 안 되는 문제가 보고되어 있으며, 이 역시 해당 프로그램의 버그로 추정됩니다. MS IME에서도 동일하게 발생합니다. 갑자기 최신 소프트웨어들에서 IME 쪽으로 자질구레한 버그가 왜 이리 자꾸 발견되는지 모르겠습니다. 한번 짜고 나서는 고칠 일도 없고 버그가 들어갈 일도 없을 것 같은데.

Posted by 사무엘

2010/11/07 11:23 2010/11/07 11:23
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/406

직업병

1.
레크리에이션 시간에 하는 OX 퀴즈 말이다. 이거 완전 퀵 정렬스럽다는 느낌이 들지 않는지?
퀴즈는 PIVOT값이다. 정말 알쏭달쏭해서 사람들이 O와 X로 반반씩 갈려야 좋은 문제이고,
너무 쉽거나 해서 사람들이 한데 쏠리면 그건 난감하다. 퀵 정렬도 완전 똑같다. ㅋㅋ

2.
수업 시간에 각 학생들에게 설문지를 돌리거나 과제물을 나눠 준다. 내게도 서류 뭉치가 왔는데, 이게 어디서 왔는지 모르겠고 내가 살펴본 뒤에 다음으로 이걸 어느 방향에다가 넘겨줘야 할지 잘 모를 때가 있다.
이건 C++로 치면 iterator이다. 서류 뭉치는 모든 학생들을 한 번씩 순회하는데, ++itor; 명령이 수행되려면 지금의 순회 위치로부터 다음 순회 위치를 알 수 있어야 한다. 트리 구조를 순회한다면, 각 노드마다 부모 노드 포인터도 갖추고 있어야 한다는 뜻.

3.
요즘 존재하는 수많은 웹사이트들 중, html 수작업으로 만들어진 것들은 로컬 환경으로 치면 기계어로 짠 네이티브 프로그램이고, 블로그 엔진 기반은 닷넷처럼 일종의 상부 계층 위에서 돌아가는 프로그램에다 비유할 수 있을 것 같다.
개인 사용자가 나모 같은 에디터로 홈페이지를 만들 일이 없어졌다는 건, 윈도우 환경에서 어셈블러 수작업으로 프로그램을 만들 일이 없어진 것과 비슷한 맥락이 아닌가 싶다.
하지만 Win32 API 같은 네이티브 계층 자체가 완전히 없어지는 날은 과연 올까?

4.
외솔관에 있는 대학원생 독서실에 있다가 위당관으로 수업을 들으러 간다. 두 건물의 뒤쪽엔 높은 언덕이 있기 때문에 3층과 4층이 뒷문으로 연결되어 있으며, 이 경로를 이용하면 건물 사이를 왕래할 때 번거롭게 1층까지 내려갔다가 다시 올라갈 필요가 없다.
바깥에 비해 상대적으로 어두운 건물 복도를 걸으면서 지하철 터널을 떠올리는 것은 어렵지 않다. 그러다가 잠시 밖으로 나가면, 지하철이 강을 건너거나 서울 지하철 8호선의 복정-산성 구간 같은 곳을 지나느라 잠시 지상으로 나온 것 같은 느낌이 든다.

5.
교회에서 성가대 연습을 한다. 노래를 부르는데 반주자가 악보를 넘기느라 잠시 피아노 반주가 중단되었다. 그래도 노래는 박자나 음정의 어긋남이 없이 계속 잘 이어진다.
이것은 절연 구간을 지나느라 전동차에 전원 공급이 잠시 중단되더라도 차가 관성으로 계속 달리는 것과 같은 맥락으로 풀이할 수 있다. 아울러, 바닷물과 민물을 넘나드는 연어는 교류-직류 겸용 전동차의 예표이다.
일상생활 속에서 철도 패턴을 찾기는 어려운 일이 아니다.

6.
대학 학부까지만 학업을 마치고 취업을 한 건, 지금 생각해 보니 학업이라는 지하철이 서울 시계까지만 건설된 뒤 노선이 끊어졌던 듯한 느낌이다. 학부를 졸업한 지 5년이 지나서야 대학원에 들어가니, 그 선로를 이어서 장거리 광역전철을 건설하는 것 같다.

7.
<날개셋> 한글 입력기 5.65를 공개한 후, 소스를 대대적으로 뒤집어엎었다.
null-terminate 스트링의 write 버퍼를 받는 모든 함수에는 버퍼의 크기에 대한 정보를 추가하고, sprintf 같은 함수 호출도 버퍼 오버런을 일으키지 않게 다 손질했다.
파일을 읽고 쓰는 과정에서 에러 처리를 더욱 강화하고, 범용적인 dll 모듈은 thread-safe하도록 고쳤다.
좀 비효율적이고 불합리하게 만들어져 있던 라이브러리 API를 뜯어고쳤다.

그래서 다음 버전으로 잠정 계획 중인 <날개셋> 한글 입력기 5.8은 5.5 시절부터 비교적 잘 유지되어 왔던 API 하위 호환성이 모두 깨질 예정이다.
타자연습도 덩달아 버전업된다. 입력기에 적용된 프로그래밍 테크닉이 그대로 적용되고, 그리고 연습글을 좀 정리할 생각이다.

6만 줄에 달하는 <날개셋> 한글 입력기 소스 코드를 들여다보노라면 정말 나만의 세계, 나만의 건축물, 나만의 철도 노선에 들어온 느낌이다. 의존도라고는 Win32 API와 몇몇 Ansi C 함수밖에 없으며, 나머지 코드들은 100% 자체 제작이다. 다른 프레임워크나 오픈소스 작품 같은 거 쓴 것이 전혀 없다.

누구에게 돈이나 시간 면에서 단 한 치도 얽매인 게 없이, 전적으로 개인 취미 생활로 개발하는 것이다 보니,
단순히 기능만 되게 하는 게 아니라 소스 코드의 질에도 굉장히 신경을 쓴다.
비록 한 줄에 100칼럼을 꽉꽉 채우느라 겉보기로는 코드가 좀 지저분해 보여도, 구조는 의외로 깔끔한 편. ㅋㅋㅋㅋ

코드에 무슨 공통된 패턴이 반복되는 게 발견되면 함수로 따로 떼낸다거나, 모듈 간의 공통된 기능을 한 기반 클래스로 빼낸다거나.. 이런 식으로 "리팩터링"을 수시로 진행한다는 뜻이다.
이런 거 공사 하나 잘 해서 추상적인 클래스가 하나 탄생하고 상속 계층이 한 단계 올라간다거나 하면,
어려운 버그를 잡은 것만큼이나 기쁘다.

Posted by 사무엘

2010/10/17 18:08 2010/10/17 18:08
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/393

« Previous : 1 : ... 7 : 8 : 9 : 10 : 11 : 12 : 13 : 14 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/04   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

Site Stats

Total hits:
2675910
Today:
478
Yesterday:
2124