구글 사이츠 자기 도메인 연결 기능 추가

추가됐다고 발표된지는 좀 됐는데 모든 사용자한테 동시에 이 기능이 뜨지는 않고 천천히 뜬듯. 아니면 구글이 공갈을 쳤거나. 어쨌거나 그런 기능 추가됐다는거 확인하고 매일 내 좃스팟 확인을 해왔는데 오늘 보니 나도 메뉴가 떴더라.

바로 www.yoonkn.com 을 http://sites.google.com/a/yoonkn.com/wiki 에 매핑을 했는데 실패! 절라.. www 가 이미 매핑이 됐다고 에러가 뜨더라. 알고보니 내가 이전에 www.yoonkn.com 을 구글 페이지 로 링크를 해뒀었네. 근데 이걸 바꿔도 www 가 매핑이 됐다고 뜨고.. 어떻게 손보기가 힘들더라.

좀 고민하다가 어차피 안쓰는 기능이니 구글페이지를 내려버리고 그외 구글챗 구글캘린더 등 내가 구글앱에서 쓰지 않는 기능들을 덩달아 내려버렸다. 대강 정리후 다시 www 매핑을 시도해보니 성공

이제 www.yoonkn.com  으로 내 위키에 접근이 가능해졌고, 위키안의 페이지들도 www.yoonkn.com/페이지이름/페이지이름 식으로 이쁘게 나온다.

아.. 맘에 드네.

플레인스케이프: 토먼트 모드 3종

http://www.spellholdstudios.net/shs/triple_pst_mod_release_and_a_welcome_to_qwinn

헐
잼나겠다.
한글판에 적용하면 어케될지 몰겠네

보고있는 웹사이트 마음대로 수정하기 ( 자바스크립트 )

• http://www.reddit.com/r/programming/info/6qmuw/comments/
• http://www.blogstorm.co.uk/cut-and-paste-one-line-of-code-to-make-any-website-editable/
  

주소창에 아래 스크립트 집어넣으면 브라우저 상에서 수정가능

javascript:document.body.contentEditable='true'; document.designMode='on'; void 0

언급된대로 구라샷 만드는데 써먹을수 있겠군. 잇힝
아래는 위 스크립트 개정판. 토글이 가능하다. 수정후엔 수정모드를 풀어줘야 하니 이걸 써먹자.

javascript:if(document.body.contentEditable == 'false' || document.body.contentEditable == 'inherit')document.body.contentEditable = 'true';else document.body.contentEditable = 'false';void 0

cmake 2.4-patch 7 하고 ccache 사용시 cmake 가 컴파일러를 파악하지 못하는 문제

release 빌드를 했는데 최적화 옵션이 빠진것을 보고 make edit-cache 에서 t 로 모든 옵션 켜고 읽어보니 cmake 가 세팅해줘야 할 옵션들이 죄다 빠져있었다. 좀 생각해보니 ccache 가 문제인것 같은데 역시나 CC="ccache gcc" CXX="ccache g++" 로 환경변수 잡았던거 빼고 돌려보니 cmake 가 정상적으로 플래그들 세팅해주더라.

혹시나 또다시 삽질하는 경우를 피하기위해 적어둔다.
좀더 뒤지면 해결책도 나올것 같은데 그건 나중에.


아래는 FLAGS 들이 비어있는 상태. cmake 가 CMAKE_COMPILER_ARGS1 이란놈으로 뭔가 할것 같은데.. 결과는 그렇지 못했다.

아래는 정상일때. 컴파일러가 제대로 인식이 됐고 cflags 들이 적절히 세팅되었다.

cmake 로 pkg-config 사용하기 ( CFLAGS, LDFLAGS 설정하기 )

이전위키에 적은글

씨바 cmake 깝깝하네.
걍 CFLAGS, LDFLAGS 만 세팅하는게 뭐이리 중구난방인지
급히 여기 적어두고 나중에 몰아서 새위키에 정리하자.

# cmake 에 딸려오는 UsePkgConfig 를 쓰기로 했다.
# EXECUTE_PROCESS 를 써볼려고 헀는데 영 지저분해지길래 이놈을 쓴다.
INCLUDE(UsePkgConfig)
# UsePkgConfig.cmake 에 나온 예제 그대로
PKGCONFIG(gstreamer-0.10 GSTREAMER_INCLUDEDIR GSTREAMER_LIBDIR GSTREAMER_LDFLAGS GSTREAMER_CFLAGS)
# 인클루드 디렉토리 추가
INCLUDE_DIRECTORIES(${GSTREAMER_INCLUDEDIR})
# 링크 디렉토리 추가
LINK_DIRECTORIES(${GSTREAMER_LIBDIR})
# cflags 추가. cflag 에 -d 나 /D 만 있는게 아닌데 이딴 이름을 쓰는건 좀
# 아니라고 보는데.. 이 방법 말고 cmake 가 세팅하는 모든 CFLAGS,
# CXXFLAGS 를 수정하는 수단을 못찾겠다.
ADD_DEFINITIONS(${GSTREAMER_CFLAGS})


