Last December, gcl moved the control file for GCL_MULTIPROCESS_MEMORY_POOL to the user's homedir to get around multiuser access problems. One can also step around all such issues with
export GCL_MULTIPROCESS_MEMORY_POOL=nil If problems persist beyond this please let me know. Take care, Gunter Königsmann <[email protected]> writes: > Maybe you can contact the maintainer of the Debian package for Maxima > and ask him for advice about it. I don't think I can help solve this > problem -- I don't observe that behavior on my system, and I don't > know enough about GCL to offer a solution. > > Hey! That happens to be the problem I was investigating on the launchpad > virtual build servers. > > I wasn't sure if it is actually is a real problem since on my own > (non-virtual) machine I never encountered it. And there actually are options > on what we can do (see my other mail I've just sent to this list). But I > don't know if any of these options is optimal, so I would like > the others to decide: Memory management isn't a strong point of gcl. If we > don't tweak it in src/maxima.in > > * we typically cannot run maxima on the same machine thunderbird, Chromium or > firefox runs on > * we typically cannot run two maxima sessions on the same machine > * And the build servers having only 16GB of RAM available for our test suite > run don't manage to run maxima's test suite without running out-of-memory. > > But if we tweak gcl's memory management there (like we actually do) the > settings we decide upon might not be helpful for the actual user that runs an > actual problem. > > Kind regards, > > Gunter. > > _______________________________________________ > Maxima-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > -- Camm Maguire [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
