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,
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
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
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)
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
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
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
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
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
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
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
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
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?
--
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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,
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 -
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
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
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
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']
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
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
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
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!
--
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
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
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
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
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
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
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
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
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
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
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,
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
+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
+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
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
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
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
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
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
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
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
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
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"
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"
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
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
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,
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:
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
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
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
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
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
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
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
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
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
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,
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.
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
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
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
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
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
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
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"
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
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 pa
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
401 - 500 of 3164 matches
Mail list logo
