Yagur의 Juggling

  생산성이 좋다고 하는 C#으로 제작된 Singularity란 OS의 아키텍처라고 합니다. C/C++과는 달리 버퍼 오버런 문제가 적은 언어인 C#으로 이루어져있으니 상당한 잇점이 존재할것 같습니다.

  30~40년된 기반기술로 부터 탈피해 새로운 OS를 만들고자 하는 40여명의 연구원들이 만들었다고 합니다. 학습용, 비상용 용도로 제공되는 RDK도 있다고 합니다.

 저와 지인들 사이에서 번역 공장으로 알려진 류광님의 C++Ox 미리보기입니다. 차기 표준에 관심이 있으신분들이 보시면 흥미로운것들이 많습니다.

1. 2007/11/11 C++0x(차기 C++ 표준) 미리보기 1, 널 포인터의 이름은 nullptr (4)
2. 2007/11/19 C++0x 미리보기 2, 오른쪽 꺾음괄호들(>>) (4)
3. 2007/12/04 C++0x 미리보기 3, 템플릿 별칭 (1부)
4. 2007/12/08 C++0x 미리보기 3, 템플릿 별칭 (2부) (2)
5. 2008/01/31 C++0x 미리보기 4, 새로운 열거형 (4)
6. 2008/03/09 C++0x 미리보기 5, 정적 단언문 (2)
7. 2008/04/01 C++0x 미리보기 6, 확장된 friend 선언
8. 2008/05/31 C++0x 미리보기 7, 가변인수 템플릿
9. 2008/08/21 C++0x 미리보기 8, 위임생성자
10. 2008/11/09 C++0x 미리보기 9, 상속생성자
11. 2008/12/31 C++0x 미리보기 10, 범위기반 for 루프
12. 2009/05/08 C++0x 미리보기 11, auto의 새로운 용법
13. 2009/06/27 C++0x 미리보기 12, 표현식의 형식을 알려주는 decltype
14. 2009/08/30 C++0x 미리보기 13. Concepts는 다음기회로(1부)
15. 2009/09/13 C++0x 미리보기 14. Concepts는 다음기회로(2부)
    

그 외에도 오른쪽 링크에 많은 사항들이 고려되고 있습니다. [open-std.org 링크]

Maya 2008 Released
마야 2008이 출시되었습니다.
8.5에서 버젼업 되어서 Maya 9이라고 출시될줄 알았는데, 이제 Maya 2008 이군요. 설마 DirectX SDK 처럼 Maya 2008 차기 버젼을 2008 June 이런식으로 명명하게 되는걸까요?(예전엔 8이 8.5로 버젼업해서 판매되었었죠.)
예전부터(Alias일때부터) 게임산업쪽의 지원을 위해 API에 몇몇 예제 플러그인 소스를 지원했었습니다. 머 vrml, ge2 exporter이런것들 말이죠. 하지만 위의 예제와 API Reference만으로는 진입장벽이 조금 높았던 기억이 있습니다.
API 와 MEL스크립트를 강력하게 지원해주는 마야는 어느 산업에서나 사랑을 받아왔던것 같습니다. 한국의 게임계에서는 3DMAX쪽이 사용자층의 비율과 충성도가 상대도 안될많큼 높습니다만, 그래도 언젠가 좀더 높은 비중을 차지하게 될날을 기대해 봅니다.
좋은 소식은 DirectX HLSL에 대한 공식적인 지원과 Mental ray 텍스쳐 베이킹 성능의 향상이라고 합니다. 8.0에서 커스텀 쉐이더를 플러그인 형태(cgfx와 ASHLI)로 지원했었는데요, 저 플러그인들의 성능향상인지, 아니면 내장된 특별한 기능(?)인지는 써봐야 알수 있을것 같군요.
쉐이더 저작툴은 다른것을 활용했었지만 마야에서 제공하는 기능이 만족스럽다면 마야로 옮겨 보는것도 나쁘지 않을것 같습니다. 어쨋던 프로그래밍 가능한 하드웨어 쉐이더를 사용하는 대세를 마야는 잘 따르고 있는것 같습니다.
새로운 기능보다 대부분 멀티코어를 지원함으로서 생기는 성능향상과 일반적인 마야 API의 성능향상을 통한 툴의 성능향상이 새버젼의 바뀐점들의 주류를 이루고 있습니다. 이제 쿼드코어도 나오고 메모리의 한계(기존 4기가)도 늘어나는 시점이니 당연할수도 있겠습니다.
뷰포트의 성능향상도 이야기가 되고있군요. 좀더 정확하고 빨라진 하드웨어 뷰포트는 작업자의 능률에 많은 영향을 미치니 새 버젼으로 갈아타야할 좋은 이유가 될수있을것 같습니다.
자세한 내용은 링크를 통해 보세요^^

