This is present in 0.16 and latest from svn, but not in 0.15. Specifying a keyword arg in an initialize-instance method does not make the keyword a valid initarg for make-instance.
Armed Bear Common Lisp 0.16.0 Java 1.6.0_12 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.425 seconds. Startup completed in 2.086 seconds. Type ":help" for a list of available commands. CL-USER(1): (defclass c1() (x)) #<STANDARD-CLASS C1 {5A347448}> CL-USER(2): (defmethod initialize-instance :after ((c c1) &key x2) (setf (slot-value c 'x) x2)) #<STANDARD-METHOD INITIALIZE-INSTANCE :AFTER (C1) {79A1EA46}> CL-USER(3): (make-instance 'c1 :x2 1) Debugger invoked on condition of type PROGRAM-ERROR: Invalid initarg :X2. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(4):
Works as expected in 0.15
Armed Bear Common Lisp 0.15.0 Java 1.6.0_12 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.45 seconds. Startup completed in 2.021 seconds. Type ":help" for a list of available commands. CL-USER(1): (defclass c1() (x)) #<STANDARD-CLASS C1 {615E7597}> CL-USER(2): (defmethod initialize-instance :after ((c c1) &key x2) (setf (slot-value c 'x) x2)) #<STANDARD-METHOD INITIALIZE-INSTANCE :AFTER (C1) {7346B111}> CL-USER(3): (make-instance 'c1 :x2 1) #<C1 {772EDF9A}> CL-USER(4):
2009/9/25 Steve Rolls srolls24@gmail.com:
This is present in 0.16 and latest from svn, but not in 0.15. Specifying a keyword arg in an initialize-instance method does not make the keyword a valid initarg for make-instance.
CL-USER(2): (defmethod initialize-instance :after ((c c1) &key x2) (setf (slot-value c 'x) x2)) #<STANDARD-METHOD INITIALIZE-INSTANCE :AFTER (C1) {79A1EA46}> CL-USER(3): (make-instance 'c1 :x2 1) Debugger invoked on condition of type PROGRAM-ERROR: Invalid initarg :X2.
Thanks for the report, we check the initargs for shared-initialize methods, but not for methods of initialize-instance itself. Therefore, we don't find that :x2 initarg (because we only look into shared-initialize methods) and thus the arg check fails. I'll hopefully be able to fix this during the weekend.
2009/9/26 Ville Voutilainen ville.voutilainen@gmail.com:
Thanks for the report, we check the initargs for shared-initialize methods, but not for methods of initialize-instance itself. Therefore, we don't find that :x2 initarg (because we only look into shared-initialize methods) and thus the arg check fails. I'll hopefully be able to fix this during the weekend.
Well, it took a lot longer than I hoped to get into fixing this problem, but the fix is committed on trunk, r12178.
Ville Voutilainen wrote:
2009/9/26 Ville Voutilainen ville.voutilainen@gmail.com:
Thanks for the report, we check the initargs for shared-initialize methods, but not for methods of initialize-instance itself. Therefore, we don't find that :x2 initarg (because we only look into shared-initialize methods) and thus the arg check fails. I'll hopefully be able to fix this during the weekend.
Well, it took a lot longer than I hoped to get into fixing this problem, but the fix is committed on trunk, r12178.
Thanks Ville.
There is still at least one case that abcl is not happy with. A keyword argument with a default value.
CL-USER(7): (defclass c1() (x)) #<STANDARD-CLASS C1 {34E5190A}> CL-USER(8): (defmethod initialize-instance :after ((c c1) &key (x2 0)) (setf (slot-value c 'x) x2)) #<STANDARD-METHOD INITIALIZE-INSTANCE :AFTER (C1) {70DFB596}> CL-USER(9): (make-instance 'c1) #<C1 {39CEFFB8}> CL-USER(10): (make-instance 'c1 :x2 11) Debugger invoked on condition of type TYPE-ERROR: (X2 0) cannot be coerced to a string. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(11):
2009/10/7 Steve Rolls srolls24@gmail.com:
Thanks Ville. There is still at least one case that abcl is not happy with. A keyword argument with a default value.
Well, I'll see what I can do.
I also imagine that abcl is not happy with methods for make-instance itself taking keywords.
We now check initargs for shared-initialize and initialize-instance methods, but not for make-instance methods. It's probably reasonable to expect people to want to write :before/:after methods for make-instance.
2009/10/7 Steve Rolls srolls24@gmail.com:
There is still at least one case that abcl is not happy with. A keyword argument with a default value.
This problem is fixed by r12179. Our initarg checking used string= for the element of the method lambda list, but that element is a list if there's a default value for the argument.
Ville Voutilainen wrote:
2009/10/7 Steve Rolls srolls24@gmail.com:
There is still at least one case that abcl is not happy with. A keyword argument with a default value.
This problem is fixed by r12179. Our initarg checking used string= for the element of the method lambda list, but that element is a list if there's a default value for the argument.
Thanks again Ville.
BTW, the performance improvements in head vs. the last version I used (0.13) are very impressive. Running regression tests on my code (which makes fairly extensive use of CLOS) took 300 seconds with 0.13. Now it is 24 seconds on the first run and 14 seconds on the second run.
On Fri, Oct 9, 2009 at 5:18 PM, Steve Rolls srolls24@gmail.com wrote:
Ville Voutilainen wrote:
2009/10/7 Steve Rolls srolls24@gmail.com:
There is still at least one case that abcl is not happy with. A keyword argument with a default value.
This problem is fixed by r12179. Our initarg checking used string= for the element of the method lambda list, but that element is a list if there's a default value for the argument.
Thanks again Ville.
BTW, the performance improvements in head vs. the last version I used (0.13) are very impressive. Running regression tests on my code (which makes fairly extensive use of CLOS) took 300 seconds with 0.13. Now it is 24 seconds on the first run and 14 seconds on the second run.
Wow! That's *very* impressive. Do you have time to investigate what might be causing this? Could it be that you're not only heavily using CLOS extensively, but you're using deep call stacks a lot too? Or maybe you're using structures a lot?
Anyway, if you can share some experience with us what commits made your tests faster and which ones slowed it down, that could really be helpful information in improving our performance further. (And we're definitely dedicated to doing so!)
Regards,
Erik.
Erik Huelsmann wrote:
On Fri, Oct 9, 2009 at 5:18 PM, Steve Rolls srolls24@gmail.com wrote:
Ville Voutilainen wrote:
2009/10/7 Steve Rolls srolls24@gmail.com:
There is still at least one case that abcl is not happy with. A keyword argument with a default value.
This problem is fixed by r12179. Our initarg checking used string= for the element of the method lambda list, but that element is a list if there's a default value for the argument.
Thanks again Ville.
BTW, the performance improvements in head vs. the last version I used (0.13) are very impressive. Running regression tests on my code (which makes fairly extensive use of CLOS) took 300 seconds with 0.13. Now it is 24 seconds on the first run and 14 seconds on the second run.
Wow! That's *very* impressive. Do you have time to investigate what might be causing this? Could it be that you're not only heavily using CLOS extensively, but you're using deep call stacks a lot too? Or maybe you're using structures a lot?
Anyway, if you can share some experience with us what commits made your tests faster and which ones slowed it down, that could really be helpful information in improving our performance further. (And we're definitely dedicated to doing so!)
Regards,
Erik.
When I get a chance, I'll try to look into it some more.
armedbear-devel@common-lisp.net
-
Erik Huelsmann -
Steve Rolls -
Ville Voutilainen