2009년 4월 29일 수요일

유튜브 xcom 플레이 영상


Let's Play The X-Com Superhuman Antarctica Challenge
슈퍼휴먼난이도 에 아이언맨 플레이..
(xcomutil 안쓰면 난이도가 리셋되는 버그가 있는걸로 아는데.. 플레이보면 xcomutil 을 안쓴것 같은데 내가 수퍼휴먼을 해본적이 없어서 저 난이도가 정상인지 모르겠다)


헐 안그래도 xcom1 을 다시 하던 중이었는데 위링크가 보이더라.
나는 대원죽는게 싫어서 적은수만 쓰고 죽으면 로딩하는 편인데
거기다 소심해서 낮은 난이도로.
저친구는 사정없이 소모품으로 쓰네.
뭐 저게 정상플레이겠지.




Let's Play The X-Com Terror from the Deep Pacific Challenge
xcom2 도 플레이 했구먼.
그러고보니 xcom2 는 엔딩본적이 없는것 같다.

그외에도 let's play 로 검색해보면 잼나는게 몇개 뜬다.
특히나 판타즈마고리아... 헐. 이거 하고싶었는데 못해본것중 하나!



추가. xcom 플레이어의 let's play 시리즈 몇개 링크해둔다.


돼지독감

WikiPedia:Swine influenza
위키피디아:돼지 인플루엔자

http://en.wikipedia.org/wiki/2009_swine_flu_outbreak

2009년 4월 28일 화요일

박인권 - 여자전쟁

http://sports.khan.co.kr/

이런 미칠듯한 병맛 만화는 오랜만이네.
도저히 눈을 뗄수가 없다.





아이팟 터치 2.2.1 탈옥

QuickFreedom 을 이용.
이게 에러보고가 허접해서 몇번 실패
(프로그레스바가 진행안됨. CPU 도 idle 이라 진행되는 기미가 없음)

http://www.iclarified.com/entry/index.php?enid=3212
에 소개된 방법으로 재시도 하다 보니 요상한 에러가 뜨는것 발견
D 드라이브에 ipsw 받은게 문제라는걸 감잡고 ( 이런 제기랄?! 도스시절 CDROM 잡는것도 아니고 이게 무슨 개짓인지)

ipsw 를 C 드라이브로 옮긴후 QuickFreedom 으로 재시도.
QuickFreedom 이 하라는대로 따라하면 끝.

해킹펌을 준비해준후 아이툰에서 이놈을 이용해서 복원을 해야 하는데
이때 복원버튼을 시프트하고 같이 눌러야 하더라.
흠. 이거 누르기 전엔 몰라서 시간버렸다.

DFU 모드는 좀 병신같더라.
이모드로 들어갈때 화면에 뭔가 뿌려줬으면 편했을텐데
그냥 까만화면만 보여주고 있으니 이건 뭐 되는건지 마는건지.
아이튠을 띄워둔 상태에서 DFU 진입하면 다이얼로그가 뜨니 참고하자.


여기 정리 잘되있더라.
http://mymaru.tistory.com/167

그나저나 아이튠은 정말 보기 힘든 병신 어플.
이렇게 잘죽거나 또는 죽여도 안죽고 CPU 먹고있는 병신은 흔치 않지.


2009년 4월 25일 토요일

UFO: Alien Invasion xcom 오픈소스 구현체

http://ufoai.sourceforge.net/

이프로젝트 안지는 오래됐는데 설치해본건 오늘이 처음이네.
아주 잠깐 구경만 해봤는데 컨트롤이 좀 어색해서 손맛은 덜하더라.
그래도 그래픽도 괜찮고 다양한 무기에 ufopedia 도 그럴듯 하고..
역시 기대되는 프로젝트다.

아직은 오리지날 xcom 들이 재미는 더 좋은듯. 도스박스에 숨은 외계인 잡아주는 치트 정도만 쓰면 꽤나 쾌적한데.. 마지막으로 했던게 제작년쯤인거 같은데 가끔 생각나네.

ufoai 2.2.1 을 받아서 돌려본거고.. 아마 몇달 또는 몇년후에 다시한번 돌려볼일이 생기겠지.

2009년 4월 24일 금요일

jdee 2.3.6 설치

