The Best & Rarities


요즘 가장 즐겨듣는 음반을 소개합니다. 직접 구입한 음반은 아니구요, 랑랑이 쓴 책에 대한 리뷰를 블로그에 써서 출판사에서 선물을 준 것인지 아니면 구입할때 이벤트가 있었는지는 모르겠지만 공짜로 얻었습니다. ^^; 공짜로 얻은 음반치고는 애지중지 하며 열심히 듣고 있어요.

이 앨범은 CD2장으로 구성되어 있는데, 두번째 CD는 아직 거의 들어보지 못했습니다. 첫번째 CD에 담긴 음악이 너무 좋아서 여기 있는 곡들만 반복해서 듣고 있습니다.

1. Hungarian Rhapsody No.2 In C Sharp Minor (Franz Liszt)
2. Apring Dance (Sun Yiqiang)
3. Piano Sonata In C Major, K.330 : I. Allegro Moderato (Wolfgang Amadeus Mozart)
4. Liebestraum, S.541, No.3 (Franz Liszt)
5. Yellow River Concerto, Ii. Ode To The Yellow River
6. Nocturne In D Flat Major, Op.27 No.2 (Frederic Chopin)
7. Kinderszenen, Op.15, Traumerei (Robert Schumann)
8. Autumn Moon On A Calm Lake (Lu Wencheng)
9. Rhapsody On A Theme Of Apganini, Op.43, Variation 18 (Sergei Rachmaninov)
10. Piano Concerto No.4 In G Major, Op.58, Ii. Andante Con Moto (Ludwig Van Beethoven)
11. Piano Sonata No.3 In B Minor, Op.58, Iv. Finale (Frederic Chopin)
12. Piano Concerto No.1 In B Flat Minor, Op.23, Iii. Allegro Con Fuoco (Peter Ilyich Tchaikovsky)

보통 4번 트랙부터 7번 트랙까지, 11번 트랙부터 12번 트랙까지 듣습니다.

특히 리스트의 Liebestraum은 요즘 저의 favorite classical music 입니다! 정말 감미롭고 아름다워서 제가 아는 모든 사람들에게 들려 주고 싶은 음악이에요. 언젠가는 직접 연주해보고 싶기도 합니다. (1만시간 연습하면 누구나(?) 전문가가 될 수 있다는 제목의 기사가 떠오르는 군요. ^^;)

이 앨범을 들으면서 얻은 또 하나의 수확은 쇼팽의 소나타를 좋아하게 되었다는 것입니다! 11번 트랙에 소나타 3번이 상당히 마음에 들었거든요. 임동혁, 임동민 형제의 쇼팽 소나타 앨범도 한번 들어보고 싶네요. 하지만 역시 쇼팽은 발라드라는 생각에는 여전히 변함이 없습니다.

5번 트랙을 보면 제목이 생소하지 않나요? 해석하자면 “황하강 피아노 협주곡”입니다. 이 곡을 들어보면 중국문화의 느낌을 클래식 형식으로 잘 살렸다는 느낌을 받게 됩니다. 그리고 부럽다는 생각이 들었습니다. 우리도 “한강 교향곡”, “한강 피아노 협주곡” 같은 것 하나 있어야 하는 것 아닙니까?

DVD에서 봤던 그의 격한(?) 몸짓만큼이나 강렬한 감정이 음악에 실려 있는 듯 하여, 집중해서 그의 음악을 들을때면 온몸이 짜릿해 짐을 느낍니다. 이 앨범에 어느정도 실증이 날때 즈음에는 그의 다른 앨범 혹은 더 나아가 그의 공연에 관심을 가져봐야겠습니다.

알루미늄 아이맥(iMac) 24인치

맥미니, 맥북, 아이맥 사이에서 방황하다 결국 미친척 하고 아이맥 24인치를 구입해 버렸습니다! 회사에 들어온 이후로 제 자신에게 가장 큰 선물이 되겠네요. ^^; 다소 성급한 구매였지만 몇일 사용해본 결과 매우 만족스럽습니다. 


