방금 IronPython 1.0 Beta 5를 릴리즈했습니다. 이번 릴리즈의 초점은 성능 개선입니다. 처음 시작할 때 컴파일하는 시간을 줄이기 위해 메소드 최적화를 on-demand로 합니다. 어트리뷰트 접근 제어를 개선했고, 자주 쓰이는 코드의 오버헤드를 줄였습니다. 그 외에 자잘한 튜닝이 있었습니다.
export G_SLICE=always-malloc 과 같이 해서 예전 메모리 allocator를 사용하도록 강제할 수 있습니다. 영향을 받는 프로그램으로 irssi, balsa, monodoc 등이 있고, evolution도 뜨자마자 죽었습니다만 지금은 수정되었습니다.
방금 IronPython 1.0 Beta 3를 릴리즈했습니다. 이 릴리즈는 주로 1.0 안정 버전으로 가기 위한 버그 수정 릴리즈입니다. 안타깝게도 PythonEngine API쪽은 들여다보지 못했지만 다음 베타에는 할 겁니다.
CLR과 파이썬 연동을 계속해서 개선하고 있습니다. 이 릴리즈에서는 CLR 어셈블리 로딩을 위한 clr.Path 지원을 추가했습니다. (파이썬을 위한 sys.path와 비슷한 성격을 가집니다.) 배열 지원을 개선했습니다. .NET 배열을 슬라이싱 할 수 있고, Array[int]((2, 3, 4, 5))와 같이 하여 2, 3, 4, 5를 값으로 가지는 정수형 배열을 만들 수 있게 되었습니다.
가사 위 재단이 주장하는 것처럼 위 프로그램이 오픈소스라고 하더라도 과연 어느 특정한 개인이나 회사가 최초 공개된 소스를 바탕으로 보다 업그레이드된 프로그램을 개발한 경우 반드시 이를 공개하여야 한다면 그 프로그램을의 공개와 관련하여 가하는 제한은 사실상 또는 법률상 무효인 것입니다. 왜냐하면 어차피 누군가는 위 프로그램을 바탕으로 업그레이드 할 것임이 분명하고 또 이를 영업상 사용할 수도 있는 것인데 이를 항상 공개하여야 한다면 이는 바로 "누구도 자신의 비용과 노력을 들여 영원히 업그레이드를 하지말고 원시 소스 그냥 사용하라는 것과 동일합니다." 즉 개인의 창의성, 경제성 및 이윤추구동기를 무한히 제한하는 것으로서 효력이 없다고 하여야 할 것입니다.
GPL인 라이브러리를 GPL이 아닌 프로그램에 링크하는 것은 (LGPL과는 달리) 허용되지 않지만, 예를 들어 파이프나 소켓을 통해 통신이 이루어진다면 이것이 "derived work"인가 하는 문제는 훨씬 애매해집니다. 일반적으로 파이프를 통해 오고가는 텍스트의 포맷이나 소켓의 프로토콜이 "단지 GPL을 피해가기 위해" 고안된 것이라면 무효이고, 일반적이고 다른 프로그램도 사용할 수 있는 것이라면 두 프로그램을 분리된 것으로 볼 수 있다고 해석되는 것 같습니다.
KLDP 블로그는 그다지 화려하지도, 많은 기능을 제공하지도 않지만 F/OSS, IT에 관련된 충실한 내용을 담고자 노력하는 분들이 함께 만들어 나가고 있습니다. 혹시라도 이곳에서 블로그를 운영하시고자 하는 분은 이곳으로 어떤 내용으로 운영하실지를 알려 주십시오. 확인 후 개설 여부를 결정하여 알려 드리도록 하겠습니다.
