[sage-devel] Re: Can we get rid of the "Consider using a block-scoped tag" warning?

[Kwankyu Lee]

On Friday, August 4, 2023 at 1:54:53 AM UTC+9 Volker Braun wrote:

The test output is full of "Warning: Consider using a block-scoped tag by 
inserting the line...", making it hard to see where the actual error is. 


I agree. Hopefully, the warnings would be removed soon if more people work 
on them . Fortunately the tool "sage -fixdoctests"  improved by

https://github.com/sagemath/sage/pull/36024 (not yet in beta)

is very efficient  as it handles directories just like "sage -t". For 
example, you can run "sage -fixdoctests src/sage/schemes/toric", that will 
fix all files in the directory tree.

Actually it would make a sense that we create a mega PR by running "sage 
-fixdoctests src/sage" as soon as #36024 gets in beta. 

-- 
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/5ae4eab7-1437-425d-b0c8-e8910ac468adn%40googlegroups.com.

Re: [sage-devel] Re: Memory leak (quite bad)

[Dima Pasechnik]

is it  related to https://github.com/sagemath/sage/issues/27185 ?
and/or
https://github.com/sagemath/sage/issues/19363

pynac is a worry.

On Thu, 3 Aug 2023, 23:59 Volker Braun,  wrote:

> A quick valgrind run for
>
> from sage.all import sqrt
> T2 = sqrt(2)
> for b in range(num := 100_000):
> C = sqrt(T2)
>
> confirms that it is in pynac:
>
> ==3947957== 799,912 bytes in 99,989 blocks are definitely lost in loss
> record 1,299 of 1,300
> ==3947957==at 0x484182F: malloc (vg_replace_malloc.c:431)
> ==3947957==by 0x1A6D3B07: sig_malloc (memory.c:1898)
> ==3947957==by 0x1A6D3B07: __pyx_f_4sage_3ext_6memory_sage_sig_malloc
> (memory.c:1517)
> ==3947957==by 0x13D0EC2B: ???
> ==3947957==by 0x13D0FEFD: ???
> ==3947957==by 0x1FBA2393:
> GiNaC::numeric::integer_rational_power(GiNaC::numeric&, GiNaC::numeric
> const&, GiNaC::numeric const&) (numeric.cpp:1621)
> ==3947957==by 0x1FBA266D:
> GiNaC::numeric::integer_rational_power(GiNaC::numeric&, GiNaC::numeric
> const&, GiNaC::numeric const&) (numeric.cpp:1614)
> ==3947957==by 0x1FBA94DC: GiNaC::rational_power_parts(GiNaC::numeric
> const&, GiNaC::numeric const&, GiNaC::numeric&, GiNaC::numeric&, bool&)
> (numeric.cpp:1692)
> ==3947957==by 0x1FBAA2AF: GiNaC::numeric::power(GiNaC::numeric const&)
> const (numeric.cpp:1916)
> ==3947957==by 0x1FBBA918: GiNaC::power::eval(int) const (power.cpp:536)
> ==3947957==by 0x1FB09107: GiNaC::ex::construct_from_basic(GiNaC::basic
> const&) (ex.cpp:923)
> ==3947957==by 0x1FBB9D89: ex (ex.h:314)
> ==3947957==by 0x1FBB9D89: GiNaC::power::eval(int) const (power.cpp:507)
> ==3947957==by 0x1FB09107: GiNaC::ex::construct_from_basic(GiNaC::basic
> const&) (ex.cpp:923)
> ==3947957==
>
> On Wednesday, July 5, 2023 at 5:24:27 PM UTC+2 Gonzalo Tornaria wrote:
>
>> This slowly and inexorably goes on. Computing `sqrt(T2)` leaks 32 bytes
>> each and every time (asymptotically).
>>
>> Found by a student who, through no fault of himself, brought down our
>> server (unable to ssh in until the OOM triggered -- but since the leak is
>> slow it takes a while to trash 16G of swap).
>>
>> ===
>> $ cat memleak.py
>> from sage.all import sqrt
>> T2 = sqrt(2)
>> import psutil
>> ps = psutil.Process()
>> base = ps.memory_info().rss
>> for a in range(1, 10):
>> for b in range(num := 100_000):
>> C = sqrt(T2)
>> mem = ps.memory_info().rss - base
>> print(f"{mem/1e6 :.2f} MB ({mem/a/num :.2f} bytes/iter)")
>> $ sage memleak.py
>> 2.70 MB (27.03 bytes/iter)
>> 5.95 MB (29.74 bytes/iter)
>> 9.19 MB (30.64 bytes/iter)
>> 12.44 MB (31.09 bytes/iter)
>> 15.41 MB (30.82 bytes/iter)
>> 18.65 MB (31.09 bytes/iter)
>> 21.90 MB (31.28 bytes/iter)
>> 25.14 MB (31.43 bytes/iter)
>> 28.39 MB (31.54 bytes/iter)
>> ===
>>
>> Replace the 10 in the outer loop by something larger at your own peril
>> (each outer iteration will take 3.2M so 10_000 should kill a laptop in an
>> hour or two).
>>
>> This is with system sagemath 10.0 but it also happens with 9.6, 9.7, 9.8
>> and 10.0 in cocalc.com.
>>
>> Best,
>> Gonzalo
>>
>> --
> 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/eb17a08e-1576-4ab6-b09a-8333e3d55caan%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/CAAWYfq2%3DTam5MdjGAdEdeuht1f0eKX01qdswRS2CvU6H0ZhoLw%40mail.gmail.com.