# 바이너리 하나 추가.
ADD_EXECUTABLE(a a.c)
# 그 바이너리에 LDFLAGS 적용. 이것도 절라 쓰레기 같은데.. 그냥
# 글로벌하게 LDFLAGS 를 수정하고 싶은데 깔끔한 방법이
# 안보인다. CMAKE_MODULE_LINKER_FLAGS 를 바꾸면 된다는데 SET 으로 저걸
# 바꾸는게 그다지 깔끔해 보이진 않는다.
SET_TARGET_PROPERTIES(a PROPERTIES LINK_FLAGS ${GSTREAMER_LDFLAGS})

티스토리에 있던 글 가져와봤는데

역으로도 되는지 모르겠다.
기존 글이랑 머징이 안되고 날려버린다는게 좀 거시기하군.

emacs + gdb 편하게 디버깅하기

이전에 적었던 글
http://oldpie.yoonkn.com/cgi-bin/moin.cgi/DebuggingWithEmacs
http://oldpie.yoonkn.com/cgi-bin/moin.cgi/using_GDB
를 새 위키에 적기전에 잠시 정리. emacs 와 gdb 로 디버깅하기 란 페이지에 정리할 생각.

emacs 에서 gdb 를 visual studio 와 유사한 키바인딩으로 사용하기

