레이블이 editor인 게시물을 표시합니다. 모든 게시물 표시
레이블이 editor인 게시물을 표시합니다. 모든 게시물 표시

2011년 1월 10일 월요일

[Emacs] Encoding 자동 판별 모듈 - Unicad

들어가기 전에 - 인코딩이 왜 문제인가?

한글 Windows 환경(꼭 한글 Windows가 아니더라도 OS 기본 인코딩이 영문 또는 서유럽어가 아닌 경우)에서 소스 코드를 다루는 사람이라면 한번 정도는 겪어보았을 법한 문제가 있습니다. 소스를 text editor로 열었더니 ?로 보이는 부분이 있고, 이 파일을 조금 수정한 다음 저장해서 compile 하면 compile이 실패하거나 성공하더라도 실행 중에 엉뚱한 글자(?)가 보여지는 일 말이죠. 이것은 다중 바이트 인코딩 문자셋(여기서는 euc-kr 또는 cp949)에서 ASCII 코드 확장 영역의 문자 코드를 일부 중복 사용하기 때문에 발생하는 문제입니다.

Windows의 기본 편집기인 메모장(notepad.exe), Scintella 기반의 Notepad++SciTE 등은 물론이고 대다수의 text editor들이 latin-1(iso-8859-1, ASCII 코드 기반의 서유럽어 표현을 위한 문자셋을 정의) 인코딩을 시스템 기본 인코딩과 구별하지 않거나, 또는 구별해준다고 해도 적절히 판별하지 못하기 때문에 한글 Windows 환경에서 latin-1 인코딩으로 작성된 파일을 읽어오면 일부 문자가 ?로 보이는 문제를 겪게 됩니다. (대표적으로 ©, 16진 코드값은 A9)

Notepad++과 몇몇 text editor의 경우는 메뉴에서 파일의 인코딩을 강제 지정해줄 수 있지만, 인코딩이 제대로 판별되지 않았음을 알려주지 않기 때문에 사용자가 주의 깊게 관찰하지 않으면 놓치기 십상이지요.

굳이 위와 같은 특수한 사례를 들지 않는다고 하더라도 이미 Unicode(특히, UTF-8)는 개발 프로젝트의 국제화 및 현지화(Internationalization and localization)와 관련하여 다국어를 지원하는 데 꼭 필요한 인코딩으로 확실하게 자리잡고 있고, 기존에 사용되고 있던 다양한 인코딩의 데이터를 적절히 판별하여 Unicode로 변환하는 것은 매우 중요한 일이 되었습니다. 그리고, 이러한 작업은 전 세계에서 Unicode 하나만 사용하는 날이 올 때까지는 결코 피해갈 수 없는 일이기도 합니다.

그렇다면 Emacs에서는?

Emacs에서는 기본적으로 BOM(byte-order mark)을 가지고 있는 Unicode(UTF-16, UTF-8) 인코딩 정도만 적절히 판단해줍니다. 그래서, EmEditor를 볼 때마다 항상 부러웠던 것이 대부분의 character encoding(문자 인코딩)을 외부 라이브러리나 도구의 도움 없이 에디터 자체적으로 깔끔하게 지원한다는 점이었습니다. 특히 BOM이 없는 Unicode를 포함한 다양한 인코딩에 대한 자동 판별 능력은 타의 추종을 불허할 만큼 탁월하다고 할 수 있지요. 그래서 간혹 파일의 인코딩이 애매한 경우(위에서 언급했던 것처럼 latin-1 인코딩이 사용됐다고 짐작되는 경우 또는 BOM없이 저장된 UTF-16 인코딩 파일의 경우 등)에는 EmEditor Freeware Edition을 사용해서 확인해보곤 했습니다.

그런데, EmEditor 없이도 필요한 만큼 유용하게 사용할 수 있는 문자 인코딩 자동 판별 모듈을 발견하게 되면서 더 이상 EmEditor를 부러워하지 않아도 되게 되었습니다. '필요한 만큼 유용하게'라는 단서를 단 이유는, 발견한 그 자동 판별 모듈이 세상 모든 인코딩을 완벽하게 판별해주지는 못하지만 한글과 영문을 주로 사용하는 사람이 만날 수 있는 대부분의 인코딩은 무리 없이 잘 판별해주기 때문입니다.

그 문자 인코딩 자동 판별 모듈의 이름은 Unicad입니다. 자세한 소개를 하기 전에 우선 Emacs가 파일의 인코딩을 판별하는 방법에 대해 간단하게 살펴보고 넘어가겠습니다.

Emacs의 파일 인코딩 판별 방법

Emacs에는 파일의 인코딩을 판별하는 데 사용되는 find-auto-coding 함수가 있어서 파일을 읽어올 때 이 함수를 통해 파일의 인코딩을 판별하게 됩니다. 실제로는 그 과정이 좀 더 복잡하겠지만, 핵심이 되는 부분만 간추려보면 대략 다음과 같습니다.

auto-coding-alist
      |
      V
auto-coding-regexp-alist
      |
      V
'coding:' 태그 (파일 내용 중)
      |
      V
auto-coding-functions

auto-coding-alist

파일명 규칙인코딩 쌍으로 구성된 cons의 list를 저장하는 변수입니다. 파일의 인코딩을 확인하기 위해 가장 먼저 적용하는 방법으로, 파일명이 규칙과 일치하는 항목이 있을 경우 해당하는 인코딩을 선택하고 일치하는 항목이 없으면 다음 판별 과정으로 넘어갑니다.

제가 사용 중인 Emacs에서 변수값은 다음과 같았습니다. 주로 파일의 확장자와 관련된 내용이 대부분입니다.

