Re: [sage-devel] Possible Cython bug
See https://github.com/cython/cython/issues/1807 -- 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] Possible Cython bug
It is a Cython bug.
Most simple example:
sage: %%cython
: def get(obj, int i):
: return obj[i]
sage: class D(dict): pass
sage: d = D([(-1, "hello")]); d
{-1: 'hello'}
sage: get(d, -1)
...
KeyError: 0
sage: d[-1]
'hello'
--
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 (not yet, and not for soon)
On 2017-08-07 12:00, François Bissey wrote: Looking at this more closely. Why isn’t the “bytes” conversion done earlier - before checking that the file exists. +1 I know that Erik Bray will disagree with this, but I would advocate to use "bytes" as much as possible when dealing with filenames. -- 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: Possible Cython bug
On 2017-08-04 10:49, Vincent Delecroix wrote: Indeed, this is a subtle issue Cython thinks that F is a sequence because Family does support the sequence protocol (this is lost somewhere in the macro __Pyx_GetItemInt). As a consequence, Cython translates a negative index "-i" into "len(sequence) - i". Which is indeed wrong in the above case... Cython should have called PyObject_GetItem. I can try to write a Cython bug report if nobody has done that already. -- 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: What exactly is R.gens() suposed to return?
On 2017-07-27 17:55, Travis Scrimshaw wrote: TL;DR One of the biggest questions for me is should gens for a polynomial ring with 0 variables return (1,) or ()? I think consistency within polynomial rings is important (more than consistency with other rings). So, it is obvious to me that the only correct answer is (). -- 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-packaging] Re: [sage-devel] Upgrade PARI to git master
On 2017-07-26 00:46, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: Would it be worth creating a fork of PARI What *exactly* do you mean with that? I feel like "fork" is just a word and you can already consider the PARI-in-Sage to be a fork of PARI. you would avoid the problems of a distribution not accepting a git-master copy. I'm not convinced that distributions would accept a fork either (again, this may depend on the precise meaning of "fork"). For example, distros generally use GMP instead of the fork MPIR that Sage uses. -- 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] Upgrade PARI to git master
I just created two tickets: - https://trac.sagemath.org/ticket/23543 for upgrading to the latest official bugfix release - https://trac.sagemath.org/ticket/23544 for upgrading to git master -- 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] Upgrade PARI to git master
On 2017-07-25 22:28, William Stein wrote: +1 -- there were a lot of people at Sage Days last week asking about feasibility of making a Pari-master package, since pari stable is so old, and they really needed things in the newers version of Pari. Interesting. Do you happen to know which features of pari-master were asked 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.
[sage-devel] Re: [sage-packaging] Upgrade PARI to git master
On 2017-07-25 22:34, Ximin Luo wrote: Do you think it would be feasible for Sage "standard" to maintain compatibility with both PARI stable and the development version? I have not actually tried, so it is hard to tell right now. Given the past history of the PARI package inside Sage, I expect that we will regularly upgrade PARI in Sage to future git master versions. Every time, the difference with the stable version increases and the chance of compatibility decreases. So even if we are compatible now, there is no guarantee that this will remain the case in the future. Moreover, we do not have machinery in place to check this compatibility: I can do it for this upgrade, but it might easily be forgotten the next time. Everything also depends on how you define "compatibility". There might be a large difference between "Sage builds and works" and "all doctests pass". The first one is much more likely than the second one. 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] Upgrade PARI to git master
Hello sage-devel and sage-packaging, I propose to upgrade the PARI package to the git master version instead of the current released version. The main motivation for me is to use the new plotting engine for the PARI Jupyter kernel. The plotting engine has changed a lot since the stable release. This is split into many commits and it affects even the build system, so I think it would be too much work to do this with a patch. Currently, I do have plotting support in my PARI Jupyter kernel, but it requires patches which were written by me but substantially changed by upstream PARI. So it doesn't work with any upstream version of PARI and I want to fix this. In the current stable release, plotting is implemented only in the GP command line program, not in the PARI library. So a stable release cannot work for me. A second motivation is that stable releases of PARI are very slow. The most recent stable PARI releases (excluding bugfix releases) were in november 2016, march 2014 and june 2011. Upgrading now to git master gives the advantage that we can profit from improvements in PARI. It will also make the transition to the next stable release easier: the large time between stable releases implies many changes. Since many components of Sage use PARI, there are a substantial number of changes needed in Sage with every PARI upgrade. By doing this upgrade in steps, this becomes more manageable. Many versions of Sage have used git versions of PARI, for the second reason I mentioned above. So there is certainly a precedent for doing this. I do know that this request is controversial because distributions are not likely to accept a "git master" version. However, I feel that I cannot make progress with the PARI Jupyter kernel unless this is resolved. So I would like distributions to accept that Sage is moving again to a git master version of PARI. If it worked in the past with older Sage and PARI versions, it should also work in the future. I didn't make a Trac ticket for this yet precisely because I know it is controversial. Comments? Suggestions? 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-packaging] Re: [sage-devel] Cython 0.26 released
On 2017-07-20 11:12, François Bissey wrote: Now some more details about that pickling support. People working on distro may very well want to ship cython with that support enabled. It's not a different way of shipping Cython. It's just setting a flag in the setup.py of Sage. See the bottom of https://git.sagemath.org/sage.git/diff?id=23d258ad1f83c354c3163941c7745d5eada63f25 So this shouldn't affect distros at all. -- 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] Cython 0.26 released
Cython 0.26 has been released today. There is a ticket for upgrading in Sage: https://trac.sagemath.org/ticket/23360 Two important notes: - For the first time since long, the Sage distribution now builds with a 100% vanilla Cython, no patches are required. I hope this will make packagers happy! - Cython now supports pickling for cdef classes. This is enabled by default in Cython, but I disabled it for Sage because we have lots of custom pickling support. It can be enabled in specific cases with cimport cython @cython.auto_pickle(True) cdef class Foo: -- 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 installing package linbox-1.4.2
On 2017-07-19 20:22, Jose Luis Bracamonte Amavizca wrote: internal compiler error: Killed The most likely cause of this is running out of system memory. How much memory does your system have? Was it particularly heavily loaded? Did you use a lot of parallel processes to compile 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] UnicodeDecodeError while compiling cython with %runfile
I am starting to lose my patience with people posting bug reports and omitting the most important part, like the log file or traceback. Anyway, I'm guessing this might be https://github.com/ipython/ipython/pull/10692 If you would have posted the traceback instead of "...", I could actually know for 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. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Category question: how to get base ring?
On 2017-06-30 17:01, Nicolas M. Thiery wrote: On Fri, Jun 30, 2017 at 10:39:50AM +0200, Jeroen Demeyer wrote: OK, but the question becomes: Suppose a parent R is in Algebras(something), is it safe to assume that R is an algebra over R.base_ring()? In other words, what is the semantic of "base_ring"? Hmm, good point. The funny thing is that this brings us back to a brief discussion we had two years ago on #18310 Actually, this seems more related to #22962 -- 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: Old-style packages
On 2017-07-08 13:37, Simon King wrote: Sure. The meataxe experience was the reason why I tried optional extension modules. I don't recall *who* said so, but I was told that optional extension modules in the Sage source tree should only be used for functionalty that exists in vanilla Sage and can be used with an optional backend (as in the case of meataxe: Sage does have matrices over finite non-prime fields of odd characteristic, but meataxe provides an optional backend for them). I don't think that it should be so strict. Of course, the optional module should still be within the scope of Sage and be sufficiently related to things that Sage does. Keep in mind that there are advantages to having your code *not* in Sage, namely: (1) it might be usable by people who don't have Sage (2) you can develop it as you wish, no need to go through the Sage Trac There has been some movement recently to move code out of Sage as external package. In particular cysignals, cypari2 and fpylll are now packages which used to be part of Sage. There is a plan to do the same with the PPL interface too. That's not necessarily bad. If the documentation of optional stuff is built by default It's the opposite. There is no documentation for optional packages. There are technical reasons for this, I have not really tried to make it work. -- 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] on reference manual pages for code which depends on optional packages
On 2017-07-08 21:45, mforets wrote: i think that it is convenient to show that too, but are there any objections? No objections, just technical reasons. There is no infrastructure in the Sage docbuilder to deal with optional modules. -- 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] What to do with the "Timed out" failures of patchbots?
On 2017-07-07 16:25, Kwankyu Lee wrote: (1) Leave it as it is and live with it. (2) Increase default "Timed out" time limits by SAGE_TIMEOUT, SAGE_TIMEOUT_LONG variables. (3) Split the files that take long to be tested. (4) Actually investigate why the tests time out so often -- 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: Old-style packages
On 2017-07-07 13:24, Simon King wrote: However I was told that the plan to add optional extension modules will not be supported. Who has said this? We do currently have several optional extension modules (in particular, one implementing matrices using meataxe, where you were involved in IIRC). What is true is that we currently do not support optional documentation. I would need to turn the Cython-code into another separate (pip-installable) package That is not particularly hard and I would be willing to help with any technical packaging problems you have. I need a way to build the documentation of the Cython-code Maybe this helps: http://opendreamkit.org/2017/06/09/CythonSphinx/ -- 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: "execution error" when opening the Sage Jupyter Notebook with the SageMath-7.6.app
On 2017-07-04 18:32, mforets wrote: it seems to be something with the 10.12 upgrade: https://github.com/jupyter/notebook/issues/2438 https://stackoverflow.com/questions/44057601/ipython-notebook-will-not-start-on-command-line Indeed. The conclusion seems to be that it's a bug in OS X, which will be fixed in a future OS X 10.12.6 update. -- 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] Old-style packages
TL;DR: should we drop support for old-style .spkg packages completely in Sage? Old-style packages are a relic from the old Sage development model from Sage versions < 6.0. They are packages containing the sources and metadata in one .spkg archive. New-style packages, with metadata in the main Sage git tree, were introduced in Sage 6.0, released in december 2013. You can find a list of existing old-style packages at http://www-ftp.lip6.fr/pub/math/sagemath/spkg/optional/ We already had some discussion about dropping support of old-style packages in 2015, see https://trac.sagemath.org/ticket/19004 and https://trac.sagemath.org/ticket/19158 both merged in Sage 6.9, released October 2015. The latter ticket also introduced a deprecation warning for old-style packages: == NOTE == You are about to download and install an old-style package. While this might still work fine, old-style packages are unmaintained and deprecated. This package will be removed in future versions of SageMath. If you care about this package, you should make a proper new-style package instead. For more information about making Sage packages, see http://doc.sagemath.org/html/en/developer/packaging.html == The reason I ask to drop support for old-style packages is to simplify and improve the installation of new-style Sage packages. In particular ticket https://trac.sagemath.org/ticket/23179 conflicts with old-style packages. -- 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] About milestone sage-feature
On 2017-07-03 23:33, Nils Bruin wrote: This will be a pain to manage. These branches will go stale very quickly and rebasing will be a frustrating chore. If you have programs that you don't want to install in sage proper, then just maintain them as a python package with sage as a dependency and put the source on github if you like. Then you don't get bogged down by the sage development process at all. In this form it will also be much easier to combine it with other such features (without having to merge branches). +1. If you have a branch that you don't want to be merged in Sage, don't put it on the Sage trac. This looks more in the scope of a separate package, which can be a Sage optional 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] About milestone sage-feature
On 2017-07-02 08:03, Kwankyu Lee wrote: 1. Add a new ticket status "needs_feedback". This is a status between "new" and "needs_review". I would guess that the problems are not technical, so technical solutions won't help. Maybe sage-feature branches don't get merged because they are too optimistic, too much work, adding a feature that nobody cares about... 2. Let patchbots test sage-feature tickets in needs_feedback status. I don't see the point of early testing on the patchbot. Usually, when working on a ticket (a "normal" ticket or a "feature" ticket), there are just a few files relevant to that ticket. You can easily test those yourself. The patchbot is meant to test other unrelated parts of Sage and to test the patch on different systems. But that's something that you would normally only do when the ticket is mostly finished. And even if you really want the patchbot to test a branch for some reason, you could still set the ticket to needs_review with a comment that it's just for the patchbot. Currently patchbots refuse to test tickets in sage-feature milestone. If so, that's a bug which should be fixed. -- 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] Category question: how to get base ring?
On 2017-06-29 19:41, Nicolas M. Thiery wrote: Hi Jeroen, On Tue, Jun 27, 2017 at 11:31:36AM +0200, Jeroen Demeyer wrote: Suppose that R is some parent which is contained in the category Algebras(B) for some ring B, how does one determine B from the parent R? I am asking because I want to implement a new method in the ParentMethods of Algebras, which needs to refer to the base_ring of the category. I feel like ParentMethods should have a way to refer back to the category where the ParentMethods was defined. You can safely assume that the parent B implements R.base_ring(). OK, but the question becomes: Suppose a parent R is in Algebras(something), is it safe to assume that R is an algebra over R.base_ring()? In other words, what is the semantic of "base_ring"? -- 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: Category question: how to get base ring?
On 2017-06-27 15:34, Travis Scrimshaw wrote: If I understand what you're asking correctly, you can just ask for the base ring of the category: For that to work, I first need to know that category and that's exactly my problem. Inside the ParentMethods of a category C, I don't know how to get C. -- 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] Category question: how to get base ring?
Suppose that R is some parent which is contained in the category Algebras(B) for some ring B, how does one determine B from the parent R? I am asking because I want to implement a new method in the ParentMethods of Algebras, which needs to refer to the base_ring of the category. I feel like ParentMethods should have a way to refer back to the category where the ParentMethods was defined. -- 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: make sage-8.0: error installing matplotlib on debian
What happens when you do cd '/home/coulbois/programmes/sage/cmi-sage/local/var/tmp/sage/build/matplotlib-1.5.1.p0/src' && '/home/coulbois/programmes/sage/cmi-sage/sage' --python setup.py --name -- 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] get_systems() is totally unreliable without profiling enabled in Cython
On 2017-06-14 12:36, Erik Bray wrote: The fact that you put "systems" in quotes I think really gets to what my question is: How is "systems" defined in this case? Essentially, a "system" is any external math package/library that a computation uses. So things like Pynac, MPFR, PARI, Maxima, OpenBLAS, ... I agree that this is not really objective, for various reasons: 1. Why restrict to "math" packages? We could consider Python, Cython, ECL or CyPari2 to be a "system" too. 2. What about trivial uses? For example, if we ask to list all elements of FiniteField(16), does that really "use" Givaro? Technically, it does but only in a very trivial way. -- 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] get_systems() is totally unreliable without profiling enabled in Cython
On 2017-06-14 11:07, Erik Bray wrote:
I guess I don't really understand what it's for then.
What's your proposed user interface?
Currently, it is for example
sage: get_systems("(x^2 - 1).expand()")
to get the list of "systems" involved in the execution of the Sage
command (x^2 - 1).expand()
--
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: Blog post "Sphinx documentation of Cython code using ``binding=True``"
On 2017-06-10 08:24, 'Martin R' via sage-devel wrote: the problem was, if I remember correctly, that the way sphinx for sage is set up, sage is not a single project. This has nothing to do with what I wrote about. There are essentially two main ways how Sphinx-in-Sage differs from vanilla Sphinx: 1. Sphinx-in-Sage builds the documentation in pieces and then merges it as one document. 2. Sphinx-in-Sage has lots of customization to deal with Cython code. My post was about 2, not 1. -- 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] Blog post "Sphinx documentation of Cython code using ``binding=True``"
See http://opendreamkit.org/2017/06/09/CythonSphinx/ -- 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] get_systems() is totally unreliable without profiling enabled in Cython
On 2017-06-06 16:11, Erik Bray wrote: such as providing a way to manually list systems/libraries used by a specific function That's not the problem. The problem is how to determine which functions are actually called. -- 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] get_systems() is totally unreliable without profiling enabled in Cython
Do you know about sage.misc.citation.get_systems()?
It's supposed to tell which underlying "system" (library, package, ...)
is used for a particular computation.
One example from a docstring:
sage: from sage.misc.citation import get_systems
sage: get_systems('((x+1)^2).expand()')
['ginac']
This is implemented by using cProfile to look at which modules implement
the functions called when executing the code.
The problem is that this is totally unreliable when Cython is compiled
without profiling support (which is the default). The above example only
works because `Expression.expand()` is called by Python instead of
Cython. If that call would be inside some other Cython code, then
Python's profiler would not detect it:
sage: cython('def callexpand(x): return x.expand()')
sage: from sage.misc.citation import get_systems
sage: get_systems('callexpand(((x+1)^2))')
[]
So what should we do?
(A) Silently ignore this issue (status quo).
(B) Give a warning when get_systems() is called when Cython profiling
was not enabled.
(C) Deprecate get_systems() completely.
I am asking because #22747 (compiling Cython code with binding=True)
will "break" profiling even further as even the top-level call of
Expression.expand() would not be detected as something to be entered in
the profiler.
--
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] algebraic number package?
On 2017-05-26 15:19, Ralf Stephan wrote: The qqbar source does not use a lower-level library. What do you mean with this? It actually uses quite a large fraction of Sage (number fields, polynomials, interval arithmetic, ...) -- 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] Brainstorming about Sage dependencies from system packages
Otherwise it sets `$(inst_)` to a dummy file that always exists (this way any dependencies for that package are still satisfied, but the spkg is never actually built/installed). Let me mention *why* I came up with this dummy file: even if configure detects that a Sage package is not needed, it can still be explicitly installed by sage -i PKGNAME# This is essentially the same as "make PKGNAME" If I understand your proposal, if a system package is used, sage -i PKGNAME will *not* install the Sage package since the "spkg" is satisfied by the system package. Personally, I find it more intuitive if "sage -i PKGNAME" would unconditionally install the Sage package PKGNAME, even if PKGNAME was detected as system package. By default, all packages would be installed from the sage-dist source as is the case now. I wonder why you propose this. The reason why we check for gcc for example is because we want to avoid building the Sage package if we can. If you go to the trouble of adding a check for system packages, the default should be to *not* install the Sage package if the system package works. Apart from these two points, I totally agree with your post. Now to find a volunteer to implement all that :-) 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] modules/packages in an @interact
I don't fully understand what you want to do, but please have a look at src/sage/interacts There, various interacts are defined which can be called by the user. It works both in SageNB and Jupyter. I guess your package could do something similar. If you only care about Jupyter, there are other solutions too: in Jupyter, an "interact" is just an object which can be displayed. You create such an object with: def interactive_function(...): ... w = interact.widget(interactive_function) After this, w will be the interact object. Just defining it in this way does not display 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] Second round poll for H5 a specific guideline for writing docstrings
On 2017-05-22 12:21, Kwankyu Lee wrote: The non-redundant information will be implied by the list of hyphened items, if we stick to the convention. So, in order to understand the docstring, the user needs to read the docstring and the convention on how to read the docstring. Not good! -- 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] Second round poll for H5 a specific guideline for writing docstrings
On 2017-05-22 12:05, Kwankyu Lee wrote: My opinion is that the phrase "a tuple `(a,b,c)` where ..." is just redundant. I think that "a tuple" is important non-redundant information. -- 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] Second round poll for H5 a specific guideline for writing docstrings
On 2017-05-22 12:05, Kwankyu Lee wrote: This is ugly. By your previous opinion, wouldn't you prefer this? | OUTPUT:a tuple of ``(a,b,c)``where -``a``is... -``b``is... -``c``is... | I think that the guideline of this thread combined with your one-liner style for OUTPUT allows this. Of course, this is much better. -- 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: Second round poll for H5 a specific guideline for writing docstrings
On 2017-05-22 11:35, Jori Mäntysalo wrote: Why that? What's wrong with being verbose in the OUTPUT block? This is a misquote. I meant to reply to Sébastien Labbé. -- 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: Second round poll for H5 a specific guideline for writing docstrings
On 2017-05-19 14:16, Jori Mäntysalo wrote: The only thing I want to see in the OUTPUT block is the *type* of the objects and how many of them. Why that? What's wrong with being verbose in the OUTPUT block? I would like something like INPUT: - ``certificate`` -- boolean; whether to output a certificate, see OUTPUT OUTPUT: - If ``certificate=False``: a boolean - If ``certificate=True``: something more complicated -- 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] Second round poll for H5 a specific guideline for writing docstrings
I very much object to this: If the output consists of several items, add each starting with a hyphen. If the output consists of several items, the OUTPUT string should clearly mention that fact (and it should mention whether the output is a tuple or list or some other structure with several items). So something like: OUTPUT: - a tuple `(a,b,c)` where - ``a`` is ... - ``b`` is ... - ``c`` is ... -- 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] Second round poll for H5 a specific guideline for writing docstrings
As I mentioned on the other thread, since OUTPUT is not a list of things (as opposed to INPUT), I would prefer OUTPUT: tuple of lattices -- 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 for issue G1 a specific guideline for writing docstrings
On 2017-05-18 14:36, Erik Bray wrote: I don't think you could write something that is intelligent enough to distinguish the literals ``True``, ``False``, or ``None`` with the word itself (which would be capitalized if beginning a sentence--not common, but not impossible either). Reasonable example: "None of the input vertices should be adjacent." -- 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] splitting BRiAl
On 2017-05-18 11:25, Francois Bissey wrote: Puzzled me for a while too. It doesn’t. So you are saying that BRiAl consists of two *independent* parts which don't interact at all? That by itself would increase the reasons for splitting. Does Sage actually require both parts? -- 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] splitting BRiAl
On 2017-05-18 01:09, François Bissey wrote: And I have a pure python pybrial that install with a minimal setup.py. If it's pure Python, then how does it access the libBRiAl 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] Poll for issue G2 a specific guideline for writing docstrings
On 2017-05-17 17:10, Daniel Krenn wrote: I find this perfectly fine. I personally would write "Return whether this lattice is contained in the other lattice", but I do not find any need to include ``self`` in the one-line description. Well, in general, sentences containing too many words like "this", "that", "it", "the $thing", ... are hard to understand. Perhaps the is_sublattice() example I gave might be acceptable, but I wouldn't push it much further. -- 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 for issue G5 a specific guideline for writing docstrings
On 2017-05-17 17:09, Vincent Delecroix wrote: I like the above, however there can be more complicated output (depending on the output). An example is given by "is_cyclotomic" that returns either a boolean or an integer Of course a list makes sense in this case. I didn't say to forbid a list, just that the general case shouldn't be a 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.
Re: [sage-devel] Poll for issue G5 a specific guideline for writing docstrings
What about OUTPUT: lattice Unlike an INPUT, an OUTPUT is not a list of things. So why format it as a list? A list could be useful for example in OUTPUT: a tuple ``(a,b)`` with - ``a`` a foo - ``b`` a bar -- 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 for issue G4 a specific guideline for writing docstrings
+1 In practice, this is already how things are done anyway. -- 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 for issue G2 a specific guideline for writing docstrings
+1 but make it clear that this is only a guideline and then "``self``" might still be better in some cases. For example, imagine def is_sublattice(self, other): """ Return ``True`` if this lattice is contained in the other lattice. """ In this case, it would be better to refer to ``self`` and ``other``. -- 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 policy question: require docstrings and doctests?
On 2017-05-17 12:19, Vincent Delecroix wrote: Here are several reasons: - random seeds are always the same That can easily be fixed by explicitly changing the random seed in the doctest (probably some helper context should be provided for this) - impossible to have complicated test code First of all, doctests can contain arbitrary code, so it can be as complicated as you want. Second, you could write a dedicated test function like def complicated_test_function(many, arguments, here): """ TESTS: sage: complicated_test_function(1, 2, 3) """ This is like a unit test without requiring a new testing framework. - impossible to tune the tests to make it more intensive (let say I want to run the tests for 1000 inputs rather than 10) You can run many iterations of the doctests. - TESTS part are often unreadable If the test code is complicated, using a different test framework will not help. You would just be running the same unreadable code in a different way. - `TestSuite(my_object).run()` is not illustrative I don't understand what you mean 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. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Sage policy question: require docstrings and doctests?
On 2017-05-17 12:19, Vincent Delecroix wrote: 1) Each code path (including errors) must be tested". You can easily translate this requirement as "require 100% *line* coverage" instead of *function* coverage which is what is current sage-coverage script tests. 2) Introduce an alternative way of testing Sage code in the flavour of unit tests We have had this discussion before... which problem would that solve? Doctesting is just a tool. You can run the same tests as doctest or as py.test test: a test is just some code which is run. There is nothing magical about "unit testing" that it cannot be done using doctests. Before we add a new testing framework, I would like to see at least one compelling advantage of 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] Sage policy question: require docstrings and doctests?
On 2017-05-15 18:39, Erik Bray wrote: It's possible using something like coverage.py will just work, but I haven't tried it yet. For Cython, see http://cython.readthedocs.io/en/latest/src/tutorial/profiling_tutorial.html#enabling-coverage-analysis -- 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 policy question: require docstrings and doctests?
On 2017-05-15 15:56, Erik Bray wrote: The point is that no matter how well motivated a coding guideline is it's just that--a guideline (maybe even a very important one!). But one never bend over backwards to write non-idiomatic, convoluted, or not well-motivated code just to satisfy a guideline. Totally +1 Too bad that too many people take the coverage script too literal. For functions which are meant to be called directly by end users, doctests are essential because they should show examples of how the function should actually be used. However, for internal functions or things like __init__, it is often not easy to write meaningful docstrings. Something I regularly see is that people literally write the same doctest twice in two different places (say, an end-user function and an internal function) just to satisfy a stupid script. -- 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] SageNB -> Jupyter conversion needs testers
Let me remind that there are various tickets regarding the SageNB->Jupyter conversion which need review: #22668: HTML widget without description #22654: Implement %%fortran in Jupyter #22636: Make the Sage interact library work in Jupyter -- 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] help needed to debug a systematically killed Sage
On 2017-04-07 20:13, Vincent Delecroix wrote: 8G should be enough!? (note that Sage used to work...) Be sure to double-check dmesg and check if there is something suspicious. -- 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] help needed to debug a systematically killed Sage
Another guess: a sage-cleaner getting confused and killing wrong processes. -- 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] As of Sage 8.0, lcm is from sage.arith.functions but gcd is not
On 2017-04-07 19:23, Nils Bruin wrote: Importing infrastructure has changed significantly between Py2 and Py3\ Really? What has changed? -- 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] help needed to debug a systematically killed Sage
On 2017-04-07 13:34, Vincent Delecroix wrote: However, after step 2) I end up with a very broken Sage that is immediately killed with no information at all Too little memory available on your system? -- 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] When install SAGE, it says: 'gmp.h' and 'libgmp' have different versions
On 2017-04-06 11:37, Peng wrote: Yes, it is SAGE 5.7. I didn't try the new version. Is the old version the reason for this error? No idea, but you will not get help for issues in such an old 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] When install SAGE, it says: 'gmp.h' and 'libgmp' have different versions
On 2017-04-06 05:10, Peng wrote: /home/user/sage-5.7/spkg/logs/ecm-6.3.p8.log Is your version of Sage really 5.7? That version is years old. -- 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] Better lazy imports
Hello sage-dev,
this week I worked on something which I find quite exciting: a context
("with" statement) for lazy imports. See
https://trac.sagemath.org/ticket/22752
The old lazy import
lazy_import('sage.arith.srange', 'xsrange', 'sxrange', deprecation=20094)
can now be written as
with lazyimport(deprecation=20094):
from sage.arith.srange import xsrange as sxrange
In addition to the syntax change, two more issues are fixed for the new
"lazyimport" context:
1. It works in Cython.
2. Lazy relative imports are supported.
This is implemented by overriding __builtin__.__import__ (which is a
documented way to change the import mechanism).
The motivating reason to improve lazy imports was to work on fixing the
cyclic import problem in Sage (#21636).
Enjoy (and please review),
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] algdep (PARI) with clang on FreeBSD
On 2017-03-29 11:24, Dima Pasechnik wrote: Is the following a bug, or not: Fix planned at https://trac.sagemath.org/ticket/22714 -- 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] algdep (PARI) with clang on FreeBSD
On 2017-03-29 11:24, Dima Pasechnik wrote: Is the following a bug, or not: A bug in what :-) This is already interesting (on Linux): sage: float(RR(3).sqrt()) 1.7320508075688772 sage: float(RDF(3).sqrt()) 1.7320508075688772 sage: float(RR(sqrt(3))) 1.7320508075688772 sage: float(RDF(sqrt(3))) 1.7320508075688774 The last one is actually more wrong (error: 0.55 ulp) than the first three (error: 0.45 ulp). Interestingly, it is precisely this wrong answer which is used in the doctest. I think it's fair to say that the doctest isn't robust. -- 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] 'make PACKAGE' does not build the toolchain
Feature Use "./sage -i PACKAGE" if you want to build the toolchain first. -- 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: linker options for C code in ext/interpreters and other stuff in sagelib
On 2017-03-27 23:15, François Bissey wrote: The generated sage/ext/interpreters/wrapper_cdf.pxd has the following statement: cimport sage.libs.cypari2.types That would pull `-lpari`. That's not actually true. Just using the *types* from PARI doesn't need linking against PARI. It's cysignals which pulls -lpari. To add `-lm` you would have to add a line #distutils: libraries = m at the top of the same .pxd file Actually, the .pyx file. If something is needed for the .pxd file, the "# distutils" declaration should be in the .pxd file. But this is not the case here, so it should be in the .pyx file. -- 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: An "easy looking" computation in AA that sage can't do
I believe that this is simply https://trac.sagemath.org/ticket/15600 The variable d lies in a number field of degree 32, which is rather big to call polredbest() on. -- 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: Names of special methods like _pari_
On 2017-03-15 19:00, Kwankyu Lee wrote: The following statement from PEP8 is quite definitive: __double_leading_and_trailing_underscore__ : "magic" objects or attributes that live in user-controlled namespaces. E.g. __init__ , __import__ or __file__ . Never invent such names; only use them as documented. That's true but I don't like that they don't say what you should use instead. I think the alternatives are even worse (see my initial post in this thread). One minor "harm" that I can think of is that an uninitiated person may misunderstand __pari__ as a new python magic attribute and look for it in python manual :-) Let me mention again that such names have been invented in the past, like __array__ for NumPy. As far as I know, this is not at all controversial. -- 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: Names of special methods like _pari_
On 2017-03-15 18:41, William Stein wrote: Name mangling to hide data is an ugly hack. This totally is *not* about name mangling. Names like __foo are mangled but not __foo__. -- 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: Names of special methods like _pari_
On 2017-03-14 21:44, William Stein wrote: I'm in favor of (1) and against (4). I would have named it __pari__ in the first place if I thought that was better... I'm general against double underscore methods entirely, except the ones pre-defined by python. Would you care to explain your reasons? -- 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: Names of special methods like _pari_
On 2017-03-15 12:45, TB wrote: FWIW, I find that having a consistent convention for special Sage functions [1] is a good thing. In some cases (e.g. _repr_, _add_) the names were chosen according to the dunder name in Python, so those methods probably should not change. This thread is not about _repr_ or _add_. I totally agree that those should not change. -- 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: Names of special methods like _pari_
On 2017-03-15 11:42, Erik Bray wrote: I don't have a strong feeling about it, but +0.5. I don't see anything wrong with _pari_, and keeping with a __ (call it "sunder" instead of "dunder") convention if it's already in use is the least work. Let me clarify some things: (1) This is not about Sage but about a separate future project called "cypari2". So we're not keeping any convention, we are establishing a convention. (2) The change to __pari__ is already implemented (https://trac.sagemath.org/ticket/22470) so both _pari_ and __pari__ are zero work at this point. -- 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: Names of special methods like _pari_
On 2017-03-14 20:38, Luca De Feo wrote: - It's bikeshedding, let's not waste developers' time with it I already spent much more time on *this discussion* than the implementation at #22470. -- 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] Is anybody using set_coercion_model()?
The coercion model in Sage seems to be designed to allow it to be changed: there is a global object coercion_model defined in element.pyx which can be get/set using get_coercion_model() and set_coercion_model(). So *in theory* it is possible to implement a different coercion model. However, in practice I think that: 1. There is no need for an alternative coercion model. 2. Many places in Sage assume specific behaviour about the coercion model, so changing it would break lots of things. So I suggest to drop support for a changable coercion model. One advantage is that we could just import the "coercion_model" global instead of needing to call get_coercion_model() every time. This would lead to cleaner and faster code. What do you think? 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] "replacement" optional packages
On 2017-03-12 09:27, Dima Pasechnik wrote: On the other hand, it appears that surf had never been ported to OSX. What does that mean? It just means that pandoc is more popular than surf. I somebody has really tried to compile surf on OS X and didn't manage, that would be a different story. But if nobody has even tried, it means nothing. -- 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] "replacement" optional packages
On 2017-03-12 09:35, Dima Pasechnik wrote: X11? That can be disabled with --disable-gui -- 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] "replacement" optional packages
On 2017-03-11 20:18, Dima Pasechnik wrote: in this sense dependence on pandoc is OK, dependence on surf - much less so. Isn't the issue with surf the same as pandoc: it requires dependencies which are not part 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. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] "replacement" optional packages
Speaking of optional packages, we should also think of a strategy to deal with optional packages which have dependencies which are not part of Sage. For example, the optional rst2ipynb package requires pandoc, which is not in Sage. On the other hand, in #22378 I wanted to package surf as optional package and got complains from Dima that I couldn't because it had dependencies not in Sage (such as libjpeg). -- 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] division of a list by an integer
See https://trac.sagemath.org/ticket/22573 -- 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] Host notebook() at localhost:8080/ instead of simply at localhost:8080
On 2017-03-10 03:00, Gere Mia wrote: Is there a way to make make notebook() host at localhost:8080/ instead of simply at localhost:8080? Not directly. One way to make something like that work is to use reverse proxying using a separate webserver. For example see https://httpd.apache.org/docs/2.4/howto/reverse_proxy.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] A question about sage reference manual building
On 2017-03-10 00:11, Kwankyu Lee wrote: Am I understanding the situation right? Mostly. I think the problem is that the .rst files for removed Sage library files are not removed. If so, then this is something to be fixed Obviously and would you give some pointers to where I should look? There is a ticket https://trac.sagemath.org/ticket/19882 -- 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] State of sage built with clang/clang++ on OS X - update
On 2017-02-26 08:27, Isuru Fernando wrote: Anybody know why some python extensions with C++ as the language are compiled with -std=c99? I'm using sage-7.5.1 Fix at https://trac.sagemath.org/ticket/22554 -- 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] tachyon-0.98.9.p5 build error in Linux
Just a guess: do you have a broken/unusual version of Make? I would suggest to try upgrading to the latest version of GNU Make and 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] Re: The end of our current R saga ? Reviews needed.
On 2017-03-03 15:27, Emmanuel Charpentier wrote: This set of tickets is up for review again since about two weeks. in Trac#21770 <https://trac.sagemath.org/ticket/21770>, Jeroen Demeyer is of the opinion of keeping curl (and probably pcre, but he doesn't say that) as optional packages "for a while". This woulkd delay our already exceeding late upgrade of R by the same amount. No, it would not delay anything since I proposed to make those packages standard exactly when we upgrade R to the version which needs those packages. -- 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: Names of special methods like _pari_
On 2017-03-02 14:19, Marc Mezzarobba wrote: Jeroen Demeyer wrote: (4) __pari__(): consistent with Python (__int__, __str__) and NumPy (__array__). However, creating such names possibly goes against the Python documentation [2]. Why "possibly"? The way I understand [2] is that __names__ are reserved for use by the Python interpreter and standard library, period. As I have said before, NumPy have invented __array__ too. And I don't think that the Python Naming Police came to hunt them down. What bothers me about [1] and [2] is that they do not say which names should be used for custom special methods. [1] https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles [2] https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers But if you want to do the same with all conversion methods, there could well be a conflict with some future standard python module. *Any* name has the potential to clash with Python or with other packages. And I don't think that __pari__ is much more likely to clash than any other of the proposed names. -- 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: Names of special methods like _pari_
On 2017-03-01 18:27, Nils Bruin wrote: you might want to look for precedents of implementations that use that naming conventions for protocols that are only supported by add-on libraries NumPy is an example: it specifies a special method .__array__(). So at least we would be in good company with .__pari__(). In fact, using something other than "_pari_" could be advantageous: you can tweak the API of pyri until you hit 1.0 I don't need to change any API. I want to split of src/sage/libs/cypari2 as a separate package called CyPari2, without changing any API. It does seem to me that your desire to choose a different name I don't have a particular desire to *change* the name. I want to decide on the best name to use. And I don't want to keep the name just because that is the status-quo. And of course, I will think of backwards-compatibility. -- 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: Names of special methods like _pari_
On 2017-03-01 11:47, Simon King wrote: I don't think they are that much different in spirit. In all cases, the single underscore methods are for implementing functionality in a Sage-specific way No, you are misunderstanding. There is absolutely nothing Sage-specific about _pari_. In fact, I started this discussion because we would like to split up the PARI interface as a different package, independent from Sage. And the Sage convention _pari_ would not make much sense then. On the other hand, _repr_ or _mul_ are only defined for subclasses of SageObject, so therefore they are Sage-specific. a "visible" one (.pari()) in the case of _pari_ There is no such thing as a .pari() method. Maybe you are confusing with the pari() global function? But then I would argue that the situation is very similar to str or int: Python has global functions str() and int() calling .__str__() and .__int__() methods. Which is *exactly* analogous as what pari() does: it currently calls a ._pari_() method. Given the analogy I just explained, this should be changed to .__pari__(). -- 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] Experimental package gap3 installation broken
This was broken in #20692, the "cd src" should NOT have been removed: diff --git a/build/pkgs/gap3/spkg-install b/build/pkgs/gap3/spkg-install index a91ab6f..cf76e22 100755 --- a/build/pkgs/gap3/spkg-install +++ b/build/pkgs/gap3/spkg-install @@ -17,20 +17,6 @@ echo "GAP3_DIR = $GAP3_DIR" echo "INSTALL_DIR = $INSTALL_DIR" ### -## MODIFY UPSTREAM -### - -cd src -for patch in ../patches/*.patch; do -[ -r "$patch" ] || continue # Skip non-existing or non-readable patches -patch -p1 <"$patch" -if [ $? -ne 0 ]; then -echo >&2 "Error applying '$patch'" -exit 1 -fi -done - -### ## INSTALLATION ### -- 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] "replacement" optional packages
I have been thinking about this too. My personal conclusion was that the "type" enumeration (standard, optional, experimental, pip, script) is simply too restricted and that we need additional metadata with more degrees of freedom. Currently, the "type" field is relevant for: - which packages are installed by default - which packages should be packed in the source tarball - which --optional tags are given when doctesting - whether a warning message is given when installing the package - the Make rules of a package - the automatic dependencies of a package I think that's bordering on being too much already. So +1 to more metadata but -1 to inventing yet another type. -- 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] Names of special methods like _pari_
On 2017-03-01 03:43, David Roe wrote: I don't see the benefits of changing as sufficient to outweigh the costs of an incompatible change We could always keep supporting _pari_ with deprecation, so the cost of changing is zero. -- 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] Names of special methods like _pari_
What about _latex_? Would you plan to change that, too? Sage objects and elements have lots of single-underscore methods, like _repr_, _mul_, etc. Well, I would put _latex_ in the same basket as _pari_. But _repr_ and _mul_ are different: they deal with the implementation of SageObject/Element so this is *not* about those methods. I'm not convinced, because you'll potentially break code people have written that is not included in the Sage library. For that reason, I'm -1 to changing _pari_ in a backwards incompatible way. We could always keep supporting _pari_ with deprecation, so that's not really an issue. -- 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] Names of special methods like _pari_
On 2017-02-28 20:46, Johan S. H. Rosenkilde wrote: In that case, it could be seen as an implementation detail that objects have the _pari method, and private would be apt. Yes, it's an "implementation detail" but it's not "private". I would say it's a public implementation detail: something that users shouldn't need to know but something that package developers should know and can rely on. A private name like "_pari" would imply that we can remove/change it at will, which is not applicable in this case. I think this is exactly like Python's special methods such as __init__: as a user, you would normally not call these but they are very important when developing a class. -- 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: Names of special methods like _pari_
On 2017-02-28 21:08, Nils Bruin wrote: On Tuesday, February 28, 2017 at 8:26:22 AM UTC-8, Jeroen Demeyer wrote: (4) __pari__(): consistent with Python (__int__, __str__) and NumPy (__array__). However, creating such names possibly goes against the Python documentation [2]. This would leave with me the strong expectation that the advised way of invoking this method is via pari(), which of course could work. That's exactly right. So if it does give you that impression, that would be an additional reason in favour of (4). -- 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: Names of special methods like _pari_
On 2017-02-28 21:08, Nils Bruin wrote: So it seems to me changing the names will be a lot of work with very limited actual benefit. It's just a simple search-and-replace-all, so essentially no work. I don't think we should stick with the status quo just because of 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.
[sage-devel] Names of special methods like _pari_
This is a continuation of discussion from https://trac.sagemath.org/ticket/22470 I will only talk about _pari_ below but this is just an example. We also have _gap_ and others. Sage supports the special method _pari_() to convert arbitrary objects to PARI. Now I would like to ask the question whether _pari_() is really the best name. Especially if we want Sage to fit better in a larger Python ecosystem, it makes sense to think about this. We essentially have 5 options: (1) _pari_(): the status-quo. This seems to be very Sage-specific, I don't know if this naming convention is used anywhere else. (2) _pari(): meant for private methods. This doesn't seem correct to me, because we want this method to be part of the public API. (3) __pari(): even more private with mangling, so even less suitable. (4) __pari__(): consistent with Python (__int__, __str__) and NumPy (__array__). However, creating such names possibly goes against the Python documentation [2]. (5) pari(): very simple but it doesn't make it clear that it has a special meaning. Higher chance of false positives with people using a pari() method for something else. My personal choice would be (4). Since this seems to be a controversial topic, I decided to write this sage-devel post. There is some discussion about naming in these two references: [1] https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles [2] https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers but neither seems to answer what is the right thing to do for our use case. 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] install problem with sage-7.5.1 from Paul Zimmermann
On 2017-02-27 16:48, William Stein wrote: while trying to install Sage 7.5.1 from source on my machine (Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz, Debian GNU/Linux 9.0 (stretch), gcc 6.3.0) I got a failure in mpir-2.7.2 (log file attached). Any advice? Fixed in https://trac.sagemath.org/ticket/22260 -- 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] SageNB -> Jupyter conversion needs testers
On 2017-02-26 16:52, John Cremona wrote: @ cells with %gp and %magma were not recognised as being different. I could put %magma followed by a magma command on the same line, but it was useful to put %magma just once at the top of a cell and have the whole cell interpreted using magma. Right. Jupyter uses %% (double percent) for multi-line magics. So replacing %gp by %%gp should work. But this could be done automatically. -- 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] State of sage built with clang/clang++ on OS X - update
On 2017-02-26 10:57, Ralf Stephan wrote: The travis build failed. Usually git maintainers expect the PR submitter to check and fix all such failures. I know, but that's not the issue. They didn't say "yes we like your patch but you need to fix it". They said "why not do Y or Z instead" and I explained why Y or Z wouldn't work and the discussion ended 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] State of sage built with clang/clang++ on OS X - update
On 2017-02-26 08:39, Francois Bissey wrote: That’s because python doesn’t do c++ compilation properly out of the box. That's true but that has nothing to do with Sage using -std=c99 for C++ extensions. I know how to fix this but it needs https://github.com/cython/cython/pull/466 which Cython refuses to merge for reasons which are unclear to me. So if anybody has any friends at Cython, please ping them... -- 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.
