>>> "Dan Hirsch" <thequux@...> seems to think that:
>I'm interested in writing an sqlite backend; my current design is
>tohave a hunk of elisp call out to a daemon written in C (it's not
>easyto parse the output from the sqlite command line tool, and this
>way, Ican make the lisp much simpler.)
Sounds like a good idea.
>So far, all is good, but I do have a few questions.
>1) The semanticdb-file backend stores a large number of fields in
>thetag; what are all of these? I just need to know what kind of data
>willneed to be stored so that I can create the schema.
The fields in a tag are completely arbitrary. We've specified a few.
Your database should probably only specify search able fields that are
relevant in search. The rest should be stored as Emacs Lisp parseable
Key fields would be (based on function name.)
semantic-tag-class (a symbol, like 'function or 'variable)
semantic-tag-attributes (a list of things like datatype or constness)
semantic-tag-properties (a list of bookkeeping stuff)
Search routines that go through the database also search the following
semantic-tag-external-member-parent (ie, a method of what class)
and that's about it. I would suggest the core storage be just the 4
items above, and then any new searches could be in some associated
The most common search is against names. Names are searched by exact
match, starting substring (for completion) and by regular expression.
>2) I am NOT a lisp programmer. Actually, this is the first time
>I'veused it. So, if somebody would be willing to write the lisp part,
>Iwould appreciate it. (maybe semanticdb-external?)
I can assist, though I don't have very much free time. The basics are
in semanticdb-file, where the file io is replaced / some other
>On the C side, using stdin/stdout would be easiest, but I can
>dosockets/fifos/whatever. (actually, maybe not RPC, but that is a
stdout is a fine way to talk to Emacs.
>Finally, for an unrelated project, would it be theoretically
>possibleto run the bovinator in C? That would speed up bovinating
>/usr/includeexponentially, and also allow it to be done in the
There are three parser styles. One is the bovinator. One is wisent,
and the third is 'whatever'. It is certainly possible to write a C
program to parse files into Semantic format. The interface to such a
tools would be quite easy.
I had studied how ebrowse works to see if I could adapt it to my
needs, but the output it produces was a bit confusing.
>The way that I could see doing it is having elisp feed the
>c-bovinatora filename, which the c-bovinator would, well, bovinate,
>and send theresults back to emacs/the RDB backend described above.
It would need to operate on stdin/stdout since parsing happens against
text not on disk. Additionally, partial reparsing (subsets of a
buffer) would be a key aspect to keeping speed up.
>I am not sure how long caching all of /usr/include would take, but
>Iget the feeling that it would not be something I could do over
>aweekend... (it's about 350 MB of files, including Boost, which
>isbasically generated by the preprocessor on loading)
That would indeed be unwise. Semantic's template parsing still is
quite bad and the results would not be useful. Semantic needs an
interface to some other sort of tool, such as cscope, to do such heavy
duty parsing work. There are just way too many symbols to reasonably
expect to put into a lisp data structure.
>Finally, on another unrelated note, there's the problem parsing
>Gtkmmand friends. It loads the main header just fine, and it sees
>theinclude files, but it doesn't get any further than that. (no
>So, I have no problem completing the gtkmm include guards, but
>that'sall that gets cached :-( Needless to say, this is rather
[ ... ]
There are many reasons why it may not find a completion. From your
description I cannot decide if you have a parsing problem, or a
You can use global-semantic-show-unmatched-syntax-mode to find parsing
problems. You can use 'semantic-analyze-current-context' to see how
semantic tries to classify a search criteria for symbol lookup.
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org