headers
Eric M. Ludlam | 1 May 2010 01:57
Gravatar

Re: Recommendations for new CEDET & JDEE user for a (mostly) Java project

Hi,

CEDET was certainly designed to work cross-language, as it provides a 
single API that works across all languages, with a secondary API for 
working across languages that have basic structure, like javascript or C.

Unfortunately, I'm not a Java or JDEE expert.

The basic strategy is to get an EDE project pointing to the root of all 
your code.  I'm assuming all the languages you mentioned are in one big 
mega-project.  That top level project then needs to know about all the 
targets.  For simplicity sake, you could have one target per language 
type, or more detailed, one target per language/directory.

That sounds good, but no-one has written such a generic project.  If you 
feel adventurous, you could copy ede-emacs.el to your own thing, and 
change ede-emacs-project-root to ede-myproject-project-root and fix the 
directory detection.  The framework for rolling your own is pretty easy 
from there.

If all else fails, you can just use ede-cpp-root, and it will deal with 
your c++ code fine, and provide a simple root-of-project for all the 
cross referencing functions.

As for all your languages, each language has varying levels of support 
based on how much effort the folks who use that language have chosen to 
put into it.  In the JDEE case, they have their own completion system. 
There have been projects to merge CEDET's from-source-only completion 
with JDEEs from-compiled-only parsing, but it has never been finished.
(Continue reading)

Permalink | Reply | 14 comments |
headers
David Ventimiglia | 1 May 2010 02:31
Favicon

Re: Recommendations for new CEDET & JDEE user for a (mostly) Java project

Thanks, Eric.  I've a few, more-specific questions spliced in below.

> The basic strategy is to get an EDE project pointing to the root of
all
> your code.  I'm assuming all the languages you mentioned are in one
big
> mega-project.  That top level project then needs to know about all the
> targets.  For simplicity sake, you could have one target per language
> type, or more detailed, one target per language/directory.

So far, I just started with ede-simple-project, which I created with the
command ede-new while visiting a Java file buried deep in that part of
our source-tree.  This put a file in my $HOME/.ede directory defining
that ede-simple-project.  I also have run GNU Global in my project root.
What do I do now to enable completion, lookup, and cross-references for
symbols?  

> As for the symbol references, you can use any of the different tools
> you
> prefer, or none.  If you try it (once you have an EDE project
> specifying
> the root) with the find/grep solution and it is fast enough, then you
> can consider yourself done.

I made these customizations:

