'분류 전체보기'에 해당되는 글 104건

카테고리 없음

YCSB는 Mongodb를 싫어하는 것 같다.

일단 위의 문제로 인하여 많은 사람들이 노가다를 하고 있는데 ...
버전이 업그레이드 되면서 ObjectID를 체크하는 부분이 변경되어서 24byte를 맞추도록 되었는 것인지
원래 그랬던 것인지 정확한 history는 알 수 없지만...
어쨋든 문제는 MongoDbClient.java의 read, update, insert , delete 함수 내에 아래 코드 때문이다.

간단히 설명하자면 아래 코드는 _id 키에 ObjectId를 key 문자열로 생성해서 넣어주는 것인데
이게 ObjectId 객체가 안에서 받은 값을 24글자가 맞는지, 알파벳이나 숫자의 연속으로 이루진 것인지 조사를 한다.
조건에 해당되지 않으면 미친 에러를 방출
결론은...아래와 같이 변경해주고 다시 컴파일 ant clean : ant : ant dbcompile-mongodb
그럼 이제 에러가 나지 않고~ 잘될 것이다.
read, update, insert, delete 모두 수정해주자..
여기서 또 주의할 것이.. insert만 제길 DBObject q 로 선언안하고 DBObject r로 선언되어있다. 복사해서 붙여넣기 할 때 조심하자..

Before - DBObject q = new BasicDBObject().append("_id", new ObjectId(key));

After - DBObject q = new BasicDBObject(); q.put("user", key);

조만간 YCSB를 이용한 mongodb 성능테스트에 대한 글을 포스팅 해봐야겠군...

카테고리 없음
AWS에는 CUDA 3.2 버전이 기본 셋팅
CUDA 4를 설치하고자 하면 아래를 참조 (CUDA 4의 경우 개발자 등록을 해야 한다.)

wget으로 Driver, Toolkit, SDK를 다운

64bit driver

# wget http://developer.download.nvidia.com/compute/cuda/4_0_rc2/drivers/devdriver_4.0_linux_64_270.40.run
# wget http://developer.download.nvidia.com/compute/cuda/4_0_rc2/toolkit/cudatoolkit_4.0.13_linux_64_rhel4.8.run
# wget http://developer.download.nvidia.com/compute/cuda/4_0_rc2/ToolsSDK/cudatools_4.0.13_linux_64.run
# wget http://developer.download.nvidia.com/compute/cuda/4_0_rc2/gpucomputingsdk_4.0.13_linux.run

AWS에서 기본적으로 제공되는 이전 버전은 반드시 삭제 한다.
# sudo yum remove nvidia cudatoolkit


1. 드라이버 설치

현재 커널 소스를 설치

# yum install kernel-devel- uname -r
(uname으로 kernel버전을 알아내어 yum으로 넘김)

NVIDIA 드라이버 설치

#NVIDIA-Linux-x86_64_260.19.12.run

# reboot (instance 리부팅)

드라이버 확인
# /usr/bin/nvidia-smi -q -a


# ls /dev/*nv*
# /dev/nvidia0, /dev/nvidia1, /dev/nvidiactl, /dev/nvram
위의 파일이 존재하는지 확인

2. Toolkit 설치

sh cudatoolkit_{version}.run
환경 설정
# vi ~/.bash_profile or # vi ~/.bashrc 를 실행하여 아래 내용 추가

export PATH=/usr/local/cuda/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

3. SDK 설치

# sh cudasdk{version}.run


깔끔하게 reboot 한번 해주면 완료


카테고리 없음

apache와 subversion을 연동하여 apache를 실행 시켰을 때 위의 에러가 발생하면 sqlite3이 분명 centos에 버전이 낮아 소스로 설치를 했을 경우일 것이다. 보통 subversion을 컴파일할 때 configure에서 sqlite 경로를 잡아주면 제대로 빌드도 되고 설치도 되지만 apache와 연동할 땐 에러가 난다.

그땐 configure를 실행할 때도 해결방법이 나온다.

sqlite의 소스 디렉토리에 있는 sqlite3.c를 subversion의 소스 디렉토리에 sqlite-amalgamation 디렉토리를 만들어주고 거기에 복사해 넣는다. 그러면 libtool로 sqlite3을 붙여준다.

# mkdir subversion-1.6.6/sqlite-amalgamation
# cp sqlite-3.6.20/sqlite3.c subversion-1.6.6/sqlite-amalgamation/sqlite3.c
# cd subversion-1.6.6
# ./configure –with-apxs=/usr/local/apache/bin/apxs –with-apr=/usr/local/apache/bin/apr-config –with-apr-util=/home/xxx/src/httpd-2.2.9/srclib/apr-util   
# make && make install

