Re: [sage-devel] Deactivate sage-env for conda

Sounds like what “module”/lmod are supposed to do automatically for you. Sourcing sage-env effectively give you a sage shell as you would if you run “sage -sh”. Again there is not really a deactivation. It starts a new shell and once you type exit you are out. But you could try to work out

[sage-devel] Deactivate sage-env for conda

Hi, Conda packages can have a activate.sh and deactivate.sh bash files that are run when an environment containing that package is activated or deactivated. I was thinking about doing "source bin/sage-env" to activate the sage environment. Problem is that there is no deactivate script that

Re: [sage-devel] build fails 'Cannot allocate memory'

Thank you for the suggestions! Much appreciated. On Sunday, March 12, 2017 at 2:47:55 PM UTC-7, Dima Pasechnik wrote: > > > > On Sunday, March 12, 2017 at 6:01:29 PM UTC, lvas...@berkeley.edu wrote: >> >> Wow, it works! Yay! >> > > to skip building sage's documentation, one can run 'make build'

Re: [sage-devel] Re: Names of special methods like _pari_

> In summary, I'll withdraw my vote for (1). Interesting and funny situation! If there's no more opposition, I may give positive review to #22470 tomorrow, after all. If you're wondering, #22470 keeps support for _pari_, but deprecates it in favour of __pari__. Luca -- You received this

Re: [sage-devel] Reviewing tickets with dependencies

On 03/16/2017 12:26 AM, Ralf Stephan wrote: > The author of 1234 has IMO the responsibility to monitor 987 and do > timely updates of 1234 when 987 changes, including canceling the > positive flag on 1234. > I don't want to beat this to death, but if the author of 1234 is so vigilant, why can't

Re: [sage-devel] Re: Names of special methods like _pari_

I'm also willing to change my mind, since I don't feel that strongly, and a number of people in favor of __pari__ seem to care a lot. There is still a nonzero cost to deprecation, since people will have to change their code to update to the new convention. But I don't think there are that many

[sage-devel] Re: Making package polymake optional

Hi! On 2017-03-15, kcrisman wrote: >> Now that we are in the process of having a proper interface to polymake >> (see [1] thanks to Simon) I would propose to move the package polymake >> from experimental to optional. For those who don't know, polymake is a >> CAS focused

[sage-devel] Re: Reviewing tickets with dependencies

On 2017-03-16, Ralf Stephan wrote: > The author of 1234 has IMO the responsibility to monitor 987 and do timely > updates of 1234 when 987 changes, including canceling the positive flag on > 1234. +1 -- You received this message because you are subscribed to the Google