[sage-devel] Re: python3-3.9.2 failed to build while running 'sage -i pynormaliz' (ModuleNotFoundError: No module named 'binascii')

[Matthias Koeppe]

There's now a proposed solution in the branch of 
https://trac.sagemath.org/ticket/32056, needs review

On Thursday, June 24, 2021 at 10:59:26 AM UTC-7 Matthias Koeppe wrote:

> I have opened https://trac.sagemath.org/ticket/32056 for the mysterious 
> issue with 'binascii'.
>
>
> On Thursday, June 24, 2021 at 9:46:36 AM UTC-7 marc@gmail.com wrote:
>
>> I am seeing the same error with Python 3.9.5 when I attempt to build Sage 
>> 9.4.beta3 from source on macOS 11.4.  The build fails when it attempts to 
>> import distutils, which depends on the binascii module.  Searching through 
>> the python build directory with find indicates that binascii.o does not 
>> get built.  If I run make in the python build directory using my normal 
>> environment then binascii.o is built, as is the extension module 
>> binascii.cpython-39-darwin.so, and the python build succeeds.  But If I 
>> run make in a sage-buildsh subshell then binascii.o does not get built and 
>> the make command fails in the same way as with the build of sage.  So 
>> evidently something in the sage build environment is preventing python from 
>> compiling its binascii module.
>>
>> I am attaching the log file.
>>
>> - Marc
>>
>> On Friday, June 18, 2021 at 3:09:58 PM UTC-5 max...@gmail.com wrote:
>>
>>> Hi!
>>>
>>> I'm trying to install PyNormaliz within freshly installed Sage 9.3 
>>> within freshly installed Ubuntu 20.04.02 LTS.It breaks giving the following 
>>> error:
>>>
>>> ===
>>> LD_LIBRARY_PATH=/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src
>>>  
>>> CC='gcc -pthread' LDSHARED='gcc -pthread -shared 
>>> -Wl,-rpath-link,/usr/local/SageMath.93/local/lib 
>>> -L/usr/local/SageMath.93/local/lib 
>>> -Wl,-rpath,/usr/local/SageMath.93/local/lib  -L. 
>>> -Wl,-rpath-link,/usr/local/SageMath.93/local/lib 
>>> -L/usr/local/SageMath.93/local/lib 
>>> -Wl,-rpath,/usr/local/SageMath.93/local/lib   ' OPT='-DNDEBUG -g -fwrapv 
>>> -O3 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS=''   ./python -E 
>>> ./setup.py  build
>>> Traceback (most recent call last):
>>>   File 
>>> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/./setup.py",
>>>  
>>> line 33, in 
>>> from distutils import log
>>>   File 
>>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/_distutils_hack/__init__.py",
>>>  
>>> line 83, in create_module
>>> return importlib.import_module('setuptools._distutils')
>>>   File 
>>> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/Lib/importlib/__init__.py",
>>>  
>>> line 127, in import_module
>>> return _bootstrap._gcd_import(name[level:], package, level)
>>>   File 
>>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/setuptools/__init__.py",
>>>  
>>> line 16, in 
>>> import setuptools.version
>>>   File 
>>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/setuptools/version.py",
>>>  
>>> line 1, in 
>>> import pkg_resources
>>>   File 
>>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/pkg_resources/__init__.py",
>>>  
>>> line 23, in 
>>> import zipfile
>>>   File 
>>> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/Lib/zipfile.py",
>>>  
>>> line 6, in 
>>> import binascii
>>> ModuleNotFoundError: No module named 'binascii'
>>> make[3]: *** [Makefile:638: sharedmods] Error 1
>>>
>>> 
>>> Error building python3-3.9.2
>>>
>>> 
>>> ===
>>>
>>> A full log is attached.
>>>
>>> Please advise.
>>>
>>> Thanks,
>>> Max
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0e692e6f-6ec0-4508-95fb-de96bb75f6efn%40googlegroups.com.

Re: [sage-devel] Re: python3-3.9.2 failed to build while running 'sage -i pynormaliz' (ModuleNotFoundError: No module named 'binascii')

[Dima Pasechnik]

On Thu, Jun 24, 2021 at 6:56 PM Marc Culler  wrote:
>
> On Thu, Jun 24, 2021 at 11:50 AM Dima Pasechnik  wrote:
> >
> > There is no need to build Python, you can either use one from Homebrew
> > or from the official Python distribution.
> >
>
> That is an extremely unhelpful answer, especially given what I am
> trying to do.  It is also ridiculous.  If people are following the
> build instructions in the README file and the build is failing then
> the build is broken and it should be fixed.

We have 10 people per day asking what to do with broken Python build, you know,
it is tiring...
Please see
https://doc.sagemath.org/html/en/installation/source.html#linux-recommended-installation

>
> Fortunately, I was able to solve my problem in spite of this unhelpful
> help.  The build is not broken.  But the instructions in the README
> file are incomplete.  The answer which would have helped me is this:
>
> "If you switch branches in the git repository then you need to run
> make distclean before rebuilding sage."
>
> And that really should be added to the README file.
>
> - Marc
>
> PS If you are going to tell people that they do not have to build
> python to build sage then you should also provide instructions for how
> to build sage without building python.

Please see
https://doc.sagemath.org/html/en/installation/source.html#linux-recommended-installation
as well as read the last half a page of the output of ./configure


>
> >
> > > The build fails when it attempts to import distutils, which depends on 
> > > the binascii module.  Searching through the python build directory with 
> > > find indicates that binascii.o does not get built.  If I run make in the 
> > > python build directory using my normal environment then binascii.o is 
> > > built, as is the extension module binascii.cpython-39-darwin.so, and the 
> > > python build succeeds.  But If I run make in a sage-buildsh subshell then 
> > > binascii.o does not get built and the make command fails in the same way 
> > > as with the build of sage.  So evidently something in the sage build 
> > > environment is preventing python from compiling its binascii module.
> > >
> > > I am attaching the log file.
> > >
> > > - Marc
> > >
> > > On Friday, June 18, 2021 at 3:09:58 PM UTC-5 max...@gmail.com wrote:
> > >>
> > >> Hi!
> > >>
> > >> I'm trying to install PyNormaliz within freshly installed Sage 9.3 
> > >> within freshly installed Ubuntu 20.04.02 LTS.It breaks giving the 
> > >> following error:
> > >>
> > >> ===
> > >> LD_LIBRARY_PATH=/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src
> > >>  CC='gcc -pthread' LDSHARED='gcc -pthread -shared 
> > >> -Wl,-rpath-link,/usr/local/SageMath.93/local/lib 
> > >> -L/usr/local/SageMath.93/local/lib 
> > >> -Wl,-rpath,/usr/local/SageMath.93/local/lib  -L. 
> > >> -Wl,-rpath-link,/usr/local/SageMath.93/local/lib 
> > >> -L/usr/local/SageMath.93/local/lib 
> > >> -Wl,-rpath,/usr/local/SageMath.93/local/lib   ' OPT='-DNDEBUG -g -fwrapv 
> > >> -O3 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS=''   ./python -E 
> > >> ./setup.py  build
> > >> Traceback (most recent call last):
> > >>   File 
> > >> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/./setup.py",
> > >>  line 33, in 
> > >> from distutils import log
> > >>   File 
> > >> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/_distutils_hack/__init__.py",
> > >>  line 83, in create_module
> > >> return importlib.import_module('setuptools._distutils')
> > >>   File 
> > >> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/Lib/importlib/__init__.py",
> > >>  line 127, in import_module
> > >> return _bootstrap._gcd_import(name[level:], package, level)
> > >>   File 
> > >> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/setuptools/__init__.py",
> > >>  line 16, in 
> > >> import setuptools.version
> > >>   File 
> > >> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/setuptools/version.py",
> > >>  line 1, in 
> > >> import pkg_resources
> > >>   File 
> > >> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/pkg_resources/__init__.py",
> > >>  line 23, in 
> > >> import zipfile
> > >>   File 
> > >> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/Lib/zipfile.py",
> > >>  line 6, in 
> > >> import binascii
> > >> ModuleNotFoundError: No module named 'binascii'
> > >> make[3]: *** [Makefile:638: sharedmods] Error 1
> > >> 
> > >> Error building python3-3.9.2
> > >> 
> > >> ===
> > >>
> > >> A full log is attached.
> > >>
> > >> Please advise.
> > >>
> > >> Thanks,
> > >> Max
> > >
> > > --
> > > 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 

Re: [sage-devel] Re: python3-3.9.2 failed to build while running 'sage -i pynormaliz' (ModuleNotFoundError: No module named 'binascii')

[Matthias Koeppe]

On Thursday, June 24, 2021 at 10:56:37 AM UTC-7 marc@gmail.com wrote:

> If people are following the 
> build instructions in the README file and the build is failing then 
> the build is broken and it should be fixed. 
>
>
I agree 
 

> [...] The answer which would have helped me is this: 
>
> "If you switch branches in the git repository then you need to run 
> make distclean before rebuilding sage."
>

I agree that we need to give better instructions for incremental builds. 
There are long-standing issues in our build system, tracked in  
https://trac.sagemath.org/ticket/29708 and 
https://trac.sagemath.org/ticket/31277, that make a "make distclean" 
necesssary.


If "make distclean" helped resolve the issue with "binascii" and the 
python3 spkg was afterwards successfully built, it suggests that the 
python3 installation picks up site packages from the previous installation 
in SAGE_LOCAL. This is a very specific problem that should definitely be 
fixed separately from the above build system issues.



 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/16118383-be13-4cf7-b5ed-b5b3cce17921n%40googlegroups.com.

[sage-devel] Re: python3-3.9.2 failed to build while running 'sage -i pynormaliz' (ModuleNotFoundError: No module named 'binascii')

[Matthias Koeppe]

I have opened https://trac.sagemath.org/ticket/32056 for the mysterious 
issue with 'binascii'.


On Thursday, June 24, 2021 at 9:46:36 AM UTC-7 marc@gmail.com wrote:

