manywaypark's Blog
개발, 검색, 함수

플러그인 설치가 꼬여서 eclipse를 지웠다가 재설치를 했는데,
다음과 같은 에러 로그를 뿌리면서 Ubuntu box에서 eclipse가 실행되지 않았다.

로그 처음 부분:
!SESSION 2008-06-11 19:16:32.612 -----------------------------------------------
eclipse.buildId=M20070212-1330
java.version=1.6.0_03
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Command-line arguments:  -os linux -ws gtk -arch x86_64 -debug -consoleLog

!ENTRY org.eclipse.osgi 2 1 2008-06-11 19:16:35.246
!MESSAGE NLS missing message: initializer_error in: org.eclipse.core.internal.runtime.messages

!ENTRY org.eclipse.osgi 2 1 2008-06-11 19:16:35.247
!MESSAGE NLS missing message: fileInitializer_fileNotFound in: org.eclipse.core.internal.runtime.messages

!ENTRY org.eclipse.osgi 2 1 2008-06-11 19:16:35.248
!MESSAGE NLS missing message: fileInitializer_IOError in: org.eclipse.core.internal.runtime.messages

!ENTRY org.eclipse.osgi 2 1 2008-06-11 19:16:35.248
!MESSAGE NLS missing message: fileInitializer_missingFileName in: org.eclipse.core.internal.runtime.messages

!ENTRY org.eclipse.osgi 4 0 2008-06-11 19:16:35.270
!MESSAGE An error occurred while automatically activating bundle org.eclipse.ui.workbench (8).
!STACK 0
org.osgi.framework.BundleException: The activator org.eclipse.ui.internal.WorkbenchPlugin for bundle org.eclipse.ui.workbench is invalid
    at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:141)


해결법은 간단히 다음 명령어 입력:
$sudo apt-get --purge remove libswt3.2-gtk-*
#lets him remove all eclipse pakages and reinstall eclipse
$sudo apt-get install eclipse
libswt와 모종의 충돌(?)이 있는 듯하다.

참고:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446299#120
https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/109583

happy hackin'

변고

잡담 2008. 6. 11. 13:24 by manywaypark
변고
- manywaypark
어이없게도
청명한 하늘에서
수박만한 우박이......

나라가 어찌되려구 며칠만에 이 모양을 만들어놓는지... 뉴스보기가 무섭다.

명박산성

잡담 2008. 6. 11. 01:32 by manywaypark
발주: 이명박
시공: 어청수
사용자 삽입 이미지

version info:
os:
Windows XP (on Fujitsu Lifebook U1010)
emacs:
This is GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
 of 2007-06-02 on RELEASE
distel:
revision 64


Distel을  make (base)로 설치시에 다음과 같은 오류가 나면서 멈추었다.

emacs -batch -f batch-byte-compile elisp/erlext.el
Cannot open load file: korea-util
make: *** [elisp/erlext.elc] Error 127

emacs 쪽에서 byte compile을 하다가 오류가 난거 같았는데, Makefile을 보니 좀 복잡했다.
그냥 혹시나 하는 마음에 앵무새짓거리 한번...
C:\home\hacking\erlang\distel>emacs -batch -f batch-byte-compile elisp/erlext.el

Loading subst-jis...
Loading subst-big5...
Loading subst-gb2312...
Loading subst-ksc...
Loading cl-extra...
Wrote c:/home/hacking/erlang/distel/elisp/erlext.elc

