Hello. I have some interest in simplifying installation of Cells-GTK on as wide range of platforms as possible (from the "expansive" point-of-view: I have a perfectly fine installation of Cells-GTK on SBCL on Linux on my notebook). The attached patch enables ECL support in Ramarren cells fork. It actually does nothing except noting that ECL uses :clos package for MOP. I hope it will be included in master branch somewhen soon.. (cells::test-cells) gives no Cells errors (dribble errors do not count, right?).
Thanks Michael Raskin
Hello,
I pushed your patch to GitHub. I also tried running cells-gtk3 demo application on ECL, and it ran after I eliminated remains of UFFI dependency, since cffi-uffi-compat doesn't load. I pushed those fixes also (although I'm not sure if ALLOC-COL-TYPE-BUFFER shouldn't be just deleted, since it seems to be either exported or used), and changed (/ 3 0) in test application, since ECL just refused to compile it.
The only problem left is that cl-glut sometimes throws a package error (something with exporting SPECIAL), but it works on RETRY.
Regards, Jakub Higersberger
2010/1/29 Michael Raskin f9cef2aa@yandex.ru:
Hello. I have some interest in simplifying installation of Cells-GTK on as wide range of platforms as possible (from the "expansive" point-of-view: I have a perfectly fine installation of Cells-GTK on SBCL on Linux on my notebook). The attached patch enables ECL support in Ramarren cells fork. It actually does nothing except noting that ECL uses :clos package for MOP. I hope it will be included in master branch somewhen soon.. (cells::test-cells) gives no Cells errors (dribble errors do not count, right?).
Thanks Michael Raskin
On 01/29/2010 11:40 AM, Ramarren wrote:
Hello,
I pushed your patch to GitHub. I also tried running cells-gtk3 demo application on ECL, and it ran after I eliminated remains of UFFI dependency, since cffi-uffi-compat doesn't load. I pushed those fixes
I am currently convincing CFFI maintainers to accept either of two two-line fixes for that UFFI dependency..
also (although I'm not sure if ALLOC-COL-TYPE-BUFFER shouldn't be just deleted, since it seems to be either exported or used), and changed (/ 3 0) in test application, since ECL just refused to compile it.
I guess you can just replace it with eval. Although that may lead to ECL wanting GCC.
The only problem left is that cl-glut sometimes throws a package error (something with exporting SPECIAL), but it works on RETRY.
I currently fail to understand what they are doing wrong. I fail to make sense of Common Lisp standard meaning of their shadow statement.
-
Michael Raskin -
Ramarren