> I am seeing the same error with Python 3.9.5 when I attempt to build Sage 
> 9.4.beta3 from source on macOS 11.4.  The build fails when it attempts to 
> import distutils, which depends on the binascii module.  Searching through 
> the python build directory with find indicates that binascii.o does not 
> get built.  If I run make in the python build directory using my normal 
> environment then binascii.o is built, as is the extension module 
> binascii.cpython-39-darwin.so, and the python build succeeds.  But If I 
> run make in a sage-buildsh subshell then binascii.o does not get built and 
> the make command fails in the same way as with the build of sage.  So 
> evidently something in the sage build environment is preventing python from 
> compiling its binascii module.
>
> I am attaching the log file.
>
> - Marc
>
> On Friday, June 18, 2021 at 3:09:58 PM UTC-5 max...@gmail.com wrote:
>
>> Hi!
>>
>> I'm trying to install PyNormaliz within freshly installed Sage 9.3 within 
>> freshly installed Ubuntu 20.04.02 LTS.It breaks giving the following error:
>>
>> ===
>> LD_LIBRARY_PATH=/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src
>>  
>> CC='gcc -pthread' LDSHARED='gcc -pthread -shared 
>> -Wl,-rpath-link,/usr/local/SageMath.93/local/lib 
>> -L/usr/local/SageMath.93/local/lib 
>> -Wl,-rpath,/usr/local/SageMath.93/local/lib  -L. 
>> -Wl,-rpath-link,/usr/local/SageMath.93/local/lib 
>> -L/usr/local/SageMath.93/local/lib 
>> -Wl,-rpath,/usr/local/SageMath.93/local/lib   ' OPT='-DNDEBUG -g -fwrapv 
>> -O3 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS=''   ./python -E 
>> ./setup.py  build
>> Traceback (most recent call last):
>>   File 
>> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/./setup.py",
>>  
>> line 33, in 
>> from distutils import log
>>   File 
>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/_distutils_hack/__init__.py",
>>  
>> line 83, in create_module
>> return importlib.import_module('setuptools._distutils')
>>   File 
>> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/Lib/importlib/__init__.py",
>>  
>> line 127, in import_module
>> return _bootstrap._gcd_import(name[level:], package, level)
>>   File 
>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/setuptools/__init__.py",
>>  
>> line 16, in 
>> import setuptools.version
>>   File 
>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/setuptools/version.py",
>>  
>> line 1, in 
>> import pkg_resources
>>   File 
>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/pkg_resources/__init__.py",
>>  
>> line 23, in 
>> import zipfile
>>   File 
>> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/Lib/zipfile.py",
>>  
>> line 6, in 
>> import binascii
>> ModuleNotFoundError: No module named 'binascii'
>> make[3]: *** [Makefile:638: sharedmods] Error 1
>>
>> 
>> Error building python3-3.9.2
>>
>> 
>> ===
>>
>> A full log is attached.
>>
>> Please advise.
>>
>> Thanks,
>> Max
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0fc51e5c-d7cb-422a-a1fd-73660c41fb74n%40googlegroups.com.

Re: [sage-devel] Re: python3-3.9.2 failed to build while running 'sage -i pynormaliz' (ModuleNotFoundError: No module named 'binascii')

[Marc Culler]

On Thu, Jun 24, 2021 at 11:50 AM Dima Pasechnik  wrote:
>
> There is no need to build Python, you can either use one from Homebrew
> or from the official Python distribution.
>

That is an extremely unhelpful answer, especially given what I am
trying to do.  It is also ridiculous.  If people are following the
build instructions in the README file and the build is failing then
the build is broken and it should be fixed.

Fortunately, I was able to solve my problem in spite of this unhelpful
help.  The build is not broken.  But the instructions in the README
file are incomplete.  The answer which would have helped me is this:

"If you switch branches in the git repository then you need to run
make distclean before rebuilding sage."

And that really should be added to the README file.

- Marc

PS If you are going to tell people that they do not have to build
python to build sage then you should also provide instructions for how
to build sage without building python.

>
> > The build fails when it attempts to import distutils, which depends on the 
> > binascii module.  Searching through the python build directory with find 
> > indicates that binascii.o does not get built.  If I run make in the python 
> > build directory using my normal environment then binascii.o is built, as is 
> > the extension module binascii.cpython-39-darwin.so, and the python build 
> > succeeds.  But If I run make in a sage-buildsh subshell then binascii.o 
> > does not get built and the make command fails in the same way as with the 
> > build of sage.  So evidently something in the sage build environment is 
> > preventing python from compiling its binascii module.
> >
> > I am attaching the log file.
> >
> > - Marc
> >
> > On Friday, June 18, 2021 at 3:09:58 PM UTC-5 max...@gmail.com wrote:
> >>
> >> Hi!
> >>
> >> I'm trying to install PyNormaliz within freshly installed Sage 9.3 within 
> >> freshly installed Ubuntu 20.04.02 LTS.It breaks giving the following error:
> >>
> >> ===
> >> LD_LIBRARY_PATH=/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src
> >>  CC='gcc -pthread' LDSHARED='gcc -pthread -shared 
> >> -Wl,-rpath-link,/usr/local/SageMath.93/local/lib 
> >> -L/usr/local/SageMath.93/local/lib 
> >> -Wl,-rpath,/usr/local/SageMath.93/local/lib  -L. 
> >> -Wl,-rpath-link,/usr/local/SageMath.93/local/lib 
> >> -L/usr/local/SageMath.93/local/lib 
> >> -Wl,-rpath,/usr/local/SageMath.93/local/lib   ' OPT='-DNDEBUG -g -fwrapv 
> >> -O3 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS=''   ./python -E 
> >> ./setup.py  build
> >> Traceback (most recent call last):
> >>   File 
> >> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/./setup.py",
> >>  line 33, in 
> >> from distutils import log
> >>   File 
> >> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/_distutils_hack/__init__.py",
> >>  line 83, in create_module
> >> return importlib.import_module('setuptools._distutils')
> >>   File 
> >> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/Lib/importlib/__init__.py",
> >>  line 127, in import_module
> >> return _bootstrap._gcd_import(name[level:], package, level)
> >>   File 
> >> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/setuptools/__init__.py",
> >>  line 16, in 
> >> import setuptools.version
> >>   File 
> >> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/setuptools/version.py",
> >>  line 1, in 
> >> import pkg_resources
> >>   File 
> >> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/pkg_resources/__init__.py",
> >>  line 23, in 
> >> import zipfile
> >>   File 
> >> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/Lib/zipfile.py",
> >>  line 6, in 
> >> import binascii
> >> ModuleNotFoundError: No module named 'binascii'
> >> make[3]: *** [Makefile:638: sharedmods] Error 1
> >> 
> >> Error building python3-3.9.2
> >> 
> >> ===
> >>
> >> A full log is attached.
> >>
> >> Please advise.
> >>
> >> Thanks,
> >> Max
> >
> > --
> > 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/sage-devel/f53afd48-abd2-440b-a996-f9950e16ad58n%40googlegroups.com.
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "sage-devel" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/sage-devel/euE9MJnfjAo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> 

Re: [sage-devel] Re: python3-3.9.2 failed to build while running 'sage -i pynormaliz' (ModuleNotFoundError: No module named 'binascii')

[Dima Pasechnik]

On Thu, Jun 24, 2021 at 5:46 PM Marc Culler  wrote:
>
> I am seeing the same error with Python 3.9.5 when I attempt to build Sage 
> 9.4.beta3 from source on macOS 11.4.

There is no need to build Python, you can either use one from Homebrew
or from the official Python distribution.


> The build fails when it attempts to import distutils, which depends on the 
> binascii module.  Searching through the python build directory with find 
> indicates that binascii.o does not get built.  If I run make in the python 
> build directory using my normal environment then binascii.o is built, as is 
> the extension module binascii.cpython-39-darwin.so, and the python build 
> succeeds.  But If I run make in a sage-buildsh subshell then binascii.o does 
> not get built and the make command fails in the same way as with the build of 
> sage.  So evidently something in the sage build environment is preventing 
> python from compiling its binascii module.
>
> I am attaching the log file.
>
> - Marc
>
> On Friday, June 18, 2021 at 3:09:58 PM UTC-5 max...@gmail.com wrote:
>>
>> Hi!
>>
>> I'm trying to install PyNormaliz within freshly installed Sage 9.3 within 
>> freshly installed Ubuntu 20.04.02 LTS.It breaks giving the following error:
>>
>> ===
>> LD_LIBRARY_PATH=/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src
>>  CC='gcc -pthread' LDSHARED='gcc -pthread -shared 
>> -Wl,-rpath-link,/usr/local/SageMath.93/local/lib 
>> -L/usr/local/SageMath.93/local/lib 
>> -Wl,-rpath,/usr/local/SageMath.93/local/lib  -L. 
>> -Wl,-rpath-link,/usr/local/SageMath.93/local/lib 
>> -L/usr/local/SageMath.93/local/lib 
>> -Wl,-rpath,/usr/local/SageMath.93/local/lib   ' OPT='-DNDEBUG -g -fwrapv -O3 
>> -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS=''   ./python -E 
>> ./setup.py  build
>> Traceback (most recent call last):
>>   File 
>> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/./setup.py",
>>  line 33, in 
>> from distutils import log
>>   File 
>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/_distutils_hack/__init__.py",
>>  line 83, in create_module
>> return importlib.import_module('setuptools._distutils')
>>   File 
>> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/Lib/importlib/__init__.py",
>>  line 127, in import_module
>> return _bootstrap._gcd_import(name[level:], package, level)
>>   File 
>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/setuptools/__init__.py",
>>  line 16, in 
>> import setuptools.version
>>   File 
>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/setuptools/version.py",
>>  line 1, in 
>> import pkg_resources
>>   File 
>> "/usr/local/SageMath.93/local/lib/python3.9/site-packages/pkg_resources/__init__.py",
>>  line 23, in 
>> import zipfile
>>   File 
>> "/usr/local/SageMath.93/local/var/tmp/sage/build/python3-3.9.2/src/Lib/zipfile.py",
>>  line 6, in 
>> import binascii
>> ModuleNotFoundError: No module named 'binascii'
>> make[3]: *** [Makefile:638: sharedmods] Error 1
>> 
>> Error building python3-3.9.2
>> 
>> ===
>>
>> A full log is attached.
>>
>> Please advise.
>>
>> Thanks,
>> Max
>
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/f53afd48-abd2-440b-a996-f9950e16ad58n%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1Z%2BJWoupqNMrqx19w8kBh3LctrREVjsCdBnyBbwpXKng%40mail.gmail.com.

