ageldama님의 노트

CFFI로 Hello MsgBox

Sat, 27 Mar 2010 23:24:48 +0900

(defpackage :cffi-user
(:use :common-lisp :cffi))

(in-package :cffi-user)

(require :asdf)
(asdf:oos 'asdf:load-op :cffi)

(define-foreign-library lib-user32
(t (:default "user32")))

(use-foreign-library lib-user32)

(defctype hwnd :unsigned-int)

(defcfun "MessageBoxA"
:int
(wnd     hwnd)
(text    :string)
(caption :string)
(type    :unsigned-int))

(MessageBoxA 0
"OH HAI!"
"THIS IS MESSAGE FROM OUTER SPACE"
0)
;;; EOF

참고:

ps. 하악하악... ccl 하악하악...

Lua

Wed, 03 Mar 2010 01:26:30 +0900

Lua

2010/02/27 00:47:40

쉽게 접했고, 처음엔 좀 만만하게 생각했고, 그리고 실제로 사용해도 만만했고;; 좋았다.

간편하고 실용적이고 내가 원하는걸 하는데 큰 어려움이 없었다. 특히 C/C++ 애플리케이션에 내장하였을때 간편하고도 강력했다.

luabind와 같은 C++ Binding Wrapper들은 정말 아무런 생각없이 써도 될 정도로 깔끔하고 좋았다.

내부적으로 어떻게 돌아가는지 소스코드를 읽어보고 싶다는 생각이 들었다. (2010년 2월말쯤)

언젠가 기회가 된다면 ANSI C Lua 소스코드를 분석해보고 싶다.

그리고 "Programming in Lua" 책 산것도 한번 꼭 읽어봐야지. (http://insightbook.springnote.com/pages/253177)

LuaJIT

http://luajit.org
거 의 그냥 lua 엔진 교체해서 바로 적용하면 되는듯;;; 심심하면 이따 해봐야징
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&d=data&calc=calculate&gpp=on&java=on&luajit=on&v8=on&lua=on&tracemonkey=on&box=1
- 벤 치마킹 결과 : g++이 median이 1.07 (평균적으로 가장 빠름), 그냥 Lua이 25.88인데, LuaJIT은 2.33 ㅎㄷㄷㄷ;;
  - 어째서 이게 놀라운거냐하면, CommonLisp SBCL, Haskell GHC, Ocaml 같은 나름 Native 컴파일러가 붙어있고 또 좋다는 언어들보다 좀 빠른거니까;;;

luac, 기타 로딩방식

luac로 .lua 파일을 컴파일하면?
- http://www.lua.org/manual/4.0/luac.html 바이트코드 형태로 변환이 가능함
- http://sonhy1.tistory.com/76 요런 트릭으로 여러 스크립트를 하나로 뭉쳐서 보관이 가능함
- bin2c등을 이용해서 아예 c 문자열등으로 만들어서 컴파일할때 붙여버릴수있음. (그걸 lua_dobuffer정도 해주면 되겠죵?)
  - http://www.redwiki.net/wiki/wiki.php/bin2c

lua -> .exe?

슬프게도 아직 그런건 없심.
python
- py2exe : http://www.py2exe.org/ http://logix4u.net/Python/Tutorials/How_to_create_Windows_executable_exe_from_Python_script.html
- freeze : http://wiki.python.org/moin/Freeze
ruby
- RubyScript2Exe : http://www.erikveen.dds.nl/rubyscript2exe/
perl
위 에서 보듯이 다른 언어들에는 이미 있지만, 그것들도 사실 .exe 파일의 내부에 바이트 컴파일한 소스를 내장하고 VM도 한덩어리로 뭉치는 VB와 같은 .exe을 만드는 방식임...
실제로 C/C++, Haskell처럼 진짜 .exe을 만들지는 못함. (앞으로 진짜 컴파일러가 나오면 또 모를까)

Google AI Challenge와 Lua

Language	T	E	ratio
C++	45	247	1.8167
C#	13	63	2.0577
Python	6	127	0.4711
C. Lisp	2	11	1.8131
Lua	1	4	2.4930
Go	1	8	1.2465
Haskell	1	32	0.3116

There were 708 entries, so I'll call the top 71 scorers "the top 10%".

To see which languages were over/under represented in the top 10%,

I'll confabulate the following "representation ratio": (T / E) * (708 / 71),

where E = number of entries in the language, T = number of entries in the language that made the 10%.

E은 총 참가자, T은 참가자중 상위 10%에 속한 갯수. 헐퀴... 엔트리 대비 상위 10% 비율이 좀 쩌는군함.

2010/03/02 화요일

luajit을 갖고 놀아봤음. Agent8에도 붙여보고 나름 간단한 (팩토리얼, ackermann) 예제를 만들어서 시간도 재봤는데 정말 멋지더라.
- 자바정도의 성능이 나오고, lua랑 비교했을때는 차원이 다른 성능
google ai challenge에서 비율이 높게 나온건 엔트리가 워낙에 적어서 비중이 크기 때문이라고 생각도 되지만, 어쨌든 쉽게 강력한 개념에 접근이 가능하다는 강점 덕분에 그런게 아닐까? 오히려 쉽게 배우고 잘 쓸수있는 언어들이 강점으로 드러났다고 생각한다. commonlisp, haskell, c++등의 매우 해커적인 학습곡선의 언어들은 상대적으로 좀 거시기하니까
Programming in Lua 책을 읽기 시작했는데 뭐랄까... 음 단순히 루아만을 학습하는데 좋은게 아니라 현대적인 프로그래밍 언어에서 중요한 개념들은 대부분 표현이 가능한것 같다
- 클로져
- coroutine/continuation
- first-class function
- ...거기에 이런 개념들을 적절하고 좋은 번역으로 읽을수있어서 좋았다.
- 좀 아쉬운건 "루아"라는거 정도?
- 책으로서 정말 완전한 tutorial이자, 완전한 reference였다.
  - 루아 언어 자체의 모든 기능들과 테크닉들을 정말 완전하고도 간결하게 설명해줬고
  - C언어를 통한 확장과 C언어 애플리케이션에 내장하는 주제에 대해서도 완전히 설명했다
  - 또한 어떻게 보면 보통 생략하고 쉽게 다룰수도 있는 쓰레기 수집이나 자원관리에 대해서도 심도있고 완전하게 다뤘다고 생각한다.
- 최근에 읽어본 컴퓨터 관련 서적중에 가장 높은 점수를 주고 싶다.

정리: lua c-extension .dll 만들기

Tue, 02 Mar 2010 21:10:57 +0900

Lua C-extension .DLL 작성하기

2010/03/02 20:39:14 윤종혁

01. 빌드 / 기초적인 인터페이싱

일반적인 .dll 빌드와 같이 한다.
- gcc -fPIC 옵션으로 컴파일한다.
- gcc -shared 옵션으로 링크한다.

mingw기준으로 dll에 노출할 함수의 시그니쳐는 다음과 같이 한다.

extern "C" __declspec(dllexport) int add(int a, int b)

C++ 컴파일할때는 "extern "C""
ANSI C 컴파일할때는 그냥 "extern"
C++ 컴파일시에도 컴파일러가 name-mangling하지않도록 주의한다.

02. Lua 확장모듈로서

예를 들어, "hello"라는 모듈이라면 다음과 같은 방법으로 require한다.

require 'hello'

이러한 모듈은 실제 파일이름이 "hello.dll"일것이며, "luaopen_hello(L)"라는 다음과 같은 시그니쳐의 함수를 dll-export한다.

int luaopen_msgbox(lua_State *L)

L을 받아서 이 lua_State*에 luabind나 lua C API을 이용하여 함수등을 바인딩해주면 된다.
반드시 되돌림값으로 "1"을 되돌린다.

03. 기타

다음과 같이 나누는 경우도 있으므로 주의
- require 'socket'인 경우
- 내부적으로 socket.lua 에서 require 'socket.core'하는 경우가 있음. <-- 모듈의 대부분은 lua로 작성하고 나머지 부분만 C-extension으로 구현하는 경우 이렇게.
- 이럴때은 core.dll로 배포하며 실제 위치는 socket/core.dll로 위치시킨다.
- luaopen함수의 이름은 "luaopen_socket_core"와 같이 한다

스터디: -fPIC, 공유라이브러리 만들기?

Mon, 01 Mar 2010 22:12:32 +0900

gcc의 -fPIC 옵션이 뭐지?

2010/03/01 21:52:49

http://openlook.org/blog/2004/03/22/cb-687/

-fPIC와 -fpic

2004년 3월 22일 17시 23분
댓글 없음

으흐흐. 그동안 같은 플래그인 줄 알고 있었던 -fPIC와 -fpic가 서로 다른 것이었군요. 최근 한 cvs-all 메일에서 David O'Brien씨가 역시 옛날 툴체인 메인테이너답게 이런 구석진 것을 알려주는 군요. 흐흐 문제의 메일

대략 요약하면, -fpic는 global offset table (GOT)을 통해 심볼들을 액세스하는데 기계에 따라서 정해진 한계가 있어서 이게 경우에 따라서는 실패할 수도 있다는군요. 그렇지만, 성공하면 -fPIC에 비해 더 적은 속도 저하를 얻을 수 있고, -fPIC는 크기에 상관이 없는 대신 엄청난 속도 저하가~~~ 흐흐 그런데 i386에서는 -fPIC나 -fpic나 똑같아서;;

http://lists.freebsd.org/pipermail/cvs-ports/2004-March/030214.html

  -fpic

    Generate position-independent code (PIC) suitable for use in a shared

    library, if supported for the target machine. Such code accesses all

    constant addresses through a global offset table (GOT). The dynamic

    loader resolves the GOT entries when the program starts (the dynamic

    loader is not part of GCC; it is part of the operating system). If

    the GOT size for the linked executable exceeds a machine-specific

    maximum size, you get an error message from the linker indicating

    that -fpic does not work; in that case, recompile with -fPIC instead.

    (These maximums are 16k on the m88k, 8k on the SPARC, and 32k on the

    m68k and RS/6000. The 386 has no such limit.)



  -fPIC

    If supported for the target machine, emit position-independent code,

    suitable for dynamic linking and avoiding any limit on the size of

    the global offset table. This option makes a difference on the m68k,

    m88k, and the SPARC.

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Use -fPIC or -fpic to generate code. Whether to use -fPIC or -fpic to generate code is target-dependent. The -fPIC choice always works, but may produce larger code than -fpic (mnenomic to remember this is that PIC is in a larger case, so it may produce larger amounts of code). Using -fpic option usually generates smaller and faster code, but will have platform-dependent limitations, such as the number of globally visible symbols or the size of the code. The linker will tell you whether it fits when you create the shared library. When in doubt, I choose -fPIC, because it always works.

shared-library을 만들때는 항상 -fPIC을 쓰면 되겠군. (-fpic은 될지 안될지 모르고 거의 안된다고 보면 되고)

공유라이브러리

추가적으로 좋은것도 찾았군...

In some cases, the call to gcc to create the object file will also need to include the option ``-Wl,-export-dynamic''. Normally, the dynamic symbol table contains only symbols which are used by a dynamic object. This option (when creating an ELF file) adds all symbols to the dynamic symbol table (see ld(1) for more information). You need to use this option when there are 'reverse dependencies', i.e., a DL library has unresolved symbols that by convention must be defined in the programs that intend to load these libraries. For ``reverse dependencies'' to work, the master program must make its symbols dynamically available. Note that you could say ``-rdynamic'' instead of ``-Wl,export-dynamic'' if you only work with Linux systems, but according to the ELF documentationthe ``-rdynamic'' flag doesn't always work for gcc on non-Linux systems.

음... 정리해보면

"-Wl,-export-dynamic"해서 .so에는 없고 .so을 불러올 대상에 있는 심볼을 .so에서 참조해야한다면 이를 써서 이를 해소할수있다는뜻인듯.
"-rdynamic"을 써도 되지만 리눅스가 아닌 환경에서는 보장할수없다는군.

정적라이브러리

정적라이브러리는 object file(.o로 끝나는) 의 단순한 모음이다. 정적라이브러린느 보통 .a 의 확장자를 가진다. 간단히 사용할수 있다. 컴파일시 적재되므로 유연성이 떨어진다. 최근에는 정적라이브러리는 지양되고 있는 추세이다. 컴파일시 적재되므로 아무래도 바이너리크기가 약간 커지는 문제가 있을것이다.

공유라이브러리

공유라이브러리는 프로그램이 시작될때 적재된다. 만약 하나의 프로그램이 실행되어서 공유라이브러리를 사용했다면, 그뒤에 공유라이브러리를 사용하는 모든 프로그램은 자동적으로 만들어져 있는 공유라이브러리를 사용하게 된다. 그럼으로써 우리는 좀더 유연한 프로그램을 만들수 잇게 된다.

정적라이브러리와 달리 라이브러리가 컴파일시 적재되지 않으므로 프로그램의 사이즈 자체는 작아지지만 이론상으로 봤을때, 라이브러리를 적재하는 시간이 필요할것이므로 정적라이브러리를 사용한 프로그램보다는 1-5% 정도 느려질수 있다. 하지만 보통은 이러한 느림을 느낄수는 없을것이다.

동적라이브러리

공유라이브러리가 프로그램이 시작될때 적재되는 반면 이것은 프로그램시작중 특정한때에 적재되는 라이브러리이다. 플러그인 모듈등을 구현할때 적합하다. 설정파일등에 읽어들인 라이브러리를 등록시키고 원하는 라이브러리를 실행시키게 하는등의 매우 유연하게 작동하는 프로그램을 만들고자 할때 유용하다.

정적라이브러리 만들기

[root@localhost test]# gcc -c mysum.c

[root@localhost test]# ar rc libmysum.a mysum.o

간단히 .o 파일들을 ar로 묶기;;;

공유라이브러리 만들기

[root@localhost test]# gcc -fPIC -c mysum.c

[root@localhost test]# gcc -shared -W1,-soname,libmysutff.so.1 -o libmysum.so.1.0.1 mysum.o

[root@localhost test]# cp libmysum.so.1.0.1 /usr/local/lib

[root@localhost test]# ln -s /usr/local/lib/libmysum.so.1.0.1 /usr/local/lib/libmysum.so

음... 옵션으로 -fPIC을 줘서 컴파일하고 "-shared -W1,-soname,lib..."와 같은걸줘서 링크함을 알수있다. (그리고 LD_LIBRARY_PATH에 추가하고)

대상 프로그램에 링크할때는 .so 파일에 대해서 링크하면 된다. ("-l" 옵션)

http://www.linuxlab.co.kr/docs/98-11-2.htm

-shared

이것은 공유 라이브러리를 만들어라 하는 옵션이다. 그래서 라이브러리에 관련된 출력파일에 실행 가능한 형태가 되는 것이다.

Wl, -soname, libName.so.xxx

이 -W1옵션은 gcc(1)가 콤마로 부분된 다음 옵션들을 링커에게 알려주기 위한 것이다. 이것은 gcc(1)가 ld(1)에게 옵션을 넘겨주기 위한 방법이다. 이 예에서는 링커에게 다음과 같은 옵션을 넘겨준 것이다.

-soname libName.so.xxx

이 옵션은 라이브러리에 대한 soname을 고정시키는 것이다. 그리고 필요한 다른 프로그램에서는 이 soname을 사용해야만 한다.

동적라이브러리?

공유라이브러리와 같으며, 대신 링크를 시키지 않았다가 dlopen계열 함수를 이용해서 동적으로 연결하는 방식을 의미한다.

http://wiki.kldp.org/HOWTO/html/Program-Library-HOWTO/dl-libraries.html <-- 이문서를 참고하면 링크하지 않은 .so 라이브러리를 실행시간에 .dll처럼 접근하는 방법이 나타나있심. (Win32라면 LoadLibrary, GetProcAddress)

.la 파일?

http://stackoverflow.com/questions/1238035/libtool-what-la-file-is-for

It is textual file that includes description of library.

It allows libtool create platform independent names.

For example, libfoo goes to:

Under linux:

/lib/libfoo.so       # symlink to shared object/lib/libfoo.so.1# symlink to shared object/lib/libfoo.so.1.0.1# shared object/lib/libfoo.a        # static library/lib/libfoo.la       # libtool library

Under cygwin:

/lib/libfoo.dll.a    # import library/lib/libfoo.a        # static library/lib/libfoo.la       # libtool library/bin/cygfoo_1.dll    # dll

Under windows mingw:

/lib/libfoo.dll.a    # import library/lib/libfoo.a        # static library/lib/libfoo.la       # libtool library/bin/foo_1.dll       # dll

So.. libfoo.la is the only file that preserved between platforms by libtool allowing to understand, what happens with:

library dependencies
actual file names
library version and revision

Without depending on specific platform implementation of libraries

스터디: calling convention?

Mon, 01 Mar 2010 21:46:27 +0900

Calling Convetion?

2010/03/01 21:33:11

뭔가 복잡해 보이면서도 그간 잘 몰랐던 그것. (사실 좀 알기는 했지만;;;)

대략 알고 있던 내용은 다음과 같음

함수 호출시 인자들을 스택에 넣는 방법에 관련한거라는거 (L->R, R->L 뭐 이런... 윈쪽부터 스택에 넣을거냐 오른쪽부터 넣을거냐 그런차이

그래서 더 알고싶은건

어떤것들이 있는지
어떤 차이가 있는지
어떻게 적용하면 되는지
...그리고 곁다리로 함수 선언시 그밖에 어떤것들이 더 다른지

http://kkamagui.springnote.com/pages/339546

2.1 stdcall, cdecl, fastcall

실제로 어셈블리어를 아는 것도 중요하지만 이 함수를 C 언어에서 어떻게 호출하여 사용할 것인가 하는 문제도 중요하다. 흔히들 호출 규약(Calling Convention)이라고 표현하는 이것은 함수를 호출하는 규약인데, 몇가지 방식이 존재한다.

stdcall(pascal) 방식 : 스택에 파라메터를 역순으로 삽입하고 함수를 호출. 스택의 정리작업을 호출된 함수에서 수행. 파스칼 언어 및 베이직 언어에서 사용하는 방식
cdecl 방식 : 스택에 파라메터를 넣는 방식은 stdcall과 같음. 단 스택의 정리작업을 호출한 함수에서 수행. C언어에서 사용하는 방식
fastcall 방식 : 몇개의 파라메터는 레지스터를 통해 넘기고 나머지 파라메터는 스택을 사용하는 방식

위의 세가지 중에서 보편적인 방식 두가지는 stdcall 및 cdecl 방식이다. 이 두가지 방식의 가장 큰 차이점은 스택의 정리를 누가 하는 가이다.

stdcall 방식 같은 경우 Callee(호출 된 함수)에서 스택 정리를 하므로 Caller(호출하는 함수)와 Callee 모두 파라메터의 개수를 알고 있어야 정상적인 처리가 가능하다.

반면 cdecl 방식 같은 경우 Caller에서 스택 정리를 하므로 Callee는 파라메터의 개수를 정확하게 몰라도 된다. 바로 이 점이 C 언어의 가변인자(Variable Argument)를 가능하게 하는 것이다(printf와 같은 함수를 생각해보자).

가변인자에 대해서는 나중에 알아보고 우리가 사용할 cdecl에 대해서 자세히 알아보자.

음 역순으로 삽입한다는게 인자가 a, b, c라면 스택의 맨 아래부터 c, b, a의 순으로 쌓는다는거겠지?

http://beforu.egloos.com/2117375

http://beforu.egloos.com/2117409

함수 호출 과정과 스택 프레임Stack Frame
함수 호출 규약을 이해하기 위해서는 먼저 스택 프레임에 대한 이해가 필요하다. 스택 프레임은 호출된 함수가 실행되는 동안에 필요한 로컬 변수 등의 정보나 호출한 함수의 실행에 필요한 정보Context가 손실되지 않도록 스택에 저장할 때 취하는 구조Data Structure를 의미한다. 이렇게 저장해야 하는 정보에는 함수의 실행이 종료된 뒤에 리턴할 주소나, 로컬 변수, 자신을 호출한 함수의 스택 프레임 위치, 레지스터 같은 기계 상태, 예외 처리 리스트 등이 포함된다. 스택 프레임은 기본적으로 함수가 호출될 때마다 새로 설정되며, 프레임 포인터Frame Pointer 혹은 베이스 포인터Base Pointer를 통해서 참조할 수 있다. 프레임 포인터는 현재 실행되는 함수의 스택 프레임이 스택 상의 어느 주소 위치하고 있는지 가리키는 값으로, 인텔 아키텍처에서는 ebp 레지스터에 저장된다

cdecl
cdecl 호출 규약은 C 컴파일러 혹은 C++ 컴파일러에서 전역 함수Global Function나 전역 스태틱 함수Globacl Static Function, 스태틱 멤버 함수Static Member Function 호출에 기본적으로 사용하는 규약이다. cdecl 호출 규약에서 컴파일러는 멤버 함수의 오른쪽 인자부터 왼쪽 인자 순으로 스택에 집어 넣고, 함수 호출이 종료된 뒤 함수 호출자는 스택에 집어 넣은 인자를 제거하며, 리턴 값이 있는 경우 레지스터 eax를 통해서 리턴 값을 돌려 받는다. cdecl 호출 규약에서는 호출자가 넣은 인자를 제거하게 되어 있으므로, 함수가 가변 개수의 인자를 가져도 안전하게 스택을 정리할 수 있다.

stdcall (pascall)
stdcall 호출 규약은 윈도우 플랫폼에서 시스템 API를 호출할 때 사용하는 규약이다. stdcall 호출 규약에서 컴파일러는 멤버 함수의 오른쪽 인자부터 왼쪽 인자 순으로 스택에 집어 넣고, 함수 호출이 종료되면 호출된 함수가 인자를 스택에서 제거하며, 리턴 값이 있는 경우 레지스터 eax를 통해서 리턴 값을 돌려 받는다. 호출된 함수가 스택에서 제거해야 할 인자의 개수를 정확히 알아야 하기 때문에 cdecl 규약과 달리 stdcall 규약의 함수에는 가변 개수의 인자를 전달할 수 없다.

thiscall
thiscall 호출 규약은 C++에서 클래스 멤버 함수를 호출하기 위해서 사용하는 호출 규약이다. C++ 멤버 함수를 실행하기 위해서는 this 포인터를 알고 있어야 하기 때문에, thiscall 규약에서는 this 포인터를 ecx 레지스터에 넣어서 전달하게 된다. this 포인터를 ecx에 넣어서 전달한다는 점 외에는 stdcall 호출 규약과 동일하다.

fastcall
fastcall 호출 규약은 인자를 전달하면서 스택이 아니라 레지스터를 사용하는 규약이다. 기본적인 동작 방식은 stdcall과 유사하지만, 가장 앞 쪽 두 개의 인자를 레지스터 ecx와 edx를 사용하여 전달한다는 점이 다르다. 스택을 사용하지 않고 레지스터에 인자를 전달하기 때문에 호출 비용이 조금 더 낮을 것으로 기대할 수 있다.

naked
naked 호출 규약은 컴파일러가 작성하는 프롤로그나 에필로그 코드를 사용하지 않고 자신이 프롤로그와 에필로그를 작성하고자 할 때 사용한다. 인자를 전달받는 방식은 cdecl과 마찬가지이기 때문에 인자를 정리할 필요는 없지만, 함수에서 돌아갈 때 스택을 원상복구 하지 않으면 프로그램이 정상 동작하지 않을 가능성이 높기 때문에 naked 호출 규약을 사용한 함수 안에서 스택을 다룰 때는 매우 주의해야 한다. 저수준Low-Level에서 특별한 작업을 해야 할 필요가 있는 경우가 아니라면 사용할 필요가 없는 호출 규약이다.

프레임 포인터 생략Frame Pointer Omission ("-fomit-frame-pointer")
마이크로소프트 비주얼 C++, Microsoft Visual C++ 컴파일러에는 속도 향상을 위해서 함수 내부에서 프레임 포인터를 사용하지 않는 옵션이 있다. 이 옵션이 적용되면 프롤로그와 에필로그가 약간씩 줄어들게 되고, ebp를 프레임 포인터로 사용하지 않고 범용 레지스터로 활용할 수 있게 되기 때문에 중간 결과를 저장하기 위한 공간이 늘어나서 코드 길이가 줄어들 수 있는 여지가 생긴다. 반면 프레임 포인터가 없기 때문에 실행 중 디버거를 연결해서 스택 프레임 상태를 알 수 없으므로 인자나 로컬 변수 상태, 이전 스택 프레임에 대한 정보를 찾을 수 없으므로 콜 스택Call Stack이나 함수 호출 인자를 볼 수 없기 때문에 디버깅이 어려워지게 된다.

http://serious-code.net/moin.cgi/CallingConvention

1 Calling Convention?

함수 호출 방식(Calling Convention)이란 호출자(caller, 피호출자 함수를 호출하는 함수)와 피호출자(callee, 호출자로부터 호출되는 함수) 간에 미리 정해둔, 파라미터의 전달 순서와 사용이 끝난 후의 스택 정리에 대한 규약이라고 할 수 있다. WIN32 환경에서는 기본적으로 세 가지의 호출 방식이 존재한다.

Standard Call -- 파라미터들은 코드 상의 오른쪽 파라미터부터 먼저 푸쉬되고(첫번째 파라미터가 스택의 맨 위로 오게 된다는 말이다.), 피호출자(callee)가 스택을 정리한다.
CDECL or C Calling Convention -- 파라미터들은 코드 상의 오른쪽 파라미터부터 먼저 푸쉬되고(첫번째 파라미터가 스택의 맨 위로 오게 된다는 말이다.), 호출자(caller)가 스택을 정리한다.
Fast Call -- C++의 내부 구조에 익숙하다면, 멤버 함수를 호출하기 위해서는 this 포인터가 반드시 필요하다는 것을 알 것이다. 일반적으로 이 this 포인터가 스택에 최초로 푸쉬되는 파라미터다. 하지만 이 방식에서는 this 포인터를 스택에다가 푸쉬하는 게 아니라, 레지스터(ECX)에 저장한다. 파라미터들은 코드 상의 오른쪽 파라미터부터 먼저 푸쉬되고(첫번째 파라미터가 스택의 맨 위로 오게 된다는 말이다.), 피호출자(callee)가 스택을 정리한다.
Pascal Calling Convention -- 이 방식은 더 이상 사용할 수 없다. 이는 모두 Standard Call로 대체되었다. 어쨌든 원래의 Pascal Calling Convention은 파라미터를 코드 상의 왼쪽 것부터 먼저 푸쉬하고, 피호출자(callee)가 스택을 정리한다.

결 국 파라미터의 전달 순서와 스택 정리에 대한 규약이 다르므로, 다른 규약을 이용해서 만들어진 DLL 안에 있는 함수를 헤더 같은 것도 없이 동적으로 바인딩해서 사용하는 경우, 그것을 컴파일러에게 명시적으로 가르쳐줘야하는 것이다. (호출하는 측과 호출받는 쪽이 다른 Calling Convention을 사용할 수 있으므로...)

2 스택 정리를 누가 하든 무슨 상관인가?

2.1 호출자가 정리 - C Calling Convention

Invoke MyFunction, 1, 2, 3, 4

코드가 아래와 같이 변환된다.

PUSH    4   

PUSH    3   

PUSH    2   

PUSH    1   

CALL    MyFunction 

ADD     sp, 16      ;; -->> 스택 정리 코드..

장점 : 호출하는 측에서 스택에다 몇 개의 파라미터를 집어넣었는지 알고, 스택 정리를 담당하므로, 가변 인자(variable arguments)를 사용할 수 있다.
단점 : 프로그램의 크기가 커진다. 호출자가 스택을 정리한다는 말은, 위에서도 보듯이 함수 호출할 때마다 스택 정리하는 코드가 들어가야 한다는 말이고, 이는 프로그램의 크기 증가와 속도 감소를 가져온다.

printf 함수 같은 것이 가변 인자를 사용하는 대표적인 예이다. 하지만 피호출자는 인자가 몇개나 전달되었는지 정확히 알 수 없다. 그냥 포맷 문자열 같은 것을 이용해서 추측할 뿐이다. 예를 들어 printf 함수를 호출할 때, "%i %i %i" 문자열을 주면, printf 함수는 호출하는 측에서 추가적으로 스택에다 3개의 인자를 집어넣지 않은 경우(프로그래머의 실수!)에도, 스택에 있는 3개의 값을 이용해 문자열을 생성할 것이다. 이것이 크래시를 일으킬지, 아닐지는 정확히 알 수 없다. 3개 이상의 인수를 전달하는 경우는 어차피 호출하는 측에서 스택을 정리하므로 문제가 되지 않는다.

2.2 피호출자가 정리 - Standard Calling Convention

Invoke MyFunction, 1, 2, 3, 4

코드가 아래와 같이 변환된다.

PUSH    4   

PUSH    3   

PUSH    2   

PUSH    1   

CALL    MyFunction

장점 : 피호출자가 스택 정리를 담당한다면, 프로그램의 크기는 작아진다. 또한 스택 정리 명령어를 매번 호출하지 않아도 되므로, 속도 또한 빨라진다.
단점 : 피호출자가 자신이 정리할 스택의 크기(파라미터들의 총 크기)를 정확히 알고 있어야 하므로, 가변 인자를 사용할 수 없다.

호출자가 하든, 피호출자가 하든 어딘가에서는 스택을 정리해야하지 않는가? 즉 위에서 없어진 ADD sp, 16는 어차피 피호출자, 즉 MyFunction 내부에서 호출해야 하지 않느냐는 말이다. 어차피 어디에선가 호출해야 한다면 프로그램의 크기가 왜 작아지며, 빨라지는가? 이는 인텔 계열에서 지원하는 특수한 명령어 때문이다. 즉 리턴하면서 스택 정리를 동시에 하는 명령어가 있기 때문에, 프로그램의 크기가 작아지고, 빨라진다는 말이다.

3 정리

from http://www.smkang.com

Calling Conventions	Arguments Passing	Stack Maintenance	Name Decorations	Notes
__cdecl	Right -> Left	호출자가 Stack에서 인자를 제거한다.	함수 이름 앞에 _를 붙인다. Ex) _foo	C/C++함수의 기본 호출 규약
__stdcall	Right -> Left	호출된 함수가 Stack에서 인자를 제거한다.	_가앞에 붙고 뒤에 @와 인자의 크기가 10진수로 붙는다. Ex) _foo@12	대부분의 System 함수가 사용. VB에서 내부함수가 사용.
__fastcall	첫번째 2개의 DWORD 파라미터는 ECX, EDX 레지스터 사용. 나머지는 Right->Left	호출자가 Stack에서 인자를 제거한다.	@이 앞에 붙고 @과 인자의 크기가 10진수로 뒤에 붙는다. Ex) @foo@12	Intel CPU 만 사용. Borland의 Delphi 컴파일러가 사용.
this	Right -> Left this 매개변수는 ECX 레지스터사용.	호출자가 Stack에서 인자를 제거한다.	None	C++클래스의 멤버 함수가 사용. COM에서 사용.
naked	Right -> Left	호출자가 Stack에서 인자를 제거한다.	None	VxD에서 사용. Custom Prolog 와 Epilog를 만들때 사용.