(global-set-key [f9] 'gud-break)        ; 소스창에서 바로 브레이크포인트 설정
(global-set-key [f10] 'gud-next)        ; 현재 라인 실행하고 다음 라인으로
(global-set-key [f11] 'gud-step)        ; 현재 함수안으로 따라 들어간다
(global-set-key [(shift f11)] 'gud-finish) ; 현재 실행중인 함수 리턴후 멈춤
(global-set-key [(shift f10)] '(lambda () ; 현재 커서까지 실행하고 멈춤
                                (interactive)
                                (call-interactively 'gud-tbreak)
                                (call-interactively 'gud-cont)))

흠 recenter-top-bottom 을 매번 불러서 커서를 화면 중앙으로 유지하는 것도 편할거 같은데 아직 시도는 안해봤다. 지금도 그렇게 불편하진 않다..


아래 스샷처럼 여러 윈도 같이 띄우기

(setq gdb-many-windows t)

내가 원하는 윈도를 따로 프레임으로 띄우기
내 모니터가 작아서 저렇게 놓고 디버깅하긴 좀 불편하다. 자주 쓰는 gdb 콘솔윈도우는 따로 프레임으로 뽑아내서 아래 그림처럼 alt-tab 으로 전환해가면서 사용하는게 더 편하다.

조렇게 쓰려면 위쪽 gdb 창에가서 C-x 5 2 를 누르거나 아니면 GUD 메뉴를 써먹자.
따로 뜬 프레임만 닫을때는 C-x 5 0

간단한 .gdbinit 사용
정말 최소한의 것만 적자면

1. pretty print 켜주고,
   
2. emacs 상에서 M-x gdb 로 gdb 띄울때 매번 arg 세팅을 피하기 위해서 set args 해주고
3. 몇몇 중요한 함수들 브레이크를 미리 잡아둔다.

정도... 예를들어 .gdbinit 을 요런식으로 만들어주자.

set print pretty on
set args -B 200 --frames 5 -o /tmp/output.264 /tmp/foreman_352x288_30fps_449.yuv 352x288
b x264_me_search_ref

어떤 타입의 정보를 자주 살펴봐야 할때
gdb 의 print 명령이 꽤나 좋지만 아주 복잡한 구조체가 있고 그중 일부 멤버만 디버깅에 필요하다면 매번 print 하는건 상당히 귀찮다. 아래에 언급한 STL 디버깅 스크립트 처럼 gdbinit 안에 적당한 디버깅용 함수를 만들어서 이걸 이용하는 방법도 있지만 대부분의 경우 가능하면 소스안에 포함하는게 좋다고 본다.( 물론 STL 은 내부구현이 가려져 있으니 소스내에서 뽑는건 오히려 좋지 않겠지, msvc 도 유사한 기능이 있을테니 이런건 디버거 레벨에서 처리하는게 맞을듯) 예를들어 아래 같은 코드가 있으면

디버깅시 int 값이 필요할때마다 gdb 상에서 call dump_int(foo) 를 통해서 값을 출력해볼수 있다.

좀더..

• 그외 http://oldpie.yoonkn.com/cgi-bin/moin.cgi/using_GDB 에는 적어뒀지만 command 가 상당히 자주 쓰이는 편인데.. 이건 나중에 위키에 올릴때 다시 정리하자.
• 보통 복잡한 구조체더라도 관심있는 멤버는 몇 안되는데.. 적당히 걸러서 보여주는 함수를 만들어 쓰는 경우도 있다. STL 을 풀어서 보여주는 http://www.yolinux.com/TUTORIALS/src/dbinit_stl_views.txt 등이 좋은 예... 아직 써보지는 않았다. STL 내부를 까보면서 까지 디버깅해야 할 상황이라면.. 끔찍하군.
• http://www.yolinux.com/TUTORIALS/GDB-Commands.html 가 깔끔하게 잘 정리된듯. 위 STL 풀어주는 함수정의도 이 링크에서 발견.
  
  
  
  
  
  
  

윈도머신을 ssh 로 관리하기

http://www.oreillynet.com/onlamp/blog/2008/06/ssh_in_to_microsoft_windows.html?CMP=OTC-6YE827253101&ATT=ssh+in+to+Microsoft+Windows

지금 쓰고있는 윈도머신이 없어서 테스트는 안해봤다. 저글에 소개된 freeSSHd 는 전에 한번 써본것 같은데 기억이 안나네. 다운만 받고 설치를 안했었나?

어쨌거나 이런게 있으니 기억해두자. 위키에 적기 애매한 링크라 여기 적어둔다.
뭐 사실 적어는 두지만 내가 이걸 쓸것 같지는 않다. rdp 가 쓸만하니까..

실행파일 안에 파일 집어넣기

http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967

흠 재미나는 방법이구나. 아래 댓들에도 나왔지만 나라면 재미없게 덤프떠서 변수 하나에 바이너리 때려박는 .c 파일을 만들었을텐데 위에서 소개된 방법은 정말 묘하다.

boost test 프레임웍 최소한의 사용법

아 씨바 좃스팟이 로그인이 안되길래 일단 여기 적어둔다.
사무실에서 테스트해본거라 리눅스 환경.

Makefile 소스 보기

CC  = gcc
CXX = g++
LDFLAGS += -lboost_unit_test_framework

all: a.out b.out

a.out: a.o
    $(CXX) $^ $(LDFLAGS) -o $@
b.out: b.o
    $(CXX) $^ $(LDFLAGS) -o $@

%.o: %.cpp
    $(CXX)  -c $(CXXFLAGS) -o $@ $< -MMD
%.o: %.c
    $(CC)  -c $(CFLAGS) -o $@ $< -MMD

clean:
    -rm -f *.o *.d
    -rm -f core
    -rm -f a.out b.out

-include $(wildcard *.d)

a.cpp 는 워낙 간단하니 적지 않는다.

b.cpp 소스 보기

#define BOOST_TEST_DYN_LINK                         // 소스를 보니 boost_unit_test_framework 를 동적으로 링크하려면 이걸 디파인을 해줘야 하는듯.
                                                    // 실사용시라면 이자리 보다 Makefile 등에서 해주는게 맞겠지.
#define BOOST_TEST_MODULE test module name blahblah // 테스트 모듈의 이름을 define 으로 지정해 주는 모냥이군.
#include <boost/test/unit_test.hpp>                 // included 버전의 헤더를 쓴다면 링크를 피할수 있어서 편해지지만 빌드가 느려질거다

// 함수하나를 만들어서 자동으로 register 까지.
// 앵간한 경우라면 요 방법 하나만 알고 써먹어도 충분할듯.
// BOOST_AUTO_TEST_CASE 매크로를 이용해서 test case 를 추가.
BOOST_AUTO_TEST_CASE(test_sucks)
{
    BOOST_CHECK(1);                          // assert 와 같은놈 참이면 pass 거짓이면 fail
    BOOST_CHECK_EQUAL(1,1);                  // 두 인자 동등비교. 이게 굳이 필요한가? BOOST_CHECK 하나로 충분한거 아닌가
                                             // 어쨌건 요런놈들을 test tools 라고 하는데 boost/test/test_tools.hpp 를 읽어보자.

    int i = 0;
    BOOST_TEST_CHECKPOINT("before divzero"); // 신기하구나. 시그널이나 트랩등이 걸린 경우는 가장 마지막 CHECKPOINT 를 찍어준다. 의심나는 구간 앞에 박아두면 된다.
    i = 100 / i;

    BOOST_TEST_MESSAGE("you sucks");         // 찍혀야 하는거 아닌가 안찍히네
                                             // 아.. 이놈을 빌드해서 나온 파일을 실행할때 --log_level=all 이란 옵션을 주면 된다.
                                             // 또는 환경변수에 BOOST_TEST_LOG_LEVEL=all 를 줘도 같은 효과.
                                             // boost test 의 문서중 parameters 라는 부분을 찾아 읽어보자.
}




// 테스트 스위트를 만드려면 BOOST_AUTO_TEST_CASE() 와 BOOST_AUTO_TEST_SUITE_END() 매크로 를 쓴다.
// 스위트까지 만들어서 테스트를 할일이 있을까? 흠 fixture 를 써야 할 경우라면 필요하겠군.
BOOST_AUTO_TEST_SUITE(suite)

BOOST_AUTO_TEST_CASE(hello_suite)
{
}

// 중첩도 가능
BOOST_AUTO_TEST_SUITE(suite)

BOOST_AUTO_TEST_CASE(hello_inner_suite)
{
}

BOOST_AUTO_TEST_SUITE_END()

BOOST_AUTO_TEST_SUITE_END()




// 좀 복잡한 테스트 스위트
BOOST_AUTO_TEST_SUITE(suite2)
struct adder {
    adder()  { BOOST_TEST_MESSAGE("setup fixture"); }
    ~adder() { BOOST_TEST_MESSAGE("teardown fixture"); }
    int add(int x, int y) { return x+y; }
};

BOOST_FIXTURE_TEST_CASE(test_adder_1, adder)
{
    // adder 의 non-private 멤버에 바로 접근이 가능
    BOOST_CHECK_EQUAL(add(1,1),1);
}


BOOST_AUTO_TEST_SUITE_END()

몇가지 포인트만 적어보면

• header 파일을 인클루드 할때 included 아래의 헤더를 가져오면 이놈이 main 을 가지고 있어서 boost_unit_test_framework 를 링크할 필요가 없다. 단 이런짓을 하면 안그래도 느린 빌드속도가 더 느려질테니 불편해도 링크를 해서 쓰자. 이내용은 boost test 문서중에 FAQ 에 들어있다.
• 리눅스 환경에서 처음 빌드했을때 링크에러가 자꾸 났었다. 적당히 소스를 뒤져보니 BOOST_TEST_DYN_LINK 를 디파인해주지 않아서 생긴 문제. 물론 so 버전 말고 .a 를 링크해줘도 해결됐었겠지. 어쨌거나 이부분은 좀 거슬리는데.. 윈도환경에서도 테스트를 해보고 그럴듯하게 빌드시스템(Make, Cmake) 로 뽑아내는 방법을 찾아야겠다.
• 위에서 적은 경우는 BOOST_AUTO_TEST_CASE 를 이용해서 함수를 정의하면서 register 까지 해버린 경우인데 사실 코딩하다 보면 함수 정의와 register 를 따로 해야 하는 경우도 생기겠지... 난 이런식으로 테스트 코드와 릴리즈 코드가 섞이는것을 좋아 하지 않으니 그런 경우는 아예 적지도 않았다. 릴리즈 빌드에 테스트코드 넣는것은 아직 거부감이 든다.
• BOOST_CHECK_BLAHBLAH 류의 매크로가 여러가지 준비되어있다. 이놈들을 test tools 라고 하는데 위 주석에도 적었지만 boost/test/test_tools.hpp 를 참고하자.
• 테스트 스위트 는 BOOST_AUTO_TEST_SUITE 와 BOOST_AUTO_TEST_SUITE_END 매크로로 정의되며 중첩도 가능하다.
• 테스트 스위트를 쓴다면 결국 픽스쳐를 쓴다는 소리. boost test 의 샘플을 가져다가 잘 도는것을 테스트해봤는데 프리프로세서 풀어보고 소스를 읽어보려고 하니 좀 복잡하네.
  
• 위 예제에서는 스위트 안에 adder 란 클래스와 test_adder_1 이란 픽스쳐를 만들었는데 만약 test_adder_2 라는 픽스쳐를 만들어서 테스트를 하게 되면 adder 가 두번 생성 ( 정확히는 boost test 시스템이 만든 adder 의 서브클래스겠지 ), 이 되서 각각의 fixture 마다 다른 인스턴스를 보게된다. fixture 마다 완전히 독립되었다는것 명심하자. 하나의 인스턴스를 순서대로 이어받는식으로 작성이 가능한지는 모르겠다.
• 위에 적은 내용을 확인하려면 BOOST_TEST_MESSAGE 등의 매크로를 쓰면 된다. 기본값으로는 이걸로 메시지를 뿌려도 안찍히니 boost test 에 parameter 란걸 조정해줘야 하는데 실행파일을 실행할때 --log_level=all 라는 인자를 주거나 BOOST_TEST_LOG_LEVEL=all  란 환경변수를 주거나 하는등의 방법이 있다. 이내용은 boost test 문서중 parameter 를 참고.