[sage-devel] Re: Error building Sage

Thank you very much, it's working perfectly. And I am the one who's sorry for not asking in English in the first place. Le jeudi 28 février 2019 07:02:49 UTC+9, John H Palmieri a écrit : > > Please try this: > > ./sage -f zlib > ./sage -f python2 python3 > make > > and see if that fixes the

Re: [sage-devel] Re: Proposal: Add ascii_art representation to factor

And to have this behavior, you simply need to implement the methods _ascii_art_ and _unicode_art_ respectively. For a simple _ascii_art_, see combinat/shuffle.py. Maybe combinat/plane_partition.py is another decent example, but there are a bunch of examples in the combinat folder. Best, Travis

[sage-devel] Re: Inequalities in Z/nZ

On Wednesday, February 27, 2019 at 3:14:53 PM UTC-8, Nils Bruin wrote: > > On Wednesday, February 27, 2019 at 2:17:06 PM UTC-8, John H Palmieri wrote: >> >> Why does Sage allow inequalities in Z/nZ? >> > > I'm pretty sure that it's a historical artifact from Python 2, where > inequality

[sage-devel] Re: Inequalities in Z/nZ

On Wednesday, February 27, 2019 at 2:17:06 PM UTC-8, John H Palmieri wrote: > > Why does Sage allow inequalities in Z/nZ? > I'm pretty sure that it's a historical artifact from Python 2, where inequality relations exist between nearly all objects, because "cmp" is 3-valued. None of the usual

[sage-devel] Inequalities in Z/nZ

Why does Sage allow inequalities in Z/nZ? sage: Z3 = Integers(3) sage: a = Z3(4) sage: b = Z3(2) sage: a < b True sage: a < 3 False While < may make sense in the set {0, 1, 2, ..., n-1}, it doesn't make sense in the ring Z/nZ: sage: Z3(1) < Z3(2) True sage: 1+Z3(1) < 1+Z3(2) False sage:

[sage-devel] Re: Error building Sage

Please try this: ./sage -f zlib ./sage -f python2 python3 make and see if that fixes the problem. (Apologies for not responding in French.) On Wednesday, February 27, 2019 at 1:52:02 PM UTC-8, Quentin Hillebrand wrote: > > En compilant avec make j'obtiens j'obtiens une erreure lors de la >

[sage-devel] Error building Sage

En compilant avec make j'obtiens j'obtiens une erreure lors de la construction de pip-18.0. Je suis sur un MacBook Pro avec macOS Mojave Version 10.14.3. Merci d'avance de votre attention -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

[sage-devel] Re: Should valgrind work when running doctests?

I believe ./sage -t --long --valgrind "doctest" is broken. Please see https://trac.sagemath.org/ticket/27381 for a fix. On Monday, February 25, 2019 at 10:36:47 PM UTC-6, Steven Trogdon wrote: > > Running ./sage --valgrind works with a resulting sage prompt. However, > > ./sage -t --long

Re: [sage-devel] Re: Proposal: Add ascii_art representation to factor

ascii_art and unicode_art are distinct functions. Le 27/02/2019 à 16:02, Juan Nicolas Pardo Martin a écrit : I was thinking about that too, however you only do so in environments where is supported or make a parameter to ascii_art allow Unicode or an entirely new method From: Volker Braun

Re: [sage-devel] Re: python3 status report

On Sun, 27 Jan 2019, 13:39 Vincent Delecroix, <20100.delecr...@gmail.com> wrote: > Le 27/01/2019 à 14:32, Simon King a écrit : > > Hi Frédéric, > > > > On 2019-01-27, Frédéric Chapoton wrote: > >> (2) the most badly failing file is "explain_pickle" with 70 failing > >> doctests. Hopefully, this

Re: [sage-devel] Re: Scalar field on manifold not completely initialized?

+1 for "_SAGE_FUNC". The user should not have to think about the Maxima pre-defined name space unless s/he wants to use a Maxima function: "When I use a word, it means what I choose it to mean, neither more nor less." -- Humpty-Dumpty On Tuesday, February 26, 2019 at 10:33:23 AM UTC-8, Nils

[sage-devel] Re: .an_element() != 0?

On Wednesday, February 27, 2019 at 11:25:38 PM UTC+9, Daniel Krenn wrote: > > Can I savely assume that S.an_element() of something S (within SageMath) > returns an element different from S.zero() if possible (meaning if there > are nonzero elements in S)? > The purpose of S.an_element() is

RE: [sage-devel] Re: Proposal: Add ascii_art representation to factor

I was thinking about that too, however you only do so in environments where is supported or make a parameter to ascii_art allow Unicode or an entirely new method From: Volker Braun Sent: Wednesday, 27 February 2019 00:39 To: sage-devel Subject: [sage-devel] Re: Proposal: Add ascii_art

Re: [sage-devel] .an_element() != 0?

Le 27/02/2019 à 15:29, Jeroen Demeyer a écrit : On 2019-02-27 15:25, Daniel Krenn wrote: Can I savely assume that S.an_element() of something S (within SageMath) returns an element different from S.zero() if possible (meaning if there are nonzero elements in S)? Personally, I wouldn't assume

Re: [sage-devel] .an_element() != 0?

