Is there any official machine-readable schematic data for GTK+ which I could use to generate bindings?
Technically, I know that the C headers are machine-readable but is there anything lighter weight (such as JSON or XML) that doesn't require me hooking a code generator up to C parser.
Give a look to the gir files shipped with the GTK libraries. They contain XML gobject-introspection information which is AFAIK the input of the bindings generators.
https://wiki.gnome.org/Projects/GObjectIntrospection
Related
ctags is a simple source code tagging system, also integrated in vi (and its flavours nvi, vim, etc.). AFAIK, it builds a plain text file where all the elements (functions, macros, ...) of the source code are indexed. But this file may become too large and unmanageable when the source code tree is extremely huge: this is the case of a kernel (Linux, *BSD, or similar).
Is still ctags or exuberant-ctags suitable for a complex source tree like a kernel?
If not, what tools (with the same integration in vi as ctags) can replace it? This may become subjective, so if possible provide a list of suggested tools: any comments, and references to a guide with the keyboard shortcuts in vi, are welcome.
Supported languages should be at least C, C++, assembly. The tool should be usable through CLI. I would principally like to jump to the definition of functions, macros, struct and similar objects (with ctags, pressing Ctrl+] with the cursor over the item name), to their manpages if possible, and back to the code.
The only alternative tool I know so far is GNU global, with a pretty complex vi integration, which seems to be possible only through Perl (and I can't find the equivalent of Ctrl+]).
The answer to your first point is a resounding yes.
You can use ctags to generate a tags file for different subtrees, thus keeping the size of the generated file to a minimum. At this point, you need to have a mechanism in place for searching for these multiple tags files. Vim provides this, of course.
I have given some advice here, so you may want to check that out.
Of course, I use exuberant-ctags there, so keep that in mind.
I tried to configure perl-5.18.2.
In checking C library phase, I got following messages.
Checking for GNU C Library...
You are not using the GNU C Library
I can use /mingw/bin/nm to extract the symbols from your C libraries. This
is a time consuming task which may generate huge output on the disk (up
to 3 megabytes) but that should make the symbols extraction faster. The
alternative is to skip the 'nm' extraction part and to compile a small
test program instead to determine whether each symbol is present. If
you have a fast C compiler and/or if your 'nm' output cannot be parsed,
this may be the best solution.
You probably shouldn't let me use 'nm' if you are using the GNU C Library.
Shall I use /mingw/bin/nm to extract C symbols from the libraries? [y] /mingw/bi
n/x86_64-w64-mingw32-nm.exe
I can't seem to find your C library. I've looked in the following places:
/lib
/usr/lib
None of these seems to contain your C library. I need to get its name...
Where is your C library?
Where is my C library?
I've tried /mingw/bin/nm.exe too.
http://search.cpan.org/dist/perl-5.18.2/README.win32:
The INSTALL file in the perl top-level has much information that is only relevant to people building Perl on Unix-like systems. In particular, you can safely ignore any information that talks about "Configure".
Instead, follow the instructions in the README.win32 file.
As I understood it "javadoc" is the name of the tool that generates html-documentation which also goes by the name javadoc. Atleast that is how I've been using the words..
But what is the generated output of the tool doxygen called? Doxygen-doc? doxy-doc? or maybe something else?
(Question in c++ context, if it matters)
Separate the tools from the output format.
Javadoc is a markup system. I think it is incorrect to call its html output (or any other output) "javadoc". The same way as you would not call a web page styled in Word "Word".
Similarly, Doxygen is also a markup system. It does not have its own documentation output type. Its 'types' are the output types it supports, that is: HTML, Latex, Man pages, RTF and more. See the full list.
You mention C++. Doxygen supports "C, Objective-C, C#, PHP, Java, Python, IDL (Corba, Microsoft, and UNO/OpenOffice flavors), Fortran, VHDL, Tcl, and to some extent D.
See Overview.
Short answer: "Design Documentation"
It's not a file format, it's a type of document that can be in any format. Usually html if you used Doxygen to create it.
How to access identifiers used in C program using AST.
I am new to eclipse plugin development and trying to customize eclipse plug-in to ensure that the variable name, function name, structure or whatever the programmer declares should not contain some specific set of words.
Please let me know some good CDT AST guide with examples. Thank you!
Over two weeks with zero responses. Looks like you are not going to get an answer.
I don't know how to help with CDT.
Our DMS Software Reengineering Toolkit with is C Front End parses C, builds ASTs and full C symbol table for a variety of dialects of C. Given this, it is rather easy to enumerate the C symbol table entries, and run an arbitrary predicate on names to see if they violate your conventions.
I've got a bunch of ACPI Source Language files and I want to calculate file to file similarities between them. I thought of using something like Perl's Parse::RecDescent
but I am stuck at:
1) Translating the ACPI Grammar (www.acpi.info/DOWNLOADS/ACPIspec40a.pdf) to something Parse::RecDescent would understand
2) Have a metric to compare 2 parsed files
Any ideas?
To get started with Parse::RecDescent you may look at Pro Perl Parsing, Ch. 5 or
at Advanced Perl Programming, Ch. 2
Xml Diff tools should be appropriate for comparing hierarchically structured data; perhaps you can apply such a tool to ASTs saved in XML format
So you have two problems:
Parsing ACPI to build an AST. This has the usual troubles of ensuring that you have a well defined grammar, that your parsing machinery can parse according to that grammar (often you have to bend a good grammar definition to enable the parsing machiney to process it), and building a corresponding AST. You will have these troubles with Perl parsing machinery, simply because it is a parsing engine.
Comparing the structure of the ASTs and producing a sensible answer. What you are likely to find here is that there is some literature describing roughtly how to do this (using e.g. Levenshtein distance), but that the details for ASTs matter. (Change distilling: Tree differencing for fine-grained source code change extraction Finally, having determined the distance, you need to print out the deltas in some readable form.
However, AFAIK, my company is the only one that has reduced this to practice. See our Smart Differencer tool. THe SmartDifferencers parse, build ASTs, and report changers in terms of ASTs elements moved, inserted, deleted, replaced, or modifiied by consistent identifier substitition. They depend on any underlying very strong GLR parsing engine which minimized the problems of accepting new grammars. They work for many common languages but not presently for ACPI.