On Dec 27, 3:13 pm, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > Another issue came up: ticket #13566 also causes a segmentation fault > which goes away when #715 + #11521 are undone. [...] > My feeling is increasing that Sage isn't ready yet for #715.
I feel compelled to repeat here that sage is not useful for my research without it. Presently, I can only do toy examples with it. If there is no clear road to improve sage's memory management I'll have to discard my previous investments as sunk costs and abandon it. I'd hate to do so. I don't see how we can expect that reverting #715 now will lead to a smoother remerging process down the road. In fact, I expect that with the lost momentum it will be harder later. That said, previous work with singular showed that as soon as memory management is exposed to the usual tools, valgrind and similar tools make it often a trivial operation to find what's wrong and many of the mistakes turn out quite shallow once you know where to look. Building python with debug on sounds like a great step towards this and the recent comments in this thread seem to indicate we're quite close to making it easy to build sage with it. It sounds like quite a doable project to get patch queue in place that allows `export SAGE_DEBUG=yes` to do the desired thing. Once that is in place, I'm happy to do some runs and help locate (and fix?) bugs. So ... Please post instructions on how to get a sage build that allows valgrinding python memory allocations! There is a reasonable team of people presently who are willing to invest some time in tracking down these issues. Please stick with it for now! In the mean time, I'd be happy to review #13870 should you need it ;-). -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
