posted by 아겔-_- 2010.11.05 23:38

Win32 + CLISP + SLIME

-*- org -*-

1 아겔 2010-11-05 금

2 필요성

  • Win32에서 쓸만한 커먼리습 구현/환경을 세팅하는게 나름대로 많은 사람들이 도전하고 나도 해봤는데 만만치도 않고, 만족스럽게 구현하는게 힘들었었다.
  • 나름 이번에 CLISP을 구현체로 사용하면서 느낀점과 노하우를 정리해보기.

3 어째서 CLISP?

3.1 장점

  • 윈도에서 별 문제없이 잘굴러간다. (CCL, SBCL, CMUCL이 좀 불안정하고 항상 베타인점과 비교해서 큰 장점이라고 생각함.) Viaweb의 경우에도 윈도환경에서 CLISP을 이용하여 개발하였다고.
  • 안정적이다. 윈도환경에서 다른 구현체들은 다운되거나 SWANK만 띄우다가도 죽는 Kitten of Death을 종종 보는데 CLISP/Win32에서는 그런 경우를 본적이없다.
  • 생각보다 정말 빠르다. 바이트코드를 이용하는 VM이라서 다른 네이티브 코드를 생성하는 컴파일러에 비해서 느릴거라는 생각을 했는데 그렇게 차이가 안나고 오히려 다른 언어들(자바, 파이썬…)등보다 빠르고 특히 수치연산과 같은 부분은 놀랄정도로 빠르다. 실제로 애플리케이션 개발해서 사용해도 성능에 무리가 없다.
  • 애플리케이션 개발하여 단독배포(Standalone Deployment)이 윈도에서도 현실적이고 잘되어있다. 단순히 EXT:SAVEINITMEM을 이용하여 실행화일과 함께 이미지를 떨굴수있도록 되있어서 편하게 배포할수있다.
  • 유니코드 지원이 좋다. 다른 구현체에 비해서 유니코드 구현 레벨도 높고 바로 적용해서 쓸만한 수준이다.
  • 구현노트에 정말 자세하게 문서화를 잘해놨고, 윈도환경에서 큰 사용자를 크게 놀래키지않고 안정적이고 멋진 성능으로 커먼리습을 경험하기에 좋은 구현체라고 생각한다. (다른 운영체제에서도 그렇긴하지만)

3.2 단점

  • 스레드 지원이 좀 거시기하다. CLISP 구현노트(implementation notes) 문서에는 CL:*FEATURES*에 :MT이 있고, MT 패키지를 통해서 구현하고, POSIX, Win32에서 지원한다는데 내 버젼에서는 지원이 꺼져있나보당. (CLISP 2.49, 2010/07/07, Win32)
  • "Bordeaux Threads"와 같은 de Facto 스레드 라이브러리에서도 CLISP은 아예 지원이 안되고있음.
  • 스레드 관련 때문인지 Hunchentoot와 같은 일반적으로 커먼리습 웹개발에 이용하는 웹서버/웹프레임웍이 지원안된다. (다른 대안도 많지만)
  • 내장 함수들은 docstring이 거의 없어서 slime-autodoc의 덕을 별로 못본다. 다른 구현체들은 docstring이 나름 붙을만큼 붙어있어서 HyperSpec 안봐도 대충 알수있지만 docstring도 안붙고 인자 이름도 그냥 arg1, arg2… 이렇게만 보여서 가끔 거시기함.

3.3 대안들

  • SBCL : 좋고 네이티브 컴파일러라 멋지긴한데, 리눅스/FreeBSD였다면 이를 쓰겠지만, 윈도에서는 정말 너무하다 싶을 정도로 뻗어버려서 안쓰고 만다는 생각밖엔 안든다. docstring이나 그런것들도 친절하게 잘해놨고, 배포도 쉽게 할수있도록 배려를 해놨지만 여전히 윈도지원이 거시기하다.
  • Clozure CL : 네이티브 컴파일러, docstring 모두 좋은데, 역시 무서울정도로 뻗어주고 윈도에서 배포도 좀 거시기해보인다.
  • ECL : 윈도에서도 빌드되고 바이트코드 방식이라고. 음 나름 평이 좋은거 같은데 시도해볼까.
  • MKCL : 아직 써본적없음. KCL계열이고, ECL에서 fork했다고. 윈도에서도 MingW을 이용해서 빌드가 가능하단다. 나중에 한번 시도해보고 싶음. 프로젝트 자체가 매우 새롭다.
  • 상용 구현체 (Franz, LispWorks) : 돈 있으면 사서 쓰고싶다. 트라이얼들은 사용시간 제한이 있거나, 힙크기 제한이나 이미지 저장이나 deploy을 못하게 막아놓았다. 결국 돈주고 사는게 제일 속편할거 같다.
  • ABCL : 특이하게 JVM위에서 굴러가는 구현체. 시도해보면 재밌을거 같다.

