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
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
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
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.
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 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.
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
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 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
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 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 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
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
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:
/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 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 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 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
On Thursday, August 29, 2019 at 7:15:51 AM UTC-7, Frédéric Chapoton wrote:
>
> Hello
>
> Somebody (else) should make sure that every single remaining piece of
> python2 is removed from a python3 sage. In particular, we should not build
> python2 at all.
>
See
On Friday, August 2, 2019 at 1:36:36 PM UTC-7, Nils Bruin wrote:
>
> On Friday, August 2, 2019 at 11:39:47 AM UTC-7, Timo Kaufmann wrote:
>>
>> Hi!
>>
>> As part of my packaging workflow, I find myself pasting error messages
>> into the trac search pretty frequently to discover if something is
See
https://ask.sagemath.org/question/47214/help-doesnt-show-function-call/.
Some of the time when you evaluate
blah?
the signature is not present. Is this a bug or is it intended?
I like this behavior:
sage: A = SteenrodAlgebra()
sage: A.antipode?
Signature: B.antipode(self, *args)
I am writing to follow up on this. The University of Washington has now
stopped accepting donations to the Sage Foundation fund. People looking for
ways to donate in support of Sage will need to find other avenues for that,
and I encourage people to create those avenues if they know how. Of
On Tuesday, June 18, 2019 at 10:12:06 AM UTC-7, Parth Dubal wrote:
>
> I tried to download manually and put it into upstream directory but it is
> already present and the installation didn't even reach to that step. I
> don't understand, if it was already downloaded earlier then why the
>
On Tuesday, June 18, 2019 at 8:47:31 AM UTC-7, Parth Dubal wrote:
>
> Hi,
>
> I tried three times to install sage as described in github on my virtual
> machine (Ubuntu 19) but the installation gets stuck for hours at the point
> of downloading zeromq-4.2.5.tar.gz. I am running ubuntu on
On Saturday, June 8, 2019 at 8:56:09 AM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Sat, 8 Jun 2019 16:50 John H Palmieri, > wrote:
>
>>
>>
>> On Saturday, June 8, 2019 at 1:25:11 AM UTC-7, vdelecroix wrote:
>>>
>>> Le 07/06/2019 à 16:44,
On Saturday, June 8, 2019 at 1:25:11 AM UTC-7, vdelecroix wrote:
>
> Le 07/06/2019 à 16:44, Jeroen Demeyer a écrit :
> > 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
On Friday, June 7, 2019 at 7:44:03 AM UTC-7, Jeroen Demeyer wrote:
>
> 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
>
>
docutils-0.14
>
> I'll run make ptest-python3 as you suggest.
>
> Thanks again
>
> Brian
>
>
>
> On Thu, May 30, 2019 at 3:19 PM John H Palmieri > wrote:
>
>>
>>
>> On Thursday, May 30, 2019 at 2:15:12 PM UTC-7, Brian Ball wrote:
>>>
>&g
On Thursday, May 30, 2019 at 2:15:12 PM UTC-7, Brian Ball wrote:
>
> I built sage 8.7 with python 3.6.
>
What do you mean by "built"? Did you run "make"? If so, did it complete
without error? (I would find that surprising, since "make" should build the
documentation.)
What does the file
If I run
./sage -tp --file-iterations=2 src/sage/algebras/
then I get many doctest failures. Is this expected? Is something broken
when using the "--file-iterations" flag?
--
sage -t src/sage/algebras/free_algebra.py # 1
On Wednesday, May 29, 2019 at 5:52:26 PM UTC-7, Michael Orlitzky wrote:
>
> On 5/28/19 5:09 PM, Sébastien Labbé wrote:
> >
> > $ cd
> /home/slabbe/GitBox/sage/local/var/tmp/sage/build/pynormaliz-2.5/src
> > $ strace sh congiure
> > ...
> > 4000 lines in total including:
> > ...
> >
There is also the "warn-long" flag:
sage -t --warn-long 3.2 FILE
should tell you all tests in FILE that take more than 3.2 seconds.
On Thursday, May 23, 2019 at 4:05:04 PM UTC-7, Travis Scrimshaw wrote:
>
> sage -t --verbose (or -tp of course)
>
> Best,
> Travis
>
>
> On Friday, May 24,
Did you try "print(mat.str())"?
On Saturday, May 18, 2019 at 6:37:02 PM UTC-7, Kwankyu Lee wrote:
>
> Hi,
>
> If mat is a matrix of large size, it is displayed in a short form:
>
> sage: mat
> 22 x 32 dense matrix over Finite Field of size 2 (use the '.str()' method
> to see the entries)
>
>
>
On Friday, May 3, 2019 at 10:22:25 AM UTC-7, Salvatore Stella wrote:
>
> Hi All,
> has anyone tried installing CHomP recently? For me it fails applying
> patches.
> It is an old-style package and apparently it is very stale; does it
> provide
> any tangible speedup in
On Tuesday, April 23, 2019 at 12:18:13 AM UTC-7, Daniel Krenn wrote:
>
> On 23.04.19 01:37, John H Palmieri wrote:
> > I was running a patchbot successfully until some time last week. For
> > reasons I don't understand, I did "git pull" on the patchbot, and now it
I was running a patchbot successfully until some time last week. For
reasons I don't understand, I did "git pull" on the patchbot, and now it
won't run with Python 2, complaining
File "sage_patchbot/plugins.py", line 309
yield from names
^
SyntaxError: invalid syntax
Do I
What does
sage: C
Set partitions of {'a', 'c', 'b'}
reveal? Is it helpful, or can it be omitted? Maybe it's good enough to do
sage: C = SetPartitions(["a", "b", "c"])
sage: C.cardinality()
5
sage: sorted(C)
[{{'a'}, {'b'}, {'c'}},
{{'a'}, {'b', 'c'}},
{{'a', 'b'}, {'c'}},
{{'a', 'b', 'c'}},
On Tuesday, April 16, 2019 at 8:30:13 PM UTC-7, Nils Bruin wrote:
>
> On Tuesday, April 16, 2019 at 8:06:06 PM UTC-7, Brian Fitzpatrick wrote:
>>
>>
>> Is this a bug?
>>
>> Looks like it. The problem seems to be that "sparse matrices over SR"
> aren't special cased the way dense matrices are
Is the printed order important? If not, you can change the doctest to
something else that is actually testing something relevant, maybe like
sage: 'B' in frozenset()
True
or
sage: (define the frozenset S somehow)
sage: S == frozenset(['A', 'B', 'C'])
True
Or if
Can you provide details of how you created the polyhedron? As David said,
Q.vertices() should make a copy before returning the result, and I would
like to recreate this so I can fix it.
On Thursday, April 11, 2019 at 9:21:42 PM UTC-7, Narayanan Narayanan wrote:
>
> Thank you David. Using
What happens when you run this version of Sage and do
sage: PointConfiguration.set_engine('internal') # to make doctests
independent of TOPCOM
sage: p = PointConfiguration([[-1,-1],[1,1],[1,0],[0,1],[0,0]])
and then if that succeeds, plot p?
What if you omit the first line and just
I am confused about how Sage's doctests work with a deprecation warning,
for example as coming from the @experimental decorator. Here is a snippet
from the top of rings/padics/padic_lattice_element.py:
sage: R = ZpLC(2)
doctest:...: FutureWarning: This class/method/function is marked as
On Wednesday, April 3, 2019 at 4:20:43 PM UTC-7, Yagamy Light wrote:
>
>
>
> On Thursday, 4 April 2019 01:58:09 UTC+3, John H Palmieri wrote:
>>
>>
>>
>> On Wednesday, April 3, 2019 at 3:13:43 PM UTC-7, Yagamy Light wrote:
>>>
>>>
>
On Wednesday, April 3, 2019 at 3:13:43 PM UTC-7, Yagamy Light wrote:
>
>
>
> On Wednesday, 3 April 2019 22:42:15 UTC+3, Samuel Lelievre wrote:
>>
>>
>>
>> Le mercredi 3 avril 2019 17:43:51 UTC+2, Yagamy Light a écrit :
>>>
>>> # Steps to reproduce (in terms of terminal comands:
>>>
>>> $ cat
On Sunday, March 24, 2019 at 12:21:43 PM UTC-7, Chaman Agrawal wrote:
>
> I was trying to contribute through a ticket related to documentation but I
> am not sure how docstrings are generating HTML and have doubts.
> 1) It is ignoring all the function of with names like __function_name__
>
It's part of nauty.
> On Thu, Mar 21, 2019 at 9:58 PM John H Palmieri > wrote:
>
>>
>>
>> On Thursday, March 21, 2019 at 9:38:03 PM UTC-7, Ai Bo wrote:
>>>
>>> Saw this in the document:
>>> res/mod : only generate subset res out of subsets 0..mod-1
On Thursday, March 21, 2019 at 9:38:03 PM UTC-7, Ai Bo wrote:
>
> Saw this in the document:
> res/mod : only generate subset res out of subsets 0..mod-1
>
It would help if you gave some context for this. I'm guessing that most
Sage users won't know what "geng" is. I certainly didn't. I found
On Friday, March 15, 2019 at 3:31:33 AM UTC-7, Dima Pasechnik wrote:
>
> On Thu, Mar 14, 2019 at 7:51 PM John H Palmieri > wrote:
> >
> > I'm seeing the same failure on a Mac running the most recent OS X. I
> have openssl 1.1.1a installed on this machine, and
On Thursday, March 14, 2019 at 1:46:38 PM UTC-7, kcrisman wrote:
>
> I just ran the following command, and amazingly got only one timeout and
> one error. The rest is fine.
>
> ./sage -tp 3 -T 600 --optional=sage,python2,latex src/sage
>
>
I'm seeing the same failure on a Mac running the most recent OS X. I have
openssl 1.1.1a installed on this machine, and I see the error in Sage. Then
I did './sage -i openssl' and './sage -f python2', and I still see the
error. The Python 2 log file does not list ssl among the modules which
For those of you who use OS X and also like to do incremental upgrades to
Sage's most recent beta release, I would suggest running 'make distclean'
and then 'make'. Why? Previous versions of Sage have broken file manifests
for its packages – not broken on linux, only OS X – so package
201 - 300 of 1458 matches
Mail list logo