(("\\.\\(arc\\|zip\\|lzh\\|lha\\|zoo\\|[jew]ar\\|xpi\\|rar\\|7z\\|ARC\\|ZIP\\|LZH\\|LHA\\|ZOO\\|[JEW]AR\\|XPI\\|RAR\\|7Z\\)\\'" . no-conversion-multibyte)
 ("\\.\\(exe\\|EXE\\)\\'" . no-conversion)
 ("\\.\\(sx[dmicw]\\|odt\\|tar\\|tgz\\)\\'" . no-conversion)
 ("\\.\\(gz\\|Z\\|bz\\|bz2\\|xz\\|gpg\\)\\'" . no-conversion)
 ("\\.\\(jpe?g\\|png\\|gif\\|tiff?\\|p[bpgn]m\\)\\'" . no-conversion)
 ("\\.pdf\\'" . no-conversion)
 ("/#[^/]+#\\'" . emacs-mule))

auto-coding-regexp-alist

파일 시작 바이트 패턴인코딩 쌍으로 구성된 cons의 list를 저장하는 변수입니다. 파일 첫 n 개의 바이트와 일치하는 패턴이 있으면 해당하는 인코딩을 선택하고 일치하는 것이 없으면 다음 판별 과정으로 넘어갑니다.

제가 사용 중인 Emacs에서 변수값은 다음과 같았습니다. Unicode의 BOM과 몇몇 특정 바이너리 형식 파일에 대한 내용을 포함하고 있습니다.

(("\\`BABYL OPTIONS:[   ]*-\\*-[        ]*rmail[        ]*-\\*-" . no-conversion)
 ("\\`\376\377" . utf-16be-with-signature)
 ("\\`\377\376" . utf-16le-with-signature)
 ("\\`\357\273\277" . utf-8-with-signature)
 ("\\`;ELC^T^@^@^@" . emacs-mule))

'coding: ' 태그

파일의 첫 두 줄 안에서 특정 형식의 태그를 찾아 인코딩을 판별하는 방법으로, 태그의 형식은 아래와 같습니다.

-*- ... coding: CODING-SYSTEM; ... -*-

예를 들어, C 소스 파일에 인코딩이 UTF-8임을 명시하고자 한다면 다음과 같이 추가해주면 됩니다.

/* -*- coding: utf-8 -*- */

앞선 다른 방법들과 마찬가지로, 인코딩 지정 태그를 발견하지 못하여 인코딩 판별에 실패했을 경우 다음 판별 과정으로 넘어갑니다.

auto-coding-functions

인코딩 판별 함수의 list를 저장하는 변수입니다. 파일 내용의 전부 또는 일부(Emacs 도움말에 따르면 파일의 첫 1 KB와 끝 3 KB 정도를 포함해야 한다고 되어 있습니다.)에 대해 각 판별 함수를 순서대로 호출하면서 알맞은 인코딩이 발견될 경우 그 인코딩을 선택합니다. 조금 있다가 설명할 Unicad는 이 변수에 고유 판별 함수를 추가하게 됩니다. 그러므로, 위 세 단계에서 적절한 인코딩을 판별해내지 못했을 경우에만 효과가 있는 것이죠.

제가 사용 중인 Emacs에서 변수값은 다음과 같았습니다.

(sgml-xml-auto-coding-function sgml-html-meta-auto-coding-function)

Unicad

이제 본론으로 들어가서, UnicadUniversal Characterset Auto Detector의 줄임말이고, Mozilla Universal Charset Detector를 Emacs 모듈로 이식(porting)한 것이라고 합니다. 이 모듈은 Google Code에서 호스팅되고 있고, EmacsWiki에 별도로 설명하는 페이지를 가지고 있습니다.

Project Link: http://code.google.com/p/unicad/

EmacsWiki Link: http://www.emacswiki.org/cgi-bin/emacs/Unicad

사용 방법은 무척 간단합니다. unicad.el 파일을 다운로드 한 다음 load-path에 경로를 추가하거나 site-lisp(또는 ~/.emacs.d) 폴더에 복사해넣은 뒤 .emacs 파일에 간단하게 한 줄 추가해주면 됩니다.

