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