rein’s world

현재는 과거로부터 추론 가능하다

오늘 새벽 1시경에 내가 하던 짓

Image from http://xkcd.net 

under CCL 2.5-attribution non-commercial

…그리고 나서 중편 애니메이션 한 편, 책 두 권, 그리고 나서도 라노벨 반 권을 읽고야 잠이 들었다. 토요일에 12시간 일하고(…) 일요일에도 4시간 일한 사람이 저런 짓을 하면 월요일날 몸 상태를 짐작할 수 있다.

log4cxx 0.10.0 RC 6

뭔가 RC 상태가 계속 지속되는게 불만족스럽긴 하지만, 그렇다고 첫번째 Apache Release가 될 애를 그냥 내놓고 싶지않은 개발자들의 심정을 이해 못할 것도 아니다. 일단 빌드만해보고 링크해서 잘 도나 보기만. RC가 끝나야 main-trunk에 commit을 하던가 말던가…

대가의 글이란

한 분야에서 대가(master)라고 부를만한 사람의 글은 세 줄정도만 읽어봐도 대가다 라는 것을 느낄 수 있다. 적당한 숙련자가 수 페이지의 아티클을 만들어낼 내용을 몇 단어로 표현할 수 있다는 점에서 Hurb Sutter나 Bjarne Stroustrup은 대가다.

그렇지만  C++에 익숙해지기 위해서 이런 대가급을 따라잡으려 노력해야하는건 좀 피곤한듯. 뭐 그래서 어제 람다와 클로져가 문법적으로 쉽게 표현되는 걸 환영한 것이긴 하지만…

ps. 마지막 부분의 내용을 한 번 더 곱씹자면, 내 생각을 표현하기 위해선 몇 페이지의 글이 언제나 필요하다는 점에서 아직 난 멀었다고 채찍질해야할 필요를 너무나 느낀다.

밑의 글을 쓰고나서, 집에서 나와 코엑스로 향했음. 오늘의 목표는 맥북! 생애최초의 노트북을 한 번도 안 써본 마지막 major(?) OS로 해보자! 를 외치며 구입하러 왔음

사려고 한 물건은 새로 출시된 맥북(흰 색) 중에 제일 싼 애 — 13″ 화면에 DVD write 기능이 없는 콤보 드라이브랑, 120GB하드, 1GiB 메모리에 Core2Duo 2.1Ghz 인 녀석. 메모리가 확실히 적어보여서 1GiB 추가 구매할 생각으로 갔음

학생 할인을 받고 싶은데, 그러면 카드를 분할해서 구입하는 꼼수는 안통하는 듯 해서, 오프라인 매장으로 갔는데 복지카드 + 그냥 카드로 결제까지하고, 직원이 메모리를 찾으러 뒷문(?)을 열고 들어가더라…

근데 이뭐(…). 메모리 없다고 어찌할꺼냐라고 하길래, 일단 구매 취소하고, 카드 결제 취소 확인하고, 메모리 들어오면 알려달라고 하고 연락처 남기고 돌아왔음 -_-

지름신 강제송환? 과연 재소환 될 것인가!(…)

ps. 서점에 가보니 지속적인 통합이 출시되어있었다. 번역질도 좋고해서 회사 사무실 이전이 끝나면 주문해야겠음. 지금은 접견실도 철수해버리고, 이사 직전의 일주일간은 택배를 쉽게 못 받을 상황

Hurb Sutter의 블로그인 Sutter’s Mill에 이런 포스팅이 올라왔음

The ISO C++ committee met in Bellevue, WA, USA on February 24 to Mar 1. Here’s a quick summary of what we did (with links to the relevant papers to read for more details), and information about upcoming meetings.

Lambda functions and closures (N2550)

For me, easily the biggest news of the meeting was that we voted lambda functions and closures into C++0x. I think this will make STL algorithms an order of magnitude more usable, and it will be a great boon to concurrent code where it’s important to be able to conveniently pass around a piece of code like an object, to be invoked wherever the program sees fit (e.g., on a worker thread).

C++ has always supported this via function objects, and lambdas/closures are merely syntactic sugar for writing function object. But, though “merely” a convenience, they are an incredibly powerful convenience for many reasons, including that they can be written right at the point of use instead of somewhere far away.

요약하자면 지난 ISO C++ commitee에서 승인된 C++의 새 명세 중 하나로 lambda와 closure가 추가되었다는 것. 이제 예전에 BOOST PP를 사용해가면서 rein이 반 어거지로 구현했던 C++의 closure 구현은 삽질이 되는 날이 다가오게 되었다. (좀 근 미래의 일이긴 하지만 그래도 미래의 일이라는데 위안을)

일단은 Java의 익명 함수나 C#의 delegate 비슷한 기능을 위해서 boost::lambda 를 쓰거나 rein이 한 것처럼 closure 를 정의하는 삽질을 안해도 될 듯함.

