Chihun

애견 협회에 보면 페키니즈에 대해 이렇게  설명하고 있다.

“페키니즈는 불가사의한 성질과 자신감을 지니고 있으며, 매력적이고 아주 강한 독립심도 갖고 있다. 그들은 무엇에도 겁내지 않고 공격적이지도 않다. 또한 그들은 자신의 주인에게 우정과 편안함을 주는 것을 인생 최고의 유일한 목표로 삼고 있다.

이 견종은 독립심에 있어 사자를 닮아야 하고 예쁘고 우아하고 섬세하기 보다는 용기와 대담성을 가져야 하는데 가슴이 넓고 갈기가 풍성하므로 이러한 조건을 만족시키기에 충분한 외모를 갖추고 있다. 편식을 하는 경향이 있고 코를 심하게 골지만 아파트 생활에 적당하고 물건을 씹는 법은 없으며 큰 소리로 짓기 때문에 경비견으로 적당하다. 외부인에게는 경계심이 강하지만 주인과 그 가족에게는 충성스럽다. 반면에 자기 고집이 세어 제멋대로인 면이 있으므로 훈련을 시키는데에 어려움이 따른다.”

그러고보면, 집에 있는 흰둥이의 성격이 이해가 된다. 말 그대로 불가사의하고 고집이 세다. 그런데, 녀석은 겁이 좀 있어서 새로운 물건에 대해서는 경계를 하던데. 집에서만 너무 오래 지내서 그런가.

집 근처 매장에서 샀다. 내일은 안되고 모레 경남이 꺼 사면된다 캬캬

매장에서 살 수 있다면서! 그런데 몇군데 물어봤는데 다들 언제 살 수 있을지 모른다고 그러는거냐. 도대체 장사할 생각이 있는건가? sk에서 블렉베리 팔던데 요금제도 아이폰이랑 비슷하고. 대신 요금 거의 걱정 없이 한달 내내 메신저를 편하게 사용할 수 있다는 장점이…내년초에 최신기종 들여올거라는 소문도…사실 아이팟 터치 써보니 터치로 자판 누르기 정말 힘들었다.

아…그래서…언제 테크노 마트에서 살 수 있는 거냐고……….sk도 짜증나지만 kt도 짜증난다.

브라질에선 우승하면 소방차 타고 팬들한테 물뿌린다고 한다. 파리아스가 강력하게 요청해서 소방차 타고 카퍼레이드 했다고.

완전 간지폭풍이다! 아참, 사진에서 “감독” 글자 위에 오렌지 색 모자쓴 아이가 파리아스의 아들이다.

미안하다. 불법인건 알지만, 사진은 스포탈코리아에서 가져왔다.

우승이다! 파리아스는 포항의 영웅이다!

하나 사야겠다!
http://www.overdose.co.kr/zbxe/?mid=cook&search_target=title_content&search_keyword=%C6%A2%B1%E8&document_srl=40162

smalltalk의 syntax는 상당히 깔끔하고 parsing하기도 좋은 구조이긴 하다. 그런데 거기서 딱 2개가 까다롭고, 1개는 귀찮다.

1) block 내부의 bytecode를 건너뛰기 위한 jump류의 bytecode : 사실 jump자체가 필요없는데 control structure를 최적화 하기 위해 넣어 놓은 상당히 많은 수의 jump bytecode가 있긴 하다. 그런데, block에 속한 코드를 실행하지 않고 건너뛰기 위해서도 있어야 한다. 그래서 조금 귀찮다.

2) message cascading: stack machine에서 메세지를 받는 객체가 stack에 들어가고 그 위에 argument들이 들어가고 마지막으로 argument개수와 message selector가 들어간 다음에 메세지 호출을 실행하게 되는데, 이 메세지를 받는 객체를 미리 복제해서 stack에 두개를 넣어두어야 한다. {duplicate-invoke-pop} 이 시퀀스가 계속 반복되는데, syntax tree를 만들지 않고 parsing하면서 bytecode를 뱉어내기에는 상당히 까다로운 구조이다. 그리고, 마지막 cascaded message invoke의 결과가 전체 statement의 결과가 되기 때문에 마지막에는 duplicate가 없어야 한다. 아 짜증나.
3) super로 보내는 메세지: 대부분의 경우는 별 문제가 없는데 이 놈의 super가 cascading이랑 결합되면 꼬이기 시작한다. 도무지 깔끔한 방법이 떠오르지 않아서, smalltalk-80을 가장 충실히 재현한 squeak을 살펴봤더니 super에 대해 cascading을 못하게 애초에 막아놨다. 캭캭. 이해한다. 못하는 것은 아니지만 귀찮아서 안한거구나.

