Hello Kenny,
As of CLISP 2.38 (if not earlier, I haven't checked), the #+clisp defun for slot-definition-name is no longer necessary.
With that commented out, motor-control.lisp runs fine. Just thought you'd like to know :-)
I'm starting to look at Cells 3 with my first experiment being to write a simple game as a demo for my Graphic-Forms project, using Cells as the data model of course. I'll let you know how it goes.
-- Jack Unrue
On 4/1/06, Jack Unrue jdunrue@gmail.com wrote:
Hello Kenny,
As of CLISP 2.38 (if not earlier, I haven't checked), the #+clisp defun for slot-definition-name is no longer necessary.
Aha! I spotted that when cleaning up the code and had a feeling it could go. Thanks for the patch.
With that commented out, motor-control.lisp runs fine. Just
thought you'd like to know :-)
I'm starting to look at Cells 3 with my first experiment being to write a simple game as a demo for my Graphic-Forms project, using Cells as the data model of course. I'll let you know how it goes.
Please do, and I will be happy to help if you get stuck. I try to make up with support what I have omitted by way of doc.
Did you look at the Celtk module which is alongside Cells in the Cells project repository? That may give you some ideas on how to proceed. Note that Tk required a lot more handholding than I have encountered with other systems, so Celtk may have complexities your set-up will not -- I guess to be fair it is to be expected that driving an OO framework from a second Cells-based OO framework will be harder than driving a purely procedural... well, if you are using MFC, maybe not.
Anyway, let me know if you would like a second opinion on anything.
ken
On 4/1/06, Ken Tilton kentilton@gmail.com wrote:
Please do, and I will be happy to help if you get stuck. I try to make up with support what I have omitted by way of doc.
Did you look at the Celtk module which is alongside Cells in the Cells project repository? That may give you some ideas on how to proceed. Note that Tk required a lot more handholding than I have encountered with other systems, so Celtk may have complexities your set-up will not -- I guess to be fair it is to be expected that driving an OO framework from a second Cells-based OO framework will be harder than driving a purely procedural... well, if you are using MFC, maybe not.
Anyway, let me know if you would like a second opinion on anything.
Just wanted to follow up...I'm in the midst of cleaning up some GDI handle leaks in my code, so I haven't gotten back to Cells just yet. Hopefully soon.
-- Jack Unrue
On 4/1/06, Ken Tilton kentilton@gmail.com wrote:
On 4/1/06, Jack Unrue jdunrue@gmail.com wrote:
Hello Kenny,
As of CLISP 2.38 (if not earlier, I haven't checked), the #+clisp defun for slot-definition-name is no longer necessary.
Aha! I spotted that when cleaning up the code and had a feeling it could go. Thanks for the patch.
Sorry I didn't catch this before, but you also need these changes for clisp (also tested on LW):
=================================================================== RCS file: /project/cells/cvsroot/cells/model-object.lisp,v retrieving revision 1.4 diff -r1.4 model-object.lisp 53c53 < for sn = (slot-definition-name esd) ---
for sn = (clos::slot-definition-name esd)
115,116c115,116 < (when (md-slot-cell-type (type-of self) (slot-definition-name esd)) < (let* ((slot-name (slot-definition-name esd)) ---
(when (md-slot-cell-type (type-of self) (clos::slot-definition-name esd)) (let* ((slot-name (clos::slot-definition-name esd))
=================================================================== RCS file: /project/cells/cvsroot/cells/cells-test/test.lisp,v retrieving revision 1.4 diff -r1.4 test.lisp 228c228 < for sn = (slot-definition-name esd) ---
for sn = (clos::slot-definition-name esd)
-- Jack Unrue