headers
Berndl, Klaus | 8 Sep 2004 10:17
Picon

Bug in semantic-c.el with define-mode-local-override definitions

Hi guys,

i think i have detected a serious bug in cedet beta3b...

It seems that the mode-local stuff has been completey redesigned between  cedet2b and cedet3b - in
semantic-c.el now the macro define-mode-local-override is used, e.g. for semantic-tag-abstract-p.
Well, this is not  abug but IMHO defining this for c-mode is a bug! Anyway in cedet2b this function works
whereas in cedetbeta3b it doesn't:
If point stays onto a virtual method in a c++-header-file then the following code fails in 3b (in 2b it works):

(semantic-tag-abstract-p (semantic-current-tag) 
                         (semantic-current-tag-parent))

Should this overloads not being defined for c++-mode instead of c-mode - or even better for c-common-mode
if an override should be used for for all c-modes?! maybe the macro define-mode-local-override (and
subsequent stuff from mode-local.el) should be designed to get a list of modes instead exactly one mode?!

Thoughts?

Ciao,
Klaus

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
Permalink | Reply | 0 comments |
headers
David PONCE | 8 Sep 2004 12:01
Picon

Re: Bug in semantic-c.el with define-mode-local-override definitions

Hi Klaus,

> i think i have detected a serious bug in cedet beta3b...
> 
> It seems that the mode-local stuff has been completey redesigned
> between cedet2b and cedet3b - in semantic-c.el now the macro
> define-mode-local-override is used, e.g. for
> semantic-tag-abstract-p. Well, this is not abug but IMHO defining
> this for c-mode is a bug! Anyway in cedet2b this function works
> whereas in cedetbeta3b it doesn't: If point stays onto a virtual
> method in a c++-header-file then the following code fails in 3b (in
> 2b it works):
> 
> (semantic-tag-abstract-p (semantic-current-tag) 
>                          (semantic-current-tag-parent))
> 
> Should this overloads not being defined for c++-mode instead of
> c-mode - or even better for c-common-mode if an override should be
> used for for all c-modes?! maybe the macro
> define-mode-local-override (and subsequent stuff from mode-local.el)
> should be designed to get a list of modes instead exactly one mode?!

AFAIK, c++-mode is considered by semantic as derived from c-mode,
because of the following statement at the end of semantic-c.el:

(define-child-mode c++-mode c-mode
  "`c++-mode' uses the same parser as `c-mode'.")

