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.
15:39:51
drmeister
The frames with ??? are JITted functions and debug information is ignored - so there is no information on them.
15:40:39
drmeister
There used to be C++ functions between every pair. Now functions call each other directly.
15:42:14
drmeister
Instance_O::entry_point (that's the start of a generic function call using the old dispatch method)
15:43:10
drmeister
Instance_O::entry_point -> standard_dispatch -> apply_method -> funcall_consume_valist_ -> COMBINE-METHOD-FUNCTIONS2.LAMBDA -> apply_method -> funcall_consume_valist_ -> ???
15:56:50
drmeister
Now that functions are calling each other directly - it is easier to incorporate, test and verify inlining.
15:57:28
drmeister
:notify frgo The new way functions are calling each other may require some adjustments to defcallback.
15:57:33
drmeister
::notify frgo The new way functions are calling each other may require some adjustments to defcallback.