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
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
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
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
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
>
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
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
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
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
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
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())
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
12 matches
Mail list logo
