guile-debugging and breakpoints

guile-debugging and breakpoints

[Volkan YAZICI]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

Hi,

[I've some questions about guile-debugging package and because of I
couldn't find a suitable place to ask, I decided to post them in here.
I hope it's ok.]

While executing an s-exp with some breakpoints, everything goes
fine. But after I finish the execution and want to re-execute the code
with same breakpoints, this time gds just returns the result. It doesn't
pop-up a stack window for stepping as it did previously. Has anybody
ever experienced a similar problem? How can I fix this?

BTW, I think, requirement of a region to set/delete a breakpoint is
quite inconvenient. Therefore I've written two small emacs functions
which sets/deletes the breakpoint in the backward-up-list. (At least
it's better than manually searching with (search-forwards "(") as
current guile-debugging does.) I attached them with the post, in case of
anybody would be interested in.

guile-debugging is an awesome project. I hope its development won't stop
and be as stable/functional as guile.


Regards.

[-- Attachment #2: gds-scheme-extras.el --]
[-- Type: text/plain, Size: 855 bytes --]

(defun my-gds-set-breakpoint ()
  "Create a new GDS breakpoint at point."
  (interactive)
  (save-excursion
    ;; Find the beginning of the current s-exp. (BACKWARD-UP-LIST will
    ;; raise an error for us in case of it couldn't find a valid upper
    ;; s-exp.)
    (backward-up-list)
    (or (gds-breakpoint-overlays-at (point)) ; Do we already have one?
	;; Mark the position and save to breakpoints file.
	(and (gds-make-breakpoint-overlay
	      (list gds-default-breakpoint-type
		    'at
		    buffer-file-name
		    (gds-line-and-column (point))))
	     (gds-write-breakpoints-file)))))

(defun my-gds-delete-breakpoint ()
  "Delete the GDS breakpoint set at point."
  (interactive)
  (save-excursion
    (forward-char)
    (backward-up-list)
    (if (gds-breakpoint-overlays-at (point))
	(call-interactively (function gds-delete-breakpoint)))))

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging and breakpoints

[Neil Jerram]

Volkan YAZICI <yazicivo@ttnet.net.tr> writes:

> Hi,

Hi, and sorry for taking so long to respond to your emails about
guile-debugging.

> [I've some questions about guile-debugging package and because of I
> couldn't find a suitable place to ask, I decided to post them in here.
> I hope it's ok.]

Here is fine, because (i) there isn't a more specific list for
guile-debugging (ii) guile-debugging is planned to become part of core
Guile (iii) it is likely to be of interest to Guile users in general.

> While executing an s-exp with some breakpoints, everything goes
> fine. But after I finish the execution and want to re-execute the code
> with same breakpoints, this time gds just returns the result. It doesn't
> pop-up a stack window for stepping as it did previously. Has anybody
> ever experienced a similar problem? How can I fix this?

No, I haven't experienced this.  Can you provide more details so I can
try to reproduce it?

> BTW, I think, requirement of a region to set/delete a breakpoint is
> quite inconvenient. Therefore I've written two small emacs functions
> which sets/deletes the breakpoint in the backward-up-list. (At least
> it's better than manually searching with (search-forwards "(") as
> current guile-debugging does.) I attached them with the post, in case of
> anybody would be interested in.

Thanks, I'll take a look at the patch.  Conceptually, however, the
issue is how this would interact with the existing behaviour of C-x
SPC when there is no region, namely to set a breakpoint on the
procedure whose definition contains point.  Do you have any suggestion
for that?

> guile-debugging is an awesome project. I hope its development won't stop
> and be as stable/functional as guile.

Thanks; it's an ongoing project, as far as I'm concerned.

Regards,
     Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging and breakpoints

[Volkan YAZICI]

Hi,

[Excuse me for the late reply. I was quite busy with setting up the
furnitures and just found chance to put my computer on a suitable
table.]

On Dec 29 02:29, Neil Jerram wrote:
> Volkan YAZICI <yazicivo@ttnet.net.tr> writes:
> > While executing an s-exp with some breakpoints, everything goes
> > fine. But after I finish the execution and want to re-execute the code
> > with same breakpoints, this time gds just returns the result. It doesn't
> > pop-up a stack window for stepping as it did previously. Has anybody
> > ever experienced a similar problem? How can I fix this?
> 
> No, I haven't experienced this.  Can you provide more details so I can
> try to reproduce it?

Here are the steps to reproduce the same unexpected behaviour:

Installation Steps:
-------------------
  cd guile-debugging-0.15
  ./configure --prefix=/opt && make && make install
  mkdir ~/.emacs.d/gds
  cp emacs/*.el ~/.emacs.d/gds/
  cat >>~/.emacs <<EOF
;;; GDS (Guile Debugging Server)
(add-to-list 'load-path "~/.emacs.d/gds")
(setq gds-scheme-directory "/opt/share/guile")
(require 'gds)
EOF

Triggering Exception:
---------------------
Step 0: Opened below Scheme file:
        (define (cons-rat a b)
	  (* (expt 2 a)
	     (expt 3 b)))

	(define (expt-power n m k)
	  (if (not (= 0 (remainder n m))) k
	      (expt-power (/ n m) m (+ k 1))))

	(define (car-rat n)
	  (expt-power n 2 0))

	(define (cdr-rat n)
	  (expt-power n 3 0))

	(car-rat (cons-rat 5 7))

Step 1: Placed a breakpoint in `(if...' of `expt-power' definition.
Step 2: Selected whole file and executed the region. (C-c C-r)
Step 3: Everything worked fine and I stepped with `o' and `g' keys
        till I see the return value.
Step 4: I tried to re-execute the `(car-rat (cons-rat 5 7))' s-exp but
        this time it just outputed the result. (No stepping this
	time.) Furthermore, when I place a new breakpoint and executed
	a new s-exp that triggers the newly set breakpoint, it again
	just dumped the result. No stepping.

> > BTW, I think, requirement of a region to set/delete a breakpoint is
> > quite inconvenient. Therefore I've written two small emacs functions
> > which sets/deletes the breakpoint in the backward-up-list. (At least
> > it's better than manually searching with (search-forwards "(") as
> > current guile-debugging does.) I attached them with the post, in case of
> > anybody would be interested in.
> 
> Thanks, I'll take a look at the patch.  Conceptually, however, the
> issue is how this would interact with the existing behaviour of C-x
> SPC when there is no region, namely to set a breakpoint on the
> procedure whose definition contains point.  Do you have any suggestion
> for that?

I don't think there's any use case for setting many breakpoints in a
region. Because, once user gets stopped in the first breakpoint of the
beginning of a region of breakpoints, he/she can move forward by
stepping. There's no need to stop at the next s-exp. (But this
doesn't mean gds-delete-breakpoints is useless. It's quite feasible to
think somebody removing breakpoints in some region of the code.)
Therefore, I think setting breakpoint manually one by one for every
s-exp is a better choice.

> > guile-debugging is an awesome project. I hope its development won't stop
> > and be as stable/functional as guile.
> 
> Thanks; it's an ongoing project, as far as I'm concerned.

I'm not a much Scheme/Guile (nor Emacs) guru, but I'd be happy to help
you in any subject I can.


Regards.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging and breakpoints

[Neil Jerram]

Volkan YAZICI <yazicivo@ttnet.net.tr> writes:

> Here are the steps to reproduce the same unexpected behaviour: [...]

If this is with Guile 1.6.x, I think the behaviour is caused by losing
source properties when an `if' expression is memoized.  To investigate
this, can you see if the following patch solves the problem?

--- libguile/eval.c	2 Oct 2006 20:22:49 -0000	1.234.2.12
+++ libguile/eval.c	14 Jan 2007 00:54:06 -0000
@@ -544,7 +544,8 @@
 {
   long len = scm_ilength (SCM_CDR (xorig));
   SCM_ASSYNT (len >= 2 && len <= 3, scm_s_expression, "if");
-  return scm_cons (SCM_IM_IF, SCM_CDR (xorig));
+  SCM_SETCAR (xorig, SCM_IM_IF);
+  return xorig;
 }

With Guile 1.8 or CVS, I find that the breakpoint doesn't even work
the first time!  I'm still looking into that.

> Step 4: I tried to re-execute the `(car-rat (cons-rat 5 7))' s-exp but
>         this time it just outputed the result. (No stepping this
> 	time.) Furthermore, when I place a new breakpoint and executed
> 	a new s-exp that triggers the newly set breakpoint, it again
> 	just dumped the result. No stepping.

Where did you place the new breakpoint?

> I don't think there's any use case for setting many breakpoints in a
> region. Because, once user gets stopped in the first breakpoint of the
> beginning of a region of breakpoints, he/she can move forward by
> stepping. There's no need to stop at the next s-exp.

OK, you've persuaded me on this - but I'm not sure it addresses the
whole problem.  I still think it might be useful to be able to set a
breakpoint on a procedure by doing C-x SPC anywhere in the procedure's
definition - which conflicts with your backward-up-list
interpretation.  What do you recommend?

> (But this doesn't mean gds-delete-breakpoints is useless. It's quite
> feasible to think somebody removing breakpoints in some region of
> the code.)  Therefore, I think setting breakpoint manually one by
> one for every s-exp is a better choice.

I agree with on these two points.

Regards,
     Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging and breakpoints

[Volkan YAZICI]

On Jan 14 01:01, Neil Jerram wrote:
> With Guile 1.8 or CVS, I find that the breakpoint doesn't even work
> the first time!  I'm still looking into that.

I use Guile from cvs tip too. And after you asked for "Where did you
place the new breakpoint?" I realized that the problem is with putting
the breakpoint on an IF s-exp. IMHO, more importantly, what are the
available places that we can safely place a breakpoint. For instance,
in (define (foo ...)) or (define foo (lambda ...)) example, where
should I place my breakpoint to make it stop at FOO calls. Maybe some
words about this in the gds-tutorial.txt would be nice.

> > I don't think there's any use case for setting many breakpoints in a
> > region. Because, once user gets stopped in the first breakpoint of the
> > beginning of a region of breakpoints, he/she can move forward by
> > stepping. There's no need to stop at the next s-exp.
> 
> OK, you've persuaded me on this - but I'm not sure it addresses the
> whole problem.  I still think it might be useful to be able to set a
> breakpoint on a procedure by doing C-x SPC anywhere in the procedure's
> definition - which conflicts with your backward-up-list
> interpretation. What do you recommend?

What about defining a new `set' of bindings for placing a breakpoint:

;;; A generic internal method to set a breakpoint.
(define (gds-set-breakpoint type) ...)

;;; Set a breakpoint to the current s-exp cursor is currently in.
;;; Example binding: C-c C-b s
(define (gds-set-breakpoint-on-sexp)
  (gds-set-breakpoint 's-exp))

;;; Set a breakpoint to the outmost DEFINE s-exp.
;;; Example binding: C-c C-b d
(define (gds-set-breakpoint-on-def)
  (gds-set-breakpoint 'def))

BTW, is it possible to handle exceptions in a more fancy way. For
instance:

(define (inc n) (+ n 1))
(inc "str")

;;; Evaluating in current module (guile-user)
EXCEPTION: wrong-type-arg ("+" "Wrong type argument in position ~A:
~S" (1 "str") ("str"))
 => unhandled-exception-in-evaluation

Yes, it's not possible to make GDS understand all of the thrown
exceptions, but at least we should be able to place some hooks for the
known exceptions. (Like in this example, wrong-type-arg exception.)
IMHO, we can at least use OBJECT->STRING to place given arguments into
the error string and print whole information in a more fancy style.

If you agree on this idea, I'm volunteered to prepare a patch for this
if you'd give me an example about how can I place such a hook. (And
this will be the only step to take to make people be able to place
their own fancy-exception-printing handler hooks.)


Regards.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging and breakpoints

[Volkan YAZICI]

Hi,

I think we should support emacs console users too. AFAIK, below lines
just work with emacs under X.

gds-scheme.el:
--------------
406              (define-key map [mouse-1] 'gds-show-last-stack)
407	         (insert "[click here to show error stack]"

As an emacs user who prefers to use emacs under GNU screen, it'd be
better to bind that action to a key too. (It's not very easy to type
M-x gds-show-last-stack everytime.)


Regards.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging and breakpoints

[Neil Jerram]

Volkan YAZICI <yazicivo@ttnet.net.tr> writes:

> Hi,
>
> I think we should support emacs console users too. AFAIK, below lines
> just work with emacs under X.
>
> gds-scheme.el:
> --------------
> 406              (define-key map [mouse-1] 'gds-show-last-stack)
> 407	         (insert "[click here to show error stack]"
>
> As an emacs user who prefers to use emacs under GNU screen, it'd be
> better to bind that action to a key too. (It's not very easy to type
> M-x gds-show-last-stack everytime.)

Good point, thanks.  How about adding two possibilities here?

1. `RET' as a text-property binding within the "[click here to show
   error stack]" text - i.e. same scope as mouse-1.

2. `C-h S' in scheme-mode-map.  This means that `C-h S' will work
   anywhere in both the *Guile Evaluation* buffer and the source code
   buffer.

Regards,
     Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging and breakpoints

[Volkan YAZICI]

On Jan 14 01:30, Neil Jerram wrote:
> Volkan YAZICI <yazicivo@ttnet.net.tr> writes:
> > gds-scheme.el:
> > --------------
> > 406              (define-key map [mouse-1] 'gds-show-last-stack)
> > 407	         (insert "[click here to show error stack]"
> 
> Good point, thanks.  How about adding two possibilities here?
> 
> 1. `RET' as a text-property binding within the "[click here to show
>    error stack]" text - i.e. same scope as mouse-1.
> 
> 2. `C-h S' in scheme-mode-map.  This means that `C-h S' will work
>    anywhere in both the *Guile Evaluation* buffer and the source code
>    buffer.

Both of these features would be nice. Umm... If it is possible, I'd
give my vote to both!


Regards.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging and breakpoints

[Neil Jerram]

Volkan YAZICI <yazicivo@ttnet.net.tr> writes:

> On Jan 14 01:30, Neil Jerram wrote:
>> Volkan YAZICI <yazicivo@ttnet.net.tr> writes:
>> > gds-scheme.el:
>> > --------------
>> > 406              (define-key map [mouse-1] 'gds-show-last-stack)
>> > 407	         (insert "[click here to show error stack]"
>> 
>> Good point, thanks.  How about adding two possibilities here?
>> 
>> 1. `RET' as a text-property binding within the "[click here to show
>>    error stack]" text - i.e. same scope as mouse-1.
>> 
>> 2. `C-h S' in scheme-mode-map.  This means that `C-h S' will work
>>    anywhere in both the *Guile Evaluation* buffer and the source code
>>    buffer.
>
> Both of these features would be nice. Umm... If it is possible, I'd
> give my vote to both!

Doing both is what I meant.  These bindings will be in CVS soon and
then the next guile-debugging release.

Regards,
     Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user