On 2012-12-29, Nils Bruin <nbr...@sfu.ca> wrote: > On Dec 29, 6:01 am, Simon King <simon.k...@uni-jena.de> wrote: >> * In sage/misc/memory_info.py, MemoryInfo().available_swap() returns >> zero, but it is expected to return a positive number. No idea where >> that comes from. > For me that test works properly. However, I'd say it's perfectly > legitimate to configure a system with no swap at all, so I'd say the > test is wrong. Perhaps the result of copy/pasting tests to satisfy > formal merging rules? > > I don't think this issue is related to "debug" builds, though. The > file itself got introduced on #13211 and merged in 5.6b1. Volker is > the sole author, so he can probably comment. as the reviewer of #13211, I can say that I was never too happy about that heuristic. Actually, GAP wants to reserve an awful lot of swap on systems with a lot of RAM, something that to me is a bug (fixed by a proper setjump/longjump combination).
> > The main use seems to be to compute a suggested GAP workspace size. the only use, AFAIK. > In fact, I have already checked that the current suggested GAP workspace > leads to a failing sage startup if user limits are set much lower than > available memory: On a machine with 16Gb swap/ 16Gb memory and a 2Gb > vmemoryuse limit (which is not an unreasonable limit if you're more > interested in catching out-of-control memory use than in using lots of > memory), sage fails to start up. If I make memory_info.py lie about > available memory, no problem occurs. I think the heuristic there needs > a little more work. IIRC, the user limits are not taken into account there. Mea culpa, then. Dima -- 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.
