This is a slide which summarizes Pro Git. I have made this because I wanted to give the description of Git to my co-workers. I hope that it would be a great help to find a specific topic of Git. If you want to know more details than this, you can easily refer to the information of Pro Git because this slide has the same titles as it.
2013년 7월 13일 토요일
제가 Pro Git 내용을 요약한 자료를 공개합니다. 같이 일하는 동료들에게 Git 에 대해 소개하려고 만들었던 자료입니다. Git에 대한 특정 내용을 알고 싶을 때, 이 자료의 목차에서 내용을 찾아보기에 좋은 것 같아 블로그에 올립니다.
This is a slide which summarizes Pro Git. I have made this because I wanted to give the description of Git to my co-workers. I hope that it would be a great help to find a specific topic of Git. If you want to know more details than this, you can easily refer to the information of Pro Git because this slide has the same titles as it.
This is a slide which summarizes Pro Git. I have made this because I wanted to give the description of Git to my co-workers. I hope that it would be a great help to find a specific topic of Git. If you want to know more details than this, you can easily refer to the information of Pro Git because this slide has the same titles as it.
2013년 5월 10일 금요일
GObject - Inheritance
이번에는 GObject 상속 구조에 대해서 기술하려 합니다.
상속을 설명하기 위한 class 들은 다음과 같습니다.
UniversityStudent가 StudentInfo를 상속하고, StudentInfo로부터 UniversityStudent는 name, address를 상속받고 자신만의 데이터인 university_name을 갖습니다. method는 StudentInfo에서 상속받지만 그대로 상속받지 않고 약간 변형합니다(Method override).
이 두 클래스를 GObject로 구현해 보겠습니다.
우선, Class를 구현하기 위한 구조체는 다음과 같습니다.
StudentInfo는 GObject에서 상속받고, UniversityStudent는 StudentInfo로부터 상속받습니다. C의 구조체로 상속관계를 표현하는 가장 좋은 방법 중의 하나는 바로 구조체 중첩입니다. 이렇게 하면 UniversityStudent는 StudentInfo의 data와 method (function pointer)를 그대로 가져올 수 있습니다.
UniversityStudent* us;
us->parent.parent.g_type_instance.g_class->g_type
((GTypeInstance*)us)->g_class->g_type
위 코드는 GObject에서 어떻게 class구조에 대한 pointer를 가져오는지 보여주고 있습니다. C 구조체의 첫번째 필드는 항상 그 구조체의 첫번째 byte부터 저장되는데, 이 속성을 이용해서 우리는 UniversityStudent의 class 정보를 쉽게 가져올 수 있는 것입니다.
university_student_parent_class 포인터는 university_student_class_init() 함수 내에서 정의할 것입니다.
상속을 test 하기 위한 함수입니다. line 104에서 UnversityStudent type으로 GObject를 생성합니다. line 108 ~ 111까지 Instance 정보와 Class 정보를 얻기 위한 pointers를 선언합니다. uobj1은 UNIVERSITY_TYPE_STUDENT type 입니다. 따라서 line 114는 university_student_print 함수를 호출한 것과 같습니다. 또한 line 125도 uobj1의 StudentInfoClass 포인터를 얻어서 print 함수를 호출했기 때문에 line 114와 같은 함수를 호출한 것입니다.
line 118, 119에서 uobj1을 StudentInfo와 UniversityStudent type으로 각각 cast 합니다. C 문법으로 보면 STUDENT_INFO와 UNIVERSITY_STUDENT는 우리가 정의했던 macro이지만 GObject의 cast라고 생각하면 편리합니다. 따라서 line 121의 결과는 si, us 포인터들이 같은 값을 나타냅니다.
line 129 ~ 132의 출력 결과는 모두 같습니다. 즉 uobj1에 대한 class 포인터를 얻는 방법이 여러 가지라는 것을 나타냅니다. 특히 line 132의 구문은 우리가 앞에서 봤던 GObject에서 Class 정보를 얻는 방법인데, 이것은 설명을 위해 추가한 것으로 보통은 이렇게 하지는 않습니다. line 131처럼, 미리 정의한 macro를 사용하지요.
그럼 우리가 override된 함수가 아닌 부모 class의 함수만 호출하고 싶다면 어떻게 할까요? line 139가 그 방법을 알려주고 있습니다. 부모 class의 pointer를 얻고 싶을 때에는 g_type_class_peek_parent 함수를 사용합니다.
line 142에서 uobj2를 생성하고, line 145에서 그 값을 출력하고, line 147, 148에서 생성되었던 GObject들을 해제합니다. g_object_unref의 결과 finalize 함수가 호출되고, memory는 안전하게 헤제되는 것입니다.
위 코드를 실행한 결과는 다음과 같습니다.
Start main() ...
student_info_base_init() called 1
student_info_class_init() called
gobj_class: 0x971ee30, klass:0x971ee30
student_info_parent_class: 0x971ed00
student_info_base_init() called 2
university_student_base_init() called
university_student_class_init() called
gobj_class: 0x971ef40, klass: 0x971ef40
university_student_parent_class: 0x971ee30
student_info_init() called
StudentInfoClass: 0x971ee30
student_info_parent_class: 0x971ed00
university_student_init() called
UniversityStudentClass: 0x971ef40
university_student_parent_class: 0x971ee30
university_student_print() called
student_info_print() called
Name : 김혜진
Address : 부산
University : 부산대
Instance pointers for uobj1:
STUDENT_INFO: 0x971f810, UNIVERSITY_STUDENT: 0x971f810
STUDENT_INFO_GET_CLASS(uobj1)->print
university_student_print() called
student_info_print() called
Name : 김혜진
Address : 부산
University : 부산대
Class pointers for uobj1:
STUDENT_INFO_GET_CLASS: 0x971ef40
UNIVERSITY_STUDENT_GET_CLASS: 0x971ef40
((GTypeInstance*)us)->g_class: 0x971ef40
university_student_parent_class for uobj1: 0x971ee30
STUDENT_INFO_GET_CLASS(g_type_class_peek_parent(usc))->print
student_info_print() called
Name : 김혜진
Address : 부산
student_info_init() called
StudentInfoClass: 0x971ee30
student_info_parent_class: 0x971ed00
university_student_init() called
UniversityStudentClass: 0x971ef40
university_student_parent_class: 0x971ee30
university_student_print() called
student_info_print() called
Name : 김수진
Address : 서울
University : 서울대
부산대 information is being deleted.
김혜진 information is being deleted.
서울대 information is being deleted.
김수진 information is being deleted.
상속을 설명하기 위한 class 들은 다음과 같습니다.
| Class | Data | Method |
|---|---|---|
| StudentInfo | name, address | print 'name' and 'address' |
| UniversityStudent | name, address, university_name | print 'name', 'address' and 'university_name' |
UniversityStudent가 StudentInfo를 상속하고, StudentInfo로부터 UniversityStudent는 name, address를 상속받고 자신만의 데이터인 university_name을 갖습니다. method는 StudentInfo에서 상속받지만 그대로 상속받지 않고 약간 변형합니다(Method override).
이 두 클래스를 GObject로 구현해 보겠습니다.
우선, Class를 구현하기 위한 구조체는 다음과 같습니다.
UniversityStudent* us;
us->parent.parent.g_type_instance.g_class->g_type
((GTypeInstance*)us)->g_class->g_type
위 코드는 GObject에서 어떻게 class구조에 대한 pointer를 가져오는지 보여주고 있습니다. C 구조체의 첫번째 필드는 항상 그 구조체의 첫번째 byte부터 저장되는데, 이 속성을 이용해서 우리는 UniversityStudent의 class 정보를 쉽게 가져올 수 있는 것입니다.
StudentInfo의 class 구현은 첫번째 GObject 설명에서 이미 다루었고, 여기서는 UniversityStudent class를 중심으로 설명하겠습니다.
UniversityStudent도 StudentInfo와 마찬가지로 university_student_base_init(), university_student_class_init(), university_student_init() 함수를 정의하고 g_type_register_static 함수로 type 정보를 등록합니다(university_student_get_type).
university_student_get_property(), university_student_set_property() 함수를 만들어 private data인 university_name을 읽고 쓸수 있도록 합니다.
university_student_finalize() 함수를 만들어서 UniversityStudent 객체가 파괴될 때 memory를 정리하는데, 이 함수에서 StudentInfo의 finalize 함수를 다음과 같이 호출합니다.
line 92에서 finalize() call을 통해서 Superclass의 finalize 함수를 실행합니다. 다음은 UniversityStudent의 class 초기화 함수입니다.
line 117에서 university_student_parent_class를 정의합니다.
line 126에서 GObject의 finalize 함수를 override 합니다.
line 128에서 StudentInfo Class의 print 함수를 university_student_print 함수로 override 합니다.
line 138에서 property를 등록하는데, property 한 개를 등록할 때에는 g_object_class_install_property를 사용하고, 여러 개를 한꺼번에 등록할 때에는 g_object_class_install_properties를 사용합니다(GObject property 설명 참조).
line 120에서 class pointer 들을 출력하는 부분이 있습니다. 실행 결과가 어떻게 될까요? 한번 생각해 보세요. 결과는 잠시 후에 설명합니다. 다음은 instance 초기화 함수입니다.
line 150에서 UniversityStudent 포인터로부터 class 구조체 포인터를 얻고, 그 값을 출력하고 있습니다. 비교를 위해서 parent class의 포인터(university_student_parent_class)도 출력합니다.
line 118, 119에서 uobj1을 StudentInfo와 UniversityStudent type으로 각각 cast 합니다. C 문법으로 보면 STUDENT_INFO와 UNIVERSITY_STUDENT는 우리가 정의했던 macro이지만 GObject의 cast라고 생각하면 편리합니다. 따라서 line 121의 결과는 si, us 포인터들이 같은 값을 나타냅니다.
line 129 ~ 132의 출력 결과는 모두 같습니다. 즉 uobj1에 대한 class 포인터를 얻는 방법이 여러 가지라는 것을 나타냅니다. 특히 line 132의 구문은 우리가 앞에서 봤던 GObject에서 Class 정보를 얻는 방법인데, 이것은 설명을 위해 추가한 것으로 보통은 이렇게 하지는 않습니다. line 131처럼, 미리 정의한 macro를 사용하지요.
그럼 우리가 override된 함수가 아닌 부모 class의 함수만 호출하고 싶다면 어떻게 할까요? line 139가 그 방법을 알려주고 있습니다. 부모 class의 pointer를 얻고 싶을 때에는 g_type_class_peek_parent 함수를 사용합니다.
line 142에서 uobj2를 생성하고, line 145에서 그 값을 출력하고, line 147, 148에서 생성되었던 GObject들을 해제합니다. g_object_unref의 결과 finalize 함수가 호출되고, memory는 안전하게 헤제되는 것입니다.
위 코드를 실행한 결과는 다음과 같습니다.
Start main() ...
student_info_base_init() called 1
student_info_class_init() called
gobj_class: 0x971ee30, klass:0x971ee30
student_info_parent_class: 0x971ed00
student_info_base_init() called 2
university_student_base_init() called
university_student_class_init() called
gobj_class: 0x971ef40, klass: 0x971ef40
university_student_parent_class: 0x971ee30
student_info_init() called
StudentInfoClass: 0x971ee30
student_info_parent_class: 0x971ed00
university_student_init() called
UniversityStudentClass: 0x971ef40
university_student_parent_class: 0x971ee30
university_student_print() called
student_info_print() called
Name : 김혜진
Address : 부산
University : 부산대
Instance pointers for uobj1:
STUDENT_INFO: 0x971f810, UNIVERSITY_STUDENT: 0x971f810
STUDENT_INFO_GET_CLASS(uobj1)->print
university_student_print() called
student_info_print() called
Name : 김혜진
Address : 부산
University : 부산대
Class pointers for uobj1:
STUDENT_INFO_GET_CLASS: 0x971ef40
UNIVERSITY_STUDENT_GET_CLASS: 0x971ef40
((GTypeInstance*)us)->g_class: 0x971ef40
university_student_parent_class for uobj1: 0x971ee30
STUDENT_INFO_GET_CLASS(g_type_class_peek_parent(usc))->print
student_info_print() called
Name : 김혜진
Address : 부산
student_info_init() called
StudentInfoClass: 0x971ee30
student_info_parent_class: 0x971ed00
university_student_init() called
UniversityStudentClass: 0x971ef40
university_student_parent_class: 0x971ee30
university_student_print() called
student_info_print() called
Name : 김수진
Address : 서울
University : 서울대
부산대 information is being deleted.
김혜진 information is being deleted.
서울대 information is being deleted.
김수진 information is being deleted.
이 출력은 첫번째 글의 StudentInfo에 대한 설명에 나온 코드와 조금 다른데, 그 이유는 제가 출력문만 보기 편하게 조금 손질했기 때문입니다. 또한 전체 코드는 여기에 있습니다.
university_student_class_init 함수의 출력을 보면 university_student_parent_class에서 부모의 class pointer를 출력하고 있는데, 이 값이 StudentInfoClass의 출력 값과 같습니다. 즉 university_student_parent_classs는 정확하게 부모의 class pointer 값을 가지고 있음을 알 수 있습니다.
student_info_base_init 함수의 호출 순서를 살펴보면 이 함수가 언제 쓰이는지 알 수 있습니다. 즉 student_info_class_init가 호출되기 전에 한번, university_student_base_init가 호출되기 전에 또 한번 호출되었는데, 이는 student_info_base_init 함수가 class hierachy에서 자신을 포함한 모든 자식 class가 만들어질 때마다 호출됨을 의미합니다.
uobj2를 생성할 때에는 class 생성 함수들이 호출되지 않는 것도 볼 수 있습니다. 이는 object-oriented programming의 특성으로, class는 한번만 생성되고 instance는 여러 개가 생성되므로 당연한 결과 입니다.
이상으로 GObject 상속에 대한 내용을 마칩니다. 다음에는 interface에 대한 내용을 다룰 예정인데, 글을 올리는 것이 생각보다 많은 노력이 들어가네요. 게다가 Algorithm 연구 등 개인적으로 공부하는 것도 많아서 글을 올리는 속도가 굉장히 느립니다. 그렇지만 GObject 뿐만 아니라 GLib API까지 다루어보고 싶고, 아무리 오래 걸리더라도 그 목표를 달성하고 싶습니다.
2013년 4월 2일 화요일
Git 과 svn 비교 - svn 대비 git의 차별점
Git에 대해 생각했던 점을 정리해보려 합니다. 이 글은 git을 처음 시작하는 분이나, 혹은 git을 이미 잘 사용하고 있는 분에게도 생각해볼 만한 유용한 내용을 공유하려는 목적으로 작성되었습니다.
git을 사용하면서 스스로에게 다음과 같은 질문을 할 때가 많았습니다.
그런데, 많은 open source projects 들이 git을 사용하고 있고, 소위 잘나가는 개발사들은 git을 기반으로한 source control을 사용합니다. 거기에는 나름의 이유가 있고, 그 이유를 정확히 알아야 우리가 각 project에 최적인 방법으로 source를 운용할 수 있습니다. 우리가 원하는 것은 결국 소스를 최신으로 유지하면서도 개발자들이 원하는대로 원하는 순간에 수정할 수 있는 방법을 찾는 것이고, 이를 달성하기 위해서는 분산 관리 방식의 장점을 정확히 이해하는 것부터 시작해야 할 것입니다.
svn으로 작업할 때에는 소스를 중앙 저장소에 commit 하기 전에 대부분의 기능을 완성해놓고 commit 하는 경우가 많습니다. 그도 그럴 것이, commit을 한다는 자체가 중앙 저장소에 내가 만든 기능을 공개한다는 뜻이기 때문입니다. 그래서 개발자가 자신만의 version history를 가질 수 없고, commit한 내용에 실수가 있을 시에 다른 개발자에게 바로 영향을 미치게 됩니다. ( 물론, branch를 따서 관리하는 방법도 있지만, 수백명의 개발자의 branch를 따로 만들어주고 관리하는 것은 굉장히 어렵습니다. )
반면, git은 개발자가 자신만의 commit history를 가질 수 있고, 개발자와 서버의 저장소는 독립적으로 관리 가능합니다. 여기서 독립적으로 관리한다는 말은 개발자의 commit이 바로 서버에 영향을 미치지 않는다는 것입니다. 개발자는 마음대로 commit하다가 자신이 원하는 순간에 서버에 변경 내역(commit history)을 보낼 수 있으며, 서버의 통합 관리자는 관리자가 원하는 순간에 각 개발자의 commit history를 가져올 수 있습니다.
통합 관리자가 각 개발자의 commit history를 가져온다는 것은, 각 개발자가 완성한 commit histroy에 대해서 통합 관리자가 차후에 아무때나 가져와 적용할 수 있다는 뜻입니다. 통합 관리자가 각 개발자의 commit history를 가져오기 전에 이미 각 개발자는 자신의 저장소와 서버의 저장소간 통합을 마친 상태이므로 통합 관리자는 별다른 어려움 없이 commit history를 가져올 수 있습니다. ( 여기서 별다른 어려움이 없다는 말은 merge conflicts가 일어나지 않는다는 말입니다. 다른 말로 Fast forward merge 라고 합니다. 클릭하면 커지는 아래 그림 참조. )
Figure 1. git repository의 commit history
이렇게 git은 서버 저장소와 개발자 저장소가 독립적으로 commit history를 가져갈 수 있기 때문에 매우 유연한 방식으로 source를 운영할 수 있으며, 이러한 유연성이 git의 가장 큰 장점입니다. 이 유연성을 바탕으로 바로 우리의 목적인 "소스를 최신으로 유지하면서도 개발자들이 원하는 때에 원하는 만큼 수정할 수 있는 방법"을 달성할 수 있는 것입니다.
따라서 svn과 다르게 git은 굉장히 다양한 방식으로 소스를 관리할 수 있으며, open source projects에서 많이 사용하는 방법들에는 다음과 같은 것들이 있습니다.
위 방식들에 대한 자세한 내용은 http://git-scm.com/book 을 참고하시기 바랍니다.
git을 사용하면서 스스로에게 다음과 같은 질문을 할 때가 많았습니다.
- git이 svn 대비 장점은 무엇일까?
- 왜 많은 조직들이 svn에서 git으로 옮기려고 하는가?
그런데, 많은 open source projects 들이 git을 사용하고 있고, 소위 잘나가는 개발사들은 git을 기반으로한 source control을 사용합니다. 거기에는 나름의 이유가 있고, 그 이유를 정확히 알아야 우리가 각 project에 최적인 방법으로 source를 운용할 수 있습니다. 우리가 원하는 것은 결국 소스를 최신으로 유지하면서도 개발자들이 원하는대로 원하는 순간에 수정할 수 있는 방법을 찾는 것이고, 이를 달성하기 위해서는 분산 관리 방식의 장점을 정확히 이해하는 것부터 시작해야 할 것입니다.
svn으로 작업할 때에는 소스를 중앙 저장소에 commit 하기 전에 대부분의 기능을 완성해놓고 commit 하는 경우가 많습니다. 그도 그럴 것이, commit을 한다는 자체가 중앙 저장소에 내가 만든 기능을 공개한다는 뜻이기 때문입니다. 그래서 개발자가 자신만의 version history를 가질 수 없고, commit한 내용에 실수가 있을 시에 다른 개발자에게 바로 영향을 미치게 됩니다. ( 물론, branch를 따서 관리하는 방법도 있지만, 수백명의 개발자의 branch를 따로 만들어주고 관리하는 것은 굉장히 어렵습니다. )
반면, git은 개발자가 자신만의 commit history를 가질 수 있고, 개발자와 서버의 저장소는 독립적으로 관리 가능합니다. 여기서 독립적으로 관리한다는 말은 개발자의 commit이 바로 서버에 영향을 미치지 않는다는 것입니다. 개발자는 마음대로 commit하다가 자신이 원하는 순간에 서버에 변경 내역(commit history)을 보낼 수 있으며, 서버의 통합 관리자는 관리자가 원하는 순간에 각 개발자의 commit history를 가져올 수 있습니다.
통합 관리자가 각 개발자의 commit history를 가져온다는 것은, 각 개발자가 완성한 commit histroy에 대해서 통합 관리자가 차후에 아무때나 가져와 적용할 수 있다는 뜻입니다. 통합 관리자가 각 개발자의 commit history를 가져오기 전에 이미 각 개발자는 자신의 저장소와 서버의 저장소간 통합을 마친 상태이므로 통합 관리자는 별다른 어려움 없이 commit history를 가져올 수 있습니다. ( 여기서 별다른 어려움이 없다는 말은 merge conflicts가 일어나지 않는다는 말입니다. 다른 말로 Fast forward merge 라고 합니다. 클릭하면 커지는 아래 그림 참조. )
따라서 svn과 다르게 git은 굉장히 다양한 방식으로 소스를 관리할 수 있으며, open source projects에서 많이 사용하는 방법들에는 다음과 같은 것들이 있습니다.
위 방식들에 대한 자세한 내용은 http://git-scm.com/book 을 참고하시기 바랍니다.
2013년 1월 30일 수요일
GObject example source codes
제가 예제로 작성한 코드를 공유하려 합니다.
git://github.com/seungzzang/DES-GObject.git
위 주소를 입력으로 git clone 하시면 전체 소스를 받으실 수 있습니다.
git clone git://github.com/seungzzang/DES-GObject.git
소스 내용 중, iface 라는 directory가 있는데, 여기에 있는 소스는 interface를 설명할 때 사용할 것입니다.
아주 간단한 소스이지만, GObject를 처음 공부하는 분들에게는 도움이 되리라 생각합니다.
이 소스를 compile 하려면 glib-2.0, gobject-2.0 libraries 이 필요합니다.
이 소스를 compile 하려면 glib-2.0, gobject-2.0 libraries 이 필요합니다.
피드 구독하기:
글 (Atom)