I've already figured out the issues - see below. And even more
questions arise :)
On Thu, Jul 12, 2012 at 7:40 AM, Eric M. Ludlam <ericludlam@...> wrote:
> On 07/09/2012 02:57 PM, Vladimir Kazanov wrote:
>>
>> Hello!
>>
>> I am not totally sure where to report Semantic-related issues (maybe
>> those are just questions), so decided to post here. Sorry for probable
>> inconveniences.
>
>
> This is the right place for questions about semantic. cedet-devel is
> another good mailing list with a bent toward extending CEDET.
>
>
>> Anyway, I am studying Semantic possibilities for Java parsing. I plan
>> to implement a mode of mine, extending the grammar where needed. So,
>> following the manual and early commits of malabar-mode (a rather nice
>> Java mode, not supported any more), I copied wisent-java.wy into my
>> project, made a few renames at appropriate places and generated a
>> parser (wisent-vk-java-wy.el). So good so far.
>>
>> Code from vk-java-mode.el follows:
>>
>> (require 'semantic-load)
>> (require 'wisent-vk-java-wy)
>> (require 'vk-java-eassist) ;; Toying with an app from cedet/contrib
>>
>> (define-derived-mode vk-java-mode java-mode "VK"
>> "VK Java mode"
>> (vk-semantic-setup))
>>
>> (defun vk-semantic-setup ()
>> (setq semantic-lex-depth 10)
>> (setq semantic-lex-analyzer 'wisent-vk-java-lexer)
>> (wisent-vk-java-wy--install-parser))
>>
>> (provide 'vk-java-mode)
>>
>> But I've quickly dumped into two problems:
>>
>> 1. Sometimes the "bovinate" command just gives me nil, sometimes -
>> not. I wasn't able to localize the problem, it is unstable. So the
>> question is: how can I debug the issue?
>
>
> The way most of the mode-specific features in CEDET work is through a core
> CEDET library called mode-local. It allows you to define a variable or
> function that is 'local' to some mode. Basically, if your buffer is of
> foo-mode, then any variables or functions customized as local to foo are set
> in that buffer.
>
> In mode-local there is a function `define-child-mode' that finishes what is
> started with `define-derived-mode'. I had a similar problem when I created
> support for arduino-mode, a child mode of C++. Behaviors seemed erratic
> till I remembered that I had to use define-child-mode to finish the
> connection.
>
> There is also a '%langaugemode' directive to use in your grammar to make
> sure things line up.
>
> I'll add this trick to the doc.
I do not need to use the built-in Java parser, as I use a separate
one, built from a custom grammar. It was a default hook for java-mode
that was interfering - added in semantic/semantic-loaddefs.el. It
installed the default parser, and that conflicted with the parser of
mine.
>
>> 2. The manual describing tags says clearly: the first element of a tag
>> is its name (a string), followed by its class. and three other
>> elements.
>>
>> But for the following simple code I can see (after "bovinating") the
>> name being smth like (("test" 12 . 25)):
>>
>> public class Test {
>> static void main(String[] args) {
>> }
>> public int test;
>> private int test2;
>> }
>>
>> Usual tag querying API does not work for such names, leaves me no
>> choice but to parse by hand, which is probably wrong. Switching major
>> mode back to vanilla java-mode gives me a normal AST tree and adequate
>> tag names.
>>
>> So question is the same here. How can I debug the issue? is there
>> anything wrong with my Semantic setup?
>
>
> In the wisent manual is a section on grammar debugging. There are some
> verbosity flags, and a way to enter edebug on a rule action. By debugging
> an action, you can step through the code to see what its return value is.
>
> The data you got back for "test" is a lexical tag. The buffer is converted
> to lexical tags, which are parsed with the grammar. The grammar actions
> then have implicit values they return, which become the saved information.
>
> You can watch the buffer get run through the lexer with semantic-lex-debug.
> If you do:
>
> M-x semantic-lex- TAB
>
> you can find misc debugging tools for lexical analysis. This is useful to
> see if the buffer is converted into the kinds of tokens you are actually
> trying to parse!
>
> In addition, all tags generated (using a TAG macro, such as VARIABLE-TAG or
> some-such start out as 'raw' tags. All raw tags need to be cooked down.
> Usually this is automatic, but you can override semantic-tag-expand-function
> with your own. Usually that is to convert something like:
>
> int x,y;
>
> into two tags, X and Y.
>
> Good Luck
> Eric
I've fixed this one. It was lack of java-specific
semantic-tag-expand-function. Copying from the default parser solved
the problem. New question:
I am trying to use semanticdb to cache parsed data, and I setq'd a
correct root-specifying function. It works well for parsing imports
and saving tags for manually opened files; but I couldn't find a way
to precache a complete project tree. I tried the following trick, but
still wasn't able to load all project tags into the db:
;; for every file in a project tree do
(with-current-buffer (find-file-noselect project-file-path)
(bovinate) ;; try semantic-fetch-tags too
(kill-buffer))
Maybe there is an idiom of some sort for such things? And I do need to
get all the tags, as I am trying to implement project-wide tag search.
Or am I getting something wrong?
--
Yours sincerely,
Vladimir Kazanov,
software developer,
mob. +7 (499) 34-34-912
ICQ: 82042707
skype: stvovka
email: vkazanov@...
--
С уважением,
Владимир Казанов,
программист,
моб. +7 (499) 34-34-912
ICQ 82042707
skype: stvovka
эл.почта vkazanov@...
|