Simple Lisp(S-Expression) Interpreter Project를 LGPL로 open 했습니다.
얼마전에, Rapid Tool Developement Tool 로서의 Lisp에 대한 의견을 여쭈는 글을 올렸었습니다. (http://kldp.org/node/116791)
사실 좀 오래전부터 개인적인 필요 - C/C++ 에 익숙한 사람이 또다른 script language에 의존하지 않고, script를 쉽게 짜기 위해... - 에 의해서 Console로 사용할 수 있는 lisp interpreter를 개발하고 있었습니다만...(S-Expression이 워낙 이해하기 쉽고, 사용하기 쉽기때문에...) 그 동안 마땅히 코드를 정리할 짬이 나지 않아서 오픈하지 못했었습니다.
(사실 그때는 REPL도 몰랐었고... 그냥 개인적인 필요에 의해서 개발을 시작했었습니다.)
직장생활하면서, 틈틈이 코드를 짜는 것도 쉽지 않았고.. 시간 내기도 힘들어서 차일피일 미루다가... 이번에, 마음먹고 코드도 정리하고, documentation도 하고.. 해서 드디어 open했습니다.
License는 LGPL이구요, Github에서 hosting합니다.
위치는 http://github.com/yhcting/ylisp 입니다.
아.. 혹시 여유있으신 분은 yhcting.wordpress.com (제 블로그...^^) 에 오셔서 글이라도 남겨 주시면 더욱 감사드리겠습니다.
참고로, 전 유명한 Lisp(Common Lisp, Haskel, elisp등)을 잘 모릅니다. 그래서, S-Expression에 대한 mathematical model을 기초로 해서 만들었기 때문에, 말은 Lisp Interpreter라고 했습니다만, 사실 S-Expression을 이용해서 자신만의 Lisp을 만들 수 있는 base project...라고 보는게 맞을것 같습니다....여튼 그렇습니다.^^;
많은 조언 + 격려 + 질책을 부탁드립니다.
GC를 레퍼런스 카운팅으로 구현하시면 안됩니다.
상호참조하는 구조가 있을 경우 메모리 출혈이 일어나게 됩니다. 과다출혈하면 프로그램이 사망하죠 ㅠㅠ
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
지적 감사합니다..
거기에 대한 처리도 구현해 두었습니다.
Cyclic한 Cross reference의 경우 memory pool이 특정 threshold이상이 사용되게 되면, Full scan을 통해서, 이런 문제를 걸러내도록 했습니다.
자세한 내용은 readme의 GC부분에 언급해 두었습니다. 더 자세하는, 코드에...^^;
다만, 이런 과정은 굉장히 cost가 비싸기 때문에, 위의 경우처럼 pool이 특정 수치 이상으로 사용되었을때, 가끔 한번씩만 돌도록 했습니다.
다시한번, 관심 감사드립니다.
(사실... 제가 생각하기에 메모리 부분의 가장 큰 이슈는... 아무래도 External Fragmentation이 아닌가 싶습니다... 이부분을 처리를 해야할지 - 처리하려니.. 너무 해야할 일들이 많아서... - 아니면 그냥 이대로 무시할지... 쩝...)
그 동안 진행 상황...
실로 오랜만에 update합니다.
위의 ylisp을 이용해서 실제로 tool을 만들어 사용하면서 많은 기능들이 추가/수정/debugging 되어서 많이 안정화 된 듯 합니다.
그래서 그 동안의 update사항을 정리해 보았습니다. (사실 "관심 가져 주세요~" 라는 외침이라는... -_-; )
* Multi-threading 지원.
- 새로운 interpreting thread를 생성할 수 있음. ('create-thread'라는 function 추가)
- per-thread symbol table 구현 됨. (global symbol, per-thread symbol, local symbol 이렇게 세 가지가 존재 함.)
- global symbol 의 set/unset 동기화.
* GC
- reference counter + scanning => scanning only : 굳이 두가지 방식을 모두 고집할 필요는 없어 보여서...
- MT (Multi-threading)을 지원하기 위해, 모든 interpreting thread를 suspend시키고, trigger됨.
* Data Structure for symbol look-up : Hash -> Trie
* 그 밖에 많은 native function들이 추가되었습니다. (제가 tool을 만들어 사용하면서 필요에 의해 추가되었다는... -_-; )
ylisp은 REPL 를 기본으로하고 있는 library라... user command를 해석 -> 반영 해야하는 tool에 사용하면 제법 괜찮은 효과를 보이더군요.
이상입니다.
기회가 되면 이후에 또 관련 update를 posting하겠습니다.
2011년 좋은 한해 되세요~
ylisp로 어떤 툴을 만들어 사용하시는지요?
아 대단하심니다. 프로그램 언어를 직접 만들어 사용하시다니.
근데 님께서 만드신 툴로 어떤 문제를 해결하고 계신지요?
저의 경우...
필요에 따라서 간단한 tool을 만들기 위해 programming을 해야하는 경우가 많은데, 이런 것들을 빨리 할 수가 있어서 도움이 되는 군요.
특히, ylisp자체가 library라 기존 tool의 성능 확장에 상당히 유용했습니다.
ylisp을 이용해서 만든 가장 복잡한 툴이라면, Android application을 위한, Block Box Test Tool 이라고 할 수 있겠네요.
요즘 Android device쪽 일을 하고 있는데, Android application에 대해 Black Box Test - 그러니까, user input (key 혹은 touch event) -> 예상되는 결과의 match (Unit test와는 좀 다르죠...) - 를 쉽게 수행하기가 힘들더군요.
Black Box Test를 위해서 user input history를 기억하고, 재생할 수 있는 tool은 있었는데, 그냥 눈으로 결과를 보고 검증할 수 밖에 없었습니다. 계속 보고 있어야 하죠..-_-;
그래서, 간단한 Application에 ylisp library를 연결하고, ylisp으로 jdb을 embed해서, user input + jdb input 에 대한 jdb output을 검사하는 script를 작성해서 돌려보니 좋은 결과를 얻을 수 있었습니다.
아.. 글을 적어 놓고 보니, 아무도 이해를 못할 내용이 되어 버렸군요... 죄송합니다. ㅜ.ㅜ
그럼 사용자 키 인풋에 대한 검증은 어떻게 하시는지요?
아하 사용자 터치 인풋을 님께서 만든 스크립트로 해결하고 계시군요.
근데 테스트 루틴에서 결과를 어떻게 비교하시는가요?
오류가 발생하면 화면이 달라질 수도 있을 텐데요.
GUI와 상관없이 함수단에서 값을 비교하세요? 아님 GUI랑 연계가 되서 이미지 비교를 하시나요?
만약 제가 님의 경우였다면 전 LUA를 사용했을 것 같네요.
아... 역시 제 글이 너무 두서가 없었군요..
너무 횡설수설해서 내용전달이 제대로 되지 못했군요...ㅜ.ㅜ
먼저 사과드립니다.(_ _)
자세한 내용을 적기는 어려울 것 같고 간단하게 설명하겠습니다.
터치 인풋을 스크립트로 해결하는 건 아니구요.
(이건 사실 굳이 스크립트로 안해도 다양하게 여러가지 방법들이 많으니...)
jdb 혹은 Android의 기타 다른 툴들 - adb를 이용한 여러가지 방법들이 많죠 - 과 기존 tool을 연계하기 위해, 그리고 이런 외부 tool들과의 연계 data를 근거로, 검증을 위한 scripting을 위해 ylisp을 사용했습니다.
또, GUI level에서 검증하느냐, 함수단에서 검증하느냐는 case by case혹은 정책에 대한 부분입니다.
Android에서 제공하는 기능을 통해서 GUI단에서 비교할 수도 있고 - 굳이 이미지가 아니라, resource id를 비교한다던가 등등 - , jdb를 통해서 함수단에서 값을 비교할 수도 있습니다. 경우에 따라 두 가지 모두를 사용할 수도 있죠.
그리고 LUA를 사용했을 것 같다는 말씀에는 별다른 의견이 없습니다. 제가 LUA를 잘 모르기 때문에 그렇기도 하거니와, language는 하나의 도구일 뿐인만큼 편한걸 사용하면 된다고 생각합니다.
관심 가져 주셔서 감사합니다.
친절한 답변에 감사합니다.
친절한 답변에 감사합니다.