On 2016-05-18 22:49, François Bissey wrote:
On 05/19/16 02:28, John Cremona wrote:
Two similar machines running ubuntu 14.04 and gcc-4.8.4. On one 7.2
built fine but on the other ipython ran into difficulties. This was
an upgrade from 7.1 in the git sense, i.e. I have the source repo,
which
On 2016-05-17 16:33, Bruno Grenet wrote:
B. What should the content (element) over QQ (or other fraction fields)
be?
I think that the gcd of the coefficients is the only good answer.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
On 2016-05-17 16:33, Bruno Grenet wrote:
3. Make `content` always return an element, create a method
`content_ideal` to return an ideal, and implement `content` only
over PIDs.
I vote for 3.
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
On 2016-05-17 15:14, Erik Bray wrote:
Perhaps one thing you might consider is a way to set the default
globally--so that for example all permutations can be set zero-based
from a single flag, without having to specify from_zero everywhere.
I think global flags like that are evil, since they
On 2016-05-15 17:46, saad khalid wrote:
I'm not exactly sure what to do here. Now, when I try running a doctest
like the following:
It's quite normal that doctests will fail, since Sage did not build
succesfully. If you want to build everything except for the
documentation, you can run "make
On 2016-05-16 11:34, Frédéric Chapoton wrote:
Once this is done, the plan is
to add "from __future__ import print_function" to src/sage/all.py.
Why only "once this is done". What makes that file so special?
--
You received this message because you are subscribed to the Google Groups
On 2016-05-12 15:32, Vincent Delecroix wrote:
Hi,
The point is that you are not able anymore to use variables from other
problems.
For good reasons obviously...
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group
Did you use the GCC from the system or from Sage? (to verify: does
$SAGE_ROOT/local/bin/gcc exist?)
--
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
This has been the default for a long time now, there is no need to add
it explicitly:
On 2016-05-09 00:17, Volker Braun wrote:
export SAGE_PARALLEL_SPKG_BUILD=yes
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this
On 2016-04-29 10:38, Nicolas M. Thiery wrote:
P.f(x) # use the morphism as a function
P.f.rank() # play with the morphism itself
cached method also does this.
You can do P.f(x) to call the cached_method f but you also do stuff like
My vote:
[X] Phase out properties which perform any non-trivial computation
In certain cases, properties might be useful (but it could very well be
that there are 0 such cases in Sage).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
On 2016-04-21 11:04, Simon King wrote:
I suppose it would be enough if SageMath would do the "from __future__"
imports at startup. In that way, the doc tests would automatically have
to comply with Python 3, isn't it?
No, future imports work on a file-by-file basis. Also, the parsing of
On 2016-04-21 10:47, Daniel Krenn wrote:
What about doctests?
Doctests are a different issue. I would prefer to *not* change doctests,
because doctests are supposed to mimic the Sage command line. If the
command line does not have __future__ imports, the doctests also should not.
--
You
Hello,
concerning the porting of Sagelib(*) to Python 3, I propose to
eventually add
from __future__ import print_function, division, absolute_import,
unicode_literals
to *every* .py(x) file in Sagelib (even those modules which don't print,
don't divide, don't import and don't have
On 2016-04-21 03:08, William Stein wrote:
Hi,
How much disk space is it supposed to take to download and build Sage
from source these days...?
It happens that I just did a make distclean; make
My whole $SAGE_ROOT is 7.3GB but that includes the git repo (258MB) and
the upstream files (903MB)
On 2016-04-20 16:26, William Stein wrote:
Hi,
My one remark for this thread is that it is relatively easy to make
something pip installable.
For anybody reading William's post, better use this link:
https://python-packaging-user-guide.readthedocs.org/en/latest/
It contains similar
On 2016-04-20 09:24, Volker Braun wrote:
I propose to delete them
I disagree. It's not because some packages are broken, that they should
all be removed.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
On 2016-04-17 03:27, kcrisman wrote:
Last night I was thinking about another issue - the eventual proposed
complete removal of sagenb from Sage
Just a small addition: even if we switch to Jupyter by default, that
doesn't mean that we will drop SageNB immediately. We should still ship
it as
Let me also remind everyone that you don't have to use the full source
tarball. If you like to download at build-time from the internet, clone
the git repo (which does not contain tarballs) and build from that.
--
You received this message because you are subscribed to the Google Groups
On 2016-04-16 17:29, Dima Pasechnik wrote:
Any other largish Python-based project that does these kind of tarballs
these days?
The Sage source tarball is a distribution containing many packages, it's
not a "Python project".
Of course it's hard to change this sort of attitude
I don't
On 2016-04-16 16:19, Michael Orlitzky wrote:
It gets us one step closer to a Sage that will use what's already
installed on the system.
No, it does not do that. It's just a different way of installing packages.
It will also make the Sage tarballs smaller
I don't think that "small tarballs"
Great... that still doesn't work.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to
What is the problem that your proposal fixes?
--
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 2016-04-16 12:15, Volker Braun wrote:
IMHO we should always use pip, but pip
depends on openssl.
Not for local packages, as far as I know.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving
On 2016-04-15 22:46, Dima Pasechnik wrote:
it does not quite work outside Sage tree.
Of course not. SageNB depends on Sage.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
On 2016-04-15 23:59, Volker Braun wrote:
So as a
minimal proposal, how about we just take over the SageNB github repo and
make releases whenever we need them. Which really isn't all that often.
Isn't that exactly the current situation? As long as Sage and SageNB are
in a separate git repo, we
On 2016-04-15 22:06, John H Palmieri wrote:
I don't know if there are any right now, but I think that many of the
recent changes in sagenb have come because there were changes in the
Sage library. Maybe "difficult" is not the right word, but this adds an
artificial layer of complexity: instead
On 2016-04-15 21:53, Dima Pasechnik wrote:
Why not? You haven't answered this question.
Does sagenb run without Sage now?
No, it needs Sage.
Python packages can have dependencies, so the fact that it needs Sage
does not imply that "it's not a proper Python package".
--
You received
On 2016-04-15 21:31, Dima Pasechnik wrote:
not a proper Python package.
Why not? You haven't answered this question.
--
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
On 2016-04-15 19:11, Dima Pasechnik wrote:
I can try to make it into a proper Python package, instead of going
forward with #14840.
Why do you think that #14840 does not "make it a proper Python package"???
--
You received this message because you are subscribed to the Google Groups
On 2016-04-15 14:34, Erik Bray wrote:
It is a problem to have unmaintained and maybe working but poorly
tested and poorly integrated code that nobody knows how to maintain
anymore and that doesn't meet the coding and interface standards of
the rest of the package.
There is a huge amount of
On 2016-04-15 14:34, Erik Bray wrote:
I'd certainly be interested in having that discussion with anyone else
interested. I don't know most of the Sage package well enough though
to know where to begin.
Obviously, I'm also interested in that discussion.
--
You received this message because you
On 2016-04-15 14:12, Erik Bray wrote:
I say focus on fixing the real problems, not the symptoms.
I don't care. I want *any* fix (a real fix or a symptom-fix) and the
status-quo is not a fix.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
On 2016-04-15 16:15, William Stein wrote:
But +1 for having people who care have the ability to push to the repo
on github and generally take over maintenance.
Any volunteers? If there is indeed somebody who is seriously willing to
manage SageNB, that would be a good solution. However, by
Hello all,
I propose to make SageNB no longer a separate package but to move it
back into the Sage git tree. For purposes of installation and use of
SageNB, it will still be a separate Python package, but the sources will
be in $SAGE_ROOT/src/sagenb instead of a separate git repo. The changes
On 2016-04-14 21:32, William Stein wrote:
So I wonder if you think
that, say, elliptic curves should be a separate package too?
I'm not lowering the fact/opinion ratio further...
I would at least help to understand what exactly it is that you are
proposing. You keep using the words "normal
On 2016-04-14 20:35, William Stein wrote:
However I'm only now starting to complain loudly and
repeatedly just because I'm seeing such a huge wasted opportunity.
Instead of complaining, why don't you put together a more concrete and
technical proposal of what you actually want? Because this
On 2016-04-14 17:38, Erik Bray wrote:
Sage already has the problem of large
chunks of code that are effectively unmaintained and create a
maintenance burden on anyone serious about maintaining sage. Their
interfaces whither, and become inconsistent with the rest of the
package. It's dead
On 2016-04-14 17:21, Nils Bruin wrote:
On Thursday, April 14, 2016 at 1:52:37 AM UTC-7, Jeroen Demeyer wrote:
I like it exactly the way it is. If you explicitly ask for a polynomial
over a polynomial, this is the expected answer.
It is at odds with the behaviour for multivariate
On 2016-04-14 15:46, Erik Bray wrote:
If truly nobody can maintain an affiliated package
anymore it might die. And that's a problem since it might mean loss of
functionality for users
A logical conclusion from the above that it's a simply a bad idea to
split up Sage into separate packages
A really important point (which so far hasn't been addressed) is how to
deal with breakages of affiliated packages. I see two ways:
1. If I make a change to some core package, it is my responsibility to
ensure that no affiliated package breaks.
2. It is the responsibility of the affiliated
On 2016-04-14 08:58, Nils Bruin wrote:
Univariate polynomial rings seem to convert into each other by basically
just converting coefficient vectors. Unfortunately, this leads to
results that are at odds with sage's concept that conversions are done
by looking at variable names:
sage: S.=ZZ[]
On 2016-04-14 00:00, Simon King wrote:
If I understand correctly, such a decorator would not work in Cython code.
Why not? Cython supports decorators.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
Luca, I read your post but I don't really buy your argument that
"rewriting an entire module" is easier with a modular Sage. I think it's
equally hard in all cases, modular or not.
I think the reason that the coding people are moving forward quickly is
mainly because there is an enthousiastic
On 2016-04-05 20:44, William Stein wrote:
I am recommending to absolutely everybody I talk with about Sage
development that we switch from our current massive monolithic
centralized approach toward standard open source practices. Namely,
lots of smaller libraries, standard open source
On 2016-04-12 21:58, William Stein wrote:
If 3d plotting were in a separate python library we would enforce it
working in a new release in precisely the same way we do so now with
standard packages. Install and test it.
Which is very much a pain right now with SageNB. I find it a bad thing
On 2016-04-12 08:02, Jori Mäntysalo wrote:
Will this test be run with ./sage -t?
More generally, such questions can easily be answered by the running the
doctests with the --verbose option.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
On 2016-04-12 00:04, Nicolas M. Thiery wrote:
Dear Sage developers,
It's quite common that optional doctests come in batch, typically when
documenting a method that is only available when a certain feature or
package is available.
Let me add something here: often, not *every* test
On 2016-04-12 00:04, Nicolas M. Thiery wrote:
Dear Sage developers,
It's quite common that optional doctests come in batch, typically when
documenting a method that is only available when a certain feature or
package is available. Having to mark each and every test line with
`#
On 2016-04-12 08:02, Jori Mäntysalo wrote:
For example src/sage/modular/modform/ambient.py contains function
_compute_hecke_matrix_prime_power with docstring
TESTS:
sage: M = ModularForms(1, 12)
i.e. missing a colon: should be TESTS::.
Will this test be run with ./sage
On 2016-04-11 15:00, Erik Bray wrote:
Also some automated checks are put in place
which really help.
Can you elaborate on 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,
On 2016-04-11 14:29, Erik Bray wrote:
Don't advertise an interface as stable and then move it around
between X.Y releases without a deprecation process. Sage-the-library,
or much of it, is grown up enough (in terms of stability) that it
should definitely be doing this.
Of course we should be
On 2016-04-09 16:23, William Stein wrote:
Feedback from users makes it clear they need a stable foundation on
which to build their work
And you think having *many* packages with interdependencies which are
independently managed will actually make it more *stable*? Sounds like
the contrary to
On 2016-04-08 18:43, William Stein wrote:
the first thing I noticed in that from sage-6.10 to sage-7.x
import sage.rings.arith
completely BROKE.
That's totally exaggerated.
It didn't completely BREAK, it still works with a nice deprecation warning:
Importing is_prime from here is
On 2016-04-08 13:26, Luca De Feo wrote:
This is something that should only happen at major version bumps, if ever.
That's easily solved: the next stable release of Sage should be Sage 8,
then Sage 9 and so on...
We do have a 1-year deprecation policy, but of course it's not enforced
(and I
On 2016-04-08 00:58, William Stein wrote:
- Cython: relying on pxi/pxd files from the sage library.
Please push for https://github.com/cython/cython/pull/483 if you care
about this. Cython upstream doesn't seem to "get" that we need this patch.
--
You received this message because you
On 2016-03-31 08:13, Jori Mäntysalo wrote:
[reference] WARNING: Unable to fetch
/home/jm58660/sage/local/share/doc/sage/doctrees/en/reference/knots/environment.pickle
This is http://trac.sagemath.org/ticket/20321
--
You received this message because you are subscribed to the Google Groups
On 2016-03-30 14:49, Eugene E. wrote:
The default version of Python in Arch Linux is 3, but I was under the
impression that the Sage brings a python version of its own, no?
Maybe it doesn't use that to run relocate-once.py
--
You received this message because you are subscribed to the Google
Which version of Sage is that? If older than 7.1.rc1, you should upgrade
and try again.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
On 2016-03-23 09:29, Jori Mäntysalo wrote:
Intentionally?
I don't think so.
--
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 2016-03-21 14:08, Harald Schilly wrote:
Hi, I'm the one updating doc.sagemath.org and just found out that
building the documentation has changed in 7.1.
Indeed. Mostly, things have been moved around. The old src/doc was split
in three pieces:
- src/doc contains now only the documentation
On 2016-03-16 11:41, chris wuthrich wrote:
Is there a way that we could at least overwrite the docstring ?
You could always define a new "len" which just calls the old "len" but
with a custom docstring.
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
On 2016-03-18 18:01, Volker Braun wrote:
I did it once and nobody reviewed it
To be fair, I reviewed it negatively because of potential issues that
you didn't care about.
But it's certainly true that sage-location is mostly redundant.
--
You received this message because you are subscribed
On 2016-03-18 11:52, Volker Braun wrote:
file timestamps
Doesn't binary-pkg reset the timestamps to the original after modifications?
--
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
On 2016-03-18 04:10, David Roe wrote:
Here's a use case where the recent changes to relocatability are really
annoying. I'd like 6 sage installs in an SMC project so that different
groups at Sage Days 71 can work independently. So I tried building a
copy from source and then copying it five
On 2016-03-15 06:03, Kwankyu Lee wrote:
Yes, it is a feature. I agree that it might be a silly feature.
After having fully merged: http://trac.sagemath.org/ticket/20182,
how about changing the meaning of "all" in "make testall" and "sage -t
--optional=all" to
On 2016-03-14 08:00, Travis Scrimshaw wrote:
Thanks. I will then make sure I restrict myself to only using `sage -tp
--all`.
Or just run make (p)test(long).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
On 2016-03-13 23:52, Travis Scrimshaw wrote:
Hey all,
I was somewhat surprised when I ran `make ptestall` that it was
testing all optional packages, in contrast to `sage -tp --all`, which
only tests the installed optional packages. Is this a feature?
Yes, it is a feature. I agree that it
On 2016-03-11 12:03, Erik Bray wrote:
But really (especially these days) that should be a
minority case, and Sage should have just used the `patch` I have.
Since recently, I started adding some general mechanism to actually do
this. I.e. make the special case that we currently have for GCC
On 2016-03-10 20:58, François Bissey wrote:
conda is married to the x86(_64) architecture. No support for power for
you.
Are you saying that conda won't work at all on anything besides x86? Or
just that there are only official binaries for x86?
--
You received this message because you are
On 2016-03-10 18:19, William Stein wrote:
On Thu, Mar 10, 2016 at 9:10 AM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
After a quick look at conda, one major difference is that its focus is
really on binary packages. It might not be easy to support the Sage "build
from source"
On 2016-03-10 19:23, Michael Orlitzky wrote:
Its main issue is that all of the build
scripts are incredibly naive. For example, the source-based install
routing for PostgreSQL is,
https://github.com/conda/conda-recipes/blob/master/postgresql-9.3/build.sh
I consider the fact that build scripts
On 2016-03-10 18:19, William Stein wrote:
For example, do you prefer
Debian Linux or Gentoo Linux?
I absolutely hate Debian and their "we only package software from 5
years ago" philosophy.
I use Gentoo myself.
--
You received this message because you are subscribed to the Google Groups
On 2016-03-10 18:08, Erik Bray wrote:
One other note on this question-- Sage already leverages the existing
parallel build capability of make to handle this. I don't think
there's anything deep to it, though Jeroen can correct me if there are
details I'm missing.
It's not just a matter of
After a quick look at conda, one major difference is that its focus is
really on binary packages. It might not be easy to support the Sage
"build from source" model in conda.
Of course, we could build binary conda packages for Sage, but that's not
the same as using conda as package manager
On 2016-03-10 17:12, Erik Bray wrote:
It might almost be worth rebuilding Sage's packaging on top of the
conda platform, so that we can eliminate a lot of the overhead of
developing a packaging system alongside sage. But the devil is of
course in the details, and I could also understand any
On 2016-03-10 16:42, Ralf Stephan wrote:
sage: NaN is NaN
True
Of course, that is testing that NaN is the same Python object as NaN.
I really meant this:
sage: x = RDF(NaN)
sage: x == x
False
That this returns True for RR is a bug.
--
You received this message because you are subscribed to
On 2016-03-09 23:56, Thierry wrote:
Willing to
change the behaviour will be similar to requesting that 'NaN in RR' should
return False.
Not the topic of this thread, but I really think that "NaN in RR" should
return False. RR represents the real numbers and NaN is *not a number*.
Note that
On 2016-03-08 01:42, Kwankyu Lee wrote:
The "Special markup to influence (doc)tests" section of the developer's
guide claims that it is comprehensive. But I could not find any
explanation on the use of ellipsis "..."
The ellipsis is part of Python's doctest framework. In Python it's not
On 2016-03-07 09:36, Daniel Krenn wrote:
*** Warning: can't expand ~.
Does the path contain "~"?
--
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 2016-03-06 11:23, John Cremona wrote:
I seemed to remember that form 7.0 one must now
do "./configure" before "make"
That's not actually true. Running ./configure before make is optional.
But if you do run ./configure, you need to ensure that configure itself
is up-to-date. So you really
On 2016-03-04 11:21, Salvatore Stella wrote:
especially when you consider that
among the duplicated things there are some heavy package to compile like
gcc
GCC is only installed if needed. If Sage installs GCC, it must be that
your system GCC is either outdated of incomplete (missing Fortran?).
On 2016-03-02 20:02, Bruno Grenet wrote:
Dear all,
1. Should we use aliases when some object/concept has several names in
mathematics?
* Pro: Make the method easier to find
* Con: Too many method names makes searching via tab-completion
for instance more difficult
I
On 2016-03-01 14:25, William Stein wrote:
And there is a big warning message that many new users see.
For good reasons, since using function-call syntax will bite you sooner
or later. I think it's best to allow the syntax while keeping the warning.
--
You received this message because you
On 2015-10-04 23:00, Simon King wrote:
And why does it need to be *manually* decorated with $(INST)/? Shouldn't
it be enough to give a list of unmodified package names, optionally
modified by prescribing a range of acceptable version numbers?
Thus, why "$(INST)/MEATAXE $(INST)/DATABASE_GAP"
Concerning benchmarking, let me state that timing the tests is the easy
part. The hard part is doing something useful with the results.
For SageMath, the "doing something useful" part should be to make this
part of the continuous integration tests such that patches which
significantly slow
On 2016-02-29 12:21, Simon King wrote:
Interesting. I wonder how that can be debugged. I mean, it is file i/o.
That definitely should work.
See #20136 (I have no time to fix these issues, but that ticket should
contain enough information but somebody to fix it).
--
You received this message
On 2016-02-28 10:49, Simon King wrote:
I'd also like to ask people to test the package on a range of platforms.
The meataxe testsuite fails on powerpc64le:
Host system:
Linux sardonis 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:13 UTC
On 2016-02-28 10:49, Simon King wrote:
Recently, a "MeatAxe" package was added to Sage. Currently, it is
experimental
Really?
jdemeyer@sardonis:~/sage-check$ cat build/pkgs/meataxe/type
optional
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
On 2016-02-28 10:49, Simon King wrote:
Hi!
Recently, a "MeatAxe" package was added to Sage. Currently, it is
experimental --- based on my mistaken assumption that a new package
should first be experimental before it can be made optional.
The only difference between optional and experimental
On 2016-02-27 15:35, Dima Pasechnik wrote:
version 2.6 has just been released
Very good, this obsoletes my previous complaints. Can you first make a
ticket to update nauty (still optional) to this new version? Otherwise
there is not much point in voting.
--
You received this message
On 2016-02-26 18:39, Martin Vahi wrote:
WHY THE HELL IS SO MUCH MONEY AND TIME SPENT ON DOING IT IN STEAD OF
AUTOMATING IT AWAY!
I think you are misunderstanding what kind of boring work we are talking
about. For example, porting Sage to Python 3 is certainly boring but
cannot be fully
On 2016-02-24 15:33, Clemens Heuberger wrote:
Some subquestions coming to my mind:
* Shall tests related to publications be moved to another directory
(sage/tests/publications)?
Fine.
* What files are welcome there?
Anything which satisfies the rules on doctests (in particular, tests
should
On 2016-02-23 19:36, kcrisman wrote:
To wit, I still have a sqlalchemy tar in upstream/
That's the "problem"... don't put stuff in upstream if you don't want it
handled by sage-fix-pkg-checksums.
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
On 2016-02-23 15:50, Clemens Heuberger wrote:
It is also impossible to compile Sage 6.5 nowadays
I assume this was a build from git? That's indeed not supported. A real
build-from-source-tarball should still work.
Bottom line: I cannot reproduce 11 month old results anymore.
Personally,
On 2016-02-22 23:18, Volker Braun wrote:
I think you just ran out of RAM
Most likely. Note the signal is "Killed", not "Segmentation Fault". So
it's probably the out-of-memory killer which killed your gcc.
--
You received this message because you are subscribed to the Google Groups
On 2016-02-21 10:55, Martin Vahi wrote:
|gcc -fPIC
-L/home/ts2/Projektid/progremise_infrastruktuur/matemaatikamootorid/Sage/juur_liivakast/2016_02_xx_Sage_7_0/bonnet/tmp_/build_dir/sage-7.0/local/lib
-Wl,-rpath,/home/ts2/Projektid/progremise_infrastruktuur/matemaatikamootorid/Sage/juur_liivakast
On 2016-02-15 16:28, Travis Scrimshaw wrote:
It did seem to go a lot faster than I recall too... My guess is Jeroen
from http://trac.sagemath.org/ticket/19127.
That ticket wasn't meant to make the docbuilding faster. If it did,
that's very good. But I cannot really explain why.
--
You
On 2016-02-01 10:40, 'Martin R. Albrecht' via sage-devel wrote:
In particular, I am *very* interested in turning Sage’s interrupt
handling into something that can be easily installed from PyPI.
This is now ready. The upstream package is hosted at
https://github.com/sagemath/cysignals and the
I think writing better ticket titles could also help a lot. Maybe we
could actually ask reviewers of a ticket to also review the ticket title
to ensure it makes sense.
People should also change titles after better understanding the bug or
writing a fix. For example I changed
#20025:
801 - 900 of 3164 matches
Mail list logo
