Abstract:

This presentation introduces Pharo CIG (C Interface Generator), a powerful tool designed to automate the creation of Foreign Function Interface (FFI) bindings in the Pharo programming environment. The speaker begins by outlining the core problem: the Pharo community is relatively small, making it impractical to reimplement the vast number of existing, high-quality C and C++ libraries. Manually creating and maintaining bindings is a tedious, error-prone, and unsustainable process. Pharo CIG solves this by parsing C/C++ header files using libclang and automatically generating the necessary Pharo code. For C libraries, it creates direct UFFI bindings. For C++ libraries, it employs a more sophisticated approach, generating an intermediate C wrapper library (which it can also compile) and then creating Pharo bindings to interface with that wrapper. The talk features several successful demonstrations, including generating bindings for C libraries like raylib and libxml2, and for C++ libraries like libnoise and libical. The tool is presented as a work-in-progress with the potential to significantly expand Pharo's capabilities by making it vastly easier to leverage the external software ecosystem.

Pharo CIG: Automatically Generating Interfaces to C/C++ Libraries

• 0:02:22 The Core Problem: No Language is an Island: Pharo Smalltalk cannot exist in isolation. Due to a small community size, it's not feasible to rewrite every necessary tool and library from scratch. Interfacing with external libraries is essential for the ecosystem's survival and growth.
• 0:07:07 The Pain of Manual Bindings: The traditional method of manually creating FFI bindings for C libraries is time-consuming, prone to errors, and difficult to maintain, especially when the underlying libraries update their APIs (as shown with the libgit example).
• 0:08:57 The Solution: Pharo CIG (C Interface Generator): The presenter introduces a tool that automates the generation of Pharo bindings. It uses libclang to parse C/C++ header files and generates all the necessary Pharo classes, methods, and structures.
• 0:10:24 How it Works: Recipes and Generation: The process is controlled by a "recipe" file, where the user specifies details like the library name, header files to import, and required include paths. The tool then generates a complete, independent Pharo package.
• 0:12:09 Threading Support: The generator supports Pharo's threaded FFI, allowing the user to specify whether a library should run in the main UI thread (critical for graphics libraries), a separate worker thread, or the same thread as the Pharo VM.
• 0:23:37 Real-World Use Case: libxml2: A demonstration shows the successful generation of over 9,500 methods and structures for the complex libxml2 library. This solved a real-world problem for a community member who needed an XML validator in Pharo.
• 0:36:20 Handling C++ Libraries: C++ is more complex as it lacks a standard ABI. Pharo CIG handles this by generating an intermediate C wrapper file (using extern "C") that exposes the C++ functionality. The tool can then compile this wrapper into a shared library and generate Pharo bindings for it.
• 0:39:23 C++ Demo: libnoise: The presenter shows a successful mapping of the libnoise C++ library, which generates procedural noise for textures and terrain. The tool correctly handles C++ classes and namespaces, mapping them to Pharo equivalents.
• 0:49:26 Live Demo: libical and ChatGPT: In a live demonstration, bindings are generated for libical (an iCalendar library). The presenter then uses ChatGPT to generate sample Pharo code to test the newly created bindings, which successfully parse an iCalendar event.
• 0:57:40 Status and Future Work: The tool is a work-in-progress. C support is mostly stable, while C++ support is actively being improved on a per-library basis. Future plans include adding support for custom naming strategies, better documentation, and specialized generators for frameworks like GTK.
• 1:02:38 Programming in C with Pharo: A key takeaway is that while the bindings are auto-generated, using them is like programming in C. The developer is still responsible for manual memory management (e.g., calling free on allocated structures) and handling potential crashes.