그런 뒤에 apache를 실행시켜주면 해결 완료

카테고리 없음
python 업그레이드하고자 python2.7.1을 소스로 받아서 설치했는데 prefix를 잘못주어!
"/usr"에 설치를 했다. 그럼 python2.4.3을 쓰는 기존의 솔루션이 빙시가 될 수 있다는...
버전 업그레이드는 "/usr/local"에다 해주고 필요한 솔루션은 따로 패스를 걸어주자...

일단 복구 방법은 rpm으로 python과 yum을 둘다 삭제 그때는 --nodeps 옵션으로
디펜던시를 체크하지 말자

# rpm -e --nodeps yum
# rpm -e --nodeps python


자 그런 다음 이제 CentOS 홈페이지의 repository로 들어가자 이때 익스플로러8 가지구 검색하면 고생한다.
그냥 크롬쓰자 크롬이 짱이구나..

설치할 때도 --nodeps 옵션을 주자 이미 꼬여있기에 디펜던시 체크는 의미가 없다..

# rpm -Uvh --nodeps http://mirror.centos.org/centos-5/5/os/x86_64/CentOS/yum-3.2.22-33.el5.centos.noarch.rpm 
# rpm -Uvh --nodeps http://mirror.centos.org/centos-5/5/os/x86_64/CentOS/python-2.4.3-43.el5.x86_64.rpm
# rpm -Uvh --nodeps http://mirror.centos.org/centos-5/5/os/x86_64/CentOS/python-devel-2.4.3-43.el5.x86_64.rpm
# rpm -Uvh --nodeps http://mirror.centos.org/centos-5/5/os/x86_64/CentOS/yum-fastestmirror-1.1.16-14.el5.centos.1.noarch.rpm
# rpm -Uvh --nodeps http://mirror.centos.org/centos-5/5/os/x86_64/CentOS/yum-metadata-parser-1.1.2-3.el5.centos.x86_64.rpm

여기까지 설치하고
# yum
을 쳐보면 에러가 발생 libpython2.4.so를 못찾는다.
python-libs를 설치하지 않았기 때문!

# rpm -Uvh --nodeps http://mirror.centos.org/centos-5/5/os/x86_64/CentOS/python-libs-2.4.3-43.el5.x86_64.rpm

위에 까지 설치한 뒤
# yum list python
쳐보자 아주 잘된다..

위의 url은 x86_64는 64비트 Centos 설치를 했을 경우다 32비트를 설치하였다면 i386으로 변경하자

아 그리고 버전이 계속 업그레이드 됨에 따라 위의 url이 깨졌을 경우 적절히 알아서 잘 찾아서 설치하면 된다... 그정도는 우리 모두 할 수 있지 않나요??

모르면 tomcabout@gmail.com 으로 메일이나 구글톡 친구 신청을 하도록~
 
카테고리 없음
멋진 http://blurblah.net/194 님이 해주신


Google C++ Testing Framework 시작하기




Introduction

Google C++ Testing Framework(이하 google test)은 더 나은 C++ test를 위한 tool이다. 또 Linux, Mac, Windows 모두에서 사용 가능하다.
좋은 test를 위해 Google test가 초점을 맞추고 있는 내용은 아래와 같다.

1. Test는 독립적이어야 하고 반복가능해야 한다.
  Success 혹은 Fail인 test를 debug 하는 일은 힘든 일이라 google test는 test를 별도의 object로 분리해 독립적으로 수행되도록 만든다. Test fail인 경우 google test에서는 실패한 case만 별도로 수행해 빠른 debugging이 가능하도록 지원한다.

2. Test는 잘 조직되어 있어야 하고, test되는 code의 구조를 잘 반영하고 있어야만 한다.
  Google test는 같이 공유할 수 있는 data와 subroutine을 가진 testcase들로 구성하는 것이 가능하다. 이러한 공통적인 패턴들이 test를 이해하기 쉽게 하고 유지보수가 용이하게 만들어준다.

3. Test는 portable 해야하며 재사용이 가능해야 한다.
  Open source community는 플랫폼에 종속적인 많은 source code들을 보유하고 있으며 이들을 test하기 위해서는 test 또한 특정 플랫폼에 종속적이어야 한다. 그래서 google test는 다양한 OS와 compiler를 지원하며 다양한 설정으로 동작이 가능하다.

