[sage-devel] Re: WeakValueDictionary: items are deleted too soon
On 2018-03-12, Nils Bruin wrote: > Your example doesn't convince me at all that we need this change though. > You should only consider making a change if you have a real-world example > that would significantly benefit and if you can show that degradation in > other normal use is minimal. A simplistic "timeit" statement, although > instructive, does not necessarily illustrate real-world usage. +1 Kind regards, Simon -- 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] Re: A little Python 3 status update
by the way, is there a python3 meta-ticket? I can't find it. On Friday, December 1, 2017 at 9:16:04 AM UTC, Frédéric Chapoton wrote: > > Great ! I am impatient that the 24 positive-reviewed tickets for python3 > get closed, so that we can move forward again safely. > > Le mercredi 29 novembre 2017 17:20:33 UTC+1, Erik Bray a écrit : >> >> Just achieved a result I've been trying to get to pretty much since >> diving into helping with the Python 3 port of Sage: >> >> $ ./sage -t src/sage/doctest/ >> too many failed tests, not using stored timings >> Running doctests with ID 2017-11-29-16-09-22-b19471aa. >> Git branch: u/embray/python3/doctest-fixes >> Using --optional=mpir,python2,sage >> Doctesting 11 files. >> sage -t src/sage/doctest/util.py >> [141 tests, 1.30 s] >> sage -t src/sage/doctest/external.py >> [38 tests, 1.62 s] >> sage -t src/sage/doctest/__init__.py >> [0 tests, 0.00 s] >> sage -t src/sage/doctest/fixtures.py >> [59 tests, 1.18 s] >> sage -t src/sage/doctest/sources.py >> [366 tests, 2.16 s] >> sage -t src/sage/doctest/all.py >> [0 tests, 0.00 s] >> sage -t src/sage/doctest/reporting.py >> [111 tests, 1.41 s] >> sage -t src/sage/doctest/parsing.py >> [271 tests, 2.39 s] >> sage -t src/sage/doctest/control.py >> [198 tests, 18.71 s] >> sage -t src/sage/doctest/forker.py >> [450 tests, 106.73 s] >> sage -t src/sage/doctest/test.py >> [23 tests, 51.69 s] >> -- >> All tests passed! >> -- >> Total time for all tests: 246.0 seconds >> cpu time: 24.2 seconds >> cumulative wall time: 187.2 seconds >> >> >> This required a number of (mostly little) fixes to the doctest >> framework itself, miscellaneous support frameworks, and a large chunk >> of the rest of Sage (since the test suite for sage.doctest itself runs >> the tests for a few modules as part of its self-test). I haven't made >> tickets for all these fixes yet either, so you won't be able to >> reproduce this outside my private branch just yet. >> >> But having a test runner whose results can be somewhat relied on >> should allow for rapid progress on the rest of the work needed for >> Python 3 support, since running the test suites for individual modules >> and/or entire packages will make it easier to pinpoint where work is >> needed. I'll keep working to organize my existing fixes into a >> reasonable set of patches so that the doctest runner is working for >> everyone. Then perhaps we can organize a little Python 3 bug bash. >> >> Best, >> Erik >> > -- 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] Re: Failing patchbot due to PCRE tests
FYI - I also tried to build this on Cygwin64 last night and got stuck at PCRE. 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 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] Re: WeakValueDictionary: items are deleted too soon
On Monday, March 12, 2018 at 9:58:39 AM UTC, Jeroen Demeyer wrote:
>
> There is some very bad behaviour related to CachedRepresentation caching
> that I'm observing on #24742 (but this is otherwise unrelated to that
> ticket):
>
> sage: timeit('MatrixSpace(ZZ,3,3)')
> 625 loops, best of 3: 117 µs per loop
>
> Now, we try again but we first create a strong reference:
>
> sage: S = MatrixSpace(ZZ,3,3)
> sage: timeit('MatrixSpace(ZZ,3,3)')
> 625 loops, best of 3: 4.13 µs per loop
>
> This is much faster the second time! In the first example, the caching
> of CachedRepresentation.__classcall__ is pointless since there is no
> strong reference to the entry in the cache, so it gets deleted
> immediately whenever the "MatrixSpace(ZZ,3,3)" is deleted.
>
> This is just the usual Py_DECREF of Python objects, it has nothing to do
> with the cyclic garbage collector: the behaviour remains the same even
> with gc.disable().
>
> This makes me think that we might need a version of CachedRepresentation
> which keeps semi-strong references: these would only be deleted by the
> cyclic garbage collector but not by a simple Py_DECREF().
>
> This is extremely easily done: let the object store a reference to itself.
That makes it part of a cycle, and hence a decref won't delete it.
It doesn't sound like the right solution to me though: if you think the
system benefits from keeping certain recently constructed objects around,
they should probably be part of an LRU cache.
Your example doesn't convince me at all that we need this change though.
You should only consider making a change if you have a real-world example
that would significantly benefit and if you can show that degradation in
other normal use is minimal. A simplistic "timeit" statement, although
instructive, does not necessarily illustrate real-world usage.
I'm happy to see certain objects are now quickly disappearing from memory!
we usually have the opposite problem, and that really grinds things to a
halt.
>
> Jeroen.
>
--
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] Re: Failing patchbot due to PCRE tests
On Monday, March 12, 2018 at 1:46:46 PM UTC, Erik Bray wrote: > > On Mon, Mar 12, 2018 at 2:42 PM, Erik Bray > wrote: > > The Ubuntu 14.04 patchbot "Arando" (I'm not exactly sure who this one > > belongs to) has been failing consistently ever since #24628 [1]: > > > > > https://patchbot.sagemath.org/log/24508/Ubuntu/14.04/i686/3.13.0-95-generic/arando/2018-03-11%2001:54:13 > > > > > It seems there are some tests in the PCRE test suite that are not > > passing no matter what on Ubuntu. > > > > I think that's something that needs to be looked into. Maybe it's a > > legitimate failure that needs to be addressed, but I'm also starting > > to wonder if the fix from #24628 wasn't too extreme, if it means > > having to essentially maintain fixes for platform-specific bugs on > > PCRE... > > > > [1] https://trac.sagemath.org/ticket/24628 > > As a followup, my own Ubuntu 14.04 machine passed the PCRE test suite > just fine, so I'm not sure what the problem is on Arando. The `make > check` output doesn't tell us anything about why the test failed. > arando is a 32-bit Linux box, this is the only unusual thing about it. I'm sitting just 2 meters away from it now. Linux arando 3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 17:05:16 UTC 2016 i686 i686 i686 GNU/Linux If you like I can give you access to it. The best way to proceed with PCRE is to use the system's one, I guess. -- 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] Re: Failing patchbot due to PCRE tests
my two previous messages here have been deleted. Weird. On Monday, March 12, 2018 at 1:46:46 PM UTC, Erik Bray wrote: > > On Mon, Mar 12, 2018 at 2:42 PM, Erik Bray > wrote: > > The Ubuntu 14.04 patchbot "Arando" (I'm not exactly sure who this one > > belongs to) has been failing consistently ever since #24628 [1]: > > > > > https://patchbot.sagemath.org/log/24508/Ubuntu/14.04/i686/3.13.0-95-generic/arando/2018-03-11%2001:54:13 > > > > > It seems there are some tests in the PCRE test suite that are not > > passing no matter what on Ubuntu. > > > > I think that's something that needs to be looked into. Maybe it's a > > legitimate failure that needs to be addressed, but I'm also starting > > to wonder if the fix from #24628 wasn't too extreme, if it means > > having to essentially maintain fixes for platform-specific bugs on > > PCRE... > > > > [1] https://trac.sagemath.org/ticket/24628 > > As a followup, my own Ubuntu 14.04 machine passed the PCRE test suite > just fine, so I'm not sure what the problem is on Arando. The `make > check` output doesn't tell us anything about why the test failed. > -- 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] Re: Failing patchbot due to PCRE tests
Interestingly, the message I just posted "has been deleted". What's going on? Arando is a 32-bit Linux system I can get you access to. The bot is run by Jeroen, IIRC. On Monday, March 12, 2018 at 1:46:46 PM UTC, Erik Bray wrote: > > On Mon, Mar 12, 2018 at 2:42 PM, Erik Bray > wrote: > > The Ubuntu 14.04 patchbot "Arando" (I'm not exactly sure who this one > > belongs to) has been failing consistently ever since #24628 [1]: > > > > > https://patchbot.sagemath.org/log/24508/Ubuntu/14.04/i686/3.13.0-95-generic/arando/2018-03-11%2001:54:13 > > > > > It seems there are some tests in the PCRE test suite that are not > > passing no matter what on Ubuntu. > > > > I think that's something that needs to be looked into. Maybe it's a > > legitimate failure that needs to be addressed, but I'm also starting > > to wonder if the fix from #24628 wasn't too extreme, if it means > > having to essentially maintain fixes for platform-specific bugs on > > PCRE... > > > > [1] https://trac.sagemath.org/ticket/24628 > > As a followup, my own Ubuntu 14.04 machine passed the PCRE test suite > just fine, so I'm not sure what the problem is on Arando. The `make > check` output doesn't tell us anything about why the test failed. > -- 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] Re: Failing patchbot due to PCRE tests
On Mon, Mar 12, 2018 at 5:28 PM, Dima Pasechnik wrote: > I have been trying to post a reply to this thread, and was getting > "message is deleted", from different machines in fact. > > Now let me try email interface. Weird. I have no idea why that would be. > Erik, arando is a 32-bit Linux box I can give you access to. Ah, the 32-bitness might have something to do with it. Shall I send you my public key? -- 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] Re: Failing patchbot due to PCRE tests
I have been trying to post a reply to this thread, and was getting "message is deleted", from different machines in fact. Now let me try email interface. Erik, arando is a 32-bit Linux box I can give you access to. -- 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] Proposal : Add pplpy and gmpy2 as standard packages.
On Fri, Mar 9, 2018 at 3:40 PM, jplab wrote: > Hi all, > > Allow me to jump in the discussion as a daily "Sage user" of code using the > ppl backend in the Polyhedron class. > I put the "Sage user" in quotes, because it seems that it was used for > different types of users. > > What's in for the normal strictly routine not-developing user? > > Well, IMHO more transparency about libraries used. Basically, I just figured > out where the wrapper for ppl was(!). > Ok, perhaps I'm ignorant or stupid; but to me, it seems like making pplpy > and gmpy2 standard packages > is not a revolutionary idea that is going to break everything, or is it? > Further, > >> - no Standard Sage user is asked to know or use gmpy2 or pplpy. >>These are respectively used as gmp data transition and backend >>for polyhedra > > > Further, I believe that the strictly routine not-developing user will not > notice the difference as the vast majority > (of the users of sage that I know) are not even aware that there is such a > thing as a "python integer" and a > "Sage integer" and they keep on using Sage despite some of its > incongruities. So if we speak of those users, > I can not really see how any smelly unpleasantness would be laid down on > their heads by making ppl available > through a standard library as opposed to being Cython wrapped. +1 the vast majority of routine users do not care about such implementation details. It is a minority of users who do, and if we retain backwards compatibility at first, and transition instructions, those few users who care (and are generally more advanced) are able to adapt. In the long run it's win-win for everyone. -- 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] Re: Failing patchbot due to PCRE tests
On Mon, Mar 12, 2018 at 2:42 PM, Erik Bray wrote: > The Ubuntu 14.04 patchbot "Arando" (I'm not exactly sure who this one > belongs to) has been failing consistently ever since #24628 [1]: > > https://patchbot.sagemath.org/log/24508/Ubuntu/14.04/i686/3.13.0-95-generic/arando/2018-03-11%2001:54:13 > > It seems there are some tests in the PCRE test suite that are not > passing no matter what on Ubuntu. > > I think that's something that needs to be looked into. Maybe it's a > legitimate failure that needs to be addressed, but I'm also starting > to wonder if the fix from #24628 wasn't too extreme, if it means > having to essentially maintain fixes for platform-specific bugs on > PCRE... > > [1] https://trac.sagemath.org/ticket/24628 As a followup, my own Ubuntu 14.04 machine passed the PCRE test suite just fine, so I'm not sure what the problem is on Arando. The `make check` output doesn't tell us anything about why the test failed. -- 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] Failing patchbot due to PCRE tests
The Ubuntu 14.04 patchbot "Arando" (I'm not exactly sure who this one belongs to) has been failing consistently ever since #24628 [1]: https://patchbot.sagemath.org/log/24508/Ubuntu/14.04/i686/3.13.0-95-generic/arando/2018-03-11%2001:54:13 It seems there are some tests in the PCRE test suite that are not passing no matter what on Ubuntu. I think that's something that needs to be looked into. Maybe it's a legitimate failure that needs to be addressed, but I'm also starting to wonder if the fix from #24628 wasn't too extreme, if it means having to essentially maintain fixes for platform-specific bugs on PCRE... [1] https://trac.sagemath.org/ticket/24628 -- 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] WeakValueDictionary: items are deleted too soon
On Mon, Mar 12, 2018 at 10:58 AM, Jeroen Demeyer wrote:
> There is some very bad behaviour related to CachedRepresentation caching
> that I'm observing on #24742 (but this is otherwise unrelated to that
> ticket):
>
> sage: timeit('MatrixSpace(ZZ,3,3)')
> 625 loops, best of 3: 117 µs per loop
>
> Now, we try again but we first create a strong reference:
>
> sage: S = MatrixSpace(ZZ,3,3)
> sage: timeit('MatrixSpace(ZZ,3,3)')
> 625 loops, best of 3: 4.13 µs per loop
>
> This is much faster the second time! In the first example, the caching of
> CachedRepresentation.__classcall__ is pointless since there is no strong
> reference to the entry in the cache, so it gets deleted immediately whenever
> the "MatrixSpace(ZZ,3,3)" is deleted.
>
> This is just the usual Py_DECREF of Python objects, it has nothing to do
> with the cyclic garbage collector: the behaviour remains the same even with
> gc.disable().
>
> This makes me think that we might need a version of CachedRepresentation
> which keeps semi-strong references: these would only be deleted by the
> cyclic garbage collector but not by a simple Py_DECREF().
I'm not exactly sure what you have in mind here, but you might be
interested in PEP-442 regardless:
https://www.python.org/dev/peps/pep-0442/
--
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] Re: WeakValueDictionary: items are deleted too soon
On 2018-03-12, Simon King wrote: > Hi Jeroen, > > On 2018-03-12, Jeroen Demeyer wrote: >> This is just the usual Py_DECREF of Python objects, it has nothing to do >> with the cyclic garbage collector: the behaviour remains the same even >> with gc.disable(). >> >> This makes me think that we might need a version of CachedRepresentation >> which keeps semi-strong references: these would only be deleted by the >> cyclic garbage collector but not by a simple Py_DECREF(). > > Would that remotely be possible without massive changes to Python > infrastructure? Deeper changes than a monkey patch to gc.collect seem not to be needed, see #24954. Best regards, Simon -- 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] Re: WeakValueDictionary: items are deleted too soon
Hi Jeroen, On 2018-03-12, Jeroen Demeyer wrote: > This is just the usual Py_DECREF of Python objects, it has nothing to do > with the cyclic garbage collector: the behaviour remains the same even > with gc.disable(). > > This makes me think that we might need a version of CachedRepresentation > which keeps semi-strong references: these would only be deleted by the > cyclic garbage collector but not by a simple Py_DECREF(). Would that remotely be possible without massive changes to Python infrastructure? Best regards, Simon -- 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] WeakValueDictionary: items are deleted too soon
I created https://trac.sagemath.org/ticket/24954 for this -- 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] WeakValueDictionary: items are deleted too soon
There is some very bad behaviour related to CachedRepresentation caching
that I'm observing on #24742 (but this is otherwise unrelated to that
ticket):
sage: timeit('MatrixSpace(ZZ,3,3)')
625 loops, best of 3: 117 µs per loop
Now, we try again but we first create a strong reference:
sage: S = MatrixSpace(ZZ,3,3)
sage: timeit('MatrixSpace(ZZ,3,3)')
625 loops, best of 3: 4.13 µs per loop
This is much faster the second time! In the first example, the caching
of CachedRepresentation.__classcall__ is pointless since there is no
strong reference to the entry in the cache, so it gets deleted
immediately whenever the "MatrixSpace(ZZ,3,3)" is deleted.
This is just the usual Py_DECREF of Python objects, it has nothing to do
with the cyclic garbage collector: the behaviour remains the same even
with gc.disable().
This makes me think that we might need a version of CachedRepresentation
which keeps semi-strong references: these would only be deleted by the
cyclic garbage collector but not by a simple Py_DECREF().
Jeroen.
--
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] Nauty as a default generator for graphs
On Fri, 9 Mar 2018, David Roe wrote: Will I break something if I change graphs(n) without any additional parameter to use nauty? It did the change at https://trac.sagemath.org/ticket/24951 Sounds good to me. You might add an algorithm keyword to the graphs function, which defaults to nauty. Not sure... It can be done with property=lambda _: True. I think that mostly algorithm-keyword should have a meaning -- there should be a situation where someone would prefer one over the other. On Fri, 9 Mar 2018, 'Martin R' via sage-devel wrote: Besides, it would also be supercool to have a class Graphs analogous to the class Posets, and have the cardinality of the first few layers built in (analogous to Posets(16).cardinality()) I am not sure about that. What should be the meaning of, say "g in graphs(10)" or "g in graphs"? -- Jori Mäntysalo
