Wow. Defining a class changes error messages. Look at this fully! If I call (time) I get an error message about "~S" but after defining a dummy class when I do (time) I get the correct error message! CL-USER(1): (time) #<THREAD "interpreter" {3DCA1588}>: Debugger invoked on condition of type PROGRAM-ERROR Wrong number of arguments for ~S. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): 0 CL-USER(3): (defclass abc ()) #<STANDARD-CLASS ABC {784E8EDC}> CL-USER(4): (time) #<THREAD "interpreter" {3DCA1588}>: Debugger invoked on condition of type PROGRAM-ERROR Wrong number of arguments for TIME. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): On Wed, Jan 12, 2011 at 10:18 AM, Blake McBride <blake@mcbride.name> wrote:

Here is another example:

Error loading /Users/blake/NetBeansProjects/Arahant/src/java/com/arahant/lisp/utils.lisp at line 268 (offset 10995) #<THREAD "main" {E4EB585}>: Unhandled condition of type SIMPLE-ERROR:  The slot ~S is missing from the class ~S.

"~S" isn't very helpful.

Thanks.

Blake McBride

On Tue, Jan 11, 2011 at 8:52 AM, Blake McBride <blake@mcbride.name> wrote:

...

I've noticed a problem with error reporting in certain cases.  For example, if you type (cons) you get:

"Wrong number of arguments for CONS."

However, if you type (time) you get:

"Wrong number of arguments for ~S."

It should be:

"Wrong number of arguments for TIME."

Of course this is a problem because it doesn't give any pointers when a function fails.

I've seen this issue in several instances.

Thanks.

Blake McBride

On Fri, Jan 21, 2011 at 5:43 PM, Blake McBride <blake@mcbride.name> wrote:

These sorts of messages are making development significantly and needlessly time consuming:

#<THREAD "http-8084-3" {37ADF98A}>: Unhandled condition of type SIMPLE-ERROR:  There is no applicable method for the generic function ~S when called with arguments ~S.

I believe it's related to a problem with autoloading not firing in certain situations. As a workaround, try to ensure that the pretty printer and/or print-object is loaded before you run your code (a simple (pprint 42) should do). I can't check it right now, so let me know if it doesn't work. Bye, Alessio

On 21 January 2011 20:50, Blake McBride <blake@mcbride.name> wrote:

I tried putting your (pprint 42) right before the line that causes the problem and I got: 42 #<THREAD "http-8084-3" {3D33EF4C}>: Unhandled condition of type SIMPLE-ERROR:  There is no applicable method for the generic function ~S when called with arguments ~S.

I think I've found the reason, and it's not autoload but rather Condition.getMessage(), which was never intended to return anything in its base form. It used to print getFormatControl().toString(), which sometimes printed crap like org.armedbear.lisp.Lisp$unboundValue@19ccb73. Then Alessio committed a fix that makes Condition.getMessage() return getFormatControl only if format control has been bound. I think the correct approach is to make Condition.getMessage() return null. That fixes the (time) example Blake posted, and does the right thing for type-errors that used to print unboundValue. I'll go through the rest of Blake's reports, see that the others are fixed and will commit the patch after that. Thanks for the reports, fixing this soon.

Dear Ville, Enclosed are the samples you requested. The file error.lisp can produce either error depending on witch code you uncomment. Obviously, the errors are intended. The error message is what is in question. To use, load clos-utils.lisp first and then error.lisp. I hope this is helpful. Thanks for your help. Blake McBride On Sun, Jan 23, 2011 at 12:41 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

On 23 January 2011 20:15, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

...

return null. That fixes the (time) example Blake posted, and does the right thing for type-errors that used to print unboundValue. I'll go through the rest of Blake's reports, see that the others are fixed and will commit the patch after that. Thanks for the reports, fixing this soon.

Blake, do you have simple snippets that cause the slot/method printouts? I was unable to cause such printouts with some simple slot/method cases I've tried, so I need some tests to check whether I've fixed it all.

I just checked it again and it works correctly as you expected. I think I checked out the latest source just a little early. When I updated just now I got another file (I think condition.java) and it works now. Thank you very much. Blake McBride On Tue, Jan 25, 2011 at 1:48 PM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote:

On 24 January 2011 01:22, Blake McBride <blake@mcbride.name> wrote:

...

Dear Ville, Enclosed are the samples you requested. The file error.lisp can produce either error depending on witch code you uncomment. Obviously, the errors are intended. The error message is what is in question. To use, load clos-utils.lisp first and then error.lisp. I hope this is helpful.

With the getMessage() fix I made (and which Erik committed) I seem to get correct messages for those functions. Am I missing something? Can you check whether the current trunk works for you?