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
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
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.
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
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
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
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
>
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
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
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
>
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
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
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
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
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
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
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,
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
> 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
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
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"
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.
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
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:
>
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.
>
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
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
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"
>
>
> > *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.
>
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,
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
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
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
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
>
> 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
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
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
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
56 matches
Mail list logo
