xylosper's notebook

Hybrid님이 만드신 SitmoLaTeX Display를 보고, 플러그인을 한번 열어보니, 고정된 주소로 렌더링해주는 거라면 뭐든지 가능하겠다 싶어서 CodeCogs의 LaTeX Equation Editor를 이용하여 Xy LaTeX Editor라는 이름으로 텍스트큐브용 LaTeX편집기 플러그인을 만들었습니다.

이 플러그인은 LaTeX 수식을 표시해줄 뿐만 아니라, 글을 작성하고 편집할때 수식의 미리보기와 수식 입력을 도와주는 툴바를 제공합니다.

플러그인을 설치하면 다음과 같이 글 작성창 하단에 두개의 버튼이 생깁니다.

1. 새 수식 삽입하기
   본문에 새 수식을 삽입하기 위해 수식 에디터를 엽니다.
2. 선택된 수식 고치기
   본문에서 선택된 수식을 고치기 위해 수식 에디터를 엽니다.

어느 버튼을 누르던 다음과 같은 수식 에디터 창이 열립니다.버튼에 따른 차이는, 새 수식 삽입하기 버튼은 아무것도 입력되지 않은 창을 띄우고, 선택된 수식 고치리 버튼은 선택된 수식의 내용이 미리 입력되어있다는 점입니다.

적당히 편집후 확인 버튼을 누르면, 새 수식 삽입되거나 수정될 수식이 갱신됩니다.
참고로 글 작성시에 보이는 것은 어디까지나 '미리보기'입니다. 실제로는 수식내용이 그대로 저장되고, 나중에 다시 글을표시할때 이미지로 치환됩니다.

또한 본문에 직접 [tex*]...[tex*](실제론 tex*가 아니라 tex)사이에 수식을 입력해도 실제로 표시될때 이미지로 치환됩니다.

몇가지 설정가능한 부분이 있는데, 그중 다음 두가지는 약간의 설명이 필요할듯 하여 소개합니다.

1. 자동업데이트 시간
   위에서 설명한 수식 입력후 자동으로 이미지를 갱신해주기 까지의 시간 간격을 밀리초단위로 설정합니다. 0보다 작은 수가 입력되면 자동업데이트기능을 끕니다.
2. 본문 렌더링 여부
   렌더링 설정부분에서 '글 표시할 때'라는 부분이 있는데, 이부분을 체크해제하면 Xy LaTeX Editor의 미리보기 및 편집기 기능만을 이용하게됩니다. 본문의 수식을 실제로 표시하는 것은 다른 방법을 이용하고 싶은 경우에 체크를 해제하면 됩니다.

마지막으로 사이드바에 CodeCogs 배너를 추가할 수 있는 기능이 있습니다.
플러그인을 적용하면 사이드바 위젯에 CodeCogs배너가 선택가능해집니다.
Xy LaTeX Editor의 수식 렌더링은 전부 CodeCogs에 의해서 생성된 것이며, 실제 이미지또한 CodeCogs에 의해서 제공됩니다.
CodeCogs는 이미지를 제공하는 대신, 다음과 같은 배너를 웹사이트에 달아줄것을 '부탁'하고 있습니다.
어디까지나 부탁이므로 이를 따를 의무는 없습니다만, 도리로서 되도록이면 본 플러그인을 이용하시는 분들은 (특히 글 표시할때에도 이 플러그인을 이용하시는 경우에는) 사이드바에 배너를 추가해주길 저도 '부탁'드립니다.
실제로 배너가 달린 모습은 제 블로그의 사이드바에서 볼수 있습니다.

한가지 주의사항이 있는데요, 글 표시할때 렌더링을 CodeCogs로 하는 경우, 과다하게 이미지를 가져다 쓰는 경우 블록될수 있다고 경고하고 있습니다. 일일 10,000번이상의 이미지 요청이 예상될경우는 따로 연락을 달라고 합니다. 자세한 것은 CodeCogs홈페이지의 LaTeX Editor Usage Policy를 참고해주세요.
마지막으로 LaTeX 글이면서 수식이 하나도 없기에, 테스트도 겸해서 몇가지 식을 끄적이고 마칩니다.