4 Emacs+SLIME 기본세팅

  • 딱 필요한 설정만 하는게 취향.

4.1 이맥스 설치

4.2 SLIME 패키지 수동 설치

  • 그냥 cvs snapshot 받아서 압축 풀어서 바로 적용.

4.3 ~/.emacs

(setq slime-net-coding-system 'utf-8-unix)
(add-to-list 'load-path "c:/lisp/slime-2010-10-29/")
(require 'slime)
(setq inferior-lisp-program "c:/lisp/clisp/clisp.exe")
(slime-setup '(slime-fancy))
(setq slime-header-line-p nil)

5 mk-defsystem? ASDF? libCL? QuickLisp? clbuild?

  • 의존성, 외부 라이브러리.
  • 커먼리습에도 다양한 시도가 있구낭.
  • 그 이외에도 어떤 '시스템(system)'을 컴파일하고, 이미지에 적재하는데 좀 자동화하는 필요성도 있긴함. 어떤 시스템을 만들어서 배포하는데 이런거 일일이 적어주기도 그렇고 스크립트로 작성하기도 마땅한건 아니니까.
  • '시스템' : 패키지는 이름공간을 나누는데 이용하고, 자바와 같은 플랫폼과는 다르게 단순히 한 소스파일이 꼭 하나의 패키지 항목이라고 말할수도 없고, 하나의 소스에도 여러 패키지를 만들수도 있고… 차라리 C/C++처럼 여러개로 분할하여 컴파일도 가능하고… 커먼리습은 파일기반이라기보다는 이미지 기반이기 때문에 좀 다른 접근법이 필요함. 이런 상황에서 다수개의 패키지, 다수개의 소스파일을 일괄, 자동화하여 빌드/로딩할 방법이 필요함. 이런 집합을 '시스템'이라고 부르는듯함.
  • 어떻게 생각하면 C/C++의 make이랑도 비슷하다고 생각하면됨.
  • 의외로 "quicklisp user survey"(http://xach.livejournal.com/271794.html)의 결과에서 재밌는 부분을 찾았다. 나 이외에도 대부분의 CL이용자들이 직접 그냥 손으로 다운로드하여 시스템을 설치하는구나…

5.1 mk-defsystem

  • CLOCC(the CommonLisp Open Code Collection)에 포함된 'defsystem'
  • 좀 오래된 방법인거 같음.
  • 더 대중적으로 인기도 많고 대세인 'asdf'의 'asdf-install'을 통해 설치가 가능하단다.
  • C/C++의 make이랑 비슷한 위상인듯.

5.2 ASDF

  • ".asd" 파일을 통해서 정의한 시스템을 그와 딸린 소스코드를 컴파일/로딩하는데 이용하는 de Facto.
  • 현재 오픈소스 리습 커뮤니티의 거의 대부분의 라이브러리나 애플리케이션은 asdf을 통해 패키징하고 배포하는게 대세인듯.
  • 네트웍을 통해 자동으로 패키지를 다운로드하고 설치하고, 의존성도 자동으로 설치해주는 asdf-install 같은 확장도 있어서 편리하다.
  • 윈도 환경에선 asdf-install이 마땅치 않으나 그래도 asdf을 손으로 설치해도 나쁘지 않으므로 이렇게 이용하는게 차라리 속편하다.

5.3 libCL

  • 리눅스 배포판처럼 아예 자주 쓰는 커먼리습 라이브러리들을 한번에 묶어서 설치해 사용하도록 하는 방법.
  • 그럭저럭 쓸만한데 업데이트도 느리고 윈도7에서 잘 굴러가지도 않아서 편하긴 하지만 안쓰게됨.

5.4 QuickLisp

  • asdf-install처럼 원격의 시스템을 받아다 의존성까지 풀어서 설치하는 새로운 방식.
  • 좋긴한데 중앙집중적으로 또 다른 저장소에서 메타데이터들을 관리하고 좀 마음에 안들때도 있음. 어차피 정말 그래도 써야겠다면 어차피 손으로 로딩해도 되긴하지만. 무엇보다 윈7에서 잘 안맞는거 같아서 이것도 접었음.

5.5 clbuild

  • asdf-install처럼 라이브러리를 다운로드/컴파일/로드하는 방식.
  • jhbuild을 모델로해서 만들었다고 하는구낭. 쉘스크립트 방식이라 윈도에선 좀 거시기할듯. 그리고 QuickLisp처럼 중앙 저장소에서 관리를 하는구나.

6 ASDF 이용

6.1 ~/.clisprc.lisp을 이용하여 asdf 로딩/설정

  • 단순히 "asdf.lisp" 파일을 시작시 CL:LOAD 하도록 지정해주면됨.
    ;; c:/lisp/lisp/asdf/asdf.lisp 있어야겠죠?
    (load #P"c:/lisp/asdf/asdf")
    

6.2 시스템 컴파일/로딩

  • 시스템의 이름을 지정할때는 예를 들어, 시스템 이름이 "puri"인 경우 키워드나 문자열, 심볼 모두 가능.
  • ASDF:*CENTRAL-REGISTRY*에 ".asd" 파일과 소스코드가 위치한 디렉토리를 CL:PUSH해주고서 실행하는게 윈도에선 속편함.
    • 단점으로는 의존성들에 대해서도 일일이 CL:PUSH ^^;
  • 컴파일 : ASDF:COMPILE-SYSTEM이나 ASDF:OPERATE, ASDF:OOS와 ASDF:COMPILE-OP 이용.
    > (ASDF:COMPILE-SYSTEM :puri)
    ;; ..or
    > (ASDF:OPERATE 'ASDF:COMPILE-OP :puri)
    ;; ..
    > (ASDF:OOS 'ASDF:COMPILE-OP :puri)
    
  • 로딩 : 컴파일과 같으나, ASDF:LOAD-SYSTEM, ASDF:LOAD-OP인점만 다름. 컴파일은 자동으로 적용.

6.3 기타…

  • 윈도에서 "바로가기"를 이용하여 유닉스의 심볼릭 링크처럼 ASDF:*CENTRAL-REGISTRY*에 지정한 디렉토리에 ".asd" 파일만 링크하면 매번 시스템 적재할때마다 ASDF:*CENTRAL-REGISTRY*에 경로를 지정안해도 된다고 하는데 난 왜 안되지;;;
  • "NTFS Symbolic Link"을 이용하여 시도해보면될까
  • 아님 ASDF:*SYSTEM-DEFINITION-SEARCH-FUNCTIONS*에 하위 디렉토리를 검색하여 로딩하도록 함수를 추가해서도 해결이 가능해보인다.
    • http://en.wikibooks.org/wiki/Common_Lisp/External_libraries/ASDF/Configuring_ASDF#Alternative_to_symlinks.2C_search_directories_recursively
      ;; An alternative to the standard sysdef search can be defined.  This                
      ;; code below can be dropped into your Lisp init files and customized.               
      ;; It will search for all ASDF systems in subdirectories of the                      
      ;; specified directories.  That lets you simply "drop-in" new packages               
      ;; into one of the specified directories, and it will be available for               
      ;; loading without any further steps.                                                
      (in-package #:asdf)
      (defvar *subdir-search-registry* '(#p"/my/lisp/libraries/")
        "List of directories to search subdirectories within.")
      (defvar *subdir-search-wildcard* :wild
        "Value of :wild means search only one level of subdirectories; value of :wild-inferiors means search
       all levels of subdirectories (I don't advise using this in big directories!)")
      (defun sysdef-subdir-search (system)
        (let ((latter-path (make-pathname :name (coerce-name system)
                                          :directory (list :relative
                                                           *subdir-search-wildcard*)
                                          :type "asd"
                                          :version :newest
                                          :case :local)))
          (dolist (d *subdir-search-registry*)
            (let* ((wild-path (merge-pathnames latter-path d))
                   (files (directory wild-path)))
              (when files
                (return (first files)))))))
      (pushnew 'sysdef-subdir-search *system-definition-search-functions*)
      

Author: Jonghyouk Yun <ageldama@gmail.com>

Date: 2010-11-05 23:34:01 KST

HTML generated by org-mode 6.21b in emacs 23

신고
posted by 아겔-_- 2009.11.28 19:26

세줄요약:
  • clojure.jar, clojure-contrib.jar 절대 (직접) 설치하지마라!!!
  • 개발하려면 emacs + (elpa) + swank-clojure 써라!!!
  • lein을 활용해라!!!


1. emacs에 elpa을 설치한다 : http://tromey.com/elpa/

  방문해서 install elisp코드 이맥스 scratch 버퍼에 붙여넣고 C-j




2. swank-clojure 설치하여 slime + clojure 설치를 한방에

  이맥스에서 "M-x package-list-packages"한 다음 "swank-clojure"에서 "I"로 체크하고 "X"로 설치... 


3. ~/.emacs에 다음을 추가하여 유니코드 사용가능하게
(setq slime-net-coding-system 'utf-8-unix)

4. 이맥스에서 "M-x slime"하여 테스트!


5. leiningen을 설치 : http://github.com/technomancy/leiningen/

"lein" 쉘스크립트를 다운 받아 적당히 PATH에 걸고 실행가능으로.
그리고 다음을 쉘에서 실행하여 clojure, clojure-contrib등을 설치...
lein self-install

이렇게 하면 간략한 clojure 개발환경 세팅 끝.

project.clj을 만들고 lein compile, jar, uberjar, test등을 바로 적용이 가능해졌고, clojars에서 제공하는 외부 라이브러리를 다운 받아 적용이 가능해졌고 pom을 만들어 clojars에 배포하거나 apache-maven에 적용도 가능해지는 멋진 환경에 되었심...

이맥스에서는 "M-x swank-clojure-project"로 해당 project.clj의 경로를 지정하면 프로젝트를 바로 인식해서 열어준다능... (클래스패스등...)

하악하악... 


신고
posted by 아겔-_- 2009.10.04 18:02

 

2009/10/03 23:57:43

 

나같은 vimpire도 결국엔... 하악거리게 되었;;;

은근 사용해 보는데 이클립스에 익숙해져서 그런지 완전 좋게 느껴지는... vim이라는 구속구를 벗어버린 느낌이랄까...

 

 

ELPA

  • CPAN처럼 네트웍을 통해 elisp을 설치하는 하악... 2009/10/03 23:57:58
  • clojure-mode설치하고 M-x clojure-install해보고 나서 바로 반해버렸음

 

 

ParEdit

  • http://www.emacswiki.org/emacs/ParEdit
  • "괄호"을 위한 에디터! 2009/10/04 00:00:34
  • 리습코드를 편집하는데 이젠 없으면 안되게 나를 만들어버린 ㅜ.ㅜ

    • 괄호 자동 붙이기, M-)이라던지 C-k등을 느껴보아요...
  1. ;;; paredit.el
  2. (autoload 'paredit-mode "paredit" "Minor mode for pseudo-structurally editing Lisp code." t)
  3. (add-hook 'emacs-lisp-mode-hook       (lambda () (paredit-mode +1)))
  4. (add-hook 'lisp-mode-hook             (lambda () (paredit-mode +1)))
  5. (add-hook 'lisp-interaction-mode-hook (lambda () (paredit-mode +1)))
  6. (add-hook 'slime-repl-mode-hook       (lambda () (paredit-mode +1)))
  7. (add-hook 'slime-mode-hook            (lambda () (paredit-mode +1)))

 

http://www.emacswiki.org/emacs/ParEdit

 

http://www.emacswiki.org/emacs/PareditCheatsheet

 

SLIME + ElDoc

  • SLIME은 뭐 말할거 없잖수... 2009/10/04 00:02:12
  • ElDoc은 뭔가 입력할때(함수호출...) 메시지 버퍼에 인자목록등을 뿌려주는 하악하악...
  • (slime-setup '(slime-fancy))

    • 요렇게 초기화하면 대략 기타 contrib등을 같이 로딩함.
    • slime/contrib이하를 참고
    • 기타 원하는거 로딩해도 좋은데 정말 강력해지는 slime!
  • (setq slime-net-coding-system 'utf-8-unix)

    • 인코딩 지정해야지 심볼등을 정상적으로 한글입력!

 

 

 

 

 

이 글은 스프링노트에서 작성되었습니다.

신고
posted by 아겔-_- 2009.05.03 21:14
저는 vim을 좋아해요. 일상적인 텍스트/코드편집에서 정말 편하다는게 뭔지 느껴요.

이맥스나 jEdit도 좋아했었지만 언제나 vim으로 돌아오더라구요. (뭔가 마음이 급해서 엄청나게 편집해댈때)

vim에서 창분할이나 매크로 같은건 정말 코딩을 편하게 해주는것 같아요. FuzzyFinder, BufExplorer 같은 제게는 *필수* 플러그인들도 한몫하구요.

vim은 나름 오해를 받으며 사는것 같은데, vim은 vi가 아니라는걸 흔히 오해하는것 같아요. vim script로 vim을 확장하는건 나름 괜찮은 작업인것 같은데 마치 이맥스만 그런 환경인것처럼 되는거 같고, vim도 정말 문서화가 방대하고 세세하게 잘되어있는데 그런걸 잘 소개하지 않는것 같아요. (<ESC>:help 42)

솔직히 저랑은 이맥스는 잘 안 맞는다는 느낌이 많았아요. 더 중요한건 ~/.emacs을 잘 정리하고 관리할만큼 제가 부지런하지 못해서 그런것도 있겠지만... (제 ~/.vimrc은 플러그인 목록만 추가되지 몇년째 그대로 쓰고 있어요)

jEdit도 정말 멋진 편집기라고 생각해요. 특히 멀티셀렉션/수직선택은 다른 편집기에서 보기 힘든 정말 강력한 기능이었고, 이맥스스러운 키바인딩도 조금만 익숙해지면 정말 편리했었구요. 그럼에도 몇몇 자잘한 버그랑 좀 큰 파일(덤프한 xml을 열어서 무언가를 찾아본다거나. 그럴일 별로 없을지도;)을 열거나 성능에 대한 불만으로 사용을 접었었죠.

이맥스랑 jEdit의 기능중 멋지다고 생각하는게 검색인데, 특히 incremental-search랑 jEdit에서는 HyperSearch라고 부르는 이맥스의 M-x occur였어요. 버퍼의 모든 매칭되는 라인을 나열해주고 그중에서 하나씩 방문할수있도록 해주는 기능이죠. 증분검색은 사실 vi/vim에서 <ESC>n이랑 다를게 없는데, M-x occur은 찾을수없었어요. 나름 한눈에 파일의 내용중에 분포를 파악하기 정말 좋은 기능인데. (n을 누르면서 버퍼를 한바퀴 돌면;;; 좀 많이 포함한 버퍼는 어디까지였는지도 까먹고;;;)

하여튼 이를 구현한 플러그인이 있더라구요:

일단 vi/vim에서 하던대로 <ESC>/로 검색하고 <ESC>:Occur하면 매칭을 모두 보여주고 그 버퍼에서 엔터나 탭으로 해당 라인으로 바로 점프까지... ㅋ...



신고
posted by 아겔-_- 2009.02.01 16:33

팩터를 다시 갖고 놀면서(특히 FUEL^^;) Project Euler을 풀고 있어요. (http://projecteuler.net/index.php?section=problems)

처음에는 끔찍하게 생각하는 방식이랑 concatenative하게 안되다가 좀 자연스러워지면서 가속이 확확 붙는군요^^;

화면은 2백만 이하의 소수 구하는건데 좀 느리네요 ㅜ.ㅜ;; 오늘안에 산출값이 나올지 약간 의문이랄까^^;

하여튼 팩터+이맥스의 러브러브 스크린샷 하나 올릴게요.


신고

'삽질+돈되는짓 > FactorLanguage' 카테고리의 다른 글

팩터는 어떤 언어임까?  (0) 2009.02.13
Why "Factor"?  (0) 2009.02.13
io.encodings.korean을 완성했습니다.  (2) 2009.02.12
factor-kr을 시작했습니다.  (0) 2009.02.08
ProjectEuler 풀면서 한컷!  (0) 2009.02.01
FactorLanguage을 위한 SLIME?  (2) 2009.01.31
posted by 아겔-_- 2009.01.31 23:04
저는 FactorLanguage을 좋아합니다. (http://en.wikipedia.org/wiki/Factor_(programming_language))

실용적이고 제가 원하는것을 모두 갖춘것 같은 언어라고 생각해요. 커먼리습은 너무 오래되고 커지기만 한 느낌이고(물론, 언어자체의 설계를 뒤집을 필요가 전혀없으니까 그렇긴해도, 구현이나 개발환경이 그런게 사실 윈도나 런곳에서는 좀 제한적이잖아요?), 스킴은 뭔가 구현마다 너무 큰 갭이 있는것 같고요. (다른분들보다 제가 아둔해서 그렇게 느끼는걸수도 있겠죠. ^^;)

커먼리습 같은 네이티브 컴파일러, 파일/이미지기반의 개발, ffi도 괜찮고, 이미 다른 언어에서 구현하기 힘들정도로 멋진 도구들을 많이 갖추고 있고, 그리고 무엇보다 심플하고 완전한 언어 그자체로부터 나오는 강력한 표현력은 리습의 s-expression에서 느낀것보다 훨씬 신선하게 저에게 충격을 줬었습니다. 제게 있어서 리습은 제 생각하는 방법을 바꿔버린 언어이고, Factor은 생각하는 방법을 다시 바꾼 언어죠.

하여튼 제게 있어서는 다른 리습해커들에게 커먼리습이 갖는것처럼 뭔가 완전하고 아름다운 제 도구인 FactorLanguage에서 좀 싫어하는건 사실 개발환경이었어요.

익숙해지기 힘들고, 거추장스럽고, 마우스에 손이 자주가야하고, 그리고 무엇보다 아직은 한글입력/출력이 안되는! ㅜ.ㅜ




그런데 좋은 소식이 있었더라구요.
언제나 팩터쪽은 그런식(!!!)이듯이 순식간에 엄청난 물건이!

FUEL(Factor's Ultimate Emacs Library)이라는 겸손한 이름(;;;)의 Emacs모드였어요.

원래 팩터를 개발한 슬라바 아저씨(Slava Pestov, http://factor-language.blogspot.com/)가 jEdit을 개발한 사람이어서 그런지 jEdit쪽 바인딩이나 그런건 나름 괜찮았었는데, jEdit자체가 요즘엔 좀 거시기한 에디터가 되고 그랬던 와중에, 기존에 팩터에서 사용가능한 vim, emacs 모드에서 이맥스 모드였던 "factor.el"이 발전하여 SLIME(http://common-lisp.net/project/slime/)처럼 막강한 개발환경이 되었어요!

관련 블로그 포스팅 : http://factor-language.blogspot.com/2009/01/screencast-editing-factor-code-with.html


하악하악... 설정도 그냥 이맥스랑 팩터만 설치하고, 이맥스에서 fu.el을 load-file하면 끝!

;;; ~/.emacs에서...
(load-file "d:/tools/factor/misc/fuel/fu.el")

그리고 "M-x run-factor"하고 잠시 (처음 시작할때는 좀 많이 기둘려야 해용 ㅜ.ㅜ) SLIME-REPL처럼 사랑스러운 scratchpad을 만날수있답니다!

팩터 파일을 편집하고, 바로 REPL측에 컴파일/적재하고, 이를 테스트하고, 작성하면서 관련된 레퍼런스를 즉시 검색하고(팩터은 코드와 함께 문서도 적재되서 언제나 실행시간에 관련 문서를 바로바로 찾아볼수있답니다. ^^), 코드를 "리-팩터링"한다던지 하는 개발환경으로서 SLIME 못지 않은 환경을 간단히 갖출수있었어요.
(심지어 이클립스와 같은 자바IDE에서나 보던 'Organize Imports'와 같은 "fuel-update-usings"같은것까지 있더라구요.)

자세한 /뽀대/는 다음 스크린캐스트 : http://blip.tv/file/1658806


저에게는 FUEL이 참 설레이는 환경이 되었어요. *^^*




ps. 처음 "M-x run-factor"하면 많이 느린데요, 이유는 필요한 vocab(모듈이랑 비슷한 개념이에요)을 vm에 적재하고, 최적화 컴파일러를 거쳐서 컴파일하기 때문인데요, 빠르게 하시려면 한번 그렇게 적재하신 다음에 scratchpad에서 "save"을 쳐서, 이미지를 업데이트 하시면 다음번 "run-factor'부터는 빠르게 올라온답니다. 스몰톡이나 커먼리습처럼 파일기반으로 개발이 가능하면서도, vm의 현재 상태를 이미지로 만들어서 deploy하거나 개발할때 편리하게 이용할수있어요. ^^
신고

'삽질+돈되는짓 > FactorLanguage' 카테고리의 다른 글

팩터는 어떤 언어임까?  (0) 2009.02.13
Why "Factor"?  (0) 2009.02.13
io.encodings.korean을 완성했습니다.  (2) 2009.02.12
factor-kr을 시작했습니다.  (0) 2009.02.08
ProjectEuler 풀면서 한컷!  (0) 2009.02.01
FactorLanguage을 위한 SLIME?  (2) 2009.01.31

티스토리 툴바