Planet PostgreSQL에 떳군요.
Oleg Bartunov와 Teodor Sigaev가 만들고 공식 코어에 붙이는 일은 다른사람이 한것으로 보입니다.
일본어는 TSearch2에 확장해서 쓸수 있는것 같은데 한국어도 개발되면 좋겠군요.
유럽언어 전용 풀텍스트 형태소 해석기(Contrib Module) 였는데, 이젠 공식적으로 코어에 포함된다니, 유럽은 아니지만 한국어도 공식 포함되었으면 좋겠군요(그럴려면 한국의 오픈소스 개발 진영에서 기여를 해야할텐데 말입니다.)

Oleg와 Teodor의 사진을 찾을수 있었습니다.
Oleg와 Teodor가 전부 러시아인이라고 되어있는데 Teodor가 동양인이로군요(예상밖).

Star wars : The Force Unleashed - Euphoria Engine Tech Demo


케릭터의 본 시스템(래그돌)이 공중에 떠있을때나 무엇인가 매달려야 할때를 시뮬레이션으로
알수있군요! 애니메이터가 애니메이션을 만드는것이 아닙니다. 대단합니다.
Euphoria를 케릭터가 애니메이션되다가 블렌딩해서 쓸수있는것 같습니다. 언젠가 한번 쓸기회가 생겼으면 좋겠군요.

아래는 테크데모입니다.

NaturalMotion의 Euphoria 링크입니다[ L I N K ]

출처

평범한 자를 위한 성공 습관

1. 스스로 돕는 것만이 성공과 부를 얻는 길이다
2. 탁월한 존재가 되겠다는 열망을 품어라
3. 무엇을 하든 최고가 되어라
4. 일할 의욕이 일한 시간을 만든다
5. 병졸 신분에서도 장군의 꿈을 가져라
6. 지식과 경험을 총동원하여 집중하라
7. 실패한 경험이 없다면 결과물도 없다
8. 세심한 전문성이 승패를 좌우한다
9. 인덕을 쌓는 것도 성공의 자질 중 하나이다
10. 개인적인 비극을 발상 전환의 계기로 삼아라

11. 개인적인 이득을 떠나야 위대한 성과가 나온다
12. 앞서고 싶다면 기꺼이 불편을 감수하라
13. 어떤 희생과 고난도 감수할 각오를 하라
14. 기회를 붙잡으려면 관찰하는 자세를 가져라
15. 평범한 몰입이 비범한 재능보다 낫다
16. 규율있는 삶을 통해 자기 수양에 힘써라
17. 맡은 바 일에 최선을 다하는 데서 위안과 행복을 얻어라
18. 지혜의 주성분은 명랑함과 부지런함이다
19. 모험심과 용기는 성공의 필수 요소이다
20. 야망이 길을 터줄 것이다

21. 시행착오를 두려워하지 말라
22. 시간이 걸리더라도 자신만의 길을 개척하라
23. 작은 일들이 위대함의 씨앗이다
24. 무시해도 될 만큼 사소한 일이란 없다
25. 기회가 없다면 스스로 기회를 만들어라
26. 과감하게 결정하고 밀어붙여라
27. 어떤 대가를 치르더라도 경쟁자에게 배워라
28. 일단 잡은 기회는 놓치지 말라
29. 가치있는 목적, 결연한 의지면 충분하다
30. 타인에 대한 의무감도 불가능을 극복하는 힘이다

31. 모든 것을 제 힘으로 하는 습관을 들여라
32. 모든 길은 비즈니스로 통한다
33. 세상 탓을 하지 말라
34. 절대로 빈둥거리지 말라
35. 한번에 한 가지씩 완벽하게 처리하라
36. 미래의 이익을 위해 현재의 만족을 포기하라
37. 칼에 죽는 육체보다 돈에 죽는 영혼이 더 많다
38. 경험은 지혜의 또 다른 이름임을 잊지 말라
39. 나를 존중하지 않고서는 성공할 수 없다
40. 일단 무엇이 되겠다고 결심하면 모든 것을 걸어라

