<div dir="ltr"><div dir="ltr">Hi Régis and everyone,Thank you so much for the pointer to the SDK tools page and unoidl-write. It was the 'aha!' moment I needed. I had actually seen the unoidl/README.md /Users/devanshvarshney/lode/dev/libreoffice/unoidl/README.md file before, but I must admit my eyes glazed over at the detailed binary format specs, and I missed the high-level descriptions of unoidl-read and the other tools. Your email made it all click into place.It immediately clarified why my earlier attempts with regview were failing; I was using a legacy tool for a modern format. Focusing on unoidl-read as the correct tool for this PoC was the right path.I set out to generate the static UNO API dumps and ran into a classic, but very educational, "context" problem. My initial command failed:$ ./instdir/.../unoidl-read workdir/Rdb/udkapi.rdbdyld[...]: Symbol not found: __ZN6unoidl7Manager11addProviderE...I realized this was a dynamic linker error. The tool, run from a plain shell, had no context for where the required LibreOffice libraries were. The fix was to properly set up the SDK environment.Following this pointer, I immediately focused on the SDK toolchain.First, I had to get the SDK tools running. I located setsdkenv_unix in the SDK directory (instdir/LibreOfficeDev26.2_SDK/).$ ls instdir/LibreOfficeDev26.2_SDK/ bin config.sub ... classes <a href="http://configure.pl">configure.pl</a> ... ... ... setsdkenv_unix ...$ source ./setsdkenv_unixThe initial run was an interactive configuration step that created a personalized script for my machine: ~/LibreOfficeDev26.2_SDK/Devanshs-MacBook-Pro.local/setsdkenv_unix.shMy initial attempts to run unoidl-read right after this failed with a "Symbol not found" error, because the configuration script doesn't modify the current shell. The key was to source the generated script in a new terminal session to set up the necessary environment variables, like DYLD_LIBRARY_PATH on macOS.<pre><code>$ source ~/LibreOfficeDev26.2_SDK/Devanshs-MacBook-Pro.local/setsdkenv_unix.sh </code><pre><code> ************************************************************************ * SDK environment is prepared for MacOSX * ... (environment variables listed) ... ********************************************************************</code></pre><code>$ echo $DYLD_LIBRARY_PATH /Users/devanshvarshney/lode/dev/libreoffice/instdir/... </code>Generating the UNO API Dumps with unoidl-readWith the environment correctly set, I was able to successfully run unoidl-read on the RDB files located in workdir/UnoApiTarget/. This is a huge step forwad<code># In the libreoffice source root, after sourcing the env script $ cd ~/lode/dev/libreoffice $ mkdir -p ~/gsoc_dumps # This command now works! $ unoidl-read $PWD/workdir/UnoApiTarget/udkapi.rdb > \ ~/gsoc_dumps/uno_udkapi.rdb.dump.txt # This also works, providing udkapi.rdb as a dependency $ unoidl-read $PWD/workdir/UnoApiTarget/udkapi.rdb \ $PWD/workdir/UnoApiTarget/offapi.rdb > \ ~/gsoc_dumps/uno_offapi.rdb.dump.txt</code></pre>Key Findings & Next Steps </div><div dir="ltr">1. Success with unoidl-read: The tool works perfectly on the modern RDB files generated by the build system (like udkapi.rdb, offapi.rdb). The output is detailed and provides the structured type information we need for our static cache PoC. 2. Legacy RDBs: Interestingly, when I tried to run unoidl-read on some other RDBs from workdir/Rdb/ (like pyuno.rdb), I got a different error:<div style="font-family:comic sans ms,sans-serif" class="gmail_default"><pre><code> $ unoidl-read $PWD/workdir/Rdb/pyuno.rdb Bad input <...>: cannot open legacy file: 6</code></pre>This confirms the unoidl/README.md note that unoidl::Manager can detect the old legacy format but may not be able to read all of them with this specific tool. It's a great insight into the mixed-format nature of the registry system. Path Forward: This unblocks our static analysis path! I can now generate the comprehensive UNO API dumps we need for our "Master Information Table."</div><div class="gmail_default"> </div><div style="font-family:comic sans ms,sans-serif" class="gmail_default">I also saw dependency errors when trying to read RDBs that reference types defined elsewhere:</div><div style="font-family:comic sans ms,sans-serif" class="gmail_default"><pre><code>$ unoidl-read $PWD/workdir/UnoApiTarget/udkapi.rdb \ $PWD/workdir/UnoApiTarget/oovbaapi.rdb > ... Unknown entity com.sun.star.drawing.XControlShape</code></pre>oovbaapi.rdb needs to know about XControlShape, but that type isn't defined in udkapi.rdb. It's likely in offapi.rdb? This confirms that for a complete dump, one must provide the full chain of dependencies on the command line</div>---------------------------------------------------------------------------------------------------------Thank you Régis for your email! Your question was the perfect pointer and sent me down a very productive path of discovery. It helped connect all the dots from my mentor meetings and codebase review.You asked:<blockquote class="gmail-ng-star-inserted">So idlc and regmerge are still relevant ?</blockquote>My finding is that for modern development, they are largely replaced by the unoidl- toolchain. I've compiled my recent findings into a Q&A format below, as I think the journey has been very educational. </div><div dir="ltr">TL;DR - Key Discoveries<ul class="gmail-ng-star-inserted"><li class="gmail-ng-star-inserted">unoidl-read is the modern tool to inspect .rdb files; regview is for legacy formats.</li><li class="gmail-ng-star-inserted">The SDK environment must be sourced (setsdkenv_unix.sh) before running its tools to avoid dynamic linker errors.</li><li class="gmail-ng-star-inserted">theCoreReflection service is our C++ gateway to get rich, live type information from the UNO runtime, which is our primary method for the C++ PoCs.</li></ul> </div><div dir="ltr">GSoC BASIC IDE: A Deeper Dive Q&A on UNO Tooling & Data ExtractionMy project's first phase is all about data acquisition. Here are some questions I've explored while trying to get the static UNO API data.<h4 class="gmail-ng-star-inserted">Tooling Evolution</h4>Q1: So, are idlc and regmerge still relevant?A: For modern LibreOffice development, mostly no. The documentation is clear: unoidl-write is the new, unified tool that compiles .idl files directly into the modern .rdb format. While the old tools might be kept for legacy build scripts, core development now relies on the unoidl- toolchain.Q2: What is the correct tool to view the contents of modern .rdb files?A: The correct tool is unoidl-read. My initial attempts to use the older regview tool failed because it's designed for the legacy registry format. unoidl-read is specifically built to parse the new format that unoidl-write produces.<h4 class="gmail-ng-star-inserted">Environment & Execution</h4><pre><code>Q3: Why did my first attempts to run unoidl-read fail with a "Symbol not found" error? A: This was a classic environment issue. The error dyld[...]: Symbol not found... means the unoidl-read executable couldn't find the shared library it depends on. The SDK tools are not statically linked, and a standard terminal doesn't know where LibreOffice's internal libraries are.</code></pre>Q4: What's the correct way to use the SDK tools from the command line?A: You must prepare your shell session first. The first run of instdir/LibreOfficeDev26.2_SDK/setsdkenv_unix is an interactive setup that creates a personalized script. For every new terminal session after that, you must source that generated script. For me, this is: source ~/LibreOfficeDev26.2_SDK/Devanshs-MacBook-Pro.local/setsdkenv_unix.shQ5: After fixing the environment, unoidl-read still gave errors like "Unknown entity" or "Input ... does not exist." Why?A: This revealed two more key concepts:<ol class="gmail-ng-star-inserted"><li class="gmail-ng-star-inserted">Paths: The tool works best with absolute paths, which I resolved by using $PWD to construct the full path.</li><li class="gmail-ng-star-inserted">Dependencies: RDB files depend on each other. For example, offapi.rdb requires udkapi.rdb. You must provide dependencies first on the command line.</li></ol>Q6: What is a correct unoidl-read command to dump a complex RDB?A: You have to list its dependencies first. This successfully generated a full, readable dump for me:<div class="gmail-syntax-highlighted-code-wrapper"><div class="gmail-syntax-highlighted-code"><pre> <code>unoidl-read $PWD/workdir/UnoApiTarget/udkapi.rdb \ $PWD/workdir/UnoApiTarget/offapi.rdb > \ ~/gsoc_dumps/uno_offapi.rdb.dump.txt</code> </pre></div></div>Q7: Can unoidl-read handle all .rdb files?A: Interestingly, no. When I tried it on pyuno.rdb, I got the error Bad input <...>: cannot open legacy file: 6. This confirms the tool is for the modern format and highlights the mixed-format nature of the registry.<h4 class="gmail-ng-star-inserted">Reflection vs. Static Dumps</h4>Q8: What did the mentor mean with the cppumaker command?A: The command cppumaker -Gc ... reads RDBs to generate C++ header files. It's a perfect example of a tool consuming the RDB data. It's not for creating a generic data dump, but it confirms that the RDBs contain the necessary structured information for programmatic use.Q9: What is the best way to get UNO API info programmatically in C++?A: The mentor-guided PoC approach using the theCoreReflection service is the answer. The UNO runtime loads all RDBs, and theCoreReflection is our C++ "window" into that live, in-memory type system. It's more reliable than parsing RDB files ourselves. Our C++ PoC 2 successfully used theCoreReflection::forName() to dump methods, parameters, and inheritance.Q10: What crucial information did the theCoreReflection PoC confirm we can get?A: It proved we can get everything needed for rich auto-completion:<ul class="gmail-ng-star-inserted"><li class="gmail-ng-star-inserted">Method Signatures (with fully qualified return types).</li><li class="gmail-ng-star-inserted">Parameter Names & Types (crucial for "Parameter Info" tooltips).</li><li class="gmail-ng-star-inserted">Inheritance (superclasses, essential for a complete member list).</li><li class="gmail-ng-star-inserted">Struct & Enum Definitions (member names and types).</li></ul>Q11: So, what's the difference between the unoidl-read dump and the theCoreReflection dump?A: unoidl-read gives us a static view of everything defined in the RDB files. theCoreReflection gives us a live view of what the runtime knows. They should be very similar, but the C++ approach is what we'll use in the final code. The static dump is our "answer key" for validation.Q12: Why bother with the C++ PoCs if unoidl-read gives us the dump?A: Because the final "Master Analyzer" will be C++ code running inside LibreOffice. The PoCs prove that our implementation language and strategy can access the required data. The unoidl-read dump is our "answer key" to check our C++ extractor against.<h4 class="gmail-ng-star-inserted">Built-in vs. UNO vs. User Code</h4>Q13: How does ScriptForge's .pyi stub file fit into this?A: It's a key source of inspiration. As Rafael Lima mentioned, it might be manually curated for Python tooling. This tells us that having a structured API definition is a powerful pattern, and we can use the .pyi as a high-quality reference for what our parser should extract from the actual ScriptForge .bas source files.Q14: What was the point of the MsgBox investigation?A: MsgBox is a perfect example of a built-in BASIC function, a different category from UNO services. Its signature isn't in an IDL file. We have to find its definition in the C++ source (basic/source/runtime/) and see how its parameters are handled to extract its signature. This PoC proves we can handle this third category of data.Q15: How does the MS Office VBA Object Browser help?A: The screenshot Jonathan Clark shared post meeting 3 in chat MsgBox as a "Member of Interaction'". This is a crucial UX insight. It tells us that grouping related built-in functions under a logical "class" in our Object Browser will provide a more familiar experience for users.Q16: Where does the BASIC parser's symbol table fit in?A: While theCoreReflection and C++ analysis handle UNO and built-ins, the SbiParser and its SbiSymPool are the only source of truth for the user's own code being written in the editor. Our upcoming PoC 4 will focus on extracting symbols from these internal compiler structures.<h4 class="gmail-ng-star-inserted">Final Thoughts & Flow</h4>Q17: What is the immediate coding priority now?A: Our C++ PoCs 1 & 2 for UNO are working. The next coding task, as per mentor guidance, is PoC 3: The MsgBox deep dive, followed by PoC 4: BASIC Parser Symbol Extraction. This "breadth-first" approach demonstrates we can handle all major data categories.Q18: What's the plan for the cache storage (SQLite, Binary file, etc.)?A: This is a later design decision. For now, the PoCs are dumping simple text files, which is perfect for analysis. Once we've proven we can get all the data, we'll design an efficient cache structure.Q19: What is the flow of information for UNO types, now that we understand the new tools?A: The updated flowchart is:<div class="gmail-syntax-highlighted-code-wrapper"><div class="gmail-syntax-highlighted-code"><pre> <code>.idl Files --(unoidl-write)--> .rdb Files (Source of Truth) (Modern Binary Registry loaded by LO) | | | (Docs for humans) +-----> <Live UNO Type System> | (In-memory, accessed by...) v | +-----------+ v | Doxygen | +---------------------+ +-----------+ | theCoreReflection | | (Service in C++) | +---------------------+ | v <Rich Type Info for C++ PoC / Final App> +----------------+ (Dumps contents of) +--> `unoidl-read` SDK Tool | Text Dump | <--------------------+ (For static analysis) | (Our PoC File) | +----------------+</code> </pre></div></div>Q20: What was the final takeaway from my unoidl-read struggles?A: The environment is everything! Sourcing the setsdkenv_unix.sh script to provide the library context for SDK tools is the key. It was an invaluable lesson. </div><div dir="ltr"> </div><div><div style="font-family:comic sans ms,sans-serif" class="gmail_default">Another flow chart a bit easier compared to above -</div> </div><div><pre><code>+------------------------+ | .idl Files | | (Text Definitions) | +------------------------+ | | unoidl-write v +------------------------+ | .rdb Files | | (Binary Registry Data) | +------------------------+ | | Loaded by v +----------------------------------------+ | <Live UNO Type System> | | (In-memory, managed by LibreOffice) | +----------------------------------------+ | | Accessed by v +------------------------+ | theCoreReflection | | (C++ Service API) | +------------------------+ | | Used in v +------------------------+ | Our C++ PoC / Final | | Code Completion | +------------------------+ Additional Tools and Paths: ──────────────────────────────────────────── +------------------+ +------------------+ | Doxygen |<--------| .idl Files | | (Docs for Humans)| +------------------+ +------------------+ +------------------+ | unoidl-read |<--------| .rdb Files | | (Static Dump) | +------------------+ | → Text Dump | +------------------+ +------------------+ +------------------+ | cppumaker |<--------| .rdb Files | | javamaker | +------------------+ | (Lang Bindings) | +------------------+</code></pre> Terminal session - </div><div><pre><code> Devanshs-MacBook-Pro    \lode\dev\libreoffice  ➜ (  poc_basic  3)   21ms   6:00 PM    devanshvarshney ❯❯ ls ~/lode/dev/libreoffice/instdir/LibreOfficeDev26.2_SDK/ bin config.sub examples setsdkenv_unix share classes <a href="http://configure.pl">configure.pl</a> include <a href="http://setsdkenv_unix.sh.in">setsdkenv_unix.sh.in</a> config.guess docs index.html settings  Devanshs-MacBook-Pro    \lode\dev\libreoffice  ➜ (  poc_basic  3)   18ms   6:34 PM    devanshvarshney ❯❯ cd ~/lode/dev/libreoffice/instdir/LibreOfficeDev26.2_SDK/  Devanshs-MacBook-Pro    \lode\dev\libreoffice\instdir\LibreOfficeDev26.2_SDK  ➜ (  poc_basic  3)   15ms   6:34 PM    devanshvarshney ❯❯ source ./setsdkenv_unix ************************************************************************ * * You have to configure your SDK environment first before you can * use it. The configuration has to be done only once. * ************************************************************************ sh: line 0: cd: /System/Library/Frameworks/JavaVM.Framework/Versions/CurrentJDK: No such file or directory Used SDK = /Users/devanshvarshney/lode/dev/libreoffice/instdir/LibreOfficeDev26.2_SDK Enter the Office installation directory [/Applications/LibreOffice.app]: Enter GNU make (3.79.1 or higher) tools directory [/Users/devanshvarshney/lode/opt/bin]: Enter zip (2.3 or higher) tool directory [/usr/bin]: Enter cat tool directory [/bin]: Enter sed tool directory [/usr/bin]: C++ compilers where for example a language binding exist: - Solaris, Sun WorkShop 6 update 1 C++ 5.2 2000/09/11 or higher - Linux, GNU C++ compiler, gcc version 4.0.1 or higher - MacOS, GNU C++ compiler, gcc version 4.0.1 or higher Enter the directory of the C++ compiler, the directory where the compiler is located (optional) [/usr/bin]: Enter .NET SDK (8 or higher) installation directory (optional) []: Enter Java SDK (1.6 or higher) installation directory (optional) [/Users/devanshvarshney/jdk/jdk-17.0.15+6/Contents/Home]: Default output directory is in your HOME directory. Enter an existent directory if you prefer a different output directory (optional) [/Users/devanshvarshney]: Automatic deployment of UNO components (YES/NO) [YES]: ************************************************************************ * ... your SDK environment has been prepared. * For each time you want to use this configured SDK environment, you * have to run the "setsdkenv_unix" script file! * Alternatively can you source one of the scripts * "/Users/devanshvarshney/LibreOfficeDev26.2_SDK/Devanshs-MacBook-Pro.local/setsdkenv_unix.sh" * to get an environment without starting a new shell. ************************************************************************ ************************************************************************ * * SDK environment is prepared for MacOSX * * SDK = /Users/devanshvarshney/lode/dev/libreoffice/instdir/LibreOfficeDev26.2_SDK * Office = /Applications/LibreOffice.app * Make = /Users/devanshvarshney/lode/opt/bin * Zip = /usr/bin * cat = /bin * sed = /usr/bin * C++ Compiler = /usr/bin * Dotnet = * Java = /Users/devanshvarshney/jdk/jdk-17.0.15+6/Contents/Home * SDK Output directory = /Users/devanshvarshney/LibreOfficeDev26.2_SDK * Auto deployment = YES * ************************************************************************ [oh-my-zsh] Would you like to update? [Y/n] y Updating Oh My Zsh  Devanshs-MacBook-Pro    \lode\dev\libreoffice  ➜ (  poc_basic  3)   17ms   6:53 PM    devanshvarshney ❯❯ source ~/LibreOfficeDev26.2_SDK/Devanshs-MacBook-Pro.local/setsdkenv_unix.sh ************************************************************************ * * SDK environment is prepared for MacOSX * * SDK = /Users/devanshvarshney/lode/dev/libreoffice/instdir/LibreOfficeDev26.2_SDK * Office = /Applications/LibreOffice.app * Make = /Users/devanshvarshney/lode/opt/bin * Zip = /usr/bin * cat = /bin * sed = /usr/bin * C++ Compiler = /usr/bin * Dotnet = * Java = /Users/devanshvarshney/jdk/jdk-17.0.15+6/Contents/Home * SDK Output directory = /Users/devanshvarshney/LibreOfficeDev26.2_SDK * Auto deployment = YES * ************************************************************************  Devanshs-MacBook-Pro    \lode\dev\libreoffice  ➜ (  poc_basic  3)   31ms   7:01 PM    devanshvarshney ❯❯ ls $PWD/workdir/UnoApiTarget/ bridgetest.rdb cppuhelper.rdb performance.rdb cppu_qa_cppumaker_types.rdb offapi.rdb scaddins.rdb cppu_qa_types.rdb oovbaapi.rdb udkapi.rdb  Devanshs-MacBook-Pro    \lode\dev\libreoffice  ➜ (  poc_basic  3)   34ms   7:01 PM    devanshvarshney ❯❯ ls -l ~/LibreOfficeDev26.2_SDK/ total 0 drwxr-xr-x 3 devanshvarshney staff 96 16 Jun 18:35 Devanshs-MacBook-Pro.local drwxr-xr-x 3 devanshvarshney staff 96 16 Jun 18:35 macosx  Devanshs-MacBook-Pro    \lode\dev\libreoffice  ➜ (  poc_basic  3)   34ms   7:15 PM    devanshvarshney ❯❯ ls -l ~/LibreOfficeDev26.2_SDK/Devanshs-MacBook-Pro.local total 24 -rw-r--r-- 1 devanshvarshney staff 9439 16 Jun 18:35 setsdkenv_unix.sh  Devanshs-MacBook-Pro    \lode\dev\libreoffice  ➜ (  poc_basic  3)   112ms   7:35 PM    ⚡devanshvarshney ❯❯ unoidl-read $PWD/workdir/UnoApiTarget/udkapi.rdb $PWD/workdir/UnoApiTarget/offapi.rdb > ~/gsoc_dumps/uno_offapi.UnoApiTarget.dump.txt  Devanshs-MacBook-Pro    \lode\dev\libreoffice  ➜ (  poc_basic  3)   31ms   7:47 PM    ⚡devanshvarshney ❯❯ unoidl-read $PWD/workdir/Rdb/pyuno.rdb > ~/gsoc_dumps/pyuno.rdb.dump.txt Bad input <file:///Users/devanshvarshney/lode/dev/libreoffice/workdir/Rdb/pyuno.rdb>: cannot open legacy file: 6  Devanshs-MacBook-Pro    \lode\dev\libreoffice  ➜ (  poc_basic  3)   65ms   7:48 PM    ⚡devanshvarshney ❯❯ unoidl-read $PWD/workdir/Rdb/saxparser.rdb > ~/gsoc_dumps/saxparser.rdb.dump.txt Bad input <file:///Users/devanshvarshney/lode/dev/libreoffice/workdir/Rdb/saxparser.rdb>: cannot open legacy file: </code> </pre> </div><div dir="ltr"> </div><div dir="ltr">I hope this detailed Q&A is helpful for everyone following the project!</div><div>I have also attached the generated UNO Static Dump txt Files.</div><div> </div><div>Dynamic PoCs are here <a href="https://gerrit.libreoffice.org/c/core/+/186475">https://gerrit.libreoffice.org/c/core/+/186475</a></div><div> </div><div>Initial implementation <a href="https://gerrit.libreoffice.org/c/core/+/185362">https://gerrit.libreoffice.org/c/core/+/185362</a></div><div><div style="font-family:comic sans ms,sans-serif" class="gmail_default">I will also share the updated Master Analyzer ODS soon.</div></div><div dir="ltr"><pre><code>Initial mail <a href="https://lists.freedesktop.org/archives/libreoffice/2025-May/093264.html">https://lists.freedesktop.org/archives/libreoffice/2025-May/093264.html</a> Week 1 mail <a href="https://lists.freedesktop.org/archives/libreoffice/2025-May/093280.html">https://lists.freedesktop.org/archives/libreoffice/2025-May/093280.html</a> Week 2 and 3 mail <a href="https://lists.freedesktop.org/archives/libreoffice/2025-June/093362.html">https://lists.freedesktop.org/archives/libreoffice/2025-June/093362.html</a></code></pre> Thank you again for the pointer. It was exactly the clue I needed to understand the toolchain and make real progress on the data-gathering phase.<div class="gmail_default" style="font-family:comic sans ms,sans-serif"><div>Regards,</div><div>Devansh</div> </div></div><div> </div><div> </div><div> </div><div> </div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 16 Jun 2025 at 17:34, Regis Perdreau <<a href="mailto:regis.perdreau@gmail.com">regis.perdreau@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi</div><div> <a href="https://api.libreoffice.org/docs/tools.html" target="_blank">https://api.libreoffice.org/docs/tools.html</a></div><div><div dir="ltr" class="gmail_signature">"'unoidl-write' is the new UNOIDL compiler, replacing the former idlc and regmerge tools. "</div><div dir="ltr" class="gmail_signature"> </div><div class="gmail_signature">So idlc and regmerge still relevant ?</div><div class="gmail_signature"> </div><div class="gmail_signature">Bests,</div><div dir="ltr" class="gmail_signature"> </div><div dir="ltr" class="gmail_signature"> </div><div dir="ltr" class="gmail_signature">Régis Perdreau </div></div> </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 16 juin 2025 à 13:38, Regis Perdreau <<a href="mailto:regis.perdreau@gmail.com" target="_blank">regis.perdreau@gmail.com</a>> a écrit : </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div> Tanks for this work.</div><div> </div><div>Bests,</div><div><div dir="ltr" class="gmail_signature"> Régis Perdreau </div></div> </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 16 juin 2025 à 13:21, Devansh Varshney <<a href="mailto:varshney.devansh614@gmail.com" target="_blank">varshney.devansh614@gmail.com</a>> a écrit : </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone, <div>This week has been one of the best learning experiences for me,</div><div>especially digging into the "behind-the-scenes" of LibreOffice's UNO APIs.</div> My initial work (<a href="https://gerrit.libreoffice.org/c/core/+/185362" target="_blank">Gerrit 185362</a>) was a first step, but feedback from my mentors in our meetings provided a crucial directive: first, figure out how to get the data. Before we can build a great auto-completion system, we need a deep, proven understanding of where all the information (for BASIC, UNO, ScriptForge, etc.) lives and how to access it programmatically. This led to a fascinating dive into the UNO data pipeline. Understanding the UNO Data Pipeline: From IDL to Runtime For anyone curious about how UNO works under the hood, here's a breakdown of what I've learned. It's a pipeline that turns human-readable API definitions into an efficient system the application uses at runtime. IDL (Interface Definition Language): This is the source of truth for all UNO APIs. These .idl text files define every service, interface, method, property, struct, and enum. Locations: udkapi/ (core types) & offapi/ (office-specific types). idlc & regmerge: During the build, idlc (the IDL Compiler) compiles .idl files into intermediate binary .urd files. Then, regmerge combines these into .rdb (Registry Database) files. .rdb Files: These are the optimized binary databases that LibreOffice loads at startup. Key files include types.rdb (from udkapi.rdb etc.), services.rdb, and offapi.rdb. This is an installation artifact, not a source file, which clarified my initial search! theCoreReflection: At runtime, this powerful UNO service provides live, programmatic access to all the type information that was loaded from the .rdb files. regview Tool: A command-line tool (registry/tools/regview.cxx) designed to dump the contents of an .rdb file. My initial attempts to use this was unsuccessful, which, along with mentor guidance, led us to pivot our strategy. SbUnoObject & XIntrospectionAccess: The bridge in BASIC for interacting with live UNO objects, using dynamic introspection to discover their capabilities. <div>A simplified flow of this pipeline looks like this:</div><div> </div><div>.idl Files --(idlc)--> .urd Files --(regmerge)--> .rdb Files (Source of Truth) (Binary intermediate) (Loaded by LO Runtime) | v <LO Runtime Type System> (Accessible via theCoreReflection) ^ | (Reads .rdb) regview Tool | v <Textual Dump></div><div> </div><div> </div><div>Understanding ScriptForge (wizards/source/scriptforge/) I also looked into ScriptForge, which is crucial for modern BASIC scripting. <a href="https://gerrit.libreoffice.org/c/core/+/164867" target="_blank">https://gerrit.libreoffice.org/c/core/+/164867</a> - .xlb files are XML manifests listing the libraries. - .xba files are ZIP-like packages containing the actual .bas source modules. - .pyi file is a Python stub that provides type hints to Python IDEs for auto-completion. As Rafael Lima mentioned, this might be manually created, making it a great model for the kind of rich API definition we want to achieve for BASIC. How its information becomes available:</div><div> </div><div>.bas files (inside .xba packages listed in .xlb) | v (Loaded by BasicManager/StarBASIC) <SbModule objects with source code> | v (Compiled by SbiParser) <SbMethod, SbxVariable symbols within the SbModule> --- Parallel path for Python tooling --- .pyi file (wizards/source/scriptforge/python/scriptforge.pyi) | v (Read by Python IDEs) <Type hints for Python auto-completion></div><div> </div><div> </div><div>From Static File Parsing to C++ PoCs Given the complexities of parsing static RDB/IDL files directly, and the clear guidance from Meeting 3, our immediate focus has shifted. The new priority is to write C++ Proof-of-Concept (PoC) code to programmatically gather data and get this code onto Gerrit for review. I'm very excited to share that the first two PoCs are complete. Gerrit Patch:<a href="https://gerrit.libreoffice.org/c/core/+/186475" target="_blank"> https://gerrit.libreoffice.org/c/core/+/186475</a> This patch contains the CppUnit tests for these experiments. UNO Services and Memes - Why Context Comes First So for example I’ve seen this happen a lot on social media. There’s a meme going around, people are laughing, sharing it, reacting to it… and then there’s always someone in the comments asking: "What’s the context behind this?" I mean, I’ve done it too. Sometimes you just miss the reference, maybe it’s from a movie, or some political moment, or even a viral soundbite. Without the context, it’s just a picture or a clip. You don’t get why it’s funny, why it hits. And then someone replies and goes: "Oh, this is from Interstellar, that scene where Cooper watches years of messages after time dilation." Now it starts to click. That context sets the stage. Then maybe another reply adds: "Yeah, and the reason it’s funny here is because someone compared it to missing one lecture and coming back to find the whole syllabus changed." So first you got the context, then someone gave the reference point, say, the movie and then you dove into the details: the exact scene, the emotion, the punchline. That’s what makes it all land. And honestly, that’s how I see working with UNO services too. In our PoC, we had to first get the component context otherwise we’re just floating, not grounded in the current state of the app. Once we had that, we could ask for something like com.sun.star.reflection.CoreReflection, and only then could we start introspecting the real details, interfaces, methods, enums, all the building blocks. It’s kind of beautiful how that maps: Context → “Where am I?” Service → “What am I working with?” Introspection → “What can this thing do?” And just like in memes, without context, the rest doesn’t mean much. Funny enough, this whole idea of “context” is even a thing in frameworks like React or Java. So maybe context is more universal than we think. Summary of C++ Proof-of-Concepts (PoCs) Here's a breakdown of the PoCs I've implemented in the Gerrit patch: PoC 1: Listing All Available UNO Service Names Concept: Queries the XMultiComponentFactory (Service Manager) to get all creatable UNO service names. Source: comphelper/processfactory.hxx (getProcessServiceManager()). Task: - Get XComponentContext. - Get XMultiComponentFactory. - Call getAvailableServiceNames(). - Log each service name. Result: Successfully dumped service names. PoC 2: Introspecting Specific UNO Definitions via theCoreReflection Concept: theCoreReflection provides access to the complete in-memory type information that LibreOffice loaded from its RDBs. Source: com.sun.star.reflection.theCoreReflection, XIdlClass, etc. (implementation in <a href="https://git.libreoffice.org/core/+/refs/heads/master/stoc" target="_blank">stoc/source/</a>). Task: - Get theCoreReflection instance. - For a list of key type names (XModel, XSpreadsheet, PropertyValue, etc.): - Call forName(sTypeName) to get its XIdlClass blueprint. - Dump all details: superclasses, methods (with full parameter info), properties, struct fields, and enum members. Result: Extracted rich, detailed API definitions. This proves we can get the data needed for Parameter Info and accurate dot-completion. <a href="https://gerrit.libreoffice.org/c/core/+/186475/4/basic/uno_available_services_cpp_dump.txt" target="_blank">https://gerrit.libreoffice.org/c/core/+/186475/4/basic/uno_available_services_cpp_dump.txt</a> Next Steps: Diving into BASIC Internals With the UNO data access path validated, the next focus is on BASIC itself. PoC 3 (In Progress): The MsgBox Deep Dive My current task is to trace MsgBox from its user-facing documentation (both LO and MSO) down to its C++ implementation (SbRtl_MsgBox in basic/source/runtime/methods.cxx). This will help us understand how to handle built-in functions and their often-implicit parameter signatures. Future PoC: Parser Symbol Extraction After MsgBox, the plan is to write a C++ PoC that interacts with the SbiParser to extract its internal symbol tables (SbiSymPool) for user-defined code. A mentor's comment, "We have a cppumaker, etc., and why not a basicmaker?", really resonated with me. It highlights that our ultimate goal is to create a powerful "analyzer" for BASIC that provides the same level of rich, structured information for our IDE tools as other "makers" do for their respective languages. And yes I have to speed up stuff. Thanks for following this.</div><div> </div>-- <div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,</div><div>Devansh </div></div></div></div> </blockquote></div> </blockquote></div> </blockquote></div><div> </div> -- <div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,</div><div>Devansh </div></div></div></div>