Thread: [CEDET-devel] java semanticdb backend?
Brought to you by:
zappo
From: <jo...@ve...> - 2007-02-14 22:54:02
|
Inspired by the immense sucess of the ebrowse semanticdb backend, I was thinking it would be interesting to have a look at making a java semanticdb backend(or rather fleshing out the existing one) Im having a little trouble getting started though. My plans is to simply query beanshell for each symbol. Are there any obvious drawbacks with this? -- Joakim Verona http://www.verona.se |
From: Eric M. L. <er...@si...> - 2007-02-15 02:57:36
|
>>> jo...@ve... seems to think that: >Inspired by the immense sucess of the ebrowse semanticdb backend, I >was thinking it would be interesting to have a look at making a java >semanticdb backend(or rather fleshing out the existing one) Huzzah! >Im having a little trouble getting started though. > >My plans is to simply query beanshell for each symbol. >Are there any obvious drawbacks with this? The version of semanticdb-java.el in CEDET/CVS is a skeleton I built for this purpose. This database MUST be an omniscient database, as the return result from `semanticdb-get-tags', which returns all database tags, could be catastrophic in scope. ;) If you know how to implement the stub function `semanticdb-beanshell-search' to find things from the beanshell, then writing all the query functions should be easy. Paul Kinnucan told me that the thing to do is write some Java code that beanshell would load. There would be a function for each query feature semanticdb needs which would System.out lisp code that Emacs would `read' or `eval' into tags. The preferred output could be either function calls to construct tags, or match the semanticdb save files. He has pre-existing code in JDE for writing lisp code. The cool thing about that is you can implement the semanticdb search routines entirely in Java and test them without writing any Emacs Lisp, then worry about getting the semanticdb glue working later. I would be very happy to see this done. I completely re-wrote the original semanticdb with Paul K. just for this project, so I've been kind of sad to see it lapse. Thanks! Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: <jo...@ve...> - 2007-02-15 08:29:18
|
"Eric M. Ludlam" <er...@si...> writes: >>My plans is to simply query beanshell for each symbol. >>Are there any obvious drawbacks with this? > > The version of semanticdb-java.el in CEDET/CVS is a skeleton I built > for this purpose. > > This database MUST be an omniscient database, as the return result > from `semanticdb-get-tags', which returns all database tags, could be > catastrophic in scope. ;) > > If you know how to implement the stub function > `semanticdb-beanshell-search' to find things from the beanshell, then > writing all the query functions should be easy. ok, so what would the arguments to (defun semanticdb-beanshell-search (querytext)) look like? My concern is that the beanshell function wont get enough type information to give reasonable results, but I'll have to look further into it. > Paul Kinnucan told me that the thing to do is write some Java code > that beanshell would load. There would be a function for each query > feature semanticdb needs which would System.out lisp code that Emacs > would `read' or `eval' into tags. The preferred output could be > either function calls to construct tags, or match the semanticdb save > files. He has pre-existing code in JDE for writing lisp code. I think returning lisp structures directly to emacs is the way to go. > The cool thing about that is you can implement the semanticdb search > routines entirely in Java and test them without writing any Emacs > Lisp, then worry about getting the semanticdb glue working later. Yes, so if we can find a syntax for what the queries to the beanshell would look like we would be mostly set. > I would be very happy to see this done. I completely re-wrote the > original semanticdb with Paul K. just for this project, so I've been > kind of sad to see it lapse. I'm deeply motivated by otherwise being forced to accept Eclipse as being better in this regard :| > Thanks! > Eric > -- Joakim Verona |
From: Eric M. L. <er...@si...> - 2007-02-15 12:12:17
|
>>> jo...@ve... seems to think that: >"Eric M. Ludlam" <er...@si...> writes: > >>>My plans is to simply query beanshell for each symbol. >>>Are there any obvious drawbacks with this? >> >> The version of semanticdb-java.el in CEDET/CVS is a skeleton I built >> for this purpose. >> >> This database MUST be an omniscient database, as the return result >> from `semanticdb-get-tags', which returns all database tags, could be >> catastrophic in scope. ;) >> >> If you know how to implement the stub function >> `semanticdb-beanshell-search' to find things from the beanshell, then >> writing all the query functions should be easy. > >ok, so what would the arguments to (defun semanticdb-beanshell-search >(querytext)) look like? > >My concern is that the beanshell function wont get enough type >information to give reasonable results, but I'll have to look further >into it. I dunno. Likely you could fabricate some beanshell (Java) code in Emacs to pass into beanshell. If the Java and semanticdb API were basically the same except for syntax, that would simplify things. >> Paul Kinnucan told me that the thing to do is write some Java code >> that beanshell would load. There would be a function for each query >> feature semanticdb needs which would System.out lisp code that Emacs >> would `read' or `eval' into tags. The preferred output could be >> either function calls to construct tags, or match the semanticdb save >> files. He has pre-existing code in JDE for writing lisp code. > >I think returning lisp structures directly to emacs is the way to go. > > >> The cool thing about that is you can implement the semanticdb search >> routines entirely in Java and test them without writing any Emacs >> Lisp, then worry about getting the semanticdb glue working later. > >Yes, so if we can find a syntax for what the queries to the >beanshell would look like we would be mostly set. > >> I would be very happy to see this done. I completely re-wrote the >> original semanticdb with Paul K. just for this project, so I've been >> kind of sad to see it lapse. > >I'm deeply motivated by otherwise being forced to accept Eclipse as >being better in this regard :| [ ... ] Oi! We can't have that! Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: <jo...@ve...> - 2007-02-15 17:18:51
|
interesting little beanshell snippet: (you need beanshell.el from jde) m-x bsh-run (bsh-eval (oref 'bsh-standalone-bsh the-bsh) " getMethods(classname){ Class c = Class.forName(classname); m = c.getDeclaredMethods(); for (int i = 0; i < m.length; i++) print(m[i].toString()); } " ) (bsh-eval (oref 'bsh-standalone-bsh the-bsh) "getMethods(\"java.util.Stack\");") will return: public synchronized java.lang.Object java.util.Stack.pop() public java.lang.Object java.util.Stack.push(java.lang.Object) public boolean java.util.Stack.empty() public synchronized java.lang.Object java.util.Stack.peek() public synchronized int java.util.Stack.search(java.lang.Object) Almost done, right? (just kidding :) beanshell.el also has interfaces to immediately evaluate elisp that the beanshell method might return. -- Joakim Verona |
From: Suraj A. <sac...@gm...> - 2007-02-15 17:44:48
|
Have you had a look at the helper functions in jde-complete.el? jde-complete-invoke-get-class-info calls jde.util.Completion.getClassInfowhich returns a nice s-expression. You still have to convert it to something semanticdb can digest, but at least you don't have to write any of the java code to compose the sexpr. jde-complete-get-accessible-info is a wrapper around the previous function which caches the results from the call to the java method so you don't have to make a (relatively time-consuming) call to the beanshell each time to get the class info. You could probably either reuse this cache, which is used for completing symbol names in JDE, or just write a similar one. Forgive me for not RTFM, but what will having a java semantic db back-end give us? I maintain the jde-usages plugin for JDE (jde-usages.sf.net) and might be able to help. Suraj On 2/15/07, jo...@ve... <jo...@ve...> wrote: > > > interesting little beanshell snippet: > (you need beanshell.el from jde) > > m-x bsh-run > > (bsh-eval (oref 'bsh-standalone-bsh the-bsh) > " > getMethods(classname){ > Class c = Class.forName(classname); > m = c.getDeclaredMethods(); > for (int i = 0; i < m.length; i++) > print(m[i].toString()); > } > " > ) > > (bsh-eval (oref 'bsh-standalone-bsh the-bsh) > "getMethods(\"java.util.Stack\");") > > will return: > > public synchronized java.lang.Object java.util.Stack.pop() > public java.lang.Object java.util.Stack.push(java.lang.Object) > public boolean java.util.Stack.empty() > public synchronized java.lang.Object java.util.Stack.peek() > public synchronized int java.util.Stack.search(java.lang.Object) > > > Almost done, right? (just kidding :) > > beanshell.el also has interfaces to immediately evaluate elisp that > the beanshell method might return. > > -- > Joakim Verona > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > |
From: Eric M. L. <er...@si...> - 2007-02-15 18:52:02
|
>>> "Suraj Acharya" <sac...@gm...> seems to think that: >Forgive me for not RTFM, but what will having a java semantic db back-end >give us? I maintain the jde-usages plugin for JDE (jde-usages.sf.net) and >might be able to help. Summary: Supporting JDE core functionality (beanshell searching) in Semantic allows JDE tools and UIs to be ported to Semantic, and used in other languages. CEDET attempts to provide for any language the types of things JDE provides for Java. For example, there is something similar to eldoc provided by semantic which, with this Java backend, would provide that feature for any Java system library too. Semantic also has a completion engine, similar to the one provided by JDE. This backend would enable semantic to do that same sort of completion. At the moment, that completion will only work for .java source files currently parsed by semantic. Combining the bits JDE does and what Semantic does would provide completions that were up to date with the source code, not just what was compiled and loaded by beanshell. There have been a couple features pioneered in JDE that have been generalized in Semantic, and later removed from JDE. JDE has a lot of great stuff that could benefit other languages, and semantic provides a sort of generic way to think about what is in the code. Converting JDE parts to generic semantic parts allows tools to be written that might have started in JDE to work across multiple languages. An example with jde-usages would be that, if jde-usages used semantic tags as an internal API, then the user interfaces it provides could be used for C/C++ via cscope. (Note: I don't know anything about jde-usages other than what is on the web page you posted, so I'm guessing.) Does that help? Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Suraj A. <sac...@cs...> - 2007-02-16 00:45:10
|
Hi Eric, Thanks for very detailed reply :-) Some sort of unified eldoc and completion with inputs from both CEDET as well as JDE would indeed be very useful. I started to look at semantic-complete.el but soon got lost, so here are some really basic questions: 1) How would I use semanticdb to find all the methods in class " some.package.ClassName"? My (false) impression has been that semanticdb was designed to only answer questions like "what are all the methods with names starting with 'foo'". I'm sure there is a smart way to restrict your search using an appropriate tag table, but I can't figure out where the code mapping from a java namespace to a tag table would go. 2) Does semantic-complete do some analysis of the tokens before the string being completed to figure out what tag table to use? For example, if I've trying complete the following line in a java-mode buffer: a.b.c.foo Then this should show me tags with names starting with "foo" which are children of the java class that "c" is an instance of. In the JDEE we have some very nasty looking code which analyzes an expression like "a.b.c" and tries to guess what its type is. Is there a mechanism to hook mode specific completion logic into semantic-complete? Suraj On 2/15/07, Eric M. Ludlam <er...@si...> wrote: > > >>> "Suraj Acharya" <sac...@gm...> seems to think that: > >Forgive me for not RTFM, but what will having a java semantic db back-end > >give us? I maintain the jde-usages plugin for JDE (jde-usages.sf.net) and > >might be able to help. > > Summary: > > Supporting JDE core functionality (beanshell searching) in Semantic > allows JDE tools and UIs to be ported to Semantic, and used in > other languages. > > CEDET attempts to provide for any language the types of things JDE > provides for Java. For example, there is something similar to eldoc > provided by semantic which, with this Java backend, would provide that > feature for any Java system library too. > > Semantic also has a completion engine, similar to the one provided by > JDE. This backend would enable semantic to do that same sort of > completion. At the moment, that completion will only work for .java > source files currently parsed by semantic. Combining the bits JDE > does and what Semantic does would provide completions that were up to > date with the source code, not just what was compiled and loaded by > beanshell. > > There have been a couple features pioneered in JDE that have been > generalized in Semantic, and later removed from JDE. JDE has a lot of > great stuff that could benefit other languages, and semantic provides > a sort of generic way to think about what is in the code. Converting > JDE parts to generic semantic parts allows tools to be written that > might have started in JDE to work across multiple languages. > > An example with jde-usages would be that, if jde-usages used semantic > tags as an internal API, then the user interfaces it provides could be > used for C/C++ via cscope. (Note: I don't know anything about > jde-usages other than what is on the web page you posted, so I'm > guessing.) > > Does that help? > Eric > > -- > Eric Ludlam: za...@gn..., > er...@si... > Home: http://www.ludlam.net Siege: www.siege-engine.com > Emacs: http://cedet.sourceforge.net GNU: www.gnu.org > |
From: Eric M. L. <er...@si...> - 2007-02-16 05:45:55
|
>>> "Suraj Acharya" <sac...@cs...> seems to think that: >Hi Eric, > >Thanks for very detailed reply :-) Some sort of unified eldoc and completion >with inputs from both CEDET as well as JDE would indeed be very useful. I >started to look at semantic-complete.el but soon got lost, so here are some >really basic questions: There are a few independent layers to try and understand. At the bottom is a parser generator, and some parsers that produce a list of tags for a particular buffer. Those tag lists are also associated with a database table. Tables are stored in a particular database which is associated with a particular directory and a save file. Some databases generate tags from other sources (like beanshell, if implemented.) As such, these DBs can look just like regular semantic parsed files, just faster. --- ok, that's tag management. Then there is searching. --- semantic-find searches through a tag list for some match by name, return type, class (function, variable) or whatever. semanticdb-find searches through lists of databases for the same. You can either search through all known databases vaguely related to a project, or through a selective subset based on a recursive search of #include/import statements. --- That's searching. For completion: --- semantic-ctxt.el has a few tricks for parsing source code around a point to determine what a completion prefix might be. senator.el is a minor mode, and some if it's features include simple brute force completion, and other features. semantic-analyze.el has the analysis tools that convert a prefix (like a.b.c) into a list of matching tags, analyzes the local context to determine what the type needed is (1st arg of a fcn, assign into a variable, etc.) semantic-complete.el is a rather complex system for managing completions from a system where providing "every" tag you might want is unwise. It has a lot of other crazy features specific to assisting a user narrow down a tag list. It uses several methods for generating completion lists and for assisting in choosing a tag by name, such as tooltips of completion lists, or showing where a tag is defined in a different window so you can see what you are completing. semantic-ia.el has some simple completion routines using semantic-analyze to choose completions. It is basically demos of using semantic-analyze.el semantic-idle.el has fancy eldoc and auto-completion features. semantic-sb.el puts various features of semantic and the analyzer into speedbar. There, hopefully my other answers can be short. ;) >1) How would I use semanticdb to find all the methods in class " >some.package.ClassName"? If `semantic-dependency-tag-file' doesn't resolve your import of some.package.Classname into a particular java file, you would need to override that function for java. At this point, semanticdb-find would add it to a list of tables. If that table/file can't be found, then we would rely on the as yet unwritten beanshell to eventually get a tag representation of some.package.Classname. >My (false) impression has been that semanticdb was designed to only answer >questions like "what are all the methods with names starting with 'foo'". >I'm sure there is a smart way to restrict your search using an appropriate >tag table, but I can't figure out where the code mapping from a java >namespace to a tag table would go. semantic-analyze.el with the help of semantic-ctxt.el will find all C++ 'using' type statements, and add those to various search lists till the desired symbol is found. I'm not that familiar with Java, but you will likely need to override `semantic-ctxt-scoped-types' to get that list. >2) Does semantic-complete do some analysis of the tokens before the string >being completed to figure out what tag table to use? >For example, if I've trying complete the following line in a java-mode >buffer: > >a.b.c.foo It is semantic-ctxt.el's job to convert a.b.c.foo into a prefix, and determine basic state around that statement. semantic-analyze.el's job to resolve the prefix. First it will try to find 'a' in all included scopes. (See above.) In a, it will try to find b, in b, it will try to find c, and in c, it will do a completion search for 'foo' to see what turns up. Lastly, for all possible 'foo' matches, it looks to see what the return value of foo will be used for, and extrapolates the type needed. It then narrows down the list of 'foo's to only those that return a particular type. Thus: int q; q = a.b.c.foo-!- Or: blah(int a, char b); blah(a.b.c.foo-!- it will find a foo of type int and provide only that, or those if there is more than one. >Then this should show me tags with names starting with "foo" which are >children of the java class that "c" is an instance of. >In the JDEE we have some very nasty looking code which analyzes an >expression like "a.b.c" and tries to guess what its type is. Is there a >mechanism to hook mode specific completion logic into semantic-complete? This system in semantic complex, but I think it is relatively well organized. The main problems it has is determining all available scopes in a language independent way, and also making sure the correct databases are searched. Key reasons this stuff doesn't work in java are: * Missing overloads for items that are distinctly not C++ * Missing global database for all those library calls. Hope that helps. I think the barrier to entry on Java successfully using this stuff is relatively small since it is quite similar to C++ in some ways. Eric >Suraj > >On 2/15/07, Eric M. Ludlam <er...@si...> wrote: >> >> >>> "Suraj Acharya" <sac...@gm...> seems to think that: >> >Forgive me for not RTFM, but what will having a java semantic db back-end >> >give us? I maintain the jde-usages plugin for JDE (jde-usages.sf.net) and >> >might be able to help. >> >> Summary: >> >> Supporting JDE core functionality (beanshell searching) in Semantic >> allows JDE tools and UIs to be ported to Semantic, and used in >> other languages. > -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Eric M. L. <er...@si...> - 2007-03-04 14:29:26
|
Hi, >>> jo...@ve... seems to think that: >--=-=-= > >"Eric M. Ludlam" <er...@si...> writes: > >>>>> jo...@ve... seems to think that: >>>"Eric M. Ludlam" <er...@si...> writes: > >I'm working a bit on the semanticdb-java backend but I'm having basic >issues. > >For instance: > >ELISP> (setq D (semanticdb-create-database semanticdb-project-database-java "/some/place")) >*** Eval error *** Symbol's value as variable is void: filename [ ... ] > >;; Create the database, and add it to searchable databases for Java mode. >(defvar-mode-local java-mode semanticdb-project-system-databases > (list > ;; Create a global instance for all Java source files. > (semanticdb-project-database-java "Java")) > "Search Java Class files for for symbols.") The above line creates the database, and adds it to the list of system databases for Java. As such, your line where you attempt to create a new database is not needed. Also, there is no filename associated with it, thus the error. >;; NOTE: Be sure to modify this to the best advantage of your >;; language. >(defvar-mode-local java-mode semanticdb-find-default-throttle > '(project system recursive) > "Search project files, then search this omniscience database. >It is not necessary to do system or recursive searching because of >the omniscience database.") The java DB you are creating is a singleton, so there can be only one DB, and it should be classified as omniscient, so your default throttle should have `omniscience' in the list. I don't code much Java, so you should tune the above list dependent on how import statements and your new DB work. [ ... ] >I dont seem to be able to hook in the backend properly. I remember >having the same issues with the ebrowse backend, but when looking at >the code it seems basically the same. > >I attach my code, which is just the skeleton + some print statements. > > >Anyway, my current plan is to inerface the completion functions in the >JDE to semantic. > >This call returns class info for the StringBuffer class: >(jde-complete-get-classinfo "java.lang.StringBuffer") > >My thinking is I only need to adapt the returned structure to >something semanticdb can understand, and basic completion through >semantic will work. Completion through JDE will of course still >work. I think if you change the throttle to include semanticdb-project-system-databases, and then call `semanticdb-find-test-translate-path' you should see your new DB available. How databases are linked together isn't complicated, but at the same time, it is obscure enough that it confuses me too. Basically there is one big list, and databases and tables are scanned by the path translator for searches. Each DB needs to provide the right info so that the path translation step will accept that database. It's the path translation algorithm that gets a bit difficult to debug. Good Luck Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: <jo...@ve...> - 2007-03-04 22:33:41
|
"Eric M. Ludlam" <er...@si...> writes: >>;; Create the database, and add it to searchable databases for Java mode. >>(defvar-mode-local java-mode semanticdb-project-system-databases >> (list >> ;; Create a global instance for all Java source files. >> (semanticdb-project-database-java "Java")) >> "Search Java Class files for for symbols.") > > The above line creates the database, and adds it to the list of > system databases for Java. As such, your line where you attempt to > create a new database is not needed. Also, there is no filename > associated with it, thus the error. ok, so that seems to fix the error. > I think if you change the throttle to include > semanticdb-project-system-databases, and then call > `semanticdb-find-test-translate-path' you should see your new DB > available. Since the db is omniscient, its not searched by default, so I must do like so: (semanticdb-find-test-translate-path t) (I must first do: (semanticdb-file-table (car semanticdb-project-system-databases) "/tmp") for this to actually work though) Another question: JDE completion is pretty good because with code like: public class tst { public static void main(String[] args) throws Exception { java.lang.StringBuffer x; x.<point here> } } completion only picks up stuff from StringBuffer. How can this be done with cedet? implementing semanticdb-find-tags-external-children-of-type-method doesnt appear to be quite enough, or is it? -- Joakim Verona |
From: Eric M. L. <er...@si...> - 2007-03-05 02:19:49
|
>>> jo...@ve... seems to think that: >"Eric M. Ludlam" <er...@si...> writes: >>>;; Create the database, and add it to searchable databases for Java mode. >>>(defvar-mode-local java-mode semanticdb-project-system-databases >>> (list >>> ;; Create a global instance for all Java source files. >>> (semanticdb-project-database-java "Java")) >>> "Search Java Class files for for symbols.") >> >> The above line creates the database, and adds it to the list of >> system databases for Java. As such, your line where you attempt to >> create a new database is not needed. Also, there is no filename >> associated with it, thus the error. > >ok, so that seems to fix the error. > > >> I think if you change the throttle to include >> semanticdb-project-system-databases, and then call >> `semanticdb-find-test-translate-path' you should see your new DB >> available. > >Since the db is omniscient, its not searched by default, so I >must do like so: > > (semanticdb-find-test-translate-path t) > >(I must first do: > >(semanticdb-file-table (car semanticdb-project-system-databases) >"/tmp") > >for this to actually work though) My apologies for not being clear. You need to set the throttle like this: (defvar-mode-local java-mode semanticdb-find-default-throttle '(project system recursive omniscience) "Search project files, then search this omniscience database. It is not necessary to do system or recursive searching because of the omniscience database.") so it will search it by default. See semanticdb-el for a more complete example. >Another question: > >JDE completion is pretty good because with code like: >public class tst { > public static void main(String[] args) throws Exception { > java.lang.StringBuffer x; > x.<point here> > } >} > >completion only picks up stuff from StringBuffer. > >How can this be done with cedet? > >implementing semanticdb-find-tags-external-children-of-type-method >doesnt appear to be quite enough, or is it? [ ... ] In the above case, "java.lang.StringBuffer" can be resolved in one pass via the database, but semantic-analyze is rigged to resolve individual namespaces such one at a time. At a guess, you may need to override `semantic-ctxt-current-symbol' to return ( "java.lang.StringBuffer" ) instead of ( "java" "lang" "StringBuffer" ). Or perhaps ( "java.lang" "StringBuffer" ). Basically, the logic is very different for Java than C++. To use the DB you are creating, you need things set up one way, but to use the classic DB's for uncompiled sources, you need things set up a different way. The analyzer has a function called `semantic-analyze-find-tag-sequence'. If you turn this into an override method, then the java method might be: (define-mode-local-override semantic-analyze-find-tag-sequence java-mode (... args ...) "blah blah" (let ((match (search-for-tag-with-bsh ...))) (if (not match) semantic-analyze-find-tag-sequence-default match))) You should also probably override `semantic-ctxt-scoped-types' for however Java manages scoping similar to C++ using statements. I suspect once you get bsh working, the next step is to go through the analyzer and start turning various functions into override methods, and likely moving sections into a C/C++ specific set. At the moment, the analyzer and completion engine is really setup just for C/C++, so it would be good to get a second complex language in there. That will make it more usable for future languages. Good Luck Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: <jo...@ve...> - 2007-03-05 08:14:42
|
> My apologies for not being clear. You need to set the throttle like > this: Please dont apologize, its me being dense! > (defvar-mode-local java-mode semanticdb-find-default-throttle > '(project system recursive omniscience) > "Search project files, then search this omniscience database. > It is not necessary to do system or recursive searching because of > the omniscience database.") > > so it will search it by default. See semanticdb-el for a more > complete example. This still doesnt work: ELISP> semanticdb-find-default-throttle (project omniscience system recursive) ELISP> (semanticdb-find-test-translate-path) shows only: /home/joakim/tst.java: 1 tags : #<semanticdb-project-database-file project/> whereas (semanticdb-find-test-translate-path t) shows: /home/joakim/tst.java: 1 tags : #<semanticdb-project-database-file project/> System: table > I suspect once you get bsh working, the next step is to go through the > analyzer and start turning various functions into override methods, > and likely moving sections into a C/C++ specific set. Ok, I will return with more questions when I actually get anywhere. > At the moment, the analyzer and completion engine is really setup just > for C/C++, so it would be good to get a second complex language in > there. That will make it more usable for future languages. I agree. The other languages im currently interested in are Python, Javascript and Ocaml. Python should be very similar to this Java backend in that one would query a backend python process for symbol information(although i suppose it would be hard because with python one would really need to really run the source files to actually know types). Ocaml would maybe be slightly like ebrowse because it uses compiled type files, and also like etags, becase one can generate etag files for ocaml. Wouldnt etag support in semantic be cool? Javascript would be, uhm, weird. I didnt get very far with that. -- Joakim Verona |
From: <jo...@ve...> - 2007-03-06 13:38:08
|
"Eric M. Ludlam" <er...@si...> writes: Im still having basic issues. For insance I have this simple testclass: public class tst { class class_y { int mungo; } class_y x; void mupp(String a){ x.; java.lang.StringBuffer stringbuffervar; stringbuffervar.; } } the parse tree becomes: (semantic-analyze-current-context) [object semantic-analyze-context "context" (189 . 189) (("stringbuffervar" variable (:type "java.lang.StringBuffer") (reparse-symbol field_declaration) [125 164]) "") #'variable (nil) (("tst" type (:typemodifiers ("public") :members (("class_y" type (:members (("mungo" variable (:type "int") (reparse-symbol class_member_declaration) #<overlay from 48 to 58 in tst.java>)) :type "class") (reparse-symbol class_member_declaration) #<overlay from 24 to 64 in tst.java>) ("x" variable (:type "class_y") (reparse-symbol class_member_declaration) #<overlay from 69 to 79 in tst.java>) ("mupp" function (:arguments (("a" variable (:type "String") (reparse-symbol formal_parameters) #<overlay from 94 to 102 in tst.java>)) :type "void") (reparse-symbol class_member_declaration) #<overlay from 84 to 196 in tst.java>)) :type "class") nil #<overlay from 1 to 198 in tst.java>)) (("class_y" type (:members (("mungo" variable (:type "int") (reparse-symbol class_member_declaration) #<overlay from 48 to 58 in tst.java>)) :type "class") (reparse-symbol class_member_declaration) #<overlay from 24 to 64 in tst.java>) ("x" variable (:type "class_y") (reparse-symbol class_member_declaration) #<overlay from 69 to 79 in tst.java>) ("mupp" function (:arguments (("a" variable (:type "String") (reparse-symbol formal_parameters) #<overlay from 94 to 102 in tst.java>)) :type "void") (reparse-symbol class_member_declaration) #<overlay from 84 to 196 in tst.java>)) (("stringbuffervar" variable (:type "java.lang.StringBuffer") (reparse-symbol field_declaration) [125 164])) #<buffer tst.java>] So the parser knows the type of stringbuffervar, that I want to look up later in semanticdb is java.lang.StringBuffer. Thats good and all. Howwever, in (defun semantic-analyze-possible-completions-default ... (prefixtypes (oref a prefixtypes)) does not get set in this case, so later I wind up here: ;; What should I do here? I think this is an error condition. (setq completetexttype nil)) so my question is if prefixtypes should be filled in earlier somewhere, and whos responsible for that, or should it work some other way? >>implementing semanticdb-find-tags-external-children-of-type-method >>doesnt appear to be quite enough, or is it? > [ ... ] > > In the above case, "java.lang.StringBuffer" can be resolved in one > pass via the database, but semantic-analyze is rigged to resolve > individual namespaces such one at a time. > > At a guess, you may need to override `semantic-ctxt-current-symbol' > to return ( "java.lang.StringBuffer" ) instead of ( "java" "lang" > "StringBuffer" ). Or perhaps ( "java.lang" "StringBuffer" ). > > Basically, the logic is very different for Java than C++. To use the > DB you are creating, you need things set up one way, but to use the > classic DB's for uncompiled sources, you need things set up a > different way. > > The analyzer has a function called > `semantic-analyze-find-tag-sequence'. If you turn this into an > override method, then the java method might be: > > (define-mode-local-override semantic-analyze-find-tag-sequence > java-mode (... args ...) > "blah blah" > (let ((match (search-for-tag-with-bsh ...))) > (if (not match) > semantic-analyze-find-tag-sequence-default > match))) > > You should also probably override `semantic-ctxt-scoped-types' for > however Java manages scoping similar to C++ using statements. -- Joakim Verona http://www.verona.se |
From: <jo...@ve...> - 2007-03-05 15:16:18
|
"Eric M. Ludlam" <er...@si...> writes: > I don't have any good thoughts on this yet, but here are some > observations. > > semanticdb-equivalent-mode - See the same fcn in semanticdb-el.el. I > think it would be good to include the 'mode-local' piece. > > In semanticdb-el, there is an override of > `semanticdb-find-translate-path' for. This is to prevent recursion. > In C/C++ loading in a #include implies you also load that file's > #includes. I don't think this is the case in java. I'm not certain > you need this equivalent method, but you should probably remove > 'recursive' from the throttle. > > I should probably figure out why the elisp version needs an override. > The implication is that having 'recursive and 'omniscience in the > throttle at the same time is bad and that seems.. uh, bad. > > I'll investigate on the .el side, but in the meantime, having an > override like that for java-mode will likely help. Im still not really geting very far, but this hack helps a bit: ; just a hack... (define-mode-local-override semanticdb-find-translate-path java-mode (path brutish) "brutish hack" (progn (message "semanticdb-find-translate-path java-mode %s " path) (semanticdb-find-translate-path-default path t); always do brutish search. its a hack. ) ) I still need to do: (semanticdb-file-table (car semanticdb-project-system-databases) "/tmp") in a Java buffer before doing (semanticdb-find-test-translate-path) to get the system object included though. > > Good Luck > Eric > >>>> jo...@ve... seems to think that: >> >>> My apologies for not being clear. You need to set the throttle like >>> this: >> >>Please dont apologize, its me being dense! >> >>> (defvar-mode-local java-mode semanticdb-find-default-throttle >>> '(project system recursive omniscience) >>> "Search project files, then search this omniscience database. >>> It is not necessary to do system or recursive searching because of >>> the omniscience database.") >>> >>> so it will search it by default. See semanticdb-el for a more >>> complete example. >> >> >> >>This still doesnt work: >> >>ELISP> semanticdb-find-default-throttle >>(project omniscience system recursive) >> >>ELISP> (semanticdb-find-test-translate-path) >> >>shows only: >> >>/home/joakim/tst.java: 1 tags : #<semanticdb-project-database-file >>project/> >> >>whereas (semanticdb-find-test-translate-path t) >> >>shows: >> >>/home/joakim/tst.java: 1 tags : #<semanticdb-project-database-file project/> >>System: table >> >> >>> I suspect once you get bsh working, the next step is to go through the >>> analyzer and start turning various functions into override methods, >>> and likely moving sections into a C/C++ specific set. >> >>Ok, I will return with more questions when I actually get anywhere. >> >>> At the moment, the analyzer and completion engine is really setup just >>> for C/C++, so it would be good to get a second complex language in >>> there. That will make it more usable for future languages. >> >>I agree. The other languages im currently interested in are Python, >>Javascript and Ocaml. >> >>Python should be very similar to this Java >>backend in that one would query a backend python process for symbol >>information(although i suppose it would be hard because with python >>one would really need to really run the source files to actually know >>types). >> >>Ocaml would maybe be slightly like ebrowse because it uses >>compiled type files, and also like etags, becase one can generate etag >>files for ocaml. Wouldnt etag support in semantic be cool? >> >>Javascript would be, uhm, weird. I didnt get very far >>with that. >> >> > > -- > Eric Ludlam: za...@gn..., er...@si... > Home: http://www.ludlam.net Siege: www.siege-engine.com > Emacs: http://cedet.sourceforge.net GNU: www.gnu.org -- Joakim Verona http://www.verona.se |
From: Eric M. L. <er...@si...> - 2007-03-07 12:25:32
|
Hi, I ran your example, and the analyzer seems to do doing what you needed without modification, so some of my earlier ruminations were in error. Eventually the analyzer calls (semanticdb-find-tags-by-name name) where name is "java.lang.StringBuffer", and not split up as I had been wondering earlier. So if you can run (semanticdb-find-tags-by-name name) and get what you want, then the analyzer should too. Eric >>> jo...@ve... seems to think that: >"Eric M. Ludlam" <er...@si...> writes: > >Im still having basic issues. > >For insance I have this simple testclass: > >public class tst { > class class_y { > int mungo; > } > class_y x; > void mupp(String a){ > x.; > java.lang.StringBuffer stringbuffervar; > stringbuffervar.; > } >} > >the parse tree becomes: > >(semantic-analyze-current-context) >[object semantic-analyze-context "context" > (189 . 189) > (("stringbuffervar" variable > (:type "java.lang.StringBuffer") > (reparse-symbol field_declaration) > [125 164]) > "") > #'variable > (nil) > (("tst" type > (:typemodifiers > ("public") > :members > (("class_y" type > (:members > (("mungo" variable > (:type "int") > (reparse-symbol class_member_declaration) > #<overlay from 48 to 58 in tst.java>)) > :type "class") > (reparse-symbol class_member_declaration) > #<overlay from 24 to 64 in tst.java>) > ("x" variable > (:type "class_y") > (reparse-symbol class_member_declaration) > #<overlay from 69 to 79 in tst.java>) > ("mupp" function > (:arguments > (("a" variable > (:type "String") > (reparse-symbol formal_parameters) > #<overlay from 94 to 102 in tst.java>)) > :type "void") > (reparse-symbol class_member_declaration) > #<overlay from 84 to 196 in tst.java>)) > :type "class") > nil #<overlay from 1 to 198 in tst.java>)) > (("class_y" type > (:members > (("mungo" variable > (:type "int") > (reparse-symbol class_member_declaration) > #<overlay from 48 to 58 in tst.java>)) > :type "class") > (reparse-symbol class_member_declaration) > #<overlay from 24 to 64 in tst.java>) > ("x" variable > (:type "class_y") > (reparse-symbol class_member_declaration) > #<overlay from 69 to 79 in tst.java>) > ("mupp" function > (:arguments > (("a" variable > (:type "String") > (reparse-symbol formal_parameters) > #<overlay from 94 to 102 in tst.java>)) > :type "void") > (reparse-symbol class_member_declaration) > #<overlay from 84 to 196 in tst.java>)) > (("stringbuffervar" variable > (:type "java.lang.StringBuffer") > (reparse-symbol field_declaration) > [125 164])) > #<buffer tst.java>] > >So the parser knows the type of stringbuffervar, that I want to look >up later in semanticdb is java.lang.StringBuffer. Thats good and all. > >Howwever, in (defun semantic-analyze-possible-completions-default ... > >(prefixtypes (oref a prefixtypes)) does not get set in this case, so >later I wind up here: > > ;; What should I do here? I think this is an error condition. > (setq completetexttype nil)) > >so my question is if prefixtypes should be filled in earlier >somewhere, and whos responsible for that, or should it work some other way? > > > > >>>implementing semanticdb-find-tags-external-children-of-type-method >>>doesnt appear to be quite enough, or is it? >> [ ... ] >> >> In the above case, "java.lang.StringBuffer" can be resolved in one >> pass via the database, but semantic-analyze is rigged to resolve >> individual namespaces such one at a time. >> >> At a guess, you may need to override `semantic-ctxt-current-symbol' >> to return ( "java.lang.StringBuffer" ) instead of ( "java" "lang" >> "StringBuffer" ). Or perhaps ( "java.lang" "StringBuffer" ). >> >> Basically, the logic is very different for Java than C++. To use the >> DB you are creating, you need things set up one way, but to use the >> classic DB's for uncompiled sources, you need things set up a >> different way. >> >> The analyzer has a function called >> `semantic-analyze-find-tag-sequence'. If you turn this into an >> override method, then the java method might be: >> >> (define-mode-local-override semantic-analyze-find-tag-sequence >> java-mode (... args ...) >> "blah blah" >> (let ((match (search-for-tag-with-bsh ...))) >> (if (not match) >> semantic-analyze-find-tag-sequence-default >> match))) >> >> You should also probably override `semantic-ctxt-scoped-types' for >> however Java manages scoping similar to C++ using statements. > |