어제 하루 종일 낑낑대던 문제가 있었습니다.
싱글톤(singleton)을 이용한 객체를 가져다 쓰는 부분에서 자꾸 segmentation fault가 발생하는 것입니다.

싱글톤의 구현 자체는 다음과 같이 C++에서 극히 일반적인 static변수를이용한 구현입니다.

class Singleton {
public:
    static Singleton *get() {static Singleton self; return &self;}
private:
    Singleton() {}
};

싱글톤 자체는 공유라이브러리에 들어있고, 이것을 서로 다른 두 바이너리에서 동시에 가져다 쓰는 형태인데요, 딱히 서로 다른 쓰레드에서 가져다 쓰는 것도 아니기 때문에, 멀티쓰레딩 환경에서의 static변수로 인한 문제도 없을 것이라 생각하여 별 신경 안썼었습니다.

그런데 이부분에 죽어대니 도대체 원인을 알수 없더군요...

그러던중 구글링 하다가 다음과 같은 글을 발견하였습니다.

function static 스타일의 Singleton 버그?

결론은, Singleton::get()함수가 인라이닝되는 바람에, 싱글톤이 싱글톤이 아니게 된 것이었습니다.

Singleton::get()함수의 구현을 cpp파일로 뺐더니 잘 돌아가네요-_-;

오늘의 교훈: static변수를 이용한 싱글톤 구현은 반드시 해더파일과 분리하자!

LMV를 만들면서 가장 문제가 되던 것이 사전 검색에 시간이 너무 오래 걸린 다는 것이었다.

표제어가 10만개가 넘어가니, 일일이 파일을 오픈해서 처음부터 쭉 읽어가면서 찾자니 시간이 정말 오래 걸리고..

그렇다고 메모리에 올려서 찾자니, 어차피 메모리에 올리는 동안에 시간 걸리고...이건 뭐 쓰레드로 어떻게 한다고 해도, 메모리에 올리면 파일 용량 그대로 올라가는 셈이니 터무니 없이 많이 먹게 되고...

그래서 생각해낸 방법이 사전 파일을 카테고리화해서 쪼갠 다음에, 단어 검색할때, 해당하는 카테고리의 파일만 검색하도록 하는 방법이다.

이것으로 어떻게 시간문제는 해결 했으나, 사전의 통합관리가 불편하고, 무엇보다 이 방법은 사전마다 언어가 다르니 카테고리도 달라지고, 파일개수도 많아 지고..아무튼 확장성이 거의 없다.

그러다가 데브피아에서 조언 받은 SQLite라는 파일DB를 사용해보기로 했다.

사실 지금까지 데이터 베이스 프로그래밍은 공부하던 MFC책의 예제 하나를 그냥 후루룩 넘겨본것 뿐이라 SQLite를 쓰는데 주저감이 있었다.

하지만, 실제로 SQLite를 이용해보니 왜 이걸 안썼는지 후회될 정도로 좋다.

SQLite의 검색 속도나 삽입속도를 0.몇초 식으로 잰 벤치마킹도 많던데, 그런건 모르겠지만, 예전에 사전파일 하나로 되있었을때 단어 하나 검색하는데 길게는 2,3초씩 걸리던 것이, SQLite로 DB화 한후에는 그냥 검색 실행하면 바로 나온다.


무엇보다 좋은 점은, C 라이브러리이기 때문에 C는 물론이고, C++에서도 쉽게 사용할 수 있다는 것이다.

codeproject에서 SQLite용 래퍼클래스를 다운 받아서 쓰고 있는데, 파일 입출력처럼 간단하게 함수 몇개로 조작하면서, 속도는 월등히 빠르니 정말 물건인듯 하다.

꼭 체계적으로 디비디자인해서 써야 되는 상황이 아니더라도, 파일 DB라는 점때문에, 앞으로도 대용량 파일 관리에는 SQLite를 이용하는게 편리할 듯하다.

SQLite 홈페이지: http://www.sqlite.org
사용중인 SQLite 래퍼 클래스: http://www.codeproject.com/database/CppSQLite.asp?df=100&forumid=34722&fr=26