잉? 된건가?
C:\home\hacking\erlang\distel>make
make: Nothing to be done for `base'.

된거군!
(이유가 궁금하긴 하지만, Windows에서 일어난 일이므로 신경끈다.  ^^)

happy hackin'

cygwin 업그레이드 후에 이전에 본적 없는 눈에 거슬리는 이상한 메시지가 명령을 내릴 때 마다 출력되었다.
윈도우에서 fstab를 찾는 것은 좀 이상하지 않은가?
Huh?  No /etc/fstab file?  Using default root and cygdrive prefix...

mount
로 현재 마운트 된것들을 살펴보고 그것들을 %CYGWIN_HOME%/etc/fstab에 저장해주면 된다.

다음은 내 경우다. (c와 d가 hdd이므로 마운트하고, e는 SD card 이므로 안 써준다.)

C:\>mount
Huh?  No /etc/fstab file?  Using default root and cygdrive prefix...
c:\cygwin on / type ntfs (binmode,system)
c: on /cygdrive/c type ntfs (binmode,noumount,user)
d: on /cygdrive/d type ntfs (binmode,noumount,user)
e: on /cygdrive/e type vfat (binmode,noumount,user)


/etc/fstab :
c:/cygwin / system binary 0 0
c:/cygwin/bin /usr/bin system binary 0 0
c:/cygwin/lib /usr/lib system binary 0 0
# c: /c system binary 0 0
# d: /d system binary 0 0

왜 이렇게 불편하게 되었는지는 모르겠다.
(맨 밑에 두줄은 대충 되는 것같기도 하나, PATH 설정이 좀 꼬여서 특정 application(make 등)에서
문제가 생기는 듯하다. 빼자.)
참고: http://article.gmane.org/gmane.os.cygwin/97894

happy hackin'

 

개발 작업

잡담 2008. 5. 16. 21:31 by manywaypark
늦은 출근길에 문득 든 생각.
개발 작업은 GCVL이 아닐까?

GCVL -> google, ctrl-c, ctrl-v, loop.


물론, Lisp의 REPL에서 따온말이다. ^^

내 버전은 (emacs 사용자이므로),

GWYL -> google, M-w, C-y, loop.


happy hackin'
둘 다 Bill Clementson님의 글이다.
처음 것은 약간 간략 버전(?) 정도 된다.

Setting Up SLIME for Win32 CL Implementations
The Common Lisp Cookbook - Setting up an IDE with Emacs on Windows or Mac OS X

중생들이 많이 사용하는 Windows/OSX에서 다양한 CL implementation들을 설정하고 사용하는 법에 대해서 설명해주는 주옥같은 글들이다.

Bill에게 경의를...

ps. 갑자기 위 글들 내용중에 필요한 것이 있어서 여기저기 찾아 헤맸다. 둘 다 내 del.icio.us에 고이 간직되어 있었다는.... Orz.

happy hackin'




Windows에서 SBCL을 실행했을 때 다음과 같은 에러가 나면서 실행이 안되는 경우가 있다.
VirtualAlloc: 0x1e7.
ensure_space: failed to validate 536870912 bytes at 0x09000000
(hint: Try "ulimit -a"; maybe you should increase memory limits.)

해결책은 간단하다. 다음과 같은 옵션을 줘서 실행한다.
sbcl --dynamic-space-size 128

그래도 안되면 128을 좀더 줄여보면 실행될 것이다.

테스트 환경:
Windows XP Professional
SBCL 1.0.13

참고: http://objectmix.com/lisp/254740-cannot-activate-sbcl.html

happy hackin'
1 ~ 2 글자로 만든 이유는?
자주 쓸 것이라 예상했기 때문이다.

f()
forget - shell의 모든 binding을 없앤다.
f(Foo) forget Foo - Foo에대한 binding을 없앤다.
c(module) compile - 모듈 compile. c(module, {d, debug}) 과 같은 형식으로 컴파일 타임에 설정을 추가하면, -ifdef(debug). 등에서 활용가능하다.
l(module) load - load (compiled) module.
q() quit - shell 끝내기.
rr("record-file.hrl") read record (from file) - read record information.
rf(record) forget record - record 정보 제거, tuple로 보이게 만든다.

보일때 마다 정리를 하고 있었는데...
help()가 있었다... Orz.


happy hackin'
synopsis - the bug
mysql 데이터를 oracle로 옮기는 아주 단순한 모듈을 clsql을 사용해서 만들었다.
처음에는 oracle 서버 설정이 잘못되어 oci를 통해 oracle에 접근하는 것이 불가능했다.
ORA-12705: Cannot access NLS data files or invalid environment specified.
서버 설정은 다음과 같이 하면 별 무리가 없을 듯했다.
# in .bash_profile of user oracle
export NLS_LANG=(KOREAN_KOREA|AMERICAN_AMERICA).UTF8
export ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data      ## 9i  이하 버전
export ORA_NLS10=$ORACLE_HOME/nls/data                    ## 10g 이상 버전

클라이언트 쪽은 utf-8 환경의 우분투이므로,
export NLS_LANG=.UTF8

서버/클라이언트 설정을 맞추고 나자 다음과 같은 서버 에러를 내면서 레코드 삽입이 멈추는 심각한 상태가 되어 버렸다. 운좋게 들어간 몇몇 레코드들은 한글이 모조리 깨져있었다.
ORA-01756 quoted string not properly terminated
처음에는 인코딩 문제인것같아 환경변수 설정을 바꿔가면서 해봤다. 테스트용 모듈이 가끔 정상적인 한글을 insert할 때가 있었는데, 그 경우는 lisp 소스에 한글이 static하게 박혀있고 그 모듈을 (load "test.lisp")의 형태로 읽어들일 경우에만 한글이 제대로 오라클 DB로 전송되었다(지금도 이 부분이 정확히 어떻게 해서 성공적으로 그렇게 되었는지는 잘 이해가 안가는 상태다. lisp reader의 농간으로 추측되긴한다). 즉, 같은 소스를 emacs에서 읽어들여 function을 eval하면 깨진 한글이 전송되는... 신기하긴 하지만 돌아버릴 것같은 상황이 연출된 것이다. Orz...

이것이 눈물겨운 hacking의 시작이었다.

problem solving - the patch
clsql-oracle 및 uffi의 소스를 뒤졌다. oracle-sql.lisp에서 일단 실마리를 찾았다. sql-stmt-exec에서 oci interfact를 통해 sql statement를 실행하는데, uffi를 사용해 foreign string으로 변환 후에 oci interface를 통해 서버측으로 전달되게 되어있었다.
인코딩의 문제라는 강력한 심증이 있었으므로, lisp string 에서 변환된 foreign string을 lisp string으로 다시 변환(convert-from-foreign-string)해서 로그를 찍어보았다. 로그는 출력되지 않고 encoding error가 났다.
debugger invoked on a SB-INT:C-STRING-DECODING-ERROR in thread
#<THREAD "initial thread" {10025DEED1}>:
c-string decoding error (:external-format :UTF-8):
the octet sequence 3 cannot be decoded.

문제의 근원 (root cause)이 파악되는 순간이었다 (반이나 왔다고 긍정적으로 생각할 수도, 반이나 남았다고 비관적으로 생각할 수도 있는... go냐 stop이냐를 정말 갈등하게 하는 순간이다). '그냥 bug report하고 기다릴까? 테스트 케이스까지만 만들어 주고 report and wait??' 이런 유혹에 잠시 빠질려는 순간 어디선지 모르게 승부욕이 용솟음쳤다. 내나라의 아름다운 글을 바르게 표시하는 것은 내손으로 하자. 막판에는 사명감까지 생겼다. --;;

이제, 지금 이순간 필요한 것은 확실한 test case의 작성!!
(defparameter *tests* '("english" "한글"))
(dolist (test *tests*)
  (let* ((f    (uffi:convert-to-foreign-string test))
         (back (uffi:convert-from-foreign-string f)))
    (format t "~%test=~a, back=~a" test back)
    (assert (string= test back))))

역시 한글에서만 error가 났다. 용의자는 convert-to-foreign-string 아니면 convert-from-foreign-string 으로 압축되었다.

테스트 코드를 좀 끼워넣어보고, 함수를 재정의(lisp이 정말 강력한 부분)해보고 해서 찾은 진범은 바로,
uffi:convert-to-foreign-string

unicode에 대한 고려가 안되어있었다.

sbcl의 unicode관련 코드를 좀 살펴보고, uffi쪽 코드도 좀 살펴보고 해서 uffi:convert-to-foreign-string를 수정해서 상기 테스트 코드가 통과되게 만들었다.
이젠 DB쪽 삽입을 테스트할 차례. 자신감으로 충만해서 잠시 잊었던 나의 원래 목적인 (제일 처음 작성했던!!) mysql2oracle migration 모듈을 실행했다.
그런데 또 위에서 나왔던 ORA-01756에러가 났다. Orz...

이상하게 이번에는 전혀 짜증나지도 않았고, 해결할 수 없을지도 모른다는 생각도 들지 않았다. 이미 uffi와 clsql-oracle의 내부를 어느정도 파악하고 있었기 때문에 할 수 있다는 생각이 들었다.
잠시 살펴본 결과 sql-stmt-exec에서 oci interface로 전달하는 파라미터 중에 sql statememt의 길이를 전달하는 부분이 있었는데 여기에 원래 lisp string의 길이를 전달하고 있었다 (ascii string은 utf-8로 인코딩해도 길이가 같기 때문에 문제가 안되지만 한글등의 non-ascii는 당연히 짤려버려서 에러가 난다).
그래서 간단히 uffi:foreign-string-length를 불러서 해결하려했으나, 이 함수는 아무도 안쓰는지 완전히 잘못되어 있었다. macro의 body를 defun으로 정의해놓았고, 그나마 그것도 문법오류를 포함하고 있었고, unicode 고려도 안되어있었다. 악의 축같은 함수(매크로) 였지만, 이미 익숙해져 있는 모듈이었으므로 간단히 고칠 수 있었다.

이제 남은 것은 기존 테스트 케이스 돌려보기 및 upstream 반영을 위해 maintainer에게 patch 전달하기.



happy hackin'
1 ··· 23 24 25 26 27 28 29 ··· 31 
분류 전체보기 (306)
잡담 (20)
함수형 언어 (65)
emacs (16)
java (18)
tips & tricks (154)
사랑 (1)
가사 (0)
독서 (4)
mobile (6)
비함수형 언어 (2)

공지사항

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

03-29 16:00