여튼 이 얘기를 IRC에 붙여놓고 나온 Berryz WebShare 개발자 채널의 반응 (길어서 접었음)

계속 읽기: “C++ 0x 새소식 - lambda 와 closure” »

WordCamp Dallas 에서 WordPress 2.5 가 릴리즈되었습니다.

그렇지만 전체 열려있던 티켓 중 1/4 가까운 양이 처리되지 않았는데, 이런 식으로 릴리즈 되는건 약간 달갑지 않기도 하군요. 뭐 그래도 2.4 버젼을 건너뛰고, 3 차례의 Release Candidate 가 나온 후 최종 버젼이 공개되긴 했습니다.

이제 선택 가능한 관리자 메뉴(Fresh, classic 2종의 색상 테마는 기본 제공), 편집가능한 대쉬보드나 내장된 갤러리 기능 등 “블로깅 편의성”에 중점을 둔 2.5 버젼을 아마도 안정적으로 사용할 수 있게 되었습니다.

ps. 그렇지만 열린 티켓(issue? ticket?)이 좀 남아있는 관계로 머지 않은 시간 내에 2.5.1 을 보게 되지 않을까 합니다.

뭔가 좌절스럽다. 아무리 현재 구현인 Flash 9 / ActionScript 3.0이 아니라지만 (Flash 8/ActionScript 2.0임) 이렇게 쓰기 괴로운 스크립트 언어는 처음이다. Python 을 처음 접했을 때 느꼈던 편안한 프로그래밍 같은 거랑은 수억 광년 떨어진 무언가인 느낌

Class 는 무조건 별도의 파일로

.fla 에서 class 키워드를 썼더니 — 밑에서 언급하는 문제를 검사하려고 — class는 외부에 선언해라! 라는 오류 메시지만…

Class 는 하나의 파일에 1개만

x.as 에는 class x만 선언할 수 있다. (이름이 맞지 않으면 그것도 오류) 그리고 x.as에 class a를 선언하면 안된다는 오류를 볼 수 있다.

Sibling member function을 함수 포인터를 통해 호출할 때 비정상 동작

이거 덕분에 2시간 날렸다. 책임져라 Adobe. -_-

this pointer(?)의 scope는 함수 포인터를 통해 멤버 함수가 호출된 순간(…)까지만 유지된다. 예를 들어서

class A {
    private var n:Number = 1
    private var f:Array = [ f0, f1, f2 ]

    public function f0():Boolean { return true }
    public function f1():Boolean { return this.n == 1 }
    public function f2():Boolean { return f1() }

    public function f3():Boolean { return this.f[0]() }
    public function f4():Boolean { return this.f[1]() }
    public function f5():Boolean { return this.f[2]() }
}

가 있다고 치자. A의 instance를 만들고 f0~f5 까지 호출하면 어떤 결과가 나올까? 프로그래밍언어에 조금이라도 익숙하다면 모두 같은 결과(true)가 나올 거라고 생각할 것이다…

그러나 ActionScript 는 기대를 저버리지 않고(…) 다음과 같은 결과를 내놓는다.

truetruetruetruefalseundefined

…처음 4개는 결과가 제대로(혹은 예상대로?) 나왔다. 그렇지만 f4를 호출했을 때 this 포인터가 함수 안까지 전달이 되지 않아서? 해석이 되지 않아서? 여튼 this 포인터를 f1/f2이 제대로 받아들일 수 없는 형태로 함수가 호출되고, false, undefined라는 정말 색다른(…)결론을 내려준다. f3의 결과가 제대로 나온 것은 아마 f0가 this를 참조하지 않아서라고밖엔;

이런 형태의 코드를 짜고 있었는데 this가 참조되지 않을꺼라곤 상상도 못했는데, 여튼 그런결과를 내서 저런 류의 함수에 첫번째 인자로 this 에 해당하는 값이 언제나 전달되게 수정했다.

사용기라고 하니 뭔가 거창하지만, 오전에 Flash CS3 trial을 받고, 오후에 코드 제네레이터 초안까지 잡았으니 일단 사용기는 사용기.

C++과 통신할 수 있는 ActionScript 모듈을 만들어내는게 목표였는데, 사용하다 괴로운 점이 한 두가지가 아니었다.

약 타입 언어주제에 제한이 많다

완전히 동적 타입이라 사용하기 쉬운 것도 아니고, 그렇다고 함수형 언어의 강력한 정적 타입 검사랑은 비교도 안되는 주제에 이런 저런 안되는게 왜 그리 많은지…

게다가 타입 지정이 기본도 아니라는 것은 참 아스트랄

텍스트 기반의 소켓 구현