4 링크

Win32: WinInet 캐쉬

Mon, 01 Mar 2010 21:25:30 +0900

UrlDownload나 InternetOpen등으로 HTTP, FTP접근하면 IE의 프록시 설정을 그대로 반영한다는 편리함 이외에도 캐슁까지 되버린다능;;;

그래서 캐쉬를 날려주거나 캐쉬를 쓰지 않도록 처리할 필요가 있음.

http://msdn.microsoft.com/en-us/library/aa383983%28VS.85%29.aspx 요청을 날리기 전에 URL을 넘겨서 캐쉬를 삭제하고 요청을 날려주세요.
- http://msdn.microsoft.com/en-us/library/aa383928%28VS.85%29.aspx WinInet 캐슁에 관련한 문서
- 추가적으로 HttpOpenRequest, and InternetOpenUrl. 호출시 INTERNET_FLAG_NO_CACHE_WRITE 플래그를 줘서 캐슁을 안하게 조절이 가능해요.
- 서버측 캐쉬 제어: INTERNET_FLAG_PRAGMA_NO_CACHE
- 클라이언트측 캐쉬 제어 : INTERNET_FLAG_DONT_CACHE 또는INTERNET_FLAG_NO_CACHE_WRITE 미안;;; 깜빡했심;;;

2010/03/01 21:25:29