이것들만 없으면 parser도 상당히 깔끔해질텐데…지금 대략 구현한 것이 디버깅 코드 포함해서 lexer+parser 가 대략 1800라인쯤 된다. 저것들 때문에 추가된 것들이 상당히 많은 것 같다. 이대로 가면, vm포함해서 bootstrap하기 전까지 5000라인 안쪽으로 선방할 수 있을 것 같다. 가능할까?

|a|
[:b :c |  [ :d | ^b].value ]

여기서 ^b의 b가 바깥 block의  첫번째 block argument에 어떻게 binding되는지 정말 궁금했었는데.. 아래 링크에 재밌는 이야기가 있다.
http://c2.com/cgi/wiki?SmalltalkBlocksAndClosures

중간 쯤에 이런 말이 있다.

“The original implementation of blocks in Smalltalk was not exactly the same as closures. This was because block arguments were not the same thing as method arguments, but were actually temporaries in the method that defined the block. Thus, if you evaluated the block, the system did not allocate space for the arguments, but just reused some existing variables. If you called the block twice, the second time would just write over the variables used the first time. If the block called itself recursively, this would change the arguments that you used the first time.”

block argument를 메소드의 local variable로 만들어서 컴파일할 때 block literal을 생성하면서 거기다 binding시키는 방법이다. 이것이 st-80의 방법이다. st-80을 가장 충실하게 재현한 squeak도 마찬가지. 이렇게 하면, block을 recursive call할 수가 없다. 같은 variable을 사용하기 때문에. 저 링크에서 언급한 대로 squeak을 제외하고는 방법을 바꿨다고 한다. 어떻게 했는지는 모르겠다만.

지금은 거의 망했지만, 상당히 성능이 괜찮았던 st/x의 문서중에 다음 링크가 있다.

st/x context

block argument외에 바깥쪽 변수를 참조하는 block은 런타임에 context를 만들어서 참조하는 변수를 모두 가져오는 방식을 한다고 한다. 내가 생각해봤는데 이건 좀 낭비가 심한 것 같아서 버린 생각을 실제로 잘 쓰고 있는 것으로 봐서 쓸만할 것 같기도. 어차피 이런 식의 참조를 사용하는 경우가 거의 없기 때문에.

“On-the-fly Garbage Collection”, Dijkstra, 1978, ACM. 무서운 놈. Garbage collection이 있는 현대 언어의 대부분이 이 방식의 변종을 사용하고 있다. 그런데 이미 78년도에 나왔고, 그것도…garbage collection만을 위해서 만든 것도 아니고, 적절한 예일 것 같아서 garbage collection을 골랐다고. 역시 무서운 놈이다.

먼 옛날 부터 프로그래밍 언어를 만들고 싶었는데 이런 저런 이유로 계속 미뤄오다가, C++이랑 바인딩하기 편하고 스크립팅을 쉽게 할 수 있는 언어를 찾아도 마음에 드는 것이 없어서 만들기로 생각을  하였다. 뭐 내가 하는 것이 다 그렇지만 나의 로망인 smalltalk를 모델로 삼아 시작하였다. 당연히 object oriented  prog가 되어야 하고 콘솔 모드가 따로  있기를 원하기 때문에 smalltalk-80이랑 같이 little smalltalk도 참고하였다. 그리고 구현때문에 참조한 것이 io라는 언어랑 ruby. smalltalk-80을 제외하고는…현실적인 이유에 대해 적절한 타협을 많이 한 듯 싶다. 그마나 ruby는 좀 나은 편이다. (대신 성능을 희생했다) smalltalk-80은 타협을 적절히 했지만 참 절묘한 곳에서 했기 때문에 구조가 정말 아름답다.

