Closed dimpase closed 5 years ago
So, would this still pop up if right before running these tests you removed ~/.sage/
?
Replying to @dimpase:
So, would this still pop up if right before running these tests you removed
~/.sage/
?
See comment:94. There, it didn't help. Now, it doesn't either:
king@klap:~/Sage/git$ mv ~/.sage/ ~/.sageBAK
king@klap:~/Sage/git$ mkdir ~/.sage
king@klap:~/Sage/git$ sage/sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 8.9.beta8, Release Date: 2019-08-25 │
│ Using Python 2.7.15. Type "help()" for help. │
└────────────────────────────────────────────────────────────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Setting permissions of DOT_SAGE directory so only you can read and write it.
sage: from pGroupCohomology import CohomologyRing
sage: from pGroupCohomology.cohomology import COHO
sage: CohomologyRing.doctest_setup()
sage: CohomologyRing.global_options('debug')
sage: _ = COHO()
Critical bug in python.
kwds.get('root', COHO.workspace) is <type 'str'>
COHO.workspace is <type 'str'>
str=<type 'unicode'>, unicode=<type 'unicode'>
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
<ipython-input-5-a303ce041f27> in <module>()
----> 1 _ = COHO()
pGroupCohomology/cohomology.pyx in pGroupCohomology.cohomology.COHO.__init__()
RuntimeError: An explicit cast to <str> resulted in a unicode object
I wonder if the problem occurs because I am not installing the development versions of my package from an actual "package" (using sage -i p_group_cohomology
), but directly from the sources. I.e., in the src
folder of my development tree, I do
sage -python setup.py build
sage -pip install . --upgrade
I know that sage -python setup.py build
does create .c files in the src folder, but since the changed module is recompiled both in py2 and py3, I thought that it doesn't matter. And for efficiency, I want that only modules are recompiled that have changed.
So, I would like to test if the problem persists when separating the py2- and py3 build folders. When doing sage -python setup.py build
, is it somehow possible to prescribe in what folder the .c
and .pyc
files are created? Then, I could choose separate folders for py2 and py3.
I am now putting cythonize(..., build_dir=os.path.join("build","c_files-{}.{}".format(version_info.major, version_info.minor)))
into my setup.py
. In that way, the c-files will be created in separate directories for both Sage versions.
Let's see if this is enough to solve the problem!
PS: Even if it solves the problem, I will test upon import whether str is unicode in py2, and if it is, raise a RuntimeError
advising to recompile. I hope this error will never pop up...
After changing setup.py so that the .c files will be in different folders for different python versions, tests in cohomology.pyx pass both with py2 and py3 and then py2 again. So, I can now turn to modular_cohomology.pyx and finally init.py (which contains a long doc string, namely the "general overview" of the package).
Hooray! When I ran sage -tp 2 --force-lib --long --warn-long 60.1
, all tests passed both in python 2 and python 3. I don't know how significant the run time differences are. In any case, here are the details:
Python-3
========
Running doctests with ID 2019-09-25-00-50-30-78efa273.
Using --optional=build,dochtml,gap_packages,libsemigroups,meataxe,memlimit,mpir,python2,sage
Sorting sources by runtime so that slower doctests are run first....
Doctesting 13 files using 2 threads.
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/cochain.pxd
[0 tests, 0.00 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/cochain.pyx
[1481 tests, 350.33 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/cohomology.pyx
[1445 tests, 363.25 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/isomorphism_test.py
**********************************************************************
File "/home/king/Projekte/coho/coho-devel/src/pGroupCohomology/isomorphism_test.py", line 67, in pGroupCohomology.isomorphism_test.IsomorphismTest
Warning, slow doctest:
T.explore_isomorphisms() # long time
Test ran for 122.79 s
[213 tests, 221.05 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/modular_cohomology.pyx
[459 tests, 274.13 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/factory.py
[229 tests, 126.99 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/__init__.py
[343 tests, 96.76 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/dickson.pyx
[28 tests, 1.53 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/auxiliaries.py
[39 tests, 0.79 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/barcode.py
[143 tests, 10.31 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/resolution.pxd
[0 tests, 0.00 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/resolution_bindings.pxd
[0 tests, 0.00 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/resolution.pyx
[882 tests, 22.95 s]
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 765.7 seconds
cpu time: 939.6 seconds
cumulative wall time: 1468.1 seconds
Python-2
========
Running doctests with ID 2019-09-25-01-04-47-fa1de7f4.
Git branch: matrix_implementation_keyword
Using --optional=build,ccache,dochtml,frobby,gap_packages,gdb,gfortran,libsemigroups,meataxe,memlimit,mpir,p_group_cohomology,python2,sage
Sorting sources by runtime so that slower doctests are run first....
Doctesting 13 files using 2 threads.
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/cochain.pyx
[1481 tests, 437.44 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/cochain.pxd
[0 tests, 0.00 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/cohomology.pyx
[1445 tests, 465.15 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/isomorphism_test.py
**********************************************************************
File "/home/king/Projekte/coho/coho-devel/src/pGroupCohomology/isomorphism_test.py", line 67, in pGroupCohomology.isomorphism_test.IsomorphismTest
Warning, slow doctest:
T.explore_isomorphisms() # long time
Test ran for 116.79 s
[213 tests, 229.85 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/modular_cohomology.pyx
[459 tests, 312.40 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/factory.py
[229 tests, 124.88 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/__init__.py
[343 tests, 96.86 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/resolution.pxd
[0 tests, 0.00 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/resolution.pyx
[882 tests, 21.38 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/dickson.pyx
[28 tests, 1.63 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/auxiliaries.py
[39 tests, 0.78 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/resolution_bindings.pxd
[0 tests, 0.00 s]
sage -t --long --warn-long 60.1 /home/king/Projekte/coho/coho-devel/src/pGroupCohomology/barcode.py
[143 tests, 14.90 s]
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 873.5 seconds
cpu time: 996.8 seconds
cumulative wall time: 1705.3 seconds
Hence, tomorrow (i.e., in central European time, today in a few hours :-)
) I will create a new package version and post it here for review.
Something more to do: I think I should add a test showing what happens when moving the directory associated with a cohomology ring. The package can cope with moved data, based on some trickery in the attribute _default_filename
that is defined by Sage's unpickler. I've turned _default_filename
into a property (with getter, setter and deleter), and its documentation should contain the new test.
I'm afraid that another test failure popped up. So, I cannot post the new version yet.
Description changed:
---
+++
@@ -1,21 +1,3 @@
+The aim of this ticket is to provide a new version of the optional `p_group_cohomology` spkg so that it builds and passes tests both with python-2 and python-3.
-```
-[p_group_cohomology-3.2] Installing p_group_cohomology-3.2
-[p_group_cohomology-3.2]
-[p_group_cohomology-3.2] Error compiling Cython file:
-[p_group_cohomology-3.2] ------------------------------------------------------------
-[p_group_cohomology-3.2] ...
-[p_group_cohomology-3.2] ## If it doesn't, then we need to find out *after* loading
-[p_group_cohomology-3.2] second_cache_attempt = False
-[p_group_cohomology-3.2] if not coho_options.has_key('@newroot@'):
-[p_group_cohomology-3.2] try:
-[p_group_cohomology-3.2] OUT = _cache.get((GroupKey,StateFile)) or _cache.get((GroupKey,StateFile[:-5]))
-[p_group_cohomology-3.2] except StandardError, msg:
-[p_group_cohomology-3.2] ^
-[p_group_cohomology-3.2] ------------------------------------------------------------
-[p_group_cohomology-3.2]
-[p_group_cohomology-3.2] pGroupCohomology/cohomology.pyx:160:15: undeclared name not builtin: StandardError
-[p_group_cohomology-3.2]
-```
-`StandardError` has been removed in Python3.
-Cf. e.g. http://python3porting.com/differences.html#standarderror
+Hopefully the version number 3.3 (two times three) is appropriate.
After fixing the failed test (in which I forgot to save something before loading it), I added a new feature to unit_test_64
: Previously it was only tested whether the generator degrees and the Poincaré series of a freshly computed cohomology ring is consistent with what is stored in the database; now I test whether the new ring and the stored ring are isomorphic.
Indeed they are, for all groups of order 64. More precisely: In many cases the generators of the relation ideal are not identical. But in all cases, mapping the i-th generator of the new ring to the i-th generator of the old ring results in an isomorphism.
There is one remaining py3 issue, though: When I try to build the documentation, I get the error "No module named sphinx". The documentation does build, when I use py2. What can I do to fix it in py3?
EDIT: Is it not the case that sphinx is installed in Sage for building its documentation, both in py2 and py3? I am not sure if I ever tried to build the documentation of Sage-with-py3, though. Will sphinx be installed when I do a plain make
in Sage (i.e., when I build the docs)?
Sphinx should be installed, yes. Look for SAGE_ROOT/local/lib/python3.7/site-packages/sphinx/
. If you run Sage, can you import sphinx
?
Edit: this is for a Python 3 build of Sage.
Replying to @jhpalmieri:
Sphinx should be installed, yes. Look for
SAGE_ROOT/local/lib/python3.7/site-packages/sphinx/
. If you run Sage, can youimport sphinx
?
It was a trivial mistake: In the doc's Makefile, I had SPHINXBUILD = python -msphinx
, but since python means python-2 even in a py3-install of Sage, I have to use SPHINXBUILD = sage -python -msphinx
I checked that the package builds and passes tests in Sage-with-py3. I checked that when running the tests directly on the sources (not during package installation) the tests pass in Sage-with-py2. I recommend that whoever reviews this tries the package both in py2 and in py3.
New commits:
2e0d11e | Pass unpickling options to pickle.load, default encoding 'latin1'. Accept both str and bytes in mtx_unpickle |
8c105cd | Make str_to_bytes/bytes_to_str accept both str and bytes input. |
c8a0748 | Add tests for #28444 |
89ac77a | Fix keyword for py3-only test |
3693024 | Fix doc strings in sage.misc.persist |
f0828ee | Add a comment regarding the expected data type for an unpickle helper |
ba41ebe | Fix two typos in a comment |
463806c | Upgrade p_group_cohomology to version 3.3 |
Commit: 463806c
Author: Simon King
Description changed:
---
+++
@@ -1,3 +1,7 @@
The aim of this ticket is to provide a new version of the optional `p_group_cohomology` spkg so that it builds and passes tests both with python-2 and python-3.
Hopefully the version number 3.3 (two times three) is appropriate.
+
+[Package documentation](https://users.fmi.uni-jena.de/cohomology/documentation/)
+
+[Source ball](https://users.fmi.uni-jena.de/cohomology/p_group_cohomology-3.3.tar.xz)
Hooray! In Py2, sage -f -c p_group_cohomology
results in
...
[p_group_cohomology-3.3] Running the test suite for p_group_cohomology-3.3...
[p_group_cohomology-3.3] make[2]: Entering directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1'
[p_group_cohomology-3.3] Making check in src
[p_group_cohomology-3.3] make[3]: Entering directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1/src'
[p_group_cohomology-3.3] make mnttest.sh
[p_group_cohomology-3.3] make[4]: Entering directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1/src'
[p_group_cohomology-3.3] test -r ./test.reg || cp ./test.reg .
[p_group_cohomology-3.3] make[4]: Leaving directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1/src'
[p_group_cohomology-3.3] make check-TESTS
[p_group_cohomology-3.3] make[4]: Entering directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1/src'
[p_group_cohomology-3.3] make[5]: Entering directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1/src'
[p_group_cohomology-3.3] PASS: mnttest.sh
[p_group_cohomology-3.3] ============================================================================
[p_group_cohomology-3.3] Testsuite summary for modular_resolution 1.1
[p_group_cohomology-3.3] ============================================================================
[p_group_cohomology-3.3] # TOTAL: 1
[p_group_cohomology-3.3] # PASS: 1
[p_group_cohomology-3.3] # SKIP: 0
[p_group_cohomology-3.3] # XFAIL: 0
[p_group_cohomology-3.3] # FAIL: 0
[p_group_cohomology-3.3] # XPASS: 0
[p_group_cohomology-3.3] # ERROR: 0
[p_group_cohomology-3.3] ============================================================================
[p_group_cohomology-3.3] make[5]: Leaving directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1/src'
[p_group_cohomology-3.3] make[4]: Leaving directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1/src'
[p_group_cohomology-3.3] make[3]: Leaving directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1/src'
[p_group_cohomology-3.3] make[3]: Entering directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1'
[p_group_cohomology-3.3] make[3]: Leaving directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1'
[p_group_cohomology-3.3] make[2]: Leaving directory '/home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3/src/modular_resolution-1.1'
[p_group_cohomology-3.3] Running doctests with ID 2019-09-26-11-19-11-b01ece2b.
[p_group_cohomology-3.3] Git branch: t/28414/p_group_cohomology_in_py_3
[p_group_cohomology-3.3] Using --optional=build,ccache,dochtml,frobby,gap_packages,gdb,gfortran,libsemigroups,meataxe,memlimit,mpir,python2,sage
[p_group_cohomology-3.3] Sorting sources by runtime so that slower doctests are run first....
[p_group_cohomology-3.3] Doctesting 13 files using 3 threads.
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/modular_cohomology.pyx
[p_group_cohomology-3.3] [459 tests, 456.02 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/cochain.pxd
[p_group_cohomology-3.3] [0 tests, 0.00 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/cochain.pyx
[p_group_cohomology-3.3] [1481 tests, 599.35 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/cohomology.pyx
[p_group_cohomology-3.3] [1465 tests, 606.86 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/isomorphism_test.py
[p_group_cohomology-3.3] **********************************************************************
[p_group_cohomology-3.3] File "pGroupCohomology-3.3/pGroupCohomology/isomorphism_test.py", line 67, in pGroupCohomology.isomorphism_test.IsomorphismTest
[p_group_cohomology-3.3] Warning, slow doctest:
[p_group_cohomology-3.3] T.explore_isomorphisms() # long time
[p_group_cohomology-3.3] Test ran for 161.47 s
[p_group_cohomology-3.3] [213 tests, 307.72 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/__init__.py
[p_group_cohomology-3.3] [343 tests, 148.33 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/factory.py
[p_group_cohomology-3.3] **********************************************************************
[p_group_cohomology-3.3] File "pGroupCohomology-3.3/pGroupCohomology/factory.py", line 133, in pGroupCohomology.factory.unit_test_64
[p_group_cohomology-3.3] Warning, slow doctest:
[p_group_cohomology-3.3] L, t = unit_test_64(from_scratch=False) # long time
[p_group_cohomology-3.3] Test ran for 99.46 s
[p_group_cohomology-3.3] [229 tests, 209.64 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/resolution.pxd
[p_group_cohomology-3.3] [0 tests, 0.00 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/resolution.pyx
[p_group_cohomology-3.3] [882 tests, 26.85 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/dickson.pyx
[p_group_cohomology-3.3] [28 tests, 1.41 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/barcode.py
[p_group_cohomology-3.3] [143 tests, 21.04 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/resolution_bindings.pxd
[p_group_cohomology-3.3] [0 tests, 0.00 s]
[p_group_cohomology-3.3] sage -t --long --warn-long 80.0 pGroupCohomology-3.3/pGroupCohomology/auxiliaries.py
[p_group_cohomology-3.3] [39 tests, 0.92 s]
[p_group_cohomology-3.3] ----------------------------------------------------------------------
[p_group_cohomology-3.3] All tests passed!
[p_group_cohomology-3.3] ----------------------------------------------------------------------
[p_group_cohomology-3.3] Total time for all tests: 815.2 seconds
[p_group_cohomology-3.3] cpu time: 1261.3 seconds
[p_group_cohomology-3.3] cumulative wall time: 2378.1 seconds
[p_group_cohomology-3.3]
[p_group_cohomology-3.3] real 13m52.051s
[p_group_cohomology-3.3] user 22m48.984s
[p_group_cohomology-3.3] sys 4m1.098s
[p_group_cohomology-3.3] Successfully installed p_group_cohomology-3.3
[p_group_cohomology-3.3] Deleting temporary build directory
[p_group_cohomology-3.3] /home/king/Sage/git/sage/local/var/tmp/sage/build/p_group_cohomology-3.3
[p_group_cohomology-3.3] Finished installing p_group_cohomology-3.3.spkg
make[1]: Leaving directory '/home/king/Sage/git/sage/build/make'
real 27m19.468s
user 30m7.398s
sys 4m10.930s
Sage build/upgrade complete!
In Py3, I had more warnings about slow tests (six instead of two, if I recall correctly), but perhaps my laptop (or its harddisk) was busy with other things.
Now I am running unit_test_64
in Python-2. Note that in Python-3 I got about 20 (or even more) examples where the freshly computed relation ideal was presented by a different set of generators than what was stored in the database. But, as I have mentioned in comment:82, this seems to be Singular not doing all tail reduction in py2.
Replying to @simon-king-jena:
Now I am running
unit_test_64
in Python-2. Note that in Python-3 I got about 20 (or even more) examples where the freshly computed relation ideal was presented by a different set of generators than what was stored in the database.
Just for the record: In the py2 version, the freshly computed results were identical (not only equal up to generator choice) to the stored results.
By the way, at the recent Sage Days in Bonn, I learnt how to host the package repository at github and use Travis CI to some extent. I have posted the link to the ticket description.
Note, however, that testing it on Travis CI with python-3 will be difficult: I was told that the current Sage-with-py3 docker image is rather outdated, and also I don't know how I should write my .travis.yml
so that the automatic tests involve both py2 and py3. The answer on sage-devel didn't help me much. Is someone reading this who can tell me how I should modify .travis.yml
?
Description changed:
---
+++
@@ -5,3 +5,5 @@
[Package documentation](https://users.fmi.uni-jena.de/cohomology/documentation/)
[Source ball](https://users.fmi.uni-jena.de/cohomology/p_group_cohomology-3.3.tar.xz)
+
+[p_group_cohomology at Travis CI](https://travis-ci.org/sagemath/p_group_cohomology)
Suppose I delete .sage/pGroupCohomology/
, to force the package to reinstall those files. Then
[p_group_cohomology-3.3] IOError: Saved data at /Users/jpalmier/.sage/pGroupCohomology/db/4gp2/H4gp2.sobj are not readable: expected bytes, unicode found
I guess I have a few questions:
.sobj
files which are readable by Python 2?.sobj
file and rebuild in this case? .sobj
file — maybe somehow the file got corrupted — should it just rebuild?This particular problem should not happen much: people won't be switching from Python 3 to Python 2 very much. So don't work too hard to get the Python 3 version to produce .sobj
files which are readable by Python 2.
Replying to @jhpalmieri:
Suppose I delete
.sage/pGroupCohomology/
, to force the package to reinstall those files. Then
- if I build with Python 2 first and then Python 3, all tests pass.
- if I build with Python 3 first and then Python 2, I get failures:
[p_group_cohomology-3.3] IOError: Saved data at /Users/jpalmier/.sage/pGroupCohomology/db/4gp2/H4gp2.sobj are not readable: expected bytes, unicode found
It was a good idea to do such tests. And I am surprised about the error message: There is no use of bytes in the whole cohomology package. Perhaps the error is about unpickling a MeatAxe matrix (sage.matrix.matrix_gfpn_dense.Matrix_gfpn_dense
)? But this was supposed to be fixed in #28444.
I guess I have a few questions:
- is it possible (and not too much work to implement) for the Python 3 version to build
.sobj
files which are readable by Python 2?
I thought they were.
- if not, should the package discard the existing
.sobj
file and rebuild in this case?- more generally, if there is any error reading the
.sobj
file — maybe somehow the file got corrupted — should it just rebuild?
It is already the case that if some data source provides data in legacy format, it will automatically be overwritten by a new pickle.
This particular problem should not happen much: people won't be switching from Python 3 to Python 2 very much. So don't work too hard to get the Python 3 version to produce
.sobj
files which are readable by Python 2.
But it should still work and needs to be investigated.
I'll follow your instructions (remove .sage/pGroupCOhomology
, install (and also test?) with Python 3 and then install with Python 2 and see what is happening.
Replying to @simon-king-jena:
I'll follow your instructions (remove
.sage/pGroupCOhomology
, install (and also test?) with Python 3 and then install with Python 2 and see what is happening.
I installed and tested when I did this, but just now I hit the same error with:
sage: from pGroupCohomology import CohomologyRing
sage: CohomologyRing(16, 2)
H^*(SmallGroup(16,2); GF(2))
sage: from pGroupCohomology import CohomologyRing
sage: CohomologyRing(16, 2)
---------------------------------------------------------------------------
IOError Traceback (most recent call last)
<ipython-input-2-e1924d996e12> in <module>()
----> 1 CohomologyRing(Integer(16), Integer(2))
/Users/jpalmier/Desktop/Sage/sage_builds/py2/sage-8.9.rc1/local/lib/python2.7/site-packages/pGroupCohomology/factory.pyc in __call__(self, *args, **kwds)
1778 if q < 128:
1779 extras['websource'] = False
-> 1780 OUT = self._check_compatibility(CacheKey, self._get_p_group_from_cache_or_db(GStem, KEY, **extras) or self._get_p_group_from_scratch(KEY, q, GStem, GroupName, **extras))
1781 return OUT
1782
/Users/jpalmier/Desktop/Sage/sage_builds/py2/sage-8.9.rc1/local/lib/python2.7/site-packages/pGroupCohomology/factory.pyc in _get_p_group_from_cache_or_db(self, GStem, KEY, **kwds)
1209 if '@use_this_root@' in coho_options:
1210 del coho_options['@use_this_root@']
-> 1211 raise IOError("Saved data at %s are not readable: %s"%(os.path.join(root_workspace,file_name), msg))
1212 ## 3. Link with local sources and load from there
1213 elif root_local_sources and os.access(os.path.join(root_local_sources,file_name), os.R_OK) and not from_scratch:
IOError: Saved data at /Users/jpalmier/.sage/pGroupCohomology/db/16gp2/H16gp2.sobj are not readable: NEWOBJ class argument isn't a type object
Probably the following would work, too (so that it is not always needed to reinstall):
Anyway, after doing the py3 test suit, I can confirm what you reported: The stuff in .sage/pGroupCohomology/db/16gp2
cannot be unpickled with py2. In particular, the state descriptor cannot be loaded:
sage: S = load('/home/king/.sage/pGroupCohomology/db/16gp2/dat/State.sobj')
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-3-2796f9b01dc5> in <module>()
----> 1 S = load('/home/king/.sage/pGroupCohomology/db/16gp2/dat/State.sobj')
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/persist.pyx in sage.misc.persist.load (build/cythonized/sage/misc/persist.c:2845)()
157
158 ## Load file by absolute filename
--> 159 with open(filename, 'rb') as fobj:
160 X = loads(fobj.read(), compress=compress, **kwargs)
161 try:
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/persist.pyx in sage.misc.persist.load (build/cythonized/sage/misc/persist.c:2795)()
158 ## Load file by absolute filename
159 with open(filename, 'rb') as fobj:
--> 160 X = loads(fobj.read(), compress=compress, **kwargs)
161 try:
162 X._default_filename = os.path.abspath(filename)
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/persist.pyx in sage.misc.persist.loads (build/cythonized/sage/misc/persist.c:6929)()
1043
1044 unpickler = SageUnpickler(io.BytesIO(s), **kwargs)
-> 1045 return unpickler.load()
1046
1047
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/persist.pyx in sage.misc.persist._BaseUnpickler.load (build/cythonized/sage/misc/persist.c:5806)()
655
656 def load(self):
--> 657 return self._unpickler.load()
658
659 def noload(self):
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/structure/factory.pyx in sage.structure.factory.lookup_global (build/cythonized/sage/structure/factory.c:4615)()
748 Integer Ring
749 """
--> 750 name = bytes_to_str(name, encoding='ASCII')
751 try:
752 return factory_unpickles[name]
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/cpython/string.pxd in sage.cpython.string.bytes_to_str (build/cythonized/sage/structure/factory.c:5038)()
55 return b
56 if type(b) is not bytes:
---> 57 raise TypeError(f"expected bytes, {type(b).__name__} found")
58
59 if PY_MAJOR_VERSION <= 2:
TypeError: expected bytes, unicode found
And I guess this can be fixed in bytes_to_str
: After the changes in #28444, bytes_to_str
is more tolerant about the input type (it may be str), but it should be even more so. It should (in py2) accept unicode.
I think it's good enough if py2-created pickles work with py3.
Require the opposite compatibility seems to be an overkill.
Replying to @dimpase:
I think it's good enough if py2-created pickles work with py3.
Require the opposite compatibility seems to be an overkill.
I believe the fix (in #28540) would be relatively easy.
If you think that we shouldn't worry so much about reading py3-pickles in py2, then of course the group cohomology package can be reviewed as it is now. If I am right about #28640, then #28540 will fix the unpickling of py3-cohomology in py2 without any change in the package.
Replying to @simon-king-jena:
And I guess this can be fixed in
bytes_to_str
: After the changes in #28444,bytes_to_str
is more tolerant about the input type (it may be str), but it should be even more so. It should (in py2) accept unicode.
I think that at this point it's becoming pretty clear you should use a routine that is not named bytes_to_str
, but a routine "ensure_str", which in py3 accepts unicode=str and return the result unchanged, and also accepts py2's "bytes=str" objects and assumes it's "latin1" encoded, because that's what it would have been as a "str" in py2.
You are clearly NOT converting a "bytes" object to a "str" here; you are ensuring something is a "str", doing some conversions if necessary. You should use a routine that reflects that in its name if you need specific behaviour.
The reason why I care is because you are changing routines in sage.cpython.string, which people will expect to contain widely valid; well-defined routines. Stretching them up with hacks for specific purposes will lead to silent erroneous behaviour further down the line, when these routines are used in other contexts because they sound like the right tool (but aren't).
If it gets a py3 "unicode" object in py2, ideally it could just leave it as unicode, because that should be valid in str contexts in py2 for the most time as well. But we may be far from the ideal in py2. A safe choice would be str(<unicode>)
to ensure you actually get a py2 str. That uses "ascii" encoding, so it may fail. You could allow for "UTF-8" but that would not round-trip correctly with the "latin1" on the other side. Using "latin1" for encoding unicode-to-str on py2 may also fail, because not all unicode code points have an encoding in "latin1".
Replying to @nbruin:
The reason why I care is because you are changing routines in sage.cpython.string, which people will expect to contain widely valid; well-defined routines. Stretching them up with hacks for specific purposes will lead to silent erroneous behaviour further down the line, when these routines are used in other contexts because they sound like the right tool (but aren't).
Agreed. I have already changed the topic of #28540.
If it gets a py3 "unicode" object in py2, ideally it could just leave it as unicode, because that should be valid in str contexts in py2 for the most time as well. But we may be far from the ideal in py2. A safe choice would be
str(<unicode>)
to ensure you actually get a py2 str. That uses "ascii" encoding, so it may fail.
The application (and the place where #28540 should be changed) is sage.structure.factory.lookup_global
. This function used to only accept str. By #28444, it also accepts bytes, which makes it possible to unpickle a py2-pickle in py3.
I suggest in #28540 that it also accepts a unicode. This makes it possible to unpickle a py3-pickle in py2.
Again, I won't make this a dependency for the cohomology package.
sage: from pGroupCohomology import CohomologyRing
sage: H = CohomologyRing(16,2,options='debug')
_get_p_group_from_cache_or_db:
Data found at /home/king/.sage/pGroupCohomology/db/16gp2/H16gp2.sobj
Group data are rooted at '/home/king/.sage/pGroupCohomology/db'.
Loading a cohomology ring:
The state descriptor of the to-be-unpickled ring is expected to be provided at u'/home/king/.sage/pGroupCohomology/db/16gp2/dat/State.sobj'
---------------------------------------------------------------------------
IOError Traceback (most recent call last)
<ipython-input-2-a62afc150e39> in <module>()
----> 1 H = CohomologyRing(Integer(16),Integer(2),options='debug')
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/pGroupCohomology/factory.pyc in __call__(self, *args, **kwds)
1778 if q < 128:
1779 extras['websource'] = False
-> 1780 OUT = self._check_compatibility(CacheKey, self._get_p_group_from_cache_or_db(GStem, KEY, **extras) or self._get_p_group_from_scratch(KEY, q, GStem, GroupName, **extras))
1781 return OUT
1782
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/pGroupCohomology/factory.pyc in _get_p_group_from_cache_or_db(self, GStem, KEY, **kwds)
1209 if '@use_this_root@' in coho_options:
1210 del coho_options['@use_this_root@']
-> 1211 raise IOError("Saved data at %s are not readable: %s"%(os.path.join(root_workspace,file_name), msg))
1212 ## 3. Link with local sources and load from there
1213 elif root_local_sources and os.access(os.path.join(root_local_sources,file_name), os.R_OK) and not from_scratch:
IOError: Saved data at /home/king/.sage/pGroupCohomology/db/16gp2/H16gp2.sobj are not readable: NEWOBJ class argument isn't a type object
So, the previous error arising in lookup_global has gone.
I am afraid the new error looks more like an error that needs to be fixed in the package, not in the Sage library. We will see...
Next step of debugging.
In Py2, where we still have py3-pickles in DOT_SAGE
:
sage: from pGroupCohomology.cohomology import COHO
sage: H = COHO()
sage: S = load('/home/king/.sage/pGroupCohomology/db/16gp2/dat/State.sobj')
sage: H.__setstate__(S)
---------------------------------------------------------------------------
IOError Traceback (most recent call last)
<ipython-input-4-9c79e2f6e0a6> in <module>()
----> 1 H.__setstate__(S)
pGroupCohomology/cohomology.pyx in pGroupCohomology.cohomology.COHO.__setstate__()
IOError: Unable to read resolution saved at /home/king/Sage/git/sage/local/share/pGroupCohomology/16gp2/dat/R16gp2.sobj
The same in py3:
sage: from pGroupCohomology.cohomology import COHO
sage: H = COHO()
sage: S = load('/home/king/.sage/pGroupCohomology/db/16gp2/dat/State.sobj')
sage: H.__setstate__(S)
sage: print(H)
Cohomology ring of Small Group number 2 of order 16 with coefficients in GF(2)
Computation complete
Minimal list of generators:
[c_2_1: 2-Cocycle in H^*(SmallGroup(16,2); GF(2)),
c_2_2: 2-Cocycle in H^*(SmallGroup(16,2); GF(2)),
c_1_0: 1-Cocycle in H^*(SmallGroup(16,2); GF(2)),
c_1_1: 1-Cocycle in H^*(SmallGroup(16,2); GF(2))]
Minimal list of algebraic relations:
[c_1_0^2,
c_1_1^2]
So, the error is now moved to __setstate__
. I guess I'll fix it there.
Meanwhile I know at what point the error mentioned in comment:125 arises:
sage: pg_RESL_sparse_unpickle_class = unpickle_global('pGroupCohomology.resolution', 'RESL_sparse_unpickle_class')
sage: si1 = unpickle_newobj(pg_RESL_sparse_unpickle_class, ())
---------------------------------------------------------------------------
UnpicklingError Traceback (most recent call last)
<ipython-input-2-855d0a850e70> in <module>()
----> 1 si1 = unpickle_newobj(pg_RESL_sparse_unpickle_class, ())
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/explain_pickle.pyc in unpickle_newobj(klass, args)
2438 return pers[int(id)]
2439
-> 2440 return SageUnpickler.loads(pickle, persistent_load=pers_load)
2441
2442
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/persist.pyx in sage.misc.persist.SageUnpickler.loads (build/cythonized/sage/misc/persist.c:6467)()
962 """
963
--> 964 return cls(io.BytesIO(data), **kwargs).load()
965
966
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/persist.pyx in sage.misc.persist._BaseUnpickler.load (build/cythonized/sage/misc/persist.c:5806)()
655
656 def load(self):
--> 657 return self._unpickler.load()
658
659 def noload(self):
UnpicklingError: NEWOBJ class argument isn't a type object
But I do not have the faintest idea yet what this error means. For comparison, in py3 I get
sage: pg_RESL_sparse_unpickle_class = unpickle_global('pGroupCohomology.resolution', 'RESL_sparse_unpickle_class')
sage: si1 = unpickle_newobj(pg_RESL_sparse_unpickle_class, ())
sage: si1
<pGroupCohomology.resolution.RESL_sparse_unpickle_class object at 0x7f2ee987abe0>
I'm guessing that a class in Python-3 is a type, but in Python-2 it generally isn't. Is that the meaning of the error? But isn't it the case that a class defined in Cython (here: resolution.pyx) automatically is a type?
Anyway, I'll try to turn class RESL_sparse_unpickle_class
into class RESL_sparse_unpickle_class(object)
and see if it helps.
Replying to @simon-king-jena:
Anyway, I'll try to turn
class RESL_sparse_unpickle_class
intoclass RESL_sparse_unpickle_class(object)
and see if it helps.
Nope.
sage: from pGroupCohomology.resolution import RESL_sparse_unpickle_class
sage: RESL_sparse_unpickle_class
<class 'pGroupCohomology.resolution.RESL_sparse_unpickle_class'>
sage: isinstance(_, type)
True
but still
sage: pg_RESL_sparse_unpickle_class = unpickle_global('pGroupCohomology.resolution', 'RESL_sparse_unpickle_class')
sage: si1 = unpickle_newobj(pg_RESL_sparse_unpickle_class, ())
Traceback (most recent call last):
...
UnpicklingError: NEWOBJ class argument isn't a type object
Odd. After trying again, the error is gone. In Py2:
sage: R = load("/home/king/.sage/pGroupCohomology/db/16gp2/dat/R16gp2.sobj")
---------------------------------------------------------------------------
OSError Traceback (most recent call last)
<ipython-input-1-c703eea54ef8> in <module>()
----> 1 R = load("/home/king/.sage/pGroupCohomology/db/16gp2/dat/R16gp2.sobj")
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/persist.pyx in sage.misc.persist.load (build/cythonized/sage/misc/persist.c:2845)()
157
158 ## Load file by absolute filename
--> 159 with open(filename, 'rb') as fobj:
160 X = loads(fobj.read(), compress=compress, **kwargs)
161 try:
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/persist.pyx in sage.misc.persist.load (build/cythonized/sage/misc/persist.c:2795)()
158 ## Load file by absolute filename
159 with open(filename, 'rb') as fobj:
--> 160 X = loads(fobj.read(), compress=compress, **kwargs)
161 try:
162 X._default_filename = os.path.abspath(filename)
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/persist.pyx in sage.misc.persist.loads (build/cythonized/sage/misc/persist.c:6929)()
1043
1044 unpickler = SageUnpickler(io.BytesIO(s), **kwargs)
-> 1045 return unpickler.load()
1046
1047
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/misc/persist.pyx in sage.misc.persist._BaseUnpickler.load (build/cythonized/sage/misc/persist.c:5806)()
655
656 def load(self):
--> 657 return self._unpickler.load()
658
659 def noload(self):
pGroupCohomology/resolution.pyx in pGroupCohomology.resolution.RESL_sparse_unpickle_class.__call__()
pGroupCohomology/resolution.pyx in pGroupCohomology.resolution.RESL.__init__()
OSError: Bad file format in file pgroup.c (line 404)
So, now complain about NEWOBJ any more.
Spoke too soon. Immediately after this different error (i.e., in the same session), I again got the "NEWOBJ" error.
sage: from pGroupCohomology.resolution import RESL_sparse_unpickle_class
sage: pg_RESL_sparse_unpickle_class is RESL_sparse_unpickle_class
False
In a different session, I got the answer "True".
Anyway, the error about "NEWOBJ" comes from python. It seems that python decided to kill data persistency. I tried to work around to the extent that py2-pickles of cohomology rings seem to be legible in py3. But I think I will not work further on making py3-pickles legible in py2.
Another question: Why is the branch of this ticket shown red?
The oddity is: Sometimes pg_RESL_sparce_unpickle_class
is RESL_sparse_unpickle_class
and sometimes it isn't. When the error occurs, I get
sage: pg_RESL_sparse_unpickle_class
<class pGroupCohomology.auxiliaries.unpickle_old_resl at 0x7fb8d4f549a8>
It is not nice that unpickle_global('pGroupCohomology.resolution', 'RESL_sparse_unpickle_class')
sometimes returns something else. But perhaps it is worth trying to make this class inherit from object
.
Replying to @simon-king-jena:
But perhaps it is worth trying to make this class inherit from
object
.
Nope, didn't help. As there doesn't seem to be an easy fix, I do not plan to work further on it.
Do I understand correctly that I have to rebase on the current develop branch?
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
7ad6a4a | Upgrade p_group_cohomology to version 3.3 |
Maybe it would be simpler, if any error arises reading a pickle, to just delete and reproduce the pickle file. Compatibility going from Python 3 to Python 2 may be annoying to debug and to fix, and besides, there may be other errors that we haven't foreseen.
Or as you say, to just not work on the Py3 -> Py2 conversion. That's fine with me.
I am using unpickle_override for RESL_sparse_unpickle_class
, but I am not sure if that's needed at all.
Bummer. Apparently I have destroyed the git repository for my py3 installation. It says:
king@klap:~/Sage/git/py3$ git lg
fatal: your current branch 't/28444/fix_backwards_incompatibility_of_unpickling_in_python_3' does not have any commits yet
and ALL files in the Sage tree are untracked. How has that happened, and how to fix it?
Hopefully John has a version of this branch just before you did that fateful forced push.
There could be copies left on patchbots, maybe LinuxMint/18.2/x86_64/4.8.0-53-generic/pc78-math patchbot does have it...
Unfortunately I don't, but there are the commits in comment:113 which are still accessible.
yes, indeed, these commits are available in the full "git fetch trac" - I have them locally, in case they get gc'd.
Replying to @dimpase:
Hopefully John has a version of this branch just before you did that fateful forced push.
git branch -d
. As a result, all files in the py3 worktree are now untracked, as is shown by git status
, and git log
says that there has never been a commit. Again, I am talking about only one of my two worktrees.git branch -d
on it.So, from my perspective, "solving the problem" means "allowing me to do git checkout <branchname>
in the py3-worktree" -- this currently is refused, because git claims that I should first commit or stash the whole Sage library.
Would git checkout -f <branch_name>
possibly help? Or would I possibly destroy even more?
The aim of this ticket is to provide a new version of the optional
p_group_cohomology
spkg so that it builds and passes tests both with python-2 and python-3.Hopefully the version number 3.3 (two times three) is appropriate.
Package documentation
Source ball
p_group_cohomology at Travis CI
Depends on #28444
CC: @simon-king-jena
Component: packages: optional
Author: Simon King
Branch:
6c5dafc
Reviewer: John Palmieri
Issue created by migration from https://trac.sagemath.org/ticket/28414