음 예전에는 걍 우분투가 깔아주는거 썼었는데 cedet 도 그렇고 몇가지 패키지를 벗어나 직접 깔다보니 뭔가 잘 안맞네. 별수없이 소스가져다 직접 설치했다. 간단한거지만 자바쪽은 내가 영 아는게 없고 설치문서도 친절하지 않아서 좀 고생했네.

  1. https://jdee.svn.sourceforge.net/svnroot/jdee/branches/2.3.6/jde/ 를 체크아웃 (svn) 나는 ~/.emacs.d/jde 로 받았다.
  2. ant 로 빌드 후 ant dist 해주니 dist 란 디렉토리에 필요한 파일들을 모아주더라. 요 dist 해주는걸 몰라서 한참 헤맸고 이 때문에 이글을 쓰고있다. 보통 make 쓰는 친구들은 install 이란 타겟을 만들어두는데 여기는 그런게 없네. ( 음 빼먹었는데.. ant 그냥 하면 안되고 몇가지 값을 바꿔줘야 하는데 이게 뭐드라 암튼 .프라퍼티 파일을 수정하면 되더라. 구조가 간단하니 그냥 열어보면 안다. 만약 처음에 이게 없으면 ant 한번 돌리면 생겼던가? )
  3. dist/lisp 을 로드경로에 추가하고.. 등등 나머지는 jdee 가 하라는대로 하면 된다. 참고로 내가 쓰고있는 설정은
    (add-to-list 'load-path (expand-file-name "~/.emacs.d/jde/dist/lisp"))
    (add-to-list 'load-path (expand-file-name "~/.emacs.d/elib-1.0"))
    (require 'jde)

jdee 세팅전에 넷빈즈를 잠깐 돌려봤는데 뭐 좋긴 좋더만. 이런게 공짜라니 우왕ㅋ굳ㅋ
그런데 아무래도 이맥스가 편해서 jdee 를 설치하게 됐다. 내가 자바를 쓸것도 아니고..


2009년 4월 23일 목요일

haskell 잠깐 둘러보면서 느낀것들 횡설수설

haskell 이 실용적인 언어는 아니라고 생각되서 앞으로 더 haskell 문서를 보게될지 모르겠네. 어쨌건 haskell 을 배우면서(배웠다기 보다는 정말 구경한거.. 그냥 지하철에서 문서좀 읽다 자다가.. 간단히 샘플몇개 코딩해본게 전부지) 내 코딩스타일을 바꿔야 할점들을 몇개 더 알게됐는데 정리해두자.

아 그전에 망할 모나드 트랜스포머.. 모나드 스택 은 킹왕짱좋은 개념이란건 알겠는데 결국 이산을 못넘은게 좀 아쉽긴 하다. 뭐 대강 왜 이친구들이 모나드를 스택식으로 쌓아올렸는지 뭐 그 필요성? 그걸로 얻은 것들? 뭐 그런것들에 대해서 냄새는 맡았지만.. 뭐 그걸로 얻는게 많다는것도 알게 됐지만 내눈엔 가까운길 놔두고 멀리 돌아가는 길로밖에 안보인다. 코딩을 이렇게 까지 복잡하게 해야 하는것에 납득할수가 없었다.

뭐 순수함수형 언어라는게 그렇더라. 순수함을 지키기 위해서 희생이 너무큰데 글쎄.. 그렇게 까지 지킬 필요가 있을까. 어차피 컴퓨터 라는 기계 자체가 펑셔널 하질 않은것을.


어쨌건 몇가지 적어둔다.
  • 먼저 pure functional 이란 말부터.. 가장 중요한것은 값이 일단 정해지면 절대 변하지 않는다는게 기본 개념이다. 물론 이게 되면 여러가지로 장점이 많지. 보통 함수형언어 책들 앞대가리들 읽어보면 이런 내용이 줄줄이 나온다. 그런데 내 결론은 그거 죄다 헛소리. 꿈꾸는 소리. 그러고 보면 haskell 이 여기까지 발전한게.. 정말 haskell 커뮤니티 애들은 천재들의 집단인거다.
  • 모나드.. 음 이게 정말 뭐랄까 대단하다. 모나드 자체는 정말 별거 아닌데 응용이 무지막지하게 나온다. 처음 이개념을 도입한놈은 천재중의 천재라고 할수 있겠네.. 어쨌건 실체는 뭐랄까.. 만들기 졸라 불편하면서 동시에 오사용을 막을수있는 매크로 랄까. 현재 언어스펙으로 나타내기 어려운 개념을 표현한다는 점에선 lisp macro 와 유사하지만.. lisp macro 가 만들고 쓰는게 상당히 자유로운것에 비해 monad 는 아주 번거롭게 틀에 같힌 형태?(좀더 좋게 표현하면 그 monad 가 나타내는 world 에 안전하게 격리된 상태 낄낄) 대신에 macro 를 많이 쓰는 경우 스파게티가 나오지만 monad 는 계층형태로 이쁘게 쌓아올리는 식의 코딩이 가능하다.( 모나드 트랜스포머.. ) 뭐 이렇게만 쓰면 monad 개념이 아주 좋은게 맞는데.. 뭐 자세히 지금 내 기분을 적기가 어렵지만 어쨌건 monad 는 코딩이 아주 번거롭다.. 이건 내가 C 식의 사고를 하기 때문인건데.. 뭐 어쨌건 monad 는 존나 좋은 개념. 하지만 나한텐(대부분의 다른 개발자들도 마찬가지라고 생각되는데) 아주 불편한 개념.

헐.. 글을 막쓰다 보니 주제를 벗어났네. 요점만 적자. 앞으로 내가 코딩하면서 몇가지 신경써줄것들이다.
  • pure code 와 impure code 의 분리. 이건 사실 굳이 함수형 언어 개발자가 아니더라도 몸으로 알고있는 사실. 하지만 haskell 의 경우 언어가 이런면을 강요하다 보니 좀더 분리에 신경을 쓰게 됐는데 이런식으로 철저히 분리를 하고 나니 코드가 좀더 유연해지더라. 이건 사실 모듈화를 잘하라는 진리와 상통하는 말이다.
  • typeclass 의 사용.  이건 결국 템플릿 메타 프로그래밍으로 이어지겠지. 그리고 데이타모델링에 OOP 를 피하는 좋은 수단이기도 하고. 이런류의 내용은 C++ 쪽 문서들에도 몇번 강조되고있는 글인데 haskell 로 좀 코딩하다 보니 감이 잡히더라. 단 글로 나타낼정도로 명확히 정리하지 못해서 좀 아쉽다. 뭐 내가 하는게 다 그렇지.
  • 위험한 코드는 아예 빌드가 안되도록. 이것도 당연히 이미 여러 C++ 문서에서 다루고 있는 것이지만 다시한번 느낀점이다. 컴파일러가 잡아주는게 가능한 문제라면 무조건 컴파일러가 잡아줘야 한다. 또는 컴파일러가 잡아주도록 만들어야 한다. 그냥 읽고 지나갔던 static assert 나.. 여러 템플릿 기법을 다시 둘러봐야 겠다.  난 static assert 를 잡느니 main 앞에 assert 를 모아두는걸 좋아하는 편인데.. 앞으론 좀 적극적으로 써봐야 겠다. 이미 boost 의 경우 유명해져서 이것저것 써도 태클 들어올일은 적을테고 말이지. 코드를 짤때 위험하게 쓰일 경우를 대비해서 주석한줄 달랑 적지 말고 최대한의 방어를 하자. 특히 C++ 클래스는 컴파일러가 말없이 만드는 코드들이 많고.. 또 타입캐스팅이 말없이 일어나는 경우가 많으니 주의 또 주의.
  • 최소한의 함수들을 만들어서 조립. haskell 의 compose 는 정말 쇼크였다. 일단 문법이 편히 받쳐주니 여러가지를 composing 해서, 또는 compose 를 염두에 두고 만들어봤는데 정말 그리 좋을수가 없더라. 아직 C++ 이 이런식으로 사용하기는 적절하지 않은데 뭐 다른 편법을 쓰더라도 이놈은 좀더 공부해둘 필요가 있다. 흠 그런데 이런식으로 코딩하려면 제네릭한 함수가 있어야 하고.. 결국 템플릿 메타 프로그래밍(evil)으로 빠진다.

그외.. 꼭 haskell 이라서 라기 보단.. haskell 쪽에 몇가지 굉장히 매력적인 라이브러리들(QuickCheck, STM, Parsec 등등)이 있는데 내방식대로 써먹을 방법을 찾아봐야겠다. 또 FRP 란놈도 좀 흥미가 생기던데 아직 구경도 안해봤다. 이건 좀 아쉽군..

아.. 그리고 순수함수형 데이타구조에 대한 글들도 좋은게 많던데 이건 좀 읽어봐야겠더라. 이친구들은 이게 성능이 나쁘지 않다고 말을 하던데 흠.. 사실 믿어지질 않네.

어.. 하나 더. haskell 의 중요한 특성중에 lazy 가 있는데 흠. 글쎄 난 이놈에겐 별 매력을 못느겼다. lazy 특성때문에 얻은 장점이 아주 많다는걸 알겠는데 ( 무한 자료구조 같은경우는 정말 깨더라. 여기에 리커시브까지 끼면 후럴... ) 이 코드가 실제로 어떻게 돌아가는지 상상이 잘 안되더라. 이것도 뭐 숙련도 문제이긴 헌데 나한테는 넘을수없는 벽이었다. strict 가 기반이고 lazy 는 선택적으로 쉽게 지원해주면 좋았을텐데.. 참고로 clojure 가 strict 가 기본에 lazy-cons 라는 적절한 놈을 지원하더라. 우왕ㅋ굳ㅋ
(사실 언어가 돌아가는 모양을 알아야 되겠다는게 선언적 언어인 haskell 에는 좀 안어울릴수도 있는데 알고싶은걸 어쩌랴? 적어도 메모리가 얼마나 쌓이는지는 알아야지)

추가로.. 맘에 안들던점. 망할 언어확장. haskell 98 이 오래된 스펙이라 몇가지 추가기능들을 확장이란식으로 제공하던데 이건뭐.. haskell 의 발전을 옆에서 지켜본 사람이 아니면 그런 확장이 있는것도 모를테고.. 아니 사실 이건 haskell 의 문서부족에 대한 불평이네. haskell 문서들은 그냥 레퍼런스거나 아니면 거창한 내용을 담고있는 논문레벨의 문서(확장가능한 익셉션.. 이건뭐 정말 깨더군. 글쎄 다른언어같았다면 그냥 언어차원에서 구현하고 이리쓰셈. 하거나 확장가능한 언어라면 라이브러리단에서 붙이고 친절한 튜터리얼을 줬을텐데 haskell 은 이게 부족해서 문서를 찾다보면 논문까지 도달하게 되더라. 꽥 아니 뭐 이게 더 나은 모양이긴 하지만...)..

윗문단 다시 정리하면 튜터리얼의 부재가 상당히 짜증났다. 몇몇 문서들은 이게 프로그래머(haskell 구현자가 아닌 haskell 유저) 보라고 쓴건지 수학자 보라고 쓴건지.. 용어는 다른 언어와 미묘하게 다르고 뭐 생소한 학문에서 따온 용어를 언어에 붙여넣은것도 있고 어쨌건 haskell 은 그들만의 언어라는 느낌이 강하다.

엇 그리고 보니 haskell 의 장점중 하나가 병렬성인데 이쪽은 전혀 안봤네. 이건 나중에 다시 한번 둘러보자..


음. currying 에 대해서도. 이것도 킹왕짱. 아주 끌리는 언어적 기능. 전에 ocaml 구경할때는 그냥 그런갑다 했는데 이번에 이게 얼마나 좋은지 느꼈다. 뭐 lisp 애들은 매크로로 만들어 쓰는거 같던데 헐. 어쨌거나 함수를 받아서 함수를 내놓는다는 그야말로 고차원적 코딩이 자연스럽게 이루어지는 기반이라고도 할수있는데 아쉽게도 현재 C++ 에서는 쓰기가 좀 애매하다. boost::bind 를 써서 흉내가 가능하긴 한데... 흠. 다음 표준에 람다가 어느정도까지 들어가는지 좀 확인해보고 고민해보자.













비쥬얼 스튜디오 2010 에서 과거상태로 되돌리는 디버깅(historical debugging) 지원한다는데? (managed)


흠 놀랍군. 이짓 하려면 vm 수준(이라기 보단 OS 레벨의 지원이랄까?)의 뭔가가 있어야 할텐데.. 그래서 vmware 에서 이미 먼저 보여줬고 뭐 ms 에서야 dotnet 끼고 하는거라 가능한거겠지. native 쪽에선 꿈도 못꾸겠지? 런타임만으로는 이런게 구현이 어려울테니.

ms, dotnet 죄다 나랑은 거리가 멀어서 걍 제목만 읽어두고 적어둔다.
역시 돈들인 환경이 좋긴 좋다.

다음번엔 다시 ms 기술기반으로 일해보고 싶군.

2009년 4월 22일 수요일

O3D, 구글의 인터랙티브 3D 플러그인 in 브라우저

이런 류의 플러그인은 여러번 시도가 있었으나 대세는 못되고 시들었지만 웹상에서 3d 지원이 필요한것은 부정할수없지. 잘난 구글이 얼마나 잘났는지 구경해보자.

리눅스에서는 직접 빌드해야 하는 모양이라.. 귀찮아서 직접 돌아가는걸 구경하지는 못했다. 우왕ㅋ굳ㅋ

2009년 4월 21일 화요일

unspecified_bool_type, safe bool idiom, C++ 에서 어떤 클래스를 bool 값으로 캐스팅하는 좀더 안전한 방법

boost 코드에 unspecified_bool_type 라는게 자주 나오는데 이게 뭔지 찾을수 있도록 실마리가 될 링크를 적어둔다.

The Safe Bool Idiom

나는 항상 명시적인 캐스팅을 하는 주의라 .valid(), .good() 등의 멤버함수를 두는 편인데 그렇지 않은 코드들도 자주 보이니 읽어두자. 이거 거꾸로 코드만 보고서 왜 이런 짓을 했는지 역으로 알아보는것은.. 내 능력으론 불가능 했겠지? C++ 도 오래된 언어라 여러가지 트릭이 많은편인데 그중 몇가지는 idiom 이란 거창한 이름으로 포장되어 있으니 가끔씩 둘러봐야 한다.

2009년 4월 17일 금요일

ubuntu 에서 firefox 창의 크기를 키웠을때 패널뒤로 숨거나 패널을 가리는 문제

이것도 뭐라 말하기 애매하구만.
꽤나 오래전부터 가끔씩 firefox 가 패널 영역까지 창이 커져서 짜증이 나는 문제가 있었는데
그냥 참으면서 써오다 오늘 기분 드러울때 이문제가 또 생기길래 검색을 해봤다.

http://ubuntuforums.org/showthread.php?p=4918486

compiz 와의 충돌이 문제였나본데
뭐 그냥 화면효과 끄면 되지만 건좀 썰렁할거 같고
언급된대로 컴피즈 설정 관리자 를 설치후 적절히 세팅을 해줬다.
이걸로 해결이 됐는지 모르겠네

다음에 이런문제가 또 생기면 compiz 꺼버리든가 하자.

이것도 꽤 연륜있는 버그.
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/240593
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/240736

2009년 4월 16일 목요일

c++ 로 간단한 웹을 붙일때 도움될 라이브러리들

우선 링크들만.
ghc 가 그나마 바이너리를 작게 뽑아주길래 happstack 으로 어떻게 해볼려고 했었는데
좌절하고 c++ 쪽 라이브러리들을 찾아본것.

내가 원하는것은 가능한 가벼울것. 스탠드얼론웹서버가 되야 할것. 기존 코드에 바로 집어넣는게 가능해야 할것.누군가에게 받은 html 을 바로 적용할수 있을정도의 간단한 템플릿(복잡한 UI 가 있는게 아니고 그냥 버튼 몇개, 테이블 몇개정도만 쓸꺼니까.. 그이상은 내능력 밖이다).

지금까지는 필요할때마다 대강 아주 무식하게 만들어 써왔는데 C++ web development framework 를 읽고 나서 관련 라이브러리를 한번 정리해봤다.
일단 wt 쪽을 좀 둘러볼 생각이긴 한데 아마 대강 보다 말것 같고 GNU libmicrohttpd
를 쓰게될것 같군... 아니면 직접 대강 만들어 쓰던가...


Wt, C++ Web Toolkit
GPL 또는 상용 라이센스. 이건 라이센스부터 에러인데 상용라이센스 지원하는걸 보니 개발은 계속될듯. 그런데 html 기반으로 개발하는게 아니라 위젯스타일이라..
뭐 어쨌건 상당히 재미있어 보이는 라이브러리. 이놈때문에 이글을 쓰게됐다.

CppCMS
이건 간단한 서버가 아니라 대용량 서버를 컨셉으로 잡았네.... 글쎄 이건 좀 애매하네.
이런 요구사항이라면 당연히 자바등을 택할텐데.
쓸일없을듯.

GNU libmicrohttpd
위쪽 두개와는 성격이 다른건데 뭐 내상황에는 이런놈이 더 어울린다.
임베디드 장비에도 박아넣을수 있을정도로 작고 C 에 LGPL 까지.. 아주 걍 딱이네.
사실 이건 몇달전에 한번 봐뒀던놈. 아래 위키 페이지에서 놀다보니 이놈이 제일 그럴듯해보였었지.

http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers
뭐.. 사실 여기 다들어있다.








c++ 대용량 파일처리에 대한 글, 그리고 그걸로 알게된 glibc Feature Test Macros 목록들

내가 대용량 파일을 리눅스쪽에서 다룰일은 없지만 뉴스그룹 보다가 눈에 띄길래 적어둔다.

http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/f4be9c112c05ef9b

-D_FILE_OFFSET_BITS=64 이 옵션은 gnu global FAQ 에서도 읽은 기억이 난다.
그때는 대강 넘겼는데 이게 fopen 류들을 fopen64 류 들로 바꿔주는 편리한 놈이네.

참고하자.
http://www.suse.de/~aj/linux_lfs.html
http://www.delorie.com/gnu/docs/glibc/libc_285.html

위와 같은 매크로는 glibc 쪽에서 제공해주는 기능이라고 볼수있는데 feature 라고 불리는듯 하네. http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#Feature-Test-Macros 에 리스트가 나와있으니 참고하자.

아 그리고 boost 에 mapped_file 이란게 있다는것도 알게됐는데 쓰고싶지는 않다.
소스는 봐둘만 하겠다.

암호관리를 lastpass 로

패스워드 관리를 지금껏
1. pwdhash내계정 설치본
2. keepass
3. 파폭암호관리자 foxmark 싱크 ( 그전엔 구글브라우저싱크 )

를 써왔는데 이번에 lastpass 로 갈아탔다.
전에쓰던 방법들은 아무래도 손이 가지만 암호정보가 내손에만 있었는데
lastpass 는 암호화 됐다곤 하지만 서버쪽으로 데이타가 전송이 되서 좀 껄끄롭긴 헌데..
늙었는지 수작업 좀 해주는게 영 짜증나네.

나온지 꽤 시간이 지났고 여기저기 리뷰에서도 관심을 받는 서비스이니만큼
한번 믿어본다...

이놈들이 보안처리를 어떻게 하는지는 FAQ 를 읽어보자.

2009년 4월 15일 수요일

도미노 피자 재판

http://gall.dcinside.com/list.php?id=pizza&no=9516

디씨는 삭제가 잦으니 백업.

펼쳐두기..


이게 진짠가.. 소비자를 병신으로 보는구만.

추가링크
http://gall.dcinside.com/list.php?id=pizza&no=9518&page=2
http://gall.dcinside.com/list.php?id=pizza&no=9519&page=2
이거 진짜였네..

하나더
http://blog.naver.com/lsulrich?Redirect=Log&logNo=100051606429



2009년 4월 14일 화요일

boost::asio 로 만들어본 간단한 콘솔 서버 ( async_read_until 사용예 )

서버를 짜다보면 간단한 제어 인터페이스를 노출할 경우가 많은데 보통 웹을 붙이거나 shell 을 흉내낸다. 이하는 asio 로 간단히 shell 흉내를 내는 코드를 만들어본것.

그냥 시간이 남아 간단히 만들어본건데 async_read_until 때문에 조금 고생했다.
이놈이 받는 버퍼는 다른 async 류 함수들과 달리 streambuf 더라.
나는 평소 C++ 을 쓰더라도 stream 쪽은 전혀 쓰질 않아서 이쪽은 하나도 모르는데.. 그래서 좀 애먹었다. 급한대로 streambuf 로부터 한글자씩 꺼내서 처리해봤는데 이건 좀 아닌거 같고 좀더 나은 방법을 뒤져봐야겠다.


이하는 main 을 담고있는 코드.
한줄을 받아서 한줄을 내놓는 최소한의 로직만 담고있는 클래스 echo 를 정의하고 이놈으로 console<echo> 인스턴스를 만들어 io_service 에 붙였다. 당연히 그냥 asio 공부하려고 만들어본 코드니 제구실하기엔 부족한 코드.

main.cpp..


아래는 console, session 을 담고있는 코드
console<T> 는 그냥 acceptor 라고 보면 된다. 특정 포트로 tcp 받아서 session<T> 를 까주는 놈. session<T> 는.. 결국 session<echo> 로 인스턴스가 만들어지는데 echo 가 가진 함수를 부르기 위한 소켓관련 작업들을 해주는 놈이다.

console.hpp..


이건 include 모음집. 네임스페이스 처리가 짱나서 하나에 몰아두고 쓰는게 좋지.

boostasio.hpp..



음.
좀더 뒤져서 asio::streambuf 에서 값을 꺼내는 방법을 하나 더 찾았다.
        asio::const_buffer data = buf_.data();
        const char* b = asio::buffer_cast<const char*>(data);
        const char* e = b + readed;
뭐 대략 이런식인데 이것도 통쾌한 방법은 아닌거 같다. 문서상 그리고 메일링에서도 istream 을 통해 꺼내오는것을 권장하는거 같은데.. iostream 쪽 코드는 영 손대기 그렇구만..
그리고 이런식으로 뽑아쓸경우 consume 으로 버퍼 비워주는것도 잊지말자.


추가.
ReadHandler 같은경우 error 와 readed 를 인자로 받는데 나는 error 나면 readed 무시하고 바로 에러를 내도록 했지만 경우에 따라 readed 를 먼저 처리하고 error 확인해야 할때도 있을거 같은데.. 이건 나중에 asio 를 정말 쓰게되면 다시 만날 문제겠지.






POCO C++ Libraries, 네트웍 위주의 크로스플래폼 라이브러리

http://pocoproject.org/
  • threads, thread synchronization and advanced abstractions for multithreaded programming
  • streams and filesystem access
  • shared libraries and class loading
  • powerful logging and error reporting
  • security
  • network programming (TCP/IP sockets, HTTP, FTP, SMTP, etc.)
  • XML parsing (SAX2 and DOM) and generation
  • configuration file and options handling
  • SQL database access (ODBC, MySQL, SQLite)

음 처음보는 라이브러리인데 네트웍 서버를 짜는데 유용한 기능들로 채워져있다.
이런 올인원식의 라이브러리는 별로 좋아하지는 않지만 엥간히 필요하다 싶은건 전부 들어있네. 이정도 규모 라이브러리를 이제 처음 듣다니.. 내가 너무 무신경했다.

기억해두고 눈치보다가 안정성이 검증됐다 싶으면 슬슬 공부해보자.

PS.
DB/암호화모듈/html,xml/소켓(http,ftp,smtp 프로토콜 은 고수준 지원)/쓰레드/cache 등등 정말 없는게 없네...



google perftools

http://code.google.com/p/google-perftools/

지금은 리눅스만 써서 valgrind 면 충분한데 혹시나 나중에 다시 윈도개발자로 돌아간다던가 할경우 진단툴로 써먹어보자. 본래 목적인 malloc 대용으로 쓸일은.. 아마도 없을듯. 아무래도 컴파일러가 제공하는 기본 malloc 이 더 검증이 잘 됐겠지?

달랑 링크만 적기 뭐해서 사용법이나 익혀보자 했는데 워낙 간단하니 그럴것도 없네.
기존 프로그램에 바로 적용해서 돌려보니 잘 돌아간다.



2009년 4월 13일 월요일

BCCL(boost concept check library) 첫인상

http://groups.google.com/group/comp.lang.c++/browse_thread/thread/ec94a39f632a6c05

할짓없으니 쓰지도 않을 다른 잡다한 언어들을 공부를 했었는데 밥벌이 도구 C++ 도 조금씩 따라가야겠군. 뭐 어차피 다음 표준은 멀었고 나온다고 해도 몇년간은 건드리지 못하겠지만.. 뭐 어쨌건 컨셉(이라기보단 BCCL)에 대해서 약간.

먼저 결론부터 말하면 병신같다.


용어부터 몇개 적어두자. 참고로 현재 컨셉에 대해 적는것은 BCCL (부스트 컨셉 체크 라이브러리) 쪽 문서를 대강 읽어버고 적는것으로 C++ 다음 표준에 대한 문서를 읽어본것은 아니다. 그건 나중에 구현이 나오면 다시 읽어보든가 하게 되겠고 일단 BCCL 쪽에서 말하는 용어부터.
  • concept - 타입이 지켜야 할 것들
  • model - concept 을 지킨 타입
  • refinement - 컨셉의 확장이라는데 잘 모르겠다. 다른 컨셉을 포함하는 컨셉이란걸까?
그리고 컨셉은 네가지 종류가 있는데
  • valid expression - 컴파일 되야 한다는거. 뭐 정의안된 함수를 부르거나 하면 안된다는 뻔한소리겠지.
  • associcate types - 글쎄 뭔지 모르겠네. 어떤 타입 T 가 어떤 컨셉의 모델이면 부수적으로 다른 타입들고 유효해야 하는데 그 성질을 말하는거 같다.
  • invariants - 이건 전혀 상상이 안간다. 불변의 런타임 특성이라.. 정적 특성도 아니고..
  • complexity guarantees - 이건 정말 이해불가능이었다.. 어떻게 언어차원에서 이걸 정의할수가 있는거지. 결국 이 단어때문에 낚여서 BCCL 문서를 보다가 때려치게 됐다. BCCL 은 이 네가지중 위 두가지.. 즉 신택스 쪽만 체크해준다. 뭐 당연한거면 당연한건데 낚였다는 느낌을 지울수가 없네.
이제 대강 컨셉이 뭔지 알게됐다. 어떤 타입 T 가 가질수있는 성질들을 적절히 분류해둔게 컨셉이라고 생각하면 되겠다. 아주 복잡하게 설명되어있는데 간단히 haskell 식으로 말하면 컨셉은 타입클래스와 유사한놈이라고 보면 된다. 모델은 물론 이 타입클래스의 인스턴스가 되겠고.. 리파인먼트는 클래스 상속쯤이되려나(내가 리파인먼트를 제대로 이해했다면)

문제는 haskell 같은경우 애초에 이런식(메타프로래밍)으로 만들어진 언어라서 언어적인 지원이 좋다는거. 어떤 타입이 어떤 타입클래스의 인스턴스여야 하는데 그게 누락되었다면 친절하게 이해갈수있는 에러메시지를 띄워준다.

그런데 C++ 은 그렇지 못하다.. 템플릿이 가장 짱나는 점이 에러가 나면 대책없다는거.( 사실 빌드 느린게 더 짜증난다... )
당장 stl 만 보더라도 쓰다가 에러가 나면 에러메시지를 읽느니 내가 뭘 잘못했는지 코드를 한번더 읽어보는게 디버깅이 더 빠르다. 이게 stl 같이 익숙한 표준 라이브러리니까 가능한거지 생소한 템플릿 라이브러리를 쓰다가 에러가 나면 욕밖에 안나온다.

그래서 나온게 컨셉 체크 라이브러리 인데.. 글쎄.. 이게 공부의 의욕을 부르는 좋은 라이브러리는 아니다. 드러운 템플릿/매크로 매직...


템플릿 관련 공부를 하다보면 항상 결론은 같다..
정말 믿을수있는 라이브러리라면 잘 공부한후에 쓰고(안쓰기가 힘들다. 템플릿만으로 가능한게 많으니)
내가 만드는 라이브러리는 절대로 템플릿 쓰지 말것.
타이핑 더 하더라도 유지보수 어려운 쓰레기를 만드는것보단 나을게다.


진짜 결론은 템플릿 공부하기 싫다는거 ㅎㅎㅎ

그래도 틈틈히 공부는 해둬야겠지..
다음엔 실제로 조금 코딩을 해봐야겠다.


http://www.boost.org/doc/libs/1_38_0/libs/concept_check/concept_check.htm
http://www.boost.org/community/generic_programming.html#concept

추가.
C++ 다음 확장에서 컨셉을 언어레벨에서 지원하는구만.
그럼 굳이 이런 매크로질을 공부할 의미는 없지.
이거 완존 뻘짓했네.
http://www.generic-programming.org/languages/conceptcpp/specification/
참고






2009년 4월 9일 목요일

boost::asio 를 이용한 tcp 연결 테스터 -- boost::bind 와 boost::function 을 이용해서 두 클래스의 의존성 줄이기

음 제목짓기가 애매하네.
어떤 서버가 tcp 연결을 몇개까지 받는지 테스트해야 했는데 어쩌다 보니 C++ 로 짜게 됐다.(ghc 의 소켓제한 때문에..)

워낙 간단한 코드라 평소 안하던짓을 한번 해보고 코드를 적어둔다.

소켓을 다룰때 많은 세션을 다루려면 이 세션을 다루는 매니저 클래스가 있을법 한데 보통 이경우 세션 클래스가 매니저 클래스를 알아야만 한다(커플링). 이걸 bind 와 function 으로 좀 오버해서 만들어봤다.

물론 이외에도 방법은 많고.. 실무에 써야 한다면 아마도 당연히 그냥 의존성을 그냥 두고 가거나 아니면 signal 류 라이브러리를 썼겠지. 아래 코드는 재미삼아 만들어본것에 불과하다.



펼쳐두기..


추가.
어쩌다보니 연결 받는놈도 필요해서 만들었다. 걍 같이 적어둔다.

펼쳐두기..