41. 아무 것도 아니기 때문에 무엇이든지 될 수 있다
42. 늘 거울이라고 생각하고 살아라
43. 인격은 최고의 자산이다.
44. 인격자와 독재자는 습관에 따라 좌우된다.

--- 새뮤얼 스마일즈, <인생을 최고로 사는 지혜(자조론) Self-Help> ---

실행파일의 DLL Depedency를 알고 싶을때 쓸수 있는 Utility입니다. [링크]

출처 KLDP 링크

UTF-8은 무엇인가?

무엇보다 먼저 UCS와 유니코드는 단지 정수를 문자에 할당하는 코드 테이블일 뿐이라는 것이다. 그러한 문자 혹은 문자 각각의 정수 값의 시퀀스가 어떻게 바이트 시퀀스로 나타날 수 있는 지에 대한 몇 가지대안들이 존재한다. 대단히 이해하기 쉬운 두개의 인코딩은 유니코드 텍스트를 2 혹은 4바이트 시퀀스의 시퀀스(sequences of either 2 or 4 bytes sequences)로써 저장한다. 이러한 용어에 관한 공식적인 명칭은 각각 UCS-2와 UCS-4이다. 다른 방법으로 명시되지 않는다면, 가장 중요한 바이트가 이들의 첫번째로 온다(Bigendianconvention). ASCII 또는 Latin-1 파일은 모든 ASCII 바이트의 앞에 0x00 바이트를 삽입하므로써,UCS-2 파일로 변환시킬 수 있다. UCS-4 파일을 원한다면, 모든 ASCII 바이트 앞에 그 대신에 세개의 0x00바이트를 삽입해야만 한다.

유닉스 환경에서 UCS-2(또는 UCS-4)를 사용하는 것은 매우 심각한 문제점을 불러온다. 이러한 인코딩을 가진 문자열들은 파일명과 C 라이브러리 함수 파라미터에서 특별한 의미를 갖는 '\0' 혹은 '/'와 같이 매우 광범위한 문자 바이트를 부분적으로 포함할 수 있다. 이에 더해, 대다수의유닉스 툴들은 ASCII 파일을 예상하며, 큰 수정이 없이는 16비트 단어들을 문자로 읽을 수 없다. 이러한 이유 때문에 UCS-2는 파일명과 텍스트 파일 및 환경 변수 등에 적합한 유니코드의 외부 인코딩(suitable external encoding of Unicode)이 아니다.

ISO 10646-1 의 Annex R과 RFC 2279상에 정의된 UTF-8 인코딩은 이러한 문제점들이 없다. 이것은 유닉스 스타일의 운영 체제하에서 유니코드를 사용하기 위한 의심할 여지없이 좋은 방법이다.

UTF-8은 다음의 성질을 갖고 있다:

• U+0000부터 U+007F까지의 UCS 문자들은 0x00에서 0x7f 바이트까지 쉽게 인코딩된다(ASCII와의호환성). 이것은 오직 7비트의 ASCII 문자들을 포함하는 파일 및 문자열들이 ASCII와 UTF-8 양쪽 모두에서 같은인코딩을 갖는다는 것을 의미한다.
• U+007F보다 큰 모든 UCS 문자들은 각각 독자적인 바이트의 시퀀스로써 인코딩되며, 이것들은 각각 가장 중요한비트셋(bit set)을 가진다. 그러므로 다른 문자의 부분에 어떤 ASCII 바이트(0x00-0x7f)도 나타날 수 없다.
• ASCII가 아닌 문자를 나타내는 멀티바이트 시퀀스의 첫번째 바이트는 항상 0xC0에서부터 0xFD 범위에 있으며,그것은 이러한 문자를 위해 얼마나 많은 바이트가 필요한 지를 가르킨다. 멀티바이트 시퀀스의 모든 이후의 바이트들은0x80에서부터 0xBF 범위에 있다. 이 때문에 resynchronization을 쉽게할 수 있고 국가에 구애받지 않고인코딩할 수 있으며 바이트를 잃어버리지 않게 된다.
• 가능한 모든 2³¹ UCS 코드를 인코딩할 수 있다.
• UTF-8로 인코딩한 문자들은 이론적으로 6바이트 길이까지 가능하지만, 16비트 BMP 영역 문자들은 오직 3바이트 길이까지 가능하다.
• Bigendian UCS-4 바이트 문자열의 정렬 순서는 보존된다.
• 0xFE 및 0xFF 바이트는 결코 UTF-8 인코딩에서 사용하지 않는다.

