[sage-devel] OpenSSL versioning scheme and license: upcoming changes
Read on the openssl-announce mailing list. -- Forwarded message - From: Matt Caswell Date: Wed 2018-11-28 17:06 UTC Subject: [openssl-announce] OpenSSL Versioning and License To: openssl-users, openssl-project, openssl-announce Please see the following blog post about OpenSSL Versioning and License: https://www.openssl.org/blog/blog/2018/11/28/version/ Matt -- openssl-announce mailing list https://mta.openssl.org/mailman/listinfo/openssl-announce -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] memory problem
On Wednesday, November 28, 2018 at 1:48:53 PM UTC-8, Nils Bruin wrote: > > > I'm not sure this is the same memory problem the Martin originally > stumbled on, because there I was not seeing large numbers of objects on the > heap. > Hm, I must have done the original test on a different version of sage. For the original code, I'm seeing the same behaviour. So that means the reference loop might have been introduced relatively recently. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] memory problem
On Wednesday, November 28, 2018 at 12:53:57 AM UTC-8, Jori Mäntysalo wrote:
>
> The code can be made a little shorter:
>
> def check(n):
> while True:
> for P in Posets(n):
> x = P._hasse_diagram.moebius_function(0, n-1)
> print get_memory_usage()
>
> It still has the same error limit, i.e. check(6) works but check(7) does
> not. I played a little with the code, and gc.collect() does not seem to
> make anything. After a little more I got
>
>
I think this code most definitely leaks; also with n=6.
def check(n):
for j in [1..6]:
i = 0
for P in Posets(n):
x = P._hasse_diagram.moebius_function(0, n-1)
i += 1
if i > 2000:
break
print get_memory_usage()
import gc
from collections import Counter
gc.collect()
pre={id(c) for c in gc.get_objects()}
check(6)
gc.collect()
post=Counter(type(o) for o in gc.get_objects() if id(o) not in pre)
sorted(post.iteritems(),key=lambda t: t[1])
finds plenty of HasseDiagram objects on the heap.
You can look at backreference graphs, using "objgraph":
objgraph.show_backrefs([o for o in gc.get_objects() if type(o) is
sage.combinat.posets.hasse_diagram.HasseDiagram][5:6],max_depth=8,filename="graph.dot")
(you may have to experiment with the actual object you take the backrefs
of; not all of them are so well-connected)
You'll quickly see the object is in some "WeakCachedFunction" (a cached
__classcall__). The fact that the reference is found indicates the
HasseDiagram object is a key. Probably the value is something kept alive by
the key. The cache itself of course lives on a class, so has unlimited
lifespan. It will take a little bit more work to dig up the actual place
where the reference loop is made, but hopefully with this information
someone can find it.
I'm not sure this is the same memory problem the Martin originally stumbled
on, because there I was not seeing large numbers of objects on the heap.
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] memory problem
NEW MESSAGE: I got it: breadth_first_search (used in HasseDiagram.is_lequal) leaks. if I use breadth_first_search(i, distance=self.cardinality()) instead, the leak is gone. Martin OLD MESSAGE: I just tried with python3. The code runs. check_bad3(7) allocates roughly 0.5 megabytes per invocation. check_bad3(6) also steadily allocates, but only about 0.1MB. check_bad3(5) even less. So, in fact, in python3 they all leak memory, if that's what a memory leak is. And I made a mistake in my previous message. The same is true for python2, but they leak much less memory. A few 100 runs are necessary so you see it for check_bad3(4), for example. However, as soon as I remove the call to moebius_function, the leak is gone. Martin -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] memory problem
Can you confirm that running check_bad3 above allocates memory without limits? Martin Am Mittwoch, 28. November 2018 20:56:41 UTC+1 schrieb Jori Mäntysalo: > > On Wed, 28 Nov 2018, 'Martin R' via sage-devel wrote: > > > Thank you for looking into this. I think the problem exists also for > the > > following code, however only for n = 8: > > I did some other tests too, but only got confused. Hasse diagrams are just > graphs, I think -- they are not derived from UniqueRepresentation. > > Can this be a bug in Python? Maybe we can make quick modification to > digraph code so that we can create posets with Py3-compiled Sage, and test > that. But all of this is above my knowledge. :=( > > -- > Jori Mäntysalo > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] memory problem
On Wed, 28 Nov 2018, 'Martin R' via sage-devel wrote: Thank you for looking into this. I think the problem exists also for the following code, however only for n = 8: I did some other tests too, but only got confused. Hasse diagrams are just graphs, I think -- they are not derived from UniqueRepresentation. Can this be a bug in Python? Maybe we can make quick modification to digraph code so that we can create posets with Py3-compiled Sage, and test that. But all of this is above my knowledge. :=( -- Jori Mäntysalo
Re: [sage-devel] memory problem
Thank you for looking into this. I think the problem exists also for the following code, however only for n = 8: def check_bad3(n): from sage.graphs.digraph_generators import DiGraphGenerators from sage.combinat.posets.hasse_diagram import HasseDiagram for dig in DiGraphGenerators()(n, is_poset): P = HasseDiagram(dig) x = P.moebius_function(0, n-1) print get_memory_usage() -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Sage 6.7 build error on FreeBSD 12 RC2
the old Sage port to FreeBSD is too old anyway, and used a very ugly libm-related workaround which is not even needed on FreeBSD 12. Currently, with some patches, you can build Sage on FreeBSD 12 from source, but it has few problems, the most glaring of which is a segfault in scipy. See https://trac.sagemath.org/ticket/26249 On Wed, Nov 28, 2018 at 1:41 PM Олег Жаркой wrote: > > sage dont build from ports on FreeBSD 12 x64 > > Hardware: > Core i7-2700k, 32Gb RAM > > OS: > uname -a: > FreeBSD zbsd1 12.0-PRERELEASE FreeBSD 12.0-PRERELEASE r340933 ZBSD-VM amd64 > > -- > 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 post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: doctest quality and patchbots
On 2018-11-28 09:17, E. Madison Bray wrote: +1 There are several tests which, when run in an unusual order, result in random failures. This is obviously a failure of test isolation if nothing else, and such cases *should* be rooted out and fixed. It's not a failure of "test isolation" if nobody ever claimed that tests *are* isolated. The only way to really have test isolation is to run a separate process for each test. We already do that for separate files, but not for individual tests. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] QQbar.simplify() or minpoly() don't work
Hi ! I have a problem with this example: sage: b = (x^7 - 2*x^6 + x^3 - 2*x^2 + 2*x - 1).roots(ring=QQbar)[3][0] sage: b.abs().minpoly() It doesn't terminates ! (In fact it finished a very long tilme after with a pari stack overflow.) (If I do b.abs().simplify(), the result is the same). But if I do this computation in an other way, it works (it takes only a few seconds): sage: b = (x^7 - 2*x^6 + x^3 - 2*x^2 + 2*x - 1).roots(ring=QQbar)[3][0] sage: y = b*b.conjugate() sage: y.simplify() sage: sqrt(y).minpoly() If I don't do the step y.simplify(), the computation doesn't terminates (or at least it takes more than 15min). Computations in QQbar should be improved... Is it possible to make sage use the second way to compute the minpoly of b.abs() ? Paul -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] memory problem
On Sun, 25 Nov 2018, 'Martin R' via sage-devel wrote: I still think that there is something odd going on. I do not understand the following: def check(n): while True: for P in Posets(n): Q = P.with_bounds() x = Q.moebius_function(Q.bottom(), Q.top()) print get_memory_usage() The code can be made a little shorter: def check(n): while True: for P in Posets(n): x = P._hasse_diagram.moebius_function(0, n-1) print get_memory_usage() It still has the same error limit, i.e. check(6) works but check(7) does not. I played a little with the code, and gc.collect() does not seem to make anything. After a little more I got AttributeError: 'FinitePoset_with_category' object has no attribute '_hasse_diagram' from the code! I reset the notebook and tried def check(n): while True: i = 0 for P in Posets(n): x = P._hasse_diagram.moebius_function(0, n-1) i += 1 if i > 2000: break print get_memory_usage() and still get memory leak. But with i > 1000 it works. So it's not about size of poset but the number of them. Weird. -- Jori Mäntysalo
Re: [sage-devel] Re: doctest quality and patchbots
On Fri, Nov 23, 2018 at 4:23 PM Simon King wrote: > > Hi Jeroen, > > On 2018-11-23, Jeroen Demeyer wrote: > > On 2018-11-22 18:45, 'Martin R' via sage-devel wrote: > >> 1) would it be easy and desirable to make the patchbots run tests in > >> random order? > > > > Easy: yes > > Desirable: no, it would create a lot of doctest failures > > ... whose fixing is likely to make Sage run more stably. Afte all, > doctests that fail when being executed in a different order mean that > there are side-effects. And side-effects imply instability. > > So, I'd tend to believe that it is desirable. +1 There are several tests which, when run in an unusual order, result in random failures. This is obviously a failure of test isolation if nothing else, and such cases *should* be rooted out and fixed. There are quite a lot of them though--I've stumbled on them many times but rarely bothered with it myself. But as a matter of principle I agree with the suggestion of running tests in random order and fixing any problems that arise. Perhaps for now there would be too many failures that it shouldn't be the default. But I would definitely encourage anyone who wants to to try to fix some of those failures... -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
