[Gambas-user] Wiki Database

[Cedron Dawg]

Thanks Tobi,

You have saved me a ton of time and effort.

These two lines reveal the structure of the info files:

gambas-master/app/src/gambas-wiki/.src/Main.module
908:    nClass += iCpt
909:    nSym += (aFile.Count - iCpt * 3) / 4

However, some files break this pattern with inserted comments.  So these resulting counts may be off.  (Bug?)  I added a field to the Component list with a comment count from the file.

These are the files that have comments:

gb.web.feed   125
gb.map        119
gb.web.form    26
gb.media.form  10
gb.logging      9
gb.report2      2
gb.form         1
gb.net.pop3     1
gb.report       1


Side note (Strange If syntax):

gambas-master/app/src/gambas-wiki/.src/CClassInfo.class
25:  If Not sParent And If CComponent.Classes.Exist(sName) Then

I've attached a project which gathers the information and produces three TSV (tab separated values) files.

For the Keywords, I am simply parsing the source of gambaswiki.org/wiki/lang.  That should be adequate for now.

Great progress!

Ced


----- Original Message -----
From: "Tobias Boege" <taboege at gmail.com>
...

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?
> gambas-master/app/src/gambas-wiki
> 

Yes.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

----[ Gambas mailing-list is hosted by https://www.hostsharing.net ]----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: InfoScanner-0.0.1.tar.gz
Type: application/x-compressed-tar
Size: 12283 bytes
Desc: not available
URL: <https://lists.gambas-basic.org/pipermail/user/attachments/20190504/4cd4e7b9/attachment-0001.bin>