[Gambas-user] Wiki Database
taboege at gmail.com
Sat May 4 13:28:26 CEST 2019
On Sat, 04 May 2019, Cedron Dawg wrote:
> Hi Tobi,
> Thanks so much. It took three tries, but I got it. This is going to take some looking at.
> I've also been examining the source tree and I may be best off scanning the source.
> For C based components, these sections should give me the info I want:
> GB_DESC ComplexDesc =
> GB_DECLARE("Complex", sizeof(CCOMPLEX)),
> // Utility Methods
> GB_METHOD("_new", NULL, Complex_new, "[(Real)f(Imag)f]"),
> GB_STATIC_METHOD("_call", "Complex", Complex_call, "[(Real)f(Imag)f]"),
> GB_STATIC_METHOD("Polar", "Complex", Complex_Polar, "[(Abs)f(Arg)f]"),
> GB_METHOD("Copy", "Complex", Complex_Copy, NULL),
> GB_METHOD("ToString", "s", Complex_ToString, "[(Local)b]"),
> GB_METHOD("Conj", "Complex", Complex_Conjugate, NULL),
> //GB_METHOD("Neg", "Complex", Complex_Negative, NULL),
> GB_METHOD("Inv", "Complex", Complex_Inverse, NULL),
> //GB_METHOD("Set", NULL, Complex_Set, "[(Real)f(Imag)f]"),
It might seem so, but remember that this is C souce code. Nothing stops
a developer from playing the macro game and make such a class description
effectively unparsable if you're not the C preprocessor. This is being
done in the GUI components to some extent where class definitions are
repetitive, but in reality you're not missing any "important" symbols
if you ignore unknown macros. If you run the preprocessor over the
source files, you will notice that GB_METHOD, GB_STATIC_METHOD, etc.
are all macros as well which declare tiny structs. Once they have been
preprocessed away, it becomes much harder to recognise what they were.
Using the .info files is far more robust. The full story is as follows:
The C compiler and linker turn native component source code into shared
objects. During the course of that, class descriptions such as the above
are demacroed, compiled into blobs. The interpreter requires exported
classes to be listed in an array of pointers to such blobs, at the
symbol GB_CLASSES inside the .so file. Sure enough every native component
has this symbol:
$ nm /usr/lib/gambas3/gb.so | grep GB_CLASSES
000000000001c760 D GB_CLASSES
Now you might be thinking: hah, I will take the .so file, peek into the
GB_CLASSES array and turn the fixed-size structs that are created by
the GB_DECLARE, GB_METHOD, GB_PROPERTY, etc. macros into the information
that I need.
Good idea, but don't do that because the tool gbi3 does exactly this
already and its output is: the .info files. They're called this way
because they contain the info you want.
Even more: the .info syntax is the same for components written in C/C++
and Gambas. It's a line-oriented plaintext file encoding of those binary
blobs that are created by the GB_DESC macros. Once the ABI of the
interpreter changes, gbi3 will change accordingly because it's inside
the Gambas source tree, and the .info files are more likely to remain
compatible, even if they're undocumented. Even the IDE uses these files
to generate its autocompletion popup.
> Is the wiki script you are talking about in?
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
More information about the User