달가락의 장난소

달가락의 장난소 http://dalgarak.egloos.com 알아서 남 줘야지. 근데 남 줄만큼 아는게 없다는 문제가 있지요. -_-; ko Tue, 03 Nov 2009 15:11:15 GMT Egloos 달가락의 장난소 http://pds7.egloos.com/logo/200712/18/28/d0051528.png http://dalgarak.egloos.com 77 77 알아서 남 줘야지. 근데 남 줄만큼 아는게 없다는 문제가 있지요. -_-; <![CDATA[ 많은 사람들이 착각하는 것. ]]> http://dalgarak.egloos.com/3411654 http://dalgarak.egloos.com/3411654
1. Win32 API 레벨에서 Path Delimiter는 forward slash('/')를 지원한다. 무조건 backslash('\\') 를 사용해야 한다는 편견을 버려주시길. 다만 인터페이스 상 슬래시를 다른 용도의 delimiter로 사용할 수 있기 때문에, 지원 안하는 것 처럼 보일 수 있지만. 멀티 플랫폼을 위한 프로그래밍을 해야 한다면, 그냥 슬래시를 사용하는게 속이 편하다.

2. GNU/Linux, gcc에서 -fshort-wchar를 써서 wchar_t를 표현하는 데 UCS-2를 사용할 경우 (대부분의 GNU 플랫폼에서는 UCS-4를 사용한다. 윈도우는 UCS-2.) 시스템의 (g)libc API function을 사용하는 것을 포기해야 한다. (ex. wcslen(), wcsdup() 등) gcc 매뉴얼에서도, -fshort-wchar는 binary incompatible code를 생성한다고 명시되어 있다. 뭐 이래저래 따져볼 것 없이, 가장 간단한 문제로 Null-Terminated String을 읽어낼 수 없기 때문에(데이터는 2byte에 걸쳐있는데, libc function에서는 4byte씩 읽어대기 때문.) SIGSEGV가 빵빵 터지게 된다. 만약 멀티 플랫폼을 위한 프로그램이라면, 해당 wide character를 하나로 통일한다고 끝나는 문제가 아님을 기억해 두고, 내부에서 wcs*() 계통의 함수를 대체할 대체 함수를 같은 조건 (-fshort-wchar)에서 빌드하여 해결해야 한다.

애시당초 wchar_t 의 representation에 대한 표준이 없기 때문에 발생한 문제긴 하지만, wchar_t * 계통의 데이터를 담는 데이터를 생성하고, 다루는 플랫폼이 다를 경우에는 이를 신경 써줘야 한다.

3...

이후는 다음에 생각나면 더 적을련다.
]]> 재미없는것들 http://dalgarak.egloos.com/3411654#comments Tue, 03 Nov 2009 15:11:15 GMT 달가락 <![CDATA[ GNU/Linux상에서의 Daemonizer. ]]> http://dalgarak.egloos.com/3399404 http://dalgarak.egloos.com/3399404 stdin, stdout, stderr의 /dev/null redirection, fork()등 해 줘야할 것을 왠만큼 다 해준다.

더 궁금하시다면, man 3 daemon

Hangup signal(=SIGHUP)에서의 reloading, Interrupt(=SIGINT)에서의 중단 등에 대해서는 적절한 sigaction() 처리를 추가로 함께 하면 된다.

끝.

tag : daemon, linux, C ]]> daemon linux C http://dalgarak.egloos.com/3399404#comments Wed, 28 Oct 2009 13:02:40 GMT 달가락 <![CDATA[ IIS 6 동적 컨텐츠 압축 ... ]]> http://dalgarak.egloos.com/3374311 http://dalgarak.egloos.com/3374311 UTF-8 Page, "text/xml" ContentType의 데이터를 전달할 때,
왠만해서는 문제가 안생길 텐데, 브라우저에서 압축이 풀린 후에 뭔가 데이터가 꼬이는 현상이 벌어졌다.
CodePage나 CharSet을 지정안해서 벌어지는 문제도 아니고,

그래서 일단 동적 압축을 끄는 것으로 해결은 했는데, IIS 6에서 이런 경우는 처음일세.