So the override stuff should work in c++-mode (and it actually works
for me using Emacs 21.3/21.3.50 with cc-mode 5.31, and XEmacs 21.4.15
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berndl, Klaus | 8 Sep 2004 14:02
Picon

RE: Bug in semantic-c.el with define-mode-local-ove rride definitions

Hi david,

ok, point is taken - means seems no bug with defining the overload for
c-mode...

But nevertheless something doesn't work:

here is what is done by semantic-tag-abstract-p-c-mode:

   ((eq (semantic-tag-class tag) 'function)
    (semantic-tag-get-attribute tag :pure-virtual-flag))

Ok, when i put point onto the virtual method "aProctedMethod"
(line 8 in the following short c++-header-file klaus-test.hpp) then
(semantic-tag-attributes (semantic-current-tag)) returns

(:prototype-flag t :typemodifiers ("virtual") :type "void")

You see, there is no attribute :pure-virtual-flag contained in
the plist! So no one can be found and therefore in turn the
abstract-p check fails...

In cedet-beta2b we have the following situation:

(defun semantic-tag-abstract-p (tag &optional parent)
  "Return non nil if TAG is abstract.
Optional PARENT is the parent tag of TAG.
In UML, abstract methods and classes have special meaning and behavior
in how methods are overridden.  In UML, abstract methods are italicized.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David PONCE | 8 Sep 2004 15:00
Picon

Re: Bug in semantic-c.el with define-mode-local-override definitions

Klaus,

> ok, point is taken - means seems no bug with defining the overload for
> c-mode...

Good ;-)

> But nevertheless something doesn't work:
> 
> here is what is done by semantic-tag-abstract-p-c-mode:
> 
>    ((eq (semantic-tag-class tag) 'function)
>     (semantic-tag-get-attribute tag :pure-virtual-flag))
> 
> Ok, when i put point onto the virtual method "aProctedMethod"
> (line 8 in the following short c++-header-file klaus-test.hpp) then
> (semantic-tag-attributes (semantic-current-tag)) returns
> 
> (:prototype-flag t :typemodifiers ("virtual") :type "void")
> 
> You see, there is no attribute :pure-virtual-flag contained in
> the plist! So no one can be found and therefore in turn the
> abstract-p check fails...

I didn't received your klaus-test.hpp sample.  Anyway it looks you're
probably right.  The :pure-virtual-flag is provided by the c.by
grammar rule:

fun-or-proto-end
  : SEMICOLON
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berndl, Klaus | 8 Sep 2004 15:36
Picon

RE: Bug in semantic-c.el with define-mode-local-ove rride definitions

Hi david,

thanks for your prompt help!

> I didn't received your klaus-test.hpp sample.  Anyway it looks you're

ooops, sorry, my fault..but we do not need it anymore, s.b. ;-)

> probably right.  The :pure-virtual-flag is provided by the c.by
> grammar rule:
> 
> fun-or-proto-end
>   : SEMICOLON
>     ( t )
>   | semantic-list
>     ( nil )
>  ;; Here is an anoying feature of C++ pure virtual methods
>   | EQUAL ZERO SEMICOLON
>     ( :pure-virtual-flag )
>   ;
> 
> which seems to check that the function declaration ends with "= 0;" to
> consider it as pure virtual, which looks good for me.

Yes, agree

> 
> IMO, the problem is in the C override of `semantic-tag-abstract-p'
> which doesn't check the virtual modifiers for functions.  Probably it
> should be modified like this:
(Continue reading)

Permalink | Reply | 501 comments |
headers
David Ponce | 8 Sep 2004 19:51
Picon

Re: Bug in semantic-c.el with define-mode-local-override definitions

 > thanks for your prompt help!

You're welcome.

[...]
 >
 > Yes, i have applied this patch and now it works great! Thanks a lot!

I committed it.

[...]
 > BTW: Some time ago i have reported or suggested to add a way to add own
 > stuff to semantic-elisp-use-read - because tools like ECB define also
 > special macros for defining functions etc.. which should also being
 > parsed as normal defuns etc.....
 > Currently i have to open semantic-el.el and add my code to this function
 > and this every time a new cedet release has been released or when i update
 > the CVS-sources... Really annoying... If i remember right you have already
 > suggested a quite smart mechanism how this could be more customizable by
 > other tools........ What's the status of this?

Eric and I got the same idea to use special symbol properties to drive
semantic-elisp-use-read, instead of a hard coded `cond' clause.

Unfortunately we haven't had free time enough yet to work on that :-(

David

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
(Continue reading)

Permalink | Reply | 501 comments |
headers
david.ponce | 6 Sep 2004 14:16
Picon

semantic patch proposal

Hi Eric,

I submit you the following patch to semantic.

The main changes are:

* In the idle scheduler:
 
  The `semantic-idle-core-handler' now ignores non file buffers to
  speedup things.  A more important change is that the
  `semantic-idle-scheduler-function' now activates the core handler
  even if the idle scheduler is not enabled in current buffer.  This
  let a chance to process other idle-enabled buffers during idle time.

* In python support:

  I fixed some minor bugs in the grammar, and implemented
  auto-generation of lexical analyzers when possible.  The main
  changes are in wisent-python.el.  I completely reworked the lexer to
  simplify the code, make it more robust, and more compliant with
  python 2.3 specs.  The new code no more advices the built-in
  `scan-lists'.  IMO, it is better to use semantic overloads to
  implement the missing python-mode overrides, particularly the
  "context" API.

I would greatly appreciate your feedback, and if you don't have
objection I would like to commit these changes.

Thank you so much for your time!
David
(Continue reading)

Permalink | Reply | 0 comments |
headers
eric | 14 Sep 2004 15:51
Gravatar

Where am I?

Hello all.

  On Aug 29th, I moved to a new house.  Naturally, the home network went down for
a while, and all is in disarray.  There is a long list of messages in my queue to
answer from this mailing list.  I don't know when I will have time to answer
them.  Hopefully "soon", but who knows.  If anyone else has a moment to help out
that would be really great. 

  For David.  You're patches look good for what little time I have examined them.
 Feel free to check them in.

  The new house is great.  It has a great range out back where I can launch my
catapults with abandon.  This fall is going to be really really busy for me. 
While the move is over, I have a baby coming in about a month, and two catapults
to prepare for the championships in November.  (See www.siege-engine.com)  I
should be back in action on great new CEDET stuff when the snow flies.

Eric

-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
Permalink | Reply | 0 comments |
headers
David PONCE | 15 Sep 2004 11:41
Picon

Re: Where am I?

Hello Eric,

[...]
>   For David.  You're patches look good for what little time I have
> examined them.  Feel free to check them in.

Thanks!  I committed them.

>   The new house is great.  It has a great range out back where I can
> launch my catapults with abandon.  This fall is going to be really
> really busy for me.  While the move is over, I have a baby coming in
> about a month, and two catapults to prepare for the championships in
> November.  (See www.siege-engine.com) I should be back in action on
> great new CEDET stuff when the snow flies.

I wish you much happiness in your new house, with your new baby
(that's a grand news!).

I hope to have enough time to support CEDET until your return ;-)

Good luck!

Sincerely,
David

-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berndl, Klaus | 18 Sep 2004 13:23
Picon

rewritten semantic-elisp-do-read so it is now smart and driven by symbol-properties!

Hi David,

> Eric and I got the same idea to use special symbol properties to drive
> semantic-elisp-use-read, instead of a hard coded `cond' clause.
> 
> Unfortunately we haven't had free time enough yet to work on that :-(

Well, i have not really much time but in the meanwhile this hard-code
cond is boring me ;-)

So here is a code which gives you a smart and easy to customize 
elisp-parser...just replace the existing semantic-elisp-use-read
with the following code.

Especially read the very detailed docstring of semantic-elisp-set-tagger
where i have tried to explain the new feature as best as possible ;-)
A review would be nice.

----- code begin ------

(defun semantic-elisp-set-tagger (symbol-or-list tag-gen-fcn)
  "Define a tag-generation-function for certain symbols.
SYMBOL-OR-LIST is either a symbol or a list of symbol for which TAG-GEN-FCN is
called to generate an appropriate semantic-tag. This function \"tells\"
semantic how to generate such a tag for a certain symbol, e.g. how to generate
a function-tag when the `defun'-keyword is found in an elisp-sourcebuffer.

TAG-GEN-FCN is either a function or a symbol. If a function use that function
to generate the semantic-tag for SYMBOL-OR-LIST. If a symbol then semantic
first checks if is a function-symbol which has not set an own TAG-GEN-FCN. If
(Continue reading)

Permalink | Reply | 0 comments |

Gmane