작년에 맥북을 사용했던 전력이 있기 때문에 mac osx에 금방 익숙해 질 수 있었습니다. mac osx의 사용자 인터페이스가 워낙 훌륭하기 때문이기도 하겠죠. 넓고 선명한 화면도 훌륭하지만, 가장 만족스러운 부분은 소음이 거의 없다는 것입니다. 얼마전에 처분한 조립PC는 정말 시끄러웠거든요! 컴퓨터로 음악을 듣는게 바보스럽게 느껴질 정도로…

Objective-C 공부 후에, mac 어플리케이션 혹은 iPhone/iPod Touch 어플리케이션을 개발해보려고 합니다. 어느정도 진행이 되면 블로그에 관련 글을 쓸 수 있겠죠. ^^

Call stack을 깨는 버그의 해결

decNumber Library(http://speleotrove.com/decimal/)를 사용하는 코드에서 Call stack을 깨먹는 버그가 발생하여 지난 일주일동안 마음이 편치 않았는데, 결국 해결했습니다! 워낙 사소한 실수에서 비롯된 일이라 부끄럽기 그지 없지만, 유사한 버그로 머리를 쥐어뜯고 있을 누군가에게 도움이 될지도 모른다는 바램을 가지고 용기를 내어 보겠습니다!

Call stack을 깨는 코드는 다음과 같습니다.

이 함수가 호출되면 sementation fault가 발생하면서 프로그램이 죽는 현상이 발생했습니다. gdb에서 bt를 실행해보니 call stack이 깨졌다는 사실을 알 수 있었습니다. 곰곰히 생각해보니 로컬변수에 값을 쓰다가 activation record의 return address 영역을 엎어 쓰는 것 같더라구요. 이를 확인하기 위해 left 변수 앞에 임의로 char buf[100]; 변수 선언을 넣었더니 call stack이 깨지는 현상은 사라졌습니다.

decNumber 라이브러리를 사용하여 실제 계산을 수행하는 코드는 다음과 같습니다.

여기서 눈여겨 보아야 할 것은 DECNUMDIGITS라는 상수(constant)입니다. 항상 decNumber를 사용해 계산을 수행하기 위해서는 decContext를 설정해서 전달해 주어야 하는데 이때 DECNUMDIGITS을 참조하게 되죠. 이 값을 별도로 설정하지 않으면 decNumber.h에서 1로 설정하기 때문에 정상적인 연산을 수행할 수 없습니다.

따라서 decNumber로 표현 및 계산하고자하는 최대 자리수를 #define으로 미리 지정해 주어야 합니다.  문제는 여기에 있었습니다. decNumber를 사용하여 계산하는 함수를 따로 분리하는 과정에서 decNumber.h를 include 하는 문장 뒤에 #define DECNUMDIGITS를 포함하는 헤더파일의 include 문장이 존재하게 되었던거죠! 결과적으로 decNumber.h가 확장될때는 DECNUMDIGITS가 기본값인 1로 결정되고, 제가 작성한 코드에서는 프로젝트 전역 헤더파일에서 정의한 값(30)이 참조되었습니다. 변수와 정의와 변수의 참조 사이에 괴리(?)가 발생했던 겁니다. 

decNumber.h를 살펴보면 문제는 좀 더 명확해 집니다.

decNumber.h를 include하는 문장 앞에 DECNUMDIGITS을 정의한 프로젝트 전역 헤더파일을 include하도록 수정함으로써 문제는 간단히 해결되었습니다. 대부분의 버그가 비슷하겠지만, 문제를 찾아서 해결하고 나니 참으로 허무한 기분이 들었습니다. 한동안 제 자신이 미워지더군요. ^^;

이번 경험을 통해 얻은 교훈은 다음과 같습니다.

1. macro 사용에 유의하자.
2. 헤더파일의 include 순서에 유의하자.
3. call stack을 깨는 경우는 문자열을 비롯한 array의 잘못된 사용 및 참조로 발생하는 경우가 많다.

Ruby로 작성한 회귀 테스트 장치

저희팀(TmaxSoft, Compiler팀)은 컴파일러를 개발하고 있습니다. 컴파일러를 개발하다보면 코드의 수정 혹은 추가로 인해 기존에 잘 되던 것이 잘 안되는 문제가 빈번히 발생합니다. 언어를 처리하는 프로그램의 특성상 상호의존적인 코드의 비중이 높기 때문이죠.

그런 까닭에 “실용주의 프로그래머“에서도 강조하는 회귀 테스트가 정합성을 생명으로하는 컴파일러의 개발과정에서 빼놓을 수 없는 영역을 차지하게 됩니다. 

저희팀에서 컴파일러 혹은 인터프리터의 개발과정에서 사용하는, Ruby로 작성된 회귀 테스트 장치(regression test harness) 코드는 다음과 같습니다. (Ruby의 맛만 살짝 본 상태에서 제가 작성한 조악한 코드지만, ‘이런식으로 회귀 테스트를 하기도 하는구나!’ 정도로 이해해주시면 좋겠네요.)

컴파일러나 인터프리터가 제대로 동작하는지 확인하는 가장 간단한(?) 방법은 소스코드를 사용하여 예상대로 동작하는지 확인하는 것 입니다. 일반적인 경우에는 standard output(이하 stdout) 결과를 보고 이상유무를 파악합니다. 기본적인 아이디어는 여기서 정리하고 본론으로 들어가자면…

여기서 소개한 회귀 테스트를 위해서는 2가지 작업이 선행되어야 합니다.

1. 회귀 테스트에 포함시킬 예제 파일의 이름(확장자 제외)을 list.txt에 추가 (newline으로 여러개의 파일구분)
2. 정상 동작할때 stdout을 filename.out 파일에 저장 (e.g. ezp -i filename.ezt > filename.out)

회귀 테스트 과정은 다음과 같습니다.

1. list.txt에서 테스트 할 파일 이름을 추출하여 nameArray에 저장, 이 때 존재하는 파일인지 확인
2. ezp 인터프리터 실행하여 stdout을 filename.tmp에 저장
3. diff로 정상 동작시 결과 filename.out과 현재 실행 결과 filename.tmp를 비교
4. diff의 stdout이 비어 있으면 테스트 성공! 비어있지 않으면 failArray에 추가
5. 회귀테스트 결과 출력

저희팀에서는 (당연한 이야기겠지만) 저장소에 commit하기 전에 회귀 테스트를 통과하는 것을 정책적으로 강제하고 있습니다.

Code::Blocks

Code::Blocks는 윈도우, 리눅스, 맥 환경을 모두 지원하는 오픈소스 C/C++ 개발 환경입니다.

http://www.codeblocks.org/

리눅스나 유닉스를 기반으로 하는 맥의 경우 C 프로그래밍 환경을 쉽게 갖출 수 있지만, 윈도우의 경우 로컬 시스템에 C 프로그래밍 환경을 마련하기가 애매한 것 같습니다. 윈도우를 위한 gcc환경인 MinGW를 직접 설치해야 하죠.

윈도우 환경에 Code::Blocks를 설치하는 경우 codeblocks-8.02mingw-setup.exe 파일을 다운받아 실행하시면 MinGW가 함께 설치되고 Code::Blocks의 기본 컴파일러로 등록이 됩니다. 별도의 설정없이 바로 프로젝트를 생성하고 빌드하고 실행할 수 있는 환경을 마련할 수 있습니다.

IDE 자체도 훌륭합니다. function outline, folding, debug, syntax highlighting 등등 IDE가 갖추어야 할 기본적인 기능은 모두 포함하고 있습니다. 윈도우에 C 프로그래밍 환경을 마련하고자하는 분들에게 Code::Blocks를 추천하고 싶네요.