tag : asp, charset, troubleshooting, http, compression ]]> asp charset troubleshooting http compression http://dalgarak.egloos.com/3374311#comments Fri, 16 Oct 2009 08:29:58 GMT 달가락 <![CDATA[ 요새 다시 생각하는 것 ]]> http://dalgarak.egloos.com/3362656 http://dalgarak.egloos.com/3362656
1. TCP

* 짧은 통신이 필요한 클라이언트 단이라면 SO_RCVTIMEO/SO_SNDTIMEO를 사용해도 괜찮다고 생각하는 건 금물. 사용 안하는게 몸에 좋다. blocking + Poll(Select)가 차라리 낫다. 입출력이 많다면 Non-blocking socket을 심각하게 고려하고, 통신 과정에 대한 간단한 finite state machine을 정의해 놓는게 이래저래 모델을 손쉽게 갈아타는데 도움이 될 것이다.
* WSAEventSelect(). 속도는 그럴싸한데... 개별의 Event Monitoring을 위한 thread가 필요하다는 사실을 잊지말것.
* 당연한거지만 Response Time이 중요하다면 Nagle Algorithm은 끄도록 한다.

2. 기타 코딩 관련
* Win32 Thread를 생성하기 위해 static class member function을 사용할려면 인자로 자신의 클래스 인스턴스를 참조해야, non-static member function을 조작할 수 있다. static member function을 thread-safe하게 작성하려면, 고민을 좀 더 해야 한다.
* ATL을 가지고 Active Server Components를 작성할 때는, 인터페이스를 thread-safe하게 만들어둬야 한다.
* 여러개의 문자(character)를 매칭하고, 필터링할 경우, STL string에서는 find_first_of()를 사용하도록 한다.

3. 검색
* 형태소 분석 결과로 나타난 어절과, 원래 문장상에 나타난 어절이 일치하는 용언에 대한 boosting은 입력된 질의문에 대한 직관적인 결과를 필요로 하는 지금 현재의 세태에선 필수적이다. n-gram이라면 이런 고민은 당연히 덜 하게되겠지만, 색인어 추출을 위해 언어 처리 기술을 사용하는 경우에는, 몇몇 용언과 접사에 대한 positive / negative boosting이 필요하다.

- 영어의 경우 이러한 고민이 적게 들어가는데, 한글은 좀 다르다. made의 경우 stemming된 결과가 make라고 할 경우, 어차피 Inverted Index 상의 Dictionary에서는 made, make가 들어갈 것이기 때문에, Term Frequency의 영향으로 made가 랭킹에서 상위에 위치하게 되지만, 한글의 경우 이러한 boosting 없이는, 질의어가 형태소 분석 결과가 동일한 경우(e.g. '갈다') 모호한 단어가 (e.g. '가는', '가시다') 원형 단어의 순위와 혼재되어 나타날 수 있음을 잊지 말아야 한다.

* 형태소 분석 후 품사 태깅을 할 때, 해당 단어의 품사 중의성을 해소하기 위해 인접 어절을 살펴보게 되는데, 문서의 경우 색인을 하면 충분히 문장이 길기 때문에 이러한 정보를 통해 확률이 낮은 후보가 제거 가능하지만, 사용자 입력 질의문의 경우 대부분 짧은 용언이나 명사를 입력하기 때문에 모든 후보를 다 뽑을 수 밖에 없다. 그래서, 이 들 색인어 추출의 기준이 다르기 때문에 발생하는 격차에 대한 고민을 같이 해야 한다.

뭐 더 있긴 한데 나머지는 기억이 안나서. 생각은 많은데 ...

tag : tcp, 정보검색, 형태소분석, 검색 ]]> 정보검색 tcp 정보검색 형태소분석 검색 http://dalgarak.egloos.com/3362656#comments Sun, 11 Oct 2009 03:56:06 GMT 달가락 <![CDATA[ IE 8 + Visual Studio 2005, 2008에서 변수 / 함수 생성 마법사 오류를 위한 Workarounds ]]> http://dalgarak.egloos.com/2170685 http://dalgarak.egloos.com/2170685 버그에 대한 상세한 내용은 다음의 링크 [http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=425510] 를 참조하세요.