완전한 object orientaion을 만들기 위해서는 meta level의 아키텍쳐가 있어야 하는데, 최근 유행하는 java나 c#등의 언어는 사실 1단계의 메타 레벨 밖에 없다. 그래서 할 수 있는 것이라고는 런타임에 오브젝트가 실행가능한 메소드 검사하는 것이나 변수 이름 보기나 추가하기 정도 밖에 없다. 뭐 그정도만 해도 충분 한 것 같더라만. 그래도 기분이 찜찜하고, 구현이 더러워진다. 객체의 class의 class의 class의 class의 class는 도대체 무엇일까…이렇게 길게 말하지 않아도, 객체의 class의 class는 무엇일까. 그것으로 뭔가를 할 수가 있나..라는 질문에 대답할 수  있는 언어는 사실 많지 않다. 개념이 단순해 질수록 구현이 정말로 단순해지고 깨끗해 진다. 예를 들면 little smalltalk의 4번째 버전은 콘솔용의 인터프리터와 컴파일러를 포함한 virtual machine 코드가 1800라인 밖에 안된다. 실제 기본 라이브러리는 2만줄 정도의 smalltalk코드로 되어 있다. (게다가 2만줄도 엄청나게 단순한 코드 밖에 없다.)
아래 그림은 smalltalk-80의 구현 메뉴얼인, blue book이라고 불리는 “Smalltalk-80, The Language and its implementation, Adele Goldberg and David Robson”의 책에서 가져온 부분이다. 그림에서는 간단한 기본 클래스 몇개와 클래스의 메타 레벨이 어떻게 서로 연결되어 있는지를 알려준다. 실선은 부모 객체(클래스)이고 점선은 자신이 속한 클래스를 가리킨다. 꾸준히 공부하지는 않았지만 이 모양을 처음 보고 이해하기 까지 5년 정도 흐른 것 같다. 지금도 모양은 이해하지만 구현은 또 다른 범위라 이 둘을 연결하는데는 종종 머리속이 혼란스러울 때가 있다. 하긴 smalltalk의 개발팀도 이 모양에 도달하기 까지 10년 가까이 걸렸다.

이젠 어떻게하면 만들 수 있을지는 알겠는데, 구현하다 보니 거추장스러운 것이 하나둘이 아니다. 특히 귀찮게 하는 것이 garbage collection인데, 처음에는 그냥 reference counting하면 되겠지..했지만, 회사에서 reference counting하는데 엄청난 오버헤드에 놀라서 안쓰는 것이 좋겠다고 생각했다. 아무튼 빨랑 만들어서 게임에 붙여야지.

8강전은 2차전 승부다. 원정 경기가서 1-1로 비기다가 한명 퇴장 당한 후 내리 실점 당해 1-3으로 졌다. 두번째 경기가 홈경기이긴 하지만 조금 힘들지 않을까 걱정했는데, 골 폭풍 몰아쳤다. 그래서 4-1로 이겨서 4강 진출했다! 저질 심판의 방해에도 불구하고 4골 모두 너무 멋있게 잘 들어갔다. 편파 판정을 넘어서버렸다. 스틸야드 (포항 홈구장)는 정말 멋진 곳이다. 올해 들어서 홈에서 경기를 졌던 적이 없는 것 같다. 작년에도 거의 그랬던 것 같다. 요즘 2만여명 정원의 경기장에 평균 관중이 15000명이란다. 분위기 좋겠다.
빨리 은퇴해서 포항으로 이사가고 싶다.

우왓! 부산이랑 2차전에서 5-1로 이겨서 컵대회 우승! 포항 올해 엄청난 득점력이구나. 이대로 K리그랑 AFC우승까지 가는거다!!

김기동 또 골넣었다. 올해 도대체 몇골째냐! 나이를 잊은 것 아닌가!!

경임이가 가계부 만드는데 불편함을 겪길래 하나 만들었다.  아래 그림 같은 모양인데 대충 있어야할 것만 있다. 편의기능이나 좀 더 추가하고 마무리 해야겠다. C#으로 만들었고 단순 무식한 프로그램이다. 아무리봐도 윈도콘트롤 중에서는 DataGridView가 가장 복잡하지만 가장 좋은 것 같다.

몇 주 전 쯤 주말에 뭘할까 고민하다가 뺑뺑이 돌려 고른 장소였다. 딱 2시간 돌아다니면 끝이다. 사실 2시간까지 걸리지도 않겠지만, 너무 더워서.. 한마디로 요약하자면..별로다.
 

보온병에 시원한 차를 담아서! 보온병이야 말로 근대 기술이 가져다 준 놀라운 발명품 중 하나다!

사진이 하나도 없으니 썰렁해서 몇장 올려놓는다. 귀찮기 그지없구먼.