On Mon, Sep 9, 2019 at 7:51 PM John H Palmieri wrote:
> I am writing to ask for help fixing a Python 3 problem. On some platforms,
> there are Python 3 doctest failures in
>
> - libs/eclib/interface.py (#28454)
I believe that this has been fixed upstream, it has certainly been
reported by me.
On Sun, Sep 1, 2019 at 9:14 PM Thierry wrote:
> It should also take into account some deep changes in the logic.
I agree in general. But in my opinion, it's mostly independent of
porting Sage to Python 3. We could do those changes now or next year,
it doesn't really matter.
--
You received
On Thu, Aug 29, 2019 at 6:02 PM Samuel Lelievre
wrote:
> Possibly somewhat related (sorry if not): after building Sage
> for Python 3, running `sage -t` lets the doctesting framework
> decide what to set `optional` to, and apparently it uses
> "python2" rather than "python3"; is this the desired
On 2019-08-07 15:42, E. Madison Bray wrote:
What if, at some point, we just make a Sage release that breaks
backwards compatibility?
We could, but I don't think that PEP 3141 is worth breaking backwards
compatibility for.
--
You received this message because you are subscribed to the Google
On 2019-08-06 17:30, TB wrote:
sage: plot(lambda x: x.imag + 2) # Works
sage: plot(lambda x: x.imag() + 2, (x, -3, 3)) # Empty plot
That's "only" an annoyance: you need to use x.imag or x.imag() depending
on what x is. That's not a problem of interoperability. And if you
really want generic
On 2019-07-27 18:49, 'Mark Bell' via sage-devel wrote:
During Sage Days 100, I experienced an issue with Sage's Integers and
Rational not being compatible with Python's built in Fraction class.
This made me unable to run my Python code within Sage
It would be good to explain better exactly
On 2019-06-07 16:38, E. Madison Bray wrote:
While I agree it's part of an annoying trend, this is one change I
welcome: The Python interpreter shipped in OSX has always *always*
been broken and unusable
What matters for Sage is: was it sufficiently functional to bootstrap a
build of Sage?
On 2019-05-17 10:02, Kwankyu Lee wrote:
What is the proper way to copy a cython object with all its attributes?
Write a __copy__ method doing the copy manually. Unless I'm missing a
Cython feature that helps with this.
--
You received this message because you are subscribed to the Google
On 2019-05-13 16:04, Dima Pasechnik wrote:
as Debian does not have iconv in libgd, I assume it's safe to remove
the dependence.
If that's possible, sure.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
On 2019-05-13 15:51, Michael Orlitzky wrote:
It's possible to build libgd without iconv as
far as I can tell (check CMakeLists.txt)
A dependency is not the same as a requirement. If it's used by the
package (optional or not), it's almost certainly a dependency.
--
You received this message
On 2019-05-09 11:42, Sébastien Labbé wrote:
I was expecting the tag list to be the same. The missing ones are build
and dochtml.
build and dochtml have to be specified explicitly. This is working as
intended.
--
You received this message because you are subscribed to the Google Groups
I think that your environment is too messed up. Why do you have all
those environment variables like $CPATH and $LD_LIBRARY_PATH set? That's
probably what's causing the breakage. Can you try to build in a clean
environment, without setting any such environment variables?
--
You received this
On 2019-05-09 10:55, Vincent Delecroix wrote:
Dear Pepijn,
Your config.log mentions that you ran
$ ./configure --prefix=/home/pwissing/sage-8.7/local
--libdir=/home/pwissing/sage-8.7/local/lib
--with-gmp=/home/pwissing/sage-8.7/local
--with-mpfr=/home/pwissing/sage-8.7/local
That's the
On 2019-04-15 13:56, Frédéric Chapoton wrote:
* An expert is required on src/sage/misc/classcall_metaclass.pyx
Is there a ticket for that?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails
On 2019-04-14 22:42, Mark wrote:
include "cysignals/signals.pxi"
That's no longer supported. The proper way to use cysignals is
from cysignals.signals cimport sig_check # or whatever you need from
cysignals
--
You received this message because you are subscribed to the Google Groups
How did you notice that, i.e. why do you need SAGE_LOGS?
I'm -1 on restoring SAGE_LOGS, since it's one of those things which
confuses build-time and run-time. There should be no need to access the
Sage build logs at run-time. On binary installations, there might not
even be a logs directory.
On 2019-04-09 16:29, Bill Page wrote:
Is this a known problem?
Now it is: https://trac.sagemath.org/ticket/27629
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
See https://trac.sagemath.org/ticket/27477
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send
On 2019-03-11 16:42, Eric Gourgoulhon wrote:
Shall I open a ticket?
Yes and please include the traceback.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
On 2019-03-11 10:42, E. Madison Bray wrote:
The spkg-install script (e.g. under
local/var/tmp/sage/build/patch-2.7.5/spkg-install) should start with a
shebang line like
#!/usr/bin/env bash
So that should already use the correct shell unless your `bash` is
actually something that is not
This is probably https://trac.sagemath.org/ticket/27374
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this
On 2019-03-08 19:18, Volker Braun wrote:
* If is optional then add a #warning that it is recommended
Yes, it's optional but the hard part is figuring out whether it's
supported or not.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
On 2019-03-08 10:42, Jeroen Demeyer wrote:
(*) For some reason, the analogous C header works
regardless of MACOSX_DEPLOYMENT_TARGET. Unfortunately, this header is
not compatible with C++, so I really need .
I just realized that I tried this only with g++ on Linux. With clang++
on OS X, does
Hello,
While working on cysignals, I encounted an issue with
$MACOSX_DEPLOYMENT_TARGET. I have a fix, but I don't know if it's good.
It's not specific to Sage, but it will affect Sage since cysignals is a
Sage package.
For cysignals, I'd really like to use MACOSX_DEPLOYMENT_TARGET >= 10.9
On 2019-03-03 12:46, Simon Brandhorst wrote:
Shouldn't the gp session be closed afterwards? After all it is not
used/referenced anymore?
So that the file descriptor gets freed again?
If not what is the recommended way to start computations in gp
The recommended way is not to use the GP pexpect
On 2019-03-03 12:46, Simon Brandhorst wrote:
Shouldn't the gp session be closed afterwards? After all it is not
used/referenced anymore?
But maybe it's not closed *immediately*. It would be interesting to do
the same experiment with a time.sleep(0.1) or a gc.collect() in the loop.
--
You
On 2019-03-03 11:48, Vincent Delecroix wrote:
Is this supposed to crash Sage?
OK, I missed that part. The fact that you run out of file descriptors is
not a bug, but the fact that it crashes Sage is a bug.
--
You received this message because you are subscribed to the Google Groups
On 2019-03-03 11:43, Vincent Delecroix wrote:
Could you open a trac ticket? This is definitely a bug
(most probably in `interfaces/expect.py`).
I wouldn't call it a bug. You're opening 1 independent GP sessions,
which each need a few file descriptors. It's normal that you run out of
file
Since many years, we have patched the Python in Sage with a patch to
mitigate some security issues related to sys.path.
The security issue is the following: if you run a Python script from a
world-writable directory, say a script like /tmp/foo.py this is very
insecure since Python will add
On 2019-02-27 15:25, Daniel Krenn wrote:
Can I savely assume that S.an_element() of something S (within SageMath)
returns an element different from S.zero() if possible (meaning if there
are nonzero elements in S)?
Personally, I wouldn't assume anything.
--
You received this message because
On 2019-02-27 10:31, Simon Brandhorst wrote:
Okay. But I cannot reproduce the error consistently. Post anyways?
Yes. The traceback is clear enough.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
On 2019-02-26 17:52, John Cremona wrote:
I am testing a new version of the standard spkg eclib, see
https://trac.sagemath.org/ticket/27360. I am getting doctesting
failures caused *only* because of changes in output buffering resulting
in the tail end of the output of one command appearing at
On 2019-02-27 09:58, John Cremona wrote:
The problem went away after I did "make distclean; make build".
Originally what I did after checking out a new branch was
(1) put the new tarball into upstream/
(2) edit the file build/pkgs/eclib/package-version.txt
(3) issue the magic command which
On 2019-02-27 08:35, Frédéric Chapoton wrote:
This problem is also seen in the python3 patchbot report, as can be
found here :
https://patchbot.sagemath.org/log/0/Ubuntu/16.04/x86_64/4.4.0-141-generic/atlas/2019-02-24%2011:31:45?short
In Python 3, the situation is different because Python
On 2019-02-26 17:52, John Cremona wrote:
I am testing a new version of the standard spkg eclib, see
https://trac.sagemath.org/ticket/27360. I am getting doctesting
failures caused *only* because of changes in output buffering resulting
in the tail end of the output of one command appearing at
Please create a Trac ticket for this.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email
On 2019-02-26 23:44, Kwankyu Lee wrote:
It could be possible to hammer the coercion model to behave more nicely
with the category framework, at least with respect to the issue that I
raised.
By the way, why is it an issue in the first place? Is there any reason
why you don't want to inherit
On 2019-02-26 21:53, Jeroen Demeyer wrote:
I think that you are 100% right but that (as with many things) it is the
way it is for historical reasons and it hasn't bothered anyone
sufficiently much to change it.
Part of the reason why I haven't personally touched _lmul_/_rmul_ (while
I did
On 2019-02-26 14:44, Kwankyu Lee wrote:
My question is: why should I use `ModuleElement` instead of just `Element`?
If I use `Element`, the scalar multiplication is not detected by the
coercion system. So I am forced to use `ModuleElement`.
Since my parent is in the category of modules over
You can ignore that "An unexpected error occurred while tokenizing
input" message. It's IPython having trouble with the traceback, it has
nothing to do with your Cython code.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from
On 2019-02-13 11:02, jonathan.kliem via sage-devel wrote:
I'm getting a strange error when raising an error in cython(), example:
I don't really understand your problem. You ask Cython to raise an
exception and the exception is raised. It seems like Cython is doing
exactly what it's supposed
Why neither nbviewer nor binder are able to find
(or serve or ?) these javascript files?
The problem is these lines in src/sage/repl/rich_output/backend_ipython.py
These paths should be changed to take into account the base URL of the
server (don't ask me *how* to do this precisely).
--
On 2019-02-11 11:12, David Coudert wrote:
Le mardi 29 janvier 2019 23:19:12 UTC+1, Thierry (sage-googlesucks@xxx)
a écrit :
Hi,
On Sun, Jan 27, 2019 at 11:21:21AM -0800, David Coudert wrote:
[...]
> The most complicated issue is certainly edges of Graph: we sort the
>
On 2019-02-06 20:52, Nils Bruin wrote:
This is the same as in python:
>>> import signal
>>> signal.alarm(1)
0
>>> Alarm clock
It looks like this is just the default signal handler for python (the
one that just prints the signal name and exits)
For the record, that message "Alarm clock" is
On 2019-02-07 16:45, E. Madison Bray wrote:
Apparently Jeroen argued about this with the IPython developers some
time ago: https://github.com/ipython/ipython/pull/9867
Indeed. Your post did seem familiar to me, but I actually forgot about
that discussion.
--
You received this message
> Out of curiosity: How many existing tests fail for that reason?
We had to fix a *huge* number of issues because of comparing apples and
oranges. It was one of the biggest porting efforts towards Python 3, that's why
I consider it a big deal. Look at the long list of dependencies on Trac
Trac ticket #22029 changes the coercion model such that comparisons of
Element instances now behave like in Python 3. This means that
comparisons of elements with uncomparable types/parents will raise an
error instead of returning some random answer. I believe that this is an
important step in
There are problems with patchbot zancara:
OSError: [Errno 122] Disk quota exceeded:
'/home/mi/kliem/.sage/temp/zancara/16740'
Full log:
https://patchbot.sagemath.org/log/27152/debian/9.6/x86_64/4.9.0-8-amd64/zancara/2019-01-29%2021:56:24
--
You received this message because you are
On 2019-01-29 09:32, Vincent Delecroix wrote:
1) When a user performs `sage -pip install X`, should the documentation
be compiled and installed?
I'm pretty sure that the answer is "no" for most Python packages. I see
two reasons for this:
- there is no easy and obvious way to integrate
On 2019-01-28 06:18, Travis Scrimshaw wrote:
See possibly https://trac.sagemath.org/ticket/27114.
No, it's https://trac.sagemath.org/ticket/27109
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving
On 2019-01-27 22:36, Simon King wrote:
But do py3 experts agree that to transform os.path.join(...) to char*
(which is not in pickling but in module initialisation), I need
PyString_...?
No! Please see src/sage/cpython/string.pyx
(sorry no time now to answer more)
--
You received this
On 2019-01-27 19:23, John Cremona wrote:
On Sun, 27 Jan 2019 at 17:10, Frédéric Chapoton mailto:fchapot...@gmail.com>> wrote:
ok, then --optional=sage,py3 is ok (all doctests pass) whereas
./sage -t --optional=sage,py2 src/sage/modular/cusps_nf.py
Is there a particular reason for
On 2019-01-27 14:23, Frédéric Chapoton wrote:
Some good python3 changes are blocked by the long awaited ticket
https://trac.sagemath.org/ticket/23572
What do you mean with that? It's a ticket adding doctests for a book,
how is that related to Python 3 porting?
--
You received this message
On 2019-01-23 00:11, William Stein wrote:
I helped support somebody using the Cygwin
version of Sage on Windows at the Sage booth at the Joint Math
Meetings last week, and it typically took about 1 minute to start up
Sage, which was scary.
But mathematical computations (which do not involve
The error message seems to imply that you tried to install (part of)
Sage as a different user. Maybe the safest option is to delete your
installation completely:
rm -rf /home/devikasugathan/sage
and then try again.
--
You received this message because you are subscribed to the Google Groups
On 2019-01-13 15:34, Dima Pasechnik wrote:
As we see, Debian is already picking up this update.
If Debian *already* has it anyway, what's the point of upgrading it in
SageMath? Especially if it doesn't require any changes to the Sage library.
--
You received this message because you are
Does anybody have any idea what is the purpose of
compile_result_dir = os.environ['XML_RESULTS']
in src/setup.py?
It was introduced in https://trac.sagemath.org/ticket/9828 in a ticket
about upgrading Cython but without explanation...
Jeroen.
--
You received this message because you
On 2019-01-10 21:51, 'Julien Puydt' via sage-devel wrote:
Didn't François mention changing SAGE_ROOT wasn't needed?
He said
SAGE_ROOT should only be needed for the packaging system
and possibly the doctests. I regard any needs for SAGE_ROOT at runtime
a bug.
In other words: it is still
On 2019-01-10 20:46, 'Julien Puydt' via sage-devel wrote:
Le 10/01/2019 à 20:07, François Bissey a écrit :
I have recently made the following change in sage-on-gentoo’s env.py
_add_variable_or_fallback('SAGE_LOCAL', sysconfig.get_config_var("prefix”))
which means SAGE_LOCAL is now
On 2019-01-04 10:22, John Cremona wrote:
Some of the runs I have been doing use a large amount of RAM and some
fail
"fail" in which sense? I assume you mean a PariError saying that the
stack overflowed but I can only guess...
One is suppose to be able to increase this using the following
On 2018-12-22 12:32, Volker Braun wrote:
Just avoid premature optimization; Nobody cares if the one-time dlopen()
takes a nanosecond longer or not...
I agree here... especially for a one-time function call.
And even if you do plan to open the GAP library thousands of times per
second, you
On 2018-12-20 00:12, Dima Pasechnik wrote:
How about trying to get this into 8.5? (or perhaps 8.5.1?)
Rushing GAP 4.10 in Sage 8.5 doesn't sound like a good idea to me.
Ideally, it should be sufficiently tested in betas.
--
You received this message because you are subscribed to the Google
I suggest the following:
If Sage 8.5 is ready to be released right now, I see no reason to delay
that. Then follow up soon with Sage 8.6.
On the other hand, if Sage 8.5 is going to dragged for other reasons
anyway, then we might as well try to get GAP-4.10 in this release.
--
You received
On 2018-12-13 13:11, John Cremona wrote:
The problem is that t is a pari gen and Sage tries too hard to compare
that with python 0.
This has nothing to do with Sage or Python, the "problem" is that PARI
considers [0] and 0 equal.
Personally, I think that Sage (really the package cypari2
On 2018-12-06 14:07, Simon King wrote:
And if I understand correctly what you said in another post, it is
*dynamically* determined which reference is weak and which reference
is strong. When is it determined? During cyclic gc?
Yes, during GC: that's the only time where it matters. More
On 2018-12-06 08:35, Simon King wrote:
Then what will be your reference graph? Or phrased differently:
Where/how will you store coercion maps?
The basic idea is the following (I have not worked out all the details yet):
* The coercion model only stores weak references to anything (domains,
On 2018-12-06 01:36, Nils Bruin wrote:
Because the coercion map from A to
B is also stored on A, a strong reference to B exists.
No. The map will be referenced both from A and from B with one of those
references weak and one of those references strong, without specifying a
priori which one
On 2018-12-05 18:33, Nils Bruin wrote:
I think you were thinking of limiting the life span of c via referencing
it via a "MultiWeakRef" from both A and C. However, with the scenario
above, A has its life span already bounded below by C anyway, so the
"MultiWeakRef" never gets to work its magic.
On 2018-12-05 14:54, Simon King wrote:
o Mild problem: If there is an external strong reference to, say,
f, then it is possible that Q becomes garbage collected anyway,
and we would end up with an invalid map.
That is one of the things that I would like to fix: maps and
On 2018-12-05 16:50, Volker Braun wrote:
Right, automatic clearing of circular references is only in Python 3...
I would phrase that as: properly dealing with __del__ is only in Python 3.
Luckily, __del__ is used only very rarely in Sage.
--
You received this message because you are
On 2018-12-04 18:06, Nils Bruin wrote:
Tripledict does that to some extent (with its keys): if one of the key
parts gets deallocated, the weakref callback removes the strong
reference to the value.
Yes, but then we potentially end up again in the situation where things
are *only* weakly
On 2018-12-03 17:21, Nils Bruin wrote:
In order to
make that possible, the coercion map (referenced strongly on the
codomain -- it needs to be strongly referenced somewhere to keep it
alive) must not hold a strong ref to the domain.
I wonder if there is a way to somehow reference an object
I am studying the coercion model in detail, looking for optimization
opportunities. One source of slow-down is the use of weak references.
Over time, more and more places in Sage use weak references. But I'd
like to look at the big picture and see where weak references should be
used and
This week I worked on the coercion model to make it faster. It turns out
that there was some margin for micro-optimizations. There are two
tickets in need of review: #26776 and #26790.
If you need to be convinced, run
sage: a = RR(25); b = ZZ(2)
sage: timeit('a+b', repeat=100, number=10)
On 2018-11-29 10:38, E. Madison Bray wrote:
But I sometimes get failures in tests depending on which order the
*files* were run in. That's what I'm talking about.
But that's really unusual (and unrelated to --randorder). Do you have
*any* concrete example of such a failure?
--
You received
On 2018-11-28 09:17, E. Madison Bray wrote:
+1 There are several tests which, when run in an unusual order, result
in random failures. This is obviously a failure of test isolation if
nothing else, and such cases *should* be rooted out and fixed.
It's not a failure of "test isolation" if
On 2018-11-22 18:45, 'Martin R' via sage-devel wrote:
1) would it be easy and desirable to make the patchbots run tests in
random order?
Easy: yes
Desirable: no, it would create a lot of doctest failures
2) concerning https://trac.sagemath.org/ticket/26586, is it desirable to
define
On 2018-11-22 18:45, 'Martin R' via sage-devel wrote:
* The tests of individual functions within a single file are ALL
executed in the same environment.
Same "environment" in the sense of same Python process (there is one
process for each file to be tested). But global variables are
On 2018-11-06 19:07, François Bissey wrote:
SAGE_LOCAL is another story,
however we probably could figure it out from the python configuration rather
than a seed.
Isn't SAGE_LOCAL == sys.prefix
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
The license has not been updated yet in their git repo:
https://github.com/openssl/openssl/blob/master/LICENSE
I also downloaded the latest release (1.1.1) and it still contains the
bad BSD license.
So it seems that the license change is not official yet...
--
You received this message
On 2018-10-31 22:23, Volker Braun wrote:
With ipython/jupyter you can't run the notebook in the current Python
session, but you can just launch a completely new process.
Are you sure? Can't you just import the Jupyter application as a Python
package and run it that way? I have not tried it
On 2018-10-21 11:57, Volker Braun wrote:
Try "git remote prune origin" or "git remote update origin --prune"
Thanks. The first one worked.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails
Any ideas?
error: cannot lock ref
'refs/remotes/trac/u/embray/python3/sage-rings-polynomial-polydict/misc': 'refs/remotes/trac/u/embray/python3/sage-rings-polynomial-polydict'
exists; cannot create
'refs/remotes/trac/u/embray/python3/sage-rings-polynomial-polydict/misc'
From
Part of the problem (but certainly not all of it) is
https://trac.sagemath.org/ticket/26463
Sage was executing "from sage.rings.integer import Integer" 100 times.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this
Actually, I think that it's the .sage() call which is already taking a
long time:
sage: M = MatrixSpace(ZZ,1000,5).random_element()
sage: %time res = M.__pari__().matsnf(1)
CPU times: user 68 ms, sys: 0 ns, total: 68 ms
Wall time: 68.7 ms
sage: %time v = res.sage()
CPU times: user 4.03 s, sys:
On 2018-10-02 23:01, Dima Pasechnik wrote:
So you need to ship generated C files for C99, C11, and C++ files for
c++11, c++14, c++17, blah++foo, etc etc etc?
No. You *do* need to tell Cython the language (C or C++). But beyond
that, it generates code compatible with any version of the C/C++
On 2018-10-02 17:53, Dima Pasechnik wrote:
Letting Cython to do necessary adjustments for the target C/C++
compiler seems like the most natural thing to do...
Cython doesn't need to do any such "necessary adjustments". It's
completely independent of C/C++ compilers (and it should be).
--
On 2018-10-02 16:50, kcrisman wrote:
Thanks, Thierry. Sounds like we need a ticket for this.
I assume you mean a Snappy ticket since the problem with Snappy is
completely unrelated to Sage.
Note also (in general) that
You are using pip version 9.0.3, however version 18.0 is available.
On 2018-10-01 20:19, kcrisman wrote:
new = max(os.path.getmtime(file) for file in
glob('cython/core/*.pyx'))
ValueError: max() arg is an empty sequence
It's bad packaging by upstream: it's running Cython but the Cython
source files are not in the snappy source tarball.
--
You
On 2018-09-26 16:48, 'Martin R' via sage-devel wrote:
Indeed, it seems that the test is not actually being run.
You mean that it *was* not actually being run, but now it is. I don't
know what caused the change, but it's clearly in the good sense since
that doctest should be run.
--
You
On 2018-09-26 13:03, 'Martin R' via sage-devel wrote:
and all tests pass.
Which command are you using to run the tests? Something might have
changed there.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and
On 2018-09-24 18:00, Dima Pasechnik wrote:
Perhaps the most tricky is 2 (or perhaps not anymore, after out
infamous CoC discussion fiasco we could agree it makes sense to get
something in place; we can have a look at
https://numfocus.org/code-of-conduct
and see if we can just agree to this)
On 2018-09-26 10:10, 'Martin R' via sage-devel wrote:
In https://trac.sagemath.org/ticket/26348 a doctest is failing, because
apparently the semantics of "..." has changed.
I don't think that anything has changed here. As far as I know, "..." at
the start of a line after a "sage:" line has
It must be said that I found this tool quite valuable. When unpickling
goes wrong, it is typically not easy to find out why and explain_pickle
does help with that.
That being said, if nobody wants to maintain it, it has to go (with
praise, as you said)...
--
You received this message
On 2018-09-12 07:42, Simon King wrote:
However, the place in #25090/#25091 where the author uses is_package_installed,
is a Python file.
Why does a Python file care whether the normaliz library and headers are
installed? Now I'm looking at #25091 and it seems to me (but correct me
if I'm
On 2018-09-11 18:55, Simon King wrote:
Specifically, I ask because of #25090/#25091: How can one test whether
normaliz is installed?
Use Cython: see src/sage/features/bliss.py for an example for the
"bliss" library
--
You received this message because you are subscribed to the Google Groups
On 2018-09-10 21:36, John Cremona wrote:
The bug is because of this:
Since you almost fixed this bug, could you actually create a ticket to
fix it?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
On 2018-09-06 08:21, Andrew wrote:
*package:pip-18.0
log file:/usr/local/src/sage/logs/pkgs/pip-18.0.log
attach this log file please ^
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails
Let me make one important comment (something that I've said before
though): a large part of what makes the current workflow work is not so
much Trac itself but our git server and the "git trac" scripts.
For example, I very much like the fact that we have a single git repo
where all pull
On 2018-09-03 15:53, Erik Bray wrote:
P.S. If anyone has additional comments, positive or negative, on
https://trac.sagemath.org/ticket/25914 they would be most appreciated
That doesn't seem the right ticket.
--
You received this message because you are subscribed to the Google Groups
1 - 100 of 3164 matches
Mail list logo