Workaround 소개 페이지:

http://blogs.msdn.com/vcblog/archive/2009/03/28/some-vs2005-and-vs2008-wizards-pop-up-script-error.aspx

MS VC++ 팀 블로그에서 소개한 내용입니다. IE 8 설치하고 나서 변수 / 함수 마법사 등을 사용할 때 발생하는 오류에 대한 Workaround 입니다. 자세한 내용은 위를 따라가시면 될 듯 하고, 그냥 간단하게 클릭으로 내용을 추가하실려면 아래의 레지스트리 파일을 받으시고, 더블 클릭해서 추가하면 끝납니다. (64bit OS를 사용하시면 32-bit regedit를 사용하셔야 합니다.)

이후에 정확한 패치가 나오겠...지만(?) 이전에는 이를 통해 해결하시면 됩니다.

d0051528_VS200x-IE8-WorkArounds.reg

그것 말고도 http://jiangsheng.spaces.live.com/blog/cns!1BE894DEAF296E0A!878.entry 페이지를 통해 소개된 Workaround 프로그램이 있지만, 방식은 동일합니다. 1207 이외의 엔트리에 대해서도 규칙을 추가한다는 점을 제외하면 말이죠.

tag : VisualStudio, IE8, ScriptError, Workarounds ]]> VisualStudio IE8 ScriptError Workarounds http://dalgarak.egloos.com/2170685#comments Mon, 30 Mar 2009 04:29:13 GMT 달가락 <![CDATA[ win32 ftell() 사용시 주의사항. ]]> http://dalgarak.egloos.com/2168393 http://dalgarak.egloos.com/2168393
win32에서는 fopen() (혹은 _fopen()) 사용시 append, binary 모드를 옵션으로 열고,
바로 ftell()를 찍으면 파일의 끝 포지션이 아니라 첫 포지션이 나오는 현장을 목격.

이건 뭥미 싶어서 대강 보니까, MSDN ftell() function (CRT)에 다음 구절이 적혀있다.
"If no I/O operation has yet occurred on a file opened for appending, the file position is the beginning of the file."

당연히 두번째 파일을 다시 열 때는 정상적으로 마지막 포지션이 나올 것이다.

따라서, win32에서는 열고 난 뒤 닥치고 fseek(fp, 0, SEEK_END)를 써서 끝 포지션으로 옮겨줄 것.

덕분에 포팅했던 녀석에서 거하게 삽질해주셨음.

tag : ftell, win32, 으으, 개념ㅇ벗음 ]]> ftell win32 으으 개념ㅇ벗음 http://dalgarak.egloos.com/2168393#comments Tue, 03 Mar 2009 12:58:44 GMT 달가락 <![CDATA[ 대용량 MS Access Database(.mdb)를 SQL Server로 마이그레이션: SSMA ]]> http://dalgarak.egloos.com/2167683 http://dalgarak.egloos.com/2167683
이번에는 조금 이야기가 많이 다릅니다:

여기 1.03GB (1,106,890,752 바이트) 용량의 MS Access DB 파일이 있습니다. 본 텍스트 파일은 500MB 남짓 하는 데이터인데,
DB로 마이그레이션 하기 위해 이런저런 삽질을 하다가 아래의 도구를 사용해서 해결했습니다.

총 row 수가 1,500,000 정도 되는데, 데이터 양이 제법 크다보니 ALTER TABLE 거는 것도 만만치가 않아서, 처음 임포팅할 때 인덱스라던지, constraint를 그대로 이전하고 싶었거든요. SQL Server 2005의 '가져오기' 마법사로는 constraint가 보존이 안되는 문제가 있었구요, MS Access의 'ODBC로 내보내기' 기능은 올바르게 동작하지 않았습니다. 양이 많다보니 ODBC 타임아웃이 걸려버리더랩니다.

그래서 이래저래 찾아보니 SSMA(SQL Server Migration Assistant) for Access 라는게 있더라구요. Access 말고도, Oracle, Sybase to SQL Server 2005 마이그레이션 툴이 존재를 하고 있었습니다.

