예전에 Emacs에서 Rails 코딩하기라고 올린 글이 있었는데, 이번에 루비코코아를 살펴보면서 이맥스를 사용하다보니, 대문자 C가 안쳐지는 문제를 발견했다; 해결 방법은 .emacs 파일의 다음 라인을
(define-key ruby-mode-map "C-m" 'newline-and-indent)
=>
(define-key ruby-mode-map "\C-m" 'newline-and-indent)
이와 같이 고쳐주면 된다.
2008년 10월 14일 화요일
2008년 9월 2일 화요일
여러가지 언어를 배운다는 것 - Why Lisp?
'실용주의 프로그래머'라는 책을 보면 한 달에 하나 정도 새로운 언어를 살펴보는 것이 도움이 된다는 얘기가 나온다. 어떻게 생각하는가? 새로운 언어를 배운다는 것은 노력은 잔뜩 들어가는 데 비해 얻는 것은 별로 없는 행동이 아닐까? 한 언어에서는 함수 정의를 위해 def를 쓰고 다른 언어에서는 defun을 쓴다는 걸 살펴보는 게 무슨 의미가 있을까?
언어를 배움으로써 무언가를 얻고 싶다면, 표기법의 차이가 아니라 개념의 차이를 살피려고 노력해야 한다. 언어를 익혀보면, 실제로 표기법의 차이를 익히는데 드는 시간은 그리 크지 않다. 대부분의 시간은 전에 알지 못하던 새로운 개념을 이해하는데 들기 마련이다. 언어는 사고를 지배한다. 극단적인 예이지만, 셋 이상의 수를 가리키는 말이 없는 언어를 쓰는 사람들은 수에 대한 개념이 극히 제한될 수 밖에 없다.
어떤 언어에는 있고 다른 언어에는 없는, 정말로 고유한 개념 같은 것이 있을까? 글쎄, 예를 들어 보자. Lisp이 다른 언어에 비해 가진 고유한 특징은 데이터와 코드의 형태가 같다는 것이다. Lisp의 자료구조 중 하나인 리스트는 코드를 표현하는 데도 쓰인다. 즉, 다음의 두 표현은 모두 리스트(데이터)이면서 코드이다.
(1 2 3 4)
(defun hello () "hello")
데이터와 코드의 형태가 같다는 것은 언어를 만드는 것과 프로그램을 짜는 것 사이의 경계가 없다는 것을 의미한다. 둘 다 기본 언어 위에 추상(abstraction)을 쌓아 올려서 우리가 표현하고자 하는 것을 쉽게 표현할 수 있게 만드는 것일 뿐이다. 예를 하나 들어 보겠다.
Erlang에서는 -compile(export_all). 옵션을 파일 위쪽에 선언하면 모듈 안의 모든 함수들이 다른 모듈에서 사용할 수 있도록 export 된다. Lisp에서는 어떤 패키지 안의 함수들을 export 하려면 다음과 같이 선언해 주어야 한다.
(export '(function1 function2 function3 ...))
Lisp에서 한 번의 선언을 통해 패키지 안의 모든 함수를 export 하는 with-export-all이라는 operator를 만들고 싶었다고 하자. with-export-all이 해야 할 일은 다음과 같다.
1. 코드 중에 defun(함수를 선언하는 symbol)으로 시작하는 코드가 있는지 살펴보고 있다면 함수 이름을 리스트에 저장한다.
2. 리스트에 저장된 함수 이름을 export 한다.
with-export-all을 사용하면 다음 예와 같이 확장(expansion)되어야 할 것이다.
위와 같이 동작하는 with-export-all의 코드는 다음과 같다.
with-export-all은 리스트(코드)를 받아서 리스트의 각 요소가 함수를 선언하는 코드(리스트)인지 살펴보고 맞을 경우 함수 이름을 빼내서 리스트를 만든다. 그 뒤에 함수들을 export하는 부분을 추가한 코드(리스트)를 리턴한다. with-export-all이 하는 일은 코드를 받아서 살펴보고 조작한 코드를 리턴하는 것이다. 동시에 그것은 그저 리스트(데이터, 배열이나 벡터라고 봐도 무방할 수 있는)를 받아서 조작한 리스트를 리턴하는 것일 뿐이다.
다른 언어에서 비슷한 일을 하려면 코드를 받는 메써드를 만들어야 할 것이다. 하지만 다른 언어에서 코드는 데이터가 아니다. 따라서 코드를 넘기려면 데이터의 형식인 스트링으로 넘기던지 해야 할 터이지만, 위와 같은 예에서 파일의 코드 전체를 export_all이라는 메써드에 스트링으로 넘겨야 한다면 정상적인 코딩은 불가능해질 것이다. 코드 전체가 한 색깔로, indentation도 없이 표시되는 것을 보게 될 테니 말이다.
C의 매크로는 코드를 받아 코드를 리턴할 수 있다. 하지만 Lisp에서 데이터와 코드의 형태가 같다는 것은 데이터를 다루는 수준의 섬세함으로 코드를 조작할 수 있다는 말이 된다. C에서 위와 같이 코드를 살펴보고 복잡한 작업을 하는 매크로를 만드는 것드는 것은 어려운 일이다. 더구나 C의 매크로에는 결정적인 단점이 하나 있는데 매크로를 정의하는 데 사용되는 symbol의 name confliction(흔히 variable capture라고 일컬어지는 문제)을 피할 방법이 없다는 것이다.
(AOP를 사용하는 것은 위와 같은 operator를 사용하는 것과 다른데, 어떤 오퍼레이터가 적용되는지가 코드에 보이지 않기 때문이다. 예를 들어, 매크로를 사용하면 with-export-all-function, with-export-all-macro, with-export-all 등의 operator들을 만들어 상황에 따라 코드의 일부만 적절한 operator로 감싸는 것도 가능하다. 하지만 AOP를 사용해서 포인트컷을 정규식으로 표현하게 되면 그렇게 부분적이고 세밀한 적용은 불가능하거니와, 적용 여부가 명시적으로 눈에 안 보인다는 단점을 지닌다)
데이터와 코드의 형태가 같다는 것은 아직까지는 Lisp만의 고유한 특성이라고 할 수 있다. Lisp이 가진 가비지 콜렉션이나 interactive 프로그래밍 환경 등의 특성들을 다른 언어들이 가져가 도입했지만 아직까지도 데이터와 코드의 형태가 같다는 특성만은 취하질 못하고 있다. 왜일까? 이유는 나도 잘 모르겠다.
Lisp의 최고 장점으로 꼽히는 매크로의 힘과 우아함도 사실상 코드와 데이터의 형태가 같다는 데서 나오는 것이라고 할 수 있다(추가적으로 모든 operator가 리스트의 첫번째에 온다는 것이 언어가 가진 문법의 전부라는 것도 우아함을 만들어내는 요소라고 할 수 있다. 흔히 'Lisp에는 문법이 없다'라고 말해지기도 한다). Lisp의 매크로는 언어의 표현력에 가해지는 제약을 없앰으로써 프로그래머에게 무한한 자유를 부여한다.
요지는 언어마다 그 언어를 통해 배울 수 있는 고유한 개념이나 관점등이 있다는 것이다. 함수형 언어가 가진 개념들의 정수를 살펴보고 싶다면 Haskell, 병행성과 scalability에 관심이 있다면 Erlang, 객체 지향에 대해 알고 싶다면 Smalltalk 등이 좋을 것이다. 하지만 현재 익숙한 언어 외에 하나의 언어밖에 볼 시간이 없다면 Common Lisp을 볼 것을 추천한다. 그 이유는 Common Lisp이 여러 가지 개념들을 동시에 접할 수 있는 multi-paradigm 언어이기 때문이다. '모든것이 가능하다'라는 말이 Common Lisp을 가장 잘 표현해주는 말이 아닌가 생각한다. 프로그래머는 원하는 모든 것을 할 수 있다. 객체 지향 방식으로 프로그래밍 할 수도 있고, 함수형 언어의 특징을 사용할 수도 있다. 동적 타입에 의존할 수도 있고 정적으로 형을 선언해서 프로그램을 빠르게 만드는 것도 가능하다. 기본적으로 abstraction 레벨이 높아서 표현력이 뛰어난(더 적은 문장으로도 많은 내용을 표현할 수 있다면 표현력이 좋다고 할 수 있다) 반면에, goto나 비트연산, 스택을 다루는 등의 하위 레벨의 표현도 가능하다. Common Lisp을 통해서 다음과 같은 개념들을 익힐 수 있다.
Lisp을 보고 나서 다른 언어를 살펴보게 되면 Lisp에서 나온 개념의 하위 개념을 다루고 있는 경우가 대부분이기 때문에 이해가 매우 쉽다고 할 수 있다.
Common Lisp을 살펴보고 싶다면 Common Lisp 가이드를 참고하기 바란다.
언어를 배움으로써 무언가를 얻고 싶다면, 표기법의 차이가 아니라 개념의 차이를 살피려고 노력해야 한다. 언어를 익혀보면, 실제로 표기법의 차이를 익히는데 드는 시간은 그리 크지 않다. 대부분의 시간은 전에 알지 못하던 새로운 개념을 이해하는데 들기 마련이다. 언어는 사고를 지배한다. 극단적인 예이지만, 셋 이상의 수를 가리키는 말이 없는 언어를 쓰는 사람들은 수에 대한 개념이 극히 제한될 수 밖에 없다.
어떤 언어에는 있고 다른 언어에는 없는, 정말로 고유한 개념 같은 것이 있을까? 글쎄, 예를 들어 보자. Lisp이 다른 언어에 비해 가진 고유한 특징은 데이터와 코드의 형태가 같다는 것이다. Lisp의 자료구조 중 하나인 리스트는 코드를 표현하는 데도 쓰인다. 즉, 다음의 두 표현은 모두 리스트(데이터)이면서 코드이다.
(1 2 3 4)
(defun hello () "hello")
데이터와 코드의 형태가 같다는 것은 언어를 만드는 것과 프로그램을 짜는 것 사이의 경계가 없다는 것을 의미한다. 둘 다 기본 언어 위에 추상(abstraction)을 쌓아 올려서 우리가 표현하고자 하는 것을 쉽게 표현할 수 있게 만드는 것일 뿐이다. 예를 하나 들어 보겠다.
Erlang에서는 -compile(export_all). 옵션을 파일 위쪽에 선언하면 모듈 안의 모든 함수들이 다른 모듈에서 사용할 수 있도록 export 된다. Lisp에서는 어떤 패키지 안의 함수들을 export 하려면 다음과 같이 선언해 주어야 한다.
(export '(function1 function2 function3 ...))
Lisp에서 한 번의 선언을 통해 패키지 안의 모든 함수를 export 하는 with-export-all이라는 operator를 만들고 싶었다고 하자. with-export-all이 해야 할 일은 다음과 같다.
1. 코드 중에 defun(함수를 선언하는 symbol)으로 시작하는 코드가 있는지 살펴보고 있다면 함수 이름을 리스트에 저장한다.
2. 리스트에 저장된 함수 이름을 export 한다.
with-export-all을 사용하면 다음 예와 같이 확장(expansion)되어야 할 것이다.
(with-export-all
(defun hello ()
"hello")
(defvar *hey*)
(defun bye ()
"bye")))
=>
(PROGN
(EXPORT '(HELLO BYE))
(DEFUN HELLO () "hello")
(DEFVAR *HEY*)
(DEFUN BYE () "bye"))
위와 같이 동작하는 with-export-all의 코드는 다음과 같다.
(defmacro with-export-all (&body body)
(let ((function-list nil))
(loop for expression in body do
(if (equalp 'defun (first expression))
(push (second expression) function-list)))
(setf function-list (reverse function-list))
`(progn
(export ',function-list)
,@body)))
with-export-all은 리스트(코드)를 받아서 리스트의 각 요소가 함수를 선언하는 코드(리스트)인지 살펴보고 맞을 경우 함수 이름을 빼내서 리스트를 만든다. 그 뒤에 함수들을 export하는 부분을 추가한 코드(리스트)를 리턴한다. with-export-all이 하는 일은 코드를 받아서 살펴보고 조작한 코드를 리턴하는 것이다. 동시에 그것은 그저 리스트(데이터, 배열이나 벡터라고 봐도 무방할 수 있는)를 받아서 조작한 리스트를 리턴하는 것일 뿐이다.
다른 언어에서 비슷한 일을 하려면 코드를 받는 메써드를 만들어야 할 것이다. 하지만 다른 언어에서 코드는 데이터가 아니다. 따라서 코드를 넘기려면 데이터의 형식인 스트링으로 넘기던지 해야 할 터이지만, 위와 같은 예에서 파일의 코드 전체를 export_all이라는 메써드에 스트링으로 넘겨야 한다면 정상적인 코딩은 불가능해질 것이다. 코드 전체가 한 색깔로, indentation도 없이 표시되는 것을 보게 될 테니 말이다.
C의 매크로는 코드를 받아 코드를 리턴할 수 있다. 하지만 Lisp에서 데이터와 코드의 형태가 같다는 것은 데이터를 다루는 수준의 섬세함으로 코드를 조작할 수 있다는 말이 된다. C에서 위와 같이 코드를 살펴보고 복잡한 작업을 하는 매크로를 만드는 것드는 것은 어려운 일이다. 더구나 C의 매크로에는 결정적인 단점이 하나 있는데 매크로를 정의하는 데 사용되는 symbol의 name confliction(흔히 variable capture라고 일컬어지는 문제)을 피할 방법이 없다는 것이다.
(AOP를 사용하는 것은 위와 같은 operator를 사용하는 것과 다른데, 어떤 오퍼레이터가 적용되는지가 코드에 보이지 않기 때문이다. 예를 들어, 매크로를 사용하면 with-export-all-function, with-export-all-macro, with-export-all 등의 operator들을 만들어 상황에 따라 코드의 일부만 적절한 operator로 감싸는 것도 가능하다. 하지만 AOP를 사용해서 포인트컷을 정규식으로 표현하게 되면 그렇게 부분적이고 세밀한 적용은 불가능하거니와, 적용 여부가 명시적으로 눈에 안 보인다는 단점을 지닌다)
데이터와 코드의 형태가 같다는 것은 아직까지는 Lisp만의 고유한 특성이라고 할 수 있다. Lisp이 가진 가비지 콜렉션이나 interactive 프로그래밍 환경 등의 특성들을 다른 언어들이 가져가 도입했지만 아직까지도 데이터와 코드의 형태가 같다는 특성만은 취하질 못하고 있다. 왜일까? 이유는 나도 잘 모르겠다.
Lisp의 최고 장점으로 꼽히는 매크로의 힘과 우아함도 사실상 코드와 데이터의 형태가 같다는 데서 나오는 것이라고 할 수 있다(추가적으로 모든 operator가 리스트의 첫번째에 온다는 것이 언어가 가진 문법의 전부라는 것도 우아함을 만들어내는 요소라고 할 수 있다. 흔히 'Lisp에는 문법이 없다'라고 말해지기도 한다). Lisp의 매크로는 언어의 표현력에 가해지는 제약을 없앰으로써 프로그래머에게 무한한 자유를 부여한다.
요지는 언어마다 그 언어를 통해 배울 수 있는 고유한 개념이나 관점등이 있다는 것이다. 함수형 언어가 가진 개념들의 정수를 살펴보고 싶다면 Haskell, 병행성과 scalability에 관심이 있다면 Erlang, 객체 지향에 대해 알고 싶다면 Smalltalk 등이 좋을 것이다. 하지만 현재 익숙한 언어 외에 하나의 언어밖에 볼 시간이 없다면 Common Lisp을 볼 것을 추천한다. 그 이유는 Common Lisp이 여러 가지 개념들을 동시에 접할 수 있는 multi-paradigm 언어이기 때문이다. '모든것이 가능하다'라는 말이 Common Lisp을 가장 잘 표현해주는 말이 아닌가 생각한다. 프로그래머는 원하는 모든 것을 할 수 있다. 객체 지향 방식으로 프로그래밍 할 수도 있고, 함수형 언어의 특징을 사용할 수도 있다. 동적 타입에 의존할 수도 있고 정적으로 형을 선언해서 프로그램을 빠르게 만드는 것도 가능하다. 기본적으로 abstraction 레벨이 높아서 표현력이 뛰어난(더 적은 문장으로도 많은 내용을 표현할 수 있다면 표현력이 좋다고 할 수 있다) 반면에, goto나 비트연산, 스택을 다루는 등의 하위 레벨의 표현도 가능하다. Common Lisp을 통해서 다음과 같은 개념들을 익힐 수 있다.
- atom, symbol, keyword parameter
=> Erlang의 atom, 루비의 symbol, Object-C의 키워드가 당연해 보이게 된다. - higher order function, currying, closure, memoize
=> 자바스크립트나 Erlang의 higher order function이나 closure가 쉽게 눈에 들어온다. - Object Oriented System, OO 개념의 메타 개념이라 할 수 있는 meta object protocol(MOP)
=> 루비의 MOP는 어린애 장난 수준으로 보이게 된다. - exception 개념의 메타 개념이라 할 수 있는 condition system
- continuation
=> On Lisp을 읽는다는 가정 하에 - 런타임과 컴파일타임의 구별이 없는 hot code deployment
- 코드와 데이터의 동일성과 매크로
=> Lisp만의 고유한 특성으로, 가장 살펴볼만한 가치가 있는 개념이라고 생각한다.
Lisp을 보고 나서 다른 언어를 살펴보게 되면 Lisp에서 나온 개념의 하위 개념을 다루고 있는 경우가 대부분이기 때문에 이해가 매우 쉽다고 할 수 있다.
Common Lisp을 살펴보고 싶다면 Common Lisp 가이드를 참고하기 바란다.
2008년 5월 6일 화요일
Weblocks 웹 프레임워크 가이드
4월 한 달 동안은 논산 훈련소에 다녀오느라 공부도, 포스팅도 전혀 하지 못했다. 덕분에 Weblocks 코드를 보면서 파악했던 것들도 많이 까먹은 것 같다. Weblocks는 현재 리습 유저로서 선택할 수 있는 거의 유일한 웹 프레임워크라고 생각된다. 함부로 말할 수는 없겠지만 아이디어도 깔끔하고 여러모로 Rails보다도 나은 면이 많은 것 같다. 다만 여타 오픈 소스 소프트웨어와 마찬가지로 처음 접하는 사람에게 도움을 줄 만한 문서가 부족하다. 도움이 될 만한 문서가 있다고 해도 토론 그룹에 흩어져 있는 경우가 많아서 찾기도 쉽지 않다. 직접 자세하게 가이드를 써 보면 좋겠지만 아직 그럴 내공도 안 되고, 그래서 Weblocks를 이해하는데 도움이 될 만한 글들을 한데 링크해보는 것으로 그치려고 한다.
공식 매뉴얼
view에 관한 introduction
언제나 그렇지만 뭔가를 익히기 위한 제일 좋은 방법은 예를 보는 것이다.
hello world example
A simple blog example
이외에도 다운받은 코드의 cl-weblocks/examples/ 디렉토리 아래에 있는 예들을 살펴보는 것도 꽤나 도움이 된다.
파일 업로드에 관한 스레드
Lisp for the Web - Weblocks와 직접 관련있는 글은 아니지만 Weblocks가 hunchentoot와 cl-who 라이브러리에 바탕을 두고 있기 때문에 저 둘에 관련된 아티클도 도움이 될 거라 생각한다.
Weblocks에서 새로운 타입을 정의하는 것에 관한 아티클
공식 매뉴얼
view에 관한 introduction
언제나 그렇지만 뭔가를 익히기 위한 제일 좋은 방법은 예를 보는 것이다.
hello world example
A simple blog example
이외에도 다운받은 코드의 cl-weblocks/examples/ 디렉토리 아래에 있는 예들을 살펴보는 것도 꽤나 도움이 된다.
파일 업로드에 관한 스레드
Lisp for the Web - Weblocks와 직접 관련있는 글은 아니지만 Weblocks가 hunchentoot와 cl-who 라이브러리에 바탕을 두고 있기 때문에 저 둘에 관련된 아티클도 도움이 될 거라 생각한다.
Weblocks에서 새로운 타입을 정의하는 것에 관한 아티클
2008년 3월 27일 목요일
적응형 소프트웨어로서의 웹 어플리케이션
다양한 브라우저에서 "동일하게 보이고 동일하게 동작하는" 웹 어플리케이션을 만들기란 쉽지 않다. 브라우저라는 환경이 너무나 다양한 탓이다. 다양한 환경을 다루는 솔루션은 단일한 환경을 다루는 솔루션에 비해 복잡해지기 마련이다.
같은 이유로 적응형 소프트웨어를 만드는 것도 어려운 일이다. 사실, "다양한 환경에서 제대로 기능하는 것"이 적응형 소프트웨어의 목표라고 할 때, 웹 어플리케이션은 브라우저라는 다양한 환경에서 제대로 동작하려고 애쓰는 적응형 소프트웨어라고도 할 수 있다.
여러 개의 솔루션을 종합해서 하나로 만든 솔루션은 복잡하기 때문에 유지보수가 어렵다. 다음 예를 보자.
이 코드는 인터넷 익스플로러와 오페라, 기타 브라우저에서 모두 똑같은 모양의 웹 페이지를 보여주기 위한 CSS 코드이다. 인터넷 익스플로러가 너비 값을 해석하는 방식의 차이 때문에 인터넷 익스플로러를 위한 너비값을 먼저 지정한 후, voice-family 속성을 사용해 인터넷 익스플로러가 선언이 끝난 것처럼 인식하게 하고, 그 후에 다른 브라우저를 위한 너비 값을 선언한 것이다. 하지만 오페라 브라우저도 인터넷 익스플로러처럼 voice-family 속성을 만나면 해석을 멈추기 때문에 아래 쪽에 오페라 브라우저만을 위해 추가적인 선언을 해 주었다. 이 코드는 서로 다른 브라우저 환경에서 동일한 모양을 보여준다는 목표를 달성하기 위해 일종의 CSS 트릭을 이용하고 있다. 이런 방식은 코드를 복잡하게 만들 뿐 아니라 브라우저들의 버전이 바뀌어 CSS를 해석하는 규칙이 변한다면 더 이상 유효하지 않게 된다. 하지만 CSS 기법을 담고 있는 많은 책들이 서로 다른 브라우저 문제를 해결하기 위해 이와 비슷한 트릭들에 의존하고 있다.
위 코드를 주석 없이 본다면 사실상 어떤 부분이 인터넷 익스플로러를 위한 부분이고 어떤 부분이 나머지 브라우저를 위한 부분인지, 맨 아래 오페라를 위해 삽입한 코드는 왜 들어가 있는건지, 알기가 어렵다. 하지만 각각의 CSS 코드를 분리해서 상황에 맞게 로드할 수 있다면 다음과 같이 될 것이다.
이 편이 코드를 읽기는 훨씬 쉽다. 따라서 환경에 대응하는 각각의 솔루션을 분리하는 것이 복잡도를 줄이는 방법이다. 하지만 S라는 솔루션을 Sa, Sb, ... Sz 으로 분리했을 경우, 요구사항이 변하거나 다른 해결 방법을 사용하고자 하여 Sa가 Sa'으로 변경되면 Sb, ... Sz 도 같이 변경해 주어야 한다는 번거로움이 생긴다.
따라서 이상적인 방법은 Sa와 나머지 솔루션 사이의 차이를 Vab, Vac, ... Vaz로 정의한 다음, Sa만을 변경해 나가고 나머지 솔루션은 Sa에 Vab ... Vaz를 적용해 자동으로 생성하는 것이다.
이와 같은 생각을 웹 어플리케이션에 적용해보자. 하나의 브라우저에 대해서만 CSS나 자바스크립트 코드를 작성한 후 브라우저 사이의 차이를 정의한 룰을 적용해서 다른 브라우저들에 적합한 CSS와 자바스크립트 코드를 생성해내는 것이 가능할 것이다. 일단 각 브라우저에 적합한 코드들을 만들어 냈다면, 리퀘스트의 정보를 살펴보고 해당 브라우저에 맞는 코드를 로드하게 만드는 것은 쉬운 일이다.
솔루션 사이의 차이를 어떻게 기술할 수 있을까? 필요한 것은 코드에서 "관심의 대상이 되는 부분"을 정의하고 그 부분에 "규칙에 의한 변화"를 가해서 다른 솔루션을 만들어내는 것이다. AOP의 pointcut과 advice가 의도는 다를지언정 이와 비슷한 역할을 한다고 할 수 있다. 따라서 솔루션 사이의 variation을 정의하기 위해, pointcut과 advice 같은 형식을 이용할 수 있다.
이와 같은 생각을 variation-applier라는 도구로 구현해보았다. 이 도구는 CSS 파일을 대상으로 한다. 사용 방법은 기본 솔루션에 해당하는 디렉토리와, variation 룰들(IE.var opera.var 등등)이 들어 있는 디렉토리, 솔루션들이 생성될 디렉토리를 지정하고 apply를 누르면, variation 룰 당 하나씩 새로운 솔루션이 생성된다.
variation rule은 pointcut과 advice의 개념을 사용했지만 최대한 CSS 문법과 비슷하게 기술하도록 하였다. 사용 예는 다음과 같다.
기본적으로 selector가 같을 때만 variation 규칙이 적용되지만 variation의 selector를 global로 선언한 경우에는 selector에 관계없이 모두 적용된다.
variation-applier는 Common Lisp으로 작성되었으며 weblocks 웹 프레임워크 위에서 실행된다. 실행을 위해서는 Common Lisp과 weblocks를 설치하고, 소스 코드의 build-and-test.lisp 파일을 SLIME으로 로드(ctrl+c ctrl+l)한 후, SLIME에서 (variation-applier:start-variation-applier)를 치면 된다. 브라우저의 주소창에 localhost:8080 을 쳐 넣으면 입력 화면이 나타나는 것을 볼 수 있다.
Blogger에는 파일을 첨부할 수가 없기에 티스토리 블로그에 소스 코드를 올려놓았다.
소스 코드 다운로드
같은 이유로 적응형 소프트웨어를 만드는 것도 어려운 일이다. 사실, "다양한 환경에서 제대로 기능하는 것"이 적응형 소프트웨어의 목표라고 할 때, 웹 어플리케이션은 브라우저라는 다양한 환경에서 제대로 동작하려고 애쓰는 적응형 소프트웨어라고도 할 수 있다.
여러 개의 솔루션을 종합해서 하나로 만든 솔루션은 복잡하기 때문에 유지보수가 어렵다. 다음 예를 보자.
#sidebar {
padding: 10px;
border: 5px solid black;
width: 230px; /* for Internet Explorer */
voice-family: “\“3\””;
voice-family: inherit;
width: 200px; /* real value */
}
html>body #sidebar {
width: 200px;
} /* for Opera */
이 코드는 인터넷 익스플로러와 오페라, 기타 브라우저에서 모두 똑같은 모양의 웹 페이지를 보여주기 위한 CSS 코드이다. 인터넷 익스플로러가 너비 값을 해석하는 방식의 차이 때문에 인터넷 익스플로러를 위한 너비값을 먼저 지정한 후, voice-family 속성을 사용해 인터넷 익스플로러가 선언이 끝난 것처럼 인식하게 하고, 그 후에 다른 브라우저를 위한 너비 값을 선언한 것이다. 하지만 오페라 브라우저도 인터넷 익스플로러처럼 voice-family 속성을 만나면 해석을 멈추기 때문에 아래 쪽에 오페라 브라우저만을 위해 추가적인 선언을 해 주었다. 이 코드는 서로 다른 브라우저 환경에서 동일한 모양을 보여준다는 목표를 달성하기 위해 일종의 CSS 트릭을 이용하고 있다. 이런 방식은 코드를 복잡하게 만들 뿐 아니라 브라우저들의 버전이 바뀌어 CSS를 해석하는 규칙이 변한다면 더 이상 유효하지 않게 된다. 하지만 CSS 기법을 담고 있는 많은 책들이 서로 다른 브라우저 문제를 해결하기 위해 이와 비슷한 트릭들에 의존하고 있다.
위 코드를 주석 없이 본다면 사실상 어떤 부분이 인터넷 익스플로러를 위한 부분이고 어떤 부분이 나머지 브라우저를 위한 부분인지, 맨 아래 오페라를 위해 삽입한 코드는 왜 들어가 있는건지, 알기가 어렵다. 하지만 각각의 CSS 코드를 분리해서 상황에 맞게 로드할 수 있다면 다음과 같이 될 것이다.
/* Internet Explorer */
#sidebar {
width: 230px;
padding: 10px;
border: 5px;
}
/* the others */
#sidebar {
width: 200px;
padding: 10px;
border: 5px;
}
이 편이 코드를 읽기는 훨씬 쉽다. 따라서 환경에 대응하는 각각의 솔루션을 분리하는 것이 복잡도를 줄이는 방법이다. 하지만 S라는 솔루션을 Sa, Sb, ... Sz 으로 분리했을 경우, 요구사항이 변하거나 다른 해결 방법을 사용하고자 하여 Sa가 Sa'으로 변경되면 Sb, ... Sz 도 같이 변경해 주어야 한다는 번거로움이 생긴다.
따라서 이상적인 방법은 Sa와 나머지 솔루션 사이의 차이를 Vab, Vac, ... Vaz로 정의한 다음, Sa만을 변경해 나가고 나머지 솔루션은 Sa에 Vab ... Vaz를 적용해 자동으로 생성하는 것이다.
이와 같은 생각을 웹 어플리케이션에 적용해보자. 하나의 브라우저에 대해서만 CSS나 자바스크립트 코드를 작성한 후 브라우저 사이의 차이를 정의한 룰을 적용해서 다른 브라우저들에 적합한 CSS와 자바스크립트 코드를 생성해내는 것이 가능할 것이다. 일단 각 브라우저에 적합한 코드들을 만들어 냈다면, 리퀘스트의 정보를 살펴보고 해당 브라우저에 맞는 코드를 로드하게 만드는 것은 쉬운 일이다.
솔루션 사이의 차이를 어떻게 기술할 수 있을까? 필요한 것은 코드에서 "관심의 대상이 되는 부분"을 정의하고 그 부분에 "규칙에 의한 변화"를 가해서 다른 솔루션을 만들어내는 것이다. AOP의 pointcut과 advice가 의도는 다를지언정 이와 비슷한 역할을 한다고 할 수 있다. 따라서 솔루션 사이의 variation을 정의하기 위해, pointcut과 advice 같은 형식을 이용할 수 있다.
이와 같은 생각을 variation-applier라는 도구로 구현해보았다. 이 도구는 CSS 파일을 대상으로 한다. 사용 방법은 기본 솔루션에 해당하는 디렉토리와, variation 룰들(IE.var opera.var 등등)이 들어 있는 디렉토리, 솔루션들이 생성될 디렉토리를 지정하고 apply를 누르면, variation 룰 당 하나씩 새로운 솔루션이 생성된다.
variation rule은 pointcut과 advice의 개념을 사용했지만 최대한 CSS 문법과 비슷하게 기술하도록 하였다. 사용 예는 다음과 같다.
/* base file */
#sidebar
{ width: 200px; margin: 0;}
case 1
/* var file */
#sidebar
{ width: ((calculate + 30px)); }
=>
/* result file */
#sidebar
{ width: 230px; margin: 0; }
case 2
/* var file */
#sidebar
{ width: ((before border 5px) (calculate * 1.1 + 10) (after padding 10px)); }
=>
/* result file */
#sidebar
{ border: 5px; width: 230px; padding: 10px; margin: 0;}
case 3
/* var file */
global
{ width: ((around border 0)) margin: ((delete)) }
=>
/* result file */
#sidebar
{ border: 0; }
기본적으로 selector가 같을 때만 variation 규칙이 적용되지만 variation의 selector를 global로 선언한 경우에는 selector에 관계없이 모두 적용된다.
variation-applier는 Common Lisp으로 작성되었으며 weblocks 웹 프레임워크 위에서 실행된다. 실행을 위해서는 Common Lisp과 weblocks를 설치하고, 소스 코드의 build-and-test.lisp 파일을 SLIME으로 로드(ctrl+c ctrl+l)한 후, SLIME에서 (variation-applier:start-variation-applier)를 치면 된다. 브라우저의 주소창에 localhost:8080 을 쳐 넣으면 입력 화면이 나타나는 것을 볼 수 있다.
Blogger에는 파일을 첨부할 수가 없기에 티스토리 블로그에 소스 코드를 올려놓았다.
소스 코드 다운로드
2008년 3월 22일 토요일
프로젝트 만들기
매번 패키지 설정을 하는 것이 귀찮아서 자동으로 폴더와 파일을 생성하는 함수를 짰다.
(make-project 'hello)
=>
./hello/
./hello/src/
./hello/test/
./hello/build-and-test.lisp
./hello/hello.asd
./hello/hello-test.asd
./hello/src/hello.lisp
./hello/test/hello-test.lisp
적당한 테스트와 소스 코드를 추가한 후 build-and-test.lisp 파일을 SLIME으로 로드(ctrl+c ctrl+l)하면 빌드 및 테스트가 이루어지고 결과가 표시된다.
아래 코드를 보면 짤린 것처럼 보이지만 긁어서 붙여보면 제대로 보인다; 후.. 블로거에서 코드 들여쓰기를 제대로 보이게 하려면 pre 태그를 쓰는 수밖에 없는데 이마저도 코드가 길어지면 짤려 보이니, 참 난감하다. 누구 블로거에서 코드 제대로 보이게 하는 방법 아시는 분 메일로 알려주시면 정말 감사하겠습니다. ^^;
(make-project 'hello)
=>
./hello/
./hello/src/
./hello/test/
./hello/build-and-test.lisp
./hello/hello.asd
./hello/hello-test.asd
./hello/src/hello.lisp
./hello/test/hello-test.lisp
적당한 테스트와 소스 코드를 추가한 후 build-and-test.lisp 파일을 SLIME으로 로드(ctrl+c ctrl+l)하면 빌드 및 테스트가 이루어지고 결과가 표시된다.
아래 코드를 보면 짤린 것처럼 보이지만 긁어서 붙여보면 제대로 보인다; 후.. 블로거에서 코드 들여쓰기를 제대로 보이게 하려면 pre 태그를 쓰는 수밖에 없는데 이마저도 코드가 길어지면 짤려 보이니, 참 난감하다. 누구 블로거에서 코드 제대로 보이게 하는 방법 아시는 분 메일로 알려주시면 정말 감사하겠습니다. ^^;
(defun make-project (project-name)
(let ((name-string (string-downcase (symbol-name project-name))))
(ensure-directories-exist (make-pathname :directory (list :relative name-string)))
(ensure-directories-exist (make-pathname :directory (list :realtive name-string "src")))
(ensure-directories-exist (make-pathname :directory (list :relative name-string "test")))
(with-open-file (build-and-test (make-pathname :directory (list :relative name-string)
:name "build-and-test"
:type "lisp")
:direction :output :if-exists nil)
(format build-and-test
"(push (make-pathname :directory (pathname-directory *load-truename*)) asdf:*central-registry*)~%(require '~A-test)~%(~A-test:~A-test)~%(format t ~A)~%(quit)"
name-string name-string name-string "\"~%\""))
(with-open-file (asd (make-pathname :directory (list :relative name-string)
:name name-string
:type "asd")
:direction :output :if-exists nil)
(format asd
";;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Base: 10 -*-~%~%(defpackage #:~A-asd~% (:use :cl :asdf))~%~%(in-package :~A-asd)~%~%(defsystem ~A~% :name \"~A\"~% :depends-on ()~% :components ((:module src :components ((:file \"~A\")))))"
name-string name-string name-string name-string name-string))
(with-open-file (test-asd (make-pathname :directory (list :relative name-string)
:name (concatenate 'string name-string "-test")
:type "asd")
:direction :output :if-exists nil)
(format test-asd
";;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Base: 10 -*-~%~%(defpackage #:~A-test-asd~% (:use :cl :asdf))~%~%(in-package :~A-test-asd)~%~%(defsystem ~A-test~% :name \"~A-test\"~% :depends-on (\"~A\" :lisp-unit)~% :components ((:module test :components ((:file \"~A-test\")))))"
name-string name-string name-string name-string name-string name-string))
(with-open-file (main (make-pathname :directory (list :relative name-string "src")
:name name-string
:type "lisp")
:direction :output :if-exists nil)
(format main
"(defpackage #:~A~% (:use :cl))"
name-string))
(with-open-file (test-main (make-pathname :directory (list :relative name-string "test")
:name (concatenate 'string name-string "-test")
:type "lisp")
:direction :output :if-exists nil)
(format test-main
"(defpackage #:~A-test~% (:use :cl :~A :lisp-unit)~% (:export #:~A-test))~%~%(in-package :~A-test)~%~%(defun ~A-test ()~% (run-all-tests :~A-test))"
name-string name-string name-string name-string name-string name-string))))
2008년 3월 10일 월요일
MacPorts 사용법
MacPorts는 DarwinPorts의 새 이름으로 리눅스의 apt-get과 비슷하게 각종 소프트웨어의 설치를 쉽게 해 준다. MacPorts 홈페이지에서 dmg 파일을 받아 설치하면 되는데, 설치 후 port 명령이 매뉴얼대로 되지 않는다면, 경로 설정이 안 되어 있어서 그런 것이다. 홈디렉토리(~)에 .profile 파일을 만들어서 다음과 같이 경로를 추가한다.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
'port search 프로그램이름'(e.x. port search buildbot)과 같이 하면 port를 통해 설치할 수 있는 프로그램들을 찾아볼 수 있다. 원하는 프로그램 이름을 찾으면 'sudo port install buildbot'과 같이 인스톨하면 된다.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
'port search 프로그램이름'(e.x. port search buildbot)과 같이 하면 port를 통해 설치할 수 있는 프로그램들을 찾아볼 수 있다. 원하는 프로그램 이름을 찾으면 'sudo port install buildbot'과 같이 인스톨하면 된다.
Common Lisp 가이드
사실 리습을 처음 공부하려면 막막하다. 어떤 책으로 시작해야 할지, 수 많은 구현 중에 어떤 구현을 사용해야 할지, 쓸만한 라이브러리나 웹 프레임워크는 어떤 게 있는지.. 알기가 어렵다. 국내에 도움을 얻을 만한 책도, 활발한 커뮤니티도 없다. 그래서 내 경험을 바탕으로, 매우 주관적인 가이드를 써 보고자 한다.
1. 구현(Implementation)
리습은 구현이 여러 개다. 언어 자체를 규정하는 Common Lisp ANSI specification이 있고, 그 specification에 맞게 누구나 커먼 리습을 구현할 수 있다. 많은 구현 중에 SBCL을 사용할 것을 추천한다. 오픈 소스이고, 빠르고, 멀티 스레드를 지원한다. 오픈 소스 중 그 다음으로 추천할만한 구현은 OpenMCL(현재는 Clozure CL로 이름을 바꿨다)정도이다.
2. 설치
리눅스, 맥, 윈도우즈 사용자인데 간편한 설치를 원한다면:
LispBox를 다운받아 설치하는 것이 간편한 방법이다. 윈도우즈 사용자일 경우 Clisp 버전을, 리눅스나 맥 사용자일 경우는 SBCL 버전을 다운받는 것을 추천한다. Clisp은 멀티 스레드를 지원하지 않기 때문에 웹 개발 같은 데 사용하기는 어렵지만, 학습 용도로는 아무 문제가 없다.
맥, 윈도우즈 사용자인데 IDE를 사용해 보고 싶다면:
Lispworks Personal Edition이라는 상용 IDE를 몇 가지 제약과 함께 무료로 사용할 수 있다.
맥 사용자인데 간편한 설치와 좀 더 맥 친화적인 환경을 원한다면:
ReadyLisp이 제격이다.
리눅스나 맥 사용자인데 일일이 직접 설치하기를 원한다면:
리습 작업환경은 사실 Emacs + 리습 구현 + SLIME 이라는 세 가지를 설치한 후 연동해 주는 것이다. Emacs와 리습 구현 자체는 apt-get이나 MacPorts를 통해 쉽게 설치할 수 있을 것이고, SLIME은 내려받아 압축을 푼 뒤 별도의 설치 없이 연동만 하면 된다. 설치방법은 리눅스나 맥이나 거의 동일하다. 다음 글들을 참조하면 된다.
http://onlisp.blogspot.com/2007/12/common-lisp-emacs_12.html
http://onlisp.blogspot.com/2008/01/sbcl-thread.html
3. 에디터
Emacs. 사실 vi나 이클립스를 사용하는 방법도 존재하긴 하지만, 리습의 에디터로는 Emacs가 거의 절대적이라고 생각해도 무방하다.
4. 책
속성으로 아주 기본적인 내용만 빠르게 흝고 싶다면:
http://onlisp.blogspot.com/2007/12/2-ansi-common-lisp.html
http://www.cs.gmu.edu/~sean/lisp/LispTutorial.html
http://psg.com/~dlamkins/sl/chapter03.html
사실 위의 내용만 봐서는 리습을 다른 언어와 차별화하는 특성이 어떤 것인지 알기 어렵다. 리습을 제대로 공부해 보고 싶다면 다음의 책들을 추천한다:
ANSI Common Lisp - Paul Graham
간명하고 재미있게 씌어진 책이다. 다만 온라인에 공개되어 있지 않다는 단점이 있다. 구할 수만 있다면 시작하기에 제일 좋은 책이긴 하다. 일부 챕터의 번역이 인터넷에 올라와 있다.
Chapter 1~4
http://xeraph.com/ => Article/프로그래밍 언어
Chapter 2, 10
http://onlisp.blogspot.com/2007/12/2-ansi-common-lisp.html
http://onlisp.blogspot.com/2007/12/10-ansi-common-lisp.html
Practical Common Lisp
매우 친절하고 자세하게 기술되어 있는 책이다. 온라인에 모두 공개되어 있다는 점도 좋다. 현 시점에서는 가장 추천할만한 책이 아닌가 생각된다. 다만, 저자가 뭐든지 늘여쓰는 경향이 있고, 책 분량이 꽤 되기 때문에 보다가 포기할 가능성도 있다.
Successful Lisp
역시 온라인에서 모두 볼 수 있다. 내용이 그리 많지 않아서 금방금방 볼 수 있고, 유용한 팁들도 꽤 있다.
On Lisp
리습이 가진 최고의 장점이라고 할 수 있는 매크로의 모든 것을 다룬 책이다. 링크한 홈페이지에서 무료로 다운받을 수 있다. 리습에 관한 기본적인 내용을 어느 정도 익혔다고 생각될 때 보는 게 좋다.
5. 커뮤니티
공부하다가 모르는 것에 대해 질문을 해야 할 필요가 있다면 구글 그룹이 좋다. Planet Lisp이라는 곳에서 리습에 관련된 글과 뉴스들을 볼 수 있다.
6. 라이브러리
대부분의 리습 라이브러리들은 Cliki라는 곳에서 찾아볼 수 있다. 다음 라이브러리들을 추천한다.
라이브러리들의 쉬운 설치를 위해: asdf
C와 C++ 라이브러리들을 가져다 쓰려면: cffi
테스팅 프레임워크: lisp-unit
웹 프레임워크: weblocks
웹 서버: hunchentoot
Database: CLSQL
정규식: cl-ppcre
7. 커먼 리습 레퍼런스
언어 자체에 대한 레퍼런스를 보고자 한다면 Common Lisp HyperSpec이 좋다(Emacs에서 slime이 로드된 상태일 때 코드 위에서 ctrl+c ctrl+d h 를 누르면 바로 해당 HyperSpec 페이지로 이동한다). 또는 CLTL2를 참고해도 좋다.
1. 구현(Implementation)
리습은 구현이 여러 개다. 언어 자체를 규정하는 Common Lisp ANSI specification이 있고, 그 specification에 맞게 누구나 커먼 리습을 구현할 수 있다. 많은 구현 중에 SBCL을 사용할 것을 추천한다. 오픈 소스이고, 빠르고, 멀티 스레드를 지원한다. 오픈 소스 중 그 다음으로 추천할만한 구현은 OpenMCL(현재는 Clozure CL로 이름을 바꿨다)정도이다.
2. 설치
리눅스, 맥, 윈도우즈 사용자인데 간편한 설치를 원한다면:
LispBox를 다운받아 설치하는 것이 간편한 방법이다. 윈도우즈 사용자일 경우 Clisp 버전을, 리눅스나 맥 사용자일 경우는 SBCL 버전을 다운받는 것을 추천한다. Clisp은 멀티 스레드를 지원하지 않기 때문에 웹 개발 같은 데 사용하기는 어렵지만, 학습 용도로는 아무 문제가 없다.
맥, 윈도우즈 사용자인데 IDE를 사용해 보고 싶다면:
Lispworks Personal Edition이라는 상용 IDE를 몇 가지 제약과 함께 무료로 사용할 수 있다.
맥 사용자인데 간편한 설치와 좀 더 맥 친화적인 환경을 원한다면:
ReadyLisp이 제격이다.
리눅스나 맥 사용자인데 일일이 직접 설치하기를 원한다면:
리습 작업환경은 사실 Emacs + 리습 구현 + SLIME 이라는 세 가지를 설치한 후 연동해 주는 것이다. Emacs와 리습 구현 자체는 apt-get이나 MacPorts를 통해 쉽게 설치할 수 있을 것이고, SLIME은 내려받아 압축을 푼 뒤 별도의 설치 없이 연동만 하면 된다. 설치방법은 리눅스나 맥이나 거의 동일하다. 다음 글들을 참조하면 된다.
http://onlisp.blogspot.com/2007/12/common-lisp-emacs_12.html
http://onlisp.blogspot.com/2008/01/sbcl-thread.html
3. 에디터
Emacs. 사실 vi나 이클립스를 사용하는 방법도 존재하긴 하지만, 리습의 에디터로는 Emacs가 거의 절대적이라고 생각해도 무방하다.
4. 책
속성으로 아주 기본적인 내용만 빠르게 흝고 싶다면:
http://onlisp.blogspot.com/2007/12/2-ansi-common-lisp.html
http://www.cs.gmu.edu/~sean/lisp/LispTutorial.html
http://psg.com/~dlamkins/sl/chapter03.html
사실 위의 내용만 봐서는 리습을 다른 언어와 차별화하는 특성이 어떤 것인지 알기 어렵다. 리습을 제대로 공부해 보고 싶다면 다음의 책들을 추천한다:
ANSI Common Lisp - Paul Graham
간명하고 재미있게 씌어진 책이다. 다만 온라인에 공개되어 있지 않다는 단점이 있다. 구할 수만 있다면 시작하기에 제일 좋은 책이긴 하다. 일부 챕터의 번역이 인터넷에 올라와 있다.
Chapter 1~4
http://xeraph.com/ => Article/프로그래밍 언어
Chapter 2, 10
http://onlisp.blogspot.com/2007/12/2-ansi-common-lisp.html
http://onlisp.blogspot.com/2007/12/10-ansi-common-lisp.html
Practical Common Lisp
매우 친절하고 자세하게 기술되어 있는 책이다. 온라인에 모두 공개되어 있다는 점도 좋다. 현 시점에서는 가장 추천할만한 책이 아닌가 생각된다. 다만, 저자가 뭐든지 늘여쓰는 경향이 있고, 책 분량이 꽤 되기 때문에 보다가 포기할 가능성도 있다.
Successful Lisp
역시 온라인에서 모두 볼 수 있다. 내용이 그리 많지 않아서 금방금방 볼 수 있고, 유용한 팁들도 꽤 있다.
On Lisp
리습이 가진 최고의 장점이라고 할 수 있는 매크로의 모든 것을 다룬 책이다. 링크한 홈페이지에서 무료로 다운받을 수 있다. 리습에 관한 기본적인 내용을 어느 정도 익혔다고 생각될 때 보는 게 좋다.
5. 커뮤니티
공부하다가 모르는 것에 대해 질문을 해야 할 필요가 있다면 구글 그룹이 좋다. Planet Lisp이라는 곳에서 리습에 관련된 글과 뉴스들을 볼 수 있다.
6. 라이브러리
대부분의 리습 라이브러리들은 Cliki라는 곳에서 찾아볼 수 있다. 다음 라이브러리들을 추천한다.
라이브러리들의 쉬운 설치를 위해: asdf
C와 C++ 라이브러리들을 가져다 쓰려면: cffi
테스팅 프레임워크: lisp-unit
웹 프레임워크: weblocks
웹 서버: hunchentoot
Database: CLSQL
정규식: cl-ppcre
7. 커먼 리습 레퍼런스
언어 자체에 대한 레퍼런스를 보고자 한다면 Common Lisp HyperSpec이 좋다(Emacs에서 slime이 로드된 상태일 때 코드 위에서 ctrl+c ctrl+d h 를 누르면 바로 해당 HyperSpec 페이지로 이동한다). 또는 CLTL2를 참고해도 좋다.
유용한 SLIME 명령어들
사실 코드를 읽다가 repl로 돌아가야 할 경우가 많은데, 그럴 때마다 ctrl+x b로 버퍼를 전환하는 건 여간 귀찮은 일이 아니다. 그럴 경우에 slime repl로 돌아가려면:
ctrl+c ctrl+z
slime을 종료하고 재시동 해야 할 때가 있다. slime 종료는:
, quit
lisp 코드를 읽다가 특정 리습 심볼에 대한 common lisp hyperspec을 보고 싶다면:
ctrl+c ctrl+d h
프로그램을 읽는데, 함수나 변수의 정의된 부분을 살펴보고 싶다면:
meta+.
(meta는 보통 alt. 단 해당 정의부분이 탑레벨에 로드되어 있어야 한다. 예를 들어 define-test 라는 매크로의 정의가 lisp-unit 이라는 라이브러리에 되어 있다면 해당 매크로의 정의를 보기 위해서는 (asdf:operate asdf:load-op 'lisp-unit)과 같이 해당 라이브러리가 로드되어 있어야 한다.)
정의부를 살펴보고 다시 원래 코드로 되돌아가려면:
meta+,
(meta+. 의 반대라고 할 수 있다.)
함수 하나를 컴파일하려면:
커서가 함수 위에 있을 때 ctrl+c ctrl+c
파일을 로드하려면:
로드하려는 파일의 버퍼에서 ctrl+c ctrl+l
파일을 컴파일하고 로드하려면:
컴파일하려는 파일의 버퍼에서 ctrl+c ctrl+k
repl에서 약간의 오타 때문에 거의 똑같은 표현식을 다시 치는 것은 귀찮은 일이다. 입력했던 표현식들을 거꾸로 탐색하려면:
meta+p
반대는:
meta+n
슬라임 쪽 버퍼에 있을 때는 tab만 눌러도 자동완성이 되지만 코드 쪽 버퍼에 있을 때는 meta+tab 이 자동완성.
함수의 caller들을 보고 싶다면:
ctrl+c <
함수의 callee들을 보고 싶다면:
ctrl+c >
슬라임 명령어는 아니고 Emacs 명령어지만 적어본다.
Undo:
ctrl+_
Redo:
ctrl+x z
ctrl+c ctrl+z
slime을 종료하고 재시동 해야 할 때가 있다. slime 종료는:
, quit
lisp 코드를 읽다가 특정 리습 심볼에 대한 common lisp hyperspec을 보고 싶다면:
ctrl+c ctrl+d h
프로그램을 읽는데, 함수나 변수의 정의된 부분을 살펴보고 싶다면:
meta+.
(meta는 보통 alt. 단 해당 정의부분이 탑레벨에 로드되어 있어야 한다. 예를 들어 define-test 라는 매크로의 정의가 lisp-unit 이라는 라이브러리에 되어 있다면 해당 매크로의 정의를 보기 위해서는 (asdf:operate asdf:load-op 'lisp-unit)과 같이 해당 라이브러리가 로드되어 있어야 한다.)
정의부를 살펴보고 다시 원래 코드로 되돌아가려면:
meta+,
(meta+. 의 반대라고 할 수 있다.)
함수 하나를 컴파일하려면:
커서가 함수 위에 있을 때 ctrl+c ctrl+c
파일을 로드하려면:
로드하려는 파일의 버퍼에서 ctrl+c ctrl+l
파일을 컴파일하고 로드하려면:
컴파일하려는 파일의 버퍼에서 ctrl+c ctrl+k
repl에서 약간의 오타 때문에 거의 똑같은 표현식을 다시 치는 것은 귀찮은 일이다. 입력했던 표현식들을 거꾸로 탐색하려면:
meta+p
반대는:
meta+n
슬라임 쪽 버퍼에 있을 때는 tab만 눌러도 자동완성이 되지만 코드 쪽 버퍼에 있을 때는 meta+tab 이 자동완성.
함수의 caller들을 보고 싶다면:
ctrl+c <
함수의 callee들을 보고 싶다면:
ctrl+c >
슬라임 명령어는 아니고 Emacs 명령어지만 적어본다.
Undo:
ctrl+_
Redo:
ctrl+x z
2008년 2월 10일 일요일
VMware, Parallels, 그리고 Ubuntu 7.10
VMware와 Parallels trial 버전을 각각 깔아서 시험해본 결과를 적어봅니다.
외장하드를 연결했을 때 Parallels 같은 경우에는 윈도우에도, 맥에도 양쪽 다 제대로 마운트가 안 되는데 비해, VMware에서는 잘 됩니다.
저는 맥에서 네스팟을 쓰는데 Parallels로 윈도우를 시동시키면 인터넷이 안 되네요.
VMware에는 Ubuntu 7.10이 깔리는데 비해 Parallels에는 안 깔립니다. VMware 문서에 보면 Ubuntu 6.10까지만 지원한다고 되어 있어서 7.10이 깔릴지 반신반의 했었는데 깔리더군요. 주의할 점 몇 가지만 적어보면,
Ubuntu 설치할 때 인터넷이 연결된 상태로 하는 게 좋습니다. 그래야 한글 설정 같은 것이 자동으로 잡힙니다. 제가 가진 라이브시디가 초기 버전이라 그런지도 모르지만..
설치가 끝나고 정상적으로 리붓이 되질 않고 멈춰버리는데, VMware에서 강제적으로 리붓시키면 됩니다.
리붓 후 VMware 툴을 설치해야 합니다. Virtual Machine -> Install VMware Tools 를 선택하면 cd-rom 아래에 tar.gz 파일이 보입니다. 아무데로나 복사해서 압축을 풀고(tar -xvzf 파일이름) doc 아래의 Install 문서대로 따라하면 됩니다. 설치는 수퍼유저로 해야 한다고 나와 있는데, Ubuntu를 처음 깔면 root user 패스워드는 설정이 안 되어 있기 때문에 su가 안 먹힙니다. 그 때는 sudo passwd root 로 root user 패스워드를 설정해 주면 됩니다.
처음엔 네이티브에 비해 엄청 느려서 쓸 수가 없다고 생각했는데, VMware 툴을 설치한 후 리붓하니 그래도 적당한 속도가 나오는 것 같습니다. 쓸만하네요.
둘 중 하나를 구입할 생각이었는데 지금으로서는 VMware쪽으로 마음이 기우는 듯 합니다.
외장하드를 연결했을 때 Parallels 같은 경우에는 윈도우에도, 맥에도 양쪽 다 제대로 마운트가 안 되는데 비해, VMware에서는 잘 됩니다.
저는 맥에서 네스팟을 쓰는데 Parallels로 윈도우를 시동시키면 인터넷이 안 되네요.
VMware에는 Ubuntu 7.10이 깔리는데 비해 Parallels에는 안 깔립니다. VMware 문서에 보면 Ubuntu 6.10까지만 지원한다고 되어 있어서 7.10이 깔릴지 반신반의 했었는데 깔리더군요. 주의할 점 몇 가지만 적어보면,
Ubuntu 설치할 때 인터넷이 연결된 상태로 하는 게 좋습니다. 그래야 한글 설정 같은 것이 자동으로 잡힙니다. 제가 가진 라이브시디가 초기 버전이라 그런지도 모르지만..
설치가 끝나고 정상적으로 리붓이 되질 않고 멈춰버리는데, VMware에서 강제적으로 리붓시키면 됩니다.
리붓 후 VMware 툴을 설치해야 합니다. Virtual Machine -> Install VMware Tools 를 선택하면 cd-rom 아래에 tar.gz 파일이 보입니다. 아무데로나 복사해서 압축을 풀고(tar -xvzf 파일이름) doc 아래의 Install 문서대로 따라하면 됩니다. 설치는 수퍼유저로 해야 한다고 나와 있는데, Ubuntu를 처음 깔면 root user 패스워드는 설정이 안 되어 있기 때문에 su가 안 먹힙니다. 그 때는 sudo passwd root 로 root user 패스워드를 설정해 주면 됩니다.
처음엔 네이티브에 비해 엄청 느려서 쓸 수가 없다고 생각했는데, VMware 툴을 설치한 후 리붓하니 그래도 적당한 속도가 나오는 것 같습니다. 쓸만하네요.
둘 중 하나를 구입할 생각이었는데 지금으로서는 VMware쪽으로 마음이 기우는 듯 합니다.
2008년 2월 5일 화요일
Buildbot과 Subversion으로 빌드와 테스트 자동화하기 2 - Lisp 프로그램의 빌드와 테스트
쉘에서 명령어 하나로 빌드와 테스트를 다 할 수 있다면 Buildbot을 이용해서 빌드와 테스트를 자동화하는 것은 매우 쉬울 것이다. 내 경우에는 build-and-test.lisp 파일에 빌드와 테스트 과정을 저장하고 쉘에서 다음과 같은 명령어로 빌드와 테스트를 수행하였다.
> sbcl --load build-and-test.lisp
build-and-test 파일의 내용은 대체로 다음과 같이 구성될 수 있을 것이다.
사실 asdf를 이용해서 시스템을 구성하고 컴파일하는 것에 대해서는 설명이 조금 길어질 수 있다. 하지만 언제나 예를 보는 것이 가장 쉽기 때문에 내 예를 보이도록 하겠다. SBCL과 lisp-unit을 사용한 예제이다.
내 디렉토리 구조가 다음과 같다고 할 때,
paip> find . -not -iname "*.fasl" -and -not -iname "*~"
.
./build-and-test.lisp
./paip-test.asd
./paip.asd
./src
./src/chapter-1.lisp
./src/chapter-2.lisp
./src/paip.lisp
./test
./test/chapter-1.lisp
./test/chapter-2.lisp
./test/paip-test.lisp
각각의 파일 내용은 다음과 같다.
paip.asd
paip-test.asd
src/paip.lisp
src/chapter-1.lisp
src/chapter-2.lisp
test/paip-test.lisp
test/chapter-1.lisp
test/chater-2.lisp
build-and-test.lisp
몇 가지 주의할 점을 얘기해보면,
1. 파일과 디렉토리 사이의 의존 관계를 :depends-on 으로 명확히 표시해 주어야 한다. 그저 의존 순서에 따라 순차적으로 적게되면 때때로 패키지 에러가 발생할 수 있다.
2. 파일이 로드되는 순간에 현재 디렉토리를 알아내서 asdf:*central-registry*에 동적으로 추가할 수 있어야 한다. 그래야 체크아웃하는 디렉토리가 어디인지에 영향을 받지 않고 빌드를 수행할 수 있다. 위의 예대로 하면 되지만, 동적으로 디렉토리와 패스를 알아내는 것에 관심이 있다면 이 포스트를 참조하면 좋다.
> sbcl --load build-and-test.lisp
build-and-test 파일의 내용은 대체로 다음과 같이 구성될 수 있을 것이다.
; 이 파일이 로드될 시점의 디렉토리를 asdf:*central-registry*에 동적으로 추가
(push (make-pathname :directory (pathname-directory *load-truename*))
asdf:*central-registry*)
; 어플리케이션과 테스트를 빌드
(require 'application)
(require 'application-test)
; 테스트를 수행
(application-test:run-all-tests)
; Buildbot이 빌드와 테스트가 성공한 것으로 인식하도록 sbcl을 정상 종료
(quit)
사실 asdf를 이용해서 시스템을 구성하고 컴파일하는 것에 대해서는 설명이 조금 길어질 수 있다. 하지만 언제나 예를 보는 것이 가장 쉽기 때문에 내 예를 보이도록 하겠다. SBCL과 lisp-unit을 사용한 예제이다.
내 디렉토리 구조가 다음과 같다고 할 때,
paip> find . -not -iname "*.fasl" -and -not -iname "*~"
.
./build-and-test.lisp
./paip-test.asd
./paip.asd
./src
./src/chapter-1.lisp
./src/chapter-2.lisp
./src/paip.lisp
./test
./test/chapter-1.lisp
./test/chapter-2.lisp
./test/paip-test.lisp
각각의 파일 내용은 다음과 같다.
paip.asd
;;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Base: 10 -*-
(defpackage #:paip-asd
(:use :cl :asdf))
(in-package :paip-asd)
(defsystem paip
:name "paip"
:components ((:module src
:components ((:file "paip")
(:file "chapter-1"
:depends-on ("paip"))
(:file "chapter-2"
:depends-on ("paip"))))))
paip-test.asd
;;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Base: 10 -*-
(defpackage #:paip-test-asd
(:use :cl :asdf))
(in-package :paip-test-asd)
(defsystem paip-test
:name "paip-test"
:depends-on ("paip" :lisp-unit)
:components ((:module test
:components ((:file "paip-test")
(:file "chapter-1"
:depends-on ("paip-test"))
(:file "chapter-2"
:depends-on ("paip-test"))))))
src/paip.lisp
(defpackage #:paip
(:use :cl)
(:documentation
"Exercises of Paradigms of Artificial Intelligence Programming"))
src/chapter-1.lisp
(in-package :paip)
(export '(power count-atoms))
; 1.2
(defun power (base exp)
(if (= exp 0)
1
(do ((result 1 (* result base))
(exp exp (- exp 1)))
((= exp 0) result))))
; 1.3
(defun count-atoms (expression)
(if (null expression)
0
(if (atom expression)
1
(+ (count-atoms (first expression)) (count-atoms (rest expression))))))
src/chapter-2.lisp
(in-package :paip)
(export '(rule-lhs rule-rhs rewrites))
(defun rule-lhs (rule)
"The left-hand side of a rule."
(first rule))
(defun rule-rhs (rule)
"The right-hand side of a rule."
(rest (rest rule)))
(defun rewrites (category grammar)
"Return a list of the possible rewrites for this category."
(rule-rhs (assoc category grammar)))
test/paip-test.lisp
(defpackage #:paip-test
(:use :cl :paip :lisp-unit)
(:export #:paip-test))
(in-package :paip-test)
(defun paip-test ()
(run-all-tests :paip-test))
test/chapter-1.lisp
(in-package :paip-test)
; 1.2
(define-test power
(assert-equal 1 (power 2 0))
(assert-equal 4 (power 2 2))
(assert-equal 1024 (power 2 10)))
; 1.3
(define-test count-atoms
(assert-equal 0 (count-atoms nil))
(assert-equal 1 (count-atoms 'a))
(assert-equal 3 (count-atoms '(1 2 3)))
(assert-equal 5 (count-atoms '((1) 2 (3 (4) 5)))))
test/chater-2.lisp
(in-package :paip-test)
(define-test rule-lhs
(assert-equal (rule-lhs '(noun -> man ball woman)) 'noun))
(define-test rule-rhs
(assert-equal (rule-rhs '(noun -> man ball woman)) '(man ball woman)))
(defmacro with-simple-grammar (&body body)
`(let ((simple-grammar '((sentence -> (noun-phrase verb-phrase))
(noun-phrase -> (article noun))
(verb-phrase -> (verb noun-phrase))
(article -> the a)
(noun -> man ball woman table)
(verb -> hit took saw liked))))
,@body))
(define-test rewrites
(with-simple-grammar
(assert-equal '(man ball woman table) (rewrites 'noun simple-grammar))
(assert-equal '((article noun)) (rewrites 'noun-phrase simple-grammar))))
build-and-test.lisp
(push (make-pathname :directory (pathname-directory *load-truename*))
asdf:*central-registry*)
(require 'paip-test)
(paip-test:paip-test)
(format t "~%")
(quit)
몇 가지 주의할 점을 얘기해보면,
1. 파일과 디렉토리 사이의 의존 관계를 :depends-on 으로 명확히 표시해 주어야 한다. 그저 의존 순서에 따라 순차적으로 적게되면 때때로 패키지 에러가 발생할 수 있다.
2. 파일이 로드되는 순간에 현재 디렉토리를 알아내서 asdf:*central-registry*에 동적으로 추가할 수 있어야 한다. 그래야 체크아웃하는 디렉토리가 어디인지에 영향을 받지 않고 빌드를 수행할 수 있다. 위의 예대로 하면 되지만, 동적으로 디렉토리와 패스를 알아내는 것에 관심이 있다면 이 포스트를 참조하면 좋다.
Buildbot과 Subversion으로 빌드와 테스트 자동화하기
글을 두 개로 나눠서 적는 것이 좋겠다. 일단 여기서는 Subversion과 Buildbot을 어떻게 설치하고 사용하는지 설명한다. 두번째 글에서는 Lisp 코드의 컴파일과 테스트를 ASDF와 Buildbot을 이용해서 어떻게 자동화하는지 설명하겠다.
I. 기본 개념
'단위 테스트, 버전 관리, 빌드와 테스트 자동화' 이 세 가지는 꼭 수행해야 하는 실행지침으로 꼽힌다. 이 글에서는 버전 관리를 위해서 Subversion을 사용하고, 빌드와 테스트 자동화를 위해서 Buildbot을 사용한다고 가정한다.
Subversion은 CVS와 같은 버전 관리 툴이고, CVS의 단점을 보완하기 위해서 개발되었다고 한다. 현재는 가장 널리 쓰이고 있지만, darcs라는 툴로 많은 사람이 넘어가고 있는 것 같기도 하다. (같은 일을 할 때 darcs가 Subversion보다 손이 덜 간다고 한다. darcs는 패치 등에 대한 이론적 기반을 가지고 만들어진 같고, 가장 radical한 언어 중 하나라고 평가되는 Haskell로 짜여졌다.)
Buildbot은 Python으로 작성된, 빌드와 테스트를 자동화하기 위한 도구이다. 버전 관리 도구의 저장소를 감시하고 있다가 저장소에 변화가 생기면 코드를 체크아웃해와서 빌드와 테스트를 수행하고, 그 결과를 웹이나 이메일로 보여준다. Buildbot의 구조적인 장점은 build master와 build slave가 분리되어 있어서, 서로 다른 플랫폼에서 수행되는 빌드들을 관리하기가 용이하다는 것이다. build master는 각각의 build slave들이 어떻게 build를 수행하고 그 결과를 보고해야 할지에 대한 모든 정보를 가지고 있다. 실제로 빌드를 수행하는 build slave들은 build master에 접속해서 build master가 지시하는대로 할 뿐이다. build master와 build slave는 서로 다른 머신에 위치해 있어도 상관이 없기 때문에, 예를 들어 서로 다른 빌드를 수행하는 머신 1,2,3을 머신 4에서 총괄하는 것이 가능하다.
II. 설치
환경이 리눅스라면,
sudo apt-get install subversion
sudo apt-get install buildbot
환경이 맥이라면,
MacPorts를 이용해서 설치하면 된다. MacPorts는 DarwinPorts의 새 이름으로 리눅스의 apt-get과 비슷하게 각종 소프트웨어의 설치를 쉽게 해 준다. MacPorts 홈페이지에서 dmg 파일을 받아 설치하면 되는데, 설치 후 port 명령이 매뉴얼대로 되지 않는다면, 경로 설정이 안 되어 있어서 그런 것이다. 홈디렉토리(~)에 .profile 파일을 만들어서 다음과 같이 경로를 추가한다.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
'port search 프로그램이름'(e.x. port search buildbot)과 같이 하면 port를 통해 설치할 수 있는 프로그램들을 찾아볼 수 있다. 원하는 프로그램 이름을 찾으면 'sudo port install buildbot'과 같이 인스톨하면 된다.
환경이 윈도우라면,
이 경우는 해보질 않아서 모르겠다. 설치는 각각의 홈페이지를 참조해서 어떻게든 알아서;
III. 사용법
Subversion
저장소를 로컬의 /Users/peter/svn-repos 에 만든다고 할 때 각종 명령의 예는 다음과 같다. 로컬이 아니고 웹인 경우에는 'file://'부분을 'http://'로 바꾸면 된다.
새로운 저장소 만들기
svnadmin create /Users/peter/svn-repos
저장소에 프로젝트 만들기(기존 소스 코드를 저장소 안의 한 디렉토리로 임포트하는 경우)
app> svn import -m "application initial import" file:///Users/peter/svn-repos/app
이 경우는 저장소 아래에 app 디렉토리를 만들고 현재 디렉토리 아래의 모든 디렉토리와 파일들을 집어넣은 것이다. 하지만 저장소의 디렉토리를 살펴봐도 app 디렉토리는 눈에 보이지 않는다. 저장소에 저장된 프로젝트의 디렉토리 위치를 보고 싶다면 어떻게 해야 할까?
1. 체크아웃 해 온 작업본 디렉토리에서 svn info 또는,
2. 아무 곳에서나 svnlook tree /Users/peter/svn-repos
저장소로부터 파일 체크아웃하기
svn co file:///Users/peter/svn-repos/app app
작업본 디렉토리의 상태 알아보기
svn status
파일 앞의 M 표시는 그 파일이 변경되었다는 것을, ? 표시는 그 파일이 버전 관리 하에 놓여있지 않다는 것을 나타낸다. ? 표시된 파일을 버전 관리 대상으로 추가하기 위해서는 svn add를 사용
작업본 디렉토리의 변경을 저장소에 저장
app> svn commit -m "message"
리비전 내역 전체를 보려면
app> svn log
작업본 디렉토리의 내용을 최근 저장소의 리비전으로 갱신하려면
svn update
작업본 디렉토리에서 수행한 변경을 체크아웃 해 온 시점으로 되돌리려면
svn revert .
리비전 10과 리비전 11 사이의 변경 내역을 보고 싶다면
app> svn diff -r 10:11
작업본 디렉토리의 리비전이 11인데 리비전 9로 되돌리고 싶다면
app> svn merge -r 11:9
기타 알아두면 좋은 것
바이너리 파일이나, 백업 파일들은 저장소에 저장될 필요가 없다. Subversion이 이런 파일들을 무시하게 만들기 위해서는 ~/.subversion/config 파일의 global-ignores 부분을 수정하면 된다. 예를 들어, *.fasl 파일들과 *~ 파일들을 무시하고 싶다면 다음과 같이 수정하면 된다.
global-ignores = *.fasl *~
그리고 에디터가 필요한 Subversion 명령을 사용하게 될 경우가 있다. 예를 들어, emacs를 사용하고 싶다고 하면, ~/.profile 에 다음과 같이 추가한다.
SVN_EDITOR=/usr/bin/emacs
export SVN_EDITOR
Buildbot
1. build master를 만들자
/Users/peter/buildbot/master/our-master 에 마스터를 만든다고 가정하자.
buildbot create-master /Users/peter/buildbot/master/our-master
2. build master를 설정한다.
our-master 디렉토리에 보면 master.cfg.sample 파일이 있을 것이다. 이 파일을 편집해서 master.cfg 파일로 저장한다. 예를 보는 게 쉬울 것이다.
# 슬레이브 이름과 패스워드를 설정
from buildbot.buildslave import BuildSlave
c['slaves'] = [BuildSlave("slave-name", "slave-passwd")]
# 슬레이브가 접속할 포트 설정
c['slavePortnum'] = 9989
# 저장소의 변화를 어떻게 감지할지 설정한다. Subversion이라면 SVNPoller를 사용
from buildbot.changes.svnpoller import SVNPoller
c['change_source'] = SVNPoller("file:///Users/peter/svn-repos/app")
# treeStableTimer와 빌더 이름을 설정해 주면 된다.
from buildbot.scheduler import Scheduler
c['schedulers'] = []
c['schedulers'].append(Scheduler(name="all", branch=None,
treeStableTimer=2*60,
builderNames=["our-builder"]))
# 빌드 절차를 팩토리로 만드는 부분. 체크아웃->빌드 및 테스트 순서로 이루어져야 할 것이다.
# svnurl 에 빌드를 위해 체크아웃 해 와야 할 저장소의 디렉토리를 넣는다.
# ShellCommand 로 쉘에서 수행할 명령을 지정할 수 있다.
# 이 경우에는 build-and-test.lisp 파일에 빌드와 테스트 방법을 넣어놓고 로드하게 한 것이다.
from buildbot.process import factory
from buildbot.steps import source, shell
f1 = factory.BuildFactory()
f1.addStep(source.SVN(svnurl="file:///Users/peter/svn-repos/app"))
f1.addStep(shell.ShellCommand(command=["sbcl", "--load", "build-and-test.lisp"]))
# 빌더 이름, 빌더가 사용할 슬레이브 이름과 팩토리 이름을 설정해준다.
# builddir은 슬레이브 디렉토리 아래의 어떤 디렉토리에서 빌드를 수행할지를 설정하는 것이다.
# 이 예에서는 슬레이브가 full이라는 디렉토리를 만들어 빌드를 수행할 것이다.
b1 = {'name': "our-builder",
'slavename': "slave-name",
'builddir': "full",
'factory': f1,
}
c['builders'] = [b1]
c['status'] = []
# 웹과 메일로 빌드의 상태를 볼 수 있다.
from buildbot.status import html
c['status'].append(html.WebStatus(http_port=8010))
# sendToInterestedUsers를 False로 설정하면 extraRecipients 로만 메일이 간다고 한다.
# 빌드가 실패할 때만 메일이 가도록 mode='failing'으로 설정할 수도 있다.
# 하지만 무슨 이유에선지 메일은 제대로 보내지질 않는 것 같다.
from buildbot.status import mail
c['status'].append(mail.MailNotifier(fromaddr="buildbot@localhost", extraRecipients=['peter@matrix'], sendToInterestedUsers=False)
c['buildbotURL'] = "http://localhost:8010/"
3. build slave를 만들자
/Users/peter/buildbot/slave/our-slave 에 슬레이브를 만들고, 위에서 한 설정을 사용한다고 가정하자.
buildbot create-slave /Users/peter/buildbot/slave/our-slave localhost:9989 slave-name slave-passwd
4. build master와 build slave를 실행시키자
buildbot start /Users/peter/buildbot/master/our-master
buildbot start /Users/peter/buildbot/slave/our-slave
build master가 master.cfg 파일을 다시 읽어들이게 하려면
buildbot reconfig /Users/peter/buildbot/master/our-master
master와 slave를 멈추려면
buildbot stop /Users/peter/buildbot/slave/our-slave
buildbot stop /Users/peter/buildbot/master/our-master
이제 localhost:8010 을 살펴보자. 모든 것이 제대로 되었다면 BuildSlave를 클릭했을 때 Slave가 연결된 상태라고 나올 것이다. 저장소에 커밋이 일어나면 treeStableTimer 만큼 기다렸다가 체크아웃과 빌드가 수행된다. 쉘에서 수행된 커맨드의 exit code가 0이 아닌 값이거나 아무 stdout이 없이 20분이 지나면 빌드는 실패한 것으로 간주된다. 그 외의 경우는 성공한 것으로 처리되고, 어떤 경우든 stdout이 로그로 남는다. 웹의 Waterfall Display에서 시간대별로 모든 체크아웃과 빌드의 로그를 볼 수 있다.
여기까지 Subversion과 Buildbot을 살펴보았다. 빌드 과정은 빌드해야 하는 프로그램의 언어가 무엇이냐에 따라서 달라질 수 있다. Lisp 프로그램을 빌드하고 테스트하는 것에 대해서는 다음 글에서 다루도록 하겠다.
I. 기본 개념
'단위 테스트, 버전 관리, 빌드와 테스트 자동화' 이 세 가지는 꼭 수행해야 하는 실행지침으로 꼽힌다. 이 글에서는 버전 관리를 위해서 Subversion을 사용하고, 빌드와 테스트 자동화를 위해서 Buildbot을 사용한다고 가정한다.
Subversion은 CVS와 같은 버전 관리 툴이고, CVS의 단점을 보완하기 위해서 개발되었다고 한다. 현재는 가장 널리 쓰이고 있지만, darcs라는 툴로 많은 사람이 넘어가고 있는 것 같기도 하다. (같은 일을 할 때 darcs가 Subversion보다 손이 덜 간다고 한다. darcs는 패치 등에 대한 이론적 기반을 가지고 만들어진 같고, 가장 radical한 언어 중 하나라고 평가되는 Haskell로 짜여졌다.)
Buildbot은 Python으로 작성된, 빌드와 테스트를 자동화하기 위한 도구이다. 버전 관리 도구의 저장소를 감시하고 있다가 저장소에 변화가 생기면 코드를 체크아웃해와서 빌드와 테스트를 수행하고, 그 결과를 웹이나 이메일로 보여준다. Buildbot의 구조적인 장점은 build master와 build slave가 분리되어 있어서, 서로 다른 플랫폼에서 수행되는 빌드들을 관리하기가 용이하다는 것이다. build master는 각각의 build slave들이 어떻게 build를 수행하고 그 결과를 보고해야 할지에 대한 모든 정보를 가지고 있다. 실제로 빌드를 수행하는 build slave들은 build master에 접속해서 build master가 지시하는대로 할 뿐이다. build master와 build slave는 서로 다른 머신에 위치해 있어도 상관이 없기 때문에, 예를 들어 서로 다른 빌드를 수행하는 머신 1,2,3을 머신 4에서 총괄하는 것이 가능하다.
II. 설치
환경이 리눅스라면,
sudo apt-get install subversion
sudo apt-get install buildbot
환경이 맥이라면,
MacPorts를 이용해서 설치하면 된다. MacPorts는 DarwinPorts의 새 이름으로 리눅스의 apt-get과 비슷하게 각종 소프트웨어의 설치를 쉽게 해 준다. MacPorts 홈페이지에서 dmg 파일을 받아 설치하면 되는데, 설치 후 port 명령이 매뉴얼대로 되지 않는다면, 경로 설정이 안 되어 있어서 그런 것이다. 홈디렉토리(~)에 .profile 파일을 만들어서 다음과 같이 경로를 추가한다.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
'port search 프로그램이름'(e.x. port search buildbot)과 같이 하면 port를 통해 설치할 수 있는 프로그램들을 찾아볼 수 있다. 원하는 프로그램 이름을 찾으면 'sudo port install buildbot'과 같이 인스톨하면 된다.
환경이 윈도우라면,
이 경우는 해보질 않아서 모르겠다. 설치는 각각의 홈페이지를 참조해서 어떻게든 알아서;
III. 사용법
Subversion
저장소를 로컬의 /Users/peter/svn-repos 에 만든다고 할 때 각종 명령의 예는 다음과 같다. 로컬이 아니고 웹인 경우에는 'file://'부분을 'http://'로 바꾸면 된다.
새로운 저장소 만들기
svnadmin create /Users/peter/svn-repos
저장소에 프로젝트 만들기(기존 소스 코드를 저장소 안의 한 디렉토리로 임포트하는 경우)
app> svn import -m "application initial import" file:///Users/peter/svn-repos/app
이 경우는 저장소 아래에 app 디렉토리를 만들고 현재 디렉토리 아래의 모든 디렉토리와 파일들을 집어넣은 것이다. 하지만 저장소의 디렉토리를 살펴봐도 app 디렉토리는 눈에 보이지 않는다. 저장소에 저장된 프로젝트의 디렉토리 위치를 보고 싶다면 어떻게 해야 할까?
1. 체크아웃 해 온 작업본 디렉토리에서 svn info 또는,
2. 아무 곳에서나 svnlook tree /Users/peter/svn-repos
저장소로부터 파일 체크아웃하기
svn co file:///Users/peter/svn-repos/app app
작업본 디렉토리의 상태 알아보기
svn status
파일 앞의 M 표시는 그 파일이 변경되었다는 것을, ? 표시는 그 파일이 버전 관리 하에 놓여있지 않다는 것을 나타낸다. ? 표시된 파일을 버전 관리 대상으로 추가하기 위해서는 svn add를 사용
작업본 디렉토리의 변경을 저장소에 저장
app> svn commit -m "message"
리비전 내역 전체를 보려면
app> svn log
작업본 디렉토리의 내용을 최근 저장소의 리비전으로 갱신하려면
svn update
작업본 디렉토리에서 수행한 변경을 체크아웃 해 온 시점으로 되돌리려면
svn revert .
리비전 10과 리비전 11 사이의 변경 내역을 보고 싶다면
app> svn diff -r 10:11
작업본 디렉토리의 리비전이 11인데 리비전 9로 되돌리고 싶다면
app> svn merge -r 11:9
기타 알아두면 좋은 것
바이너리 파일이나, 백업 파일들은 저장소에 저장될 필요가 없다. Subversion이 이런 파일들을 무시하게 만들기 위해서는 ~/.subversion/config 파일의 global-ignores 부분을 수정하면 된다. 예를 들어, *.fasl 파일들과 *~ 파일들을 무시하고 싶다면 다음과 같이 수정하면 된다.
global-ignores = *.fasl *~
그리고 에디터가 필요한 Subversion 명령을 사용하게 될 경우가 있다. 예를 들어, emacs를 사용하고 싶다고 하면, ~/.profile 에 다음과 같이 추가한다.
SVN_EDITOR=/usr/bin/emacs
export SVN_EDITOR
Buildbot
1. build master를 만들자
/Users/peter/buildbot/master/our-master 에 마스터를 만든다고 가정하자.
buildbot create-master /Users/peter/buildbot/master/our-master
2. build master를 설정한다.
our-master 디렉토리에 보면 master.cfg.sample 파일이 있을 것이다. 이 파일을 편집해서 master.cfg 파일로 저장한다. 예를 보는 게 쉬울 것이다.
# 슬레이브 이름과 패스워드를 설정
from buildbot.buildslave import BuildSlave
c['slaves'] = [BuildSlave("slave-name", "slave-passwd")]
# 슬레이브가 접속할 포트 설정
c['slavePortnum'] = 9989
# 저장소의 변화를 어떻게 감지할지 설정한다. Subversion이라면 SVNPoller를 사용
from buildbot.changes.svnpoller import SVNPoller
c['change_source'] = SVNPoller("file:///Users/peter/svn-repos/app")
# treeStableTimer와 빌더 이름을 설정해 주면 된다.
from buildbot.scheduler import Scheduler
c['schedulers'] = []
c['schedulers'].append(Scheduler(name="all", branch=None,
treeStableTimer=2*60,
builderNames=["our-builder"]))
# 빌드 절차를 팩토리로 만드는 부분. 체크아웃->빌드 및 테스트 순서로 이루어져야 할 것이다.
# svnurl 에 빌드를 위해 체크아웃 해 와야 할 저장소의 디렉토리를 넣는다.
# ShellCommand 로 쉘에서 수행할 명령을 지정할 수 있다.
# 이 경우에는 build-and-test.lisp 파일에 빌드와 테스트 방법을 넣어놓고 로드하게 한 것이다.
from buildbot.process import factory
from buildbot.steps import source, shell
f1 = factory.BuildFactory()
f1.addStep(source.SVN(svnurl="file:///Users/peter/svn-repos/app"))
f1.addStep(shell.ShellCommand(command=["sbcl", "--load", "build-and-test.lisp"]))
# 빌더 이름, 빌더가 사용할 슬레이브 이름과 팩토리 이름을 설정해준다.
# builddir은 슬레이브 디렉토리 아래의 어떤 디렉토리에서 빌드를 수행할지를 설정하는 것이다.
# 이 예에서는 슬레이브가 full이라는 디렉토리를 만들어 빌드를 수행할 것이다.
b1 = {'name': "our-builder",
'slavename': "slave-name",
'builddir': "full",
'factory': f1,
}
c['builders'] = [b1]
c['status'] = []
# 웹과 메일로 빌드의 상태를 볼 수 있다.
from buildbot.status import html
c['status'].append(html.WebStatus(http_port=8010))
# sendToInterestedUsers를 False로 설정하면 extraRecipients 로만 메일이 간다고 한다.
# 빌드가 실패할 때만 메일이 가도록 mode='failing'으로 설정할 수도 있다.
# 하지만 무슨 이유에선지 메일은 제대로 보내지질 않는 것 같다.
from buildbot.status import mail
c['status'].append(mail.MailNotifier(fromaddr="buildbot@localhost", extraRecipients=['peter@matrix'], sendToInterestedUsers=False)
c['buildbotURL'] = "http://localhost:8010/"
3. build slave를 만들자
/Users/peter/buildbot/slave/our-slave 에 슬레이브를 만들고, 위에서 한 설정을 사용한다고 가정하자.
buildbot create-slave /Users/peter/buildbot/slave/our-slave localhost:9989 slave-name slave-passwd
4. build master와 build slave를 실행시키자
buildbot start /Users/peter/buildbot/master/our-master
buildbot start /Users/peter/buildbot/slave/our-slave
build master가 master.cfg 파일을 다시 읽어들이게 하려면
buildbot reconfig /Users/peter/buildbot/master/our-master
master와 slave를 멈추려면
buildbot stop /Users/peter/buildbot/slave/our-slave
buildbot stop /Users/peter/buildbot/master/our-master
이제 localhost:8010 을 살펴보자. 모든 것이 제대로 되었다면 BuildSlave를 클릭했을 때 Slave가 연결된 상태라고 나올 것이다. 저장소에 커밋이 일어나면 treeStableTimer 만큼 기다렸다가 체크아웃과 빌드가 수행된다. 쉘에서 수행된 커맨드의 exit code가 0이 아닌 값이거나 아무 stdout이 없이 20분이 지나면 빌드는 실패한 것으로 간주된다. 그 외의 경우는 성공한 것으로 처리되고, 어떤 경우든 stdout이 로그로 남는다. 웹의 Waterfall Display에서 시간대별로 모든 체크아웃과 빌드의 로그를 볼 수 있다.
여기까지 Subversion과 Buildbot을 살펴보았다. 빌드 과정은 빌드해야 하는 프로그램의 언어가 무엇이냐에 따라서 달라질 수 있다. Lisp 프로그램을 빌드하고 테스트하는 것에 대해서는 다음 글에서 다루도록 하겠다.
2008년 1월 9일 수요일
Emacs에서 Common Lisp Hyperspec 보기
리습 코드를 읽다보면 아무래도 모르는 함수나 매크로에 대한 레퍼런스를 찾아볼 필요가 생긴다. Common Lisp Hyperspec이 웹에 있고 HTML 파일을 내려받아 로컬에 저장해 놓고 볼 수도 있지만 인덱스를 일일이 클릭해가며 모르는 심볼을 찾아보는 것은 귀찮은 일이다.
보다 나은 방법은 커서가 심볼 위에 있을 때 ctrl+c ctrl+d h 를 입력하는 것이다(slime이 실행되어 있는 상태여야 한다). 그러면 해당 심볼에 해당하는 Hyperspec 웹 페이지가 뜨게 된다. 하지만 웹 페이지를 띄우는 방법은 느리고, Emacs를 벗어나야 한다는 게 불편하다. 그래서 Emacs 내에서 Hyperspec을 보는 방법을 적어보려고 한다.
Reference:
http://www.foldr.org/~michaelw/log/programming/lisp/dpans-texinfo-edition
http://www.phys.au.dk/~harder/dpans.html
1. Texinfo가 필요하다. 최신 버전을 다운로드 받아서 설치한다. 설치는 내려받은 소스의 압축을 푼 폴더에서 다음과 같이 입력하면 된다.
./configure
make
sudo make install
그런데 소스 폴더에 있는 INSTALL 파일을 읽어보면 위와 같은 일반적인 설치 과정만으로는 texinfo.tex 와 *.tex 파일들은 설치되지 않으니 추가적인 설치 명령이 필요하다고 하는데, 파일에서 말하는 TEXMF라는 게 무엇인지 모르겠다. 일단 위와 같은 일반적인 설치만으로도 목적을 달성하는 데는 별 문제가 없었으니 넘어가자.
2. dpans2texi-1.03.tar.gz를 다운 받아 압축을 푼 후 압축이 풀린 디렉토리에서 다음과 같이 입력한다.
./configure
wget ftp://parcftp.xerox.com/pub/cl/dpANS3/*
wget ftp://parcftp.xerox.com/pub/cl/dpANS3R/*
make
sudo make install
만일 wget이 없다면 설치하도록 하자. 소스 파일을 다운로드해서 압축을 푼 후 디렉토리에서 다음과 같이 입력하면 된다.
./configure
make
sudo make install
3. .emacs 파일(emacs startup file)에 다음과 같이 추가한다.
이제 리습 코드의 심볼 위에 커서가 있을 때 ctrl+h S 를 입력하고 엔터를 치면 해당 심볼에 대한 레퍼런스가 바로 뜰 것이다.(글의 시작 부분에 링크한 Reference에는 ctrl+h ctrl+i 라고 써 있지만 최근 버전의 Emacs에서 키 바인딩이 바뀌면서 기존 단축키가 먹지 않는다. ctrl+h 대문자S 를 눌러야 한다.) 그리고 ctrl+h i 를 눌러서 info 페이지로 들어가면 Programming 카테고리에 ANSI Common Lisp이 생긴 것을 볼 수 있다.
다른 방법을 소개하고 있는 페이지들도 링크해본다.
http://www.newartisans.com/blog_files/hyperspec.info.for.emacs.php
http://bc.tech.coop/blog/031002.html
http://lemonodor.com/archives/2002/02/living_in_emacs.html
보다 나은 방법은 커서가 심볼 위에 있을 때 ctrl+c ctrl+d h 를 입력하는 것이다(slime이 실행되어 있는 상태여야 한다). 그러면 해당 심볼에 해당하는 Hyperspec 웹 페이지가 뜨게 된다. 하지만 웹 페이지를 띄우는 방법은 느리고, Emacs를 벗어나야 한다는 게 불편하다. 그래서 Emacs 내에서 Hyperspec을 보는 방법을 적어보려고 한다.
Reference:
http://www.foldr.org/~michaelw/log/programming/lisp/dpans-texinfo-edition
http://www.phys.au.dk/~harder/dpans.html
1. Texinfo가 필요하다. 최신 버전을 다운로드 받아서 설치한다. 설치는 내려받은 소스의 압축을 푼 폴더에서 다음과 같이 입력하면 된다.
./configure
make
sudo make install
그런데 소스 폴더에 있는 INSTALL 파일을 읽어보면 위와 같은 일반적인 설치 과정만으로는 texinfo.tex 와 *.tex 파일들은 설치되지 않으니 추가적인 설치 명령이 필요하다고 하는데, 파일에서 말하는 TEXMF라는 게 무엇인지 모르겠다. 일단 위와 같은 일반적인 설치만으로도 목적을 달성하는 데는 별 문제가 없었으니 넘어가자.
2. dpans2texi-1.03.tar.gz를 다운 받아 압축을 푼 후 압축이 풀린 디렉토리에서 다음과 같이 입력한다.
./configure
wget ftp://parcftp.xerox.com/pub/cl/dpANS3/*
wget ftp://parcftp.xerox.com/pub/cl/dpANS3R/*
make
sudo make install
만일 wget이 없다면 설치하도록 하자. 소스 파일을 다운로드해서 압축을 푼 후 디렉토리에서 다음과 같이 입력하면 된다.
./configure
make
sudo make install
3. .emacs 파일(emacs startup file)에 다음과 같이 추가한다.
(require 'info-look)
(info-lookup-add-help
:mode 'lisp-mode
:regexp "[^][()'\" \t\n]+"
:ignore-case t
:doc-spec '(("(ansicl)Symbol Index" nil nil nil)))
이제 리습 코드의 심볼 위에 커서가 있을 때 ctrl+h S 를 입력하고 엔터를 치면 해당 심볼에 대한 레퍼런스가 바로 뜰 것이다.(글의 시작 부분에 링크한 Reference에는 ctrl+h ctrl+i 라고 써 있지만 최근 버전의 Emacs에서 키 바인딩이 바뀌면서 기존 단축키가 먹지 않는다. ctrl+h 대문자S 를 눌러야 한다.) 그리고 ctrl+h i 를 눌러서 info 페이지로 들어가면 Programming 카테고리에 ANSI Common Lisp이 생긴 것을 볼 수 있다.
다른 방법을 소개하고 있는 페이지들도 링크해본다.
http://www.newartisans.com/blog_files/hyperspec.info.for.emacs.php
http://bc.tech.coop/blog/031002.html
http://lemonodor.com/archives/2002/02/living_in_emacs.html
2008년 1월 8일 화요일
Emacs에서 정규식 테스트하기
Reference:
http://www.newartisans.com/blog_files/regex.tool.for.emacs.php
1. regex-tool.el 파일을 받는다. emacs가 위치한 디렉토리 아래의 site-lisp 디렉토리 또는 /usr/local/share/emacs/site-lisp 디렉토리에 넣으면 된다.
2. .emacs 파일(emacs 시작시에 읽어들이게 되는 설정 파일. 없으면 홈폴더에 만들면 된다.)에 다음 코드를 추가한다.
(load "regex-tool" t) ; load regex-tool if it's available
3. meta+x load-file을 입력해 regex-tool.el 파일을 수동으로 로드해준다. 한 번 그렇게 해 주고 난 뒤에는 meta+x regex-tool 을 치면 정규식 테스트가 가능한 것을 볼 수 있다.
http://www.newartisans.com/blog_files/regex.tool.for.emacs.php
1. regex-tool.el 파일을 받는다. emacs가 위치한 디렉토리 아래의 site-lisp 디렉토리 또는 /usr/local/share/emacs/site-lisp 디렉토리에 넣으면 된다.
2. .emacs 파일(emacs 시작시에 읽어들이게 되는 설정 파일. 없으면 홈폴더에 만들면 된다.)에 다음 코드를 추가한다.
(load "regex-tool" t) ; load regex-tool if it's available
3. meta+x load-file을 입력해 regex-tool.el 파일을 수동으로 로드해준다. 한 번 그렇게 해 주고 난 뒤에는 meta+x regex-tool 을 치면 정규식 테스트가 가능한 것을 볼 수 있다.
2008년 1월 4일 금요일
맥에서 SBCL이 thread를 지원하도록 만들기
SBCL은 맥에서 experimental threading을 지원한다고 되어있지만, 그런 식으로 발표된지가 1년이 훨씬 넘었기 때문에 더 이상 experimental한 것이 아니라고 보는 사람들이 많다. 어쨋건, 맥에서 SBCL로 웹 프로그래밍을 해보려면 threading support는 필수적이기 때문에 SBCL을 어떤 식으로 인스톨해야 스레드를 지원하도록 만들 수 있는지 알아보도록 하겠다. 요점은 특정한 설정을 주고 소스를 직접 컴파일해야 되는데, 컴파일하려면 리습 구현이 필요하기 때문에 일단 바이너리 버전의 SBCL을 설치한 다음, 소스코드를 컴파일해서 바이너리를 만들고 그 바이너리로 인스톨하면 된다. 구체적인 설치 과정은 다음과 같다.
1. 바이너리 버전의 SBCL을 다운받아 인스톨한다.
바이너리 파일을 다운받아 압축을 푼 폴더에서 sudo sh install.sh
2. SBCL의 소스 코드를 내려받아 압축을 푼다.
예를 들어 압축을 푼 폴더가 /Users/chanwoo/Downloads/sbcl-1.0.13 라고 하자.
3. 내려받은 소스 코드 디렉토리의 최상단(/Users/chanwoo/Downloads/sbcl-1.0.13 폴더)에 customize-target-features.lisp 파일을 다음과 같은 내용으로 만들어 저장한다.
4. 소스를 컴파일한다.
sudo sh make.sh
5. 기존에 설치된 SBCL을 지운다.
/usr/local/bin/sbcl 과 /usr/local/lib/sbcl 을 삭제
6. 소스 디렉토리(/Users/chanwoo/Downloads/sbcl-1.0.13)에서 바이너리 파일을 인스톨하듯이 인스톨하면 된다.
sudo sh install.sh
Hunchentoot를 돌려보면 스레드를 지원하는 것을 볼 수 있다! :)
1. 바이너리 버전의 SBCL을 다운받아 인스톨한다.
바이너리 파일을 다운받아 압축을 푼 폴더에서 sudo sh install.sh
2. SBCL의 소스 코드를 내려받아 압축을 푼다.
예를 들어 압축을 푼 폴더가 /Users/chanwoo/Downloads/sbcl-1.0.13 라고 하자.
3. 내려받은 소스 코드 디렉토리의 최상단(/Users/chanwoo/Downloads/sbcl-1.0.13 폴더)에 customize-target-features.lisp 파일을 다음과 같은 내용으로 만들어 저장한다.
(lambda (features)
(flet ((enable (x)
(pushnew x features))
(disable (x)
(setf features (remove x features))))
;; Threading support, available only on x86/x86-64 Linux, x86 Solaris
;; and x86 Mac OS X (experimental).
(enable :sb-thread)))
4. 소스를 컴파일한다.
sudo sh make.sh
5. 기존에 설치된 SBCL을 지운다.
/usr/local/bin/sbcl 과 /usr/local/lib/sbcl 을 삭제
6. 소스 디렉토리(/Users/chanwoo/Downloads/sbcl-1.0.13)에서 바이너리 파일을 인스톨하듯이 인스톨하면 된다.
sudo sh install.sh
Hunchentoot를 돌려보면 스레드를 지원하는 것을 볼 수 있다! :)
2008년 1월 2일 수요일
ASDF (Another System Definition Facility)
커먼 리습 프로그래밍을 하다보면 홈 폴더가 아닌 다른 폴더에 저장된 .lisp 파일을 로드해 올 수는 없을까 하는 의문이 생기게 된다. load가 파일을 읽어들여오는 path 설정은 도대체 어디서 하는거지? 라고 고민할 수 있다. 결론적으로 말하면 load는 파일을 로드하기 위해서 복수의 디렉토리를 살펴볼 능력이 없다. 하지만 방법이 없는 것은 아니다. asdf를 사용하면 원하는 일을 할 수 있다. SBCL이나 OpenMCL 같은 경우에는 asdf가 기본적으로 포함되어 있기 때문에 별도의 설치가 필요 없다. asdf를 사용할 때 다음과 같이 해주기만 하면 된다.
(require 'asdf)
asdf는 사실 프로그램이 복수의 파일들로 나뉘어서 짜여질 때 파일들 사이의 의존관계를 지켜가며 컴파일하도록 도와주는 C의 make와 비슷한 것이라 보면 된다. 이러한 의존관계는 .asd 파일로 만들어진다. 다음 cow.asd 파일의 예를 보면 tail.lisp 파일은 legs.lisp 파일에 의존적이다.
cow.asd 및 tail.lisp, legs.lisp 등의 파일이 ~/work/cow 폴더에 저장되어 있다고 하자. 그러면 이 시스템을 사용하기 위해서는 자신이 사용하는 리습의 스타트업 파일(홈폴더 아래에 만들면 되며 SBCL은 .sbclrc OpenMCL은 openmcl-init.lisp)에 다음과 같이 추가하면 된다.
(require 'asdf)
(push #p"~/work/cow" asdf:*central-registry*)
이렇게 추가한 뒤에는 SBCL에서는 그저 (require 'cow)라고 하는 것만으로 파일들이 차례대로 로드된다. 다른 리습 구현에서는 (asdf:operate 'asdf:load-op 'cow)라고 해야 하지만.
따라서 asdf를 이용하게 되면 홈 폴더가 아닌 곳에 리습 파일을 놓고 로드할 수가 있다. 리습 파일을 원하는 폴더에 위치시키고 그 폴더를 asdf:*central-registry*에 등록시킨 다음, 폴더 안에 있는 .lisp 파일들을 어떤 식으로 로드할 것인지를 .asd 파일로 만들어 역시 같은 폴더 안에 위치시키면 된다. 만일 로드하고자 하는 리습 파일이 lisp-unit.lisp파일 하나뿐이라면 lisp-unit.asd 파일은 다음과 같은 것으로 충분할 것이다.
아무튼, 여기서 다 설명할 수는 없지만, asdf는 현재 Common Lisp에서 시스템을 구성하는 일반적인 방법이다. 그리고 asdf-install은 Common Lisp 라이브러리를 설치하는데 가장 널리 사용되는 도구다. 둘 다 Common Lisp의 교과서들을 끝내고 실제 세상으로 나갈 때 반드시 사용하게 되는 도구라고 할 수 있다.
(require 'asdf)
asdf는 사실 프로그램이 복수의 파일들로 나뉘어서 짜여질 때 파일들 사이의 의존관계를 지켜가며 컴파일하도록 도와주는 C의 make와 비슷한 것이라 보면 된다. 이러한 의존관계는 .asd 파일로 만들어진다. 다음 cow.asd 파일의 예를 보면 tail.lisp 파일은 legs.lisp 파일에 의존적이다.
;;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Base: 10 -*-
(defpackage #:cow-asd
(:use :cl :asdf))
(in-package :cow-asd)
(defsystem cow
:name "cow"
:version "0.0.0"
:maintainer "T. God"
:author "Desmon Table"
:licence "BSD sans advertising clause (see file COPYING for details)"
:description "Cow"
:long-description "Lisp implementation of our favorite ruminant"
:components ((:file "tail"
:depends-on ("package" "legs"))
(:file "legs"
:depends-on ("package"))
(:file "head"
:depends-on ("package"))
(:file "package")))
cow.asd 및 tail.lisp, legs.lisp 등의 파일이 ~/work/cow 폴더에 저장되어 있다고 하자. 그러면 이 시스템을 사용하기 위해서는 자신이 사용하는 리습의 스타트업 파일(홈폴더 아래에 만들면 되며 SBCL은 .sbclrc OpenMCL은 openmcl-init.lisp)에 다음과 같이 추가하면 된다.
(require 'asdf)
(push #p"~/work/cow" asdf:*central-registry*)
이렇게 추가한 뒤에는 SBCL에서는 그저 (require 'cow)라고 하는 것만으로 파일들이 차례대로 로드된다. 다른 리습 구현에서는 (asdf:operate 'asdf:load-op 'cow)라고 해야 하지만.
따라서 asdf를 이용하게 되면 홈 폴더가 아닌 곳에 리습 파일을 놓고 로드할 수가 있다. 리습 파일을 원하는 폴더에 위치시키고 그 폴더를 asdf:*central-registry*에 등록시킨 다음, 폴더 안에 있는 .lisp 파일들을 어떤 식으로 로드할 것인지를 .asd 파일로 만들어 역시 같은 폴더 안에 위치시키면 된다. 만일 로드하고자 하는 리습 파일이 lisp-unit.lisp파일 하나뿐이라면 lisp-unit.asd 파일은 다음과 같은 것으로 충분할 것이다.
(defpackage #:lisp-unit-asd
(:use :cl :asdf))
(in-package :lisp-unit-asd)
(defsystem lisp-unit
:name "lisp-unit"
:components ((:file "lisp-unit")))
아무튼, 여기서 다 설명할 수는 없지만, asdf는 현재 Common Lisp에서 시스템을 구성하는 일반적인 방법이다. 그리고 asdf-install은 Common Lisp 라이브러리를 설치하는데 가장 널리 사용되는 도구다. 둘 다 Common Lisp의 교과서들을 끝내고 실제 세상으로 나갈 때 반드시 사용하게 되는 도구라고 할 수 있다.
2008년 1월 1일 화요일
Common Lisp Testing Framework
어떤 프로그래밍 언어를 사용해서 프로그램을 하든 테스팅 프레임워크와 프로파일러는 필요하다. 커먼 리습의 테스팅 프레임워크들을 잘 정리해놓은 글이 있어 링크해본다. Common Lisp Testing Framework
lisp-unit은 사용법이 아주 간단할 뿐더러 문서화도 잘 되어 있다. 하지만 테스트를 조직화 할 수 있는 방법이 마땅치 않아서 간단한 테스트만을 필요로 할 때 적합하다고 한다. FiveAM과 Stefil은 좀 더 스케일이 크고 조직화된 테스트에 적합하다고 한다.
1. lisp-unit 설치
lisp-unit은 원래 파일 하나로 배포되었지만, 2007년 1월 11일자로 asdf-install 가능하게 바뀌었다. 설치하려면 슬라임에서 다음과 같이 한다.
(require 'asdf-install)
(asdf-install:install 'lisp-unit)
2. FiveAM과 Stefil 설치
FiveAM과 Stefil을 설치하기 전에 해야 할 것이 두 가지 있다.
1. 다음과 같이 최신의 slime을 받아서 사용하는 것이 좋다.
cvs -d :pserver:anonymous:anonymous@common-lisp.net:/project/slime/cvsroot co slime
slime-2.0을 사용하면 컴파일이 제대로 되지 않는다.
2. slime이 위치한 디렉토리를 asdf:*central-registry*에 추가한다.
추가하지 않고 컴파일하면, FiveAM과 Stefil 둘 다 swank라는 것을 요구하는 것을 볼 수 있다. swank는 slime의 다른 이름이다. 리습구현의 스타트업 파일에(SBCL의 경우에는 홈 폴더의 .sbclrc 파일) 다음과 같이 slime이 위치한 디렉토리를 추가해주면 된다.
(push #p"/Users/chanwoo/cl-library/slime/" asdf:*central-registry*)
이제 준비가 되었으면 두 테스팅 프레임워크를 설치해보자.
1. FiveAM 설치
FiveAM은 asdf로 설치 가능하다. 다음과 같이 하면 설치 끝.
(require 'asdf-install) ;GPG체크 때문에 디버거로 떨어지면 0번을 눌러서 진행하면 된다.
(asdf:install-install 'fiveam)
2. Stefil 설치
먼저 iterate, alexandria, defclass-star를 설치해야 한다.
(require 'asdf-install)
(asdf-install:install 'iterate)
(asdf-install:install 'alexandria)
defclass-star는 다음과 같이 darcs로 내려받은 후,
darcs get http://common-lisp.net/project/defclass-star/darcs/defclass-star
폴더를 asdf:*central-registry*에 추가하면 설치 끝이다.
세 가지를 다 설치했다면, 이제 Stefil을 다음과 같이 내려받은 후,
darcs get http://common-lisp.net/project/stefil/darcs/stefil
해당 디렉토리를 asdf:*central-registry*에 추가하면 설치 끝.
설치가 끝나고 FiveAM이나 Stefil을 사용하려면 SBCL에서는 단순히,
(require 'fiveam) 또는 (require 'stefil) 로 충분하다.
SBCL외의 다른 구현을 사용한다면,
(asdf:operate 'asdf:load-op 'fiveam) 또는 (asdf:operate 'asdf:load-op 'stefil) 라고 하면 된다.
lisp-unit은 사용법이 아주 간단할 뿐더러 문서화도 잘 되어 있다. 하지만 테스트를 조직화 할 수 있는 방법이 마땅치 않아서 간단한 테스트만을 필요로 할 때 적합하다고 한다. FiveAM과 Stefil은 좀 더 스케일이 크고 조직화된 테스트에 적합하다고 한다.
1. lisp-unit 설치
lisp-unit은 원래 파일 하나로 배포되었지만, 2007년 1월 11일자로 asdf-install 가능하게 바뀌었다. 설치하려면 슬라임에서 다음과 같이 한다.
(require 'asdf-install)
(asdf-install:install 'lisp-unit)
2. FiveAM과 Stefil 설치
FiveAM과 Stefil을 설치하기 전에 해야 할 것이 두 가지 있다.
1. 다음과 같이 최신의 slime을 받아서 사용하는 것이 좋다.
cvs -d :pserver:anonymous:anonymous@common-lisp.net:/project/slime/cvsroot co slime
slime-2.0을 사용하면 컴파일이 제대로 되지 않는다.
2. slime이 위치한 디렉토리를 asdf:*central-registry*에 추가한다.
추가하지 않고 컴파일하면, FiveAM과 Stefil 둘 다 swank라는 것을 요구하는 것을 볼 수 있다. swank는 slime의 다른 이름이다. 리습구현의 스타트업 파일에(SBCL의 경우에는 홈 폴더의 .sbclrc 파일) 다음과 같이 slime이 위치한 디렉토리를 추가해주면 된다.
(push #p"/Users/chanwoo/cl-library/slime/" asdf:*central-registry*)
이제 준비가 되었으면 두 테스팅 프레임워크를 설치해보자.
1. FiveAM 설치
FiveAM은 asdf로 설치 가능하다. 다음과 같이 하면 설치 끝.
(require 'asdf-install) ;GPG체크 때문에 디버거로 떨어지면 0번을 눌러서 진행하면 된다.
(asdf:install-install 'fiveam)
2. Stefil 설치
먼저 iterate, alexandria, defclass-star를 설치해야 한다.
(require 'asdf-install)
(asdf-install:install 'iterate)
(asdf-install:install 'alexandria)
defclass-star는 다음과 같이 darcs로 내려받은 후,
darcs get http://common-lisp.net/project/defclass-star/darcs/defclass-star
폴더를 asdf:*central-registry*에 추가하면 설치 끝이다.
세 가지를 다 설치했다면, 이제 Stefil을 다음과 같이 내려받은 후,
darcs get http://common-lisp.net/project/stefil/darcs/stefil
해당 디렉토리를 asdf:*central-registry*에 추가하면 설치 끝.
설치가 끝나고 FiveAM이나 Stefil을 사용하려면 SBCL에서는 단순히,
(require 'fiveam) 또는 (require 'stefil) 로 충분하다.
SBCL외의 다른 구현을 사용한다면,
(asdf:operate 'asdf:load-op 'fiveam) 또는 (asdf:operate 'asdf:load-op 'stefil) 라고 하면 된다.
피드 구독하기:
글 (Atom)