Yellowbirds

안녕하세요? 천재태지 서주영입니다.

ecore_timer 는 EFL 에서 사용하는 타이머입니다.
타이머에 원하는 주기와 콜백을 설정해놓으면 매 주기마다 콜백이 불리게 됩니다. 타이머는 어플리케이션 제작 시에 흔히 사용하기 때문에 EFL 에서도 타이머를 제공합니다.

timer 를 생성하는 함수는 아래와 같습니다.

EAPI Ecore_Timer *                 

ecore_timer_add(double        in,  

                              Ecore_Task_Cb func,

                              const void   *data)

첫번째 인자로 double 형으로 주기를 입력 받습니다. 두번째 인자로 주기마다 불릴 콜백 함수를 입력받고, 마지막에는 콜백함수에 넘겨줄 사용자 데이터를 입력받습니다.

[유의사항 1 - 타이머의 주기]
기본적으로는 정해놓은 주기마다 콜백이 불리지만, 한가지 유의해야할 점은, 정확하게 해당 주기 마다 타이머가 불리는 것이 아니라 해당 주기의 시간이 초과했을 때 콜백이 불린다는 겁니다. 즉, 주기를 1.0 초로 설정해놓으면 최초 시간의 1.01 혹은 1.02 초 뒤에 콜백이 불릴 수 있다는 것입니다. 이 점을 잘 고려해서 사용해야 합니다.

[유의사항 2 - 타이머 종료]
타이머를 종료하는 방법은 두 가지가 있습니다.
첫번째는 ecore_timer_del() 을 이용하는 방법이고 두번째는 타이머에 걸어둔 콜백에서 ECORE_CALLBACK_CANCEL 을 리턴하는 방법입니다.  
ecore_timer_del() 은 원하는 시점에 타이머를 종료하는 방법인데, 이 함수의 원형은 아래와 같습니다.

EAPI void *                         

ecore_timer_del(Ecore_Timer *timer) 

ecore_timer_add() 를 사용할 때 리턴받은 포인터를 ecore_timer_del() 에 인자로 넣어주면 됩니다.

그리고 타이머 콜백에서 ECORE_CALLBACK_CANCEL 을 리턴하는 경우는 타이머를 더이상 사용하지 않고 폐기시키겠다는 의미입니다. 만약 타이머를 계속 돌리고 싶다면, ECORE_CALLBACK_RENEW 를 리턴하시면 됩니다.

이 두가지 용법을 알고 상황에 맞게 적절하게 사용하셔야 합니다. 

유의사항 3 -  타이머 변수 처리)
이번 유의사항이 가장 중요한 겁니다. 타이머에 대한 포인터를 변수에 저장해놓을 때, 타이머를 삭제한 경우 타이머 포인터를 NULL 로 초기화해줘야 합니다.
예를 들어, 아래와 같은 코드가 있다고 했을 때

Ecore_Timer *my_timer = ecore_timer_add(1.0, _my_timer_cb, NULL);
...
...
if (my_timer)
   ecore_timer_del(my_timer);

ecore_timer_del() 을 실행하는 순간 타이머가 종료됩니다.
그런데 만약 ecore_timer_del() 을 한 뒤에 다시 my_timer 를 체크하고 ecore_timer_del() 을 실행하면 어떻게 될까요?

 Ecore_Timer *my_timer = ecore_timer_add(1.0, _my_timer_cb, NULL);
...
...
if (my_timer)
   ecore_timer_del(my_timer); ---> (1)
...
...
if (my_timer) ---> (2)
   ecore_timer_del(my_timer);

얼핏 생각하면 이미 타이머가 종료되었기 때문에 ecore_timer_del() 은 아무것도 하지 않을 것 같지만, 실제로는 아래와 같은 에러 메시지를 출력합니다.

ERR<6750>:ecore ecore.c:441 _ecore_magic_fail() 

*** ECORE ERROR: Ecore Magic Check Failed!!!

*** IN FUNCTION: ecore_timer_del()

