Blood pressure, specifically.
What does one do with this:
ABCL Debug.assertTrue() assertion failed! java.lang.Error: ABCL Debug.assertTrue() assertion failed! at org.armedbear.lisp.Debug.assertTrue(Debug.java:46) at org.armedbear.lisp.Package.shadowingImport(Package.java:601) at org.armedbear.lisp.PackageFunctions$9.execute(PackageFunctions.java:190) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:776)
No message - go hunt in source code. Yuck.
-Alan
On 5/4/10 4:47 PM, Alan Ruttenberg wrote:
Blood pressure, specifically.
What does one do with this:
ABCL Debug.assertTrue() assertion failed! java.lang.Error: ABCL Debug.assertTrue() assertion failed! at org.armedbear.lisp.Debug.assertTrue(Debug.java:46) at org.armedbear.lisp.Package.shadowingImport(Package.java:601) at org.armedbear.lisp.PackageFunctions$9.execute(PackageFunctions.java:190) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:776)
No message - go hunt in source code. Yuck.
Provide a test case please? But you knew that…
No recent work should have impacted this section of the code from what I can make of it, so we need to know how this code is failing to fix it.
I committed a sin on this one and worked around it and didn't record the specifics :( I'll be better next time.
But what I wanted to point out (not very constructively - sorry) was that it would be nice if debug.assertTrue printed out what it tried to assert as a message, to the console, so that one could diagnose a little without having to find the line in the source code.
I've been hitting a number of these. Often they happen at odd times, with very little to go on to even start debugging - say when compiling a function. There isn't a stack trace that's informative, I don't know what abcl was doing, and the report doesn't give me enough information to start.
A lot of the time I'll spend the effort to try to track it down, but I'd certainly appreciate it if some of the developers could think a bit about how to improve the situation wrt debugging such.
Regards, Alan
On Thu, May 6, 2010 at 4:16 AM, Mark Evenson evenson@panix.com wrote:
On 5/4/10 4:47 PM, Alan Ruttenberg wrote:
Blood pressure, specifically.
What does one do with this:
ABCL Debug.assertTrue() assertion failed! java.lang.Error: ABCL Debug.assertTrue() assertion failed! at org.armedbear.lisp.Debug.assertTrue(Debug.java:46) at org.armedbear.lisp.Package.shadowingImport(Package.java:601) at
org.armedbear.lisp.PackageFunctions$9.execute(PackageFunctions.java:190)
at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:776)
No message - go hunt in source code. Yuck.
Provide a test case please? But you knew that…
No recent work should have impacted this section of the code from what I can make of it, so we need to know how this code is failing to fix it.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 5/6/10 3:44 PM, Alan Ruttenberg wrote:
I committed a sin on this one and worked around it and didn't record the specifics :( I'll be better next time.
But what I wanted to point out (not very constructively - sorry) was that it would be nice if debug.assertTrue printed out what it tried to assert as a message, to the console, so that one could diagnose a little without having to find the line in the source code.
Since Java doesn't have a standard macro facility or a concept like eval, I can't think of an wasy way to output the tested assertion without repeating the string twice (which tends to lead to errors in my experience). There is often little context in the assertion code as to why the particular assertion needs to be true, so I'm not sure how helpful this would be.
If you got an idea how to make this more meaningful, I'm willing to implement something better.
On Thu, May 6, 2010 at 11:03 AM, Mark Evenson evenson@panix.com wrote:
On 5/6/10 3:44 PM, Alan Ruttenberg wrote:
I committed a sin on this one and worked around it and didn't record the specifics :( I'll be better next time.
But what I wanted to point out (not very constructively - sorry) was that it would be nice if debug.assertTrue printed out what it tried to assert as a message, to the console, so that one could diagnose a little without having to find the line in the source code.
Since Java doesn't have a standard macro facility or a concept like eval, I can't think of an wasy way to output the tested assertion without repeating the string twice (which tends to lead to errors in my experience). There is often little context in the assertion code as to why the particular assertion needs to be true, so I'm not sure how helpful this would be.
If you got an idea how to make this more meaningful, I'm willing to implement something better.
My java buddy says use this facility: http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
-Alan
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 6 May 2010 18:53, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Since Java doesn't have a standard macro facility or a concept like eval, I can't think of an wasy way to output the tested assertion without repeating the string twice (which tends to lead to errors in my experience).
My java buddy says use this facility: http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
That doesn't, unfortunately, solve the concern Mark states above. What we'd like to have is capability to say Assert((5 + 6 + 7) == 18); and have that output the parameters in string form and as computed values as well. You can do something like that pretty easily with lisp, but not with java. ;)
On 5/6/2010 11:18 AM, Ville Voutilainen wrote:
That doesn't, unfortunately, solve the concern Mark states above. What we'd like to have is capability to say Assert((5 + 6 + 7) == 18); and have that output the parameters in string form and as computed values as well. You can do something like that pretty easily with lisp, but not with java. ;)
Doesn't AspectJ provide a way to do this? I seem to recall that you can stringify a join point.
Please tell me we aren't going to add AspectJ! I have nothing against AspectJ, I just don't want to insert the additional level of implementation complexity!
Thanks.
Blake McBride
On Thu, May 6, 2010 at 11:24 AM, Brian Mastenbrook brian@mastenbrook.net wrote:
On 5/6/2010 11:18 AM, Ville Voutilainen wrote:
That doesn't, unfortunately, solve the concern Mark states above. What we'd like to have is capability to say Assert((5 + 6 + 7) == 18); and have that output the parameters in string form and as computed values as well. You can do something like that pretty easily with lisp, but not with java. ;)
Doesn't AspectJ provide a way to do this? I seem to recall that you can stringify a join point. -- Brian Mastenbrook brian@mastenbrook.net http://brian.mastenbrook.net/
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 6 May 2010 19:53, Blake McBride blake@mcbride.name wrote:
Please tell me we aren't going to add AspectJ! I have nothing against
Ok, I'll tell you - we are not going to add AspectJ. :)
On Thursday, May 6, 2010, Ville Voutilainen ville.voutilainen@gmail.com wrote:
On 6 May 2010 18:53, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Since Java doesn't have a standard macro facility or a concept like eval, I can't think of an wasy way to output the tested assertion without repeating the string twice (which tends to lead to errors in my experience).
My java buddy says use this facility: http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
That doesn't, unfortunately, solve the concern Mark states above. What we'd like to have is capability to say Assert((5 + 6 + 7) == 18);
well, having a look at the code, that wouldn't be that useful. In many case some Boolean is computed and the assertion tests that Boolean.
I think it needs something more like a formatted message associated with the failure.
-Alan
and have that output the parameters in string form and as computed values as well. You can do something like that pretty easily with lisp, but not with java. ;)
On 6 May 2010 19:32, Alan Ruttenberg alanruttenberg@gmail.com wrote:
That doesn't, unfortunately, solve the concern Mark states above. What we'd like to have is capability to say Assert((5 + 6 + 7) == 18);
well, having a look at the code, that wouldn't be that useful. In many case some Boolean is computed and the assertion tests that Boolean.
With the above example, you could show _how_ the boolean is computed. That assert would print stuff like
"Assertion failed at foobar.java:123: ((5 + 6 + 8) == 18)"
or
"Assertion failed at foobar.java:666: (verifyBlackMagic(1, 2, 3, 4))"
On Thu, May 6, 2010 at 12:39 PM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote:
On 6 May 2010 19:32, Alan Ruttenberg alanruttenberg@gmail.com wrote:
That doesn't, unfortunately, solve the concern Mark states above. What
we'd like
to have is capability to say Assert((5 + 6 + 7) == 18);
well, having a look at the code, that wouldn't be that useful. In many case some Boolean is computed and the assertion tests that Boolean.
With the above example, you could show _how_ the boolean is computed. That assert would print stuff like
"Assertion failed at foobar.java:123: ((5 + 6 + 8) == 18)"
or
"Assertion failed at foobar.java:666: (verifyBlackMagic(1, 2, 3, 4))"
Yes, but I think what's needed is more like:
if (p.host != NIL) { if (p.host instanceof SimpleString) { host = new SimpleString(((SimpleString)p.host).getStringValue()); } else if (p.host instanceof Symbol) { host = p.host; } else if (p.host instanceof Cons) { host = new Cons((Cons)p.host); } else { Debug.assertTrue(false); ==> Debug.fail("Expected pathname host of '"+ p + "' to be a string, symbol, or cons");
-Alan
}
armedbear-devel@common-lisp.net