SQL Server Migration Assistant for Access 다운로드 (아래 버전 다운)

링크를 따라가보니, MS Access 2007 대응의 마이그레이션 도구도 이미 있더라구요. 아래 버전을 사용하시면 Access 2007 DB(.accdb)를 사용할 수 있습니다.

SSMA(SQL Server Migration Assistant) for Access 4.0

다만, 사용하실 때 조금 귀찮지만, 라이센스를 등록하라고 나옵니다. 링크를 누르시고, passport id(핫메일 계정 정도) 넣으시고 간단하게 등록하시면 라이센스 파일을 받을 수 있습니다. 나머지는 그냥 안내문만 따라가시면 무사히 이전을 할 수 있습니다.

대용량이건 나발이건 일단 위 녀석으로 무사히 임포팅을 했습니다. 우.

tag : access, SQL2005, Migration, 마이그레이션, -ㅅ- ]]> 재미없는것들 access SQL2005 Migration 마이그레이션 -ㅅ- http://dalgarak.egloos.com/2167683#comments Tue, 24 Feb 2009 11:46:25 GMT 달가락 <![CDATA[ win32 포팅, 그리고 Pthread for win32를 사용시 주의사항 ]]> http://dalgarak.egloos.com/2166011 http://dalgarak.egloos.com/2166011 이제 그 프로그램을 win32에서 작동시켜야 하는 입장이 되어 이래저래 간단하게 포팅했었다. 뭐 순수 C 코드라 몇몇 VS 2005에서 가려대는 Deprecated된 POSIX 함수를 제외하면 포팅에 큰 무리는 없었다. 포팅을 요청한 클라이언트에게는 대략 2주라고 이야기 했었는데, 이틀 정도 잡으니까 3개 정도를 포팅할 수 있었다.

일단 몇몇 파일 다루는 쪽을 포팅하면 완전히 다 끝날 것 같다.

gettimeofday()와 같이 시간을 다루는 함수, 그리고 readdir() 과 같은 디렉토리 관리 함수, 그 밖의 getopt() 같은 것은 직접 구현하거나, 구글링을 해서 잘 만들어진 win32용 구현체를 구하던지 해서 포팅을 진행해야 한다. winsock의 경우, WSAStartup()을 사용하여 초기화 해주는 것만 잊지 않고, 소켓을 닫을 때 close() 대신 closesocket()을 사용해야 한다는 것, 그리고 read() / write() 대신 recv() / send()로 갈아타주면 된다는 사항을 빼면 큰 문제는 없을 것이다. 뭐 적절히 #if(n)def 절을 잘 사용해서, VC++임을 확인할 수 있는 _MSC_VER 와, WIN32 define으로 가려주면 ... 지저분한 코드가 되겠지만 각각의 플랫폼을 존중해 줄 수는 있을 것이다.

open()을 사용할 때 (VS2005에서 권장하는 네이밍은 앞에 _(underbar)가 더 붙는다) 주의 사항은, *NIX에서 바이너리 데이터를 다룰 때 굳이 IO_BINARY 플래그를 세팅해 줄 필요가 없었던 것과 달리, win32에서는 반드시 세팅해 줘야 한다. 그리고, S_IREAD|S_IWRITE 역시 세팅해줘야 close() 이후에 해당 파일의 attribute에 read-only가 걸리는 현상을 막을 수 있다.

여튼, 이전에 솔라리스 - pthread로 포팅 하던 가운데 실수를 좀 저질렀으나,
운빨(?)로 잘 돌아가던 녀석이 pthread for win32에서 민감하게 반응해 준 터라, 실수를 잡아낼 수 있었다.

주의사항은,

1. pthread_mutex_t 를 사용할 때는 반드시 pthread_mutex_init()를 해주던가, static으로 설정하는 녀석을

static pthread_mutex_t pt_mutex_ids = PTHREAD_MUTEX_INITIALIZER;

로 초기화 해줘야 한다. 신기하게도, init를 하지 않을 경우 pthread_mutex_unlock()에서 빵- 하고 터지더라.