[sage-devel] Re: python3-3.8.5 won't compile under Big Sur

[Volker Braun]

Looks like its #31326, but I posted some details to #30651

On Sunday, March 7, 2021 at 8:16:08 PM UTC+1 Matthias Koeppe wrote:

> Details please -> https://trac.sagemath.org/ticket/30651
>
> On Sunday, March 7, 2021 at 3:16:37 AM UTC-8 Volker Braun wrote:
>
>> For the record, I've set up a BS buildbot at http://build.sagemath.org, 
>> but it currently doesn't succeed in compiling Sage.
>>
>>
>>
>> On Friday, March 5, 2021 at 9:01:51 PM UTC+1 harald@gmail.com wrote:
>>
>>> Hi,
>>>
>>> I've been trying to compile Sage on a Mac running macOS 11.2.2 (Big Sur).
>>> (I first tried to install the binary package, but the process was 
>>> interrupted by 30+ dialog boxes telling me that I had to authorize this and 
>>> that .so because it had been downloaded from an unknown source.)
>>>
>>> Unfortunately, python3-3.8.5 won't compile. First, it claimed gcc it was 
>>> broken - but then, when I did
>>>
>>> export CC=clang
>>>
>>> export CXX=clang++
>>>
>>> I still ran into trouble. I've installed zlib, but that doesn't seem to 
>>> help.
>>>
>>>
>>> See the log file. Thank you in advance for your help!
>>>
>>>
>>> Best
>>>
>>> Harald Helfgott
>>>
>>> University of Goettingen/CNRS
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a8aeee09-ec82-42ab-8384-9c8a1097c960n%40googlegroups.com.

[sage-devel] Re: python3-3.8.5 won't compile under Big Sur

[Matthias Koeppe]

Details please -> https://trac.sagemath.org/ticket/30651

On Sunday, March 7, 2021 at 3:16:37 AM UTC-8 Volker Braun wrote:

> For the record, I've set up a BS buildbot at http://build.sagemath.org, 
> but it currently doesn't succeed in compiling Sage.
>
>
>
> On Friday, March 5, 2021 at 9:01:51 PM UTC+1 harald@gmail.com wrote:
>
>> Hi,
>>
>> I've been trying to compile Sage on a Mac running macOS 11.2.2 (Big Sur).
>> (I first tried to install the binary package, but the process was 
>> interrupted by 30+ dialog boxes telling me that I had to authorize this and 
>> that .so because it had been downloaded from an unknown source.)
>>
>> Unfortunately, python3-3.8.5 won't compile. First, it claimed gcc it was 
>> broken - but then, when I did
>>
>> export CC=clang
>>
>> export CXX=clang++
>>
>> I still ran into trouble. I've installed zlib, but that doesn't seem to 
>> help.
>>
>>
>> See the log file. Thank you in advance for your help!
>>
>>
>> Best
>>
>> Harald Helfgott
>>
>> University of Goettingen/CNRS
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/15a5b423-6173-4a99-86d0-7f4693707eadn%40googlegroups.com.

[sage-devel] Re: python3-3.8.5 won't compile under Big Sur

[Volker Braun]

For the record, I've set up a BS buildbot at http://build.sagemath.org, but 
it currently doesn't succeed in compiling Sage.



On Friday, March 5, 2021 at 9:01:51 PM UTC+1 harald@gmail.com wrote:

> Hi,
>
> I've been trying to compile Sage on a Mac running macOS 11.2.2 (Big Sur).
> (I first tried to install the binary package, but the process was 
> interrupted by 30+ dialog boxes telling me that I had to authorize this and 
> that .so because it had been downloaded from an unknown source.)
>
> Unfortunately, python3-3.8.5 won't compile. First, it claimed gcc it was 
> broken - but then, when I did
>
> export CC=clang
>
> export CXX=clang++
>
> I still ran into trouble. I've installed zlib, but that doesn't seem to 
> help.
>
>
> See the log file. Thank you in advance for your help!
>
>
> Best
>
> Harald Helfgott
>
> University of Goettingen/CNRS
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7453439c-c937-4e11-968f-919e6d69cd85n%40googlegroups.com.

[sage-devel] Re: python3-3.8.5 won't compile under Big Sur

[Matthias Koeppe]

Sage 9.2 does not support building from source on Big Sur 
(see 
https://wiki.sagemath.org/ReleaseTours/sage-9.2#Availability_of_Sage_9.2_and_installation_help).
 
You can try the latest development version in the 9.3 series.

On Friday, March 5, 2021 at 12:01:51 PM UTC-8 harald@gmail.com wrote:

> Hi,
>
> I've been trying to compile Sage on a Mac running macOS 11.2.2 (Big Sur).
> (I first tried to install the binary package, but the process was 
> interrupted by 30+ dialog boxes telling me that I had to authorize this and 
> that .so because it had been downloaded from an unknown source.)
>
> Unfortunately, python3-3.8.5 won't compile. First, it claimed gcc it was 
> broken - but then, when I did
>
> export CC=clang
>
> export CXX=clang++
>
> I still ran into trouble. I've installed zlib, but that doesn't seem to 
> help.
>
>
> See the log file. Thank you in advance for your help!
>
>
> Best
>
> Harald Helfgott
>
> University of Goettingen/CNRS
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/16678f1d-4c33-4fb5-a321-394e52a57a0dn%40googlegroups.com.

[sage-devel] Re: python3 report (may of the last python2 year)

[David Coudert]

> * There are some remaining hard problems in graphs, under current scrutiny 
> I think.
>

The main remaining issues in the graph module are related to isomorphisms, 
automorphisms, and related methods.

1) #27571: align behaviors of algorithm 'sage' and 'bliss' in 
`automorphism_group` and fix a doctest in 
MathonPseudocyclicStronglyRegularGraph generator.

When finalized, we will have to fix bugs with `automorphism_group`, 
`PermutationGroupElement`, and possibly other methods.

2) fix `is_isomorphic` for graphs with edge labels. 
A first attempt is done in #27232 , 
but this proposal is certainly not satisfactory. One issue is that we can 
sort lists of unhashable objects (of different types).

3) #27435 deal with a failing doctest in graph_database.py with 
interactive_query 

Help is more than welcome !!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/bc3d1af3-91f5-4bdb-88dc-2ad28a28b354%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: python3 patchbot

[Samuel Lelievre]

Frédéric wrote:

> [...] although I vaguely remember that Samuel Lelievre
> once asked for something like that, and I may have
> prepared the ground for it (I forgot about that),
> but never for any feedback.

Yes, I was asking about that a while ago, and it took me
a while to experiment and to set things up. I think I now
have two patchbots trying out tickets:
- one for Python2-based SageMath,
- one for Python3-based SageMath.

Let me know if you spot anything wrong with my setup.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c5378dff-fc0f-4e87-81c0-6d7ae68f7161%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: python3 status report (mi-april of last python2 year)

[Volker Braun]

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)

[Andrew]

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)

[Nils Bruin]

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)

[Andrew]

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)

[Vincent Delecroix]

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)

[Volker Braun]

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)

['Martin R' via sage-devel]

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)

['Martin R' via sage-devel]

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)

[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)

[John H Palmieri]

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)

[Andrew]

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 patchbot

[Frédéric Chapoton]

I see that you tried option (2). Not quite successful, it seems.

Your patchbot shows a failure in

sage -t --long src/sage/modular/pollack_stevens/padic_lseries.py

Does it pass when you run it manually ?

F

Le mercredi 17 avril 2019 15:06:59 UTC+2, Daniel Krenn a écrit :
>
> Is it possible to set up a patchbot for running tests of SageMath on 
> Python3? 
>

-- 
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 patchbot

[Frédéric Chapoton]

What do you expect to do ?

(1) run all the tests and see the 94 remaining failing files ?

(2) or run only python3-certified tests and check that they pass on your 
machine ?

I am doing (1) after almost every beta release. I have never tried (2), 
although I vaguely remember that Samuel Lelievre once asked for something 
like that, and I may have prepared the ground for it (I forgot about that), 
but never for any feedback.

It is not clear to me whether or not the "--with-python=3" in configure is 
robust enough to survive all patchbots cleaning operations.

Frederic

Le mercredi 17 avril 2019 15:06:59 UTC+2, Daniel Krenn a écrit :
>
> Is it possible to set up a patchbot for running tests of SageMath on 
> Python3? 
>

-- 
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

[John Cremona]

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

[Thierry]

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

[Jeroen Demeyer]

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

[David Coudert]

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

[Volker Braun]

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

[Thierry]

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

[Daniel Krenn]

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

[Eric Gourgoulhon]

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

[Samuel Lelievre]

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

[E. Madison Bray]

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

[Simon King]

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

[Jeroen Demeyer]

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

[Simon King]

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

[Simon King]

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

[Simon King]

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

[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)? 
>

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

[Simon King]

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

[Frédéric Chapoton]

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

[Simon King]

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

[Timo Kaufmann]

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

[Vincent Delecroix]

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

[Simon King]

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

[Vincent Delecroix]

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

[Dima Pasechnik]

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

[Simon King]

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

[Vincent Delecroix]

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

[Dima Pasechnik]

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

[Vincent Delecroix]

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

[Vincent Delecroix]

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

[Frédéric Chapoton]

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

[Simon King]

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

[Simon King]

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

[Frédéric Chapoton]

>
>
> > *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

[Vincent Delecroix]

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

[Simon King]

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

[Kwankyu Lee]

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

[John H Palmieri]

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

[Kwankyu Lee]

>
> 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

[John H Palmieri]

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

[Kwankyu Lee]

>
> 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

[John H Palmieri]

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

[Frédéric Chapoton]

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

[Kwankyu Lee]

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

[Frédéric Chapoton]

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

[Volker Braun]

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.

Re: [sage-devel] Re: python3 report (end of august 2018)

[Erik Bray]

On Tue, Aug 28, 2018 at 2:36 AM John Cremona  wrote:
>
> I could do this for elliptic curves, but not this week as I'm at a meeting.

FWIW for elliptic curves my python3 branch has these failures:

sage -t src/sage/schemes/elliptic_curves/descent_two_isogeny.pyx  # 1
doctest failed
sage -t src/sage/schemes/elliptic_curves/cm.py  # 4 doctests failed
sage -t src/sage/schemes/elliptic_curves/ell_modular_symbols.py  # 4
doctests failed
sage -t src/sage/schemes/elliptic_curves/ell_rational_field.py  # 3
doctests failed
sage -t src/sage/schemes/elliptic_curves/isogeny_class.py  # 4 doctests failed
sage -t src/sage/schemes/elliptic_curves/padic_lseries.py  # 1 doctest failed
sage -t src/sage/schemes/elliptic_curves/gal_reps_number_field.py  # 2
doctests failed
sage -t src/sage/schemes/elliptic_curves/ell_number_field.py  # 2
doctests failed
sage -t src/sage/schemes/elliptic_curves/constructor.py  # 1 doctest failed

So, fewer, but still a number.

What this means in part of course is that I still need to get more
python3 fixes upstreamed and merged.  I'll have more time after the
OpenDreamKit reporting period is over.

> On Mon, 27 Aug 2018 at 00:02, John H Palmieri  wrote:
>>
>> First, thank you, Frédéric, for all of the work you've done on this.
>>
>> Second, to everyone else: if you're an expert in, say, toric varieties or 
>> elliptic curves, try building Sage with Python 3 and then fixing doctests on 
>> the appropriate directory. Some of these will be easy for anyone, but some 
>> may require expertise in the particular mathematics.
>>
>> (Third, by the way, most of the errors in steenrod_algebra.py were fixed by 
>> https://trac.sagemath.org/ticket/25927, which already has a positive review. 
>> Most of the remaining failures just have to do with different sorting in 
>> Python 2 vs. Python 3 when printing dictionaries.)
>>
>>   John
>>
>>
>>
>> On Sunday, August 26, 2018 at 8:47:01 AM UTC-7, Frédéric Chapoton wrote:
>>>
>>> Dear all, here is a short python3 status report.
>>>
>>> There is a patchbot report with python3 for 8.4.b2 somewhere on the page : 
>>> https://patchbot.sagemath.org/ticket/0/
>>> (@ patchbot breeders, please update your patchbot so that we know if it 
>>> builds and runs sage with python2 or python3.)
>>>
>>> We are now hopefully getting close to making the documentation (html and 
>>> pdf) build with python3. One good step in this direction would be to merge 
>>> the 4 waiting pull requests in sagenb (and then upgrade the sagenb spkg, 
>>> see https://trac.sagemath.org/ticket/25837).
>>>
>>> Otherwise, some progress has been made on the hash issue 
>>> (https://trac.sagemath.org/ticket/24551). There remains in particular the 
>>> controversial question of the hash issue for groups. There is no general 
>>> agreement on the meaning of equality for groups, and this will probably 
>>> make the definition of hash difficult.
>>>
>>> The patchbot report on sage+python3  for 8.4.b2 has still many (and I mean 
>>> many) failing doctests. But it also stops badly in the way shown below, 
>>> complaining that too many files are open. Could somebody investigate this 
>>> issue, please ?
>>>
>>> And I would like to know if some buildbot is using the python3 make target 
>>> that is now available ?
>>>
>>> Frédéric
>>>
>>> sage -t --long src/sage/combinat/crystals/kac_modules.py  # 3 doctests 
>>> failed
>>> sage -t --long src/sage/matroids/matroids_plot_helpers.py  # 1 doctest 
>>> failed
>>> sage -t --long src/sage/libs/gap/element.pyx  # 2 doctests failed
>>> sage -t --long src/sage/groups/conjugacy_classes.py  # 2 doctests failed
>>> sage -t --long src/sage/docs/instancedoc.pyx  # 1 doctest failed
>>> sage -t --long src/sage/rings/padics/factory.py  # 104 doctests failed
>>> Doctests interrupted: 843/3700 files tested
>>> --
>>> Total time for all tests: 6360.5 seconds
>>> cpu time: 10897.2 seconds
>>> cumulative wall time: 12855.4 seconds
>>> Traceback (most recent call last):
>>>   File "/home/u1/chapoton/sage3/src/bin/sage-runtests", line 156, in 
>>> 
>>> err = DC.run()
>>>   File 
>>> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/control.py",
>>>  line 1187, in run
>>> self.run_doctests()
>>>   File 
>>> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/control.py",
>>>  line 915, in run_doctests
>>> self.dispatcher.dispatch()
>>>   File 
>>> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/forker.py",
>>>  line 1912, in dispatch
>>> self.parallel_dispatch()
>>>   File 
>>> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/forker.py",
>>>  line 1809, in parallel_dispatch
>>> w.start()  # This might take some time
>>>   File 
>>> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/forker.py",
>>>  line 2095, in start
>>> super(DocTestWorker, self).start()
>>>   File 
>>> 

Re: [sage-devel] Re: python3 report (end of august 2018)

[John Cremona]

I could do this for elliptic curves, but not this week as I'm at a meeting.

John

On Mon, 27 Aug 2018 at 00:02, John H Palmieri 
wrote:

> First, thank you, Frédéric, for all of the work you've done on this.
>
> Second, to everyone else: if you're an expert in, say, toric varieties or
> elliptic curves, try building Sage with Python 3 and then fixing doctests
> on the appropriate directory. Some of these will be easy for anyone, but
> some may require expertise in the particular mathematics.
>
> (Third, by the way, most of the errors in steenrod_algebra.py were fixed
> by https://trac.sagemath.org/ticket/25927, which already has a positive
> review. Most of the remaining failures just have to do with different
> sorting in Python 2 vs. Python 3 when printing dictionaries.)
>
>   John
>
>
>
> On Sunday, August 26, 2018 at 8:47:01 AM UTC-7, Frédéric Chapoton wrote:
>>
>> Dear all, here is a short python3 status report.
>>
>> There is a patchbot report with python3 for 8.4.b2 somewhere on the page
>> : https://patchbot.sagemath.org/ticket/0/
>> (@ patchbot breeders, please update your patchbot so that we know if it
>> builds and runs sage with python2 or python3.)
>>
>> We are now hopefully getting close to making the documentation (html and
>> pdf) build with python3. One good step in this direction would be to merge
>> the 4 waiting pull requests in sagenb (and then upgrade the sagenb spkg,
>> see https://trac.sagemath.org/ticket/25837).
>>
>> Otherwise, some progress has been made on the hash issue (
>> https://trac.sagemath.org/ticket/24551). There remains in particular the
>> controversial question of the hash issue for groups. There is no general
>> agreement on the meaning of equality for groups, and this will probably
>> make the definition of hash difficult.
>>
>> The patchbot report on sage+python3  for 8.4.b2 has still *many* (and I
>> mean *many*) failing doctests. But it also stops badly in the way shown
>> below, complaining that too many files are open. Could somebody investigate
>> this issue, please ?
>>
>> And I would like to know if some buildbot is using the python3 make
>> target that is now available ?
>>
>> Frédéric
>>
>> sage -t --long src/sage/combinat/crystals/kac_modules.py  # 3 doctests
>> failed
>> sage -t --long src/sage/matroids/matroids_plot_helpers.py  # 1 doctest
>> failed
>> sage -t --long src/sage/libs/gap/element.pyx  # 2 doctests failed
>> sage -t --long src/sage/groups/conjugacy_classes.py  # 2 doctests failed
>> sage -t --long src/sage/docs/instancedoc.pyx  # 1 doctest failed
>> sage -t --long src/sage/rings/padics/factory.py  # 104 doctests failed
>> Doctests interrupted: 843/3700 files tested
>> --
>> Total time for all tests: 6360.5 seconds
>> cpu time: 10897.2 seconds
>> cumulative wall time: 12855.4 seconds
>> Traceback (most recent call last):
>>   File "/home/u1/chapoton/sage3/src/bin/sage-runtests", line 156, in
>> 
>> err = DC.run()
>>   File
>> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/control.py"
>> , line 1187, in run
>> self.run_doctests()
>>   File
>> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/control.py"
>> , line 915, in run_doctests
>> self.dispatcher.dispatch()
>>   File
>> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/forker.py"
>> , line 1912, in dispatch
>> self.parallel_dispatch()
>>   File
>> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/forker.py"
>> , line 1809, in parallel_dispatch
>> w.start()  # This might take some time
>>   File
>> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/forker.py"
>> , line 2095, in start
>> super(DocTestWorker, self).start()
>>   File
>> "/home/u1/chapoton/sage3/local/lib/python3.6/multiprocessing/process.py",
>> line 105, in start
>> self._popen = self._Popen(self)
>>   File
>> "/home/u1/chapoton/sage3/local/lib/python3.6/multiprocessing/context.py",
>> line 223, in _Popen
>> return _default_context.get_context().Process._Popen(process_obj)
>>   File
>> "/home/u1/chapoton/sage3/local/lib/python3.6/multiprocessing/context.py",
>> line 277, in _Popen
>> return Popen(process_obj)
>>   File
>> "/home/u1/chapoton/sage3/local/lib/python3.6/multiprocessing/popen_fork.py"
>> , line 19, in __init__
>> self._launch(process_obj)
>>   File
>> "/home/u1/chapoton/sage3/local/lib/python3.6/multiprocessing/popen_fork.py"
>> , line 65, in _launch
>> parent_r, child_w = os.pipe()
>> OSError: [Errno 24] Too many open files
>>
>>
>> By the way, here are the worst offenders, those having hundreds of
>> failing doctests:
>>
>> sage -t --long src/sage/schemes/elliptic_curves/ell_number_field.py  #
>> 107 doctests failed
>> sage -t --long src/sage/modular/pollack_stevens/modsym.py  # 199
>> doctests failed
>> sage -t --long src/sage/schemes/hyperelliptic_curves/
>> 

[sage-devel] Re: python3 report (end of august 2018)

[John H Palmieri]

First, thank you, Frédéric, for all of the work you've done on this.

Second, to everyone else: if you're an expert in, say, toric varieties or 
elliptic curves, try building Sage with Python 3 and then fixing doctests 
on the appropriate directory. Some of these will be easy for anyone, but 
some may require expertise in the particular mathematics.

(Third, by the way, most of the errors in steenrod_algebra.py were fixed by 
https://trac.sagemath.org/ticket/25927, which already has a positive 
review. Most of the remaining failures just have to do with different 
sorting in Python 2 vs. Python 3 when printing dictionaries.)

  John



On Sunday, August 26, 2018 at 8:47:01 AM UTC-7, Frédéric Chapoton wrote:
>
> Dear all, here is a short python3 status report.
>
> There is a patchbot report with python3 for 8.4.b2 somewhere on the page : 
> https://patchbot.sagemath.org/ticket/0/
> (@ patchbot breeders, please update your patchbot so that we know if it 
> builds and runs sage with python2 or python3.)
>
> We are now hopefully getting close to making the documentation (html and 
> pdf) build with python3. One good step in this direction would be to merge 
> the 4 waiting pull requests in sagenb (and then upgrade the sagenb spkg, 
> see https://trac.sagemath.org/ticket/25837).
>
> Otherwise, some progress has been made on the hash issue (
> https://trac.sagemath.org/ticket/24551). There remains in particular the 
> controversial question of the hash issue for groups. There is no general 
> agreement on the meaning of equality for groups, and this will probably 
> make the definition of hash difficult. 
>
> The patchbot report on sage+python3  for 8.4.b2 has still *many* (and I 
> mean *many*) failing doctests. But it also stops badly in the way shown 
> below, complaining that too many files are open. Could somebody investigate 
> this issue, please ?
>
> And I would like to know if some buildbot is using the python3 make target 
> that is now available ?
>
> Frédéric
>
> sage -t --long src/sage/combinat/crystals/kac_modules.py  # 3 doctests 
> failed
> sage -t --long src/sage/matroids/matroids_plot_helpers.py  # 1 doctest 
> failed
> sage -t --long src/sage/libs/gap/element.pyx  # 2 doctests failed
> sage -t --long src/sage/groups/conjugacy_classes.py  # 2 doctests failed
> sage -t --long src/sage/docs/instancedoc.pyx  # 1 doctest failed
> sage -t --long src/sage/rings/padics/factory.py  # 104 doctests failed
> Doctests interrupted: 843/3700 files tested
> --
> Total time for all tests: 6360.5 seconds
> cpu time: 10897.2 seconds
> cumulative wall time: 12855.4 seconds
> Traceback (most recent call last):
>   File "/home/u1/chapoton/sage3/src/bin/sage-runtests", line 156, in 
> 
> err = DC.run()
>   File 
> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/control.py"
> , line 1187, in run
> self.run_doctests()
>   File 
> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/control.py"
> , line 915, in run_doctests
> self.dispatcher.dispatch()
>   File 
> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/forker.py"
> , line 1912, in dispatch
> self.parallel_dispatch()
>   File 
> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/forker.py"
> , line 1809, in parallel_dispatch
> w.start()  # This might take some time
>   File 
> "/home/u1/chapoton/sage3/local/lib/python3.6/site-packages/sage/doctest/forker.py"
> , line 2095, in start
> super(DocTestWorker, self).start()
>   File 
> "/home/u1/chapoton/sage3/local/lib/python3.6/multiprocessing/process.py", 
> line 105, in start
> self._popen = self._Popen(self)
>   File 
> "/home/u1/chapoton/sage3/local/lib/python3.6/multiprocessing/context.py", 
> line 223, in _Popen
> return _default_context.get_context().Process._Popen(process_obj)
>   File 
> "/home/u1/chapoton/sage3/local/lib/python3.6/multiprocessing/context.py", 
> line 277, in _Popen
> return Popen(process_obj)
>   File 
> "/home/u1/chapoton/sage3/local/lib/python3.6/multiprocessing/popen_fork.py"
> , line 19, in __init__
> self._launch(process_obj)
>   File 
> "/home/u1/chapoton/sage3/local/lib/python3.6/multiprocessing/popen_fork.py"
> , line 65, in _launch
> parent_r, child_w = os.pipe()
> OSError: [Errno 24] Too many open files
>
>
> By the way, here are the worst offenders, those having hundreds of failing 
> doctests:
>
> sage -t --long src/sage/schemes/elliptic_curves/ell_number_field.py  # 
> 107 doctests failed
> sage -t --long src/sage/modular/pollack_stevens/modsym.py  # 199 doctests 
> failed
> sage -t --long src/sage/schemes/hyperelliptic_curves/
> hyperelliptic_finite_field.py  # 126 doctests failed
> sage -t --long src/sage/modular/modform/element.py  # 346 doctests failed
> sage -t --long src/sage/rings/padics/padic_lattice_element.py  # 167 
> doctests failed
> sage -t --long 

Re: [sage-devel] Re: python3 status

[Emmanuel Charpentier]

Dear Nils,

Le jeudi 31 mai 2018 18:31:31 UTC+2, Nils Bruin a écrit :
>
> On Thursday, May 31, 2018 at 4:52:04 AM UTC-7, Emmanuel Charpentier wrote:
>>
>> I'm grabbing the opportunity to recall that , whereas I have installed 
>> the Sage kernel in my (systemwide) jupyter installation via the suitable 
>> "jupyter 
>> kernelspec install ..." invocation), when I try to use it from the 
>> systemwide jupyter via the "normal" invocation "jupyter notebook", it 
>> complains of SAGE_ROOT being undefined and does not lauch Sage. OTOH, if  I 
>> invoke "SAGE_ROOT= jupyter notebook", all is fine and dandy. 
>> My $SAGE_ROOT/sage script is symlinked to /usr/local/bin/, which is on 
>> my $PATH.
>>
>> Suggestions ?
>>
>  
> Yes, that is very close to my usage scenario as well (as an aside: 
> "jupyter kernelspec install" on the sage kernel involved COPYING all the 
> sage documentation into the kernelspec directory. In most scenarios 
> symlinking it is more appropriate (that's how sage installs its kernel in 
> its own kernel)
>

Should I revert to symlinking ? It seems not :
 

> If you are placing your kernel.json outside of the sage installation 
> anyway, you can edit the relevant "kernel.json" to refer to "sage" rather 
> than the hard path to $SAGE_LOCAL/bin/sage that is there presently. The 
> changes we are discussing here would avoid having to make that edit.
>
  So, at least for now, I'd better *copy* kernel.json (to be able to edit) 
and symlink the rest (incl. documentation). And the patch under discussion 
should allow for simple "standard" installation. Right ?

--
Emmanuel Charpentier

-- 
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

[Matthias Koeppe]

I have created https://trac.sagemath.org/ticket/25486 for this.

On Wednesday, May 30, 2018 at 10:32:42 AM UTC-7, Matthias Koeppe wrote:
>
> On Wednesday, May 30, 2018 at 9:01:59 AM UTC-7, Nils Bruin wrote:
>>
>>
>> Currently, if I run the script $SAGE_LOCAL/bin/sage in my normal 
>> environment (where SAGE_ROOT is not set) then I get:
>>
>> Error: You must set the SAGE_ROOT environment variable or run this
>> script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory.
>> Error setting environment variables by sourcing 
>> '/usr/local/sage/sage-git/local/bin/sage-env';
>> possibly contact sage-devel (see 
>> http://groups.google.com/group/sage-devel).
>>
>> If instead I run the script $SAGE_ROOT/sage a value for SAGE_ROOT is 
>> figured out and everything works fine when called from my normal 
>> environment.
>>
>>
> I agree that we should make $SAGE_LOCAL/bin/sage work without environment 
> variables set.
> We discussed this in https://trac.sagemath.org/ticket/21479 ("./configure 
> --prefix=SAGE_LOCAL"), when $SAGE_LOCAL/bin/sage-env-config was introduced; 
> but then a less ambitious solution was implemented for that ticket.
>
> We could add a line setting $SAGE_ROOT in $SAGE_LOCAL/bin/sage-env-config 
> (via src/bin/sage-env-config.in).
>
> On the other hand, of course, most uses of SAGE_ROOT have been eliminated 
> (see https://trac.sagemath.org/ticket/21591 - Replace use of SAGE_ROOT by 
> more specific environment variables); and it would be good to finish this 
> job and allow sage to work without having to complain about this 
> environment variable.
>
>
>
>
>

-- 
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

[Nils Bruin]

On Thursday, May 31, 2018 at 4:52:04 AM UTC-7, Emmanuel Charpentier wrote:
>
> I'm grabbing the opportunity to recall that , whereas I have installed the 
> Sage kernel in my (systemwide) jupyter installation via the suitable "jupyter 
> kernelspec install ..." invocation), when I try to use it from the 
> systemwide jupyter via the "normal" invocation "jupyter notebook", it 
> complains of SAGE_ROOT being undefined and does not lauch Sage. OTOH, if  I 
> invoke "SAGE_ROOT= jupyter notebook", all is fine and dandy. My 
> $SAGE_ROOT/sage script is symlinked to /usr/local/bin/, which is on my 
> $PATH.
>
> Suggestions ?
>
 
Yes, that is very close to my usage scenario as well (as an aside: "jupyter 
kernelspec install" on the sage kernel involved COPYING all the sage 
documentation into the kernelspec directory. In most scenarios symlinking 
it is more appropriate (that's how sage installs its kernel in its own 
kernel)

If you are placing your kernel.json outside of the sage installation 
anyway, you can edit the relevant "kernel.json" to refer to "sage" rather 
than the hard path to $SAGE_LOCAL/bin/sage that is there presently. The 
changes we are discussing here would avoid having to make that edit.

-- 
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

[Emmanuel Charpentier]

I'm grabbing the opportunity to recall that , whereas I have installed the 
Sage kernel in my (systemwide) jupyter installation via the suitable "jupyter 
kernelspec install ..." invocation), when I try to use it from the 
systemwide jupyter via the "normal" invocation "jupyter notebook", it 
complains of SAGE_ROOT being undefined and does not lauch Sage. OTOH, if  I 
invoke "SAGE_ROOT= jupyter notebook", all is fine and dandy. My 
$SAGE_ROOT/sage script is symlinked to /usr/local/bin/, which is on my 
$PATH.

Suggestions ?

--
Emmanuel Charpentier

Le mercredi 30 mai 2018 19:32:42 UTC+2, Matthias Koeppe a écrit :
>
> On Wednesday, May 30, 2018 at 9:01:59 AM UTC-7, Nils Bruin wrote:
>>
>>
>> Currently, if I run the script $SAGE_LOCAL/bin/sage in my normal 
>> environment (where SAGE_ROOT is not set) then I get:
>>
>> Error: You must set the SAGE_ROOT environment variable or run this
>> script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory.
>> Error setting environment variables by sourcing 
>> '/usr/local/sage/sage-git/local/bin/sage-env';
>> possibly contact sage-devel (see 
>> http://groups.google.com/group/sage-devel).
>>
>> If instead I run the script $SAGE_ROOT/sage a value for SAGE_ROOT is 
>> figured out and everything works fine when called from my normal 
>> environment.
>>
>>
> I agree that we should make $SAGE_LOCAL/bin/sage work without environment 
> variables set.
> We discussed this in https://trac.sagemath.org/ticket/21479 ("./configure 
> --prefix=SAGE_LOCAL"), when $SAGE_LOCAL/bin/sage-env-config was introduced; 
> but then a less ambitious solution was implemented for that ticket.
>
> We could add a line setting $SAGE_ROOT in $SAGE_LOCAL/bin/sage-env-config 
> (via src/bin/sage-env-config.in).
>
> On the other hand, of course, most uses of SAGE_ROOT have been eliminated 
> (see https://trac.sagemath.org/ticket/21591 - Replace use of SAGE_ROOT by 
> more specific environment variables); and it would be good to finish this 
> job and allow sage to work without having to complain about this 
> environment variable.
>
>
>
>
>

-- 
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

[Matthias Koeppe]

On Wednesday, May 30, 2018 at 9:01:59 AM UTC-7, Nils Bruin wrote:
>
>
> Currently, if I run the script $SAGE_LOCAL/bin/sage in my normal 
> environment (where SAGE_ROOT is not set) then I get:
>
> Error: You must set the SAGE_ROOT environment variable or run this
> script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory.
> Error setting environment variables by sourcing 
> '/usr/local/sage/sage-git/local/bin/sage-env';
> possibly contact sage-devel (see http://groups.google.com/group/sage-devel
> ).
>
> If instead I run the script $SAGE_ROOT/sage a value for SAGE_ROOT is 
> figured out and everything works fine when called from my normal 
> environment.
>
>
I agree that we should make $SAGE_LOCAL/bin/sage work without environment 
variables set.
We discussed this in https://trac.sagemath.org/ticket/21479 ("./configure 
--prefix=SAGE_LOCAL"), when $SAGE_LOCAL/bin/sage-env-config was introduced; 
but then a less ambitious solution was implemented for that ticket.

We could add a line setting $SAGE_ROOT in $SAGE_LOCAL/bin/sage-env-config 
(via src/bin/sage-env-config.in).

On the other hand, of course, most uses of SAGE_ROOT have been eliminated 
(see https://trac.sagemath.org/ticket/21591 - Replace use of SAGE_ROOT by 
more specific environment variables); and it would be good to finish this 
job and allow sage to work without having to complain about this 
environment variable.




-- 
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

[Nils Bruin]

On Wednesday, May 30, 2018 at 1:28:25 AM UTC-7, Jeroen Demeyer wrote:
>
> On 2018-05-29 22:57, Nils Bruin wrote: 
> > it would also be useful to 
> > use a "sage" executable that can figure out $SAGE_ROOT from scratch. 
>
> Can you say more precisely what you mean with this? 
>

Currently, if I run the script $SAGE_LOCAL/bin/sage in my normal 
environment (where SAGE_ROOT is not set) then I get:

Error: You must set the SAGE_ROOT environment variable or run this
script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory.
Error setting environment variables by sourcing 
'/usr/local/sage/sage-git/local/bin/sage-env';
possibly contact sage-devel (see http://groups.google.com/group/sage-devel).

If instead I run the script $SAGE_ROOT/sage a value for SAGE_ROOT is 
figured out and everything works fine when called from my normal 
environment.

If I change sage's kernel_spec to run the latter, I can use the whole 
SAGE_LOCAL/share/jupyter/kernels/sagemath jupyter kernel description 
directly with /usr/bin/jupyter (via a symlink or so).

I think that's an advantage. If it were up to me, I would probably inject 
the logic of SAGE_ROOT/sage into SAGE_LOCAL/bin/sage because for me that 
would work fine.

Linking to SAGE_LOCAL/share/jupyter/kernels/sagemath has the advantage that 
upgrades are automatically picked up when I use /usr/bin/jupyter. I can of 
course copy & edit files, but then they are not kept up-to-date.
Similarly, I could edit the file in-place (e.g., equip the script with a 
hard-coded value for SAGE_ROOT), but then I have to deal with a source tree 
that is forever patched wrt. vanilla.

-- 
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

[Jeroen Demeyer]

On 2018-05-29 22:57, Nils Bruin wrote:

it would also be useful to
use a "sage" executable that can figure out $SAGE_ROOT from scratch.


Can you say more precisely what you mean with this?

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To 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

[Samuel Lelievre]

Tue 2018-05-29 15:59:27 UTC, Frédéric Chapoton:
>
> here is a small report on the slow progress towards Python3-compatibility
> for Sage.
>
> Sage is already building and starting with python3 since some time 
already.
> It is explained in https://trac.sagemath.org/ticket/15530 how to get
> a python3-sage. One can note an even longer startup time (sigh).
>
> There has been recent progress on the pexpect interfaces and lib 
interfaces,
> so this sage3 is now somewhat usable. Try it !

Hi Frédéric, thanks for the hard work on making Sage Python3-compatible!
I succeeded in building Sage 8.3.beta1 both for Python2 and for Python3.
I started using "SagePy3" for regular work, switching to "SagePy2" only
when "SagePy3" won't do the work. I thus noted there's a fair amount one
can already do with "SagePy3".

> Our next goal is to get the documentation build. After that, one will have
> to make all doctest pass, but we are still a long way from that.
> Another interesting step would be to be able to launch the jupyter 
notebook
> with sage3. Currently, it looks for the sage kernel in the python2 library
> (no ticket yet).
>
> The current result of trying to build the doc can be seen here: 
>
> 
https://patchbot.sagemath.org/log/0/Ubuntu/18.04/x86_64/4.15.0-20-generic/petitbonum/2018-05-27%2021:55:21?plugin=docbuild
>
> Apparently, we are not so far to manage building the documentation. Two
> important issues, responsible for many errors in docbuilding:
>
> (A) fix some heavy problem of hash in the manifolds code, see
> https://trac.sagemath.org/ticket/25393
>
> (B) need to reactivate the build of sagenb in python3, see
> https://trac.sagemath.org/ticket/22431
>
> Ticket 22431 above need people to check (1) that the upgraded sagenb
> works smoothly on python2 and (2) that sage3 still builds and starts
> after building sagenb.
>
> (note that even after 22341, sagenb will not work in sage3, due to some
> missing parts of twisted, that require upgrading twisted.)
>
> Does somebody care ?

I care a lot! But all I can do so far (not that it helps a lot) is build
each new beta both for Py3 and Py2 and work primarily with the Py3 one,
switching to the Py2 one only as needed.

By the way, did "SagePy3" 8.3.beta2 build for anyone? I had no luck getting
it to build under (now unsupported) macOS 10.10.5. I have to try 8.3.beta3
now that it is out.

Do we ensure each new beta builds for Py3 on supported platforms?

Maybe the announcement for each new beta on sage-release could remind
readers that https://trac.sagemath.org/ticket/15530 has the instructions
for building a Python3-based 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.

[sage-devel] Re: python3 status

[Nils Bruin]

On Tuesday, May 29, 2018 at 8:59:27 AM UTC-7, Frédéric Chapoton wrote:
>
> Hello,
>
> here is a small report on the *slow* progress towards 
> python3-compatibility for sage.
>
> Sage is already building and starting with python3 since some time 
> already. It is explained in https://trac.sagemath.org/ticket/15530 how to 
> get a python3-sage. One can note an even longer startup time (sigh).
>
> There has been recent progress on the pexpect interfaces and lib 
> interfaces, so this sage3 is now somewhat usable. Try it !
>
> Congratulations and thank you for the hard work on something that is 
ultimately absolutely required.
 

> Our next goal is to get the documentation build. After that, one will have 
> to make all doctest pass, but we are still a *long* way from that.
> Another interesting step would be to be able to launch the jupyter 
> notebook with sage3. Currently, it looks for the sage kernel in the python2 
> library (no ticket yet).
>

That's sage.repl.ipython_kernel.SageKernelSpec._kernel_cmd, which currently 
invokes "$SAGE_LOCAL/bin/sage --python". If you change that to "--python3" 
it should be OK. I guess we can have two kernel specs: sage/Py3 and 
sage/Py3. [on a different note, it would also be useful to use a "sage" 
executable that can figure out $SAGE_ROOT from scratch. Then the kernelspec 
is usable with arbitrary jupyters]

-- 
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 and super()

[Eric Gourgoulhon]

Le jeudi 16 novembre 2017 15:02:36 UTC+1, Eric Gourgoulhon a écrit :
>
> so this should hamper the transition to Python3
>

Yet another typo: "this should hamper" --> "this should not hamper"
Sorry.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
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 comparing, an idea about deprecation

[Jeroen Demeyer]

On 2017-11-05 22:51, Travis Scrimshaw wrote:

I'm not quite sure what you're asking. min and max are not fundamentally
changed between Python3 except that the cmp keyword will no longer be
valid.


The functions min() and max() are not fundamentally different but the 
way how comparison works is different:


Python 2.7.5 (default, Oct 11 2013, 15:40:52)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 < "x"
True

Python 3.4.1 (default, Sep  4 2015, 12:50:14)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 < "x"
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unorderable types: int() < str()

It would be possible to implement a variant of the min() function which 
would be closer to the Python 3 semantics by not falling back to 
comparison by id().


--
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 comparing, an idea about deprecation

[Travis Scrimshaw]

I'm not quite sure what you're asking. min and max are not fundamentally 
changed between Python3 except that the cmp keyword will no longer be 
valid. So if you do min(L) or min(L, key=foo), both will work in Python3, 
up to how you are doing comparisons within L. For that, it is localized to 
the objects of L, so you should *not* do anything in the call to min.

Best,
Travis


On Monday, November 6, 2017 at 4:21:06 AM UTC+10, Jori Mäntysalo wrote:
>
> Is it possible to run min(L) in Python2 and at the same time check if it 
> could be run in Python3 for given L? 
>
> Reason: allow_multiple_edges() on generic_graph.py and keep_label='min' 
> (or 'max'), can we have a nice deprecation? 
>
> -- 
> Jori Mäntysalo 
>

-- 
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

[Dima Pasechnik]

Given http://www.python3statement.org/ lists a number of crucial Sage 
dependencies to drop py2 on or before 2020, there is little choice. :-)
In fact, I think we should get Sage added to that list too, and get to work 
on py3 in the earnest.



On Friday, October 13, 2017 at 4:56:11 PM UTC+1, Frédéric Chapoton wrote:
>
> Hello,
>
> I have reached this point with the ugly python3 experimental branch 
> "public/python3-experiment-8.1.b7":
>
>
> ┌┐
> │ SageMath version 8.1.beta7, Release Date: 2017-10-03   │
> │ Type "notebook()" for the browser-based notebook interface.│
> │ Type "help()" for help.│
> └┘
> ┏┓
> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
> ┗┛
> sage: 3*3
> 9
> sage: parent(_)
> Integer Ring
>
>
> Cool, no ? Or maybe nobody cares ?
>
> Many things are still not working. The cmp problem has been much reduced, 
> but still not fully fixed. On our way is a large-scale unicode problem, and 
> maybe another large scale hash problem.
>
> Frederic
>

-- 
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

[Nils Bruin]

On Friday, October 13, 2017 at 5:56:11 PM UTC+2, Frédéric Chapoton wrote:
>
> Hello,
>
> I have reached this point with the ugly python3 experimental branch 
> "public/python3-experiment-8.1.b7":
>
>
> ┌┐
> │ SageMath version 8.1.beta7, Release Date: 2017-10-03   │
> │ Type "notebook()" for the browser-based notebook interface.│
> │ Type "help()" for help.│
> └┘
> ┏┓
> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
> ┗┛
> sage: 3*3
> 9
> sage: parent(_)
> Integer Ring
>
>
> Cool, no ? Or maybe nobody cares ?
>
> It's definitely the former and not the latter. This is very cool and a lot 
of people care (or will, or should).
Once this branch gains traction, I imagine you may have to edit the 
"warning" banner and replace "may be" with "is" for a while.

-- 
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

[John H Palmieri]

That's great! Thank you for all of your work on this.

  John


On Friday, October 13, 2017 at 8:56:11 AM UTC-7, Frédéric Chapoton wrote:
>
> Hello,
>
> I have reached this point with the ugly python3 experimental branch 
> "public/python3-experiment-8.1.b7":
>
>
> ┌┐
> │ SageMath version 8.1.beta7, Release Date: 2017-10-03   │
> │ Type "notebook()" for the browser-based notebook interface.│
> │ Type "help()" for help.│
> └┘
> ┏┓
> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
> ┗┛
> sage: 3*3
> 9
> sage: parent(_)
> Integer Ring
>
>
> Cool, no ? Or maybe nobody cares ?
>
> Many things are still not working. The cmp problem has been much reduced, 
> but still not fully fixed. On our way is a large-scale unicode problem, and 
> maybe another large scale hash problem.
>
> Frederic
>

-- 
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 in sage

[Eric Gourgoulhon]

Le vendredi 25 août 2017 19:35:27 UTC+2, Nils Bruin a écrit :

>
> Something along the lines of
>
> import sage.repl.ipython_kernel.install
> sage.repl.ipython_kernel.install.JUPYTER_PATH = 
> spec = sage.repl.ipython_kernel.install.SageKernelSpec()
> spec.update()
>
> With any luck, you'll see SageMath show up in the kernel list.
>
>
Thanks!

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 in sage

[Nils Bruin]

On Friday, August 25, 2017 at 12:55:56 AM UTC-7, Eric Gourgoulhon wrote:
>
> Hi,
>
> Le jeudi 24 août 2017 23:17:07 UTC+2, Nils Bruin a écrit :
>
>>
>> If you're using jupyter for non-sage-specific purposes (apparently 
>> relying on a system python3), why not use system jupyter? Personally, I 
>> just install the sage-jupyter kernel in the system jupyter. 
>>
>
>
> This sounds nice! Could you please provide some details about how you 
> proceeded?
>

Something along the lines of

import sage.repl.ipython_kernel.install
sage.repl.ipython_kernel.install.JUPYTER_PATH = 
spec = sage.repl.ipython_kernel.install.SageKernelSpec()
spec.update()

With any luck, you'll see SageMath show up in the kernel list.

-- 
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 in sage

[Erik Bray]

On Fri, Aug 25, 2017 at 1:38 PM, Erik Bray  wrote:
> On Thu, Aug 24, 2017 at 11:49 PM, William Stein  wrote:
>> On Thu, Aug 24, 2017 at 2:17 PM, Nils Bruin  wrote:
>>> On Thursday, August 24, 2017 at 1:30:25 PM UTC-7, William wrote:

 I'm not sure what the status is these days, but we may want to stop
 including a python3 binary in Sage by default with "python3" right
 there in the "sage -sh" path...
>>>
>>>
>>> As far as I understand, having python3 included in sage is part of the
>>> deliberate strategy towards porting sage to python3. Since sage comes with
>>> its own python(2), the most straightforward move of sage would be towards
>>> sage working on top of an included python3.
>>
>> The problem is simply the "python3" executable which gets picked up
>> and breaks things.
>>
>>> If you're using jupyter for non-sage-specific purposes (apparently relying
>>> on a system python3), why not use system jupyter? Personally, I just install
>>> the sage-jupyter kernel in the system jupyter. That way, your main jupyter
>>> runs independent of sage (other than the extensions that get registered upon
>>> registering the sage kernel), and doesn't get confused by the system things
>>> sage does.
>>
>> Nope.For example, Sage worksheets in Cocalc have a full "jupyter
>> bridge" that lets you simultaneously use several different Jupyter
>> kernels from within a Sage session, e.g., in different cells of a
>> notebook.  Having python3 in the PATH randomly breaks many of these.
>> Removing it, and everything works fine.
>>
>> For now I guess we'll keep deleting local/bin/python3 ourselves...
>>
>> Frickin' Guido...
>
> How is this Guido's fault?  Why should having python3 in the PATH
> break anything?  Sounds like a problem with Jupyter if you ask me.

I couldn't reproduce the problem in my Sage install, but I don't know
if I'm setting things up the same way as in CoCalc (which isn't
clear).  I did:

$ ./sage -sh
$ pip install jupyter-console bash_kernel  # These do not come standard in Sage
$ python -m bash_kernel.install --prefix="$SAGE_LOCAL"
$ jupyter console --kernel=bash
Jupyter console 5.2.0

GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.



In [1]: python -c 'print "Hello"'
Hello

In [2]: python3 -c 'print("Hello")'
Hello

-- 
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 in sage

[Erik Bray]

On Thu, Aug 24, 2017 at 11:49 PM, William Stein  wrote:
> On Thu, Aug 24, 2017 at 2:17 PM, Nils Bruin  wrote:
>> On Thursday, August 24, 2017 at 1:30:25 PM UTC-7, William wrote:
>>>
>>> I'm not sure what the status is these days, but we may want to stop
>>> including a python3 binary in Sage by default with "python3" right
>>> there in the "sage -sh" path...
>>
>>
>> As far as I understand, having python3 included in sage is part of the
>> deliberate strategy towards porting sage to python3. Since sage comes with
>> its own python(2), the most straightforward move of sage would be towards
>> sage working on top of an included python3.
>
> The problem is simply the "python3" executable which gets picked up
> and breaks things.
>
>> If you're using jupyter for non-sage-specific purposes (apparently relying
>> on a system python3), why not use system jupyter? Personally, I just install
>> the sage-jupyter kernel in the system jupyter. That way, your main jupyter
>> runs independent of sage (other than the extensions that get registered upon
>> registering the sage kernel), and doesn't get confused by the system things
>> sage does.
>
> Nope.For example, Sage worksheets in Cocalc have a full "jupyter
> bridge" that lets you simultaneously use several different Jupyter
> kernels from within a Sage session, e.g., in different cells of a
> notebook.  Having python3 in the PATH randomly breaks many of these.
> Removing it, and everything works fine.
>
> For now I guess we'll keep deleting local/bin/python3 ourselves...
>
> Frickin' Guido...

How is this Guido's fault?  Why should having python3 in the PATH
break anything?  Sounds like a problem with Jupyter if you ask me.

-- 
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 in sage

[Eric Gourgoulhon]

Hi,

Le jeudi 24 août 2017 23:17:07 UTC+2, Nils Bruin a écrit :

>
> If you're using jupyter for non-sage-specific purposes (apparently relying 
> on a system python3), why not use system jupyter? Personally, I just 
> install the sage-jupyter kernel in the system jupyter. 
>


This sounds nice! Could you please provide some details about how you 
proceeded?

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.

Re: [sage-devel] Re: python3 in sage

[John H Palmieri]

On Thursday, August 24, 2017 at 2:50:09 PM UTC-7, William wrote:
>
> On Thu, Aug 24, 2017 at 2:17 PM, Nils Bruin  
> wrote: 
> > On Thursday, August 24, 2017 at 1:30:25 PM UTC-7, William wrote: 
> >> 
> >> I'm not sure what the status is these days, but we may want to stop 
> >> including a python3 binary in Sage by default with "python3" right 
> >> there in the "sage -sh" path... 
> > 
> > 
> > As far as I understand, having python3 included in sage is part of the 
> > deliberate strategy towards porting sage to python3. Since sage comes 
> with 
> > its own python(2), the most straightforward move of sage would be 
> towards 
> > sage working on top of an included python3. 
>
> The problem is simply the "python3" executable which gets picked up 
> and breaks things. 
>

Will any python3 executable break things, or is there something 
specifically wrong with the one that Sage builds?
 

>
> > If you're using jupyter for non-sage-specific purposes (apparently 
> relying 
> > on a system python3), why not use system jupyter? Personally, I just 
> install 
> > the sage-jupyter kernel in the system jupyter. That way, your main 
> jupyter 
> > runs independent of sage (other than the extensions that get registered 
> upon 
> > registering the sage kernel), and doesn't get confused by the system 
> things 
> > sage does. 
>
> Nope.For example, Sage worksheets in Cocalc have a full "jupyter 
> bridge" that lets you simultaneously use several different Jupyter 
> kernels from within a Sage session, e.g., in different cells of a 
> notebook.  Having python3 in the PATH randomly breaks many of these. 
> Removing it, and everything works fine. 
>
> For now I guess we'll keep deleting local/bin/python3 ourselves... 
>
> Frickin' Guido... 
>
> William 
>
>
> -- 
> William (http://wstein.org) 
>

-- 
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 in sage

[William Stein]

On Thu, Aug 24, 2017 at 2:17 PM, Nils Bruin  wrote:
> On Thursday, August 24, 2017 at 1:30:25 PM UTC-7, William wrote:
>>
>> I'm not sure what the status is these days, but we may want to stop
>> including a python3 binary in Sage by default with "python3" right
>> there in the "sage -sh" path...
>
>
> As far as I understand, having python3 included in sage is part of the
> deliberate strategy towards porting sage to python3. Since sage comes with
> its own python(2), the most straightforward move of sage would be towards
> sage working on top of an included python3.

The problem is simply the "python3" executable which gets picked up
and breaks things.

> If you're using jupyter for non-sage-specific purposes (apparently relying
> on a system python3), why not use system jupyter? Personally, I just install
> the sage-jupyter kernel in the system jupyter. That way, your main jupyter
> runs independent of sage (other than the extensions that get registered upon
> registering the sage kernel), and doesn't get confused by the system things
> sage does.

Nope.For example, Sage worksheets in Cocalc have a full "jupyter
bridge" that lets you simultaneously use several different Jupyter
kernels from within a Sage session, e.g., in different cells of a
notebook.  Having python3 in the PATH randomly breaks many of these.
Removing it, and everything works fine.

For now I guess we'll keep deleting local/bin/python3 ourselves...

Frickin' Guido...

William


-- 
William (http://wstein.org)

-- 
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 in sage

[Nils Bruin]

On Thursday, August 24, 2017 at 1:30:25 PM UTC-7, William wrote:
>
> I'm not sure what the status is these days, but we may want to stop 
> including a python3 binary in Sage by default with "python3" right 
> there in the "sage -sh" path... 


As far as I understand, having python3 included in sage is part of the 
deliberate strategy towards porting sage to python3. Since sage comes with 
its own python(2), the most straightforward move of sage would be towards 
sage working on top of an included python3.

If you're using jupyter for non-sage-specific purposes (apparently relying 
on a system python3), why not use system jupyter? Personally, I just 
install the sage-jupyter kernel in the system jupyter. That way, your main 
jupyter runs independent of sage (other than the extensions that get 
registered upon registering the sage kernel), and doesn't get confused by 
the system things sage does.

I think we might consider not packaging jupyter with sage, or at least 
making registering sage as a kernel to a foreign jupyter more 
straightforward. The jupyter-sage boundary is bridged by a communication 
protocol, so is a lot easier to manage than the sage-python boundary (which 
is a binary API 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.

Re: [sage-devel] Re: python3 (not yet, and not for soon)

[Frédéric Chapoton]

This seems to fix the core-dumped issue. I have added a suggestion 
to https://trac.sagemath.org/ticket/23325

Le dimanche 6 août 2017 09:44:00 UTC+2, François Bissey a écrit :
>
> In pynac's spkg-intall replace 
> ./configure --disable-static --prefix=${SAGE_LOCAL} --with-giac=no 
> --libdir="$SAGE_LOCAL/lib” 
> with 
> ./configure --disable-static --prefix=${SAGE_LOCAL} --with-giac=no 
> --libdir="$SAGE_LOCAL/lib” PYTHON=python3.6 
> If you have something more subtle for the value of PYTHON, you may try it. 
> Ultimately we’ll have to set that variable, preferably in that place so we 
> can see a record of it in config.log. 
>
> > On 6/08/2017, at 19:23, Frédéric Chapoton  > wrote: 
> > 
> > So what would be an exact brutal and temporary fix ? 
> > 
> > Le dimanche 6 août 2017 09:13:51 UTC+2, François Bissey a écrit : 
> > I have seen this strange thing before on this list I am sure. 
> > For some reason the wrong thing ends up being passed to configure 
> > and be tested. 
> > 
> > A more brutal and effective way to force the issue is to edit 
> > spkg-install for pynac. It will have to be done anyway. 
> > 
> > > On 6/08/2017, at 19:09, Frédéric Chapoton  wrote: 
> > > 
> > > configure:3249: checking whether 
> /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1 version is 
> >= 2.7 
> > > configure:3260: 
> /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1 -c import 
> sys # split strings by '.' and convert to numeric. Append some zeros # 
> because we need at least 4 digits for the hex conversion. # map returns an 
> iterator in Python 3.0 and a list in 2.x minver = list(map(int, 
> '2.7'.split('.'))) + [0, 0, 0] minverhex = 0 # xrange is not present in 
> Python 3.0 and range returns an iterator for i in list(range(0, 4)): 
> minverhex = (minverhex << 8) + minver[i] sys.exit(sys.hexversion < 
> minverhex) 
> > > ./configure: line 3261: 
> /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1: Permission 
> denied 
> > > configure:3263: $? = 126 
> > > configure:3268: result: no 
> > > configure:3270: error: Python interpreter is too old 
> > > 
> > 
> > 
> > -- 
> > 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+...@googlegroups.com . 
> > To post to this group, send email to sage-...@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 (not yet, and not for soon)

[Frédéric Chapoton]

adding a PYTHON=python3 line in spkg-install seems to fix the version check 
issue

Le dimanche 6 août 2017 09:13:51 UTC+2, François Bissey a écrit :
>
> I have seen this strange thing before on this list I am sure. 
> For some reason the wrong thing ends up being passed to configure 
> and be tested. 
>
> A more brutal and effective way to force the issue is to edit 
> spkg-install for pynac. It will have to be done anyway. 
>
> > On 6/08/2017, at 19:09, Frédéric Chapoton  > wrote: 
> > 
> > configure:3249: checking whether 
> /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1 version is 
> >= 2.7 
> > configure:3260: 
> /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1 -c import 
> sys # split strings by '.' and convert to numeric. Append some zeros # 
> because we need at least 4 digits for the hex conversion. # map returns an 
> iterator in Python 3.0 and a list in 2.x minver = list(map(int, 
> '2.7'.split('.'))) + [0, 0, 0] minverhex = 0 # xrange is not present in 
> Python 3.0 and range returns an iterator for i in list(range(0, 4)): 
> minverhex = (minverhex << 8) + minver[i] sys.exit(sys.hexversion < 
> minverhex) 
> > ./configure: line 3261: 
> /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1: Permission 
> denied 
> > configure:3263: $? = 126 
> > configure:3268: result: no 
> > configure:3270: error: Python interpreter is too old 
> > 
>
>

-- 
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 (not yet, and not for soon)

[François Bissey]

In pynac's spkg-intall replace
./configure --disable-static --prefix=${SAGE_LOCAL} --with-giac=no 
--libdir="$SAGE_LOCAL/lib”
with
./configure --disable-static --prefix=${SAGE_LOCAL} --with-giac=no 
--libdir="$SAGE_LOCAL/lib” PYTHON=python3.6
If you have something more subtle for the value of PYTHON, you may try it.
Ultimately we’ll have to set that variable, preferably in that place so we 
can see a record of it in config.log.

> On 6/08/2017, at 19:23, Frédéric Chapoton  wrote:
> 
> So what would be an exact brutal and temporary fix ?
> 
> Le dimanche 6 août 2017 09:13:51 UTC+2, François Bissey a écrit :
> I have seen this strange thing before on this list I am sure. 
> For some reason the wrong thing ends up being passed to configure 
> and be tested. 
> 
> A more brutal and effective way to force the issue is to edit 
> spkg-install for pynac. It will have to be done anyway. 
> 
> > On 6/08/2017, at 19:09, Frédéric Chapoton  wrote: 
> > 
> > configure:3249: checking whether 
> > /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1 version is 
> > >= 2.7 
> > configure:3260: 
> > /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1 -c import 
> > sys # split strings by '.' and convert to numeric. Append some zeros # 
> > because we need at least 4 digits for the hex conversion. # map returns an 
> > iterator in Python 3.0 and a list in 2.x minver = list(map(int, 
> > '2.7'.split('.'))) + [0, 0, 0] minverhex = 0 # xrange is not present in 
> > Python 3.0 and range returns an iterator for i in list(range(0, 4)): 
> > minverhex = (minverhex << 8) + minver[i] sys.exit(sys.hexversion < 
> > minverhex) 
> > ./configure: line 3261: 
> > /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1: Permission 
> > denied 
> > configure:3263: $? = 126 
> > configure:3268: result: no 
> > configure:3270: error: Python interpreter is too old 
> > 
> 
> 
> -- 
> 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 (not yet, and not for soon)

[Frédéric Chapoton]

So what would be an exact brutal and temporary fix ?

Le dimanche 6 août 2017 09:13:51 UTC+2, François Bissey a écrit :
>
> I have seen this strange thing before on this list I am sure. 
> For some reason the wrong thing ends up being passed to configure 
> and be tested. 
>
> A more brutal and effective way to force the issue is to edit 
> spkg-install for pynac. It will have to be done anyway. 
>
> > On 6/08/2017, at 19:09, Frédéric Chapoton  > wrote: 
> > 
> > configure:3249: checking whether 
> /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1 version is 
> >= 2.7 
> > configure:3260: 
> /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1 -c import 
> sys # split strings by '.' and convert to numeric. Append some zeros # 
> because we need at least 4 digits for the hex conversion. # map returns an 
> iterator in Python 3.0 and a list in 2.x minver = list(map(int, 
> '2.7'.split('.'))) + [0, 0, 0] minverhex = 0 # xrange is not present in 
> Python 3.0 and range returns an iterator for i in list(range(0, 4)): 
> minverhex = (minverhex << 8) + minver[i] sys.exit(sys.hexversion < 
> minverhex) 
> > ./configure: line 3261: 
> /home/chapoton/sage3/local/var/lib/sage/installed/python3-3.6.1: Permission 
> denied 
> > configure:3263: $? = 126 
> > configure:3268: result: no 
> > configure:3270: error: Python interpreter is too old 
> > 
>
>

-- 
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.