lnf (lean and fast) type system

• C++ 이 싫음
• Go 좋음
• OpenGL + SDL 을 윈도에서 돌려야 하는 관계로 Go 는 피하고 싶음.
• Linux / 윈도, 적어도 이 두 가지 환경에서는 conditional compile 등등에 크게 구애받지 않고 빌드하고 싶음

최소한으로 생각하고 구현한 feature set 은 다음과 같다.

• 복수의 interface 를 구현할 수 있고 sub-typing 은 이를 통하여 지원함
• implementation 이 포함된 class 는 상속되지 않음
• length 값을 가지는 string type
• Go 의 slice type

잘 한 짓인지는 모르겠다. vala 도 꽤나 마음에 드는 상황이라...

젠투에서 긁어붙이는 용도

#!/bin/bash

mkdir /mnt/gentoo
mount -t ext4 /dev/sda3 /mnt/gentoo/
mount -t ext4 /dev/sda1 /mnt/gentoo/boot/
mount -t ext4 /dev/sda4 /mnt/gentoo/home/
mount -t proc /proc /mnt/gentoo/proc/
mount -t sysfs /sys /mnt/gentoo/sys/
mount --rbind /dev/ /mnt/gentoo/dev/

gnome 터미널에서 emacs를 쓰려다가 alt키로 고생하기

gnome terminal에서 emacs를 쓰려면 alt 키 이벤트를 그놈 터미널이 채가는 바람에 이맥스의 meta키가 제대로 작동하지 않을 수가 있다. 터미널에서 오른클릭하고 Show Menubar를 꺼버리면 된다.

우분투에서 trac 설치 중에 trac.*cgi 파일이 없어서 시간 허비하기

0.11 이후로 trac의 cgi 파일은 deploy를 통해서 생성해야 한다. 기본 패키지에 들어 있지 않다. 우분투 10.04 기준.

$trac-admin <env 디렉토리> deploy <cgi파일 만들 경로> 

Google I/O 2011: Memory management for Android Apps 요약 (draft)

• 메모리가 커진다고 해도 화면 해상도는 그 못지 않게 빠른 비율로 상승하므로 메모리 관리의 필요성이 줄어든다고 오판하지 말 것
• Gingerbread, Honeycomb의 주요 변경점
  • Gingerbread에서 concurrent garbage collection 지원 시작
  • Honeycomb에서 비트맵 데이터가 Dalvik Heap으로 들어옴
• 메모리 관리툴 사용하기
  • logcat
  • HPROF dump
  • MAT

Honeycomb에서 비트맵 데이터가 Dalvik Heap으로 들어옴

• 허니컴 이전까지는 비트맵 데이터는 native malloc으로 메모리에 잡히고, 이것의 레퍼런스를 담고 있는 오브젝트가 Dalvik Heap에 들어 있었음.
• 따라서 제대로 메모리가 GC 되기 위해서는, recycle이라는 메소드를 수동으로 호출하거나, finalizer에 의존해야만 했음.
• 또한 MAT 등의 표준적인 메모리 도구에 잡히지 않던 점이 개선될 것임.

MAT

• dominator 개념을 익힐 것 - GC에서 특정 obj로 연결되는, 지나가지 않으면 안 되는 entity
• MAT의 dominator 그래프 기능을 활용할 것

Android에서 sqlite3 파일을 패키지에 포함시키기.

안드로이드에 미리 만든 sqlite파일을 이용하기 위하여 처리할 것들을 간략하게 정리

1. 파일 크기
asset 리소스는 1메가 이상 크기의 파일을 허용하지 않는다. 미리 900kb정도 사이즈로 split해야 하고, 앱의 첫 구동시에 이 파일을 지정된 경로로 합쳐서 복사하는 루틴이 필요하다.

2. db의 포맷

• 데이터 테이블에는 `_id`라는 이름의 integer filed가 필요하고, 이것은 rowid여야 한다.
• android_metadata라는 테이블이 필요하다. 특히 locale이라는 text형 filed가 필요하다.

3. SQLiteOpenHelper, ContentPrivider 클래스를 작성.


위의 세 가지 사항을 해결해야 한다. 자세한 내용은 추후에.

JAVA - PHP 간 AES encryption 데이터 송수신에서 패딩으로 망하기

자바에서 encryption한 데이터를 php로 전달했을 때 패딩에 의해서 문제가 생길 수 있다.

AES 등의 암호화 알고리듬은 데이터를 특정 사이즈의 블록 단위로 암호화한다. 예를 들어서 블록의 사이즈가 32kb인데 암호화하려는 스트링은 50kb라면, 32kb * 2 = 64kb를 맞추도록 뒷부분을 패딩으로 채워넣는다.

이 패딩 방식이 php는 null 패딩이며, 자바의 경우에는 몇 가지 패딩 방식을 지원하지만 php의 null 패딩은 포함되지 않는다. 결론은


1. 자바에서 직접 null padding을 구현하거나
2. php에서 PKCS5 패딩을 제거하거나.


1의 경우에 사용 알고리듬에 따라서 사이즈가 딱 맞는 블록을 어레이로 선언하고 나머지를 null값으로 채워주면 되겠고, 후자의 경우에

<?php
$decrypted = mdecrypt_generic($td, base64_decode($enc_auth_token));
$dec_s = strlen($decrypted);
$padding = ord($decrypted[$dec_s-1]);
$decrypted = substr($decrypted, 0, -$padding);
?>

처럼 처리해 주면 될 것이다.