On Tuesday 17 September 2024 at 07:04:18 UTC-7 dim...@gmail.com wrote:
that's the legacy of developing software in a platform-independent machine assembly language known as C or C++, or Fortran :-) Then, as we know, Greenspun's tenth rule states that: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. That's not actually the kind of bug I was thinking of. The memory leaks that have been particularly hard to find in sage were on python/cython level, which are generally memory-safe languages. They are about how to handle the essentially global data structure that arises from the coercion framework. For instance, if you'd store on ZZ the coercion maps to any ring in the normal way, every ring now has a reference from an object that will never be garbage collected (ZZ) and hence will not be eligible for collection either. Sage doesn't do that, of course, but the coercion graph does need to hold this information somehow. Doing that in a way that still allows parts to be pruned once some objects are not referenced very much anymore is truly a delicate problem. The globally unique "UniqueParent"s are another example of such a hard-to-manage global data structure, where garbage removal is very delicate. From python's (or common lisp's) perspective these wouldn't be memory leaks: they are just globally accessible structures ineligible for collection. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/adf2eec2-1512-4116-8a20-aa8db5536bdcn%40googlegroups.com.
