Problem with cedet-edebug...

Hi all,

Just started playing around with cedet more extensively, and ran into a 
problem where edebug breaks when encountering certain data structures 
(alists) and trying to print them.  This is with a very recent CVS 
Emacs on both Mac OS X and GNU/Linux, and cedet-1.0beta3b.

Specifically, if you instrument the following code for edebug-ging, and 
then run the kjc-test-defun function to trigger edebug and just hit 
space at each stop point to move to the next one, you'll eventually run 
into an error that's listed below.

(setq kjc-test '(("foo" . "bar")))

(defun kjc-test-defun ()
   (let ((a kjc-test))
     (car a)))

Wrong type argument: listp, "bar"
error: "Cannot return from the debugger in an error" [4 times]

At this point, edebug has given up, apparently due to it seeing this as 
an internal error.

I'll admit, I find this error pretty strange - I thought that listp 
couldn't actually cause an error if given a non-list argument, but it 
seems to be (or possibly the message I'm seeing is unrelated).  I 
couldn't get a stack trace for some reason - perhaps it's because 
edebug has turned off that stuff as it does its internal update to 
print the result into the minibuffer.

Re: Problem with cedet-edebug...

On Sat, 2 Oct 2004 01:58:45 -0400, Ken Coleman wrote:
> Hi all,
> 
> Just started playing around with cedet more extensively, and ran into a 
> problem where edebug breaks when encountering certain data structures 
> (alists) and trying to print them.  This is with a very recent CVS 
> Emacs on both Mac OS X and GNU/Linux, and cedet-1.0beta3b.
> 
> Specifically, if you instrument the following code for edebug-ging, and 
> then run the kjc-test-defun function to trigger edebug and just hit 
> space at each stop point to move to the next one, you'll eventually run 
> into an error that's listed below.
> 
> (setq kjc-test '(("foo" . "bar")))
> 
> (defun kjc-test-defun ()
>    (let ((a kjc-test))
>      (car a)))
> 
> Wrong type argument: listp, "bar"
> error: "Cannot return from the debugger in an error" [4 times]
> 
> At this point, edebug has given up, apparently due to it seeing this as 
> an internal error.
> 
> I'll admit, I find this error pretty strange - I thought that listp 
> couldn't actually cause an error if given a non-list argument, but it 
> seems to be (or possibly the message I'm seeing is unrelated).  I 
> couldn't get a stack trace for some reason - perhaps it's because 
> edebug has turned off that stuff as it does its internal update to 

Re[1]: Bug in the VC-support of speedbar

>>> "Berndl, Klaus" <klaus.berndl <at> sdm.de> seems to think that:
>Hi Eric,
>
>i have found a small bug in speedbar which probably prevents =
>`speedbar-vc-directory-enable-hook' to work correct or to work at all.
>
>The line
>
>(run-hook-with-args ....)=20
>
>must be
>
>(run-hook-with-arg-until-success ...)
>
>because the docstring of run-hook-with-args says "...it is the best to =
>to depend on the value returned by run-hook-with-args!..."
>
>Otherwise the result of speedbar-vc-check-dir-p is unpredictable for all =
>backends besides CVS, RCS and SCCS...
  [ ... ]

Thanks!  Could you check that in?

Eric

--

-- 
          Eric Ludlam:                 zappo <at> gnu.org, eric <at> siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: Problem with cedet-edebug...

Hi Eric,

[...]
> That sounds familiar.  I suspect it has to do with this patch I had
> made for Paul K. a while back and haven't had time to check in yet.
[...]

I committed your patch:

        * cedet/semantic/semantic-tag.el

        (semantic-tag-p): Return nil if an error occurs.

Thanks!
David

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

cogre diff + questions about linking/unlinking overlays

Hello,

I'm experimenting with the cogre-uml support.

Saving of an autogenerated graph doesnt work, so I made a diff to
enable it.

Saving and loading of an uml graph works a bit with this diff but
there are problems.

A saved and restored graph looses its ability to link with the
original source.

The diff tries to take care of this, by useing the semantic overlay
link/unlink functions. This doesnt work however. At least the
overlays arent saved like #<overlay ...> in the file so it works to
restore the file somewhat with this diff.

Am I using the link/unlink stuff the wrong way?

Cheers,
/Joakim

Re[1]: cogre diff + questions about linking/unlinking overlays

>>> Joakim Verona <joakim <at> verona.se> seems to think that:
>Hello,
>
>I'm experimenting with the cogre-uml support.
>
>Saving of an autogenerated graph doesnt work, so I made a diff to
>enable it.
>
>Saving and loading of an uml graph works a bit with this diff but
>there are problems.
>
>A saved and restored graph looses its ability to link with the
>original source.
>
>The diff tries to take care of this, by useing the semantic overlay
>link/unlink functions. This doesnt work however. At least the
>overlays arent saved like #<overlay ...> in the file so it works to
>restore the file somewhat with this diff.
>
>Am I using the link/unlink stuff the wrong way?

You have the right idea.  Semanticdb uses the same calls as you are
using.

The problem with the -link- functions is that they assume that the
tags are to be linked to the current buffer.  A bit of an oversight
in the API it appears.

The code needed to fix it involves using semanticdb-find calls to
search out tags with those names in the project.  The tags in the

Re: cogre diff + questions about linking/unlinking overlays

"Eric M. Ludlam" <eric <at> siege-engine.com> writes:

>>>> Joakim Verona <joakim <at> verona.se> seems to think that:
> The problem with the -link- functions is that they assume that the
> tags are to be linked to the current buffer.  A bit of an oversight in
> the API it appears.

hmm oki, that probably explains it...

> The code needed to fix it involves using semanticdb-find calls to
> search out tags with those names in the project.  The tags in the
> saved UML nodes would then be completely replaced with the found ones.
> At the time I wrote that code, there was no good way to do this which
> is why I didn't.  I hadn't thought of just re-linking them.

the good thing with that aproach would be that the graph would
assimilate changes in for instance method declarations in the original
source, no? The code could also be used to make a working "refresh"
function I guess, that re-creates the uml graph from changed sources.

> It seems to me that the semantic API needs a way to also save the
> originating file name.  I'll have to think up a way to allow tags to
> be saved/restored by external applications.

A further benefit of that is that it would ease round-trip editing I
guess. For instance, It might be convenient to use the graph to prototype a
number of classes. Each node could have manually entered tags,
including filenames. Then sources could be generated to files, from
the graph. And then sources could be changed and the graph refreshed
and so on...

RE: Re[1]: Bug in the VC-support of speedbar

Eric M. Ludlam wrote:
>>>> "Berndl, Klaus" <klaus.berndl <at> sdm.de> seems to think that: Hi Eric,
>> 
>> i have found a small bug in speedbar which probably prevents =
>> `speedbar-vc-directory-enable-hook' to work correct or to work at
>> all. 
>> 
>> The line
>> 
>> (run-hook-with-args ....)=20
>> 
>> must be
>> 
>> (run-hook-with-arg-until-success ...)
>> 
>> because the docstring of run-hook-with-args says "...it is the best
>> to = to depend on the value returned by run-hook-with-args!..."
>> 
>> Otherwise the result of speedbar-vc-check-dir-p is unpredictable for
>> all = backends besides CVS, RCS and SCCS...
>   [ ... ]
> 
> Thanks!  Could you check that in?

Done.

Ciao,
Klaus

> 

Re[2]: cogre diff + questions about linking/unlinking overlays

>>> Joakim Verona <joakim <at> verona.se> seems to think that:
>"Eric M. Ludlam" <eric <at> siege-engine.com> writes:
>
>>>>> Joakim Verona <joakim <at> verona.se> seems to think that:
>> The problem with the -link- functions is that they assume that the
>> tags are to be linked to the current buffer.  A bit of an oversight in
>> the API it appears.
>
>hmm oki, that probably explains it...
>
>> The code needed to fix it involves using semanticdb-find calls to
>> search out tags with those names in the project.  The tags in the
>> saved UML nodes would then be completely replaced with the found ones.
>> At the time I wrote that code, there was no good way to do this which
>> is why I didn't.  I hadn't thought of just re-linking them.
>
>the good thing with that aproach would be that the graph would
>assimilate changes in for instance method declarations in the original
>source, no? The code could also be used to make a working "refresh"
>function I guess, that re-creates the uml graph from changed sources.

Yup.  A useful feature indeed.

>> It seems to me that the semantic API needs a way to also save the
>> originating file name.  I'll have to think up a way to allow tags to
>> be saved/restored by external applications.
>
>A further benefit of that is that it would ease round-trip editing I
>guess. For instance, It might be convenient to use the graph to prototype a
>number of classes. Each node could have manually entered tags,

Re: cogre diff + questions about linking/unlinking overlays

"Eric M. Ludlam" <eric <at> siege-engine.com> writes:

>>>> Joakim Verona <joakim <at> verona.se> seems to think that:
>>"Eric M. Ludlam" <eric <at> siege-engine.com> writes:
>>
>>>>>> Joakim Verona <joakim <at> verona.se> seems to think that:
>>> The problem with the -link- functions is that they assume that the
>>> tags are to be linked to the current buffer.  A bit of an oversight
>>> in the API it appears.
>>

Ok, I tried to set the current buffer to the buffer containing the
originating class. It works, which is nice, but you have to find the
proper buffer to link to and so on. (which is what you say below)

>>> The code needed to fix it involves using semanticdb-find calls to
>>> search out tags with those names in the project.  The tags in the
>>> saved UML nodes would then be completely replaced with the found
>>> ones.  At the time I wrote that code, there was no good way to do
>>> this which is why I didn't.  I hadn't thought of just re-linking
>>> them.

I'll try this aproach next.

Some wories though:

- In my case I test with a class called x.y.z.Parser, in the file
Parser.java. The "tag name" seems to be only "Parser" though. Why is
this?