(require 'unicad)

그리고, 속도 향상을 위해서 byte-compile 해주는 것을 권장합니다. (M-x byte-compile-file RET <path_of_unicad>\unicad.el)

이렇게 하면 모듈이 로드될 때 auto-coding-functions 변수에 unicad-universal-charset-detect 함수가 자동으로 추가되기 때문에 이후 파일을 읽어올 때마다 그 파일의 인코딩을 적절하게 판별해줍니다. Unicad 모듈을 로드한 다음 auto-coding-functions 변수값을 살펴보면 아래와 같이 함수가 추가되어 있는 것을 확인할 수 있습니다.

(unicad-universal-charset-detect sgml-xml-auto-coding-function sgml-html-meta-auto-coding-function)

제가 테스트 해보니 적어도 Unicode(UCS2 with BOM, UTF-8 with/without BOM)와 euc-kr(cp949), latin-1(iso-8859-1) 등은 문제 없이 잘 판별해주었습니다. 이 정도면 필요한 만큼 충분하지요.

단점이라면, 파일을 읽어올 때 인코딩을 판별하기 위한 함수를 한번 더 거치는 것이기 때문에 그 만큼 파일을 여는 속도가 느려진다는 것인데, 거슬릴 정도로 느껴지는 수준은 아니라서 문자 인코딩 자동 판별이라는 이점을 고려할 때 충분히 감수할 수 있다고 봅니다.

Tip - Vim에서 파일 인코딩 자동 판별하기

Vim에서도 필요한 만큼 유용하게 사용할 수 있는 문자 인코딩 자동 판별 방법이 있습니다. 특별히 추가 모듈이나 외부 도구를 사용할 필요 없이 .vimrc(또는 Windows 환경에서 _vimrc) 파일에 간단하게 아래 설정을 추가해주면 됩니다.

" 멀티 바이트를 지원하면
if has("multi_byte")
  " Vim 편집 시 내부 인코딩
  set encoding=utf-8
  " 터미널 인코딩
  set termencoding=utf-8
  " 새로 작성하는 파일 기본 인코딩
  setglobal fileencoding=utf-8
  " 읽어 오는 파일의 인코딩을 판별하는 순서
  set fileencodings=ucs-bom,utf-8,cp949,latin1
endif

위와 같이 설정하면, 파일 편집을 위해 Vim 내부적으로는 UTF-8 인코딩을 사용하고, 읽어오는 파일의 인코딩을 판별하기 위해 ucs-bom(Universal Character Set with byte-order mark), utf-8, euc-kr(cp949), latin1 순으로 적용해봅니다. 각 인코딩을 적용해 파일의 내용을 디코딩할 때 해당 문자셋 테이블을 벗어나는 값이 발견되면 다음 인코딩을 시도하는 방식이기 때문에, 실제 한글 Windows 환경에서 꽤 자주 문제가 되는 latin-1 인코딩 파일도 문제 없이 잘 판별해줍니다.

마치면서...

Text editor는 프로그래머 또는 개발자라는 타이틀을 달고 살아가는 전쟁터에서 가장 기본이 되는 무기입니다. 좋은 무기를 가지는 것이 첫 번째로 중요한 일이라면 그 무기를 충분히 활용할 수 있도록 익숙해지는 것 또한 그 못지 않게 중요한 일입니다. 비록 하나의 무기로 모든 전투에서 승리할 수는 없겠지만, 잘 찾아보면 무기의 성능을 한층 향상시켜줄 수 있는 많은 비법들이 있습니다. Emacs를 위한 문자 인코딩 자동 판별 모듈인 Unicad가 바로 그런 것들 중 하나이겠지요. 지금은 멋진 물건의 발견에 기뻐하는 것으로 만족해야 하지만 좀 더 노력한 뒤에는 멋진 물건을 스스로 만들 수 있게 되리라 기대해봅니다.

2009년 4월 1일 수요일

LispIDE - 가볍게 쓸 수 있는 Windows 용 Lisp editor

Windows 환경에서 Lisp으로 간단한 코드를 작성하고 간편하게 실행해볼 수 있는 프로그램을 소개해드립니다. 물론 Emacs + SLIME 궁합이 상당히 강력하긴 하지만, 몇 줄 안되는 짧은 코드를 작성하고 실행해보는 데 그 무거운 Emacs를 실행하기는 좀 부담스러울 때가 있습니다.(저만 그런가요?) 그래서 뭔가 대체할 만한 것이 없을까 찾아보다가 발견하게 된 것이 바로 LispIDE입니다. 아마도 Common Lisp이나 Scheme 공부를 막 시작하시는 분들에게 특히 유용할 것 같네요.


LispIDE 특징을 살펴보면,
  • Lisp과 Scheme 소스에 대한 구문 강조(Syntax Highlighting) 지원
  • SBCL, CLISP, Corman Lisp 등 대부분의 commandline Lisp과 Scheme 구현체 지원
  • 편집창에 다중 탭 지원
  • 간편한 REPL 기능 제공 (Lisp 표현식을 손쉽게 전송)
  • 커서 키로 제어 가능한 편리한 history 기능 제공
  • CHM 형식의 HyperSpec, CLtL2 포함
  • Lisp 재시작 버튼 제공
LispIDE는 무료로 사용 가능한 freeware이고 소스도 함께 공개되어 있습니다. 홈페이지에 darcs 저장소에서 내려받을 수 있는 방법을 친절하게 알려주고 있습니다. :)

잡담.
최근 Windows 상에서 Emacs 23 CVS + SLIME CVS 궁합으로 SBCL을 연결해 사용해보면 약간의 문제가 있더군요. REPL buffer 상에서 입력한 표현식에 에러가 발생하면 그 다음부터 SBCL과 Emacs 사이의 pipeline에 문제가 생겨 더 이상 표현식이 전달되지 않는 현상이 생깁니다. CLISP은 별 문제가 없어서 당분간은 CLISP을 사용하려고 하는데, 속도면에서 월등한 SBCL을 쓰지 못하는 게 좀 아쉽습니다. 좋은 해결 방법 아시는 분 안계세요? :-$

2008년 8월 6일 수요일

Source Insight에서 Symbian Build Log Parsing으로 Error Link 만들기

Source Insight에서 Symbian Build Log Parsing으로 Error Link 만들기

Source Insight에서 Symbian Build Log Parsing으로 Error Link 만들기

Parse Source Links 기능이란?

  • Source Insight에서 build 등의 결과물로 생성된 log를 분석하여 error나 warning 같은 항목에 대해 link를 만들어주는 기능입니다.
  • 만들어진 link를 사용하여 error 또는 warning이 발생한 source 위치로 즉시 이동이 가능합니다.

Build script for Symbian

  • 먼저, Source Insight에서 간편하게 build할 수 있도록 도와주는 batch script가 필요합니다.
  • 첨부된 mybuild.bat.rar 파일을 download한 후 압축을 풀고 PATH 환경 변수에 지정되어 있는 적절한 위치에 복사해둡니다.
    혹은 파일이 복사된 위치를 PATH 환경 변수에 추가해줍니다.
  • 이 batch script는 다음과 같은 방식으로 동작합니다.
    1. 현재 편집 중인 소스와 동일한 경로에서 bld.inf 파일을 찾아 그 파일이 존재하면 build를 수행합니다.
    2. 없다면, 현재 편집 중인 소스와 동일한 경로에서 group\bld.inf 파일을 찾아 그 파일이 존재하면 build를 수행합니다.
    3. 역시 없다면, 현재 편집 중인 소스와 동일한 경로에서 bld\bld.inf 파일을 찾아 그 파일이 존재하면 build를 수행합니다.
    4. 그래도 없다면, 한 단계 상위 폴더로 이동한 후 1 번부터 반복합니다.
      ※ 무한 반복을 막기 위해 최대 3 단계까지만 상위 폴더를 살피도록 되어 있습니다.