4. Test가 실패했을 때, 문제에 대한 정보들을 가능한 많이 제공해야 한다.
  Google test는 첫번째 실패 시점에서 멈추지 않는다. 대신에 현재의 test는 중단시키고, 다음의 test로 계속 진행되도록 한다. 현재의 test가 지나간 후에 치명적이지 않은 실패에 대해 report 하도록 설정하는 것이 가능해서 여러개의 bug들을 발견하고 수정할 수 있다.

5. Testing framework은 test 작성자들을 다른 일들에서 해방시키고 test 내용에만 집중할 수 있게 만들어줘야 한다.
  Google test는 이미 정의된 test들은 유지해 두기 때문에 test 실행을 위해 사용자들이 또 다시 나열할 필요가 없도록 한다.

6. Test는 빨라야만 한다.
  Google test를 사용하면 test 사이에서의 공유된 자원들을 재사용할 수 있다.

Google test는 xUnit architecture 기반으로 만들어졌기 때문에 JUnit이나 PyUnit을 사용할 때와 비슷하여 빠르게 적용하기 좋다.



Setting up a New Test Project

Google test를 사용하기 위해선 Google test를 compile 해서 사용자의 test에 library로 link 해야만 하며, 자주 사용되는 build system에 대한 build file을 제공하고 있다.(msvc, xcode, make, codegear, scons directory) 만약 기본으로 제공되는 것과 다른 system을 사용하고 있다면 make/Makefile을 참조하면 되는데, 기본적으로 src/gtest-all.cc와 GTEST_ROOT, GTEST_ROOT/include를 compile 해야만 한다.(GTEST_ROOT : Google test root directory)

Google test library를 compile 할 수 있게 되었다면 project를 생성해서 사용자의 test program을 위한 build target을 수행해야만 한다. 또 사용자의 test를 compile 할 때, compiler가 gtest/gtest.h를 찾을 수 있게 GTEST_ROOT/include 를 포함해야만 한다.



Basic Concepts

Google test를 사용할 때 condition이 true인지를 확인하는 assertion을 사용하는 것으로 시작하는 것이 좋다. Assertion의 결과는 success, nonfatal failure, fatal failure 중에 하나가 될 수 있으며, fatal failure가 발생했다면 현재의 function은 중단될 것이다. (하지만 전체 program은 정상적으로 진행됨)

Testcase는 하나 이상의 test로 구성될 수 있는데 사용자는 code의 구조를 반영할 수 있도록 여러개의 testcase들로 grouping이 가능하며, 복수의 test가 common object나 subroutine을 공유해야 한다면 그런 것들을 test fixture class에 넣어두고 사용할 수 있다.



Assertions

Google test의 assertion은 function call로 구성된 macro이다. Assertion이 fail로 끝나게 되면, google test는 assertion의 source file, line number, failure message 들을 화면에 출력한다.

Assertion은 같지만 현재의 function은 다르게 처리하는 function 들의 짝으로 구성되어 있는데, ASSERT_XXX 의 형태로 구성된 assertion은 fatal failure를 발생시켜 현재의 function을 중단시키며, EXPECT_XXX 형태의 assertion은 nonfatal failure를 발생시키고 현재 수행중인 function을 중단시키지 않는다.

Custom failure message 를 사용하려면, '<<' 연산자를 이용해서 해결할 수 있다. 예제는 아래와 같다.

ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";

for (int i = 0; i < x.size(); ++i) {
  EXPECT_EQ
(x[i], y[i]) << "Vectors x and y differ at index " << i;
}

만약 wchar_t*, TCHAR* 등의 wide string을 사용하고 있다면, 출력되면서 자동으로 UTF-8로 변환된다.



Basic Assertions


앞에서도 언급되었지만 ASSERT_XXX는 fatal failure를 발생시키며, EXPECT_XXX는 nonfatal failure를 발생시킨다.



Binary Comparison

여기에서는 두 값을 비교하는 assertion 구문들을 설명한다.


실패했을 경우 google test는 두 가지 값 val1, val2를 출력하게 되는데 사용자가 test 하고자 하는 구문은 actual에, expected value는 expected 항목에 넣어주어야 한다.

이러한 assertion 구문들은 사용자 정의 operator들에 대해서도 동작이 가능한데, 만약 사용자 정의 연산자들을 사용하게 된다면 ASSERT_XXX 구문을 사용하는 것이 좋다. 왜냐하면 ASSERT_XXX 구문은 비교 결과 뿐만 아니고, 두 개의 operand 들도 화면에 출력해주기 때문이다.