ERR<6750>:ecore ecore.c:451 _ecore_magic_fail()   Input handle is wrong type

    Expected: f7d713f4 - Ecore_Timer (Timer)

    Supplied: 008c2dc1 - <UNKNOWN>

ERR<6750>:ecore ecore.c:454 _ecore_magic_fail() *** NAUGHTY PROGRAMMER!!!

*** SPANK SPANK SPANK!!!

*** Now go fix your code. Tut tut tut!

Ecore_Timer *my_timer = ecore_timer_add();

...
...
if (my_timer)
  {
     ecore_timer_del(my_timer);
     my_timer = NULL;
  }

그리고 ecore_timer_del() 이 아니라 콜백의 리턴값을 이용하여 타이머를 종료할 때도 타이머를 가리키는 변수를 항상 NULL 로 초기화해야 합니다.

Eina_Bool
_my_timer_cb(void *data)
{
   my_timer = NULL;
   return ECORE_CALLBACK_CANCEL;
}

이는 비단 EFL 의 문제가 아니라 C 언어를 사용하는 프로그램에서 발생하는 근본적인 문제입니다. 그러므로 앞으로는 이런 종류의 상황에 접했을 때 변수를 적절하게 초기화하는 센스를 발휘하기 바랍니다.

감사합니다. 

$ git config --global color.branch auto

$ git config --global color.diff auto

$ git config --global color.interactive auto

$ git config --global color.status auto

git config --global color.branch auto

git config --global color.diff auto

git config --global color.interactive auto

git config --global color.status auto

Eric Raymond가 쓴 글로 open source에 대한 자신의 생각을 쓴 좋은 글이다. 대학교 3학년 때쯤 읽었으니 거의 10년만에 다시 한 번 읽게 됐다. 다시 읽으면서 역시 좋은 글이라는 것을 또 한 번 느꼈고 일부 맘에 와닿는 내용을 정리했다. 번역된 글이 있으니 읽어보는 것도 좋겠다.

쌍따옴표로 묶인 것은 원문의 표현을 거의 그대로 가져온 것이고, 나머지는 내 생각대로 적은 것이다.

- "좋은 소프트웨어는 개인의 가려운 곳을 긁는 것으로 시작한다."
필요한 것을 만들게 되면 남도 그것을 필요로 하는 경우가 있다. 그게 상당히 일반적인 성질의 것이라면 프로그램은 인기를 얻을 수 있다. 이건 상업용 프로그램(혹은 성당 스타일의 프로그램)과 크게 차별성을 가지지는 않는다고 생각한다. 상업용 프로그램도 모두 다른 사람이 필요로 하고 있다고 파악하고 제작하는 것이니까.

- "좋은 프로그래머는 어떤 프로그램을 만들어야 할 지 알고, 훌륭한 프로그래머는 어떤 프로그램을 다시 만들어야 할 지 안다."
기존 프로그램을 재사용 할 줄 알아야 한다는 이야기다. 모든 것을 혼자 다 다시 만드는 것은 바보같은 짓이 아닌가.

- "개발자들에 대한 빠른 피드백, 그 방법은 잦은 발표(release)"
개발자들이 성취감을 느낄 수 있도록 해준다. 자주 발표될 때마다 내가 기여한 코드가 mainstream에 반영되면 기쁨을 느낄 수 있을 것이다. 어딘가 기여했다는 느낌. 그 프로젝트에 소속되었다는 느낌. 또한 빨리 수정하고 빨리 발표하면 그만큼 디버깅에 중복이 발생하지 않는다. 남이 고친 것을 내가 고칠 필요는 없으니까.

- "누군가에게는 간단할 것이다."
내게는 어려운 문제라도 다른 어떤 사람에게는 간단한 문제일 수 있다. 문제 해결의 속도가 상당히 빨라질 수 있다는 거다. 훈수가 좋은 비유가 될 듯.