On 2019-02-27 15:25, Daniel Krenn wrote: Can I savely assume that S.an_element() of something S (within SageMath) returns an element different from S.zero() if possible (meaning if there are nonzero elements in S)? Personally, I wouldn't assume anything. -- You received this message because

[sage-devel] .an_element() != 0?

Can I savely assume that S.an_element() of something S (within SageMath) returns an element different from S.zero() if possible (meaning if there are nonzero elements in S)? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

[sage-devel] Re: `ModuleElement` is forced though `Element` should be enough by the category framework

> > > In particular, Jeroen, concerning the strange rule that _lmul_ not being > implemented means that it returns None: I seem to recall (but I am not > 100% sure) that P._get_action_(Q) (or some other method name, I don't > recall) could test what happens if P.zero()._lmul_(Q.zero()) or

Re: [sage-devel] `ModuleElement` is forced though `Element` should be enough by the category framework

On Wednesday, February 27, 2019 at 3:26:08 PM UTC+9, Jeroen Demeyer wrote: > > On 2019-02-26 23:44, Kwankyu Lee wrote: > > It could be possible to hammer the coercion model to behave more nicely > > with the category framework, at least with respect to the issue that I > > raised. > > By the

[sage-devel] Re: Proposal: Add ascii_art representation to factor

Nice suggestion! Now tracked at #27377: - Sage Trac ticket 27377 Provide ascii_art and unicode_art for factorizations https://trac.sagemath.org/ticket/27377 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and

Re: [sage-devel] Note on libpflll during Sage 8.6 install

On Tue, Feb 26, 2019 at 2:36 PM E. Madison Bray wrote: > > On Mon, Feb 11, 2019 at 6:07 PM Randall wrote: > > > > A couple of comments relating to my attempts to build Sage 8.6 on openSuse > > Leap 15.0 system. (64 bit Intel Core X980s) > > > > 1. The fplll build failed due to non-shareable

Re: [sage-devel] flushing stdout during doctests

On Wed, 27 Feb 2019 at 09:16, Jeroen Demeyer wrote: > On 2019-02-26 17:52, John Cremona wrote: > > I am testing a new version of the standard spkg eclib, see > > https://trac.sagemath.org/ticket/27360. I am getting doctesting > > failures caused *only* because of changes in output buffering

[sage-devel] Re: During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()

This is now #27374 On Wednesday, February 27, 2019 at 9:53:35 AM UTC+1, Simon Brandhorst wrote: > > - > SystemError Traceback (most recent call last) > in () >

Re: [sage-devel] Re: During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()

On 2019-02-27 10:31, Simon Brandhorst wrote: Okay. But I cannot reproduce the error consistently. Post anyways? Yes. The traceback is clear enough. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

[sage-devel] Re: During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()

Okay. But I cannot reproduce the error consistently. Post anyways? -- 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

Re: [sage-devel] flushing stdout during doctests

On 2019-02-26 17:52, John Cremona wrote: I am testing a new version of the standard spkg eclib, see https://trac.sagemath.org/ticket/27360. I am getting doctesting failures caused *only* because of changes in output buffering resulting in the tail end of the output of one command appearing at

Re: [sage-devel] Re: flushing stdout during doctests

On 2019-02-27 09:58, John Cremona wrote: The problem went away after I did "make distclean; make build". Originally what I did after checking out a new branch was (1) put the new tarball into upstream/ (2) edit the file build/pkgs/eclib/package-version.txt (3) issue the magic command which

Re: [sage-devel] flushing stdout during doctests

On Wed, 27 Feb 2019 at 08:56, Jeroen Demeyer wrote: > On 2019-02-26 17:52, John Cremona wrote: > > I am testing a new version of the standard spkg eclib, see > > https://trac.sagemath.org/ticket/27360. I am getting doctesting > > failures caused *only* because of changes in output buffering

Re: [sage-devel] Re: flushing stdout during doctests

On 2019-02-27 08:35, Frédéric Chapoton wrote: This problem is also seen in the python3 patchbot report, as can be found here : https://patchbot.sagemath.org/log/0/Ubuntu/16.04/x86_64/4.4.0-141-generic/atlas/2019-02-24%2011:31:45?short In Python 3, the situation is different because Python

Re: [sage-devel] Re: flushing stdout during doctests

The problem went away after I did "make distclean; make build". Originally what I did after checking out a new branch was (1) put the new tarball into upstream/ (2) edit the file build/pkgs/eclib/package-version.txt (3) issue the magic command which updates the checksum (4) ./sage -i eclib

Re: [sage-devel] flushing stdout during doctests

On 2019-02-26 17:52, John Cremona wrote: I am testing a new version of the standard spkg eclib, see https://trac.sagemath.org/ticket/27360. I am getting doctesting failures caused *only* because of changes in output buffering resulting in the tail end of the output of one command appearing at

Re: [sage-devel] During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()

Please create a Trac ticket for this. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email

[sage-devel] During a libgap evaluation: SystemError: calling remove_from_pari_stack() inside sig_on()

- SystemError Traceback (most recent call last) in () > 1 classify_ord_pe(L,Integer(2),Integer(2),"results/order4.txt","w") /home/simon/.sage/temp/k3/8598/K3_aut_classification.sageqIg9CK.py in