ASSERT_EQ에서 pointer를 사용한다면 pointer의 일치여부를 테스트하게 된다. 만약 두 개의 문자열을 사용했다면, 두 문자열의 값이 일치하느냐를 테스트하지 않고 동일한 memory location인지를 판단해서 결과를 내보낸다. 만약에 문자열 값의 일치여부를 테스트하고 싶다면 ASSERT_EQ를 사용해서는 안되고 대신에 ASSERT_STREQ를 사용하면 된다. 특별한 경우, NULL을 비교해야 하는 경우가 생긴다면 ASSERT_STREQ(NULL, c_string)을 사용하면 되지만, 두 개의 문자열 object를 비교하려고 한다면 ASSERT_EQ를 사용한다.

ASSERT 구문은 narrow, wide string 모두에 대해 동작한다.



String Comparison

문자열 비교를 위해서는 다음의 assertion 구문들을 사용한다.


위의 assertion 구문중 CASE가 포함된 항목들이 있는데, CASE는 대소문자를 구별하지 않는다는걸 의미한다. 또 NULL pointer와 비어있는 문자열은 다름을 유의해야 한다.



Simple Tests

Test를 작성하기 위해 일단 아래의 절차대로 수행한다.

1. Test function을 정의하고 이름 붙이기 위해서 TEST() macro를 사용한다. 이 macro는 일반적은 C++ function으로 구성되어 있으며 결과값을 return 하지 않는다.

2. 이 function에서 사용자가 원하는 가능한 C++ 구문들을 사용하면 되고, 값의 비교를 위해서는 google test의 assertion 구문을 사용하면 된다.

3. Test 결과는 이 assertion 구문에 의해 결정된다.

TEST(test_case_name, test_name) {
 
... test body ...
}

TEST() macro에서 첫번째 argument는 testcase의 이름을 의미하며 두번째 argument는 testcase 안에서의 test 이름을 의미한다. Testcase는 여러개의 test를 포함할 수 있다. 또 다른 testcase에서 같은 test 이름을 가질 수 있다.

예를 들어보자. 간단한 function인

int Factorial(int n); // Returns the factorial of n

이 있다.

이 function을 test 하기 위해서 아래와 같은 testcase를 작성할 수 있다.

// Tests factorial of 0.
TEST
(FactorialTest, HandlesZeroInput) {
  EXPECT_EQ
(1, Factorial(0));
}

// Tests factorial of positive numbers.
TEST
(FactorialTest, HandlesPositiveInput) {
  EXPECT_EQ
(1, Factorial(1));
  EXPECT_EQ
(2, Factorial(2));
  EXPECT_EQ
(6, Factorial(3));
  EXPECT_EQ
(40320, Factorial(8));
}

Google test는 testcase에 의해 grouping 하는 것이 가능한데, TEST()의 첫번째 argument를 동일하게 사용함으로써 이를 가능케 만들 수 있다. 위의 예제에서 보면 HandlesZeroInput 이라는 test와 HandlesPositiveInput test는 각각 다른 test를 의미하지만 FactorialTest 라는 testcase의 이름을 동일하게 사용함으로써 grouping이 가능함을 보여주고 있다.



Text Fixtures : Using the Same Data Configuration for Multiple Tests

사용자가 유사한 data를 사용해서 하나 이상의 test를 작성한다면, test fixture를 사용할 수 있다. 이 test fixture를 사용한다는 것은 여러개의 다양한 test를 작성하는 과정에서 같은 object의 configuration을 재사용한다는 것을 의미한다.

Fixture를 작성할 때에는 아래의 내용대로 수행하면 된다.

1. ::testing::Test 로부터 class를 derive한다. Sub-class 에서 fixture member에 접근해야 하기 때문에 protected 혹은 public 으로 작성해야 한다.

2. Class 내부에서 사용자가 원하는대로 object들을 선언해 사용한다.

3. 필요하다면, 생성자나 SetUp() function을 작성해둔다.

4. 생성자나 SetUp() function을 정의해서 사용하고 있다면, 해당 function에서 사용했던 resource를 반환하기 위해 소멸자나 TearDown() function을 작성한다.

5. Subroutine 들을 작성한다.

Fixture를 사용하기 위해서는 TEST() 대신에 TEST_F()를 사용해야만 한다.
TEST()에서는 첫번째 argument가 testcase의 이름이었지만 TEST_F()를 사용할 때는 첫번째 argument로 test fixture class의 이름을 사용해야만 한다.

불행하게도 C++ macro 라는게 두가지 type을 처리하는 하나의 macro를 지원하지 않기 때문에 어쩔 수 없이 두 가지의 macro TEST(), TEST_F()를 적절히 사용해야만 한다. 또 당연하겠지만 TEST_F() macro를 사용하기 이전에 TEST_F()에 사용될 fixture class가 정의되어 있어야만 한다.

