<div dir="ltr">If I do (in .eval):<br><br>(let ((*debugger-hook* #'sys::%debugger-hook-function))<br> (/ 1 0))<br><br>I basically get nothing. No java or CL error. And I don't get the "11 nested errors".<br>
<br>Jonathan<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 6:12 PM, Jonathan Fischer Friberg <span dir="ltr"><<a href="mailto:odyssomay@gmail.com" target="_blank">odyssomay@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Threads should not be a problem. I have a thread pool (of one thread), where all evals are executed (had this problem before :) ).<br>
<br>If I do the let version in the repl, I seem to get both an exception and a CL error. Like this:<br>
<br>CL-USER(1): (let ((*debugger-hook* #'sys::%debugger-hook-function)) (/ 1 0))<br>org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp condition: Arithmetic error DIVISION-BY-ZERO signalled.<br> at org.armedbear.lisp.Interpreter$1.execute(Interpreter.java:569)<br>
at org.armedbear.lisp.LispThread.execute(LispThread.java:653)<br> ...stack trace...<br>#<THREAD "interpreter" {5B6ADD}>: Debugger invoked on condition of type ERROR<br> Caught org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp condition: Arithmetic error DIVISION-BY-ZERO signalled..<br>
<br>and I get into the debugger.<br><br>If I use the setf version in the repl, It throws an exception and exits (which I think is the behavior I want).<br><br>If I use setf with .eval, I get:<br>Maximum error depth exceeded (11 nested errors) with 'Arithmetic error DIVISION-BY-ZERO signalled.'.<br>
<br>I have added (/ 1 0) to the eval call, so that happens after eval has been called 11 times. But the exception never reaches my java code.<span class="HOEnZb"><font color="#888888"><br><br>Jonathan<br></font></span></div>
<div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Feb 19, 2013 at 6:03 PM, Alessio Stalla <span dir="ltr"><<a href="mailto:alessiostalla@gmail.com" target="_blank">alessiostalla@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry, to clarify: defparameter is a friend of setf when used like you<br>
did, which is not how it's normally used (defparameter defines a<br>
global dynamic variable and, as a side effect, modifies its value if<br>
it already had one, but you never use it just for its side effect).<br>
You can imagine defparameter as a shorthand for a defvar followed by a<br>
setf.<br>
<div><div><br>
On Tue, Feb 19, 2013 at 6:00 PM, Alessio Stalla <<a href="mailto:alessiostalla@gmail.com" target="_blank">alessiostalla@gmail.com</a>> wrote:<br>
> I don't think the package is the culprit. Your package most probably<br>
> USEs the CL package, or many other things would not work as you'd<br>
> expect.<br>
><br>
> Answering your earlier question, the correct way would be (setf<br>
> *debugger-hook* ...) rather than defparameter, or even better binding<br>
> instead of assigning - (let ((*debugger-hook* ...)) (do-your-stuff)).<br>
><br>
> But I don't think that can make a difference between working and not<br>
> working at all. It is more of a question of good style. Perhaps you're<br>
> not considering thread-local bindings? If you run your<br>
> defparameter/setf form on one thread, but .eval is called on another<br>
> thread (and with a GUI involved, that is very probable), then chances<br>
> are that the code in your .eval call is running in a dynamic<br>
> environment where *debugger-hook* is locally rebound, and thus the<br>
> global binding that you modify with defparameter/setf is shadowed. You<br>
> can detect it by printing the value of *debugger-hook* in an .eval<br>
> call triggered by the GUI. If that is the case, you should make sure<br>
> to assign a new value to *debugger-hook* on the right thread, or,<br>
> better, to use (let ...) as shown above. Let me stress that using LET<br>
> is usually what you want in Lisp, especially when dealing with dynamic<br>
> variables; a good rule of thumb is: avoid SETF and friends<br>
> (defparameter is a friend) unless you're working on local variables.<br>
> Of course, experts know when and how to break the rules :D but if<br>
> you're a beginner, sticking to that style will make things easier to<br>
> understand and debug, once you enter the right mindset.<br>
><br>
> hth,<br>
> Alessio<br>
><br>
> On Tue, Feb 19, 2013 at 5:50 PM, Jonathan Fischer Friberg<br>
> <<a href="mailto:odyssomay@gmail.com" target="_blank">odyssomay@gmail.com</a>> wrote:<br>
>> It might be that I'm in the wrong package. Although the repl is in cl-user,<br>
>> and even if I change to that package the code in the previous mail has no<br>
>> effect.<br>
>><br>
>> Jonathan<br>
>><br>
>><br>
>> On Tue, Feb 19, 2013 at 5:36 PM, Jonathan Fischer Friberg<br>
>> <<a href="mailto:odyssomay@gmail.com" target="_blank">odyssomay@gmail.com</a>> wrote:<br>
>>><br>
>>> I don't know if this is the correct way to do it, but I did:<br>
>>><br>
>>> (defparameter *debugger-hook* #'sys::%debugger-hook-function)<br>
>>><br>
>>> In the repl (from running java -jar abcl.jar), this worked as expected.<br>
>>> However, I can't seem to get it working with the .eval function of my<br>
>>> interpreter instance.<br>
>>><br>
>>> Jonathan<br>
>>><br>
>>><br>
>>> On Tue, Feb 19, 2013 at 5:07 PM, Alessio Stalla <<a href="mailto:alessiostalla@gmail.com" target="_blank">alessiostalla@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Short story: if you call into Lisp using the JSR-223 API, conditions<br>
>>>> are automatically rethrown as Java exceptions.<br>
>>>><br>
>>>> Long story: the way this is implemented is by binding *debugger-hook*<br>
>>>> to an internal, probably undocumented function, that already does what<br>
>>>> you want. It is called sys::%debugger-hook-function.<br>
>>>><br>
>>>> On Tue, Feb 19, 2013 at 4:25 PM, Jonathan Fischer Friberg<br>
>>>> <<a href="mailto:odyssomay@gmail.com" target="_blank">odyssomay@gmail.com</a>> wrote:<br>
>>>> > I should add that a solution from inside CL would also work. I'm using<br>
>>>> > the<br>
>>>> > ABCL eval to execute all code, so maybe I could wrap the call with<br>
>>>> > something<br>
>>>> > like this:<br>
>>>> ><br>
>>>> > (handler-case<br>
>>>> > (... do-stuff ...)<br>
>>>> > (... catch CL-condition + throw java exception ...))<br>
>>>> ><br>
>>>> > I don't know if that would work. Also, my CL skills are not good enough<br>
>>>> > to<br>
>>>> > finish the code above (how do I capture all conditions?), so help would<br>
>>>> > be<br>
>>>> > appreciated.<br>
>>>> ><br>
>>>> > Jonathan<br>
>>>> ><br>
>>>> ><br>
>>>> > On Tue, Feb 19, 2013 at 3:30 PM, Jonathan Fischer Friberg<br>
>>>> > <<a href="mailto:odyssomay@gmail.com" target="_blank">odyssomay@gmail.com</a>> wrote:<br>
>>>> >><br>
>>>> >> Hi again, :)<br>
>>>> >><br>
>>>> >> I'm currently running CL-code from java. The gui is completely<br>
>>>> >> implemented<br>
>>>> >> on the java side. It would be nice if all errors occuring inside abcl<br>
>>>> >> could<br>
>>>> >> be captured from the java side (to be displayed in the gui as an<br>
>>>> >> error). Is<br>
>>>> >> that possible?<br>
>>>> >><br>
>>>> >> Jonathan<br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> > _______________________________________________<br>
>>>> > armedbear-devel mailing list<br>
>>>> > <a href="mailto:armedbear-devel@common-lisp.net" target="_blank">armedbear-devel@common-lisp.net</a><br>
>>>> > <a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel</a><br>
>>>> ><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Some gratuitous spam:<br>
>>>><br>
>>>> <a href="http://ripple-project.org" target="_blank">http://ripple-project.org</a> Ripple, social credit system<br>
>>>> <a href="http://villages.cc" target="_blank">http://villages.cc</a> Villages.cc, Ripple-powered community economy<br>
>>>> <a href="http://common-lisp.net/project/armedbear" target="_blank">http://common-lisp.net/project/armedbear</a> ABCL, Common Lisp on the JVM<br>
>>>> <a href="http://code.google.com/p/tapulli" target="_blank">http://code.google.com/p/tapulli</a> my current open source projects<br>
>>>> <a href="http://www.manydesigns.com/" target="_blank">http://www.manydesigns.com/</a> ManyDesigns Portofino, open source<br>
>>>> model-driven Java web application framework<br>
>>><br>
>>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Some gratuitous spam:<br>
><br>
> <a href="http://ripple-project.org" target="_blank">http://ripple-project.org</a> Ripple, social credit system<br>
> <a href="http://villages.cc" target="_blank">http://villages.cc</a> Villages.cc, Ripple-powered community economy<br>
> <a href="http://common-lisp.net/project/armedbear" target="_blank">http://common-lisp.net/project/armedbear</a> ABCL, Common Lisp on the JVM<br>
> <a href="http://code.google.com/p/tapulli" target="_blank">http://code.google.com/p/tapulli</a> my current open source projects<br>
> <a href="http://www.manydesigns.com/" target="_blank">http://www.manydesigns.com/</a> ManyDesigns Portofino, open source<br>
> model-driven Java web application framework<br>
<br>
<br>
<br>
--<br>
Some gratuitous spam:<br>
<br>
<a href="http://ripple-project.org" target="_blank">http://ripple-project.org</a> Ripple, social credit system<br>
<a href="http://villages.cc" target="_blank">http://villages.cc</a> Villages.cc, Ripple-powered community economy<br>
<a href="http://common-lisp.net/project/armedbear" target="_blank">http://common-lisp.net/project/armedbear</a> ABCL, Common Lisp on the JVM<br>
<a href="http://code.google.com/p/tapulli" target="_blank">http://code.google.com/p/tapulli</a> my current open source projects<br>
<a href="http://www.manydesigns.com/" target="_blank">http://www.manydesigns.com/</a> ManyDesigns Portofino, open source<br>
model-driven Java web application framework<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>