polymake 4.11 made it back to the Arch repos.

We are running the sanitizer in the configuration with libc++ from LLVM, where std::string has a small internal buffer for short strings (up to 6 bytes) overlapping with the pointer to heap-allocated long strings. This way, from the low-level perspective, the last character is always well-allocated ...

Well, it was primarily your insistence that forced me to have one more close look at that issue But the general warning remains: the current hack may cease to work with any new perl release.
BTW what happened to julia Debian package? Did they decide to move to snap, like firefox and chrome?

We tried to find such a hack but we failed. The problem is that the perl interpreter has hidden some vital functions which were necessary for parsing polymake perl code, starting with such elementary things as Matrix<Rational>. They can't be "revealed" from outside without modifying the pe...

... I haven't yet tracked down that issue. If anybody is interested in working with me on completing this patch, please get in touch I fully understand and appreciate your wish to help us in this misery, but I'm afraid any hacks we would try here will be in vain. Once the perl maintainers decided t...

The most probable reason is the incompatibility with the new perl version 5.38. This incompatibility turned out to be of such a fundamental nature that we decided to "divorce" polymake from perl altogether. This is, however, a large scale refactoring which takes substantial time. Until it'...

The most probable reason is the incompatibility with the new perl version 5.38. This incompatibility turned out to be of such a fundamental nature that we decided to "divorce" polymake from perl altogether. This is, however, a large scale refactoring which takes substantial time. Until it'...

Thanks for your heroic attempts to save the package! However, I'm afraid that this approach won't be sustainable. My guess is that perl maintainers introduced the symbol hiding on purpose, probably they plan to massively refactor the interpreter guts and with this measure they aimed exactly at catch...

Indeed, we are aware of the incompatibility problem with perl 5.38. There is no simple cure against the symbol hiding introduced there. Eventually polymake will lose the mandatory perl bindings, but this refactoring is still work in progress and there is no clear timeline yet for the completion. The...

It turns out that the projection function in polymake is severely broken: it treats the input with EQUALITY property in a highly inefficient manner, leading to a combinatorial exposion. The "nofm" option is also implemented wrongly, it produces just an empty cone object when the input is a...