2. 각 thread의 stack size를 반드시 설정해 줄 것.

뭐 사용하는 스레드의 수에 맞게 조정해야 할 일이지만, 리눅스나 기타 POSIX 호환 시스템의 경우 스레드당 기본 스택 사이즈가 주어지기 때문에 보통은 별로 신경 안써도 문제가 없는 항목이다.
그런데 pthread for win32의 경우 pthread_attr_setstacksize()를 사용하여 초기화 하지 않으면 기본 stack size가 0이 되어버려, Visual Studio (포팅에 사용한 컴파일러는 VC++ 2005.)에서 0xC00000FD stack overflow를 일으키고 프로그램이 죽는 현상이 발생하게 된다. pthread for win32를 사용할 때, stack overflow가 발생하면 일단 thread stack size를 확인해보는 것이 좋겠다.

둘 다 pthread를 다룰 때 기초적인 사항이지만, 생각 없이 코드를 다루다보니개념부족으로 이런 삽질을. 으하하.

tag : pthread, pthread_for_win32, vs2005, porting ]]> 재미없는것들 pthread pthread_for_win32 vs2005 porting http://dalgarak.egloos.com/2166011#comments Sun, 08 Feb 2009 03:59:21 GMT 달가락 <![CDATA[ MS Office 2007 excel파일(.xlsx)을 MS-SQL 2005(또는 기타 ODBC를 지원하는 DBMS)로 이전하기 ]]> http://dalgarak.egloos.com/2165242 http://dalgarak.egloos.com/2165242
아래 내용 한줄 요약 : MS Access에서 Excel 파일의 내용을 가져올려면 "외부 데이터" 메뉴를 통해서 import 해야 한다. 걍 파일 열기로 링크 시켜버리면 대략 낭패.

----

최근 일 때문에 엑셀로 온 데이터를 MS-SQL에 삽입해야 하는 일이 생겼다. (.. 엑셀 파일로 주시더라;) 그런데, 다음과 같은 문제가 있어 import를 할 수 없는 상황에 처해 있었다.

문제는 다음과 같다:

(1) MS-SQL 2005의 SQL Server Management Studio의 Import 기능에는, xls로 부터 읽어들일 수는 있으나 Office 2007용 호환인 xlsx 파일 형식으로는 읽어들일 수 없다.
(2) 이게 오피스 2007 전용이고, 97-2003 호환인 xls로 변환하기에는, row의 수가 65535개를 넘어서는 구간을 올바르게 표현할 수 없다는 거.
(3) 혹시나 해서 Microsoft Office 12.0 Access Database Engine OLE DB Provider를 사용하여 Import를 시행, *.accdb (오피스 2007용 access 파일) 파일을 읽어들일 수는 있었으나 excel 파일로 링크된 테이블을 가져올수 없는 문제가 있음을 확인했다.

--

그래서 일단은 MS Access 2007을 사용하여 해결하려고 한다. 다행히도, 살펴보니 SQL Server로의 이전 기능을 포함하여, ODBC로 Export 하는 기능이 있어, 이를 사용하기로 했다. 일단 MS Access에서는, 외부 excel 파일을 연결하여 표현할 수 있었으므로, excel 파일을 access로 읽어 일단 테이블 형태로 볼 수 있도록 했다. 그런 다음 아름답게 odbc 연결을 사용하여, 대상 SQL 서버에 대한 ODBC 연결을 생성하고, 이를 통해 export를 하였다.

그런데, 사소한(?) 문제가 더 있음을 확인. 대놓고 일단 Export를 해서 MS-SQL에 심는 것은 했는데, 예상하고 있던 row count보다 값이 모자란다. 어딘가에서 누락이 일어났다는 뜻. 필드의 사이즈 규칙등을 벗어나는 경우 누락이 일어난다.

어떻게든 문제를 해결하고자, id를 excel 파일에 부여를 했다. 기존 excel 파일에는 각각의 row에 id로 부를 만한 데이터가 존재하지 않았다. 총 row count는 대략 51만. 일단 =row()-1 (일단 맨 첫번째 row는 각 column의 이름이 들어가기 때문)을 사용하여, 각 row에 번호를 부여하였다.