- 리누스 토발즈 왈, "문제를 발견하는 사람과 이해하는 사람이 동일할 필요가 없다."
문제(버그)를 발견하는 것이 더 중요하다고 토발즈는 말했다. 하지만 사실 둘 다 중요하다고 본다.
여튼 여기서 말하고자 하는 것은 발견을 잘 하는 사람이 해결을 잘 할 필요는 없다는 것. <좋은 테스터 = 좋은 개발자>일 필요가 없다는 것이다. 오픈 소스 정책을 취하게 되면 수많은 테스터와 수많은 개발자를 내편으로 만들 수 있다. 베타 테스터를 품는 것이 중요하다. 정말로 열정적으로 헌신해 주는 사람들이 있다. 적극적으로 베타 테스터와 소통하고, 리스트에 사람들을 포함시키고 릴리즈가 있을 때마다 발표하고 의견을 듣고 버그 리포트도 받고 소스에 대한 수정본을 보내주는 사람이 있으면 적극적으로 검토하고 취하자. 이렇게 하다보면 베타 테스터 리스트에서 점점 사람들이 빠져나가는 현상이 발생한다고 하는데, 그 이유는 '잘 동작하니 더 이상 듣고 싶지 않다'란다. 이 때쯤 되면 "베타"딱지를 뗄 수 있는 것이 아닐까.

- 사회학에서의 델파이 효과: "비슷하게 전문적인 (혹은 비슷하게 무지한) 관찰자들로 이루어진 대중의 평균적인 의견이 그 관찰자 중 무작위로 뽑은 한 명의 의견보다 더 신뢰할 만하다."
전체의 의견이 그리 바보같지는 않다는 것. 집단 지성이 그리 나쁜 결과로 이어지지는 않는다는 것. 리눅스와 위키피디아를 통해 증명되었다고 생각한다.

- "널리 사용되는 프로그램의 유지, 보수에 들어가는 비용은 40퍼센트 혹은 그 이상이다. 놀랍게도 사용자 수에 큰 영향을 받는다. 사용자가 많을 수록 유지 보수에 더 많은 비용이 들어간다는 것."
왜? 더 많은 사용자가 더 많은 버그를 찾아내기 때문이다. 더 많이 사용되는 윈도우에서 더 많은 취약점이 발견되고 더 많은 악성코드가 제작된다. 윈도우 자체의 보안 결함은 논외로 하자. 더 많은 보안 이슈가 발생하는 건 그만큼 많은 사용자가 있어서 그렇다는 것을 다들 인정할 거다.

- 많은 사용자가 있고 그들과 소통하면  좋은 아이디어를 얻게 되는 경우도 있다. 때로는 그것이 천금같은 것일 수도 있다.
일반 사용자와 오픈 소스에서의 참여자는 다르다. 참여하는 사람들은 그 프로젝트에 소속감을 가지고 있다. 좋은 아이디어가 떠오르면 제공할 의사가 더 많다는 의미도 된다.

- 생택쥐베리 왈: "(설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다. (Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away)"
그냥 멋진 말.

- open source project의 leader는 사회성이 좋아야 된다.
어쩔 수 없는 것이다. 어디서든 리더가 되려면 그럴 수밖에. 유시민님의 강연에서 이런 말을 들은 적이 있다. 리더는 두 가지 중 하나를 갖춰야 한다. 엄청 똑똑하거나, 인간적으로 존경스럽거나. 각각 너무 똑똑하니 배신하면 걸리겠지, 이렇게 좋은 분을 내가 배신할 수는 없어라고 생각해서 그렇단다. 재밌는 이야기다. 사실 대규모 open source project의 leader가 되려면 둘 다 갖춰야 할 것 같다. 아무나 못하는 것은 확실하다.

다음의 짧은 논문을 읽고 떠오른 생각들 정리해본다. Vassils Kostakos, et al. "NFC on mobile phones: issues, lessons, and future research", 2007

NFC의 편의성