사용해야 했던게 Flash 8 / ActionScript 2.0이라소 binary socket이 없다. 그럼 무슨 짓을 해야하는가 하면…

• Binary <-> text 변환을 수시로 한다
• 한 번에 전송되는 단위는 Null-terminated string 1개
• 다만 이렇게 간단한 데이터 구조라 버퍼링 같은 것은 밑단에서 해결
• 사용되는 문자열은 기본적으로 UTF-8

Binary -> Text 변환에 UTF-8을 더하면(…), 안정적으로 보낼 수 있는 binary–to–text 변환이 아주 적은 수로 줄어든다. UTF-8의 경우 각 바이트의 처음 몇 비트만 보면 이게 연속인지, 끝인지 파악할 수 있는데 (물론 첫 바이트로 다 알 수 있기도하고), 단순히 8bit을 다 쓰는 인코딩을 했다간 이게 뭐가 날아갈지.

게다가 \0 이 전송되면 그걸로 메시지 하나가 종료… 일단 뼈대로는 구글 차트에서 사용되는 8bit 중 6bit을 쓰게해주는 녀석을 생각 중.

계속 읽기: “Flash ActionScript 사용기” »

좀 더 명확히 하자면 production level code 101 이라고 해야겠지만.

• TCP가 믿을 수 있다고(reliable)하지만 이건 “연결이 살아있으면 언젠가는 전송될 수도 있다” 란 의미다. 허술한 추상화에 속지 말 것
• TCP 소켓에 send를 했을 때, 해당 함수 호출로만 전부다 전송될 거라고 절대로 믿지 말아라 — 반환값을 확인하고 적절한 처리를 해줘라
• TCP 소켓에서 recv를 했을 때는 반드시 버퍼링을 해야한다 — 절대로 특정 길이만큼은 올거라고 가정하지 말아라. 특정 길이보다 길게는 안 올거라고 믿어서도 안된다

얼마 전에 세번째 항목이 고려되지 않은 코드를 봐야했는데(…), 참 보고있기 괴로웠다.

recv를 하면 크게 세 가지 경우가 나온다

• (즐겁게도) 정확히 응용 프로그램에서 사용하는 단위로 메시지가 왔을 때 — 단순히 상위단에서 처리하게 해주면 끝
• (불행히도) 응용 프로그램에서 필요한 길이보다 짧게 왔을 때 — 적당히 보관(…)해주고 다음 TCP 세그먼트 가 오는 것을 기다려야한다
• (역시 불행스럽게도) 응용 프로그램에서 사용하는 것보다 긴 길이가 왔다면, 메시지를 하나 처리하고 다음 메시지 처리를 이 세 가지 경우에 맞춰서 다시 처리해야한다

길이의 가정을 하지 말아야하는 이유가 여기서도 마지막 항목 때문. 응용 프로그램에서 사용하는 메시지 길이가 짧다고 — 특히나 path MTU보다 작다고 — 그 메시지가 한꺼번에 올 수 있는 것은 아니다. Path MTU가 1000 bytes 메시지가 300 bytes 고라고 해도 메시지 4개가 사이좋게 뭉쳐서 오면(…), 4번째 메시지는 100 bytes만 버퍼에 남게 된다.

결국 최소한으로 잡아도 이런 메시지 처리 코드가 나오게 된다.

1. recv() 로 TCP 소켓에서 데이터를 받는다
2. 데이터 길이가 응용 프로그램 메시지 길이와 비교.
3. 필요한 것보다 짧으면 남은 데이터를 적당한 버퍼에 보관하고 다시 1로
4. ( 응용 프로그램에서 메시지 처리)
5. 4에서 처리 후 남은 부분의 길이를 받아온다.
6. 다시 2로 (1이 아님에 주의)

이렇게 하면 위에서 설명한 세 가지 경우가 대부분 처리 된다.

결론적으로 말하면,

TCP가 보장하는 부분은 매우 적다. TCP 세그먼트를 받아서 필요한 크기로 재조립할 생각을 하자

ps. 101 이긴 하지만 좀 추상적인 내용이다. 그래도 이게 네트웍 프로그래밍으로 toy program이 아닌 물건을 만드려면 필요한 “최소한”의 지식이라고 생각해서 끄적여본다.

WP 2.5의 RC 버젼이 리뷰 과정에 들어갔다고 함.

일단 로드맵은 이렇게 바뀌었다 — 출시예정일(?)이 2030년 만우절로(…)

아마 이번 RC 버젼이 순조롭게 리뷰를 통과한다면 빠르면 이번 주말이나 다음 주초, 늦어도 그 다음 주에는 최종 출시버젼을 쓸 수 있게 되지 않을까 한다. 원래는 3월 중순이였지만 결국 예상대로(?) 순조롭게 늦춰져서 4월 초에 발매되는건가…