Pictures 한밤중에 끄적이는 낙서.. 2017/02/21 01:30 by WSID

가끔씩 낙서를 그려주니 재밌고 좋군요.

피로하다는 것이 문제지만...;;



Computing 2017년 02월 15일의 Onggi 2017/02/15 03:17 by WSID



안녕하십니까. 다소 타이밍이 늦였지만, 이렇게 글을 올려봅니다.

1. 2주간 한 것들 ...


지지난주부터 진행된 일이라고는...

유감스럽게도 (...) 빼먹은 단위 테스트를 집어 넣거나 하진 않고, 소스코드를 다듬는 수준에서 끝났습니다.
전반적인 구조를 변경할 생각을 하니 (착하신 여러분들은 따라하시면 안됩니다.) 힘이 빠져서입니다.


2. 구조 변경


구조의 변경이 작은 부분이 아니라, 다양한 부분을 변경하기 때문에 하위로 2부분을 나누게 되었습니다. 전반적인 구조는 이 글에서 설명해 놓았습니다.

(다시한번 말하지만, 착하신 여러분들은 따라하시면 안됩니다. 시간을 들여 열심히 만든 탑을 스스로 무너트려야 하는 고통을 받게 됩니다.)




가. ModuleFactory, ModuleFactoryGroup

Module과 이를 구성하는 ModuleObject가 혹여나 Store별로 따로 저장해야 할 값이 생길 경우를 대비하여, 각각의 Store별로 Module 객체를 생성하여 가지고 다니는 형식으로 구성하였습니다. (다시 말하면, 열어놓은 파일마다, Module 객체가 생성되는 것입니다.)

Store별로 Module에 따로 저장할 값을 가질 필요가 없고, 파일을 열 때마다, Module들을 생성하는 것은 부적합하다고 생각하였습니다. Store 하나를 위해 생성될 Module이 한 둘이 아니기 때문입니다.

따라서 ModuleFactoryGroup에서 ModuleFactory를 얻은 뒤 Module을 생성하지 않고, ModulePool에서 Module을 얻는 방식을 사용할 예정입니다.

나. Field와 Compound

Onggi에서는 테이블과 컬럼을 조작하기 쉽도록 Table과 Column 객체를 생성하였습니다. 그리고 이러한 역할에서 더 나아가, 다른 객체에 대한 정보를 저장할 수 있는 TableObj와 객체에서 값을 얻어내는 기능을 추가한 ColumnInstance를 추가하였습니다.

하지만, 이러한 기능 확장은 추가된 특성치가 테이블이나 컬럼에 묶여 버린다는 단점을 가지고 있습니다. 가령 예를 들면, 저장할 객체의 하위 필드가 구조체일 경우, 해당 구조체에 2개 이상의 컬럼을 배치하기 쉽지 않습니다. (물론 일부 DBMS의 경우 구조체 타입을 만들 수 있지만, 주 타겟인 SQLite는 지원하지 않는군요...)

따라서 테이블이나 컬럼보다는, 여러 컬럼들을 아우르는 Field와 이들을 모은 Compound로 나타내고자 합니다. (Compound가 테이블의 집합이 아닌건, 단순한 구조체의 경우 테이블을 만들기보단, 다른 테이블 내에서 여러 컬럼에 걸친 형태로 표현되는 것이 더 낫기 때문입니다.)


3. 객체간 관계

일반적으로 객체는 단순한 데이터가 아닌 이상 다른 객체 (같은 종류일 수 있고, 다른 종류일 수 있습니다.) 와 연관되어 있습니다. C를 비롯한 언어에서는 이러한 참조가 "포인터"의 형태로 나타나지만, 데이터베이스에서는 외래키(컬럼의 값은 항상 참조되는 테이블의 컬럼의 값으로 존재해야 하는 제약조건)의 형태로 나타납니다.

이러한 것을 중간에서 처리할 수 있도록 하는 Relation 객체를 만들고자 합니다.


+

글을 쓰고 지우고 쓰고를 반복하니 확실히 지난번에 썼다가 지워버린 글보단 나아진 듯 하군요... 역시.. 글을 안쓰다보니 글쓰기 능력이 퇴화......

2017년 1월 24일의 근황 2017/01/24 14:02 by WSID

[ 위 그림은 예전에 그린 그림입니다. ]

오랫만입니다.. =ㅂ=;;;
비슷 비슷한 날들을 지내홨었지만, 그러한 날들이라도 쌓이고 쌓이다 보면 뭔가 이야깃거리가 되는 것 같습니다.

1. Onggi

일단 얼추 기본적인 뼈대는 갖춘것 같으니, 기능의 추가는 잠시 멈추고, 일단 내부 정리를 하면서 0.2를 준비해야 할 것 같습니다. 아직 Pencilator에 필요한 기능을 갖춘건 아니지만, (서로 연관된 객체를 저장 및 불러오기 등..) 지금껏 급히 작성해온 감이 있고 많은 기능들이 추가되어 복잡해지기도 하였습니다. 또 불완전한 기능을 제거하는 시간도 될 것 같습니다.

