February 2026 - GiNaC-devel

Questions regarding decoupling the global state to allow independent execution contexts
by Patrick Jacobs 20 Feb '26

20 Feb '26

Hello! While a relatively new user of GiNaC, I've been following the long-standing discussions regarding multithreading and the inherent difficulties of implementing thread-safety in a library designed around global state and shared memory. Pardon my ignorance, as I am not yet fully versed on the library's internal implementation. I would like to ask a few conditional questions regarding the possibility of personally implementing a multi-state/context architecture for GiNaC. 1. Is it correct to say that the library currently relies on a single, global "environment" that acts as the sole gatekeeper for all symbolic state? Does this design effectively prevent multiple independent processes from referencing the library's logic (not process objects at runtime in the global thread; the actual GiNaC library) at the same time? 2. Is it possible to decouple the library's core algebraic logic from this singular global state? Could the library be structured so that its functions serve a context provided by the user, rather than relying on a hardcoded global one? 3. If the library were modified to support independent contexts could multiple such worlds coexist within the same program without interfering with one another? 4. Could this be implemented in a way where the current global state simply becomes a default context? Specifically, is it possible to ensure that users who do not need multiple contexts see no change in behavior or performance? 5. In a world of isolated contexts, how might we facilitate the "translation" or "importing" of an expression from one independent world into another? This may merely have to be copies of expressions, but that can be handled at the use-case level. 6. Where are the primary "anchors" of this global state located within the codebase? If I were to personally take on the challenge of implementing such a context-based architecture, what areas of the library should I study first? Again, I am not asking the GiNaC community to implement these changes. I am asking for guidance on whether this is even possible and, if so, how to possibly implement this myself. I believe that by permitting multiple independent instances of a state to exist, the multithreading problem can be solved through isolation rather than the complexity of locks. I appreciate you taking the time to read this. Patrick S. Jacobs

2 3

Primary repo moved to Codeberg.org
by Richard B. Kreckel 15 Feb '26

15 Feb '26

Hi! TL;DR: If you have cloned the GiNaC git repository, please do: $ git remote set-url origin https://codeberg.org/ginac/ginac.git So it's been decided to modernize the environment a bit... Several people have expressed interest in doing things with GiNaC and kindly suggested that it would be easier to have a fashionable forge-based workflow where they can clone the repository, make changes, send pull requests, etc. Another consideration was the ongoing surge of distributed AI scrapers aggressively crawling our Gitweb instance in millisecond intervals, blatantly ignoring robots.txt, and repeatedly overwhelming the poor server with web traffic. After having looked at several forge platforms, we (i.e. Bruno Haible and myself) have decided to move the primary repo of both GiNaC and CLN to Codeberg.org: <https://codeberg.org/ginac/ginac> Codeberg e.V. is a Berlin-based non-profit organization dedicated to build and maintain supporting infrastructure for the creation, collection, dissemination, and archiving of Free and Open Source Software. Their Forgejo software is a free git-based hosting platform with most of the bells and whistles known from GitHub, GitLab, etc. Modern hip hackers will feel right at home there! ;-) I've set us up as an Organization <https://codeberg.org/ginac/> hosting both the CLN and GiNaC repos. It should be pretty transparent. If you need something special, don't hesitate to contact me! Along the way, this acquits us from having to come up with lame excuses to the pesky question where our issue tracker is. It is now here: <https://codeberg.org/ginac/ginac/issues> For now, the web site <https://www.ginac.de/> and the mailing lists will remain as they are. Happy hacking! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

2 1

printing of class power
by Stefan Weinzierl 12 Feb '26

12 Feb '26

Dear all, happy new year to everybody and my apologies for coming up with a potential bug report shortly after a new release. The code snippet symbol x("x"); ex f = 2*x; ex g = pow(x,5); f.print(GiNaC::print_context(std::cout)); std::cout << std::endl; g.print(GiNaC::print_context(std::cout)); std::cout << std::endl; will print 2*x [power object] Is that really intentional? The behaviour is the same in GiNaC 1.8.7 and 1.8.8. Best wishes, Stefan

3 11

GiNaC 1.8.10 released
by Richard B. Kreckel 11 Feb '26

11 Feb '26

Hi, GiNaC 1.8.10 has been released. It includes a new class Gt for evaluating elliptic multiple polylogarithms with arbitrary arguments. (This is work by Claude Duhr, Florian Lorkowski, Robin Marzucca, Sofia Mauch, and Stefan Weinzierl.) The minimum C++ language standard level has been raised to C++14. This version is ABI-compatible to the previous version 1.8.9. Happy hacking! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

2 3

Compiler-dependent bug with nested lists
by Florian Lorkowski 09 Feb '26

09 Feb '26

Dear GiNaC developers, I noticed a strange bug, which only happens with some compiler versions. In some cases, nested lists collapse into a flat list. Consider the following program: > #include <iostream> > #include "ginac/ginac.h" > > using namespace GiNaC; > int main(int argc, const char** argv) { > std::cout << lst{lst{1}} << std::endl; > return 0; > } I tested this with GCC 11.4.0 and clang 21.1.0. With those compilers, it correctly prints > {{1}} But with clang 19.1.7, it instead yields > {1} I tested some other cases and it seems that the issue occurs whenever a list has a single element which is also a list. Best regards Florian

2 4