Parsing Build Logs

이제 mybuild.bat를 사용해 Custom Command에 설정을 추가하면 됩니다.
  1. Options 메뉴 -> Custom Commands... 항목을 실행합니다.


  2. Command 콤보박스에서 Build Project 항목을 선택합니다.


  3. 그림에서 보이는 것과 같이 설정 내용을 입력합니다.
    1. mybuild.bat script를 사용하여 'build armv5' 옵션으로 build 수행하는 설정입니다.
    2. script 실행 경로를 현재 편집 중인 파일의 경로로 지정합니다.
    3. 편집 중이던 파일을 저장하고 build 실행하면서 출력 결과를 capture하는 설정입니다.
    4. capture한 출력 결과를 parsing 하도록 설정합니다.
    5. parsing pattern이 File, Line 순임을 지정합니다.
    6. parsing pattern을 설정합니다.
      • Error와 Warning 포함: ^"\(.+\)", line \([^:]+\): [EW].*
      • Error만 포함: ^"\(.+\)", line \([^:]+\): E.*
    7. 반드시 Close 버튼을 눌러 설정한 내용을 저장합니다.


  4. 앞서 설정했던 Build Project와 마찬가지로 Clean Build 항목도 설정합니다.


  5. 마지막으로 Compile File 항목도 설정합니다.


Toolbar 설정 및 Key 할당

  • Toolbar 설정 - Source Insight에서는 build와 관련된 toolbar를 별도로 제공하고 있습니다.
    1. View 메뉴 -> Toolbars -> Build 항목을 실행합니다.


    2. 그러면 toolbar 영역에 다음과 같은 toolbar가 추가됩니다.


  • Key 할당
    1. Options 메뉴 -> Key Assignments... 항목을 실행합니다.


    2. 그림과 같이 Build 항목들에 대해 적절한 key를 할당해줍니다.
      1. build라고 입력하면 아래 콤보박스에 build와 관련된 항목들만 추려서 보여줍니다.
      2. 새로운 key를 할당할 항목을 선택하고 Assign New Key... 버튼을 누른 후 할당할 키조합을 눌려줍니다.
      3. OK 버튼을 눌러 설정한 내용을 저장합니다.


실행 관련 Screenshot

  • build를 실행한 모습입니다.


  • build 중 error가 발생했을 때 해당 source 위치에 대한 link를 생성해준 모습입니다.


2008년 8월 5일 화요일

Source Insight에서 Custom Token Macro 활용하기

Source Insight에서 Custom Token Macro 활용하기

이 내용은 제 springnote에 정리한 내용을 옮겨온 것입니다.


Token Macro란?

  • Token Macro는 소스에 삽입되어 있는 특정 macro 문구를 Source Insight가 올바로 해석할 수 있도록 원문으로 풀어서 기술해주는 기능입니다.
  • Source Insight가 지원하는 token macro 파일은 다음과 같습니다.
Language File Name
C and C++ C.tom - default 파일이 Source Insight에 포함되어 있음
HTML Html.tom
Java Java.tom
Resource Files Rc.tom
X86 Assembly Language X86.tom
Perl Perl.tom
  • 내 문서/Source Insight 폴더 아래에 두면 모든 프로젝트에 공통 적용됩니다.
  • 각 프로젝트의 root 폴더에 tom 파일을 두면 그 프로젝트에 대해 공통 tom 파일보다 우선합니다.

Symbian 개발 소스를 위한 설정

  • Symbian 개발 소스에도 특별히 알려주지 않으면 소스의 parsing이 제대로 되지 않아 참조가 꼬이는 문제가 발생합니다.
  • 이 문제를 해결하기 위해 e32def.h 파일 등의 내용을 가져와 C.tom 파일에 적절히 추가해주면 됩니다.
  • Symbian SDK 3.2를 기준으로 미리 작성해둔 C.tom 파일을 첨부하였습니다.
    1. 첨부된 C.tom 파일을 내 문서/Source Insight 폴더에 복사해넣습니다. 원래 있던 원본 파일은 백업을 해두시는 것이 좋습니다.
    2. Project를 rebuild 합니다.
      Project 메뉴 -> Rebuild Project 항목 선택
      ※ Project를 rebuild 하지 않아도 상수 정의 등과 같은 단순한 macro의 경우 즉시 정상적으로 보이게 됩니다. 하지만 정확한 참조 DB 생성을 위해서는 rebuild 해주는 것이 좋습니다.
  • 스크린샷
    • C.tom 파일을 적용하기 전
      _LIT로 정의된 문자열 상수가 제대로 parsing되지 못하고 엉뚱한 ID로 해석됩니다.

    • C.tom 파일을 적용한 후
      _LIT로 정의된 문자열 상수에 대한 참조가 정상적으로 잘 표시됩니다.



      rss 또는 rls에 정의된 resource 참조도 정상적으로 잘 찾아줍니다.

2008년 8월 4일 월요일

Source Insight에서 Custom Language 추가하기

Source Insight에서 Custom Language 추가하기

이 내용은 제 springnote에 정리해둔 것을 가져온 것입니다.


