Re: [sage-devel] Re: python3 status report (mi-april of last python2 year)
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, just do the right thing in _repr_. -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report (mi-april of last python2 year)
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
> 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
> and couldn't find one.I guess that I could just grep through all of the
> documentation...
>
> Andrew
>
> On Saturday, 20 April 2019 12:14:53 UTC+10, Nils Bruin wrote:
>>
>> 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 need to be tested. The test
>> comes later by showing that further methods on C have the desired effect.
>> In that case,
>>
>> sage: C # random print order
>> Set partitions of {'a', 'c', 'b'}
>> sage: C.cardinality()
>> 5
>>
>> does the trick AND we keep the output displayed for documentation
>> purposes.
>>
>>
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report (mi-april of last python2 year)
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 intended it to just be "random" with additional explanation. But the system accepts it. So it IS a supported comment :-). I think it's better than a bare random, otherwise a reader might get confused about what is random about a set of partitions. -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report (mi-april of last python2 year)
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
and couldn't find one.I guess that I could just grep through all of the
documentation...
Andrew
On Saturday, 20 April 2019 12:14:53 UTC+10, Nils Bruin wrote:
>
> 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 need to be tested. The test
> comes later by showing that further methods on C have the desired effect.
> In that case,
>
> sage: C # random print order
> Set partitions of {'a', 'c', 'b'}
> sage: C.cardinality()
> 5
>
> does the trick AND we keep the output displayed for documentation purposes.
>
>
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report (mi-april of last python2 year)
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 to
alphabetical order if the elements can't be compared). This is how the
plain-python set() works; The set members are unordered but the IPython
displayhook will sort them to obtain nicer output:
$ python
[...]
set([1,2,320,6,210])
{320, 1, 2, 6, 210}
$ ipython
[...]
In [1]: set([1,2,320,6,210])
Out[1]: {1, 2, 6, 210, 320}
Shouldn't we implement that only as a IPython hook as well then?
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report (mi-april of last python2 year)
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't be compared). This is how the
plain-python set() works; The set members are unordered but the IPython
displayhook will sort them to obtain nicer output:
$ python
[...]
>>> set([1,2,320,6,210])
{320, 1, 2, 6, 210}
$ ipython
[...]
In [1]: set([1,2,320,6,210])
Out[1]: {1, 2, 6, 210, 320}
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report (mi-april of last python2 year)
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://trac.sagemath.org/ticket/23324)
>
> For the concrete issue at hand, the use of `Set` could be easily removed
> in all methods except `SetPartition.base_set` and
> `SetPartitions_set.base_set`, because in these two cases calling code might
> expect a `Set`.
>
> Should we do this?
>
> I should add that this (probably) doesn't solve the underlying issue, and
> moreover may affect a lot of doctests, because it might change the ordering
> of the parts returned in _repr_.
>
> Martin
>
>
> Am Samstag, 20. April 2019 04:14:53 UTC+2 schrieb Nils Bruin:
>>
>> 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 need to be tested. The test
>> comes later by showing that further methods on C have the desired effect.
>> In that case,
>>
>> sage: C # random print order
>> Set partitions of {'a', 'c', 'b'}
>> sage: C.cardinality()
>> 5
>>
>> does the trick AND we keep the output displayed for documentation
>> purposes.
>>
>>
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report (mi-april of last python2 year)
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 `SetPartition.base_set` and
`SetPartitions_set.base_set`, because in these two cases calling code might
expect a `Set`.
Should we do this?
I should add that this (probably) doesn't solve the underlying issue, and
moreover may affect a lot of doctests, because it might change the ordering
of the parts returned in _repr_.
Martin
Am Samstag, 20. April 2019 04:14:53 UTC+2 schrieb Nils Bruin:
>
> 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 need to be tested. The test
> comes later by showing that further methods on C have the desired effect.
> In that case,
>
> sage: C # random print order
> Set partitions of {'a', 'c', 'b'}
> sage: C.cardinality()
> 5
>
> does the trick AND we keep the output displayed for documentation purposes.
>
>
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report (mi-april of last python2 year)
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 need to be tested. The test comes later
by showing that further methods on C have the desired effect. In that case,
sage: C # random print order
Set partitions of {'a', 'c', 'b'}
sage: C.cardinality()
5
does the trick AND we keep the output displayed for documentation purposes.
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report (mi-april of last python2 year)
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'}},
{{'a', 'c'}, {'b'}}]
You should use your judgment about whether the doctest prints useful output
for a reader, for example. If it needs different cases for py2 and py3, is
it more helpful to print it or is it more confusing?
On Friday, April 19, 2019 at 4:10:28 PM UTC-7, Andrew wrote:
>
> 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 {'a', 'b', 'c'}
>
> but this does not address the underlying problem. At first sight this
> looks like an issue with `SetPartitions` and, indeed,
> `combinat/setpartition.py` has several failing doc-tests but as far as I
> can see this is actually an issue with `Set` even though `sets/set.py`
> passes all doc-tests. You can see this because
>
> Set(['a', 'b', 'c'])
>
> gives different output with each sage session, at least when `sage` is
> compiled with python3.
>
> On Monday, 15 April 2019 21:56:54 UTC+10, Frédéric Chapoton wrote:
>>
>> Hello,
>>
>> sage-with-python3 (now using python 3.7.3) has now *less than 100 files*
>> (94 precisely) with failing doctests, for a total of *324 failing
>> doctests*. Among these, 34 files have a single failing doctest.
>>
>> A detailed summary can be found here :
>> https://trac.sagemath.org/ticket/26212
>>
>> There remains many hard-to-fix issues. Please help if you can.
>>
>> * Matroid, dynamics and combinat people should care for their code. The
>> cluster code needs particular work.
>>
>> * We should also strive to make all tests pass in rings/
>>
>> * An expert is required on src/sage/misc/classcall_metaclass.pyx
>>
>> Frédéric
>>
>>
>>
>>
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report (mi-april of last python2 year)
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 {'a', 'b', 'c'}
but this does not address the underlying problem. At first sight this looks
like an issue with `SetPartitions` and, indeed, `combinat/setpartition.py`
has several failing doc-tests but as far as I can see this is actually an
issue with `Set` even though `sets/set.py` passes all doc-tests. You can
see this because
Set(['a', 'b', 'c'])
gives different output with each sage session, at least when `sage` is
compiled with python3.
On Monday, 15 April 2019 21:56:54 UTC+10, Frédéric Chapoton wrote:
>
> Hello,
>
> sage-with-python3 (now using python 3.7.3) has now *less than 100 files*
> (94 precisely) with failing doctests, for a total of *324 failing
> doctests*. Among these, 34 files have a single failing doctest.
>
> A detailed summary can be found here :
> https://trac.sagemath.org/ticket/26212
>
> There remains many hard-to-fix issues. Please help if you can.
>
> * Matroid, dynamics and combinat people should care for their code. The
> cluster code needs particular work.
>
> * We should also strive to make all tests pass in rings/
>
> * An expert is required on src/sage/misc/classcall_metaclass.pyx
>
> Frédéric
>
>
>
>
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
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 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 doctests. But good progress was made by David Coudert, > > > > 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)? > > > >> *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. So, given my existing Sage > > installation, what would be the easiest way to create a second > > installation with python 3 that is automatically configured to work > > well with "git trac"? I guess it is some kind of git clone. Also I > > don't know what make target is needed. > > You need a different clone of your git repo, let say sage-py3. In that > clone, do > > $ make configure > $ ./configure --with-python=3 > > Then, unless you rerun configure, every call to make will take care > of the Python 3 switch automatically. > Not quite: doing make distclean will take you back to the python2 default and you'll need to run configure again. This just happened to me. (I have a bad habit of doing make distclean; make whenever anything mysterious happens). > See also https://wiki.sagemath.org/Python3-compatible%20code > > Vincent > > -- > 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 to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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 list > > of pairs is a very wrong approach (though this is what is done for > > years). Indeed, a list is not only an iterator, but also a > > container. In > > particular: > > > > (a,b) in G.edges() > > > > is a syntaxially correct statement, but it is far from equivalent to: > > > > G.has_edge(a,b) > > > > Which is extremely misleading and can lead to silent mistakes > > (personally, i used lot of hand-made reorderings in my pyograms > > before i > > discovered has_edge). > > > > Here i would advocate that G.edges() returns a *view* on G, with a > > dedicated __iter__ method corresponding to the edge_iterator method and > > a __contains__ method corresponding to the has_edge method. By having a > > view, you will save a lot of time and memory, and have the benefit that > > it will follow the graph's mutations. > > > > > > This is an interesting idea, although I'm not sure how to implement that > > efficiently. > > I don't see why it should be inefficient (assuming you implement it in > Cython of course). Actually, a view is somehow pointing to an existing object, so it is O(1), to be compared to contstructing a list which is O(|E|). Ciao, Thierry -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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
> 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
> to update a very large number of algorithms. We could also design
a method
> to compare object of different types.
> In fact, the main issue is that we use and compare vertices by id
instead
> of mapping vertices to integer and work only with these integers.
That
> would ease our life, but it's not easy to change that.
We discussed the difference between mathematical and algorithmic level
various times (for equality, comparison, etc).
Here, at the "algorithmic" level, the vertices are of course
comparable,
and most algorithms in graph theory rely on this (starting by the most
fundamental such as DFS, BFS, etc). Trying to avoid comparison of
vertices would be suicidary, and trying to do that with Sage will just
lead to unreadable artificially complicated code.
If you want an integer label for each vertex, why not just ask to the
backend:
sage: G = graphs.WorldMap()
sage: G
World Map: Graph on 251 vertices
sage: G.vertices()[0]
'Afghanistan'
sage: GG = G._backend.c_graph()[0]
sage: GG
sage: GG.verts()[0]
0
So, somehow, you do not have to map Sage objects back to integers,
since
we already have a map from integers to Sage objects.
I did not check the implementations, but though it is kind of too late
given the size of Sage, i would advocate to have two explicit layers
for
combinatorial objects such as words, graphs, permutations, etc, one
"algorithmic" where the atoms are integers, with all the good
properties, and a "label" dictionary, where we could attach any Sage
object to them for "mathematical" questions. And it would be amazing if
they were an specified way to do that uniformly.
In fact we already have methods to do that, but changing the code to use
these methods is not an easy task...
sage: G = graphs.PetersenGraph()
sage: G.set_vertex(0, 'abc')
sage: G.set_vertex(1, graphs.CycleGraph(3))
sage: print(G.get_vertices())
{0: 'abc', 1: Cycle graph: Graph on 3 vertices, 2: None, 3: None, 4:
None, 5: None, 6: None, 7: None, 8: None, 9: None}
That said, regarding the .edges() method, i think that returning a list
of pairs is a very wrong approach (though this is what is done for
years). Indeed, a list is not only an iterator, but also a
container. In
particular:
(a,b) in G.edges()
is a syntaxially correct statement, but it is far from equivalent to:
G.has_edge(a,b)
Which is extremely misleading and can lead to silent mistakes
(personally, i used lot of hand-made reorderings in my pyograms
before i
discovered has_edge).
Here i would advocate that G.edges() returns a *view* on G, with a
dedicated __iter__ method corresponding to the edge_iterator method and
a __contains__ method corresponding to the has_edge method. By having a
view, you will save a lot of time and memory, and have the benefit that
it will follow the graph's mutations.
This is an interesting idea, although I'm not sure how to implement that
efficiently.
I don't see why it should be inefficient (assuming you implement it in
Cython of course).
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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 no solution for this
> > issue. We can decide to stop ordering the vertices, but then we will
> have
> > to update a very large number of algorithms. We could also design a
> method
> > to compare object of different types.
> > In fact, the main issue is that we use and compare vertices by id
> instead
> > of mapping vertices to integer and work only with these integers. That
> > would ease our life, but it's not easy to change that.
>
> We discussed the difference between mathematical and algorithmic level
> various times (for equality, comparison, etc).
>
> Here, at the "algorithmic" level, the vertices are of course comparable,
> and most algorithms in graph theory rely on this (starting by the most
> fundamental such as DFS, BFS, etc). Trying to avoid comparison of
> vertices would be suicidary, and trying to do that with Sage will just
> lead to unreadable artificially complicated code.
>
> If you want an integer label for each vertex, why not just ask to the
> backend:
>
> sage: G = graphs.WorldMap()
> sage: G
> World Map: Graph on 251 vertices
> sage: G.vertices()[0]
> 'Afghanistan'
>
> sage: GG = G._backend.c_graph()[0]
> sage: GG
>
> sage: GG.verts()[0]
> 0
>
> So, somehow, you do not have to map Sage objects back to integers, since
> we already have a map from integers to Sage objects.
>
> I did not check the implementations, but though it is kind of too late
> given the size of Sage, i would advocate to have two explicit layers for
> combinatorial objects such as words, graphs, permutations, etc, one
> "algorithmic" where the atoms are integers, with all the good
> properties, and a "label" dictionary, where we could attach any Sage
> object to them for "mathematical" questions. And it would be amazing if
> they were an specified way to do that uniformly.
>
In fact we already have methods to do that, but changing the code to use
these methods is not an easy task...
sage: G = graphs.PetersenGraph()
sage: G.set_vertex(0, 'abc')
sage: G.set_vertex(1, graphs.CycleGraph(3))
sage: print(G.get_vertices())
{0: 'abc', 1: Cycle graph: Graph on 3 vertices, 2: None, 3: None, 4: None,
5: None, 6: None, 7: None, 8: None, 9: None}
That said, regarding the .edges() method, i think that returning a list
> of pairs is a very wrong approach (though this is what is done for
> years). Indeed, a list is not only an iterator, but also a container. In
> particular:
>
> (a,b) in G.edges()
>
> is a syntaxially correct statement, but it is far from equivalent to:
>
> G.has_edge(a,b)
>
> Which is extremely misleading and can lead to silent mistakes
> (personally, i used lot of hand-made reorderings in my pyograms before i
> discovered has_edge).
>
> Here i would advocate that G.edges() returns a *view* on G, with a
> dedicated __iter__ method corresponding to the edge_iterator method and
> a __contains__ method corresponding to the has_edge method. By having a
> view, you will save a lot of time and memory, and have the benefit that
> it will follow the graph's mutations.
>
>
This is an interesting idea, although I'm not sure how to implement that
efficiently.
David.
PS: when all currently in "needs review" tickets will be closed, the number
of py3 failing doctests in the graph module will be small (HELP welcome
here to review tickets and fix remaining doctests). It will then become
easier to see the effect of changes like not sorting end vertices of edges
(we could try that), implement a *view* on G, etc.
--
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 to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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 > to update a very large number of algorithms. We could also design a method > to compare object of different types. > In fact, the main issue is that we use and compare vertices by id instead > of mapping vertices to integer and work only with these integers. That > would ease our life, but it's not easy to change that. We discussed the difference between mathematical and algorithmic level various times (for equality, comparison, etc). Here, at the "algorithmic" level, the vertices are of course comparable, and most algorithms in graph theory rely on this (starting by the most fundamental such as DFS, BFS, etc). Trying to avoid comparison of vertices would be suicidary, and trying to do that with Sage will just lead to unreadable artificially complicated code. If you want an integer label for each vertex, why not just ask to the backend: sage: G = graphs.WorldMap() sage: G World Map: Graph on 251 vertices sage: G.vertices()[0] 'Afghanistan' sage: GG = G._backend.c_graph()[0] sage: GG sage: GG.verts()[0] 0 So, somehow, you do not have to map Sage objects back to integers, since we already have a map from integers to Sage objects. I did not check the implementations, but though it is kind of too late given the size of Sage, i would advocate to have two explicit layers for combinatorial objects such as words, graphs, permutations, etc, one "algorithmic" where the atoms are integers, with all the good properties, and a "label" dictionary, where we could attach any Sage object to them for "mathematical" questions. And it would be amazing if they were an specified way to do that uniformly. That said, regarding the .edges() method, i think that returning a list of pairs is a very wrong approach (though this is what is done for years). Indeed, a list is not only an iterator, but also a container. In particular: (a,b) in G.edges() is a syntaxially correct statement, but it is far from equivalent to: G.has_edge(a,b) Which is extremely misleading and can lead to silent mistakes (personally, i used lot of hand-made reorderings in my pyograms before i discovered has_edge). Here i would advocate that G.edges() returns a *view* on G, with a dedicated __iter__ method corresponding to the edge_iterator method and a __contains__ method corresponding to the has_edge method. By having a view, you will save a lot of time and memory, and have the benefit that it will follow the graph's mutations. Ciao, Thierry > David. > > -- > 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 to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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 new > installation, and to "git pull" again (pulling develop from my old > installation, but NOT directly from trac). I use `git worktree` a lot and might be helpful for you as well -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 to you Frédéric, and the small team who got involved, > for your efforts on getting Sage Python 3 ready. > A big +1 ! I have been using the > Python 3 version exclusively for a while now and enjoying it a lot. > +1 As a side note, let me point that the manifold examples posted at https://sagemanifolds.obspm.fr/examples.html work like a charm with Python 3 (I've tested a selected sample and they all work, including those involving SymPy, without any modification). > I would also encourage all developers (and users) to use their `init.sage` > to help use Python3 habits even whey working with Python2-based Sage. > > Here is my `init.sage`, suggestions welcome: > > > https://github.com/slel/sagemath-tips/blob/master/init-dot-sage/init.sage > > In particular it forces me to always use Python3-style print! > Thanks for sharing. Eric. -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 doctests, and a total of 866 failing doctests. > Among those, 74 files have 1 failing doctest. > > (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 doctests. But good progress was made by David Coudert, > > (4) then, various small issues, such as sorting sets and dictionaries, > etc. Some good python3 changes are blocked by the long awaited ticket > https://trac.sagemath.org/ticket/23572 > > STATEMENT: I would to advocate that *every developer switch to python3 NOW*. > > This will help to prevent regressions, as the one that happened recently > in elliptic curves. This will also motivate people to fix the part of the > code base that they use and that still fails. > > Please vote! Strong +1 from me. Many, many thanks to you Frédéric, and the small team who got involved, for your efforts on getting Sage Python 3 ready. I have been using the Python 3 version exclusively for a while now and enjoying it a lot. I would also encourage all developers (and users) to use their `init.sage` to help use Python3 habits even whey working with Python2-based Sage. Here is my `init.sage`, suggestions welcome: https://github.com/slel/sagemath-tips/blob/master/init-dot-sage/init.sage In particular it forces me to always use Python3-style print! -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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 also have to have a working > installation of my group cohomology spkg. Although I do think Frédéric is jumping the gun *slightly*, he did explicitly write "every developer switch to Python 3", which I took to mean, use `./configure --with-python=3` in any Sage you use for development of Sage itself. If you are both developing Sage and using Sage for teaching you should have separate installations anyways. You should be using a stable version for teaching and research (unless actively doing development for said research). -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 Thank you for the pointer! Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 about pickling, where PyBytes probably still is the way to go. 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_...? Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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')) works. In py3 it doesn't, since os.path.join returns str not bytes. 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_... """ So, I guess for Python 3 compatibility, I need to revert the change and return to PyString_..., as os.path.join returns str. Cheers, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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_dense, I get a TypeError: expected bytes, str found. 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... Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
> 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 that. Another source of problems is that the order of keys of dictionary, i.e., list(mydict.keys()) or list(myset), might be different in py2 and py3. This breaks many doctests, but may be more complicated, it changes the order in which the neighbors of a vertex are visited (check G._backend.iterator_nbrs??). Consequently, the returned solution of some algorithms might be differents (but still correct). A solution is to tag doctests with py2 and py3. 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 to update a very large number of algorithms. We could also design a method to compare object of different types. In fact, the main issue is that we use and compare vertices by id instead of mapping vertices to integer and work only with these integers. That would ease our life, but it's not easy to change that. David. -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 and ~/Sage/git/py3/local are not the same probably means that no recompilation will be needed. Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 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 different > directories. From your main repo do this: > > $ git worktree add /path/to/the/new/checkout branch-to-checkout > > You'll keep your python2 checkout and the new directory will be part of > the same repo. That means that remotes are set up as before and you have > access to the same branches. You can also create a new branch and > immediately create a worktree for that: > > $ git worktree add -b my-feature-branch /path/to/the/new/checkout > branch-to-checkout > > > -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 Thank you! I am trying this, also having a symlink to the original worktree's "upstream" directory. Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 different directories. From your main repo do this: $ git worktree add /path/to/the/new/checkout branch-to-checkout You'll keep your python2 checkout and the new directory will be part of the same repo. That means that remotes are set up as before and you have access to the same branches. You can also create a new branch and immediately create a worktree for that: $ git worktree add -b my-feature-branch /path/to/the/new/checkout branch-to-checkout -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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" should be your local repo. Correct! king@klap:~/Sage/py3/sage$ git remote -v origin /home/king/Sage/py3/../git/sage (fetch) origin /home/king/Sage/py3/../git/sage (push) tracg...@trac.sagemath.org:sage.git (fetch) trac g...@trac.sagemath.org:sage.git (push) $ git branch --set-upstream-to trac/develop king@klap:~/Sage/py3/sage$ git branch * develop t/13447/make_libsingular_multivariate_polynomial_rings_collectable So, indeed we are talking about "develop", but: king@klap:~/Sage/py3/sage$ git branch --set-upstream-to trac/develop error: the requested upstream branch 'trac/develop' does not exist hint: hint: If you are planning on basing your work on an upstream hint: branch that already exists at the remote, you may need to hint: run "git fetch" to retrieve it. hint: hint: If you are planning to push out a new local branch that hint: will track its remote counterpart, you may want to use hint: "git push -u" to set the upstream config as you push. git has no clue what is on trac (of course) but apparently does not want to find out automatically. Do $ git fetch trac develop so that it knows. And then $ git branch --set-upstream-to trac/develop (I tried and it worked). Though "git pull" is not a so good idea since that would pull *all* branches from trac. You would better run $ git pull trac develop Vincent -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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! king@klap:~/Sage/py3/sage$ git remote -v origin /home/king/Sage/py3/../git/sage (fetch) origin /home/king/Sage/py3/../git/sage (push) tracg...@trac.sagemath.org:sage.git (fetch) tracg...@trac.sagemath.org:sage.git (push) >$ git branch --set-upstream-to trac/develop king@klap:~/Sage/py3/sage$ git branch * develop t/13447/make_libsingular_multivariate_polynomial_rings_collectable So, indeed we are talking about "develop", but: king@klap:~/Sage/py3/sage$ git branch --set-upstream-to trac/develop error: the requested upstream branch 'trac/develop' does not exist hint: hint: If you are planning on basing your work on an upstream hint: branch that already exists at the remote, you may need to hint: run "git fetch" to retrieve it. hint: hint: If you are planning to push out a new local branch that hint: will track its remote counterpart, you may want to use hint: "git push -u" to set the upstream config as you push. So, still something is wrong. Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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 without reading tons of documentation. After $ git clone sage-original sage-py3 The default remote in sage-py3 will be the sage-original local folder. First step, add the remote for trac (sage-py3) $ git remote add trac g...@trac.sagemath.org:sage.git Second step set trac to be the default upstream (sage-py3) $ git branch --set-upstream-to trac Doesn't work for me. My bad. 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. king@klap:~/Sage/py3/sage$ git branch --set-upstream-to trac This was an erroneous command. It is $ git branch --set-upstream-to trac/develop (or trac/mater if you cloned the master branch) Note that this will only take care of the current branch (develop). Vincent -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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: > 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 Vincent Delecroix <20100.delecr...@gmail.com > > wrote: > > > >> > >> > >> 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. 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 new > >>> installation, and to "git pull" again (pulling develop from my old > >>> installation, but NOT directly from trac). > >> > >> This has nothing to do with python 3. You only need to set up > >> properly your remote and branches. > >> > >> After > >> > >> $ git clone sage-original sage-py3 > >> > >> The default remote in sage-py3 will be the sage-original local > >> folder. First step, add the remote for trac > >> > >>(sage-py3) $ git remote add trac g...@trac.sagemath.org:sage.git > >> > >> Second step set trac to be the default upstream > >> > >>(sage-py3) $ git branch --set-upstream-to trac > >> > >> For all this, the best is to read the git documentation. > >> > >> Vincent > >> > >> PS: the Frederic version is less trouble but more bandwidth! > >> > >> -- > >> 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 to sage-devel@googlegroups.com. > >> Visit this group at https://groups.google.com/group/sage-devel. > >> For more options, visit https://groups.google.com/d/optout. > >> > > > > -- > 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 to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 > >$ git clone sage-original sage-py3 > > The default remote in sage-py3 will be the sage-original local > folder. First step, add the remote for trac > > (sage-py3) $ git remote add trac g...@trac.sagemath.org:sage.git > > Second step set trac to be the default upstream > > (sage-py3) $ git branch --set-upstream-to trac Doesn't work for me. king@klap:~/Sage/py3/sage$ git remote add trac g...@trac.sagemath.org:sage.git king@klap:~/Sage/py3/sage$ git branch --set-upstream-to trac error: the requested upstream branch 'trac' does not exist hint: hint: If you are planning on basing your work on an upstream hint: branch that already exists at the remote, you may need to hint: run "git fetch" to retrieve it. hint: hint: If you are planning to push out a new local branch that hint: will track its remote counterpart, you may want to use hint: "git push -u" to set the upstream config as you push. > PS: the Frederic version is less trouble but more bandwidth! Exactly. I thought a local copy would be both faster and easier to obtain. Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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 Vincent Delecroix <20100.delecr...@gmail.com wrote: 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. 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 new installation, and to "git pull" again (pulling develop from my old installation, but NOT directly from trac). This has nothing to do with python 3. You only need to set up properly your remote and branches. After $ git clone sage-original sage-py3 The default remote in sage-py3 will be the sage-original local folder. First step, add the remote for trac (sage-py3) $ git remote add trac g...@trac.sagemath.org:sage.git Second step set trac to be the default upstream (sage-py3) $ git branch --set-upstream-to trac For all this, the best is to read the git documentation. Vincent PS: the Frederic version is less trouble but more bandwidth! -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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, > > > > 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" would mean that I need to go to my old > > installation, "git pull" (pulls develop from trac), go to the new > > installation, and to "git pull" again (pulling develop from my old > > installation, but NOT directly from trac). > > This has nothing to do with python 3. You only need to set up > properly your remote and branches. > > After > >$ git clone sage-original sage-py3 > > The default remote in sage-py3 will be the sage-original local > folder. First step, add the remote for trac > > (sage-py3) $ git remote add trac g...@trac.sagemath.org:sage.git > > Second step set trac to be the default upstream > > (sage-py3) $ git branch --set-upstream-to trac > > For all this, the best is to read the git documentation. > > Vincent > > PS: the Frederic version is less trouble but more bandwidth! > > -- > 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 to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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? Vincent Le 27/01/2019 à 14:56, Frédéric Chapoton a écrit : 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 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 new installation, and to "git pull" again (pulling develop from my old installation, but NOT directly from trac). That's awkward and could certainly be done better. In that clone, do $ make configure $ ./configure --with-python=3 Thank you! Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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. 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 new installation, and to "git pull" again (pulling develop from my old installation, but NOT directly from trac). This has nothing to do with python 3. You only need to set up properly your remote and branches. After $ git clone sage-original sage-py3 The default remote in sage-py3 will be the sage-original local folder. First step, add the remote for trac (sage-py3) $ git remote add trac g...@trac.sagemath.org:sage.git Second step set trac to be the default upstream (sage-py3) $ git branch --set-upstream-to trac For all this, the best is to read the git documentation. Vincent PS: the Frederic version is less trouble but more bandwidth! -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 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 new > installation, and to "git pull" again (pulling develop from my old > installation, but NOT directly from trac). > > That's awkward and could certainly be done better. > > >In that > > clone, do > > > > $ make configure > > $ ./configure --with-python=3 > > Thank you! > > Best regards, > Simon > > -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 spkg. So far, there is no way for me to be sure that python3 would work for me. Also, there is a high probability that I need to refactor my group cohomology spkg so that it works in python3. So, FOR NOW, I won't immediately drop python2. Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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" would mean that I need to go to my old installation, "git pull" (pulls develop from trac), go to the new installation, and to "git pull" again (pulling develop from my old installation, but NOT directly from trac). That's awkward and could certainly be done better. >In that > clone, do > > $ make configure > $ ./configure --with-python=3 Thank you! Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
> > > > *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, given my existing Sage > installation, what would be the easiest way to create a second > installation with python 3 that is automatically configured to work > well with "git trac"? I guess it is some kind of git clone. Also I > don't know what make target is needed. > > How to build sage with python3: first "git clone" into another dir, say "sage3" then inside this dir: make configure ./configure --with-python=3 make build The first two lines need only be used once and for all. concerning the tests, there is currently a partial test target that ensure that thing know to pass still pass if you want to run all tests, then all course, you will meet failures in some parts of sage -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: python3 status report
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, where generic_graph.py has 50 failing doctests. But good progress was made by David Coudert, 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)? *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. So, given my existing Sage installation, what would be the easiest way to create a second installation with python 3 that is automatically configured to work well with "git trac"? I guess it is some kind of git clone. Also I don't know what make target is needed. You need a different clone of your git repo, let say sage-py3. In that clone, do $ make configure $ ./configure --with-python=3 Then, unless you rerun configure, every call to make will take care of the Python 3 switch automatically. See also https://wiki.sagemath.org/Python3-compatible%20code Vincent -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 doctests. But good progress was made by David Coudert, 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)? > *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. So, given my existing Sage installation, what would be the easiest way to create a second installation with python 3 that is automatically configured to work well with "git trac"? I guess it is some kind of git clone. Also I don't know what make target is needed. Best regards, Simon -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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? "make distclean" followed by "./configure > --with-python=3" and then "make" works for me. > I followed exactly the same steps, but somehow sage building failed somewhere in middle. I don't remember exactly what failed. I think we should recommend building from new clone... > > -- > John > > -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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. -- John -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
> > 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+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 is a good point: Python 2 and Python 3 builds cannot really coexist within the same Sage installation: you need separate installations for each. (Or run 'make distclean' before switching Python versions.) -- John -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
> > 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" 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 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... >> > -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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... > -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 the folders where all doctests are known to pass. I maintain such a list in the ticket #26212 (and I just had to remove the folder '"manifolds", where some doctests were broken in the latest release). Le samedi 27 octobre 2018 20:15:47 UTC+2, Volker Braun a écrit : > > 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 known failures. Any > thoughts on that one? > > > -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: python3 status report
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 known failures. Any thoughts on that one? -- 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 to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