두 폰이 서로 데이터를 주고 받을 일이 있을 때, 블루투스나 NFC를 이용할 수 있다. 논문에서는 두 가지를 이용해서 전화번호를 교환하는 프로그램을 각각 작성한 후에 사람들에게 얼마나 편리한지 질문했다. (실험 결과에 대한 구체적인 이야기가 없었지만!) 전반적으로 NFC가 편리하다는 평이었다고 한다. 그 첫 번째 이유는 사용자가 별로 할 일이 없다는 것. 블루투스는 기기 간의 페어링(pairing)을 해야 한다. 반면 NFC는 접촉만으로 바로 데이터 교환이 가능하다. 단, NFC는 읽고 쓰기 중 하나를 선택하여 단방향(one-way) 통신만 가능하기 때문에 사용자가 개입하여 내가 데이터를 받을 것인지 줄 것인지를 선택해야 하는 문제가 있는데, 여기서는 두 장치가 서로 번갈아가며 주고 받기를 서로 알아서 하도록 프로그래밍했기 때문에 사용자가 할 일이 거의 없었다. 사용자 입장에서는 폰을 서로 갖다대는 것만으로 데이터 교환이 되는 것이 신기하고 편리했을 것이다. 그리고 이것이 두 번째 이유로 연결되는데, 터치로 데이터를 교환하는 것은 블루투스를 이용한 원격(물론 멀지 않은 거리지만) 교환보다 더 원시적인 방법처럼 보이지만 오히려 '중간에 다른 디바이스가 끼어들어 내 정보가 세어나가진 않을까?' 하는 우려를 줄여준다. 내가 보고 있는 상대방과 정확히 정보를 교환하고 있다는 느낌을 사용자에게 주는 것이다. NFC가 근거리 통신 방식이기 때문에 보안 측면에서 유리하다는 것은 이미 많이 언급된 내용이다.

QR code와의 비교

NFC를 사용하면 태그를 폰에 접촉하는 것만으로 바로 데이터를 가져올 수 있다. 반면 QR code를 읽기 위해선 카메라를 이용하는 리더 앱을 가동해야 하는 번거로움이 있다. 얼마전에 코엑스에 갔을 때 재밌게 본 시연이 있었는데, TV에서 나오는 아이유의 음악에 폰이 가까이 두니 관련 링크를 열어 보여주는 것이었다. 물론 여기에 사용된 아이유의 음악은 사람이 듣지 못하는 주파수 영역에 데이터를 주입해서 보내는 것이었고 폰은 그것을 듣고 데이터를 뽑아내는 것이었다.  아이디어는 재밌으나 폰에서는 데이터를 해석할 수 있는 앱을 역시 가동하고 있어야 한다. 이 앱은 카메라 대신에 마이크를 켜두고 있어야 한다는 것이 차이점일 뿐이다. 결국 사용자 편의성 면에서는 QR code와 별다른 차이가 없다고 볼 수 있다.

NFC의 단점? 1. 화면과 멀어지는 사용자

태그를 읽기 위해 - 혹은 다른 NFC 장치에게 데이터를 전송하기 위해 - 서는 접촉을 해야 하므로, 내 폰을 내 눈과 먼 거리에 두어야 할 경우가 발생할 수 있다. 데이터 교환 상황이나 완료 여부, 에러 발생 여부 등을 알아보기가 다소 힘들 수 있다. 물론 예로 든 수준의 알림은 화면에 큰 글자를 출력하거나 깜빡임을 이용하거나 소리를 내거나 진동을 발생시킴으로써 해결할 수 있다. 그러나 화면을 터치함으로써 어떤 interaction을 이어나가야 하는 경우라면 작업을 진행하기에 까다로워질 수 있다.  선택 버튼을 눌러야 한다거나 패스워드를 입력해야 한다거나 따위가 예가 될 수 있다. 결론적으로 interaction이 많은 작업보다는 접촉만으로 바로 데이터가 교환되고 바로 통신이 종료되는 어플리케이션이 적합하다.

NFC의 단점? 2. 악성 데이터

이 문제는 사실 NFC 만의 문제는 아니다. NFC를 이용할 때도 역시 조심해야 한다 정도가 좋겠다. 태그로부터 읽히는 정보에는 스팸이나 악성 페이지로의 링크가 있을 수 있어 주의해야 한다. 조금 더 주의를 기울여야 하는 부분은 태그로부터 정보를 읽어오는 것뿐만 아니라 어떤 명령을 받아들일 수도 있다는 점이다. 어떤 사람의 명함에 폰을 대면 바로 그 사람에게 전화가 걸리거나 이메일을 보내거나 문자를 보낼 수 있도록 폰이 동작하는 것이 그 예가 되겠다. 접촉을 하는 즉시 폰이 어떤 행위를 하게 되는 것은 편리할 때도 많지만 악성 행위를 동작시키는 태그가 이용될 수도 있기 때문에 주의해야 한다