Custom Language란?

  • Source Insight에서 기본적으로 제공하는 프로그래밍 언어 외에 사용자가 새로운 언어 타입을 재정의하거나 추가할 수 있는 기능을 말합니다.
  • 가장 일반적으로 많이 사용되는 C/C++, Java 등의 언어에 대한 Language Definition은 이미 Source Insight에 포함되어 있는데, 이것들 외에 사용자가 별도로 더 추가하고 싶은 언어가 있을 수 있습니다. 이럴 때 사용하는 것이 Custom Language 기능입니다.
  • 또는 Symbian C++ 등과 같이 별도의 추가적인 파일 확장자나 parsing 규칙을 일부 사용하는 경우에 기존 Language Definition을 상속/재정의 해서 사용할 수도 있습니다.

Custom Language File 구하기

  • 기본적으로 Source Insight 공식 홈페이지에서 제공하는 Custom Language File(이하 CLF)을 사용할 수 있습니다.
  • 인터넷 검색을 통해서 몇몇 CLF 파일을 구할 수 있기도 하지만, 의외로 드뭅니다. :(
  • 사용자가 직접 CLF를 만드는 것도 가능합니다. 이 작업은 좀 번거롭고 시간이 걸릴 수 있습니다.

Custom Language 추가하기

Custom Language를 추가하는 데에는 두 가지 작업을 필요합니다. 하나는 Language 자체에 대한 parsing 정보를 등록하는 것이고, 나머지는 등록한 Language를 Project에 적용할 수 있도록 Document Option에 추가해주는 것입니다.
  1. 새로운 Language 추가하기 
    1. Options 메뉴 -> Preferences 메뉴 -> Languages 탭으로 이동합니다.



    2. Import 버튼을 눌러 원하는 CLF 파일을 가져옵니다.
      Add 버튼을 눌러서 새로운 Language를 추가하고 직접 keyword 편집이나 symbol parsing 규칙 등록 등의 작업을 해줄 수도 있습니다.



    3. 이제 Languages 탭에서 새로운 Language가 추가된 것을 확인할 수 있습니다.
      ※ 사용자가 추가한 Custom Language는 아이콘이 약간 다릅니다.



  2. 추가한 Language에 대한 Document Option 추가하기 
    1. Options 메뉴 -> Document Options 메뉴를 실행한 다음 다이얼로그에서 Add Type 버튼을 눌러 새로운 타입을 추가합니다.



    2. 추가된 타입에 대한 상세 설정을 해줍니다.



      1. 이 Language Type이 적용될 확장자를 지정해줍니다.
      2. Include when adding to projects 항목을 체크해주어야 프로젝트 생성 시 해당 확장자 파일이 자동으로 추가됩니다.
      3. 위 첫 번째 단계에서 추가한 Custom Language를 지정해줍니다.

Symbian C++ 개발을 위한 추천 설정

Symbian 관련 개발 상에서는 일반 C++ 개발 상에서와 달리 추가되는 파일들이 몇 가지 더 있습니다. 그렇기 때문에 이 파일들을 별도의 Language Type으로 등록해주면 소스 분석에 더욱 도움이 됩니다.
  • 가장 먼저 Symbian C++ 관련 C.tom 파일을 적용해두셔야 합니다.
  • Symbian C++ 관련 source 파일 등록
    • 추가해야 할 확장자들: *.hrh;*.pan;*.inl;*.rsg;*.rh;*.loc;*.mbg;*.rss;*.rls
      주의: C++ Language Type에 Symbian C++ 관련 확장자를 등록해두신 분은 C++ Language Type 쪽에서 그 확장자를 제거해주실 필요가 있습니다.



  • Symbian C++ 관련 build script 파일 등록
    • 추가해야 할 확장자들: *.mmp;*.midef;*.inf;*.iby



2007년 3월 25일 일요일

HxD - Freeware Hex Editor

컴퓨터로 이런 저런 작업을 하다보면 특정 파일의 내부를 있는 그대로 까보아야 하는 경우가 제법 있습니다. 그 파일의 형식이 일반 텍스트 파일이라면 텍스트 편집기나 하다 못해 메모장으로라도 열어서 확인할 수가 있지만 이진(binary) 데이터로 가득 찬 파일들은 문제가 좀 있죠.

이때 필요한 것이 hex editor입니다. 개별 byte를 16진 값으로 보여준다고 해서 붙여진 이름인 것 같은데, 정말 없어서는 안될 필수 도구 중 하나라고 감히 말할 수가 있겠습니다.

문제는 쓸만한 hex editor는 죄다 상용 프로그램이라는 것입니다.(꽤 유명한 hex editor로는 Hex Workshop, WinHex 등이 있습니다.) 물론, 무료로 개발되어 배포되는 것들도 제법 있고, 16진 편집 기능을 함께 제공하는 텍스트 편집기(PSPad, DesyEdit 등이 있죠.)도 있지만 상용 hex editor에 비해서 기능이 많이 부족한 것이 사실입니다. 늘 이런 사실을 안타까워 하고 있었는데, 오늘 우연히 발견하게 된 HxD가 그 안타까움을 상당 부분 해결해주었습니다.



HxD의 제작자가 소개하는 주요 기능을 나열해보면..
  • RAM 편집 기능
  • Disk 편집 기능 (Hard disk, Zip-disk, CD, ...) (Win9x, WinNT and higher)
  • 유연하고 빠른 찾기/바꾸기 기능(Unicode 지원을 포함하는 문자열, 16진 값, 정수 값, 실수 값)
  • Ansi, DOS, EBCDIC 문자셋에 대한 표현 기능
  • 체크섬 생성 기능: Checksum, CRCs, Custom CRC, SHA-1, SHA-512, MD5, ...
  • 소스 코드 형식에 맞춘 데이터 내보내기(Pascal, C, Java)와 형식화된 데이터 내보내기(plain text, HTML, Richtext, TeX) 기능
  • 기본적인 수준의 데이터 통계
  • 파일 크기 무제한
  • 수정된 데이터 부분 표시 기능
  • 되돌리기 무제한
정말 상용 프로그램에 비해서 크게 뒤지지 않는 멋진 기능들을 제공하고 있습니다. 이런 좋은 프로그램을 무료로 배포한다는 점에 대해 제작자에게 감사하지 않을 수 없습니다. ;-)

