Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#9304 closed defect (fixed)

trac #8218 (finite_rings) broke all my pickles!

Reported by: was Owned by: was
Priority: minor Milestone: sage-4.6.1
Component: pickling Keywords: pickling
Cc: Merged in: sage-4.6.1.alpha0
Authors: William Stein, David Loeffler Reviewers: John Cremona
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

I have a lot of pickles here (in the data directory):

http://sage.math.washington.edu/home/wstein/db/modsym/

All the ones without "aplist" in their name were broken by trac #8218 which rearranged code without any backwards compatibility imports. This should have never happened. Sigh.

Anyway, my pickles are fixed by just adding back one file.

Attachments (2)

trac_9304-pickling_issue.patch (580 bytes) - added by was 9 years ago.
trac_9304-alternative.patch (844 bytes) - added by davidloeffler 9 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 9 years ago by was

  • Status changed from new to needs_review

Changed 9 years ago by was

Changed 9 years ago by davidloeffler

comment:2 Changed 9 years ago by davidloeffler

This is arguably my fault, since I reviewed #8218. Anyway, we have a much nicer way of fixing unpickling problems now, without all of these annoying file stubs lying around.

sage: load('http://sage.math.washington.edu/home/wstein/db/modsym/data/gamma0-1088-2.sobj')
Attempting to load remote file: http://sage.math.washington.edu/home/wstein/db/modsym/data/gamma0-1088-2.sobj
Loading: [..................................................]
((1088, 2), (0.69604299999997465, 1.0720680000000016, 8.3885230000000206, 11.104694999999936, 21.261328999999932), Modular Symbols space of dimension 148 for Gamma_0(1088) of weight 2 with sign 1 over Rational Field)

You know better than I do whether that's the right output, but at least it isn't raising an error.

comment:3 Changed 9 years ago by cremona

What would be a good way to test this for review?

comment:4 Changed 9 years ago by davidloeffler

Hi John,

Try running the command

sage: load('http://sage.math.washington.edu/home/wstein/db/modsym/data/gamma0-1088-2.sobj')

with and without the patch (either one!) applied. Without the patch you'll get an error similar to the one Salman Baig reports on sage-devel (here). With the patch it should load fine.

comment:5 Changed 9 years ago by cremona

  • Authors set to William Stein, David Loeffler
  • Keywords pickling added
  • Reviewers set to John Cremona
  • Status changed from needs_review to needs_info

With either patch the load is OK but does give a deprecation warning:

sage: load('http://sage.math.washington.edu/home/wstein/db/modsym/data/gamma0-1088-2.sobj')
Attempting to load remote file: http://sage.math.washington.edu/home/wstein/db/modsym/data/gamma0-1088-2.sobj
Loading: [..................................................]
/home/jec/sage-current/local/lib/python2.6/site-packages/IPython/iplib.py:2073: DeprecationWarning: Your data is stored in an old format. Please use the save() function to store your data in a more recent format.
  exec code_obj in self.user_global_ns, self.user_ns
((1088, 2), (0.69604299999997465, 1.0720680000000016, 8.3885230000000206, 11.104694999999936, 21.261328999999932), Modular Symbols space of dimension 148 for Gamma_0(1088) of weight 2 with sign 1 over Rational Field)

which is exactly the same warning as I get without the patch. Am I doing something stupid here?

Of the two patches, I prefer the second ("alternative") since it implements a more general method, and does not need to create that little dummy (almost) file.

comment:6 Changed 9 years ago by davidloeffler

That's weird: it really shouldn't work without the patch! If I run that command in a clean 4.6.alpha3 build, I get the same DeprecationWarning? but it's followed by ImportError: No module named integer_mod_ring. Did you try running it before installing either patch?

If you install William's patch, build, and then qpop it and build again, the file it re-creates will still be lurking in your build directory. If that's the case try switching to a clean branch to see the ImportError.

comment:7 Changed 9 years ago by cremona

  • Status changed from needs_info to needs_review

I think you are right. I tried it before applying patches, saw that something was not right but did not copy the output. When I tried again after removing the patches (using hg qpop and sage -br) it still works!

But I just tried again on another machine, still 4.6.alpha3, and with no patches the load command gives

sage: load('http://sage.math.washington.edu/home/wstein/db/modsym/data/gamma0-1088-2.sobj')
Attempting to load remote file: http://sage.math.washington.edu/home/wstein/db/modsym/data/gamma0-1088-2.sobj
Loading: [..................................................]
/home/jec/sage-current/local/lib/python2.6/site-packages/IPython/iplib.py:2073: DeprecationWarning: Your data is stored in an old format. Please use the save() function to store your data in a more recent format.
  exec code_obj in self.user_global_ns, self.user_ns
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/home/jec/sage-4.6.alpha3/devel/sage-main/<ipython console> in <module>()

/home/jec/sage-current/local/lib/python2.6/site-packages/sage/structure/sage_object.so in sage.structure.sage_object.load (sage/structure/sage_object.c:7486)()

/home/jec/sage-current/local/lib/python2.6/site-packages/sage/structure/sage_object.so in sage.structure.sage_object.loads (sage/structure/sage_object.c:9052)()

/home/jec/sage-current/local/lib/python2.6/site-packages/sage/structure/sage_object.so in sage.structure.sage_object.unpickle_global (sage/structure/sage_object.c:8659)()

ImportError: No module named integer_mod_ring

It's a mystery that popping the patches left a setup in which the load works; and that left open the possibility that the only reason why the second patch worked was that the effect of the first patch was still around (!) so on the second machine I applied the second patch without previously applying the first, and that still worked.

Moreover, then popping the second patch put the system back properly (the load again fails).

So I am giving the *second* patch a positive review.

comment:8 Changed 9 years ago by cremona

  • Status changed from needs_review to positive_review

comment:9 Changed 9 years ago by jdemeyer

  • Merged in set to sage-4.6.1.alpha0
  • Resolution set to fixed
  • Status changed from positive_review to closed

Merged alternative patch

comment:10 Changed 9 years ago by mpatel

  • Milestone changed from sage-4.6 to sage-4.6.1
Note: See TracTickets for help on using tickets.