Re: Bug in semantic-el.el and a nifty new parser for defalias

Hi Klaus,

> The parsing of defstruct fails in some cases.
> 
> The docstring of `defstruct' in GNU Emacs is wrong, because also the
> following is allowed:
> 
> (defstruct tramp-file-name multi-method method user host path)
> 
> So the following (current) parser fails:
> 
[...]
> 
> This parser works:
> 
> (semantic-elisp-setup-form-parser
>     (lambda (form start end)
>       (semantic-tag-new-type
>        (symbol-name (if (consp (nth 1 form))
>                         (car-safe (nth 1 form))
>                       (nth 1 form)))
>        "struct"
>        (semantic-elisp-desymbolify (nthcdr 2 form))
>        (cons nil nil)
>        ))
>   defstruct
>   )
> 
> (see implementation of defstruct to see why this is necessary)

Re: Bug in semantic-el.el and a nifty new parser for defalias

> Finally not duplicating the arglist in the tag will not unnecessarily
> increase the size of the tags database, and should please Eric ;)

I forgot to say that we could enhance the function
`semantic-tag-function-arguments' with your code to extract the
arglist of the aliased function when the :definition attribute is
non-nil.

Eric, any thoughts?

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re[6]: Problem installing cedet-1.0beta3b

Hi,

  There appears to be some sort of speedbar boot up issue that
prevents the "attached" frame (where you start speedbar from) to be
set when we first request the button list.

  I don't know why that is, nor why no other specialty mode cares, but
I have fixed it for the class browser case.  That fix is now in CVS.

Thanks
Eric

>>> Peter Milliken <PeterM <at> resmed.com.au> seems to think that:
>Hi Eric,
>
>This is the error I get if I (a) open a .cpp file, then (b) create a
>speedbar frame (M-x speedbar) and then (c) select Senator->Analyse->Speedbar
>Class Browser:
>
>Debugger entered--Lisp error: (wrong-type-argument (or object-p class-p)
>nil)
>  signal(wrong-type-argument ((or object-p class-p) nil))
>  eieio-oref(nil reference-directory)
>  semanticdb-find-translate-path-brutish-default(nil)
>  semanticdb-find-translate-path-default(nil t)
>  semanticdb-find-translate-path(nil t)
>  semanticdb-find-tags-collector(#[(table tags) "�	\n#,G"(B [table
>class tags semanticdb-find-tags-by-class-method] 4] nil nil t)
>  semanticdb-brute-find-tags-by-class(type)
>  semantic-cb-new-class-browser()

Re[1]: javascript support?

>>> Joakim Verona <joakim <at> verona.se> seems to think that:
>I saw some hinting of some embryonic javascript support for cedet
>somewhere on the list.
>
>Whats the status of this support? Can I help with it somehow?
>I was just about to try my hand at converting an ecmascript bnf to
>wisent when I saw this mention.

Hi,

  I had started getting things together to write a javascript parser.
I was hoping to use the freely available language description and
convert it to wisent, and use it to try out some mixed-mode parsing
of JS embedded in html.

  Then I bought a house, and the wife had a baby, and that's about it.

  Appended find my .wy file which I did not finish.  Much of it is
copied from David's wisent-java-tags.wy.  It includes the full
EMACScript specification and a URL for where I got it.

  While it is probably possible to a straight conversion, getting
semantic tags out of the grammar is a little more complex than just
parsing stuff.

  I thought I had more, but I can't seem to find it right now.
Hopefully this will be a good start.

Eric
-------------------

Re[1]: Suggestions to dframe- and speedbar implementation for first stable cedet-release

Howdy! (and Happy New Year!)

  Aside from having much less free time these days, I don't have much
interest in converting "dframe" to be buffer based instead.  To do so,
I would have to re-write large chunks of ECB for Speedbar, and you
have already done a fine job there.

  In addition, the Emacs team has the task of enabling a "frame" that
attaches to the side of an existing frame.  That would solve all my
speedbar problems with no effort on my part.  Yay!

  I am sympathetic to anything that would let speedbar run in an ECB
managed window in a more convenient way.

  I suspect your suggestion 1 and 2 are the same, but I agree.
Suggestion 3 also sounds like a grand idea.  I would recommend that
you make those changes in speedbar/dframe since you will be able to
test co-incidental ECB changes at the same time.  When you are happy
with them, post a diff to the mailing list, and since you are already
marked as a CEDET developer, you could check them in.

Thanks
Eric

