Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90251] |
Sat, 14 February 2015 11:13  |
lecacheux.alain
Messages: 325 Registered: January 2008
|
Senior Member |
|
|
In a previous IDL session, I built three long LIST() variables made of various arrays and structures (no objects). I then save them, by the usual command:
IDL> save, list1, list2, list3
Problem arises when I want to restore the lists by using:
IDL> restore, 'idlsave.dat'
Actually, IDL crashes immediately. Likely, I made some error in the creation program.
The strange thing is that I can restore my variables by using the IDL_SaveFile object, i.e:
IDL> s = Obj_New('IDL_SaveFile', 'idlsave.dat')
IDL> s.Names()
LIST1
LIST2
LIST3
IDL> s.Restore, 'LIST1'
IDL> s.restore, 'LIST2'
IDL> s.Restore, 'LIST3'
IDL> help, list1, list2, list3
LIST1 LIST <ID=2 NELEMENTS=11916>
LIST2 LIST <ID=23835 NELEMENTS=154366>
LIST3 LIST <ID=332568 NELEMENTS=166282>
Any clue ?
What kind of error might make a successful saveset crashing IDL ?
alx.
|
|
|
|
|
Re: Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90261 is a reply to message #90253] |
Sun, 15 February 2015 08:33   |
chris_torrence@NOSPAM
Messages: 528 Registered: March 2007
|
Senior Member |
|
|
On Saturday, February 14, 2015 at 12:51:23 PM UTC-7, alx wrote:
> Le samedi 14 février 2015 20:17:22 UTC+1, Matthew Argall a écrit :
>> See this discussion.
>>
>> https://groups.google.com/forum/#!topic/comp.lang.idl-pvwave /RWNh8htf8Rw
>
> Thanks for the tip. I know this discussion.
> But in my case, the IDL versions for SAVE, RESTORE and IDL_SaveFile::Restore are homogeneous as being 8.4.
> And the main question is: why a behavior difference between RESTORE and IDL_SaveFile::Restore ?
>
> alx.
Hi alx,
Are you sure that you don't have an old IDL version on your path? When IDL restores the save file, it will try to load the list code, to make sure it is in sync with the latest version. If you have an old version on IDL's path, it will accidentally pick that up and that will lead to problems.
-Chris
|
|
|
Re: Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90262 is a reply to message #90261] |
Sun, 15 February 2015 09:35   |
lecacheux.alain
Messages: 325 Registered: January 2008
|
Senior Member |
|
|
Le dimanche 15 février 2015 17:33:32 UTC+1, Chris Torrence a écrit :
> On Saturday, February 14, 2015 at 12:51:23 PM UTC-7, alx wrote:
>> Le samedi 14 février 2015 20:17:22 UTC+1, Matthew Argall a écrit :
>>> See this discussion.
>>>
>>> https://groups.google.com/forum/#!topic/comp.lang.idl-pvwave /RWNh8htf8Rw
>>
>> Thanks for the tip. I know this discussion.
>> But in my case, the IDL versions for SAVE, RESTORE and IDL_SaveFile::Restore are homogeneous as being 8.4.
>> And the main question is: why a behavior difference between RESTORE and IDL_SaveFile::Restore ?
>>
>> alx.
>
> Hi alx,
>
> Are you sure that you don't have an old IDL version on your path? When IDL restores the save file, it will try to load the list code, to make sure it is in sync with the latest version. If you have an old version on IDL's path, it will accidentally pick that up and that will lead to problems.
>
> -Chris
Hi Chris,
The used machine is a freshly installed one so that I am sure that there is only one IDL (8.4) on it.
{ x86_64 Win32 Windows Microsoft Windows 8.4 Sep 27 2014 64 64}
After a machine reboot the problem disappeared: RESTORE is now restoring correctly.
Before the machine reboot, I just restarted each time the IDL session.
Can we imagine that some error in managing LIST variables inside the first session (loaded DLL or something else) could have permanently affected the other following sessions ?
I suspect the construct "list1 += list_", used in a large loop, when building at first the lists variables.
alain.
|
|
|
Re: Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90265 is a reply to message #90262] |
Mon, 16 February 2015 09:14   |
chris_torrence@NOSPAM
Messages: 528 Registered: March 2007
|
Senior Member |
|
|
On Sunday, February 15, 2015 at 10:35:50 AM UTC-7, alx wrote:
> Le dimanche 15 février 2015 17:33:32 UTC+1, Chris Torrence a écrit :
>> On Saturday, February 14, 2015 at 12:51:23 PM UTC-7, alx wrote:
>>> Le samedi 14 février 2015 20:17:22 UTC+1, Matthew Argall a écrit :
>>>> See this discussion.
>>>>
>>>> https://groups.google.com/forum/#!topic/comp.lang.idl-pvwave /RWNh8htf8Rw
>>>
>>> Thanks for the tip. I know this discussion.
>>> But in my case, the IDL versions for SAVE, RESTORE and IDL_SaveFile::Restore are homogeneous as being 8.4.
>>> And the main question is: why a behavior difference between RESTORE and IDL_SaveFile::Restore ?
>>>
>>> alx.
>>
>> Hi alx,
>>
>> Are you sure that you don't have an old IDL version on your path? When IDL restores the save file, it will try to load the list code, to make sure it is in sync with the latest version. If you have an old version on IDL's path, it will accidentally pick that up and that will lead to problems.
>>
>> -Chris
>
> Hi Chris,
> The used machine is a freshly installed one so that I am sure that there is only one IDL (8.4) on it.
> { x86_64 Win32 Windows Microsoft Windows 8.4 Sep 27 2014 64 64}
> After a machine reboot the problem disappeared: RESTORE is now restoring correctly.
> Before the machine reboot, I just restarted each time the IDL session.
> Can we imagine that some error in managing LIST variables inside the first session (loaded DLL or something else) could have permanently affected the other following sessions ?
> I suspect the construct "list1 += list_", used in a large loop, when building at first the lists variables.
>
> alain.
Well, I can imagine a lot. :-) But I've never heard of this happening... Anyway, it sounds like you solved the problem, so unless it occurs again, I would just pretend that it never happened...
Cheers,
Chris
|
|
|
Re: Different behavior of RESTORE and IDL_SaveFile::Restore ? [message #90266 is a reply to message #90265] |
Mon, 16 February 2015 10:47  |
lecacheux.alain
Messages: 325 Registered: January 2008
|
Senior Member |
|
|
Le lundi 16 février 2015 18:14:07 UTC+1, Chris Torrence a écrit :
> On Sunday, February 15, 2015 at 10:35:50 AM UTC-7, alx wrote:
>> Le dimanche 15 février 2015 17:33:32 UTC+1, Chris Torrence a écrit :
>>> On Saturday, February 14, 2015 at 12:51:23 PM UTC-7, alx wrote:
>>>> Le samedi 14 février 2015 20:17:22 UTC+1, Matthew Argall a écrit :
>>>> > See this discussion.
>>>> >
>>>> > https://groups.google.com/forum/#!topic/comp.lang.idl-pvwave /RWNh8htf8Rw
>>>>
>>>> Thanks for the tip. I know this discussion.
>>>> But in my case, the IDL versions for SAVE, RESTORE and IDL_SaveFile::Restore are homogeneous as being 8.4.
>>>> And the main question is: why a behavior difference between RESTORE and IDL_SaveFile::Restore ?
>>>>
>>>> alx.
>>>
>>> Hi alx,
>>>
>>> Are you sure that you don't have an old IDL version on your path? When IDL restores the save file, it will try to load the list code, to make sure it is in sync with the latest version. If you have an old version on IDL's path, it will accidentally pick that up and that will lead to problems.
>>>
>>> -Chris
>>
>> Hi Chris,
>> The used machine is a freshly installed one so that I am sure that there is only one IDL (8.4) on it.
>> { x86_64 Win32 Windows Microsoft Windows 8.4 Sep 27 2014 64 64}
>> After a machine reboot the problem disappeared: RESTORE is now restoring correctly.
>> Before the machine reboot, I just restarted each time the IDL session.
>> Can we imagine that some error in managing LIST variables inside the first session (loaded DLL or something else) could have permanently affected the other following sessions ?
>> I suspect the construct "list1 += list_", used in a large loop, when building at first the lists variables.
>>
>> alain.
>
> Well, I can imagine a lot. :-) But I've never heard of this happening... Anyway, it sounds like you solved the problem, so unless it occurs again, I would just pretend that it never happened...
>
> Cheers,
> Chris
Ok. Forget it.
But I must also say that I never had any problem with IDL Save/Restore, while using IDL since several decades (since V2.0 on PDP11).
Whence my surprise...
alx.
|
|
|