그리고, 제가 별도로 강조하고 싶은 특징은, 설치가 필요 없는 단일 실행 파일로 구성되어 있다는 점입니다. USB 메모리 등에 휴대하고 다니면서 편리하게 사용할 수도 있고, 홈페이지에서 바로 다운로드해서 사용하고 사용이 끝나면 지워버려도 상관없기 때문에 PC방 등이나 내 소유가 아닌 PC에서 작업할 때에도 부담이 없습니다.

HxD의 공식 홈페이지는 다음과 같습니다.

LINK: http://www.mh-nexus.de/hxd/

저와 같은 목마름으로 안타까워 하셨던 분들은 이제 HxD로 그 목마름을 해결해보시기 바랍니다. :)

2007년 1월 11일 목요일

EMACS + SLIME + CLISP on Win32

얼마 전에 EmacsW32에 관한 글을 올렸는데, 그 때 잠시 언급했던 SLIME mode를 사용하는 방법에 대해 조금 더 자세히 살펴보려고 합니다.

1. 준비물:
  • EmacsW32+Emacs:
    보통 latest EmacsW32+Emacs patched Emacs patched icon을 받으시면 됩니다.
  • SLIME mode:
    stable release를 받으시면 됩니다. (이 글을 작성하는 시점에서 2.0이 최신 버전이네요.) 취향에 따라서 CVS 저장소로부터 직접 받으셔도 됩니다.
  • CLISP (또는 SLIME이 지원하는 다른 Lisp 구현체):
    보통 clisp-x.xx-win32-mingw-without-readline.zip 파일을 받으시면 됩니다. CLISP 대신 다른 상용 Lisp 구현체나 SBCL도 많이 사용하신다고 알고 있는데, 이 글에서는 제가 애용하는 CLISP만을 예로 들겠습니다. - 사실 SLIME 설정 시에 큰 차이는 없습니다. -

2. CLISP 설치
매우 간단합니다. download한 파일을 적절한 폴더에 압축 풀어주면 끝입니다. 바탕화면에 단축아이콘을 생성해주는 install.bat가 별도로 제공이 되지만, 경로명에 한글이 들어가는 경우에는 parse error를 내더군요. 그냥 'clisp.exe' 파일에 대해서 직접 단축아이콘 하나 만드시면 됩니다. 그리고, 어차피 Emacs 내에서 SLIME mode를 통해 실행할 것이기 때문에 단축아이콘을 쓸 일이 거의 없을 겁니다. 이 글에서는 'C:\CLISP' 폴더에 압축을 풀었다고 가정합니다.

3. EmacsW32+Emacs 설치
이것 역시 설치가 매우 간단합니다. 설치 패키지 형태로 되어 있기 때문에 실행한 다음 next 버튼만 누르다보면 설치가 완료됩니다. 설치 중간에 설치 폴더를 변경하지 않았다면 'C:\Program Files\Emacs' 폴더에 설치가 되었을 겁니다.

4. SLIME mode 설치 및 설정
Emacs 설치 폴더 아래에 만들어진 'site-lisp' 폴더에 'slime-2.0.zip' 파일의 압축을 풉니다. 그러면 'slime-2.0' 폴더가 만들어집니다. 이것으로 설치는 끝입니다. 이제 SLIME mode가 Emacs에서 load 될 수 있도록 '.emacs' 설정 파일에 SLIME 관련 내용을 추가해주기만 하면 됩니다. '.emacs' 파일은 'C:\Documents and Settings\사용자 계정\Application Data' 폴더에 있습니다. 없다면 새로 하나 만들어 주세요.