>>> <klaus.berndl <at> sdm.de> seems to think that:
>Hi Eric and all other speedbar/dframe-guys!
>
>I would like to offer you three suggestions concerning
>speedbar/dframe-implementation:
>

Re[2]: Bug in semantic-el.el and a nifty new parser for defalias

>>> David PONCE <david.ponce <at> wanadoo.fr> seems to think that:
>> Finally not duplicating the arglist in the tag will not unnecessarily
>> increase the size of the tags database, and should please Eric ;)
>
>I forgot to say that we could enhance the function
>`semantic-tag-function-arguments' with your code to extract the
>arglist of the aliased function when the :definition attribute is
>non-nil.
>
>Eric, any thoughts?

Hi,

  Fixing defstruct parsing sounds like a good idea.  I'm not surprised
it was broken as I probably never tested it.

  C has something like an alias that you can declare in a "typedef",
and it is a special kind of type which is the type it is aliasing
through the "parent" slot.

  A function being aliased will not always be loaded into Emacs for
the finding so it may be unreliable to attempt any extra extraction.
It may be best to postpone such searching till later for other reasons
as well.  For example with these definitions:

Emacs Lisp:
  (defalias 'newsym 'oldsym "why an alias")
  (defalias 'newsym (lambda (a) "Say what?") "What say?")

C:

AW: Re[1]: Suggestions to dframe- and speedbar implementation for first stable cedet-release

Re: Bug in semantic-el.el and a nifty new parser for defalias

Hi Eric,

> Fixing defstruct parsing sounds like a good idea.  I'm not surprised
> it was broken as I probably never tested it.

OK, I committed the fix.

>   C has something like an alias that you can declare in a "typedef",
> and it is a special kind of type which is the type it is aliasing
> through the "parent" slot.
> 
>   A function being aliased will not always be loaded into Emacs for
> the finding so it may be unreliable to attempt any extra extraction.
> It may be best to postpone such searching till later for other reasons
> as well.  For example with these definitions:
> 
> Emacs Lisp:
>   (defalias 'newsym 'oldsym "why an alias")
>   (defalias 'newsym (lambda (a) "Say what?") "What say?")
> 
> C:
> #define NEWSYM oldsym
> 
>   These ought to be addressed in the same way, though the C one isn't
> captured in the TAG structure yet.  It may be that an "alias" is
> something special to deal with for multiple languages.  For example:
> 
> (semantic-format-tag-summarize ALIAS)
> Alias: ALIAS  ==  SOURCE-OF-ALIAS
> 
>   and the analyzer would then be able to correctly translate anything
> marked as an alias for something else.  This could be
> valuable... depending on the prevalence of aliasing languages.  It
> would certainly make some aspects of the C pre-processor much easier
> to deal with.

Good points Eric!  So what do you think of this definition inspired
from what the C parser produces for typedefs?

(semantic-elisp-setup-form-parser
    (lambda (form start end)
      (let ((alias (nth 1 form)))
        (semantic-tag-new-type
         ;; If not a quoted symbol evaluate the alias expression.
         ;; Signal an error if the alias is not a symbol.
         (symbol-name (if (eq (car alias) 'quote)
                          (cadr alias)
                        (eval alias)))
         "typedef" ;; Indicate an alias
         nil nil
         ;; The following attribute hold the aliased definition.
         :typedef (nth 2 form)
         )))
  defalias
  )

Thanks!

I which you and your family an happy new year.

David

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

RE: Bug in semantic-el.el and a nifty new parser for defalias

First of all a happy new year to all reading this mail!

David PONCE wrote:
> Hi Eric,
> 
>> Fixing defstruct parsing sounds like a good idea.  I'm not surprised
>> it was broken as I probably never tested it.
> 
> OK, I committed the fix.

Please wait a moment, because IMO your latest defstruct parser has a bug
(or at least an annoying behavior, see below). here is a working one:

(semantic-elisp-setup-form-parser
    (lambda (form start end)
      (let ((slots (nthcdr 2 form)))
        ;; Skip doc string if present.
        (and (stringp (car slots))
             (setq slots (cdr slots)))
        (semantic-tag-new-type
         (symbol-name (if (consp (nth 1 form))
                          (car (nth 1 form))
                        (nth 1 form)))
         "struct"
         ;; make tags for the members
         (mapcar (lambda (m)
                   (semantic-tag-new-variable
                    m nil nil))
                 (semantic-elisp-desymbolify (nthcdr 2 form)))
;;          (semantic-elisp-desymbolify slots)
         (cons nil nil)
         )))
  defstruct
  )

Try parsing with your latest version and with my version:

(defstruct tramp-file-name multi-method method user host path)

With your latest version i get a wrong-type-argument error, whereas with
that version above all works fine. tramp-file-name is displayed by ECB
as:

[-] tramp-file-name:struct
 `- [-] [Variables]
     |  host
     |  method
     |  multi-method
     |  path
     `- user

Or can a type have plain string-members???? ....<some tests>.....
Appearantly because speedbar displays such a defstruct correctly...
now i found why i get a wrong-type-argument error... it comes because
currently ECB expects that all children of a semantic-tag to be a
semantic-tags too and therefore calls functions as semantic-bucketize for
the list of childrens of a semantic-tag or semantic-tag-name for a single
children of a tag.... currently these functions fails when called for plain
strings... at least semantic-bucketize fails when calls with a list of
strings instead a list of tags...

Well, now we know the problem, the question is now how to deal with - in my 
opinion there are several possible approaches:
1. Only semantic tags are allowed as childrens (:members) of a semantic-tag
   (e.g. variable-tags for the members of structs (c, c++) or defstructs
   (elisp)
2. ECB (and all other tools using semantic) have to take care that children of 
   a tag are not needed to be semantic-tags too and have to deal suitable with
   them
3. cedet/semantic allows all API-functions dealing with tags to be called also
   with plain strings (or whatever) and return something suitable
   (e.g. (semantic-tag-name "klaus") returns "klaus" and does not fail

I would vote for 1. but admit that i do really see if this would have 
serious drawbacks?! Approach 2. would be a lot of work for tools like ECB.
Approach 3. is - hmm, how to say - also somehow clumsy and ugly.....

What do xou think??

> 
>>   C has something like an alias that you can declare in a "typedef",
>> and it is a special kind of type which is the type it is aliasing
>> through the "parent" slot. 
>> 
>>   A function being aliased will not always be loaded into Emacs for
>> the finding so it may be unreliable to attempt any extra extraction.
>> It may be best to postpone such searching till later for other
>> reasons as well.  For example with these definitions:
>> 
>> Emacs Lisp:
>>   (defalias 'newsym 'oldsym "why an alias")
>>   (defalias 'newsym (lambda (a) "Say what?") "What say?")
>> 
>> C:
>> #define NEWSYM oldsym
>> 
>>   These ought to be addressed in the same way, though the C one isn't
>> captured in the TAG structure yet.  It may be that an "alias" is
>> something special to deal with for multiple languages.  For example:
>> 
>> (semantic-format-tag-summarize ALIAS)
>> Alias: ALIAS  ==  SOURCE-OF-ALIAS
>> 
>>   and the analyzer would then be able to correctly translate anything
>> marked as an alias for something else.  This could be
>> valuable... depending on the prevalence of aliasing languages.  It
>> would certainly make some aspects of the C pre-processor much easier
>> to deal with.
> 
> Good points Eric!  So what do you think of this definition inspired
> from what the C parser produces for typedefs?
> 
> (semantic-elisp-setup-form-parser
>     (lambda (form start end)
>       (let ((alias (nth 1 form)))
>         (semantic-tag-new-type
>          ;; If not a quoted symbol evaluate the alias expression.
>          ;; Signal an error if the alias is not a symbol.
>          (symbol-name (if (eq (car alias) 'quote)
>                           (cadr alias)
>                         (eval alias)))
>          "typedef" ;; Indicate an alias
>          nil nil
>          ;; The following attribute hold the aliased definition.
>          :typedef (nth 2 form)
>          )))
>   defalias
>   )

well, i have tried this parser and then i get the following ECB-display of an
defalias (excerpt of the methods-browser of ECB:

[+] [Requires]
ecb-delete-window-ecb-windows-left-right:typedef
ecb-toggle-enlarged-compilation-window:typedef
[+] [Variables]
(balance-windows around ecb)
(compilation-set-window-height around ecb)

Here is the speedbar display:

[-] ecb-layout.el #
 {-} Types
   => delete-window-ecb-windows-left-right{}
   => toggle-enlarged-compilation-window{}
 {+} Variables
 {+} Defuns
 {+} Requires
 {+} Misc

Well, i understand Eric's points and i agree in some aspects but nevertheless
i found this display of a defalias not really satisfying - for a defvaralias
it makes more sense - but IMHO a defalias is NOT a type but just another name
for a function (refernces in C++ are also just other names!)

IMO a defalias should ba parsed as something like a function ans a defvaralias
as something like a variable because exactly these they are. Both of them are
not types!

Ciao,
Klaus

> Thanks!
> 
> I which you and your family an happy new year.
> 
> David

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re[2]: Bug in semantic-el.el and a nifty new parser for defalias

>>> <klaus.berndl <at> sdm.de> seems to think that:
  [ ... ]
>Or can a type have plain string-members???? ....<some tests>.....
>Appearantly because speedbar displays such a defstruct correctly...
>now i found why i get a wrong-type-argument error... it comes because
>currently ECB expects that all children of a semantic-tag to be a
>semantic-tags too and therefore calls functions as semantic-bucketize for
>the list of childrens of a semantic-tag or semantic-tag-name for a single
>children of a tag.... currently these functions fails when called for plain
>strings... at least semantic-bucketize fails when calls with a list of
>strings instead a list of tags...
>
>Well, now we know the problem, the question is now how to deal with - in my 
>opinion there are several possible approaches:
>1. Only semantic tags are allowed as childrens (:members) of a semantic-tag
>   (e.g. variable-tags for the members of structs (c, c++) or defstructs
>   (elisp)
>2. ECB (and all other tools using semantic) have to take care that children of 
>   a tag are not needed to be semantic-tags too and have to deal suitable with
>   them
>3. cedet/semantic allows all API-functions dealing with tags to be called also
>   with plain strings (or whatever) and return something suitable
>   (e.g. (semantic-tag-name "klaus") returns "klaus" and does not fail
> 
>I would vote for 1. but admit that i do really see if this would have 
>serious drawbacks?! Approach 2. would be a lot of work for tools like ECB.
>Approach 3. is - hmm, how to say - also somehow clumsy and ugly.....
>
>What do xou think??

Hi,

  Plain strings have been allowable children since the first parsers I
wrote.  The reason was that if a language only provided a name and
nothing else worth storing, then why store it?  A classic example are
function arguments in Lisp.  When all you have is:

 (defun myfunc (a)
   "...")

Why store ("a" 'variable nil nil ...) when "a" is just as useful?

Admittedly, this had to be special cased throughout different parts
of semantic and was a source of bugs.  It may be time to retire this
idea.

However, you could use the function
`semantic-tag-components-with-overlays' to restrict what you get to
only semantic tags.

