On 2017-11-07 12:26, mmarco wrote:
I have to clarify: Tomer Bauer did not volunteer to give a talk about
creating extensions;
"extensions" in which sense? I'm guessing Sage packages.
Within Python, the word "extension" usually refers to a Python module
written in C as in
On 2017-11-05 19:20, Jori Mäntysalo wrote:
Is it possible to run min(L) in Python2 and at the same time check if it
could be run in Python3 for given L?
Reason: allow_multiple_edges() on generic_graph.py and keep_label='min'
(or 'max'), can we have a nice deprecation?
Speaking of comparisons
On 2017-11-05 22:51, Travis Scrimshaw wrote:
I'm not quite sure what you're asking. min and max are not fundamentally
changed between Python3 except that the cmp keyword will no longer be
valid.
The functions min() and max() are not fundamentally different but the
way how comparison works is
On 2017-11-05 19:20, Jori Mäntysalo wrote:
Is it possible to run min(L) in Python2 and at the same time check if it
could be run in Python3 for given L?
That depends mostly on what arguments you give to min(). Are we talking
about
1) Standard Python types (str, int, ...)
2) Instances of
On 2017-11-03 10:23, Travis Scrimshaw wrote:
No, Sage automatically does not install gcc if the system versions of
gcc, g++, and gfortran all match and are at least 5.4.0.
The minimum version is 4.8 (not 5.4.0). But it's true that gcc, g++ and
gfortran must have the same version number.
--
On 2017-10-31 13:01, mmarco wrote:
So, would someone be interested in coming and giving a short course on
one of those subjects (or to suggest other subjects that you think could
be interesting)? Ideally, each course would consist on a few lectures
plus some practical sessions.
I might be able
On 2017-10-30 16:51, Erik Bray wrote:
Thanks to some request/response dumps Jeroen sent me, I think I can
take a guess at the problem. His university has set up a forward
proxy to cache static HTTP resources, and so while his /login request
comes from his machine, or whatever NAT router it's
On 2017-10-30 16:28, William Stein wrote:
Not necessarily.Pickle is *the* canonical extensible object
serialization system for Python. It’s of course very extensible in
that users can define how objects pickle, eg by defining a dunder reduce
method. As such they can of course make that
Another very relevant question: are pickles supposed to be
hardware/OS-independent? In other words: can I take a pickle from one
machine and unpickle it on a different machine (assuming that the
software version is the same)?
--
You received this message because you are subscribed to the
On 2017-10-30 15:50, Erik Bray wrote:
Is it possible you're using Tor
or some other sort VPN that uses a different IP address on each
request?
Personally, I'm not doing that. But it could be that my university is
doing something funny. As I said, the problem seems to be with my
university
On 2017-10-30 15:12, Erik Bray wrote:
My point, however, is baked directly into the file format--the pickle
format is very Python version-dependent (there are I think 5 different
pickle formats now)
It's true that the format has changed, but always in a
backward-compatible way. For basic
On 2017-10-29 23:14, Travis Scrimshaw wrote:
What about any object that does a TestSuite(foo).run()? This guarantees
that it pickles (assuming it is not skipping that test) and is an object
that someone would create.
Sounds like a good idea to me. We could have TestSuite(foo).run() create
a
On 2017-10-29 20:22, Simon King wrote:
The m*n-fold pickle jar should not pollute the SageMath sources.
In that way, a new pickle jar version wouldn't result in a new
to-be-merged git commit. Instead, the jar should only be stored
on some SageMath servers.
I don't like this part. It should be
On 2017-10-30 08:41, Simon King wrote:
would you rather have no test at all than a
superficial consistency test on a wide range of objects, versions and
machines?
Yes. A test which doesn't actually test anything is worse than no test.
That's exactly the situation that we currently have with
On 2017-10-30 11:07, Jeroen Demeyer wrote:
I just tried with my phone and the problem also occurs there! What is
wrong with me if I'm the only person having this problem?
OK, the common source of problems might be my university network. I
disabled wifi on my phone and now it seems to work
I just tried with my phone and the problem also occurs there! What is
wrong with me if I'm the only person having this problem?
--
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-10-30 10:39, John Cremona wrote:
Have you changed browser of cookie settings?
I just tried another browser (Chromium instead of Firefox) and the
problem persists. So I think that we can exclude the browser as source
of problems. I have no idea what is going on...
--
You received
On 2017-10-30 10:28, julien.puydt via sage-devel wrote:
Clock issue? I would check the hours on the affected computers...
As far as I know, my clock is correct. It is being synchronized via NTP.
Current time on my machine is
Mon Oct 30 10:34:36 CET 2017
It's true that my computer changed
On 2017-10-30 01:39, Travis Scrimshaw wrote:
How
difficult is it to parallelize Cython code?
Cython supports OpenMP:
http://cython.readthedocs.io/en/latest/src/userguide/parallelism.html
Note that OpenMP may not be supported on all systems. This is something
we will need to check.
On 2017-10-30 10:09, Jeroen Demeyer wrote:
It seems to work if I make an edit very quickly after logging in. So it
looks as if I'm being automatically logged out 5 minutes after I log in
or so.
It's actually much less than 5 minutes, more like a few seconds. Often,
when I log
Hello,
this morning I'm having strange problems with Trac. I can log in to Trac
and the page shows that I'm logged in. But whenever I try to make a
change I get a permission error saying that I'm not logged in.
It seems to work if I make an edit very quickly after logging in. So it
looks as
On 2017-10-29 20:22, Simon King wrote:
As part of the release process of a new version of SageMath,
a new version of the pickle jar is created by some patchbots
on m different machines and replaces the m oldest versions of
the pickle jar.
That's the easy part. The hard part is deciding what to
This is a topic which comes up now and then but which hasn't been
resolved so far.
Sage has a "pickle jar" stored in src/ext/pickle_jar/pickle_jar.tar.bz2
and there are tests in src/sage/structure/sage_object.pyx which check
that every object in the pickle jar can be unpickled without raising
There are various downloads that we need to consider:
(A) Downloads of Sage-the-distribution source/binary tarballs
(B) Cloning the git repo
(C) Downloading tarballs while building from the git repo
I think that (A) should be our primary worry, since those are usually
not checked by anybody.
On 2017-10-25 17:38, Emmanuel Charpentier wrote:
The incompatibility between GPL and OpenSSL Licenses does not seem to
amount to much
This is a very dubious statement. And the rest of your implementation
plan depends on this, so we should really think about this.
For example, a lot depends
On 2017-10-25 18:01, Emmanuel Charpentier wrote:
Your inputs, please ?
I think it is completely pointless. And it's never going to work in
practice... nobody is going to want to maintain that branch.
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
Just never ever override
double underscore __richtcmp__ for elements.
Yes, that is a very good point to make and reinforce.
Same for __add__, __mul__ and so on... except if you explicitly want to
bypass the coercion model (which is not fully supported anyway, see
#24066)
--
You
On 2017-10-25 00:08, Eric Gourgoulhon wrote:
I have the feeling that the current tendency is towards a more modular
and lighter Sage, which deviates from the original "batteries included"
philosophy.
I would like to keep "batteries OPTIONALLY included". This means: use
system software if
On 2017-10-24 20:58, Emmanuel Charpentier wrote:
A non-communicating R in Sage can be very useful if you are not using R
in Sage at all
I just meant to say that if you don't use R, then it's fine to have a
non-communicating R. I admit that the wording was a bit cryptic.
--
You received this
On 2017-10-19 17:21, Emmanuel Charpentier wrote:
I do not think that a
non-communicating R is useful in Sage.
A non-communicating R in Sage can be very useful if you are not using R
in Sage at all (which is very likely the vast majority of Sage users).
--
You received this message because
This is an infinite loop:
: if type(other)!=type(self):
: #other knows how to do the comparison
: return other.__eq__(self)
The correct Python thing to do is to return NotImplemented in this case.
--
You received this message because you are
On 2017-10-19 20:56, Nicolas M. Thiery wrote:
Forgot to mention: if you open the javascript console (shift-ctrl-K on
Firefox/linux), you can trace what's going on with the connection to
binder.
This seems suspicious:
SyntaxError: missing : after property id thebelab@0.0.5:30745:13
I know
On 2017-10-20 11:32, Luca De Feo wrote:
So according to your point checking the SHA1 is useless, because
attackers are not able to get malicious source tarballs accepted by
SageMath.
That is totally not what I said. We don't care about collision
resistance, but we still need preimage
If you say that something does not work, it would be good to show a
simple example of what you did. It is impossible for me to understand
why your code doesn't work without seeing your code.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
On 2017-10-20 10:54, Dima Pasechnik wrote:
Once upon a time, http was not universally supported, one needed to use
ftp instead.
You misunderstood my point. It is not about http vs. https.
What bothers me is that "downloading packages from CRAN" is considered
so important by R that it refuses
On 2017-10-19 20:07, Luca De Feo wrote:
There you go for something crippled! https://shattered.io/
I don't think that this is actually relevant. This attack would only
work if an attacker is able to provide a specially manufactured source
tarball and get it accepted by SageMath. At that
On 2017-10-19 17:19, Emmanuel Charpentier wrote:
Again : R is not only a software package but also an ecosystem.
But why? One could say the same for Python, but you can still install
Python without OpenSSL.
What if I simply want to use R without any external packages? Or what if
I want to
On 2017-10-19 17:24, William Stein wrote:
Good, as well they should. Like you, they likely feel a responsibility
to their users to do the right thing regarding security. I really
appreciate the "so much trouble" you are "causing" Emmanuel.
I also agree here. The only options should be "use
On 2017-10-18 18:21, Nicolas M. Thiery wrote:
Dear Sage developers,
You can find a demo of live documentation on:
https://more-sagemath-tutorials.readthedocs.io/
Pick e.g. "Demo basics", click "Activate", and wait a bit. To evaluate
a cell, use shift-Enter as in Jupyter.
On 2017-10-18 19:02, Emmanuel Charpentier wrote:
This option commits us to maintain (unnecessary and dangerous, IMHO)
Sage-specifc SSL patches at least in R, Python and pip
Really? Which Sage-specific SSL patches does this require in Python and pip?
It seems to me that R is the only package
On 2017-10-18 16:31, Eric Gourgoulhon wrote:
Hi Sage Devs,
We plan to develop some experimental package for Sage, which requires to
make use of a C++ library (basically this is to implement numerical
calculus on manifolds). What would you recommend to make the link
between Sage (Python) code
On 2017-10-18 01:38, William Stein wrote:
Absolutely not. That's not how security software works (and would be
insulting to the OpenSSL developers). You are **epically**
understimating what OpenSSL is and does.
+1
Implementing crypto in practice is very different from implementing a
toy
Quick question: does the use the Jupyter software from Sage or from
binder itself?
--
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
First of all, I think that your email is unfair because it presents the
"Yes" option as something that we could just easily do. However, as
mentioned in another post in this thread, the "Yes" option might
actually be illegal.
So my vote is "No".
--
You received this message because you are
On 2017-10-18 03:08, William Stein wrote:
(a) using a broken version of the Python/R/Sage stack that exposes
them to installing malware
Is that really the case? I think pip is actually fail-safe in the sense
that it simply refuses to download if OpenSSL is not supported. So there
is no
On 2017-10-18 03:08, William Stein wrote:
The choice for users installing the Sage binary is between:
So you are worried about *binaries*? Are there any distros that we ship
binaries for that *don't* have a systemwide OpenSSL installed by default?
--
You received this message because you
On 2017-10-17 12:13, Simon Brandhorst wrote:
Because the documentation did not tell me it was possible:
That *what* is possible? @richcmp_method simply allows to define just
one comparison method __richcmp__ instead of six __eq__, __lt__, ...
However, the functionality of what that
So basically you want to add OpenSSL to Sage and then say
"We know that distributing SageMath might be illegal, but it is unlikely
that somebody will sue. Use at your own risk!"
I doubt that this is such a good deal.
--
You received this message because you are subscribed to the Google
On 2017-10-16 12:08, Emmanuel Charpentier wrote:
|_| Yes, we should fully support OpenSSL now, and clarify the
licensing issue.
What does "clarifying" the licensing issue even mean? The fact that
OpenSSL is *in the process of* relicensing does not help us at the
moment. And you don't
Remove the @richcmp_method decorator.
--
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
On 2017-10-14 11:50, John Cremona wrote:
How can we be sure that new code witten by people (like me) who are
not python2/3 experts does not regress?
I think it's also important to mention that Cython is quite different
from plain Python in this regard. Cython generally tries to be
compatible
I forgot to say that I created https://trac.sagemath.org/ticket/24001
for this.
On 2017-10-09 21:15, Jeroen Demeyer wrote:
While working on some dot2tex/graphviz oddities, I noticed something
strange: many of the doctests marked "optional - dot2tex graphviz"
actually pass even wh
While working on some dot2tex/graphviz oddities, I noticed something
strange: many of the doctests marked "optional - dot2tex graphviz"
actually pass even when neither dot2tex nor graphviz is installed.
There are 28 doctests which have "# optional - dot2tex" or "# optional -
dot2tex graphviz"
Hello all Sage developers,
I am getting more and more annoyed that many people tend to report bugs
(both on Trac and on the mailing list) *without* tracebacks.
Those tracebacks are often crucial information to fix a bug. For a
totally reproducible and deterministic bug, this isn't so bad
Anybody has a complete backtrace, preferably with GDB installed?
--
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
On 2017-10-05 07:41, Ralf Stephan wrote:
Replacing sig_str() with sig_on() in matrix_integer_dense.pyx:_cinit
resolves it.
Probably sig_str() is broken in the new Cython.
Interesting. Are you very sure about this? On which system do you get
this error and is it reproducible?
--
You received
On 2017-09-27 16:10, Vincent Delecroix wrote:
Not sufficient: the package has to be useful for Sage and used in
Sage... emacs is unlikely to become an optional package even if it
satisfies the above conditions.
That's why I added "as opposed to experimental" :-)
emacs shouldn't be
On 2017-09-27 09:11, Vincent Delecroix wrote:
If FriCAS is
* well maintained
* does build on various architectures and systems (32bits/64 bits,
GNULinux/cygwin/OSX)
Indeed. This is exactly the necessary and sufficient condition for a
package to be optional (as opposed to experimental).
--
I'll try to have a look today.
--
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
On 2017-09-26 12:10, Maarten Derickx wrote:
I can't seem to reach trac.sagemath.org , the page seems to take forever
to load. Do other people have this problem as wel?
Me too.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from
On 2017-09-22 12:31, Simon King wrote:
On 2017-09-21, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
So +1 for type(x) on non Element.
More precisely: If isinstance(x,Element), then one shouldn't call
.parent() either. Instead, one could use x._parent.
That is what the current
On 2017-09-21 15:34, 'Martin R' via sage-devel wrote:
It turns out that this has been noticed before:
https://trac.sagemath.org/ticket/20626#comment:2
And there is even a rejected fix!
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
After cleaning up some code related to homsets in #23905, I noticed that
the new code was about 20% to 30% slower in some cases. I traced this
difference to a call
R = parent(x)
where x was a Python function (so, not a Sage Element).
It turns out that parent(x) tries to call x.parent(). If
On 2017-09-20 02:28, Kiran Kedlaya wrote:
Currently, some code is unable to be included in Sage (except as an
optional package) because it is not 32-bit safe. One example close to my
heart is Drew Sutherland's smalljac package for computing L-series of
hyperelliptic curves; Drew's position is
On 2017-09-15 21:48, Travis Scrimshaw wrote:
On Friday, September 15, 2017 at 2:31:05 PM UTC-5, Maarten Derickx wrote:
Is it assymptotically 10% or is it 10% for the case in which you are
testing it? In the first case I would be surprised in the second
case it is not that weird.
On 2017-09-16 03:31, Nils Bruin wrote:
So if you're finding you can't put a "from A import a" at the top-level
and using it locally has noticeable cost (which can easily happen:
imports have a significant cost, even for modules that are already
present), then you could try to do a straight
On 2017-09-15 09:00, Jori Mäntysalo wrote:
If so, a
bug in Sage could -- at least in theory -- lead a compromise to the server.
It's a *feature* of Sage (actually Python) that it can run arbitrary
code, not a bug.
--
You received this message because you are subscribed to the Google Groups
On 2017-09-14 15:21, kcrisman wrote:
Well, in principle someone could use a bug in an outside program to hack
into Sage
If that "outside program" is executing arbitrary strings in Sage, the
bug is with that outside program, not with Sage.
There is a reason why things like the Sage Cell
On 2017-09-13 21:56, rjf wrote:
Just because a package builds, loads, and passes some tests
doesn't mean that it also includes some security attack.
Does anyone care about / have any useful thoughts about /. that?
What would security even mean for a mathematics program? Sage is not
meant for
On 2017-09-13 15:28, Maarten Derickx wrote:
So the main questions: do we consider an optional package not building,
not passing it's own testsuite or causing sage to have doctest failures
a bug?
Yes.
In the other thread it was mentioned that patchbot failures should be
considered blocker
On 2017-09-11 18:59, Maarten Derickx wrote:
I think that all patchbot failure tickets should automatically deserve
the status critical.
They should be blockers (unless the error comes from a broken patchbot).
p.s. Tips on how to search for tickets on trac are welcome!
Google
On 2017-09-10 06:09, Maarten Derickx wrote:
I plan to work on https://github.com/sagemath/sage_sample quite a bit. For
which I hope that it falls under sage packaging ;)
I think we have 2 or 3 such projects in the mean time. Maybe we should
take the best ideas from each.
--
You received
On 2017-09-08 14:55, Simon King wrote:
sage: cython("""
: #!clib gap
: from sage.libs.gap.gap_includes cimport *
: from sage.libs.gap.element cimport GapElement_FiniteField
: from sage.libs.gap.libgap import libgap
: def test(x):
: libgap_enter()
: cdef
On 2017-09-08 11:31, John Cremona wrote:
What does that look like in terms of (a,b,c)?
Totally crazy. The obvious thing gives a very complicated polynomial.
The problem of course is that everything is defined modulo the equation
f(x,y,z) = 0. So you need to find a simple representative in
On 2017-09-07 19:11, Ben Hutz wrote:
There does not appear to be an __eq__()
operator implemented for scheme points, but it does show up in tab
completion in the notebook, but can't tell me where the code is from. Is
this an artifact of starting to transition the code to python3. Or this
just
For completeness:
We should also consider negatives. But it turns out that going from P to
-P simply turns (a,b,c) in (b,a,c).
There is also a torsion point T = (56 : 728 : 1)
Adding that point gives genuinely different solutions. With the torsion
point, the first solution is psi(13*P + T).
Hello all,
In order to keep distributions happy, I managed to do the PARI upgrade
in such a way that compatibility with PARI-2.9.3 will remain.
I specifically created a new ticket
https://trac.sagemath.org/ticket/23796 for this. After this ticket, the
only doctest failures with PARI master
On 2017-09-06 17:28, Ximin Luo wrote:
If there is no "normalise" function for that context, perhaps there is at least
a method to check that two objects represent the same mathematical group, so:
I sort of agree in principle, but this is easier said than done. In many
cases, the mathematics
On 2017-09-06 17:24, Erik Bray wrote:
Interpreting
"str" as "bytes" is the only way it can be if language_level=2.
I think you are misunderstanding. You didn't post the complete C code
generated by Cython:
__pyx_t_4 = __Pyx_PyBytes_FromString(__pyx_v_s); if
(unlikely(!__pyx_t_4))
On 2017-09-06 17:05, Erik Bray wrote:
"language level 2" [...], where "str" means "bytes".
[citation needed]
Where did you get the idea that Cython interprets "str" as "bytes" with
Python 3?
In https://trac.sagemath.org/ticket/23089 I argued *against* changing
the Cython language_level.
On 2017-07-25 22:16, Jeroen Demeyer wrote:
Hello sage-devel and sage-packaging,
I propose to upgrade the PARI package to the git master version instead
of the current released version.
Now that the cypari2 upgrade has been merged, I am working on this.
Thanks to the new cypari2, *building
On 2017-09-04 23:37, Dr. David Kirkby (Kirkby Microwave Ltd) wrote:
removing it would make a 64-bit Solaris port more work.
I disagree here. It is very likely that fixes are needed anyway to port
Sage to 64-bit Solaris. So if things need to be fixed, we should think
of the best way to fix
On 2017-09-04 19:34, Erik Bray wrote:
+1 I think if this functionality is needed for Solaris (or any other
platform) it should be moved into configure.ac, and the explicit
environment variables done away with.
Totally agreed!
--
You received this message because you are subscribed to the
There is the message "Killed" which can normally only happen if
something external kills Sage. A common case is the Linux OOM
(out-of-memory) killer which kills processes when the system runs out of
memory. Second, the docbuilder is known to use huge amounts of memory.
--
You received this
Possibly, you are running out of memory.
Are you building in parallel?
How much memory (RAM + swap) do you have?
Was your system particularly loaded while you were building Sage?
Is the error reproducible, i.e. does it happen again if you retry the build?
--
You received this message because
In the long section "Rationale for Cygwin and possible alternatives", I
would add subsections for each alternative.
[hardware-assisted virtualization] typically does not come enabled by default
(as a security measure)
Is that really true? What is non-secure about hardware-assisted
On 2017-08-30 09:37, david.coud...@inria.fr wrote:
It's not a bug, it's how equality is defined
Thinking of the coercion model, I would argue that this is a bug.
Of course we don't do coercions for graphs, but one could imagine a coercion
graphs without loops -> graphs with loops
and then
On 2017-08-28 12:45, Nicolas M. Thiery wrote:
- Are there plans to enforce the above future imports to our doctests? In
particular unicode_literals which seems more problematic?
TL;DR: I do not consider it a problem that stuff breaks with "from
__future__ import unicode_literals".
The
On 2017-08-28 14:33, Simon King wrote:
Is there any chance to get it to work for
magical Python methods?
Certainly not easily. It could be done on a case-by-case basis, but not
in general.
If not, then I think magical methods should be
banned from the category framework.
De facto, this
I'm guessing it might be this from
https://docs.python.org/3.6/reference/datamodel.html#object.__hash__
A class that overrides __eq__() and does not define __hash__() will have
its __hash__() implicitly set to None.
Python2:
>>> class X(tuple):
... def __eq__(self, other): return False
On 2017-08-28 13:03, Nicolas M. Thiery wrote:
This has been rediscussed recently, with attempts to assess precisely
the overhead and mitigate it. I don't manage to find the exact ticket,
but it's around #23435; Jeroen do you remember?
It's the discussion on
On 2017-08-25 13:37, Simon King wrote:
Not much, actually:
My point was that a __dict__ makes any attribute access slower, not just
this lazy attribute. It will also seriously slow down cpdef methods.
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
On 2017-08-25 13:07, Simon King wrote:
Hi!
I just realise that @property works for Cython, and it is
competitive!
Indeed. Cython has optimized code to deal with standard decorators like
@staticmethod, @classmethod and @property.
The reason that lazy_import does not work for Cython classes
On 2017-08-25 11:59, Erik Bray wrote:
I found this to also be a significant source of slowdown, every time
sage-env is sourced
See https://trac.sagemath.org/ticket/23711
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this
On 2017-08-25 11:59, Erik Bray wrote:
This can probably be avoided, somehow...
Why do we even need the matplotlib version number in the first place?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
On 2017-08-23 23:44, Marc Masdeu wrote:
This is essentially what they are supposed to be.
But it's not what your package does! You are using "sage" all over the
place.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this
On 2017-08-23 17:44, Marc Masdeu wrote:
I know that there is several people who think that this is not the way
that code should be distributed. I am asking feedback from the
complementary set of people, really (although constructive comments from
anyone are definitely welcome!).
My personal
On 2017-08-22 16:43, Ralf Stephan wrote:
Is there a chance one can put a @doc_index decorator on cdef methods in
a Cython file?
Not without patching Cython. This isn't the first time this problem came
up, so maybe this is a less crazy idea than it sounds initially.
Now, often the *features*
On 2017-08-08 00:43, Stefan wrote:
P.S. The Graph class does way too much sorting. See e.g.
sage.graphs.generic_graph.GenericGraph.vertices()
I created https://trac.sagemath.org/ticket/22349 for that.
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
The simplest workaround is to use F[i] instead of F[i]
--
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
301 - 400 of 3164 matches
Mail list logo