일단은 이번주와 다음주를 통해 정리 작업을 마치고 0.2라고 딱지를 붙여야 할 것 같습니다.



2. Haskell의 겉을 핥아보기

제가 주로 쓰는 언어가 C이고 가끔씩 만지작 거리는 언어는 Vala를 비롯하여, 객체지향적 성질을 가지고 있는 언어입니다. 하지만, 함수형 언어가 대두되고 있는 상황인지라, 저는 이 중에서 Haskell의 겉을 핥아 보았습니다. 하지만, 역시나 크게 다른 문제 해결 방식에 너무 적응하기 어렵군요... 객체가 중심이 아니라, 함수가 중심이 되다보니 힘든 것 같습니다.

"함수형 사고"라는 책이 도서관에 있어서 한번 읽어본 적이 있는데, 다시 한번 읽어보면 어떤 느낌일지..



3. Astroneer

행성의 자원을 채취해서 기지와 차량 등을 건설하고, 더 깊은 곳의 자원을 캐러 가거나, 아니면 다른 행성의 자원을 캐러가는 게임인 Astroneer를 구매햐여 플레이 하였습니다. 높은 컴퓨터 사양을 요구하는 것만 빼면, 극 초기 버전임에도 재밌게 플레이 하였습니다.

일단 해볼껀 다 해보았기 때문에, 어느정도 업데이트가 있기 전까진 당분간은 덮어둘 듯 싶습니다.. (...)




4. "The Lost" in Binding of Isaac: Afterbirth

Binding of Isaac: Afterbirth에서 The Lost를 언락하여 플레이 하고 있습니다. 옛날 보다는 많이 언락이 쉬워져서 언락을 할 수 있었습니다만, 한방만 맞아도 죽는 특성도 있지만, 기본 성능이 이를 벌충해 주지 못하기 때문에 플레이 자체도 많이 어렵습니다.

(어떠한 공격 1회에도 사망, 빨간 하트 충전 불가, 소울 하트 등은 즉시 증발)

하지만 이 캐릭터로 보스 클리어시 좋은 아이템이 언락되기도 하기 때문에 일단은 플레이 하고 있습니다.

(그리고 나중에 그리드도 언락을)



5. Lollypop 음악 플레이어


음악 플레이어로 Gnome Music을 써보았다가, Lollypop 음악 플레이어를 써보았습니다. 둘다 제목 표시줄에 버튼 등을 달고 있지만, 자세히 보면 다른 모양을 하고 있습니다. 개인적으로 제일 맘에 드는 부분은 창을 최소한으로 줄이면 미니모드로 작동하는 점이었습니다.

[좌측: Gnome Music  ...  우측: Lollypop]
[아래: Lollypop 창을 아주 작게 줄였을 때]



Computing 2017년 01월 17일의 Onggi. 2017/01/17 00:12 by WSID

안녕하세요~! 일요일에 써서 올렸어야 했지만, 이러쿵 저러쿵 하다보니 오늘 글을 써서 올리게 되었습니다. (...)

  1. 이름 덧붙이기


같은 이름의 테이블이 생성되는 것을 막기 위해 덧댄 이름을 사용하곤 합니다. 기존에는 수동으로 이름을 덧대어 썼지만, 지금은 자동으로 이름을 덧대어 쓸 수 있도록 하였습니다.



2. CREATE 속성 지정

테이블의 생성에 있어서는 다양한 특성이 적용됩니다. 어떤 특성은 크게 신경쓸 부분이 없어서 넘어갈 수 있지만, 어떤 특성의 경우는 성능등에 크게 영향을 미칠 수도 있습니다.

libgda는 테이블 생성을 비롯하여, 다양한 부분에서 세부적인 특성을 GdaServerOperation을 통해 조절할 수 있도록 하였습니다. 저는 이런 특성을 생성시에 GdaServerOperation에 전달할 수 있도록 함수를 추가하였습니다.

void onggi_module_object_set_create_attr (OnggiModuleObject *object,
    const gchar *attr,
    const gchar *value)

void onggi_module_object_set_create_attr_f (OnggiModuleObject *object,
    const gchar *attr,
    const gchar *value,
    ...)



3. [진행중] OnggiConstruction

OnggiModule을 직접 조립하여 (직접 OnggiTable, OnggiColumn을 생성하여 합치는 방법) 생성할 수 있습니다. 그러나 GUI가 직접 조립에서 데이터를 이용한 생성으로 건너간 것처럼, OnggiModule도 XML등을 이용해서 조립하도록 하였습니다.

전에서도 이야기 한 바와 같이, 이러한 기능을 뒷받침하는 것은 OnggiConstruction입니다. OnggiConstruction은 노드들을 트리 모양으로 구성하여 한꺼번에 객체들을 생성할 수 있도록 합니다. XML에서 객체를 생성해야 한다면, XML의 각 태그를 OnggiConstructionNode로 변환한 뒤, 이를 통해 객체를 생성하는 방식입니다.