In most cases I handled this case generically such that most of the
routines (semantic-format, speedbar, imenu, etc) would know how to
deal with both types.  In speedbar, it is already important to
differentiate between tags with and without overlays so it can
determine if a name is clickable.  It isn't much of a stretch to go
one more.

Perhaps a couple more options are: 
  * Add a function `semantic-tag-components-as-tags' that converts
    any strings to tags.
  * Have `semantic-tag-components' convert any strings to tags.
    (though this would cause problems with code that modifies
     lists of components in place.)

At this point, my only resistance to #1 is that the datastructures
would get bigger, and I'm feeling a bit lazy of late. ;)

  [ ... ]
>> Good points Eric!  So what do you think of this definition inspired
>> from what the C parser produces for typedefs?
>> 
>> (semantic-elisp-setup-form-parser
>>     (lambda (form start end)
>>       (let ((alias (nth 1 form)))
>>         (semantic-tag-new-type
>>          ;; If not a quoted symbol evaluate the alias expression.
>>          ;; Signal an error if the alias is not a symbol.
>>          (symbol-name (if (eq (car alias) 'quote)
>>                           (cadr alias)
>>                         (eval alias)))
>>          "typedef" ;; Indicate an alias
>>          nil nil
>>          ;; The following attribute hold the aliased definition.
>>          :typedef (nth 2 form)
>>          )))
>>   defalias
>>   )
>
>well, i have tried this parser and then i get the following ECB-display of an
>defalias (excerpt of the methods-browser of ECB:
  [ ... ]
>Well, i understand Eric's points and i agree in some aspects but nevertheless
>i found this display of a defalias not really satisfying - for a defvaralias
>it makes more sense - but IMHO a defalias is NOT a type but just another name
>for a function (refernces in C++ are also just other names!)
>
>IMO a defalias should ba parsed as something like a function ans a defvaralias
>as something like a variable because exactly these they are. Both of them are
  [ ... ]

Hopefully my previous email in response to David explains better what
I was thinking.

Thanks!
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

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt