[sage-devel] Re: New trac status badges

[Matthias Koeppe]

Thanks a lot for this work, Tobias! Glad to see that it is merged now.

I have added a bit based on your posting 
to https://wiki.sagemath.org/ReleaseTours/sage-9.6


On Sunday, February 13, 2022 at 1:26:06 PM UTC-8 tobias...@gmail.com wrote:

> Hi everyone,
>
> as you probably have already seen, there are a few new status badges in 
> the trac ticket display.
> We have now:
> 1. Linter that checks that the code of the current branch adheres to the 
> style guidelines. In order to see details when it fails, you can click on 
> it and then select the most recent workflow run. (This already exists for a 
> while)
> 2. Buid & test that builds sage for the current branch (incrementally on 
> top of the system packages of the develop branch) and runs the test. 
> Details are again available by clicking on the badge. (This is currently 
> still gray until https://trac.sagemath.org/ticket/33263 is merged into 
> master)
> 3. Build documentation workflow that builds the documentation for the 
> current branch. If you click on it, you get the html output of the 
> successful run. The idea is to use this to easily inspect changes to the 
> documentation without the need to locally rebuild the docs yourself. If the 
> doc build fails, you can go to 
> https://github.com/sagemath/sagetrac-mirror/actions/workflows/doc-build.yml 
> and choose the particular branch to see what went wrong.
> 4. Open in gitpod. This will spin up a pre-configured dev environment in 
> the browser (based on VS code), where the branch is already checked-out and 
> everything is pre-build. Feel free to use it to quickly check that the 
> changes in the ticket work as expected or to even make further changes 
> yourself. To find out more: https://www.gitpod.io/
>
> The idea is that these three status badges complement the existing 
> patchbots (and maybe even replace them in the future). In particular, they 
> are supposed to always be green. Please keep this in mind when reviewing a 
> ticket. 
>

-- 
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/fa011350-6b93-40e2-948d-a88bce053c35n%40googlegroups.com.

[sage-devel] Re: Sage's GSoC Application

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   Just as a reminder, I need to submit the application in one week on 
*February 
21st*.

I need a rough idea of how many people are willing to mentor a project. 
Furthermore, I need you to add some potential projects to the wiki page (or 
post them here and I can add them).

If we do not have sufficiently many projects and potential mentors, then we 
might not have a successful GSoC application.

Please respond and/or add a project by *Friday, Feb. 18th*. I would 
appreciate having a little bit of a buffer. :)

Best,
Travis


On Monday, February 7, 2022 at 9:28:35 AM UTC+9 Travis Scrimshaw wrote:

> Hi everyone,
>It is that time of year where we submit an application to Google to be 
> an organization as part of Google's Summer of Code (GSoC). As I indicated 
> last year, I will be doing the main administrative work of the submission 
> and running GSoC this year (assuming there are no objections).
>
> To begin, there are two significant changes from previous years. The first 
> is that there are two lengths of projects: medium-term (175 hours) and 
> long-term (350 hours). Secondly, the timeline has increased flexibility and 
> allows for extensions up to 22 weeks instead of the usual 12 weeks. For 
> more information, you can read Google's announcement:
>
>
> https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html
>
> As part of our application, we need a good list of potential projects for 
> students to work on. This is where you come in. I have created an page of 
> potential projects:
>
> https://wiki.sagemath.org/GSoC/2022
>
> If you are possibly interested in mentoring (no commitment required) or 
> have a more complicated feature you would like to see implemented, please 
> add an entry to the list.
>
> The deadline for the submission is Feb. 21st, so if you could please add 
> your thoughts on projects by then, it would be appreciated. This is not a 
> hard deadline for all projects for GSoC, but it would be useful to improve 
> our organization's application.
>
> Let me know if you have any questions or comments. I am looking forward to 
> working with everyone again on having another successful year as part of 
> GSoC!
>
> Best,
> Travis
>
>
>

-- 
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/cea50d6b-d1d0-4e54-847e-1753fd2a1eban%40googlegroups.com.

[sage-devel] New trac status badges

[Tobias Diez]

Hi everyone,

as you probably have already seen, there are a few new status badges in the 
trac ticket display.
We have now:
1. Linter that checks that the code of the current branch adheres to the 
style guidelines. In order to see details when it fails, you can click on 
it and then select the most recent workflow run. (This already exists for a 
while)
2. Buid & test that builds sage for the current branch (incrementally on 
top of the system packages of the develop branch) and runs the test. 
Details are again available by clicking on the badge. (This is currently 
still gray until https://trac.sagemath.org/ticket/33263 is merged into 
master)
3. Build documentation workflow that builds the documentation for the 
current branch. If you click on it, you get the html output of the 
successful run. The idea is to use this to easily inspect changes to the 
documentation without the need to locally rebuild the docs yourself. If the 
doc build fails, you can go to 
https://github.com/sagemath/sagetrac-mirror/actions/workflows/doc-build.yml 
and choose the particular branch to see what went wrong.
4. Open in gitpod. This will spin up a pre-configured dev environment in 
the browser (based on VS code), where the branch is already checked-out and 
everything is pre-build. Feel free to use it to quickly check that the 
changes in the ticket work as expected or to even make further changes 
yourself. To find out more: https://www.gitpod.io/

The idea is that these three status badges complement the existing 
patchbots (and maybe even replace them in the future). In particular, they 
are supposed to always be green. Please keep this in mind when reviewing a 
ticket. 

-- 
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/6fa086b9-276e-419e-9232-ff03f2b0708cn%40googlegroups.com.

Re: [sage-devel] Moving SAGE_TMP to the system location

[François Bissey]

> On 14/02/2022, at 03:57, Michael Orlitzky  wrote:
> 
> If not, I'm proposing we,
> 
>  1. Replace all direct uses of SAGE_TMP in library/doctest code with 
> python's tempfile module.
>  2. Drop SAGE_TMP from tmp_filename() and tmp_dir(); this will revert
> to whatever directory the OS uses.
>  3. Slowly migrate away from tmp_filename() and tmp_dir() to the 
> functions that python provides.

+1

-- 
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/463E6DED-39AB-44DA-8869-C26F02255851%40gmail.com.

Re: [sage-devel] Can we restore `mean`?

[Matthias Koeppe]

On Sunday, February 13, 2022 at 12:58:41 PM UTC-8 David Roe wrote:

> The documentation of Python's statistics module notes that "Unless 
> explicitly noted, these functions support int, float, Decimal and Fraction. 
> Behaviour with other types (whether in the numeric tower or not) is 
> currently unsupported. Collections with a mix of types are also undefined 
> and implementation-dependent."
>

Yes, they need the Sage community's input to develop this further.
 

 

-- 
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/809e1d38-c377-4bcc-a29f-b17b310437bcn%40googlegroups.com.

Re: [sage-devel] Can we restore `mean`?

[David Roe]

The documentation of Python's statistics module notes that "Unless
explicitly noted, these functions support int, float, Decimal and Fraction.
Behaviour with other types (whether in the numeric tower or not) is
currently unsupported. Collections with a mix of types are also undefined
and implementation-dependent."

https://trac.sagemath.org/ticket/28234 is not easy to fix.  Even if a long
term goal is being able to use the built in stats module (which may or may
not be a good idea given the disclaimer above), I think we should add mean
back in.
David

On Sun, Feb 13, 2022 at 3:16 PM Matthias Koeppe 
wrote:

> IMO the best long-term solution is to make sure that the built-in stats
> module (https://docs.python.org/3/library/statistics.html) can be used.
> However, as explained in the ticket https://trac.sagemath.org/ticket/29662
> (and https://trac.sagemath.org/ticket/28234), there are bugs that prevent
> users from using it with some Sage types.
>
>
> On Saturday, February 12, 2022 at 7:28:43 PM UTC-8 wst...@gmail.com wrote:
>
>> This happened in https://trac.sagemath.org/ticket/29662, as requested
>> by kcrisman. I just looked at that
>> ticket and added a comment about several additional examples where
>> deprecating mean breaks things
>> in subtle ways...
>>
>> On Sat, Feb 12, 2022 at 7:14 PM Samuel Lelievre
>>  wrote:
>> >
>> > Dear sage-devel,
>> >
>> > Taking averages is a common operation, and a `mean` function
>> > such that `mean(xx)` returns `sum(xx) / len(xx)` regardless of
>> > the type of objects in the iterable `xx` is extremely convenient.
>> >
>> > For instance, for a polygon whose vertices `uu` have coordinates
>> > in a number field and are represented as vectors over that field,
>> > `mean(uu)` finds the centre of that polygon. To center the polygon
>> > at the origin, use `c = mean(uu)` and `vv = [u - c for u in uu]`.
>> >
>> > In Sage 9.5, using `mean` displays a warning:
>> > ```
>> > DeprecationWarning: sage.stats.basic_stats.mean is deprecated;
>> > use numpy.mean or numpy.nanmean instead
>> > ```
>> > This is after #29662 was merged in SageMath 9.5.beta1.
>> >
>> > Alas, `numpy.mean` cannot find the mean of a list of vectors
>> > over a number field.
>> >
>> > Of course, as a workaround, I can define
>> >
>> > def mean(xx):
>> > r"""
>> > Return the mean of this iterable.
>> > """
>> > return sum(xx) / len(xx)
>> >
>> > and place that in an `init.sage` file in my `~/.sage` folder.
>> >
>> > Having that built into Sage is so much more convenient though.
>> > Can we have it back?
>> >
>> > Kind polygonal regards, --Samuel
>> >
>> > --
>> > 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+...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sage-devel/60fe4b1c-db88-4caa-8d13-670b9b3edb79n%40googlegroups.com.
>>
>>
>>
>>
>> --
>> William (http://wstein.org)
>>
> --
> 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/72970d04-877d-41bb-8af5-7dce382f887bn%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/CAChs6_nCoYCiUVCVsqmEN3wFSy%2BETKHxVPLJ6HmRQbSFTJMLxA%40mail.gmail.com.

Re: [sage-devel] Can we restore `mean`?

[Matthias Koeppe]

IMO the best long-term solution is to make sure that the built-in stats 
module (https://docs.python.org/3/library/statistics.html) can be used. 
However, as explained in the ticket https://trac.sagemath.org/ticket/29662 
(and https://trac.sagemath.org/ticket/28234), there are bugs that prevent 
users from using it with some Sage types. 


On Saturday, February 12, 2022 at 7:28:43 PM UTC-8 wst...@gmail.com wrote:

> This happened in https://trac.sagemath.org/ticket/29662, as requested
> by kcrisman. I just looked at that
> ticket and added a comment about several additional examples where
> deprecating mean breaks things
> in subtle ways...
>
> On Sat, Feb 12, 2022 at 7:14 PM Samuel Lelievre
>  wrote:
> >
> > Dear sage-devel,
> >
> > Taking averages is a common operation, and a `mean` function
> > such that `mean(xx)` returns `sum(xx) / len(xx)` regardless of
> > the type of objects in the iterable `xx` is extremely convenient.
> >
> > For instance, for a polygon whose vertices `uu` have coordinates
> > in a number field and are represented as vectors over that field,
> > `mean(uu)` finds the centre of that polygon. To center the polygon
> > at the origin, use `c = mean(uu)` and `vv = [u - c for u in uu]`.
> >
> > In Sage 9.5, using `mean` displays a warning:
> > ```
> > DeprecationWarning: sage.stats.basic_stats.mean is deprecated;
> > use numpy.mean or numpy.nanmean instead
> > ```
> > This is after #29662 was merged in SageMath 9.5.beta1.
> >
> > Alas, `numpy.mean` cannot find the mean of a list of vectors
> > over a number field.
> >
> > Of course, as a workaround, I can define
> >
> > def mean(xx):
> > r"""
> > Return the mean of this iterable.
> > """
> > return sum(xx) / len(xx)
> >
> > and place that in an `init.sage` file in my `~/.sage` folder.
> >
> > Having that built into Sage is so much more convenient though.
> > Can we have it back?
> >
> > Kind polygonal regards, --Samuel
> >
> > --
> > 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+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/60fe4b1c-db88-4caa-8d13-670b9b3edb79n%40googlegroups.com
> .
>
>
>
> -- 
> William (http://wstein.org)
>

-- 
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/72970d04-877d-41bb-8af5-7dce382f887bn%40googlegroups.com.

Re: [sage-devel] Can we restore `mean`?

[kcrisman]

My original ticket title was "Clarify stats module role", not deprecate.   
"This ticket is to split the more technical stuff (which presumably may 
still be used for researchers, but not for the sort of things basic R or 
pandas data frames would be) into a separate module where it can be taken 
care of."  The whole notion of removing something as basic as "mean" from 
global namespace is not something I would support.

However, that does bring up a broader issue of who the end users of Sage 
are supposed to be.  I understand the idea of Sage solely as a Python 
library like Sympy or whatever.  However, not just historically have we 
behaved otherwise, but it seems rather opposed to the mission statement of 
Sage.  Our goal isn't to be "best standard Python library for math" but 
"open-source competitor to ..." and they are stand-alone programs, by 
design and rightly so. (This could include having a pip-installable 
version, obviously.) This question is naturally not directly part of this 
thread, but it seems to come up fairly often.  As for me, too many memories 
of needing warnings in Maple like "Did you remember to load the plots 
package via the with(plots): command?"   Nils has a good quote on the 
ticket, "A python library is just not a very good match for what people 
expect from an interactive CAS, so I think it's good we have a shim layer 
that makes sagemath behave a little more like a traditional CAS."

On Saturday, February 12, 2022 at 10:28:43 PM UTC-5 wst...@gmail.com wrote:

> This happened in https://trac.sagemath.org/ticket/29662, as requested
> by kcrisman. I just looked at that
> ticket and added a comment about several additional examples where
> deprecating mean breaks things
> in subtle ways...
>
> On Sat, Feb 12, 2022 at 7:14 PM Samuel Lelievre
>  wrote:
> >
> > Dear sage-devel,
> >
> > Taking averages is a common operation, and a `mean` function
> > such that `mean(xx)` returns `sum(xx) / len(xx)` regardless of
> > the type of objects in the iterable `xx` is extremely convenient.
> >
> > For instance, for a polygon whose vertices `uu` have coordinates
> > in a number field and are represented as vectors over that field,
> > `mean(uu)` finds the centre of that polygon. To center the polygon
> > at the origin, use `c = mean(uu)` and `vv = [u - c for u in uu]`.
> >
> > In Sage 9.5, using `mean` displays a warning:
> > ```
> > DeprecationWarning: sage.stats.basic_stats.mean is deprecated;
> > use numpy.mean or numpy.nanmean instead
> > ```
> > This is after #29662 was merged in SageMath 9.5.beta1.
> >
> > Alas, `numpy.mean` cannot find the mean of a list of vectors
> > over a number field.
> >
> > Of course, as a workaround, I can define
> >
> > def mean(xx):
> > r"""
> > Return the mean of this iterable.
> > """
> > return sum(xx) / len(xx)
> >
> > and place that in an `init.sage` file in my `~/.sage` folder.
> >
> > Having that built into Sage is so much more convenient though.
> > Can we have it back?
> >
> > Kind polygonal regards, --Samuel
> >
> > --
> > 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+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/60fe4b1c-db88-4caa-8d13-670b9b3edb79n%40googlegroups.com
> .
>
>
>
> -- 
> William (http://wstein.org)
>

-- 
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/c7c66de5-c7b0-4003-8066-6b67a4926a78n%40googlegroups.com.

[sage-devel] prime_pi problem

[dan...@gmail.com]

prime_pi() fails in Sage 9.5 on my MacBook Pro M1, MacOs 11.3.1.

I am using the macOS app available at: 
https://github.com/3manifolds/Sage_macOS/releases 
.

prime_pi() apparently causes a segmentation fault for any argument less 
than or equal to 15359. For whatever it's worth, 15359 is the 1794th prime 
number.

This problem does NOT occur with version 9.4 of the same app, nor does it 
occur in CoCalc 9.5.

Here is the output I get from running prime_pi(*15359*):

│ SageMath version 9.5, Release Date: 2022-01-30 │

│ Using Python 3.9.9. Type "help()" for help.│

sage: prime_pi(*15359*)
   



(no backtrace available)



Unhandled SIGSEGV: A segmentation fault occurred.

This probably occurred because a *compiled* module has a bug

in it and is not properly wrapped with sig_on(), sig_off().

Python will now terminate.



zsh: segmentation fault  

Saving session...

...copying shared history...

...saving history...truncating history files...

...completed.


[Process completed]

-- 
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/e5e8317e-a099-4373-920d-4172be8cd357n%40googlegroups.com.

Re: [sage-devel] Re: Moving SAGE_TMP to the system location

[Michael Orlitzky]

On Sun, 2022-02-13 at 09:18 -0800, Volker Braun wrote:
> Are we talking about /tmp or /var/tmp? 

Short answer: /tmp.

Long answer: The python tempfile functions use a directory that,

  "is chosen from a platform-dependent list, but the user of the 
   application can control the directory location by setting the 
   TMPDIR, TEMP or TMP environment variables."

So ultimately, it's up to python, or the user. But TMPDIR is typically
associated with /tmp on UNIX (both are POSIX), and I don't think
there's cross-platform consensus on a /var/tmp equivalent. So my
money's on /tmp where there's a choice.

-- 
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/57e9328adbb97df5ef8a35de0bfb532a8bffac8b.camel%40orlitzky.com.

[sage-devel] Re: Moving SAGE_TMP to the system location

[Volker Braun]

Are we talking about /tmp or /var/tmp? 

https://systemd.io/TEMPORARY_DIRECTORIES/ says:
* /tmp/ should be used for smaller, size-bounded files only; /var/tmp/ 
should be used for everything else.
* Data that shall survive a boot cycle shouldn’t be placed in /tmp/.

While its often the case that /var/tmp has some time-based cleanup, this is 
not universally so.


-- 
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/7848acc1-089a-4f75-b3af-eae6bf3373b8n%40googlegroups.com.

Re: [sage-devel] Moving SAGE_TMP to the system location

[William Stein]

On Sun, Feb 13, 2022 at 6:57 AM Michael Orlitzky  wrote:
>
> tl;dr I think we should forego SAGE_TMP and use whatever the system's
> temporary location is.

+1.

I'm pretty sure I "created" this SAGE_TMP thing in the first place,
and that my reasons were:

a. ignorance about the built in Python solution (which in 2004 might
have been immature),

b. concerns about security, which are no longer of primary importance
for Sage.  For example,
on a multiuser Linux system, admins need to make sure that files
written to /tmp are by default only
readable by one user; also, it's annoying if users accidentally write
a lot of data to /tmp, causing
trouble for everybody else.


Regarding these, of course (a) is not a good argument, and (b) should
no longer be either.
In addition, for users of CoCalc, the home directory is a network
mounted ZFS filesystem, with snapshots
and compression, whereas /tmp is a ramdisk dedicated to just that one
project that is orders of magnitude
faster than $HOME.  Thus for CoCalc, it would be *massively* better
for Sage to use /tmp rather
than the current SAGE_TMP defaulting to a directory under $HOME.

-- William

>
> The first-order benefits of that are,
>
>   1. No need to maintain SAGE_TMP code ourselves.
>
>   2. The system temporary location is often optimized for temporary
>  access (e.g. is mounted in RAM), and is automatically cleaned
>  occasionally. Compare to SAGE_TMP which defaults to a directory
>  under $HOME.
>
> The second-order benefit is that it would eliminate the need for our
> custom tmp_filename() and tmp_dir() functions. Both of those are thin
> wrappers around what python provides, differing mainly in that they use
> SAGE_TMP. But moreover,
>
>   1. tmp_filename() opens a file, closes it, and then gives you back
>  the name. This is in contrast to python's NamedTemporaryFile(),
>  which gives you the open file without closing it. Since in most
>  cases you actually want to use the file, tmp_filename() is
>  slightly but pointlessly inefficient.
>
>   2. tmp_dir() returns only the name of the newly-created directory,
>  while python's TemporaryDirectory() gives you a file-like object.
>  If you need to clean up, the file-like object can cleanup(),
>  while the name returned from tmp_dir() requires you to call
>  something like shutil.rmtree() on it.
>
>   3. Neither of them remove the file or directory when you're done
>  with it, requiring sage-cleaner to deal with them at a later
>  point (if all goes well). The python tempfile functions give
>  you the option to auto-delete.
>
> These are small annoyances. Does SAGE_TMP provide any benefits to
> justify them?
>
> If not, I'm proposing we,
>
>   1. Replace all direct uses of SAGE_TMP in library/doctest code with
>  python's tempfile module.
>   2. Drop SAGE_TMP from tmp_filename() and tmp_dir(); this will revert
>  to whatever directory the OS uses.
>   3. Slowly migrate away from tmp_filename() and tmp_dir() to the
>  functions that python provides.
>
>
> --
> 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/84da47e539b342c270760e7e6200272a820fa5d1.camel%40orlitzky.com.



-- 
William (http://wstein.org)

-- 
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/CACLE5GDcuYrbw2Dhs-gtjbaV6giuQHOG4MHuabhtaOhSHV2ZrQ%40mail.gmail.com.

[sage-devel] Moving SAGE_TMP to the system location

[Michael Orlitzky]

tl;dr I think we should forego SAGE_TMP and use whatever the system's
temporary location is.

The first-order benefits of that are,

  1. No need to maintain SAGE_TMP code ourselves.

  2. The system temporary location is often optimized for temporary 
 access (e.g. is mounted in RAM), and is automatically cleaned 
 occasionally. Compare to SAGE_TMP which defaults to a directory 
 under $HOME.

The second-order benefit is that it would eliminate the need for our
custom tmp_filename() and tmp_dir() functions. Both of those are thin
wrappers around what python provides, differing mainly in that they use
SAGE_TMP. But moreover,

  1. tmp_filename() opens a file, closes it, and then gives you back
 the name. This is in contrast to python's NamedTemporaryFile(),
 which gives you the open file without closing it. Since in most 
 cases you actually want to use the file, tmp_filename() is 
 slightly but pointlessly inefficient.

  2. tmp_dir() returns only the name of the newly-created directory,
 while python's TemporaryDirectory() gives you a file-like object.
 If you need to clean up, the file-like object can cleanup(), 
 while the name returned from tmp_dir() requires you to call 
 something like shutil.rmtree() on it.

  3. Neither of them remove the file or directory when you're done 
 with it, requiring sage-cleaner to deal with them at a later
 point (if all goes well). The python tempfile functions give
 you the option to auto-delete.

These are small annoyances. Does SAGE_TMP provide any benefits to
justify them?

If not, I'm proposing we,

  1. Replace all direct uses of SAGE_TMP in library/doctest code with 
 python's tempfile module.
  2. Drop SAGE_TMP from tmp_filename() and tmp_dir(); this will revert
 to whatever directory the OS uses.
  3. Slowly migrate away from tmp_filename() and tmp_dir() to the 
 functions that python provides.


-- 
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/84da47e539b342c270760e7e6200272a820fa5d1.camel%40orlitzky.com.