TEST_F()를 사용할 때, google test는 아래와 같은 절차를 수행하게 된다.

1. Runtime 시에 test fixture를 생성한다.

2. SetUp()을 호출해 초기화를 수행한다.

3. Test를 수행한다.

4. TearDown()을 호출함으로써 resource를 반환하거나 하는 처리를 한다.

5. Test fixture를 소멸시킨다. 주의할 내용은 같은 testcase 내부에서의 각각의 test는 다른 test fixture를 확보해 사용하며 google test는 다음 test fixture를 생성하기 전에 이전 fixture를 삭제한다. Google test는 여러개의 test를 위해 동일한 test fixture를 재사용하지 않으며 하나의 test가 test fixture에 가한 변화가 다른 test 들에는 영향을 주지 않음을 의미한다.

아래의 예제를 살펴보자. Queue라는 이름의 queue class에 대한 test를 작성한다고 생각해보자.

template <typename E> // E is the element type.
class Queue {
 
public:
 
Queue();
 
void Enqueue(const E& element);
  E
* Dequeue(); // Returns NULL if the queue is empty.
  size_t size
() const;
 
...
};

가장 먼저 fixture class를 정의한다.

class QueueTest : public ::testing::Test {
 
protected:
 
virtual void SetUp() {
    q1_
.Enqueue(1);
    q2_
.Enqueue(2);
    q2_
.Enqueue(3);
 
}

 
// virtual void TearDown() {}

 
Queue<int> q0_;
 
Queue<int> q1_;
 
Queue<int> q2_;
};

이 경우에 각 test 마다 소멸자가 대신 수행하기 때문에 깨끗하게 정리할 필요가 없어서 TestDown()을 작성하지 않았다. 이 작업까지 마친 후에 아래처럼 test fixture를 이용해 TEST_F()를 작성할 수 있다.

TEST_F(QueueTest, IsEmptyInitially) {
  EXPECT_EQ
(0, q0_.size());
}

TEST_F
(QueueTest, DequeueWorks) {
 
int* n = q0_.Dequeue();
  EXPECT_EQ
(NULL, n);

  n
= q1_.Dequeue();
  ASSERT_TRUE
(n != NULL);
  EXPECT_EQ
(1, *n);
  EXPECT_EQ
(0, q1_.size());
 
delete n;

  n
= q2_.Dequeue();
  ASSERT_TRUE
(n != NULL);
  EXPECT_EQ
(2, *n);
  EXPECT_EQ
(1, q2_.size());
 
delete n;
}

이 test들이 수행될 때 아래와 같은 과정을 거치게 된다.

1. Google test가 QueueTest object를 생성한다. (t1이라 부르자.)

2. t1.SetUp() 이 호출되어서 t1을 초기화한다.

3. t1의 첫번째 test인 IsEmptyInitially가 수행된다.

4. Test 종료 후에 t1.TearDown()이 호출되어 정리한다.

5. t1이 소멸된다.

6. 다른 QueueTest object에 대해 위의 과정이 반복되는데, 이번엔 DequeueWork test에 대해 반복 수행된다.



Invoking the Tests

TEST()와 TEST_F() 는 google test에서 내부적으로 등록된다. 그렇기 때문에 다른 C++ testing framework 들과 달리 test를 수행하기 위해 다시 정의할 필요가 없다.

Test 들을 정의한 후에 RUN_ALL_TESTS()를 사용해서 test를 수행시킬 수 있다. RUN_ALL_TESTS()는 모든 test가 성공일 때에는 0을 반환하고 아닐 경우에는 1을 return하는 macro이다. RUN_ALL_TESTS()는 아래와 같은 과정을 거치면서 수행된다.

1. Google test의 모든 flag들의 상태를 저장한다.

2. 첫번째 test를 위한 test fixture를 생성한다.

3. SetUp()으로 초기화한다.

4. Fixture object와 함께 test를 수행한다.

5. TearDown()을 호출해서 resource들을 반환하거나 정리한다.

6. Fixture object를 제거한다.

7. Google test의 flag들을 복구한다.

8. 모든 test가 완료될 때 까지 위의 과정을 반복한다.

RUN_ALL_TEST()는 한 번 이상 수행하는걸 지원하지 않기 때문에 단 한번만 호출될 수 있도록 작성해야 한다.



Writing the main() function

아래의 예처럼 test에 필요한 test fixture나 main() function을 작성할 수 있다.

