Under which circumstances setting *BREAK-ON-SIGNALS* may not cause a
debugger to be entered when the appropriate condition is raised?
I thought that setting *BREAK-ON-SIGNALS* to, for example, CONDITION
will unconditionally cause any (WARN "Something") to enter a debugger.
It works that way when I do in REPL (Lisp listener)
cl-user(1): (setq *break-on-signals* 'condition)
condition
cl-user(2): (warn "Something")
Break: Something
break entered because of *break-on-signals*.
Restart actions (select using :continue):
0: return from break.
1: skip warning.
2: continue processing.
3: Return to Top Level (an "abort" restart).
4: Abort entirely from this (lisp) process.
[1c] cl-user(13):
However, setting *BREAK-ON-SIGNALS* seems doesn't affect the compiled
code. It is rather inexact expression. I have a project which I
ASDF:LOAD-OP, this project has a call to WARN, and when after loading
the project I set *BREAK-ON-SIGNALS* to CONDITION I still get just a
warning when WARN is called, no break at all.
Am I missed something about how setting *BREAK-ON-SIGNALS* works?
Using ACL80
--
Vladimir Zolotykh
Hi,
> Am I missed something about how setting *BREAK-ON-SIGNALS* works?
Nope, it seems that your understanding of *break-on-signals* is fine,
the problem (at a guess) is that warn is getting called at a
different time than what you expect.
Do you have a small test case that illustrates the problem?
ie. a small file that when compiled ignores *break-on-signals*
Cheers,
Sean.
On 4 May 2006 02:41:15 -0700
"sross" <······@gmail.com> wrote:
> Do you have a small test case that illustrates the problem?
> ie. a small file that when compiled ignores *break-on-signals*
The application in question is a CLIM application. The one thing I've
already discovered:
(setq *break-on-signals* 'simple-warning)
(find-application-frame 'sid :create :force)
---> No break <---
(make-application-frame 'sid)
(let ((*break-on-signals* 'simple-warning)) (run-frame-top-level *))
Break: Xt:
Name: xmScrollBar
Class: XmScrollBar
The specified scrollbar value is greater than the maximum
scrollbar value minus the scrollbar slider size.
break entered because of *break-on-signals*.
May be now you'll see my problems in composing "test case". Knowing
next to nothing (at present) about FIND-APPLICATION-FRAME (I mean what
it does inside) it is difficult for me to decise what should be in the
"test case".
--
Vladimir Zolotykh
The two examples seem to be doing different things...
I'm guessing (I'm not on my own machine right now) that
(find-application-frame 'sid :create :force) will either
find an existing frame of class 'sid or call make-application-frame.
The code which actually signals the warning is the call to
run-frame-top-level so theoretically the following code should
also cause a break.
(setf *break-on-signals* 'simple-warning)
(run-frame-top-level (find-application-frame 'sid :create :force))
Cheers,
Sean.
On 5 May 2006 04:41:49 -0700
"sross" <······@gmail.com> wrote:
> The two examples seem to be doing different things...
>
> I'm guessing (I'm not on my own machine right now) that
> (find-application-frame 'sid :create :force) will either
> find an existing frame of class 'sid or call make-application-frame.
> The code which actually signals the warning is the call to
> run-frame-top-level so theoretically the following code should
> also cause a break.
>
> (setf *break-on-signals* 'simple-warning)
> (run-frame-top-level (find-application-frame 'sid :create :force))
You're quite right
(setf *break-on-signals* 'simple-warning)
(run-frame-top-level (make-application-frame 'sid :create :force))
causes a break.
(find-application-frame 'sid :own-process nil)
also breaks and the last one gives the solution of my little problem.
FIND-APPLICATION-FRAME actually uses MP:PROCESS-RUN-FUNCTION.
(defun foo ()
(warn "Something"))
(defun test-2 ()
(let ((*break-on-signals* 'simple-warning))
(mp:process-run-function "foo" #'foo)))
TEST-2 doesn't break.
(defun test-3 ()
(let ((*break-on-signals* 'simple-warning))
(mp:process-run-function
(list
:name "foo"
:initial-bindings `((*break-on-signals* . ',*break-on-signals*)))
#'foo)))
TEST-3 happily causes a break.
What I still don't understand is why TEST-4
(defun test-4 ()
(let ((*break-on-signals* 'simple-warning))
(mp:process-run-function
(list
:name "foo"
:initial-bindings `(,@excl:*cl-default-special-bindings*))
#'foo)))
isn't equivalent to TEST-3. EXCL:*CL-DEFAULT-SPECIAL-BINDINGS*
contains *BREAK-ON-SIGNALS* and according to ACL Doc (Multiprocessing,
section 4.0 Processes and their dynamic environments)
(process-run-function
`(:name ...
:initial-bindings
((*readtable* . ',*readtable*)
,@excl:*cl-default-special-bindings*))
...)
I'd think that TEST-4 shall cause a break as well as TEST-3. But in
reality it doesn't. I took a glance at
EXCL:*CL-DEFAULT-SPECIAL-BINDINGS* (I've included it in the end) and
realized that I don't understand at all how
EXCL:*CL-DEFAULT-SPECIAL-BINDINGS*, being used as as proposed in
Multiprocessing doc, might be usefull in the sence of obtaining in the
new ("child") process the same value of *BREAK-ON-SIGNALS* as it was
in the parent process. Would you mind throwing a little light on this?
--
Vladimir Zolotykh
cl-user(303): (pprint excl:*cl-default-special-bindings*)
((inspect::*inspector-hook* . inspect::*inspector-hook*) (excl.scm::*ed-hook* . excl.scm::*ed-hook*)
(*print-pprint-dispatch*
. #S(excl::pprint-dispatch-struct :conses-with-cars #<eq hash-table with 73 entries @ #x7112b96a>
:structures #<equal hash-table with 0 entries @ #x7112b992>
:others (#S(excl::entry :test #<Function function-call-p>
:fn #<Function alternative-fn-call>
:full-spec ((-5) (satisfies excl::function-call-p)))
#S(excl::entry :test #<Function consp>
:fn #<Function pprint-fill-no-annotation>
:full-spec ((-10) cons))
#S(excl::entry :test #<Function always-true>
:fn #<Function default-use-print-object>
:full-spec ((-10) t)))))
(excl::*break-on-warnings* . excl::*break-on-warnings*) (*break-on-signals* . *break-on-signals*) (*random-state* make-random-state nil)
(excl::*case-translation* if (eq *current-case-mode* :case-insensitive-upper) :common :local) (*package* find-package :user) (*print-lines*)
(*print-miser-width* . 40) (*print-right-margin*) (*print-readably*) (*print-gensym* . t) (*print-array* . t) (*print-case* quote :upcase)
(*print-circle*) (*print-length*) (*print-level*) (*print-radix*) (*print-base* . 10)
(*print-pretty* system:global-symbol-value '*print-pretty*) (*print-escape* . t)
(excl::*debug-enclose-printer-errors* . excl::*debug-enclose-printer-errors*) (*enclose-printer-errors* . *enclose-printer-errors*)
(*print-nickname* . *print-nickname*) (*read-base* . 10) (*read-default-float-format* quote single-float))
cl-user(304):
According to the franz multiprocessing docs you have to
explicitly supply new values for initial-bindings otherwise
everything is evaluated in the dynamic environment of the
new process (so you lose the binding you created)
This requires you to do
(mp:process-run-function
(list
:name "foo"
:initial-bindings `((*break-on-signals* . ',*break-on-signals*))
,@excl:*cl-default-special-bindings*))))
Cheers,
Sean.
On 5 May 2006 09:51:44 -0700
"sross" <······@gmail.com> wrote:
> According to the franz multiprocessing docs you have to
> explicitly supply new values for initial-bindings otherwise
> everything is evaluated in the dynamic environment of the
> new process (so you lose the binding you created)
>
> This requires you to do
> (mp:process-run-function
> (list
> :name "foo"
> :initial-bindings `((*break-on-signals* . ',*break-on-signals*))
> ,@excl:*cl-default-special-bindings*))))
The another solution might be to use TPL:SETQ-DEFAULT
cl-user(1): (defun bar ()
(mp:process-run-function
`(:name "foo"
:initial-bindings (,@excl:*cl-default-special-bindings*))
#'(lambda () (format t "~&*break-on-signals* = ~S~%" *break-on-signals*))))
bar
cl-user(2): (bar)
#<multiprocessing:process foo(3) @ #x715fb5ea>
cl-user(3):
*break-on-signals* = nil
cl-user(6): (tpl:setq-default *break-on-signals* 'simple-warning)
simple-warning
cl-user(7): (sys:global-symbol-value '*break-on-signals*)
simple-warning
t
cl-user(8): (bar)
#<multiprocessing:process foo(3) @ #x715fe49a>
cl-user(9):
*break-on-signals* = simple-warning
cl-user(9):
I must confess that I knew nothing about these "global values" and
that is why it was so difficult for me to catch the meaning of the
(*break-on-signals* . *break-on-signals*) pair and like in the
excl:*cl-default-special-bindings*. The CDR of the pair is the "global
value" and the CAR is the value in the sense of CL:BOUNDP. Mistakenly
thinking that both were in CL:BOUNDP sense I couldn't make neither
head nor tail of it.
--
Vladimir Zolotykh