using load to load objects

[Andrey Novoseltsev]

Hello,

I've tried to use sage-6.5.beta5 on a worksheet from December. It contains

v = load("name")

to load an object from name.sobj, but it no longer works since load(...) in the notebook wants to load source files and requires a second argument (globals) for it as well. Is it intentional and I missed something, or is it a bug? (Which I would consider to be at least critical, if not a blocker...) On the command line this construction still behaves as it should.

Thank you!
Andrey

[kcrisman]

v = load("name")

Really?  Note that this would have to be in the *same cell* as you saved it currently, I think.  (Which I see as a problem, Jeroen does not.)

Does https://github.com/sagemath/sagenb/issues/107 have any relevant info?

[William Stein]

On Wed, Jan 14, 2015 at 5:16 PM, kcrisman <kcri...@gmail.com> wrote:
>>
>> v = load("name")
>>
>
> Really? Note that this would have to be in the *same cell* as you saved it
> currently, I think. (Which I see as a problem, Jeroen does not.)

Often, people would do

v = save(DATA+"myobj")

and

v = load(DATA+"myobj")


Also, load supports grabbing objects from URL's e.g.

s = load("http://wstein.org/tmp/surprise.sobj")

And this all works on the Sage command line for the last 8 years and
does work right *now* in the sage command line in Sage 6.5.beta5. A
change so that "load(...) in the notebook wants to load source files
and requires a second argument (globals) for it as well." is indeed a
major blocker regression.


/scratch/wstein/x/sage-6.5.beta5$ ./sage
┌────────────────────────────────────────────────────────────────────┐
│ Sage Version 6.5.beta5, Release Date: 2015-01-05 │
│ Type "notebook()" for the browser-based notebook interface. │
│ Type "help()" for help. │
└────────────────────────────────────────────────────────────────────┘
sage: s = load("http://wstein.org/tmp/surprise.sobj")
Attempting to load remote file: http://wstein.org/tmp/surprise.sobj
Loading: [.]

>
> Does https://github.com/sagemath/sagenb/issues/107 have any relevant info?
>
>>
>> to load an object from name.sobj, but it no longer works since load(...)
>> in the notebook wants to load source files and requires a second argument
>> (globals) for it as well. Is it intentional and I missed something, or is it
>> a bug? (Which I would consider to be at least critical, if not a blocker...)
>> On the command line this construction still behaves as it should.
>>
>> Thank you!
>> Andrey
>

> --
> You received this message because you are subscribed to the Google Groups
> "sage-notebook" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-noteboo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-notebook.
> For more options, visit https://groups.google.com/d/optout.



--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Jonathan Gutow]

I noticed this too.  Since I have been busy, I just assumed that this was a change people had asked for, but I had missed.  If not, I too request that it be reverted.

Jonathan

[Andrey Novoseltsev]

On Wednesday, 14 January 2015 18:16:32 UTC-7, kcrisman wrote:

v = load("name")

Really?  Note that this would have to be in the *same cell* as you saved it currently, I think.  (Which I see as a problem, Jeroen does not.)

My "name" is an absolute path to a data file and everything worked fine before. The problem is that now a different function is called, "the magic one" I guess, and that's not what I want or what used to happen...

[kcrisman]

> Really?  Note that this would have to be in the *same cell* as you saved it
> currently, I think.  (Which I see as a problem, Jeroen does not.)

Often, people would do

   v = save(DATA+"myobj")

and

   v = load(DATA+"myobj")

Correct, in fact that is even the documented preference in the sagenb help page.

 

change so that "load(...) in the notebook wants to load source files
and requires a second argument (globals) for it as well." is indeed a
major blocker regression.

Also thanks for confirming this Andrey.  I'd be all for having the usual behavior, but I can't think of what we would have done that changed it just in the past version.  Can you try an earlier Sage install?  My guess is that somehow the IPython upgrade is related to this, as a lot of "hooks" changed in ways I don't quite fully understand.

[William Stein]

For what it is worth the Sage notebook didn't make any use of IPython
last time I looked at it. Literally 0. So if somebody decided to
rewrite things to change that (probably a good idea), then this would
likely be a natural side effect.

[Andrey Novoseltsev]

On Thursday, 15 January 2015 19:12:34 UTC-7, kcrisman wrote:

Also thanks for confirming this Andrey.  I'd be all for having the usual behavior, but I can't think of what we would have done that changed it just in the past version.  Can you try an earlier Sage install?  My guess is that somehow the IPython upgrade is related to this, as a lot of "hooks" changed in ways I don't quite fully understand.

All works fine if I use 6.4, so it is the latest sagenb package that broke this, which kind of breaks my research notebook that rely on loading precomputed objects from disks. Computing them each time from scratch is not cool as it takes about an hour for this case.

[William Stein]

The load function just calls something built into Sage, so at least
you can use that as a workaround:

a = 2/3
sage.structure.sage_object.save(a, 'a.sobj')
sage.structure.sage_object.load('a.sobj')

[Andrey Novoseltsev]

On Friday, 16 January 2015 13:48:38 UTC-7, William Stein wrote:

On Fri, Jan 16, 2015 at 11:51 AM, Andrey Novoseltsev <novo...@gmail.com> wrote:
> On Thursday, 15 January 2015 19:12:34 UTC-7, kcrisman wrote:
>>
>> Also thanks for confirming this Andrey.  I'd be all for having the usual
>> behavior, but I can't think of what we would have done that changed it just
>> in the past version.  Can you try an earlier Sage install?  My guess is that
>> somehow the IPython upgrade is related to this, as a lot of "hooks" changed
>> in ways I don't quite fully understand.
>
>
> All works fine if I use 6.4, so it is the latest sagenb package that broke
> this, which kind of breaks my research notebook that rely on loading
> precomputed objects from disks. Computing them each time from scratch is not
> cool as it takes about an hour for this case.

The load function just calls something built into Sage, so at least
you can use that as a workaround:

  a = 2/3
  sage.structure.sage_object.save(a, 'a.sobj')
  sage.structure.sage_object.load('a.sobj')

Yes, but should we allow 6.5 to be released with such a change without any deprecation period? (I am actually fine using 6.4 for this project, I specifically tried to switch to a newer one to see if I can detect any issues with the new notebook in regular use.)

[William Stein]

You're right -- *NO* we should not.

> (I am actually fine using 6.4 for this project, I
> specifically tried to switch to a newer one to see if I can detect any
> issues with the new notebook in regular use.)
>

[Andrey Novoseltsev]

https://github.com/sagemath/sagenb/issues/336
http://trac.sagemath.org/ticket/17645