#include "this/package/foo.h"
#include <gtest/gtest.h>

namespace {

// The fixture for testing class Foo.
class FooTest : public ::testing::Test {
 
protected:
 
// You can remove any or all of the following functions if its body
 
// is empty.

 
FooTest() {
   
// You can do set-up work for each test here.
 
}

 
virtual ~FooTest() {
   
// You can do clean-up work that doesn't throw exceptions here.
 
}

 
// If the constructor and destructor are not enough for setting up
 
// and cleaning up each test, you can define the following methods:

 
virtual void SetUp() {
   
// Code here will be called immediately after the constructor (right
   
// before each test).
 
}

 
virtual void TearDown() {
   
// Code here will be called immediately after each test (right
   
// before the destructor).
 
}

 
// Objects declared here can be used by all tests in the test case for Foo.
};

// Tests that the Foo::Bar() method does Abc.
TEST_F
(FooTest, MethodBarDoesAbc) {
 
const string input_filepath = "this/package/testdata/myinputfile.dat";
 
const string output_filepath = "this/package/testdata/myoutputfile.dat";
 
Foo f;
  EXPECT_EQ
(0, f.Bar(input_filepath, output_filepath));
}

// Tests that Foo does Xyz.
TEST_F
(FooTest, DoesXyz) {
 
// Exercises the Xyz feature of Foo.
}

}  // namespace

int main(int argc, char **argv) {
 
::testing::InitGoogleTest(&argc, argv);
 
return RUN_ALL_TESTS();
}

이 예제에서 main() function에 사용된 ::testing::InitGoogleTest() function은 google test의 flag를 설정하기 위해 command line으로 입력된 값들을 사용한다. 이런 방법은 사용자가 다양한 flag를 통해 test program을 제어 가능하도록 해준다.



Important note for Visual C++ users

만약 사용자가 test를 library에 넣어두었고, main() function이 .exe 파일 안에서 별도의 library로 작성되어 있다면 test는 수행되지 않을것이다. 이유는 Visual C++의 bug 때문인데, 사용자가 test를 정의했을 때, google test는 test를 등록하기 위해 static object로 생성한다. 이러한 object들은 어디서든 참조되지 못하지만 생성자들은 여전히 수행하려고 한다. 그래서 사용자는 main program에서 test와 함께 library를 참조해야만 한다. 그러기 위해서는 library에서 아래처럼 function을 선언한다.

__declspec(dllimport) int PullInMyLibrary() { return 0; }

DLL이 아닌 static library로 작성했다면 위와 같은 선언은 필요하지 않지만, main program에서는 아래와 같이 작성해 주어야 한다.

int PullInMyLibrary();
static int dummy = PullInMyLibrary();

추가로 static library로 test를 작성한다면 main program의 linker option에 /OPT:NOREF를 넣어주어야 하고, test를 DLL로 작성하게 된다면 google test 역시 DLL로 build 해주어야 test가 제대로 수행될 수 있다. 그래도 가장 손쉬운 방법은 test를 library로 만들지 않는 것이다.




 
카테고리 없음
inode를 찾아서 삭제하자.


#  ls -ali 
10010625 drwxr-xr-x  3 root   root          4096  6 13 10:55 ?Q?W??äÓT???<R?æÒ????'???????a?a
       2 drwxr-xr-x 15 root   root          4096  6 13 10:57 .
       2 drwxr-xr-x 25 root   root          4096  3 23 22:23 ..
 5603329 drwxr-xr-x  5 spam   spam          4096  2  8 18:29 DOMAINS
 9568257 drwx------  2 alloe  alloe         4096  6 10 15:53 alloe

# find . -inum 10010625 -exec rm -f {} \;

카테고리 없음
서버가 2개 있다고 가정하에 설명을 한다.

A, B 서버가 존재 할 때 A에서 B로 자동으로 로그인을 하고 싶다~ 라고 할 때
원하는 로그인 아이디로 A의 계정을 이동시키고~ 예) alloe계정으로 B서버에 자동으로 로그인하고 싶다~ (alloe계정은 A, B서버 둘 다 존재해야 함), root 권한을 가진 상태에서 # > su alloe 를 실행

A 서버에서 해당 alloe 아이디로 실행
$ > cd ~
$ > ssh-keygen -t rsa
(단계 별로 뭔가 물어보는데 모두 엔터를 친다.)
$ > cat .ssh/id_rsa.pub
(위의 명령어로 나온 값을 복사해 놓는다. ssh-rsa AAAAAB ????????????????????== alloe@서버도메인 으로 출력된 것을 이야기 한다.)

