I have drafted a Python Enhancement Proposal (PEP) to unify built-in and
Python functions:
https://github.com/jdemeyer/PEP-functions
This is just a draft for now, it has not officially been submitted (so
there is no PEP number yet). Cython could benefit from this because
Cython functions woul
On 2018-03-28 15:05, Simon King wrote:
By "graphical", I really mean "interactively".
It seems to me that those would be two different things:
(1) A notebook widget for inputting matrices
(2) A command-line tool (running in the terminal) for inputting matrices
--
You received this message be
On 2018-03-28 14:52, Samuel Lelievre wrote:
Sometimes you want to copy-paste a matrix, say from a web page
(eg an Ask Sage question) where the matrix was given only as an
output, and you would hope to save yourself the trouble of adding in
all the commas.
That is a different issue: why would a
On 2018-03-28 14:25, Simon King wrote:
I think it would be nice for SageMath to have such function, too. Both
in the notebook and on command line, actually.
I don't see much point for the command line. If you're using the command
line, it's reasonable to expect that you can enter a matrix manu
On 2018-03-16 12:40, David Loeffler wrote:
IMHO, the patchbot should be reconfigured so that it re-tests ticket 0
after every upgrade, and if that test fails, the patchbot should stop
Absolutely not. I agree that the current patchbot situation is not good,
but what you propose is much worse.
This is https://trac.sagemath.org/ticket/24612
--
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 2018-03-13 23:26, Samuel Lelièvre wrote:
My view is that since it's pip-installable, it's as though it were
already an optional package.
I have a very different view of that. "optional" implies a level of
official support in SageMath. In particular, it should actually build
and work proper
On 2018-03-14 02:08, John H Palmieri wrote:
I feel like we need another class of package: "pending" (or perhaps some
other name) = those which we propose to make standard soon.
I agree with Vincent: the build system doesn't need to know that.
--
You received this message because you are subscr
On 2018-03-13 23:26, Samuel Lelièvre wrote:
What would it mean to make it an optional package?
Exactly the same as making it a standard package, except that the type
is "optional" instead of "standard".
Once you do that, it will be trivial to make it a standard package by
just changing the
Cython 0.28 has been released, see below for the official announcement.
The Sage ticket is #24111, but it needs to be updated.
Hi everyone,
I'm pleased to announce the immediate availability of Cython 0.28, after
almost half a year of development.
https://pypi.python.org/pypi/Cython/0.28
Th
On 2018-03-13 18:33, Samuel Lelievre wrote:
Let me try to make the case for making JupyterLab a standard package.
What is your case for *NOT* making it an optional package first?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe fr
On 2018-03-13 14:42, Erik Bray wrote:
But it
sounds like that's more or less what Jeroen is proposing (as long as
it's not caching matrices by value?)
I'm not caching the Element (Matrix) but the Parent (MatrixSpace).
--
You received this message because you are subscribed to the Google Groups
On 2018-03-13 12:00, Nils Bruin wrote:
you'd be making life harder for the memory cache of the processor.
IMHO, if you worry about that, you shouldn't be writing Python.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this g
On 2018-03-13 10:38, Dima Pasechnik wrote:
this example, assuming the matrix size is a parameter, would easily
become a memory leak
You mean with my code from #24954? My idea is to cache strongly only a
fixed finite number (currently 128) of CachedRepresentation instances.
So even if you crea
On 2018-03-12 23:07, Nils Bruin wrote:
Your example doesn't convince me at all that we need this change though.
You should only consider making a change if you have a real-world
example that would significantly benefit and if you can show that
degradation in other normal use is minimal. A simplis
I created https://trac.sagemath.org/ticket/24954 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
There is some very bad behaviour related to CachedRepresentation caching
that I'm observing on #24742 (but this is otherwise unrelated to that
ticket):
sage: timeit('MatrixSpace(ZZ,3,3)')
625 loops, best of 3: 117 µs per loop
Now, we try again but we first create a strong reference:
sage: S =
On 2018-03-11 23:32, Travis Scrimshaw wrote:
When I set the umask of my laptop to 0002, then I can run doctests.
However, 0002 makes the created files/directories /more/ permissive by
making it group writable. So this seems like a bug in Sage to me; at
least it contradicts the error message...
What are the permissions of the directory where you installed Sage and
what is your umask?
--
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...@
On 2018-03-08 14:22, Vít Tuček wrote:
Sorry, I thought there is only one way to install Sage packages.
I ran sage -i dot2tex.
The error log is attached to my previous mail.
You attached a log file of mpfr, not for dot2tex.
--
You received this message because you are subscribed to the Google
On 2018-03-06 14:42, Vít Tuček wrote:
I tried install dot2tex in Sage 8.1
How? Which command did you run?
and got error building mpfr.
Which error did you get exactly?
See https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
--
You received this message because you are subscribed to the
On 2018-03-06 00:29, Samuel Lelièvre wrote:
I opened a ticket to make JupyterLab a standard package:
https://trac.sagemath.org/ticket/24904
Any opinions?
Shouldn't it be an optional package first?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" grou
On 2018-02-23 02:28, Matthias Koeppe wrote:
See https://trac.sagemath.org/ticket/21864
Interesting. The upstream issue is also related to header files. It
might be that the way how we worked around the upstream issue no longer
works with the new build system changes in Sage.
--
You received
Thanks everybody! It seems that OS X always gives the "wrong" result.
--
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 p
On 2018-02-22 21:19, Justin C. Walker wrote:
the crash log.
What is that? How do you produce such a log?
--
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-de
On 2018-02-22 17:32, Dima Pasechnik wrote:
$ clang forksigaltstack.c -o forksigaltstack && ./forksigaltstack
got signal 11
status = 0
Excellent. So it's only Apply who is crazy.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe fro
On 2018-02-22 16:13, David Joyner wrote:
clang: error: no such file or directory: 'forksigaltstack.c'
clang: error: no input files
Sorry, I obviously forgot to mention the step "copy the attached file
forksigaltstack.c to the current working directory" and then run
uname -a
gcc forksigaltsta
If you have an OS X (or BSD) system installed with development tools,
please run:
uname -a
gcc forksigaltstack.c -o forksigaltstack && ./forksigaltstack
and post the output. This code is a reduction of a test failure in
cysignals. I consider that failure to be an OS X bug. I want to have
some
If somebody wants to fix this, you should try pip. gambit is currently
one of the few Python packages that are installed using the classical
setup.py script instead of pip.
Changing to pip is an obvious thing to do anyway and it might even fix
the problem.
--
You received this message becaus
Interesting fact: the number of lines with trailing whitespace is
generally *increasing* with every Sage release. So it seems to me that
the biggest problem (if you find whitespace a problem) is preventing new
whitespace.
--
You received this message because you are subscribed to the Google Gr
On 2018-02-20 14:16, Erik Bray wrote:
I'd be completely fine with that so long as no one complains about
otherwise irrelevant whitespace cleanup coming along for the ride in
my tickets.
To clarify, I'm fine with this too if it's not too much in one branch
(this is of course very subjective).
First of all, we should ensure that no new trailing whitespace is added.
Otherwise, your effort is futile. The recently added file
src/sage/rings/valuation/valuation_space.py is a bad example.
I recall that we had a discussion about autogenerated patchbombs not so
long ago. I think it's a bad
On 2018-02-16 14:05, Eric Gourgoulhon wrote:
The build is successful though, as if it was mere warnings and not true
errors.
They are warnings, not errors. In this case, you can ignore them since
you probably don't have gmpy2 installed (it is not a standard package).
--
You received this me
On 2018-02-15 23:59, Andy Howell wrote:
I think you may have something else wrong with your system. I too
upgraded from 17.04 to 17.10. I built 8.2beta 3 with no problems. I'm
compiling beta 5 right now.
It would be interesting to see the output of
$ ldd /usr/lib/gcc/x86_64-linux-gnu/7.2.0/cc1
On 2018-02-15 22:37, Harald Helfgott wrote:
First, here is the output of /usr/lib/gcc/x86_64-linux-gnu/7.2.0$ ldd cc1
linux-vdso.so.1 => (0x7fff8af56000)
libisl.so.15 => /usr/lib/x86_64-linux-gnu/libisl.so.15
(0x7fcb74113000)
libmpc.so.3 => /usr/lib/x86_64-linux-gnu/libm
On 2018-02-15 21:34, Harald Helfgott wrote:
What is the issue here? What can be done?
Seems like a conflict between the mpfr/mpc libraries used by your
system's GCC and the libraries in Sage.
Can you try to find the location of the "cc1" program used by GCC.
Typically, this will be in a loc
On 2018-02-14 11:46, Frédéric Chapoton wrote:
But it is *very annoying* to work with it, because after a simple change
in any single file, "./sage -br" seems to *trigger the recompilation of
all 474 pyx files.*
I can't reproduce this on vanilla 8.2.beta5 with Python 3. So either
it's a specifi
On 2018-02-07 00:35, Volker Braun wrote:
But implementation details can surely be worked out. A totally basic
idea: put the specifics of the integer type and integer wrap/unwrapping
in an cython include file. At build time, copy the include file with the
desired implementation.
But what is the
On 2018-02-05 22:47, Volker Braun wrote:
A better implementation would be to make the integer implementation(s) a
build-time option; pplpy could internally use a fused type for all
available implementations.
I think that's a lot easier said than done. Also, a Python class cannot
really contain
On 2018-02-05 09:11, Vincent Klein wrote:
This require to have pplpy as a standard package. As pplpy use gmpy2 the
latter should be stantard too.
Do we agree to do this ?
Fine for me.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscr
On 2018-01-31 16:14, Samuel Lelievre wrote:
Not an expert in build systems, but
+1 to looping only once
+1 to the speedup
+1 to making it easier to use system packages for more of Sage's
dependencies
In case that it wasn't clear, I'm also +1 to all of the above.
--
You received this message be
On 2018-01-31 14:37, Erik Bray wrote:
All that's changed is how they're presented.
But that is a very important change! It's like "all I changed is
replacing your car by instructions on how to build a car".
I'm replacing this:
I don't see it that way. In my mind you are replacing readabl
On 2018-01-31 12:21, Erik Bray wrote:
I'm not going to say I didn't expect pushback from you on this, but I
feel like this is not a real argument.
I assure you that it was meant as a serious argument. I'm not
complaining for the sake of complaining.
In fact, the old code was still essential
On 2018-01-30 13:19, Erik Bray wrote:
I think the resulting Makefile, and its
template, are easier to understand for one.
This is unfortunately the part where I disagree and it is also the
reason why I am against the current patch. The resulting Makefile uses
some macro constructions which ma
On 2018-01-26 12:10, Dima Pasechnik wrote:
PS. We now have access
Who is "we"?
I'm certainly willing to have a look if "I" have access.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving email
On 2018-01-24 17:45, Dima Pasechnik wrote:
In a nutshell: break MPFR building, then do `./sage -f mpir`, and you
will see MPFR starting (and failing) to build.
I created https://trac.sagemath.org/ticket/24592 for this.
Workaround: `make mpir-clean; ./sage -i mpir`
--
You received this message
Can you give more details please? What is the precise command that you
ran and what is the output?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsu
On 2018-01-19 09:20, Ralf Stephan wrote:
Hi,
Is deprecation necessary for class member functions starting with
underscore, i.e. a weak "internal use" indicator?
No, unless it's a special method. Those are methods which typically
start and end with an underscore. See
https://trac.sagemath.org/
On 2018-01-17 12:00, 'Maria MacCallum' via sage-devel wrote:
Trying to run make.
Sparc processor, solaris 11.3
Unfortunately, we don't have any Solaris testing machines. So unless you
make such a machine available for testing, I'm afraid that it might be
difficult to fix Sage on Solaris SPAR
On 2018-01-16 12:40, mmarco wrote:
In order to organize the schedule, I would like to know how many hours
do you plan to spend in the miny course that you will give. If possible,
separate them in theoretical explanations and practical lessons (or
maybe even coding sprints).
For Cython, it proba
On 2018-01-12 14:48, Ralf Stephan wrote:
If you wanted to merge branch X into such a ticket you would just apply
the script on top of branch X. That was the point of the idea.
I get that, but it doesn't solve merge conflicts with other tickets.
--
You received this message because you are subs
On 2018-01-10 21:41, Richard_L wrote:
I happened to look through my system's dump log and discovered that
building Sage
Just to be sure that we are talking about the same thing, this happened
while *building* Sage, not testing?
For testing, some segfaults are expected.
--
You received this
On 2018-01-11 10:58, Ralf Stephan wrote:
I don't understand. What case exacty cannot be handled in your opinion?
Just the usual problem with "git merge" that you get conflicts if two
different commits change the same code.
--
You received this message because you are subscribed to the Google
On 2018-01-10 03:29, Simon King wrote:
Even reloading the page works (IIRC).
I don't think so because something needs to happen on the server side.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receivin
On 2018-01-10 08:44, Ralf Stephan wrote:
PS:
https://github.com/python-rope/rope
One problem is that rope cannot do Cython
Needless to say, that makes it absolutely unsuitable for Sage. Don't
waste your time with it.
--
You received this message because you are subscribed to the Google Group
On 2018-01-10 08:44, Ralf Stephan wrote:
I would like to
experiment with a new procedure for refactoring tickets that aims to
make reviewing them much easier, which will be needed for larger
refactorings that touch a lot of files.
I like the idea of using tools to automate refactoring.
***Howe
On 2018-01-09 00:38, Nils Bruin wrote:
An alternative workaround is to put a comment on the ticket yourself.
Even an empty comment works.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails f
On 2018-01-08 00:24, Samuel Lelievre wrote:
I noticed that Sage's Trac server sometimes delays
displaying commits on a ticket history; the commits
only appear attached to the next comments that gets
added to the ticket.
See https://github.com/sagemath/sage_trac_plugin/issues/10
--
You received
I was not proposing to "just" stop
So what do you propose then?
but i think that polluting all the
ticket's reports because of an unrelated issue is not productive.
Please propose an alternative which is more productive than "polluting
all the ticket's reports".
--
You received this messa
On 2018-01-02 22:59, Volker Braun wrote:
IMHO it shouldn't be easy to find. Certainly nobody should base their
work on it.
I agree here.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails fr
On 2017-12-24 17:07, Thierry wrote:
It should stop.
That's not a solution. If it just stops, then nobody would notice that
there is a problem. And since there are regularly problems, running a
patchbot would require a lot more work. You would just kill all
patchbots, which is much worse than
On 2017-12-23 12:41, Thierry wrote:
that it
would be a good thing to test against ticket 0 at each beta
I believe that the patchbot does that indeed. It just tests it and goes
ahead testing other tickets.
In your opinion, what should happen when a patchbot detects a failure in
ticket 0?
-
On 2017-12-23 11:20, Thierry wrote:
There is already a mechanism named "ticket 0": at every new beta release,
the patchbots must succeed to build and doctest the new version correctly,
before working on usual tickets.
I believe that's only when starting up the patchbot, not at every beta
rele
On 2017-12-23 10:41, David Loeffler wrote:
Is there any way we can make the patchbot recognise that its version of
Sage won't build, and stop testing tickets if so, rather than merrily
ploughing on testing tickets and reporting spurious "build failure"
messages to all of them?
-1 to hiding prob
On 2017-12-20 09:56, Vincent Delecroix wrote:
In #24285, I did implement a _arb_ and _acb_ methods on number field
elements. In order for the coercion model to use it, I had to fight with
coercions declared in the constructor (self._populate_coercion_lists_)
versus has_coerce_map_from. Depending
On 2017-12-21 10:58, Erik Bray wrote:
Do you mean you need some test to make
sure that a test someone wrote is actually being run?
Yes. We test that all things which look like doctests are actually
tested as doctest.
If there were a quoting issue in the doctest parser that happened to
be ca
On 2017-12-19 17:11, Simon King wrote:
Why "changes in the framework"? Isn't it possible to exploit what the
current framework has to offer?
At least, it would be convenient if the logic to determine a
NamedConversionMap was factored out to a separate method. Then
_coerce_map_from_() could ca
On 2017-12-19 12:17, Erik Bray wrote:
It's *attempting* to validate that the
doctest parser skips tests when it's supposed to.
Actually, it's also the converse.
Sometimes people write stuff like
"""
EXAMPLES::
sage:
"""
in random strings which aren't actually docstrings. The naive pa
On 2017-12-19 10:13, Simon King wrote:
Typically, _coerce_map_from_ either returns "True" or "None".
Interesting. For RIF, I implemented a specific coercion map. So in some
cases, I am returning a map instead of True/False/None.
But the problem that I need to solve is that this map is strict
On 2017-12-18 18:31, Simon King wrote:
One way to answer the question whether a coercion from A to B exists is
by implementing the method B._coerce_map_from_.
Right, I was asking the question because I need to implement such a
method for RIF and CIF.
If that method returns "True" then the c
Hello,
I'm working on coercion for interval fields (See Trac #24371) and there
is one issue that I don't know how to solve elegantly:
Sage has NamedConvertMap to convert via special methods like
_real_mpfi_(). When looking for a conversion map, it first tries to find
a coercion map and then
On 2017-12-11 18:35, Simon King wrote:
Well, we want to mix in P.category().element_class (an abstract class)
into whatever P prescribes for its elements. So, P.element_class
should be a class whose mro also contains abstract element classes
defined in the category.
What I did not say is that th
On 2017-12-11 13:31, Simon King wrote:
Except if the basic functionality refers to category stuff. Element
creation does!
Can you elaborate on this? In the case where a Parent has an
element_class attribute, why should element creation involve categories?
I agree that it should still be *pos
On 2017-12-10 22:29, Nicolas M. Thiery wrote:
As far as I remember, it's stipulated that any Parent should be in
Sets.
I don't think that this is stipulated somewhere. I also feel that this
shouldn't be a hard requirement. I think that the low-level basic stuff
(I consider creating elements a
On 2017-12-10 15:39, Travis Scrimshaw wrote:
My guess is so that one could define an _element_constructor_ at the
category level.
I see. The problem is that the category comes after Parent in the MRO,
right? So if Parent implements _element_constructor_, then the category
cannot.
--
You rec
The "modern" way to define a Parent class is as follows:
class MyParent(Parent):
Element = MyElement
def __init__(self):
Parent.__init__(self, category=MyCategory())
One thing which surprises me is that the code to have the "Element =
MyElement" trick work is implemented in the
On 2017-12-08 15:56, Erik Bray wrote:
I don't understand the point about the "buildbot
workflow" but it sounds like that might be a problem with that
workflow.
This was certainly the bottleneck when I was release manager. But I
cannot speak for the current release manager.
On most projects
On 2017-12-08 15:56, Erik Bray wrote:
Right now the way it (seems to) work is new tickets get assigned to
the next release milestone. That release is then
made...whenever...regardless of what tickets are still open or not,
and then all those tickets (typically) remain in old milestones for
compl
Your email was quite long so I'll just reply bit by bit...
On 2017-12-08 15:56, Erik Bray wrote:
What you really
want is to have some set of "core maintainers", possibly with
different responsibilities for different areas of the code depending
on their expertise. And a sign-off from one of them
On 2017-12-07 23:57, Simon King wrote:
from libc.string cimport memcpy
This one is fine.
include "cysignals/signals.pxi"
from cysignals.signals cimport FOO
include 'sage/ext/stdsage.pxi'
from MODULE cimport BAR
You'll have to fill in the exact values for FOO, BAR and MODULE though.
Th
See https://trac.sagemath.org/ticket/24337 for actually doing 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 pos
On 2017-12-08 10:26, Erik Bray wrote:
a) Have a normal "bleeding edge" master branch into which all accepted
changes are immediately merged
Now everything boils down to defining "accepted changes".
Just having a ticket set to positive review does not mean that much. It
is a bad idea to merge
On 2017-12-02 01:24, d...@shorewestern.com wrote:
communicative human nature yearns for
abbreviation
My impression is that this is mostly an American phenomenon.
Off-topic true story: when I was a young PhD student, I spent a few
weeks in Berkeley (California, USA). While walking to the unive
On 2017-12-04 23:52, Dima Pasechnik wrote:
I will open a trac ticket changing Math* to Wiskunde.
Great idea!
--
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 sag
On 2017-12-07 15:13, Simon King wrote:
How to fix that?
This is a bug that several people have reported but I don't know how to
reproduce it.
make distclean and start again?
That works.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To u
On 2017-12-06 15:49, Erik Bray wrote:
I think this question has come up before, but I don't know that
there's been a really satisfactory solution.
Many of the doctests have dicts as their output (or worse, contained
embedded in their output). This can fail from time to time since dict
element o
On 2017-12-04 16:04, Thierry wrote:
The problem in just rebuilding is that there might be old files lying
around still interacting
Well, those shouldn't interact. If they do, that's a bug.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsu
On 2017-12-04 15:37, Thierry wrote:
No, we have to be able to remove all the old stuff from the package.
You said "rebuilds the package and its dependencies" but you really mean
"uninstalls the package and its dependencies" (possibly followed by a
rebuild which is just a normal build at that
On 2017-12-04 15:23, Thierry wrote:
A great improvement in
the dev workflow would be to have a kind of "make clean " that
rebuilds the package and its dependencies
Doesn't "make -B " do something like that? I haven't tried.
--
You received this message because you are subscribed to the Google
On 2017-12-04 15:23, Thierry wrote:
i would vote to consider such issues as not-a-bug
I would *personally* report it as a bug if it would happen to me and I
know what causes it. Upgrade failures can be because of real bugs. For
example, if this would happen on every beta, it would be quite an
On 2017-12-04 10:53, Dima Pasechnik wrote:
Anyway, it's not a bug.
We are supposed to support incremental builds, so it is a bug. There
have been several reports of if, so it cannot be due to one
misconfigured system. On the other hand, nobody has bothered to create a
ticket for it, so maybe
On 2017-12-04 00:46, Dima Pasechnik wrote:
I saw this as well, while incrementally building 8.1.rc4.
I cannot reproduce this...
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, se
Do tracebacks work? That is obviously important to debug stuff.
I notice from the bug report on https://trac.sagemath.org/ticket/24221
that there is something wrong with traceback formatting.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To uns
On 2017-11-29 15:55, tuxedomask2002 wrote:
The executable, following the documentation.
Sorry, I cannot help you further given the explanation that you gave.
There is obviously something wrong with your setup, but I cannot guess what.
In any case, you should not manually set SAGE_ROOT if you
On 2017-11-29 14:15, tuxedomask2002 wrote:
./sage
Error: You must set the SAGE_ROOT environment variable or run this
script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory.
What is this "./sage" script that you are trying to run?
--
You received this message because you are subscribed to
On 2017-11-29 13:30, tuxedomask2002 wrote:
prepend-path SAGE_ROOT /home/groups/sc/modules/packages/sage/8.0/
However, when I try to start sage via "sage", I receive:
Error: SAGE_ROOT is set to a bad value:
Why are you manually setting SAGE_ROOT in the first place? Unless you
have multiple Sa
On 2017-11-22 02:49, François Bissey wrote:
This is a big upgrade, in fact it would have been easier to upgrade
to 2.0.2 but we missed that window.
You could still upgrade to 2.0.2 now and upgrade to 2.1.0 later, if that
makes your life easier.
we used an interpolation
What is "an interpo
On 2017-11-22 08:57, Gabriel Chênevert wrote:
I find pow's silent behavior quite unsettling
I agree! As it happens, I am working on fixing pow(). In the (near)
future, the 3-argument version of pow() will typically raise an error in
Sage, except in a few well-defined cases. For example, pow()
On 2017-11-18 09:22, Emmanuel Charpentier wrote:
You *should* be able to move the sage-x.y.z/ directory anywhere you
want. If you copy the sage script or make a symbolic link to it, you
should modify the script to reflect this (as instructed at the top of
the script). It is best i
On 2017-11-16 15:02, Eric Gourgoulhon wrote:
I understand that the Python2-syntax of super, i.e. super(class,
self), is still valid in Python3 [1] so this should not hamper the
transition to Python3, but in writing new code (as I am doing at the
moment) shouldn't we use the Python3 way, i.e. supe
201 - 300 of 3222 matches
Mail list logo
