freenode/#clasp - IRC Chatlog
Search
13:05:01
drmeister
I almost have cclasp building but I encountered an exception handling problem when EXIT is invoked when building cclasp.
13:17:19
Shinmera
In http://www.lispworks.com/documentation/HyperSpec/Body/f_shared.htm it mentions this for the initialisation of slots with initforms:
13:17:21
Shinmera
"Any slots indicated by slot-names that are still unbound at this point are initialized according to their :initform forms. For any such slot that has an :initform form, that form is evaluated in the lexical environment of its defining defclass form and the result is stored into the slot. For example, if a before method stores a value in the slot, the :initform form will not be used to supply a value for the
13:17:46
Shinmera
How would I hope to "evaluate the form in the lexical environment of the defclass"?
13:18:45
beach
Shinmera: What Bike said. It is very explicit in the AMOP, but not so much in the Common Lisp HyperSpec.
13:19:25
beach
Shinmera: the macro DEFCLASS turns the INTIFORM into an INITFUNCTION. You need to do nothing.
13:21:25
Shinmera
It would be great if that was linked or hinted at in http://metamodular.com/CLOS-MOP/slot-definition-initfunction.html too
13:36:07
beach
Shinmera: Like that: http://metamodular.com/CLOS-MOP/slot-definition-initfunction.html
14:47:14
drmeister
I think the impact on build time will be small because the big problem is still there - lexical variables being stored in activation frames. That's a structural problem of the bclasp compiler that will require a fair amount of rewriting.
14:47:37
drmeister
It should impact cclasp compilation time though - but I don't have evidence for that yet because I haven't gotten to that yet.
14:49:13
drmeister
And when I squeeze out more glue in effective method calls that I am much more aware of and capable of handling now with the experiences of the last months - it should speed up even more.