다음은 제가 사용하고 있는 SLIME 설정 내용입니다.
전체 파일은 여기서 받으세요.
;; SLIME 설치된 폴더
(add-to-list 'load-path
"C:/Program Files/Emacs/site-lisp/slime-2.0/")
(require 'slime)
;; UTF-8 인코딩을 기본으로 사용 --> 한글 symbol 사용을 위해
(setq slime-net-coding-system 'utf-8-unix)
;; Lisp 실행 파일
(setq inferior-lisp-program "C:/CLISP/clisp.exe")
(setq common-lisp-hyperspec-root
"http://www.lispworks.com/documentation/HyperSpec/")
;; FireFox를 사용한다면 아래 주석 해제
;(setq browse-url-generic-program
; "C:/Program Files/Mozilla Firefox/firefox.exe")
;(setq browse-url-browser-function (quote browse-url-generic))
(add-hook 'inferior-lisp-mode-hook
(lambda () (inferior-slime-mode t)))
(add-hook 'lisp-mode-hook
(lambda ()
(set (make-local-variable
'lisp-indent-function)
'common-lisp-indent-function)))
(slime-setup :autodoc t)

5. 실행해보기
자, 이제 실행을 해봅시다. Emacs를 실행한 다음 아래과 같이 입력합니다.

M-x slime

'M-x'는 'Alt'키를 누르면서 'x' 키를 누르라는 의미입니다. 그러면 창 가장 아래쪽 미니 버퍼에 커서가 깜빡이는데, 여기서 'slime'이라고 입력한 다음 enter 키를 누르면 됩니다. 이제 편집창에 새로운 버퍼들이 만들어지면서 뭔가 글이 막 올라가다가 마지막에 CLISP prompt가 뜨게 됩니다.

이 다음부터는 여러분의 몫입니다. ;-)

6. 재미있는 팁 한 가지를 알려드리면...
위 SLIME 설정 내용 중에 UTF-8 사용이 가능하도록 추가해준 부분이 있는데, 이렇게 UTF-8 인코딩을 사용하게 되면 한글 symbol을 사용할 수 있게 됩니다. 물론 사용하는 Lisp 구현체가 UTF-8을 지원해주어야 가능합니다. CLISP은 UTF-8을 지원하고 있습니다.

2007년 1월 8일 월요일

EmacsW32 - Enhancements for Emacs W32 Users


Unix 계열 환경에서 프로그램을 작성하거나 Lisp 프로그램을 주로 작성하는 사람이 아니라고 해도 Emacs라는 이 위대한 editor(사실 editor 그 이상이죠.)에 대한 이름은 한 번쯤 들어보셨을 것이라 생각됩니다. - Emacs에 대한 상세한 소개는 이미 잘 만들어져 있는 Wikipedia의 이맥스 페이지를 참고해주세요. -

저는 성격 상 Emacs보다는 vi 쪽으로 더 많은 정이 가지만, 요즘 들어서 Common Lisp을 공부하다 보니 Emacs만한 것이 없다는 생각이 절로 드네요. 그래서, Windows 환경에서 쓸만한 Emacs 패키지를 찾아보았습니다. EmacsWiki라든가 EmacsKR 같은 Emacs 커뮤니티 사이트를 뒤지다 보니 많은 분들이 추천하는 패키지가 딱 있더군요. 바로 EmacsW32입니다.

EmacsW32 자체는 Emacs lisp 모듈과 Emacs를 위한 유용한 Windows 프로그램을 모아 놓은 것입니다. 그런데, 친절하게도 현재 한창 개발 중인 Emacs 22 버전을 CVS 저장소에서 직접 가져다가 Windows 환경을 위한 몇 가지 유용한 patch까지 가미해서 설치 패키지 형태(EmacsW32+Emacs)로 제공해주고 있습니다. 이 설치 패키지는 기본적으로 leim을 포함하고 있어서 별도의 추가 설치 없이 바로 한글을 입력할 수 있고, Unicode 파일에 대한 편집도 가능하더군요. 몇 년 전에 잠시 사용해본 Emacs for Windows NT보다 훨씬 간편하고 안정적이라고 할 수 있었습니다.

EmacsW32 공식 페이지는 다음과 같습니다.

LINK: http://ourcomments.org/Emacs/EmacsW32.html

Windows 환경에서 간편하게 사용할 수 있는 Emacs 패키지를 찾고 계신다면 EmacsW32+Emacs를 강력히 추천합니다. 그리고, Common Lisp 개발자인 경우 SLIME mode를 설치하시면 금상첨화입니다. :-)

2006년 3월 13일 월요일

EmEditor 5 Freeware Edition


완벽한 다국어 편집 지원을 가장 큰 장점으로 꼽을 수 있는 빠르고 강력한 기능의 editor가 있습니다. 바로 EmEditor인데요, 이미 알고 계신 분들이 많을 것이지만 다시 한 번 이렇게 소개해 드리는 이유는 5.0 버전 발표와 함께 freeware edition이 출시되었다는 기쁜 소식을 알려드리기 위함입니다.

EmEditor는 프로그래머들을 위한 대부분의 editor들이 일반적으로 지원하는 기능을 고스란히 지원하고 있습니다. 여기에 덧붙여서 다양한 plug-in 지원, 강력한 macro 지원, 완벽한 다국어 편집 지원 등을 특장점으로 가지고 있고, 5.0 버전에 와서는 아무리 많은 파일을 열어도 점유하는 메모리는 8MB 남짓한 정도로 유지되는 뛰어난 자원 관리 능력까지 겸비하게 되었습니다,

지금 소개해드리는 freeware edition은 macro와 plug-in 등의 기능이 제한되지만, license 비용이 별도로 필요하지 않은 형태로 출시된 제품입니다. 생략된 기능들이 좀 아쉽기는 하지만, 다국어 편집을 완벽하게 지원하고 Windows의 Notepad를 대체할 수 있을 정도로 가벼우면서도 강력한 기능을 자랑하는 editor는 좀처럼 찾기 쉽지 않습니다.

Freeware edition 5.0 버전에서는 정규표현식을 사용한 치환이 안되는 문제가 보고 되어 있습니다만, 조만간 수정될 것으로 기대합니다. 5.01 beta 1 이후 버전에서 이 문제는 수정되었습니다.

EmEditor Free 6.00.4 버전의 다운로드 페이지입니다.
LINK: http://www.emeditor.com/modules/download2/rewrite/tc_5.html

EmEditor의 공식 홈페이지는 다음과 같습니다.
LINK: http://www.emeditor.com

소개글이 두서 없고 빈약해서 이 editor의 장점을 제대로 전달하지 못하고 있는 것이 안타깝네요. 더욱 자세한 내용은 공식 홈페이지를 참고 해주세요.

2005년 12월 28일 수요일

PSPad - freeware text and code editor


이미 많은 사용자 층을 확보하고 있는 PSPad가 이번에 기능을 대폭 강화해서 새로 4.5.0 버전을 발표했네요. PSPad는 개발자를 위한 에디터로서 손색이 전혀 없을 만큼 다양한 기능을 제공하고 있는데 그 중에서도 굵직한 것을 몇 개 들어보면 다음과 같습니다.

- Project 단위 파일 관리 지원
- FTP 연동
- Macro 지원
- Syntax Highlighting
- HEX Edit 지원
- Unicode, UTF-8 완벽지원
- 다국어 인터페이스 지원(한글도 지원됨)

제 경험 상 이 editor에서 가장 마음에 드는 부분은 다국어 편집 시 글꼴 깨짐없이 완벽하게 UTF-8, Unicode 인코딩을 지원해준다는 점입니다. (이전 4.3.x 버전까지만 해도 글꼴 깨짐 현상이 있었는데, 4.5.0 버전에 와서 수정이 된 모양입니다.)

AcroEditDesyEdit 같은 국내 개발자에 의한 freeware 편집기들도 나무랄 데 없이 좋은 데 Unicode 혹은 UTF-8 파일을 열었을 때 한국어가 아닌 서유럽어 문자들에서 글꼴 깨짐 현상이 나타나더군요. 어떻게 보면 그다지 심각한 문제가 아닐 수도 있겠지만, 다국어 환경에서 작업을 하는 사람들에게는 꽤 치명적인 문제일 수 있죠. ^^;

다음은 PSPad의 공식 홈페이지입니다.

http://www.pspad.com

이 PSPad는 이러한 막강한 기능을 제공하면서도 free로 배포됩니다.

2004년 1월 6일 화요일

SciTE - 프로그래머를 위한 작고 강력한 편집기

간편하게 사용할 수 있는 공개 편집기를 찾다가 발견한 것입니다. 홈페이지에서도 'A free source code editor for Win32 and X' 라고 소개되어 있는 것처럼 다중 플랫폼을 지원하고, 각종 소스 코드를 편집하는데 편리한 많은 기능들을 가지고 있으며, 상당히 가볍고 빠릅니다. 눈에 띄는 특징 중 하나는 설정 방식으로, 마치 Java의 properties 파일 형식과 유사한데, 편집기의 거의 모든 부분을 변경할 수 있을 정도로 막강합니다.(막강한 대신 조금 어렵기는 합니다. 하지만, 프로그래머를 위한 편집기이니만큼 그 정도는 감수를...)

[*] 아래는 SciTE의 공식 홈페이지입니다.
http://www.scintilla.org/SciTE.html

[*] 스크린샷입니다.
http://www.scintilla.org/SciTEImage.html

[*] 번역된 언어 파일들입니다.
http://code.google.com/p/scite-files/wiki/Translations

제가 나름대로 어눌한 실력이나마 번역을 해서 제작자에게 메일로 보내두었는데, 등록이 될 때까지는 약간의 시간이 걸린다고 합니다.(제작자가 휴가중이랍니다.) 그래서, 이곳에 따로 직접 제가 번역한 파일을 링크하겠습니다. 필요하신 분들은 많이 많이 받아가세요. ^^

Download: locale.ko_KR.properties

이 파일을 'locale.properties'로 이름을 변경한 다음 SciTE가 있는 디렉터리에 복사해넣으시면 됩니다.

[*] 좀 더 편리한 사용을 위한 설정 파일입니다. (제 기준에서 ㅡㅡ)

Download: SciTEUser.properties

이 설정 파일에서는 나눔고딕코딩 글꼴을 사용하도록 설정하고 있기 때문에 글꼴이 아직 설치되어 있지 않을 경우 아래 주소에서 받아 설치하세요.

LINK: 나눔고딕코딩 글꼴

이 파일을 사용자의 Home 디렉터리에 복사해넣으시면 됩니다. Windows 2000/XP의 경우 일반적으로 'C:\Documents and Settings\<사용자 계정 이름>'이 Home 디렉터리가 됩니다. 가장 확실하게 확인하는 방법은 환경변수 중에서 HOME 또는 HOMEPATH의 값을 확인해보시면 됩니다.

좀 더 나은 프로그래밍 환경이 될 수 있도록... ^^

2003년 5월 27일 화요일

Cream for Vim


UNIX 계열의 OS에서 아마 가장 많이 사용되는 편집기는 vi일 것입니다. 그런 vi의 기능을 향상시키고 좀 더 다양한 플랫폼 상에서 사용할 수 있도록 하기 위해서 진행되고 있는 프로젝트가 바로 Vim입 니다. 이미 많은 분들이 이 Vim을 사용하고 계실 겁니다. 대부분의 Linux 배포판에 기본으로 Vim 패키지가 포함이 되어 있고, Windows용으로 설치 프로그램 형태의 패키지도 제공이 되니까 별다른 어려움 없이 vi를 경험해볼 수 있는 좋은 기회를 제공해준다고나 할까요.

이런 Vim을 한 단계 더 업그레이드 해주는 것이 있습니다. 바로 Cream이죠. Cream은 기존 Vim의 기능을 확장하는 스크립트로 구성되어 있습니다. 어떤 점에서는 오히려 더 복잡하게 느껴질 수도 있는 기능들이지만, Vim 사용에 익숙한 사용자라면 한 번쯤 생각해보았을 기능들, 가려운 곳을 시원하게 긁어줄 수 있는 기능들을 잔뜩 제공합니다. 그 중에서도 특히 눈에 띄는 점이라면,
  • 향상된 Syntax Highlighting 기능
  • vi에 익숙치 않은 사용자를 위한 Basic Mode 제공
  • vi style의 편집을 원하는 사용자를 위한 Expert Mode 제공
  • 화려한 Color Theme
등이 있습니다. (물론 제 생각입니다. ㅡㅡ^)

설치법이나 주요기능들에 대한 내용은 공식 홈페이지를 참고하세요. (제가 게을러서 일일이 퍼다 나르는 게 귀찮네요. ^^; )
공식홈페이지의 주소는 다음과 같습니다.

http://cream.sourceforge.net/

참고로, Windows용으로는 Vim과 통합된 Cream with Vim 패키지도 제공이 되니까 복잡한 수동 설치과정을 거치지 않고도 손쉽게 Cream을 사용해보실 수 있습니다.