위의 값을 B 서버에 동일한 alloe 계정 홈디렉토리에 써줘야 한다.
$ > mkdir .ssh
$ > chmod 700 .ssh
$ > echo "아까 복사해 놓은 ssh-rsa AAAAABB??? 뭐 이런 값" >> .ssh/authorized_keys
$> chmod 600 .ssh/authorized_keys

위의 과정이 완료되었다면 테스트를 해봐야지

A서버에서 실행
$ > ssh -l alloe B서버주소
위의 명령어를 실행하면 암호를 안물어보고 바로~ 접속이 된다.

성공

양방향으로 할려면 머리를 조금만 쓰면 된다..


카테고리 없음
컴파일시 -pg 옵션 추가
# g++ -pg -g -o sample sample.cpp

# gprof sample > sample_profile.txt

인자가 있을 경우 그냥 실행하면 gmon.out 이 생긴다 그 파일을 이용하여 gprof로 분석 가능
# ./sample score.json

gmon.out을 이용한 분석
# gprof sample gmon.out > sample_profile.txt

결과 보기
# vim sample_profile.txt

결과를 볼 수 있다.
카테고리 없음
mongodb를 사용하는데 두 가지 방법이 있다. binary버전 source버전

binary버전은 어떠한 설명서도 필요없이 쉽게 다운만 받아서 설치할 수 있지만 source 버전의 경우 빌드하기 위해 설치하고 준비해야할 것들이 매우 많다. 특히 centos의 경우 5.4버전이라도 구형 stable한 버전의 library를 주로 사용하기 때문에 업그레이드를 해주어야 할 것들도 매우 많다.

요구사항
boost
spider monkey - js
mongodb 소스 (c++로 mongodb가 만들어져서 c++드라이버는 자체 내장되어있다. 빌드할때 퉁쳐서 빌드가 된다.)
mongodb c driver 소스
pcre 업그레이드 (6.6.2 with unicode support)
scons 2.0.1
python 2.7


1. boost 설치
boost의 경우 요즘은 아주 쉽게 설치 할 수 있기 때문에 홈페이지에서 소스를 가져다가 설치하면 금새 할 수 있다. 간단히 설명하겠다.

소스 설치의 경우 boost도 조금 복잡하기에 그냥 yum 으로 설치하도록 하자

만약 다른 곳에서 boost를 사용하고 있고 버전이 낮아서 높은 버전을 원한다면 www.boost.org에서 source최신 버전을 다운받아 설명서를 보면서 설치하시면 된다.. (boost는 자료가 많기 때문에 설명을 패스함)

# yum install boost-devel

2. spider monkey
mongodb에서 server-side javascript execution을 위해 spider monkey가 필요하다. 이 것은 js라이브러리를 설치하면 해결할 수 있다.

Download
# curl - O ftp://ftp.mozilla.org/pub/mozilla.org/js/js-1.7.0.tar.gz
# tar xvfz js-1.7.0.tar.gz

Build
# cd js/src
# export CFLAGS="-DJS_C_STRINGS_ARE_UTF8"
export로 CFLAGS를 잡아주지 않으면 mongodb를 빌드하는데는 문제가 없지만 차후 mongodb를 사용할 때 한글 지원이 제대로 되지 않을 우려가 있다. (한글을 사용하고자 하면 에러를 발생시킨다.), 기본적으로 spider monkey는 utf8을 지원하지 않도록 되어 있기 때문에 위의 변수를 선언해주어야 하는 것이다.
# make -f Makefile.ref

Install
# JS_DIST=/usr make -f Makefile.ref export
JS_DIST로 설치될 경로를 설정해준다.

3. Python 2.7 설치
python은 scons를 사용하기 위해 설치를 해준다.
scons를 사용하면 mongodb를 빌드하고 설치하기 매우~!!! 편하다.

Download
#wget http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tgz
# tar xvfz Python-2.7.1.tgz
# cd Python-2.7.1
# ./configure
# make & make install

4. scons 설치
python을 설치했으니 scons는 다운받아서 설치만 하면 된다.

# wget http://downloads.sourceforge.net/project/scons/scons/2.0.1/scons-2.0.1.tar.gz
# tar xvfz scons-2.0.1.tar.gz
# cd scons-2.0.1
# python setup.py install

5. mongodb and c++ driver 설치
mongodb는 http://www.mongodb.org/downloads 사이트에서 전 품목을 절찬리 다운 받을 수 있다.
우리는 소스가 필요하니 제일 오른쪽에 source 필드에서 1.6.5 버전을 다운받자 (최신 버전을 받아도 되나, 옛날에 hadoop의 최신버전으로 고생을 많이 해본 경험으로 그 뒤로는 항상 stable 버전으로 다운받아서 설치하였다.)

