There's now a proposed solution in the branch of
https://trac.sagemath.org/ticket/32056, needs review
On Thursday, June 24, 2021 at 10:59:26 AM UTC-7 Matthias Koeppe wrote:
> I have opened https://trac.sagemath.org/ticket/32056 for the mysterious
> issue with 'binascii'.
>
>
> On Thursday, June
On Thu, Jun 24, 2021 at 6:56 PM Marc Culler wrote:
>
> On Thu, Jun 24, 2021 at 11:50 AM Dima Pasechnik wrote:
> >
> > There is no need to build Python, you can either use one from Homebrew
> > or from the official Python distribution.
> >
>
> That is an extremely unhelpful answer, especially give
On Thursday, June 24, 2021 at 10:56:37 AM UTC-7 marc@gmail.com wrote:
> If people are following the
> build instructions in the README file and the build is failing then
> the build is broken and it should be fixed.
>
>
I agree
> [...] The answer which would have helped me is this:
>
>
I have opened https://trac.sagemath.org/ticket/32056 for the mysterious
issue with 'binascii'.
On Thursday, June 24, 2021 at 9:46:36 AM UTC-7 marc@gmail.com wrote:
> I am seeing the same error with Python 3.9.5 when I attempt to build Sage
> 9.4.beta3 from source on macOS 11.4. The build
On Thu, Jun 24, 2021 at 11:50 AM Dima Pasechnik wrote:
>
> There is no need to build Python, you can either use one from Homebrew
> or from the official Python distribution.
>
That is an extremely unhelpful answer, especially given what I am
trying to do. It is also ridiculous. If people are fo
On Thu, Jun 24, 2021 at 5:46 PM Marc Culler wrote:
>
> I am seeing the same error with Python 3.9.5 when I attempt to build Sage
> 9.4.beta3 from source on macOS 11.4.
There is no need to build Python, you can either use one from Homebrew
or from the official Python distribution.
> The build f
Looks like its #31326, but I posted some details to #30651
On Sunday, March 7, 2021 at 8:16:08 PM UTC+1 Matthias Koeppe wrote:
> Details please -> https://trac.sagemath.org/ticket/30651
>
> On Sunday, March 7, 2021 at 3:16:37 AM UTC-8 Volker Braun wrote:
>
>> For the record, I've set up a BS buil
Details please -> https://trac.sagemath.org/ticket/30651
On Sunday, March 7, 2021 at 3:16:37 AM UTC-8 Volker Braun wrote:
> For the record, I've set up a BS buildbot at http://build.sagemath.org,
> but it currently doesn't succeed in compiling Sage.
>
>
>
> On Friday, March 5, 2021 at 9:01:51 PM
For the record, I've set up a BS buildbot at http://build.sagemath.org, but
it currently doesn't succeed in compiling Sage.
On Friday, March 5, 2021 at 9:01:51 PM UTC+1 harald@gmail.com wrote:
> Hi,
>
> I've been trying to compile Sage on a Mac running macOS 11.2.2 (Big Sur).
> (I first tr
Sage 9.2 does not support building from source on Big Sur
(see
https://wiki.sagemath.org/ReleaseTours/sage-9.2#Availability_of_Sage_9.2_and_installation_help).
You can try the latest development version in the 9.3 series.
On Friday, March 5, 2021 at 12:01:51 PM UTC-8 harald@gmail.com wrote
> * There are some remaining hard problems in graphs, under current scrutiny
> I think.
>
The main remaining issues in the graph module are related to isomorphisms,
automorphisms, and related methods.
1) #27571: align behaviors of algorithm 'sage' and 'bliss' in
`automorphism_group` and fix
Frédéric wrote:
> [...] although I vaguely remember that Samuel Lelievre
> once asked for something like that, and I may have
> prepared the ground for it (I forgot about that),
> but never for any feedback.
Yes, I was asking about that a while ago, and it took me
a while to experiment and to set
On Saturday, April 20, 2019 at 8:41:34 PM UTC+2, vdelecroix wrote:
>
> Shouldn't we implement that only as a IPython hook as well then?
>
The displayhook override is really just a hack since the plain python
output can't be changed, whereas Sage can generate nice output by default.
So IMHO no,
See https://trac.sagemath.org/ticket/27710 for a python3 fix to
combinat/tutorial.py
On Sunday, 21 April 2019 09:26:11 UTC+10, Andrew wrote:
>
> Fixing this problem properly as Martin or Volker suggests is probably the
> best option but `# random print order` is a good option too, which I was
>
On Saturday, April 20, 2019 at 4:26:11 PM UTC-7, Andrew wrote:
>
> Fixing this problem properly as Martin or Volker suggests is probably the
> best option but `# random print order` is a good option too, which I was
> not aware of -- or is this really `# random` with additional explanation?
>
I
Fixing this problem properly as Martin or Volker suggests is probably the
best option but `# random print order` is a good option too, which I was
not aware of -- or is this really `# random` with additional explanation?
Is there a complete list of the doc-test modifiers anywhere? I just looked
Le 20/04/2019 à 09:43, Volker Braun a écrit :
On Saturday, April 20, 2019 at 1:10:28 AM UTC+2, Andrew wrote:
Set(['a', 'b', 'c'])
gives different output with each sage session, at least when `sage` is
compiled with python3.
Ideally Set._repr_ would try to sort the set members (falling back t
On Saturday, April 20, 2019 at 1:10:28 AM UTC+2, Andrew wrote:
>
> Set(['a', 'b', 'c'])
> gives different output with each sage session, at least when `sage` is
> compiled with python3.
>
Ideally Set._repr_ would try to sort the set members (falling back to
alphabetical order if the elements can
Sorry: "Should we do this?" should be "Should I do this?"
Martin
Am Samstag, 20. April 2019 06:31:20 UTC+2 schrieb Martin R:
>
> In my opinion, `Set` should not be used in library code. It is slow,
> unnecessary, and can hide subtle bugs when the underlying object is not
> hashable. (https://t
In my opinion, `Set` should not be used in library code. It is slow,
unnecessary, and can hide subtle bugs when the underlying object is not
hashable. (https://trac.sagemath.org/ticket/23324)
For the concrete issue at hand, the use of `Set` could be easily removed in
all methods except `SetPar
On Friday, April 19, 2019 at 5:25:13 PM UTC-7, John H Palmieri wrote:
>
> What does
>
> sage: C
> Set partitions of {'a', 'c', 'b'}
>
>
> reveal? Is it helpful, or can it be omitted?
>
> Adding to that: perhaps it reveals something for the documentation reader.
But in that case the output doesn't
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'}},
What the accepted best practice for fixing the failing python3 doc-tests?
For example, in `combinat/tutorial.py` I can fix one of the failing
doc-tests with:
sage: C = SetPartitions(["a", "b", "c"])
sage: C #py2
Set partitions of {'a', 'c', 'b'}
sage: C #py3
Set partitions of
I see that you tried option (2). Not quite successful, it seems.
Your patchbot shows a failure in
sage -t --long src/sage/modular/pollack_stevens/padic_lseries.py
Does it pass when you run it manually ?
F
Le mercredi 17 avril 2019 15:06:59 UTC+2, Daniel Krenn a écrit :
>
> Is it possible to se
What do you expect to do ?
(1) run all the tests and see the 94 remaining failing files ?
(2) or run only python3-certified tests and check that they pass on your
machine ?
I am doing (1) after almost every beta release. I have never tried (2),
although I vaguely remember that Samuel Lelievre
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 w
Hi,
On Mon, Feb 11, 2019 at 11:14:35AM +0100, Jeroen Demeyer wrote:
> On 2019-02-11 11:12, David Coudert wrote:
> >
> >
> > Le mardi 29 janvier 2019 23:19:12 UTC+1, Thierry (sage-googlesucks@xxx)
> > a écrit :
[...]
> >
> > That said, regarding the .edges() method, i think that returning a
On 2019-02-11 11:12, David Coudert wrote:
Le mardi 29 janvier 2019 23:19:12 UTC+1, Thierry (sage-googlesucks@xxx)
a écrit :
Hi,
On Sun, Jan 27, 2019 at 11:21:21AM -0800, David Coudert wrote:
[...]
> The most complicated issue is certainly edges of Graph: we sort the
> ve
Le mardi 29 janvier 2019 23:19:12 UTC+1, Thierry (sage-googlesucks@xxx) a
écrit :
>
> Hi,
>
> On Sun, Jan 27, 2019 at 11:21:21AM -0800, David Coudert wrote:
> [...]
> > The most complicated issue is certainly edges of Graph: we sort the
> > vertices of an edge before returning it... I have n
Also, I have now set up a Python3 buildbot to catch regressions!
--
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 t
Hi,
On Sun, Jan 27, 2019 at 11:21:21AM -0800, David Coudert wrote:
[...]
> The most complicated issue is certainly edges of Graph: we sort the
> vertices of an edge before returning it... I have no solution for this
> issue. We can decide to stop ordering the vertices, but then we will have
> t
On 2019-01-27 14:50, Simon King wrote:
> How to do so most easily, so that "git pull" etc. still referes to trac?
> That was part of my question. Doing "git pull
> /path/to/my/old/installation" would mean that I need to go to my old
> installation, "git pull" (pulls develop from trac), go to the ne
Le mardi 29 janvier 2019 10:29:43 UTC+1, Samuel Lelievre a écrit :
>
> Sun 2019-01-27 14:23:08 UTC+1, Frédéric Chapoton:
> >
> >
> > STATEMENT: I would to advocate that *every developer switch to python3
> NOW*.
> >
> >
> > Please vote!
>
> Strong +1 from me.
>
>
+1 from me too.
Many, many thanks
Sun 2019-01-27 14:23:08 UTC+1, Frédéric Chapoton:
>
> here is a small progress report on porting sage to python3.
> Good, but still too slow for my taste. The sooner we can
> catch up with jupyter, the better..
>
> (1) with the latest beta (8.7.b1), there are now exactly 200 files
> having failing
On Sun, Jan 27, 2019 at 2:55 PM Simon King wrote:
>
> Hi Frédéric,
>
> On 2019-01-27, Frédéric Chapoton wrote:
> > I am pretty sure you would be rather happy working only with python3.
>
> That's too early. For teaching, I need to know that I have a working
> Sage installation, and for research I
Hi Jeroen,
On 2019-01-27, Jeroen Demeyer wrote:
> On 2019-01-27 22:36, Simon King wrote:
>> But do py3 experts agree that to transform os.path.join(...) to char*
>> (which is not in pickling but in module initialisation), I need
>> PyString_...?
>
> No! Please see src/sage/cpython/string.pyx
Tha
On 2019-01-27 22:36, Simon King wrote:
But do py3 experts agree that to transform os.path.join(...) to char*
(which is not in pickling but in module initialisation), I need
PyString_...?
No! Please see src/sage/cpython/string.pyx
(sorry no time now to answer more)
--
You received this message
PS:
On 2019-01-27, Simon King wrote:
> The funny thing is that 2 years ago, I was told by Jeroen:
> """
> For Python 3 compatibility, you should use bytes instead of str for
> pickling.
>
> This means changing the PyString_... functions to PyBytes_...
> """
To be fair, Jeroen talked abo
Hi,
On 2019-01-27, Simon King wrote:
> Is there a ticket for meataxe on python 3 already? I guess not. So,
> unless someone stops me in the next hour or so, I'll open one...
I created https://trac.sagemath.org/ticket/27152.
First problem: In py2,
PyBytes_AsString(os.path.join(DOT_SAGE,'meataxe'
Dear all,
using "git worktree", I now have both python 2 and python 3 versions of
Sage on my computer. Thank you!
Of course, I started to check packages that I care about --- and
immediately found a problem with the "meataxe" optional package.
When trying to create a matrix of type Matrix_gfpn_d
> Is there an apparent common reason for most of these failing tests? Such
> as code that makes assumptions on sorting (which, IIRC, is different in
> Python 2 and Python 3)?
>
Many many methods were relying on sorted list of vertices and edges. We
have done significant progresses to reduce
Hi Frédéric,
On 2019-01-27, Frédéric Chapoton wrote:
> Does this mean that everything dependent on python will have to be
> recompiled when you switch ?
My original worktree was ~/Sage/git/sage. I added a new worktree
~/Sage/git/py3 using "git worktree add". The fact that
~/Sage/git/sage/local
Does this mean that everything dependent on python will have to be
recompiled when you switch ?
F
Le dimanche 27 janvier 2019 16:26:17 UTC+1, Timo Kaufmann a écrit :
>
>
>
> Am Sonntag, 27. Januar 2019 14:32:16 UTC+1 schrieb Simon King:
>
>> > *STATEMENT *: I would to advocate that **every devel
Hi Timo,
On 2019-01-27, Timo Kaufmann wrote:
> Git worktrees would be a solution. Essentially you keep one git repository,
> but check out two branches at the same time in different directories. From
> your main repo do this:
>
> $ git worktree add /path/to/the/new/checkout branch-to-checkout
Am Sonntag, 27. Januar 2019 14:32:16 UTC+1 schrieb Simon King:
> > *STATEMENT *: I would to advocate that **every developer switch to
> python3
> > NOW**.
>
> How?
>
Git worktrees would be a solution. Essentially you keep one git repository,
but check out two branches at the same time in d
Le 27/01/2019 à 15:56, Simon King a écrit :
Hi Vincent,
On 2019-01-27, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
king@klap:~/Sage/py3/sage$ git remote add trac g...@trac.sagemath.org:sage.git
After that, you should see "trac" among your remotes
$ git remote -v
And "origin" sho
Hi Vincent,
On 2019-01-27, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
>> king@klap:~/Sage/py3/sage$ git remote add trac
>> g...@trac.sagemath.org:sage.git
>
> After that, you should see "trac" among your remotes
>
> $ git remote -v
>
> And "origin" should be your local repo.
Correct!
Hi Simon,
Le 27/01/2019 à 15:19, Simon King a écrit :
On 2019-01-27, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
This has nothing to do with python 3.
Sure.
You only need to set up
properly your remote and branches.
Exactly. And that's already more than what I can do in git witho
I believe it was added by
What I am unsure about now (too hard to dig using a phone :-)) is how to
switch between different SAGE_LOCAL.
Probably by setting an env. variable.
https://trac.sagemath.org/ticket/21479
On Sun, 27 Jan 2019 14:12 Vincent Delecroix <20100.delecr...@gmail.com
wrote:
> Pl
Hi Vincent,
On 2019-01-27, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> This has nothing to do with python 3.
Sure.
> You only need to set up
> properly your remote and branches.
Exactly. And that's already more than what I can do in git without
reading tons of documentation.
> After
Please tell us how. None of us claimed that two clones were needed.
Le 27/01/2019 à 15:03, Dima Pasechnik a écrit :
Why does one need two clones? We have functionality to allow a custom build
location. It should be possible to give it to configure as a parameter...
On Sun, 27 Jan 2019 13:58 Vin
Why does one need two clones? We have functionality to allow a custom build
location. It should be possible to give it to configure as a parameter...
On Sun, 27 Jan 2019 13:58 Vincent Delecroix <20100.delecr...@gmail.com
wrote:
>
>
> Le 27/01/2019 à 14:50, Simon King a écrit :
> > Hi Vincent,
> >
PPS: if you intend to have a py2 and py3 installation it is a good
idea to have a shared $SAGE_ROOT/upstream/ repository (where
package tarballs are downloaded). This can be done via a simple
simlink in the py3 installation.
Maybe we could create a configure option --with-upstream=PATH for
this?
Le 27/01/2019 à 14:50, Simon King a écrit :
Hi Vincent,
On 2019-01-27, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
You need a different clone of your git repo, let say sage-py3.
How to do so most easily, so that "git pull" etc. still referes to trac?
That was part of my question.
git clone git://github.com/sagemath/sage.git sage3
Le dimanche 27 janvier 2019 14:50:22 UTC+1, Simon King a écrit :
>
> Hi Vincent,
>
> On 2019-01-27, Vincent Delecroix <20100.d...@gmail.com >
> wrote:
> > You need a different clone of your git repo, let say sage-py3.
>
> How to do so most eas
Hi Frédéric,
On 2019-01-27, Frédéric Chapoton wrote:
> I am pretty sure you would be rather happy working only with python3.
That's too early. For teaching, I need to know that I have a working
Sage installation, and for research I also have to have a working
installation of my group cohomology
Hi Vincent,
On 2019-01-27, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> You need a different clone of your git repo, let say sage-py3.
How to do so most easily, so that "git pull" etc. still referes to trac?
That was part of my question. Doing "git pull
/path/to/my/old/installation" wou
>
>
> > *STATEMENT *: I would to advocate that **every developer switch to
> python3
> > NOW**.
>
> How?
>
> To make my question more precise: For production I would like to
> keep a python 2 installation of Sage.
I am pretty sure you would be rather happy working only with python3.
> So
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 will be treated very carefully by Erik M. Bray
(3) after that, we still have problems with graph, wher
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 will be treated very carefully by Erik M. Bray
>
> (3) after that, we still have problems with graph, where generic_graph.py
> has 50 failing do
On Wednesday, October 31, 2018 at 2:34:59 AM UTC+9, John H Palmieri wrote:
>
>
>
> On Monday, October 29, 2018 at 9:36:33 PM UTC-7, Kwankyu Lee wrote:
>>
>> Or run 'make distclean' before switching Python versions.
>>>
>>
>> For me, "make distclean" did not work.
>>
>
> What didn't work about it?
On Monday, October 29, 2018 at 9:36:33 PM UTC-7, Kwankyu Lee wrote:
>
> Or run 'make distclean' before switching Python versions.
>>
>
> For me, "make distclean" did not work.
>
What didn't work about it? "make distclean" followed by "./configure
--with-python=3" and then "make" works for me.
>
> Or run 'make distclean' before switching Python versions.
>
For me, "make distclean" did not 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
On Sunday, October 28, 2018 at 10:15:21 PM UTC-7, Kwankyu Lee wrote:
>
> How did your tentative fail ?
>>
>
> It was incremental build from sage with python2.
>
> So I tried to build in a freshly-cloned repository, and sage with python3
> was built successfully on my mac.
>
> Thanks!
>
This i
>
> How did your tentative fail ?
>
It was incremental build from sage with python2.
So I tried to build in a freshly-cloned repository, and sage with python3
was built successfully on my mac.
Thanks!
--
You received this message because you are subscribed to the Google Groups
"sage-devel
I regularly build with Python 3 on a mac. Well, not the documentation, but
everything else.
On Sunday, October 28, 2018 at 5:07:12 AM UTC-7, Frédéric Chapoton wrote:
>
> No idea. Did some other people manage or fail to build sage with python3
> on mac ?
>
> How did your tentative fail ?
>
> Le
No idea. Did some other people manage or fail to build sage with python3 on
mac ?
How did your tentative fail ?
Le dimanche 28 octobre 2018 12:03:01 UTC+1, Kwankyu Lee a écrit :
>
> Is the status the same also for mac? I recently tried to build sage for
> python 3 on mac, but only to fail...
>
Is the status the same also for mac? I recently tried to build sage for
python 3 on mac, but only to fail...
--
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-
There is already a python3-specific make target (since
https://trac.sagemath.org/ticket/24706) but nobody ever told me if this is
used or not. I do not have the technical knowledge to setup my own buildbot.
The idea could be to modify this make target, for example : maybe one could
test only th
Wonderful news!
I can add a python 3 build to the buildbot, but without running tests its
probably not going to be super useful. What would be great is if there were
a way to run the known-good doctests on python3, e.g. "make ptestlong"
could just have a blacklist of those 414 files that are kn
On Tue, Aug 28, 2018 at 2:36 AM John Cremona wrote:
>
> I could do this for elliptic curves, but not this week as I'm at a meeting.
FWIW for elliptic curves my python3 branch has these failures:
sage -t src/sage/schemes/elliptic_curves/descent_two_isogeny.pyx # 1
doctest failed
sage -t src/sage
I could do this for elliptic curves, but not this week as I'm at a meeting.
John
On Mon, 27 Aug 2018 at 00:02, John H Palmieri
wrote:
> First, thank you, Frédéric, for all of the work you've done on this.
>
> Second, to everyone else: if you're an expert in, say, toric varieties or
> elliptic c
First, thank you, Frédéric, for all of the work you've done on this.
Second, to everyone else: if you're an expert in, say, toric varieties or
elliptic curves, try building Sage with Python 3 and then fixing doctests
on the appropriate directory. Some of these will be easy for anyone, but
some
Dear Nils,
Le jeudi 31 mai 2018 18:31:31 UTC+2, Nils Bruin a écrit :
>
> On Thursday, May 31, 2018 at 4:52:04 AM UTC-7, Emmanuel Charpentier wrote:
>>
>> I'm grabbing the opportunity to recall that , whereas I have installed
>> the Sage kernel in my (systemwide) jupyter installation via the suita
I have created https://trac.sagemath.org/ticket/25486 for this.
On Wednesday, May 30, 2018 at 10:32:42 AM UTC-7, Matthias Koeppe wrote:
>
> On Wednesday, May 30, 2018 at 9:01:59 AM UTC-7, Nils Bruin wrote:
>>
>>
>> Currently, if I run the script $SAGE_LOCAL/bin/sage in my normal
>> environment (w
On Thursday, May 31, 2018 at 4:52:04 AM UTC-7, Emmanuel Charpentier wrote:
>
> I'm grabbing the opportunity to recall that , whereas I have installed the
> Sage kernel in my (systemwide) jupyter installation via the suitable "jupyter
> kernelspec install ..." invocation), when I try to use it fro
I'm grabbing the opportunity to recall that , whereas I have installed the
Sage kernel in my (systemwide) jupyter installation via the suitable "jupyter
kernelspec install ..." invocation), when I try to use it from the
systemwide jupyter via the "normal" invocation "jupyter notebook", it
compl
On Wednesday, May 30, 2018 at 9:01:59 AM UTC-7, Nils Bruin wrote:
>
>
> Currently, if I run the script $SAGE_LOCAL/bin/sage in my normal
> environment (where SAGE_ROOT is not set) then I get:
>
> Error: You must set the SAGE_ROOT environment variable or run this
> script from the SAGE_ROOT or SAGE
On Wednesday, May 30, 2018 at 1:28:25 AM UTC-7, Jeroen Demeyer wrote:
>
> On 2018-05-29 22:57, Nils Bruin wrote:
> > it would also be useful to
> > use a "sage" executable that can figure out $SAGE_ROOT from scratch.
>
> Can you say more precisely what you mean with this?
>
Currently, if I run
On 2018-05-29 22:57, Nils Bruin wrote:
it would also be useful to
use a "sage" executable that can figure out $SAGE_ROOT from scratch.
Can you say more precisely what you mean with this?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubs
Tue 2018-05-29 15:59:27 UTC, Frédéric Chapoton:
>
> here is a small report on the slow progress towards Python3-compatibility
> for Sage.
>
> Sage is already building and starting with python3 since some time
already.
> It is explained in https://trac.sagemath.org/ticket/15530 how to get
> a pytho
On Tuesday, May 29, 2018 at 8:59:27 AM UTC-7, Frédéric Chapoton wrote:
>
> Hello,
>
> here is a small report on the *slow* progress towards
> python3-compatibility for sage.
>
> Sage is already building and starting with python3 since some time
> already. It is explained in https://trac.sagemath.
Le jeudi 16 novembre 2017 15:02:36 UTC+1, Eric Gourgoulhon a écrit :
>
> so this should hamper the transition to Python3
>
Yet another typo: "this should hamper" --> "this should not hamper"
Sorry.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
On 2017-11-05 22:51, Travis Scrimshaw wrote:
I'm not quite sure what you're asking. min and max are not fundamentally
changed between Python3 except that the cmp keyword will no longer be
valid.
The functions min() and max() are not fundamentally different but the
way how comparison works is d
I'm not quite sure what you're asking. min and max are not fundamentally
changed between Python3 except that the cmp keyword will no longer be
valid. So if you do min(L) or min(L, key=foo), both will work in Python3,
up to how you are doing comparisons within L. For that, it is localized to
the
Given http://www.python3statement.org/ lists a number of crucial Sage
dependencies to drop py2 on or before 2020, there is little choice. :-)
In fact, I think we should get Sage added to that list too, and get to work
on py3 in the earnest.
On Friday, October 13, 2017 at 4:56:11 PM UTC+1, Fréd
On Friday, October 13, 2017 at 5:56:11 PM UTC+2, Frédéric Chapoton wrote:
>
> Hello,
>
> I have reached this point with the ugly python3 experimental branch
> "public/python3-experiment-8.1.b7":
>
>
> ┌┐
> │ SageMath version 8.1.b
That's great! Thank you for all of your work on this.
John
On Friday, October 13, 2017 at 8:56:11 AM UTC-7, Frédéric Chapoton wrote:
>
> Hello,
>
> I have reached this point with the ugly python3 experimental branch
> "public/python3-experiment-8.1.b7":
>
>
> ┌
Le vendredi 25 août 2017 19:35:27 UTC+2, Nils Bruin a écrit :
>
> Something along the lines of
>
> import sage.repl.ipython_kernel.install
> sage.repl.ipython_kernel.install.JUPYTER_PATH =
> spec = sage.repl.ipython_kernel.install.SageKernelSpec()
> spec.update()
>
> With any luck, you'll see Sag
On Friday, August 25, 2017 at 12:55:56 AM UTC-7, Eric Gourgoulhon wrote:
>
> Hi,
>
> Le jeudi 24 août 2017 23:17:07 UTC+2, Nils Bruin a écrit :
>
>>
>> If you're using jupyter for non-sage-specific purposes (apparently
>> relying on a system python3), why not use system jupyter? Personally, I
>>
On Fri, Aug 25, 2017 at 1:38 PM, Erik Bray wrote:
> On Thu, Aug 24, 2017 at 11:49 PM, William Stein wrote:
>> On Thu, Aug 24, 2017 at 2:17 PM, Nils Bruin wrote:
>>> On Thursday, August 24, 2017 at 1:30:25 PM UTC-7, William wrote:
I'm not sure what the status is these days, but we may w
On Thu, Aug 24, 2017 at 11:49 PM, William Stein wrote:
> On Thu, Aug 24, 2017 at 2:17 PM, Nils Bruin wrote:
>> On Thursday, August 24, 2017 at 1:30:25 PM UTC-7, William wrote:
>>>
>>> I'm not sure what the status is these days, but we may want to stop
>>> including a python3 binary in Sage by def
Hi,
Le jeudi 24 août 2017 23:17:07 UTC+2, Nils Bruin a écrit :
>
> If you're using jupyter for non-sage-specific purposes (apparently relying
> on a system python3), why not use system jupyter? Personally, I just
> install the sage-jupyter kernel in the system jupyter.
>
This sounds nice! Co
On Thursday, August 24, 2017 at 2:50:09 PM UTC-7, William wrote:
>
> On Thu, Aug 24, 2017 at 2:17 PM, Nils Bruin >
> wrote:
> > On Thursday, August 24, 2017 at 1:30:25 PM UTC-7, William wrote:
> >>
> >> I'm not sure what the status is these days, but we may want to stop
> >> including a pyth
On Thu, Aug 24, 2017 at 2:17 PM, Nils Bruin wrote:
> On Thursday, August 24, 2017 at 1:30:25 PM UTC-7, William wrote:
>>
>> I'm not sure what the status is these days, but we may want to stop
>> including a python3 binary in Sage by default with "python3" right
>> there in the "sage -sh" path...
>
On Thursday, August 24, 2017 at 1:30:25 PM UTC-7, William wrote:
>
> I'm not sure what the status is these days, but we may want to stop
> including a python3 binary in Sage by default with "python3" right
> there in the "sage -sh" path...
As far as I understand, having python3 included in sag
This seems to fix the core-dumped issue. I have added a suggestion
to https://trac.sagemath.org/ticket/23325
Le dimanche 6 août 2017 09:44:00 UTC+2, François Bissey a écrit :
>
> In pynac's spkg-intall replace
> ./configure --disable-static --prefix=${SAGE_LOCAL} --with-giac=no
> --libdir="$SAG
adding a PYTHON=python3 line in spkg-install seems to fix the version check
issue
Le dimanche 6 août 2017 09:13:51 UTC+2, François Bissey a écrit :
>
> I have seen this strange thing before on this list I am sure.
> For some reason the wrong thing ends up being passed to configure
> and be test
In pynac's spkg-intall replace
./configure --disable-static --prefix=${SAGE_LOCAL} --with-giac=no
--libdir="$SAGE_LOCAL/lib”
with
./configure --disable-static --prefix=${SAGE_LOCAL} --with-giac=no
--libdir="$SAGE_LOCAL/lib” PYTHON=python3.6
If you have something more subtle for the value of PYTHO
So what would be an exact brutal and temporary fix ?
Le dimanche 6 août 2017 09:13:51 UTC+2, François Bissey a écrit :
>
> I have seen this strange thing before on this list I am sure.
> For some reason the wrong thing ends up being passed to configure
> and be tested.
>
> A more brutal and eff
1 - 100 of 190 matches
Mail list logo