다음의 바이트 시퀀스는 한 문자를 나타내기 위해 사용한다. 사용되는 시퀀스는 그 문자의 유니코드 번호에 따라 달라진다.

U-00000000 - U-0000007F:	0xxxxxxx
U-00000080 - U-000007FF:	110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF:	1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF:	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF:	111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF:	1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

xxx비트의 위치는 이진 표기법에 의해 문자 코드 번호의 비트들로 채워진다. 오른쪽의 x비트는 별로 중요하지 않다. 그 문자의 코드 번호를 나타내는 오직 가장 짧은 멀티바이트 시퀀스만 사용할 수 있다. 멀티바이트 시퀀스에서 첫 번째 바이트의 왼쪽 1비트의 수는 전체 시퀀스에서의 바이트 수와 같다는 점에 주의하라.

예: "유니코드 문자 U+00A9 = 1010 1001"(저작권 부호)는 다음과 같은 UTF-8에 따라 인코딩된다.

11000010 10101001 = 0xC2 0xA9

그리고 문자 U+2260 = 0010 0010 0110 0000(저작권 부호)는 다음과 같은 UTF-8에 따라 인코딩된다.

11100010 10001001 10100000 = 0xE2 0x89 0xA0

이러한 인코딩의 공식 명칭과 정확한 표기는 UTF-8이며, UTF는 UCS Transformation Format을 의미한다. utf8혹은 UTF_8과 같은 다른 방법으로 UTF-8을 문서에 쓰지마라. 물론 인코딩 자체를 참조하지 않고 변수명에 참조할 경우에는괜찮다.

UTF-8의 디코딩 처리 순서에 있어서 중요한 점은 다음과 같다: 보안상의 이유 때문에, UTF-8 디코더는 한 문자를 인코딩하기 위해서 필요 이상으로 긴 UTF-8 시퀀스를 받아들여서는안 된다. 예를 들어 U+000A(라인 피드) 문자는 오직 0x0A 형식으로 UTF-8 스트림으로부터 받아들여야만 하며, 다음의 다섯가지와 같이 과도하게 긴(overlong) 형식으로 받아들여서는 안된다.

  0xc0 0x8A

  0xe0 0x80 0x8A

  0xf0 0x80 0x80 0x8A

  0xf8 0x80 0x80 0x80 0x8A

  0xfc 0x80 0x80 0x80 0x80 0x8A

가장 짧은 인코딩을 찾기 위한 UTF-8 서브스트링 테스트를 무시하기 어떤 과도하게 긴 UTF-8 시퀀스를 남용할 수 있다. 모든 과도하게 긴 형식의 UTF-8 시퀀스는 다음의 바이트 패턴 중 한 가지로 시작한다.

1100000x (10xxxxxx)

11100000 100xxxxx (10xxxxxx)

11110000 1000xxxx (10xxxxxx 10xxxxxx)

11111000 10000xxx (10xxxxxx 10xxxxxx 10xxxxxx)

11111100 100000xx (10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx)

정상적인 UTF-8 혹은 UCS-4 데이터상에서 코드 위치 U+FFFE와 U+FFFF 뿐만 아니라 코드 위치U+D800 부터 U+DFFF(UTF-16 대용)까지는 사용해서는 안 된다. UTF-8 디코더는 이러한 것들을 안전성을 이유로,잘못된 형식으로 혹은 너무 긴 시퀀스로 취급해야 만 한다.

Markus Kuhn의 UTF-8 decoder stress test file은 잘못된 형식을 갖는 과도하게 긴 UTF-8 시퀀스의 체계적인 모음을 포함하고 있으며 디코더의 강력함을 증명해준다.

링크 : http://www.koders.com/info.aspx?c=tools

종종 코드를 찾기 위해 들르는 곳입니다. 편리한 플러그인이 존재하는군요.

Search Koders.com faster without a browser

• The Koders search panel is displayed as a toolbal component within the IDE
• Search directly from the editor by right clicking on a term
• Localize the plug-ins for additional languages

Let SmartSearch™ work for you

• SmartSearch™ finds and recommends existing source code in real-time
• SmartSearch™ runs transparently in the background, as you work.

More Plug-in Information