Download
mongodb
# wget http://downloads.mongodb.org/src/mongodb-src-r1.6.5.tar.gz
c driver
https://github.com/mongodb/mongo-c-driver
위의 url로 가서 다운받아서 서버로 넘기자 - 해당 url을 wget으로 받는 경로를 몰라 그냥 받아서 서버로 전송시켰다.

Build Mongodb
# tar xvfz mongodb-src-r1.6.5.tar.gz
# cd mongodb-src-r1.6.5
# scons all
빌드가 모두 완료 된 뒤 mongodb를 그냥 사용할 것이라면 아래와 같이 설치
# scons --prefix=/usr/mongo install
빌드가 모두 완료 된 뒤 mongodb를 활용하여 뭔가를 만들 것이라면 아래와 같이 설치 (prefix는 안해줘도 된다 기본 경로는 /usr/local, 난 그냥 /usr에 설치했다. /usr/local로 그냥 설치해서 차후 library 경로를 /usr/local/lib, /usr/local/include 로 잡아주어도 된다.)
# scons --prefix=/usr/mongo --full install

Build C Driver
# tar xvfz mongodb-mongo-c-driver-v0.1-63.tar.gz
# cd mongodb-mongo-c-driver-f853306
기본적인 빌드
# scons 
gcc를 c99 모드로 빌드
# scons --c99
빌드를 하고 나서 test를 진행
# scons test
빌드를 하고 나서 테스트를 하는데 서버의 경로를 지정 (다른 리모트 서버에 mongodb가 설치되어있다면)
# scons test --test-server=111.111.111.111
하지만 위의 test의 경우 test source가 모두 하드코딩으로 127.0.0.1 (localhost)로 잡혀있어서 물론 안해봤지만 안될 듯하다. 그래서 그냥 scons --c99로 빌드



모두 설치가 완료
그러면 해당 경로로 가보면 모두 설치가 된 것을 확인할 수 있다.

# mongod &
# mongo
했을 경우 제대로 접속된다면 OK

문의 사항이 있다면 tomcabout@google.com으로 메일이나 구글톡을 신청해서 물어보셔도 됩니다.



카테고리 없음
mongodb를 source로 컴파일해서 사용할려고 하면 아래와 같은 warning이 등장한다.

"warning: some regex utf8 things will not work.  pcre build doesn't have --enable-unicode-properties"

아래와 같이 확인 해보면 "No Unicode properties support" 라고 확인할 수 있다.
# pcretest -C
PCRE version 6.6 06-Feb-2006
Compiled with
  UTF-8 support
  No Unicode properties support
  Newline character is LF
  Internal link size = 2
  POSIX malloc threshold = 10
  Default match limit = 10000000
  Default recursion depth limit = 10000000
  Match recursion uses stack
rpm으로 pcre를 업그레이드해서 unicode를 support 하도록 해보자.
상세 내용은 아래 링크에서 참조할 수 있다.
http://chrisjean.com/2009/01/31/unicode-support-on-centos-52-with-php-and-pcre/
wget으로 rpm을 다운 받자.
# wget http://vault.centos.org/5.1/updates/SRPMS/pcre-6.6-2.el5_1.7.src.rpm
rpm을 풀어서 소스를 수정
# rpm -ivh pcre-6.6-2.el5_1.7.src.rpm
vi로 pcre.spec을 수정
# vi /usr/src/redhat/SPECS/pcre.spec
%configure --enable-utf8 <- 이렇게만 되어있는 곳에 --enable-unicode-properties를 추가하자
"%configure --enable-utf8 --enable-unicode-properties"



 
rpm을 다시 빌드하자
# rpmbuild -ba /usr/src/redhat/SPECS/pcre.spec
rpm 설치
# rpm -Uvh /usr/src/redhat/RPMS/i386/pcre-6.6-2.7.i386.rpm /usr/src/redhat/RPMS/i386/pcre-devel-6.6-2.7.i386.rpm
확인
# pcretest -C




PCRE version 6.6 06-Feb-2006
Compiled with
  UTF-8 support
  Unicode properties support
  Newline character is LF
  Internal link size = 2
  POSIX malloc threshold = 10
  Default match limit = 10000000
  Default recursion depth limit = 10000000
  Match recursion uses stack

1 ··· 3 4 5 6 7 8 9 ··· 11
블로그 이미지

개발자

우와신난다