ccl, asdf 환경잡기

Mon, 01 Mar 2010 16:03:28 +0900

2010/03/01 15:55:19

~/.sbclrc, ~/.cclinit등의 초기화 스크립트에 다음을 추가

http://bitbucket.org/adaltan/configs/src/tip/lisp/win32-ccl/

대략 다음의 스크립트을 잡조

http://yoonkn.textcube.com/238

http://paste.lisp.org/display/83926

clozure common lisp 세팅

분류없음 | 2010/02/13 23:14 | 기냄

그냥 몇가지 적어둔다.

뜰때 읽는 파일이 ccl-init.lisp 인데 내가 환경변수 HOME 을 잡아둔 곳에서 읽지 않고 내문서 그쪽에서 읽는다. $HOME 읽는 프로그램들 중(*nix 쪽에서 나온 놈들)에 이렇게 돌아가는건 처음보네. 아.. 허긴 이놈은 mac 출신이구나. 어쨌건 ccl 띄운후 (user-homedir-pathname) 를 확인해보면 알수있다.

위 경로에 ccl-init.lisp 을 만들고 아래 코드로 c:/opt/lisp 아래의 asdf 패키지들을 찾도록 했다. 아래 코드는 http://paste.lisp.org/display/83926 에서 가져온것

(require 'asdf)

(defun setup-registry (directory-path)

  (format t "; adding components under ~A to asdf registry~%" directory-path)

  (mapc (lambda (asd-pathname)

          (pushnew (make-pathname :name nil

                                  :type nil

                                  :version nil 

                                  :defaults asd-pathname)

                   asdf:*central-registry*

                  :test #'equal))

        (directory (merge-pathnames #p"**/*.asd" directory-path))))

(setup-registry #p"c:/opt/lisp/")

asdf-install 이 지원되는 모양인데.. 난 수작업을 하는편.

http://read-eval-print.blogspot.com/2009/06/clozure-cl-windows.html 를 보면 인코딩 세팅하는 코드도 나와있다. 지금은 그냥 돌려본거라 이건 테스트 안해봤는데 한글윈도에서 코딩하려면 반드시 필요하겠지. 파일인코딩은 euc-kr, 그외는 utf-8 식으로..

(setf ccl:*default-external-format*

      (ccl:make-external-format :character-encoding :utf-8

                                :line-termination :dos)

      ccl:*default-file-character-encoding* :utf-8

      ccl:*default-socket-character-encoding* :utf-8)

패 키지 몰아서 받는건 아래 링크 통해서 하고있다. libcl 자체가 패키지관리기능을 가지고 있지만 난 그냥 저거 압축만 풀어서 쓰고있는 상태.

http://libcl.com/

(require 'asdf)

(defun setup-registry (directory-path)

  (format t "; adding components under ~A to asdf registry~%" directory-path)

  (mapc (lambda (asd-pathname)

          (pushnew (make-pathname :name nil

                                  :type nil

                                  :version nil 

                                  :defaults asd-pathname)

                   asdf:*central-registry*

                  :test #'equal))

        (directory (merge-pathnames #p"**/*.asd" directory-path))))

;;;

(setup-registry #p"/usr/local/src/ediware/")

utf-8로 맞추고 그러는건 다음처럼...

http://read-eval-print.blogspot.com/2009/06/clozure-cl-windows.html

;;;;-*- lisp -*-



;;; 最適化

#+nil

(declaim (optimize (debug 3) (safety 3) (speed 0) (space 0)

                   (compilation-speed 3)))

#+nil

(declaim (optimize (debug 0) (safety 0) (speed 3) (space 0)

                   (compilation-speed 0)))



;;; 文字コード

(setf ccl:*default-external-format*

      (ccl:make-external-format :character-encoding :utf-8

                                :line-termination :dos)

      ccl:*default-file-character-encoding* :utf-8

      ccl:*default-socket-character-encoding* :utf-8)


;;; ....

;; require で asdf:oos する

(defun asdf-module-provider-function (module)

  (when (asdf:find-system module nil)

    (asdf:oos 'asdf:load-op module)

    t))

(pushnew 'asdf-module-provider-function

         ccl::*module-provider-functions*)

(defmethod asdf:perform :around ((o asdf:load-op) (c asdf:cl-source-file))

  (handler-case (call-next-method o c)

    (#+sbcl sb-ext:invalid-fasl

      #+allegro excl::file-incompatible-fasl-error

      #+lispworks conditions:fasl-error

      #+cmu ext:invalid-fasl

      #-(or sbcl allegro lispworks cmu) error ()

      (asdf:perform (make-instance 'asdf:compile-op) c)

      (call-next-method))))

뭔가 많군... 결론적으로

~/.cclinit등의 lisprc에서 asdf 로딩 및 asdf:*central-registry* 등록
lisprc에서 charset 지정
slime에서 charset 지정
기타 slime-autoloads들 지정 (slime-fancy등...)

웹서핑: Ioke

Mon, 01 Mar 2010 14:40:50 +0900

Ioke?

2010/03/01 14:39:19

Io같은 CLR, JVM언어!

http://www.infoq.com/news/2008/11/ioke InfoQ와의 인터뷰

http://ioke.org/ ioke 홈페이지

http://olabini.com/blog/ 저자 ola bini의 블로그

JRuby 개발자였던 Ola Bini이 만든 언어군함...

나의 오픈소스 프로젝트

Sun, 28 Feb 2010 23:57:01 +0900

프로젝트

개인플젝, 오픈소스참여, ...

개인플젝

DimSum : 위키덕후의 야망!

오픈소스

ruby-openal : 루비 OpenAL 바인딩 (완성, out-of-date, 언젠가 업데이트?)
Factor io.encodings.korean : 팩터언어에서 한글인코딩 (완성)
sbcl-kor : SBCL 커먼리습컴파일러에서 한글인코딩 (완성, 비공식패치)
sdlhan : SDL에서 조합형 한글출력 라이브러리 (완성, 추가개발할 생각없음-_-)
lein.py : leiningen in python ... 이제 안할거임;;
- http://groups.google.com/group/clojure/browse_thread/thread/abb20def146bc9d3/ddf3178234327d4d?#ddf3178234327d4d

org-mode

Sat, 27 Feb 2010 23:20:35 +0900

org-mode

VIM만 몇년을 고수하다가 이맥스로 최근에 다시 전향하면서 이맥스의 강력함을 깨달았다.

이클립스에서 자바 개발이나 하는 회사일에 다행히 내겐 펄이나 파이썬, 루비 같은 작업 이외에도 GCC/G++로 C/C++ 개발작업이 있었는데 이를 위해 이맥스를 썼었던게 계기가 되었다. 처음엔 그냥 파일 편집을 다른 VIM으로 하다가 언젠가부터 "M-x compile"의 강력함에 빠져버렸다. 그리고 나서는 거의 대부분의 작업을 이맥스에서 하게 되었고 지금은 키바인딩도 VIM/이맥스 둘 다 익숙하다.

그러다가 org-mode을 이용해서 일기나 PIMS로 쓸려다가 좀 맞지 않는다는걸 깨달았었다. 그것보다는 차라리 일정관리, TODO관리등을 위해서 쓸 생각이다. 프로젝트나 개발작업등을 하는데 있어서는 언제나 "TODO.txt"을 이용했었으니까.

마침 info 페이지도 있고 읽으면서 공부해보면 좋을것 같다. 2010/02/27 00:53:42

info-page 읽다가 열어봤음... (이맥스에서 C-h i해서 org-mode 항목)

펄처럼 간단한건 간단하게 하는 나름의 미니멀리즘이 좋았음.

http://orgmode.org/

기본적인 info-page 읽어봤는데 처음 소개단에서 느낌 잡은건 다음과 같다.

문서구조

기본적인 outline-mode와 다를게 없이 텍스트 파일에 대한 편집모드다.
'*'등을 이용한 리스트를 관리한다. --> 노드
- 좀 별의 갯수에 따라 depth을 결정한다. 'org-indent-mode'등을 이용하면 더 시각적으로 표현해준다.
- 1, +, - 등 ordered, unordered list을 보일수있다.
- 각 리스트의 하위에 여러줄의 내용을 적거나 해줄수있다.
- depth별로 보이고 안보이고를 조절도 가능하고, 원하는 노드의 깊이를 조절하거나 트리를 자르고 붙이는 기능이 전부 지원된다.
- 원하는 노드만 다른 버퍼에 C-c C-x b로 열어서 편집도 가능하다
- 노드에 태그를 붙여서 관리할수있다.
- footnote을 따로 관리할수있다.

표

표 편집은 간단히 |, |- 등을 이용하니까 자동으로 먹어주는구나... 하악하악... 죽인다...

표 편집만으로 끝나는게 아니라 spreadsheet로 동작도 한다... elisp을 지원해;;;
gnuplot이랑 연동해서 plotting도 돼;;; ㄷㄷㄷ

링크

링크도 죽여준다;;;

[[link]] 또는 [[link][desc]]의 포맷인데, link은 *foo **bar #somewhere http://...등도 먹고, elisp:같은거까지 지원;;; ㄷㄷㄷ
C-c C-l을 이용해서 쉽게 링크를 만들기

TODO list

기본적으로는 TODO 태그를 붙여놓으면 되는데
C-c C-t을 갖고 TODO<->DONE 상태를 쉽게 전환
기타 검색/보기 기능이 잘 연동되어 있군함.
단순히 TODO, DONE이 아니라 다른 워크플로우로 확장도 가능하군.
org-todo-keywords 변수를 커스터마이징해서 TODO-DONE의 워크플로우 이외에 다른 키워드 집합의 워크플로우도 만들수있다.
- TODO, ALPHA, VERIFIED, DONE
- REPORTED, CONFIRMED, CANCELLED, FIXED 뭐 이런 버그픽스 플로우라던지...
- ...이런 워크플로우 값들을 ~/.emacs에 저장해 공유하기 귀찮으면 파일별로 지정도 가능해서 파일을 공유하면 자동으로 이루어지게도 되는군!
작업에 대한 로깅도 자동으로 할수도 있고...
우선순위 조정도 가능하군함... S-Up, S-Down
TODO 리스트의 끝에 [%] [/]을 붙여서 하위 TODO들의 진행 상황을 한눈에 볼수있음
TODO 리스트의 딸린 - 리스트을 이용해서 TODO 대신 [ ]을 붙이면 C-c C-c을 통해서 리스트를 체크할수있다;;; 그러면 TODO랑 같은 효과

프로퍼티

위에서 알아본 drawer의 특별한 형태로 :PROPERTIES: ... :END: 드로워에 속한다. 중간의 값들은 다음처럼 표현한다.

* foo
:PROPERTIES:
:TITLE: foobar
:SOME: a b c d e
:END:

검색이 가능한... 나름의 DB을 구현할수도 있겠군함.

elisp을 갖고 조작이 가능해서 무한히 이용 가능할듯.

Dates, Times

C-. 이랑 C-!으로 insert
+1w +1y와 같이 repeat을 줘서 같은날을 반복해서 보일수있군
HEADLINE에서 C-c C-d (deadline), C-c C-s (scheduled)을 insert
calendar나 agenda에서 보이나?

Capture

아이디어를 "잡아내기"
???

기타 그밖에 agenda등은 잘 모르겠다. 2010/02/27 23:20:19

결국 뭔가 TODO문서나 그런걸 자동적으로 관리도 해주겠지만 그런것까지는 별로 좋아하지않고 일단 TODO나 그런걸 관리하는게 좀 더 자동화되서 좋긴하다.

2010/02/27 23:20:46

Emacs + Clojure

Sat, 31 Oct 2009 00:46:31 +0900

Emacs: clojure-mode + slime

2009/10/03 18:05:58

emacs-23을 서버 계정에 설치했음.
그리고 ELPA을 설치해서 clojure-mode을 설치
바로 M-x clojure-install하니까 깔리네 헐퀴...
그리고 M-x slime 하니 떠버렸;;; ㄷㄷㄷ
이러다가 이맥스로 전향해버릴듯;;; Factor FUEL도 죽이고;;;

유니코드 심볼 사용하기

2009/10/31 00:46:05

(setq slime-net-coding-system 'utf-8-unix)

EmacsW32을 이용하여 윈도에 설치하기

2009/10/04 00:14:51

참고문서: http://tommih.blogspot.com/2009/08/emacs-clojure-and-windows.html

Emacs, Clojure and Windows

How to: Latest Clojure in Windows Vista (and others) with EmacsW32

Plan A:

Download EmacsW32 and install it from: http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl. You need to set HOME environment variable to point to your home directory. Note: the path is case sensitive! Otherwise Emacs will write all its stuff into users AppData directory.
Install ELPA, copy the following to *scratch* buffer in Emacs:
(let ((buffer (url-retrieve-synchronously
"http://tromey.com/elpa/package-install.el")))
(save-excursion
(set-buffer buffer)
(goto-char (point-min))
(re-search-forward "^$" nil 'move)
(eval-region (point) (point-max))
(kill-buffer (current-buffer))))
Place cursor right at the end of the last parentheses and press CTRL-j, which will run the code.
M-x means press ALT-x in Emacs, write the text after it, and press enter. Tab completion works. Try package- to find out different commands.
M-x package-install
clojure-mode (press enter)
At this point you need to install Git. Best way to do this in Windows Vista seems to be msysgit at this point. One could also install Git through Cygwin, but installing Cygwin just for Git seems a bit too much work.
msysgit is found here: http://code.google.com/p/msysgit/downloads/list. Use the full installer.
Personally I don't click Windows integration on, because it throws crap into my context menu, which is supremely annoying.
Download and install Apache Ant. Set it into your path. This includes downloading and extracting the archive, setting ANT_HOME to Ant root, Ant bin directory into PATH, and JAVA_HOME pointing to JDK root (if you haven't already).
M-x clojure-install. This will take a while as it downloads everything required from Git repositories and compiles them. I used c:/code/clj as my Clojure installation root.
Add (clojure-slime-config "PATH") to your .emacs config file, where PATH is the path to your Clojure installation, which you specified during M-x clojure-install.
Optionally you can M-x package-install paredit for some additional lispy goodness.
Read up some documentation on Emacs, SLIME and Clojure. Happy hacking!

The installation might still have some warts which can be fixed by editing .emacs. Add the following to the end:

(clojure-slime-config "c:/code/clj")

(add-hook 'slime-connected-hook (lambda () (require 'clojure-mode)))

I don't like the toolbar so (tool-bar-mode -1) removes that.

Additionally, you might want to include additional libraries into Java classpath, which can be done by writing the following into .emacs configuration file, before package-initialize:

(setq swank-clojure-extra-classpaths (list "c:/code/java/libs/swt/swt.jar" "c:/more/java/libs/foo.jar"))

Plan B: Install Clojure Box, which uses Clojure 1.0.0

기본 설치 대충 요약

msysgit 잘 설치한다.
1. msysgit 이하의 cmd 디렉토리를 PATH환경변수에 잡아준다. (그래야 emacs측에서 호출이 가능)
당연히 JDK랑 Apache Ant 설치한다.
1. JDK은 JAVA_HOME, PATH설정 잘해주고.
2. Ant은 ANT_HOME, PATH설정 잘해주고.
3. "javac -version"이랑 "ant" 커맨드로 테스트
이맥스 설치하고, ELPA설치한다.
ELPA설치해서 clojure-mode 설치한다. (M-x package-install)
clojure-mode설치후 M-x clojure-install로 Clojure을 원하는 디렉토리에 빌드한다. (하악하악)
M-x slime으로 Happy Hacking!

clojure에 추가 CLASSPATH을 변경하고 싶을때

; swank-clojure-extra-classpaths 리스트를 세팅

(setq swank-clojure-extra-classpaths (list "c:/code/java/libs/swt/swt.jar" "c:/more/java/libs/foo.jar"))

기타

ParEdit.el 초강추!

ageldama님의 노트

CFFI로 Hello MsgBox

Lua

Lua

LuaJIT

luac, 기타 로딩방식

lua -> .exe?

Google AI Challenge와 Lua

2010/03/02 화요일

정리: lua c-extension .dll 만들기

Lua C-extension .DLL 작성하기

01. 빌드 / 기초적인 인터페이싱

02. Lua 확장모듈로서

03. 기타

스터디: -fPIC, 공유라이브러리 만들기?

gcc의 -fPIC 옵션이 뭐지?

-fPIC와 -fpic

공유라이브러리

정적라이브러리 만들기

공유라이브러리 만들기

동적라이브러리?

.la 파일?

스터디: calling convention?

Calling Convetion?

2.1 stdcall, cdecl, fastcall

1 Calling Convention?

2 스택 정리를 누가 하든 무슨 상관인가?

2.1 호출자가 정리 - C Calling Convention

2.2 피호출자가 정리 - Standard Calling Convention

3 정리

4 링크

Win32: WinInet 캐쉬

ccl, asdf 환경잡기

clozure common lisp 세팅

웹서핑: Ioke

Ioke?

나의 오픈소스 프로젝트

프로젝트

개인플젝

오픈소스

org-mode

org-mode

문서구조

표

링크

TODO list

Tag

프로퍼티

Dates, Times

Capture

Emacs + Clojure

Emacs: clojure-mode + slime

유니코드 심볼 사용하기

EmacsW32을 이용하여 윈도에 설치하기

Emacs, Clojure and Windows

기본 설치 대충 요약

clojure에 추가 CLASSPATH을 변경하고 싶을때

기타