Re: [sage-devel] Python 3 and flushing output from external libraries
On Mon, Sep 9, 2019 at 7:51 PM John H Palmieri wrote: > I am writing to ask for help fixing a Python 3 problem. On some platforms, > there are Python 3 doctest failures in > > - libs/eclib/interface.py (#28454) I believe that this has been fixed upstream, it has certainly been reported by me. Are we using the latest eclib version? > How do we fix this? Note that patching FLINT is not ideal, since it won't > help users who are using the system's version of the library. FLINT's most > recent release was in 2015, so I don't know how much we can expect from > upstream regarding new releases. So maybe the ideal solution would be to get > Python to flush the output from these external libraries. I don't know how to > do this; can anyone else help? Ideally, the upstream library should properly flush when producing output. They should use fflush (in C) or std::endl or std::flush (in C++). I guess that Sage could also do the flushing whenever we return from a library API call. > I'm also curious about what's causing the problem. Is it a bug in Python 3? It's just a completely different implementation of I/O, independent of the C standard I/O library (Python 2 uses the functionality) > Why does it only appear on some platforms? I don't think it should be platform-dependent. Let's not focus on this too much. PS: apologies for the quick and short email, I need to sleep ;-) -- 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/CALZ1QMq96G7RL1cRONNKSUx4KVt%2B6Ni6V%2BzC%3DN3cxyGCB1YkCA%40mail.gmail.com.
Re: [sage-devel] The opportunity of Python 3 migration
On Sun, Sep 1, 2019 at 9:14 PM Thierry wrote: > It should also take into account some deep changes in the logic. I agree in general. But in my opinion, it's mostly independent of porting Sage to Python 3. We could do those changes now or next year, it doesn't really matter. -- 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/CALZ1QMoCDp0_xRq%3DBcDs%3Dz9vUfrTW_OLevEkrCkCgX%3D7MkLXhA%40mail.gmail.com.
Re: [sage-devel] Re: Wrong python in Sage shell?
On Thu, Aug 29, 2019 at 6:02 PM Samuel Lelievre wrote: > Possibly somewhat related (sorry if not): after building Sage > for Python 3, running `sage -t` lets the doctesting framework > decide what to set `optional` to, and apparently it uses > "python2" rather than "python3"; is this the desired behaviour? Yes, "python2" is installed as optional package and this is simply running tests for that optional package. There aren't any such tests, but the test framework doesn't a priori know that. "python3" is not optional, therefore it's not listed in the --optional options. I agree that it's confusing, but it's not a bug. -- 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/CALZ1QMov-jyy4K2eM32_VAkCQcn6%3DnW3YmD6gNnMJ4Fch0zsSQ%40mail.gmail.com.
Re: [sage-devel] Making Integer and Rational compatible with Python Fraction
On 2019-08-07 15:42, E. Madison Bray wrote: What if, at some point, we just make a Sage release that breaks backwards compatibility? We could, but I don't think that PEP 3141 is worth breaking backwards compatibility for. -- 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/5D4AD707.8050901%40UGent.be.
Re: [sage-devel] Making Integer and Rational compatible with Python Fraction
On 2019-08-06 17:30, TB wrote: sage: plot(lambda x: x.imag + 2) # Works sage: plot(lambda x: x.imag() + 2, (x, -3, 3)) # Empty plot That's "only" an annoyance: you need to use x.imag or x.imag() depending on what x is. That's not a problem of interoperability. And if you really want generic code, you can always write complex(x).imag (at some performance cost). So it's less a problem than Fraction. To add another data point about triggering unexpected computations, numpy.array does have .real and .imag properties. As far as I can see, it doesn't actually use .real or .imag on the objects that it wraps, so again there is no problem here. -- 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/5D4A9F40.9080408%40UGent.be.
Re: [sage-devel] Making Integer and Rational compatible with Python Fraction
On 2019-07-27 18:49, 'Mark Bell' via sage-devel wrote: During Sage Days 100, I experienced an issue with Sage's Integers and Rational not being compatible with Python's built in Fraction class. This made me unable to run my Python code within Sage It would be good to explain better exactly what kind of code you were running and why this is an issue for you. I mentioned this issue to the Python devs and Guido van Rossum basically rejected the problem. He literally said "what real-world problem does that solve?" when talking about letting Python fractions interoperate with Sage fractions, see https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/27?u=jdemeyer If this would be a simple bugfix, I would dismiss Guido's comment as irrelevant. But in this case, there is no easy fix. Every proposed fix is somewhat backwards incompatible and can potentially break stuff. So we should only apply a fix if it will actually solve a real problem that people are encountering. 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5D474869.2040205%40UGent.be.
Re: [sage-devel] Apple deprecates Python
On 2019-06-07 16:38, E. Madison Bray wrote: While I agree it's part of an annoying trend, this is one change I welcome: The Python interpreter shipped in OSX has always *always* been broken and unusable What matters for Sage is: was it sufficiently functional to bootstrap a build of Sage? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5CFA7830.206%40UGent.be. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] A bug due to copying a cython object.
On 2019-05-17 10:02, Kwankyu Lee wrote: What is the proper way to copy a cython object with all its attributes? Write a __copy__ method doing the copy manually. Unless I'm missing a Cython feature that helps with 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5CDE86DA.4090107%40UGent.be. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Dependence of libgd on iconv
On 2019-05-13 16:04, Dima Pasechnik wrote: as Debian does not have iconv in libgd, I assume it's safe to remove the dependence. If that's possible, sure. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5CD97BAB.2050906%40UGent.be. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Dependence of libgd on iconv
On 2019-05-13 15:51, Michael Orlitzky wrote: It's possible to build libgd without iconv as far as I can tell (check CMakeLists.txt) A dependency is not the same as a requirement. If it's used by the package (optional or not), it's almost certainly a dependency. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5CD976F5.30203%40UGent.be. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] --optional=sage,optional missing build and dochtml tags
On 2019-05-09 11:42, Sébastien Labbé wrote: I was expecting the tag list to be the same. The missing ones are build and dochtml. build and dochtml have to be specified explicitly. This is working as intended. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5CD41E0A.5040602%40UGent.be. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Installation of Sage 8.7 crashes in mpc-1.1.0
I think that your environment is too messed up. Why do you have all those environment variables like $CPATH and $LD_LIBRARY_PATH set? That's probably what's causing the breakage. Can you try to build in a clean environment, without setting any such environment variables? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5CD3EF0D.709%40UGent.be. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Installation of Sage 8.7 crashes in mpc-1.1.0
On 2019-05-09 10:55, Vincent Delecroix wrote: Dear Pepijn, Your config.log mentions that you ran $ ./configure --prefix=/home/pwissing/sage-8.7/local --libdir=/home/pwissing/sage-8.7/local/lib --with-gmp=/home/pwissing/sage-8.7/local --with-mpfr=/home/pwissing/sage-8.7/local That's the config.log of mpc, which looks OK. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5CD3ED67.5070901%40UGent.be. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] python3 status report (mi-april of last python2 year)
On 2019-04-15 13:56, Frédéric Chapoton wrote: * An expert is required on src/sage/misc/classcall_metaclass.pyx Is there a ticket for that? -- 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: Compilation error: 'sage/ext/interrupt.pxi' not found
On 2019-04-14 22:42, Mark wrote: include "cysignals/signals.pxi" That's no longer supported. The proper way to use cysignals is from cysignals.signals cimport sig_check # or whatever you need from cysignals -- 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] ImportError: cannot import name SAGE_LOGS
How did you notice that, i.e. why do you need SAGE_LOGS? I'm -1 on restoring SAGE_LOGS, since it's one of those things which confuses build-time and run-time. There should be no need to access the Sage build logs at run-time. On binary installations, there might not even be a logs directory. -- 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] matrix equality and assumptions
On 2019-04-09 16:29, Bill Page wrote: Is this a known problem? Now it is: https://trac.sagemath.org/ticket/27629 -- 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] SystemError: calling remove_from_pari_stack() inside sig_on()
See https://trac.sagemath.org/ticket/27477 -- 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] Regression in Jupyter notebook (Sage 8.7.beta7)
On 2019-03-11 16:42, Eric Gourgoulhon wrote: Shall I open a ticket? Yes and please include the traceback. -- 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] Error in installing Sage8.6 on linux: syntax error
On 2019-03-11 10:42, E. Madison Bray wrote: The spkg-install script (e.g. under local/var/tmp/sage/build/patch-2.7.5/spkg-install) should start with a shebang line like #!/usr/bin/env bash So that should already use the correct shell unless your `bash` is actually something that is not bash-compatible. Could it be a very old version of bash? What's the output of bash --version -- 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] Unhandled SIGSEGV: A segmentation fault occurred.
This is probably https://trac.sagemath.org/ticket/27374 -- 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: How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages
On 2019-03-08 19:18, Volker Braun wrote: * If is optional then add a #warning that it is recommended Yes, it's optional but the hard part is figuring out whether it's supported or not. -- 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] How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages
On 2019-03-08 10:42, Jeroen Demeyer wrote: (*) For some reason, the analogous C header works regardless of MACOSX_DEPLOYMENT_TARGET. Unfortunately, this header is not compatible with C++, so I really need . I just realized that I tried this only with g++ on Linux. With clang++ on OS X, does work. So this avoids needing to mess with MACOSX_DEPLOYMENT_TARGET. I'll also try g++ on OS X (do we still support that actually?). -- 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] How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages
Hello, While working on cysignals, I encounted an issue with $MACOSX_DEPLOYMENT_TARGET. I have a fix, but I don't know if it's good. It's not specific to Sage, but it will affect Sage since cysignals is a Sage package. For cysignals, I'd really like to use MACOSX_DEPLOYMENT_TARGET >= 10.9 since that enables the C++ header (*) which is needed to fix Sage ticket #24288. The tricky part is that not only cysignals itself should be compiled with MACOSX_DEPLOYMENT_TARGET >= 10.9 but also every package using cysignals. I have a solution which adds the command-line flag -mmacosx-version-min=10.9 when compiling cysignals: https://github.com/sagemath/cysignals/commit/17062a64bf5672375982cf295ed93b346b55d680 Thanks to Cython magic, this flag will be passed on to every package that cimports cysignals. This solution seems to work and passes CI tests. These tests are done using Conda, which uses a Python compiled with MACOSX_DEPLOYMENT_TARGET=10.6, which is then used for every Python package (analogous to CFLAGS, distutils uses the value for MACOSX_DEPLOYMENT_TARGET which was used to compile Python). So my question is basically: what could possibly go wrong? One thing which worries me is that the command-line flag -mmacosx-version-min=10.9 overrides the environment variable MACOSX_DEPLOYMENT_TARGET. So if somebody really wanted a higher value for MACOSX_DEPLOYMENT_TARGET than 10.9, it wouldn't work. But I see no solution for this. Jeroen. (*) For some reason, the analogous C header works regardless of MACOSX_DEPLOYMENT_TARGET. Unfortunately, this header is not compatible with C++, so I really need . -- 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] ValueError: filedescriptor out of range in select()
On 2019-03-03 12:46, Simon Brandhorst wrote: Shouldn't the gp session be closed afterwards? After all it is not used/referenced anymore? So that the file descriptor gets freed again? If not what is the recommended way to start computations in gp The recommended way is not to use the GP pexpect interface at all but use the PARI library interface accessed by the "pari" object. What is it that you're *actually* trying to do? -- 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] ValueError: filedescriptor out of range in select()
On 2019-03-03 12:46, Simon Brandhorst wrote: Shouldn't the gp session be closed afterwards? After all it is not used/referenced anymore? But maybe it's not closed *immediately*. It would be interesting to do the same experiment with a time.sleep(0.1) or a gc.collect() in the loop. -- 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] ValueError: filedescriptor out of range in select()
On 2019-03-03 11:48, Vincent Delecroix wrote: Is this supposed to crash Sage? OK, I missed that part. The fact that you run out of file descriptors is not a bug, but the fact that it crashes Sage is a bug. -- 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] ValueError: filedescriptor out of range in select()
On 2019-03-03 11:43, Vincent Delecroix wrote: Could you open a trac ticket? This is definitely a bug (most probably in `interfaces/expect.py`). I wouldn't call it a bug. You're opening 1 independent GP sessions, which each need a few file descriptors. It's normal that you run out of file descriptors after a while. -- 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] What to do with the sys.path security patch?
Since many years, we have patched the Python in Sage with a patch to mitigate some security issues related to sys.path. The security issue is the following: if you run a Python script from a world-writable directory, say a script like /tmp/foo.py this is very insecure since Python will add /tmp as first entry in sys.path. So if the script starts with from __future__ import absolute_import (say) and some evil person creates /tmp/__future__.py then you'll run that code. We added a patch for this in Sage in https://trac.sagemath.org/ticket/13579 and also reported this upstream to CPython at https://bugs.python.org/issue16202 As expected, upstream was not impressed by our patch because it would break backwards compatibility. But we never really tried to discuss it seriously with upstream. If anybody wants to go for that, please do. I won't do this, I've already picked different battles with CPython. As a side remark, let me mention that Perl also had this issue but they fixed it, the current directory is no longer in the include path: https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldelta.pod#Removal-of-the-current-directory-%28%22.%22%29-from-@INC I noticed at Trac #27001 that we don't have this patch in Python 3. The question is: should we? It makes little sense to have it for Python 2 and not for Python 3. So either we drop it from Python 2 or we port it to Python 3. The ideal situation would be that it gets accepted upstream, but for the sake of argument, let's assume that it doesn't get accepted. What should we do then? 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] .an_element() != 0?
On 2019-02-27 15:25, Daniel Krenn wrote: Can I savely assume that S.an_element() of something S (within SageMath) returns an element different from S.zero() if possible (meaning if there are nonzero elements in S)? Personally, I wouldn't assume anything. -- 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: During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()
On 2019-02-27 10:31, Simon Brandhorst wrote: Okay. But I cannot reproduce the error consistently. Post anyways? Yes. The traceback is clear enough. -- 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] flushing stdout during doctests
On 2019-02-26 17:52, John Cremona wrote: I am testing a new version of the standard spkg eclib, see https://trac.sagemath.org/ticket/27360. I am getting doctesting failures caused *only* because of changes in output buffering resulting in the tail end of the output of one command appearing at the beginning of the output of the next. Since this is I/O related, it might make a difference if you redirect stdout and/or stderr to a file. For example, doing ./sage -t somefile.py 2>err.log instead of ./sage -t somefile.py Do you happen to have the *exact* command line that you used to run 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.
Re: [sage-devel] Re: flushing stdout during doctests
On 2019-02-27 09:58, John Cremona wrote: The problem went away after I did "make distclean; make build". Originally what I did after checking out a new branch was (1) put the new tarball into upstream/ (2) edit the file build/pkgs/eclib/package-version.txt (3) issue the magic command which updates the checksum (4) ./sage -i eclib [causes the new eclib to be built OK] (5) make build [rebuilds some cython files which depend on eclib] (6) run tests Surely that should work, so whatever is deciding what needs doing in step (5) is possibly not getting it quite right. First of all, yes that should work. Technically, you don't even need step (4) since the build system will detect that the version changed of eclib. However, I would be quite surprised if build issues would affect the buffering of the output. -- 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: flushing stdout during doctests
On 2019-02-27 08:35, Frédéric Chapoton wrote: This problem is also seen in the python3 patchbot report, as can be found here : https://patchbot.sagemath.org/log/0/Ubuntu/16.04/x86_64/4.4.0-141-generic/atlas/2019-02-24%2011:31:45?short In Python 3, the situation is different because Python implements its own buffering for I/O. In contrast, Python 2 relies on the I/O implementation of the C library. -- 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] flushing stdout during doctests
On 2019-02-26 17:52, John Cremona wrote: I am testing a new version of the standard spkg eclib, see https://trac.sagemath.org/ticket/27360. I am getting doctesting failures caused *only* because of changes in output buffering resulting in the tail end of the output of one command appearing at the beginning of the output of the next. It would be helpful if you could post the branch that you tried on Trac such that others can reproduce 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.
Re: [sage-devel] During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()
Please create a Trac ticket 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.
Re: [sage-devel] `ModuleElement` is forced though `Element` should be enough by the category framework
On 2019-02-26 23:44, Kwankyu Lee wrote: It could be possible to hammer the coercion model to behave more nicely with the category framework, at least with respect to the issue that I raised. By the way, why is it an issue in the first place? Is there any reason why you don't want to inherit from ModuleElement? -- 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] `ModuleElement` is forced though `Element` should be enough by the category framework
On 2019-02-26 21:53, Jeroen Demeyer wrote: I think that you are 100% right but that (as with many things) it is the way it is for historical reasons and it hasn't bothered anyone sufficiently much to change it. Part of the reason why I haven't personally touched _lmul_/_rmul_ (while I did change many other things in the coercion model) is that I never really understood how _lmul_/_rmul_ are supposed to behave precisely. And there are some strange things, especially the "return None if not implemented" part. So the only way to know whether _lmul_ is implemented is to actually call it and look at the result, which is a bit weird. -- 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] `ModuleElement` is forced though `Element` should be enough by the category framework
On 2019-02-26 14:44, Kwankyu Lee wrote: My question is: why should I use `ModuleElement` instead of just `Element`? If I use `Element`, the scalar multiplication is not detected by the coercion system. So I am forced to use `ModuleElement`. Since my parent is in the category of modules over QQ, then I think elements of the parent should be automatically treated as module elements, and using `Element` should just be ok. What do you think? I think that you are 100% right but that (as with many things) it is the way it is for historical reasons and it hasn't bothered anyone sufficiently much to change it. -- 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] strange error message when raising an Error in cython()
You can ignore that "An unexpected error occurred while tokenizing input" message. It's IPython having trouble with the traceback, it has nothing to do with your Cython code. -- 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] strange error message when raising an Error in cython()
On 2019-02-13 11:02, jonathan.kliem via sage-devel wrote: I'm getting a strange error when raising an error in cython(), example: I don't really understand your problem. You ask Cython to raise an exception and the exception is raised. It seems like Cython is doing exactly what it's supposed to do. -- 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] Poll: set online=True as the default for threejs viewer
Why neither nbviewer nor binder are able to find (or serve or ?) these javascript files? The problem is these lines in src/sage/repl/rich_output/backend_ipython.py These paths should be changed to take into account the base URL of the server (don't ask me *how* to do this precisely). -- 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: python3 status report
On 2019-02-11 11:12, David Coudert wrote:
Le mardi 29 janvier 2019 23:19:12 UTC+1, Thierry (sage-googlesucks@xxx)
a écrit :
Hi,
On Sun, Jan 27, 2019 at 11:21:21AM -0800, David Coudert wrote:
[...]
> The most complicated issue is certainly edges of Graph: we sort the
> vertices of an edge before returning it... I have no solution for
this
> issue. We can decide to stop ordering the vertices, but then we
will have
> to update a very large number of algorithms. We could also design
a method
> to compare object of different types.
> In fact, the main issue is that we use and compare vertices by id
instead
> of mapping vertices to integer and work only with these integers.
That
> would ease our life, but it's not easy to change that.
We discussed the difference between mathematical and algorithmic level
various times (for equality, comparison, etc).
Here, at the "algorithmic" level, the vertices are of course
comparable,
and most algorithms in graph theory rely on this (starting by the most
fundamental such as DFS, BFS, etc). Trying to avoid comparison of
vertices would be suicidary, and trying to do that with Sage will just
lead to unreadable artificially complicated code.
If you want an integer label for each vertex, why not just ask to the
backend:
sage: G = graphs.WorldMap()
sage: G
World Map: Graph on 251 vertices
sage: G.vertices()[0]
'Afghanistan'
sage: GG = G._backend.c_graph()[0]
sage: GG
sage: GG.verts()[0]
0
So, somehow, you do not have to map Sage objects back to integers,
since
we already have a map from integers to Sage objects.
I did not check the implementations, but though it is kind of too late
given the size of Sage, i would advocate to have two explicit layers
for
combinatorial objects such as words, graphs, permutations, etc, one
"algorithmic" where the atoms are integers, with all the good
properties, and a "label" dictionary, where we could attach any Sage
object to them for "mathematical" questions. And it would be amazing if
they were an specified way to do that uniformly.
In fact we already have methods to do that, but changing the code to use
these methods is not an easy task...
sage: G = graphs.PetersenGraph()
sage: G.set_vertex(0, 'abc')
sage: G.set_vertex(1, graphs.CycleGraph(3))
sage: print(G.get_vertices())
{0: 'abc', 1: Cycle graph: Graph on 3 vertices, 2: None, 3: None, 4:
None, 5: None, 6: None, 7: None, 8: None, 9: None}
That said, regarding the .edges() method, i think that returning a list
of pairs is a very wrong approach (though this is what is done for
years). Indeed, a list is not only an iterator, but also a
container. In
particular:
(a,b) in G.edges()
is a syntaxially correct statement, but it is far from equivalent to:
G.has_edge(a,b)
Which is extremely misleading and can lead to silent mistakes
(personally, i used lot of hand-made reorderings in my pyograms
before i
discovered has_edge).
Here i would advocate that G.edges() returns a *view* on G, with a
dedicated __iter__ method corresponding to the edge_iterator method and
a __contains__ method corresponding to the has_edge method. By having a
view, you will save a lot of time and memory, and have the benefit that
it will follow the graph's mutations.
This is an interesting idea, although I'm not sure how to implement that
efficiently.
I don't see why it should be inefficient (assuming you implement it in
Cython of course).
--
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] AlarmInterrupt causes Sage to crash hard
On 2019-02-06 20:52, Nils Bruin wrote: This is the same as in python: >>> import signal >>> signal.alarm(1) 0 >>> Alarm clock It looks like this is just the default signal handler for python (the one that just prints the signal name and exits) For the record, that message "Alarm clock" is printed by the shell (bash or whatever) whenever a process that it runs (python in this case) is killed by a signal. It's analogous to the more familiar message "Segmentation Fault". -- 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] AlarmInterrupt causes Sage to crash hard
On 2019-02-07 16:45, E. Madison Bray wrote: Apparently Jeroen argued about this with the IPython developers some time ago: https://github.com/ipython/ipython/pull/9867 Indeed. Your post did seem familiar to me, but I actually forgot about that discussion. -- 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: Trac #22029: Python 3 style comparisons
> Out of curiosity: How many existing tests fail for that reason? We had to fix a *huge* number of issues because of comparing apples and oranges. It was one of the biggest porting efforts towards Python 3, that's why I consider it a big deal. Look at the long list of dependencies on Trac #22029 if you want more details (that list is probably incomplete, not everybody working on comparisons added tickets to that list). -- 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] Trac #22029: Python 3 style comparisons
Trac ticket #22029 changes the coercion model such that comparisons of Element instances now behave like in Python 3. This means that comparisons of elements with uncomparable types/parents will raise an error instead of returning some random answer. I believe that this is an important step in making Sage ready for Python 3. We could have chosen to use Python 2 style comparisons under Python 2 and Python 3 style comparisons under Python 3, but that would inevitably lead to regressions on Python 3. It's best if code behaves as much as possible the same under Python 2 and Python 3. The change in the code is quite small, but the implications are big, so that's why I wanted to mention it here on sage-devel. 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] Patchbot zancara: Disk quota exceeded
There are problems with patchbot zancara: OSError: [Errno 122] Disk quota exceeded: '/home/mi/kliem/.sage/temp/zancara/16740' Full log: https://patchbot.sagemath.org/log/27152/debian/9.6/x86_64/4.9.0-8-amd64/zancara/2019-01-29%2021:56:24 -- 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] documentation of SageMath (Python) packages
On 2019-01-29 09:32, Vincent Delecroix wrote: 1) When a user performs `sage -pip install X`, should the documentation be compiled and installed? I'm pretty sure that the answer is "no" for most Python packages. I see two reasons for this: - there is no easy and obvious way to integrate this in setup.py - it adds extra dependencies (on Sphinx for example) unrelated to the actual functionality of the package -- 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: problem with 8.7.beta1
On 2019-01-28 06:18, Travis Scrimshaw wrote: See possibly https://trac.sagemath.org/ticket/27114. No, it's https://trac.sagemath.org/ticket/27109 -- 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: python3 status report
On 2019-01-27 22:36, Simon King wrote: But do py3 experts agree that to transform os.path.join(...) to char* (which is not in pickling but in module initialisation), I need PyString_...? No! Please see src/sage/cpython/string.pyx (sorry no time now to answer more) -- 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: Sage python3 doctests
On 2019-01-27 19:23, John Cremona wrote: On Sun, 27 Jan 2019 at 17:10, Frédéric Chapoton mailto:fchapot...@gmail.com>> wrote: ok, then --optional=sage,py3 is ok (all doctests pass) whereas ./sage -t --optional=sage,py2 src/sage/modular/cusps_nf.py Is there a particular reason for this file being used as an example here? I wasn't the original poster, but I think not. It's just a random example. -- 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] python3 status report
On 2019-01-27 14:23, Frédéric Chapoton wrote: Some good python3 changes are blocked by the long awaited ticket https://trac.sagemath.org/ticket/23572 What do you mean with that? It's a ticket adding doctests for a book, how is that related to Python 3 porting? -- 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] Native Windows version
On 2019-01-23 00:11, William Stein wrote: I helped support somebody using the Cygwin version of Sage on Windows at the Sage booth at the Joint Math Meetings last week, and it typically took about 1 minute to start up Sage, which was scary. But mathematical computations (which do not involve syscalls) shouldn't be slower, right? -- 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] Build error
The error message seems to imply that you tried to install (part of) Sage as a different user. Maybe the safest option is to delete your installation completely: rm -rf /home/devikasugathan/sage and then try again. -- 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] Upcoming Debian freeze
On 2019-01-13 15:34, Dima Pasechnik wrote: As we see, Debian is already picking up this update. If Debian *already* has it anyway, what's the point of upgrading it in SageMath? Especially if it doesn't require any changes to the Sage library. -- 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] Purpose of XML_RESULTS
Does anybody have any idea what is the purpose of compile_result_dir = os.environ['XML_RESULTS'] in src/setup.py? It was introduced in https://trac.sagemath.org/ticket/9828 in a ticket about upgrading Cython but without explanation... 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] Import issue for Sage when using the system's Python (e.g. Debian)
On 2019-01-10 21:51, 'Julien Puydt' via sage-devel wrote: Didn't François mention changing SAGE_ROOT wasn't needed? He said SAGE_ROOT should only be needed for the packaging system and possibly the doctests. I regard any needs for SAGE_ROOT at runtime a bug. In other words: it is still needed, but that's a bug. And I agree with that. -- 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] Import issue for Sage when using the system's Python (e.g. Debian)
On 2019-01-10 20:46, 'Julien Puydt' via sage-devel wrote:
Le 10/01/2019 à 20:07, François Bissey a écrit :
I have recently made the following change in sage-on-gentoo’s env.py
_add_variable_or_fallback('SAGE_LOCAL', sysconfig.get_config_var("prefix”))
which means SAGE_LOCAL is now pulled from the system rather than
a seeded value (as it was before).
Perhaps upstream would accept such a trivial change?
If you make a ticket for it, sure. But it won't help with SAGE_ROOT.
By the way, why sysconfig.get_config_var("prefix”) instead of sys.prefix?
--
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] libpari defaults
On 2019-01-04 10:22, John Cremona wrote:
Some of the runs I have been doing use a large amount of RAM and some
fail
"fail" in which sense? I assume you mean a PariError saying that the
stack overflowed but I can only guess...
One is suppose to be able to increase this using the following syntax
sage: pari.default('parisizemax', 120)
but that raises a run-time error
That error is actually a PARI "feature". It's one of the many curious
implementation details of the PARI stack. The idea is that you shouldn't
change the stack size during a computation. So the error forces the
running computation to abort.
In GP this error is silenced but you can still see its effect:
gp> a=1; default(parisizemax, 10); a=2
*** Warning: new maximum stack size = 101536 (953.676 Mbytes).
gp> a
%2 = 1
Note that the "a=2" is not executed!
Now to solutions: I would recommend using pari.allocatemem(sizemax=N) to
change the stack size. That is handled a lot better by cypari2.
--
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] hardcoding platform-dependent constants in cython
On 2018-12-22 12:32, Volker Braun wrote: Just avoid premature optimization; Nobody cares if the one-time dlopen() takes a nanosecond longer or not... I agree here... especially for a one-time function call. And even if you do plan to open the GAP library thousands of times per second, you could just compute the filename once and store it. -- 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: Delaying 8.5 or fast-tracking 8.6?
On 2018-12-20 00:12, Dima Pasechnik wrote: How about trying to get this into 8.5? (or perhaps 8.5.1?) Rushing GAP 4.10 in Sage 8.5 doesn't sound like a good idea to me. Ideally, it should be sufficiently tested in betas. -- 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] Delaying 8.5 or fast-tracking 8.6?
I suggest the following: If Sage 8.5 is ready to be released right now, I see no reason to delay that. Then follow up soon with Sage 8.6. On the other hand, if Sage 8.5 is going to dragged for other reasons anyway, then we might as well try to get GAP-4.10 in this release. -- 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] bug in trivial case of number field isomorphism due to wrong pari/sage conversion
On 2018-12-13 13:11, John Cremona wrote: The problem is that t is a pari gen and Sage tries too hard to compare that with python 0. This has nothing to do with Sage or Python, the "problem" is that PARI considers [0] and 0 equal. Personally, I think that Sage (really the package cypari2 which implements the PARI <-> Python interface) should follow the PARI semantics, even if they are dubious. -- 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: Weak references in the coercion model
On 2018-12-06 14:07, Simon King wrote: And if I understand correctly what you said in another post, it is *dynamically* determined which reference is weak and which reference is strong. When is it determined? During cyclic gc? Yes, during GC: that's the only time where it matters. More precisely, it is determined during every tp_traverse loop. With a "tp_traverse loop", I mean a loop of the form for obj in set_of_objects: type(obj)->tp_traverse(obj, visit, arg) where "visit" is constant during the loop (arg does not matter). Does that mean that you change the innards of Python's cyclic gc? No, nothing needs to be patched. It's just a clever way of implementing tp_traverse(). I am making assumptions on how GC works internally: in particular, I am assuming that it's OK to dynamically change the reference graph as long as it's consistent during every individual tp_traverse loop. Hopefully it is explained in #26790; I'll have a look... That's #26811 but that's work in progress. -- 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: Weak references in the coercion model
On 2018-12-06 08:35, Simon King wrote: Then what will be your reference graph? Or phrased differently: Where/how will you store coercion maps? The basic idea is the following (I have not worked out all the details yet): * The coercion model only stores weak references to anything (domains, codomains, actions, maps). * Coercion maps store strong references to the domain and codomain. * The domain and codomain store MultiWeakref references to the map, where one of those references is weak and one is strong. * Analogously for actions, with acting set/underlying set instead of domain/codomain. It might also make sense to consider pairs of coercion maps specially, in cases where arithmetic with A and B gives a totally new parent C and we have maps A -> C and B -> C. I haven't thought about this yet. -- 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: Weak references in the coercion model
On 2018-12-06 01:36, Nils Bruin wrote: Because the coercion map from A to B is also stored on A, a strong reference to B exists. No. The map will be referenced both from A and from B with one of those references weak and one of those references strong, without specifying a priori which one is strong and which one is weak. That's the point of MultiWeakref: as long as we're not garbage collecting, it doesn't matter which reference is strong and which one is weak: only the numbers matter, since that determines the refcount. When garbage collecting, the tp_traverse algorithm of MultiWeakref decides dynamically which reference to consider weak and which strong in a way to maximize the amount of garbage that can be collected. So let's assume that it's weakly referenced from A and strongly referenced from B. (The map will also be referenced from the coercion model, but always weakly; this won't change). Then we have a strong reference cycle from B to the map and back, which does not prevent garbage collection. So, if nothing else holds a reference to B, then both B and the map can be deleted. Anyway, that's the idea. I haven't worked out all the details yet... -- 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: Weak references in the coercion model
On 2018-12-05 18:33, Nils Bruin wrote: I think you were thinking of limiting the life span of c via referencing it via a "MultiWeakRef" from both A and C. However, with the scenario above, A has its life span already bounded below by C anyway, so the "MultiWeakRef" never gets to work its magic. With my idea, the domain and codomain would be treated exactly the same: my plan is to reference the map from both the domain and codomain in a symmetric way. In that way, the lifetime of A wouldn't depend on C the same way that the lifetime of B or C doesn't depend on A. -- 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: Weak references in the coercion model
On 2018-12-05 14:54, Simon King wrote: o Mild problem: If there is an external strong reference to, say, f, then it is possible that Q becomes garbage collected anyway, and we would end up with an invalid map. That is one of the things that I would like to fix: maps and actions should have strong references to their (co)domains. On the other hand, the coercions and actions should be sufficiently weakly referenced to prevent memory leaks but not too weakly referenced to keep them alive when needed. This will rely on #26811. -- 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: Weak references in the coercion model
On 2018-12-05 16:50, Volker Braun wrote: Right, automatic clearing of circular references is only in Python 3... I would phrase that as: properly dealing with __del__ is only in Python 3. Luckily, __del__ is used only very rarely in Sage. -- 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: Weak references in the coercion model
On 2018-12-04 18:06, Nils Bruin wrote: Tripledict does that to some extent (with its keys): if one of the key parts gets deallocated, the weakref callback removes the strong reference to the value. Yes, but then we potentially end up again in the situation where things are *only* weakly referenced. Currently, you still need a strong reference in a fixed place and ideally we shouldn't. I have a very preliminary idea at #26811 to "fix" 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.
Re: [sage-devel] Re: Weak references in the coercion model
On 2018-12-03 17:21, Nils Bruin wrote: In order to make that possible, the coercion map (referenced strongly on the codomain -- it needs to be strongly referenced somewhere to keep it alive) must not hold a strong ref to the domain. I wonder if there is a way to somehow reference an object from a pair of objects: have A and B reference C in such a way that, if either A or B get deallocated, also C gets deallocated. -- 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] Weak references in the coercion model
I am studying the coercion model in detail, looking for optimization opportunities. One source of slow-down is the use of weak references. Over time, more and more places in Sage use weak references. But I'd like to look at the big picture and see where weak references should be used and where not. Take coercion maps for example. The coercion model stores a weak reference to the coercion maps and the maps also store a weak reference to the domain (but not the codomain). It's not clear to me why this double weak reference is needed, but maybe I'm missing something. It seems more logical to use strong references in the coercion map but then store a weak reference to the map. I'd like to "fix" this with action maps first, which are conceptually simpler. 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] Faster coercions!
This week I worked on the coercion model to make it faster. It turns out
that there was some margin for micro-optimizations. There are two
tickets in need of review: #26776 and #26790.
If you need to be convinced, run
sage: a = RR(25); b = ZZ(2)
sage: timeit('a+b', repeat=100, number=10)
*Before*:
10 loops, best of 100: 756 ns per loop
*After*:
10 loops, best of 100: 636 ns per loop
This is a very nice gain for every single coercion(!) in Sage.
--
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-29 10:38, E. Madison Bray wrote: But I sometimes get failures in tests depending on which order the *files* were run in. That's what I'm talking about. But that's really unusual (and unrelated to --randorder). Do you have *any* concrete example of such a failure? -- 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.
Re: [sage-devel] doctest quality and patchbots
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 2) concerning https://trac.sagemath.org/ticket/26586, is it desirable to define comparison for `CartesianProduct`? Absolutely. If you do that, you should open a new ticket. 3) at first I thought that it is good practise to sort output whose order is essentially random I agree. 5) would it be a good idea to have `__repr__` use a "sorted output" for objects that are sets from a mathematical perspective? I would say yes, but this wouldn't really solve the problem since the function returns a list, which is not sorted. It's important to note that such sorting should be restricted to __repr__. For example, the method Poset.upper_covers() should not sort, for 2 reasons: (a) not all objects can be sorted, this is in particular a problem in Python 3 (see graphs for a bad example) (b) performance: most of the time, you don't care about ordering -- 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] doctest quality and patchbots
On 2018-11-22 18:45, 'Martin R' via sage-devel wrote: * The tests of individual functions within a single file are ALL executed in the same environment. Same "environment" in the sense of same Python process (there is one process for each file to be tested). But global variables are reset for each doctest block. * The tests of the individual functions within a single file are executed in random order. This is false. Tests are run in order. -- 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] Jupyterhub kernel and SAGE_ROOT
On 2018-11-06 19:07, François Bissey wrote: SAGE_LOCAL is another story, however we probably could figure it out from the python configuration rather than a seed. Isn't SAGE_LOCAL == sys.prefix -- 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: openssl licensing
The license has not been updated yet in their git repo: https://github.com/openssl/openssl/blob/master/LICENSE I also downloaded the latest release (1.1.1) and it still contains the bad BSD license. So it seems that the license change is not official yet... -- 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: refresh the banner
On 2018-10-31 22:23, Volker Braun wrote: With ipython/jupyter you can't run the notebook in the current Python session, but you can just launch a completely new process. Are you sure? Can't you just import the Jupyter application as a Python package and run it that way? I have not tried it though... -- 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: git fetch fails
On 2018-10-21 11:57, Volker Braun wrote: Try "git remote prune origin" or "git remote update origin --prune" Thanks. The first one worked. -- 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] git fetch fails
Any ideas? error: cannot lock ref 'refs/remotes/trac/u/embray/python3/sage-rings-polynomial-polydict/misc': 'refs/remotes/trac/u/embray/python3/sage-rings-polynomial-polydict' exists; cannot create 'refs/remotes/trac/u/embray/python3/sage-rings-polynomial-polydict/misc' From trac.sagemath.org:sage ! [new branch] u/embray/python3/sage-rings-polynomial-polydict/misc -> trac/u/embray/python3/sage-rings-polynomial-polydict/misc (unable to update local ref) -- 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] Smith Normal Form over ZZ seriously slow
Part of the problem (but certainly not all of it) is https://trac.sagemath.org/ticket/26463 Sage was executing "from sage.rings.integer import Integer" 100 times. -- 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: Smith Normal Form over ZZ seriously slow
Actually, I think that it's the .sage() call which is already taking a long time: sage: M = MatrixSpace(ZZ,1000,5).random_element() sage: %time res = M.__pari__().matsnf(1) CPU times: user 68 ms, sys: 0 ns, total: 68 ms Wall time: 68.7 ms sage: %time v = res.sage() CPU times: user 4.03 s, sys: 23 ms, total: 4.05 s Wall time: 4.05 s -- 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] snappy in Sage
On 2018-10-02 23:01, Dima Pasechnik wrote: So you need to ship generated C files for C99, C11, and C++ files for c++11, c++14, c++17, blah++foo, etc etc etc? No. You *do* need to tell Cython the language (C or C++). But beyond that, it generates code compatible with any version of the C/C++ standards. -- 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] snappy in Sage
On 2018-10-02 17:53, Dima Pasechnik wrote: Letting Cython to do necessary adjustments for the target C/C++ compiler seems like the most natural thing to do... Cython doesn't need to do any such "necessary adjustments". It's completely independent of C/C++ compilers (and it should be). -- 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] snappy in Sage
On 2018-10-02 16:50, kcrisman wrote: Thanks, Thierry. Sounds like we need a ticket for this. I assume you mean a Snappy ticket since the problem with Snappy is completely unrelated to Sage. Note also (in general) that You are using pip version 9.0.3, however version 18.0 is available. You should consider upgrading via the 'pip install --upgrade pip' command. though perhaps this is fixed in 8.4beta? Yes. -- 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] snappy in Sage
On 2018-10-01 20:19, kcrisman wrote:
new = max(os.path.getmtime(file) for file in
glob('cython/core/*.pyx'))
ValueError: max() arg is an empty sequence
It's bad packaging by upstream: it's running Cython but the Cython
source files are not in the snappy source tarball.
--
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] semantics of ... in doctests
On 2018-09-26 16:48, 'Martin R' via sage-devel wrote: Indeed, it seems that the test is not actually being run. You mean that it *was* not actually being run, but now it is. I don't know what caused the change, but it's clearly in the good sense since that doctest should be run. -- 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] semantics of ... in doctests
On 2018-09-26 13:03, 'Martin R' via sage-devel wrote: and all tests pass. Which command are you using to run the tests? Something might have changed there. -- 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 foundation ???
On 2018-09-24 18:00, Dima Pasechnik wrote: Perhaps the most tricky is 2 (or perhaps not anymore, after out infamous CoC discussion fiasco we could agree it makes sense to get something in place; we can have a look at https://numfocus.org/code-of-conduct and see if we can just agree to this) Speaking of Code of Conducts, there has recently been a CoC incident in the Python community where somebody was banned permanently after a single controversial post on a mailing list [1]. Personally, I think that this is huge overreaction (at most a warning or a temporary ban would have been in order) and it shows that a CoC can be used as an excuse to take such actions. That incident certainly makes me less supportive of having a CoC. [1] https://mail.python.org/pipermail/python-ideas/2018-September/053602.html -- 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] semantics of ... in doctests
On 2018-09-26 10:10, 'Martin R' via sage-devel wrote: In https://trac.sagemath.org/ticket/26348 a doctest is failing, because apparently the semantics of "..." has changed. I don't think that anything has changed here. As far as I know, "..." at the start of a line after a "sage:" line has always been interpreted as a continuation. -- 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] Deprecate and remove/relocate explain_pickle module?
It must be said that I found this tool quite valuable. When unpickling goes wrong, it is typically not easy to find out why and explain_pickle does help with that. That being said, if nobody wants to maintain it, it has to go (with praise, as you said)... -- 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: Question on the features introduced by #20382
On 2018-09-12 07:42, Simon King wrote: However, the place in #25090/#25091 where the author uses is_package_installed, is a Python file. Why does a Python file care whether the normaliz library and headers are installed? Now I'm looking at #25091 and it seems to me (but correct me if I'm wrong) that you *really* care about the PyNormaliz Python module, for which there is a different feature test. The whole idea of the new features framework is to make the feature test as close as possible to the actual usage of the feature. We don't check for the presence of a Sage package, we check whatever feature that you need from that Sage package. For example, if it's a Python module, we try to import it. Another way of seeing this: ask the question what would go wrong if the package wasn't installed but we skipped the feature check? That thing where it goes wrong is what you need to test for. -- 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] Question on the features introduced by #20382
On 2018-09-11 18:55, Simon King wrote: Specifically, I ask because of #25090/#25091: How can one test whether normaliz is installed? Use Cython: see src/sage/features/bliss.py for an example for the "bliss" library -- 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] QQ not isomorphic to itself?!
On 2018-09-10 21:36, John Cremona wrote: The bug is because of this: Since you almost fixed this bug, could you actually create a ticket to fix it? -- 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] Can't compile 8.4.beta3
On 2018-09-06 08:21, Andrew wrote: *package:pip-18.0 log file:/usr/local/src/sage/logs/pkgs/pip-18.0.log attach this log file please ^ -- 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: Enabling Merge Requests from GitLab
Let me make one important comment (something that I've said before though): a large part of what makes the current workflow work is not so much Trac itself but our git server and the "git trac" scripts. For example, I very much like the fact that we have a single git repo where all pull requests appear. Checking out a pull request for reviewing is so much easier with Sage than it is with typical GitHub projects. If we ever move to GitLab, we really should keep this workflow. -- 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: Enabling Merge Requests from GitLab
On 2018-09-03 15:53, Erik Bray wrote: P.S. If anyone has additional comments, positive or negative, on https://trac.sagemath.org/ticket/25914 they would be most appreciated That doesn't seem the right 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 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.
