On Wed, Mar 24, 2021 at 12:16 AM Volker Braun <vbraun.n...@gmail.com> wrote: > > I don't understand what the big pain point is, if Steve doesn't like the > limit it he can just pick a different value no? > > We do need some way of keeping the memory usage in check, people naturally > want to show off largeish computations and we run the risk to require a beefy > developer machine to be able to develop for Sage. > > As long as we have 32-bit buildbots the limit can't be much higher, but the > writing is on the wall than 32-bit is going away eventually. > > From my point of view its better to have some limit that provides immediate > feedback during development than me having to maintain a special buildbot to > limit memory usage and police tickets where developers don't have an easy way > to reproduce.
How about having make targets with and without these limits? Then most people would do make ptetslonghimem (or rather ptestlong) while others would do make ptestlonglowmen etc. (and the default should be 0, not 3300, if you ask me) > > On Tuesday, March 23, 2021 at 1:21:43 AM UTC+1 Michael Orlitzky wrote: >> >> Is anyone very much in love with the --memlimit (default: 3300MB) >> option to the sage -t command? >> >> Once again it has completely broken testing on some systems. We could >> try to guess a new, higher limit... or just admit that maybe it's not a >> great idea after all and delete the thing. The latter is what I'm about >> to propose on https://trac.sagemath.org/ticket/31395 >> >> A few points: >> >> * The failure of the default limit has been and will always be a >> recurring problem as sage requires more and more memory. Every >> time we hit it, a bunch of machines are broken until the limit >> can be raised in the "develop" branch. >> >> * The default memory limit exists for precisely one doctest (which >> I've refactored to still be tested, modulo the next bullet point). >> >> * Testing out-of-memory conditions doesn't test what you'd expect, >> since if you _actually_ run out of memory, all hell breaks loose >> on the system at the same time as your graceful error handling >> kicks in. >> >> * A global limit is likely incorrect, as would be revealed if there >> were more than one doctest using it. Each test needs the limit to >> be low enough to trigger a failure, but not low enough to crash >> the rest of sage. Both of these numbers are test- and system- >> dependent. >> >> * Reimplementing "ulimit -v" in a mathematics suite is a waste of >> development resources. >> >> I'd rather just delete it and generalize the one existing doctest with >> something like a "with memlimit(...)" context manager in the unlikely >> event that we ever have another test for OOM behavior. >> >> > -- > 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/536abe7e-c9fd-4336-aa03-8d430508a472n%40googlegroups.com. -- 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/CAAWYfq3GYEUF-Vf6C%2BMVsBvxuAbgW7jsDd88vBQF266t96RiNw%40mail.gmail.com.