* 그리고, access에서 excel의 데이터를 가져올 때, 바로 excel 파일을 "열기"로 가져오지 않고, 메뉴의 "외부 데이터 - Excel"을 사용하여, 데이터를 가져온다. (이렇게 하면 연결이 아닌, 새로운 DB 테이블로 만들어지게 된다) 이때, 기본적으로 excel 파일을 읽어오면 테이블 구조를 텍스트로 바꾸고, 각 해당 컬럼은 255자를 넘어갈 수 없는 문제가 발생하게 된다. 이를 예방하기 위해, 255자가 넘는 경우 컬럼 타입을 "메모"로 변경해서 가져오도록 한다. 여기서 인덱스도 설정해주고 ... 기타 등등 하면 된다;

그런 다음, Export를 사용하여 ODBC (또는 데이터베이스 도구 메뉴 - SQL Server 선택) 연결을 통해, SQL 서버로 데이터를 이전하면 된다. 시스템에 ODBC 커넥터만 있으면, 어떤 DBMS도, 테이블 - Export - ODBC를 통해서 내보낼 수 있다.

tag : xlsx, 엑셀2007, access, office2007, ODBC, SQLServer, 기초개념부족으로인한삽질 ]]> 재미없는것들 xlsx 엑셀2007 access office2007 ODBC SQLServer 기초개념부족으로인한삽질 http://dalgarak.egloos.com/2165242#comments Sat, 31 Jan 2009 07:22:00 GMT 달가락 <![CDATA[ Visual Assist X 설치 때 Registering 중 얼어버리는 현상 해결법. ]]> http://dalgarak.egloos.com/2163933 http://dalgarak.egloos.com/2163933 VA X의 가장 최신 버전인 10.5.1711.0 에서도 역시 마찬가지로 동일한 문제가 있고, 고쳐질 예정도 아닌 것 같으므로 알아서 다음과 같이 해결하면 된다.

문제 해결법의 원문은 아래의 링크를 확인.

http://www.wholetomato.com/forum/topic.asp?TOPIC_ID=5687

CVSNT가 대표적으로 u3dapi10.dll을 사용하는데, 설치 프로그램이 동작 중에 u3dapi10.dll을 읽어들이게 되면 설치 프로그램이 Visual Studio에 플러그-인을 등록하는 과정에서 얼어버리게 된다.

CVSNT(TortoiseCVS 역시 마찬가지다)를 미리 설치했던 사람은, C:\Program Files\CVSNT 디렉토리 내의 u3dapi10.dll의 이름을 살짝 바꿔놓고 VA X를 설치하면 된다. (당연히,) 설치하고 나서 다시 원래 이름으로 바꿔주는 센스가 필요.

다른 경우에도, 역시 마찬가지로 Path에 포함된 디렉토리를 싹 뒤져서 u3dapi10.dll을 찾아서 이름을 바꾼 후 설치하면 된다. - ㅅ-;

뱀꼬리. 이글루스에서 블로그 입력 중 Ctrl+S를 누르면 저장이 되는구나. 무심코 Ctrl+S를 눌렀다가 뭐시기 저장되었습니다... 라는 글자가 얼핏 보여서 움찔했다능.

뱀꼬리 2. 일이 많고 기록할만한게 ... 없어서 블로깅은 여전히 느립니다. 근래에 해본 것 중에 인상 깊었던건 리소스 처묵처묵한다고 맨날 두들겨 맞던 노턴 안티바이러스가 2009 버전에서 환골탈태를 했더군요. BitDefender Antivirus 2009 보다는 전반적으로 가볍더랍니다. 조금만 구글링 하시면 OEM 버전의 90일 Trial을 구하실 수 있습니다.

tag : VisualAssistX, CVSNT, Freeze, Installation, VA, VA_X ]]> 재미없는것들 VisualAssistX CVSNT Freeze Installation VA VA_X http://dalgarak.egloos.com/2163933#comments Sun, 18 Jan 2009 12:02:27 GMT 달가락