The glpk test failures are being discussed at
https://trac.sagemath.org/ticket/29493.
On Friday, May 29, 2020 at 1:19:51 PM UTC-7, Andy Howell wrote:
>
> I originally sent this to sage-release when 9.1 was released. I see the
> same test failures under 9.2.beta0. I didn't see a way to make
The particular ticket in question deals with matplotlib, which has Python
as a dependency, so I think we can safely build with "Sage's Python 3",
which should be at least 3.6. If we can accommodate older version of Python
for the rest of the Sage build — and I think we can, given the current
There is a link given to the log file in the first few lines of the
original post.
On Monday, May 18, 2020 at 8:57:35 PM UTC-7, Justin C. Walker wrote:
>
> Please include the full log for openblas.
>
> Thanks!
>
> > On May 18, 2020, at 17:05 , Valentin Buciumas > wrote:
> >
> > Hello,
> >
On Friday, May 8, 2020 at 2:17:25 PM UTC-7, Michael Orlitzky wrote:
>
> There are some duplicates in there (I've wasted enough time on it), but
> it matches things that a regex never will. That function is implemented
> by the following code, which belongs in a third-party library and not
>
On Friday, May 8, 2020 at 9:51:34 AM UTC-7, Michael Orlitzky wrote:
>
> On 5/8/20 12:11 PM, John H Palmieri wrote:
> >
> > They accomplish different things: one searches the global name space and
> > the other searches the source code.
> >
> > Examp
On Friday, May 8, 2020 at 3:08:21 AM UTC-7, Dima Pasechnik wrote:
>
> On Fri, May 8, 2020 at 10:37 AM Markus Wageringel
> > wrote:
> >
> > Am Freitag, 8. Mai 2020 09:03:08 UTC+2 schrieb Sebastian Oehms:
> >>
> >> But if we talk about users who are not interested in code and strings,
>
On Thursday, May 7, 2020 at 9:58:55 AM UTC-7, John H Palmieri wrote:
>
>
>
> On Thursday, May 7, 2020 at 4:40:52 AM UTC-7, Michael Orlitzky wrote:
>>
>> On 5/6/20 11:28 PM, John H Palmieri wrote:
>> >
>> > And to clarify, this is what you expec
On Thursday, May 7, 2020 at 4:40:52 AM UTC-7, Michael Orlitzky wrote:
>
> On 5/6/20 11:28 PM, John H Palmieri wrote:
> >
> > And to clarify, this is what you expect users to use instead of
> > search_src? ;)
> >
>
And to clarify, neither you no
On Sunday, May 3, 2020 at 4:48:49 PM UTC-7, Michael Orlitzky wrote:
>
> On 5/2/20 1:55 PM, John H Palmieri wrote:
> >
> > OMG, why does "sage -grep" use the "find" command?
> >
>
> Others have pointed out that "-r" isn't standar
Silly question, but are you sure you are starting up Sage 9.0 when you do
all of this ("sage --notebook" or "sage --sh")? If you give an explicit
path to the Sage 9.0 version, does that help? Do you have any Sage-related
environment variables which could be interfering with things?
On
On Saturday, May 2, 2020 at 11:37:57 AM UTC-7, Sébastien Labbé wrote:
>
>
>
> On Saturday, May 2, 2020 at 7:55:25 PM UTC+2, John H Palmieri wrote:
>>
>>
>>
>> On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote:
>>>
>>>
&
On Saturday, May 2, 2020 at 9:59:18 AM UTC-7, Sébastien Labbé wrote:
>
>
> I feel the same way about functions like search_src() that badly
>> reimplement grep (even if they still work).
>>
>
> I am fine with getting rid of the log_* functions, but I definitively want
> search_src(),
Did you mean 9.2? It's too late to add deprecations to 9.1, in my opinion.
On Friday, May 1, 2020 at 2:19:32 PM UTC-7, Matthias Koeppe wrote:
>
> These modules have a very limited amount of code, seem to have seen no
> major development for about 10 years, and are (with minor exceptions)
>
There is a tradeoff. If I want to search the Sage source code, running
"search_src(...)" in Sage is easy, and it's in our documentation, so people
might find it. Running '!grep -R -n ... "$SAGE_ROOT"/src/sage' is not quite
as easy; if you want the line numbers, you need -n, and it also requires
On Thursday, April 30, 2020 at 11:15:31 AM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Thu, 30 Apr 2020, 19:10 John H Palmieri, > wrote:
>
>>
>>
>> On Thursday, April 30, 2020 at 9:20:00 AM UTC-7, Michael Orlitzky wrote:
>>>
>>> On 4/30/20 11
On Thursday, April 30, 2020 at 9:20:00 AM UTC-7, Michael Orlitzky wrote:
>
> On 4/30/20 11:16 AM, Dima Pasechnik wrote:
> >
> > I think we should just remove this completely, as ipython nowadays has
> > %history magic which certainly can do the same as log_text()
> >
>
> +1
>
> I feel the
sage: var('q')
q
sage: (q+q^(-1))^(1/2)
sqrt(q + 1/q)
(By the way, I'm not sure I would call using a fraction field "naive".)
On Sunday, April 26, 2020 at 9:01:35 AM UTC-7, Jin Guu wrote:
>
> I am writing a calculator for various 'q' quantities, and often find that
> I need to manipulate
On Tuesday, April 21, 2020 at 7:59:18 PM UTC-7, John H Palmieri wrote:
>
>
>
> On Tuesday, April 21, 2020 at 5:26:00 PM UTC-7, Dima Pasechnik wrote:
>>
>> On Wed, Apr 22, 2020 at 2:56 AM k2wagle wrote:
>> >
>> > Tried this just now, ge
On Tuesday, April 21, 2020 at 5:26:00 PM UTC-7, Dima Pasechnik wrote:
>
> On Wed, Apr 22, 2020 at 2:56 AM k2wagle >
> wrote:
> >
> > Tried this just now, getting the same error. Open a ticket please.
>
> This error is already in Sage 9.0 - and this is an example from the
> manual!
>
> It's
On Monday, April 20, 2020 at 1:01:24 PM UTC-7, Emmanuel Zuñiga wrote:
>
> Hello, i would like to know how to modify the index of a matrix in
> sagemath. As an example, we all know that every object begins in 0, m[0]
> and that kind of things.
> Now, i need to modify this. to add one to the
Several of us are in favor of requiring that, in order to build Sage,
people should have to run "./configure" before running "make". I would
further propose that "make" should not itself then run "configure".
Some advantages:
- This is the same procedure used with many other software packages.
Maybe SageCell doesn't have the optional package "tides" installed. This is
the same error I see on my own computer without "tides".
On Thursday, April 16, 2020 at 9:26:21 AM UTC-7, slelievre wrote:
>
> Here is the error after executing the original poster's code in SageCell.
>
>
I would suggest two things:
$ brew install pkg-config
and then before building Sage, while in SAGE_ROOT:
$ source .homebrew-build-env
Then try ./configure to see what it says at the end about system packages.
On Tuesday, April 14, 2020 at 6:21:40 AM UTC-7, David Coudert wrote:
>
> I
On Wednesday, April 1, 2020 at 3:02:49 PM UTC-7, Matthias Köppe wrote:
>
> Another variation to try is to use " . .homebrew-build-env "
> before the build, which sets some environment variables so that homebrew's
> "keg-only packages" are found.
> Among other things, this affects libpng via
Did you look at the file "README.md"? It suggests building in parallel to
speed things up. Have you tried that?
On Thursday, April 9, 2020 at 12:35:58 PM UTC-7, hbetx9 wrote:
>
> I htink I know what I did, somehow I change the prefix to a directory that
> didn't exist. I'm recompiling to see
When I have had problems with libpng, it has helped to do "brew install
pkg-config". If you happened to start building Sage and then upgraded
Homebrew and/or Xcode in the middle of that, or if you've installed any new
Homebrew packages, you should probably start over with "make distclean"
On Wednesday, April 8, 2020 at 3:30:44 PM UTC-7, Matthias Koeppe wrote:
>
> On Wednesday, April 8, 2020 at 7:53:07 AM UTC-7, rana-aerea rossa wrote:
>>
>> I need someone to tell me where to propose three kinds of changes of
>> Sagemath.
>> (1) I guess Sagemath misses change log for some time.
On Wednesday, April 1, 2020 at 11:05:31 AM UTC-7, John H Palmieri wrote:
>
>
>
> On Tuesday, March 31, 2020 at 7:15:10 PM UTC-7, John H Palmieri wrote:
>>
>>
>>
>> On Tuesday, March 31, 2020 at 6:21:42 PM UTC-7, Matthias Köppe wrote:
>>>
>>>
On Tuesday, March 31, 2020 at 7:15:10 PM UTC-7, John H Palmieri wrote:
>
>
>
> On Tuesday, March 31, 2020 at 6:21:42 PM UTC-7, Matthias Köppe wrote:
>>
>> On Tuesday, March 31, 2020 at 8:02:48 PM UTC-4, John H Palmieri wrote:
>>>
>>> Here's the
On Tuesday, March 31, 2020 at 6:21:42 PM UTC-7, Matthias Köppe wrote:
>
> On Tuesday, March 31, 2020 at 8:02:48 PM UTC-4, John H Palmieri wrote:
>>
>> Here's the strange part: if I add the package libpng, then Sage doesn't
>> build. With these packages, it builds and p
When the build fails, there should be a message like:
The following package(s) may have failed to build...
* package: ecl
last build time: ...
log file:...
build directory: /build/directory/is/here/
Check the build directory listed at the end for the file config.log. It
r SageMath should install SPKG gmp... ##
> ## ##
> configure:10415: will use system package and not install SPKG gmp
>
>
>
> This seems to come from AX_ABSOLUTE_HEADER
>
>
>
> On Monday, March 30, 2020 at 12:18:41 PM
ote:
>
> I vaguely recall seeing similar errors on Homebrew, they were due to
> stale Homebrew. Could you try updating it?
>
> On Tue, Mar 31, 2020 at 12:23 AM John H Palmieri > wrote:
> >
> > I should also mention that I have built every beta from scratch
On OS X with a homebrew installation of Python 3.7.7 I get some failures,
mostly to do with pari, including messages like this:
PARI/GP ERROR:
*** bug in PARI/GP (Segmentation Fault), please report.
and this:
fatal error: 'gmp.h' file not found
#include "gmp.h"
^~~
On Sunday, March 29, 2020 at 12:24:38 AM UTC-7, rana-aere wrote:
>
> Thank you for clear instructions.
> I used the codes to compare how doctoring of the method _macaulay2_init_
> is displayed.
>
> sage-8.9 (command line and jupyter)
>
> ```
> Init docstring: x.__init__(...) initializes x; see
On Saturday, March 28, 2020 at 7:07:53 AM UTC-7, rana-aere wrote:
>
>
>
> I am compiling binary-pkg and encountered a deprecation warning.
> The warning appeared when I invoked sage from command line.
> (Technically, it was after messages of patching.)
>
> The warning reads
>
> ```
>
Please use "sage -i topcom" (lowercase). "topcom" is the newer version of
"TOPCOM", which is the old, outdated, package. That may not help, but it's
worth a try.
On Wednesday, March 25, 2020 at 9:50:01 AM UTC-7, Tyler L. Kelly wrote:
>
> Dear all,
>
> I was sent here in trying to install
What about
my_method = Mother.my_method
my_method.__doc__ = "new docstring"
Does that do what you want?
On Wednesday, March 18, 2020 at 9:22:31 PM UTC-7, David Roe wrote:
>
>
>
> On Wed, Mar 18, 2020 at 10:58 PM Michael Jung > wrote:
>
>> Damn it. Then I another question: Would it cause a
twisted, too, I think.
On Wednesday, March 11, 2020 at 4:25:21 PM UTC-7, François Bissey wrote:
>
> The flask packages definitely should be made optional.
>
> > On 12/03/2020, at 12:02 PM, Antonio Rojas > wrote:
> >
> > sagenb was made optional, but its dependencies (such as flask-*
>
Ticket #24824 upgraded glpk to version 4.65, patching it so it doesn't
print a warning message "Long-step dual simplex will be used". What should
we do about system-wide installations of glpk? I recently installed it
using homebrew, and the result was that Sage failed lots of tests, all
On Thursday, January 30, 2020 at 12:23:34 AM UTC-8, Markus Wageringel wrote:
>
>
>
> Also, the directory `build/pkgs/sage_conf/src/` contains untracked
> autogenerated files. This makes `configure` fail if one tries to checkout a
> previous beta.
>
>
I see this too. I don't understand why it
On Wednesday, January 29, 2020 at 3:04:12 PM UTC-8, Vipul Gupta wrote:
>
> Hello,
> I am using Ubuntu 18.04.3 LTS with sage version 9.1 beta 2
> After using below command
> git clone git://github.com/sagemath/sage.git
> cd sage
> git checkout develop
> make
>
Okay up to here. Before doing the
On Monday, January 27, 2020 at 9:59:04 AM UTC-8, Matthias Koeppe wrote:
>
> On Monday, January 27, 2020 at 9:34:41 AM UTC-5, Marc Mezzarobba wrote:
>>
>>
>> I just noticed that Sage unconditionally changes the permissions of the
>> DOT_SAGE directory to rwx--- even after the user manually
/libintmath.py",
> line 161 ? Just interesting :)
>
> вторник, 14 января 2020 г., 21:20:05 UTC+3 пользователь John H Palmieri
> написал:
>>
>> Sorry, I meant Sage *9.1.beta0*.
>>
>> On Tuesday, January 14, 2020 at 10:18:41 AM UTC-8, John H Palmieri wro
Sorry, I meant Sage *9.1.beta0*.
On Tuesday, January 14, 2020 at 10:18:41 AM UTC-8, John H Palmieri wrote:
>
> Just to confirm: everything works with Sage 9.0.beta1, built with Python
> 2. Fails with Sage built with Python 3.
>
>
> On Tuesday, January 14, 2020 at 5:55:51 A
Just to confirm: everything works with Sage 9.0.beta1, built with Python 2.
Fails with Sage built with Python 3.
On Tuesday, January 14, 2020 at 5:55:51 AM UTC-8, Александр Ватузов wrote:
>
> https://trac.sagemath.org/ticket/29009#ticket
>
> вторник, 14 января 2020 г., 16:36:27 UTC+3
It is safe to build without setting SAGE_CHECK. Also, some packages are
known to fail their test suites — see
https://groups.google.com/d/msg/sage-devel/abysgIIVGZI/fF7efL9RAwAJ, for
example.
On Saturday, January 11, 2020 at 2:40:04 AM UTC-8, Szabolcs Horvát wrote:
>
> Hello everyone,
>
> I
Dave Witte Morris pointed out the following bug (now trac 28970):
M = random_matrix(GF(4), 70, 70)
def test_matrix(iterations=50):for k in range(iterations):
S,U,V = M.smith_form()
print(k)
if not S == U * M * V:
raise ValueError
On OS X, this will
Can someone with trac admin access and know-how add a 9.2 milestone, so
people can develop for 9.2 if they want to focus on dropping Python 2
support?
Meanwhile, 9.1 should include a deprecation warning when people use
'./configure --with-python=2'.
On Sunday, January 5, 2020 at 1:06:21 PM
On Friday, January 3, 2020 at 11:54:04 AM UTC-8, finotti wrote:
>
> I'm trying to build version 9.0 from source under Linux (Debian
> Unstable/Sid). The machine has Intel Core i7-8700 CPU and 48GB of RAM.
>
> Below is the end of the compilation:
>
> [snip]
>
> [twisted-16.3.0.p0] Finished
On Monday, December 30, 2019 at 9:57:25 PM UTC-8, Isuru Fernando wrote:
>
> I'm trying to build sage 9.0.rc1 for conda. For conda what I do is I run,
> 1. Run configure
> 2. cp src/bin/* to /bin
> 3. cp src/ext/* to /share/sage/ext
> 4. run `python setup.py install` in src
>
> This has worked
On Monday, December 2, 2019 at 9:15:49 AM UTC-8, John H Palmieri wrote:
>
>
>
> On Monday, December 2, 2019 at 3:12:12 AM UTC-8, E. Madison Bray wrote:
>>
>> On Mon, Dec 2, 2019 at 6:50 AM John H Palmieri
>> wrote:
>> >
>> > Broken with a Pytho
On Monday, December 2, 2019 at 3:12:12 AM UTC-8, E. Madison Bray wrote:
>
> On Mon, Dec 2, 2019 at 6:50 AM John H Palmieri > wrote:
> >
> > Broken with a Python 2 build. Do we care?
> >
> > In particular, SageNB is not built with Python 2, but the docteste
Broken with a Python 2 build. Do we care?
In particular, SageNB is not built with Python 2, but the doctester thinks
it should be:
./sage -t -p --all --long --logfile=logs/ptestlong.log
Running doctests with ID 2019-12-01-19-23-00-d57c8cb5.
Git branch: develop
Using
It's okay with Python 3, but I'm getting a failure on OS X when built with
Python 2:
sage -t --long --warn-long 68.2 src/sage/libs/pynac/pynac.pyx
**
File "src/sage/libs/pynac/pynac.pyx", line 295, in
On Saturday, November 23, 2019 at 12:38:35 PM UTC-8, vdelecroix wrote:
>
> Le 23/11/2019 à 11:34, John H Palmieri a écrit :
> > By the way, Integer(1r) is also faster with Python 2 than with Python 3.
>
> By how much? Does it explain the 25% slowdown of the original post?
It's not actually Sage 8.9 vs. 9.0, it is? Rather it's Python 2 vs. Python
3. On my computer, I see the same timings with Python 3 builds of 8.9 and
9.0.beta6, but things look faster with Python 2 builds of 8.9 and 9.0.beta6.
By the way, Integer(1r) is also faster with Python 2 than with Python
I have what looks like a very similar setup: `pkg-config --libs libpng`
returns the same thing, I have symlinks for those two files, but matplotlib
finds libpng just fine. Did you do 'make distclean' after reinstalling
libpng and pkg-config? What does "brew list" say?
On Thursday, November
The problems with incremental building and Python 2 vs. Python 3 are being
tracked at https://trac.sagemath.org/ticket/28742
On Tuesday, November 19, 2019 at 6:57:36 AM UTC-8, Dima Pasechnik wrote:
>
> On Tue, Nov 19, 2019 at 1:59 PM E. Madison Bray > wrote:
> >
> > On Tue, Nov 19, 2019 at
Sage is not using very sophisticated methods for computing homology. If
anyone wants to implement something better, they are certainly welcome to.
I may try to look at the paper, but it may take me a while to get to it.
-- John
On Wednesday, November 13, 2019 at 4:48:18 PM UTC-8, Salvatore
I just set SAGE_CHECK=yes and tried to build Sage on several platforms: OS
X and a virtual machine running Ubuntu. Summary:
Failed on both:
- gap: looks like some sort of string-vs-bytes problem
(https://trac.sagemath.org/ticket/28728)
- cvxopt: fails with a Python 3 build, hangs (at least on
I created https://trac.sagemath.org/ticket/28721 to add documentation for
these to the developer's guide. Needs review.
John
On Thursday, November 7, 2019 at 8:27:32 AM UTC-8, John H Palmieri wrote:
>
> These shell functions are defined and documented in
> SAGE_ROOT/build/bin/
These shell functions are defined and documented in
SAGE_ROOT/build/bin/sage-dist-helpers. In my opinion they should also be
documented in the developer's guide, but they don't seem to be.
On Thursday, November 7, 2019 at 6:35:05 AM UTC-8, Simon King wrote:
>
> Hi Dima,
>
> On 2019-11-06,
Simon, you should look at the json file for p_group_cohomology to see if it
contains all of the installed files, or if indeed some are not listed. If
everything is there, there is no need to split it into two packages, unless
I'm missing something.
On Wednesday, November 6, 2019 at 9:33:04
If you want to build Sage for use with Python 3, you should do
$ make distclean
$ ./configure --with-python=3
$ make
Where does this fail for you?
On Monday, November 4, 2019 at 8:21:04 AM UTC-8, Александр Ватузов wrote:
>
> No, I am building sage only for using it with python3. So I need to
lled xcode from the
> appsrtore I am using the latest versions av I am using:
>
> ProductName:Mac OS X
> ProductVersion:10.15.1
> BuildVersion:19B88
> Xcode 11.2
> Build version 11B52
>
> Andrew
>
>
>
>
> On Saturday, 2 November 2019 05:45:
Since trac #28426 (merged pretty recently), when building with Python 3, we
do not build Python 2. Before that, we always built both.
On Sunday, November 3, 2019 at 12:57:02 PM UTC-8, Dima Pasechnik wrote:
>
> I am surprised we still even build python2 by default. Isn't it an
> optional
/28687: change scons from optional to
experimental. I thought briefly of trying to upgrade it instead, but I
don't really care about the package, so someone else who is actually
interested will have to do that.
John
On Friday, November 1, 2019 at 1:27:34 PM UTC-7, John H Palmieri wrote
Note that "sage --sws2rst ..." relies on sagenb, and therefore will only
work with Sage built with Python 2.
In any case, https://trac.sagemath.org/ticket/28685 upgrades to
beautifulsoup4, which is compatible with Python 3.
On Friday, November 1, 2019 at 3:43:32 AM UTC-7, kcrisman wrote:
>
>
I just upgraded a different machine to Catalina. This one didn't have Xcode
or homebrew installed beforehand, so I installed Xcode, its command-line
tools, and homebrew's gcc. Then I built Sage and it worked. I have now
installed a bunch of other homebrew packages relevant to Sage, and the
If you have the time, could you try uninstalling Xcode and then
reinstalling it? You might also try uninstalling and reinstalling
homebrew's gcc and any other homebrew components that are relevant to Sage.
There may be some remnants of previously installed software that is somehow
interfering.
I tried building several version of gfortran by hand on 10.15, but I
couldn't succeed, whereas I could with 10.14. I didn't try just upgrading
Sage's gfortran/gcc package to 9.x.
On Wednesday, October 30, 2019 at 3:21:58 PM UTC-7, François Bissey wrote:
>
> I suspect gcc/gfortran shipped with
I also had problems with Sage's gfortran package with OS X Catalina. I
instead installed homebrew (https://brew.sh), and used homebrew to install
their gcc package. This should install gfortran, which Sage will find as
part of its configure process, thereby bypassing Sage's gfortran package.
On Tuesday, October 29, 2019 at 4:45:53 AM UTC-7, Andrew wrote:
>
> Thanks Dima
>
> On Tuesday, 29 October 2019 17:51:02 UTC+11, Dima Pasechnik wrote:
>>
>> Did you run
>>
>> xcode-select --install
>>
>> after Xcode upgrade?
>>
>
> Yes, the command line tools are correctly installed but, as
Oops, I spoke too soon. Two more files had failures:
- sage -t --long src/sage/databases/stein_watkins.py # 20 doctests failed
- sage -t --long src/sage/interfaces/frobby.py # 12 doctests failed
On Monday, October 28, 2019 at 3:02:23 PM UTC-7, John H Palmieri wrote:
>
> With a Python 3
With a Python 3 build of Sage on OS X 10.14.6, I decided to install as many
optional and experimental packages as I could. The results:
*Optional:*
- the following packages failed to build, and the reason wasn't completely
obvious:
awali
buckygen
cbc
gambit
gdb
mpi4py
- the following
+1
On Saturday, October 26, 2019 at 5:27:51 PM UTC-7, vdelecroix wrote:
>
>
> https://trac.sagemath.org/ticket/28660
>
>
> Le 26/10/2019 à 17:20, François Bissey a écrit :
> > +1
> >
> >> On 27/10/2019, at 12:58 PM, Vincent Delecroix <20100.d...@gmail.com
> > wrote:
> >>
> >> +1
> >>
>
On Friday, October 25, 2019 at 2:59:36 AM UTC-7, Dima Pasechnik wrote:
>
> in the Sage 9.0.beta2 I get
>
> [ipython-5.8.0] Successfully installed ipython-5.8.0
> [ipython-5.8.0] Cleaning up...
> [ipython-5.8.0] Removed build tracker '/tmp/pip-req-tracker-h6h22jg5'
> [ipython-5.8.0]
>
On Thursday, October 24, 2019 at 10:57:09 AM UTC-7, Dima Pasechnik wrote:
>
> On Thu, Oct 24, 2019 at 6:48 PM Nils Bruin >
> wrote:
> >
> > On Thursday, October 24, 2019 at 10:29:48 AM UTC-7, Nils Bruin wrote:
> >>
> >>
> >> I guess via ctypes it would be possible too.
> >
> >
> >
On Wednesday, October 23, 2019 at 9:49:56 PM UTC-7, Nils Bruin wrote:
>
> On Wednesday, October 23, 2019 at 2:47:54 PM UTC-7, John H Palmieri wrote:
>>
>>
>>
>> On Wednesday, October 23, 2019 at 1:41:35 PM UTC-7, Nils Bruin wrote:
>>>
>>> On Wedne
On Wednesday, October 23, 2019 at 1:41:35 PM UTC-7, Nils Bruin wrote:
>
> On Wednesday, October 23, 2019 at 1:26:46 PM UTC-7, John Cremona wrote:
>>
>>
>> That all looks very complicated. Before I fixed the eclib source code
>> the previous method did work, namely to flush stdout and stderr
side-library
>
> is it what would work for us?
>
> On Wed, 23 Oct 2019, 20:06 John H Palmieri, > wrote:
>
>>
>>
>> On Monday, September 9, 2019 at 2:06:21 PM UTC-7, Jeroen Demeyer wrote:
>>>
>>> On Mon, Sep 9, 2019 at 7:51 PM John H Palmieri
>&g
On Monday, September 9, 2019 at 2:06:21 PM UTC-7, Jeroen Demeyer wrote:
>
> 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
> >
>
ey have the deprecated behavior in
> a function they've written.
> David
>
> On Sat, Oct 19, 2019 at 2:56 PM John H Palmieri > wrote:
>
>> Here is a doctest from sage/rings/integer.pyx:
>>
>> sage: Integer('012')
>> doctest:...: DeprecationWa
Here is a doctest from sage/rings/integer.pyx:
sage: Integer('012')
doctest:...: DeprecationWarning: use 0o as octal prefix instead of 0
If you do not want this number to be interpreted as octal, remove
the leading zeros.
See http://trac.sagemath.org/17413 for
On Friday, October 18, 2019 at 10:25:07 AM UTC-7, Dima Pasechnik wrote:
>
> Hi John,
>
> On Fri, Oct 18, 2019 at 5:08 PM John H Palmieri > wrote:
> >
> > I have compiled it without any problems. You should not be using gcc
> from homebrew, but rather the ver
I have compiled it without any problems. You should not be using gcc from
homebrew, but rather the version of gcc installed by Xcode or its
command-line tools. That might help. (You should install the homebrew gcc
package to get gfortran, but at least for me, installing homebrew's gcc
With a Python 3 build of Sage, there are three files which exhibit failures
only (or primarily?) when running the Sage patchbot. This is being tracked
at https://trac.sagemath.org/ticket/28622. Can anyone help figure out the
problem and how to fix it? To see the problem, cd to SAGE_ROOT, run
A few days ago, after the Catalina release, I used Homebrew to build gcc,
and it worked. Well, it built from source, which took a while, but it built
a version of gfortran which worked well enough to build Sage. (As far as I
know, it's completely functional, but the only reason I install
On Wednesday, October 9, 2019 at 4:51:48 AM UTC-7, David Joyner wrote:
>
>
>
> On Wed, Oct 9, 2019 at 7:42 AM Dima Pasechnik > wrote:
>
>>
>>
>> On Wed, Oct 9, 2019 at 6:34 AM David Joyner > > wrote:
>>
>>>
>>>
>>> On Wed, Oct 9, 2019 at 7:14 AM Dima Pasechnik >> > wrote:
>>>
Hi,
On OS X, Sage by default should use the system's "gcc" (which is actually
clang), so it's okay to not have a symlink connecting gcc-9 to gcc in
/usr/local/bin. What you really need is /usr/local/bin/gfortan, and
homebrew should provide that.
John
On Tuesday, October 8, 2019 at 3:56:24 PM
I have been testing new versions of Simon King's p-group cohomology
package. The current version doesn't work with Python 3, and he has been
working (#28414) to fix this. My workflow:
1. check out his git branch
2. run ./sage -f -c p_group_cohomology
3. report any issues
4.
Could you also trying using Homebrew to install gfortran?
On Wednesday, September 25, 2019 at 12:09:55 PM UTC-7, Ben Salisbury wrote:
>
> Ok, I tried the Homebrew route, and still the build failed. First, the
> computer successfully executed the following:
>
> brew install
On Tuesday, September 24, 2019 at 10:12:17 AM UTC-7, Ben Salisbury wrote:
>
> Hi,
>
> I'm attempting to build Sage from the develop branch on a new office
> computer running OS X 10.14.6. I've installed Xcode and Command Line Tools
> (or at least I thought I had), and I'm getting a build
+1 for threejs
I tried to compare the two: in a single Jupyter notebook, I plotted the
same function with both viewers. threejs produced the plot faster, and it
was snappier when rotating, zooming, etc. (This is with both Firefox and
Safari on OS X.) Same from the command-line: the threejs
On Thursday, September 12, 2019 at 12:30:34 PM UTC-7, Dima Pasechnik wrote:
>
> On Thu, Sep 12, 2019 at 5:55 PM John Cremona > wrote:
> >
> > On ubuntu, upgrade from previous beta, python3 configured: make
> ptestlong succeeds except for
> >
> > sage -t --long --warn-long 81.2
On Friday, September 6, 2019 at 3:13:07 AM UTC-7, E. Madison Bray wrote:
>
> On Fri, Sep 6, 2019 at 11:36 AM E. Madison Bray > wrote:
> >
> > Consistently getting a test failure on Cygwin related to some oddity in
> GAP:
> >
> > sage -t --long --warn-long 109.3 src/sage/tests/cmdline.py
>
On Wednesday, September 11, 2019 at 4:36:46 PM UTC-7, Volker Braun wrote:
>
> As always, you can get the latest beta version from the "develop" git
> branch. Alternatively, the self-contained source tarball is at
> http://www.sagemath.org/download-latest.html
>
OS X + Python 3: All tests
On Monday, September 9, 2019 at 2:06:21 PM UTC-7, Jeroen Demeyer wrote:
>
> 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
> >
>
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)
- rings/polynomial/polynomial_rational_flint.pyx (#28334)
and both occur for the same reason: warning messages printed by C or C++
libraries are
401 - 500 of 2203 matches
Mail list logo