기존의 구성 방식은 객체의 속성치를 하나의 노드에 저장하는 방식을 사용하였습니다.

<module name="Subject" version="1">
  <OnggiTableObj name="SubjectUser" g-type="SubjectBook" id-column="Subject/SubjectUser/name">
    <OnggiColumnProperty name="name" g-type="gchararray"/>
  </OnggiTableObj>
</module>

하지만 이러한 방식은 속성으로 기록할 수 있는 속성의 종류가 제한되어 있어서 객체 등을 속성 값으로 지정해야 할때, 이름을 지정해야 합니다. 하지만 이러한 방식은 상황에 따라서는 어색할 수 있어 아래와 같이 객체의 속성치를 하위 노드로 두는 방식입니다.

<module name="Subject">
  <version>1</version>

  <element type="OnggiTableObj" name="User">
    <g-type> SubjectBook </g-type>

    <id-column type="OnggiColumnProperty" name="name">
      <g-type> gchararray </g-type>
    </id-column>
  </element>
</module>

이러한 변경으로 인해, 하위 객체로 추가되는 노드와 속성으로 추가되는 노드를 구분하게 될 필요가 있었습니다. 따라서 노드의 종류가 추가 되었습니다. 그리고 속성으로 추가되는 노드의 경우, 속성의 이름을 구분할 필요가 있었습니다. 그래서 객체의 태그명이 추가 되었습니다.

또한 OnggiConstructionNode는 지나치게 긴 이름인 것 같아, OnggiCNode로 변경하였습니다.

GQuark onggi_cnode_get_kind (OnggiCNode *node);
const gchar *onggi_cnode_get_tag (OnggiCNode *node);

이러한 변경에 덧붙여서 GClosure를 기입하여, 다른 객체의 속성으로 사용하거나 시그널에 연결하는 등을 수행할 수 있는 등의 기능을 추가하였습니다.

이외에도 추가로 보완해야 할 점이 존재하고, 테스트가 되지 않은 기능들이 존재합니다. 따라서 큰 고개는 넘었고, 아직은 진행중이라고 보면 됩니다.


4. 이후?

 Vala로 건너갈려고 생각하고 있습니다. C가 객체지향 언어가 아니다보니, 클래스를 정의하기 위해선, 인스턴스 구조체와 클래스 구조체를 정의해 주고, 속성 등에 있어서도 불편함이 적지 않기 때문입니다. 이러한 불편함에 지쳐버린 나란 사람~!

Computing 2016년 12월 31일의 Onggi 2016/12/31 19:48 by WSID

어쩌다보니 어느새 2016년 마지막 날이 찾아오는군요..!

사실은 지지난주에 글을 올렸어야 했는데, 여러가지로 바빴고, 따라서 추가된 기능도 별로 없기에 이번에 글을 올려 봅니다.

일단 추가된 기능은 유감스럽게도 단 하나.. 이군요...


1. OnggiSaveUnit

객체에 담길 수 있는 데이터는 다양한 크기를 가집니다. 작게는 몇개의 정수부터, 크게는 MB 단위 크기의 사진 등과 같이 다양한 데이터가 저장됩니다. 객체는 자주 변경될 수 있습니다. 그러나 작은 부분은 자주 바뀐다 하더라도 큰 부분은 바뀌는 일이 드뭅니다. 따라서 객체가 바뀔 때마다 전체를 저장하는 것은 비효율성을 가져올 수도 있습니다.

따라서 객체를 여러 부분으로 나눌 수 있도록 OnggiSaveUnit을 추가하였습니다.

OnggiTableObj는 OnggiSaveUnit을 어려개 가집니다.

  onggi_table_obj_add_save_unit (table, save_unit);

OnggiSaveUnit은 OnggiColumn을 여러개 가지며, 각각의 이름을 가지고 있습니다. OnggiTableObj의 모든 컬럼은 적어도 한 OnggiSaveUint에 속하며, 어디에도 소속되지 않는 컬럼은 기본 save unit에 소속됩니다.

  onggi_save_unit_add_column (save_unit, a_column);

OnggiTableObj는 부모 타입의 객체를 저장하는 다른 OnggiTableObj의 OnggiSaveUnit에 "이름이 같은 자신의 OnggiSaveUnit"을 이을 수 있습니다. 다시 말해, 추가한 save unit의 이름이, 베이스가 되는 OnggiTableObj의 한 save unit과 이름이 같다면 하나인 것처럼 이어진다는 것입니다.

이렇게 구성한 것은 save unit을 의미에 따라 구성할 수 있게 하는 것과, save unit이 불필요하게 많아지는 것을 막기 이해서입니다.


애초에 OnggiSaveUnit을 구성한 것은 큰 데이터를 처리하기 위해 방법을 구상하다 나온 것 중에 하나인지라, 제가 쓸땐 아마 한개의 save unit을 굴리게 되지 않을까.. 합니다..

만들어 놓고 쓰질 않는다...





일단은 여기까지.. 이상입니다.

1 2 3 4 5 6 7 8 9 10 다음