[sage-devel] Re: Memory leak (quite bad)

[Volker Braun]

A quick valgrind run for 

from sage.all import sqrt
T2 = sqrt(2)
for b in range(num := 100_000):
C = sqrt(T2)

confirms that it is in pynac:

==3947957== 799,912 bytes in 99,989 blocks are definitely lost in loss 
record 1,299 of 1,300
==3947957==at 0x484182F: malloc (vg_replace_malloc.c:431)
==3947957==by 0x1A6D3B07: sig_malloc (memory.c:1898)
==3947957==by 0x1A6D3B07: __pyx_f_4sage_3ext_6memory_sage_sig_malloc 
(memory.c:1517)
==3947957==by 0x13D0EC2B: ???
==3947957==by 0x13D0FEFD: ???
==3947957==by 0x1FBA2393: 
GiNaC::numeric::integer_rational_power(GiNaC::numeric&, GiNaC::numeric 
const&, GiNaC::numeric const&) (numeric.cpp:1621)
==3947957==by 0x1FBA266D: 
GiNaC::numeric::integer_rational_power(GiNaC::numeric&, GiNaC::numeric 
const&, GiNaC::numeric const&) (numeric.cpp:1614)
==3947957==by 0x1FBA94DC: GiNaC::rational_power_parts(GiNaC::numeric 
const&, GiNaC::numeric const&, GiNaC::numeric&, GiNaC::numeric&, bool&) 
(numeric.cpp:1692)
==3947957==by 0x1FBAA2AF: GiNaC::numeric::power(GiNaC::numeric const&) 
const (numeric.cpp:1916)
==3947957==by 0x1FBBA918: GiNaC::power::eval(int) const (power.cpp:536)
==3947957==by 0x1FB09107: GiNaC::ex::construct_from_basic(GiNaC::basic 
const&) (ex.cpp:923)
==3947957==by 0x1FBB9D89: ex (ex.h:314)
==3947957==by 0x1FBB9D89: GiNaC::power::eval(int) const (power.cpp:507)
==3947957==by 0x1FB09107: GiNaC::ex::construct_from_basic(GiNaC::basic 
const&) (ex.cpp:923)
==3947957== 

On Wednesday, July 5, 2023 at 5:24:27 PM UTC+2 Gonzalo Tornaria wrote:

> This slowly and inexorably goes on. Computing `sqrt(T2)` leaks 32 bytes 
> each and every time (asymptotically).
>
> Found by a student who, through no fault of himself, brought down our 
> server (unable to ssh in until the OOM triggered -- but since the leak is 
> slow it takes a while to trash 16G of swap).
>
> ===
> $ cat memleak.py 
> from sage.all import sqrt
> T2 = sqrt(2)
> import psutil
> ps = psutil.Process()
> base = ps.memory_info().rss
> for a in range(1, 10):
> for b in range(num := 100_000):
> C = sqrt(T2)
> mem = ps.memory_info().rss - base
> print(f"{mem/1e6 :.2f} MB ({mem/a/num :.2f} bytes/iter)")
> $ sage memleak.py 
> 2.70 MB (27.03 bytes/iter)
> 5.95 MB (29.74 bytes/iter)
> 9.19 MB (30.64 bytes/iter)
> 12.44 MB (31.09 bytes/iter)
> 15.41 MB (30.82 bytes/iter)
> 18.65 MB (31.09 bytes/iter)
> 21.90 MB (31.28 bytes/iter)
> 25.14 MB (31.43 bytes/iter)
> 28.39 MB (31.54 bytes/iter)
> ===
>
> Replace the 10 in the outer loop by something larger at your own peril 
> (each outer iteration will take 3.2M so 10_000 should kill a laptop in an 
> hour or two).
>
> This is with system sagemath 10.0 but it also happens with 9.6, 9.7, 9.8 
> and 10.0 in cocalc.com.
>
> Best,
> Gonzalo
>
>

-- 
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/eb17a08e-1576-4ab6-b09a-8333e3d55caan%40googlegroups.com.

[sage-devel] Re: Can we get rid of the "Consider using a block-scoped tag" warning?

[Matthias Koeppe]

On Thursday, August 3, 2023 at 9:54:53 AM UTC-7 Volker Braun wrote:

The test output is full of "Warning: Consider using a block-scoped tag by 
inserting the line...", making it hard to see where the actual error is. 

Whats the purpose of this? Is somebody working on converting the magic 
comments?


Yes, for example in https://github.com/sagemath/sage/pull/36026

Help with this is welcome, in particular for files that are not already 
fixed in https://github.com/sagemath/sage/pull/35095

The improved "sage -fixdoctests" tool assists with it: 
https://github.com/sagemath/sage/wiki/Sage-10.1-Release-Tour#sage--fixdoctests

-- 
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/9edabe37-b7c4-4e21-a618-cf3b0d0aabb7n%40googlegroups.com.

[sage-devel] Can we get rid of the "Consider using a block-scoped tag" warning?

[Volker Braun]

The test output is full of "Warning: Consider using a block-scoped tag by 
inserting the line...", making it hard to see where the actual error is. 

Whats the purpose of this? Is somebody working on converting the magic 
comments? Should the warning be unconditionally removed? Can it at least be 
filtered out when running "/sage -t --all --long --only-errors"? Its 
--only-errors, not --only-errors-and-docstring-warnings ;)


-- 
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/41a76ce9-ced3-4bd8-94ea-b2ea38259b27n%40googlegroups.com.

[sage-devel] Re: Synchronization of GitHub state and priority labels starts on Tuesday July 18th

[seb....@gmail.com]

I've added a comment 
 to 
issue 
#35927  to enable a next 
step accordingly. More information about what will change in this step can 
be found there.


Kwankyu Lee schrieb am Donnerstag, 3. August 2023 um 01:23:16 UTC+2:

> Personally, I want the feature to keep at most one status(state) label for 
> a PR, so that if a person add a new status label (say "positive review"), 
> then the old one ("needs review") is automatically removed. Currently it is 
> annoying to do this manually.  

-- 
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/63e8eea1-48b6-464f-aa6a-c079aa607982n%40googlegroups.com.