(require 'cedet)
(global-ede-mode 1)
(semanticdb-enable-gnu-global-databases 'java-mode)
(semanticdb-enable-gnu-global-databases 'jde-mode)
(Continue reading)

Permalink | Reply | 13 comments |
headers
Eric M. Ludlam | 2 May 2010 14:46
Gravatar

Re: Recommendations for new CEDET & JDEE user for a (mostly) Java project

On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> Thanks, Eric.  I've a few, more-specific questions spliced in below.
>
>> The basic strategy is to get an EDE project pointing to the root of
> all
>> your code.  I'm assuming all the languages you mentioned are in one
> big
>> mega-project.  That top level project then needs to know about all the
>> targets.  For simplicity sake, you could have one target per language
>> type, or more detailed, one target per language/directory.
>
> So far, I just started with ede-simple-project, which I created with the
> command ede-new while visiting a Java file buried deep in that part of
> our source-tree.  This put a file in my $HOME/.ede directory defining
> that ede-simple-project.  I also have run GNU Global in my project root.
> What do I do now to enable completion, lookup, and cross-references for
> symbols?

Ah, good idea with the simple project.  I'd forgotten about that.

If you look in cedet/common/cedet.info in the node:

(cedet.info)Top:: > GNU Global

It lists all the options for enabling GNU Global in a CEDET project.

>> As for the symbol references, you can use any of the different tools
>> you
>> prefer, or none.  If you try it (once you have an EDE project
>> specifying
(Continue reading)

Permalink | Reply | 12 comments |
headers
Dale Sedivec | 2 May 2010 18:12

Error parsing Python

Greetings,

	I've found a bug in Semantic's parsing of Python code, and I'm
not sure of the best way to fix it.  This two line Python exaqmple
will trip the bug:

def f():
    return (''' ' ''')

	(This defines a function f that returns the string " ' ".  The
"return" is actually unnecessary to trip this bug but makes the
function a little easier for a non-Python programmer to understand.
The parentheses on the second line are necessary to trip the bug,
though superfluous as far as Python is concerned.)

	When I senator-force-refresh that code with debug-on-error and
semantic-lex-debug-analyzers turned on I get an error calling
scan-sexps with point on the left parenthesis on the second line.

	The problem seems to be that:

1. define-lex turns off parse-sexp-lookup-properties (semantic-lex.el
   from HEAD, line 843).
2. wisent-python-forward-line calls (forward-sexp 1) when it's looking
   at a parenthesis (wisent-python.el line 102).
3. python-mode relies on font-lock-syntactic-properties and syntax
   properties (and thus parse-sexp-lookup-properties) to parse
   triple-quoted strings.  (I believe this is the case at least as far
   back as Emacs 22's python.el.  Search for python-quote-syntax.)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric M. Ludlam | 4 May 2010 04:56
Gravatar

Re: Error parsing Python

Hi Dale,

   An interesting find, and thanks for the detailed info about the 
reproduction and location of possible problems.

   The core lex function needs to turn off the syntax placed in text 
properties because some modes, like cc-mode makes some kinds of text 
completely invisible, or to appear unexpectedly to some Emacs commands. 
  Since the lexical analyzer typically depends on features like \\s* for 
searching for certain classes of syntax, having that change randomly is 
bad.

   As far as font lock is concerned, does python depend on font-lock to 
put text properties down before features like forward-sexp to work? 
This would be bad for the wisent parser to depend on, as font-lock is 
turned off during background parsing.

   The best bet is for wisent-python-forward-line to have some sort of 
custom 'forward-sexp', but I can imagine this being rather poor.  MATLAB 
has similar syntax around quotes which prevents it from using partial 
sexp matching.

   If python does not depend on font-lock to add the feature you need, 
then having that single function just re-enable 
parse-sexp-lookup-properties seems like a fine thing to me.

Does that help?  Sorry for not having a straight answer.
Eric

On 05/02/2010 12:12 PM, Dale Sedivec wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rodrigo Canellas | 4 May 2010 13:54
Picon

'goto-definition' and 'goto-declaration'

Hi,

Does anyone know how to execute a 'goto-definition' and
'goto-declaration' implemented in CEDET?

I am using 'semantic-ia-fast-jump', which goes from declaration to
definition correctly, but it does not go the opposite way.

Thanks a lot!

--

-- 
    Rodrigo Canellas

    -----------
    Programador C++ (http://code.google.com/p/tenacitas/)
    Fotógrafo amador (http://photo.net/photos/RodrigoCanellas)

------------------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
David Ventimiglia | 4 May 2010 19:42
Favicon

Re: Recommendations for new CEDET & JDEE user for a (mostly) Java project

Thanks, Eric.  I think it might be working for me.  At least, when I do
semantic-symref on a Java function in my project, I get a buffer with a
list of references.  It's a little slow, however, and I'm wondering if
it's falling back on Grep and not using my Global tags files.  The
command cedet-gnu-global-show-root does show the right project root,
however.  

Question:  is there a way to verify it's using Global and not Grep?  

Thanks!
Best,
David

> -----Original Message-----
> From: Eric M. Ludlam [mailto:eric <at> siege-engine.com]
> Sent: Sunday, May 02, 2010 5:47 AM
> To: David Ventimiglia
> Cc: cedet-semantic <at> lists.sourceforge.net
> Subject: Re: [cedet-semantic] Recommendations for new CEDET & JDEE
user
> for a (mostly) Java project
> 
> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> > Thanks, Eric.  I've a few, more-specific questions spliced in below.
> >
> >> The basic strategy is to get an EDE project pointing to the root of
> > all
> >> your code.  I'm assuming all the languages you mentioned are in one
> > big
> >> mega-project.  That top level project then needs to know about all
(Continue reading)

Permalink | Reply | 11 comments |
headers
D Chiesa | 4 May 2010 17:19
Picon
Favicon

Is there a fn to retrieve instance variables?

Hi, I'm using the Csharp grammar from the contrib directory.

I'd like to know if there's a function to retrieve the instance variables on 
a type.

I've seen semantic-get-local-variables and 
semantic-get-all-local-variables.  Those work just fine, but aren't what I 
want.  What I'd like are in-scope instance variables.

To illustrate, the semantic--buffer-cache for a really simple C# module 
looks like this:

(("System" include nil nil #<overlay from 475 to 488 in a.cs>)
 ("System.Reflection" include nil nil #<overlay from 489 to 513 in a.cs>)
 ("Cheeso.Tools" type
  (:members
   (("Example" type
     (typemodifiers
      ("public")
      :members
      (("flavor" variable
	(:type "int")
	(reparse-symbol class_member_declaration)
	#<overlay from 580 to 595 in a.cs>)
       ("label" variable
	(:type "String")
	(reparse-symbol class_member_declaration)
	#<overlay from 604 to 628 in a.cs>)
       ("Example" function
	(typemodifiers
(Continue reading)

Permalink | Reply | 0 comments |
headers
D Chiesa | 4 May 2010 19:24
Picon
Favicon

semantic-tag-new-*

Hi again,

I'm working on making the Csharp support more usable.

I'm looking at semantic-tag.el .  There's a namespace construct in C#, 
nothing more than a scoping structure, a way to organize classes into a 
hierarchical naming space.  Like Java's package, except the syntax is 
different in C#.  The namespace gets a brace block:
  namespace Foo {
     public class Bar {
         ...
     }
  }

To support that in the parser, I've created a new tag, namespace-tag.

(defsubst semantic-tag-new-namespace (name members &rest attributes)
  "Create a semantic tag of class 'namespace.
NAME is the name of this namespace.
MEMBERS is a list of strings or semantic tags representing the
elements that are contained within the namespace.
ATTRIBUTES is a list of additional attributes belonging to this tag."
  (apply 'semantic-tag name 'namespace
         :members members
         attributes))

This seems to work fine, in the parsing.  But, for some reason, the child 
tags within that tag don't get overlays.  Instead they get vector locations. 
This breaks tag finding stuff, like semantic-get-all-local-variables and so 
on.
(Continue reading)

Permalink | Reply | 1 comment |
headers
D Chiesa | 4 May 2010 17:27
Picon
Favicon

semantic-find-tag-by-class

Am I missing something? 

In the documentation for semantic-brute-find-tag-by-class, it says: 

"Use `semantic-find-tag-by-class' instead."

Does  semantic-find-tag-by-class exist?    I can't find it.  

This is in 1.0pre7.

Thanks,

Dino Chiesa
dpchiesa <at> hotmail.com

------------------------------------------------------------------------------
Permalink | Reply | 0 comments |

Gmane