해결하고자 하는 문제는 텍스트 파일에서 한글 글자만 뽑아내는 것이다. 문서에 "한글은 영어로 Korean이라 합니다."라는 내용이 있다면 (한 글 은 영 어 로 이 라 합 니 다) 라고 뽑아내고 싶다는 것. 그리고 글자의 중복이 있으면 제거한다.  위 예제에는 중복이 없다. 코드는 아주 간단하다.

(ns korean-word-extractor.core
  (:gen-class))

(defn -main [& args]
  (let [file-name (first args)
        file-contents (slurp file-name)
        korean-chars (distinct (filter #(<= 0xAC00 (int %) 0xD7AF) (seq file-contents)))] ;; 0xAC00 ~ 0xD7AF: Hangul Range
    (println korean-chars)))

파일명은 argument로 받기로 하고, slurp을 이용해 모든 내용을 일단 얻어온다. 그 다음 한 줄의 코드가 사실 모든 일을 다 하게 되는데, 과정은 다음과 같다.

• 우선 clojure에서는 문자열에 seq 함수를 적용하면 바로 개별 문자를 list로 활용할 수 있다.
• 그 다음 한글을 필터링 해야 되는데 filter 함수를 사용할 수 있다. 0xAC00 ~ 0XD7AF는 Unicode의 한글 음절 범위이다. Unicode.org의 Hangul Syllables 문서를 보면 잘 나와있다.
• 한글 문자만 뽑아내는데 성공했으니 중복된 문자를 제거하면 된다. distinct 함수를 활용하자.
  

문제가 해결되었다.

한글과 English가 섞여 있을 경우
한글만 extract할 수 있을까?

라는 내용을 담고 있는 test.txt 파일을 만들고 실행해보면,

>lein run test.txt
(한 글 과 가 섞 여 있 을 경 우 만 할 수 까)

와 같이 원하던 결과를 얻게 된다.

다음 논문을 읽고 남기는 생각.

Csapodi, M.; Nagy, A.; , "New Applications for NFC Devices," Mobile and Wireless Communications Summit, 2007. 16th IST , vol., no., pp.1-5, 1-5 July 2007
doi: 10.1109/ISTMWC.2007.4299077
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4299077&isnumber=4299029

NFC의 장점으로 매번 이야기하는 것은

• 네트워크를 따로 구성하지 않아도 된다는 것
• 비교적 빠르다는 것
• 아주 근접한 상태에서만 통신이 되기 때문에 안전하다는 것
  

정도이다. 간단히 줄이면 "Simple and Secure". 이러한 장점으로 기기 간의 상호 인증을 할 때 NFC는 좋은 수단이 된다. 직접 터치하는 방식이기 때문에 man in the middle attack, eavesdropping에 다른 방법론보다 비교적 강하다. 기기 간 상호 인증 (키 교환)을 자연스럽게 사람이 개입하여 인증해주게 되는 것이다.

NFC는 2002년 가을 Sony와 Phillips, 두 회사가 협정한 기술이라 한다. 둘은 ECMA Internation에 표준 초안을 제출하는 것을 시작으로 표준화를 진행했고 두 개의 프로토콜 NFCIP-1, NFCIP-2가 각각 ISO/IEC 18092, ISO/IEC 21481로 제정되었다. NFC 포럼이 2004년 3월 설립되어 HP, NXP (Phillips), Sony, Texas Instruments, Nokia, NEC, Samsung, Motorola, MasterCard, VISA, Panasonic, Microsoft, Gemalto, Vodafone, Siemens 등이 참여하고 있다고. 모바일 통신 업체 그리고 통신 기기를 만드는 업체가 포함되어 있다. 개인적으로 재밌는 건 MasterCard, VISA가 참여하고 있는 것인데, 모바일 결제를 할 때 비교적 안전하고 신속하게 통신 과정을 진행 할 수 있다는 점에서 NFC가 모바일 결제 분야에서 핵심 기술로 인정받고 있다는 것을 알 수 있다.

NFCIP-1 프로토콜은 Philips의 Mifare 기술과 Sony의 FeliCa contactless IC card 기술과 호환된다고 한다. 각자 기술을 개발하다가 둘을 아우르는 프로토콜을 만들게 된 것 같다. 두 기술은 이미 교통 카드나 출입 보안 카드 등에 사용되고 있었다고 한다.

NFC의 접촉 범위는 20cm 정도.

많은 양의 통신이 필요하거나 빠른 통신이 필요한 경우 블루투스나 와이파이 등 기존 기술을 사용하는 것이 좋은데, 이런 설정을 두 기기가 빠르게 공유하기 위해서 NFC가 역시 좋은 수단이 된다.

NFC가 passive mode를 제공한다는 것도 장점이다. 모바일 기기는 배터리에 민감하기 때문에 one party의 파워로 양쪽이 통신할 수 있는 것은 큰 장점이다. NFC 통신을 할 때 한 쪽이 모바일, 한 쪽이 전원을 공급 받는 고정된 기기인 경우 이 성질은 큰 장점으로 작용할 것이다.

NFC가 탑재된 두 기기 간의 데이터 교환이 NFC를 이용한 주된 어플리케이션이지만 조금 구체적으로 응용한 예가 논문에 몇 가지 언급된다. 그 중 하나 재밌는 것은, PC와 연동하여 내 패스워드 정보 - 를 비롯한 웹 폼을 채울 수 있는 정보 - 를 내가 폰을 PC와 접촉시켜 둔 동안에만 해당 PC에서 적용되게 하는 것이다. 도서관 등의 공공 컴퓨터에 갔을 때 웹 서핑을 하게 되면 모든 웹 사이트에서 로그인을 다시 해야 한다. 귀찮지만 당연히 해야 하는 작업이다. 내 폰을 PC 옆에 마련된 NFC reader 위에 올려둠으로써 모든 로그인 절차가 자동으로 된다면 편리하지 않겠는가? 물론 폰을 분실했을 경우, 도난 당했을 경우가 아주 위험해진다.

위의 예처럼 터치를 통한 사용자 또는 기기 인증의 개념이 도입되면 폰이 일종의 보안 토큰이 되는 것이다. 클라우드 컴퓨팅이 발전하고 점차 컴퓨팅 기기는 네트워크가 가능한 더미 터미널이 되어가는 추세(크롬북이 얼마나 성공할 지는 모르지만) 라고 봤을 때, NFC 덕분에 거의 모든 사람이 소지하고 있는 스마트폰을 보안 토큰으로 활용할 수 있게 된 점은 확실히 사용자 편의성을 높이는데 한 몫을 할 수 있을 것이라 생각한다.

Common Lisp를 사용하기에 최적의 환경은 역시 리눅스. 최근 우분투가 참 많이 좋아졌고 많은 프로그램들이 리눅스를 지원하니 사용에 심각한 불편함은 없으나 역시 대한민국에서는 윈도우가 편하다.

윈도우 환경에서 리스프를 즐기기 위해서 clojure를 써보는 방법도 있지만 common lisp는 아니기 때문에 좀 애매하다. 돈을 주고 쓸 수 있는 것들은 윈도우용을 제공하지만 무료로 사용할 수 있는 것들 중 쓸만한 것인 clisp나 sbcl은 아직 공식적인 윈도우 버전을 제공하지 않는다. 뭐, 아직 공부 단계이니 돈 주고 사기는 아깝고, 원래 쓰던 sbcl을 사용하기로 했다.

sbcl은 아직까지는 윈도우 환경에서 "Available and Supported" 단계가 아니다. 포팅 중으로 표시되어 있다. 그럼에도 불구하고 설치는 간편하게 할 수 있도록 설치 파일을 제공한다. 인터넷 상의 여러 글에서, 아직은 불안정하다는 이야기를 많이 봤지만 얼마나 불안정한가는 더 사용해봐야 알 수 있겠다. 개인적으로는 간단한 코드를 돌려보는 수준이기 때문에 특별한 버그를 만나진 못했다.

우선 emacs windows 버전은 여기서 다운로드 받을 수 있다. 가장 최근의 bin 버전을 받는 것이 좋다. emacs는 설치파일을 제공하지는 않으며, zip으로 압축되어 있다. 받은 후에는 bin 폴더에 있는 바이너리를 직접 실행하여 사용하면 된다.

SLIME은 이 곳에서 받을 수 있으며 cvs snapshot을 받을 수 있다. SLIME을 다운 받은 후에는 최대한 path 설정이 간편한 곳에 두는 것이 좋다.

SBCL은 여기에서 받을 수 있다. windows 용을 클릭하여 다운로드 후 실행하면 설치된다. 설치할 때 주의할 점은 역시 설치될 경로 설정이다. 최대한 단순하게 하자.

경로를 단순하게 해야 하는 이유는 후에 emacs에서 경로를 설정할 때 공백이 들어간 경로나 긴 이름의 경로를 잘 해석하지 못하는 경우가 발생하기 때문이다.

리눅스에서는 홈 디렉토리에 .emacs에 설정 파일을 두면 되지만 윈도우의 경우에는 어디에 .emacs가 위치할까? 이것을 알 수 있는 간단한 방법은, 이멕스를 실행한 후 Options에서 아무 옵션이나 변경한 후 Save Options를 하면 어느 파일에 저장했는지가 아래 미니 버퍼에 나온다. 보통은 자신의 홈 디렉토리의 AppData/Roaming/.emacs 에 위치한다. 예를 들면 C:/Users/kju/AppData/Roaming/.emacs

.emacs의 위치를 찾았으니 이 파일을 수정하면 된다. 여기에 추가할 코드는 다음과 같다.

(setq inferior-lisp-program ""C:/Users/kju/SBCL/sbcl.exe")
(add-to-list 'load-path "C:/Users/kju/slime-2011-10-13")
(require 'slime)
(slime-setup '(slime-repl))

SBCL과 SLIME의 위치를 지정하는 것이다. 경로가 간단하면 좋은 이유가 여기에 있다. 그리고 경로에 공백이 있을 경우 실행되지 않는 경우가 많다. 경로를 설정할 때 한 가지 주의할 점은 폴더 구분자를 \이 아니라 /를 사용해야 한다는 점이다. 역슬래시를 사용할 경우 escape 문자로 인식하여 오류가 발생한다.

설정 후 M-x slime 해보고 REPL이 정상적으로 실행되면 끝.

ps. 리스프 코딩을 할 때 괄호가 조금 연하게 출력되면 소스코드를 보기에 편하다.

(defface paren-face
  '((((class color) (background dark))
     (:foreground "grey30"))
    (((class color) (background light))
     (:foreground "grey60")))
  "Face used to dim parentheses.")
(add-hook 'emacs-lisp-mode-hook
       (lambda ()
         (font-lock-add-keywords nil
                     '(("(\\|)" . 'paren-face)))))
(add-hook 'slime-mode-hook
       (lambda ()
         (font-lock-add-keywords nil
                     '(("(\\|)" . 'paren-face)))))

를 .emacs에 추가해서 괄호를 연한 회색으로 만들 수 있다. grey뒤의 숫자를 조정하여 입맛에 맞게 설정하자.

두 수의 최대공약수(GCD)를 찾는 유클리드 알고리즘은 널리 알려져있다. 이 알고리즘을 리스프로 옮겨보자. 우선 코드를 보자.

(defun euclid (a b)
  (labels
      ((euclid-gcd (a b)
(if (zerop b)
    a
    (euclid-gcd b (mod a b)))))
  (let* ((gcd (euclid-gcd a b))
  (lcm (/ (* a b) gcd)))
      (values gcd lcm))))

이 코드는 최대공약수 뿐만 아니라 최소공배수까지 얻어내는 함수다. 실행 결과는 다음과 같다.

CL-USER> (euclid 462 1071)
21
23562

두 수를 받아야 하기 때문에 파라미터를 a, b로 둔다. labels는 함수 내에서 이용할 로컬 함수를 다시 정의할 수 있도록 해준다. euclid 함수 내에서 euclid-gcd를 다시 정의한 이유는 GCD를 우선적으로 얻어낸 후 이를 이용해 LCM값까지 출력해주기 위함이다.

euclid-gcd는 두 파라미터 a, b를 그대로 이용해서 recursive 호출을 이용해서 GCD를 얻어낸다. labels로 함수를 정의한 후에는 let* 함수가 나오는데, let*는 로컬 변수를 선언하는 역할을 한다. 위에서 정의한 euclid-gcd를 이용해서 얻는 GCD값을 gcd라는 변수에 넣고, 이 gcd를 이용해서 최소공약수를 얻은 후에 lcm 변수에 할당한다. 얻어낸 gcd값을 바로 아래 라인에서 lcm을 얻는데 사용하기 때문에 let* 함수를 사용한다. 그렇지 않은 경우엔 let을 사용하면 된다.

gcd와 lcm 변수에 각각 최대공약수와 최소공약수를 할당한 후에 이 값을 돌려줘야 되는데 리스프에서는 여러 개의 값을 돌려줄 수 있다. 그 방법이 가장 마지막 줄에 있는 values 함수를 이용하는 것이다.

실제 실행했을 때 21, 23562 두 수가 연속으로 리턴되는 것을 볼 수 있는데, values가 두 값을 넘겨주기 때문이다.

리스프 관련 책을 읽다가 문자열에 대한 이야기가 나왔다. 문득, 리스프가 유니코드를 처리할 수 있을까 하는 의문이 들었다. 그리고 몇 가지 실험을 해보니 전혀 한글을 해석하지 못한다는 것을 알게 되었다.

하지만 분명 설정의 문제이리라.

"SBCL unicode"로 구글링을 해보니 SBCL은 이미 유니코드에 대한 지원을 하고 있다는 것을 알 수 있었다. 컴파일 때 옵션을 줄 수 있고 하는데 나는 우분투에서 패키지로 깔았으니 옵션을 켜고 컴파일 한 것인지 아닌지 알 수가 없다. 그냥 실험을 해보면 알게 되겠지.

모든 정보는 이 곳에서 얻었다. 결론은 간단하다. 우선 emacs가 기본적으로 유니코드(UTF-8)를 사용하게 하고, SLIME도 유니코드를 사용하게 설정하면 된다는 것.

Emacs의 메뉴바에서

Options -> MULE(Multilingual Environment) -> Set Language Environment -> UTF-8을 선택하고,
Options -> Save Options를 선택해서 저장

이렇게 하면 .emacs의 custom-set-variables에 '(current-language-environment "UTF-8")라는 것이 자동 추가된다. 이멕스의 언어 환경을 UTF-8로 바꿔주는 것이다.

다음으로 SLIME을 설정해야 하는데, .emacs에 다음 한 줄만 추가해주면 된다.

(setq slime-net-coding-system 'utf-8-unix)

이멕스를 다시 실행시켜 환경 변수가 적용되게 한 후, SLIME을 띄우자.

CL-USER> #\한
#\UD55C

CL-USER> "한글"
"한글"

오. 한글을 인식한다.

CL-USER> (char-code #\한)
54620

'한'이라는 글자에 대한 코드를 얻어낼 수 있다.

CL-USER> (code-char 54620)
#\UD55C

역으로 글자로 변환. 이렇게 character code를 보면 재미가 없으니 확실히 확인해보자.

CL-USER> (coerce '(#\UD55C) 'string)
"한"

모든 것이 잘 동작한다. 그렇다면 함수 이름으로 활용해보자.

CL-USER> (defun 안녕 ()
       (format t "안녕하세요.~%"))
안녕
CL-USER> (안녕)
안녕하세요.
NIL

완벽하다.

ps. CLISP를 가지고 실험해보니 CLISP에서도 모두 잘 동작한다.